AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi.

AUS. Gustavo Torossi 1

Introducción a UML

AUS. Gustavo Torossi


Mitos sobre UML

Aprender UML es aprender el paradigma de objetos.

UML es una metodología de desarrollo. UML es solo para modelos de objetos.


Entonces ¿qué es UML?

UML es un lenguaje “unificado” de modelado para: Visualizar Especificar Construir Documentar

los artefactos de un sistema de software.

Representar y Comunicar Ideas

Modelos precisos, no ambiguos, completos

Trasladar en forma directa a un leng. prog.

Los artefactos construidos durante un proyecto


¿Qué significa lenguaje “unificado”? Lenguaje = sintaxis + semántica Unificado a través de:

Métodos y notaciones históricas Etapas del ciclo de desarrollo (requerimientos a

implementación) Dominios de aplicación Lenguajes y plataformas de implementación Procesos de desarrollo


Evolución histórica

Nov ‘97 UML promulgado por la OMG


Influencias


Participantes en UML 1.0

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 Corp. Platinium Technology Sterling Software Taskon Texas Instruments Unisys


Modelos

E = M * C2


¿Qué es un modelo?

Una representación en algún medio que captura los aspectos importantes del sistema modelado desde un determinado punto de vista.

Un modelo de un sistema software es realizado en un lenguaje de modelado.


Propósito de los modelos

Capturar y precisar requerimientos de un dominio de conocimiento, que sea comprensible por todos los stakeholders del proyecto.

Pensar sobre un diseño de un sistema.

Capturar decisiones de diseño de un sistema.

Explorar posibles soluciones a un problema económicamente.

Generar productos de trabajo útiles.

Documentar.


UML - Conceptos


UML - Vistas

Una vista es un subconjunto de construcciones de modelado que se enfocan en un aspecto particular del sistema.

Las vistas pueden dividirse en tres áreas: Estructural Comportamiento dinámico Gestión del modelo


Vistas – Clasificación estructural

Describe los elementos del sistema (clasificadores) y sus relaciones.

Clasificadores más comunes: Clases Casos de Uso Componentes Nodos

Vistas: Vista Estática – Diagrama de clases Vista de Casos de uso – Diagrama de casos de uso Vista de Implementación – Diagrama de Componentes /

despliegue


Vistas – Comportamiento dinámico

Describe el comportamiento del sistema a través del tiempo. Vista de Interacción: modela como interactúan los objetos

para realizar una funcionalidad del sistema Diagrama de Colaboración Diagrama de Secuencia

Vista de Máquina de estados: modela el ciclo de vida de una instancia de una clase en estados y transiciones. Diagrama de Estados

Vista de Actividades: modela flujos de trabajo (workflows) Diagrama de Actividades


Vistas – Gestión del modelo

Describe la organización de los modelos en unidades jerárquicas.

Permite manejar la complejidad.

Permite organizar el sistema en paquetes, subsistemas, y modelos.


Relación Áreas - Vistas


Mecanismos de extensión de UML

Permiten adaptar los elementos de modelado asignándole una semántica particular. Estereotipos Valores etiquetados Restricciones (OCL)

Overflow<<exception>>

EventQueue {version=3.2}

add()remove()

{ordered}


La Vista Estática


La Vista Estática

Propósito: Captura la estructura de los objetos. Es la base sobre la que se construyen las otras

vistas. Es un modelo incremental.

Diagrama de Clases


Clasificación Clasificador: es un concepto discreto en el modelo que tiene identidad,

estado, comportamiento, y relaciones.

Tipos de Clasificadores Elementos del Sistema:

Clase Interfaz Tipos de datos

Conceptos de Comportamiento: Caso de Uso

Cosas del entorno: Actor

Estructuras de implementación: Componente Nodo Subsistema


Clases & Objetos Objeto = estructura + operaciones + estado interno +

identidad.

Un objeto es una instancia de una clase.

Clase: Conjunto de objetos con estructura, comportamiento, relaciones, y semántica común.

