Ejemplo de Analisis Orientado A Objetos
Ejemplo de Analisis Orientado A Objetos
Ejemplo de Analisis Orientado A Objetos
http://arantxa.ii.uam.es/~alfonsec/atm.htm
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
1 de 5
http://arantxa.ii.uam.es/~alfonsec/atm.htm
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.
2 de 5
http://arantxa.ii.uam.es/~alfonsec/atm.htm
12b. Las Transacciones actan sobre las Cuentas bancarias. De igual modo, la nmero 17 puede descomponerse as: 17a. Los Cajeros automticos entregan Dinero en efectivo. 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: 30. Los Clientes tienen Cuentas. 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. Un Banco emplea muchos Cajeros. Un Banco tiene un solo Ordenador del banco. El Ordenador central se comunica con muchos Ordenadores del banco. Etc. El resultado de estas operaciones es un esqueleto del modelo de clases sin herencia.
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.
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.
3 de 5
http://arantxa.ii.uam.es/~alfonsec/atm.htm
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.
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
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:
4 de 5
http://arantxa.ii.uam.es/~alfonsec/atm.htm
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).
5 de 5