Introducción a la ingeniería de software. Arquitectura de software (página 2)

Partes: 1, 2

13
Estilos, Patrones e Idioms
Los patrones de diseño se agrupan en tres tipos
Estilos arquitectónicos: Soluciones de organización a nivel del sistema

Patrones de diseño: Soluciones a problemas detallados de diseño de software

Idioms: Soluciones útiles para problemas específicos en algún lenguaje de programación

14
Estilos Arquitectónicos
Un estilo arquitectónico
expresa un esquema de organización estructural para sistemas de software.
Provee un conjunto de tipos de elementos predefinidos,
especifica sus responsabilidades e
incluye reglas y guías para organizar las relaciones entre ellos
(Gp:) Capa n
(Gp:) Capa n – 1
(Gp:) Capa 2
(Gp:) Capa 1
(Gp:) .
.
.
.

15
Patrones de Diseño
Un patrón de diseño
provee un esquema para refinar los elementos de un sistema de software o las relaciones entre ellos.
Describe una estructura recurrente de elementos de diseño interconectados que soluciona un problema general de diseño dentro de un contexto particular

Mencionen algún patrón de diseño que conozcan

16
Idioms
Un idiom
es un patrón de bajo nivel, específico para un lenguaje de programación.
Describe como implementar aspectos particulares de elementos o de las relaciones entre ellos usando las características de un lenguaje particular.

Arquitectura de Software
SubEstilos Arquitectónicos

18
Beneficios de Usar Estilos
Permite seleccionar una solución entendible y probada a ciertos problemas, definiendo los principios organizativos del sistema

Al basar la arquitectura en estilos que son conocidos las personas entienden más fácilmente las características importantes de la misma

19
Formas de Uso de los Estilos
Solución para el diseño del sistema
Algún estilo sirve.
Se adopta y se usa como una de las estructuras centrales de la arquitectura.

Base para una adaptación
Algún estilo soluciona parcialmente los problemas.
Se puede buscar adaptar el estilo para las restricciones particulares que se tienen.

20
Formas de Uso de los Estilos (2)
Inspiración para una solución relacionada
Ningún estilo sirve.
Sin embargo, entender problemas que solucionan ciertos estilos puede llevar a entender mejor el problema actual.
Entonces, se puede encontrar una solución que de alguna forma está relacionada con estilos existentes

Motivación para un nuevo estilo
El problema no es atacado por ningún estilo encontrado
Es una buena oportunidad para encontrar una solución general al problema y crear un nuevo estilo

21
Algunos Estilos
Shared Data (Datos Compartidos)
Pizarrón (Blackboard)
Cliente–Servidor
Capas Jerárquicas
Descomposición Orientada a Objetos
Tubos y Filtros
Control Centralizado
Control Basado en Eventos
Arquitecturas de Sistemas Distribuidos
Cliente-Servidor
Objetos Distribuidos
Peer-To-Peer
Service Oriented Architecture (SOA)

22
Shared-Data
Generalidades
Hay un almacenamiento central de datos y un conjunto de componentes que operan sobre éste.

Interacción – intercambio de datos persistentes
Múltiples accesos a los datos
Al menos un almacenamiento compartido
Si se avisa al consumidor de nuevos datos de interés es un Pizarrón (Blackboard)
Si es el consumidor quien busca los datos es un Repositorio

23
Ventajas y Desventajas
Forma eficiente de compartir grandes cantidades de datos.
No se transmiten datos de un componente a otro.
Sin embargo, los subsistemas deben estar de acuerdo en el modelo de datos del repositorio.
Las componentes que producen datos no necesitan conocer como van a ser usados esos datos.
Actividades como respaldos, seguridad, control de acceso y recuperación están centralizadas.
Sin embargo, diferentes componentes podría tener distintas políticas de recuperación, respaldo, etc.

24
Pizarrón (Blackboard)
Fuentes de Conocimiento
Procesos independientes que corresponden a particiones del conocimiento del mundo y del dominio dependientes de la aplicación
Responden a cambios en el pizarrón
Estructura de datos del Pizarrón
Estado completo de la solución del problema
único medio por el cual las Fuentes de conocimiento interactúan para llegar a la solución
Control
Guiado enteramente por el estado del pizarrón
Las Fuentes de conocimiento responden oportunamente cuando los cambios en el pizarrón aplican
Puede implementarse en las FC, en el pizarrón, en un componente separado o cualquier combinación de éstos.

