Modelo de Anlisis Orientado a Objetos

Requisitos
Explican lo que se desea que haga el sistema, ya sea en lenguaje natural, o en forma de casos de
uso a la Jacobson.
Ejemplo:
Se desea disear el software necesario para una red bancaria provista de cajeros automticos
(ATM, automatic teller machines), que sern compartidos por un consorcio de bancos. Cada
banco dispone de su propio ordenador, provisto de software propio, que lleva la informacin
sobre sus cuentas y procesa las transacciones que actan sobre dichas cuentas. A este ordenador
estn conectadas 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 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 correctamente el registro de las transacciones
efectuadas, cumplir caractersticas aceptables de seguridad y manejar correctamente 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.
Expresar los requisitos como Casos de Uso
Preparar escenarios detallados. Primero los normales. Despus se aaden los problemas que
pueden surgir. En el ejemplo de los cajeros automticos:
Escenario normal:
o El cajero automtico pide al cliente que inserte la tarjeta de crdito.
o El cliente inserta la tarjeta de crdito.
o El cajero automtico acepta la tarjeta de crdito y lee el nmero de tarjeta y el
cdigo del banco.
o El cajero automtico pide la contrasea al cliente.
o El cliente teclea "1234".
o El cajero automtico enva el nmero de tarjeta, el cdigo del banco y la
contrasea al consorcio.
o El consorcio enva el nmero de tarjeta y la contrasea al banco.
o El banco notifica la aceptacin al consorcio.
o El consorcio notifica la aceptacin al cajero automtico.
o El cajero automtico pide al cliente que elija el tipo de transaccin: retirada de
fondos, depsito, transferencia, informacin.
o El cliente selecciona retirada de fondos.
o El cajero automtico pide al cliente que teclee la cantidad.
o El cliente teclea 25000.
o El cajero automtico comprueba que la cantidad est dentro de los lmites
generales.
o El cajero automtico genera una transaccin y la enva al consorcio.
o El consorcio pasa la transaccin al banco.
o El banco aprueba la transaccin.
o El banco actualiza la cuenta.
o El banco enva al consorcio la notificacin de aceptacin y el nuevo saldo de la
cuenta.
o El consorcio enva al cajero automtico la notificacin de aceptacin y el nuevo
saldo de la cuenta.
o El cajero automtico entrega el dinero al cliente.
o El cliente toma el dinero.
o El cajero automtico pregunta al cliente si quiere un recibo.
o El cliente contesta SI.

o
o
o
o
o
o
o

El cajero automtico imprime un recibo y pide al cliente que lo tome.

El cliente toma el recibo.
El cajero automtico pregunta al cliente si quiere hacer otra operacin.
El cliente contesta NO.
El cajero automtico expulsa la tarjeta de crdito e indica al cliente que la tome.
El cliente toma la tarjeta de crdito.
El cajero automtico vuelve a la situacin inicial.
Escenario con problemas:
o El cajero automtico pide al cliente que inserte la tarjeta de crdito.
o El cliente inserta la tarjeta de crdito.
o El cajero automtico acepta la tarjeta de crdito y lee el nmero de tarjeta y el
cdigo del banco.
o El cajero automtico pide la contrasea al cliente.
o El cliente teclea "9999".
o El cajero automtico enva el nmero de tarjeta, el cdigo del banco y la
contrasea al consorcio.
o El consorcio enva el nmero de tarjeta y la contrasea al banco.
o El banco notifica el rechazo al consorcio.
o El consorcio notifica el rechazo al cajero automtico.
o El cajero automtico notifica el rechazo al cliente y pide que teclee de nuevo la
contrasea.
o El cliente teclea "1234".
o El cajero automtico enva el nmero de tarjeta, el cdigo del banco y la
contrasea al consorcio.
o El consorcio enva el nmero de tarjeta y la contrasea al banco.
o El banco notifica la aceptacin al consorcio.
o El consorcio notifica la aceptacin al cajero automtico.
o El cajero automtico pide al cliente que elija el tipo de transaccin: retirada de
fondos, depsito, transferencia, informacin.
o El cliente selecciona retirada de fondos.
o El cajero automtico pide al cliente que teclee la cantidad.
o El cliente teclea CANCELAR.
o El cajero automtico expulsa la tarjeta de crdito e indica al cliente que la tome.
o El cliente toma la tarjeta de crdito.
o El cajero automtico vuelve a la situacin inicial.

