CAPITULO 21DISEÑO ORIENTADO A OBJETOS

El DOO constituye un tipo de diseño que logra un cierto número de diferentes niveles de modularidad. Las componentes principales del sistema están organizados en “módulos” denominados subsistemas. Los datos y las operaciones que manipulan los datos están encapsulados en objetos. El DOO debe describir la organización de datos específicos, de atributos y los detalles procedimentales de las operaciones individuales.La naturaleza única del diseño orientado a objetos descansa en su capacidad de apoyarse en cuatro importantes conceptos de diseño del software: abstracción, ocultación de la información, independencia funcional y modularidad.

21.1 DISEÑO DE SISTEMAS ORIENTADOS A OBJETOS

Las cuatro capas del diseño OO son:

La capa del subsistema: contiene una representación de cada uno de los subsistemas que le permiten al software conseguir que los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta.La capa de clases y objetos: Contiene las jerarquías de clases que permite crear el sistema usando generalizaciones y especializaciones mejor definidas incrementalmente. Contiene representaciones de diseño para cada objeto.La capa de mensajes: contiene los detalles que le permiten a cada objeto comunicarse con sus colaboradores. Esta capa establece las interfaces externas e internas para el sistema. La capa de responsabilidades: contiene las estructuras de datos y el diseño algorítmico para todos los atributos y operaciones de cada objeto.

La capa base se centra en el diseño de los objetos del dominio; aportando soporte a las actividades de la interfaz hombre-computadora, gestión de tareas y datos. Los objetos del dominio también pueden usarse para desarrollar el diseño de la aplicación.

21.1.1. El enfoque convencional y el enfoque OO

Como en el diseño del software convencional, el DOO aplica diseño de datos (cuando se representan atributos), diseño de interfaces( cuando se desarrolla un modelo de intercambio de mensajes), y diseño procedimental ( en el diseño de operaciones). El diseño arquitectónico es diferente. A diferencia del diseño arquitectónico derivado a partir del uso de métodos de ingeniería del software convencionales, un diseño OO no exhibe una estructura de control jerárquica. La arquitectura de diseño OO tiene más que ver con las colaboraciones entre objetos que con el flujo de control.10 componentes de modelado para el diseño que pueden usarse para comparar diversos métodos de diseño convencionales con otros orientados a objetos:1. Representación de jerarquías de módulos2. Especificación de definiciones de datos.3. Especificación de la lógica procedimental4. Indicación de secuencia de procesoso fin-a fin5. Representaciones de estados de objetos y transiciones6. Definición de clases y jerarquías7. Asignación de operaciones a clases8. Definición detallada de las operaciones9. Especificación de conexiones de mensajes10. Identificación de servicios exclusivos.

Las dimensiones de modelado de la 5 a la 10 no se soportan usando diseño estructurado.

21.1.2 Asuntos del Diseño

Cinco criterios para juzgar la capacidad que posee un método de diseño en lograr la modularidad y los relaciona con el diseño orientadoa a objetos:

- Descomponibilidad: la facilidad con la cual un método de diseño ayuda al diseñador para descomponer un gran problema en subproblemas más sencillos de resolver.

- Componibilidad: el grado con el cual un método de diseño asegura que los componentes de un programa, una vez diseñados y construídos, pueden reusarse para crear otros sistemas.

- Comprensibilidad: facilidad de comprensión de un componente de programa sin referencia a otra información o módulos.

- Continuidad: la facilidad de hacer pequeños cambios en un programa y hacer que estos se manifiesten por sí mismo en cambios correspondientes solamente en uno o en pocos módulos más.

- Protección: característica arquitectónica que reducirá la propagación de efectos colaterales si ocurre un error en un módulo dado.

Cinco principios de diseño básicos que pueden derivarse para arquitecturas modulares:1. Unidades modulares linguísticas2. Pocas interfaces3. Pequeñas interfaces (acoplamientos débiles)4. Interfaces explícitas5. Ocultación de la información

