Unidad 2.2:

Unidad 2.2:

UML (Lenguaje de Modelamiento

Unificado)

Diagramas de UML

Use CaseDiagramsUse Case

DiagramsDiagramas de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribución

StateDiagramsState

DiagramsDiagramas de Objetos

ScenarioDiagramsScenario

DiagramsDiagramas deEstados

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

Diagramas deActividad

Modelo

“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

... Diagramas de UML

Diagrama de Casos de Uso Diagrama de Clase (incluyendo Diagrama de Objetos) Diagramas de Comportamiento

Diagrama de Estados Diagrama de Actividad Diagramas de Interacción

Diagrama de Secuencia Diagrama de Colaboración

Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue

… Casos de Uso

Existen dos elementos primordiales cuando se realiza la modelación de C.U. Diagramas de casos de uso: ilustra

gráficamente el sistema como una colección de casos, actores y sus relaciones.

Comunica a un alto nivel el alcance de los eventos de negocio que el sistema debe procesar.

El diagrama de casos de uso es muy sencillo, pero con éste comienza un importante proceso llamado descomposición funcional.

… Casos de Uso

Ejemplo:Sistema

Actor A

Caso de uso X

Actor B

Caso de uso Y

… Casos de Uso

Un C.U representa un objetivo individual del sistema y describe una secuencia de actividades y de interacciones del usuario para alcanzar el objetivo.Un C.U por sí solo no se considera como requerimiento funcional, pero la historia (el escenario) que relata el C.U consiste en uno o más requerimientos.Inicialmente los CU se definen durante la etapa de los requerimientos del ciclo de vida y se refinarán adicionalmente a lo largo de éste

… Casos de Uso: ActoresLos C.U se inician o son generados por los usuarios externos llamados Actores.Un actor inicia la actividad del sistema, un caso de uso, con el propósito de terminar alguna tarea de negocios que produzca algo con valor apreciable.Un actor representa un papel desempeñado por un usuario que interactúa con el sistema y no significa que retrate a una persona o puesto de trabajo. De hecho un actor no tiene porqué ser humano, puede ser una organización, otro sistema de información o un dispositivo externo tal como un sensor de calor.

… Casos de Uso: Actores

Existen principalmente 4 tipos de actores: Actor primario de negocios: El interesado

que se beneficia principalmente de la ejecución de un CU al recibir algo d valor medible u observable. Este actor puede o no iniciar un evento de negocios.

Ej: En el evento de negocio de un empleado que recibe el cheque como pago (algo con valor medible) del sistema de nómina cada viernes, el empleado no inicia el evento pero es el receptor primario de algo de valor.

… Casos de Uso: Actores

Actor primario del sistema: El involucrado que tiene una interfaz directa con el sistema para iniciar u ocasionar el evento de negocios o de sistema.Esto actores pueden interactuar con los actores primarios de negocios con el propósito de usar el sistema real. Ellos facilitan el evento a través del uso directo del sistema para beneficio del actor primario de negocios.Ej : Un dependiente de una tienda de abarrotes que selecciona los artículos para el cliente que compra abarrotes ó una operadora que proporciona información del directorio a un cliente.

… Casos de Uso : Actores

Actor externo servidor: El involucrado que responde a una solicitud desde el caso de uso.

Actor externo receptor: El involucrado que no es el actor primario pero que recibe algo de valor medible u observable (salida) proveniente del caso de uso.Ej: Un almacén recibe una orden de embalaje para preparar un flete después de que un cliente ha colocado una orden.

… Casos de Uso : Actores

En muchos sistemas de información hay eventos de negocios ocasionados por el calendario o la hora del reloj. Ej: El sistema de facturación de una compañía de

tarjetas de crédito genera automáticamente sus estados de cuenta en el quinto día de cada mes. (fecha de facturación).

Un banco concilia sus transacciones con cheques todos los días a las 5 pm.

Estos eventos son ejemplo de eventos temporales, ¿Quién sería el actor?, el actor de un evento temporal es el tiempo.

… Casos de Uso: Relaciones

Una relación: se ilustra como una línea entre dos símbolos en el diagrama de casos de uso. El significado de las relaciones puede diferir dependiendo de cómo se dibujen las líneas y que tipo de símbolos conectan


Asociaciones: Existe una relación entre un actor y un CU siempre que el caso describa una interacción entre éstos.

Se representa con una línea continua que conecta al actor y al CU.

Una Asociación que contiene una cabeza de flecha en el extremo que toca al CU, indica que el caso fue iniciado por el actor.

Las asociaciones sin cabeza de flecha indican una interacción entre el CU y el actor externo servidor o receptor.

