Ejemplos UML

Tema 4

Grupo 46 TACC II Curso 2008/09 1

Indice
Cajeros Automticos Sistema de Gestin de Trfico 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.

Ejemplo de Anlisis Orientado a Objetos j p j

ATMs
Se desea disear el software necesario para una red bancaria provista de cajeros automticos (ATMs), que sern compartidos por un consorcio de bancos. Cada banco dispone de una serie de servidores, provistos de software propio, que llevan la informacin sobre sus cuentas y procesa las transacciones que actan sobre dichas cuentas A estos servidores cuentas. estn 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 automticos aceptan tarjetas de crdito, 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 caractersticas 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 funcin del nmero de clientes provistos de tarjetas de crdito. 3

Diagrama de Casos de Uso

ATM
<<extend>>

Retirar Efectivo Depsito D it

actor

consorcio

cliente banco

Realizar Operacin

<<extend>> <<extend>>

Transferencia
<<include>> <<extend>>

actor

banco Informacin

Validar Tarjeta y Clave

Caso de Uso
Validar Tarjeta y Clave (Refinado)
Actores primarios: Cliente del Banco, Consorcio, Banco Interesados y Objetivos: I t d Obj ti Cliente del Banco: quiere realizar una operacin con el ATM de manera rpida, para lo que debe validar su tarjeta y contrasea. 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 validacin de manera eficaz. Banco: Quiere identificar correctamente la identidad de la tarjeta. Precondiciones: El cliente tiene una cuenta en uno de los bancos del consorcio, as como una t j t emitida por el mismo. tarjeta itid l i Garanta de xito (post-condiciones): La tarjeta se valida correctamente.
5

Caso de Uso
Validar Tarjeta y Clave (Refinado)

Escenario Principal de xito: p 1. El ATM pide al cliente que inserte la tarjeta de crdito. 2. 2 El cliente i li t inserta l t j t d crdito. t la tarjeta de dit 3. El ATM acepta la tarjeta de crdito y lee el nmero de tarjeta y el cdigo del banco. 4. El ATM pide la contrasea al cliente. 5. El cliente teclea la contrasea. 6. El ATM enva el nmero de tarjeta, el cdigo del banco y la contrasea al consorcio. 7. 7 El consorcio enva el nmero de tarjeta y la contrasea al banco correspondiente. 8. El banco notifica la aceptacin al consorcio. 9. 9 El consorcio notifica l aceptacin al cajero automtico. i ifi la i l j i
6

Caso de Uso
Validar Tarjeta y Clave (Refinado)
Escenario Alternativo: 3a. La tarjeta es ilegible 1. El ATM notifica al cliente de que la tarjeta no se puede leer 2. El ATM expulsa la tarjeta. 3. El ATM vuelve a la situacin inicial. 8a. El banco notifica el rechazo al consorcio. 1. 1 El consorcio notifica el rechazo al cajero automtico. i tifi l h l j t ti 2. El cajero automtico notifica el rechazo al cliente y pide que teclee de nuevo la contrasea. 3. Se ha repetido este escenario alternativo menos de 3 veces y el flujo continua en 5 (en el escenario principal). 3a. Se ha repetido este escenario alternativo ms de 3 veces:
1. El ATM retene la tarjeta. 2. El ATM notifica al cliente que la tarjeta q q j queda retenida. 3. El ATM notifica al consorcio que la tarjeta queda retenida. 4. El consorcio notifica al banco que la tarjeta queda retenida. 5. El ATM vuelve a la situacin inicial.

(timeouts de teclado, de comunicaciones, rotura de elementos mecnicos del cajero, etc.)

Caso de Uso
Validar Tarjeta y Clave (Refinado)
Requisitos especiales: Pantalla tctil en panel grande y plano. El texto debe ser visible desde un 50cms. Respuesta del ATM en menos de 5 secs, el 90% de las veces. Recuperacin robusta cuando el acceso mediante comunicaciones falla. Posibilidades de internacionalizacin de texto. Comunicaciones cifradas. ... Lista de variaciones de tecnologa y datos: 3a. Distintos tipos de tarjeta de crdito, dependiendo de los bancos emisores. 5a. Se introduce la contrasea mediante un teclado o en la pantalla tctil. 5b. En el futuro, creemos que se utilizarn otrs tcnicas de identificacin basadas en biometra. bi t Frecuencia de ocurrencia: Puede ser casi continua. Temas abiertos: Explorar el tema de recuperacin en caso de fallo de sistemas externos. Qu modificaciones se necesitan para idi Q difi i it idiomas y paises di ti t ? i distintos?