Los módulos están definidos como unidades modulares linguísticas cuando se corresponden con unidades sintácticas en el lenguaje usado. Esto es, el lenguaje de programación a usar debe ser capaz de soportar directamente la modularidad definida.

Para lograr un bajo acoplamiento, debe minimizarse el número de interfaces entre módulos y la cantidad de información que se mueve a través de una interfaz. Cada vez que se comuniquen los módulos, deben realizarlo de una manera obvia y directa.

Logramos el principio de ocultar información cuando la información sobre un módulo está oculta al acceso exterior, a menos que la información se defina explícitamente como “información pública”

21.1.3. La Visión del DOO

Métodos DOOEl método de BOOCH: abarca un proceso de micro-desarrollo y un proceso de macro desarrollo. El nivel de micro-desarrollo define un conjunto de tareas de diseño que se raeplican en cada etapa del proceso de macro-desarrollo. Se mantiene un enfoque evolutivo.Descripción del proceso de micro-desarrollo:- Planificación arquitectónica- Diseño táctico- Planificación de la realización

El método de Coad y Yourdon: el enfoque de diseño se dirige no solamente a la aplicación, sino también a la infraestructura para la aplicación. Descripción del proceso:

- Componente del dominio del problema

- Componente de interacción humana- Componente para la gestión de tareas- La componente para la gestión de datos

El método de Jacobson: el modelo de diseño hace hincapié en el seguimiento al modelo de análisis ISOO. Presentación del proceso:- Considerar adaptaciones para hacer que el modelo de análisis ideal cumpla con el entorno del

mundo real.- Crear bloques como objetos de diseño primario- Crear un diagrama de interacción que muestre cómo se pasan los estímulos entre bloques- Organizar los bloques en subsistemas- Revisar el trabajo de diseño. El método de Rumbaugh: Técnica de modelado de Objetos (TMO). Abarca una actividad de diseño que encara el diseño de manera que este se conduzca a dos niveles diferentes de abstracción. El diseño del sistema se centra en la distribución de los componentes necesarios para construir un producto o sistema completo. El diseño de objetos enfatiza la distribución detallada de un objeto individual.Proceso:- realizar un diseño del sistema- conducir un diseño de objeto- implementar mecanismo de control definidos en el diseño del sistema- ajustar la estructura de clase a una herencia fuerte- diseñar el intercambio de mensajes para implementar relaciones entre objetos- empaquetar las clases y asociaciones en módulos.

El método de Wirfs-Brock: define una secuencia de técnicas en el cual el análisis conduce ineludiblemente al diseño. Tareas:- construir protocolos para cada clase- crear especificaciones de diseño para cada clase- crear una especificación de diseño para cada subsistema

Para realizar un diseño OO, el ingeniero del soft debe seguir las siguientes etapas genéricas:

- Describir cada uno de los subsistemas de manera que sean implementables.- Diseño de objetos- Diseño de mensajes- Revisión del modelo de diseño e iterar siempre que sea necesario.

Las etapas de diseño examinadas en esta sección son iterativos. Pueden ejecutarse incrementalmente, de manera conjunta con actividades de AOO, hasta producir un diseño completo.

21.2. LOS COMPONENTES GENERICOS DEL MODELO DE DISEÑO OO

El análisis orientado a objetos (AOO) es una actividad de clasificación. Se determina las clases de objetos que serán aplicables al desarrollarse una solución. Se determina también las relaciones y el comportamiento del objeto.El diseño orientado a objetos (DOO) le posibilita al ing. del software la posibilidad de indicar los objetos que se derivan de cada clase y cómo estos objetos se interrelacionan unos con otros.El DOO ilustra cómo se desarrollan las relaciones entre objetos, cómo se debe implementar el comportamiento y cómo implementar la comunicación entre objetos.

Durante el diseño de los subsistemas, es necesario para el ingeniero del software definir cuatro importantes componentes del diseño:- Dominio del problema. Los subsistemas responsables de la implementación de los requisitos

del cliente directamente. - Interacción humana: los subsistemas, que implementan la interfaz de usuario.- Gestión de tareas: los subsistemas responsables del control y coordinación de tareas

concurrentes que pueden empaquetarse dentro de uno o varios subsistemas - Gestión de datos: el subsistema que es responsable del almacenamiento y recuperación de

objetos.

Cada uno de estos componentes genéricos pueden modelarse a través de una serie de clases así como las relaciones y comportamientos que constituyen requisitos. Los componentes de diseño se implementan definiendo el protocolo que describe formalmente el modelo de mensajes para cada uno de los componentes.Una vez que se ha definido un subsistema y comienza el diseño de cada uno de los componentes mencionados anteriormente, se traslada el énfasis al diseño de objetos. A este nivel los elementos del modelo CRC se convierten a una realización del diseño.

21.3. EL PROCESO DE DISEÑO DEL SISTEMA

Etapas del diseño:- Dividir el modelo de análisis en subsistemas.- Identificar la concurrencia dictada por el problema- Asignar subsistemas a procesadores y tareas- Elegir una estrategia básica para la implementación de la gestión de datos.- Identificar los recursos globales y los mecanismos de control necesarios para acceder a ellos- Diseñar un mecanismo de control apropiado para el sistema- Considerar como manipular las condiciones límite- Revisar y considerar los intercambios.

21.3.1 Partición del modelo de análisis

En el diseño OO se divide el modelo de análisis para definir colecciones cohesivas de clases, relaciones y comportamientos. Estos elementos se empaquetan como un subsistema (particiones del sistema). Un subsistema puede identificarse por los servicios que realiza. Servicio: colección de operaciones que realizan una función específica.

21.3.2 Concurrencia y asignación de subsistemas

Cuando los subsistemas son concurrentes, existen dos opciones de asignación:

- asignar cada subsistema a un procesador independiente- asignar los subsistemas al mismo procesador y ofrecer soporte de concurrencia a través de las

capacidades del sistema operativo.

Las tareas concurrentes se definen a través el examén del diagrama de estados para cada objeto. Si el flujo de eventos y transiciones indica que sólo existe un único objeto activo en un momento, se establece un hilo de control. El hilo de control continúa activo aún cuando un objeto envía un mensaje a otro, durante tanto tiempo como el primer objeto espera por una respuesta. Sin embargo, el primer objeto continúa el procesamiento después de enviar el mensajes hilo de control se divide.Las tareas en un sistema OO se diseñan aislando hilos de control.

21.3.3 El componente para la gestión de tareas

Estrategia para el diseño de los objetos que manejan tareas concurrentes:- Se determinan las características de la tarea- Se definen una tarea coordinadora y los objetos asociados- El coordinador y las tareas se integran

21.3.4. El componente para la gestión de datos

La gestión de datos abarca dos áreas distintas:1. La gestión de datos críticos para la propia aplicación2. La creación de una infraestructura para el almacenamiento y recuperación de objetos.En general la gestión de datos se diseña por capas. La idea es aislar los requisitos de bajo nivel para la gestión de datos de los de alto nivel para la gestión de los atributos del sistema.

El diseño de la componente para la gestión de datos incluye el diseño de los atributos y operaciones necesarias para la gestión de los datos. los atributos relevantes se añaden a cada objeto en el dominio del problema y brindan información que responde a la pregunta: ¿ como me almaceno?. Yourdon sugiere la creación de una clase servidor de objetos con servicios de a) informarle a cada objeto que se almacene y b) recuperar objetos almacenados para ser usados por otros componentes del diseño.

21.3.5 El componente para la gestión de recursos

Existe una variedad de recursos diferentes disponibles para un sistema o producto OO, y en muchas instancias, los subsistemas compiten por estos recursos al mismo tiempo. Los recursos globales del sistema pueden ser entidades externas o abstracciones. Se debe diseñar mecanismos de control sobre los recursos. Rumbaugh sugiere que cada recurso debería tener un objeto guardian, que es el portero del recurso, controlando los accesos a él y moderando las soluciones en conflicto sobre él.

21.3.6 El componente de interfaz hombre-máquina

21.3.7 Comunicación entre subsistemas.

Una vez que se ha definido cada subsistema, es necesario definir las colaboraciones que existen entre ellos. La comunicación pude ocurrir al establecer un enlace cliente/servidor o punto apunto. Debemos especificar el contrato que existe entre los subsistemas. Un contrato brinda indicaciones acerca de las maneras en que un subsistema puede interactuar con otro.

21.4. EL PROCESO DE DISEÑO DE OBJETOS

En el contexto del DOO debemos desarrollar un diseño detallado de los atributos y operaciones que incluyen cada clase, y una especificación completa de los mensajes que conectan la clase con sus colaboradores.

21.4.1. Descripciones de objeto

Una descripción de un objeto (una instancia de una clase o subclase) puede tomar una de estas dos formas:1. Descripción del protocolo: establece la interfaz de un objeto definiendo cada mensaje que el

objeto puede recibir y la correspondiente operación que el mismo ejecuta al recibir el mensaje.

2. Descripción de la implementación: incluye información acerca de la parte privada del objeto, esto es, detalles internos acerca de las estructuras de datos que describen los atributos del objeto y detalles procedimentales que describen operaciones.Para un sistema de muchos mensajes, es posible a menudo crear categorías de mensajes.

21.4.2. Diseño de algoritmos y estructuras de datos.

Se crea un algoritmo para implementar la especificación de cada operación.Las estructuras de datos se diseñan concurrentemente con los algoritmos. Debido a que las operaciones manipulan invariablemente los atributos de una clase, el diseño de las estructura de datos que mejor reflejan los atributos tendrá una fuerte influencia sobre el diseño algorítmico de las operaciones correspondientes.Tipos de operaciones:1. Operaciones que manipulan datos 2. Operaciones que realizan calculos3. Operaciones de monitorizan un objeto debido a la ocurrencia de un evento controlador.

Tres etapas principales para la optimización:

- Revisar el modelo objeto-relación para asegurarse que el diseño implementado lleva a una utilización eficiente de los recursos y a una facilidad de implementación. Añada redundancia donde sea necesario.

- Revisar las estructuras de datos atributos y las operaciones algorítmicas correspondientes para aumentar el rendimiento.

- Crear nuevos atributos para preservar información derivada, evitando para esto repetición de computaciones previas.

21.4.3. Componentes de programas e interfaces

Un aspecto importantes de la calidad del diseño del software es la modularidad; esto es, la especificación de componentes del programa (módulos) que se combinan para formar un programa completo. El enfoque orientado a objetos define al objeto como una componente del programa la cual está auto-enlazada con otras componentes. Pero definir objetos y operaciones no es suficiente. Durante el diseño, debemos identificar las interfaces que existen entre objetos y la estructura general de los objetos.Aunque una componente de programa es una abstracción del diseño, se deberá representar en el contexto del lenguaje de programación con el cual se debe implementar el diseño.

21.5. PATRONES DE DISEÑO

A lo largo del proceso de DOO, el ingeniero del software buscará cada oportunidad de reutilizar patrones de diseño existentes y crear nuevos si no se puede aplicar la reusabilidad.

21.5.1. Descripción de un patrón de diseño

Pueden describirse a través de la especificación de cuatro piezas de información:- El nombre del patrón- El problema al cual se aplica generalmente el patrón- Las características del patrón de diseño- Las consecuencias de la aplicación del patrón de diseño.

21.5.2 Uso de patrones en el diseño

Los patrones de diseño pueden usarse aplicando mecanismos diferentes: herencia y composición.La composición de objetos debe ser favorecida por encima de la herencia cuando existen ambas opciones. Antes de crear grandes e inmanejables jerarquías de clases (la consecuencia del sobreuso de la herencia), la composición favorece pequeñas jerarquías de clases y objetos que permanecen centrados en un objetivo. La composición usa patrones de diseño existentes de forma inalterada.