Ejemplos UML

Tema 4

Grupo 46 TACC II Curso 2008/09 1

Indice
Cajeros Automáticos Sistema de Gestión de Tráfico Ferroviario
“Object-Oriented Analysis and Design with Applications, Third Edition” Grady Booch; Robert A. Maksimchuk; Michael W. Engle; Bobbi J. Young Ph.D.; Jim Conallen; Kelli A Houston Addison Wesley Professional 2007 A. Houston. Professional, 2007.

2

Ejemplo de Análisis Orientado a Objetos j p j
ATMs
Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs), que serán compartidos por un consorcio de bancos. Cada banco dispone de una serie de servidores, provistos de software propio, que llevan la información sobre sus cuentas y procesa las transacciones que actúan sobre dichas cuentas A estos servidores cuentas. están conectados las estaciones de cajero, que son propiedad del banco y en las que operan cajeros humanos, que pueden crear cuentas e introducir transacciones sobre ellas. Los cajeros automáticos aceptan tarjetas de crédito, interaccionan con el , p usuario, se comunican con un ordenador central para llevar a cabo las transacciones, entregan dinero en efectivo al usuario e imprimen recibos. El sistema llevará el registro de las transacciones efectuadas, cumplirá características aceptables de seguridad y manejará accesos concurrentes a la misma cuenta cuenta. El coste de desarrollo de la parte compartida del sistema se dividirá entre los bancos que forman parte del consorcio en función del número de clientes provistos de tarjetas de crédito. 3

Diagrama de Casos de Uso ATM <<extend>> Retirar Efectivo Depósito D ó it «actor» consorcio cliente banco Realizar Operación <<extend>> <<extend>> Transferencia <<include>> <<extend>> «actor» banco Información Validar Tarjeta y Clave 4 .

tarjeta itid l i Garantía de éxito (post-condiciones): La tarjeta se valida correctamente. así como una t j t emitida por el mismo. Consorcio: Q i C i Quiere id tifi identificar correctamente el b t t l banco d l cliente y del li t mediar en la validación de manera eficaz.Caso de Uso Validar Tarjeta y Clave (Refinado) Actores primarios: Cliente del Banco. Banco: Quiere identificar correctamente la identidad de la tarjeta. para lo que debe validar su tarjeta y contraseña. Consorcio. Precondiciones: El cliente tiene una cuenta en uno de los bancos del consorcio. Banco Interesados y Objetivos: I t d Obj ti Cliente del Banco: quiere realizar una operación con el ATM de manera rápida. 5 .

6. El cliente teclea la contraseña. 9 El consorcio notifica l aceptación al cajero automático. 9. 8. 2. El ATM envía el número de tarjeta. El ATM acepta la tarjeta de crédito y lee el número de tarjeta y el código del banco. el código del banco y la contraseña al consorcio.Caso de Uso Validar Tarjeta y Clave (Refinado) Escenario Principal de Éxito: p 1. El ATM pide al cliente que inserte la tarjeta de crédito. 4. El ATM pide la contraseña al cliente. 2 El cliente i li t inserta l t j t d crédito. 5. t la tarjeta de édit 3. 7. 7 El consorcio envía el número de tarjeta y la contraseña al banco correspondiente. El banco notifica la aceptación al consorcio. i ifi la ió l j ái 6 .

El ATM retene la tarjeta. etc. El consorcio notifica al banco que la tarjeta queda retenida. 4. 1. 3. El ATM notifica al cliente de que la tarjeta no se puede leer 2. El ATM notifica al consorcio que la tarjeta queda retenida.Caso de Uso Validar Tarjeta y Clave (Refinado) Escenario Alternativo: 3a. … (timeouts de teclado. El cajero automático notifica el rechazo al cliente y pide que teclee de nuevo la contraseña. El banco notifica el rechazo al consorcio. Se ha repetido este escenario alternativo menos de 3 veces y el flujo continua en 5 (en el escenario principal). El ATM notifica al cliente que la tarjeta q q j queda retenida. 3. 5. 2. Se ha repetido este escenario alternativo más de 3 veces: 1. 1 El consorcio notifica el rechazo al cajero automático. rotura de elementos mecánicos del cajero. 8a. La tarjeta es ilegible 1. El ATM vuelve a la situación inicial. El ATM expulsa la tarjeta. El ATM vuelve a la situación inicial. 3. 3a.) 7 . i tifi l h l j t áti 2. de comunicaciones.

5b. Se introduce la contraseña mediante un teclado o en la pantalla táctil.. . Recuperación robusta cuando el acceso mediante comunicaciones falla. Distintos tipos de tarjeta de crédito.Caso de Uso Validar Tarjeta y Clave (Refinado) Requisitos especiales: Pantalla táctil en panel grande y plano. 5a. creemos que se utilizarán otrás técnicas de identificación basadas en biometría. Lista de variaciones de tecnología y datos: 3a. El texto debe ser visible desde un 50cms. Temas abiertos: Explorar el tema de recuperación en caso de fallo de sistemas externos. Respuesta del ATM en menos de 5 secs.. el 90% de las veces. dependiendo de los bancos emisores. Posibilidades de internacionalización de texto. En el futuro. ¿Qué modificaciones se necesitan para idi Q é difi i it idiomas y paises di ti t ? i distintos? … 8 . Comunicaciones cifradas. bi tí Frecuencia de ocurrencia: Puede ser casi continua.

Banco: Quiere identificar correctamente la cuenta del cliente. Banco Interesados y Objetivos: Cliente del Banco: quiere retirar dinero de manera rápida.Caso de Uso Retirar Efectivo(Refinado) Actores primarios: Cliente del Banco. y contraseña. El cliente selecciona retirar efectivo. Consorcio: Quiere identificar correctamente el banco del cliente y mediar en la transacción de manera eficaz. transacción Precondiciones: El cliente tiene una cuenta en uno de los bancos del consorcio. y ésta se ha validado correctamente por el banco correspondiente. quiere que se anote la transacción en su cuenta de manera correcta. y anotar la transacción. Garantía d é it ( G tí de éxito (post-condiciones): t di i ) El cliente obtiene su dinero. quiere la devolución de su tarjeta y quizá un recibo de la transacción. Consorcio. 9 . la transacción se anota. ha introducido su tarjeta.

3. 7 El banco actualiza la cuenta cuenta. 10 . 9. El consorcio pasa la transacción al banco. 4. El cliente teclea una cantidad. El ATM entrega el dinero al cliente. p que 2. El ATM comprueba que la cantidad está dentro de los límites. 9 El consorcio envía al ATM la notificación de aceptación y el saldo saldo. El banco aprueba la transacción. 8. 6.Caso de Uso Retirar Efectivo(Refinado) Escenario Principal de Éxito: 1. 7. El ATM pide al cliente q teclee la cantidad. El banco envía al consorcio la notificación de aceptación y el nuevo saldo de la cuenta. 10. 4 El ATM genera una transacción y la envía al consorcio consorcio. 5.

Caso de Uso Retirar Efectivo(Refinado) 11. 19. 16. 11 . El cliente toma el recibo. El cliente toma la tarjeta de crédito. El cliente contesta NO. El cliente contesta SI. 12. 13. 17. El ATM vuelve a la situación inicial. El cliente toma el dinero. El ATM pregunta al cliente si quiere un recibo. El ATM pregunta al cliente si quiere hacer otra operación. 15. 14. 20. 18. El ATM imprime un recibo y pide al cliente que lo tome. El ATM expulsa la tarjeta de crédito e indica al cliente que la tome.

El consorcio envía al ATM la notificación de rechazo. 3 El ATM vuelve a la situación i i i l l l it ió inicial. 1.Caso de Uso Retirar Efectivo(Refinado) Flujos Alternativos: 2a. 4 Se vuelve al caso de uso “Realizar Operación” para que el Realizar Operación usuario seleccione un tipo de transacción. La cantidad excede el límite superior o inferior. 2. 1 El ATM expulsa la tarjeta de crédito e i di al cliente que l l l t j t d édit indica l li t la tome. 3a. El banco envía al consorcio la indicación de rechazo. 3. El ATM muestra un mensaje. 6a. 2. se vuelve a 1. El banco no aprueba la transacción. El cliente pulsa la tecla CANCELAR. 1. 4. 3. El cliente toma la tarjeta de crédito. 12 .

1 El ATM retiene el dinero y la tarjeta tarjeta. j 16a. 1. El ATM vuelve a la situación inicial. El cliente contesta NO y el flujo continua en 16. El cliente no toma el dinero después de 30 secs. El cliente toma el dinero y el flujo sigue en 11. El ATM muestra un mensaje al cliente. 5. etc. El cliente contesta SI y el flujo continua en el paso 1 del caso de uso “Realizar Operación” 13 … (timeouts de comunicaciones. 1 El ATM indica al cliente que tome el dinero y emite una señal sonora sonora. 3. 2. 2. 4. El consorcio notifica al banco de la retención. 2a.Caso de Uso Retirar Efectivo(Refinado) Flujos Alternativos: 11a. 1. rotura de elementos mecánicos del cajero. El usuario no toma el dinero después de 30secs. El ATM notifica al consorcio de la retención.) . 13a.

. El texto debe ser visible desde un 50cms. Recuperación robusta cuando el acceso mediante comunicaciones falla. Lista de variaciones de tecnología y datos: 2a. En lugar de imprimir un recibo se podría mandar un SMS o un e-mail. Posibilidades de internacionalización de texto. Frecuencia de ocurrencia: Puede ser casi continua. 12a..Caso de Uso Validar Tarjeta y Clave (Refinado) Requisitos especiales: Pantalla táctil en panel grande y plano. Temas abiertos: Explorar el tema de recuperación en caso de fallo de sistemas externos. Se teclea la cantidad mediante un teclado o en la pantalla táctil. el 90% de las veces. ¿Qué modificaciones se necesitan para idiomas y paises distintos? … 14 .. Comunicaciones cifradas. Respuesta del ATM en menos de 5 secs.

Modelo de Objetos Identificar objetos y clases Identificar y depurar relaciones Identificar atributos de objetos y relaciones Añadir herencia Comprobar los casos de uso (iterar) Modularizar Añadir y simplificar métodos 15 .

S l i b los i it Añadir clases adicionales procedentes de nuestro conocimiento d l d i i t i i t del dominio.Modelo de Objetos Identificar Objetos y Clases Seleccionar nombres en l requisitos. Eliminar clases irrelevantes. Resultado: Preparar diccionario de clases clases. Eliminar clases vagas. 16 . Separar métodos. Separar atributos. Eliminar objetos de diseño. Eliminar redundancias.

interaccionan con el .Modelo de Objetos Seleccionar Nombres en los Requisitos Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs). servidores están conectados las estaciones de cajero. se comunican con un ordenador central para llevar a cabo las transacciones. El coste de desarrollo de la parte compartida del sistema se dividirá entre los bancos que forman parte del consorcio en función del número de clientes provistos de tarjetas de crédito. que son propiedad del banco y en las que operan cajeros humanos. Los cajeros automáticos aceptan tarjetas de crédito. que serán compartidos por un consorcio de bancos. que pueden crear cuentas e introducir transacciones sobre ellas. que llevan la información sobre sus cuentas y procesa las transacciones que actúan sobre dichas cuentas A estos cuentas. entregan dinero en efectivo al usuario e imprimen recibos. Cada banco dispone de una serie de servidores. p usuario. El sistema llevará el registro de las transacciones efectuadas. cumplirá características aceptables de seguridad y manejará accesos concurrentes a la misma cuenta cuenta. provistos de software propio. 17 .

transacciones Características de seguridad. Cliente. Recibo. Cajero automático (ATM) (ATM). Cuenta bancaria. Transacción de cajero. Coste de desarrollo. bancaria Información sobre la cuenta. Ordenador central central. Cajero humano. Registro de transacciones. Acceso a la cuenta cuenta. S ft Red bancaria. édit Usuario. Dinero en efectivo. Tarjeta d T j t de crédito. 18 . Estaciones de cajero. Banco Servidores. Transacción Remota. Sistema. Parte compartida. Banco. Consorcio de bancos.Modelo de Objetos Seleccionar Nombres en los Requisitos Software.

Eliminar clases irrelevantes irrelevantes. Red bancaria y Parte compartida pueden considerarse vagas. 19 . Eliminar clases vagas. Coste de desarrollo no tiene nada que ver con el problema. N quedamos Cli t y U i la i l Nos d con Cliente por adaptarse mejor al concepto. Sistema. queda fuera del sistema.Modelo de Objetos Identificar Objetos y Clases Añadir Añ di clases adicionales procedentes l di i l d t nuestro conocimiento del dominio. Cliente Usuario son l misma clase. de i i de d Eliminar redundancias. Podemos añadir l clase Lí P d ñ di la l Línea d comunicaciones. Características de seguridad.

pueden considerarse atributos Información sobre la cuenta. Separar métodos Observación: algunos nombres ( Ob ió l b (por ejemplo. eliminaremos Registro de transacciones. Línea de 20 comunicaciones. Acceso a la cuenta y Software. Dinero en efectivo y ( j ). (atributo de Cuenta bancaria). que pasan a ser clases eliminadas. q p Recibo (atributos de Cajero automático). En el ejemplo. En el ejemplo. .Modelo de Objetos Identificar Objetos y Clases Separar atributos S t ib t Los atributos definen datos asociados a un objeto. en lugar de j ( j p ) objetos (un atributo objeto se representa mediante una relación). Eliminar objetos de diseño j Todas las clases que corresponden más a la solución del problema que a la situación real. deben considerarse objetos de diseño y eliminarse en la fase del análisis. Ll j l Llamada t l fó i ) d telefónica) definen realmente operaciones o eventos.

21 .Modelo de Objetos Identificar Objetos y Clases Cajero automático (ATM) C j t áti (ATM). Tarjeta de crédito. Cuenta bancaria. j . Cliente. bancaria Transacción. Banco Servidores. Estaciones de cajero cajero. Ordenador central. Consorcio de bancos. Cajero humano. Banco.

Modelo de Objetos Identificar Objetos y Clases Consorcio Banco Cuenta Cliente Ordenador Central Servidor del Banco Cajero Humano ATM Estaciones del Cajero Transacción Remota Transacción de Cajero Tarjeta de Crédito 22 .

envía esta información al ordenador central para su validación y proceso. Consorcio de bancos: Conjunto organizado de bancos que lleva la gestión de los cajeros automáticos. Ejemplo: Cajero automático (ATM): Terminal remoto que permite a los clientes realizar t li transacciones utilizando t j t d crédito para id tifi i tili d tarjetas de édit identificarse. i Banco: Institución financiera que maneja las cuentas bancarias de sus clientes y emite t j t li t it tarjetas d crédito que f ilit de édit facilitan el acceso a l dichas cuentas a través de la red de cajeros automáticos. y entrega al usuario dinero en efectivo y un recibo. El ATM interacciona con el cliente para identificar la transacción deseada y sus datos asociados. Suponemos que el ATM no opera cuando está desconectado de la red. 23 . Suponemos que sólo se gestionan transacciones para los bancos que pertenecen al consorcio.Modelo de Objetos Diccionario de Clases El diccionario de clases contiene la definición detallada de todas las clases en lenguaje natural.

Eliminar relaciones de diseño o entre clases eliminadas. Eliminar relaciones redundantes o derivadas. 24 . li i d Eliminar eventos transitorios. Definir la multiplicidad de cada relación. Añadir relaciones olvidadas.Modelo de Objetos Identificar y depurar relaciones Seleccionar verbos relacionales en l requisitos. Reducir relaciones ternarias. S l i b l i l los i it Añadir relaciones adicionales procedentes de nuestro conocimiento d l d i i t i i t del dominio.

3. 4. El Servidor dispone de Software. Cada Servidor procesa Transacciones. p 7. 9. 10. Las Estaciones de cajero están conectadas al Servidor. 12.El Cajero humano opera en la Estación de cajero.Los Cajeros automáticos aceptan Tarjetas de crédito. t áti 2. Una Red bancaria está provista de C j 1 U R db i tá i t d Cajeros automáticos.Identificar y Depurar Relaciones Seleccionar verbos relacionales en los requisitos 1. 6. Las Estaciones de cajero son propiedad del Banco. Cada Banco dispone de un Servidor. Cada Servidor lleva la información sobre las Cuentas bancarias.Los 14 Los Cajeros automáticos interaccionan con el Usuario Usuario. 8. 13. 5. 11.El Cajero humano crea Cuentas bancarias.El 12 El Cajero humano introduce Transacciones sobre las Cuentas bancarias. 14. El Consorcio de bancos comparte los Cajeros automáticos. Una Transacción actúa sobre una Cuenta bancaria. 25 .

Los Cajeros automáticos i L C j t áti imprimen R ib i Recibos. 17. Relaciones adicionales implícitas en el texto 25. 20. 15 16. El Sistema lleva el Registro de las transacciones. 26 27. 22. p Los Clientes están provistos de Tarjetas de crédito. 23. 18 19. 26 . Los Bancos forman parte del Consorcio. El O d Ordenador central pertenece al C d t l t l Consorcio. 24.Identificar y Depurar Relaciones Seleccionar verbos relacionales en los requisitos 15. El Coste de desarrollo se divide entre los Bancos. Los Cajeros automáticos comunican con el Ordenador central. 18. Los Cajeros automáticos entregan Dinero en efectivo al Usuario. El Sistema maneja Accesos concurrentes a la Cuenta bancaria. central El Ordenador central lleva a cabo las Transacciones. El Sistema cumple Características de seguridad. 26. i Los Bancos tienen Clientes. 21. Las Cuentas bancarias están en los Bancos.

q por: 16a. 22. 29. 19. 17. 27 . Otras veces conviene reformularlas. que debería sustituirse . Eliminar eventos transitorios: Son sucesos que pertenecen al modelo dinámico y no constituyen relaciones estructurales (estáticas) entre los objetos. 18. como en el caso de la número 16. números 1. Tras ejecutarse estas operaciones no se modifica la estructura de los objetos involucrados. 29 Los Cajeros humanos son empleados de los Bancos Bancos. involucrados Eliminamos las relaciones números 13 y 14. Las Tarjetas de crédito están asociadas a las Cuentas bancarias . El Ordenador central se comunica con el Banco. Eliminar relaciones de diseño o entre clases eliminadas: Las de diseño se dejan para la fase de diseño Eliminamos las relaciones diseño. 20. 4.Identificar y Depurar Relaciones Añadir relaciones adicionales procedentes de nuestro conocimiento del tema: 28. el Ordenador central lleva a cabo las Transacciones. 21.

El Cajero humano introduce Transacciones 12b. Por ejemplo la relación número 12 (El Cajero humano introduce ejemplo. El Usuario recoge el Dinero en efectivo. 17b. Transacciones sobre las Cuentas bancarias) puede descomponerse en: 12a. Muchas veces es posible descomponerlas en varias relaciones binarias (entre dos clases). si no es posible sí que se pueden utilizar atributos posible. de relación. De igual modo. la número 17 puede descomponerse así: 17a. 12b Las Transacciones actúan sobre las Cuentas bancarias bancarias. 28 . 17a Los Cajeros automáticos entregan Dinero en efectivo efectivo.Identificar y Depurar Relaciones Reducir Relaciones Ternarias Son relaciones entre tres o más clases clases.

pero q en realidad son que necesarias. Por ejemplo: 30. 29 .Identificar y Depurar Relaciones Eliminar relaciones redundantes o derivadas Por ejemplo. 32. . sin embargo. la relación número 2 es una combinación de las relaciones número 15 y 26. Hay que tener cuidado. Añadir relaciones olvidadas. Las Transacciones pueden introducirse en una Estación de cajero.. Un Cliente puede tener muchas Tarjetas de crédito crédito. Las Transacciones son autorizadas por la Tarjeta de crédito. p p . Las redundantes por ejemplo son las que se derivan de la propiedad transitiva para relaciones. Definir la multiplicidad de cada asociación Un Banco puede contener muchas Cuentas. Los Clientes tienen C 30 L Cli t ti Cuentas. Un Cliente puede tener muchas Cuentas. El Ordenador central se comunica con muchos Ordenadores del banco banco.. Un Banco emplea muchos Cajeros.. t 31. Un Banco tiene un solo Ordenador del banco. de no eliminar relaciones aparentemente redundantes.

* se comunica con Servidor del Banco 1 Cajero Humano 1 posee introducida por tiene tiene accede a se comunica con 0..* 0.* 0 * 0..* se comunica con 0..* Estaciones del Cajero introducida en Transacción de Cajero tiene 1 0.* 0 * Cuenta 1 1 0..Modelo de Objetos Diagrama de Clases inicial Consorcio 1 posee 1 0. 0 * Banco 1 posee 1 1 1 gestiona 0 * 0.. 1 trabaja en 0.* 0.. 0 * 1 1 tiene Cliente 1 Ordenador Central 1 1 0..* 0 * ATM 1 realizada en 0..* Transacción T ió Remota autorizada por Tarjeta d T j t de 30 Crédito .* 0 * 0.* 0 * 1 0....* 0..* 0.....

