Diseo Orientado a Objetos

Diseo de la arquitectura

Una de las principales actividades del diseo es la particin de

funcionalidad, identificada en la fase de anlisis y especificacin de
requerimientos, en mdulos de software especficos. Un modulo puede
corresponder a un objeto, o un mtodo.

Especficamente, el diseo del sistema est orientado alrededor de la

definicin de objetos que representan las clases que fueron identificadas
durante el anlisis, dndose el mismo nfasis al diseo de los datos que a
las acciones del sistema.

El resultado de disear los mdulos de un sistema de software se le

conoce como diseo de la arquitectura del sistema. El diseo de la
arquitectura es el primer paso en el diseo, va seguido del diseo
detallado y la fase de pruebas del diseo.

Diseo detallado. Durante esta fase, cada uno de los mdulos

identificados durante el diseo de la arquitectura es especificado a detalle,
incluyendo seudocdigo representando los algoritmos, las firmas y los
datos miembros.

Pruebas del diseo. Sirve para verificar que los requerimientos se estn
incluyendo conforme a las especificaciones. Las estructuras creadas
durante el diseo de la arquitectura son un vehculo importante para las
pruebas del diseo, en las que se siguen los escenarios de los casos de
uso en una simulacin del uso del sistema. Dichas pruebas son
imposibles sin la representacin de los mdulos y sus inter-relaciones
(acoplamiento).
Una buena arquitectura promueve facilidad de entendimiento, pruebas
ms rpidas, bsqueda de errores ms veloz, y un mejor mantenimiento y
ampliacin del sistema.

Pasos del diseo orientado a objetos

Las actividades del diseo se pueden agrupar en los pasos siguientes:

1. Producir un diagrama de interaccin para cada escenario de caso de

uso identificado durante el anlisis.

2. Producir un diagrama de clases detallado mostrando las operaciones

de los diagramas de interaccin. Se utiliza como base el modelo del
dominio generado en el anlisis para incluir la lista completa de
operaciones. Tambin se agregan clases y relaciones tanto como sea
necesario.

3. Especificar las firmas y algoritmos de cada operacin. Las firmas son la

lista de parmetros de las operaciones con sus tipos y los valores de
retorno. El diseador especifica los algoritmos a implementarse para cada
mtodo, as como las variables internas y las estructuras de datos
requeridas por cada mtodo.

4. Disear la interfaz grfica del usuario

5. Definir la interfaz de la capa de presentacin

6. Definir la interfaz a la capa de almacenamiento de datos

7. Acomodar las clases en paquetes.

Diagramas de Interaccin en UML

UML soporta dos tipos de diagramas de interaccin: de secuencia y de

colaboracin. Dichos diagramas muestran los objetos del sistema y el
paso de mensajes entre ellos.

Los diagramas de secuencia enfatizan la secuencia cronolgica de los

mensajes y son importantes para entender el orden en el que ciertos
eventos ocurren en el sistema.
Los diagramas de colaboracin enfatizan la relacin entre objetos y son
importantes para entender la estructura del sistema, qu tanto depende un
objeto de otro (acoplamiento).

Diagramas de secuencia

La notacin grfica usada en UML para especificar diagramas de

secuencia incluye los siguientes elementos

Agentes externos (como el usuario) y todos los objetos en el sistema se

representan por lneas paralelas punteadas con el nombre del actor u
objeto en la parte superior.

Cuando slo hay un objeto de una misma clase en el diagrama de

secuencia, se prefiere el nombre de la clase.

Mensajes de un actor a un objeto, o entre objetos, se representan como

flechas etiquetadas, saliendo del objeto que invoca el mensaje al objeto
que cumple con la responsabilidad de ejecutar el mensaje. El orden de los
mensajes va de forma vertical, de arriba hacia abajo.

El diagrama de secuencia se genera de las clases descubiertas en el

anlisis y por medio de los casos de uso.

El proceso de creacin es iterativo, conforme se van creando nuevos

