Unidad 2.

2:
UML (Lenguaje de
Modelamiento
Unificado)

Diagramas de UML
Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Secuencia

Use Case
Use Case
Diagramas de
Diagrams
Diagrams
Casos de Uso

Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Colaboracin
Scenario
Scenario
Diagramas de
Diagrams
Diagrams
Estados

State
State
Diagramas de
Diagrams
Diagrams
Clases

Modelo

Diagramas de
Actividad

State
State
Diagramas de
Diagrams
Diagrams
Objetos
State
State
Diagramas de
Diagrams
Diagrams
Componentes

Component
Component
Diagrams
Diagramas
Diagrams de

Distribucin

Un modelo es una descripcin 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 Interaccin
Diagrama de Secuencia
Diagrama de Colaboracin
Diagramas de implementacin
Diagrama de Componentes
Diagrama de Despliegue

 Casos de Uso
Existen dos elementos primordiales cuando
se realiza la modelacin de C.U.

Diagramas de casos de uso: ilustra

grficamente el sistema como una coleccin 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 descomposicin 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
ms requerimientos.
Inicialmente los CU se definen durante la etapa
de los requerimientos del ciclo de vida y se
refinarn 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 propsito de terminar alguna tarea de
negocios que produzca algo con valor apreciable.
Un actor representa un papel desempeado por un
usuario que interacta 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 organizacin, otro sistema de informacin 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 ejecucin
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 nmina 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 propsito de usar el
sistema real. Ellos facilitan el evento a travs del uso
directo del sistema para beneficio del actor primario
de negocios.
Ej : Un dependiente de una tienda de abarrotes que
selecciona los artculos para el cliente que compra
abarrotes una operadora que proporciona
informacin 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 almacn recibe una orden de embalaje
para preparar un flete despus de que un
cliente ha colocado una orden.

 Casos de Uso : Actores

En muchos sistemas de informacin hay eventos
de negocios ocasionados por el calendario o la
hora del reloj.

Ej: El sistema de facturacin de una compaa de

tarjetas de crdito genera automticamente sus estados
de cuenta en el quinto da de cada mes. (fecha de
facturacin).
Un banco concilia sus transacciones con cheques todos
los das a las 5 pm.

Estos
eventos
son
ejemplo
de
eventos
temporales, Quin sera el actor?, el actor de un
evento temporal es el tiempo.

 Casos de Uso:
Relaciones
Una relacin: se ilustra como una lnea entre
dos smbolos en el diagrama de casos de uso.
El significado de las relaciones puede diferir
dependiendo de cmo se dibujen las lneas y
que tipo de smbolos conectan

 Casos de Uso:
Relaciones
Asociaciones: Existe una relacin entre un
actor y un CU siempre que el caso describa
una interaccin entre stos.

Se representa con una lnea continua que conecta al

actor y al CU.
Una Asociacin 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
interaccin entre el CU y el actor externo servidor o
receptor.

Casos de Uso: Relaciones

UML define cuatro tipos de relacin
en los Diagramas de Casos de Uso:

Comunicacin:
Actor
Caso de Uso

 Ejemplos
En el paquete tipos de venta:

Venta Normal

Cliente

Venta en Rebajas

Venta en Oferta

Vendedor

 Casos de Uso:
Relaciones
Extensin: Un CU puede contener una funcionalidad
compleja que consiste de varios pasos que hacen difcil
entender la lgica del caso.

Con objeto de facilitar el CU y hacer que se entienda ms

fcilmente, podemos extraer los pasos ms complejos para
formar su propio caso.
El caso resultante de llama caso de extensin, ya que extiende
la funcionalidad del VU original.
Un CU puede tener muchas relaciones de extensin, pero un
CU de extensin puede ser invocado solamente por el CU que
se est extendiendo
Se representa mediante una lnea con cabeza de flecha
(continua o segmentada) que comienza con el CU de extensin
y que apunta al CU que se est extendiendo.

 Casos de Uso:
Relaciones

Extensin : el Caso de Uso

origen extiende el
comportamiento
del
Caso
de
Uso
<<extend>>
destino
Caso de uso
destino
Caso de uso
origen

 Ejemplos

Realizar prstamo
Socio

Encargado
tarjeta caducada
<<extend>>
<<extends>>

Solicitar nueva tarjeta

 Casos de Uso:
Relaciones

Uses (o Inclusin): Comnmente se puede

descubrir dos o ms CU que ejecuten pasos de
funcionalidad idntica. 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 lnea con cabeza de flecha
(continua o segmentada) que comienza en el CU Oficial y
apunta al CU que se est usando.

 Casos de Uso:
Relaciones

Inclusin : una instancia del Caso de Uso origen

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

Validar operacin

Cliente

<<uses>>
<<include>>

Reintegro cuenta crdito

 Casos de Uso:
Relaciones
Dependencia: Como administrador de proyecto o
desarrollador lder, es de mucha ayuda saber
cules 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 depsito y en tercer lugar haga un retiro.

 Casos de Uso:
Relaciones
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
propsitos
de
planeacin
y
de
programacin.
Esta relacin se representa con una lnea con
cabeza de flecha que comienza en un CU y
que apunta al CU del cual depende.
<<depende de>>

 Casos de Uso:
Relaciones
Herencia: Cuando dos o ms actores
comparten un comportamiento comn (En
otras palabras, pueden iniciar el mismo caso
de uso), lo mejor es extrapolar este
comportamiento comn y asignarlo a un
nuevo actor resumen con objeto de reducir la
comunicacin redundante en el sistema.

 Casos de Uso:
Relaciones

Herencia : el Caso de Uso origen

hereda la especificacin del Caso de
Uso destino y posiblemente la
modifica y/o ampla
Caso de uso
destino
Caso de uso
origen

 Casos de Uso:
Relaciones
Ejemplo:
Giro por Internet
Transferencia
por
Internet

<<extends>>
<<extend>>

<<includes>>
<<include>>

Identificacin

Cliente
Giro
Transferencia

 Casos de Uso
El segundo elemento, narracin del caso de
uso, describe los detalles de cada evento.

RF- <id del requisito>

Versin
Autores
Fuentes
Objetivos asociados
Descripcin

Precondicin
Secuencia
Normal

Postcondicin
Excepciones

Rendimiento
Frecuencia esperada
Importancia
Urgencia
Comentarios

<nombre del requisito funcional>

<numero de versin y fecha>
<autor>
<fuente de la versin actual>
<nombre del objetivo>
El sistema deber comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activacin> , abstracto durante la realizacin de los
casos de uso <lista de casos de uso>}
<precondicin del caso de uso>
Paso Accin
1
{El <actor> , El sistema} <accin realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2
Si <condicin>, {el <actor> , el sistema} <accin
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
<postcondicin del caso de uso>
Paso Accin
1
Si <condicin de excepcin>,{el <actor> , el
sistema} }<accin realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuacin este caso
de uso {continua, aborta}
2
3
Paso Cota de tiempo
1
n segundos
2
n segundos
<n de veces> veces / <unidad de tiempo>
{sin importancia, importante, vital}
{puede esperar, hay presin, inmediatamente}
<comentarios adicionales>

 Casos de Uso
Proceso de la modelacin 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
uso

de Programar Procedimiento.

Actores
Propsito
Tipo
Resumen
Referenci
a
cruzadas
Seccin Principal.
Accin de los actores.
Flujo
normal
de
eventos.

Respuesta del sistema.

1.
3.
5..
6.
7.

2.
4.

9.

10
11

Flujos alternativos.
Lnea 3:
Lnea 7:
Lnea 8:

8.

Diagrama de Secuencia

Diagrama de Secuencia
Antes del diseo (cmo funcionar el
software) se debe investigar y definir su
comportamiento como caja negra
El comportamiento del sistema es una
descripcin de lo que hace,
sin explicar la manera en que lo hace
Parte de esa descripcin es un diagrama
de secuencia del sistema

Los diagramas de
secuencia
Es un artefacto creado de manera
rpida y fcil que muestra los eventos
de entrada y salida relacionados con el
sistema que se est estudiando.
UML incluye la notacin 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
descripcin de qu hace el sistema, sin explicar
cmo lo hace.
Def: Es un dibujo que muestra para un
escenario especfico 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 lmites del sistema desde los actores a los
sistemas.

Diagrama de secuencia
Asignacin de nombres a los
eventos:

Para una mayor claridad deben

comenzar con un verbo en infinitivo.

Relacin caso de uso/DSS

Caso de uso (CU) describe cmo actores
externos interactan con el sistema a construir
Durante la interaccin, el actor genera eventos
del sistema para un sistema,
usualmente esto requiere que alguna
operacin del sistema maneje el evento
DSS hace concretos y explcitos los eventos
que son implcitos en el CU
Veamos un DSS del curso normal de Modificar
Capital

Sesin 1

36

RunningExample DSS
Modificar
Capital
Curso
normal de
los
eventos

Sesin 1

37

Eventos y operaciones
Evento del sistema

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

Operacin del sistema

accin que el sistema ejecuta en respuesta a un evento del

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

causa la ejecucin de la operacin modificarCapital.

El nombre del evento y de la operacin pueden ser (y

generalmente son) idnticos.

Sesin 1

La diferencia es que el evento X es el estmulo y la operacin

X es la repuesta.
Lo mismo sucede con los mensajes y los mtodos en
Orientacin a Objetos y UML.

38

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

Sesin 1

39

DSS
Los casos de uso del sistema (escenarios y
eventos) son input para su creacin
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
parmetros
Usa diagrama de secuencia de UML
Sern input para
contratos de operacin
y diseo de objetos

Sesin 1

40

DSS de Modificar Capital

Actor externo

Sistema como
caja negra

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

Sesin 1

41

Elaborando un DSS
Para elaborar un DSS para un escenario, y:
Trace una lnea que represente el sistema como una
caja negra
Identifique los actores que operan directamente sobre
el sistema
Trace una lnea para cada uno de ellos.
A partir del escenario identifique los eventos
(externos) del sistema que son generados por los
actores
Mustrelos grficamente en el diagrama.
A la izquierda del diagrama puede incluir o no el texto
del caso de uso.

Sesin 1

42

Modificar Capital
Curso normal de los eventos
Accin 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
nmero de nmero de repertorio,
nombre de notaria, fecha de escritura
4. El contribuyente confirma los
cambios al capital
5. El sistema almacena cambios al
capital
Sesin 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

interactan directamente con el sistema de
software
Usuarios
OJO! Slo quien acta directamente con el sistema
Ej. En la venta de un producto: el cliente interacta con el cajero,
pero no directamente con el sistema de ventas; => cajero es
generador de eventos, cliente no
Ej. Contribuyente/Representante Electrnico
Otros sistemas
Colaboraciones con sistemas externos (de pago, etc)
Ej. No hay (an :P)

Sesin 1

44

Elaborando un DSS
Los eventos de un sistema (y sus operaciones asociadas)
deben expresarse en el nivel de propsito
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 propsito de la operacin

Mantiene un carcter abstracto y no se pronuncia sobre

qu interfaz sirve para capturar el evento del sistema
(decisiones de diseo)
Es ms claro si el nombre de un evento del sistema
comienza con un verbo

ej. agregar, introducir, terminar, efectuar

esto recalca que los eventos estn orientados a comandos

Sesin 1

45

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 cmo lo hace
Junto con CU y contratos de operacin del
sistema

Sesin 1

46

RunningExample DSS
Modificar
Capital
Curso
normal de
los
eventos

Sesin 1

47

Diagramas de Secuencia
: Socio

: Encargado

: Libro

: Ficha socio

Coger libro

Solicitar prstamo
Verificar situacin socio
Situacin socio ok
Verificar situacin libro
Situacin libro ok
Introducir prstamo
Autorizar prstamo

: Ficha libro

: Prstamo

 Diagramas de
Secuencia
B

m1

m2
m3

m4
m5

 Diagramas de
Secuencia
Ejemplo

Quien llama

Lnea telefnica

Llamado

descuelga
tono

marcar

Las bandas
rectangulares
representan los
periodos de
actividad de los
objetos

indicacin de llamada

timbre
descuelga

diga?

 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

El retorno se
considera implcito
cuando el envo es
sncrono

 Diagrama de Secuencia
En el caso asncrono 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 envo de mensajes, p.e., mientras
se cumpla una condicin:
While X
Loop
end Loop

 Estructuras de control
La iteracin puede expresarse
tambin como parte del mensaje:

*[condicin] Mensaje

 Estructuras de control
Las bifurcaciones condicionales
pueden representarse de esta forma:

If condicin
else
end if

Diagrama de Colaboracin

Mensaje
Mensaje entre objetos que es representado por
una expresin de mensaje y una pequea
flecha indicando la direccin del mensaje
Muchos mensajes pueden navegar a travs 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 tambin
this

Sesin 1

60

Creacin de instancias
Cualquier mensaje puede ser usado para crear
instancias
La convencin es llamar a estos mtodos create, o
usar un estereotipo de tipo <<create>>
Puede incluir argumentos

Sesin 1

61

Link
Camino de conexin entre dos objetos
Indica que alguna forma de navegacin o
visibilidad entre los objetos es posible
Es una instancia de asociacin
A lo largo de estos links pueden navegar los
mensajes
Puede haber mltiples mensajes en ambas
direcciones en un mismo link (carretera de
doble va)

Sesin 1

62

Secuencia de mensajes numerados

Sesin 1

63

Mensajes condicionales
Siguiendo al nmero de secuencia se
incluye una clusula condicional en
parntesis cuadrados
El mensaje es enviado slo si la
condicin es cierta

Sesin 1

64

Caminos condicionales
exclusivos
Expresiones de secuencia se
modifican con una letra de camino
condicional

Sesin 1

La primera letra usada es a por

convencin

65

Loops
Expresiones que describen un ciclo se
identifican con un asterisco y una
expresin condicional

Mientras la expresin condicional sea

verdadera el ciclo contina

Sesin 1

66

Iteracin sobre una coleccin

Describen iteraciones sobre todos los
miembros de una coleccin

Sesin 1

67

Mensajes a mtodos estticos

Para llamar a mtodos static se usa el
estereotipo <<metaclass>> para
representar la clase que contiene tal
mtodo

La clase Calendar es una instancia de metaclass

Sesin 1

68

Mensajes polimrficos
Mensajes a clases abstractas

Sesin 1

69

Reflexin sobre Diagramas

de Interaccin

www.dsic.upv.es/~uml

Problemas tpicos
Problemas tpicos de su uso:

Sesin 1

En los proyectos de desarrollo, no se

aprecia el valor de llevar a cabo el
diseo de objetos mediante estos
diagramas
Por lo anterior, se disean de manera
vaga, e imprecisa

71

DSS
UML no define nada que se llame
diagrama de secuencia del
sistema, sino que simplemente
diagrama de secuencia
El apellido sealado corresponde a
un uso especfico del diagrama de
secuencia, en que precisamente el
sistema es visto como caja negra.
Sesin 1

72

Comparacin
Uno elige cul quiere usar
Diagrama de secuencia

Ha habido ms esfuerzo en su notacin y

semntica
Herramientas dan mayores opciones de
notacin detallada
Es ms fcil ver secuencia del flujo de
llamados (de arriba hacia abajo)
Pero est forzado a extender hacia la derecha
lo nuevos objetos

Sesin 1

73

Comparacin
Diagrama de comunicacin

Sesin 1

Es mucho ms eficiente en el uso de

espacio
Ms fcil de modificar
Ms difcil ver la secuencia de
llamadas
Menos opciones de notacin

74

Diagrama de
comunicacin
1: Coger libro

: Socio

: Libro

2: Solicitar prstamo
3: Verificar situacin socio

8: Autorizar prstamo

6: Situacin libro ok

: Ficha s
ocio

4: Situacin socio ok

: Encargado
7: Introducir prstamo

: Prsta
mo

5: Verificar situacin libro

: Ficha li
bro

Sesin 1

75

Running Example
Desarrolle un diagrama de
comunicacin que represente lo
mismo que este diagrama de
secuencia

Sesin 1

76

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.

Sesin 1

77

1: Coger libro

: Socio

: Libro

2: Solicitar prstamo
3: Verificar situacin socio

8: Autorizar prstamo

6: Situacin libro ok

4: Situacin socio ok

: Encargado
7: Introducir prstamo

5: Verificar situacin libro

: Ficha li
bro

: Ficha s
ocio

: Prsta
mo

Mensajes
Un mensaje desencadena una accin
en el objeto destinatario

Un mensaje se enva si han sido

enviados los mensajes de una lista
A.1, B.3 / 1:Mensaje
B
(sincronizacin):
A

 Mensajes
Un mensaje se enva iterada y
secuencialmente a un conjunto de
instancias:
1 *[i:=1..n] : Mensaje
B
A

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

 Mensajes
Un mensaje se enva de manera
condicionada:
[x>y] 1: Mensaje

B
A

 Mensajes
Un mensaje que devuelve un
resultado:
1: distancia:= mover(x,y)
B
A

Diagrama de Clases

Temario
El Modelo de Dominio
Posibles Elementos del Dominio
Buscando elementos del Dominio en el ejemplo
Una primera representacin grfica: usando
una herramienta UML
Revisando nuestro mono: Conceptos y
Atributos
Revisando nuestro mono: Conceptos en
Asociacin
2da Iteracin: profundizando relaciones
Corrijamos nuestro mono inicial

Sesin 1

85

El Modelo de Dominio
Ya conocemos una forma bsica de representar
y especificar requerimientos

En torno a las Interacciones usuario-sistema

En forma de Casos de Uso

Sin embargo, an no conocemos de qu se

habla en esas interacciones representadas

No sabemos el detalle de los objetos, lugares, transacciones,

etc. que intervienen en la interaccin usuario-sistema

El Modelo de Dominio nos permite identificar

estos elementos y representarlos grficamente

Identificando Conceptos o Elementos del Dominio

Identificando sus Relaciones
Identificando sus Atributos

Sesin 1

86

El Modelo de Dominio
Entonces ya llegamos a las Clases y los
Objetos?

Nones, estamos recin descubriendo lo conceptos

Algunos de ellos eventualmente se convertirn en Clases
de nuestro sistema, otros pasarn al triste olvido
Pero esa es una Decisin de Diseo, nuestra tarea ahora
es entender, hacer al Anlisis
Debemos identificar conceptos no guindonos en la
implementacin, 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

Sesin 1

87

Posibles Elementos del Dominio

[Larman]

Como primera regla, podemos fijarnos en los

Sustantivos dentro de una explicacin del problema

Pero este enfoque es muy mecnico; La ambigedad del lenguaje

puede llevarnos a identificar ms de un elemento de dominio que
representan lo mismo

Podemos intentar identificando:

Objetos fsicos o tangibles

Lugares
Transacciones
Roles de la Gente (Cliente, Vendedor)
Contenedores de Conceptos
Otros sistemas
Sustantivos Abstractos (Sed)
Organizaciones
Eventos (Emergencia)
Reglas/Polticas
Grabaciones/Logs

Sesin 1

88

Buscando elementos del Dominio en el

ejemplo
Revisemos nuestro ejemplo para identificar los
Conceptos o Elementos del Dominio

Basndonos en la lista anterior

Nombrndolos como sustantivos

Nombremos adems las relaciones que existen entre

ellos

Los nombres deben ser verbos en presente (realiza, paga,

etc.)

Representemos grficamente nuestros conceptos, con

cajas y lineas

Cliente

Sesin 1

compra Auto

89

Formato de la relacin

Una primera aproximacin

grfica
La lista anterior tiene varios de los conceptos del
dominio

Pero la representacin grfica es fundamental

Podemos entenderla como un mapa, que nos permite navegar
entre los conceptos entendiendo sus relaciones

Realizaremos una representacin grfica usando

UML

UML provee distintos diagramas para modelar Anlisis y Diseo

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 Anlisis, donde no existen decisiones de Diseo

Podemos ocupar cualquier herramienta que

soporte UML para hacer nuestro diagrama

Sesin 1

91

Revisando nuestro mono: Conceptos de

Asociacin
Cuando modelamos un dominio, descubrimos que
ciertos atributos slo se dan entre la relacin entre
dos conceptos
Veamos la siguiente alternativa para modelar
Persona
Sociedad
Sociedad y Socios:
es socio de

% de Participacin de Capital y Utilidad slo tienen

sentido como atributos de la relacin entre persona y
Sociedad
No todas las personas tiene % de participacin
El % de participacin de cada socio no es atributo de la
sociedad

Para representar estas situaciones, podemos ocupar

Conceptos originados en Socio
las relaciones
+participacionCapital
+participacionUtilidad

Persona

Sociedad
es socio de

Sesin 1

92

Ahora 2da
que identificamos
los profundizando
conceptos, estudiemos
Iteracin:
mejor sus relaciones

relaciones

Algunas de ellas parecen ambiguas

Necesitamos identificar cardinalidad en las relaciones
Es decir, cuntos de uno se relacionan con cuntos de otro
Por ejemplo:
Socio

tiene

Sociedad
1

+participacionCapital
+participacionUtilidad

Ejemplos de
Cardinalidades:
0..1
1..1
0..* 1..8 (nmero mximo
1..* especfico)
*
Sesin 1

93

Podemos
enriquecer
nuestro
modelo
2da
Iteracin:
profundizando
agregando otros tipos de relaciones:

relaciones

Identificando relaciones del tipo es-un: Super

Clases y Clases
Distinguiendo distintos tipos de asociacin del tipo
tiene entre los conceptos

Asociaciones Fuertes, o Composicin, en las cuales los

conceptos contenidos existen slo si existe el

concepto contenedor (por ejemplo, mano-dedos)
Asociaciones Dbiles, o Agregacin, en las cuales los
conceptos contenidos pueden existir si no existe el
contenedor (por ejemplo grupo de contactos-contacto)

Sesin 1

94

Sintaxis de un modelo de dominio

Tipos de relaciones

ES-UN
Conceptos comparten las mismas relaciones

(y comportamiento)
Nos lleva a relaciones de herencia

Composicin, o Asociaciones Fuertes,

Conceptos contenidos existen slo si existe

el concepto contenedor (por ejemplo,

mano-dedos)

Agregacin, o Asociaciones Dbiles,

Conceptos contenidos pueden existir si no

Sesin 1

existe el contenedor (por ejemplo grupo de

95
contactos-contacto)

2da Iteracin: profundizando

relaciones
ListaContactos 1
*
Contacto
+lista
+lista

+contactos

1
*+contacto

+grupos

GrupoContactos

1
+grupo

Sesin 1

96

Algunas Reflexiones
Cmo 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)

Sesin 1

97

Referencias
[LARMAN]

Larman, Craig. Applying UML and Patterns. An

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

Sesin 1

98

Clases: Notacin Grfica

Cada clase se representa en un
rectngulo con tres
compartimientos:

motocicleta
color
cilindrada
velocidad maxima

nombre de la clase
atributos de la clase
arrancar
acelerar
operaciones de la clase
frenar

Asociacin
La asociacin expresa una conexin
bidireccional entre objetos
Una asociacin es una abstraccin de
la relacin existente en los enlaces
entre los objetos
Univ. de Murcia:Universidad

Un enlace

Universidad

Antonio:Estudiante

Estudiante
Una asociacin

 Asociacin
Ejemplo:
marido
casado-con

Administra

0.. 1
mujer
jefe
0.. 1

0.. 1

Persona *
nombre
s. s.

empleado

trabaja-para
emplea-a

* Compaa
nombre
direccin

Asociacin Cualificada
Aerolnea

Tablero
Ajedrez

nro_billete

0..1

1
fila
columna

Viajero

Cuadro

Reduce la multiplicidad del rol opuesto al considerar el

valor
del cualificador

 Agregacin:
Caracterizacin

Las caracterizaciones 1, 3, 4 y 5 estn

incluidas en el concepto ms amplio de
multiplicidadObjeto
Agregado
Multiplicidad Mnima
0
nulos permitidos
> 0 nulos no
permitidos
Multiplicidad Mxima
1
univaluado
> 1 multivaluado

Objeto
Componente

Multiplicidad Mnima
0
flexible
> 0 estricta
Multiplicidad Mxima
1
disjunto
> 1 no disjunto

Ejemplos
coche

Persona

1
0..2
+Padre
1
motor

+Hijos

 Ejemplos
Agregacin

Cuenta

1 contiene

Polgono

3.. *

{ordenado}

Persona

or
1

Punto

Asociacin excluyente

Empresa

Usuario

Clase de asociacin

est-autorizado-en

Autorizacin
prioridad
privilegios
camb_privil

Estacin

... Jerarquas de
Generalizacin/Especializa
Abstracciones ms generales.
cin
vehiculo

vehiculo terrestre

camion

coche

vehiculo areo

avion

helicoptero

... Jerarquas de
Generalizacin/Especializa
cin
La especializacin es una tcnica
muy eficaz para la extensin y
reutilizacin coche
funcionando

estropeado

... Jerarquas de
Generalizacin/Especializa
cin
Un ejemplo de Especializacin
Esttica:

vehiculo areo

avion

helicoptero

... Jerarquas de
Generalizacin/Especializa
cin
Un ejemplo de Especializacin
Dinmica:
coche

funcionando

estropeado

... Jerarquas de
Generalizacin/Especializa
cin
Ejemplo: varias especializaciones a
partir de la misma superclase:

comercial

vehiculo areo

militar
avion

helicoptero

... Jerarquas de
Generalizacin/Especializa
cin
Ejemplo: especializaciones
dinmicas de la misma superclase:
de menos de 1000kms
coche

de ms de 1000 kms
funcionando

estropeado

... Jerarquas de
Generalizacin/Especializa
Un ejemplo combinado:
cin
vehiculo

comercial
vehiculo terrestre

vehiculo areo
esttica

esttica

camion

esttica
avion

de menos de 1000kms

militar

helicoptero

coche

dinmica
de ms de 1000 kms
dinmica

funcionando

estropeado

... Jerarquas de
Generalizacin/Especializa
cin
El siguiente es un ejemplo de
clasificacin no equilibrada:
vehiculo terrestre

camion

coche

Harley Davidson

... Jerarquas de
Generalizacin/Especializa
cin
Por regla general, es mejor limitar el

nmero de subclases a cada nivel a costa

de aumentar el nmero de objetos por clase
y reservar los atributos para cualificar
afinadamente los objetos

A veces, una especializacin dinmica tiene

un equivalente a travs de una
especializacin esttica y una asociacin ...

... Jerarquas de
Generalizacin/Especializa
cin
Ejemplo:
mariposa
oruga

mariposa

crislida

Aspecto

Lepidptero

estadio
1

oruga

crislida

Lepidptero

Diagrama de Estados

 Diagramas de Estados
alta

sin prstamos

Socio Biblioteca
Nmero : int
Nombre : char[50]
Nmero prstamos : int = 0
Alta()
Baja()
Prestar(CdigoLibro : int, Fecha : date)
Devolver(CdigoLibro : int, Fecha : date)

baja

prestar

nmero_prstamos = 0

devolver[ nmero_prstamos = 1 ]

nmero_prstamos > 0
con prstamos
prestar

devolver[ nmero_prstamos > 1 ]

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

en activo
perder empleo

jubilarse
jubilarse
jubilado

 Diagramas de Estados
La comunicacin bidireccional
puede representarse mediante
comunicacin asncrona. Por
ejemplo en un Diagrama de
1: una pregunta
Colaboracin:
un
objeto

otro
objeto

2: la respuesta

 Diagramas de Estados
Si la comunicacin es sncrona el
cliente debe esperar la respuesta.
Con lo cual en el cliente
a
tendramos:
plantear pregunta
espera respuesta

recibir respuesta

 Diagramas de Estados
Las guardas permiten condicionar
la transicin:
a

Evento[ condicin ]

Acciones
Podemos especificar la ejecucin
de una accin como consecuencia
de la transicin:
a

Evento[ condicin ] / accin

Dicha accin tambin

se considera
instantnea

 Acciones
Podemos especificar el envo de un
evento a otro objeto como
consecuencia de la transicin:
a

Evento( arg1, arg2 )[ condicin ] / ^otro_objeto.evento(arg2)

 Acciones
Se puede especificar el hacer una
accin como consecuencia de
entrar, salir o estar en un estado:
estado A
entry: accin por entrar
exit: accin por salir
do: accin mientras en estado

.. Acciones
Se puede especificar el hacer una
accin cuando ocurre en dicho
estado un evento que no conlleva
salir del estado:
estado A
on evento_activador( arg1 )[ condicin ]: accin por evento

Actividades
Las actividades son similares a las
acciones pero tienen duracin y se
ejecutan dentro de un estado del objeto

Las actividades pueden interrumpirse

en todo momento, cuando se
desencadena la operacin de salida del
estado

 Actividades
Cuando una actividad finaliza se
produce una transicin automtica
de salida del estado
a
do: actividad
[ condicin ]

[ not condicin ]

Generalizacin de Estados
Podemos reducir la complejidad de

estos diagramas usando la

generalizacin 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

Generalizacin de Estados
Ejemplo:
e1

e2
e2
c

Generalizacin de Estados
Quedara como:
a

e1

e2

 Generalizacin de
Estados
Las transiciones de entrada deben
ir hacia subestados especficos:
e1
a

b
e2

e0

 Generalizacin 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:
e1

b
e2

c
e0

 Generalizacin de
Estados
Ejemplo:

e1

e1

Historial
Por defecto, los autmatas no
tienen memoria

Es posible memorizar el ltimo

subestado visitado para recuperarlo
en una transicin entrante en el
superestado que lo engloba

 Historial
Ejemplo:

d2
in
h

out
d1

 Historial
Tambin es posible la memorizacin
para cualquiera de los subestados
anidados (aparece un * junto a la H)
a
d2
h

in
x
out

y
d1

H*

 Historial
Ejemplo:
Enjuague

Lavado

Cerrar
Abrir Puerta

Abrir Puerta
Cerrar

Espera

Secado

 Destruccin de Objeto
Ejemplo:
En vuelo

despegar
Crear(matricula)

En tierra

crash

aterrizar

 Transiciones
temporizadas
Ejemplo:
Si en 30 segundos no
se introduce el dinero
se termina la
actividad pasando a
anular la transaccin.
En cualquier caso se
cierra la ranura.

/ Abrir ranura
esperar dinero
entry: Mostrar mensaje
do: Esperar 30 segundos
exit: cerrar ranura
Depsito efectuado
b

anular transaccin

 Transiciones
temporizadas
Ejemplo v.2:

/ Abrir ranura
esperar dinero
entry: Mostrar mensaje
exit: cerrar ranura

Temporizador
(30 segundos)
anular transaccin

Depsito efectuado
b

Diagrama de Actividades

Ejemplos
Buscar Bebida

[no hay caf]

[hay caf
Poner caf en filtro

[no zumo]
[hay zumo]

Aadir agua al depsito Coger taza

Coger zumo

Poner filtro en mquina

Encender mquina
^cafetera.On
Caf en preparacin
indicador de fin
Servir caf

Beber

...Ejemplos (con bandas)

Pasajero

Solicitar pasaje

Vendedor

Airline

Verificar
existencia vuelo
Dar detalles vuelo
Informar alternativas
y precios

Seleccionar vuelo

Solicitar pago Reservar plazas

Confirmar
plaza reservada

Pagar pasaje
Emitir billete

Diagrama de
Componentes

 Diagramas de
Componentes

La representacin grfica es la
siguiente:
Especificacin

Package
specification

Cuerpo

Package
body

Genrico

Generic
package

Subsistemas
Los distintos componentes pueden
agruparse en paquetes segn un
criterio lgico y con vistas a simplificar
la implementacin

Son paquetes estereotipados en

<<subsistemas>>
<<subsistema>>
NewPackage4

Diagrama de Distribucin

Diagramas de Distribucin
Servidor Central

Control y Anlisis
Comment

Acceso a BD
Comment
Rutinas de Coneccion
Comment

Terminal de Consulta
Rutinas de Coneccion
Comment
Punto de Venta

Rutinas de Coneccion
Comment

Gestin de Cuentas

Interfaz de Terminal

Comment

Comment

Interfaz de Terminal
Comment

 Diagramas de
Distribucin

Ejemplo de conexin entre nodos:

<<Procesador>
Nodo

<<<<TCP/IP>>>>
conexin1

conexin7
<<RDSI>>
dispositiv
En Rational Rose podemos
o
distinguir entre el dispositivo

por estereotipado y el
dispositivo con su propio
smbolo

<<dispositivo>>
nodo2

Paquetes

Paquetes en UML
Los paquetes ofrecen un
mecanismo general para la
organizacin de los modelos
agrupando elementos de modelado

Se representan grficamente como:

Nombre de
paquete