3ra Guia Estilos Arquitectonicos

Diseño de Software

Estilos Arquitectónicos

Fundamentos del Diseño de Software - Arquitecturas de Software 2

Diseño de Software

¿Es posible construir un puente sin tener sus planos?

• Los ingenieros civiles no pueden construir un puente sin planos

• Los planos describen la arquitectura de la obra

• La arquitectura define:

- Cuales son los componentes del puente

- Cómo ellos se conectan

- Qué justifica la estructura utilizada


Diseño de Software

¿Se puede construir un sistema sin conocer su estructura?

• En Ingeniería de Software tampoco es posible construir un sistema sin tener sus planos

- Los planos describen la arquitectura del software

• El concepto de arquitectura de software

- La Arquitectura de Software es “la organización

fundamental de un sistema que engloba a sus

componentes, las relaciones entre ellos, el ambiente y los

principios que orientan su diseño y evolución”

(IEEE Std 1471-2000)


Diseño de Software

• La definición de Bass, Clemens y Bazman (2003)

- “La arquitectura de software de un programa o sistema de

computación es la estructura o estructuras del sistema, la

cual comprende elementos de software, las propiedades

externamente visibles de esos elementos y las relaciones

entre ellos”

• Los elementos de software son los componentes de la

arquitectura

- Componentes de datos (archivos, BDs, repositorios, etc.)

- Componentes computacional (clases, métodos, objetos, etc.)

- Procesos

• Las relaciones son las conexiones entre componentes

• Las propiedades visibles son aquellos supuestos que se

hacen sobre un elemento:

- Servicios que presta

- Rendimiento

- Tolerancia a fallas, etc.


Diseño de Software

Otras definiciones

- Un conjunto de elementos arquitecturales que tienen una

forma particular

• Estos elementos se dividen en tres clases:

- elementos de procesamiento,

- elementos de datos y

- elementos de conexión

(Perry y Wolf, 1992)

- Una colección de componentes computacionales en

conjunto con una descripción de las interacciones entre

estos componentes, es decir, de los conectores

(Garlan y Shaw, 1993)


Diseño de Software

Diseño arquitectónico

• Es el proceso de diseño inicial para

identificar los subsistemas y establecer un

marco de trabajo para el control y

comunicación de los subsistemas

• Su producto es la arquitectura software


Diseño de Software

Arquitectura de Software

• La arquitectura de un sistema de software define la(s) estructura(s) del sistema en términos de:

- Componentes y

- Conexiones entre estos componentes

• Especifica la estructura y topología del sistema

• Arquitectura = {componentes, conexiones,

justificación}


Clie

nt S

ide

Co

mp

on

en

ts

Web S

erv

er

Co

mp

on

en

ts

Diseño de Software


• Una arquitectura de software es una abstracción de un

sistema

- Establece como está compuesto el sistema y como sus componentes interactúan

- Suprime los detalles de sus elementos

- Ejemplo: Arquitectura de una aplicación web basada en

componentes distribuidos Presentation Layer Business Logic Data Layer

Layer

Business Process

Components Databases

Business

Entity XML Data

Components Stores


Diseño de Software

Arquitectura de Software • La arquitectura de software es una nueva metáfora del diseño de software que abarca metodologías de análisis y de diseño

Análisis Diseño

• El concepto de arquitectura de software demanda la inclusión de las actividades de análisis y diseño dentro de un marco de trabajo más grande y más coherente

• La integración de metodologías y modelos es uno de los aspectos que distinguen las arquitecturas de software de una técnica particular de análisis y diseño


Diseño de Software


• Un aspecto central del diseño de la arquitectura de una

aplicación es su descripción

• El estándar IEEE 1471-2000 establece un modelo conceptual

para la descripción de arquitecturas de software

• La descripción arquitectónica de una aplicación se usa para:

- Hacer explicita la arquitectura del sistema en una etapa inicial, es decir se realiza un proceso de análisis desde el inicio

- Expresar la arquitectura de la aplicación y su evolución

- Facilitar la comunicación de esta arquitectura entre los interesados

- Evaluar la arquitectura y compararla con otras

- Facilitar la planificación y ejecución del desarrollo de la aplicación

- Una arquitectura se puede reutilizar si los requisitos son similares


Diseño de Software


• El marco conceptual IEEE 1471-2000 para la descripción de

arquitecturas de software Misión

1..*

+cumple Ambie nte

+habita_en

+influye

+tien e_una Aplicación

+tiene

1..*

1..* +identifica

Arquitectura

+es_descrita_por

1

+prove e_una

+es_importante_para

Asunto

1..*

Intere sado (stakeholder)

1..* 1..*

+tiene

+orien tado_a

Punto de

1..*

Vista

1

De s cripción arquitectónica

+selecciona

1..*

+cumple_con Vista

Justificación

1..* +cu bre +consiste_de

1..*

+participa_en

+establece_métodos_para

1..* 1..*

Modelo

1..*


Diseño de Software


• Procesos comunes en todo diseño arquitectónico

- Estructuración del sistema

• El sistema se estructura en varios subsistemas

- Modelado de Control

• Se establece un modelo general de las relaciones de

control entre las partes del sistema

- Descomposición modular

• Cada subsistema se descompone en módulos


Diseño de Software

Diferencia entre subsistema y módulo

• Subsistema

- Es un sistema por si mismo, sus operaciones no dependen de

servicios suministrados por otros subsistemas. Tiene interfaces

bien definidas que las utiliza para comunicarse con otros

subsistemas

- Un subsistema esta compuesto de Módulos

• Módulo

- Es un componente de un sistema que suministra uno o más

servicios a otros módulos y utiliza los servicios suministrados

por otros módulos

- Por lo general, no son un sistema independiente

- Esta compuesto de componentes simples


Diseño de Software


• Una arquitectura de software puede ser modelada y descrita

desde diferentes puntos de vista

• Cada punto de vista captura uno o más aspectos (asuntos)

de la arquitectura

- Esta representación se denomina vista

Vista Vista

funcional estructural

Aplicación

Vista de Vista

implementación dinámica


Diseño de Software

Arquitectura de Software • Una vista es una descripción parcial del sistema relacionada con un conjunto de aspectos o asuntos que se observan desde cierto punto de vista

• Una vista contiene, al menos, tres elementos:

- Propósito

• Son los aspectos de la vista que se pretenden representar

- Alcance

• Establece los límites de lo que está en la vista y lo que está fuera de ella

- Elementos

• Son los elementos arquitectónicos que

componen la vista y sus interrelaciones


Diseño de Software

El Modelo de Vistas 4+1

• El modelo de vistas 4+1 :

- Vista de Uso:

• muestra la funcionalidad del sistema

- Vista Estructural:

• muestra los componentes estructurales (paquetes y

clases) del sistema

- Vista del Comportamiento:

Vista Estructural (Diagramas de clase y

de objetos)

Vista de Implementación (Diagramas de componentes)

Vista de Uso • Describe los aspectos dinámicos del sistema

- Vista de la Implementación

• Describe los componentes implementables del sistema

- Vista del Despliegue

• Indica las relaciones entre los componentes del

sistema y el hardware donde ellos se instalarán

(Casos de uso)

Vista de Comportamiento (Diagramas de interacción, Vista de Despliegue

de estado, (Diagramas de

de actividades) despliegue)


Diseño de Software

Estilos arquitectónicos • ¿Cómo diseñan los ingenieros civiles un puente?

- Una vez establecidos los requisitos de la obra,

• Determinan cuál es el estilo arquitectónico que mejor satisface esos

requisitos

» Puente colgante, de vigas voladas, de pilotes, etc.

• Luego usan el estilo seleccionado para diseñar la estructura del

puente


Diseño de Software

Estilos arquitectónicos

• Los ingenieros de software, también, emplean estilos

arquitectónicos

• Un estilo arquitectónico se define como:

- Un patrón o modelo arquitectónico que es común a una familia

de arquitecturas de sistemas de software

- El estilo establece un vocabulario común de componentes y

conectores

- El estilo satisface un conjunto de requisitos que es común a la familia de sistemas que él representa


Diseño de Software

Diseño arquitectónico

• La primera fase del diseño es la descomposición del sistema

en subsistemas que interactúan

• Estos se describen utilizando diagramas de bloques donde

cada bloque representa un subsistema

• Se especifica este modelo utilizando estilos arquitectónicos

para compartir datos, distribuir subsistemas y comunicarse

Sistema de

Visión

Sistema de identificación de

Objetos

Controlador

de brazo

Controlador

de Asidero


Diseño de Software

Principales estilos arquitectónicos

Basado en flujo de datos

• Secuencial por lote

• Conductos y filtros

Componentes

independientes

• Procesos comunicantes

• Sistemas cliente-servidor

• Sistemas guiados por eventos

Máquinas virtuales

• Intérpretes

• Sistemas basados en reglas

Centrados en datos (modelo

del depósito)

• Bases de datos

• Pizarrones

Llamada y retorno

• Programa principal y subrutinas

• Orientado a Objetos

• Capas

Basado en Niveles

• Tres niveles

• N-niveles


Diseño de Software

Estilos arquitectónicos basados en el flujo de datos • Conciben el sistema como una

serie de transformaciones de tape

datos de entrada

- Los datos entran al sistema y

fluyen, uno a la vez, entre sus

componentes

• Principales estilos:

- Secuencial por lotes (batch)

- Tuberías y Filtros (Pipe and filter)

Secuencial por lotes

listado Valida Ordena Imprime

Tuberías y Filtros


Diseño de Software

Estilos arquitectónicos basados en el flujo de datos

• Tubería-filtros es una arquitectura

popular que conecta componentes

computacionales (filtros) a través de

conectores (pipes), de modo que las

cómputos se ejecutan a la manera

de un flujo

• Los datos se transportan a través de

las tuberías

• El sistema tubería-filtros se percibe

como una serie de transformaciones

sobre sucesivas piezas de los datos

de entrada

• Los datos entran al sistema y fluyen

a través de los componentes

Tuberías y Filtros


25

Diseño de Software


• Este estilo arquitectónico se debe usar cuando: • Se puede especificar la secuencia de un número conocido

de pasos

• No se requiere esperar la respuesta asincrónica de cada

paso

• Se busca que todos los componentes situados

corriente abajo sean capaces de inspeccionar y actuar

sobre los datos que vienen de corriente arriba (pero no

viceversa)


Diseño de Software


• Ventajas

- Son simples de entender e implementar

- Es posible implementar procesos complejos

- Es fácil de envolver (wrap) en una transacción atómica

- Los filtros se pueden empaquetar y hacerlos paralelos y

distribuidos


Diseño de Software


• Desventajas - Pueden resultar demasiado simplistas para servicios que

podrían ramificar la ejecución de la lógica del negocio de formas complicadas.

- Agregar un paso suplementario afecta el rendimiento de cada ejecución de la tubería

- No es apto para manejar situaciones interactivas, sobre todo cuando se requieren actualizaciones incrementales de la representación en pantalla

- La independencia de los filtros implica que es muy posible la duplicación de funciones de preparación que son efectuadas por otros filtros (corrección de un objeto de fecha)


Diseño de Software

Estilos arquitectónicos componentes independientes

• El sistema es concebido como un conjunto de procesos

independientes u objetos que se comunican a través de

mensajes

• La estructura es modificable, pues los procesos se pueden

desacoplar

• Principales estilos:

- Procesos comunicantes

• Constan de un conjunto de procesos independientes que se comunican

entre sí y que pueden ejecutarse en paralelo

- Sistemas guiados por eventos

• Estilo de difusión (broadcast)

• Estilo guiado por interrupciones

- Sistemas cliente-servidor (Sistemas de control)


Diseño de Software


• Modelo guiados por eventos

- Están basados en la invocación implícita, sin llamada directa

- En lugar de invocaciones de procedimientos explícitas 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

- Útil en broadcasting


Diseño de Software


• Modelo guiado por eventos (Difusión o Invocación implícita):

- El sistema consta de un manejador de eventos y varios sub-

sistemas o componentes

- Los componentes registran su interés en atender eventos específicos

- Cuando un evento ocurre, el manejador de eventos difunde o

transmite (broadcast) un anuncio

- Ejemplos de sistemas basados en eventos:

• Sistemas de tiempo real para manejo de alarmas

Componente Componente Componente Componente

1 2 3 4

Manejador de eventos


Diseño de Software


• Usos Frecuentes del modelo guiado por eventos

- Integración de herramientas

- Gestores de bases de datos (mantener consistencia)

- Interfaces de Usuario


Diseño de Software

Estilos arquitectónicos componentes independientes • El modelo de eventos señala que este estilo puede utilizarse cuando:

- Se desea manejar independientemente y de forma aislada diversas implementaciones de una función específica

- Las respuestas de una implementación no afectan la forma en que trabajan otras implementaciones

- Todas las implementaciones son de escritura solamente o de dispararse y olvidar

• Restricciones

- Quien anuncia el evento no conoce a qué componentes afecta éste

- No se pueden hacer asunciones (supuestos) acerca del orden de procesamiento


Diseño de Software


• Ventajas del estilo guiado por eventos

- Alta versatilidad al poder registrarse a eventos dinámicamente

- Alta reutilización

• Introducción de nuevos componentes únicamente registrándose

- Facilita la evolución del sistema

• Fácil sustitución de componentes

- Acoplamiento inexistente entre componentes

- Permite que procesos de negocios que no están relacionados

sean independientes

- Alienta el desarrollo en paralelo, lo que puede resultar en

mejoras de rendimiento

- Corren sincrónica o asincrónicamente porque no se espera una respuesta

•


Diseño de Software


• Desventajas del estilo guiado por eventos

- Pérdida de control en el comportamiento del sistema

- Problemas en el intercambio de datos

- Es difícil asegurar la corrección global del sistema

- Proceso sin garantías

• ¿Alguien registrado?

• ¿Orden de ejecución?


Diseño de Software


• Estilo cliente-servidor

- Es un modelo de sistemas distribuidos que muestra como los

datos y el procesamiento se distribuye a lo largo de varios

procesadores

- Sus principales componentes son:

• Un conjunto de servidores independientes que ofrecen servicios a

otros subsistema (servidores de impresoras, de archivos, etc.)

• Un conjunto de clientes que llaman a los servicios

• Una red que permite a los clientes acceder a los servicios

Servidor

Cliente

Navegador

Web

URL

Archivo

en HTML

ó XML

Internet

Intranet

URL Web

Archivo

en HTML

ó XML

Objeto Web


Diseño de Software

Estilos arquitectónicos cliente servidor

- Los clientes deben conocer los nombres de los servidores

disponibles y los servicios que ellos ofrecen.

- Los servidores no necesitan saber quienes son sus clientes

- El servidor provee servicios (datos) a los clientes bajo solicitud

• El cliente hace una invocación remota al servidor enviando una

solicitud (RPC)

• El servidor recibe la solicitud, la procesa de manera síncrona o

asíncrona y responde al cliente enviando los datos solicitados

- Este enfoque se puede utilizar junto con el modelo de depósito

Servidor

Cliente

Navegador

Web

URL

Archivo

en HTML

ó XML

Internet

Intranet

URL Web

Archivo

en HTML

ó XML

Objeto Web


Diseño de Software

Estilos arquitectónicos cliente servidor

• Ventajas

- Es una arquitectura distribuida

- Es fácil agregar un nuevo servicio

- Se puede modificar un servicio sin afectar al sistema


Diseño de Software

Estilos arquitectónicos basados en datos o repositorios • Conocido también como el

