OOAD – Diseño orientado a objetos

Después de la fase de análisis, el modelo conceptual se desarrolla aún más en un modelo orientado a objetos utilizando el diseño orientado a objetos (OOD). En el diseño orientado a objetos, los conceptos independientes de la tecnología en el modelo de análisis se asignan a clases de implementación, se identifican las restricciones y se diseñan las interfaces, lo que resulta en un modelo para el dominio de la solución. En pocas palabras, se construye una descripción detallada que especifica cómo se va a construir el sistema sobre tecnologías concretas

Las etapas para el diseño orientado a objetos pueden identificarse como –

• Definición del contexto del sistema
• Diseño de la arquitectura del sistema
• Identificación de los objetos del sistema
• Construcción de los modelos de diseño
• Especificación de las interfaces de los objetos

Diseño del sistema

El diseño de sistemas orientados a objetosEl diseño de sistemas orientados a objetos implica la definición del contexto de un sistema seguido del diseño de la arquitectura del mismo.

• Contexto – El contexto de un sistema tiene una parte estática y otra dinámica. El contexto estático del sistema se diseña utilizando un simple diagrama de bloques de todo el sistema que se expande en una jerarquía de subsistemas. El modelo del subsistema se representa mediante paquetes UML. El contexto dinámico describe cómo interactúa el sistema con su entorno. Se modela utilizando diagramas de casos de uso.

• Arquitectura del sistema – La arquitectura del sistema se diseña sobre la base del contexto del sistema de acuerdo con los principios de diseño arquitectónico, así como el conocimiento del dominio. Normalmente, un sistema se divide en capas y cada capa se descompone para formar los subsistemas.

Descomposición orientada a objetos

La descomposición significa dividir un gran sistema complejo en una jerarquía de componentes más pequeños con menor complejidad, según los principios de divide y vencerás. Cada componente principal del sistema se denomina subsistema. La descomposición orientada a objetos identifica los objetos autónomos individuales de un sistema y la comunicación entre estos objetos.

Las ventajas de la descomposición son –

• Los componentes individuales son de menor complejidad, y por lo tanto más comprensibles y manejables.

• Permite la división de la mano de obra que tiene habilidades especializadas.

• Permite sustituir o modificar subsistemas sin afectar a otros.

Identificación de la concurrencia

La concurrencia permite que más de un objeto reciba eventos al mismo tiempo y que más de una actividad se ejecute simultáneamente. La concurrencia se identifica y representa en el modelo dinámico.

Para permitir la concurrencia, a cada elemento concurrente se le asigna un hilo de control independiente. Si la concurrencia es a nivel de objeto, entonces a dos objetos concurrentes se les asignan dos hilos de control diferentes. Si dos operaciones de un solo objeto son de naturaleza concurrente, entonces ese objeto se divide entre diferentes hilos.

La concurrencia está asociada con los problemas de integridad de los datos, el bloqueo y la inanición. Por lo tanto, es necesario hacer una estrategia clara siempre que se requiera la concurrencia. Además, la concurrencia requiere ser identificada en la propia etapa de diseño, y no puede dejarse para la etapa de implementación.

Identificación de patrones

Al diseñar aplicaciones, se adoptan algunas soluciones comúnmente aceptadas para algunas categorías de problemas. Estos son los patrones de diseño. Un patrón puede definirse como un conjunto documentado de bloques de construcción que pueden utilizarse en ciertos tipos de problemas de desarrollo de aplicaciones.

Algunos patrones de diseño comúnmente utilizados son –

• Patrón de fachada
• Patrón de separación modelo vista
• Patrón de observador
• Patrón controlador vista modelo
• Patrón suscriptor
• Patrón proxy

Control de eventos

Durante el diseño del sistema, es necesario identificar los eventos que pueden ocurrir en los objetos del sistema y tratarlos adecuadamente.

Un evento es una especificación de una ocurrencia significativa que tiene una ubicación en el tiempo y el espacio.

