Lenguaje de Modelamiento Unificado

Unidad 2.2:

UML (Lenguaje de
Modelamiento Unificado)

Diagramas de UML
State
State
Use Case Diagrams de
Diagramas
Use Case Diagrams State
Use Case Diagrams de
Diagramas Clases State
Use Case Diagrams Diagrams de
Diagramas
Diagrams de
Diagramas Casos de Uso Diagrams
Diagrams Objetos
Secuencia

Scenario State
Scenario State
Diagrams de
Diagramas Diagrams de
Diagramas
Diagrams Diagrams
Colaboración Modelo Componentes

Scenario Component
Scenario Component
Diagramas de
Diagrams
Diagrams de
Diagramas Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad

“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

Caso de uso X

Actor A
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: Actores
Los 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.

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.

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:

Actor

Caso de Uso

… Ejemplos
En el paquete tipos de venta:

Venta Normal

Venta en Rebajas
Cliente Vendedor

Venta en Oferta

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
<<extend>>

Caso de uso destino

Caso de uso origen

… Ejemplos

Realizar préstamo
Socio Encargado

tarjeta caducada

<<extend>>
<<extends>>

Solicitar nueva tarjeta

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
<<include>>

Caso de uso destino

Caso de uso origen

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

… Ejemplos

Reintegro cuenta corriente <<include>>
<<uses>>

Cliente Validar operación

<<uses>>
<<include>>

Reintegro cuenta crédito

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 destino

Caso de uso origen

 Ejemplo:

<<extend>>
<<extends>>
Transferencia por Internet
Giro por Internet

Cliente

<<includes>>
<<include>> Transferencia
Giro

Identificación

… 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>
Secuencia Paso Acción
Normal 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
n
Postcondición <postcondición del caso de uso>
Excepciones 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
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 Programar Procedimiento.
uso
Actores
Propósito

Tipo
Resumen

Referenci
a
cruzadas

Sección Principal.
Acción de los actores. Respuesta del sistema.
Flujo 1. 2.
normal 3. 4.
de 5..
eventos.
6.
7. 8.

9. 10
11
Flujos alternativos.
Línea 3:
Línea 7:
Línea 8:

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.

Asignación de nombres a los eventos:
 Para una mayor claridad deben comenzar
con un verbo en infinitivo.

Relación caso de uso/DSS
Caso de uso (CU) describe cómo actores externos
interactúan con el sistema a construir
Durante la interacción, el actor genera eventos del
sistema para un sistema,
 usualmente esto requiere que alguna operación
del sistema maneje el evento
DSS hace concretos y explícitos los eventos que son
implícitos en el CU
Veamos un DSS del curso normal de “Modificar
Capital”

36
Sesión 1

RunningExample – DSS
Modificar Capital
Curso
normal de
los eventos

37
Sesión 1

Eventos y operaciones
Evento 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.
38
Sesión 1

DSS

Diagrama que muestra
 los eventos generados por actores externos,

 … su orden

 …y los eventos inter-sistemas

…para un escenario particular de un CU
Todos los sistemas son tratados como cajas negras
Foco en los eventos que cruzan la frontera entre
actores y sistemas

39
Sesión 1

DSS
Los casos de uso del sistema (escenarios y eventos)
son input para su creación
El tiempo se describe (avanza) hacia abajo
El orden de los eventos debe seguir el mismo orden
del escenario que representan
Los eventos del sistema pueden incluir parámetros
Usa diagrama de secuencia de UML
Serán input para
 contratos de operación

 y diseño de objetos

40
Sesión 1

DSS de “Modificar Capital”

Actor externo Sistema como
caja negra

Mensaje con
parámetros
Valor(es) de
retorno
asociado con el
mensaje previo
tiempo

41
Sesión 1

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.
42
Sesión 1

Modificar Capital
Curso 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 1 43

Elaborando un DSS
Consideramos 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)

