Unidad 2.2:
UML (Lenguaje de Modelamiento
Unificado)
Diagramas de UML
Use CaseDiagramsUse Case
DiagramsDiagramas de Casos de Uso
ScenarioDiagramsScenario
DiagramsDiagramas deColaboración
StateDiagramsState
DiagramsDiagramas deComponentes
ComponentDiagramsComponent
DiagramsDiagramas deDistribución
StateDiagramsState
DiagramsDiagramas de Objetos
ScenarioDiagramsScenario
DiagramsDiagramas deEstados
Use CaseDiagramsUse Case
DiagramsDiagramas deSecuencia
StateDiagramsState
DiagramsDiagramas deClases
Diagramas deActividad
Modelo
“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”
... Diagramas de UML
Diagrama de Casos de Uso Diagrama de Clase (incluyendo Diagrama de Objetos) Diagramas de Comportamiento
Diagrama de Estados Diagrama de Actividad Diagramas de Interacción
Diagrama de Secuencia Diagrama de Colaboración
Diagramas de implementación Diagrama de Componentes Diagrama de Despliegue
… Casos de Uso
Existen dos elementos primordiales cuando se realiza la modelación de C.U. Diagramas de casos de uso: ilustra
gráficamente el sistema como una colección de casos, actores y sus relaciones.
Comunica a un alto nivel el alcance de los eventos de negocio que el sistema debe procesar.
El diagrama de casos de uso es muy sencillo, pero con éste comienza un importante proceso llamado descomposición funcional.
… Casos de Uso
Ejemplo:Sistema
Actor A
Caso de uso X
Actor B
Caso de uso Y
… Casos de Uso
Un C.U representa un objetivo individual del sistema y describe una secuencia de actividades y de interacciones del usuario para alcanzar el objetivo.Un C.U por sí solo no se considera como requerimiento funcional, pero la historia (el escenario) que relata el C.U consiste en uno o más requerimientos.Inicialmente los CU se definen durante la etapa de los requerimientos del ciclo de vida y se refinarán adicionalmente a lo largo de éste
… Casos de Uso: ActoresLos C.U se inician o son generados por los usuarios externos llamados Actores.Un actor inicia la actividad del sistema, un caso de uso, con el propósito de terminar alguna tarea de negocios que produzca algo con valor apreciable.Un actor representa un papel desempeñado por un usuario que interactúa con el sistema y no significa que retrate a una persona o puesto de trabajo. De hecho un actor no tiene porqué ser humano, puede ser una organización, otro sistema de información o un dispositivo externo tal como un sensor de calor.
… Casos de Uso: Actores
Existen principalmente 4 tipos de actores: Actor primario de negocios: El interesado
que se beneficia principalmente de la ejecución de un CU al recibir algo d valor medible u observable. Este actor puede o no iniciar un evento de negocios.
Ej: En el evento de negocio de un empleado que recibe el cheque como pago (algo con valor medible) del sistema de nómina cada viernes, el empleado no inicia el evento pero es el receptor primario de algo de valor.
… Casos de Uso: Actores
Actor primario del sistema: El involucrado que tiene una interfaz directa con el sistema para iniciar u ocasionar el evento de negocios o de sistema.Esto actores pueden interactuar con los actores primarios de negocios con el propósito de usar el sistema real. Ellos facilitan el evento a través del uso directo del sistema para beneficio del actor primario de negocios.Ej : Un dependiente de una tienda de abarrotes que selecciona los artículos para el cliente que compra abarrotes ó una operadora que proporciona información del directorio a un cliente.
… Casos de Uso : Actores
Actor externo servidor: El involucrado que responde a una solicitud desde el caso de uso.
Actor externo receptor: El involucrado que no es el actor primario pero que recibe algo de valor medible u observable (salida) proveniente del caso de uso.Ej: Un almacén recibe una orden de embalaje para preparar un flete después de que un cliente ha colocado una orden.
… Casos de Uso : Actores
En muchos sistemas de información hay eventos de negocios ocasionados por el calendario o la hora del reloj. Ej: El sistema de facturación de una compañía de
tarjetas de crédito genera automáticamente sus estados de cuenta en el quinto día de cada mes. (fecha de facturación).
Un banco concilia sus transacciones con cheques todos los días a las 5 pm.
Estos eventos son ejemplo de eventos temporales, ¿Quién sería el actor?, el actor de un evento temporal es el tiempo.
… Casos de Uso: Relaciones
Una relación: se ilustra como una línea entre dos símbolos en el diagrama de casos de uso. El significado de las relaciones puede diferir dependiendo de cómo se dibujen las líneas y que tipo de símbolos conectan
… 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.
Casos de Uso: Relaciones
UML define cuatro tipos de relación en los Diagramas de Casos de Uso:
Comunicación:
Caso de Uso
Actor
… Ejemplos
Cliente
Venta Normal
Venta en RebajasVendedor
Venta en Oferta
En el paquete tipos de venta:
… 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.
… Casos de Uso: Relaciones
Extensión : el Caso de Uso origen extiende el comportamiento del Caso de Uso destino
Caso de uso origen
Caso de uso destino
<<extend>>
… Ejemplos
Solicitar nueva tarjeta
Socio Encargado
Realizar préstamo
tarjeta caducada
<<extends>><<extend>>
… 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.
… 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
En UML 1.3 se estereotipa como <<include>> lo que antes llevaba el estereotipo <<uses>>
Caso de uso origen
Caso de uso destino
<<include>>
… Ejemplos
Validar operación
Reintegro cuenta corriente
Cliente
Reintegro cuenta crédito
<<uses>>
<<uses>><<include>>
<<include>>
… 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.
… 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>>
… 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.
… 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 origen
Caso de uso destino
… Casos de Uso: Relaciones
Ejemplo:
Identificación
Giro por Internet
Cliente
Giro
<<extends>>
<<includes>>
<<extend>>
<<include>>
Transferencia por Internet
Transferencia
… Casos de Uso
El segundo elemento, narración del caso de uso, describe los detalles de cada evento.
RF- <id del requisito> <nombre del requisito funcional> Versión <numero de versión y fecha> Autores <autor> Fuentes <fuente de la versión actual> Objetivos asociados <nombre del objetivo> Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de activación> , abstracto durante la realización de los casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso> Paso Acción
1 {El <actor> , El sistema} <acción realizada por el actor o sistema>, se realiza el caso de uso < caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>
3 4 5 6
Secuencia Normal
n Postcondición <postcondición del caso de uso>
Paso Acción 1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o sistema>>, se realiza el caso de uso < caso de uso RF-x>, a continuación este caso de uso {continua, aborta}
2
Excepciones
3 Rendimiento Paso Cota de tiempo 1 n segundos 2 n segundos Frecuencia esperada <nº de veces> veces / <unidad de tiempo> Importancia {sin importancia, importante, vital} Urgencia {puede esperar, hay presión, inmediatamente} Comentarios <comentarios adicionales>
… Casos de Uso
Proceso de la modelación de casos de Usos para los requerimientos: Paso 1: Identificar a los actores del negocio Paso 2: Identificar los casos de uso para los
requerimientos de negocios. Paso 3: Construir el diagrama del modelo de
casos de uso Paso 4: Narraciones de los CU para los
requerimientos de documentos para los negocios
Caso de uso
Programar Procedimiento.
ActoresPropósito
TipoResumen
Referencia cruzadas
Sección Principal.Acción de los actores. Respuesta del sistema.
Flujo normal de eventos.
1. 2.3. 4.5..
6.7. 8.
9. 1011
Flujos alternativos.Línea 3:Línea 7:Línea 8:
Diagrama de Secuencia
Diagrama de Secuencia
Antes del diseño (cómo funcionará el software) se debe investigar y definir su comportamiento como “caja negra”El comportamiento del sistema es una descripción de lo que hace, …sin explicar la manera en que lo hace
Parte de esa descripción es un diagrama de secuencia del sistema
Los diagramas de secuencia
Es un artefacto creado de manera rápida y fácil que muestra los eventos de entrada y salida relacionados con el sistema que se está estudiando.UML incluye la notación de los diagramas de secuencia para representar los eventos que parten de los actores externos hacia el sistema.
Diagrama de secuencia
El comportamiento del sistema es una descripción de qué hace el sistema, sin explicar cómo lo hace.Def: Es un dibujo que muestra para un escenario específico de un caso de uso, los eventos que generan los actores externos, el orden y los eventos entre los sistemas. Todos los sistemas se tratan como cajas negras.Los diagramas destacan los eventos que cruzan los límites del sistema desde los actores a los sistemas.
Diagrama de secuencia
Asignación de nombres a los eventos: Para una mayor claridad deben
comenzar con un verbo en infinitivo.
Sesión 136
Relación caso de uso/DSS
Caso de uso (CU) describe cómo actores externos interactúan con el sistema a construirDurante la interacción, el actor genera eventos del sistema para un sistema, usualmente esto requiere que alguna
operación del sistema maneje el eventoDSS hace concretos y explícitos los eventos que son implícitos en el CUVeamos un DSS del curso normal de “Modificar Capital”
Sesión 137
RunningExample – DSS Modificar Capital
Curso normal de los eventos
Sesión 138
Eventos y operacionesEvento del sistema
hecho externo de entrada que un actor produce en un sistema.
Operación del sistema acción que el sistema ejecuta en respuesta a un evento del
sistema. ej., un contribuyente genera un evento “modificarCapital”, el cual
causa la ejecución de la operación “modificarCapital”.
El nombre del evento y de la operación pueden ser (y generalmente son) idénticos.
La diferencia es que el evento “X” es el estímulo y la operación “X” es la repuesta.
Lo mismo sucede con los mensajes y los métodos en Orientación a Objetos y UML.
Sesión 139
DSS
Diagrama que muestra los eventos generados por actores externos, … su orden …y los eventos inter-sistemas
…para un escenario particular de un CUTodos los sistemas son tratados como cajas negrasFoco en los eventos que cruzan la frontera entre actores y sistemas
Sesión 140
DSSLos casos de uso del sistema (escenarios y eventos) son input para su creaciónEl tiempo se describe (avanza) hacia abajoEl orden de los eventos debe seguir el mismo orden del escenario que representanLos eventos del sistema pueden incluir parámetrosUsa diagrama de secuencia de UMLSerán input para contratos de operación y diseño de objetos
Sesión 141
DSS de “Modificar Capital”
Actor externo Sistema como caja negra
Valor(es) de retorno asociado con el mensaje previo tiempo
Mensaje con parámetros
Sesión 142
Elaborando un DSS
Para elaborar un DSS para un escenario, y: Trace una línea que represente el sistema como una
caja negra Identifique los actores que operan directamente
sobre el sistema Trace una línea para cada uno de ellos.
A partir del escenario identifique los eventos (“externos”) del sistema que son generados por los actores Muéstrelos gráficamente en el diagrama.
A la izquierda del diagrama puede incluir o no el texto del caso de uso.
Sesión 1 43
Modificar CapitalCurso normal de los eventos
Acción del actor Respuesta del Sistema
1. El contribuyente solicita modificar capital
2. El sistema muestra capital inicial, enterado y por enterar actuales
3. El contribuyente ingresa:
nuevo capital inicial, nuevo capital enterado, nuevo capital por enterar y la fecha asociada
número de número de repertorio, nombre de notaria, fecha de escritura
4. El contribuyente confirma los cambios al capital
5. El sistema almacena cambios al capital
Sesión 144
Elaborando un DSSConsideramos ahora el caso de uso “Modificar Capital” a fin de identificar los eventos del sistema Primero debemos determinar los actores que
interactúan directamente con el sistema de software Usuarios
OJO! Sólo quien actúa directamente con el sistema Ej. En la venta de un producto: el cliente interactúa con el
cajero, pero no directamente con el sistema de ventas; => cajero es generador de eventos, cliente no
Ej. Contribuyente/Representante Electrónico Otros sistemas
Colaboraciones con sistemas externos (de pago, etc) Ej. No hay (aún :P)
Sesión 145
Elaborando un DSS
Los eventos de un sistema (y sus operaciones asociadas) deben expresarse en el nivel de propósito …y no en el nivel del medio de entrada o de elementos de la interfaz
Ej. “modificarCapital” es preferible a “ApretarBotonAceptar” porque capta mejor el propósito de la operación
Mantiene un carácter abstracto y no se pronuncia sobre qué interfaz sirve para capturar el evento del sistema (decisiones de diseño)Es más claro si el nombre de un evento del sistema comienza con un verbo
ej. agregar, introducir, terminar, efectuar esto recalca que los eventos están orientados a comandos
Sesión 146
DSSGuideline: Haz un DSS para el escenario principal de cada
caso de uso, y para escenarios alternativos frecuentes o complejos
¿Por qué son importantes? Investigan y definen el comportamiento del
sistema como una caja negra Describen qué es lo que sistema hace, sin
explicar cómo lo hace Junto con CU y contratos de operación del
sistema
Sesión 147
RunningExample – DSS Modificar Capital
Curso normal de los eventos
Diagramas de Secuencia
: Socio : Encargado : Libro : Ficha libro : Ficha socio : Préstamo
Coger libro
Solicitar préstamo
Verificar situación socio
Situación socio ok
Verificar situación libro
Situación libro ok
Introducir préstamo
Autorizar préstamo
… Diagramas de Secuencia
CBA
m1
m2
m3
m4
m5
… Diagramas de Secuencia
EjemploQuien llama Línea telefónica Llamado
descuelga
tono
marcar
indicación de llamada timbre
descuelga
diga?
Las bandas rectangulares representan los periodos de actividad de los objetos
… Diagramas de Secuencia Un objeto puede enviarse a sí mismo
un mensaje:a
mensaje reflexivo
… Diagramas de Secuencia Normalmente no es necesario indicar
el retorno del control:
a b
El retorno se considera implícito cuando el envío es síncrono
… Diagrama de Secuencia
En el caso asíncrono el retorno, si existe, se debe representar:
a : aa b : aa
Tipos de Control El Diagrama de Secuencia refleja de
manera indirecta las opciones de control
Un control centralizado tiene una forma como esta:
… Tipos de control
Un control descentralizado tiene una forma como esta:
… Estructuras de control
Podemos representar iteraciones en el envío de mensajes, p.e., mientras se cumpla una condición:
While XLoop
end Loop
… Estructuras de control
La iteración puede expresarse también como parte del mensaje:
*[condición] Mensaje
… Estructuras de control
Las bifurcaciones condicionales pueden representarse de esta forma:
If condición
else
end if
Diagrama de Colaboración
Sesión 160
MensajeMensaje entre objetos que es representado por una expresión de mensaje y una pequeña flecha indicando la dirección del mensajeMuchos mensajes pueden navegar a través de cada linkUn nº de secuencia es agregado para mostrar el orden secuencial de los mensaje en el flujo de control actualPuede haber automensajes también this
Sesión 1 61
Creación de instanciasCualquier mensaje puede ser usado para crear instanciasLa convención es llamar a estos métodos create, o usar un estereotipo de tipo <<create>>Puede incluir argumentos
Sesión 162
LinkCamino de conexión entre dos objetos Indica que alguna forma de navegación o
visibilidad entre los objetos es posible Es una instancia de asociación
A lo largo de estos links pueden navegar los mensajesPuede haber múltiples mensajes en ambas direcciones en un mismo link (carretera de doble vía)
Sesión 163
Secuencia de mensajes numerados
Sesión 1 64
Mensajes condicionalesSiguiendo al número de secuencia se incluye una cláusula condicional en paréntesis cuadrados El mensaje es enviado sólo si la condición es cierta
Sesión 165
Caminos condicionales exclusivos
Expresiones de secuencia se modifican con una letra de camino condicional La primera letra usada es a por
convención
Sesión 1 66
Loops
Expresiones que describen un ciclo se identifican con un asterisco y una expresión condicional Mientras la expresión condicional sea
verdadera el ciclo continúa
Sesión 1 67
Iteración sobre una colección
Describen iteraciones sobre todos los miembros de una colección
Sesión 1 68
Mensajes a métodos estáticos
Para llamar a métodos static se usa el estereotipo <<metaclass>> para representar la clase que contiene tal método La clase Calendar es una instancia de metaclass
Sesión 1 69
Mensajes polimórficos
Mensajes a clases abstractas
www.dsic.upv.es/~uml
Reflexión sobre Diagramas de Interacción
Sesión 171
Problemas típicos
Problemas típicos de su uso:• En los proyectos de desarrollo, no se
aprecia el valor de llevar a cabo el diseño de objetos mediante estos diagramas
• Por lo anterior, se diseñan de manera vaga, e imprecisa
Sesión 172
DSS
UML no define nada que se llame diagrama de secuencia “del sistema”, sino que simplemente diagrama de secuenciaEl apellido señalado corresponde a un uso específico del diagrama de secuencia, en que precisamente el sistema es visto como caja negra.
Sesión 173
ComparaciónUno elige cuál quiere usarDiagrama de secuencia Ha habido más esfuerzo en su notación y
semántica Herramientas dan mayores opciones de
notación detallada Es más fácil ver secuencia del flujo de
llamados (de arriba hacia abajo) Pero está forzado a extender hacia la
derecha lo nuevos objetos
Sesión 174
Comparación
Diagrama de comunicación Es mucho más eficiente en el uso de
espacio Más fácil de modificar Más difícil ver la secuencia de
llamadas Menos opciones de notación
Sesión 175
: Socio
: Encargado
: Libro
: Ficha libro
: Ficha socio
: Préstamo
1: Coger libro
2: Solicitar préstamo
8: Autorizar préstamo
3: Verificar situación socio
4: Situación socio ok
5: Verificar situación libro
6: Situación libro ok
7: Introducir préstamo
Diagrama de comunicación
Sesión 176
Running Example
Desarrolle un diagrama de comunicación que represente lo mismo que este diagrama de secuencia
Sesión 177
Referencias[LARMAN] Larman, Craig. Applying UML and Patterns. An Introduction to
Object Oriented Analysis and Design. Prentice Hall, 1998.
[OO Head First] Brett D. McLaughlin, Gary Pollice, Dave West. Head First Object-Oriented Analysis and
Design: A Brain Friendly Guide to OOA&D. O'Reilly Media, Inc., 2006.
: Socio
: Encargado
: Libro
: Ficha libro
: Ficha socio
: Préstamo
1: Coger libro
2: Solicitar préstamo
8: Autorizar préstamo
3: Verificar situación socio
4: Situación socio ok
5: Verificar situación libro
6: Situación libro ok
7: Introducir préstamo
Mensajes
Un mensaje desencadena una acción en el objeto destinatario
Un mensaje se envía si han sido enviados los mensajes de una lista (sincronización):
A
BA.1, B.3 / 1:Mensaje
… Mensajes
Un mensaje se envía iterada y secuencialmente a un conjunto de instancias:
A
B1 *[i:=1..n] : Mensaje
… Mensajes
Un mensaje se envía iterada y concurrentemente a un conjunto de instancias:
A
B1 *| | [i:=1..n] : Mensaje
… Mensajes
Un mensaje se envía de manera condicionada:
A
B
[x>y] 1: Mensaje
… Mensajes
Un mensaje que devuelve un resultado:
A
B1: distancia:= mover(x,y)
Diagrama de Clases
Sesión 185
Temario
El Modelo de DominioPosibles Elementos del DominioBuscando elementos del Dominio en el ejemploUna primera representación gráfica: usando una herramienta UMLRevisando nuestro mono: Conceptos y AtributosRevisando nuestro mono: Conceptos en Asociación2da Iteración: profundizando relacionesCorrijamos nuestro mono inicial
Sesión 186
El Modelo de Dominio
Ya conocemos una forma básica de representar y especificar requerimientos
En torno a las Interacciones usuario-sistema En forma de Casos de Uso
Sin embargo, aún no conocemos “de qué se habla” en esas interacciones representadas
No sabemos el detalle de los objetos, lugares, transacciones, etc. que intervienen en la interacción usuario-sistema
El Modelo de Dominio nos permite identificar estos elementos y representarlos gráficamente
Identificando Conceptos o Elementos del Dominio Identificando sus Relaciones Identificando sus Atributos
Sesión 187
El Modelo de Dominio
¿Entonces ya llegamos a las Clases y los Objetos?
Nones, estamos recién descubriendo lo conceptos Algunos de ellos eventualmente se convertirán en Clases
de nuestro sistema, otros pasarán al triste olvido Pero esa es una Decisión de Diseño, nuestra tarea
ahora es entender, hacer al Análisis Debemos identificar conceptos no guiándonos en la
implementación, sino en el contexto del problema a resolver (Dominio)
Al igual que los casos de uso, el Dominio representado debe ser validado por el Cliente
Una pista: si un Cliente no puede entender algunos de los Elementos del Dominio que hemos identificado, probablemente estos No Sean Elementos del Dominio
Sesión 188
Posibles Elementos del Dominio [Larman]
Como primera regla, podemos fijarnos en los Sustantivos dentro de una explicación del problema
Pero este enfoque es muy mecánico; La ambigüedad del lenguaje puede llevarnos a identificar más de un elemento de dominio que representan lo mismo
Podemos intentar identificando: Objetos físicos o tangibles Lugares Transacciones Roles de la Gente (Cliente, Vendedor) Contenedores de Conceptos Otros sistemas Sustantivos Abstractos (“Sed”) Organizaciones Eventos (Emergencia) Reglas/Políticas Grabaciones/Logs
Sesión 189
Buscando elementos del Dominio en el ejemplo
Revisemos nuestro ejemplo para identificar los Conceptos o Elementos del Dominio
Basándonos en la lista anterior Nombrándolos como sustantivos
Nombremos además las relaciones que existen entre ellos
Los nombres deben ser verbos en presente (“realiza”, “paga”, etc.)
Representemos gráficamente nuestros conceptos, con “cajas y lineas”
Cliente Autocompra
Formato de la relación
Sesión 191
Una primera aproximación gráfica
La lista anterior tiene varios de los conceptos del dominio
Pero la representación gráfica es fundamental Podemos entenderla como un mapa, que nos permite navegar
entre los conceptos entendiendo sus relaciones
Realizaremos una representación gráfica usando UML
UML provee distintos diagramas para modelar Análisis y Diseño
Pero ninguno en particular llamado “Modelo de Dominio” Usaremos el Diagrama de Clases de UML para dibujar nuestro
primer diagrama de Dominio Se puede decir que el Modelo de Dominio es un Diagrama de
Clases de Análisis, donde no existen decisiones de Diseño
Podemos ocupar cualquier herramienta que soporte UML para hacer nuestro diagrama
Sesión 192
Revisando nuestro mono: Conceptos de Asociación
• Cuando modelamos un dominio, descubrimos que ciertos atributos sólo se dan entre la relación entre dos conceptos
• Veamos la siguiente alternativa para modelar Sociedad y Socios: SociedadPersona
es socio de
• % de Participación de Capital y Utilidad sólo tienen sentido como atributos de la relación entre persona y Sociedad– No todas las personas tiene % de participación– El % de participación de cada socio no es atributo de la
sociedad• Para representar estas situaciones, podemos ocupar
Conceptos originados en las relaciones
SociedadPersona
es socio de
Socio
+participacionCapital+participacionUtilidad
Sesión 193
2da Iteración: profundizando relaciones
Ahora que identificamos los conceptos, estudiemos mejor sus relaciones
Algunas de ellas parecen ambiguas Necesitamos identificar cardinalidad en las relaciones Es decir, cuántos de uno se relacionan con cuántos de
otro Por ejemplo:
SociedadSocio
+participacionCapital+participacionUtilidad
tiene
*1
• Ejemplos de Cardinalidades:– 0..1– 1..1– 0..*– 1..*– *
– 1..8 (número máximo específico)
Sesión 194
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)
Tipos de relaciones “ES-UN”
Conceptos comparten las mismas relaciones (y comportamiento)
Nos lleva a relaciones de herencia Composición, o Asociaciones Fuertes,
Conceptos “contenidos” existen sólo si existe el concepto “contenedor” (por ejemplo, mano-dedos)
Agregación, o Asociaciones Débiles, Conceptos “contenidos” pueden existir si no
existe el contenedor (por ejemplo grupo de contactos-contacto)Sesión 1 95
Sintaxis de un modelo de dominio
Sesión 196
2da Iteración: profundizando relaciones
La notación de UML permite expresar estas asociaciones:
Si la Lista de Contactos es eliminada, se perderán todos los contactos y los gruposSi se elimina un Grupo de Contactos, los Contactos siguen existiendo en la Lista de ContactosTambién es conveniente identificar los roles de cada concepto en la relación
ListaContactos Contacto
GrupoContactos
+lista +contactos
1 *
+grupo
+contacto
1
*+lista
+grupos
1
*
Sesión 197
Algunas Reflexiones¿Cómo asegurarme que he modelado todo lo que corresponde?
“Todo lo que Corresponde” = Todos los Requerimientos Identificados
Podemos generar una Matriz de Trazabilidad Filas: Casos de Uso Columnas: Requerimientos Marcamos en la matriz qué casos de uso resuelven qué
requerimientos Todos los Requerimientos deben estar resueltos en a lo
menos un Caso de Uso (estamos haciendo todo lo solicitado)
Todos los Casos de Uso deben resolver por lo menos un Requerimiento (no estamos inventando funcionalidades)
Sesión 198
Referencias
[LARMAN] Larman, Craig. Applying UML and Patterns. An
Introduction to Object Oriented Analysis and Design. Prentice Hall, 1998.
Clases: Notación Gráfica
Cada clase se representa en un rectángulo con tres compartimientos:
nombre de la clase atributos de la clase operaciones de la clase
motocicleta
colorcilindradavelocidad maxima
arrancaracelerarfrenar
Asociación
La asociación expresa una conexión bidireccional entre objetos
Una asociación es una abstracción de la relación existente en los enlaces entre los objetos
Universidad Estudiante
Univ. de Murcia:Universidad Antonio:Estudiante
Una asociación
Un enlace
Ejemplo:
… Asociación
Persona Compañíatrabaja-para
nombres. s.
nombredirección
jefe
Administraempleado
* *emplea-a
0.. 10.. 1
0.. 1
*
marido
casado-con
mujer
Asociación Cualificada
Aerolínea Viajeronro_billete * 0..1
TableroAjedrez
filacolumna
1 1 Cuadro
Reduce la multiplicidad del rol opuesto al considerar el valor
del cualificador
Las caracterizaciones 1, 3, 4 y 5 están incluidas en el concepto más amplio de multiplicidad Objeto
Agregado
Objeto Componente
Multiplicidad Mínima
0 flexible
> 0 estricta
Multiplicidad Máxima
1 disjunto
> 1 no disjunto
Multiplicidad Mínima
0 nulos permitidos
> 0 nulos no permitidos
Multiplicidad Máxima
1 univaluado
> 1 multivaluado
… Agregación: Caracterización
Ejemplos
motor
coche
1
1
1
1
Persona
0..2*
+Padre
0..2
+Hijos
*
… Ejemplos
CuentaPersona
1
*
orAsociación excluyente
Empresa
*
*
Usuario Estaciónestá-autorizado-en
prioridadprivilegios
camb_privil
Autorización
* *
Clase de asociación
Polígono Puntocontiene 3.. *1
{ordenado}Agregación
Abstracciones más generales.
vehiculo
vehiculo terrestre vehiculo aéreo
camion coche avion helicoptero
... Jerarquías de Generalización/Especialización
La especialización es una técnica muy eficaz para la extensión y reutilización coche
funcionando estropeado
... Jerarquías de Generalización/Especialización
Un ejemplo de Especialización Estática: vehiculo aéreo
avion helicoptero
... Jerarquías de Generalización/Especialización
Un ejemplo de Especialización Dinámica:
coche
funcionando estropeado
... Jerarquías de Generalización/Especialización
Ejemplo: varias especializaciones a partir de la misma superclase:
vehiculo aéreo
avion helicoptero
comercial
militar
... Jerarquías de Generalización/Especialización
Ejemplo: especializaciones dinámicas de la misma superclase:
coche
funcionando estropeado
de menos de 1000kms
de más de 1000 kms
... Jerarquías de Generalización/Especialización
Un ejemplo combinado:vehiculo
vehiculo terrestre
camion
coche
funcionando estropeado
vehiculo aéreo
avion helicoptero
comercial
militar
de menos de 1000kms
de más de 1000 kms
estática
estáticaestática
dinámica
dinámica
... Jerarquías de Generalización/Especialización
El siguiente es un ejemplo de clasificación no equilibrada:
vehiculo terrestre
camion coche Harley Davidson
... 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 ...
... Jerarquías de Generalización/Especialización
Ejemplo: mariposa
oruga crisálida Lepidóptero
oruga crisálida Lepidóptero
mariposa estadio
1
Aspecto
1
... Jerarquías de Generalización/Especialización
Diagrama de Estados
Socio BibliotecaNúmero : intNombre : char[50]Número préstamos : int = 0
Alta()Baja()Prestar(CódigoLibro : int, Fecha : date)Devolver(CódigoLibro : int, Fecha : date)
con préstamos
sin préstamos
alta baja
prestar devolver[ número_préstamos = 1 ]
prestar
devolver[ número_préstamos > 1 ]
número_préstamos = 0
número_préstamos > 0
… Diagramas de Estados
Ejemplo de un Diagrama de Estados para la clase persona:
en el paro en activo
jubilado
contratar
perder empleo
jubilarsejubilarse
… Diagramas de Estados
La comunicación bidireccional puede representarse mediante comunicación asíncrona. Por ejemplo en un Diagrama de Colaboración:
un objeto
otro objeto
1: una pregunta
2: la respuesta
… 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
espera respuesta c
plantear pregunta
recibir respuesta
… Diagramas de Estados
Las guardas permiten condicionar la transición:
a bEvento[ condición ]
… Diagramas de Estados
Acciones
Podemos especificar la ejecución de una acción como consecuencia de la transición:
a bEvento[ condición ] / acción
Dicha acción también se considera instantánea
Podemos especificar el envío de un evento a otro objeto como consecuencia de la transición:
a
b
Evento( arg1, arg2 )[ condición ] / ^otro_objeto.evento(arg2)
… Acciones
Se puede especificar el hacer una acción como consecuencia de entrar, salir o estar en un estado:
estado A
entry: acción por entrarexit: acción por salirdo: acción mientras en estado
… Acciones
Se puede especificar el hacer una acción cuando ocurre en dicho estado un evento que no conlleva salir del estado:
estado A
on evento_activador( arg1 )[ condición ]: acción por evento
.. Acciones
Actividades
Las actividades son similares a las acciones pero tienen duración y se ejecutan dentro de un estado del objeto
Las actividades pueden interrumpirse en todo momento, cuando se desencadena la operación de salida del estado
Cuando una actividad finaliza se produce una transición automática de salida del estado
a
do: actividad
b[ not condición ]
b
[ condición ]
… Actividades
Generalización de Estados
Podemos reducir la complejidad de estos diagramas usando la generalización de estados
Distinguimos así entre superestado y subestados
Un estado puede contener varios subestados disjuntos
Los subestados heredan las variables de estado y las transiciones externas
Generalización de Estados
Ejemplo:
a b
c
e1
e2
e2
Quedaría como:
c
a ba be1
e2
Generalización de Estados
Las transiciones de entrada deben ir hacia subestados específicos:
c
a ba be1
e2
e0
… Generalización de Estados
Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qué subestado se entra:
c
a ba be1
e2
e1
e0
… Generalización de Estados
Ejemplo:
e1e1
… Generalización de Estados
Historial
Por defecto, los autómatas no tienen memoria
Es posible memorizar el último subestado visitado para recuperarlo en una transición entrante en el superestado que lo engloba
Ejemplo: a
d2
d1
H
d2
d1
x yh
out
in
H
… Historial
También es posible la memorización para cualquiera de los subestados anidados (aparece un * junto a la H)
a
d2
d1
H*
d2
d1
x yh
out
in
H*
… Historial
Ejemplo:
Enjuague Lavado Secado
H
Enjuague Lavado Secado
H
Espera
Cerrar PuertaAbrir Puerta
… Historial
AbrirCerrar
… Destrucción de Objeto
Ejemplo:
En tierraCrear(matricula)
En vuelo
aterrizardespegar
crash
Ejemplo: a
esperar dinero
entry: Mostrar mensajedo: Esperar 30 segundosexit: cerrar ranura
b
anular transacción
/ Abrir ranura
Depósito efectuado
Si en 30 segundos no se introduce el dinero se termina la actividad pasando a anular la transacción. En cualquier caso se cierra la ranura.
… Transiciones temporizadas
Ejemplo v.2:
… Transiciones temporizadas
a
esperar dinero
entry: Mostrar mensajeexit: cerrar ranura
b
anular transacción
/ Abrir ranura
Depósito efectuado
Temporizador(30 segundos)
Diagrama de Actividades
EjemplosBuscar Bebida
Poner café en filtro Añadir agua al depósito Coger taza
Poner filtro en máquina
Encender máquina
Café en preparación
Servir café
Coger zumo
Beber
[no hay café]
[hay café
[no zumo]
[hay zumo]
^cafetera.On
indicador de fin
...Ejemplos (con bandas)
Emitir billete
Pasajero Vendedor Airline
Solicitar pago Reservar plazas
Confirmar plaza reservadaPagar pasaje
Informar alternativas y precios
Verificar existencia vuelo
Dar detalles vuelo
Solicitar pasaje
Seleccionar vuelo
Diagrama de Componentes
La representación gráfica es la siguiente:
GenéricoCuerpoEspecificación
Package specification
Package body
Generic package
… Diagramas de Componentes
Subsistemas Los distintos componentes pueden
agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación
Son paquetes estereotipados en <<subsistemas>>
NewPackage4<<subsistema>>
Diagrama de Distribución
Diagramas de Distribución
Punto de Venta
Servidor Central
Terminal de Consulta
Gestión de Cuentas
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Rutinas de Coneccion
Comment
Interfaz de Terminal
Comment
Rutinas de Coneccion
Comment
Acceso a BD
Comment
Control y Análisis
Comment
Ejemplo de conexión entre nodos:
Nodo<<Procesador>
nodo2<<dispositivo>>
dispositivo
conexión7
conexión1<<<<TCP/IP>>>>
<<RDSI>>
En Rational Rose podemos distinguir entre el dispositivo por estereotipado y el dispositivo con su propio símbolo
… Diagramas de Distribución
Paquetes
Paquetes en UML
Los paquetes ofrecen un mecanismo general para la organización de los modelos agrupando elementos de modelado
Se representan gráficamente como:
Nombre de paquete