puede convenir dividir la clase en dos) 31 .Identificar Atributos de Objetos y Relaciones Distinguir los objetos de los atributos Distinguir entre los atributos de objetos y de relaciones Eliminar atributos privados (d di ñ ) Eli i t ib t i d (de diseño) Eliminar at butos de deta e fino a atributos detalle o Localizar atributos discordantes (muy diferentes de los demás p ede con enir demás.

Límite de crédito. Atributos de las relaciones (la multiplicidad de la relación queda sobreentendida al usar un "código") 8 y 9: Código de la estación de cajero. 32 . Cantidad entregada disponible entregada. 25: Código de la cuenta. Fecha y hora. Del Cliente: Nombre. De una Transacción del cajero: Tipo. Dirección Nombre Dirección. De la Tarjeta de crédito: Clave. 23: Código del banco.Identificar Atributos de Objetos y Relaciones Atributos de los objetos Del Banco: Nombre. Del Cajero: Nombre. Fecha y hora. g j 15: Código del cajero automático. Del Cajero automático: Efectivo disponible. 16a: Código del banco. Cantidad. Cantidad. De una Transacción remota: Tipo. De la Cuenta: Saldo. Código de la tarjeta. g 29: Código de empleado. Tipo de cuenta.

.* Cajero Humano nombre 1 tiene accede a ATM disponible entregado 1 realizada en 0......* Banco nombre 1 posee 1 1 1 gestiona 0.* 0...* 0 * se comunica con 0.* & tiene Cliente 1 nombre dirección 1 1 trabaja en 0..* 0 * introducida por 0 * 0 * 0.* 0 * 1 0..* Cuenta saldo Limite tipo 1 1 tiene 0..* Estaciones del Cajero Transacción de Cajero introducida en tipo ti fecha_hora cantidad 0.* Transacción Remota tipo fecha_hora cantidad 0. atributos Consorcio 1 1 posee 1 se comunica con 0....* .* 1 Servidor del Banco 1 posee 0.* 0 * Ordenador Central 1 se comunica con 0.* 0..Modelo de Objetos Diagrama de Clases..* 0.* tiene autorizada por Tarjeta de Crédito clave 33 1 codigo tajeta 0.

a menos que sea estrictamente necesaria.Añadir Herencia Introducimos clases nuevas (quizá abstractas) que contienen información común a dos o más clases preexistentes. Podrían refinarse los tipos de cuentas 34 . La clase Transacción será superclase de Transacción de cajero y de Transacción remota remota. necesaria Resultado: Primer diagrama de clases En el ejemplo: La clase Estación de entrada será superclase de Cajero automático y de Estación de cajero. Procurar evitar la herencia múltiple.

* Tarjeta de Crédito clave codigo tarjeta 35 1 autorizada por ...Modelo de Objetos Diagrama de Clases....* 0 * Servidor del Banco 1 posee 0.* 0.* nombre dirección 1 1 Ordenador Central 1 se comunica con 0.* Cuenta saldo limite tipo 1 1 trabaja en 0...* 1 introdu ucida en Cajero Humano nombre 1 introducida por 0.. herencia Consorcio 1 1 p posee 1 se comunica con 0.* 0.* 0 * 0....* accede a tiene ATM disponible entregado se comunica con 0..* tiene Transacción Remota 0..* Banco nombre 1 posee 1 1 1 gestiona 0...* Estacion de Entrada Estaciones del Cajero 0.* tiene Cliente 1 0. 0 * Transacción de Cajero 0.* 1 realizada en & tiene Transacción tipo fecha_hora f h h cantidad 0.

Clases sin atributos. que representa la forma en que una compañía contrata a una persona) Operaciones que no encuentran camino para realizarse: añadir relaciones. Relaciones demasiado detalladas o demasiado vagas: subirlas a una g superclase o bajarlas a una subclase. 36 . sin métodos o sin relaciones: eliminarlas. Atributos d l At ib t de clase necesarios en un acceso: pasarlos a atributos d relación i l t ib t de l ió (por ejemplo el código). Conversión de relaciones en clases: por ejemplo. Relaciones redundantes: eliminarlas.Comprobar los Casos de Uso (iterar) Para localizar fallos que deben corregirse fijarse en: Atributos muy dispares (discordantes): descomponer una clase en dos. Relaciones que nadie atraviesa: eliminarlas. Operaciones sin objetivo: añadir clase con estas operaciones como métodos de l d clase. clase Empleado (clase asociación para una relación entre las clases Persona y Compañía.

Comprobar los Casos de Uso (iterar)
En el ejemplo de los cajeros automáticos: Tarjeta de crédito desempeña dos roles: la tarjeta física, que se introduce y que permite al cajero automático conectarse con el banco, con información sobre el mundo real (banco, número de la tarjeta) y las autorizaciones concedidas por éste, que sólo son números en la memoria de un ordenador y se pueden cambiar con facilidad (contraseña, límite de crédito). Se puede descomponer en Tarjeta de crédito y Autorización de la tarjeta Una sola tarjeta. autorización puede afectar a más de una tarjeta física. Una misma autorización puede permitir acceder a más de una cuenta (y viceversa). Introducimos l clase A t li I d i la l Actualización d cuenta para refinar el concepto d ió de t fi l de Transacción. Una misma transacción puede estar compuesta de varias actualizaciones de cuenta (por ejemplo, transferencia entre cuentas son ) dos actualizaciones). No hay distinción significativa entre Banco y Ordenador del banco, por una parte, y entre Consorcio y Ordenador central, por otra. Fusionamos esas clases. clases
37

