Actualizado el 21 de Marzo del 2018 (Publicado el 10 de Enero del 2018)
758 visualizaciones desde el 10 de Enero del 2018
325,2 KB
15 paginas
Creado hace 19a (05/04/2006)
Arquitecturas Software
Juan José Moreno Navarro
(Curso de Software basado en
Componentes, junto a Lars-Ake Fredlund)
Arquitecturas Software
• Motivación:
– Complejidad creciente de aplicaciones.
– Sistemas distribuidos (segunda coordenada de
complejidad).
– Sistemas abiertos y basados en componentes
(tercera coordenada de complejidad).
• Idea principal:
Estructura de alto nivel de un sistema software y
sus propiedades globales.
Arquitecturas Software
• Características:
– Parte del diseño de software.
– Nivel del diseño de software donde se definen
la estructura y propiedades globales del
sistema.
– Incluye sus componentes, las propiedades
observables de dichos componentes y las
relaciones que se establecen entre ellos.
– Un aspecto crítico: Una arquitectura errónea
puede llevar a problemas incontables.
1
Arquitecturas Software
• Características:
– Representación de alto nivel de la estructura del
sistema describiendo las partes que lo integran.
– Puede incluir los patrones que supervisan la
composición de sus componentes y las
restricciones al aplicar los patrones.
– Trata aspectos del diseño y desarrollo que no
pueden tratarse adecuadamente dentro de los
módulos que forman el sistema.
Arquitecturas Software
• Nueva disciplina:
– Toda aplicación tiene una arquitectura, aunque
no sea explícita.
– Tradicionalmente ha habido un repertorio de
técnicas, patrones y expresiones para
estructuras sistemas software complejos.
• Arquitectura de Software:
– Hace explícito con rigor lo anterior.
– Incluye modelos, lenguajes y herramientas para
la descripción y desarrollo práctico de
arquitecturas software.
Arquitecturas Software
• Objetivos:
– 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 mutables e inmutables de la misma, así
como los costes 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 propiedad específica
del dominio.
2
Arquitecturas Software
• ¿De qué se ocupa?
– Diseño preliminar o de alto nivel.
– Organización a alto nivel del sistema, incluyendo
aspectos como la descripción y análisis de
propiedades relativas a su estructura y control
global, los protocolos de comunicación y
sincronización utilizados, la distribución física del
sistema y sus componentes, etc.
– Otros aspectos relacionados con el desarrollo del
sistema y su evolución y adaptación al cambio:
composición, reconfiguración, reutilización,
escalabilidad, mantenibilidad, etc.
Arquitecturas Software
• ¿De qué no se ocupa?
– Diseño detallado.
– Diseño de algoritmos.
– Diseño de estructuras de datos.
Arquitecturas Software
• ¿Qué elementos intervienen?
– Componentes.
– Realizan cómputos y almacenamiento de datos.
– Interaccionan unos con otros durante la
ejecución.
• ¿Qué elementos no intervienen?
– Módulos (fuente) del sistema.
– Interacción: relaciones de definición/uso.
– Importación o exportación de elementos
definidos en el código fuente.
3
Arquitecturas Software
• ¿Cómo interviene en la consecución de una
solución?
– Métodos arquitectónicos.
– Espacio de los diseños arquitectónicos:
propiedades de los diferentes diseños
arquitectónicos y su capacidad para resolver
diferentes problemas.
• ¿Cómo no interviene?
– Métodos de desarrollo de software:
Proporcionan un camino entre el espacio del
problema y la solución.
Arquitecturas Software
• Puntos en común:
– Los métodos de desarrollo suelen basarse en un
estilo arquitectónico preferido.
– Nuevos estilos arquitectónicos proponen
nuevos métodos de desarrollo.
Un mismo diseño arquitectónico puede servir
para dos aplicaciones distintas (ej. los
patrones de diseño)
Estilos arquitectónicos
• Clasificación de los sistemas software en grandes familias
cuyos integrantes comparten un patrón estructural común.
• Ejemplos: Filtros y pipes, organizados en capas,
cliente/servidor, etc.
• Intervienen: patrón de organización general, tipos de
componentes presentes habitualmente, interacciones entre
ellos.
• Ejemplos de componentes: clientes, servidores, filtros,
niveles, bases de datos, ...
• Ejemplos de mecanismos de interacción: RPC, paso de
mensajes, protocolos de comunicación, ...
• El campo de aplicación no es relevante.
4
Estilos arquitectónicos
Sistemas de flujo de datos
Procesamiento por lotes
Filtros y pipes
Sistemas basados en
llamada y retorno
Sistemas de componentes
independientes
Programa principal y subrutinas
Orientados a objetos
Organizados en capas
Comunicación entre procesos
Cliente/servidor
Basados en eventos
Estilos arquitectónicos
Sistemas centrados en
los datos
Repositiorios
Pizarras
Máquinas virtuales
Intérpretes
Basados en reglas
Sistemas heterogéneos
Localmente heterogéneos
Jerárquicamente heterogéneos
Simultáneamente heterogéneos
Estilos arquitectónicos
• Indica
– Los tipos de componentes y conectores
involucrados.
– Patrones y restricciones de interconexión o
composición entre ellos: Invariantes del estilo.
• Asociados a cada estilo hay una serie de
propiedades que lo caracterizan, determinando
sus ventajas e inconvenientes, condicionando la
elección de uno u otro estilo.
5
Ejemplo: Organización en capas
• Los componentes son las capas o niveles que pueden
estar implementadas internamente por objetos o
procedimientos.
• Cada nivel tiene asociado una funcionalidad:
– Niveles bajos: Funciones simples, ligadas al hardware o al
entorno.
– Niveles altos: Funciones más abstractas.
• Mecanismos de interacción entre componentes:
– Llamadas a procedimientos.
– Llamadas a métodos.
Ejemplo: Organización en capas
• Restricciones:
– Solo llamadas de niveles superiores a inferiores.
– (Variante) Solo llamadas entre niveles adyacentes.
• Aplicación:
– Torres de protocolos de comunicación,
– Sistemas operativos,
– Compiladores.
Ejemplo: Organización en capas
s
a
d
a
m
a
l
l
Nivel n: aplicaciones de usuario
.
.
.
Nivel n: aplicaciones de usuario
Nivel n: aplicaciones de usuario
o
n
r
o
t
e
r
6
Ejemplo: Organización en capas
• Propiedades:
– Facilita la migración. El acoplamiento con el entorno está
localizado en las capas inferiores. Estas son las únicas a
re-implementar en caso de transporte a un entorno
diferente.
– Cada nivel implementa unas interfaces claras y lógicas, lo
que facilita la sustitución de una implementación por otra.
– Permite trabajar en varios niveles de abstracción. Para
implementar los niveles superiores no necesitamos
conocer en entorno subyacente, solo las interfaces que
proporcionan los niveles inferiores.
Modelos y arquitecturas de referencia
• Particularizan un estilo imponiendo una serie de
restricciones sobre el mismo y realizando una
descomposición y definición estándar de componentes.
• OSI (Open System Interconection) que particulariza el
estilo de organización en capas, con 7 niveles.
• RM-ODP para el diseño de sistema distribuidos y
abiertos (ISO/ITU-T, 1995). Hace transparente la
heterogeneidad de plataformas, s.o., lenguajes, ...Se
basa en el estilo de componentes independientes.
• CCM, COM, JavaBeans - Sistemas basados en el
intercambio de eventos.
Marcos de trabajo/Frameworks
• Definen una arquitectura adaptada a las particularidades
de un determinado dominio de aplicación, definiendo de
forma abstracta una serie de componentes y sus
interfaces y estableciendo las reglas y mecanismos de
interacción entre ellos.
• Suele incluirse la implementación de algunos de los
componentes e incluso varias implementaciones
alternativas.
• El usuario
– Selecciona, instancia, extiende y reutiliza los componentes del
marco.
– Completa la arquitectura con nuevos componentes específicos
dentro de las relaciones estructurales del marco.
7
Marcos de trabajo
• Básicamente se presentan como un diseño reutilizable
de todo o parte de un sistema, representado por un
conjunto de componentes abstractos y la forma en
que los componentes interactuan.
• Una alternativa es verlos como un esqueleto de una
aplicación que debe ser adaptado por el programador
según sus necesidades concretas.
• Un marco de trabajo define el patrón arquitectónico
que relaciona los componentes de un sistema.
Marcos de trabajo
• Presentan dos niveles:
– Especificación de la arquitectura marco.
– Implementación del marco de trabajo (normalmente un
lenguaje orientado a objetos).
• Al desarrollo de aplicaciones a partir de un marco de
trabajo se le denomina extensión del marco:
– Puntos de entrada (hot spots): Componentes o
procedimientos cuya implementación final depende de la
aplicación concreta.
– Definidos por el diseñador del marco para que sean la
forma natural de la extensión del mismo.
Marcos de trabajo
• Dependiendo de la extensión tenemos:
Marcos de trabajo de caja blanca
Que se extienden mediante herencia, concretamente
mediante la implementación de las clases y métodos
abstractos definidos como puntos de entrada. Se tiene
acceso al código del marco y se permite reutilizar la
funcionalidad de sus clases mediante herencia y
redefinición de métodos.
Marcos de trabajo de caja de cristal
Admiten la inspección de su estructura e implementación,
pero no su modificación ni extensión, excepto en los
puntos de entrada.
8
Marcos de trabajo
Marcos de trabajo de caja gris
Los puntos de entrada no son simplemente métodos
abstractos, de los que se declara meramente su
signatura, sino que se definen por medio de un lenguaje
de especficación de alto nivel los requisitos que deben
cumplirse a la hora de implementarse.
Marcos de trabajo de caja negra
Marcos de trabajo de caja negra
Su instanciación se realiza por medio de composición y
delegación
Comentarios de: Arquitecturas Software (0)
No hay comentarios