ARQUITECTURAS DE SOFTWARE

ARQUITECTURAS DE SOFTWARE 1. DEFINICIÓN: La arquitectura de software de un programa o de un sistema computacional está definida por la estructura, co...
5 downloads 0 Views 219KB Size
ARQUITECTURAS DE SOFTWARE

1. DEFINICIÓN: La arquitectura de software de un programa o de un sistema computacional está definida por la estructura, comprendida por los elementos de software, las propiedades visibles de esos elementos y las relaciones entre ellos. Se incluyen los siguientes elementos: • • • •

La descripción de los componentes (servidores, clientes, bases de datos, filtros, capas en un sistema jerárquico, etc. ) con los cuales se construyen los sistemas Las interacciones (llamadas a procedimientos, protocolos C/S, protocolos de acceso a BD, etc) entre esos componentes Patrones para guiar la composición Restricciones sobre dichos patrones 1

2. OBJETIVOS: Algunos de los objetivos que se buscan alcanzar al diseñar una arquitectura de software son los siguientes: • • • • •

Comprender y mejorar la estructura de las aplicaciones complejas. Reutilizar dicha estructura (o partes de ella) para resolver problemas similares. Planificar la evolución de la aplicación, identificando las partes que cambian y las que permanecen constantes de la misma, así como los costos de los posibles cambios. Analizar la corrección de la aplicación y su grado de cumplimiento respecto a los requisitos iniciales. Permitir el estudio de algunas propiedades específicas del dominio.

Una de las mayores utilidades de utilizar una arquitectura es que un mismo diseño arquitectónico puede servir para dos aplicaciones distintas (ej. los patrones de diseño). Esto facilita el desarrollo de nuevas aplicaciones y reduce el tiempo que se invierte en dicho proceso. Pero así como trae beneficios, toca tener mucho cuidado en el momento de elegir una arquitectura ya que, una arquitectura errónea puede traer consigo muchos problemas. 3. LDA Un LDA es un lenguaje o notación para describir una arquitectura software e incluye principalmente : • •

1

La descripción de componentes, conectores y enlaces entre ellos. 2 Las herramientas para la verificación de la arquitectura y el prototipado rápido. 3

Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan Carlos. Moreno Navarro Juan José. Arquitecturas de Software. Curso de Software basado en Componentes. 3 Moreno Navarro Juan José. Arquitecturas de Software. Curso de Software basado en Componentes. 2

Existen LDAs de propósito general y otros de dominio específico (DSLs). Los requisitos que debe tener estos lenguajes se pueden clasificar de la siguiente manera 4 : • • • • • •

Composición o Debe describir el sistema como una composición de partes Configuración o Debe describir la arquitectura independientemente de los componentes Abstracción o Debe describir los roles abstractos que juegan los componentes Reutilización o Debe permitir reutilizar componentes, conectores, y arquitecturas Heterogeneidad o Debe permitir combinar descripciones heterogéneas Análisis o Debe permitir diversas formas de análisis de la arquitectura

Algunos ejemplos de los LDAs son: • • • • • • • • •

Lenguaje Unificado de Modelado (UML) Lenguajes de interconexión de módulos y de descripción de interfaz (CORBAIDL) Lenguajes de descripción de arquitectura: Unicon (Mary Shaw y colaboradores - CMU) Wright (Allen y Garlan) Darwin (Magee y Kramer - IC) Rapide (Luckham) C2 (Medvidovic) LEDA (U. Málaga)

4. ESTILOS ARQUITECTÓNICOS Un estilo de arquitectura es una clasificación de los sistemas software en grandes familias cuyos integrantes comparten un patrón estructural común. Este estilo captura paradigmas de computación y comunicación utilizados para tratar con los problemas de programación de una clase en particular 5 . En otras palabras, indican los tipos de componentes y conectores involucrados en una arquitectura. Los diferentes estilos de las arquitecturas tiene sus fortalezas y debilidades y, ciertos estilos hacen que sea más fácil o más difícil trabajar con diferentes obstáculos Las propiedades que caracterizan cada estilo es lo que determina la elección de uno u otro. Un estilo de arquitectura debe tener tres elementos básicos: • •

Una notación bien definida para capturar el estilo de desarrollo de la arquitectura. Un método bien definido para producir y analizar formalmente modelos basados en la especificación capturada en la notación.

4

Acuña César Javier. Arquitecturas de Software. Universidad Rey Juan Carlos. Honeywell. What is a Domain-Specific Software http://www.htc.honeywell.com/projects/dssa/dssa_whatis.html 5

Architecture?

En



Un método bien definido para producir una implementación basada en la especificación capturada en la notación.

Un estilo provee la semántica para realizar los diagramas de arquitectura. Es decir, un estilo establece el significado de los diferentes conectores que se pueden dibujar entre los componentes funcionales. Los sistemas complejos, en su mayoría, son descritos mediante la combinación de dos o más estilos básicos de arquitectura.