Casos de Uso: Relaciones

UML define cuatro tipos de relación en los Diagramas de Casos de Uso:

Comunicación:

Caso de Uso

Actor

… Ejemplos

Cliente

Venta Normal

Venta en RebajasVendedor

Venta en Oferta

En el paquete tipos de venta:


Extensión: Un CU puede contener una funcionalidad compleja que consiste de varios pasos que hacen difícil entender la lógica del caso. Con objeto de facilitar el CU y hacer que se entienda más

fácilmente, podemos extraer los pasos más complejos para formar su propio caso.

El caso resultante de llama caso de extensión, ya que extiende la funcionalidad del VU original.

Un CU puede tener muchas relaciones de extensión, pero un CU de extensión puede ser invocado solamente por el CU que se está extendiendo

Se representa mediante una línea con cabeza de flecha (continua o segmentada) que comienza con el CU de extensión y que apunta al CU que se está extendiendo.


Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino

Caso de uso origen

Caso de uso destino

<<extend>>

… Ejemplos

Solicitar nueva tarjeta

Socio Encargado

Realizar préstamo

tarjeta caducada

<<extends>><<extend>>


Uses (o Inclusión): Comúnmente se puede descubrir dos o más CU que ejecuten pasos de funcionalidad idéntica. Lo mejor es extraer estos pasos comunes para formar un caso de uso separado que sea propio llamado, CU resumen. Un CU resumen representa una forma de “reuso” y es una

herramienta excelente para reducir la redundancia entre los CU.

Un CU resumen está disponible como referencia (o uso) para cualquier otro CU que requiera su funcionalidad.

Se representa mediante una línea con cabeza de flecha (continua o segmentada) que comienza en el CU Oficial y apunta al CU que se esté usando.


Inclusión : una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino

En UML 1.3 se estereotipa como <<include>> lo que antes llevaba el estereotipo <<uses>>

Caso de uso origen

Caso de uso destino

<<include>>

… Ejemplos

Validar operación

Reintegro cuenta corriente

Cliente

Reintegro cuenta crédito

<<uses>>

<<uses>><<include>>

<<include>>


Dependencia: Como administrador de proyecto o desarrollador líder, es de mucha ayuda saber cuáles CU tienen una dependencia sobre otros CU, con objeto de determinar la secuencia en que es necesario desarrollar los CU.Ej Bancario: Hacer un retiro no puede ejecutarse hasta que haya ocurrido el caso de uso Abrir una Cta Bancaria. Debido a esto el equipo de desarrollo probablemente escogerá desarrollar el CU Abrir una cuenta bancaria primero y en segundo lugar haga un depósito y en tercer lugar haga un retiro.


Un diagrama de CU que modele las dependencias de CU del sistema mediante el uso de relaciones de dependencia proporciona un modelo que es una herramienta excelente para propósitos de planeación y de programación.Esta relación se representa con una línea con cabeza de flecha que comienza en un CU y que apunta al CU del cual depende. <<depende de>>


Herencia: Cuando dos o más actores comparten un comportamiento común (En otras palabras, pueden iniciar el mismo caso de uso), lo mejor es extrapolar este comportamiento común y asignarlo a un nuevo actor resumen con objeto de reducir la comunicación redundante en el sistema.


Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía

Caso de uso origen

Caso de uso destino


Ejemplo:

Identificación

Giro por Internet

Cliente

Giro

<<extends>>

<<includes>>

<<extend>>

<<include>>

Transferencia por Internet

Transferencia

… Casos de Uso

El segundo elemento, narración del caso de uso, describe los detalles de cada evento.

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>

… Casos de Uso

Proceso de la modelación de casos de Usos para los requerimientos: Paso 1: Identificar a los actores del negocio Paso 2: Identificar los casos de uso para los

requerimientos de negocios. Paso 3: Construir el diagrama del modelo de

casos de uso Paso 4: Narraciones de los CU para los

requerimientos de documentos para los negocios

Caso de uso

Programar Procedimiento.

ActoresPropósito

TipoResumen

Referencia cruzadas

Sección Principal.Acción de los actores. Respuesta del sistema.

Flujo normal de eventos.

1. 2.3. 4.5..

6.7. 8.

9. 1011

Flujos alternativos.Línea 3:Línea 7:Línea 8:

Diagrama de Secuencia

Diagrama de Secuencia

Antes del diseño (cómo funcionará el software) se debe investigar y definir su comportamiento como “caja negra”El comportamiento del sistema es una descripción de lo que hace, …sin explicar la manera en que lo hace

Parte de esa descripción es un diagrama de secuencia del sistema