Ejemplos algo físico → Avión algo del negocio → Pedido un concepto lógico → Horario algo de la aplicación → Window, Botón, Menú algo del comportamiento → Tarea, Proceso


Clases: Notación Gráfica

Cada clase se representa en un rectángulo con tres compartimientos:

nombre de la claseatributos de la claseoperaciones de la clase


Clases: Niveles de visibilidad

Determina el nivel de encapsulamiento de los elementos de una clase.

(-) Privado : Los atributos/operaciones son visibles solo desde la propia clase.

(#) Los atributos/operaciones protegidos están visibles para la propia clase y para las clases derivadas de la original

(+) Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación)


Clases: Niveles de visibilidad

Ejemplo

Reglas de visibilidad

+ Atributo público : int# Atributo protegido : int- Atributo privado : int

+ "Operación pública"# "Operación protegida"- "Operación privada"


Clases: Estereotipos

Objetos Entidad

Objetos Interfaz

Objetos de Control

Empleado

UIEmplead

Control


Clases y Objetos

Diagrama de Clases y Diagramas de Objetos pertenecen a dos vistas complementarias del modelo.

Un Diagrama de Clases muestra la abstracción de una parte del dominio.

Un Diagrama de Objetos representa una situación concreta del dominio.


Diagrama de Objetos

Banco Cliente

*1

Cuenta

*11 * 1 *

unBanco : Banco

cliente01 : Cliente

cliente02 : Cliente

cta0101 : Cuenta

cta0201 : Cuenta

cta0202 : Cuenta

Diagrama de Clase

Diagrama de Objetos


Interfaces Describen un protocolo de comportamiento sin

especificar su implementación. Contienen operaciones pero no atributos. Una interfaz puede ser implementada por varias clases.

Comparable

compareTo()

<<Interface>>

String

compareTo()

Date

compareTo()

File

compareTo()

<<implement>><<implement>>

<<implement>>

compareTo { ... } compareTo { ... } compareTo { ... }

String

compareTo()Comparable


Relaciones

Las relaciones entre clasificadores son: Asociación (conocimiento) Agregación / Composición Generalización Dependencias


Asociación

Asociación: Conexión semántica entre instancias de clases. proporciona una “conexión” entre los objetos para el

envio de mensajes.

Enlace: Instancia de una asociación. Lista ordenada de referencias a objetos.


Asociación: representación gráfica

Persona Compañíatrabaja-para

nombres. s.

nombredirección

jefe

Administraempleado

* *

emplea-a

0.. 1

0.. 1

0.. 1

*

marido

casado-con

mujer


Asociación: multiplicidad

Especificación de multiplicidad (mínima...máxima)

1 Uno y sólo uno

0..1 Cero o uno

M..N Desde M hasta N (enteros naturales)

* Cero o muchos

0..* Cero o muchos

1..* Uno o muchos (al menos uno)

La multiplicidad mínima >= 1 establece una restricción de existencia


Asociación: casos especiales

Asociación como clase

Asociación calificada

Asociación ordenada

Restricción

Teatro Obra

-Fecha-Hora

Presentacion

* *

Presentacion EntradaNum_Butaca

1 1..*

Presentacion Diapositiva

1{ordered}

1..*

Cuenta

Persona

1

*

orEmpresa

*

*


Agregación y composición

Representa una relación todo-partes entre objetos. Son una variación de la asociación con mayor fuerza semántica. Una composición es una forma de asociación más fuerte en la cual

el compuesto es responsable de gestionar sus partes, por ejemplo asignación y desasignación. La composición implica tres cosas Dependencia existencial. El elemento dependiente desaparece al

destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.

Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene

Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto.


Representación gráfica

Agregación

Composición

Coleccion Obra

* *

Computadora

ALU RAM Disk

1*

11

11


Generalización

Relación taxonómica entre una descripción general y otra más específica que la extiende.

Relación “es un tipo de”.

Herencia: mecanismo a través del cual los atributos, operaciones, y restricciones definidas para una clase, denominada superclase, pueden ser heredados (reutilizados) por otras clase denominadas subclases.


Representación Gráfica

Cuenta

