Introduccin 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 Mtodos 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 Estndar de OMG (Object Management Group) desde 1997 [ http://www-omg.org ] Versin 2.0: notacin simplificada

UML Significacin
Definicin: Es una familia de notaciones grficas, til para disear sistemas de software, particularmente sistemas que habrn de desarrollarse en trminos de OO. Desde su establecimiento ca. 1997, ha desplazado a una multitud de lenguajes grficos de modelado OO (lo cual es de agradecer) Mellor y Fowler: principales usos
Sketch (selectivo) * Blueprint (completo) Igual a CASE, en desgracia Lenguaje de programacin MDA, Executable UML. No realista en opinin de Fowler.

Fowler: No existe ningn estndar que especifique cmo mapea UML sobre un lenguaje de programacin 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), mquinas de estado

1 elemento de agrupacin: paquetes 1 elemento de anotacin 4 Relaciones

Dependencia, asociacin, generalizacin, realizacin

9 Diagramas

UML - Diagramas
Estticos:
Diagramas de clases Diagramas de objetos Diagramas de componentes Diagramas de despliegue Diagramas de casos de uso Diagramas de secuencia Diagramas de colaboracin Diagramas de estados Diagramas de actividades

Dinmicos:

UML 2 Diagramas

RUP
Milestones - Por primera vez en Boehm, 1996:
Incepcin - Visin y alcance - Life Cycle Objective Milestone Elaboracin - Riesgos, arquitectura y planes Life Cycle Architecture Milestone Construccin - Diseo detallado - Operation Capability Milestone Transicin - Fine tuning Product Release Milestone

Fases de anlisis y diseo

Definicin de casos de uso Definicin del modelo del dominio Definicin de diagramas de interaccin Definicin de diagramas de clases diseo

Casos de uso: Anlisis de requerimientos Modelo de dominio: Conceptos, atributos y asociaciones Diagramas de interaccin: Flujo de mensajes (invocacin de mtodos) Diagramas de clases: Mtodos requeridos por los mensajes

Anlisis de requerimientos
En UP los requerimientos se clasifican conforme al modelo FURPS+ [Grady92]:
Funcional [Casos de uso] Usabilidad: Factor humano, documentacin Fiabilidad (Reliability) Performance Soporte: Mantenimiento, configurabilidad... +: Adicionales (packaging, legales...)

Anlisis 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 estn ligados a OOD u OOP Anderson, Fowler, Cockburn... recomiendan no usar diagramas, sino escribir texto Se recomienda que sean de caja negra: qu (anlisis), pero no cmo (diseo) 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 algn otro Los casos de uso se realizan mediante diagramas de colaboracin* (UML 1) En BRJ99 son alternativamente referidos como estticos (p.203) y dinmicos (p.205) Fowler no recomienda el uso de diagramas, sino la forma narrativa Se considera que la definicin de casos de uso en UML es ms bien ambigua

Casos de Uso
Diagramas de casos de uso:
Casos de uso Actores Relaciones de dependencia, generalizacin y asociacin

Actores:
Se representan mediante monigotes Se pueden definir categoras generales (Cliente) y especializarlas a travs de relaciones de generalizacin Un Actor slo se puede conectar a un caso de uso mediante una asociacin

Diagramas de Clases
Modelan la vista de diseo esttica de un sistema La vista esttica soporta los requisitos funcionales Son los ms 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 ingeniera directa e inversa

Diagramas de Clases
Son un conjunto de nodos y arcos Contienen clases, interfaces, colaboraciones, relaciones de dependencia, generalizacin y asociacin Pueden contener tambin 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 Recomendacin 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 esttica, como una instantnea) 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 ingeniera directa, pero en la prctica esto tiene un valor limitado Las instancias son creadas en tiempo de ejecucin Hacer ingeniera inversa es ms 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 algn aspecto especfico del sistema en un momento dado