Los diagramas de secuencia

Es un artefacto creado de manera rápida y fácil que muestra los eventos de entrada y salida relacionados con el sistema que se está estudiando.UML incluye la notación de los diagramas de secuencia para representar los eventos que parten de los actores externos hacia el sistema.

Diagrama de secuencia

El comportamiento del sistema es una descripción de qué hace el sistema, sin explicar cómo lo hace.Def: Es un dibujo que muestra para un escenario específico de un caso de uso, los eventos que generan los actores externos, el orden y los eventos entre los sistemas. Todos los sistemas se tratan como cajas negras.Los diagramas destacan los eventos que cruzan los límites del sistema desde los actores a los sistemas.

Diagrama de secuencia

Asignación de nombres a los eventos: Para una mayor claridad deben

comenzar con un verbo en infinitivo.

Sesión 136

Relación caso de uso/DSS

Caso de uso (CU) describe cómo actores externos interactúan con el sistema a construirDurante la interacción, el actor genera eventos del sistema para un sistema, usualmente esto requiere que alguna

operación del sistema maneje el eventoDSS hace concretos y explícitos los eventos que son implícitos en el CUVeamos un DSS del curso normal de “Modificar Capital”

Sesión 137

RunningExample – DSS Modificar Capital

Curso normal de los eventos

Sesión 138

Eventos y operacionesEvento del sistema

hecho externo de entrada que un actor produce en un sistema.

Operación del sistema acción que el sistema ejecuta en respuesta a un evento del

sistema. ej., un contribuyente genera un evento “modificarCapital”, el cual

causa la ejecución de la operación “modificarCapital”.

El nombre del evento y de la operación pueden ser (y generalmente son) idénticos.

La diferencia es que el evento “X” es el estímulo y la operación “X” es la repuesta.

Lo mismo sucede con los mensajes y los métodos en Orientación a Objetos y UML.

Sesión 139

DSS

Diagrama que muestra los eventos generados por actores externos, … su orden …y los eventos inter-sistemas

…para un escenario particular de un CUTodos los sistemas son tratados como cajas negrasFoco en los eventos que cruzan la frontera entre actores y sistemas

Sesión 140

DSSLos casos de uso del sistema (escenarios y eventos) son input para su creaciónEl tiempo se describe (avanza) hacia abajoEl orden de los eventos debe seguir el mismo orden del escenario que representanLos eventos del sistema pueden incluir parámetrosUsa diagrama de secuencia de UMLSerán input para contratos de operación y diseño de objetos

Sesión 141

DSS de “Modificar Capital”

Actor externo Sistema como caja negra

Valor(es) de retorno asociado con el mensaje previo tiempo

Mensaje con parámetros

Sesión 142

Elaborando un DSS

Para elaborar un DSS para un escenario, y: Trace una línea que represente el sistema como una

caja negra Identifique los actores que operan directamente

sobre el sistema Trace una línea para cada uno de ellos.

A partir del escenario identifique los eventos (“externos”) del sistema que son generados por los actores Muéstrelos gráficamente en el diagrama.

A la izquierda del diagrama puede incluir o no el texto del caso de uso.

Sesión 1 43

Modificar CapitalCurso normal de los eventos

Acción del actor Respuesta del Sistema

1. El contribuyente solicita modificar capital

2. El sistema muestra capital inicial, enterado y por enterar actuales

3. El contribuyente ingresa:

nuevo capital inicial, nuevo capital enterado, nuevo capital por enterar y la fecha asociada

número de número de repertorio, nombre de notaria, fecha de escritura

4. El contribuyente confirma los cambios al capital

5. El sistema almacena cambios al capital

Sesión 144

Elaborando un DSSConsideramos ahora el caso de uso “Modificar Capital” a fin de identificar los eventos del sistema Primero debemos determinar los actores que

interactúan directamente con el sistema de software Usuarios

OJO! Sólo quien actúa directamente con el sistema Ej. En la venta de un producto: el cliente interactúa con el

cajero, pero no directamente con el sistema de ventas; => cajero es generador de eventos, cliente no

Ej. Contribuyente/Representante Electrónico Otros sistemas

Colaboraciones con sistemas externos (de pago, etc) Ej. No hay (aún :P)

Sesión 145

Elaborando un DSS

Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito …y no en el nivel del medio de entrada o de elementos de la interfaz

Ej. “modificarCapital” es preferible a “ApretarBotonAceptar” porque capta mejor el propósito de la operación

Mantiene un carácter abstracto y no se pronuncia sobre qué interfaz sirve para capturar el evento del sistema (decisiones de diseño)Es más claro si el nombre de un evento del sistema comienza con un verbo

