UNIVERSIDAD DE EL SALVADOR

FACULTAD DE INGENIERIA Y ARQUITECTURA

ESCUELA DE INGENIERIA DE SISTEMAS INFORMATICOS

HERRAMIENTAS DE PRODUCTIVIDAD

DISEO ORIENTADO A OBJETOS

UML

DIAGRAMA DE CLASES BANCA EN LINEADIAGRAMA DE CLASES BANCA EN LINEA

DESCRIPCION DEL SISTEMASe requiere un sistema que permita a un cliente de un banco realizar transacciones bancarias enlnea. Una vez que el usuario ingrese sus credenciales de acceso, si las credenciales son vlidas, elsistema deber desplegar el contenido principal del sistema. El contenido principal es un men deopciones y un lista de cuentas asociadas al cliente.

El cliente podr ver los detalles de la cuenta seleccionndola de la lista de cuentas mostradas en elcontenido principal. Como parte de los detalles debe mostrarse una opcin para consultar losmovimientos de la cuenta. Para realizar una transaccin el cliente deber seleccionar una de lasopciones del men, donde posteriormente debe seleccionar la cuenta con la que desea realizar dichatransaccin.

Al realizar una transaccin, el sistema debe validar que la cuenta que est siendo cargada (a la quese le est restando de su saldo) tenga suficiente saldo para poder ser cargada.

MODELO CONCEPTUALComo ya hemos estudiado, uno de los procesos ms crticos del diseo es la identificacin de lasclases del modelo. Al habernos familiarizado con el sistema a travs de los casos de uso, podemostener una idea ms clara de los objetos que intervienen en los procedimientos para los que serusado el sistema.

El modelo conceptual es un primer esbozo de lo que ser el diagrama de clases. Sirve principalmentepara identificar las clases de las que estar constituido el modelo de clases. Por tratarse de unesbozo no es necesario detallar las caractersticas especficas de cada clase. El identificar las clasessin entrar en sus detalles nos permitir posteriormente crear los diagramas de secuencia, que nospermitir identificar claramente los atributos y principalmente las operaciones que debe realizar cadaclase.

Como se mencion antes, el objetivo principal del modelo conceptual es identificar las entidades queconformarn el modelo y sus relaciones. Algunos autores recomiendan retomar el texto de ladescripcin del sistema e identificar aquellas palabras que sean sustantivos. Todas esas palabras,sern una clase candidata. Existen otras propuestas sobre como comenzar a identificar las clases delmodelo. En cualquier caso, todas las propuestas redundan en que se trata de identificar losconceptos ms relevantes del fenmeno en anlisis.

Sin importar como se inicie la identificacin de las clases, podemos usar algunos criterios para filtrardichas clases, que usualmente se llaman Candidatas de acuerdo a los siguientes criterios:

1. Todas las clases deben tener sentido en el rea de la aplicacin.

2. Los nombres para las clases no deben ser ambiguos y debe escogerse un nombre que mejorse apliquen al problema. En general, deben asignarse nombres de clase en singular.

3. Se deben eliminar clases redundantes. Si una clase expresa la misma informacin que otra,debe mantenerse la clase ms descriptiva.

4. Se deben eliminar clases irrelevantes que tienen poco o nada que ver con el problema.

5. Se deben eliminar las clases que debieran ser atributos ms que clases. Esto es cuando losnombres corresponden a propiedades ms que entidades independientes.

6. Se deben eliminar las clases que debieran ser roles ms que clases. Esto es cuando losnombres corresponden al papel que juegan las clases ms que entidades independientes.

7. Se deben eliminar las clases que debieran ser operaciones ms que clases. Esto es cuandolas entidades representan operaciones que son aplicadas a los objetos y no entidadesmanipuladas por s mismas.

8. Se deben eliminar las clases que corresponden a construcciones de implementacin si estnalejadas del mundo real, por lo cual deben ser eliminadas del anlisis. No se necesita unaclase para representar una entidad fsica Por ejemplo: subrutinas, listas, y arreglos, son clasestpicas de implementacin; Internet y Web son el medio de implementacin del sistema.

Clases candidatas:

Banco

Usuario

Cliente

Cuenta

Movimiento

Transaccion

Ahora podemos analizar si las clases cumplen con los criterios descritos anteriormente. La claseBanco pareciera que no tiene un significado importante en el modelo. A pesar que el sistema es paraun banco, no aporta ninguna informacin u operacin relevante al proceso.

Algunos autores recomiendan no modelar las entidades que representen actores. Esto es til parapreservar la claridad a la hora de hacer los diagramas. Sin embargo, no es una restriccin delmodelado, y cuando el nombre de una entidad describa mejor el objeto modelado, puede optarse pormantenerse y diferenciarlos con nombres especficos en los diagramas. En este caso, para evitarambigedades usaremos el nombre Usuario para referirnos a los datos del cliente dentro del sistema.