Caso de Uso
Retirar Efectivo(Refinado)
Actores primarios: Cliente del Banco, Consorcio, Banco Interesados y Objetivos: Cliente del Banco: quiere retirar dinero de manera rpida, quiere que se anote la transaccin en su cuenta de manera correcta, quiere la devolucin de su tarjeta y quiz un recibo de la transaccin. Consorcio: Quiere identificar correctamente el banco del cliente y mediar en la transaccin de manera eficaz. Banco: Quiere identificar correctamente la cuenta del cliente, y anotar la transaccin. transaccin Precondiciones: El cliente tiene una cuenta en uno de los bancos del consorcio, ha introducido su tarjeta, y contrasea, y sta se ha validado correctamente por el banco correspondiente. El cliente selecciona retirar efectivo. Garanta d it ( G t de xito (post-condiciones): t di i ) El cliente obtiene su dinero, la transaccin se anota.

Caso de Uso
Retirar Efectivo(Refinado)

Escenario Principal de xito:

1. El ATM pide al cliente q teclee la cantidad. p que 2. El cliente teclea una cantidad. 3. El ATM comprueba que la cantidad est dentro de los lmites. 4. 4 El ATM genera una transaccin y la enva al consorcio consorcio. 5. El consorcio pasa la transaccin al banco. 6. El banco aprueba la transaccin. 7. 7 El banco actualiza la cuenta cuenta. 8. El banco enva al consorcio la notificacin de aceptacin y el nuevo saldo de la cuenta. 9. 9 El consorcio enva al ATM la notificacin de aceptacin y el saldo saldo. 10. El ATM entrega el dinero al cliente.

10

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

11

Caso de Uso
Retirar Efectivo(Refinado)
Flujos Alternativos: 2a. El cliente pulsa la tecla CANCELAR. 1. 1 El ATM expulsa la tarjeta de crdito e i di al cliente que l l l t j t d dit indica l li t la tome. 2. El cliente toma la tarjeta de crdito. 3. 3 El ATM vuelve a la situacin i i i l l l it i inicial. 3a. La cantidad excede el lmite superior o inferior, se vuelve a 1. 6a. El banco no aprueba la transaccin. 1. El banco enva al consorcio la indicacin de rechazo. 2. El consorcio enva al ATM la notificacin de rechazo. 3. El ATM muestra un mensaje. 4. 4 Se vuelve al caso de uso Realizar Operacin para que el Realizar Operacin usuario seleccione un tipo de transaccin.

12

Caso de Uso
Retirar Efectivo(Refinado)
Flujos Alternativos: 11a. El usuario no toma el dinero despus de 30secs. 1. 1 El ATM indica al cliente que tome el dinero y emite una seal sonora sonora. 2. El cliente toma el dinero y el flujo sigue en 11. 2a. El cliente no toma el dinero despus de 30 secs. 1. 1 El ATM retiene el dinero y la tarjeta tarjeta. 2. El ATM muestra un mensaje al cliente. 3. El ATM notifica al consorcio de la retencin. 4. El consorcio notifica al banco de la retencin. 5. El ATM vuelve a la situacin inicial. 13a. El cliente contesta NO y el flujo continua en 16. j 16a. El cliente contesta SI y el flujo continua en el paso 1 del caso de uso Realizar Operacin
13 (timeouts de comunicaciones, rotura de elementos mecnicos del cajero, etc.)

Caso de Uso
Validar Tarjeta y Clave (Refinado)
Requisitos especiales: Pantalla tctil en panel grande y plano. El texto debe ser visible desde un 50cms. Respuesta del ATM en menos de 5 secs, el 90% de las veces. Recuperacin robusta cuando el acceso mediante comunicaciones falla. Posibilidades de internacionalizacin de texto. Comunicaciones cifradas. ... Lista de variaciones de tecnologa y datos: 2a. Se teclea la cantidad mediante un teclado o en la pantalla tctil. 12a. En lugar de imprimir un recibo se podra mandar un SMS o un e-mail.

Frecuencia de ocurrencia: Puede ser casi continua. Temas abiertos: Explorar el tema de recuperacin en caso de fallo de sistemas externos. Qu modificaciones se necesitan para idiomas y paises distintos?
14

Modelo de Objetos
Identificar objetos y clases Identificar y depurar relaciones Identificar atributos de objetos y relaciones Aadir herencia Comprobar los casos de uso (iterar) Modularizar Aadir y simplificar mtodos
15

Modelo de Objetos
Identificar Objetos y Clases

Seleccionar nombres en l requisitos. S l i b los i it Aadir clases adicionales procedentes de nuestro conocimiento d l d i i t i i t del dominio. Eliminar redundancias. Eliminar clases irrelevantes. Eliminar clases vagas. Separar atributos. Separar mtodos. Eliminar objetos de diseo. Resultado: Preparar diccionario de clases clases.
16

Modelo de Objetos
Seleccionar Nombres en los Requisitos
Se desea disear el software necesario para una red bancaria provista de cajeros automticos (ATMs), que sern compartidos por un consorcio de bancos. Cada banco dispone de una serie de servidores, provistos de software propio, que llevan la informacin sobre sus cuentas y procesa las transacciones que actan sobre dichas cuentas A estos cuentas. servidores estn 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 automticos aceptan tarjetas de crdito, 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 caractersticas 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 funcin del nmero de clientes provistos de tarjetas de crdito. 17

