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 LINEA

DESCRIPCION DEL SISTEMA
Se requiere un sistema que permita a un cliente de un banco realizar transacciones bancarias en
lnea. Una vez que el usuario ingrese sus credenciales de acceso, si las credenciales son vlidas, el
sistema deber desplegar el contenido principal del sistema. El contenido principal es un men de
opciones 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 el
contenido principal. Como parte de los detalles debe mostrarse una opcin para consultar los
movimientos de la cuenta. Para realizar una transaccin el cliente deber seleccionar una de las
opciones del men, donde posteriormente debe seleccionar la cuenta con la que desea realizar dicha
transaccin.
Al realizar una transaccin, el sistema debe validar que la cuenta que est siendo cargada (a la que
se le est restando de su saldo) tenga suficiente saldo para poder ser cargada.

MODELO CONCEPTUAL
Como ya hemos estudiado, uno de los procesos ms crticos del diseo es la identificacin de las
clases del modelo. Al habernos familiarizado con el sistema a travs de los casos de uso, podemos
tener una idea ms clara de los objetos que intervienen en los procedimientos para los que ser
usado el sistema.
El modelo conceptual es un primer esbozo de lo que ser el diagrama de clases. Sirve principalmente
para identificar las clases de las que estar constituido el modelo de clases. Por tratarse de un
esbozo no es necesario detallar las caractersticas especficas de cada clase. El identificar las clases
sin entrar en sus detalles nos permitir posteriormente crear los diagramas de secuencia, que nos
permitir identificar claramente los atributos y principalmente las operaciones que debe realizar cada
clase.
Como se mencion antes, el objetivo principal del modelo conceptual es identificar las entidades que
conformarn el modelo y sus relaciones. Algunos autores recomiendan retomar el texto de la
descripcin 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 del
modelo. En cualquier caso, todas las propuestas redundan en que se trata de identificar los
conceptos ms relevantes del fenmeno en anlisis.
Sin importar como se inicie la identificacin de las clases, podemos usar algunos criterios para filtrar
dichas 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 mejor
se 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 los
nombres corresponden a propiedades ms que entidades independientes.
6. Se deben eliminar las clases que debieran ser roles ms que clases. Esto es cuando los
nombres 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 cuando
las entidades representan operaciones que son aplicadas a los objetos y no entidades
manipuladas por s mismas.
8. Se deben eliminar las clases que corresponden a construcciones de implementacin si estn
alejadas del mundo real, por lo cual deben ser eliminadas del anlisis. No se necesita una
clase para representar una entidad fsica Por ejemplo: subrutinas, listas, y arreglos, son clases
tpicas 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 clase
Banco pareciera que no tiene un significado importante en el modelo. A pesar que el sistema es para
un banco, no aporta ninguna informacin u operacin relevante al proceso.
Algunos autores recomiendan no modelar las entidades que representen actores. Esto es til para
preservar la claridad a la hora de hacer los diagramas. Sin embargo, no es una restriccin del
modelado, y cuando el nombre de una entidad describa mejor el objeto modelado, puede optarse por
mantenerse y diferenciarlos con nombres especficos en los diagramas. En este caso, para evitar
ambigedades 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 son
los que generan modificaciones a los saldos de las cuentas. Lo mismo ocurre con la clase
Transaccion, 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 las
entidades deben tener un significado (semntica) claro y lgico. Resulta lgico decir que un usuario
es un cliente que tiene una o varias cuentas en el banco. Esta relacin tiene una direccin bien
definida, 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 sale
la asociacin conoce de la relacin, pero para la entidad a la que llega esa relacin es desconocida e
irrelevante.
En general este tipo de relaciones son muy poco frecuentes, ya que limitan el acceso entre las clases
involucradas en cualquier direccin. Por ejemplo, si tuviramos una lista de cuentas indistintamente
de quienes son sus dueos, cmo podramos conocer el usuario dueo si no se nos permite
navegar en esa direccin a travs de la asociacin?. Sin embargo, dado que el problema no nos pide
por ejemplo, un reporte de las cuentas que ha tenido movimiento en el da y la informacin de sus
dueos, podemos asumir que la asociacin con navegabilidad es suficiente para el problema
propuesto.

Asumiremos en este caso que una cuenta puede pertenecer a un solo cliente (usuario en el modelo
del negocio). Esto nos servir para describir en el modelo la multiplicidad. En Astah puede definir la
multiplicidad haciendo clic sobre la relacin y especificndolo en la vista de propiedades de la
relacin, en la pestaa End A o End B segn corresponda. Tambin puede especificarse haciendo clic
sobre la relacin y pasando el puntero del ratn sobre el final de la lnea, cuando aparezca la letra m
hacer 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 utilizados
como 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<Cuenta> cuentas; // o Cuenta[ ] cuentas;
}

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

public class Cuenta{

Otra relacin que podemos advertir es que los movimientos se realizan sobre cuentas. Esto significa
que 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 los
movimientos. Esta relacin sera til para saber qu cliente realiz cada movimiento. Sin embargo, no
es algo que se solicite en la descripcin del problema, por lo que la omitiremos en nuestro diseo.

PREGUNTAS
1. Al analizar las clases candidatas en el ejemplo, la entidad Banco debera mantenerse en el
modelo 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 estn
disponibles para programar el componente de interfaces de usuario?. Dependiendo de la
seleccin de la tecnologa, cmo se modifican los objetos de frontera y de control en los
diagramas de secuencia?.
3. Adems de un componente de interfaces de usuario, qu otros componentes podra requerir
nuestra aplicacin?.

EJERCICIOS
1. Elabore un diagrama de clases para los ejercicios de la gua anterior: Sistema de inventarios y
Sistema de pagos.
2. Elabore un diagrama de clases que mejor describa el sistema que se utiliza actualmente en la
biblioteca para prstamo de libros.
3. Elabore un diagrama de clases que mejor describa la compra de productos en lnea a travs
de 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 juego
antiguo, parecido a X-0, que consta de un tablero cuadrado en el que figuran las diagonales y
dos lneas paralelas a los lados por el punto medio (paralelas medias). La interseccin de
estas lneas son los lugares o las casillas en los que se colocan las fichas. Juegan dos
jugadores, en nuestro caso un jugador y nuestra aplicacin. En cada turno, cada jugador pone
sus fichas en el tablero, cuando las 6 fichas estn en el tablero, se mueven a los puntos
adyacentes por turnos. El objetivo es colocar 3 fichas en una misma lnea (horizontal, vertical
o diagonal).