LENGUAJE UML 2 (PARTE 2)horacioamorena.com.ar/PAG DE MATERIAS Y LIBROS/LIBROS TODOS... · 3 LENGUAJE UML 2 (Continuación) 15) Arquitecturas dirigidas por Modelos (MDA). UML ejecutable:

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


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:


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


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


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


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


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:


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


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


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:


14



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



- 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



• 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



• 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


◊ 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



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



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


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


16. MODELADO DECASOS DE USO

(CASO PRÁCTICO)

23


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



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


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


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


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


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


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


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


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


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


Retirar dinero

Consultar saldo

Depositar efectivo

Depositar cheques


Buscar tarjetas quehan sido retenidas

Buscar cheques quehan sido depositados

CA

Generalización

Asociación

32


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


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


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


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


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


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


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


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


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


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


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



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



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


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


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


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


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



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


Autenticar

«incluye»

«incluye»

«incluye»

«incluye»«incluye»

50



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


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:


Consultar Saldo

Puntos de extensión:Verificar cantidad, etc

«extiende»(verificar cantidad)

Puntos de extensión

Relación extiende

52


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


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»



Buscar tarjetas que han sido retenidas

Buscar cheques que han sido depositados

«actor»SI Banco

54


CAJERO AUTOMÁTICO: ESTRUCTURAR LOS CASOS DE USO EN PAQUETES

PoseedorTarjetaBanco

ClienteBanco


Extracción con Visa

Transacciones Cliente

Mantenimiento

Servicios de Soporte

Dependencia entre paquetes

Paquetes

55


17. DESCRIPCIÓNGRÁFICA DE LOSCASOS DE USO

56


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



• 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



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



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


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


18. DIAGRAMA DECLASES

(CASO PRÁCTICO)

62



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


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



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


charterer

1..*

65



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?


charterer

1..*estado: (abierto, cerrado)

66



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


charterer

1..*

abrirReserva()cerrarReserva()

67



:CompaniaAerea

V1:Vuelo

V2:Vuelo

1:abrirReserva()2.cerrarReserva()

3:abrirReserva()

68


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


fechaSalidahoraSalidafechaLlegadahoraLlegada

69



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



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}


fechaSalidahoraSalidafechaLlegadahoraLlegadaaeropuertoSalidaaeropuertoLlegada

nombre

2

71



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


fechaSalidahoraSalidafechaLlegadahoraLlegadaaeropuertoSalidaaeropuertoLlegada AeropuertoLlegada

1

1

Aeropuerto

72



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



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



1

0..*

74


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



salida

llegada

Escala

?

horaLlegadahoraSalida

?0..* ?

?

75


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



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



El modelado completo de las sentencias 8 y 9 tendrá entonces el siguienteaspecto:

Aeropuerto0..*Vuelo



salida

llegada

Escala

0..*


1..*

0..*0..*

1

1

1

tiene lugar en

{ordenado}

78


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



salida

llegada

Escala

0..*


1..*

0..*

1

1

{ordenado}

79


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



salida

llegada

EscalaInfo

0..*


0..*

1

1

{ordenado}

0..*

escala

80


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



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



Reserva

cancelar()confirmar()

Pasajero

concierne

concierne

1

1

82



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



Reserva


concierne

1nombrePasajero

83


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


Vuelo

Cliente ha hecho

0..*

concierne1

84


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


Vuelo

Cliente ha hecho

0..*

concierne1

Pasajero

concierne

1

0..*

0..*

85


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



salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


Cliente

Pasajero

ha hecho

concierne

concierne1 0..*

0..*

1

0..*

1

ofrece1..*

1..*

86



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



Completar el modelo con algunos atributos derivados relevantes:

EscalaInfohoraLlegadahoraSalida/duracion

0..* Vuelo


numerofechaSalidahoraSalidafechaLlegadahoraLlegada/duracion

salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


Cliente

Pasajero

ha hecho

concierne

concierne1 0..*

0..*

1

0..*

1

nombreapellidodireccionTelefonofax

fechanumero

nombreapellido

nombre

nombre

ofrece1..*

1..*

88


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

+getDuracion

Análisis Diseño

89


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




0..* Vuelo


fechaSalidahoraSalidafechaLlegadahoraLlegada/duracion

salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


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


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


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




0..*VueloGenerico

diahoraSalidahoraLlegada/duracionperiodoValidez

salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


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


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


CASO DE ESTUDIO 2: PASO 6 - MODELO DEL DOMINIO ANTES DE ESTRUCTURARLO


0..*VueloGenerico


salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


concierneconcierne1

0..*

0..*

1

fechanumero

nombre

nombre

1..*

0..1

numero

{congelado}



Vuelo

«metaclase»

{congelado}

define

ofrece1..* 0..*

Cliente

Pasajeronombreapellidodirecciontelefonofax

nombreapellido

1

0..*concierne

ha hecho

0..*

1 {congelado}

96


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


CASO DE ESTUDIO 2: PASO 6 - DIVISIÓN DEL MODELO EN DOS SECCIONES INDEPENDIENTES


0..*VueloGenerico


salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


concierneconcierne1

0..*

0..*

1

fechanumero

nombre

nombre

1..*

0..1

numero

{congelado}



Vuelo

«metaclase»

{congelado}

define

ofrece1..* 0..*