Modelo de Objetos
Diagrama de Clases, Iteración
0..* realizada en 1..*

Transacción
fecha_hora

Actualización
cantidad tipo 0..*

1

Estacion de Entrada Estaciones del Cajero
0..* posee posee 1 1

Transacción De Cajero
Intro. por 0..* 1

Transacción Remota
comenzada por 0..* 1..* 1

ATM
disponible entregado 0..* 1

Cajero Humano H
nombre trabaja 0..* en emite 1 1

Autorización

tiene 1

0..* clave limite 0..* 1

Consorcio

Banco
nombre 0..*

Cliente
gestiona nombre dirección 1 tiene 1..* 1..*

Aut. Aut 1..* por

Tarjeta de Crédito
codigo banco codigo tarjeta numero tiene

Cuenta
0..* saldo limite tipo 1
38

Modularizar
Agrupar clases en módulos. A l ód l En el ejemplo de los cajeros a tomáticos automáticos. Posibles módulos:
Cajeros en general: Cajero Estación de cajero, ATM Cajero, cajero ATM, Estación de entrada. Cuentas en general: Cuenta, Tarjeta de crédito, Autorización, Cliente, Transacción, Autorización Cliente Transacción Transacción de cajero, Transacción remota. Bancos: Banco, Consorcio.

Resultado: Diagrama de Paquetes
39

Diagrama de Paquetes Cajeros Cuentas Bancos 40 .

Modelo Dinámico Consta de los siguientes pasos: Identificar sucesos Construir diagramas de estados Comprobar consistencia (iterar) Añadir métodos 41 .

Identificar Mensajes Los L mensajes se extraen d l casos d uso j t de los de (escenarios). 42 . Pueden ser de los siguientes tipos: Señales S ñ l Entradas Decisiones Interrupciones Transiciones Acciones externas Condiciones de error Resultados: Diagramas de secuencia y de colaboración.

Diagrama de Secuencia Validar Tarjeta y Clave :Usuario insertar tarjeta pedir clave intro clave :ATM :Consorcio :Banco verificar cuenta verificar tarjeta con banco cuenta del banco valida cuenta valida 43 .

Transacción del Banco Transacción del Banco OK Transacción OK Entregar dinero Petición tomar dinero Tomar dinero Imprimir Recibo Petición continuación Terminar Expulsar Tarjeta Petición Recogida Tarjeta Mostrar Pantalla Principal :Consorcio :Banco :Usuario 44 . transacción Proc.Diagrama de Secuencia Retirar Efectivo R ti Ef ti :ATM pedir cantidad intro cantidad Proc.

Identificar Mensajes Los casos de uso (escenarios) se convierten en diagramas de secuencia. El cajero automático entrega el dinero al cliente es el mismo mensaje independientemente de la cantidad entregada. 45 . El cajero automático entrega el dinero al cliente es un evento que el objeto Cajero g q j j automático envía al objeto Cliente. Estas se compactan en diagramas de colaboración. En el ejemplo de los cajeros automáticos: El cliente introduce la contraseña define un mensaje de entrada que el objeto Cliente envía al objeto Cajero automático. Agrupar los mensajes equivalentes: El cliente introduce la contraseña es el mismo evento independientemente de la contraseña introducida. g No agrupar los mensajes no equivalentes: El banco autoriza la q transacción es distinto evento que El banco rechaza la transacción.

En el ejemplo de los cajeros automáticos centrarse en las clases dinámicas.Construir Diagramas de Estado Uno por clase. Determinar los eventos que provocan transiciones clase entre estados. que no forman parte del sistema informático: Cliente Cajero humano 46 . q que no cambian de estado de modo significativo: g Tarjeta de crédito Transacción Cuenta Tampoco hace falta considerar a fondo los objetos externos. dinámicas que cambian de estado: Cajero automático Banco Consorcio Estación de cajero No hace falta construir diagramas de estado de las clases pasivas.

Modelo de Objetos Diagrama de Transición Estados. clase ATM codigo_error 47 .

