Diseño Orientado a Objetos

Presentación del tema: "Diseño Orientado a Objetos"— Transcripción de la presentación:

1 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

2 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.

3 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.

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 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.

13 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.

14 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

15 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

16 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

17 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.

18 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.

19 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 ...

20 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ú)

21 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.

22 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.

23 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)

24 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

25 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.

26 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.

27 Patrones de diseño

28 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

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

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

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

32 Programación orientado a objetos
Composición Cliente ColecionCuentas

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

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

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

36 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

37 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

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

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

40 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.

41 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