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.

: Caj ero

:C

LOOP

[m s artcul os] capturaArti cul o(i tem ID, canti dad)

Mensaje al Mismo Objeto:

Retornos
A x1= getValor() Dos formas de mostrar un valor de retorno de un mensaje B

getValor() 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.

: Customer

f ormaRenta : (FormaRenta)

: Cliente

: Renta

: Video

: Clasif icacion

: Factura

El actor captura el id del cliente (cdigo de barras) (E1) El sistema despliega los datos del cliente El sistema despliega opciones El cliente elige la opcin rentar

CapturaId ( ) getDatosCliente ( despliega datos despliega opciones

El sistema valida si el cliente tiene pelculas no devueltas El sistema obtiene el saldo E2 E3

Elige opcin TienePend= validaRentasPendientesSaldar ( )

[para cada renta devuelta del cliente] multa =multa ( Saldo = Saldo + multa

El actor captura el id de la pelcula El sistema despliega los datos de la pelcula

CapturaIdPelicula El cliente conf irma la renta

Inicio de un loop para 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 devolucin

Conf irma

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 la renta Saldo =Saldo+ montoRenta cambiaEstado (

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 f actura [si Saldo>montoRenta]

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 nuevaVenta LOOP

: Sistema Frame de UML para manejo de ciclo (loop) de UML, con "condicin de guarda" booleana

[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 objectoriented 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.