Arquitectura de Software OO

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

Software de calidad • Fact Factor ores es exte extern rnos os (los (los que que ven ven los los usuarios) usuarios) # # #

Corrección Robustez/Fiabilidad Rendimiento/Eficiencia

• Fact Factor ores es inte interno rnoss (lo (loss que que ven ven los los desarrolladores) 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


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


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


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


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


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


8


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: –

#

Flujo de datos: –

•

permite estudiar cuellos de botella y ex tensibilidad del sistema

accesibilidad de la información y relaciones entre componentes sw

Uso de patrones como soporte a la arquitectura

© JPM, UCM 1999


9


•

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


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 –

#

El diseño OO es el proceso de invención y adaptación –

#

Donde un equipo de desarrolladores modela y entiende los requisitos del sistema 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


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


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


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


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


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


16

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

Descomposición modular –

#

Composición modular – –

#

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

Protección modular –

#

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

Continuidad modular –

#

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

Entendimiento –

#

P.ej.: diseño funcional descendente (top-down)

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


17

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

Soporte del lenguaje para unidades modulares –

#

Pocas interfaces –

#

Si dos módulos se comunican, deben intercambiar la menor información posible

Interfaces explícitas –

#

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

Interfaces pequeñas (acoplamiento débil) –

#

Los módulos deben corresponder a unidades sintácticas del lenguaje usado

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


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


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


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


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

–

Es-Un

–

Tiene-Un

© JPM, UCM 1999

En todos los métodos de diseño

Particular a la OO


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


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


24

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

Diferentes servicios para mercados diferentes –

#

Diferentes plataformas hardware o software –

#

compartición de estructuras de datos y bibliotecas de rutinas

Diferentes eventos externos –

#

velocidad vs. memoria

Diferentes recursos internos –

#

compiladores o sistemas operativos

Diferentes compromisos en recursos –

#

alfabetos diferentes, formatos de E/S diferentes, etc.

interfaz de dispositivo de E/S Unix

Compatibilidad hacia atrás

© JPM, UCM 1999


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

© JPM, UCM 1999

técnicas permiten mejorar la calidad del software


26

Arquitectura de Software OO

Recommend Documents