La clase Movimiento se refiere a los movimientos realizados en una cuenta. Estos movimientos sonlos que generan modificaciones a los saldos de las cuentas. Lo mismo ocurre con la claseTransaccion, por lo que eliminaremos esta ltima ya que se convierte en una entidad redundante.Despus de este breve anlisis, las clases del modelo son: Usuario, Cuenta y Movimiento.

Agregue un diagrama de clases al modelo nombrndolo Clases del modelo.

Recordemos que las clases identificadas son Usuario, Cuenta y Movimiento. Las relaciones entre lasentidades deben tener un significado (semntica) claro y lgico. Resulta lgico decir que un usuarioes un cliente que tiene una o varias cuentas en el banco. Esta relacin tiene una direccin biendefinida, puesto que usualmente es a travs del usuario que llegaremos a las cuentas y no al revs.Para estos casos usamos la navegabilidad unidireccional, que significa que la entidad de la que salela asociacin conoce de la relacin, pero para la entidad a la que llega esa relacin es desconocida eirrelevante.

En general este tipo de relaciones son muy poco frecuentes, ya que limitan el acceso entre las clasesinvolucradas en cualquier direccin. Por ejemplo, si tuviramos una lista de cuentas indistintamentede quienes son sus dueos, cmo podramos conocer el usuario dueo si no se nos permitenavegar en esa direccin a travs de la asociacin?. Sin embargo, dado que el problema no nos pidepor ejemplo, un reporte de las cuentas que ha tenido movimiento en el da y la informacin de susdueos, podemos asumir que la asociacin con navegabilidad es suficiente para el problemapropuesto.

Asumiremos en este caso que una cuenta puede pertenecer a un solo cliente (usuario en el modelodel negocio). Esto nos servir para describir en el modelo la multiplicidad. En Astah puede definir lamultiplicidad haciendo clic sobre la relacin y especificndolo en la vista de propiedades de larelacin, en la pestaa End A o End B segn corresponda. Tambin puede especificarse haciendo clicsobre la relacin y pasando el puntero del ratn sobre el final de la lnea, cuando aparezca la letra mhacer clic sobre ella y elegir la multiplicidad deseada.

El modelo con multiplicidad y nombre de la relacin ser el siguiente:

Aunque no es una norma, los nombres de los roles de una asociacin usualmente son utilizadoscomo nombres de los atributos de las clases.

Por ejemplo, el siguiente cdigo Java ser el correspondiente para la clase Usuario.

public class Usuario{

public List cuentas; // o Cuenta[ ] cuentas;

}

La clase Cuenta no hace referencia a la clase Usuario, puesto que la navegabilidad le oculta a laentidad Cuenta esa relacin y no conoce del cliente al que pertenece, por lo que el cdigo Java parala clase Cuenta hasta este momento ser:

public class Cuenta{

}

Otra relacin que podemos advertir es que los movimientos se realizan sobre cuentas. Esto significaque una cuenta puede tener muchos movimientos y un movimiento afecta una relacin.

En este momento podemos identificar una relacin adicional puesto que los usuarios realizar losmovimientos. Esta relacin sera til para saber qu cliente realiz cada movimiento. Sin embargo, noes algo que se solicite en la descripcin del problema, por lo que la omitiremos en nuestro diseo.

PREGUNTASPREGUNTAS

1. Al analizar las clases candidatas en el ejemplo, la entidad Banco debera mantenerse en elmodelo si se trata de un sistema para todo el sistema financiero?, por qu?.

2. Suponiendo que el sistema se implementar en Java, qu tecnologas conoce que estndisponibles para programar el componente de interfaces de usuario?. Dependiendo de laseleccin de la tecnologa, cmo se modifican los objetos de frontera y de control en losdiagramas de secuencia?.

3. Adems de un componente de interfaces de usuario, qu otros componentes podra requerirnuestra aplicacin?.

EJERCICIOSEJERCICIOS

1. Elabore un diagrama de clases para los ejercicios de la gua anterior: Sistema de inventarios ySistema de pagos.

2. Elabore un diagrama de clases que mejor describa el sistema que se utiliza actualmente en labiblioteca para prstamo de libros.

3. Elabore un diagrama de clases que mejor describa la compra de productos en lnea a travsde Amazon.com.

4. Elabore un diagrama de clases que modele un juego de damas.

5. Elabore un diagrama de clases que modele el juego de tres en lnea. Tres en lnea es un juegoantiguo, parecido a X-0, que consta de un tablero cuadrado en el que figuran las diagonales ydos lneas paralelas a los lados por el punto medio (paralelas medias). La interseccin deestas lneas son los lugares o las casillas en los que se colocan las fichas. Juegan dosjugadores, en nuestro caso un jugador y nuestra aplicacin. En cada turno, cada jugador ponesus fichas en el tablero, cuando las 6 fichas estn en el tablero, se mueven a los puntosadyacentes por turnos. El objetivo es colocar 3 fichas en una misma lnea (horizontal, verticalo diagonal).