Modelo de Objetos
Seleccionar Nombres en los Requisitos

Software, S ft Red bancaria, Cajero automtico (ATM) (ATM), Consorcio de bancos, Banco, Banco Servidores, Cuenta bancaria, bancaria Informacin sobre la cuenta, Transaccin de cajero, Estaciones de cajero, Cajero humano,

Tarjeta d T j t de crdito, dit Usuario, Ordenador central central, Transaccin Remota, Dinero en efectivo, Recibo, Sistema, Registro de transacciones, transacciones Caractersticas de seguridad, Acceso a la cuenta cuenta, Coste de desarrollo, Parte compartida, Cliente. 18

Modelo de Objetos
Identificar Objetos y Clases

Aadir A di clases adicionales procedentes l di i l d t nuestro conocimiento del dominio.

Podemos aadir l clase L P d di la l Lnea d comunicaciones. de i i

de d

Eliminar redundancias.
Cliente Usuario son l misma clase. N quedamos Cli t y U i la i l Nos d con Cliente por adaptarse mejor al concepto.

Eliminar clases irrelevantes irrelevantes.

Coste de desarrollo no tiene nada que ver con el problema, queda fuera del sistema.

Eliminar clases vagas.

Sistema, Caractersticas de seguridad, Red bancaria y Parte compartida pueden considerarse vagas.
19

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 relacin). En el ejemplo, pueden considerarse atributos Informacin sobre la cuenta, (atributo de Cuenta bancaria), Dinero en efectivo y ( j ), q p Recibo (atributos de Cajero automtico), que pasan a ser clases eliminadas.

Separar mtodos
Observacin: algunos nombres ( Ob i l b (por ejemplo, Ll j l Llamada t l f i ) d telefnica) definen realmente operaciones o eventos.

Eliminar objetos de diseo j

Todas las clases que corresponden ms a la solucin del problema que a la situacin real, deben considerarse objetos de diseo y eliminarse en la fase del anlisis. En el ejemplo, eliminaremos Registro de transacciones, Lnea de 20 comunicaciones, Acceso a la cuenta y Software.

Modelo de Objetos
Identificar Objetos y Clases

Cajero automtico (ATM) C j t ti (ATM), Consorcio de bancos, Banco, Banco Servidores, Cuenta bancaria, bancaria Transaccin, Estaciones de cajero cajero, Cajero humano, j , Tarjeta de crdito, Ordenador central, Cliente.
21

Modelo de Objetos
Identificar Objetos y Clases
Consorcio Banco Cuenta Cliente

Ordenador Central

Servidor del Banco

Cajero Humano

ATM Estaciones del Cajero Transaccin Remota Transaccin de Cajero

Tarjeta de Crdito
22

Modelo de Objetos
Diccionario de Clases

El diccionario de clases contiene la definicin detallada de todas las clases en lenguaje natural. Ejemplo:
Cajero automtico (ATM): Terminal remoto que permite a los clientes realizar t li transacciones utilizando t j t d crdito para id tifi i tili d tarjetas de dit identificarse. El ATM interacciona con el cliente para identificar la transaccin deseada y sus datos asociados, enva esta informacin al ordenador central para su validacin y proceso, y entrega al usuario dinero en efectivo y un recibo. Suponemos que el ATM no opera cuando est desconectado de la red. Consorcio de bancos: Conjunto organizado de bancos que lleva la gestin de los cajeros automticos. Suponemos que slo se gestionan transacciones para los bancos que pertenecen al consorcio. i Banco: Institucin financiera que maneja las cuentas bancarias de sus clientes y emite t j t li t it tarjetas d crdito que f ilit de dit facilitan el acceso a l dichas cuentas a travs de la red de cajeros automticos. 23

Modelo de Objetos
Identificar y depurar relaciones

Seleccionar verbos relacionales en l requisitos. S l i b l i l los i it Aadir relaciones adicionales procedentes de nuestro conocimiento d l d i i t i i t del dominio. Eliminar relaciones de diseo o entre clases eliminadas. li i d Eliminar eventos transitorios. Reducir relaciones ternarias. Eliminar relaciones redundantes o derivadas. Aadir relaciones olvidadas. Definir la multiplicidad de cada relacin.
24

Identificar y Depurar Relaciones

Seleccionar verbos relacionales en los requisitos
1. Una Red bancaria est provista de C j 1 U R db i t i t d Cajeros automticos. t ti 2. El Consorcio de bancos comparte los Cajeros automticos. 3. Cada Banco dispone de un Servidor. 4. El Servidor dispone de Software. 5. Cada Servidor lleva la informacin sobre las Cuentas bancarias. 6. Cada Servidor procesa Transacciones. p 7. Una Transaccin acta sobre una Cuenta bancaria. 8. Las Estaciones de cajero estn conectadas al Servidor. 9. Las Estaciones de cajero son propiedad del Banco. 10.El Cajero humano opera en la Estacin de cajero. 11.El Cajero humano crea Cuentas bancarias. 12.El 12 El Cajero humano introduce Transacciones sobre las Cuentas bancarias. 13.Los Cajeros automticos aceptan Tarjetas de crdito. 14.Los 14 Los Cajeros automticos interaccionan con el Usuario Usuario.
25

