Ejemplos UML

Tema 4

Grupo 46 TACC II Curso 2008/09 1

Indice
z Cajeros Automticos z 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 A. Houston Houston. Addison Wesley Professional Professional, 2007 2007.

Ejemplo j p de Anlisis Orientado a Objetos 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. cuentas A estos 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 , se comunican con un ordenador central p para llevar a cabo las usuario, 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 D it Depsito

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 I t d y Objetivos: Obj ti Cliente del Banco: quiere realizar una operacin con el ATM de manera rpida, para lo que debe validar su tarjeta y contrasea. C Consorcio: i Quiere Q i id tifi identificar correctamente t t el l banco b d l cliente del li t y 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 tarjeta t j t emitida itid por el l mismo. i Garanta de xito (post-condiciones): La tarjeta se valida correctamente.
5

Caso de Uso
Validar Tarjeta y Clave (Refinado)

Escenario Principal p de xito: 1. El ATM pide al cliente que inserte la tarjeta de crdito. 2 El cliente 2. li t i inserta t l la t tarjeta j t d de crdito. 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 El consorcio enva el nmero de tarjeta y la contrasea al 7. banco correspondiente. 8. El banco notifica la aceptacin al consorcio. 9 El consorcio 9. i notifica ifi l la aceptacin i al l cajero j automtico. 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 El consorcio 1. i notifica tifi el l rechazo h al l cajero j automtico. 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 q que la tarjeta j q 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: z Pantalla tctil en panel grande y plano. El texto debe ser visible desde un 50cms. z Respuesta del ATM en menos de 5 secs, el 90% de las veces. z Recuperacin robusta cuando el acceso mediante comunicaciones falla. z Posibilidades de internacionalizacin de texto. z Comunicaciones cifradas. z ... 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 bi biometra. t Frecuencia de ocurrencia: z Puede ser casi continua. Temas abiertos: z Explorar el tema de recuperacin en caso de fallo de sistemas externos. z Qu Q modificaciones difi i se necesitan it para idi idiomas y paises i di distintos? ti t ? z

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 G t de d xito it (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 p pide al cliente q que teclee la cantidad. 2. El cliente teclea una cantidad. 3. El ATM comprueba que la cantidad est dentro de los lmites. 4 El ATM genera una transaccin y la enva al consorcio 4. consorcio. 5. El consorcio pasa la transaccin al banco. 6. El banco aprueba la transaccin. 7 El banco actualiza la cuenta 7. cuenta. 8. El banco enva al consorcio la notificacin de aceptacin y el nuevo saldo de la cuenta. 9 El consorcio enva al ATM la notificacin de aceptacin y el saldo 9. 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 El ATM expulsa 1. l la l tarjeta t j t de d crdito dit e i indica di al l cliente li t que l la tome. 2. El cliente toma la tarjeta de crdito. 3 El ATM vuelve 3. l a la l situacin it i i inicial. i i l 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 Se vuelve al caso de uso Realizar 4. Realizar Operacin Operacin para que el 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 El ATM indica al cliente que tome el dinero y emite una seal sonora 1. 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 El ATM retiene el dinero y la tarjeta 1. 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 j continua en 16. 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: z Pantalla tctil en panel grande y plano. El texto debe ser visible desde un 50cms. z Respuesta del ATM en menos de 5 secs, el 90% de las veces. z Recuperacin robusta cuando el acceso mediante comunicaciones falla. z Posibilidades de internacionalizacin de texto. z Comunicaciones cifradas. z ... 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: z Puede ser casi continua. Temas abiertos: z Explorar el tema de recuperacin en caso de fallo de sistemas externos. z Qu modificaciones se necesitan para idiomas y paises distintos? z
14

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

Modelo de Objetos
Identificar Objetos y Clases

z Seleccionar S l i nombres b en l los requisitos. i it z Aadir clases adicionales procedentes de nuestro t conocimiento i i t d del ld dominio. i i z Eliminar redundancias. z Eliminar clases irrelevantes. z Eliminar clases vagas. z Separar atributos. z Separar mtodos. z Eliminar objetos de diseo. z 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. cuentas A estos 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 para llevar a cabo las usuario, se comunican con un ordenador central p 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. 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

z z z z z z z z

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

zTarjeta T j t de d crdito, dit zUsuario, zOrdenador central central, zTransaccin Remota, zDinero en efectivo, zRecibo, zSistema, zRegistro de transacciones, transacciones zCaractersticas de seguridad, zAcceso a la cuenta cuenta, zCoste de desarrollo, zParte compartida, zCliente. 18

Modelo de Objetos
Identificar Objetos y Clases

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

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

d de

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

z Eliminar clases irrelevantes. irrelevantes

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

z Eliminar clases vagas.

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

Modelo de Objetos
Identificar Objetos y Clases

z Separar S atributos t ib t
{ Los atributos definen datos asociados a un objeto, en lugar de j (un atributo objeto ( j se representa p mediante una relacin). ) objetos { En el ejemplo, pueden considerarse atributos Informacin sobre la cuenta, (atributo de Cuenta bancaria), Dinero en efectivo y (atributos de Cajero j automtico), q que p pasan a ser clases Recibo ( eliminadas.

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

z Eliminar objetos j de diseo

{ 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

z z z z z z z z z z z

Cajero C j automtico t ti (ATM) (ATM), Consorcio de bancos, Banco Banco, Servidores, Cuenta bancaria, bancaria Transaccin, Estaciones de cajero cajero, Cajero humano, j de crdito, , Tarjeta 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

z 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 li t transacciones i utilizando tili d tarjetas t j t de d crdito dit para identificarse. id tifi 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 li t y emite it tarjetas t j t d crdito de dit que facilitan f ilit el l acceso a dichas cuentas a travs de la red de cajeros automticos. 23

Modelo de Objetos
Identificar y depurar relaciones

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

Identificar y Depurar Relaciones

Seleccionar verbos relacionales en los requisitos
1. Una 1 U Red R db bancaria i est t provista i t de d Cajeros C j 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 p procesa Transacciones. 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 Cajero humano introduce Transacciones sobre las Cuentas 12.El bancarias. 13.Los Cajeros automticos aceptan Tarjetas de crdito. 14 Los Cajeros automticos interaccionan con el Usuario. 14.Los
25

Identificar y Depurar Relaciones

Seleccionar verbos relacionales en los requisitos
15. 15 16. 17. 18 18. 19. 20. 21. 22. 23. Los Cajeros automticos comunican con el Ordenador central. El Ordenador central lleva a cabo las Transacciones. Los Cajeros automticos entregan Dinero en efectivo al Usuario. L Cajeros Los C j automti t ti i imprimen i R ibos. Rec 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 p parte del Consorcio.

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

Identificar y Depurar Relaciones

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

z Eliminar relaciones de diseo o entre clases eliminadas:

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

z 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 q debera sustituirse por: 16a. El Ordenador central se comunica con el Banco.
27

Identificar y Depurar Relaciones

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

z De igual modo, la nmero 17 puede descomponerse as:

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

28

Identificar y Depurar Relaciones

z 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 p redundantes, ,p pero q que en realidad son necesarias. Las redundantes por ejemplo son las que se derivan de la propiedad transitiva para relaciones.

z Aadir relaciones olvidadas. Por ejemplo:

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

z 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. Un Banco emplea muchos Cajeros. Un Banco tiene un solo Ordenador del banco. El Ordenador central se comunica con muchos Ordenadores del 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 T j t de d 30 Crdito

Identificar Atributos de Objetos y Relaciones

z Distinguir los objetos de los atributos z Distinguir entre los atributos de objetos y de relaciones z Eliminar Eli i atributos t ib t privados i d (d (de di diseo) ) z Eliminar a at atributos butos de deta detalle e fino o z Localizar atributos discordantes (muy diferentes de los dems dems; p puede ede con convenir enir dividir la clase en dos)
31

Identificar Atributos de Objetos y Relaciones

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

z 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 del cajero j automtico. 15: Cdigo 16a: Cdigo del banco. 23: Cdigo del banco. 25: Cdigo g de la cuenta. 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
z Introducimos clases nuevas (quiz abstractas) que contienen informacin comn a dos o ms clases preexistentes. z Procurar evitar la herencia mltiple, a menos que sea estrictamente necesaria. necesaria z Resultado: Primer diagrama de clases z 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. { Podran refinarse los tipos de cuentas

34

Modelo de Objetos
Diagrama de Clases, herencia
Consorcio
1 1 posee p 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 f h h fecha_hora 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:
z Atributos muy dispares (discordantes): descomponer una clase en dos. z Operaciones sin objetivo: aadir clase con estas operaciones como mtodos d clase. de l z 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) z Operaciones que no encuentran camino para realizarse: aadir relaciones. z Relaciones redundantes: eliminarlas. z Relaciones demasiado detalladas o demasiado vagas: g subirlas a una superclase o bajarlas a una subclase. z Clases sin atributos, sin mtodos o sin relaciones: eliminarlas. z Relaciones que nadie atraviesa: eliminarlas. z Atributos At ib t de d clase l necesarios i en un acceso: pasarlos l a atributos t ib t d de relacin l i (por ejemplo el cdigo).

36

Comprobar los Casos de Uso (iterar)

z En el ejemplo de los cajeros automticos: z 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. tarjeta Una sola autorizacin puede afectar a ms de una tarjeta fsica. Una misma autorizacin puede permitir acceder a ms de una cuenta (y viceversa). z I Introducimos d i l clase la l A t li Actualizacin i de d cuenta t para refinar fi el l concepto de d Transaccin. Una misma transaccin puede estar compuesta de varias actualizaciones de cuenta (por ejemplo, transferencia entre cuentas son ) dos actualizaciones). z 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 H Humano
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
z Agrupar A clases l en mdulos. d l z En el ejemplo de los cajeros a automticos. tomticos Posibles mdulos:
{ Cajeros en general: Cajero, Estacin de cajero, ATM, Estacin de entrada. { Cuentas en general: Cuenta, Tarjeta de crdito, Autorizacin, Cliente, Transaccin, Transaccin de cajero, Transaccin remota. { Bancos: Banco, Consorcio.

z Resultado: Diagrama de Paquetes

39

Diagrama de Paquetes

Cajeros

Cuentas

Bancos

40

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

41

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

z 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
R ti Retirar Efectivo 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
z Los casos de uso (escenarios) se convierten en diagramas de secuencia. Estas se compactan en diagramas de colaboracin. z 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 g el dinero al cliente es un evento q que el objeto j Cajero j automtico enva al objeto Cliente.

z 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

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

Construir Diagramas de Estado

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

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

z 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
z Son consistentes los diagramas anteriores entre s? z Son consistentes con los casos de uso? z Aadir A di l la i informacin f i d de l los casos alternativos y excepciones (timeouts, etc.)

50

Arquitectura
Diagrama de Despliegue

51

Sistema de Control de Trfico Ferroviario (SCTF)

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

Sistema de Control de Trfico Ferroviario

Requisitos

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

Sistema de Control de Trfico Ferroviario

Requisitos: Comienzo (Inception)

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

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

Sistema de Control de Trfico Ferroviario

Casos de Uso
z Enrutar Tren: Establecer un plan para un tren, tren que define el recorrido de un tren particular z 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. z Controlar los Sistemas del Tren: Controlar los sistemas de a para verificar q que funcionan correctamente. bordo del tren p z Prediccin de Fallos: Realizar un anlisis del estado de los sistemas del tren para predecir la probabilidad de fallo relativa al plan del tren. z Seguimiento de Trenes: Seguir la posicin de los trenes usando los recursos del SCTF, as como GPS. z Seguimiento del trfico: Monitorizacin del trfico de trenes en una regin i geogrfica. fi z Evitar colisiones: Proporcionar los medios, automticos y manuales para evitar colisiones de trenes. z Registro R i t de d Mantenimiento M t i i t : Proporcionar P i l medios los di para anotar t el mantenimiento realizado en los trenes. 55

Sistema de Control de Trfico Ferroviario

Requisitos no Funcionales y Restricciones
z 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 opo c o a p precisin ec s e en la a velocidad e oc dad de del tren e de 1.5 5 millas/hora as/ o a ( (2.5 5 km/hora). Respuesta a las rdenes del operador en menos de 1.0 segundos. Facilidad de mantenimiento y evolucin del SCTF.

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

Sistema de Control de Trfico Ferroviario

Actores

zC Controlador t l d (Dispatcher) (Di t h ): Establece E t bl l las rutas t d de l los trenes y sigue el progreso de los trenes individuales. z Maquinista (Train Engineer): Monitoriza el estado del tren y opera p el mismo. z Operario de Mantenimieno (Maintainer): Monitoriza el estado d y mantiene i l los sistemas i d del l tren. z GPS Navstar N t : Proporciona P i l los servicios i i d de l 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: Existe un plan de trfico para el intervalo de tiempo y la regin Pre-condiciones: 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 sables por ms de un n plan de tren en un n cierto intervalo inter alo de tiempo. 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 El controlador completa la plantilla, 4. plantilla dando informacin sobre el ID de la locomotora, 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 p un p plan. 7. Se sigue en el escenario principal en el paso 5. Modificacin de un plan existente 2b El controlador selecciona modificar un plan existente. 2b. 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 El SGTF almacena el plan modificado y lo accesible para consulta y modificacin. 8. 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: presenta al maquinista q una serie de opciones. p 1. El SCTF p 2. El maquinista elige controlar los sistemas del tren. 3. El SCTF presenta al maquinista informacin de estado de los sistemas de tren. 4 El maquinista 4. i i t revisa i l la i informacin f i d de estado. 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 F Funcionalidad 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 de d uso controlar t l los l sistemas del tren

65

Definicin de la Arquitectura

66

Ingeniera de Sistemas

67

Definicin de la Arquitectura

68

Abstracciones y Mecanismos
Anlisis de dominio
z El sistema comprende cuatro abstracciones o mecanismos principales:
{ { { { Red y Comunicaciones. Base de Datos. Interfaz hombre-mquina. Control en tiempo p real de dispositivos p analgicos g y digitales. g Trenes: incluye vagones y locomotoras. Vas de tren: perfil perfil, grado grado, dispositivos de rail rail. Planes: horarios, rdenes, permisos, autoridad y asignacin de personal. Paso de mensajes. Planificacin de los horarios del tren. Visualizacin de informacin. Adquisicin de datos de los sensores.

Hay tres abstracciones comunes:

{ { {

Mecanismos para las abstracciones:

{ { { {

69

Construccin
Diseo de la Arquitectura

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

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

70

Mecanismo de Paso de Mensajes

71

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

72

Planificacin de horarios
z 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