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ónde casos de uso
Definicióndel modelodel dominio
Definiciónde diagramasde interacción
Definiciónde diagramas declases 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.