Visión general de UML (Unified Modeling Language)

1. Visión general de UML Javier Garzás jgarzas@altransdb.com jgarzas@acm.org

2. La esencia • “Si no se puede explicar lo que se hace, el trabajo carece de valor” • Erwin Schrödinger

3. ¿Qué es UML? • UML o el Unified Modeling Language • Sucesor de las notaciones de finales de los ‘80 principios de los ‘90. • Estándar OMG • LENGUAJE de propósito general, ni método, ni metodología, el método incluye al lenguaje y al proceso: • Lenguaje de Modelado Notación (generalmente gráfica) que utiliza el método para expresarse • Proceso recomendación sobre que pasos tomar para diseñar • Método Lenguaje de Modelado + Proceso

4. Situación de Partida • Cada metodólogo que se preciase necesitaba sacar su propia metodología y, por ende, su propia notación. • Tenemos notaciones distintas de: • Booch, Jacobson, Coleman, Rumbaught, Meyer, Coad, Henderson-Sellers, más y más etcs. • Esto produce problemas para: integrar, crear y usar CASEs, aprender, aplicar, construir, etc.

5. A finales de los 90 Se toma conciencia de que existe la necesidad de una notación estándar para el modelado

6. Historia de UML • Unified Method (Booch y Rumbaugh). Se presentó en el OOPSLA’95. • Unión (¿compra?) de Jacobson. • Los “Tres Amigos” son socios en la compañía Rational Software. • UML unifica los métodos de sus autores principalmente

7. Historia de UML

8. Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson) Digital Equipment Hewlett-Packard i-Logix (David Harel) IBM ICON Computing (Desmond D’Souza) Intellicorp and James Martin & co. (James Odell) MCI Systemhouse Microsoft ObjecTime Oracle Platinium Technology Sterling Software Taskon Texas Instruments Unisys Partners en UML 1.0

9. UML, síntesis de los anteriores Rumbaugh Booch Jacobson Odell Meyer Pre- and Post-conditions UML Shlaer-Mellor Object life cycles Harel State Charts Gamma et. al. Frameworks, patterns, notes Embly Wirfs-Brock Singleton classes Responsabilities y estereotipos Fusion Operation descriptions, message numbering

10. Algunas características novedosas • Incluye “stereotypes” como mecanismo de extensibilidad. • Aporta un lenguaje para expresar restricciones mediante fórmulas bien formadas: • OCL (Object Constraint Language) desarrollado por IBM • Puede describir cualquier tipo de sistema en términos de diagramas orientados a objetos: • Sistemas de Información, de Tiempo Real, Embebidos, Distribuidos, Sistemas, Web, etc.

11. Define una Notación y un Meta-Modelo • La notación es el material gráfico que se observa en los modelos, la sintaxis del lenguaje. • El meta-modelo es un diagrama, usualmente de clases, que define una notación. Es necesario para dar rigor a la notación, en UML… semi-formal

12. Aspectos peyorativos • La integración con respecto de otras técnicas (patrones de diseño, interfaces de usuario, documentación, etc.) • ¿Cercano al usuario? ¿fácil de usar sin un CASE que comprar a algún partner? ¿fácil de aprender? • “Monopolio de conceptos, técnicas y métodos en torno a UML” • Muy orientado a ser guiado por casos de uso

13. Aspectos peyorativos "... Mi larga búsqueda no ha sido en vano. Ella me ha conducido a una apreciación completa de UML, esta admirable máquina auto-alimentada, dedicada desde la A a la Z a la creación de un nuevo mercado; libre de las dificultades asociadas con el molesto negocio el desarrollo de software: ¡Libros de UML! ¡Cursos de UML! ¡Cursos sobre los libros! ¡Libros sobre los cursos! ¡Libros sobre los libros! ¡Cursos Introductorios para preparar para los cursos avanzados! ¡Cursos para aquellos que enseñan los cursos! ¡Revisiones! ¡Revistas de UML! ¡Conferencias! ¡Workshops! ¡Tutoriales! ¡Estándares! ¡Comités! ¡Camisetas! ...". Bertrand Meyer, 1997

14. Perspectivas de UML • UML es y será el lenguaje de modelado OO estándar durante los próximos años. • Los móviles: • Las figuras influyentes involucradas. • Importantes partners • Aceptación del OMG como notación estándar (que es lo mismo que dice el punto anterior) • Las pruebas: • Herramientas CASE-UML, Publicaciones, Congresos, Cursos, Vosotros, Yo, etc.

15. Diagramas en UML

16. 9 Diagramas en UML Diagrama de Casos de Uso Diagrama de Clase Diagramas de Objetos Diagramas de Comportamiento Diagrama de Estados Diagrama de Actividad Diagramas de Interacción Diagrama de Secuencia Diagrama de Colaboración Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue

17. Modelo de vistas 4+1 Descripción del modelo desde 5 vistas Vista de Diseño Vista de Implementación Vista de Casos de Uso Vista de Procesos Vista de Despliegue

18. Paquetes • Mecanismo general para dividir modelos y agrupar elementos • Representación:

19. Paquetes • Subconjuntos del modelo: • Pueden contener: clases, objetos, relaciones,componentes y diagramas asociados • Definen la arquitectura del sistema • Los estereotipos aplicables: • <<Categoría>> y <<Subsistema>> permiten distinguir los paquetes de la vista lógica y los de realización, respectivamente

20. Paquetes • Un puede contener a otros, sin límite de anidamiento • Un nivel dado puede contener paquetes y además otros elementos de modelado (por ejemplo Diagramas de Clases y de Interacción) • Cada elemento pertenece a un sólo paquete • Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes

21. Paquetes • Las importaciones entre paquetes se representan por medio de una relación de dependencia, orientada del cliente al proveedor • Esto implica que al menos una clase del paquete cliente usa los servicios ofrecidos por al menos una clase del paquete proveedor. • Una clase depende de otra si accede a un valor del proveedor, invoca a una operación o referencia al proveedor como argumento en alguna operación

22. Paquetes • Todas las clases no son necesariamente visibles desde el exterior del paquete • El operador “::” permite designar una clase definida en un contexto distinto del actual • Por ejemplo, la expresión Ventas::Producto designa la clase Producto definida en el paquete Ventas • Un paquete encapsula a la vez que agrupa

23. Paquetes • Los paquetes también poseen una interfaz y una implementación • Cada elemento de un paquete se incluye como visible o no desde el exterior del paquete • Sólo las clases públicas aparecen en la interfaz del paquete • No debe haber relaciones cíclicas entre paquetes

24. Ejemplo:

25. Casos de Uso • Captura información de cómo un sistema o negocio trabaja. • No pertenece realmente al enfoque orientado a objetos.

26. Diagramas de Casos de Uso • Cada Caso de Uso puede estar definido por: • texto que lo describe • secuencia de pasos ejecutados dentro del escenario • condiciones pre-post para que el escenario comience o termine • mezclando las anteriores • Representados por una elipse • Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo

27. Ejemplos

28. Diagramas de Interacción • Diagramas de Secuencia y de Colaboración: usados para realizar un escenario del sistema, determinando los objetos y mensajes involucrados • Un Diagrama de Secuencia muestra los objetos de un escenario mediante líneas verticales y los mensajes entre objetos como flechas conectando objetos • El Diagrama de Colaboración muestra como los objetos están conectados y los mensajes enviados acompañados de una flecha que indica su dirección

29. Ejemplo

30. Diagramas e Clases • Principal Diagrama en cualquier método de Análisis o Diseño Orientado a Objetos • Muestra las relaciones estructurales y estáticas entre las clases • Se irán refinando durante todo el proceso de desarrollo, para detallarlos se usan muchos de los otros diagramas

31. Ejemplo

32. Diagramas de Estados • Modela comportamiento, aspectos dinámicos • Se elabora un diagrama de Estados para cada clase que tenga un comportamiento dinámico importante

33. Ejemplo

34. Diagramas de actividad • Caso especial de Diagrama de Estados donde: • Todos (o la mayoría de) los estados son estados de acción • Todas (la mayoría de) las transiciones son “disparadas” como consecuencia de la finalización de la la acción. • El Diagrama puede estar asociado a: • Una clase • La implementación de una operación • Un Caso de uso

35. Ejemplos (Fowler, 1997) [no zumo] [no hay café] Buscar Bebida [hay zumo] [hay café Poner café en filtro Añadir agua al depósito Coger taza Coger zumo Poner filtro en máquina Encender máquina ^cafetera.On Café en preparación indicador de fin Servir café Beber

36. Diagramas de Componentes • Permite modelar la estructura física del software • Un componente representa un modulo de código físico. Pueden corresponder con código fuente, binario o ejecutable • Una relación de dependencia indica que un componente utiliza otro, por lo cual depende de él. Existe visibilidad entre componentes • Por lo general, un componente equivale a un paquete

37. Ejemplo

38. Diagramas de Despliege • El Diagrama de Despliege modela la distribución en tiempo de ejecución de los elementos de procesamiento y componentes de software, junto a los procesos y objetos asociados • En el Diagrama de Distribución se modelan los nodos y la comunicación entre ellos • Cada nodo puede contener instancias de componentes

39. Ejemplo

40. Relación entre Diagramas C Ó D I G O Diagramas de Distribución Diagrama de Clases y Objetos Casos de Uso Diagramas de Secuencia Diagramas de Componentes Diagramas de Colaboración Diagramas de Estados Diagramas de Actividad