CajaDeAhorro CuentaCte

Vehículo

Veihículo Terrestre Vehículo Aéreo

Coche Camión Avión Helicóptero


Herencia Múltiple

Animal

Bípedo Cuadrúpedo

Con Pelos

Con Plumas

Con Escamas

Herbívoro

Carnívoro

cubertura

cobertura

cobertura

comida

nro patas nro patas

comida

Conejo


Dependencias

Indica una relación semántica entre dos o más elementos del modelo en la cual un cambio al elemento proveedor puede requerir un cambio o indicar un cambio en el significado del elemento cliente en la dependencia.


Dependencias

De traza

De refinamiento

De uso

De importación

…

Modelo delAnalisis

Modelo deDiseño

Cliente (analisis)

Cliente (diseño)


Diagrama de clases: ejemplo


La Vista de Casos de Uso


La Vista de Casos de Uso

Capturan los requerimientos funcionales del sistema Describen la forma de usar el sistema tal como se la ve

desde el exterior. Visión de “caja negra” del sistema. No es un modelo orientado a objetos. Particiona la funcionalidad del sistema en unidades

discretas: los casos de uso. Concepto introducido por I.Jacobson en OOSE. Diagramas de Casos de Uso: Actores + Caso de uso


Actor

Representa algo que interactúa con el sistema. Puede ser humano u otro sistema. Reside fuera del sistema. Describe el entorno. Describe un “rol” que asume un usuario. La misma persona física puede asumir distintos roles. Ejemplos:

Cliente del Banco Cajero Sistema Link

Cliente del Banco


Caso de Uso Secuencia de transacciones realizadas por el sistema que brinda un

resultado de valor a un actor. Describe una “forma” de utilizar el sistema. Funciones:

Capturan requerimientos funcionales del sistema. Estructuran los modelos de objetos en vistas manejables.

Un caso de uso puede tener varios caminos de acción o “escenarios”. Los casos de uso sirven como hilo conductor del proceso de

desarrollo.


Diagrama de Caso de Uso

AdministraciónOperador

(f rom Actors)

Extracción

(from Extraccion)

TransferenciaCliente

(f rom Actors)

Depósito

Sistema Central(f rom Actors)

Cajero Automático


Descripción textualCU Extracción – Camino Estandard

1 Un mensaje de bienvenida está en espera en la pantalla del CA.

2 El cliente inserta su tarjeta en el CA.

3 El CA lee el codigo de la banda magnética y verifica que sea aceptable.

4 Si la tarjeta es aceptable, el CA solicita al cliente su código PIN.

5 El cliente ingresa su código PIN.

6 Si el código PIN es correcto, el CA solicita al cliente el tipo de transacción a realizar.

7 El cliente selecciona <extracción> y el CA envía el código PIN al Sistema bancario solicitando los datos de la cuenta del cliente.

8 Los datos de la cuenta recibidos se despliegan en la pantalla.

9 El cliente selecciona una cuenta y el monto a extraer.

10 El CA envia al sistema bancario el requerimiento de extracción.

11 El CA preparan los billetes a ser dispensados.

12 El CA imprime el comprobante del movimiento.

13 Los billetes son dispensados al cliente.


Descripción textual

RF- <id del requisito> <nombre del requisito funcional> Versión <numero de versión y fecha> Autores <autor> Fuentes <fuente de la versión actual> Objetivos asociados <nombre del objetivo> Descripción El sistema deberá comportarse tal como se describe en

el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}

Precondición <precondición del caso de uso> Paso Acción

1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x>

2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>

3 4 5 6

Secuencia Normal

n Postcondición <postcondición del caso de uso>

Paso Acción 1 Si <condición de excepción>,{el <actor> , el

sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}

2

Excepciones

3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales>


Caso de Uso: Relaciones

Inclusión: Secuencias comunes a varios casos de uso.

Procesar Tarjeta

Extracción Transferencia Depósito

<<include>>

<<include>>

<<include>>



Extensión: Partes opcionales de un caso de uso.

Extracción

EstadísticaExtracción