ej. agregar, introducir, terminar, efectuar esto recalca que los eventos están orientados a comandos

Sesión 146

DSSGuideline: Haz un DSS para el escenario principal de cada

caso de uso, y para escenarios alternativos frecuentes o complejos

¿Por qué son importantes? Investigan y definen el comportamiento del

sistema como una caja negra Describen qué es lo que sistema hace, sin

explicar cómo lo hace Junto con CU y contratos de operación del

sistema

Sesión 147

RunningExample – DSS Modificar Capital

Curso normal de los eventos

Diagramas de Secuencia

: Socio : Encargado : Libro : Ficha libro : Ficha socio : Préstamo

Coger libro

Solicitar préstamo

Verificar situación socio

Situación socio ok

Verificar situación libro

Situación libro ok

Introducir préstamo

Autorizar préstamo

… Diagramas de Secuencia

CBA

m1

m2

m3

m4

m5

… Diagramas de Secuencia

EjemploQuien llama Línea telefónica Llamado

descuelga

tono

marcar

indicación de llamada timbre

descuelga

diga?

Las bandas rectangulares representan los periodos de actividad de los objetos

… Diagramas de Secuencia Un objeto puede enviarse a sí mismo

un mensaje:a

mensaje reflexivo

… Diagramas de Secuencia Normalmente no es necesario indicar

el retorno del control:

a b

El retorno se considera implícito cuando el envío es síncrono

… Diagrama de Secuencia

En el caso asíncrono el retorno, si existe, se debe representar:

a : aa b : aa

Tipos de Control El Diagrama de Secuencia refleja de

manera indirecta las opciones de control

Un control centralizado tiene una forma como esta:

… Tipos de control

Un control descentralizado tiene una forma como esta:

… Estructuras de control

Podemos representar iteraciones en el envío de mensajes, p.e., mientras se cumpla una condición:

While XLoop

end Loop


La iteración puede expresarse también como parte del mensaje:

*[condición] Mensaje


Las bifurcaciones condicionales pueden representarse de esta forma:

If condición

else

end if

Diagrama de Colaboración

Sesión 160

MensajeMensaje entre objetos que es representado por una expresión de mensaje y una pequeña flecha indicando la dirección del mensajeMuchos mensajes pueden navegar a través de cada linkUn nº de secuencia es agregado para mostrar el orden secuencial de los mensaje en el flujo de control actualPuede haber automensajes también this

Sesión 1 61

Creación de instanciasCualquier mensaje puede ser usado para crear instanciasLa convención es llamar a estos métodos create, o usar un estereotipo de tipo <<create>>Puede incluir argumentos

Sesión 162

LinkCamino de conexión entre dos objetos Indica que alguna forma de navegación o

visibilidad entre los objetos es posible Es una instancia de asociación

A lo largo de estos links pueden navegar los mensajesPuede haber múltiples mensajes en ambas direcciones en un mismo link (carretera de doble vía)

Sesión 163

Secuencia de mensajes numerados

Sesión 1 64

Mensajes condicionalesSiguiendo al número de secuencia se incluye una cláusula condicional en paréntesis cuadrados El mensaje es enviado sólo si la condición es cierta

Sesión 165

Caminos condicionales exclusivos

Expresiones de secuencia se modifican con una letra de camino condicional La primera letra usada es a por

convención

Sesión 1 66

Loops

Expresiones que describen un ciclo se identifican con un asterisco y una expresión condicional Mientras la expresión condicional sea

verdadera el ciclo continúa

Sesión 1 67

Iteración sobre una colección

Describen iteraciones sobre todos los miembros de una colección

Sesión 1 68

Mensajes a métodos estáticos

Para llamar a métodos static se usa el estereotipo <<metaclass>> para representar la clase que contiene tal método La clase Calendar es una instancia de metaclass

Sesión 1 69

Mensajes polimórficos

Mensajes a clases abstractas

www.dsic.upv.es/~uml

Reflexión sobre Diagramas de Interacción

Sesión 171

Problemas típicos

Problemas típicos de su uso:• En los proyectos de desarrollo, no se

aprecia el valor de llevar a cabo el diseño de objetos mediante estos diagramas

• Por lo anterior, se diseñan de manera vaga, e imprecisa

Sesión 172

DSS

UML no define nada que se llame diagrama de secuencia “del sistema”, sino que simplemente diagrama de secuenciaEl apellido señalado corresponde a un uso específico del diagrama de secuencia, en que precisamente el sistema es visto como caja negra.

Sesión 173

ComparaciónUno elige cuál quiere usarDiagrama de secuencia Ha habido más esfuerzo en su notación y