Modelo de objetos
Consta de los siguientes pasos:
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
Identificar objetos y clases
Consta de los siguientes pasos:
Seleccionar nombres en los requisitos
Aadir clases adicionales procedentes de nuestro conocimiento del tema
Eliminar redundancias
Eliminar clases irrelevantes
Eliminar clases vagas

Separar atributos
Separar mtodos
Eliminar objetos de diseo
Resultado: Preparar diccionario de clases
En el ejemplo de los cajeros automticos:
Seleccionar nombres en los requisitos
Los nombres extrados de los requisitos en lenguaje natural del sistema de cajeros
automticos son los siguientes (23):
Software, Red bancaria, Cajero automtico, Consorcio de bancos, Banco, Ordenador del
banco, Cuenta bancaria, Informacin sobre la cuenta, Transaccin, Estaciones de cajero,
Cajero humano, Tarjeta de crdito, Usuario, Ordenador central, Dinero en efectivo,
Recibo, Sistema, Registro de transacciones, Caractersticas de seguridad, Acceso a la
cuenta, Coste de desarrollo, Parte compartida, Cliente.
Aadir clases adicionales procedentes de nuestro conocimiento del tema
Podemos aadir la clase Lnea de comunicaciones.
Eliminar redundancias
Cliente y Usuario son la misma clase. Nos quedamos con Cliente por adaptarse mejor al
concepto.
Eliminar clases 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.
Separar atributos
Los atributos definen datos asociados a un objeto, en lugar de objetos. Aunque la
separacin no es clara (los atributos pueden ser objetos embebidos) en algunos casos se
pueden distinguir. En el ejemplo, pueden considerarse atributos Informacin sobre la
cuenta, (atributo de Cuenta bancaria), Dinero en efectivo y Recibo (atributos de Cajero
automtico).
Separar mtodos
Algunos nombres (por ejemplo, Llamada telefnica) definen realmente operaciones o
eventos.
Eliminar objetos 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 comunicaciones, Acceso a
la cuenta y Software.
Resultado. Del anlisis anterior, resultan seleccionadas las siguientes clases (11):
Cajero automtico, Consorcio de bancos, Banco, Ordenador del banco, Cuenta bancaria,
Transaccin, Estaciones de cajero, Cajero humano, Tarjeta de crdito, Ordenador central,
Cliente.
El diccionario de clases contiene la definicin detallada de todas estas clases en lenguaje
natural. Ejemplo:
Cajero automtico: Terminal remoto que permite a los clientes realizar transacciones
utilizando tarjetas de crdito para identificarse. El cajero automtico 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 cajero automtico 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.
Banco: Institucin financiera que maneja las cuentas bancarias de sus clientes y emite
tarjetas de crdito que facilitan el acceso a dichas cuentas a travs de la red de cajeros
automticos.

Identificar y depurar relaciones