Hay cuatro tipos de eventos que pueden ser modelados, a saber –

• Evento de señal – Un objeto con nombre lanzado por un objeto y capturado por otro objeto.

• Evento de llamada – Un evento sincrónico que representa el envío de una operación.

• Evento de tiempo – Un evento que representa el paso del tiempo.

• Evento de cambio – Un evento que representa el cambio de estado.

Manejo de las condiciones límite

La fase de diseño del sistema necesita abordar la inicialización y la terminación del sistema en su conjunto así como de cada subsistema. Los diferentes aspectos que se documentan son los siguientes –

• La puesta en marcha del sistema, es decir, la transición del sistema del estado no inicializado al estado estable.

• La terminación del sistema, es decir, el cierre de todos los hilos en ejecución, la limpieza de los recursos y los mensajes a enviar.

• La configuración inicial del sistema y la reconfiguración del sistema cuando sea necesario.

• La previsión de fallos o la terminación no deseada del sistema.

Las condiciones límite se modelan mediante casos de uso límite.

Diseño de objetos

Una vez desarrollada la jerarquía de subsistemas, se identifican los objetos del sistema y se diseñan sus detalles. Aquí, el diseñador detalla la estrategia elegida durante el diseño del sistema. El énfasis pasa de los conceptos del dominio de la aplicación a los conceptos informáticos. Los objetos identificados durante el análisis se graban para su implementación con el objetivo de minimizar el tiempo de ejecución, el consumo de memoria y el coste global.

El diseño de objetos incluye las siguientes fases –

• Identificación de objetos
• Representación de objetos, es decir, construcción de los modelos de diseño
• Clasificación de las operaciones
• Diseño de los algoritmos
• Diseño de las relaciones
• Implementación del control de las interacciones externas
• Empaquetar las clases y asociaciones en módulos

Identificación de los objetos

El primer paso del diseño de objetos es la identificación de los mismos. Los objetos identificados en las fases de análisis orientado a objetos se agrupan en clases y se refinan para que sean adecuados para la implementación real.

Las funciones de esta etapa son –

• Identificar y refinar las clases en cada subsistema o paquete

• Definir los enlaces y asociaciones entre las clases

• Diseñar las asociaciones jerárquicas entre las clases, es decir, la generalización/especialización y las herencias

• Diseñar las agregaciones

Representación de objetos

Una vez identificadas las clases, es necesario representarlas mediante técnicas de modelado de objetos. Esta etapa implica esencialmente la construcción de diagramas UML.

Hay dos tipos de modelos de diseño que necesitan ser producidos –

• Modelos estáticos – Para describir la estructura estática de un sistema utilizando diagramas de clases y diagramas de objetos.

• Modelos Dinámicos – Para describir la estructura dinámica de un sistema y mostrar la interacción entre las clases utilizando diagramas de interacción y diagramas de estado.

Clasificación de Operaciones

En este paso, se definen las operaciones a realizar sobre los objetos combinando los tres modelos desarrollados en la fase OOA, es decir, el modelo de objetos, el modelo dinámico y el modelo funcional. Una operación especifica lo que debe hacerse y no cómo debe hacerse.

Se realizan las siguientes tareas respecto a las operaciones –

• Se desarrolla el diagrama de transición de estados de cada objeto del sistema.

• Se definen las operaciones para los eventos recibidos por los objetos.

• Se identifican los casos en los que un evento desencadena otros eventos en el mismo o en diferentes objetos.

• Se identifican las suboperaciones dentro de las acciones.

• Las acciones principales se amplían a diagramas de flujo de datos.

Diseño de algoritmos

Las operaciones en los objetos se definen mediante algoritmos. Un algoritmo es un procedimiento por pasos que resuelve el problema establecido en una operación. Los algoritmos se centran en cómo se debe hacer.

Puede haber más de un algoritmo correspondiente a una operación determinada. Una vez identificados los algoritmos alternativos, se selecciona el algoritmo óptimo para el dominio del problema dado. Las métricas para elegir el algoritmo óptimo son –

• Complejidad computacional – La complejidad determina la eficiencia de un algoritmo en términos de tiempo de computación y requisitos de memoria.

• Flexibilidad – La flexibilidad determina si el algoritmo elegido puede implementarse adecuadamente, sin pérdida de idoneidad en varios entornos.

• Incomprensibilidad – Determina si el algoritmo elegido es fácil de entender e implementar.

Diseño de relaciones

La estrategia para implementar las relaciones tiene que ser calcada durante la fase de diseño del objeto. Las principales relaciones que se abordan comprenden las asociaciones, las agregaciones y las herencias.

El diseñador debe hacer lo siguiente con respecto a las asociaciones –

• Identificar si una asociación es unidireccional o bidireccional.

• Analizar la trayectoria de las asociaciones y actualizarlas si es necesario.

• Implementar las asociaciones como un objeto distinto, en caso de relaciones de muchos a muchos; o como un enlace a otro objeto en caso de relaciones de uno a uno o de uno a muchos.

Respecto a las herencias, el diseñador debería hacer lo siguiente –

• Ajustar las clases y sus asociaciones.

• Identificar las clases abstractas.

• Hacer provisiones para que los comportamientos sean compartidos cuando se necesiten.

Implementación de Control

El diseñador de objetos puede incorporar refinamientos en la estrategia del modelo de carta de estado. En el diseño del sistema, se realiza una estrategia básica para realizar el modelo dinámico. Durante el diseño del objeto, esta estrategia se embellece adecuadamente para una implementación apropiada.

Los enfoques para la implementación del modelo dinámico son –

• Representar el estado como una ubicación dentro de un programa – Este es el enfoque tradicional dirigido por procedimientos por el cual la ubicación del control define el estado del programa. Una máquina de estado finito puede ser implementada como un programa. Una transición forma una declaración de entrada, la ruta de control principal forma la secuencia de instrucciones, las ramas forman las condiciones, y las rutas hacia atrás forman los bucles o iteraciones.

• Motor de máquina de estados – Este enfoque representa directamente una máquina de estados a través de una clase de motor de máquina de estados. Esta clase ejecuta la máquina de estados a través de un conjunto de transiciones y acciones proporcionadas por la aplicación.

• Control como tareas concurrentes – En este enfoque, un objeto se implementa como una tarea en el lenguaje de programación o el sistema operativo. Aquí, un evento se implementa como una llamada entre tareas. Preserva la concurrencia inherente de los objetos reales.

Empaquetado de clases

En cualquier proyecto grande, es importante la partición meticulosa de una implementación en módulos o paquetes. Durante el diseño de objetos, las clases y los objetos se agrupan en paquetes para permitir que varios grupos trabajen de forma cooperativa en un proyecto.

Los diferentes aspectos del empaquetado son –

• Ocultar la información interna de la vista exterior – Permite que una clase sea vista como una «caja negra» y permite que la implementación de la clase sea cambiada sin requerir que ningún cliente de la clase modifique el código.

• Coherencia de los elementos – Un elemento, como una clase, una operación o un módulo, es coherente si está organizado en un plan consistente y todas sus partes están intrínsecamente relacionadas de manera que sirven a un objetivo común.

• Construcción de Módulos Físicos – Las siguientes pautas ayudan mientras se construyen módulos físicos –

  • Las clases en un módulo deben representar cosas o componentes similares en el mismo objeto compuesto.

  • Las clases estrechamente conectadas deben estar en el mismo módulo.

  • Las clases no conectadas o débilmente conectadas deben colocarse en módulos separados.

  • Los módulos deben tener una buena cohesión, es decir, alta cooperación entre sus componentes.

  • Un módulo debe tener un bajo acoplamiento con otros módulos, es decir, la interacción o interdependencia entre los módulos debe ser mínima.

Optimización del diseño

El modelo de análisis captura la información lógica sobre el sistema, mientras que el modelo de diseño añade detalles para soportar un acceso eficiente a la información. Antes de que se implemente un diseño, debe ser optimizado para que la implementación sea más eficiente. El objetivo de la optimización es minimizar el coste en términos de tiempo, espacio y otras métricas.

Sin embargo, la optimización del diseño no debe ser excesiva, ya que la facilidad de implementación, la mantenibilidad y la extensibilidad son también preocupaciones importantes. A menudo se observa que un diseño perfectamente optimizado es más eficiente pero menos legible y reutilizable. Así que el diseñador debe encontrar un equilibrio entre ambos.

Las diversas cosas que se pueden hacer para la optimización del diseño son –

• Añadir asociaciones redundantes
• Omitir asociaciones no utilizables
• Optimización de algoritmos
• Guardar atributos derivados para evitar el recálculo de expresiones complejas

Añadir asociaciones redundantes

Durante la optimización del diseño, se comprueba si la derivación de nuevas asociaciones puede reducir los costes de acceso. Aunque estas asociaciones redundantes no añaden ninguna información, pueden aumentar la eficiencia del modelo global.

Omisión de Asociaciones No Utilizables

La presencia de demasiadas asociaciones puede hacer que un sistema sea indescifrable y, por tanto, reducir la eficiencia global del sistema. Por ello, durante la optimización, se eliminan todas las asociaciones no utilizables.

Optimización de algoritmos

En los sistemas orientados a objetos, la optimización de la estructura de datos y de los algoritmos se realiza de forma colaborativa. Una vez que el diseño de la clase está en su lugar, las operaciones y los algoritmos deben ser optimizados.

La optimización de los algoritmos se obtiene mediante –

• Reorganización del orden de las tareas computacionales
• Inversión del orden de ejecución de los bucles respecto al establecido en el modelo funcional
• Eliminación de caminos muertos dentro del algoritmo

Guarda y almacenamiento de atributos derivados

Los atributos derivados son aquellos atributos cuyos valores se calculan en función de otros atributos (atributos base). Volver a calcular los valores de los atributos derivados cada vez que se necesitan es un procedimiento que requiere mucho tiempo. Para evitar esto, los valores pueden ser calculados y almacenados en sus formas computadas.

Sin embargo, esto puede plantear anomalías de actualización, es decir, un cambio en los valores de los atributos base sin el correspondiente cambio en los valores de los atributos derivados. Para evitar esto, se toman los siguientes pasos –

• Con cada actualización del valor del atributo base, el atributo derivado también se vuelve a calcular.

• Todos los atributos derivados se vuelven a calcular y se actualizan periódicamente en un grupo en lugar de después de cada actualización.

Documentación del diseño

La documentación es una parte esencial de cualquier proceso de desarrollo de software que registra el procedimiento de elaboración del mismo. Las decisiones de diseño necesitan ser documentadas para cualquier sistema de software no trivial para transmitir el diseño a otros.

Áreas de uso

Aunque es un producto secundario, una buena documentación es indispensable, particularmente en las siguientes áreas –

• En el diseño de software que está siendo desarrollado por un número de desarrolladores
• En las estrategias de desarrollo iterativo de software
• En el desarrollo de versiones posteriores de un proyecto de software
• Para la evaluación de un software
• Para encontrar las condiciones y áreas de prueba
• Para el mantenimiento del software.

Contenidos

Una documentación beneficiosa debería incluir esencialmente los siguientes contenidos –

• Arquitectura del sistema de alto nivel – Diagramas de procesos y diagramas de módulos

• Abstracciones y mecanismos clave – Diagramas de clases y diagramas de objetos.

• Escenarios que ilustran el comportamiento de los aspectos principales – Diagramas de comportamiento

Características

Las características de una buena documentación son –

• Concisa y, al mismo tiempo, sin ambigüedades, coherente y completa

• Correspondiente a las especificaciones de los requisitos del sistema

• Bien estructurada

• Diagramática en lugar de descriptiva

.