©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Diseño orientado a objetos.

Presentación del tema: "©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Diseño orientado a objetos."— Transcripción de la presentación:

1 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Diseño orientado a objetos

2 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 2 Objetivos l Explicar cómo un diseño de software puede ser representado como un conjunto de objetos que interactúan para gestionar su propio estado y las operaciones l Describir las actividades en el proceso de diseño orientado a objetos l Introducir varios modelos que se pueden utilizar para describir un diseño orientado a objetos l Mostrar cómo el UML puede utilizarse para representar a estos modelos

3 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 3 Tópicos expuestos l Objetos y clases de objetos l Proceso de diseño orientado a objetos l Evolución del diseño

4 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 4 Desarrollo orientado a objetos l Análisis orientado a objetos, el diseño y la programación están relacionadas pero son distintas. l OOA se refiere a la elaboración de un modelo de objetos de la solicitud de dominio. l OOD se refiere al desarrollo de un modelo de sistema orientado a objetos para aplicar los requisitos. l OOP se refiere a la realización de un OOD utilizando un lenguaje de programación como Java o C + +.

5 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 5 Características de OOD l Los objetos son abstracciones del mundo real o entidades del sistema y se gestionan ellos mismos. l Objetos son independientes y encapsulan el estado y la representación de información. l Funcionalidad del sistema se expresa en términos de servicios entre objetos. l Areas de datos compartidos se eliminan. l Los objetos pueden ser distribuidos y pueden ejecutarse secuencialmente o en paralelo.

6 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 6 Objetos que interactúan

7 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 7 Ventajas de OOD l Más fácil mantenimiento. Los objetos se pueden entender como entidades autónomas. l Los objetos son potencialmente componentes reutilizables. l Para algunos sistemas, puede haber un evidente mapeo de entidades del mundo real al sistema.

8 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 8 Objetos y clases de objetos l Los objetos son entidades de un sistema de software que representan los casos del mundo real y entidades del sistema. l Clases de objetos son las plantillas de los objetos. Éstos pueden utilizarse para crear objetos. l Clases de objetos pueden heredar los atributos y servicios de otras clases de objetos.

9 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 9 Objetos y clases de objetos Un objeto es una entidad que tiene un estado y un conjunto definido de operaciones que operan en ese estado. El estado es representado como un conjunto de los atributos de los objetos. Las operaciones asociadas de prestar servicios a otros objetos (clientes) que solicitan estos servicios cuando se requiere algún cálculo. La definición de la clase de un objeto sirve de plantilla para los objetos. Incluye las declaraciones de todos los atributos y servicios que debería estar asociada con un objeto de esa clase.

10 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 10 El Lenguaje Unificado de Modelado l Diferentes notaciones para la descripción de los diseños orientados a objetos se propusieron en los años 1980 y 1990. l El Lenguaje Unificado de Modelado es una integración de estas anotaciones. l En él se describe una serie de anotaciones de los diferentes modelos que pueden ser producidos durante el análisis y diseño OO. l Ahora es un estándar de facto para el modelado OO.

11 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 11 Clase Empleado (UML)

12 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 12 Comunicación de objetos l Conceptualmente, los objetos se comunican por mensajes. l Mensajes El nombre del servicio solicitado por el objeto, la convocatoria; Copias de la información necesaria para ejecutar el servicio y el nombre de un titular para el resultado del servicio. l En la práctica, los mensajes se aplican a menudo por llamadas de procedimiento Name = nombre de procedimiento; Información = lista de parámetros.

13 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 13 Mensaje - ejemplos

14 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 14 Generalización y la herencia l Los objetos son miembros de las clases que definen Tipos de atributos y operaciones. l Las clases pueden ser organizadas en una jerarquía de clase donde una clase (una super-clase) es una generalización de una o más clases (sub-clases). l Una sub-clase hereda los atributos y operaciones de su super clase y puede agregar nuevos métodos o de sus propios atributos. l Generalización en UML se implementa como herencia en los lenguajes de programación OO.

15 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 15 Una jerarquía con generalización

16 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 16 Ventajas de la herencia l Se trata de un mecanismo de abstracción que se puede utilizar para clasificar las entidades. l Se trata de un mecanismo de reutilización, tanto en el diseño y la programación. l El gráfico de la herencia es una fuente de conocimientos sobre ámbitos de organización y sistemas.

17 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 17 Problemas con la herencia l Clases de objetos no son auto-contenidas. que no puede entenderse sin referencia a sus super-clases. l Los diseñadores tienen una tendencia a la reutilización del patrimonio gráfico creado durante el análisis. Puede llevar a importantes ineficiencias. l La herencia de los gráficos de análisis, el diseño y la aplicación tienen diferentes funciones y debe ser mantenido por separado.

18 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 18 Asociaciones UML l En UML, una relación generalizada se indica mediante una asociación. l Las asociaciones pueden ser anotadas con la información que describe la asociación. l Asociaciones son de carácter general, pero pueden indicar que un atributo de un objeto es un objeto o asociaciones de que un método se basa en un objeto asociado.

19 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 19 Un modelo de asociación

20 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 20 Objetos concurrentes l La naturaleza de los objetos como autónomos de las entidades hace que sean adecuados para concurrentes aplicaciones. l No es necesario que un objeto ejecute los mensajes de forma secuencial y que espere hasta completar un servicio solicitado.

21 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 21 Servidores y objetos activos l Servidores. El objeto está implementado como un proceso paralelo (servidor) con los puntos de entrada correspondientes a las operaciones de objeto. l Objetos activos Los objetos se implementan como procesos paralelos y el estado interno del objeto podrá ser modificado por el objeto en sí mismo y no sólo por las llamadas externas.

22 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 22 Transpondedor de objeto l Objetos activos pueden tener sus atributos modificados por las operaciones, pero también puede actualizarlos autónomamente mediante operaciones internas. l Un transpondedor de objeto emite la posición de una aeronave. La posición puede ser actualizada mediante un sistema de posicionamiento por satélite. El objetivo es actualizar periódicamente la posición mediante la triangulación de los satélites.

23 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 23 Un transpondedor

24 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 24 Hilos de Java l Hilos en Java son una simple construcción de los objetos de aplicación concurrente. l Debe incluir un método llamado run () y este se inicia por el JRE o tiempo de ejecución del sistema. l Objetos activos suelen incluir un bucle infinito de modo que siempre están llevando a cabo el cómputo.

25 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 25 Proceso de diseño orientado a objetos l Los procesos de diseño estructurado implican el desarrollo de un número de diferentes modelos de sistemas. l Requieren un gran esfuerzo para el desarrollo y mantenimiento de estos modelos y, para sistemas pequeños, esto puede no ser rentable. l Sin embargo, para los grandes sistemas desarrollados por diferentes grupos de diseño de modelos son un mecanismo de comunicación esencial.

26 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 26 Las fases del proceso l Destacan las principales actividades sin estar atados a ninguna propiedad, como el proceso RUP. Definir el contexto y las modalidades de utilización del sistema; Diseño de la arquitectura del sistema; Identificar los principales objetos del sistema; Desarrollar modelos de diseño; Especificar las interfaces de los objetos.

27 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 27 Descripción del sistema

28 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 28 Contexto del sistema y los modelos de utilización l Desarrollar una comprensión de las relaciones entre la fase de diseño de software y su entorno externo l Contexto del sistema Un modelo que describe otros sistemas en el entorno. Utilice un subsistema modelo para mostrar otros sistemas. Tras las presentaciones de diapositivas de los sistemas de todo el sistema de estación meteorológica. l Modelo del utilización del sistema Un modelo dinámico que describe cómo el sistema interactúa con su entorno. Usar casos de uso para mostrar las interacciones

29 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 29 Arquitectura

30 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 30 Subsistemas en el sistema de cartografía meteorológica

31 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 31 Modelos de casos de uso l Los modelos de casos de uso se utilizan para representar a cada interacción con el sistema. l Un modelo de caso de uso muestra las características del sistema en puntos suspensivos y la interacción de la entidad figura como un palo.

32 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 32 Casos de uso para la estación meteorológica

33 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 33 Descripción del caso de uso

34 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 34 Diseño arquitectónico l Una vez que las interacciones entre el sistema y su entorno se han entendido, se utiliza esta información para diseñar la arquitectura del sistema. l Una arquitectura como se explica en el capítulo 11 es apropiado para la estación meteorológica Capa de interfaz para el manejo de las comunicaciones; Capa de recogida de datos para la gestión de los instrumentos; Capa de instrumentos para la recolección de datos. l Normalmente no habrá más de 7 entidades en un modelo arquitectónico.

35 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 35 Estación meteorológica arquitectura

36 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 36 Identificación de objetos l La identificación de objetos (o clases de objetos) es la parte más difícil de diseño orientado a objetos. l No hay ninguna "fórmula mágica" para la identificación de objetos. Se basa en la habilidad, la experiencia, dominio y conocimiento de los diseñadores de sistemas. l Identificación de objetos es un proceso iterativo. Es poco probable que salga bien la primera vez.

37 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 37 Aproximaciones a la identificación l Utilice un enfoque gramatical basado en una descripción en lenguaje natural del sistema (utilizado en el método de OOD Hood). l Base de la identificación de las cosas tangibles en la aplicación de dominio. l Utilice un enfoque de comportamiento e identificar los objetos sobre la base de lo que participa en el comportamiento. l Utilice un escenario basado en el análisis. Los objetos, atributos y métodos en cada una de las hipótesis se han identificado.

38 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 38 Estación meteorológica descripción Una estación meteorológica es un paquete de software de control de instrumentos que recoge los datos, realiza procesamiento de datos y transmite estos resultados para su posterior interpretación. Los instrumentos de aire y tierra como termómetros, un anemómetro, una veleta, un barómetro y un pluviómetro. La recogida de datos se realiza periódicamente. Cuando se emite un comando de transmitir los datos del tiempo, la estación meteorológica procesa y resume los datos recogidos. Un resumen de los datos se transmitirán a la cartografía de equipo cuando se recibe una petición.

39 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 39 Estación meteorológica - clases de objetos l Termómetro, anemómetro, barómetro Aplicación de objetos que son de dominio "hardware" objetos relacionados con los instrumentos en el sistema. l Estación meteorológica La interfaz básica de la estación meteorológica con su entorno. Por lo tanto, refleja las interacciones identificadas en el uso de caso modelo. l Datos meteorológicos Encapsula el resumen de datos de los instrumentos.

40 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 40 Estación meteorológica clases de objetos

41 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 41 Objetos y refinación l Uso de dominio de más conocimientos para identificar los objetos y las operaciones Estaciones meteorológicas deberían tener un identificador único; Las estaciones meteorológicas se encuentra a distancia de los instrumentos, de modo que los fracasos tienen que ser reportados automáticamente. Por lo tanto, los atributos y las operaciones de auto-control son obligatorios. l Objetos activos o pasivos En este caso, los objetos son pasivos y recopilan datos sobre pedido en lugar de manera autónoma. Esto introduce la flexibilidad a costa del controlador de tiempo de procesamiento.

42 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 42 Diseño de modelos l Mostrar modelos de diseño de los objetos y clases de objetos y relaciones entre estas entidades. l Los modelos describen la estructura del sistema en términos de clases de objetos y relaciones. l Modelos dinámicos describen las interacciones dinámicas entre objetos.

43 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 43 Ejemplos de diseño de modelos l Sub-sistema de modelos que muestran agrupaciones lógicas de objetos en los subsistemas coherentes. l Secuencia de modelos que muestran la secuencia de interacciones objeto. l Modelos de máquinas de estados que muestran cómo cada uno de los objetos cambian su estado en respuesta a los acontecimientos. l Otros modelos incluyen el uso de los modelos de casos de uso, los modelos de agregación, modelos de generalización, etc

44 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 44 Subsistema de modelos l Muestra cómo el diseño se organiza en grupos relacionados con la lógica de los objetos. l En el UML, estas se muestran utilizando paquetes. Se trata de un modelo lógico. La organización efectiva de los objetos en el sistema puede ser diferente.

45 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 45 Subsistemas de estación meteorológica

46 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 46 Modelos de secuencia l Los modelos de secuencia muestran la secuencia de las interacciones que tienen lugar entre los objetos Los objetos están dispuestos horizontalmente en la parte superior; El tiempo es representado de manera vertical, los modelos se leen de arriba hacia abajo; Las interacciones son representadas por flechas etiquetadas, Diferentes estilos de flecha representan los diferentes tipos de interacción;

47 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 47 La recopilación de datos de secuencias

48 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 48 Statecharts l Mostrar cómo los objetos responden a diferentes solicitudes de servicio y el estado de transición provocada por estas peticiones Si el estado es apagado luego responde a un mensaje de inicio (); En el estado de espera el objeto está a la espera de nuevos mensajes; Si reportWeather () entonces el sistema se mueve a resumir el estado; Una recopilación de estado se recibe cuando se introduce una señal de reloj.

49 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 49 Estación meteorológica diagrama de estado

50 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 50 Especificación de la interfaz l Las interfaces tienen que ser especificadas de manera que los objetos y otros componentes pueden ser diseñados en paralelo. l Los diseñadores deben evitar el diseño de la interfaz de la representación, sino que debe ocultar esta en el objeto en sí. l Puede haber varias interfaces que son puntos de vista sobre los métodos previstos. l El UML utiliza los diagramas de clase de especificación de interfaz de Java, pero también puede ser utilizada.

51 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 51 Estación meteorológica de interfaz

52 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 52 Evolución del diseño l Ocultar la información dentro de los objetos significa que los cambios realizados a un objeto no afecten a otros objetos en una forma impredecible. l Asumir la vigilancia de la contaminación son las instalaciones que se agregan a estaciones meteorológicas. Estas muestran el aire y calculan la diferencia del importe de contaminantes en la atmósfera. l Lecturas de datos de la contaminación se transmiten con el clima.

53 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 53 Cambios necesarios l Añadir una clase de objeto llamado la calidad del aire como parte de WeatherStation. l Añadir una operación reportAirQuality a WeatherStation. Modificar el software de control para recoger lecturas de la contaminación. l Añadir los objetos que representan los instrumentos de vigilancia de la contaminación.

54 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 54 La vigilancia de la contaminación

55 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 55 l OOD es un enfoque para diseñar de manera que los componentes de diseño tienen su propio estado y las operaciones privadas. l Los objetos deben tener el constructor y las operaciones de inspección. Prestan servicios a otros objetos. l Los objetos pueden aplicarse simultáneamente o secuencialmente. l El Lenguaje Unificado de Modelado provee diferentes notaciones para la definición de modelos de objetos diferentes. Puntos clave

56 ©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 56 Puntos clave l Una gama de diferentes modelos pueden ser producidos en un proceso de diseño orientado a objetos. Estos incluyen el establecimiento de modelos de sistemas y dinámica. l Las interfaces de objetos deben definirse con precisión usando, por ejemplo, un lenguaje de programación como Java. l Diseño orientado a objetos potencialmente simplifica la evolución del sistema.