Consta de los siguientes pasos:
Seleccionar verbos relacionales en los requisitos
Aadir relaciones adicionales procedentes de nuestro conocimiento del tema
Eliminar relaciones de diseo o entre clases eliminadas
Eliminar eventos transitorios
Reducir relaciones ternarias
Eliminar relaciones redundantes o derivadas
Aadir relaciones olvidadas
Definir la multiplicidad de cada relacin
En el ejemplo de los cajeros automticos:
Seleccionar verbos relacionales en los requisitos
1. Una Red bancaria est provista de Cajeros automticos.
2. El Consorcio de bancos comparte los Cajeros automticos.
3. Cada Banco dispone de un Ordenador del banco.
4. El Ordenador del banco dispone de Software.
5. El Ordenador del banco lleva la informacin sobre las Cuentas bancarias.
6. El Ordenador del banco procesa Transacciones.
7. Una Transaccin acta sobre una Cuenta bancaria.
8. Las Estaciones de cajero estn conectadas al Ordenador del banco.
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 bancarias.
13. Los Cajeros automticos aceptan Tarjetas de crdito.
14. Los Cajeros automticos interaccionan con el Usuario.
15. Los Cajeros automticos comunican con el Ordenador central.
16. El Ordenador central lleva a cabo las Transacciones.
17. Los Cajeros automticos entregan Dinero en efectivo al Usuario.
18. Los Cajeros automticos imprimen Recibos.
19. El Sistema lleva el Registro de las transacciones.
20. El Sistema cumple Caractersticas de seguridad.
21. El Sistema maneja Accesos concurrentes a la Cuenta bancaria.
22. El Coste de desarrollo se divide entre los Bancos.
23. Los Bancos forman parte del Consorcio.
24. Los Clientes estn provistos de Tarjetas de crdito.
Relaciones adicionales implcitas en el texto:
25. Las Cuentas bancarias estn en los Bancos.
26. El Ordenador central pertenece al Consorcio.
27. Los Bancos tienen Clientes.
Aadir relaciones adicionales procedentes de nuestro conocimiento del tema
o 28. Las Tarjetas de crdito estn asociadas a las Cuentas bancarias .
o 29. Los Cajeros humanos son empleados de los Bancos.
Eliminar relaciones de diseo o entre clases eliminadas
Eliminamos las relaciones 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.
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 por:
16 a. El Ordenador central se comunica con el Banco.
Reducir relaciones ternarias

Son relaciones entre tres o ms clases. Muchas veces es posible descomponerlas en

varias relaciones binarias (entre dos clases). Por ejemplo, la relacin nmero 12
(El Cajero humano introduceTransacciones sobre las Cuentas bancarias) puede
descomponerse en:
o 12a. El Cajero humano introduce Transacciones
o 12b. Las Transacciones actan sobre las Cuentas bancarias.
De igual modo, la nmero 17 puede descomponerse as:
o 17a. Los Cajeros automticos entregan Dinero en efectivo.
o 17b. El Usuario recoge el Dinero en efectivo.
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, pero que en realidad son necesarias (por ejemplo, si la multiplicidad es
distinta).
Aadir relaciones olvidadas
Por ejemplo:
o 30. Los Clientes tienen Cuentas.
o 31. Las Transacciones son autorizadas por la Tarjeta de crdito.
o 32. Las Transacciones pueden introducirse en una Estacin de cajero.
Definir la multiplicidad de cada asociacin
o Un Banco puede contener muchas Cuentas.
o Un Cliente puede tener muchas Cuentas.
o Un Cliente puede tener muchas Tarjetas de crdito.
o Un Banco emplea muchos Cajeros.
o Un Banco tiene un solo Ordenador del banco.
o El Ordenador central se comunica con muchos Ordenadores del banco.
o Etc.
El resultado de estas operaciones es un esqueleto del modelo de clases sin herencia.

Identificar atributos de objetos y relaciones

Consta de los siguientes pasos:
Distinguir los objetos de los atributos
Distinguir entre los atributos de objetos y de relaciones
El identificador del objeto es siempre un atributo implcito
Eliminar atributos privados (de diseo)
Eliminar atributos de detalle fino
Localizar atributos discordantes (dividir la clase)
En el ejemplo de los cajeros automticos:
Atributos de los objetos
o Del Banco: Nombre.
o De la Cuenta: Saldo, Lmite de crdito, Tipo de cuenta.
o Del Cliente: Nombre, Direccin.
o Del Cajero: Nombre.
o De una Transaccin del cajero: Tipo, Fecha y hora, Cantidad.
o Del Cajero automtico: Efectivo disponible, Cantidad entregada.
o De una Transaccin remota: Tipo, Fecha y hora, Cantidad.
o De la Tarjeta de crdito: Clave, Cdigo del banco, Cdigo de la tarjeta.
Atributos de las relaciones
o 8 y 9: Cdigo de la estacin de cajero.
o 15: Cdigo del cajero automtico.
o 16a: Cdigo del banco.
o 23: Cdigo del banco.
o 25: Cdigo de la cuenta.
o 29: Cdigo de empleado.

Aadir herencia
Introducimos clases nuevas (virtuales) que contienen informacin comn a dos o ms clases
preexistentes. Procurar evitar la herencia mltiple, a menos que sea estrictamente necesaria.
Resultado: Primer diagrama de clases
En el ejemplo de los cajeros automticos:
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.
Comprobar los casos de uso (iterar)
Para localizar fallos que deben corregirse fijarse en:
Asimetras en las relaciones: aadir clases nuevas para equilibrarlas.
Atributos muy dispares: descomponer una clase en dos.
Dificultades en la formacin de superclases: descomponer una clase en dos. Una de sus
partes puede ajustar mejor.
Operaciones sin objetivo: aadir clase.
Relaciones duplicadas: crear superclase.
Conversin de relaciones en clases: por ejemplo, clase Empleado.
Operaciones que no encuentran camino para realizarse: aadir relaciones.
Relaciones redundantes: eliminarlas.
Relaciones demasiado detalladas o demasiado vagas: subirlas a una superclase o
bajarlas a una subclase.
Clases sin atributos, sin mtodos o sin relaciones: eliminarlas.
Relaciones que nadie atraviesa: eliminarlas.
Atributos de clase necesarios en un acceso: pasarlos a atributos de relacin.
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 autorizacin puede afectar a ms de una tarjeta fsica. Una misma
autorizacin puede permitir acceder a ms de una cuenta (y viceversa).
Introducimos la clase Actualizacin de cuenta para refinar el concepto 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 Oredenador central, por otra. Fusionamos esas clases.
Modularizar
Agrupar clases en mdulos.
En el ejemplo de los cajeros automticos. Posibles mdulos:
Cajeros en general: Cajero, Estacin de cajero, Cajero automtico, Estacin de
entrada.
Cuentas
en
general: Cuenta, Tarjeta
de
crdito, Autorizacin, Cliente, Transaccin, Transaccin
de
cajero, Transaccin
remota.
Bancos: Banco, Consorcio.

Aadir y simplificar mtodos

Todos los atributos se suponen accesibles.
Aadir mtodos que permitan navegar de un objeto a otro.
Modelo dinmico
Consta de los siguientes pasos:
Identificar sucesos
Construir diagramas de estados
Comprobar consistencia (iterar)
Aadir mtodos
Identificar sucesos
Los sucesos se extraen de los casos de uso (escenarios). Pueden ser de los siguientes tipos:
Seales
Entradas
Decisiones
Interrupciones
Transiciones
Acciones externas
Condiciones de error
Resultados: Diagramas de secuencia (trazas de eventos) y diagramas de colaboracin
(diagramas de flujo de eventos).
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 evento 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 automtico enva al objeto Cliente.
Agrupar los eventos 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 evento independientemente de la cantidad entregada.
No agrupar los eventos no equivalentes: El banco autoriza la transaccin es distinto evento que
El banco rechaza la transaccin.
Construir diagramas de estados
Uno por clase.
En el ejemplo de los cajeros automticos centrarse en las clases dinmicas, que cambian de
estado:
Cajero automtico
Banco
Consorcio
Estacin de cajero
No hace falta construir diagramas de estado de las clases pasivas, que no cambian de estado de
modo significativo:
Tarjeta de crdito
Transaccin
Cuenta
Tampoco hace falta considerar a fondo los objetos externos, que no forman parte del sistema
informtico:
Cliente
Cajero humano
Aadir mtodos
Los eventos son mtodos. Es preciso decidir de qu clase de objetos.
Las acciones y actividades realizadas en los estados son mtodos.

Modelo funcional
Consta de los siguientes pasos:
Identificar valores de entrada/salida
Construir diagramas de flujo de actividad
Describir funciones
Identificar restricciones y dependencias funcionales entre objetos
Definir criterios de optimizacin (iterar)
Aadir mtodos
Identificar valores de entrada/salida
Son los que pasan informacin desde los objetos externos al sistema de software propiamente
dicho.
En el ejemplo de los cajeros automticos son objetos externos:
Cliente
Tarjeta de crdito
Cajero humano
Los valores de entrada/salida sern:
Del cliente al cajero automtico: contrasea, tipo de transaccin, tipo de cuenta,
cantidad solicitada.
De la tarjeta de crdito al cajero automtico: cdigo del banco, cdigo de la tarjeta.
Del cajero automtico al cliente: dinero en efectivo, recibo, mensajes.
Construir diagramas de flujo de actividad
Relacionan los valores de entrada con los de salida. Suele dividirse en varias capas o niveles.
En el ejemplo de los cajeros automticos:
Nivel superior: relaciona el cliente, la tarjeta de crdito y la cuenta.
Nivel intermedio: expande la operacin "realizar transaccin", incluida en el nivel
superior.
Describir funciones
Descripcin de cada una de las funciones de nivel mnimo que aparecen en los diagramas de
flujo de actividad. La descripcin puede ser:
En lenguaje natural
Un modelo matemtico
Pseudocdigo
Tablas de decisin
Etc.
En el ejemplo de los cajeros automticos:
Descripcin de la funcin "actualizar cuenta":
actualizar cuenta (cuenta, cantidad, tipo de transaccin)
-> efectivo, recibo, mensaje
Si es una retirada de efectivo:
Si la cantidad a retirar excede el saldo,
rechazar la transaccin y no entregar dinero
En caso contrario:
Restar la cantidad del saldo y entregar dinero
Si es un depsito:
Aumentar el saldo de la cuenta y no entragar dinero
Si es una peticin de informacin:
Escribir saldo y no entregar dinero
En cualquier caso:
El recibo incluye:
- nmero del cajero automtico
- fecha y hora
- nmero de la cuenta

- tipo de transaccin
- cantidad movida
- nuevo saldo
Identificar restricciones y dependencias funcionales entre objetos
En el ejemplo de los cajeros automticos:
El saldo de una cuenta no puede ser negativo
o bien:
El saldo de una cuenta, si es negativo, no puede rebasar el lmite de crdito.
Definir criterios de optimizacin (iterar)
En el ejemplo de los cajeros automticos:
Minimizar el nmero de mensajes enviados entre localidades diferentes.
Minimizar el tiempo de bloqueo de una cuenta.
Extremadamente urgente: minimizar el tiempo de bloqueo de un banco entero.
Aadir mtodos
Las funciones del modelo funcional pueden ser simples transferencias de informacin, o
corresponder a un mtodo de algn objeto (operaciones interesantes). En este caso hay que
asignarlos y aadirlos al modelo de objetos.
En el ejemplo de los cajeros automticos, son interesantes:
Comprobar contrasea (mtodo de Autorizacin de la tarjeta).
Actualizar cuenta (mtodo de la clase Cuenta).
Se aadirn otros mtodos, no relacionados con ninguna de las cuestiones anteriores,
procedentes de nuestro conocimiento del tema:
Cerrar una cuenta (sobre Cuenta).
Autorizar una tarjeta de crdito (sobre Cuenta, parmetro la Autorizacin de la tarjeta).
Crear una cuenta (sobre Banco, parmetro el Cliente).
Crear una tarjeta de crdito (sobre Banco, parmetro el Cliente).
Cerrar una autorizacin (sobre Autorizacin de la tarjeta).