Introducción a UML

1. Notas Todo lode uml Introducción a UML

2. Agenda • Contexto • Arquitectura de Software • Métodos ágiles (XP y otros) • Modelado orientado a objetos • Elementos • Diagramas • Limitaciones • Conclusiones

3. 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

4. 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

5. 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

6. 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

7. UML 2 – Diagramas

8. 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

9. 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

10. 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...)

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Diagrama de Secuencia (DSS) • Larman, p. 118

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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 • …

30. 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

31. Diagramas de Despliegue • Se puede hacer alguna ingeniería directa, mayormente para visualizar • La ingeniería inversa es de mayor valor

32. 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

33. 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

34. 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}

35. 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}

36. Extensiones: Estereotipos • Pueden utilizar símbolos pre-existentes o iconos creados a ese efecto • Usualmente se presentan como cadenas de texto encomilladas

37. 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.

38. ¿Preguntas?