Identificar y Depurar Relaciones

Seleccionar verbos relacionales en los requisitos
15. 15 16. 17. 18. 18 19. 20. 21. 22. 23. 24. Los Cajeros automticos comunican con el Ordenador central. central El Ordenador central lleva a cabo las Transacciones. Los Cajeros automticos entregan Dinero en efectivo al Usuario. Los Cajeros automticos i L C j t ti imprimen R ib i Recibos. El Sistema lleva el Registro de las transacciones. El Sistema cumple Caractersticas de seguridad. El Sistema maneja Accesos concurrentes a la Cuenta bancaria. El Coste de desarrollo se divide entre los Bancos. Los Bancos forman parte del Consorcio. p Los Clientes estn provistos de Tarjetas de crdito.

Relaciones adicionales implcitas en el texto 25. 26. 26 27. Las Cuentas bancarias estn en los Bancos. El O d Ordenador central pertenece al C d t l t l Consorcio. i Los Bancos tienen Clientes.

26

Identificar y Depurar Relaciones

Aadir relaciones adicionales procedentes de nuestro conocimiento del tema:
28. Las Tarjetas de crdito estn asociadas a las Cuentas bancarias . 29. 29 Los Cajeros humanos son empleados de los Bancos Bancos.

Eliminar relaciones de diseo o entre clases eliminadas:

Las de diseo se dejan para la fase de diseo Eliminamos las relaciones diseo. nmeros 1, 4, 17, 18, 19, 20, 21, 22.

Eliminar eventos transitorios:

Son sucesos que pertenecen al modelo dinmico y no constituyen relaciones estructurales (estticas) entre los objetos. Tras ejecutarse estas operaciones no se modifica la estructura de los objetos involucrados. involucrados Eliminamos las relaciones nmeros 13 y 14. Otras veces conviene reformularlas, como en el caso de la nmero 16, el Ordenador central lleva a cabo las Transacciones, que debera sustituirse ,q por: 16a. El Ordenador central se comunica con el Banco.
27

Identificar y Depurar Relaciones

Reducir Relaciones Ternarias
Son relaciones entre tres o ms clases clases. Muchas veces es posible descomponerlas en varias relaciones binarias (entre dos clases); si no es posible s que se pueden utilizar atributos posible, de relacin. Por ejemplo la relacin nmero 12 (El Cajero humano introduce ejemplo, Transacciones sobre las Cuentas bancarias) puede descomponerse en:
12a. El Cajero humano introduce Transacciones 12b. 12b Las Transacciones actan sobre las Cuentas bancarias bancarias.

De igual modo, la nmero 17 puede descomponerse as:

17a. 17a Los Cajeros automticos entregan Dinero en efectivo efectivo. 17b. El Usuario recoge el Dinero en efectivo.

28

Identificar y Depurar Relaciones

Eliminar relaciones redundantes o derivadas
Por ejemplo, la relacin nmero 2 es una combinacin de las relaciones nmero 15 y 26. Hay que tener cuidado, sin embargo, de no eliminar relaciones aparentemente redundantes, p p , pero q en realidad son que necesarias. Las redundantes por ejemplo son las que se derivan de la propiedad transitiva para relaciones.

Aadir relaciones olvidadas. Por ejemplo:

30. Los Clientes tienen C 30 L Cli t ti Cuentas. t 31. Las Transacciones son autorizadas por la Tarjeta de crdito. 32. Las Transacciones pueden introducirse en una Estacin de cajero.

Definir la multiplicidad de cada asociacin

Un Banco puede contener muchas Cuentas. Un Cliente puede tener muchas Cuentas. Un Cliente puede tener muchas Tarjetas de crdito crdito. Un Banco emplea muchos Cajeros. Un Banco tiene un solo Ordenador del banco. El Ordenador central se comunica con muchos Ordenadores del banco banco. .... 29

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 *

Cuenta
1 1

0.. 0 * 1

1 tiene

Cliente
1

Ordenador Central
1

0..* se comunica con

Servidor del Banco

1

Cajero Humano
1 posee introducida por

tiene

tiene accede a

se comunica con 0..*

se comunica con 0..* 0 *

0..* 0 * 1 0..*

0..* 0 *

0..* 0 *

ATM
1 realizada en 0..* 0..* 0..*

Estaciones del Cajero

introducida en

Transaccin de Cajero

tiene 1

0..*

0..*

Transaccin T i Remota

autorizada por

Tarjeta d T j t de 30 Crdito

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 diseo) Eliminar at butos de deta e fino a atributos detalle o Localizar atributos discordantes (muy diferentes de los dems p ede con enir dems; puede convenir dividir la clase en dos)
31

Identificar Atributos de Objetos y Relaciones

Atributos de los objetos
Del Banco: Nombre. De la Cuenta: Saldo, Lmite de crdito, Tipo de cuenta. Del Cliente: Nombre, Direccin Nombre Direccin. Del Cajero: Nombre. De una Transaccin del cajero: Tipo, Fecha y hora, Cantidad. Del Cajero automtico: Efectivo disponible, Cantidad entregada disponible entregada. De una Transaccin remota: Tipo, Fecha y hora, Cantidad. De la Tarjeta de crdito: Clave, Cdigo de la tarjeta.

Atributos de las relaciones (la multiplicidad de la relacin queda sobreentendida al usar un "cdigo")
8 y 9: Cdigo de la estacin de cajero. g j 15: Cdigo del cajero automtico. 16a: Cdigo del banco. 23: Cdigo del banco. 25: Cdigo de la cuenta. g 29: Cdigo de empleado.
32

Modelo de Objetos
Diagrama de Clases, atributos
Consorcio
1 1 posee 1 se comunica con 0..* 0..*

Banco
nombre 1 posee 1 1

gestiona 0..*

Cuenta
saldo Limite tipo 1 1 tiene

0..*

& tiene Cliente 1

nombre direccin 1

1 trabaja en 0..* 0 *

Ordenador Central
1 se comunica con 0..*

Servidor del Banco

1 posee 0..* 0 * 1 0..*

Cajero Humano
nombre 1

tiene accede a

ATM
disponible entregado 1 realizada en 0..* 0 *

se comunica con 0..* 0 *

introducida por 0 * 0 * 0..* 0..*

Estaciones del Cajero

Transaccin de Cajero introducida

en tipo ti fecha_hora cantidad 0..* 0..*

Transaccin Remota
tipo fecha_hora cantidad

0..*

tiene autorizada por

Tarjeta de Crdito
clave 33 1 codigo tajeta

0..*

Aadir Herencia
Introducimos clases nuevas (quiz abstractas) que contienen informacin comn a dos o ms clases preexistentes. Procurar evitar la herencia mltiple, a menos que sea estrictamente necesaria. necesaria Resultado: Primer diagrama de clases En el ejemplo:
La clase Estacin de entrada ser superclase de Cajero automtico y de Estacin de cajero. La clase Transaccin ser superclase de Transaccin de cajero y de Transaccin remota remota. Podran refinarse los tipos de cuentas

34

Modelo de Objetos
Diagrama de Clases, herencia
Consorcio
1 1 p posee 1 se comunica con 0..* 0..*

Banco
nombre 1 posee 1 1

gestiona 0..*

Cuenta
saldo limite tipo 1

1 trabaja en 0..*

tiene Cliente 1 0..* nombre direccin 1 1

Ordenador Central
1 se comunica con 0..* 0 *

Servidor del Banco

1 posee 0..* 1 introdu ucida en

Cajero Humano
nombre 1 introducida por 0..* accede a tiene

ATM
disponible entregado

se comunica con 0..*

Estacion de Entrada

Estaciones del Cajero

0.. 0 *

Transaccin de Cajero
0..* 0 *

0..* 1 realizada en

& tiene Transaccin

tipo fecha_hora f h h cantidad

0..* 0..* tiene

Transaccin Remota
0..*

Tarjeta de Crdito
clave codigo tarjeta 35 1

autorizada por

Comprobar los Casos de Uso (iterar)

Para localizar fallos que deben corregirse fijarse en:
Atributos muy dispares (discordantes): descomponer una clase en dos. Operaciones sin objetivo: aadir clase con estas operaciones como mtodos de l d clase. Conversin de relaciones en clases: por ejemplo, clase Empleado (clase asociacin para una relacin entre las clases Persona y Compaa, que representa la forma en que una compaa contrata a una persona) Operaciones que no encuentran camino para realizarse: aadir relaciones. Relaciones redundantes: eliminarlas. Relaciones demasiado detalladas o demasiado vagas: subirlas a una g superclase o bajarlas a una subclase. Clases sin atributos, sin mtodos o sin relaciones: eliminarlas. Relaciones que nadie atraviesa: eliminarlas. Atributos d l At ib t de clase necesarios en un acceso: pasarlos a atributos d relacin i l t ib t de l i (por ejemplo el cdigo).

36

Comprobar los Casos de Uso (iterar)

En el ejemplo de los cajeros automticos: Tarjeta de crdito desempea dos roles: la tarjeta fsica, que se introduce y que permite al cajero automtico conectarse con el banco, con informacin sobre el mundo real (banco, nmero de la tarjeta) y las autorizaciones concedidas por ste, que slo son nmeros en la memoria de un ordenador y se pueden cambiar con facilidad (contrasea, lmite de crdito). Se puede descomponer en Tarjeta de crdito y Autorizacin de la tarjeta Una sola tarjeta. autorizacin puede afectar a ms de una tarjeta fsica. Una misma autorizacin puede permitir acceder a ms de una cuenta (y viceversa). Introducimos l clase A t li I d i la l Actualizacin d cuenta para refinar el concepto d i de t fi l de Transaccin. Una misma transaccin puede estar compuesta de varias actualizaciones de cuenta (por ejemplo, transferencia entre cuentas son ) dos actualizaciones). No hay distincin 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, Iteracin
0..* realizada en 1..*

Transaccin
fecha_hora

Actualizacin
cantidad tipo 0..*

Estacion de Entrada Estaciones del Cajero

0..* posee posee 1 1

Transaccin De Cajero
Intro. por 0..* 1

Transaccin Remota
comenzada por 0..* 1..* 1

ATM
disponible entregado 0..* 1

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

Autorizacin

tiene 1

0..* clave limite 0..* 1

Consorcio

Banco
nombre 0..*

Cliente
gestiona nombre direccin 1 tiene 1..* 1..*

Aut. Aut 1..* por

Tarjeta de Crdito
codigo banco codigo tarjeta numero tiene

Cuenta
0..* saldo limite tipo 1
38

Modularizar
Agrupar clases en mdulos. A l d l En el ejemplo de los cajeros a tomticos automticos. Posibles mdulos:
Cajeros en general: Cajero Estacin de cajero, ATM Cajero, cajero ATM, Estacin de entrada. Cuentas en general: Cuenta, Tarjeta de crdito, Autorizacin, Cliente, Transaccin, Autorizacin Cliente Transaccin Transaccin de cajero, Transaccin remota. Bancos: Banco, Consorcio.

Resultado: Diagrama de Paquetes

39

Diagrama de Paquetes

Cajeros

Cuentas

Bancos

40

Modelo Dinmico
Consta de los siguientes pasos: Identificar sucesos Construir diagramas de estados Comprobar consistencia (iterar) Aadir mtodos

41

Identificar Mensajes
Los L mensajes se extraen d l casos d uso j t de los de (escenarios). Pueden ser de los siguientes tipos:
Seales S l Entradas Decisiones Interrupciones Transiciones Acciones externas Condiciones de error

Resultados: Diagramas de secuencia y de colaboracin.

42

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

Diagrama de Secuencia
Retirar Efectivo R ti Ef ti
:ATM pedir cantidad intro cantidad Proc. transaccin Proc. Transaccin del Banco Transaccin del Banco OK Transaccin OK Entregar dinero Peticin tomar dinero Tomar dinero Imprimir Recibo Peticin continuacin Terminar Expulsar Tarjeta Peticin Recogida Tarjeta Mostrar Pantalla Principal :Consorcio :Banco

:Usuario

44

Identificar Mensajes
Los casos de uso (escenarios) se convierten en diagramas de secuencia. Estas se compactan en diagramas de colaboracin. En el ejemplo de los cajeros automticos:
El cliente introduce la contrasea define un mensaje de entrada que el objeto Cliente enva al objeto Cajero automtico. El cajero automtico entrega el dinero al cliente es un evento que el objeto Cajero g q j j automtico enva al objeto Cliente.

Agrupar los mensajes equivalentes:

El cliente introduce la contrasea es el mismo evento independientemente de la contrasea introducida. El cajero automtico entrega el dinero al cliente es el mismo mensaje independientemente de la cantidad entregada. g

No agrupar los mensajes no equivalentes: El banco autoriza la q transaccin es distinto evento que El banco rechaza la transaccin.
45

Construir Diagramas de Estado

Uno por clase. Determinar los eventos que provocan transiciones clase entre estados. En el ejemplo de los cajeros automticos centrarse en las clases dinmicas, dinmicas que cambian de estado:
Cajero automtico Banco Consorcio Estacin de cajero

No hace falta construir diagramas de estado de las clases pasivas, q que no cambian de estado de modo significativo: g
Tarjeta de crdito Transaccin Cuenta

Tampoco hace falta considerar a fondo los objetos externos, que no forman parte del sistema informtico:
Cliente Cajero humano
46

Modelo de Objetos
Diagrama de Transicin Estados, clase ATM

codigo_error

47

Modelo de Objetos
Diagrama de Transicin Estados, clase Banco
Banco

procesar_transaccion(tarjeta, trans) [ [res==OK]/consorcio.transaccion_ok(tarjeta) ] ( j ) [res==BAD]/consorcio.transaccion_fallo(tarjeta) [res==BAD]/consorcio.cuenta_invalida(tarjeta) Actualizando Cuenta do/res=actualizar_cuenta(tarjeta, trans)

esperando verificar(tarjeta, password)

Verificar Tarjeta entry/res=verificar_numero(tarjeta)

[res==OK]

Verificar Clave entry/res=verificar_password(password)

[res==BAD]/consorcio.bad_password(tarjeta) [res==OK]/consorcio.cuenta_ok(tarjeta)

48

Modelo de Objetos
Diagrama de Transicin Estados, clase Consorcio

49