MonitoreoExtracción

<<extend>> <<extend>>



Generalización: Distintas variantes de un caso de uso. (“es un tipo de”)

Extracción

Extracción Pesos Extracción Dólares



Ejemplo

«» «»

Hacer Pedido

<<extend>>

«» «»

SilicitarCatálogo

«» «»

Suministro dedatos declientes

<<include>>«» «»

Pedir Producto

<<include>>

«» «»

Pagar

<<include>>

«» «»

Pagar alcontado

«» «»

AcordarCrédito


La Vista de Interacción


La Vista de Interacción Representa como interactúan cooperativamente los objetos para

implementar el comportamiento definido por los casos de uso.

Colaboración: Interacción entre un conjunto de objetos para implementar un

comportamiento del sistema. Una colaboración <<realiza>> la funcionalidad definida en un casos de

uso.

Interacción: Una interacción es un conjunto de mensajes que se intercambian

dentro del contexto de una colaboración por instancias de clases (objetos) a través de enlaces (instancias de asociación).


Diagramas de Secuencia Énfasis en la secuencia cronológica de los mensajes.

: Encargado:WInPréstamos :Socio :Video :Préstamo

prestar(video, socio)

verificar situación socio

verificar situación video

registrar préstamo

entregar recibo


Diagrama de Colaboración Énfasis en la distribución física y relaciones de los objetos.

: Encargado

:WInPréstamos

:Socio

:Video

:Préstamo

1: prestar(video, socio)

2: verificar situación socio

3: verificar situación video

4: registrar préstamo5: entregar recibo


La Vista de Máquina de Estados


La Vista de Máquina de Estados

Describe el comportamiento dinámico de los objetos, modelando su ciclo de vida.

Autómatas finitos con estados y transiciones. Cada objeto se trata en forma aislada, el que se

comunica con el resto del mundo detectando eventos y respondiendo a ellos.

Es útil modelar solo para objetos con comportamiento estado-dependiente.

Uso de Diagramas de Estado.


Diagramas de Estado Cada objeto está en un estado en cierto instante. El estado describe un período de tiempo caracterizado

por: Conjunto de valores de atributos y relaciones del objeto. Período de tiempo durante el que se espera que ocurra un evento Período de tiempo durante el cual el objeto realiza una actividad

El estado en el que se encuentra un objeto determina su comportamiento.

Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase.

La transición entre estados es instantánea y se debe a la ocurrencia de un evento.


Diagramas de Estado Estados y Transiciones

A B

Evento [condición] / Acción

El evento se considera instantáneo


Diagramas de Estado Ejemplo: Pila

PilaVacía

Pila no vacíani llena

Pilallena

evento (cond)acción

push

borrar pila

crear pila poperror

pop (size > 1)

push (size+1 <> full)

borrar pila

borrar pila

push (size+1 = full)

pusherror

pop

pop (size = 1)


Eventos Acontecimiento significativo que tiene localización en tiempo y espacio. No tiene duración. Instantáneo Tipo de eventos

Señal: comunicación asíncrona entre objetos. Llamada: invocación sincrónica de método del objeto que recibe el evento. Cambio: satisfacción de una condición lógica que depende de valores de un atributo. Tiempo: instante absoluto, o lapso transcurrido.

Pueden modelarse con clases y jerarquías


Acciones Una acción es un cómputo atómico y breve

una sentencia de asignación una operación aritmética el envío de una señal a otro objeto la invocación de una operación propia asignación de valores de retorno creación o destrucción de objetos una secuencia de acciones simples

Acciones específicas de entrada, salida, durante, un estado o por un evento

estado A

entry: acción por entrarexit: acción por salirdo: acción mientras en estadoon evento: acción


Estados compuestos


La Vista de Actividades


La Vista de Actividades

Variante de la máquina de estados para modelar flujos de trabajo.

Utilización de diagramas de actividad. Caso particular de los diagramas de estado.

Los estados representan estados de actividad no de un objeto.


Diagrama de Actividades


Calles y flujo de objetos


Vistas Físicas


Vista de Implementación Modela el empaquetado físico del sistema en unidades

reutilizables llamadas “componentes”. Un componente es una unidad física de implementación

con interfaces definidas pensada para ser utilizada como parte reemplazable del sistema.

Cada componente implementa una o más clases del diseño.

Incluyen código fuente, binario, o ejecutable. Los componentes se vinculan por relaciones de

dependencia.


Diagrama de Componentes


Vista de Despliegue Modela la disposición física de los recursos de ejecución

computacional (computadores, unidades de com., etc.) Nodo: es un objeto físico de ejecución que representa

un recurso computacional. Pueden tener estereotipos (UCP, memorias, disk, etc.)

Las asociaciones entre nodos representan líneas de comunicación.

Se representan por diagramas de despliegue.


Diagrama de Despliegue


Diagrama de Despliegue

Cliente

APPServer

DB Server

* *

* *

* Web Browser

* Servlets* JSP* JDBC


La Vista de Gestión



La Vista de Gestión del modelo está compuesta por paquetes y relaciones de dependencia entre paquetes.

Paquete: es una unidad de organización del modelo. Los paquetes ofrecen un mecanismo general para la

organización de los modelos / subsistemas agrupando elementos de modelado.

Los paquetes contienen elementos del modelo como clases, diagramas de casos de uso, interacciones, etc.

Todos los elementos del modelo deben pertenecer a un paquete.

Los paquetes tambien pueden contener otros paquetes.



Los paquetes pueden organizarse según el criterio del diseñador: Por la vista (estática, casos de uso, etc.) Por subsistema Por etapa del ciclo de desarrollo.

Una buena organización refleja la arquitectura de alto nivel del sistema.


4 + 1 vistas de Kruchten

Vista Lógica

Vista de Procesos

Vista de Distribución

Vista de Realización

Vista de los Casos de Uso


Dependencias de acceso / importación

Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa

El operador “::” permite designar una clase definida en un contexto distinto del actual


Dependencias de acceso / importación

La dependencia de acceso no modifica el espacio de nombres del cliente. Solo concede permiso para establecer referencias.

La dependencia de importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinónimos de los caminos completos.


Modelo y Subsistema

Un modelo es un paquete que abarca una descripción completa de una vista particular de un sistema. Proporciona una descripción cerrada de un sistema a partir de un punto de vista.

Un subsistema es un paquete que tiene piezas separadas de especificación y de realización. Representa una partición del sistema.


Proceso de Desarrollo


Proceso de Desarrollo UML no prescribe ningún proceso de desarrollo.

Sin embargo se recomienda un proceso:

Dirigido por Casos de Uso

Centrado en la Arquitectura

Iterativo e Incremental

Ejemplo: Proceso Unificado (RUP)


Ciclo de Vida


Herramientas CASE


Herramientas CASE UML no es un leguaje de programación visual, pero sus

modelos pueden conectarse directamente con una variedad de lenguajes.

Forward & reverse engineering.

Ingeniería de ida y vuelta.


Herramientas CASE Rational Rose (www.rational.com)

Rational XDE (www.rational.com)

Borland Together (www.borland.com/together/)

Embarcadero Describe (www.embarcadero.com/)


Herramientas CASE - Libres Argo UML (argouml.tigris.org) Poseidon (www.gentleware.com) Dome (www.htc.honeywell.com/dome )

Comparativa: http://www.diatel.upm.es/malvarez/UML/Comparativa.html


Bibliografía

Título Autor ISBN

El Lenguaje Unificado de Modelado

Manual de Referencia

James Rumbaugh 8478290370

El Lenguaje Unificado de Modelado

Guía del Usuario

Grady Booch 8478290281

UML Gota a gota Martin Fowler 9684443641

UML y Patrones Craig Larman 8420534382


Recursos en la Web UML Resource Center (www.rational.com/uml/index.jsp)

The Rational Edge (www.therationaledge.com/)


¿ preguntas ?

[email protected]

AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi.

Documents

Transcript of AUS. Gustavo Torossi 1 Introducción a UML AUS. Gustavo Torossi.