Introducción a uml



Descargar 132 Kb.
Fecha de conversión12.01.2017
Tamaño132 Kb.

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 de casos de uso
  • Definición del modelo del dominio
  • Definición de diagramas de interacción
  • Definición de diagramas de 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



Compartir con tus amigos:


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal