1. Unidad 2.2:
UML (Lenguaje de
Modelamiento Unificado)
2. 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”
3. ... 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
4. … 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.
5. … Casos de Uso
Ejemplo:
Sistema
Caso de uso X
Actor A
Actor B
Caso de uso Y
6. … 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
7. … 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.
8. … 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.
9. … 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.
10. … 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.
11. … 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.
12. … 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
13. … Casos de Uso: Relaciones
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.
14. Casos de Uso: Relaciones
UML define cuatro tipos de relación en los
Diagramas de Casos de Uso:
Comunicación:
Actor
Caso de Uso
15. … Ejemplos
En el paquete tipos de venta:
Venta Normal
Venta en Rebajas
Cliente Vendedor
Venta en Oferta
16. … Casos de Uso: Relaciones
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.
17. … Casos de Uso: Relaciones
Extensión : el Caso de Uso origen
extiende el comportamiento del Caso
de Uso destino
<<extend>>
Caso de uso destino
Caso de uso origen
19. … Casos de Uso: Relaciones
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.
20. … Casos de Uso: Relaciones
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>>
21. … Ejemplos
Reintegro cuenta corriente <<include>>
<<uses>>
Cliente Validar operación
<<uses>>
<<include>>
Reintegro cuenta crédito
22. … Casos de Uso: Relaciones
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.
23. … 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 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>>
24. … Casos de Uso: Relaciones
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.
25. … Casos de Uso: Relaciones
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
26. … Casos de Uso: Relaciones
Ejemplo:
<<extend>>
<<extends>>
Transferencia por Internet
Giro por Internet
Cliente
<<includes>>
<<include>> Transferencia
Giro
Identificación
27. … Casos de Uso
El segundo elemento, narración del caso de uso,
describe los detalles de cada evento.
28. 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>
29. … 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
30. 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:
32. 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
33. 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.
34. 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.
35. Diagrama de secuencia
Asignación de nombres a los eventos:
Para una mayor claridad deben comenzar
con un verbo en infinitivo.
36. 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
38. 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
39. 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
40. 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
41. 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
42. 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
43. 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
44. 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
45. 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
46. 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
48. 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
50. … Diagramas de Secuencia
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
51. … Diagramas de Secuencia
Un objeto puede enviarse a sí mismo un
mensaje:
a
mensaje reflexivo
52. … 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
53. … Diagrama de Secuencia
En el caso asíncrono el retorno, si existe,
se debe representar:
a : aa b : aa
54. Tipos de Control
El Diagrama de Secuencia refleja de
manera indirecta las opciones de control
Un control centralizado tiene una forma
como esta:
55. … Tipos de control
Un control descentralizado tiene una forma
como esta:
56. … 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
57. … Estructuras de control
La iteración puede expresarse también
como parte del mensaje:
*[condición] Mensaje
58. … Estructuras de control
Las bifurcaciones condicionales pueden
representarse de esta forma:
If condición
else
end if
60. 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
61. 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
62. 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
64. 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
65. 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
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 66
67. Iteración sobre una colección
Describen iteraciones sobre todos los
miembros de una colección
Sesión 1 67
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 68
71. 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
72. 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
73. Comparación
Uno elige cuál quiere usar
Diagrama 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 73
Sesión 1
74. 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
75. 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
76. Running Example
Desarrolle un diagrama de
comunicación que represente lo mismo
que este diagrama de secuencia
76
Sesión 1
77. 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
78. 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
79. 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
80. … Mensajes
Un mensaje se envía iterada y
secuencialmente a un conjunto de
instancias:
1 *[i:=1..n] : Mensaje
B
A
81. … Mensajes
Un mensaje se envía iterada y
concurrentemente a un conjunto de
instancias:
1 *| | [i:=1..n] : Mensaje
B
A
82. … Mensajes
Un mensaje se envía de manera
condicionada:
[x>y] 1: Mensaje
B
A
83. … Mensajes
Un mensaje que devuelve un resultado:
1: distancia:= mover(x,y)
B
A
85. 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
86. 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
86
Sesión 1
87. 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
87
Sesión 1
88. 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
89. 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
91. 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
92. 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
93. 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:
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
94. 2da Iteración: profundizando relaciones
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
95. 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
96. 2da Iteración: profundizando relaciones
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
97. 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
98. Referencias
[LARMAN]
Larman, Craig. Applying UML and Patterns. An
Introduction to Object Oriented Analysis and Design.
Prentice Hall, 1998.
98
Sesión 1
99. 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
100. 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
101. … 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
102. 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
103. … 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
104. Ejemplos
coche Persona +Hijos
1 *
0..2
+Padre
1
motor
105. … 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
112. ... Jerarquías de
Generalización/Especialización
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
funcionando estropeado
114. ... Jerarquías de
Generalización/Especialización
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 ...
117. … 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 ]
118. … Diagramas de Estados
Ejemplo de un Diagrama de Estados
para la clase persona:
contratar
en el paro en activo
perder empleo
jubilarse
jubilarse
jubilado
119. … Diagramas de Estados
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
120. … Diagramas de Estados
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
121. … Diagramas de Estados
Las guardas permiten condicionar la
transición:
Evento[ condición ]
a b
122. 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
123. … 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
124. … 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
125. .. 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
126. 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
127. … 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
128. 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
131. … Generalización de Estados
Las transiciones de entrada deben ir
hacia subestados específicos:
e1
a b
e2
e0
c
132. … 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:
e1
a b
c
e2
e0
134. 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
138. … Destrucción de Objeto
Ejemplo:
crash
En vuelo
despegar aterrizar
Crear(matricula)
En tierra
139. … 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
145. … Diagramas de Componentes
La representación gráfica es la
siguiente:
Especificación Cuerpo Genérico
Package Package Generic
specification body package
146. 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
148. 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
Rutinas de Coneccion
Comment Comment
Punto de Venta
Rutinas de Coneccion
Comment
Gestión de Cuentas Interfaz de Terminal
Comment Comment
149. … 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
151. 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