25
Pizarrón (Blackboard)
Pizarrón
FC 1
FC 7
FC 6
FC 2
FC 3
FC 4
FC 5
Cálculos
Memoria (Compartida)

26
Cliente-Servidor
El sistema se descompone en servicios y sus servidores asociados y en clientes que acceden y usan dichos servicios.
Estilo compuesto por:
Servidores que ofrecen servicios.
Clientes que usan servicios ofrecidos por los servidores.
Una red que permite que los clientes accedan a los servidores.
Esto no es estrictamente necesario ya que clientes y servidores pueden estar en una misma máquina.
Los clientes conocen a los servidores pero no a otros clientes y los servidores no tienen porqué conocer a los clientes
la asignación de procesos a procesadores no tiene porqué ser 1:1

27
Cliente-Servidor (2)
Ci = clientes
Si = servidores

28
Capas Jerárquicas
El sistema se organiza en capas.
Cada una provee un conjunto de servicios a las capas superiores y requiere servicios de las inferiores.
Capa n
Capa n – 1
Capa 2
Capa 1
.
.
.
.

29
Capas Jerárquicas (2)
Modelo estricto: una capa sólo utiliza servicios de la inmediata inferior.
Modelo relajado: se pueden “saltar” capas.
Definición de protocolos mediante los que interactúan las capas

30
Ventajas y Desventajas
Ventajas
Facilita la comprensión
Facilita mantenimiento
Facilita reutilización
Facilita portabilidad
Desventajas
No siempre es fácil estructurar en capas ni identificar los niveles de abstracción a partir de los Requerimientos.
la interpretación de comandos en múltiples niveles puede afectar el desempeño.

31
Descomposición O.O.
Se descompone el sistema en un conjunto de objetos que se comunican.
Representación de datos y operaciones asociadas se encapsulan en un objeto.
Herencia, polimorfismo, sobrecarga de operadores, enlace dinámico.

32
Ventajas y Desventajas
Ventajas
La implementación de los objetos puede ser cambiada sin afectar a otros objetos.
Promueve la reutilización de componentes.
Muchos objetos representan entidades de la realidad por lo que es fácil entender la estructura del sistema.
Desventajas
Para usar servicios se debe conocer el nombre de la interface de otro objeto.
Los cambios en las interfaces afectan a todos los objetos que la usan.

33
Tubos y Filtros
Se descompone el sistema en módulos funcionales
Interacción – sucesiva transformación de flujos de datos
Los datos llegan a un filtro, se transforman y son pasados a través de tubos al siguiente filtro
Un único filtro puede pasar datos a múltiples tubos y recibir datos de múltiples tubos
Cada filtro es independiente del resto y no conoce la identidad de los otros filtros
La transformación del filtro puede comenzar antes de terminar de leer la entrada
Respetando el grafo, no importa la secuencia (paralelismo)
(Gp:) Filtro
(Gp:) Tubo

34
Ventajas y Desventajas
Ventajas
Se pueden reutilizar los filtros.
Es intuitivo pensar en secuencias de procesamientos de datos.
Agregar nuevas transformaciones de forma que el sistema evolucione es sencillo.
Desventajas
Acordar cuál es el formato de los datos.
Tiene que ser “genérico” si las componentes son reusadas.
Sistemas interactivos son difíciles de construir con este estilo.
Ineficiente si hace más de lo que debe o si los filtros repiten chequeos

35
Modelos de Control
Modelos de control a nivel de la arquitectura se preocupan del flujo de control entre subsistemas

Control centralizado
Un subsistema controla al resto

Control basado en eventos
Cada subsistema puede responder a eventos externos
Eventos generados por otros subsistemas
Eventos generados por el ambiente del sistema

36
Control Centralizado (1)
El control centralizado se puede dividir en dos clases
Llamada-Retorno

(Gp:) Principal
(Gp:) Subr. A
(Gp:) Subr.B
(Gp:) Subr.C
(Gp:) Subsistema
(Gp:) Llamado/Retorno

37
Control Centralizado (2)
Modelo Gerente
Una componente es el gerente del sistema y controla a los otros procesos del sistema
Controlador del Sistema
A
B
F
E
C
D

38
Control Basado en Eventos
En los modelos centralizados las decisiones de control suelen estar determinadas por valores de alguna variable de estado del sistema
En cambio, el control basado en eventos es guiado por eventos generados externamente
Ejemplos
Modelos emisión (broadcast). Se emiten los eventos a todos los subsistemas.
Modelos guiados por interrupciones. Se usan en sistemas de tiempo real. Las interrupciones son pasadas por un manejador de interrupciones a otras componentes para su procesamiento.

39
Publicar-Suscribir
Sistema de componentes independientes que anuncian y se suscriben a eventos
Interacción vía eventos anunciados
Los componentes se suscriben a eventos
Es trabajo del run-time asegurarse que cada evento publicado sea entregado a todos los suscriptores de dicho evento
Una forma es la invocación implícita

40
Arquitecturas de Sistemas Distribuidos
Ventajas
Se comparten recursos.
Apertura. Normalmente estos sistemas están diseñados con protocolos estándar.
Concurrencia.
Escalabilidad
Tolerancia a fallas

El procesamiento de la información es distribuido entre varias computadoras.

41
Arquitecturas de Sistemas Distribuidos (2)
Desventajas
Complejidad
Seguridad
Difíciles de gestionar
Muy poco predecibles

Ejemplos
Cliente-servidor
Objetos distribuidos
Peer-to-peer
Service oriented architecture (SOA)

42
Middleware
Las componentes pueden ser
Implementadas en diferentes lenguajes
Ejecutarse en distintos tipos de procesadores
Usar diferentes modelos de datos
Representar de forma diferente la información
Usar distintos protocolos de comunicación
Entonces, se necesita software para gestionar la comunicación y el intercambio de datos entre componentes
Dicho software se denomina middleware
Esta en el medio de las diferentes componentes distribuidas

43
Middleware (2)
Normalmente son usados middleware que son comprados comercialmente ya que son de propósito general.

44
Cliente-Servidor
El diseño de sistemas cliente-servidor debería reflejar la estructura lógica de la aplicación.
Una forma de mirar a una aplicación es la siguiente:
Capa de Presentación
Capa de Procesamiento
Capa Gestión de Datos

45
Cliente-Servidor (2)
Capa de presentación
Presentación de información al usuario e interacción con el mismo
Capa de procesamiento
Implementación de la lógica de la aplicación
Capa gestión de datos
Operaciones de bases de datos y archivos
En sistemas distribuidos es importante distinguir claramente esta separación ya que es posible distribuir cada capa en computadoras diferentes

46
Cliente-Servidor en 2 Niveles
Es la arquitectura más simple cliente-servidor
Varios clientes y un servidor (o varios servidores idénticos)
2 formas diferentes:
Cliente fino
El procesamiento de la información y la gestión de los datos ocurre en el servidor. El cliente sólo es responsable de ejecutar el software de presentación.
Cliente grueso
El servidor es responsable sólo de la gestión de los datos. El cliente ejecuta el procesamiento de la aplicación (la lógica de la aplicación) y la presentación.

47
Cliente Fino, Grueso y Applet
Cliente fino
Procesamiento pesado del lado del servidor
Procesamiento pesado en la red
Cliente grueso
Mejor distribución del procesamiento
La administración del sistema es más compleja
Cuando el software de aplicación cambia hay que reinstalar la aplicación en cada computadora cliente
Java Applets descargables
Están en el medio entre cliente fino y grueso
Luego de descargar el applet se ejecuta parte de la lógica de la aplicación en el cliente

48
Algunos Problemas
En 2 niveles hay que distribuir las tres capas (presentación, lógica y datos) en dos sistemas de computadoras
Pueden surgir problemas de
escalabilidad y rendimiento con el cliente fino
o de gestión del sistema si se usa cliente grueso

Para evitar estos problemas una alternativa es usar una arquitectura cliente-servidor en 3 niveles

49
Cliente-Servidor en 3 Niveles
La presentación, la lógica y los datos se separan como procesos lógicos diferentes distribuidos en distintas máquinas
Ejemplo: Sistema bancario por internet
Cliente
Cliente
Cliente
Cliente
Servidor web
Provisión de
servicios
de cuenta
Servidor de BD
SQL
Base Datos
Cuenta
Cliente
HTTP
Consulta SQL

50
Comparación
La arquitectura en 3 niveles
Es más escalable que la de 2 niveles
Reduce el tráfico en la red en comparación con cliente fino
La capa de procesamiento de la aplicación es fácilmente actualizada ya que está localizada centralmente

Cliente servidor en múltiples niveles
Ejemplo: aplicación que necesita acceder a múltiples fuentes de datos (integración de datos)

51
Ejemplos