semántica Herramientas dan mayores opciones de

notación detallada Es más fácil ver secuencia del flujo de

llamados (de arriba hacia abajo) Pero está forzado a extender hacia la

derecha lo nuevos objetos

Sesión 174

Comparación

Diagrama de comunicación Es mucho más eficiente en el uso de

espacio Más fácil de modificar Más difícil ver la secuencia de

llamadas Menos opciones de notación

Sesión 175

: Socio

: Encargado

: Libro

: Ficha libro

: Ficha socio

: Préstamo

1: Coger libro

2: Solicitar préstamo

8: Autorizar préstamo

3: Verificar situación socio

4: Situación socio ok

5: Verificar situación libro

6: Situación libro ok

7: Introducir préstamo

Diagrama de comunicación

Sesión 176

Running Example

Desarrolle un diagrama de comunicación que represente lo mismo que este diagrama de secuencia

Sesión 177

Referencias[LARMAN] Larman, Craig. Applying UML and Patterns. An Introduction to

Object Oriented Analysis and Design. Prentice Hall, 1998.

[OO Head First] Brett D. McLaughlin, Gary Pollice, Dave West. Head First Object-Oriented Analysis and

Design: A Brain Friendly Guide to OOA&D. O'Reilly Media, Inc., 2006.

: Socio

: Encargado

: Libro

: Ficha libro

: Ficha socio

: Préstamo

1: Coger libro

2: Solicitar préstamo

8: Autorizar préstamo

3: Verificar situación socio

4: Situación socio ok

5: Verificar situación libro

6: Situación libro ok

7: Introducir préstamo

Mensajes

Un mensaje desencadena una acción en el objeto destinatario

Un mensaje se envía si han sido enviados los mensajes de una lista (sincronización):

A

BA.1, B.3 / 1:Mensaje

… Mensajes

Un mensaje se envía iterada y secuencialmente a un conjunto de instancias:

A

B1 *[i:=1..n] : Mensaje

… Mensajes

Un mensaje se envía iterada y concurrentemente a un conjunto de instancias:

A

B1 *| | [i:=1..n] : Mensaje

… Mensajes

Un mensaje se envía de manera condicionada:

A

B

[x>y] 1: Mensaje

… Mensajes

Un mensaje que devuelve un resultado:

A

B1: distancia:= mover(x,y)

Diagrama de Clases

Sesión 185

Temario

El Modelo de DominioPosibles Elementos del DominioBuscando elementos del Dominio en el ejemploUna primera representación gráfica: usando una herramienta UMLRevisando nuestro mono: Conceptos y AtributosRevisando nuestro mono: Conceptos en Asociación2da Iteración: profundizando relacionesCorrijamos nuestro mono inicial

Sesión 186

El Modelo de Dominio

Ya conocemos una forma básica de representar y especificar requerimientos

En torno a las Interacciones usuario-sistema En forma de Casos de Uso

Sin embargo, aún no conocemos “de qué se habla” en esas interacciones representadas

No sabemos el detalle de los objetos, lugares, transacciones, etc. que intervienen en la interacción usuario-sistema

El Modelo de Dominio nos permite identificar estos elementos y representarlos gráficamente

Identificando Conceptos o Elementos del Dominio Identificando sus Relaciones Identificando sus Atributos

Sesión 187

El Modelo de Dominio

¿Entonces ya llegamos a las Clases y los Objetos?

Nones, estamos recién descubriendo lo conceptos Algunos de ellos eventualmente se convertirán en Clases

de nuestro sistema, otros pasarán al triste olvido Pero esa es una Decisión de Diseño, nuestra tarea

ahora es entender, hacer al Análisis Debemos identificar conceptos no guiándonos en la

implementación, sino en el contexto del problema a resolver (Dominio)

Al igual que los casos de uso, el Dominio representado debe ser validado por el Cliente

Una pista: si un Cliente no puede entender algunos de los Elementos del Dominio que hemos identificado, probablemente estos No Sean Elementos del Dominio

Sesión 188

Posibles Elementos del Dominio [Larman]

Como primera regla, podemos fijarnos en los Sustantivos dentro de una explicación del problema

Pero este enfoque es muy mecánico; La ambigüedad del lenguaje puede llevarnos a identificar más de un elemento de dominio que representan lo mismo

Podemos intentar identificando: Objetos físicos o tangibles Lugares Transacciones Roles de la Gente (Cliente, Vendedor) Contenedores de Conceptos Otros sistemas Sustantivos Abstractos (“Sed”) Organizaciones Eventos (Emergencia) Reglas/Políticas Grabaciones/Logs

