• Author / Uploaded
• JulieP.Shulterbrondt

• Categories
• Programación orientada a objetos
• Software
• Diseño
• Programación de computadoras
• Lenguaje de programación

Citation preview

Departamento de Sistemas Informáticos y Programación Curso de doctorado 1999-2000 Patrones de diseño orientado a objetos

Software de calidad • Factores externos (los que ven los usuarios) # # #

Corrección Robustez/Fiabilidad Rendimiento/Eficiencia

• Factores internos (los que ven los desarrolladores) # # # # #

Modularidad Flexibilidad/Extensibilidad Reusabilidad Compatibilidad (a través de interfaces estándares/uniformes) Mantenimiento

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

2

Arquitectura software • El software es complejo y sujeto a cambios • Es necesario estructurar el software, definir una arquitectura software: # # #

Cómo se juntan los componentes software De qué forma funciona el sistema Cuáles son los límites del software (definición de las interfaces entre los componentes)

? La arquitectura es el elemento estable ante los cambios en

el ciclo de vida del software ? La clave está en separar interfaces de implementaciones © JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

3

Arquitectura software La separación entre interfaces e implementación # #

Aísla de los cambios Sirve de mecanismo (compilable) de unión entre arquitectura e implementación

Arquitectura

© JPM, UCM 1999

Interfaces

Implementación

Diseño de arquitecturas SW orientado a objetos

4

Arquitectura software • El papel de la arquitectura es proporcionar información de diseño a los desarrolladores, para que éstos puedan hacer cambios y correcciones al software, sin romper la arquitectura. • En cada escala de un sistema software se puede definir una arquitectura y una implementación: # #

La implementación es la realización de los componentes software La arquitectura es la abstracción que define las interfaces entre componentes y ayuda a los desarrolladores y mantenedores del sistema a entender cómo se juntan los componentes

N La arquitectura no se limita al nivel de sistema (arquitectura de sistemas)

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

5

Paradigmas de ingeniería software Programación estructurada • •

Separación de diseño y codificación Asunciones: # #

• •

La mayor parte de los errores se producen durante el diseño de software Los requisitos son estables y bien conocidos (!!!)

El diseño se puede hacer de modo descendente (top-down) Separación de modelo de proceso y modelo de datos

Análisis de requisitos

© JPM, UCM 1999

Diseño

Diseño de arquitecturas SW orientado a objetos

Programación

6

Paradigmas de ingeniería software Programación orientada a objetos •

Proceso iterativo e incremental a través de 3 elementos fundamentales: Análisis OO, Diseño OO y Programación OO

•

Varias metodologías: Booch, Jacobson, Rumbaugh, Scher-Mellor, UML

•

Asunciones:

•

#

Los objetos del dominio son las entidades más estables del sistema

#

Los objetos son entidades tangibles: el modelado con objetos reduce el hueco semántico entre los modelos de tecnología software y los modelos del dominio de negocio

Mezcla modelos de procesos y datos #

Para minimizar y localizar el impacto de los cambios

N Falta la discriminación entre interfaces e implementación (!!!) © JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

7

Paradigmas de ingeniería software Arquitectura Software orientada a objetos •

Asunción principal: #

•

Los problemas del software se deben a una pobre definición de los límites del software

Elementos: #

Arquitectura OO: Cómo se diseña el software para gestionar el cambio y la complejidad del software –

#

Interfaces: especificación detallada de los límites arquitecturales –

#

Define varios límites: categorías de objetos, particiones, interacciones, etc. Por ejemplo, con CORBA IDL

Implementación: componentes software encapsulados por las interfaces, que proporcionan funcionalidad y rendimiento

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

8

Paradigmas de ingeniería software Arquitectura Software orientada a objetos •

Al análisis OO, un modelo de arquitectura OO añade: # # #

•

Flexibilidad para que el sistema evolucione ante nuevos requisitos proporcionando agrupaciones lógicas de los componentes software y una especificación de cómo interaccionan

Las interfaces determinan qué mensajes puede haber en el sistema: #

Flujo de control: –

#

permite estudiar cuellos de botella y extensibilidad del sistema

Flujo de datos: – accesibilidad de la información y relaciones entre componentes sw

•

Uso de patrones como soporte a la arquitectura

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

9

Paradigmas de ingeniería software Arquitectura Software orientada a objetos •

Tratamiento de errores # #

•

(Parte frecuentemente olvidada hasta que no se llega a la codificación) Debe ser considerada una parte de la descripción de las interfaces

Arquitecturas basadas en servicios #