diagramas de secuencia el diagrama de clases detallado se modifica y
completa. Las operaciones descubiertas (mensajes entre objetos) en los
diagramas de secuencia se agregan al diagrama de clases de diseo.

Notacin bsica de diagramas de secuencia

Objeto:

Caja de lnea de vida. A la lnea punteada se le conoce como

lnea de vida, puede ser continua o slida.

Mensaje a Otro Objeto:

En cdigo esto se representara de la siguiente manera:

public class ClaseA

private ClaseB unaB = new ClaseB();

public void mensaje1()

unaB.mensaje2();

unaB.mensaje3();

// .

Frames
UML usa frames para proveer ciclos, manejo de condiciones, entre otros.
El frame lleva en la esquina superior izquierda una etiqueta que indica el
tipo de operador, y puede o no llevar una sentencia condicional (conocida
como guarda) entre corchetes cuadrados. A continuacin se sumarizan
los operadores ms comunes.

Alt Fragmento donde hay varias alternativas divididas por la(s)

condicin(s) de guarda

Loop Ciclo que se ejecuta si la condicin es verdadera. Puede

escribirse loop(n) para indicar el nmero de ciclos.

Opt Fragmento opcional que slo se ejecuta si la condicin es

verdadera.

Par Fragmentos que se ejecutan en paralelo.

Region Regin crtica donde slo un thread o hilo puede ejecutarse.

:C
: Caj ero

LOOP [m s artcul os]

capturaArti cul o(i tem ID, canti dad)

Mensaje al Mismo Objeto:

Retornos

A B

x1= getValor()

Dos formas de
mostrar un valor
de retorno de un
getValor() mensaje

return unValor

En el presente ejemplo, tenemos el diagrama de interaccin proveniente

del siguiente diagrama de clases:

Aqu se representa una aplicacin que posee una Ventana grfica, y sta
a su vez posee internamente un botn.

Entonces el diagrama de interaccin para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos)
y la llamada a Paint() por el objeto Botn.

En el siguiente ejemplo se muestran diferentes opciones de notacin

vlidas para crear diagramas de secuencia.
 f ormaRenta : : Cliente : Renta : Video : Clasif icacion : Factura
: Customer (FormaRenta)

El actor captura el id del CapturaId ( )

cliente (cdigo de barras) (E1) getDatosCliente (
El sistema despliega los datos
del cliente despliega datos
El sistema despliega opciones
El cliente elige la opcin rentar despliega opciones

El sistema valida si el cliente

tiene pelculas no devueltas
El sistema obtiene el saldo E2 Elige opcin
TienePend= validaRentasPendientesSaldar ( )
E3

[para cada renta devuelta del cliente]

multa =multa (

Saldo = Saldo +
El actor captura el id de la multa
pelcula
El sistema despliega los datos
de la pelcula
Inicio de un
loop para
CapturaIdPelicula
El cliente conf irma la renta getDatosVideo (

despliega datos
El sistema determina cuntos
das se puede prestar la
pelcula, la multa por da para
esa pelcula y la f echa de Conf irma
devolucin

montoRenta=crearRenta (Cliente,
getClasif icacion (

getDiasRenta

getCostoRenta ( )

getMultaPorDia (

calcula f echa
El sistema registra la renta de
la pelcula (cliente-pelcula)

registra

El sistema obtiene el total de cambiaEstado (

la renta
Saldo =Saldo+ montoRenta

Fin del loop para c/pelcula que

se desea rentar

El cliente conf irma el pago

El sistema registra la renta Mostrar saldo

Conf irmar pago

registraRenta ( )
cambiaEstado (
Si el cliente est pagando
multas pasadas se registra el
pago.

El sistema genera e imprime la [si Saldo>montoRenta]

f actura

creaFactura

imprime (argtype)
Diagramas de secuencia de sistema

Un diagrama de secuencia de sistema (SSD) es un artefacto de fcil

creacin que ilustra los eventos de entrada y salida del sistema bajo
diseo. Los SSDs sirven como entrada para el diseo y son una actividad
previa a la generacin de diagramas de interaccin.

: Cajero : Sistema
Frame de UML para
nuevaVenta manejo de ciclo
(loop) de UML, con
"condicin de
guarda" booleana
LOOP [ms artculos]
capturaArticulo(itemID, cantidad)
return descripcin, total

finVenta

return total con impuestos

pagar (cantidad: Money)

return cambio, recibo Mensaje con
parmetros
Diagramas de colaboracin

En contraste con los diagramas de secuencia los diagramas de

colaboracin enfatizan la relacin entre los objetos. La notacin de UML
incluye:

Actores, representados igual que en el diagrama se secuencia. Objetos

representados como rectngulos con el nombre del objeto dentro de l. El
acoplamiento entre objetos (que implica que un objeto pasa uno o ms
mensajes al otro) es representado como una lnea slida sin direccin
uniendo a ambos rectngulos. Cada mensaje individual es representado
como lneas con direccin con la flecha apuntando en la direccin en que
es invocado el mensaje. Las etiquetas de los mensajes incluyen
numeracin para denotar el orden cronolgico en que ocurren los eventos.

1: nu eva Venta
2: capturaArti cul o(i tem ID, canti d ad)
3: fi n Ven ta
4: pa gar (ca nti dad: M o ney)

: Si stem a

: Caj ero
Despus de generar los diagramas de interaccin, es posible crear
diagramas de clases detallados que refinan y finalizan la propuesta de
clases del sistema. Recordemos que en la fase del anlisis se produce en
diagrama de clases preliminar mostrando las clases, atributos y
asociaciones, pero no se da detalle de las operaciones.

La tarea bsica del diagrama de clases del diseo es asociar los

mensajes especificados en los diagramas de interaccin con las clases en
particular. Tpicamente un mensaje est asociado con la clase a quin se
le enva el mensaje (hacia a donde apunta la flecha).

Existen al menos tres tcnicas para decidir como asociar los mensajes
con las clases:

Ocultamiento de la informacin. Ya que las variables del estado de una

clase pueden declararse como privadas o protegidas, las acciones sobre
estas variables deben ser locales a la clase en la que se declaran. Es
decir, los atributos deben tener operaciones que accedan, modifiquen, al
valor del atributo slo dentro de la misma clase donde se declaran.

Reducir redundancia. Si una accin es invocada por un distinto nmero de

clientes de un objeto en particular, se debe tener una sola copia de esa
accin implementada como un mtodo del objeto. La alternativa, tener una
copia idntica del mtodo en la clase cliente es redundante, agrega
complejidad al cdigo y reduce la modularidad y extensibilidad del cdigo.

Diseo dirigido por responsabilidades. De acuerdo con el principio de

cohesin, los mdulos que agrupan todas las acciones sobre un conjunto
de datos tienen alta cohesin, y en el diseo debe promoverse este tipo
de cohesin. Entonces, los mtodos deben implementarse en los objetos
que operan sobre los datos directamente.

El diagrama de clases del diseo especifica suficiente informacin acerca

de la estructura de los mdulos (incluyendo la firma de los mtodos) que
es posible que el programador inicie la implementacin de las clases
basado en este diagrama.

En otros documentos se ve con ms detalle la notacin del diagrama de

clases del diseo y el proceso para su creacin.
 Referencias:

Larman, Craig. Applying UML and Patterns: an introduction to object-

oriented analysis and design and iterative development. Prentice Hall PTR,
c2005

Stumpf, Robert, et al. 2005. Object Oriented Systems Analysis and Design
with UML, Pearson Education.

Booch, Grady, 1994. Objected-Oriented Analysis And Design W ith

Applications, 2nd Ed., Menlo Park, CA: Addison-W esley.
Jacobson, Ivar. et al. 1992. Object Oriented Software Engineering: a Use
Case Driven Approach. Addison W esley Publishing Company.