Upload
doananh
View
217
Download
1
Embed Size (px)
Citation preview
1
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
LENGUAJE UML 2(PARTE 2)
2
Título: Lenguaje UML 2Autor: Manuel ImazLocalidad y Año de impresión: Madrid, 2004
3
LENGUAJE UML 2 (Continuación)
15) Arquitecturas dirigidas por Modelos (MDA). UML ejecutable: evaluación depromesas y limitaciones. Estado actual de la cuestión. Ejemplos
16) Caso Práctico Nº 1 - Modelado de Casos de Uso. Cajero Automático
17) Caso Práctico Nº 1 - Descripción Gráfica de los Casos de Uso
18) Caso Práctico Nº 2 - Diagrama de Clases. Reserva de Pasajes Aéreos
19) Caso Práctico Nº 3- Diagrama de Estados. Teléfono
LENGUAJE DE MODELADO UML 2
4
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
15.ARQUITECTURASDIRIGIDAS POR
MODELOS(MDA)
5
requisitos
análisis
diseño
codificación
pruebas
implantación
Mayoríatexto
PIM
PSM
Código
Código
Proceso MDA
LA ARQUITECTURA MDA
El ciclo de vida de desarrollo MDA es similar al tradicional:
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
6
LA ARQUITECTURA MDA
La mayor diferencia está en los artefactos generados
Los artefactos consisten en modelos formales, es decir modelos que puedenser entendidos por el ordenador
Los siguientes tres modelos forman parte del núcleo de MDA:
• Modelo independiente de la plataforma (PIM)
• Modelo específico de la plataforma (PSM)
• Código
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
7
PIM
MODELO INDEPENDIENTE DE LA PLATAFORMA (PIM)
Es el primer modelo construido, a un alto nivel de abstracción, eindependiente de cualquier tecnología
El PIM describe un sistema de software que soporta algún área de negocio
Dentro del PIM, el sistema está modelado desde el punto de vista que mejorsoporta al negocio. no interesa si se implementará como una BD relacional ocomo EJB
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
8
PIM
PSM
PSM
MODELO ESPECÍFICO DE LA PLATAFORMA (PSM)
En el siguiente paso, el PIM se transforma en uno o más PSMs
Por ejemplo, un PSM EJB es un modelo del sistema en términos deestructuras EJB. Otro sería un PSM relacional
Un PSM contiene términos específicos de la plataforma (un Bean entidad, unBean sesión, una tabla, una columna, etc). Se genera un PSM por cadatecnología específica que se vaya a utilizar
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
9
CÓDIGO
El último paso es la transformación de cada PSM en código
Dado que cada PSM se ajusta a una determinada tecnología, la conversiónresulta relativamente directa
El desarrollo MDA abarca entonces el conjunto de los tres modelos: PIM,PSM y código.
El paso más complejo es la transformación del PIM en uno o varios PSMs
Una consecuencia de este tipo de desarrollo es que se eleva el nivel deabstracción con el que pueden trabajar los desarrolladores
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
10
PIM PSM CÓDIGOHERRAMIENTA
DETRANSFORMACIÓN
HERRAMIENTADE
TRANSFORMACIÓN
AUTOMATIZACIÓN DE LOS PASOS DE TRANSFORMACIÓN
Tradicionalmente, las transformaciones de modelo a modelo, o de modelo acódigo se realizan manualmente
Muchas herramientas pueden generar algún tipo de código, pero sólo setrata de una plantilla de código, que debe completarse a mano
En MDA, todas las transformaciones son realizadas por herramientas, talcomo se muestra en la siguiente figura:
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
11
BENEFICIONS DE MDA: PRODUCTIVIDAD
La novedad -en MDA- es que la transformación de PIM a PSMs también se haautomatizado, pero el desarrollador se centra en el PIM
Es evidente que se requiere definir las transformaciones exactas, una tareadifícil y especializada, pero que necesitan definirse sólo una vez y se puedenutilizar de forma indefinida
La otra ventaja es que los desarrolladores se centran en el PIM, es decir quepueden resolver mejor el problema de negocio y no distraerse en tecnologías
Dado que el modelo de alto nivel deja de ser ‘sólo papel’, aumentan lasexigencias por lograr un modelo completo y consistente respecto de losdesarrollos tradicionales
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
12
BENEFICIONS DE MDA: PORTABILIDAD
En MDA, la portabilidad se logra centrándose en el desarrollo de los PIMs,los que -por definición- son independientes de las plataformas
Por lo tanto, todo lo que se especifica a nivel de PIM es completamenteportable (se irán añadiendo nuevas transformaciones a medida queaparezcan nuevas tecnologías)
Para las plataformas más populares, hay (o estarán disponibles en un futurocercano) una gran cantidad de herramientas
Para las menos populares, se deberá utilizar una herramienta que admita laincorporación (mediante plug-ins) de nuevas definiciones detransformaciones
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
13
Primeratransformación
Primeratransformación
Segundatransformación
Segundatransformación
PIM
PSM PSM
Código Código
PuentePSM
PuenteCódigo
BENEFICIONS DE MDA: INTEROPERABILIDAD
En nuestro esquema anterior, no hemos mostrado la totalidad de loselementos intervinientes en la arquitectura MDA.
Los diversos PSMs generados a partir de un único PIM pueden a su vez tenerrelaciones entre ellos, pero MDA no solamente genera los PSMs sino ademáslos puentes entre ellos:
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
14
BENEFICIONS DE MDA: INTEROPERABILIDAD
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
Mundo Real Modelos
Fido (20 Kg., Terrible): Perro
Campeón (8 Kg., Simpático): Perro
Michi (4 Kg., Dormilón): Gato
abstraer
abstraer ClasificarClasificarMascota+ nombre+ peso
Perro+ carácter
Gato+ hábito
Entidades Reales Instancias del Modelo
Categorías Modelo de Clases
Clasificar Clasificar
Teoría de las Categorías Metamodelo
abstraer
Propiedad
Clase
15
BENEFICIONS DE MDA: INTEROPERABILIDAD
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
- Un único Meta-Meta-modelo (el MOF) - Una importante biblioteca Meta-Modelos compatibles, cada uno de ellos define un DSL - Cada modelo está definido en el lenguaje de su único meta-modelo
16
BENEFICIONS DE MDA: INTEROPERABILIDAD
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
• Qué puede hace fracasar a MDA? Sólo dos cosas:– Falta de modestia
• Propaganda excesiva• Ocultar los complejos problemas pendientes• Proclamar que todo es simple y está bajo control• etc.
– Falta de ambición• Soluciones ad-hoc• Falta de investigación o investigación insuficiente.• Restringirla a ”vendedores de herramientas case UML”• Si MDA no arranca, otros espacios tecnológicos ocuparán su
lugar
17
BENEFICIONS DE MDA: INTEROPERABILIDAD
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
• La separación de la parte de negocio de la parte técnica de los sistemas deinformación es una tendencia a largo plazo que mobilizará bastante energía deinvestigación y desarrollo en los próximos años.
• MDA no es una revolución sino una evolución: acompaña a los equipos deproducción de software en un contexto cambiante suminisrando orientaciones,soporte metodológico y herramientas prácticas.
• Muchos ingenieros ya utilizan buenas prácticas de MDE (Model DrivenEngineering); MDA trata de hacer explícitas y concretas esas buenas prácticas ylas integra en la cultura de la empresa.
• MDA no es probablemente la varita mágica de la ingeniería de software, pero:– No hay una alternativa razonable a MDA
18
GENERACIÓN DE CÓDIGO MANUAL/AUTOMÁTICA
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
◊ A OMG le ha llevado más de 12 años completar los estándares deinteroperabilidad CORBA 3.
◊ Es muy probable que MDA lleve aún más tiempo para lograr un nivelrazonable de generación automática de código
◊ Sin embargo, en algunos contextos particulares, algunas solucionesespecíficas ya están disponibles en la actualidad
0% 100%
2004 2020?
5% 60%
19
GENERACIÓN DE CÓDIGO MANUAL/AUTOMÁTICA
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
tecnologíaprocedimental
tecnología de componentes
tecnologíade objetos
Objetos,Clases,
Smalltalk, C++,...
Procedimientos,Pascal,
C,...
Paquetes,Frameworks,
Patrones,…
1980 1995 2000
refinamiento procedimental
tecnología de modelos
Modelos, Meta-Modelos,UML, OCL, MOF,
XMI, CWM
…
composición de objetos
transformación de modelos
20
GENERACIÓN DE CÓDIGO MANUAL/AUTOMÁTICA
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
La ingeniería de Modelos es el futuro de la tecnología de objetos
– De la misma manera que los objetos y las clases fueron considerados en los 80scomo ”entidades de primera clase", con librerías de varios cientos de clasesjerárquicamente organizadas, los modelos y meta-modelos están comenzando aser considerados el equivalente en los años 2000s
– Están comenzando a aparecer librerías de cientos de modelos y meta-modelosde alta abstracción y baja granularidad. Cada uno de los meta-modelos puedencontener varios cientos de conceptos y relaciones
– Se necesitarán herramientas para trabajar con estas vastas librerías de modelosy meta-modelos. Estas herramientas serán muy diferentes de las actualesherramientas CASE y navegadores de clases
21
REFERENCIAS
UML 2 Toolkit by Hans-Erik Eriksson et al.Fast Track UML 2.0 by Kendall ScottUML in Practice by Pascal RoquesUML Distilled: A Brief Guide to the StandardObject Modeling Language, Third Edition by Martin FowlerThe Object Primer: Agile Modeling-Driven DevelopmentWith Uml 2.0 by Scott W. AmblerMDA Distilled: Principles of Model-Driven Architectureby Stephen J. Mellor et al.The Unified Modeling Language User Guide by Grady Booch,Ivar Jacobson, James Rumbaugh
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
http://www.uml.org/http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UMLhttp://www-306.ibm.com/software/rational/uml/resources/uml2/index.html
22
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
16. MODELADO DECASOS DE USO
(CASO PRÁCTICO)
23
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 1: DESCRIPCIÓN DEL PROBLEMA
Se trata de un sistema simplificado de Cajero Automático (CA) que ofrece lossiguientes servicios:
1. Distribución de dinero a cada poseedor de una tarjeta inteligente a travésde un lector de tarjetas y un distribuidor de efectivo
2. Consulta del saldo de cuenta, facilidades para depósito de efectivo ycheques para los clientes del banco poseedor de una tarjeta del mismo
Tener en cuenta además:
3. Todas las transacciones deben ser seguras
4. A veces es necesario rellenar el distribuidor de billetes, etc
24
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 1: DESCRIPCIÓN DEL PROBLEMA
A partir de esta descripción, habrá que realizar las siguientes tareas:
• Identificar los actores
• Identificar los casos de uso
• Construir un diagrama de casos de uso
• Escribir una descripción textual de casos de uso
• Organizar y estructurar los casos de uso
La descripción anterior es -de forma deliberada- incompleta e imprecisa, talcomo aparecen los casos reales!!
25
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIBIR EL CONTEXTO ESTÁTICO DEL CAJERO AUTOMÁTICO (CA)
El CA es fundamentalmente un sistema de usuario único: en cada momento haysólo una instancia de cada actor (como máximo) conectado al sistema
PoseedorTarjeta ClienteBanco
OperadorMantenimiento
«actor»SA Visa
«actor»SI Banco
CA
0..10..1
0..10..1
0..1
asociación
multiplicidad
26
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIBIR EL CONTEXTO ESTÁTICO DEL CAJERO AUTOMÁTICO (CA)
En el diagrama anterior deberíamos añadir una nota para indicar que losactores humanos ClienteBanco y PoseedorTarjeta son mutuamenteexcluyentes, lo cual no es implícito de acuerdo a las multiplicidades de lasasociaciones
Otra solución, un poco más desarrollada, consiste en considerar a ClienteBancocomo una especialización de PoseedorTarjeta tal como vemos a continuación:
PoseedorTarjeta
ClienteBancoOperadorMantenimiento
«actor»SA Visa «actor»
SI Banco
CA
0..10..1
0..1
0..1
27
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: IDENTIFICAR LOS CASOS DE USO
Preparemos una lista de los casos de uso tomando cada uno de los 5 actores:
PoseedorTarjeta
• Retirar dinero
ClienteBanco
• Retirar dinero Consultar el saldo de una o más cuentas
• Depositar efectivo
• Depositar cheques
28
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: IDENTIFICAR LOS CASOS DE USO
Preparemos una lista de los casos de uso tomando cada uno de los 5 actores:
Operador de Mantenimiento
• Rellenar el distribuidor de billetes
• Buscar las tarjetas que fueron retenidas
• Buscar cheques que se han depositado
Sistema de Autorización de Visa y Sistema de Información del Banco
• Ninguno
29
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: ACTORES PRIMARIOS Y SECUNDARIOS
Contrariamente a lo que podríamos suponer, no todos los actores utilizan elsistema. Llamamos actor primario aquel para el cual el caso de uso produce unresultado observable. Un actor secundario -por el contrario- constituye el otrotipo de participante en el caso de uso
A los actores secundarios se les pide información adicional; sólo puedenconsultar o informar al sistema cuando el caso de uso es ejecutado
Éste es precisamente el caso de los dos actores “no humanos” de nuestroejemplo: el SA Visa y el SI Banco a los que se les solicita algo en el contexto derealización de algunos casos de uso
Ellos no tienen ninguna forma de utilizar por su cuenta el sistema de CajeroAutomático
30
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: CREACIÓN DEL DIAGRAMA DE CASO DE USO
Vamos a dar una expresión concreta a la identificación de los casos de usomediante la realización de diagramas UML de casos de uso
PoseedorTarjeta
ClienteBanco
OperadorMantenimiento
Retirar dinero
Consultar saldo
Depositar efectivo
Depositar cheques
Rellenar distribuidor
Buscar tarjetas quehan sido retenidas
Buscar cheques quehan sido depositados
CA
Límite del sistema
Caso de uso
Asociación
Actor
31
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: RELACIONES DE GENERALIZACIÓN/ESPECIALIZACIÓN ENTRE ACTORES
UML permite establecer relaciones de generalización/especialización entreactores, tal como podemos apreciar en el siguiente diagrama
PoseedorTarjeta
ClienteBanco
OperadorMantenimiento
Retirar dinero
Consultar saldo
Depositar efectivo
Depositar cheques
Rellenar distribuidor
Buscar tarjetas quehan sido retenidas
Buscar cheques quehan sido depositados
CA
Generalización
Asociación
32
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: RELACIONES DE GENERALIZACIÓN/ESPECIALIZACIÓN ENTRE ACTORES
El significado de esta generalización no es evidente en el ejemplo
Es cierto que permite eliminar la asociación entre el actor ClienteBanco y elcaso de uso Retirar Dinero, que ahora se hereda del actor PoseedorTarjeta,pero por el otro lado añade el símbolo de generalización entre los dos actores
Más aún, luego veremos que los actores secundarios requeridos en amboscasos son diferentes para ambos actores
Por lo tanto no utilizaremos esta solución y, para remarcar esta decisión vamosa renombrar al actor primario como PoseedorTarjetaVisa
Vamos a añadir los actores secundarios a fin de completar el diagrama decasos de uso, añadiendo asociaciones entre estos actores y los casos de usoexistentes
33
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: VERSIÓN SIMPLE DEL DIAGRAMA DE CASOS DE USO COMPLETADO
PoseedorTarjetaVisa
ClienteBanco
«actor»SA Visa
«actor»SI Banco
Retirar dinero
Consultar saldo
Depositar efectivo
Depositar cheques
Rol
secundario
secundariosecundario
secundario
secundario
34
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: VERSIÓN SIMPLE DEL DIAGRAMA DE CASOS DE USO COMPLETADO
Otra solución sería distinguir dos casos de uso para la extracción de dinero:Retirar dinero utilizando la tarjeta Visa y Retirar dinero utilizando la tarjeta delbanco. Esta solución, aunque más larga, es más precisa y fácil para el lector
Más aún, es un argumento en contra de la generalización entre actores. Ladiferenciación entre ambos casos de uso se opone al intento de heredar de unúnico caso Retirar dinero, que vimos antes de incluir los actores secundariosRetendremos esta segunda solución
PoseedorTarjetaVisa
ClienteBanco
«actor»SA Visa
«actor»SI Banco
Retirar dinero utilizandola tarjeta Visa
Retirar dinero utilizandola tarjeta del banco
35
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: ESCENARIOS Y CASOS DE USO
Una vez que hemos identificado los casos de uso debemos describirlos
La forma obvia de explicar la dinámica detallada de un caso de uso es medianteuna lista textual detallada de todas las interacciones entre los actores y elsistema
El caso de uso debe tener un comienzo y fin claramente identificados
También debemos especificar las posibles variantes
El caso de uso tendrá entonces un escenario principal y secuenciasalternativas, secuencias de error
Cada unidad de descripción de secuencias de acción constituye una secuencia.Un escenario representa una sucesión particular de secuencias, que se ejecutade principio a fin del caso de uso
36
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN TEXTUAL DE LOS CASOS DE USO
La descripción textual de los casos de uso no está estandarizada por UML. Sóloexisten orientaciones y recomendaciones de algunos autores:
Resumen de Identificación (obligatorio)Incluye el título, un resumen, fechas de creación y modificación, versión,persona a cargo, actores, etc
Flujo de eventos (obligatorio)Describe el escenario principal, las secuencias alternativas y de error ademásde las pre-condiciones y post-condiciones
Requisitos de IU (Interfaz de usuario)Se pueden añadir restricciones de interfaz de usuario (la apariencia y sensación)resultando muy útil las copias de pantallas o una maqueta desechable
37
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA
Resumen de Identificación
Título: Retirar dinero utilizando la tarjeta Visa
Resumen: Este caso de uso permite al poseedor de una tarjeta Visa, que no esel cliente de un banco, retirar dinero si su límite diario se lo permite
Actores: PoseedorTarjetaVisa (primario), SA Visa (secundario)
Fecha de creación: 04/02/2004 Fecha Actualización: 15/07/2004
Versión: 2.2
38
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (FLUJO DE EVENTOS)
Flujo de Eventos
Precondiciones:
• El alimentador de billetes del CA tiene una cantidad suficiente• No hay tarjeta en el lector
Escenario principal:
1. El PoseedorTarjetaVisa inserta su tarjeta en el lector de tarjetas del CA2. El CA verifica que la tarjeta es de un tipo reconocible3. El CA pide al PoseedorTarjetaVisa que introduzca su código personal4. El PoseedorTarjetaVisa introduce su código personal5. El CA compara el código personal con el que está codificado en el chip de
la tarjeta
39
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (FLUJO DE EVENTOS)
Escenario principal:
6. El CA solicita una autorización del Sistema de Autorización de Visa7. El Sistema de Autorización de Visa confirma la autorización y comunica el
límite diario máximo de extracción8. El CA pide al PoseedorTarjetaVisa que indique la cantidad deseada9. El PoseedorTarjetaVisa introduce la cantidad deseada10. El CA compara la cantidad deseada respecto del límite diario disponible11. El CA pregunta al PoseedorTarjetaVisa si desea un recibo12. El PoseedorTarjetaVisa pide un recibo13. El CA devuelve la tarjeta al PoseedorTarjetaVisa14. El PoseedorTarjetaVisa retira su tarjeta15. El CA emite los billetes e imprime el recibo16. El PoseedorTarjetaVisa recoge los billetes y el recibo
40
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (SECUENCIAS ALTERNATIVAS)
A1: Código personal temporalmente incorrectoLa secuencia A1 comienza en el punto 5 del escenario principal
6. El CA informa al PoseedorTarjetaVisa que el código personal es incorrectodurante la primera o segunda vez
7. El CA graba el fallo en la tarjetaEl escenario vuelve al punto 3
A2: La cantidad solicitada es mayor que el límite diario disponibleLa secuencia A2 comienza en el punto 10 del escenario principal
11. El CA informa al PoseedorTarjetaVisa que la cantidad solicitada que ellímite diario disponible
El escenario vuelve al punto 8
41
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (SECUENCIAS ALTERNATIVAS)
A3: El PoseedorTarjetaVisa no quiere un reciboLa secuencia A3 comienza en el punto 11 del escenario principal
12. El PoseedorTarjetaVisa indica que no quiere un recibo13. El CA devuelve la tarjeta al PoseedorTarjetaVisa14. El PoseedorTarjetaVisa recoge su tarjeta15. El CA emite los billetes16. El PoseedorTarjetaVisa recoge los billetes
42
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (SECUENCIAS DE ERROR)
E1: tarjeta inválidaLa secuencia E1 comienza en el punto 2 del escenario principal
3. El CA informa al PoseedorTarjetaVisa que la tarjeta no es válida (ilegible,expirada, etc) y la retiene; el caso de uso falla
E2: código personal incorrecto definitivamenteLa secuencia E2 comienza en el punto 5 del escenario principal
6. El CA informa al PoseedorTarjetaVisa que el código personal es incorrectopor tercera vez
7. El CA retiene la tarjeta8. Se notifica al Sistema de Autorización de Visa; el caso de uso falla
43
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (SECUENCIAS DE ERROR)
E3: extracción no autorizadaLa secuencia E3 comienza en el punto 6 del escenario principal
7. El Sistema de Autorización de Visa desautoriza cualquier extracción8. El CA devuelve la tarjeta; el caso de uso falla
E4: la tarjeta no es recogida por el usuarioLa secuencia E4 comienza en el punto 13 del escenario principal
14. Después de 15 segundos, el CA retiene la tarjeta15. Se informa al Sistema de Autorización de Visa; el caso de uso falla
44
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (SECUENCIAS DE ERROR)
E5: el usuario no recoge los billetes emitidosLa secuencia E5 comienza en el punto 15 del escenario principal
16. Después de 30 segundos, el CA vuelve a recoger los billetes17. Se informa al Sistema de Autorización de Visa; el caso de uso falla
Post-condiciones
• El alimentador de billetes del CA contiene menos billetes que al comienzodel caso de uso (el número de billetes entregados depende de lascantidades solicitadas)
45
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (REQUISITOS DE INTERFAZ DE USUARIO)
Requisitos de Interfaz de Usuario
Los mecanismos de entrada/salida disponibles al PoseedorTarjetaVisa serán:
• Un lector de tarjetas• Un teclado numérico (para introducir el código personal u otras cantidades)
con las teclas “introducir”, “correcto” y “cancelar”• Una pantalla para mostrar cualquier mensaje del CA• Teclas alrededor de la pantalla de tal manera que el poseedor de la tarjeta
pueda seleccionar una cantidad deseada de las ofrecidas por pantalla• Un distribuidor de billetes• Un emisor de recibos
46
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIÓN DE LA PARTE OBLIGATORIA DEL CASO DE USO RETIRARDINERO UTILIZANDO LA TARJETA VISA (RESTRICCIONES NO FUNCIONALES)
Restricciones no-funcionale s
Restricción Especificacione s
Tiempo de respuesta La interfaz del CA debe responder dentro de un tiempo máximo de 2 segundos Una transacción de extracción debe requerir menos de 2 minut o s
Consurrencia No se aplica (usuario únic o )
Disponibilid a d El CA debe poder accederse 24/7 La falta de papel para imprimir recibos no debe impedir que el poseedor de la tarjeta pueda realizar su extracció n
Integridad Las interfaces del CA deben ser extremadamente robustas como para evitar los vandalismo s
Confidencialidad El procedimiento de comparación entre el código personal introducido por teclado y el de la tarjeta debe tener un máximo de fallos de 10-6
47
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: ORGANIZACIÓN DE LOS CASOS DE USO
Finalmente, debemos refinar nuestros diagramas y descripciones
Con UML es posible detallar y organizar los casos de uso de dos manerasdiferentes y complementarias:
• Añadiendo relaciones de Incluye, extiende y de generalización entre casos deuso
• Agrupándolos en paquetes para definir bloques funcionales al más alto nivel
48
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: IDENTIFICAR PARTES COMUNES ENTRE CASOS DE USO
Si examinamos la descripción textual del caso de uso Retirar Dinero Utilizandouna Tarjeta Visa, podremos observar que los pasos uno a cinco del escenarioprincipal pueden aplicarse perfectamente a todos los casos de uso de unusuario de banco
Más aún, esta secuencia principal está completada por A1 (código personaltemporalmente incorrecto), E1 (tarjeta inválida) y E2 (código personal incorrectodefinitivamente)
Podemos identificar correctamente un nuevo caso de uso incluido en losprevios y que denominaremos Autenticar y que contiene las secuencias arribacitadas
Esto nos permitirá retirar todas estas descripciones textuales redundantes delos otros casos de uso y concentrarnos en las especificidades funcionales
49
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: IDENTIFICAR PARTES COMUNES ENTRE CASOS DE USO
Una forma de mostrar esta nueva organización de los casos de uso es:
Retirar dinero utilizandola tarjeta Visa
Consultar saldo Depositar efectivo
Depositar cheques
Retirar dinero utilizandola tarjeta del banco
Autenticar
«incluye»
«incluye»
«incluye»
«incluye»«incluye»
50
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: IDENTIFICAR PARTES COMUNES ENTRE CASOS DE USO
Obsérvese que la solución anterior asume que los usuarios del CA deben re-autenticarse para cada tipo de transacción. Si este no fuera el caso -como lo esefectivamente en los casos reales- deberíamos encarar el caso de usoAutenticar como una pre-condición para todos los otros, pero no como un casode uso incluido en los demás
Otra relación a considerar entre casos de uso es la de «extiende»
Cuando examinamos el caso de uso de retirar dinero, nos damos cuenta que elcliente del banco tiene acceso también a otros casos de uso. Porqué no permitirentonces que consulte su saldo justo antes de seleccionar la cantidad deseada?
El cliente podrá así modificar la cantidad de acuerdo a lo que le queda en sucuenta
51
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: EXTENSIÓN DE CASOS DE USO
Si retenemos este nuevo requisito funcional, todo lo que tenemos que hacer esmodelarlo en UML mediante una relación opcional de «extiende», tal comovemos en el siguiente diagrama:
Retirar dinero utilizandola tarjeta del banco
Consultar Saldo
Puntos de extensión:Verificar cantidad, etc
«extiende»(verificar cantidad)
Puntos de extensión
Relación extiende
52
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: EXTENSIÓN DE CASOS DE USO
Si analizamos en detalle los casos de uso Depositar efectivo y Depositarcheques vemos que implican los mismos actores y la misma operación:depositar dinero utilizando el CA, independientemente de que se trate deinsertar billetes en un lector o depositar un sobre con los cheques
PoseedorTarjetaBanco
«actor»SI Banco
Depositar dinero
Depositar cheques Depositar efectivo
Autenticar
«incluye»Caso de uso Padre
(abstracto)
Caso de uso Hijo(concreto) Generalización
53
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DIAGRAMA COMPLETO DE CASOS DE USO
PoseedorTarjetaVisa
«actor»SA Visa
Retirar dinero util izandouna tarjeta Visa
ClienteBanco
Retirar dinero util izandouna tarjeta del Banco
Consultar saldo
Depositar dinero
Depositar cheques Depositar efectivo
(Verificar cantidad)«extiende»
Autenticar
«incluye»
«incluye»
«incluye»
«incluye»
OperadorMantenimiento
Rellenar distribuidor
Buscar tarjetas que han sido retenidas
Buscar cheques que han sido depositados
«actor»SI Banco
54
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: ESTRUCTURAR LOS CASOS DE USO EN PAQUETES
PoseedorTarjetaBanco
ClienteBanco
OperadorMantenimiento
Extracción con Visa
Transacciones Cliente
Mantenimiento
Servicios de Soporte
Dependencia entre paquetes
Paquetes
55
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
17. DESCRIPCIÓNGRÁFICA DE LOSCASOS DE USO
56
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIONES DINÁMICAS DEL CASO DE USO
Se recomienda completar la descripción textual con uno o más diagramasdinámicos de UML. Para los casos de uso, se recomiendan los diagramas deactividad, y para los escenarios los diagramas de secuencia
Texto
Caso de Uso
Escenario
Diagrama de Actividad
Sist.
Diagrama de Secuencia
57
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIONES DINÁMICAS DEL CASO DE USO
• Para los casos de uso el diagrama de actividad es muy adecuado, ya que esmucho más fácil de entender para los usuarios porque se parecen a losdiagramas tradicionales -flowcharts. Sin embargo, los diagramas de estadopueden resultar útiles para casos de uso con mucha interacción
• Para ciertos escenerios, los diagramas de secuencia funcionan bien. Serecomienda presentarlos colocando al actor principal a la izquierda, luego unobjeto que represente al sistema como caja negra y, finalmente, los actoressecundarios que puedan ser solicitados durante el escenario a la derecha delsistema. Craig Larman1 propuso llamarlo diagrama de secuencia del sistema
1 Applying UML and Patterns (2nd. Edition), Prentice-Hall, 2001
58
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIONES DINÁMICAS DEL CASO DE USO
Crear un diagrama de secuencia del sistema que describa el escenario principaldel caso de uso Retirar dinero utilizando una tarjeta Visa
CA
PoseedorTarjetaVisa SA VisaInsertar la tarjeta Visa
Solicitar código personal
Código personal (valor) Solicitar autorización
Autorización (límite)Pregunta la cantidad a extraer deseada
Cantidad a extraer (valor)Pregunta si quiere recibo
OKExpulsa tarjetaRecoge la tarjeta
Expulsa billetes + reciboRecoge billetes + recibo
Mensaje con valor
Mensaje
59
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DESCRIPCIONES DINÁMICAS DEL CASO DE USO
Crear un diagrama de actividad que describa la dinámica del caso de usoRetirar dinero utilizando una tarjeta Visa
Verificar Tarjeta
[tarjeta válida]Verificar código
[No OK por 1ra y 2da vez]
[tarjeta inválida]
Pedir autorizacióna Visa
[OK]
[No OK por 3ra vez]
Transacción cancelada
[Extracción rechazada]
Pedir autorizacióna Visa
[Extracción autorizada]
Expulsar tarjeta[Cantidad <= límite]
[Tarjeta no recogidadespués de 15’’]
[Tarjeta recogida]
Emitir billetes Imprimir recibo
[Billetes no recogidosdespués de 30’’]
[Billetes recogidos]
[Recibo solicitado]Unión (Join)Bifurcación (Fork)
Fin nominal
Estado inicial)
Estado final)
60
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CAJERO AUTOMÁTICO: DIAGRAMA DE SECUENCIA DEL SISTEMA EXPANDIDO
CA
PoseedorTarjetaVisa SA VisaInsertar la tarjeta Visa
Solicitar código personal
Código personal (valor)
Solicitar autorización
Autorización (límite)Pregunta la cantidad a extraer deseada
Cantidad a extraer (valor)
Pregunta si quiere recibo
OK
Expulsa tarjeta
Recoge la tarjeta
Expulsa billetes + recibo
Recoge billetes + recibo
Verificar tarjeta
Verificar código
Verificar cantidad solicitada
Ver E1:Tarjeta inválida
Ver A1 y E2:Código incorrecto
Ver E3:Extracción noautorizada
Ver A2:Cantidad solicitadaes mayor que ellímite diarioVer A3:
Recibo rechazado
Ver E4:Tarjeta no recogida
Ver E5:Billetes no recogidos
61
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
18. DIAGRAMA DECLASES
(CASO PRÁCTICO)
62
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: DESCRIPCIÓN DEL PROBLEMA
Se trata de un sistema simplificado de reserva de vuelos para una agencia deviajes y que ofrece los siguientes servicios:
1. Las compañías aéreas ofrecen varios vuelos2. Una compañía abre y cierra las reservas para un determinado vuelo3. Un cliente puede reservar uno o más vuelos y para diferentes pasajeros4. Una reserva implica un único pasajero y un único vuelo5. Una reserva puede ser cancelada o confirmada6. Un vuelo tiene un aeropuerto de salida y otro de llegada7. Un vuelo tiene un día y una hora de salida y un día y hora de llegada8. Un vuelo puede implicar escalas en aeropuertos9. Una escala tiene una hora de llegada y otra de salida10. Un aeropuerto atiende a una o más ciudades
63
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 1 - MODELAR LAS SENTENCIAS 1 Y 2
Las compañías aéreas ofrecen varios vuelos
CompaniaAerea y Vuelo son conceptos importantes del mundo real conatributos y comportamientos, por lo que son clases candidatas para nuestromodelado estático
Pedemos iniciar el diagrama de clases como sigue:
Se ha preferido la multiplicidad de 1..* (por el lado de la clase Vuelo) a la de0..* porque estamos considerando compañías aéreas que ofrecen al menosun vuelo
CompaniaAerea Vueloofrece 1..*
64
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 1 - MODELAR LAS SENTENCIAS 1 Y 2
Comenzamos por la noción de que un vuelo es ofrecido normalmente poruna única compañía aérea, pero también puede ser compartido por variascompañiás que lo fletan (charterer). Por eso charterer es un buen candidatopara denominar al rol que juega la CompaniaAerea en la asociación con Vuelo
El hecho de abrir y cerrar las reservas representa un concepto dinámico,referido a cambios en el estado de un objeto -Vuelo- realizado por otro objeto-CompaniaAerea-Una solución obvia consistiría en añadir un atributo enumerado, estado,como se muestra en la siguiente figura
CompaniaAerea Vueloofrece 1..*
charterer
1..*
65
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 1 - MODELAR LAS SENTENCIAS 1 Y 2
Este no sería un enfoque correcto: cada objeto posee un estado actual porencima de los valores de sus atributos, que pertenece a las propiedadesintrínsecas del concepto de objeto. Por lo tanto el concepto de estado nodebe aparecer como un atributo en los diagramas de clase y debe sermodelado en la vista dinámica utilizando el diagrama de estado
En un diagrama de clases los únicos conceptos dinámicos son lasoperaciones
La pregunta sería entonces, ¿en qué clase colocamos las operaciones quehemos identificado?
CompaniaAerea Vueloofrece 1..*
charterer
1..*estado: (abierto, cerrado)
66
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 1 - MODELAR LAS SENTENCIAS 1 Y 2
En Vuelo y no en CompaniaAerea
En orientación al objeto consideramos que el objeto sobre el cual realizaríamosun proceso debe declararlo como una operación. Colocaremos entonces lasoperaciones en la clase Vuelo y nos aseguramos que la clase CompaniaAereatiene una asociación con ella
La asociación ofrece se instanciará en un conjunto de enlaces entre objetos delas clases CompaniaAerea y Vuelo, lo cual permitirá la circulación de mensajesde abrir y cerrar reservas entre estos objetos, como se puede ver en elsiguiente diagrama de comunicación
CompaniaAerea Vueloofrece 1..*
charterer
1..*
abrirReserva()cerrarReserva()
67
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 1 - MODELAR LAS SENTENCIAS 1 Y 2
:CompaniaAerea
V1:Vuelo
V2:Vuelo
1:abrirReserva()2.cerrarReserva()
3:abrirReserva()
68
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 2 - MODELAR LAS SENTENCIAS 6, 7 y 10
Continuemos modelando la clase Vuelo. Las sentencias 6 y 7 se refieren a elladirectamente. Consideremos primeramente la sentencia 7
7. Un vuelo tiene un día y una hora de salida y un día y hora de llegada
Estas nociones de fechas y horas representan simplemente valores, por lo quelos modelaremos como atributos y no como simples objetos
CompaniaAerea Vueloofrece 1..*1..*
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
69
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 2 - MODELAR LAS SENTENCIAS 6, 7 y 10
Un objeto es algo más importante que un atributo. Un buen criterio a aplicar eneste caso podría establecerse de la siguiente manera: si podemos preguntar aun elemento sólo por su valor, se trataría de un simple atributo; pero si hayvarias cuestiones que se refieren a él, estaríamos ante un objeto con variosatributos, además de enlaces con otros objetos
Apliquemos entonces este criterio a la sentencia 6
6. Un vuelo tiene un aeropuerto de salida y otro de llegada
Cuáles son las diferentes soluciones para modelar la sentencia 6 junto a susventajas y desventajas?
70
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 2 - MODELAR LAS SENTENCIAS 6, 7 y 10
La noción de aeropuerto es compleja (posee un nombre pero además tiene unacapacidad, sirve a ciudades, etc. Por esta razón hemos preferido modelarloscomo clases y no como meros atributos en la clase Vuelo
Una solución inicial consiste en crear una asociación con una multiplicidad de 2colocada del lado de la clase Aeropuerto. Para evitar la confusión entre salida yllegada, añadiríamos una restricción de {ordenado} del lado de Aeropuerto
AeropuertoVuelo
{ordenado}
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegadaaeropuertoSalidaaeropuertoLlegada
nombre
2
71
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 2 - MODELAR LAS SENTENCIAS 6, 7 y 10
Pero esta solución no es recomendable, dado que no es informativa para elexperto de negocio
Otra solución que puede resultar tentadora sería la de crear dos subclases apartir de la clase Aeropuerto, pero también es incorrecta porque dado que unaeropuerto es de salida para ciertos vuelos y de llegada para otros
AeropuertoSalidaVuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegadaaeropuertoSalidaaeropuertoLlegada AeropuertoLlegada
1
1
Aeropuerto
72
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 2 - MODELAR LAS SENTENCIAS 6, 7 y 10
Veamos ahora la sentencia 10
10. Cada aeropuerto atiende a una o varias ciudades
Cuál es la multiplicidad del lado de Aeropuerto en el modelado de la sentencia?
La respuesta no es tan sencilla como aparenta. Es evidente que la respuestadepende de la definición que demos al verbo “atiende” en nuestro sistema. Siatender es simplemente nombrar el método más cercano de transporte aéreo,entonces cada ciudad será atendida por un solo aeropuerto
Aeropuerto Ciudad1..*atiende
73
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 2 - MODELAR LAS SENTENCIAS 6, 7 y 10
Pero si servir significa, por ejemplo, cada método de transporte aéreo quepuede hallarse a menos de 30 Kms, entonces una ciudad puede ser atendidapor 0 o más aeropuertos. Mantendremos esta segunda definición
Aeropuerto Ciudad1..*atiende
Aeropuerto Ciudad1..*atiende
1
0..*
74
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 3 - MODELAR LAS SENTENCIAS 8 y 9
Consideremos ahora las escalas, es decir las sentencias 8 y 9
Cada escala tiene dos propiedades de acuerdo a las sentencias 8 y 9: hora dellegada y hora de salida. También hay conexiones con otros vuelos yaeropuertos, que son objetos, por lo que es natural modelarlas como clases
Aeropuerto?Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
salida
llegada
Escala
?
horaLlegadahoraSalida
?0..* ?
?
75
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 3 - COMPLETAR LAS MULTIPLICIDADES DE LAS ASOCIACIONES
De acuerdo a la sentencia 8, un vuelo puede tener escalas en aeropuertos, peroesto es ambiguo. Si consultamos a un experto del dominio podemosencontrarnos con un diagrama como el siguiente:
ToulouseMenorca: Vuelo
Palma: Escala
BurdeosMenorca: Vuelo
Palma: Aeropuerto
Menorca: Aeropuerto
76
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 3 - COMPLETAR LAS MULTIPLICIDADES DE LAS ASOCIACIONES
Una escala puede, en consecuencia, pertenecer a dos vuelos diferentes.Obsérvese lo efectivo que puede resultar un diagrama de objetos para mostrarun ejemplo -o un contraejemplo- para poder refinar un aspecto difícil de undiagrama de clases
Para completar el modelado de las sentencias 8 y 9 debemos añadir la siguienteinformación:
• La asociación entre Vuelo y Escala es una agregación puesto que correspondea una relación de contener, pero no a una de composición porque loselementos -las escalas- pueden ser compartidos
• Las escalas están ordenadas respecto de los vuelos, de tal manera quepodemos añadir uns restricción de {ordenado} del lado de la clase Escala
77
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 3 - COMPLETAR LAS MULTIPLICIDADES DE LAS ASOCIACIONES
El modelado completo de las sentencias 8 y 9 tendrá entonces el siguienteaspecto:
Aeropuerto0..*Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
salida
llegada
Escala
0..*
horaLlegadahoraSalida
1..*
0..*0..*
1
1
1
tiene lugar en
{ordenado}
78
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 3 - PROPONER UNA SOLUCIÓN MÁS SOFISTICADA PARA ESCALAS
Una idea inicial sería considerar a las escalas como una especialización deAeropuerto
Aeropuerto0..*Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
salida
llegada
Escala
0..*
horaLlegadahoraSalida
1..*
0..*
1
1
{ordenado}
79
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 3 - PROPONER UNA SOLUCIÓN MÁS SOFISTICADA PARA ESCALAS
Pero no es una idea recomendable porque ¿podemos realmente considerar queuna escala es un tipo de aeropuerto? Además de no serlo, se recomienda noutilizar este tipo de solución para heredar de aeropuerto sólo el nombreEn realidad, el concepto de escala es un tercer rol desempeñado por Aeropuerto
Aeropuerto0..*Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
salida
llegada
EscalaInfo
0..*
horaLlegadahoraSalida
0..*
1
1
{ordenado}
0..*
escala
80
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 4 - MODELAR LAS SENTENCIAS 3, 4 Y 5
Recordemos las sentencias 3, 4 y 5
3. Un cliente puede reservar uno o más vuelos y para pasajeros diferentes
4. Una reserva implica un único vuelo y un único pasajero
5. Una reserva puede cancelarse o confirmarse
Debemos diferenciar entre cliente y pasajero? Aunque a primera vista puedaparecer superfluo, es necesario separar ambos conceptos. Pensemos si no enlos viajes de negocio: el pasajero es un empleado de la empresa mientras quela empresa es el cliente
81
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 4 - MODELAR LAS SENTENCIAS 3, 4 Y 5
La sentencia 4 puede modelarse mediante 2 asociaciones
La sentencia 5 puede modelarse añadiendo 2 operaciones en la clase Reserva,de la misma manera que la sentencia 2
Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
Reserva
cancelar()confirmar()
Pasajero
concierne
concierne
1
1
82
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 4 - MODELAR LAS SENTENCIAS 3, 4 Y 5
Es posible encontrar una solución aún más sencilla, en la que el pasajero es unsimple atributo de Reserva
Sin embargo, un inconveniente de esta solución es que muy probablementenecesitemos gestionar otros detalles del pasajero (dirección, teléfono, direcciónde e-mail, forma de pago, tarjeta de millas, etc), razón por la cual deberemosdesechar la solución sencilla
Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
Reserva
cancelar()confirmar()
concierne
1nombrePasajero
83
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 4 - MODELAR LA SENTENCIA 3 Y COMPLETAR LAS MULTIPLICIDADES
En función de lo anteriormente aclarado en relación con cliente y pasajero,deberíamos rescribir la sentencia 3 de una forma más clara: un cliente puederealizar varias reservas, cada una de las cuales se refiere a un vuelo
Esta nueva redacción nos llevaría al siguiente diagrama:
Reserva
cancelar()confirmar()
Vuelo
Cliente ha hecho
0..*
concierne1
84
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 4 - MODELAR LA SENTENCIA 3 Y COMPLETAR LAS MULTIPLICIDADES
Si añadimos la clase Pasajero y completamos las multiplicidades tenemos elsiguiente diagrama, en el que la flecha de dirección indica cómo leer el nombrede la asociación:
Reserva
cancelar()confirmar()
Vuelo
Cliente ha hecho
0..*
concierne1
Pasajero
concierne
1
0..*
0..*
85
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 5 - AÑADIR ATRIBUTOS, RESTRICCIONES Y CUALIFICADORES
En base a todo lo anterior, tenemos el siguiente diagrama preliminar:
EscalaInfohoraLlegadahoraSalida
0..* Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
Cliente
Pasajero
ha hecho
concierne
concierne1 0..*
0..*
1
0..*
1
ofrece1..*
1..*
86
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 5 - AÑADIR ATRIBUTOS, RESTRICCIONES Y CUALIFICADORES
Para cada una de las clases, listamos los siguientes atributos esenciales:
Aeropuerto
• nombre
Cliente
• nombre• apellido• direccion• telefono• fax
CompaniaAerea
• nombre
EscalaInfo
• horaLlegada• horaSalida
Pasajero
• nombre• apellido
Reserva
• fecha• numero
Ciudad
• nombre
Vuelo
• número• fechaSalida• horaSalida• fechaLlegada• horaLlegada
87
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 5 - AÑADIR ATRIBUTOS, RESTRICCIONES Y CUALIFICADORES
Completar el modelo con algunos atributos derivados relevantes:
EscalaInfohoraLlegadahoraSalida/duracion
0..* Vuelo
abrirReserva()cerrarReserva()
numerofechaSalidahoraSalidafechaLlegadahoraLlegada/duracion
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
Cliente
Pasajero
ha hecho
concierne
concierne1 0..*
0..*
1
0..*
1
nombreapellidodireccionTelefonofax
fechanumero
nombreapellido
nombre
nombre
ofrece1..*
1..*
88
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 5 - ATRIBIUTOS DERIVADOS EN EL DISEÑO
Los atributos derivados permiten al analista no tomar una decisión prematurarespecto del diseño. Sin embargo, puesto que este concepto no existe en loslenguajes orientados al objeto, el diseñador podrá elegir entre varias opciones:
• mantener un atributo en el diseño con sus métodos de acceso (get y set)
• no almacenar un valor redundante, sino calcularlo a petición utilizando unmétodo público
La segunda opción es la deseable si la frecuencia de peticiones es baja y elalgoritmo para calcularlo es simple. La primera es preferible cuando laspeticiones son frecuentes o el algoritmo de cálculo es muy complejo
EscalaInfohoraLlegadahoraSalida/duracion
EscalaInfohoraLlegadahoraSalida
+getDuracion
Análisis Diseño
89
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 5 - AÑADIDO DE RESTRICCIONES Y ASOCIACIONES CUALIFICADAS
Debemos seleccionar bien las restricciones a añadir para no sobrecargar eldiagrama y hacer difícil su comprensión
Como hemos resaltado, el hecho de que una reserva concierne un único vuelo yun único pasajero y es además irreversible implica que el cambio del vuelo odel pasajero significará la cancelación de la reserva y creación de una nueva
Este hecho puede representarse mediante una restricción de {congelado} en losroles de la asociación
Finalmente, podemos convertir el atributo numero de la clase Vuelo en uncualificador de la asociación ofrece entre las clases CompaniaAerea y Vuelo
Cada vuelo es identificado unívocamente por el número apropiado para lacompañía. Obsérvese que la inclusión del cualificador disminuye lamultiplicidad del lado de la clase Vuelo
90
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 5 - AÑADIDO DE RESTRICCIONES Y ASOCIACIONES CUALIFICADAS
EscalaInfohoraLlegadahoraSalida/duracion
0..* Vuelo
abrirReserva()cerrarReserva()
fechaSalidahoraSalidafechaLlegadahoraLlegada/duracion
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
Cliente
Pasajero
ha hecho
concierne
concierne1 0..*
0..*
1
0..*
1
nombreapellidodireccionTelefonofax
fechanumero
nombreapellido
nombre
nombre
ofrece
1..*
0..1
numeroCualificador
Restricciones
{duracion =horaSalida - horaLlegada}
{Reserva. fecha<= Vuelo.fechaSalida}
{congelado}
{congelado}
91
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 6 - USO DE PATRONES DE ANÁLISIS
Todavía podemos mejorar nuestro modelo
La clase Vuelo tiene demasiadas responsabilidades diferentes, considerandolos atributos y asociaciones
En realidad tiene dos tipos diferentes de responsabilidades:
• La primera se refiere a toda la información que encontramos en los horariosde las compañías aéreas: tenemos un vuelo diario non-stop Buenos Aires-Madrid a las 14:30. Esto es un vuelo genérico, que está disponible diariamente
• La segunda recoge información relacionada con las reservas. No reservamosen el vuelo diario Buenos Aires-Madrid, sino en el del 30 de julio de 2004
Esto implica una separación de responsabilidades en dos clases diferentes
92
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 6 - EL PATRÓN METACLASE
Esta separación de responsabilidades puede lograrse aplicando un patrón deanálisis, llamado patrón metaclase, y que puede reutilizarse en otros contextos
Identificamos una clase A, que tiene demasiadas responsabilidades, algunas delas cuales no son específicas a cada instancia
En ese caso añadimos una clase TipoA, distribuimos las propiedades entreambas clases y las vinculamos mediante una asociación “1 - *”
La clase TipoA se describe como una metaclase, puesto que contieneinformación que describa a la clase A
La navegación limitada de A a TipoA no es obligatoria pero es muy frecuente
Aatributo1atributo2
TipoAatributo3atributo41*
93
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 6 - AÑADIDO DE RESTRICCIONES Y ASOCIACIONES CUALIFICADAS
EscalaInfohoraLlegadahoraSalida/duracion
0..*VueloGenerico
diahoraSalidahoraLlegada/duracionperiodoValidez
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
concierne
concierne1 0..*
0..*
1
fechanumero
nombre
nombre
1..*
0..1
numero
{congelado} abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
Vuelo«metaclase»{congelado}
Vuelo.fechaSalida debe estar enVueloGenerico.periodoValidez
94
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - ESTRUCTURAR EN PAQUETES
Ya casi hemos terminado el modelo del dominio. A fin de facilitar su uso ypreparar la actividad de diseño orientada al objeto, vamos a estructurarlo enpaquetes. Para ello nos basaremos en dos principios: coherencia eindependencia
El primer principio implica agrupar las clases que son similares desde un puntode vista semántico, para lo cual deben respetarse los siguientes criterios:
• objetivo: las clases deben suministrar servicios del mismo tipo a los usuarios
• estabilidad: aislamos las clases que son verdaderamente estables respecto deaquellas que probablemente evolucionen en el curso del proyecto. En particulardiferenciamos las clases de negocio de las clases de aplicación
• ciclo de vida de los objetos: este criterio permite a las clases ser diferenciadasde acuerdo a los diferentes ciclos de vida
95
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 6 - MODELO DEL DOMINIO ANTES DE ESTRUCTURARLO
EscalaInfohoraLlegadahoraSalida/duracion
0..*VueloGenerico
diahoraSalidahoraLlegada/duracionperiodoValidez
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
concierneconcierne1
0..*
0..*
1
fechanumero
nombre
nombre
1..*
0..1
numero
{congelado}
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
Vuelo
«metaclase»
{congelado}
define
ofrece1..* 0..*
Cliente
Pasajeronombreapellidodirecciontelefonofax
nombreapellido
1
0..*concierne
ha hecho
0..*
1 {congelado}
96
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - PROPUESTA DE ESTRUCTURAR EL MODELO EN DOS PAQUETES
De acuerdo a los criterios antes mencionados, podemos ofrecer una divisióninicial en dos paquetes:
• el primero atañe a la definición de los vuelos -muy estables en el tiempo- enespecial la sección relativa a VueloGenerico
• el segundo atañe a las reservas, junto a sus asociaciones
Cada paquete contiene un conjunto de clases que están estrechamentevinculadas, pero las clases de ambos paquetes son casi independientes
La primera división está indicada por la línea que actúa como partición en eldiagrama que mostramos a continuación
97
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 6 - DIVISIÓN DEL MODELO EN DOS SECCIONES INDEPENDIENTES
EscalaInfohoraLlegadahoraSalida/duracion
0..*VueloGenerico
diahoraSalidahoraLlegada/duracionperiodoValidez
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
concierneconcierne1
0..*
0..*
1
fechanumero
nombre
nombre
1..*
0..1
numero
{congelado}
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
Vuelo
«metaclase»
{congelado}
define
ofrece1..* 0..*
Cliente
Pasajeronombreapellidodirecciontelefonofax
nombreapellido
1
0..*concierne
ha hecho
0..*
1 {congelado}
98
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - PROPUESTA ALTERNATIVA DE ESTRUCTURAR EL MODELO
Existe, sin embargo, otra solución que consiste en particionar la clase Vuelo enel mismo paquete que la clase Reserva
El criterio utilizado en este caso es el del ciclo de vida de los objetos, con losvuelos instanciados más cercanos a las reservas que a los vuelos genéricos
Esta división alternativa puede verse en el siguiente diagrama
99
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 6 - PROPUESTA ALTERNATIVA DE ESTRUCTURAR EL MODELO
EscalaInfohoraLlegadahoraSalida/duracion
0..*VueloGenerico
diahoraSalidahoraLlegada/duracionperiodoValidez
salida
llegada 0..*
0..* {ordenado}
1
10..*
escala
CompaniaAerea
0..*
1..*
Aeropuertonombre
Ciudad
atiende
Reserva
cancelar()confirmar()
concierneconcierne1
0..*
0..*
1
fechanumero
nombre
nombre
1..*
0..1
numero
{congelado}
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
Vuelo
«metaclase»
{congelado}
define
ofrece1..* 0..*
Cliente
Pasajeronombreapellidodirecciontelefonofax
nombreapellido
1
0..*concierne
ha hecho
0..*
1 {congelado}
100
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - ENCONTRAR SOLUCIÓN QUE MINIMICE EL ACOPLE ENTRE AMBOSPAQUETES
En los dos casos previos podemos establecer que al menos una asociaciónatraviesa los límites entre paquetes. El problema de las asociaciones queatraviesan dos paquetes reside en el hecho de que una de ellas ya es suficientepara determinar una dependencia mutua entre paquetes
Es una tarea de diseño el eliminar las dependencias mutuas o cíclicas paraaumentar la modularidad y la capacidad evolutiva de la aplicación
En la primera solución hay una única asociación en juego:
cancelar()confirmar()
fechanumero
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
VueloReserva
Reservas Vuelos
concierne0..*
{congelado}
1
101
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - ENCONTRAR SOLUCIÓN QUE MINIMICE EL ACOPLE ENTRE AMBOSPAQUETES
Por omisión, una asociación entre dos clases permite la navegación en ambasdirecciones. Sin embargo, es posible limitar esta navegación a sólo unadirección a efectos de eliminar una de las dos dependencias inducidas por laasociación
UML permite representar la navegabilidad explícitamente añadiendo a laasociación una flecha para indicar la dirección única. En nuestro caso estáclaro que el conocimiento del vuelo es un pre-requisito para la reserva,mientras que la reserva puede existir por sí misma
cancelar()confirmar()
fechanumero
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
VueloReserva
Reservas Vuelos
concierne0..*
{congelado}
1
102
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - ENCONTRAR SOLUCIÓN QUE MINIMICE EL ACOPLE ENTRE AMBOSPAQUETES
Analicemos ahora la segunda solución. Esta vez hay dos asociaciones queatraviesan los paquetes. Que podemos hacer para disminuir la navegabilidad?
Tiene sentido fijar el sentido de la navegabilidad desde Vuelo haciaVueloGenerico: un vuelo real queda descrito por sólo un vuelo genérico hacia elcual debe tener acceso, mientras que un vuelo genérico puede existir por sí
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
Vuelo
ProgramaVuelosReservas
ofreceVueloGenericodiahoraSalidahoraLlegada/duracionperiodoValidez
CompaniaAereanombre
«metaclase»
0..*
0..*
describe
103
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 2: PASO 7 - SOLUCIÓN ELEGIDA
Vemos que aún añadiendo la navegabilidad, deberíamos mantener dosasociaciones de navegabilidad, lo cual implica una dependencia mutua de losdos paquetes
Debemos optar, entonces, por la primera solución en la cual distribuiríamos lasclases de la siguiente forma:
Vuelos
Reservas
+ Aeropuerto+ CompaniaAerea
+ EscalaInfo+ Ciudad+ Vuelo
+ VueloGenerico
+ Cliente+ Pasajero+ Reserva
104
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2CASO DE ESTUDIO 2: PASO 6 - PROPUESTA ALTERNATIVA DE ESTRUCTURAR EL MODELO
{congelado}
EscalaInfohoraLlegadahoraSalida/duracion
0..*
VueloGenericodiahoraSalidahoraLlegada/duracionperiodoValidez
salida
llegada 0..*
0..* {ordenado}
1
1
0..*
escala
CompaniaAerea
Aeropuertonombre
atiende
concierne
concierne1
0..*
0..*
1
0..*
1..*
Ciudadnombre
nombre
1..*
0..1
numero
{congelado}
abrirReserva()cerrarReserva()
fechaSalidafechaLlegada
Vuelo
«metaclase»
define
ofrece1..* 0..*
Reserva
cancelar()confirmar()
fechanumero
Cliente
Pasajeronombreapellidodirecciontelefonofax
nombreapellido
1
0..*concierne
ha hecho0..*
1 {congelado}
Vuelos
Reservas
105
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
19. DIAGRAMA DEESTADOS (CASO
PRÁCTICO)
106
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: DESCRIPCIÓN DEL PROBLEMA
Se trata de un sistema simplificado de teléfono que funciona con monedas:
1. El costo mínimo de todas las llamadas es 25 centavos
2. Después de insertar la moneda, el usuario tiene 2 minutos para marcar unnúmero (este limite de tiempo está determinado por la central)
3. La línea puede estar libre u ocupada
4. El usuario puede colgar primero
5. El teléfono utiliza el dinero cuando la persona llamada descuelga suteléfono y con cada unidad de tiempo (UT) generada por la central
6. El usuario puede añadir más monedas en cualquier momento
107
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: EL TELÉFONO DE MONEDAS
A partir del enunciado anterior trabajaremos en las siguientes tareas:
• Identificar los actores y casos de uso
• Construir un diagrama de secuencia del sistema
• Construir un diagrama dinámico de contexto
• Desarrollar el diagrama de estados del teléfono de monedas
108
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3:PASO 1 - IDENTIFICAR LOS ACTORES Y LOS CASOS DE USO
Cuáles con las entidades externas que interactúan directamente con el teléfono?
Si analizamos la descripción anterior, tenemos 4 candidatos: el usuario(persona que llama), la central, el teléfono y la persona llamada
Si analizamos más detalladamente el problema vemos que la central actúacomo intermediaria entre el que llama y la persona llamada. Más aún, la personallamada no interactúa directamente con el teléfono sino que estácompletamente oculta en lo denominamos la central
«actor»central
usuario Persona llamada
109
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 1 - IDENTIFICAR LOS ACTORES Y LOS CASOS DE USO
«actor»central
usuario
«sistema»Teléfono pago
«sistema»Teléfono
Persona llamada
0..1
0..1
0..1
0..1
0..*
0..*
110
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 1 - IDENTIFICAR LOS ACTORES Y LOS CASOS DE USO
Está claro que el usuario se comunica con la persona llamada por medio de 3sistemas interconectados: el teléfono pago, la central y el teléfono de lapersona llamada
La simetría del diagrama respecto de la central nos muestra que ésta juega elrol de actor respecto de los otros dos sistemas del mismo tipo
Como la persona llamada es un actor indirecto respecto del teléfono pago, no lotendremos en cuenta en el diagrama de casos de uso, que queda muy simple
«actor»central
usuario
Teléfono pago
Teléfono
111
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 2 - CREAR UN DIAGRAMA DE SECUENCIA DEL SISTEMA QUE DESCRIBAEL ESCENARIO PRINCIPAL DEL CASO DE USO TELÉFONO
:Telefono Pago
:CentraldescolgarElTelefono
insertarMoneda(25c)
marcarNumero(4123 4567) encaminarNumero(4123 4567)
tonoDeLlamada(libre)
vozPersonaLlamada
vozUsuario
UT
insertarMoneda(25c)
colgar
Nota para indicarposible repetición
:Usuario
comienzaComun
vozPersonaLlamada
vozUsuario
UT
UT
finalizarComun
Conversación
112
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 2 - EXTENDER EL DIAGRAMA ANTERIOR CON OTRAS ACTIVIDADES YELIMINANDO LA CONVERSACIÓN PARA CONCENTRARNOS EN LAS OPERACIONES DEL SISTEMA
:Telefono Pago
:CentraldescolgarElTelefono
insertarMoneda(25c)
marcarNumero(4123 4567)encaminarNumero(4123 4567)
tonoDeLlamada(libre)
insertarMoneda(25c)
colgar
:Usuario
comienzaComun
finalizarComun
verificarMoneda
incrementarCredito(25c)
tonoDeLlamada(libre)
Calcular(25c)
incrementarCredito(25c)
UT
Calcular(25c)
113
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 3 - CREAR EL DIAGRAMA DE CONTEXTO DINÁMICO USANDO LASSIGUIENTES PAUTAS
• El sistema estudiado se representa mediante un objeto en el centro deldiagrama
• Este objeto central se enmarca con una instancia de cada actor
• Un enlace conecta el sistema con cada actor
• En cada enlace, todos los mensajes de entrada y salida al sistema se listan sinnumeración
114
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 3 - CREAR EL DIAGRAMA DE CONTEXTO DINÁMICO
No hay que olvidar que el diagrama de secuencia del sistema describe elescenario principal del caso de uso Telefono, y que podrían aparecer otrosmensajes
:Usuario
:Central
:Telefono pago
descolgarElTelefonoinsertarMoneda(25c)marcarNumero(num)
ColgarvozDelUsuario
encaminarNumero(num)finalizarComun
vozPersonaLlamada
tonoLlamada(tipo)vozPersonaLlamada
comenzarComunUT
tonoLlamada(tipo)vozPersonaLlamada
Mensajes
Sistema
115
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 3 - NUEVOS MENSAJES A TENER EN CUENTA
• si hay monedas que no han sido usadas cuando el usuario cuelga, el teléfonose las devuelve
• después de insertar la cantidad mínima de 25 c el teléfono pago envía unmensaje a la central para la deducción del tiempo límite de 3 minutos
• si el número que ha sido marcado no es válido, la central lo detecta
• si el usuario cuelga primero, el final de la comunicación es enviada por lacentral
• en general, la central envía el estado de la línea al teléfono pago (libre,ocupado, fuera de servicio, etc), y no sólo el tipo de tono de llamada
116
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 3 - CREAR EL DIAGRAMA DE CONTEXTO DINÁMICO
No hay que olvidar que el diagrama de secuencia del sistema describe elescenario principal del caso de uso Telefono, y que podrían aparecer otrosmensajes
:Usuario
:Central
:Telefono pago
descolgarElTelefonoinsertarMoneda(m)
marcarNumero(num)Colgar
vozDelUsuario
encaminarNumero(num)finalizarComun
vozPersonaLlamadatiempoMarcado
tonoLlamada(tipo)vozPersonaLlamada
devolverMonedasNoUsadas
comenzarComunUT
tonoLlamada(tipo)vozPersonaLlamadavalidezDelNumero(v)
finalizarComuntiempoLimiteMarcado
Mensajes parametrizados
Sistema
117
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - DESCRIPCIÓN DETALLADA USANDO UN DIAGRAMA DE ESTADOS
El procedimiento para construir el diagrama de estados es el siguiente:
• Primero de todo, representar la secuencia de estados que describen elcomportamiento nominal de una instancia junto con las transiciones que estánasociadas a ella
• Progresivamente añadir las transiciones que correspondan a loscomportamientos “alternativos” o de error
• Completar las acciones sobre las transiciones y actividades en los estados
• Estructurar el diagrama en sub-estados y usar la notación avanzada (entrada,salida, etc) si se vuelve muy complejo
118
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - CONSTRUIR EL DIAGRAMA DE ESTADOS INICIAL
Veremos que la mayoría de los eventos que disparan las transiciones entreestados corresponden a la recepción de un mensaje enviado por un actor
Más aún, hemos usado los mismos nombres para los eventos que para loscorrespondientes mensajes (excepto para númeroVálido que es más simple queel más riguroso de validezNúmero(verdadero))
Sólo el cambio del estado “Esperando monedas” a “Esperando número” seproduce por un evento interno en el teléfono pago: la detección de cuándo sesatisface el pago de 25 centavos
UML ofrece la posibilidad de distinguir estos cambios en el estado internomediante “Cuando” seguido por una expresión booleana, cuyo cambio de falsoa verdadero dispara la transición
119
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - CONSTRUIR EL DIAGRAMA DE ESTADOS INICIAL
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
ComienzaComunicación
colgarReceptor
descolgarReceptor
120
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO Solución Básica
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
ComienzaComunicación
colgarReceptor
descolgarReceptor
colgarReceptor
colgarReceptor
121
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO Solución más elaborada
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
comienzaComunicación
colgarReceptor
descolgarReceptor
Receptor descolgado
Superestado
Transiciónfactorizada
122
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO Solución aún más elaborada
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
comienzaComunicación
colgarReceptor
descolgarReceptorReceptor descolgado
Estadoinicial
123
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO
En vez de tener una transición directa entre “Colgado” y “Esperando monedas”tenemos una primera transición entre “Colgado” y “Descolgar receptor”, yluego el símbolo gráfico del estado inicial dentro de “Receptor descolgado” aefectos de dar una indicación explícita del sub-estado inicial
Esta forma de proceder permite la división del diagrama de estados en dosniveles:
• Un primer nivel, que sólo hace aparecer los estados “Colgado” y “Receptordescolgado”
• Un segundo nivel, que corresponde a la descomposición del “Receptordescolgado”
124
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL CRÉDITO DEL USUARIOALCANZA 25 CENTAVOS
Por el momento, el crédito del usuario sólo ocurre en la expresión booleanaasociada con el evento interno de “Cuando”. Sin embargo, para que el créditoalcance los 25 centavos el usuario debe insertar una o más monedas
Podemos entonces añadir una auto-transición (que vuelve al estado inicial) enel estado “Esperando moneda”. Tan pronto como el crédito excede los 25 cts, elteléfono debe entrar en el estado “Esperando número”
Si queremos usar eventos causados por la recepción de mensajes, deberíamosañadir condiciones en las transiciones, tales como vemos a continuación:
Esperandomonedas
Esperandonúmero
insertarMoneda(m) (m < 25c)
insertarMoneda(m) (m >= 25c)
Condiciones
Auto-transición
125
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL CRÉDITO DEL USUARIOALCANZA 25 CENTAVOS
Sin embargo, la solución anterior, que parece obvia, es incorrecta puesto queno permite al usuario marcar un número después de haber insertado dosmonedas de 10 y una de 5. Por lo tanto, el teléfono pago debe almacenar unatributo crédito que se incremente cada vez que se inserta una moneda
Parece que sólo se tratara de modificar el diagrama anterior añadiendo unaacción y modificando las condiciones, como se muestra a continuación:
Esperandomonedas
Esperandonúmero
insertarMoneda(m) [m < 25c)]/incrementarCréditio(m) insertarMoneda(m) [m >= 25c]
/incrementarCrédito(m)
Acciones
126
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL CRÉDITO DEL USUARIOALCANZA 25 CENTAVOS
La solución anterior también es incorrecta, pero de una manera más sutil!
La semántica de una una transición en UML es como sigue: cuando el eventodisparador se produce, se prueba la condición: si la condición es verdadera, sedispara la transición y se ejecuta la acción asociada. En nuestro ejemplo sería:
• El usuario inserta una moneda de 10 centavos. El crédito es menor de 25 cts,se dispara la auto-transición y el crédito es ahora de 10 cts
• El usuario inserta una moneda de 10 centavos. El crédito sigue siendo menorde 25 cts y se vuelve a disparar la auto-transición, con un crédito de 20 cts
• El usuario inserta una moneda de 5 cts. El crédito es menor de 25 cts (enrealidad, es de 20 cts), se dispara la auto-transición y ahora el crédito es de 25 c
El resultado sorprendente es que el usuario ha insertado 25 cts y sigue sinpoder marcar su número
127
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL CRÉDITO DEL USUARIOALCANZA 25 CENTAVOS
Ahora estamos en condiciones de dar una solución correcta:
Esperandomonedas
Esperandonúmero
insertarMoneda(m)/incrementarCrédito(m)
cuando (crédito >= 25c)
Acción, luegocomprobación
128
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR LA GESTIÓN DEL CRÉDITO DEL USUARIOSolución para la gestión del crédito
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
comienzaComunicación/comprobar
colgarReceptor
descolgarReceptor/crédito = 0)
Receptor descolgadoinsertarMoneda(m)
/incrementarCrédito(m)
UT[créditoSuficiente]/comprobar Fin de
Comunicación
UT[créditoInsuficiente]/comprobar
129
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR LA GESTIÓN DEL CRÉDITO DEL USUARIO
Hemos añadido un nuevo estado “Fin de comunicación” para contemplar lasituación en la que se corta la llamada porque falta crédito para continuar
De todas formas, nos falta modelar la última sentencia: el usuario puedeinsertar más monedas en cualquier momento.
Aquí también hay varias soluciones posibles pero sólo una resultará correcta ysuficientemente elaborada
La primera idea que se nos ocurre es la de insertar una auto-transición -idénticaa la de “Esperando monedas” en cada sub-estado de “Receptor descolgado”
Esta forma de proceder es correcta, pero su implementación es más biencomplicada, por lo que trataremos de factorizar por medio de un estadocompuesto
130
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR LA GESTIÓN DEL CRÉDITO DEL USUARIO
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
comienzaComunicación/comprobar
colgarReceptor
descolgarReceptor/crédito = 0)
Receptor descolgado
insertarMoneda(m)/incrementarCrédito(m)
UT[créditoSuficiente]/comprobar Fin de
Comunicación
UT[créditoInsuficiente]/comprobar
Factorización de laauto-transición
131
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR LA GESTIÓN DEL CRÉDITO DEL USUARIO
Pero esta solución puede tener muchos efectos secundarios. Sin ir más lejos,cuando un estado compuesto se descompone en sub-estados, una auto-transición devuelve inevitablemente al objeto a su estado inicial
Es decir que cada inserción de moneda devolverá al objeto al estado de“Esperando monedas”
Para resolver el problema, existe en UML la noción de transición interna querepresenta un par (evento/acción) que no tiene influencia en el presente estado
La transición interna es reconocida dentro del símbolo del estado
132
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - SOLUCIÓN CORRECTA CON LA TRANSICIÓN INTERNAFACTORIZADA
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
comienzaComunicación/comprobar
colgarReceptor
descolgarReceptor/crédito = 0)
Receptor descolgadoinsertarMoneda(m)/incrementarCrédito(m)
UT[créditoSuficiente]/comprobar Fin de
Comunicación
UT[créditoInsuficiente]/comprobar
Factorización en unatransición nterna
133
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - SOLUCIÓN CORRECTA CON LA TRANSICIÓN INTERNAFACTORIZADA
En realidad, la auto-transición en el estado “Comunicación” debería ser tambiénuna transición interna. Cuando no hay efectos secundarios, es preferible utilizarla auto-transición, que resulta mucho más visual
Pero debemos tener cuidado si tenemos que descomponer “Comunicación” ensub-estados en el futuro…
Una segunda solución correcta -un poco más compleja- implica la utilizacióndel pseudo-estado «history»
La activación del pseudo-estado «history» permite que un estado compuestorecuerde el último sub-estado secuencial que estaba activo antes de ocurrir latransición
Una transición hacia el estado «history» activa nuevamente el último sub-estadoactivo en vez de retornar al sub-estado inicial
134
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - SOLUCIÓN CORRECTA CON LA AUTO-TRANSICIÓN Y EL PSEUDO-ESTADO «HISTORY»
Colgado Esperandomonedas
Cuando (crédito >= 25 c)
Esperandonúmero
Esperandovalidación
marcarNúmero
Esperando que lapersona llamada responda
Comunicación
númeroVálido
comienzaComunicación/comprobar
colgarReceptor
descolgarReceptor/crédito = 0)
Receptor descolgado
insertarMoneda(m)/incrementarCrédito(m)
UT[créditoSuficiente]/comprobar Fin de
Comunicación
UT[créditoInsuficiente]/comprobar
Pseudo-estado«history»
H
135
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR EL DIAGRAMA DE ESTADOS PARA RECOGER LATOTALIDAD DEL PROBLEMA
Si analizamos todas las sentencias nuevamente, vemos que hemos tenido encuenta las sentencias 1, 5 y 6 en detalle. Por otro lado, sólo hemos consideradoparcialmente las sentencias 2, 3 y 4
Consideremos primero la sentencia 2:
2. Después de insertar las monedas, el usuario tiene 2 minutos para marcar unnúmero (este límite de tiempo está determinado por la central)
Como el límite de tiempo está determinado por la central, hemos insertado dosmensajes al diagrama de contexto
• temporizadorDeMarcado enviado por el teléfono pago a la central
• tiempoLímiteDeMarcado enviado por la central al teléfono pago
136
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR EL DIAGRAMA DE ESTADOS PARA RECOGER LATOTALIDAD DEL PROBLEMA
En el diagrama de estados del teléfono pago tendremos ahora una transiciónque será disparada cuando se reciba el mensaje tiempoLímiteDeMarcado ycuando el mensaje temporizadorDeMarcado se envíe al entrar al estado“Esperando número”, como se muestra en el siguiente diagrama:
Esperandomonedas
Cuando (crédito >= 25 c)/enviar central.temporizadorMarcado
Esperandonúmero
Fin deComunicación o error
tiempoLímiteDeMarcado
sentencia 2
137
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR EL DIAGRAMA DE ESTADOS PARA RECOGER LATOTALIDAD DEL PROBLEMA
Hemos renombrado el estado “Fin Comunicación” puesto que este estadosumidero (es decir, sin ninguna transición de salida) también será útil paratodos los casos de error
Veamos ahora la sentencia 3
3. La línea puede estar libre u ocupada
Hasta ahora hemos asumido que la línea estaba libre y que la persona llamadalevantada el receptor. Introduciremos en el modelo la posibilidad de que lacentral devuelva un estado de línea (ocupada) y además que la persona llamadano atienda (lo que no fue anticipado en la exposición)
Para este último caso, asumimos que la central envía un mensaje detiempoLímiteDeLlamada que lleva al teléfono pago al estado de error
138
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - COMPLETAR EL DIAGRAMA DE ESTADOS PARA RECOGER LATOTALIDAD DEL PROBLEMA
Colgado Esperandomonedas
Esperandonúmero
Esperandovalidación
marcarNúmero/enviar central.númeroRuta
Esperando que lapersona llamada responda
Comunicaciónhacer/transmitirVoz
númeroVálido
comienzaComunicación/comprobar
colgarReceptor/devolverMonedas
descolgarReceptor/crédito = 0)
Receptor descolgadoinsertarMoneda(m) [m OK]/incrementarCrédito(m)
UT[créditoSuficiente]/comprobar
Fin deComunicación o error
UT[créditoInsuficiente]/comprobar
Cuando (crédito >= 25 c)/enviar central.temporizadorMarcado
estadoLínea(ocupado)
tiempoLímiteDeMarcado
númeroInválido
tiempoLímiteDeLlamado
El usuario cuelga
139
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 4 - DIAGRAMA ESTÁTICO DE CONTEXTO EXTENDIDO
Un “diagrama estático de contexto extendido” es lo que llamamos un diagramade contexto estático en el cual añadimos atributos y operaciones a nivel desistema a la clase que representa al sistema (concebido como una caja negra)
Lo mismo hacemos con los actores no humanos
Es interesante observar que añadimos operaciones a los actores no humanos(como Central) pero no en el actor Usuario. El concepto de operación no tienesentido en un actor humano: no intentamos modelarlo de una formadeterminista
En un actor no-humano, sin embargo, la lista de operaciones representa suinterfaz (en el sentido de una API, por ejemplo) puesto que es utilizado por elsistema en cuestión. Es particularmente útil verificar la interoperabilidad de losdos sistemas y asegurarse de que estas operaciones ya están disponibles oplanificadas en la especificación
140
LENGUAJE DE MODELADO UML 2LENGUAJE DE MODELADO UML 2
CASO DE ESTUDIO 3: PASO 3 - CREAR EL DIAGRAMA DE CONTEXTO DINÁMICO
No hay que olvidar que el diagrama de secuencia del sistema describe elescenario principal del caso de uso Telefono, y que podrían aparecer otrosmensajes
Usuario
«actor»Central
«sistema»Teléfono pago
+ descolgarElReceptor()+ insertarMoneda(m)+ marcarNumero(num)+ tiempoLimiteMarcado()+ validezDelNumero(v)+ estadoDeLinea()+ tiempoLimiteLlamada()+ comenzarComun()+ UT()+ finalizarComun()+ colgar()- comprobarMoneda()- transmitirVoz()
+ encaminarNumero(num)+ finalizarComun()+ temporizadorMarcado()
Mensajes parametrizados
- credito = 00..1 0..1
0..1 0..*
Operacionespúblicas
Operacionesprivadas
Valor inicial