44
Sesión 1

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 comandos45
Sesión 1

DSS
Guideline:
 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

46
Sesión 1

RunningExample – DSS
Modificar Capital
Curso
normal de
los eventos

47
Sesión 1

Diagramas de Secuencia
: Libro : Ficha socio : Ficha libro : Préstamo
: Socio : Encargado

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

A B C

m1

m2

m3

m4

m5

Quien llama Línea telefónica Llamado

 Ejemplo descuelga

tono

marcar

Las bandas
rectangulares
indicación de llamada timbre

representan los descuelga

periodos de
actividad de los diga?

objetos

 Un objeto puede enviarse a sí mismo un
mensaje:
a

mensaje reflexivo

 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 X
Loop
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

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

60
Sesión 1

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

Sesión 1 61

Link
Camino 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
mensajes
Puede haber múltiples mensajes en ambas
direcciones en un mismo link (carretera de doble vía)

62
Sesión 1

Secuencia de mensajes numerados

63
Sesión 1

Mensajes condicionales
Siguiendo 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 1 64

Caminos condicionales
exclusivos
Expresiones de secuencia se modifican
con una letra de camino condicional
 La primera letra usada es a por convención

65
Sesión 1

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 66

Iteración sobre una colección
Describen iteraciones sobre todos los
miembros de una colección

Sesión 1 67

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 68

Mensajes polimórficos
Mensajes a clases abstractas

Sesión 1 69

Reflexión sobre Diagramas de
Interacción

 www.dsic.upv.es/~uml

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

71
Sesión 1

DSS

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

72
Sesión 1

Comparación
Uno elige cuál quiere usar
 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 73
Sesión 1

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

74
Sesión 1

Diagrama de comunicación
1: Coger libro : Libro

: Socio 2: Solicitar préstamo : Ficha s
ocio
3: Verificar situación socio

8: Autorizar préstamo
4: Situación socio ok

6: Situación libro ok : Encargado
: Présta
7: Introducir préstamo mo

5: Verificar situación libro

: Ficha li
bro

75
Sesión 1

Running Example

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

76
Sesión 1

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.

77
Sesión 1

1: Coger libro : Libro

: Socio 2: Solicitar préstamo : Ficha s
ocio
3: Verificar situación socio

8: Autorizar préstamo
4: Situación socio ok

6: Situación libro ok : Encargado
: Présta
7: Introducir préstamo mo

5: Verificar situación libro

: Ficha li
bro

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.1, B.3 / 1:Mensaje B

A

… Mensajes
 Un mensaje se envía iterada y
secuencialmente a un conjunto de
instancias:
1 *[i:=1..n] : Mensaje
B

A

… Mensajes
 Un mensaje se envía iterada y
concurrentemente a un conjunto de
instancias:
1 *| | [i:=1..n] : Mensaje
B

A

… Mensajes
 Un mensaje se envía de manera
condicionada:
[x>y] 1: Mensaje
B

A

… Mensajes
 Un mensaje que devuelve un resultado:

1: distancia:= mover(x,y)
B

A

Temario
El Modelo de Dominio
Posibles Elementos del Dominio
Buscando elementos del Dominio en el ejemplo
Una primera representación gráfica: usando una
herramienta UML
Revisando nuestro mono: Conceptos y Atributos
Revisando nuestro mono: Conceptos en Asociación
2da Iteración: profundizando relaciones
Corrijamos nuestro mono inicial

85
Sesión 1

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

86
Sesión 1

¿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

87
Sesión 1

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

88
Sesión 1

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 compra Auto

89
Sesión 1

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
91
Sesión 1

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:
Persona Sociedad

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
Socio

+participacionCapital
+participacionUtilidad

Persona Sociedad

es socio de

92
Sesión 1

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:
Socio
tiene
Sociedad
+participacionCapital
1 * +participacionUtilidad

