Diseño Orientado a Objetos Ingeniería de software Unidad II Ingeniería de Software Orientado a Objetos Semana 8 Tema Diseño Orientado a Objetos

Objetivos Generales: Comprender correcta y eficientemente los conceptos y principios del espectro de técnicas de Ingeniería de Software que puedan ser aplicadas en proyectos de software. Desarrollar una cultura de ingeniería de software.

Objetivos Específicos: Aplicar correctamente los conceptos y principios relacionados a la Ingeniería de Software en la resolución de casos prácticos para la gestión de proyectos de software de calidad. Utilizar herramientas para el modelado y gestión de proyectos de software. Utilizar metodologías agiles en el desarrollo de software.

Objetivos Instruccionales: Comprender los conceptos relacionados al diseño orientado a objetos Establecer la interrelación entre los objetos en el proceso orientado a objetos

Contenidos Diseño para sistemas OO Proceso de diseño del sistema Proceso de diseño de objetos Patrones de diseño. Programación OO

Capas de la pirámide del diseño OO Diseño para Sistemas OO Capas de la pirámide del diseño OO contiene los datos estructurados en detalle y el detalle algorítmico para los atributos de cada objeto y funcionamientos Diseño de responsabilidades establece las interfaces internas y externas para el sistema, incluso los detalles de comunicación entre los colaboradores del objeto Diseño de mensajes contiene la jerarquía de la clase incluso las representaciones de cada objeto Diseño de clases y objetos contiene las representaciones de cada uno de los subsistemas y la infraestructura necesaria que permiten al software lograr los requisitos del cliente Diseño de subsistemas

Relación entre el análisis y diseño OO Diseño para Sistemas OO Relación entre el análisis y diseño OO Colaboraciones operaciones Modelo de objeto-relaciones Casos de uso Atributos, Modelo de tarjetas CRC Diseño de responsabilidades Modelo de Comportamiento de objetos Diseño de mensajes Diseño de clases y objetos Modelo de análisis Diseño de subsistemas Modelo de diseño Transformación de un modelo de análisis OO a un modelo de diseño OO

Enfoque Convencional vs. OO Diseño para Sistemas OO Enfoque Convencional vs. OO Fichman y Kemerev sugieren diez componentes de diseño modelado para comparar métodos convencionales y orientados a objetos. Representación de la jerarquía de módulos Especificación de las definiciones de datos Especificación de la lógica procedimental Indicación de secuencias de proceso final-a-final (end-to-end) Representación de estados y transición de los objetos Definición de clases y jerarquías Asignación de operaciones a las clases Definición detallada de operaciones Especificación de conexiones de mensajes Identificación de servicios exclusivos

UNIDADES LINGUISTICAS INTERFACES EXPLICITAS Diseño para Sistemas OO Aspectos del diseño Criterios para juzgar la capacidad de métodos de diseño para conseguir modularidad. Un método de diseño facilita... Principios básicos de diseño, que pueden ser deducidos para arquitecturas modulares DESCOMPONIBILIDAD Descomposición de un problema grande en problemas pequeños UNIDADES LINGUISTICAS MODULARES Los componentes del programa una vez diseñados y construidos, pueden ser reutilizados COMPONIBILIDAD POCAS INTERFACES Los componentes de un programa puedan ser entendidos, sin hacer referencia a otro modulo COMPRENSIBILIDAD PEQUEÑAS INTERFACES Pequeños cambios en un programa se revelen haciendo los cambios pertinentes en uno o muy pocos módulos CONTINUIDAD INTERFACES EXPLICITAS PROTECCCION Reduce la propagación de efectos colaterales, si ocurre un error en un modulo dado. OCULTAMIENTO DE LA INFORMACION

Diseño para Sistemas OO Panorama del DOO Diseño para Sistemas OO El método de Booch Abarca un “microproceso de desarrollo” y un “macroproceso de desarrollo”. Microproceso Define un conjunto de reglas que regulan el uso de operaciones y atributos y las políticas del dominio especifico para la administración de la memoria, manejo de errores,etc. Desarrolla situaciones que describen la semántica de las reglas y políticas Crea un prototipo para cada política Instrumenta y refina el prototipo Revisa cada política para así transmitir su visión arquitectónica Macroproceso Engloba una actividad de planificación arquitectónica, que: Agrupa objetos similares en particiones arquitectónicas separadas, Agrupa capas de objetos por nivel de abstracción, Identifica situaciones relevantes, Crea un prototipo de diseño, Valida el prototipo

Diseño para Sistemas OO Panorama del DOO Diseño para Sistemas OO El método de Rumbaugh Engloba una actividad de diseño que alienta al diseño a ser conducido a dos diferentes niveles de abstracción. Diseño de objeto Enfatiza el esquema detallado de un objeto individual. Se seleccionan las operaciones del modelo de análisis y los algoritmos se definen para cada operación. Se representan las estructuras de datos apropiadas para atributos y algoritmos. Las clases y atributos de clase son diseñados de manera que optimicen el acceso a los datos. Se crea un modelo de mensajería. Diseño de sistema Se centra en el esquema de los componentes que se necesitan para construir un sistema o producto completo. El modelo de análisis se divide en subsistemas Se define una estrategia para implementar la administración de datos Se identifican los recursos y mecanismos de control para accesarlos

Diseño para Sistemas OO Panorama del DOO Diseño para Sistemas OO El método de Jacobson El modelo idealizado de análisis se adapta para acoplarse al ambiente del mundo real. Después los objetos de diseño primarios, llamados “bloques”, son creados y catalogados como bloques de interfaz, bloque de entidades y bloques de control. La comunicación entre bloques durante la ejecución se define y los bloques se organizan en subsistemas.

Etapas genéricas del DOO Diseño para Sistemas OO Describir cada subsistema y asignar a procesadores y tareas. Elegir una estrategia para implementar la administración de datos, soporte de interfaz y administración de tareas. Diseñar un mecanismo de control, para el sistema apropiado. Diseñar objetos creando una representación procedural para cada operación, y estructuras de datos para los atributos de clase. Diseñar mensajes, usando la colaboración entre objetos y relaciones. Crear el modelo de mensajería. Revisar el modelo de diseño y renovarlo cada vez que se requiera.

Enfoque unificado para el DOO Diseño para Sistemas OO DISEÑO DE SISTEMA DISEÑO DE OBJETO Se centra en la arquitectura del software y definición de subsistemas. Describe objetos, hasta un nivel en el cual puedan ser implementados en un lenguaje de programación. Se extiende para considerar el diseño de interfaces, administración de datos con el sistema que se va a construir y administración de tareas para los subsistemas que se han especificado. Se centra en la descripción de objetos y sus interacciones con los otros. Una especificación detallada de las estructuras de datos de los atributos y diseño procedural de todas las operaciones, se crea durante el diseño de objetos. La visibilidad para los atributos de la clase se definen, y las interfaces entre objetos se elaboran para definir los detalles de un modelo completo de mensajes

Flujo de proceso para DOO Diseño para Sistemas OO Flujo de proceso para DOO Análisis orientado a objetos Diseño del sistema Diseño de la gestión de tareas Diseño de objetos Diseño de la gestión de datos Diseño de la interfaz humana

Fases del proceso de diseño de sistema Proceso de diseño del sistema Fases del proceso de diseño de sistema Comunicación entre subsistemas Componente de gestión de recursos Componente de administración de datos Componente de interfaz de usuario Componente de administración de tareas Asignación de concurrencia y subsistemas Particionar el modelo de análisis

Fases del proceso de diseño de sistema Proceso de diseño del sistema Fases del proceso de diseño de sistema Particionar el modelo de análisis Criterios a tener en cuenta al momento de definir y diseñar los subsistemas El subsistema debe tener una interfaz bien definida, a través de la cual se reduzcan todas las comunicaciones con el resto del sistema. Con la excepción de un numero pequeño de “clases de comunicaciones”, las clases incluidas dentro del subsistema deben colaborar solo con otras áreas dentro del subsistema. El número de subsistemas debe ser bajo Un subsistema puede ser particionado internamente para ayudar a reducir la complejidad. Enfoque de diseño para estratificación por capas Establecer los criterios de estratificación por capas. Determinar el número de capas. Nombrar las capas y asignar susbsistemas a las capas. Diseñar interfaces para cada capa Refinar los subsistemas, para establecer la estructura de clases de cada capa Definir el modelo de mensajería para la comunicación entre capas. Revisar el diseño de capas, para asegurar que el acoplamiento sea mínimo. Iterar para refinar el diseño de capas.

Proceso de diseño de sistema Proceso de diseño del sistema Proceso de diseño de sistema Asignación de concurrencia y subsistemas El sistema dinámico del modelo objeto-comportamiento provee una indicación de concurrencia entre clases o subsistemas. Si las clases deben actuar en sucesos asincronicamemte y al mismo tiempo, se verán como concurrentes. Cuando los subsistemas son concurrentes, existen dos tipos de alojamiento: Alojar cada subsistema en procesadores independientes Alojar los subsistemas en el mismo procesador y proporcionar soporte de concurrencia, sobre las características del sistema operativo.

Proceso de diseño de sistema Proceso de diseño del sistema Proceso de diseño de sistema Componente de administración de tareas Estrategias para el diseño de objetos que manipulan tareas concurrentes. Se determinan las características de la tarea Se define un coordinador de tarea y objetos asociados. Se integra el coordinador y otras tareas Plantilla básica de una tarea 1. Nombre de la tarea 2. Descripción 3. Prioridad 4. Servicios 5. Coordinado por... 6. Comunicados por ...

Proceso de diseño de sistema Proceso de diseño del sistema Proceso de diseño de sistema Componente de interfaz de usuario Las mayoría de las clases necesarias para crear una interfaz moderada ya existen y están disponibles, para el diseñador. Una vez que el actor y su situación de uso se definen se identifica una jerarquía de comando. La jerarquía de ordenes define la mayoría de las categorías del menú de sistema (barra de menús o la paleta de herramientas), y todas las subfunciones, que estarán disponibles en el contexto de una categoría importante de menú de sistema (ventanas de menú)

Proceso de diseño de sistema Proceso de diseño del sistema Proceso de diseño de sistema Componente de administración de datos La administración o gestión de datos engloba dos áreas distintas de interés: La administración de datos críticos para la propia aplicación La creación de infraestructura para el almacenamiento y recuperación de objetos. En general, la administración de datos se diseña en forma de capas. La idea es aislar los requisitos de bajo nivel que manipulan las estructuras de datos, de los requisitos de alto nivel para manejar los atributos del sistema.

Proceso de diseño de sistema Proceso de diseño del sistema Proceso de diseño de sistema Componente de gestión de recursos Están disponibles una variedad de recursos diferentes para un sistema o producto OO; y, muchas veces, los subsistemas compiten por estos recursos al mismo tiempo. Los recursos globales del sistema pueden ser entidades externas (unidad de disco, procesador) o abstracciones (base de datos,un objeto). Sin importar la naturaleza del recurso, el ingeniero de software debe diseñar un mecanismo de control para ello. Rumbaugh sugiere que cada recurso deba ser poseído por un “objeto guardián”, quien controlara el acceso al recurso.

Proceso de diseño de sistema Proceso de diseño del sistema Comunicación entre subsistemas Una vez que cada subsistema ha sido especificado, es necesario definir las colaboraciones que existen entre subsistemas. Listar cada petición que puede ser realizada por los colaboradores del subsistema. Para cada contrato, anotar las especificaciones (heredadas y privadas) que se requieren para implementar las responsabilidades que implica el contrato. Considerar un contrato a la vez, que incluya: Tipo de contrato (cliente – servidor , Peer to Peer) Colaboradores (nombres de los subsistemas que son parte del contrato) Clase (nombres de clases que proporcionan servicios denotados por el contrato) Operaciones (nombre de operaciones que implementan los servicios) Formato del mensaje (requerido para implementar la interacción entre colaboradores)

Descripción de objetos Diseño de algoritmos y estructura de Proceso de diseño de objetos Descripción de objetos Diseño de algoritmos y estructura de datos

Descripción de objetos Proceso de diseño de objetos Descripción de objetos Una descripción del diseño de un objeto (instancia de clase) puede tomar una o dos formas: Una descripción de protocolo que establece a interfaz de un objeto, definiendo cada mensaje que el objeto puede recibir y las operaciones que lleva a cabo cuando recibe un mensaje. Una descripción de implementación que muestra detalles de implementación para cada operación implicada por un mensaje pasado a un objeto. La descripción del protocolo no es nada mas que un conjunto de mensajes y un comentario correspondiente para cada mensaje.

Diseño de algoritmos y estructura de datos Proceso de diseño de objetos Diseño de algoritmos y estructura de datos Una variedad de representaciones contenidas en el modelo de análisis y el diseño del sistema, proveen una especificación para todas las operaciones y atributos. Se crea un algoritmo para implementar la especificación para cada operación. En muchas ocasiones el algoritmo es una simple secuencia computacional o procedural, que puede ser implementada como un modulo de software. Las estructuras de datos se diseñan al mismo tiempo que los algoritmos. Ya que las operaciones manipulan los atributos de una clase, el diseño de estructuras de datos, que reflejan mejor los atributos, tendrán un fuerte sentido en el diseño algorítmico de las operaciones correspondientes.

Patrones de diseño

Programación orientado a objetos Modelado de clases Cliente Nombre Dirección Estado ObtenerCuentas():ConjuntoDeCuentas EstablecerNombre(cadena Nombre) ObtenerNombre():Cadena No se muestran todos los atributos y operaciones

Programación orientado a objetos Generalización No se muestran todos los atributos y operaciones Cuenta CuentaCorriente Deposito

Agregación Programación orientado a objetos Componente El diamante vació representa agregación Producto Manufacturado Componente

Generalización y Agregación Programación orientado a objetos Generalización y Agregación Producto Manufacturado Componente ComponenteA ComponenteB ComponenteC

Programación orientado a objetos Composición Cliente ColecionCuentas

Programación orientado a objetos Asociación Administrador Administrador Administrador 1 1 Administra 1..* 1..* Empleado Empleado Empleado Relación simple Multiplicidad Documentada

Programación orientado a objetos Asociación Universidad Hospedar 1 estudiante miembro 1..* Estudiante Documentando roles

Programación orientado a objetos Casos de uso Emitir informe de estado Administrador Seleccionar plantilla Terminar proyecto Iniciar proyecto

Casos de uso utilizando otro caso de uso Programación orientado a objetos Casos de uso utilizando otro caso de uso “uses” Consultar producto “uses” Administrador del almacén Consultar nivel de stock Validar producto “uses” Consultar detalles de orden

Colaboraciones Programación orientado a objetos Administrador: Empleado Informe ventas Transacción ventas ViejoCliente: ClienteBanco Actualizar informe Crear transacción Cambiar detalles Un diagrama de secuencias sencillo

Colaboraciones Programación orientado a objetos Cuenta Informe balance ViejoCliente: ClienteBanco Consultar cuenta Comprobar CuentaValida GenerarInformeBalance Otro ejemplo de diagrama de secuencias

Programación orientado a objetos Diagrama de estados Cerrar cuenta Cuenta activa Transacción Crear cuenta Cuenta vacía Transacción

Apreciación Global El DOO se divide en dos grandes actividades: Diseño del sistema Diseño de objetos. El diseño de sistema crea la arquitectura del producto definiendo una serie de “capas”, que cumplen funciones especificas del sistema e identifica las clases que son encapsuladas por los subsistemas que residen en cada capa. Además incorpora la especificación de tres componentes: La interfaz de usuario La gestión de datos Mecanismos de administración de tareas El diseño de objetos se centra en los detalles internos de cada clase, definición de atributos, operaciones y detalles de los mensajes.

Diseño Orientado a Objetos Ingeniería de software Unidad II Ingeniería de Software Orientado a Objetos Semana 8 Tema Diseño Orientado a Objetos