Sesión 189

Buscando elementos del Dominio en el ejemplo

Revisemos nuestro ejemplo para identificar los Conceptos o Elementos del Dominio

Basándonos en la lista anterior Nombrándolos como sustantivos

Nombremos además las relaciones que existen entre ellos

Los nombres deben ser verbos en presente (“realiza”, “paga”, etc.)

Representemos gráficamente nuestros conceptos, con “cajas y lineas”

Cliente Autocompra

Formato de la relación

Sesión 191

Una primera aproximación gráfica

La lista anterior tiene varios de los conceptos del dominio

Pero la representación gráfica es fundamental Podemos entenderla como un mapa, que nos permite navegar

entre los conceptos entendiendo sus relaciones

Realizaremos una representación gráfica usando UML

UML provee distintos diagramas para modelar Análisis y Diseño

Pero ninguno en particular llamado “Modelo de Dominio” Usaremos el Diagrama de Clases de UML para dibujar nuestro

primer diagrama de Dominio Se puede decir que el Modelo de Dominio es un Diagrama de

Clases de Análisis, donde no existen decisiones de Diseño

Podemos ocupar cualquier herramienta que soporte UML para hacer nuestro diagrama

Sesión 192

Revisando nuestro mono: Conceptos de Asociación

• Cuando modelamos un dominio, descubrimos que ciertos atributos sólo se dan entre la relación entre dos conceptos

• Veamos la siguiente alternativa para modelar Sociedad y Socios: SociedadPersona

es socio de

• % de Participación de Capital y Utilidad sólo tienen sentido como atributos de la relación entre persona y Sociedad– No todas las personas tiene % de participación– El % de participación de cada socio no es atributo de la

sociedad• Para representar estas situaciones, podemos ocupar

Conceptos originados en las relaciones

SociedadPersona

es socio de

Socio

+participacionCapital+participacionUtilidad

Sesión 193

2da Iteración: profundizando relaciones

Ahora que identificamos los conceptos, estudiemos mejor sus relaciones

Algunas de ellas parecen ambiguas Necesitamos identificar cardinalidad en las relaciones Es decir, cuántos de uno se relacionan con cuántos de

otro Por ejemplo:

SociedadSocio

+participacionCapital+participacionUtilidad

tiene

*1

• Ejemplos de Cardinalidades:– 0..1– 1..1– 0..*– 1..*– *

– 1..8 (número máximo específico)

Sesión 194


Podemos enriquecer nuestro modelo agregando otros tipos de relaciones:

Identificando relaciones del tipo “es-un”: Super Clases y Clases

Distinguiendo distintos tipos de asociación del tipo “tiene” entre los conceptos

Asociaciones Fuertes, o Composición, en las cuales los conceptos “contenidos” existen sólo si existe el concepto “contenedor” (por ejemplo, mano-dedos)

Asociaciones Débiles, o Agregación, en las cuales los conceptos “contenidos” pueden existir si no existe el contenedor (por ejemplo grupo de contactos-contacto)

Tipos de relaciones “ES-UN”

Conceptos comparten las mismas relaciones (y comportamiento)

Nos lleva a relaciones de herencia Composición, o Asociaciones Fuertes,

Conceptos “contenidos” existen sólo si existe el concepto “contenedor” (por ejemplo, mano-dedos)

Agregación, o Asociaciones Débiles, Conceptos “contenidos” pueden existir si no

existe el contenedor (por ejemplo grupo de contactos-contacto)Sesión 1 95

Sintaxis de un modelo de dominio

Sesión 196


La notación de UML permite expresar estas asociaciones:

Si la Lista de Contactos es eliminada, se perderán todos los contactos y los gruposSi se elimina un Grupo de Contactos, los Contactos siguen existiendo en la Lista de ContactosTambién es conveniente identificar los roles de cada concepto en la relación

ListaContactos Contacto

GrupoContactos

+lista +contactos

1 *

+grupo

+contacto

1

*+lista

+grupos

1

*

Sesión 197

Algunas Reflexiones¿Cómo asegurarme que he modelado todo lo que corresponde?

“Todo lo que Corresponde” = Todos los Requerimientos Identificados

Podemos generar una Matriz de Trazabilidad Filas: Casos de Uso Columnas: Requerimientos Marcamos en la matriz qué casos de uso resuelven qué

requerimientos Todos los Requerimientos deben estar resueltos en a lo

menos un Caso de Uso (estamos haciendo todo lo solicitado)

Todos los Casos de Uso deben resolver por lo menos un Requerimiento (no estamos inventando funcionalidades)

Sesión 198

Referencias