52
Objetos Distribuidos
En la arquitectura cliente-servidor los clientes y los servidores son distintos
Los clientes reciben servicios de los servidores y no de otros clientes
Los servidores pueden actuar como clientes de otros servidores pero no requieren servicios de clientes
Los clientes deben conocer los servicios ofrecidos por servidores específicos y deben conocer como contactar a estos servidores
Enfoque más general
Remover la distinción entre clientes y servidores
Diseñar la arquitectura como una de objetos distribuidos

53
Objetos Distribuidos (2)
Se compone de objetos que proveen servicios a otros objetos y usan servicios de otros objetos
No hay distinción entre clientes y servidores
Pueden ser distribuidos entre distintas computadoras en una red y se comunican a través de middleware
Este tipo de middleware se conoce como Object Request Broker (ORB), por ejemplo, CORBA.
Es más complejo de diseñar que cliente-servidor

54
Peer-to-Peer
Sistemas descentralizados donde las computaciones pueden ser realizadas en cualquier nodo de la red
En principio no hay distinción entre clientes y servidores
El sistema se diseña para usar el poder de almacenamiento y procesamiento de múltiples computadoras en una red
Los protocolos que permiten la comunicación entre nodos están embebidos en la propia aplicación
Cada nodo debe correr una copia de la aplicación

55
Peer-to-Peer (2)
Ejemplos
Sistemas para compartir archivos
Mensajería instantánea
Seti@home
Y otros @home
Se está comenzando a usar también en el área de negocios
Intel y Boeing han implementado sistemas intensivos en las computaciones con arquitecturas p2p
Se pueden clasificar en sistemas descentralizados o semi-centralizados

56
Peer-to-Peer (3)
Algunos problemas
Overhead
Seguridad
Confianza
Entonces, son más usados en sistemas que no son críticos respecto a la información

57
Service Oriented Architecture (SOA)
Organizaciones que quieren hacer su información accesible a otros programas pueden hacerlo definiendo y publicando una interface de servicio web

Un servicio web es una representación estándar para algún recurso computacional o de información que puede ser usado por otros sistemas

58
SOA (2)
El servicio es independiente de las aplicaciones que lo usan
Se pueden construir aplicaciones mediante el uso de distintos servicios
Hay varios modelos de servicios distintos. Conceptualmente todos operan de acuerdo al siguiente modelo

59
Comparación SOA y Objetos Distribuidos
Propaganda pública de la disponibilidad del servicio
Potencialmente el enlace con el servicio puede ser en tiempo de ejecución
Oportunidad de crear nuevos servicios a través de composición de otros servicios
Pago por uso de servicios, por su uso más que por su provisión
Esto sustituye componentes caras raramente usadas
Aplicaciones más chicas y compactas
Aplicaciones que pueden ser reactivas y adaptar su operación de acuerdo a su medio mediante el cambio de enlaces a servicios durante la ejecución

60
Web Services Estándares
Los servicios se basan en estándares basados en XML
Entonces, pueden funcionar en cualquier plataforma y ser escritos en cualquier lenguaje

Estándares más conocidos:
SOAP – Simple Object Access Protocol
WSDL – Web Services Description Language
UDDI – Universal Description, Discovery and Integration.

61
Ejemplo
Un sistema de información para un auto provee al conductor con información acerca del clima, las condiciones del tráfico, información local, etc. Esto está vinculado con la radio del auto de forma que la información es entregada como una señal en un canal específico de la radio
El auto está equipado con un recibidor GPS para conocer su posición y, basado en esa posición, el sistema accede a un rango de servicios de información. La información debe ser entregada en el lenguaje especificado por el conductor

62
Ejemplo (2)

63
Evaluación de Arquitecturas
Cambiar la arquitectura de un producto ya construido requiere mucho esfuerzo
Entonces, es importante evaluar la arquitectura antes de implementarla completamente
Verificar los requisitos de calidad establecidos
Evaluaciones a posteriori resultan útiles como forma de aprendizaje y estudio de posibilidades de mejora, por ej. para una nueva versión del producto
Software Engineering Institute (SEI) propone:
Architecture Tradeoff Analysis Method (ATAM)
Software Architecture Analysis Method (SAAM)

64
Bibliografía
Software Engineering 7ed Addison WesleyIan Sommerville
Documenting Software Architectures – Views and Beyond Addison-WesleyPaul Clements et al.
Software Systems Architecture – Working with stakeholders using viewpoints and perspectivesAddison-WesleyNick Rozanski y Eoin Woods