1 / 38

Introducción a UML

Notas Todo lode uml. Introducción a UML. Agenda. Contexto Arquitectura de Software Métodos ágiles (XP y otros) Modelado orientado a objetos Elementos Diagramas Limitaciones Conclusiones. UML - Antecedentes.

joy
Download Presentation

Introducción a UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related