#

Sólo se puede acceder a un objeto por su interfaz (esto es, sin tener ningún conocimiento sobre sus detalles de implementación) Ventajas: –

Los servicios están totalmente desacoplados de los clientes que los usan – Los servicios se pueden compartir por varios clientes => reusabilidad – Posibilidad de reemplazar fácilmente un servidor por otro que ofrezca la misma interfaz => evolución y migración – Apropiado en sistemas distribuidos

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

10

Análisis, diseño y programación OO Los métodos de OO se pueden aplicar en distintas fases del ciclo de vida del software: # El análisis OO es el proceso de descubrimiento – Donde un equipo de desarrolladores modela y entiende los requisitos del sistema #

El diseño OO es el proceso de invención y adaptación – Donde el equipo de desarrolladores crea las abstracciones y mecanismos necesarios

para satisfacer los requisitos de comportamiento del sistema determinados durante el análisis #

La programación OO es el proceso de realización – Donde el equipo de programadores codifica el diseño en un lenguaje de

programación (y para un entorno determinado)

N El diseño OO, a diferencia de la programación es relativamente independiente del lenguaje de programación usado

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

11

Diseño OO Objetivos • Descomponer el sistema en módulos #

identificar la arquitectura software mediante agrupaciones –

los grupos deben maximizar la cohesión y minimizar el acoplamiento

• Determinar las relaciones entre módulos #

identificar y especificar las dependencias entre módulos – herencia, composición, uso, etc.

#

determinar la forma de comunicación entre módulos – variables globales, llamadas a funciones, memoria compartida, paso de mensajes, RPC

• Especificar las interfaces de los módulos #

Las interfaces deben estar bien definidas – facilita la prueba independiente de los módulos – mejora la comunicación e integración del grupo

• Describir la funcionalidad de los módulos #

Informalmente (comentarios o documentación) o formalmente

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

12

Diseño OO Conceptos • Composición/Descomposición • Abstracción # # #

Modularidad Ocultación de la información Jerarquías de máquinas virtuales

• Separación de Política y Mecanismo • Identificación de subconjuntos y familias de programas • Reusabilidad

? El principal propósito de estos conceptos de diseño es gestionar la complejidad del sistema software mejorando los factores de calidad del software © JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

13

Diseño OO Composición/Descomposición • Conceptos comunes a todas las técnicas de diseño software • Proceso: 1. Seleccionar un problema (una parte o todo el sistema) 2. Descomponer el problema seleccionado en uno o más componentes usando el método de diseño elegido (funcional, estructurado, OO) 3. Determinar y representar cómo interactúan los componentes (composición) 4. Repetir los pasos 1 a 3 hasta que se cumpla un criterio de terminación

• Cuestión: ¿A qué nivel de abstracción deben especificarse los módulos? – Subsistemas – Máquinas virtuales – Clases – Funciones

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

14

Diseño OO Abstracción • Motivación: modo de gestionar la complejidad # #

enfatizando las características esenciales suprimiendo los detalles de implementación

• Mecanismos de abstracción tradicionales: – Abstracción de nombres – Abstracción de expresiones – Abstracción procedimental (subrutinas) – Abstracción de datos (ADTs) – Abstracción de control (iteradores, bucles, multitarea, etc.)

• En OO: – Modularidad – Ocultación de la información – Máquinas virtuales

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

15

Diseño OO Modularidad • Motivación Característica esencial de todo buen diseño: # permite reducir la complejidad global del sistema descentralizando la arquitectura software – ejemplo: divide y vencerás #

Mejora la escalabilidad y la productividad (los módulos pueden desarrollarse independientemente por varias personas) – separación de asuntos

• Para ser útiles y reusables, los módulos deben tener: # #

Interfaces abstractas bien especificadas Gran cohesión y poco acoplamiento

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

16

Diseño OO Modularidad • Criterios para evaluar métodos de diseño: #

Descomposición modular – P.ej.: diseño funcional descendente (top-down)

#

Composición modular – ¿Se pueden construir nuevos sistemas a partir de los existentes? – P.ej.: diseño ascendente (bottom-up)

#

Entendimiento – ¿Es fácil entender los módulos por separado? ¿cuán acoplados están los módulos?

#

Continuidad modular – Pequeños cambios en la especificación afectan a un número limitado de módulos

#

Protección modular – Los problemas en ejecución están confinados a un número pequeño de módulos

relacionados #

Compatibilidad modular – Los módulos tienen interfaces bien definidos, uniformes o estándar

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

17

Diseño OO Modularidad • Principios para asegurar diseños modulares: #

Soporte del lenguaje para unidades modulares – Los módulos deben corresponder a unidades sintácticas del lenguaje usado

#

Pocas interfaces – Cada módulo debe comunicarse con tan pocos como sea posible

#

Interfaces pequeñas (acoplamiento débil) – Si dos módulos se comunican, deben intercambiar la menor información posible

#

Interfaces explícitas – Cuando dos módulos se comunican, debe estar claro en el texto de uno o de ambos

#

Ocultación de la información – Toda la información sobre un módulo debe ser privada al módulo a menos que se haya

declarado específicamente como pública

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

18

Diseño OO Ocultación de la información • Motivación: #

Los detalles de las decisiones de diseño que puedan cambiar deben ocultarse detrás de interfaces abstractas

#

Es una manera de mejorar la abstracción

• Información que suele ocultarse: #

Representaciones de datos

#

Algoritmos

#

Formatos de E/S

#

Mecanismos y políticas

#

Interfaces de módulos de bajo nivel

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

19

Diseño OO Máquinas virtuales • Motivación: #

Reducir la complejidad global: un sistema software se puede descomponer en unidades de máquinas virtuales

• Una máquina virtual proporciona un conjunto de instrucciones extendido: # #

Tipos de datos adicionales e instrucciones asociadas Extensiones incrementales a APIs existentes

• Ejemplos: #

Arquitectura de computadores: – compilador -> ensamblador -> código objeto -> microcódigo -> puertas,

trasnsitores, señales, ... #

Pilas de protocolos de comunicación: OSI, Internet

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

20

Diseño OO Máquinas virtuales • Aspectos a tener en cuenta: #

Asegurar un rendimiento adecuado – En el nivel N el rendimiento no será bueno si no lo es por debajo de ese nivel

#

Eliminar dependencias entre niveles – Para incrementar la reutilización

N Por eso se suelen usar arquitecturas en capas o niveles de abstracción

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

21

Diseño OO Máquinas virtuales • Jerarquía de máquinas virtuales: #

#

Una jerarquía reduce las interacciones entre módulos al restringir la topología de las relaciones entre máquinas virtuales Ventajas: – Facilita el desarrollo independiente de niveles o capas – Aisla las ramificaciones de un cambio – Permite el prototipado rápido

#

Relaciones que definen jerarquías: – Usa – Está-compuesto-de

En todos los métodos de diseño

– Es-Un – Tiene-Un

© JPM, UCM 1999

Particular a la OO

Diseño de arquitecturas SW orientado a objetos

22

Diseño OO Políticas y mecanismos separados •

Motivación: #

•

Varias políticas se pueden implementar mediante un conjunto de mecanismos compartidos #

•

Separación de aspectos entre qué/cuando y cómo

P. ej.: planificación de procesos y paginación en memoria virtual

La misma política se puede implementar con varios mecanismos: #

P.ej. un flujo de bytes fiable, sin duplicación puede ser proporcionado por varios protocolos de comunicación

N Qué es política y qué un mecanismo es una cuestión de perspectiva

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

23

Diseño OO Familias de programas y subconjuntos • Una familia de programas es una colección de módulos reusables que forman el armazón de una aplicación: # #

Subsistema de E/S de flujos (streams) de Unix System V Armazones de GUI como Java AWT

• Motivación: #

#

Las familias de programas son útiles para implementar subconjuntos Los subconjuntos reducen costes, tiempo, recursos humanos, etc. – Facilitan la extensión y contracción del sistema software – Promociona la reusabilidad y anticipa cambios potenciales

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

24

Diseño OO Familias de programas y subconjuntos • Las familias de programas soportan: #

Diferentes servicios para mercados diferentes – alfabetos diferentes, formatos de E/S diferentes, etc.

#

Diferentes plataformas hardware o software – compiladores o sistemas operativos

#

Diferentes compromisos en recursos – velocidad vs. memoria

#

Diferentes recursos internos – compartición de estructuras de datos y bibliotecas de rutinas

#

Diferentes eventos externos – interfaz de dispositivo de E/S Unix

#

Compatibilidad hacia atrás

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

25

Programación OO Técnicas y mecanismos • Abstracción de datos y ocultación de la información • Tipos activos (más que pasivos) • Genericidad • Herencia y vinculación dinámica • Programación por contrato • Aserciones y manejo de excepciones ? Estas técnicas permiten mejorar la calidad del software

© JPM, UCM 1999

Diseño de arquitecturas SW orientado a objetos

26