• Ejemplos de Cardinalidades:
– 0..1
– 1..1
– 0..*
– 1..* – 1..8 (número máximo
–* específico)
93
Sesión 1


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)

94
Sesión 1

Sintaxis de un modelo de dominio

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


La notación de UML permite expresar estas asociaciones:
ListaContactos 1 * Contacto
+lista +contactos
+lista 1
*+contacto

+grupos *
GrupoContactos 1

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

96
Sesión 1

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)

97
Sesión 1

Referencias
[LARMAN]
 Larman, Craig. Applying UML and Patterns. An
Introduction to Object Oriented Analysis and Design.
Prentice Hall, 1998.

98
Sesión 1

Clases: Notación Gráfica
 Cada clase se representa en un
rectángulo con tres compartimientos:
 nombre de la clase motocicleta

 atributos de la clase color
cilindrada
 operaciones de la clase
velocidad maxima

arrancar
acelerar
frenar

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
Univ. de Murcia:Universidad Un enlace Antonio:Estudiante

Universidad Estudiante
Una asociación

… Asociación
 Ejemplo:
marido

casado-con 0.. 1
0.. 1 trabaja-para * Compañía
mujer Persona *
nombre emplea-a
jefe nombre
0.. 1 s. s. dirección
Administra * empleado

Asociación Cualificada

* 0..1
Aerolínea nro_billete Viajero

Tablero fila 1 1
columna
Cuadro
Ajedrez

Reduce la multiplicidad del rol opuesto al considerar el valor
del cualificador

… Agregación: Caracterización
 Las caracterizaciones 1, 3, 4 y 5 están incluidas en el
concepto más amplio de multiplicidad
Objeto Agregado

Multiplicidad Mínima Multiplicidad Mínima
0 nulos permitidos 0 flexible
>0 nulos no permitidos >0 estricta

Multiplicidad Máxima Multiplicidad Máxima
1 univaluado 1 disjunto
>1 multivaluado >1 no disjunto

Objeto Componente

Ejemplos

coche Persona +Hijos

1 *
0..2
+Padre

1
motor

… Ejemplos
1 contiene
Agregación Polígono 3.. *
Punto
{ordenado}

* * Persona
Cuenta Asociación excluyente
or
*
Empresa
1

* está-autorizado-en *
Usuario Estación

Autorización
Clase de asociación prioridad
privilegios
camb_privil

... Jerarquías de
Generalización/Especialización
Abstracciones más generales.
vehiculo

vehiculo terrestre vehiculo aéreo

camion coche avion helicoptero

... Jerarquías de
 La especialización es una técnica muy
eficaz para la extensión y reutilización
coche

funcionando estropeado

... Jerarquías de
 Un ejemplo de Especialización Estática:
vehiculo aéreo

avion helicoptero

... Jerarquías de
 Un ejemplo de Especialización
Dinámica:
coche


... Jerarquías de
 Ejemplo: varias especializaciones a
partir de la misma superclase:
comercial

vehiculo aéreo

militar

avion helicoptero

... Jerarquías de
 Ejemplo: especializaciones dinámicas de
la misma superclase:
de menos de 1000kms

coche

de más de 1000 kms

... Jerarquías de
 Un ejemplo combinado:
vehiculo

comercial

vehiculo terrestre vehiculo aéreo
estática

estática
estática militar

camion avion helicoptero

de menos de 1000kms coche
dinámica
de más de 1000 kms
dinámica


... Jerarquías de
 El siguiente es un ejemplo de
clasificación no equilibrada:
vehiculo terrestre

camion coche Harley Davidson

... Jerarquías de
 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 ...

... Jerarquías de
 Ejemplo: mariposa

oruga crisálida Lepidóptero

Aspecto
mariposa estadio
1

oruga crisálida Lepidóptero

… Diagramas de Estados

alta baja

número_préstamos = 0
sin préstamos

prestar devolver[ número_préstamos = 1 ]

número_préstamos > 0

con préstamos

prestar

devolver[ número_préstamos > 1 ]

 Ejemplo de un Diagrama de Estados
para la clase persona:
contratar
en el paro en activo

perder empleo
jubilarse
jubilarse

jubilado

 La comunicación bidireccional puede
representarse mediante comunicación
asíncrona. Por ejemplo en un Diagrama
de Colaboración:
1: una pregunta
un otro
objeto objeto
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

plantear pregunta

espera respuesta recibir respuesta
c

 Las guardas permiten condicionar la
transición:
Evento[ condición ]
a b

Acciones
 Podemos especificar la ejecución de
una acción como consecuencia de la
transición:
Evento[ condición ] / acción
a b

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

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

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

b

… 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 entrar
exit: acción por salir
do: 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

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

… Actividades
 Cuando una actividad finaliza se
produce una transición automática de
salida del estado
[ not condición ]
a b
do: actividad

[ condición ]

b

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:
e1
a b

e2
e2
c

 Quedaría como:

e1
a b

e2

c

… Generalización de Estados
 Las transiciones de entrada deben ir
hacia subestados específicos:

e1
a b

e2

e0

c

 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:
e1
a b
c
e2
e0

 Ejemplo:

e1
e1

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

… Historial
 Ejemplo: a

d2

in
h
x y
out
d1

H

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

d2

in
h
x y

out
d1

H*

… Historial
 Ejemplo:
Enjuague Lavado Secado

H

Cerrar Puerta
Abrir Abrir
Cerrar Puerta

Espera

… Destrucción de Objeto
 Ejemplo:
crash
En vuelo

despegar aterrizar

Crear(matricula)
En tierra

… Transiciones temporizadas
 Ejemplo: a

/ Abrir ranura
Si en 30 segundos no se
introduce el dinero se
termina la actividad esperar dinero
anular transacción
pasando a anular la entry: Mostrar mensaje
transacción. En do: Esperar 30 segundos
exit: cerrar ranura
cualquier caso se cierra
la ranura.
Depósito efectuado

b

… Transiciones temporizadas
 Ejemplo v.2:
a

/ Abrir ranura

esperar dinero Temporizador
(30 segundos)
entry: Mostrar mensaje anular transacción
exit: cerrar ranura

Depósito efectuado

b

Ejemplos
[no hay café] [no zumo]
Buscar Bebida
[hay café [hay zumo]

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

Poner filtro en máquina Coger zumo

Encender máquina
^cafetera.On
Café en preparación

indicador de fin
Servir café
Beber

...Ejemplos (con bandas)
Pasajero Vendedor Airline

Solicitar pasaje
Verificar
existencia vuelo

Dar detalles vuelo

Informar alternativas
y precios
Seleccionar vuelo

Solicitar pago Reservar plazas

Confirmar
Pagar pasaje plaza reservada

Emitir billete

… Diagramas de Componentes
 La representación gráfica es la
siguiente:
Especificación Cuerpo Genérico

Package Package Generic
specification body package

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>>

<<subsistema>>
NewPackage4

Diagramas de Distribución
Servidor Central Control y Análisis

Acceso a BD Comment

Comment

Rutinas de Coneccion
Comment

Terminal de Consulta
Interfaz de Terminal
Comment Comment

Punto de Venta
Comment

Gestión de Cuentas Interfaz de Terminal

Comment Comment

… Diagramas de Distribución
 Ejemplo de conexión entre nodos:

<<Procesador> <<dispositivo>>
Nodo <<<<TCP/IP>>>> nodo2
conexión1

conexión7
<<RDSI>>
En Rational Rose podemos dispositiv
distinguir entre el dispositivo por o
estereotipado y el dispositivo con
su propio símbolo

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

Lenguaje de Modelamiento Unificado

Más contenido relacionado

La actualidad más candente (20)

Similar a Lenguaje de Modelamiento Unificado (20)

Lenguaje de Modelamiento Unificado