modelo de depósito

• En este modelo los subsistema comparten datos a fin de trabajar de forma conjunta

• En este estilo arquitectónico hay dos componentes principales:

• una estructura de datos que representa el estado actual

del sistema y

• una colección de componentes

independientes que operan sobre ella

Cliente 2

Cliente 1

Base de

datos

Cliente n …

Cliente 3

…

Cliente i


Diseño de Software

Estilos arquitectónicos basados en datos o repositorios

• Este enfoque se basa en el compartir fuentes de datos para pasar información

Cliente 2 • Estas fuentes son:

• Pizarrones

• Base de datos central

• Cada subsistemas tienen sus

propias bases de datos

Cliente 1

Base de

datos

Cliente n …

Cliente 3

…

Cliente i


Diseño de Software

Estilos arquitectónicos basados en datos o repositorios • Estilo de base de datos compartida

- Los datos comunes o de estado se mantienen en una base de

datos (BD)

- La BD es compartida por un conjunto de subsistemas

(clientes)

- Los subsistemas determinan cuando acceder a la BD

- La BD debe

• satisfacer las necesidades de

Generador

de Código

Editor

Base de … datos

Generador datos de cada uno de los Analizador subsistemas

• controlar el acceso concurrente de los subsistemas

… de informes1


Diseño de Software


• No existe necesidad de transmitir explícitamente los datos entre subsistema

• Los subsistemas que producen datos no necesitan saber como

son utilizados esos datos por otros subsistemas

• Las actividades de seguridad y control deben estar

centralizadas

• Es difícil distribuir el depósito

Generador de Código

Editor

Base de … datos

Generador

en varias máquinas Analizador … de informes1


Diseño de Software


• Estilo de pizarra (blackboard)

- Consta de:

• Fuentes de conocimiento,

necesarias para resolver el

problema

• Una pizarra que representa el

estado actual de la resolución del

problema

• Una estrategia, que regula el

orden en que operan las fuentes

- Cuando la pizarra cambia de

estado, las aplicaciones

responden


Diseño de Software


• Se utiliza en exploraciones

recientes de inteligencia

artificial distribuida,

cooperativa, en robótica, en

modelos multi-agentes, en

programación evolutiva, en

gramáticas complejas

• Se puede usar en aplicaciones

de optimización y búsqueda

en programación genética y

evolutiva que de otro modo no

encontraría un estilo en el cual

encuadrarse


Diseño de Software


• Al inicio del proceso de

resolución, se establece el

problema en la pizarra

• Las fuentes tratan de

resolverlo cambiando el

estado

• La única forma en que se

comunican entre sí es a

través de la pizarra

• Finalmente, si de la

cooperación resulta una

solución adecuada, ésta

aparece en la pizarra como

paso final


Diseño de Software

Estilos arquitectónicos de sistemas llamada retorno

• Esta familia de estilos enfatiza la facilidad a realizar

modificaciones (mantenibilidad) y la escalabilidad

• Son los estilos más generalizados en sistemas de gran

escala

• Se caracterizan por definir un modelo de activación que

implica un hilo principal de control (programa principal)

encargado de invocar operaciones


Diseño de Software

Estilos arquitectónicos de sistemas llamada retorno

• Estilo de programa principal y subrutinas

- Estilo típico de las aplicaciones procedimentales

• El control se inicia en el tope de la jerarquía del sistema (programa

principal) y es pasado a los niveles inferiores mediante llamadas a

subprogramas (calls)

Programa

Principal

Subrutina 1 Subrutina 2 … Subrutina n

Subrutina 2.1 Subrutina 2.2


Diseño de Software

Estilos arquitectónicos de sistemas llamada retorno • Estilo Orientado a Objetos

- El sistema se estructura como un conjunto de objetos que se comunican mediante pases de mensajes

- Cada objeto ofrece un conjunto de servicios u operaciones (métodos) las cuales son invocados por los otros objetos a través de mensajes

- Cada objeto tiene una clase que describe sus estructura y comportamiento