Modelo de Objetos Diagrama de Transición Estados. trans) [ [res==OK]/consorcio.bad_password(tarjeta) [res==OK]/consorcio. clase Banco Banco procesar_transaccion(tarjeta.cuenta_ok(tarjeta) 48 . trans) esperando verificar(tarjeta.cuenta_invalida(tarjeta) Actualizando Cuenta do/res=actualizar_cuenta(tarjeta.transaccion_ok(tarjeta) ] ( j ) [res==BAD]/consorcio. password) Verificar Tarjeta entry/res=verificar_numero(tarjeta) [res==OK] Verificar Clave entry/res=verificar_password(password) [res==BAD]/consorcio.transaccion_fallo(tarjeta) [res==BAD]/consorcio.

Modelo de Objetos Diagrama de Transición Estados. clase Consorcio 49 .

Ejercicio ¿Son consistentes los diagramas anteriores entre sí? ¿Son consistentes con los casos de uso? Añadir la información d l casos Añ di l i f ió de los alternativos y excepciones (timeouts. etc.) 50 .

Arquitectura Diagrama de Despliegue 51 .

que permita incrementar el tráfico de trenes.Sistema de Control de Tráfico Ferroviario (SCTF) Sistema para el control d t áfi f Si t l t l de tráfico ferroviario (d i i (de pasajeros y carga). 52 . Objetivos: Reducir costes de operación y mejorar el uso de recursos. Automatización del enrutado de trenes y monitorización de todos los elementos del sistema del tren tren. así como la programación predecible de horarios.

Sistema de Control de Tráfico Ferroviario Requisitos Problema: requisitos poco claros y contradictorios. Sistema complejo. 53 . Riesgo d “ áli i en el análisis”. para aprovechar avances en el h d h l hardware. varios años de desarrollo: permitir cierto grado de cambio en los requisitos. P bl i it l t di t i Se hace necesario un modelo de desarrollo iterativo e incremental. Metodología RUP. d d que el número Ri de “parálisis l áli i ” dado l ú de requisitos es muy grande.

Otras funciones relacionadas: Planificación del tráfico. Seguimiento de la posición de los trenes. Evitar li i E it colisiones. Registro de mantenimiento.Sistema de Control de Tráfico Ferroviario Requisitos: Comienzo (“Inception”) Dos funciones principales: enrutado d D f i i i l t d de trenes y monitorización. 54 . Predicción de fallos fallos.

automáticos y manuales para evitar colisiones de trenes. Seguimiento del tráfico: Monitorización del tráfico de trenes en una región geográfica. Seguimiento de Trenes: Seguir la posición de los trenes usando los recursos del SCTF. Controlar los Sistemas del Tren: Controlar los sistemas de a p q bordo del tren para verificar que funcionan correctamente.Sistema de Control de Tráfico Ferroviario Casos de Uso Enrutar Tren: Establecer un plan para un tren que define el tren. Predicción de Fallos: Realizar un análisis del estado de los sistemas del tren para predecir la probabilidad de fallo relativa al plan del tren. recorrido de un tren particular Planificar Tráfico: Establecer un plan de tráfico que provea una guía en el desarrollo de rutas para trenes en un periodo de tiempo para una región geográfica. ió áfi Evitar colisiones: Proporcionar los medios. Registro de Mantenimiento: Proporcionar l medios para anotar R i t d M t i i t P i los di t el mantenimiento realizado en los trenes. así como GPS. 55 .

Proporcionar una disponibilidad del sistema al nivel del 99. Proporcionar redundancia funcional completa para las capacidades del SCTF. Soporte de velocidades de tren de hasta 250 millas por hora (400 km/hora). Restricciones: Seguimiento de los estándares nacionales. Respuesta a las órdenes del operador en menos de 1.Sistema de Control de Tráfico Ferroviario Requisitos no Funcionales y Restricciones Requisitos no Funcionales: Transporte de manera segura de pasajeros y cargamento. Proporcionar precisión en la posición del tren de 10 yardas (9 metros). Asegurar la máxima reutilización y compatibilidad con el equipamiento existente.0 segundos. Maximizar el uso de componentes COTS (commercial-off-the-shelf) hardware y software. Interoperar con sistemas de gestión de tráfico en las fronteras del SCTF. Proporcionar precisión en la velocidad del tren de 1.5 millas/hora (2. governamentales e industriales.99%. h d ft 56 .5 opo c o a p ec s ó e a e oc dad de e 5 as/ o a ( 5 km/hora). Facilidad de mantenimiento y evolución del SCTF.

Maquinista (Train Engineer): Monitoriza el estado del tren y opera el mismo. 57 . d i los i del GPS Navstar: P N t Proporciona l servicios d l i los i i de localización li ió para el seguimiento de los trenes. p Operario de Mantenimieno (Maintainer): Monitoriza el estado y mantiene l sistemas d l tren.Sistema de Control de Tráfico Ferroviario Actores Controlador (Dispatcher): E t bl C t l d (Di t h ) Establece l rutas d l las t de los trenes y sigue el progreso de los trenes individuales.

Sistema de Control de Tráfico Ferroviario Diagrama de Casos de Uso Soporte para la intervención manual y automática 58 .

El SGTF presenta una plantilla para un plan de tren al controlador. El controlador selecciona desarrollar un nuevo plan para un tren. El SGTF hace accesible el plan para consulta y modificación modificación. locomotora.Caso de Uso: Enrutar Tren Propósito: Establecer un plan para el tren que actúe como repositorio para toda la información asociada con la ruta de un tren específico y las acciones que sucedan en el camino. los ingenieros ferroviarios y puntos de paso con tiempos. 2. Los distintos recursos pueden no ser usables por más de un plan de tren en un cierto inter alo de tiempo sables n n intervalo tiempo. Contacto: Pedro Pérez Fecha de modificación: 9/5/06 Pre-condiciones: Pre condiciones: Existe un plan de tráfico para el intervalo de tiempo y la región geográfica relevante al plan que se está elaborando. 4 El controlador completa la plantilla dando información sobre el ID de la locomotora plantilla. 4. 59 . 3. Escenario Principal: 1. Limitaciones: Cada tren tiene un ID único en el sistema. que detalla su ruta de viaje. Post-condiciones: Se estableció el plan para el tren. 5. 6. El SGTF presenta al controlador una lista de opciones. El SGTF asigna un ID único al plan de tren y lo almacena. El controlador introduce el plan completado en el SGTF. Suposiciones: Un plan de tren es accesible por los controladores para su consulta y modificación y accesible a los ingenieros ferroviarios para consulta.

El controlador completa un plan. 8. Modificación de un plan existente 2b. 5. El SGTF proporciona los resultados de la búsqueda. existentes 4. El controlador proporciona unos criterios de búsqueda para encontrar planes existentes. 3. 60 . 2b El controlador selecciona modificar un plan existente existente. 5. 7. El controlador selecciona un plan. Se sigue en el escenario principal en el paso 5. p p 7. El controlador selecciona un plan. basado en uno existente. El controlador proporciona unos criterios de búsqueda para encontrar planes existentes. 3. El controlador selecciona desarrollar un nuevo plan de tren. 8 El SGTF almacena el plan modificado y lo accesible para consulta y modificación modificación.Caso de Uso: Enrutar Tren Escenarios Alternativos Desarrollo de un plan basado en uno existente: 2a. El controlador modifica el plan. 6. 6. El controlador introduce el plan modificado en el SGTF. El SGTF proporciona los resultados de la búsqueda. 4.

El SCTF presenta al maquinista información de estado de los sistemas de tren. Postcondiciones: El sistema muestra información sobre el funcionamiento de los sistemas a bordo del tren. Contacto: Pedro Pérez Fecha de modificación: 10/5/06 Precondiciones: La locomotora está funcionando. ió de t d 61 . Suposiciones: La visualización del estado de los sistemas se proporciona cuando la locomotora está funcionando. 4. El maquinista elige controlar los sistemas del tren. Limitaciones: Ninguna identificada. 4 El maquinista revisa l i f i i t i la información d estado. 2. El SCTF presenta al maquinista una serie de opciones. El sistema proporciona señales audibles y visibles (resalta en amarillo los sistemas problemáticos) sobre los problemas del sistema. 3.Caso de Uso: Controlar los Sistemas del Tren Propósito: Controlar los dispositivos a bordo del tren para asegurar su funcionamiento correcto. Escenario Principal: p q p 1.

El mantenedor solicita al SCTF que alerte al maquinista de esta decisión. El mantenedor solicita revisar los resultados del análisis.Caso de Uso: Controlar los Sistemas del Tren Escenarios Alternativos Pedir visualización detallada del sistema 5. 11. 16. El maquinista pide al SCTF que alerte al mantenedor del sistema que puede fallar. 62 . 19. El SCTF avisa al mantenedor del sistema. El escenario alternativo “Pedir Visualización Detallada del Sistema” se continua en el paso 6. 17. El SCTF realiza un análisis de predicción de fallos para el sistema. 9. El maquinista elige realizar una visualización del sistema seleccinado. 14. El mantenedor revisa el análisis y determina que la condición de color amarillo no es lo suficientemente grave como para requerir acción inmediata. 7a. 18. 8. El SCTF muestra la decisión al maquinista. El SCTF presenta al maquinista el resultado del análisis. 7. 15. 6. El maquinista revisa la información detallada proporicionada. 8. 13. El SCTF le presenta la información del análisis de la predicción. El maquinista revisa el análisis. 12. El maquinista solicita un análisis de predicción de fallos para el sistema. El maquinista elige visualizar de manera detallada un sistema que muestra su estado en amarillo. 10. Se sigue en el paso 2 del escenario principal Extensión: Solicitar un análisis de predicción de fallos para un sistema. El SCTF presenta al maquinista información detallada del estado del sistema seleccionado.

Análisis de la Funcionalidad del Sistema RUP: Elaboración Caso de uso enrutar tren 63 .

Análisis de la Funcionalidad F i lid d del Sistema RUP: Elaboración Caso de uso controlar los sistemas del tren y escenario alternativo lt ti 64 .

Análisis de la Funcionalidad del Sistema Elaboración Diagrama de visión conjunta de la interacción que muestra la relación entre los distintos escenarios del caso d uso “ de “controlar l t l los sistemas del tren” 65 .

Definición de la Arquitectura 66 .

Ingeniería de Sistemas 67 .

Definición de la Arquitectura 68 .

Visualización de información. Base de Datos. Vías de tren: perfil grado dispositivos de rail perfil. Interfaz hombre-máquina. Planificación de los horarios del tren. Planes: horarios. rail. Control en tiempo real de dispositivos analógicos y digitales. 69 . grado. Adquisición de datos de los sensores. permisos. p p g g Hay tres abstracciones comunes: Trenes: incluye vagones y locomotoras. Mecanismos para las abstracciones: Paso de mensajes. autoridad y asignación de personal.Abstracciones y Mecanismos Análisis de dominio El sistema comprende cuatro abstracciones o mecanismos principales: Red y Comunicaciones. órdenes.

Construcción Diseño de la Arquitectura Paso d mensajes: P de j Entre ordenadores y dispositivos. fallos de equipos y q p seguridad. Red distribuida: distrib ida contemplar ruido. p Entre ordenadores. 70 .

Mecanismo de Paso de Mensajes 71 .

Cada plan se asigna a un tren. Un plan puede puede implicar varias órdenes y posiciones en las vías.Planificación de horarios Cada tren tiene un plan activo. 72 .

Time Location 0800 Pueblo 1300 Denver 1600 Pueblo Speed Authority Orders Set out 30 cars Set out 20 cars Return to yard As posted See yardmaster Depart yard 45 mph p As posted 1100 Colorado Springs 40 mph 73 .Planificación de horarios Ejemplo de las acciones que puede contener un plan.

Planificación de horarios 74 .

Visualización de Información 75 .

Arquitectura del Sistema 76 .

Sign up to vote on this title
UsefulNot useful