[LARMAN] Larman, Craig. Applying UML and Patterns. An

Introduction to Object Oriented Analysis and Design. Prentice Hall, 1998.

Clases: Notación Gráfica

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

nombre de la clase atributos de la clase operaciones de la clase

motocicleta

colorcilindradavelocidad maxima

arrancaracelerarfrenar

Asociación

La asociación expresa una conexión bidireccional entre objetos

Una asociación es una abstracción de la relación existente en los enlaces entre los objetos

Universidad Estudiante

Univ. de Murcia:Universidad Antonio:Estudiante

Una asociación

Un enlace

Ejemplo:

… Asociación

Persona Compañíatrabaja-para

nombres. s.

nombredirección

jefe

Administraempleado

* *emplea-a

0.. 10.. 1

0.. 1

*

marido

casado-con

mujer

Asociación Cualificada

Aerolínea Viajeronro_billete * 0..1

TableroAjedrez

filacolumna

1 1 Cuadro

Reduce la multiplicidad del rol opuesto al considerar el valor

del cualificador

Las caracterizaciones 1, 3, 4 y 5 están incluidas en el concepto más amplio de multiplicidad Objeto

Agregado

Objeto Componente

Multiplicidad Mínima

0 flexible

> 0 estricta

Multiplicidad Máxima

1 disjunto

> 1 no disjunto

Multiplicidad Mínima

0 nulos permitidos

> 0 nulos no permitidos

Multiplicidad Máxima

1 univaluado

> 1 multivaluado

… Agregación: Caracterización

Ejemplos

motor

coche

1

1

1

1

Persona

0..2*

+Padre

0..2

+Hijos

*

… Ejemplos

CuentaPersona

1

*

orAsociación excluyente

Empresa

*

*

Usuario Estaciónestá-autorizado-en

prioridadprivilegios

camb_privil

Autorización

* *

Clase de asociación

Polígono Puntocontiene 3.. *1

{ordenado}Agregación

Abstracciones más generales.

vehiculo

vehiculo terrestre vehiculo aéreo

camion coche avion helicoptero

... Jerarquías de Generalización/Especialización

La especialización es una técnica muy eficaz para la extensión y reutilización coche

funcionando estropeado


Un ejemplo de Especialización Estática: vehiculo aéreo

avion helicoptero


Un ejemplo de Especialización Dinámica:

coche



Ejemplo: varias especializaciones a partir de la misma superclase:

vehiculo aéreo

avion helicoptero

comercial

militar


Ejemplo: especializaciones dinámicas de la misma superclase:

coche


de menos de 1000kms

de más de 1000 kms


Un ejemplo combinado:vehiculo

vehiculo terrestre

camion

coche


vehiculo aéreo

avion helicoptero

comercial

militar

de menos de 1000kms

de más de 1000 kms

estática

estáticaestática

dinámica

dinámica


El siguiente es un ejemplo de clasificación no equilibrada:

vehiculo terrestre

camion coche Harley Davidson


Por regla general, es mejor limitar el número de subclases a cada nivel a costa de aumentar el número de objetos por clase y reservar los atributos para cualificar afinadamente los objetos

A veces, una especialización dinámica tiene un equivalente a través de una especialización estática y una asociación ...


Ejemplo: mariposa

oruga crisálida Lepidóptero

oruga crisálida Lepidóptero

mariposa estadio

1

Aspecto

1


Diagrama de Estados

Socio BibliotecaNúmero : intNombre : char[50]Número préstamos : int = 0

Alta()Baja()Prestar(CódigoLibro : int, Fecha : date)Devolver(CódigoLibro : int, Fecha : date)

con préstamos

sin préstamos

alta baja

prestar devolver[ número_préstamos = 1 ]

prestar

devolver[ número_préstamos > 1 ]

número_préstamos = 0

número_préstamos > 0

… Diagramas de Estados

Ejemplo de un Diagrama de Estados para la clase persona:

en el paro en activo

jubilado

contratar

perder empleo

jubilarsejubilarse


La comunicación bidireccional puede representarse mediante comunicación asíncrona. Por ejemplo en un Diagrama de Colaboración:

un objeto

otro objeto

1: una pregunta

2: la respuesta


Si la comunicación es síncrona el cliente debe esperar la respuesta. Con lo cual en el cliente tendríamos:a

espera respuesta c

plantear pregunta

recibir respuesta


Las guardas permiten condicionar la transición:

a bEvento[ condición ]


Acciones

Podemos especificar la ejecución de una acción como consecuencia de la transición:

a bEvento[ condición ] / acción

Dicha acción también se considera instantánea

Podemos especificar el envío de un evento a otro objeto como consecuencia de la transición:

a

b

Evento( arg1, arg2 )[ condición ] / ^otro_objeto.evento(arg2)

… Acciones

Se puede especificar el hacer una acción como consecuencia de entrar, salir o estar en un estado:

estado A

entry: acción por entrarexit: acción por salirdo: acción mientras en estado

… Acciones

Se puede especificar el hacer una acción cuando ocurre en dicho estado un evento que no conlleva salir del estado:

estado A

on evento_activador( arg1 )[ condición ]: acción por evento

.. Acciones

Actividades

Las actividades son similares a las acciones pero tienen duración y se ejecutan dentro de un estado del objeto

Las actividades pueden interrumpirse en todo momento, cuando se desencadena la operación de salida del estado

Cuando una actividad finaliza se produce una transición automática de salida del estado

a

do: actividad

b[ not condición ]

b

[ condición ]

… Actividades

Generalización de Estados

Podemos reducir la complejidad de estos diagramas usando la generalización de estados

Distinguimos así entre superestado y subestados

Un estado puede contener varios subestados disjuntos

Los subestados heredan las variables de estado y las transiciones externas


Ejemplo:

a b

c

e1

e2

e2

Quedaría como:

c

a ba be1

e2


Las transiciones de entrada deben ir hacia subestados específicos:

c

a ba be1

e2

e0

… Generalización de Estados

Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qué subestado se entra:

c

a ba be1

e2

e1

e0


Ejemplo:

e1e1


Historial

Por defecto, los autómatas no tienen memoria

Es posible memorizar el último subestado visitado para recuperarlo en una transición entrante en el superestado que lo engloba

Ejemplo: a

d2

d1

H

d2

d1

x yh

out

in

H

… Historial

También es posible la memorización para cualquiera de los subestados anidados (aparece un * junto a la H)

a

d2

d1

H*

d2

d1

x yh

out

in

H*

… Historial

Ejemplo:

Enjuague Lavado Secado

H

Enjuague Lavado Secado

H

Espera

Cerrar PuertaAbrir Puerta

… Historial

AbrirCerrar

… Destrucción de Objeto

Ejemplo:

En tierraCrear(matricula)

En vuelo

aterrizardespegar

crash

Ejemplo: a

esperar dinero

entry: Mostrar mensajedo: Esperar 30 segundosexit: cerrar ranura

b

anular transacción

/ Abrir ranura

Depósito efectuado

Si en 30 segundos no se introduce el dinero se termina la actividad pasando a anular la transacción. En cualquier caso se cierra la ranura.

… Transiciones temporizadas

Ejemplo v.2:

… Transiciones temporizadas

a

esperar dinero

entry: Mostrar mensajeexit: cerrar ranura

b

anular transacción

/ Abrir ranura

Depósito efectuado

Temporizador(30 segundos)

Diagrama de Actividades

EjemplosBuscar Bebida

Poner café en filtro Añadir agua al depósito Coger taza

Poner filtro en máquina

Encender máquina

Café en preparación

Servir café

Coger zumo

Beber

[no hay café]

[hay café

[no zumo]

[hay zumo]

^cafetera.On

indicador de fin

...Ejemplos (con bandas)

Emitir billete

Pasajero Vendedor Airline

Solicitar pago Reservar plazas

Confirmar plaza reservadaPagar pasaje

Informar alternativas y precios

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Seleccionar vuelo

Diagrama de Componentes

La representación gráfica es la siguiente:

GenéricoCuerpoEspecificación

Package specification

Package body

Generic package

… Diagramas de Componentes

Subsistemas Los distintos componentes pueden

agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación

Son paquetes estereotipados en <<subsistemas>>

NewPackage4<<subsistema>>

Diagrama de Distribución

Diagramas de Distribución

Punto de Venta

Servidor Central

Terminal de Consulta

Gestión de Cuentas

Comment

Interfaz de Terminal

Comment

Rutinas de Coneccion

Comment


Comment

Interfaz de Terminal

Comment


Comment

Acceso a BD

Comment

Control y Análisis

Comment

Ejemplo de conexión entre nodos:

Nodo<<Procesador>

nodo2<<dispositivo>>

dispositivo

conexión7

conexión1<<<<TCP/IP>>>>

<<RDSI>>

En Rational Rose podemos distinguir entre el dispositivo por estereotipado y el dispositivo con su propio símbolo

… Diagramas de Distribución

Paquetes

Paquetes en UML

Los paquetes ofrecen un mecanismo general para la organización de los modelos agrupando elementos de modelado

Se representan gráficamente como:

Nombre de paquete

Documents

Unidad 2.2: