Introducci

1
Introducción a UML

• Carlos ReynosoUniversidad de Buenos Aires
• Billyreyno_at_hotmail.com
• http//www.microsoft.com/spanish/msdn/arquitectura
  /roadmap_arq/arquitectura_soft.mspx

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
• autorBilly Reynoso,creación7/12/04,estadoact
  ivado

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?

• Billyr_at_microsoft.com.ar