5. CLASIFICACIÓN DE ESTILOS Los estilos arquitectónicos se clasifican en los siguientes grupos: . 1. SISTEMAS BASADOS EN FLUJOS 1. Filtros y Pipes 2. Procesamiento por lotes 2. SISTEMAS CALL/RETURN 1. Sistemas Principal/subrutinas 2. Sistemas OO 3. Capas jerárquicas 3. COMPONENTES INDEPENDIENTES 1. Procesos de comunicación 2. Cliente / Servidor 3. Sistemas de Acontecimientos o Eventos 4. MÁQUINAS VIRTUALES 1. Interpretes 2. Sistemas basados en el conocimiento 5. SISTEMAS CENTRADOS EN DATOS 1. Bases de Datos (Repositorios) 2. Sistemas de HiperTexto 3. Sistemas de pizarra

5.1 Filtros y Pipes

5.1.1 Descripción • Cada componente tiene un conjunto de entradas y un conjunto de salidas. • Cada componente lee las entradas y las transforma en salidas. 5.1.2 Restricciones • Los filtros deben ser independientes. No deben compartir estado con otros filtros. • Los filtros realizan la labor independientemente del flujo de entrada. 5.1.3 Ventajas • Permite entender el sistema global en términos de la combinación de componentes • Soporta de buena manera la reutilización. Los filtros son independientes de sus vecinos • Facilidad de Mantenimiento y mejora • Facilidad de diagnóstico (rendimiento, deadlocks) • Soportan la ejecución concurrente 5.1.4 Desventajas • No aconsejado para cuando se necesita interactividad • Problemas de performance ya que los datos se transmiten en forma completa entre filtros

5.2 Sistemas OO

5.2.1 Descripción • Las representaciones de los datos y las operaciones están encapsulados en un tipo abstracto de datos u objeto • Los componentes son objetos • Las invocaciones de métodos son los conectores 5.2.2 Restricciones: • Los objetos son responsables de la integridad de sus representaciones • Dicha representación es ocultada al resto de los objetos 5.2.3 Ventajas • Gracias al invariante de ocultación es posible reemplazar la Implementación sin que afecte a los clientes 5.2.4 Desventajas • Para invocar métodos de un objeto se debe conocer su identidad • Efectos colaterales

5.3 Capas jerárquicas

5.3.1 Descripción • Organizado jerárquicamente en capas, donde cada capa provee servicios a la capa superior y es servido por la capa inferior. • Los componentes son cada una de las capas. • Los conectores son los protocolos de interacción (Llamadas a procedimientos. Llamadas a métodos) entre las capas. • Cada nivel tiene asociado una funcionalidad: o Niveles bajos: Funciones simples, ligadas al hardware o al entorno. o Niveles altos: Funciones más abstractas. 5.3.2 Restricciones: • La interacción está limitada a las capas adyacentes 5.3.3 Ventajas • Facilita la descomposición del problema en varios niveles de abstracción. • Soporta la mejora, los cambios solo afectan a las capas vecinas • Se pueden cambiar las implementaciones respetando las interfaces con las capas adyacentes. 5.3.4 Desventajas • No todos los sistemas pueden estructurarse en capas. • Es difícil encontrar la separación en capas adecuada 5.3.5 Aplicación: • Torres de protocolos de comunicación. • Sistemas operativos. • Compiladores.

5.4 Sistemas de Acontecimientos o Eventos

5.4.1 Descripción • En lugar de invocaciones de procedimientos explicitas o directas, un componente anuncia uno o más eventos y otros componentes registran el interés en un evento asociando un procedimiento a dicho evento. • La ocurrencia de un evento causa la invocación “implícita” de procedimientos en otros módulos. • Los componentes son los módulos cuyas interfaces ofrecen un conjunto de procedimientos y de eventos • Los conectores incluyen llamadas a procedimientos tradicionales así como el ligado de eventos con llamadas a procedimientos 5.4.2 Restricciones: • Quien anuncia el evento no conoce a que componentes afecta el evento • No se pueden hacer asunciones acerca del orden de procesamiento 5.4.3 Ventajas • Provee un robusto soporte de reusabilidad • Facilita la evolución del sistema 5.4.4 Desventajas • Perdida de control en el comportamiento del sistema • Problemas en el intercambio de datos • Es difícil asegurar la corrección global del sistema

5.5 Sistemas de pizarra

5.5.1 Descripción • Existen dos tipos de componentes • Una estructura central de datos (representa el estado del proceso) • Componentes independientes (operan en función del depósito de datos) • Las interacciones entre el repositorio y los demás componentes es variable: • La entrada de los datos es seleccionada por los componentes • El estado de los datos del repositorio selecciona el proceso a ejecutar (pizarra) 5.5.2 Ventajas • Posibilita la integración de agentes. • Adecuado para la resolución de problemas no deterministas. • Se puede resumir el estado de conocimiento en cada momento del proceso 5.5.3 Desve ntajas • Estructura de datos común a todos los agentes • Problemas de carga a la hora de chequear y vigilar el estado de la pizarra.