m1()

Diagrama de

colaboración

:ObjetoTipo1

m2() m3()

:ObjetoTipo3

m3(a) :ObjetoTipo2

m4(a1,a2,a3)

:ObjetoTipo4


Diseño de Software

Estilos arquitectónicos estratificado o en capas • Conocido como el modelo de

máquinas abstractas

• Organización jerárquica donde cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le ofrece la capa inmediatamente inferior

• Las capas suelen ser entidades complejas, compuestas de varios paquetes o subsistemas

• Cada capa define un máquina abstracta cuyo lenguaje de máquina se utiliza para implementar el siguiente nivel


Diseño de Software

Estilos arquitectónicos estratificado o en capas • Casos representativos de este

estilo son muchos de los protocolos de comunicación entre capas

• El ejemplo más característico es el modelo OSI con los siete niveles (nivel físico, datos, red, transporte, sesión, presentación y aplicación)

• Permite el desarrollo incremental del sistema

• Es una estilo portable y modificable


Diseño de Software

Estilos arquitectónicos estratificado o en capas

• Ventajas

- El estilo soporta un diseño basado en niveles de abstracción

crecientes, lo cual a su vez permite la partición de un problema complejo en una secuencia de pasos incrementales

- El estilo admite muy naturalmente optimizaciones y refinamientos

- Proporciona amplia reutilización • Se pueden utilizar diferentes

implementaciones o versiones de una misma capa en la medida que soporten las mismas interfaces de cara a las capas adyacentes

• Esto conduce a la posibilidad de definir interfaces de capa estándar


Diseño de Software

Estilos arquitectónicos estratificado o en capas

• Desventajas

- Muchos problemas no admiten

un buen mapeo en una estructura jerárquica

- Consideraciones de rendimiento

pueden requerir acoplamientos

específicos entre capas de alto y

bajo nivel

- Es difícil encontrar el nivel de

abstracción correcto


Diseño de Software

Estilos arquitectónicos en niveles

• Arquitectura de tres o más niveles

- La gestión de los datos y la ejecución de los programas de

aplicación se distribuyen entre dos o más servidores

- Los clientes se encargan de manejar todo lo relativo a la

interfaz U/S (Wikipedia, 2007)


Clie

nt

Sid

e

Co

mp

on

en

ts

Web

Se

rve

r C

om

po

ne

nts

Diseño de Software

Estilos arquitectónicos en niveles

• La arquitectura de 3-Niveles

consta de:

- Capa de presentación

• Consta de uno o más clientes

que ejecutan los procesos de

interfaz U/S

- Capa de lógica del negocio

• Consta de un servidor de

aplicaciones que ejecuta los

procesos de negocios

automatizados

- Capa de datos

• Consta de un servidor de bases

de datos que administra las

bases de datos y proporciona

los datos que requiere la capa

de lógica del negocio

Presentation Layer Business Logic Data Layer

Layer

Business

Process

Components Databases

Business

Entity XML Data

Components Stores


Diseño de Software

Estilos arquitectónicos en niveles Memoria a Largo Plazo

NIVEL DELIBERATIVO

Órdenes de ejecución

Eventos Memoria a Corto Plazo

NIVEL AUTOMÁTICO

Sensores Actuadores


Diseño de Software

Actividades prácticas

• Objetivo de la actividad:

- Seleccionar uno o más estilos arquitectónicos que sean el o los más apropiados para la aplicación que su grupo diseñará

• Duración:

- 30 minutos

• Pasos a seguir:

- Analicen los requisitos funcionales y no-funcionales de su

aplicación

• Utilice el Documento de Requisitos o los modelos funcional,

estructural y dinámico elaborados en la IR (Requisitos

de Software)

- Identifiquen aquellos estilos que ustedes consideren que podrían

ser aplicados

- Seleccionen uno o más de estos estilos y justifiquen su decisión


3ra Guia Estilos Arquitectonicos

Documents

Transcript of 3ra Guia Estilos Arquitectonicos