Introducción a UML

Carlos Reynoso
Universidad de Buenos Aires
Billyreyno@hotmail.com
http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/arquitectura_soft.mspx
 Agenda
• Contexto
– Arquitectura de Software
– Métodos ágiles (XP y otros)
– Modelado orientado a objetos
• Elementos
• Diagramas
• Limitaciones
• Conclusiones
 UML - Antecedentes
• Lenguaje Unificado de Modelado: Lenguaje para
especificar, visualizar y documentar los artefactos
de los sistemas
• Grady Booch (Booch) + Jim Rumbaugh (OMT) +
Ivar Jacobson (Objectory), 1994 
• Estándar de OMG (Object Management Group)
desde 1997 [ http://www-omg.org ]
• Versión 2.0: notación simplificada
 UML – Significación
• Definición: Es una familia de notaciones gráficas, útil para
diseñar sistemas de software, particularmente sistemas que
habrán de desarrollarse en términos de OO.
• Desde su establecimiento ca. 1997, ha desplazado a una
multitud de lenguajes gráficos de modelado OO (lo cual es
de agradecer)
• Mellor y Fowler: principales usos
– Sketch (selectivo) *
– Blueprint (completo) – Igual a CASE, en desgracia
– Lenguaje de programación – MDA, Executable UML. No realista
en opinión de Fowler.
• Fowler: No existe ningún estándar que especifique cómo
mapea UML sobre un lenguaje de programación en
particular
 UML - Building blocks
• 7 Elementos Estructurales
– Clases, Interfaces, Colaboraciones, Casos de uso, Clases activas,
Componentes, Nodos
• 2 Elementos de Comportamiento
– Interacciones (mensajes, secuencias & enlaces), máquinas de estado
• 1 elemento de agrupación: paquetes
• 1 elemento de anotación
• 4 Relaciones
– Dependencia, asociación, generalización, realización
• 9 Diagramas
 UML - Diagramas
• Estáticos:
– Diagramas de clases
– Diagramas de objetos
– Diagramas de componentes
– Diagramas de despliegue
• Dinámicos:
– Diagramas de casos de uso
– Diagramas de secuencia
– Diagramas de colaboración
– Diagramas de estados
– Diagramas de actividades
UML 2 – Diagramas
 RUP
• Milestones - Por primera
vez en Boehm, 1996:
– Incepción - Visión y
alcance - Life Cycle
Objective Milestone
– Elaboración - Riesgos,
arquitectura y planes - Life
Cycle Architecture
Milestone
– Construcción - Diseño
detallado - Operation
Capability Milestone
– Transición - Fine tuning -
Product Release Milestone
 Fases de análisis y diseño

Definición Definición Definición

Definición
del modelo de diagramas de diagramas de
de casos de uso
del dominio de interacción clases diseño

• Casos de uso: Análisis de requerimientos

• Modelo de dominio: Conceptos, atributos y asociaciones
• Diagramas de interacción: Flujo de mensajes (invocación
de métodos)
• Diagramas de clases: Métodos requeridos por los mensajes
 Análisis de requerimientos
• En UP los requerimientos se clasifican
conforme al modelo FURPS+ [Grady92]:
– Funcional [Casos de uso]
– Usabilidad: Factor humano, documentación
– Fiabilidad (Reliability)
– Performance
– Soporte: Mantenimiento, configurabilidad...
– +: Adicionales (packaging, legales...)
 Análisis de requerimientos
• Casos de uso:
– Writing effective use cases [Cockburn01]
– Software Engineering Body of Knowledge,
http://www.swebok.org
– ISO 9126, IEEE Std 830, IEEE Std 1061
– SEI - Carnegie Mellon
• Introducidos por Jacobson (86) para
describir requerimientos funcionales
 Casos de Uso
• Los casos de uso son requerimientos, pero no todos los
requerimientos
• Son documentos de texto, no diagramas (aunque en UML
hay diagramas de casos de uso)
• No están ligados a OOD u OOP
• Anderson, Fowler, Cockburn... recomiendan no usar
diagramas, sino escribir texto
• Se recomienda que sean de caja negra: qué (análisis), pero
no cómo (diseño)
• Plantillas para casos de uso en http://www.usecases.org
 Casos de Uso
• Un caso de uso puede tener variantes, ser parte de otro o
extender algún otro
• Los casos de uso se realizan mediante diagramas de
colaboración* (UML 1)
• En BRJ99 son alternativamente referidos como estáticos
(p.203) y dinámicos (p.205)
• Fowler no recomienda el uso de diagramas, sino la forma
narrativa
• Se considera que la definición de casos de uso en UML es
más bien ambigua
 Casos de Uso
• Diagramas de casos de uso:
– Casos de uso
– Actores
– Relaciones de dependencia, generalización y asociación
• Actores:
– Se representan mediante monigotes
– Se pueden definir categorías generales (Cliente) y
especializarlas a través de relaciones de generalización
– Un Actor sólo se puede conectar a un caso de uso mediante
una asociación
 Diagramas de Clases
• Modelan la vista de diseño estática de un sistema
• La vista estática soporta los requisitos funcionales
• Son los más utilizados en el modelado de sistemas
orientados a objeto
– Fowler: “Psst… ¿Quiere ver un diagrama de UML?”
• Muestra un conjunto de clases, interfaces y
colaboraciones
• Son importantes para construir sistemas
ejecutables, aplicando ingeniería directa e inversa
 Diagramas de Clases
• Son un conjunto de nodos y arcos
• Contienen clases, interfaces, colaboraciones,
relaciones de dependencia, generalización y
asociación
• Pueden contener también paquetes o subsistemas
para agrupar otros elementos del modelo
• El mayor peligro de los diagramas de clases es que
uno se puede concentrar en la estructura y olvidar
la conducta – Alternar clases de diagramas
• Recomendación 2 (Fowler): No diagramar todo,
sino aspectos importantes
 Diagramas de Objetos
• Modelan las instancias de los elementos contenidos
en los diagramas de clases
• Muestran un conjunto de objetos y sus relaciones en
un momento concreto (vista estática, como una
instantánea)
• Consisten en los objetos que colaboran, pero sin
especificar los mensajes
• Contienen objetos y enlaces
• Pueden contener paquetes o subsistemas
 Diagramas de Objetos
• Se puede hacer ingeniería directa, pero en la práctica esto
tiene un valor limitado
• Las instancias son creadas en tiempo de ejecución
• Hacer ingeniería inversa es más razonable y se hace
continuamente p. ej. para localizar un enlace perdido, etc.
• Tener en cuenta:
– No es posible capturar todos los objetos potenciales de un sistema
o sus relaciones
– Se usan para capturar algún aspecto específico del sistema en un
momento dado
 Diagramas de Componentes
• Modelan aspectos físicos del sistema
• Ejecutables, bibliotecas, tablas, archivos, documentos
• Representan el empaquetamiento físico de elementos
lógicos tales como clases, interfaces y colaboraciones
• Definen abstracciones con interfaces bien definidas
• La notación canónica permite visualizar un componente
con independencia de sistema operativo o lenguaje de
programación
• Con los mecanismos de extensión (estereotipos) se puede
particularizar la notación
 Diagramas de Componentes
• Contienen componentes, interfaces y relaciones de
dependencia, asociación y realización
• También pueden contener paquetes, subsistemas e
instancias
• Es habitual hacer ingeniería directa e inversa
• Cada diagrama representa un aspecto; el conjunto
de todos representa una vista estática completa del
sistema
 Diagrama de Secuencia (DSS)
• Muestra eventos de entrada y salida relacionados con el
sistema
• UML incluye notación para representar los eventos que
parten de los actores externos hacia el sistema
• Un DSS es un dibujo que muestra, para un escenario* de
casos de uso, los eventos generados por los actores, el
orden y los eventos entre sistemas
• El orden de los eventos debe seguir el orden en el caso de
uso
 Diagrama de Secuencia (DSS)
• Larman, p. 118
 Diagrama de Secuencia (DSS)
• Forman parte del Modelo de los Casos de Uso
• No se mencionan en la especificación de UP
• Se suelen crear en la elaboración, no en la
incepción
• No es necesario crear DSS para todos los
escenarios de todos los casos de uso
• En UML 1, los elementos del DSS eran objetos;
ahora es más complicado y abstracto
 Diagramas de Secuencia
• Son buenos para comprender la conducta de varios
objetos en un solo caso de uso
• Sirven para mostrar colaboración entre objetos; no
lo son para modelar la conducta
• Si se quiere ver la conducta de un solo objeto a
través de varios casos de uso, usar un diagrama de
estados
• Muchos threads a través de muchos casos, un
diagrama de actividad
 Diagramas de Estados
• Statecharts: Muestran una máquina de estados
• Un diagrama de actividad es una clase especial de diagrama
de estados que muestra el flujo de control entre actividades
• Un diagrama de estados muestra el flujo de control entre
estados
• Especifica la secuencia de estados por la que pasa un objeto
en respuesta a eventos, junto con sus respuestas a esos
eventos
• Son útiles para modelar comportamiento regido por eventos
 Diagramas de Estados
• Usualmente se modela la vida de un objeto,
comenzando por su creación, sus estados estables y
su destrucción
• Una máquina de estados cuyas acciones están
asociadas a transiciones se llama máquina de Mealy
• Una máquina de estados cuyas acciones están
asociadas a estados se llama máquina de Moore
• En la práctica se suelen mezclar ambos tipos de
máquinas
 Diagramas de Estado
• La ingeniería directa es usual
• La ingeniería inversa es teóricamente
posible pero no es útil
– Las herramientas de ingeniería inversa no
tienen capacidad de abstracción y no pueden
producir diagramas de estado significativos
– Puede resultar más útil alguna herramienta de
animación
 Diagramas de Actividad
• Equivalente de un workflow, pero con soporte de
paralelismo
• Describen lóigica de procedimiento, lógica de
negocios y workflow
• Es uno de los que más cambió en UML 2
– En UML 1 eran casos especiales de diagramas de
estado; ya no más
– En UML 1 había reglas especiales para balancear forks
y joins; ya no es más preciso
 Diagramas de Comunicación
• Se llamaban Diagramas de Colaboración en UML
1.
• Enfatiza los vínculos de datos entre los
participantes de una interacción
• Utilizan numeración para mostrar la secuencia de
un mensaje
• Usualmente su usa numeración común, plana;
pero la legal (“Kosher”) debería ser decimal 1.1,
etc
• …
 Diagramas de Despliegue
• Modelan la vista de despliegue estática, equivalente a la
topología del sistema
– Para modelar hardware, se recomiendan lenguajes específicos,
como VHDL
• No sólo modelan el despliegue, sino que pueden
gestionarlo a través de ingeniería directa o inversa
• Contienen nodos y relaciones de dependencia y
asociación
• Pueden contener paquetes, subsistemas, componentes e
instancias
 Diagramas de Despliegue
• Se puede hacer alguna ingeniería directa,
mayormente para visualizar
• La ingeniería inversa es de mayor valor
 Vista de gestión: Paquetes
• Un paquete es una parte de un modelo
• Cada parte de un modelo debe pertenecer a un paquete
• Los paquetes contienen elementos en el más alto nivel
• Clases y relaciones, máquinas de estado, diagramas de
casos de uso, interacciones y colaboraciones
• Cualquier elemento que no esté contenido en otro paquete
• Si se ilgen bien los paquetes, representan la arquitectura de
alto nivel del sistema
 Mecanismos de Extensión
• Las herramientas pueden almacenar y manipular las
extensiones, pero sin entender su semántica
• Se espera que haya herramientas y módulos
adicionales que puedan entenderlas
• Los mecanismos usuales de extensión son:
– Restricciones
– Valores etiquetados
– Estereotipos
• Las extensiones generan “dialectos” de UML
 Extensiones: Restricción
• Es una condición semántica representada como
expresión textual
• Puede ser notación matemática formal, un lenguaje
como OCL, un lenguaje de programación o seudocódigo
• Aunque se represente en lenguaje formal, no es de
cumplimiento automático
• Habitualmente se expresan entre llaves
– cantidad: Dinero {valor múltiplo de 20}
– {Persona.Empleado = Persona.Jefe.Empleado}
 Extensiones: Valor etiquetado
• Los valores etiquetados se muestran como
cadenas con el nombre de la etiqueta, un
signo igual y un valor
• No se deben usar etiquetas reservadas
• Usualmente se ponen entre llaves
– {autor=Billy Reynoso,
creación=7/12/04,
estado=activado}
 Extensiones: Estereotipos
• Pueden utilizar símbolos pre-existentes o
iconos creados a ese efecto
• Usualmente se presentan como cadenas de
texto encomilladas
 Referencias
• Grady Booch, James Rumbaugh, Ivar
Jacobson - El Lenguaje Unificado de
Modelado. Madrid, Addison Wesley, 1999.
• Craig Larman - UML y Patrones. 2a ed.,
Madrid, Pearson/Prentice Hall, 2003.
 ¿Preguntas?

Billyr@microsoft.com.ar