Diagramas de Componentes
Modelan aspectos fsicos del sistema Ejecutables, bibliotecas, tablas, archivos, documentos Representan el empaquetamiento fsico de elementos lgicos tales como clases, interfaces y colaboraciones Definen abstracciones con interfaces bien definidas La notacin cannica permite visualizar un componente con independencia de sistema operativo o lenguaje de programacin Con los mecanismos de extensin (estereotipos) se puede particularizar la notacin

Diagramas de Componentes
Contienen componentes, interfaces y relaciones de dependencia, asociacin y realizacin Tambin pueden contener paquetes, subsistemas e instancias Es habitual hacer ingeniera directa e inversa Cada diagrama representa un aspecto; el conjunto de todos representa una vista esttica completa del sistema

Diagrama de Secuencia (DSS)

Muestra eventos de entrada y salida relacionados con el sistema UML incluye notacin 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 especificacin de UP Se suelen crear en la elaboracin, no en la incepcin 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 ms complicado y abstracto

Diagramas de Secuencia
Son buenos para comprender la conducta de varios objetos en un solo caso de uso Sirven para mostrar colaboracin entre objetos; no lo son para modelar la conducta Si se quiere ver la conducta de un solo objeto a travs de varios casos de uso, usar un diagrama de estados Muchos threads a travs de muchos casos, un diagrama de actividad

Diagramas de Estados
Statecharts: Muestran una mquina 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 creacin, sus estados estables y su destruccin Una mquina de estados cuyas acciones estn asociadas a transiciones se llama mquina de Mealy Una mquina de estados cuyas acciones estn asociadas a estados se llama mquina de Moore En la prctica se suelen mezclar ambos tipos de mquinas

Diagramas de Estado
La ingeniera directa es usual La ingeniera inversa es tericamente posible pero no es til
Las herramientas de ingeniera inversa no tienen capacidad de abstraccin y no pueden producir diagramas de estado significativos Puede resultar ms til alguna herramienta de animacin

Diagramas de Actividad
Equivalente de un workflow, pero con soporte de paralelismo Describen ligica de procedimiento, lgica de negocios y workflow Es uno de los que ms cambi en UML 2
En UML 1 eran casos especiales de diagramas de estado; ya no ms En UML 1 haba reglas especiales para balancear forks y joins; ya no es ms preciso

Diagramas de Comunicacin
Se llamaban Diagramas de Colaboracin en UML 1. Enfatiza los vnculos de datos entre los participantes de una interaccin Utilizan numeracin para mostrar la secuencia de un mensaje Usualmente su usa numeracin comn, plana; pero la legal (Kosher) debera ser decimal 1.1, etc

Diagramas de Despliegue
Modelan la vista de despliegue esttica, equivalente a la topologa del sistema
Para modelar hardware, se recomiendan lenguajes especficos, como VHDL

No slo modelan el despliegue, sino que pueden gestionarlo a travs de ingeniera directa o inversa Contienen nodos y relaciones de dependencia y asociacin Pueden contener paquetes, subsistemas, componentes e instancias

Diagramas de Despliegue
Se puede hacer alguna ingeniera directa, mayormente para visualizar La ingeniera inversa es de mayor valor

Vista de gestin: 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 ms alto nivel Clases y relaciones, mquinas 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 Extensin
Las herramientas pueden almacenar y manipular las extensiones, pero sin entender su semntica Se espera que haya herramientas y mdulos adicionales que puedan entenderlas Los mecanismos usuales de extensin son:
Restricciones Valores etiquetados Estereotipos

Las extensiones generan dialectos de UML

Extensiones: Restriccin
Es una condicin semntica representada como expresin textual Puede ser notacin matemtica formal, un lenguaje como OCL, un lenguaje de programacin o seudocdigo Aunque se represente en lenguaje formal, no es de cumplimiento automtico Habitualmente se expresan entre llaves
cantidad: Dinero {valor mltiplo 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, creacin=7/12/04, estado=activado}

Extensiones: Estereotipos
Pueden utilizar smbolos 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