Ejercicio
Son consistentes los diagramas anteriores entre s? Son consistentes con los casos de uso? Aadir la informacin d l casos A di l i f i de los alternativos y excepciones (timeouts, etc.)

50

Arquitectura
Diagrama de Despliegue

51

Sistema de Control de Trfico Ferroviario (SCTF)

Sistema para el control d t fi f Si t l t l de trfico ferroviario (d i i (de pasajeros y carga), que permita incrementar el trfico de trenes, as como la programacin predecible de horarios. Automatizacin del enrutado de trenes y monitorizacin de todos los elementos del sistema del tren tren. Objetivos: Reducir costes de operacin y mejorar el uso de recursos.
52

Sistema de Control de Trfico Ferroviario

Requisitos

Problema: requisitos poco claros y contradictorios. P bl i it l t di t i Se hace necesario un modelo de desarrollo iterativo e incremental. Metodologa RUP. Sistema complejo, varios aos de desarrollo: permitir cierto grado de cambio en los requisitos, para aprovechar avances en el h d h l hardware. Riesgo d li i en el anlisis, d d que el nmero Ri de parlisis l li i dado l de requisitos es muy grande.
53

Sistema de Control de Trfico Ferroviario

Requisitos: Comienzo (Inception)

Dos funciones principales: enrutado d D f i i i l t d de trenes y monitorizacin. Otras funciones relacionadas:

Planificacin del trfico. Prediccin de fallos fallos. Seguimiento de la posicin de los trenes. Evitar li i E it colisiones. Registro de mantenimiento.
54

Sistema de Control de Trfico Ferroviario

Casos de Uso
Enrutar Tren: Establecer un plan para un tren que define el tren, recorrido de un tren particular Planificar Trfico: Establecer un plan de trfico que provea una gua en el desarrollo de rutas para trenes en un periodo de tiempo para una regin geogrfica. Controlar los Sistemas del Tren: Controlar los sistemas de a p q bordo del tren para verificar que funcionan correctamente. Prediccin de Fallos: Realizar un anlisis del estado de los sistemas del tren para predecir la probabilidad de fallo relativa al plan del tren. Seguimiento de Trenes: Seguir la posicin de los trenes usando los recursos del SCTF, as como GPS. Seguimiento del trfico: Monitorizacin del trfico de trenes en una regin geogrfica. i fi Evitar colisiones: Proporcionar los medios, automticos y manuales para evitar colisiones de trenes. 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. 55

Sistema de Control de Trfico Ferroviario

Requisitos no Funcionales y Restricciones
Requisitos no Funcionales:
Transporte de manera segura de pasajeros y cargamento. Soporte de velocidades de tren de hasta 250 millas por hora (400 km/hora). Interoperar con sistemas de gestin de trfico en las fronteras del SCTF. Asegurar la mxima reutilizacin y compatibilidad con el equipamiento existente. Proporcionar una disponibilidad del sistema al nivel del 99.99%. Proporcionar redundancia funcional completa para las capacidades del SCTF. Proporcionar precisin en la posicin del tren de 10 yardas (9 metros). Proporcionar precisin en la velocidad del tren de 1.5 millas/hora (2.5 opo c o a p ec s e a e oc dad de e 5 as/ o a ( 5 km/hora). Respuesta a las rdenes del operador en menos de 1.0 segundos. Facilidad de mantenimiento y evolucin del SCTF.

Restricciones:
Seguimiento de los estndares nacionales, governamentales e industriales. Maximizar el uso de componentes COTS (commercial-off-the-shelf) hardware y software. h d ft
56

Sistema de Control de Trfico 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. Maquinista (Train Engineer): Monitoriza el estado del tren y opera el mismo. p Operario de Mantenimieno (Maintainer): Monitoriza el estado y mantiene l sistemas d l tren. d i los i del GPS Navstar: P N t Proporciona l servicios d l i los i i de localizacin li i para el seguimiento de los trenes.
57

Sistema de Control de Trfico Ferroviario

Diagrama de Casos de Uso

Soporte para la intervencin manual y automtica

58

Caso de Uso: Enrutar Tren

Propsito: Establecer un plan para el tren que acte como repositorio para toda la informacin asociada con la ruta de un tren especfico y las acciones que sucedan en el camino. Contacto: Pedro Prez Fecha de modificacin: 9/5/06 Pre-condiciones: Pre condiciones: Existe un plan de trfico para el intervalo de tiempo y la regin geogrfica relevante al plan que se est elaborando. Post-condiciones: Se estableci el plan para el tren, que detalla su ruta de viaje. Limitaciones: Cada tren tiene un ID nico en el sistema. Los distintos recursos pueden no ser usables por ms de un plan de tren en un cierto inter alo de tiempo sables n n intervalo tiempo. Suposiciones: Un plan de tren es accesible por los controladores para su consulta y modificacin y accesible a los ingenieros ferroviarios para consulta. Escenario Principal: 1. El SGTF presenta al controlador una lista de opciones. 2. El controlador selecciona desarrollar un nuevo plan para un tren. 3. El SGTF presenta una plantilla para un plan de tren al controlador. 4. 4 El controlador completa la plantilla dando informacin sobre el ID de la locomotora plantilla, locomotora, los ingenieros ferroviarios y puntos de paso con tiempos. 5. El controlador introduce el plan completado en el SGTF. 6. El SGTF asigna un ID nico al plan de tren y lo almacena. El SGTF hace accesible el plan para consulta y modificacin modificacin.
59

Caso de Uso: Enrutar Tren

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

Caso de Uso: Controlar los Sistemas del Tren

Propsito: Controlar los dispositivos a bordo del tren para asegurar su funcionamiento correcto. Contacto: Pedro Prez Fecha de modificacin: 10/5/06 Precondiciones: La locomotora est funcionando. Postcondiciones: El sistema muestra informacin sobre el funcionamiento de los sistemas a bordo del tren. Limitaciones: Ninguna identificada. Suposiciones: La visualizacin del estado de los sistemas se proporciona cuando la locomotora est funcionando. El sistema proporciona seales audibles y visibles (resalta en amarillo los sistemas problemticos) sobre los problemas del sistema. Escenario Principal: p q p 1. El SCTF presenta al maquinista una serie de opciones. 2. El maquinista elige controlar los sistemas del tren. 3. El SCTF presenta al maquinista informacin de estado de los sistemas de tren. 4. 4 El maquinista revisa l i f i i t i la informacin d estado. i de t d
61

Caso de Uso: Controlar los Sistemas del Tren

Escenarios Alternativos
Pedir visualizacin detallada del sistema 5. El maquinista elige visualizar de manera detallada un sistema que muestra su estado en amarillo. 6. El SCTF presenta al maquinista informacin detallada del estado del sistema seleccionado. 7. El maquinista revisa la informacin detallada proporicionada. 8. Se sigue en el paso 2 del escenario principal Extensin: Solicitar un anlisis de prediccin de fallos para un sistema. 7a. El maquinista solicita un anlisis de prediccin de fallos para el sistema. 8. El SCTF realiza un anlisis de prediccin de fallos para el sistema. 9. El SCTF presenta al maquinista el resultado del anlisis. 10. El maquinista revisa el anlisis. 11. El maquinista pide al SCTF que alerte al mantenedor del sistema que puede fallar. 12. El SCTF avisa al mantenedor del sistema. 13. El mantenedor solicita revisar los resultados del anlisis. 14. El SCTF le presenta la informacin del anlisis de la prediccin. 15. El mantenedor revisa el anlisis y determina que la condicin de color amarillo no es lo suficientemente grave como para requerir accin inmediata. 16. El mantenedor solicita al SCTF que alerte al maquinista de esta decisin. 17. El SCTF muestra la decisin al maquinista. 18. El maquinista elige realizar una visualizacin del sistema seleccinado. 19. El escenario alternativo Pedir Visualizacin Detallada del Sistema se continua en el paso 6.

62

Anlisis de la Funcionalidad del Sistema

RUP: Elaboracin

Caso de uso enrutar tren

63

Anlisis de la Funcionalidad F i lid d del Sistema

RUP: Elaboracin

Caso de uso controlar los sistemas del tren y escenario alternativo lt ti

64

Anlisis de la Funcionalidad del Sistema

Elaboracin Diagrama de visin conjunta de la interaccin que muestra la relacin entre los distintos escenarios del caso d uso de controlar l t l los sistemas del tren

65

Definicin de la Arquitectura

66

Ingeniera de Sistemas

67

Definicin de la Arquitectura

68

Abstracciones y Mecanismos
Anlisis de dominio
El sistema comprende cuatro abstracciones o mecanismos principales:
Red y Comunicaciones. Base de Datos. Interfaz hombre-mquina. Control en tiempo real de dispositivos analgicos y digitales. p p g g

Hay tres abstracciones comunes:

Trenes: incluye vagones y locomotoras. Vas de tren: perfil grado dispositivos de rail perfil, grado, rail. Planes: horarios, rdenes, permisos, autoridad y asignacin de personal.

Mecanismos para las abstracciones:

Paso de mensajes. Planificacin de los horarios del tren. Visualizacin de informacin. Adquisicin de datos de los sensores.

69

Construccin
Diseo de la Arquitectura

Paso d mensajes: P de j
Entre ordenadores y dispositivos. p Entre ordenadores.

Red distribuida: distrib ida contemplar ruido, fallos de equipos y q p seguridad.

70

Mecanismo de Paso de Mensajes

71

Planificacin de horarios
Cada tren tiene un plan activo. Cada plan se asigna a un tren. Un plan puede puede implicar varias rdenes y posiciones en las vas.

72

Planificacin de horarios
Ejemplo de las acciones que puede contener un plan.
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

Planificacin de horarios

74

Visualizacin de Informacin

75

Arquitectura del Sistema

76