Cliente


nombreapellido

1

0..*concierne

ha hecho

0..*

1 {congelado}

98


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


CASO DE ESTUDIO 2: PASO 6 - PROPUESTA ALTERNATIVA DE ESTRUCTURAR EL MODELO


0..*VueloGenerico


salida

llegada 0..*

0..* {ordenado}

1

10..*

escala

CompaniaAerea

0..*

1..*

Aeropuertonombre

Ciudad

atiende

Reserva


concierneconcierne1

0..*

0..*

1

fechanumero

nombre

nombre

1..*

0..1

numero

{congelado}



Vuelo

«metaclase»

{congelado}

define

ofrece1..* 0..*

Cliente


nombreapellido

1

0..*concierne

ha hecho

0..*

1 {congelado}

100


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:


fechanumero



VueloReserva

Reservas Vuelos

concierne0..*

{congelado}

1

101



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


fechanumero



VueloReserva

Reservas Vuelos

concierne0..*

{congelado}

1

102



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í



Vuelo

ProgramaVuelosReservas

ofreceVueloGenericodiahoraSalidahoraLlegada/duracionperiodoValidez

CompaniaAereanombre

«metaclase»

0..*

0..*

describe

103


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}


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}



Vuelo

«metaclase»

define

ofrece1..* 0..*

Reserva


fechanumero

Cliente


nombreapellido

1

0..*concierne

ha hecho0..*

1 {congelado}

Vuelos

Reservas

105


19. DIAGRAMA DEESTADOS (CASO

PRÁCTICO)

106



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


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


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


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


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


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


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)


insertarMoneda(25c)

colgar

:Usuario

comienzaComun

finalizarComun

verificarMoneda

incrementarCredito(25c)


Calcular(25c)

incrementarCredito(25c)

UT

Calcular(25c)

113


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


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


Mensajes

Sistema

115


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




:Usuario

:Central

:Telefono pago

descolgarElTelefonoinsertarMoneda(m)

marcarNumero(num)Colgar

vozDelUsuario

encaminarNumero(num)finalizarComun

vozPersonaLlamadatiempoMarcado


devolverMonedasNoUsadas

comenzarComunUT

tonoLlamada(tipo)vozPersonaLlamadavalidezDelNumero(v)

finalizarComuntiempoLimiteMarcado

Mensajes parametrizados

Sistema

117


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


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


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


CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO Solución Básica



Esperandonúmero


marcarNúmero


Comunicación

númeroVálido

ComienzaComunicación

colgarReceptor

descolgarReceptor

colgarReceptor

colgarReceptor

121


CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO Solución más elaborada



Esperandonúmero


marcarNúmero


Comunicación

númeroVálido

comienzaComunicación

colgarReceptor

descolgarReceptor

Receptor descolgado

Superestado

Transiciónfactorizada

122


CASO DE ESTUDIO 3: PASO 4 - REPRESENTAR EL HECHO DE QUE EL USUARIO PUEDE COLGAR ENCUALQUIER MOMENTO Solución aún más elaborada



Esperandonúmero


marcarNúmero


Comunicación

númeroVálido

comienzaComunicación

colgarReceptor

descolgarReceptorReceptor descolgado

Estadoinicial

123


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


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



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



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



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


CASO DE ESTUDIO 3: PASO 4 - COMPLETAR LA GESTIÓN DEL CRÉDITO DEL USUARIOSolución para la gestión del crédito



Esperandonúmero


marcarNúmero


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


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





Esperandonúmero


marcarNúmero


Comunicación

númeroVálido


colgarReceptor


Receptor descolgado



Comunicación


Factorización de laauto-transición

131



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


CASO DE ESTUDIO 3: PASO 4 - SOLUCIÓN CORRECTA CON LA TRANSICIÓN INTERNAFACTORIZADA



Esperandonúmero


marcarNúmero


Comunicación

númeroVálido


colgarReceptor


Receptor descolgadoinsertarMoneda(m)/incrementarCrédito(m)


Comunicación


Factorización en unatransición nterna

133


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


CASO DE ESTUDIO 3: PASO 4 - SOLUCIÓN CORRECTA CON LA AUTO-TRANSICIÓN Y EL PSEUDO-ESTADO «HISTORY»



Esperandonúmero


marcarNúmero


Comunicación

númeroVálido


colgarReceptor


Receptor descolgado



Comunicación


Pseudo-estado«history»

H

135


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



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



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




Esperandonúmero


marcarNúmero/enviar central.númeroRuta


Comunicaciónhacer/transmitirVoz

númeroVálido


colgarReceptor/devolverMonedas


Receptor descolgadoinsertarMoneda(m) [m OK]/incrementarCrédito(m)

UT[créditoSuficiente]/comprobar

Fin deComunicación o error


Cuando (crédito >= 25 c)/enviar central.temporizadorMarcado

estadoLínea(ocupado)

tiempoLímiteDeMarcado

númeroInválido

tiempoLímiteDeLlamado

El usuario cuelga

139


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




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

Documents

LENGUAJE UML 2 (PARTE 2)horacioamorena.com.ar/PAG DE MATERIAS Y LIBROS/LIBROS TODOS... · 3 LENGUAJE UML 2 (Continuación) 15) Arquitecturas dirigidas por Modelos (MDA). UML ejecutable: