Diseño Orientado a Objetos
Diseño de la arquitectura
Una de las principales actividades del diseño es la partición de funcionalidad, identificada en la fase de análisis y especificación de requerimientos, en módulos de software específicos. Un modulo puede corresponder a un objeto, o un método.
Específicamente, el diseño del sistema está orientado alrededor de la definición de objetos que representan las clases que fueron identificadas durante el análisis, dándose el mismo énfasis al diseño de los datos que a las acciones del sistema.
Pasos del diseño orientado a objetos
Las actividades del diseño se pueden agrupar en los pasos siguientes:
1. Producir un diagrama de interacción para cada escenario de caso de uso identificado durante el análisis.
2. Producir un diagrama de clases detallado mostrando las operaciones de los diagramas de interacción. Se utiliza como base el modelo del dominio generado en el análisis para incluir la lista completa de operaciones. También se agregan clases y relaciones tanto como sea
necesario.
3. Especificar las firmas y algoritmos de cada operación. Las firmas son la lista de parámetros de las operaciones con sus tipos y los valores de retorno. El diseñador especifica los
algoritmos a implementarse para cada método, así como las variables internas y las estructuras de datos requeridas por cada método.
4. Diseñar la interfaz gráfica del usuario
5. Definir la interfaz de la capa de presentación
6. Definir la interfaz a la capa de almacenamiento de datos 7. Acomodar las clases en paquetes.
Diagramas de Interacción en UML
UML soporta dos tipos de diagramas de interacción: de secuencia y de colaboración. Dichos diagramas muestran los objetos del sistema y el paso de mensajes entre ellos.
Los diagramas de secuencia enfatizan la secuencia cronológica de los mensajes y son importantes para entender el orden en el que ciertos eventos ocurren en el sistema.
Los diagramas de colaboración enfatizan la relación entre objetos y son importantes para entender la estructura del sistema, qué tanto depende un objeto de otro (acoplamiento).
Diagramas de secuencia
La notación gráfica 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 líneas paralelas punteadas con el nombre del actor u objeto en la parte superior.
Cuando sólo 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 análisis y por medio de los casos de uso.
El proceso de creación 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 diseño.
Notación básica de diagramas de secuencia Objeto:
Caja de línea de vida. A la línea punteada se le conoce como “línea de vida”, puede ser continua o sólida.
Mensaje a Otro Objeto:
En código esto se representaría 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 continuación se sumarizan los operadores más comunes.
Alt Fragmento donde hay varias alternativas divididas por la(s) condición(s) de guarda
Loop Ciclo que se ejecuta si la condición es verdadera. Puede escribirse loop(n) para indicar el número de ciclos.
Opt Fragmento opcional que sólo se ejecuta si la condición es verdadera.
Par Fragmentos que se ejecutan en paralelo.
Region Región crítica donde sólo un thread o hilo puede ejecutarse.
: Caj ero : C
ca pturaArti cul o(i tem ID, ca nti dad) LOOP [m ás artícul o s]
Mensaje al Mismo Objeto:
Retornos
En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente diagrama de clases:
Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee internamente un botón.
Entonces el diagrama de interacción para dicho modelo es:
A
x1=
getValor()
getV alor() return unValor
Dos formas de mostrar un valor de retorno de un men saje
En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a Paint() por el objeto Botón.
En el siguiente ejemplo se muestran diferentes opciones de notación válidas para crear diagramas de secuencia.
: Customer
El actor captura el id del cliente (código de barras) (E1) El sistema despliega los datos del cliente
El sistema despliega opciones El cliente elige la opción rentar
El sistema valida si el cliente tiene películas no devueltas El sistema obtiene el saldo E2 E 3
El actor captura el id de la película
El sistema despliega los datos de la película
El cliente confirma la renta
El sistema determina cuántos días se puede prestar la película, la multa por día para esa película y la fecha de devolución
El sistema registra la renta de la película (cliente-película)
El sistema obtiene el total de la renta
El cliente confirma el pago El sistema registra la renta
Si el cliente está pagando multas pasadas se registra el pago.
El sistema genera e imprime la factura
formaRenta : (FormaRenta)
: Cliente : Renta : Video : Clasificacion : Factura
CapturaId ( )
getDatosCliente (
despliega datos despliega opciones
Elige opción
TienePend= validaRentasPendientesSaldar ( )
multa =multa ( [para cada renta devuelta del cliente]
Saldo = Saldo + multa
CapturaIdPelicula
getDatosVideo (
despliega datos
Confirma
montoRenta=crearRenta (Cliente, getClasificacion ( getDiasRenta getCostoRenta ( ) getMultaPorDia ( calcula fecha
registra
cambiaEstado ( Inicio de un
loop para
Saldo =Saldo+ montoRenta
Fin del loop para c/película que se desea rentar
Mostrar saldo
Confirmar pago
registraRenta ( )
cambiaEstado (
[si Saldo>montoRenta]
borraRentasDevueltas(
creaFactura
imprime (argtype)
Diagramas de secuencia de sistema
Un diagrama de secuencia de sistema (SSD) es un artefacto de fácil creación que ilustra los eventos de entrada y salida del sistema bajo diseño. Los SSDs sirven como entrada para el diseño y son una actividad previa a la generación de diagramas de interacción.
Diagramas de clases del diseño
Después de generar los diagramas de interacción, es posible crear diagramas de clases detallados que refinan y finalizan la propuesta de clases del sistema. Recordemos que en la fase del análisis se produce en diagrama de clases preliminar mostrando las clases, atributos y asociaciones, pero no se da detalle de las operaciones.
La tarea básica del diagrama de clases del diseño es asociar los mensajes especificados en los diagramas de interacción con las clases en particular. Típicamente un mensaje está asociado con la clase a quién se le envía el mensaje (hacia a donde apunta la flecha).
Existen al menos tres técnicas para decidir como asociar los mensajes con las clases:
Ocultamiento de la información. 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 sólo dentro de la misma clase donde se declaran.
Reducir redundancia. Si una acción es invocada por un distinto número de clientes de un objeto en particular, se debe tener una sola copia de esa acción implementada como un método del objeto. La alternativa, tener una copia idéntica del método en la clase cliente es redundante, agrega complejidad al código y reduce la modularidad y extensibilidad del código.
Diseño dirigido por responsabilidades. De acuerdo con el principio de cohesión, los módulos que agrupan todas las acciones sobre un conjunto de datos tienen alta cohesión, y en el diseño debe promoverse este tipo de cohesión. Entonces, los métodos deben implementarse en los objetos que operan sobre los datos directamente.
El diagrama de clases del diseño especifica suficiente información acerca de la estructura de los módulos (incluyendo la firma de los métodos) que es posible que el programador inicie la implementación de las clases basado en este diagrama.
En otros documentos se ve con más detalle la notación del diagrama de clases del diseño y el proceso para su creación.
Referencias:
: Caj ero
: Siste nuevaV ma
enta
capturaArticulo(itemID, cantidad)
return descripción, total
finV ent a LOOP [más artículos]
return total con impuestos
pagar (cantidad:
Money) return cambio,
recibo Mensaje
con parám etros
Frame de UML para
manejo de ciclo
(loop) de UML, con "condició n de guarda"
booleana
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 With Applications, 2nd Ed., Menlo Park, CA: Addison-Wesley.
Jacobson, Ivar. et al. 1992. Object Oriented Software Engineering: a Use Case Driven Approach.
Addison Wesley Publishing Company.
