3ra Guia Estilos Arquitectonicos

Diseo de Software
Estilos Arquitectnicos
Fundamentos del Diseo de Software - Arquitecturas de Software
Diseo 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 - Cmo ellos se conectan - Qu justifica la estructura utilizada
Diseo de Software
Se puede construir un sistema sin conocer su estructura?
En Ingeniera 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 organizacin fundamental de un sistema que engloba a sus componentes, las relaciones entre ellos, el ambiente y los principios que orientan su diseo y evolucin (IEEE Std 1471-2000)
Diseo de Software
La definicin de Bass, Clemens y Bazman (2003)

- La arquitectura de software de un programa o sistema de computacin 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, mtodos, 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.
Diseo 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 conexin
(Perry y Wolf, 1992) - Una coleccin de componentes computacionales en conjunto con una descripcin de las interacciones entre estos componentes, es decir, de los conectores (Garlan y Shaw, 1993)
Diseo de Software
Diseo arquitectnico Es el proceso de diseo inicial para identificar los subsistemas y establecer un marco de trabajo para el control y comunicacin de los subsistemas Su producto es la arquitectura software
Diseo de Software
Arquitectura de Software La arquitectura de un sistema de software define la(s) estructura(s) del sistema en trminos de:
- Componentes y - Conexiones entre estos componentes
Especifica la estructura y topologa del sistema Arquitectura = {componentes, conexiones, justificacin}
Diseo de Software
Arquitectura de Software
Una arquitectura de software es una abstraccin de un sistema
- Establece como est compuesto el sistema y como sus componentes interactan - Suprime los detalles de sus elementos - Ejemplo: Arquitectura de una aplicacin web basada en componentes distribuidos
Presentation Layer Business Logic Layer Business Process Components Data Layer
Client Side Components
Web Server Components
Databases
Business Entity Components
XML Data Stores
10
Diseo de Software
La arquitectura de software es una nueva metfora del diseo de software que abarca metodologas de anlisis y de diseo
Anlisis Diseo
El concepto de arquitectura de software demanda la inclusin de las actividades de anlisis y diseo dentro de un marco de trabajo ms grande y ms coherente La integracin de metodologas y modelos es uno de los aspectos que distinguen las arquitecturas de software de una tcnica particular de anlisis y diseo
11
Diseo de Software
Un aspecto central del diseo de la arquitectura de una aplicacin es su descripcin El estndar IEEE 1471-2000 establece un modelo conceptual para la descripcin de arquitecturas de software La descripcin arquitectnica de una aplicacin se usa para:
- Hacer explicita la arquitectura del sistema en una etapa inicial, es decir se realiza un proceso de anlisis desde el inicio - Expresar la arquitectura de la aplicacin y su evolucin - Facilitar la comunicacin de esta arquitectura entre los interesados - Evaluar la arquitectura y compararla con otras - Facilitar la planificacin y ejecucin del desarrollo de la aplicacin - Una arquitectura se puede reutilizar si los requisitos son similares
12
Diseo de Software
El marco conceptual IEEE 1471-2000 para la descripcin de arquitecturas de software
Misin 1..* +cumple Ambie nte +habita_en +influye +tien e_una Aplicacin +tiene 1..* 1..* Intere sado (stakeholder) 1..* 1..* +tiene +es_importante_para Asunto 1..* +cu bre 1..* +participa_en +establece_mtodos_para 1..* 1..* 1..* Modelo +orien tado_a 1..* 1 +cumple_con Vista +consiste_de 1..* +identifica De s cripcin arquitectnica +selecciona Arquitectura +es_descrita_por 1 +prove e_una Justificacin
1..*
Punto de Vista
13
Diseo de Software
Arquitectura de Software Procesos comunes en todo diseo arquitectnico

- Estructuracin 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 - Descomposicin modular Cada subsistema se descompone en mdulos
14
Diseo de Software
Diferencia entre subsistema y mdulo 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 Mdulos
Mdulo
- Es un componente de un sistema que suministra uno o ms servicios a otros mdulos y utiliza los servicios suministrados por otros mdulos - Por lo general, no son un sistema independiente - Esta compuesto de componentes simples
15
Diseo de Software
Una arquitectura de software puede ser modelada y descrita desde diferentes puntos de vista Cada punto de vista captura uno o ms aspectos (asuntos) de la arquitectura - Esta representacin se denomina vista
Vista funcional Vista estructural
Aplicacin Vista de implementacin Vista dinmica
16
Diseo de Software
Una vista es una descripcin 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:
- Propsito Son los aspectos de la vista que se pretenden representar - Alcance Establece los lmites de lo que est en la vista y lo que est fuera de ella - Elementos Son los elementos arquitectnicos que componen la vista y sus interrelaciones
17
Diseo 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 Estructural
(Diagramas de clase y de objetos)
Vista de Implementacin
(Diagramas de componentes)
Vista del Comportamiento:

Describe los aspectos dinmicos del sistema Vista de Uso Vista de Comportamiento
(Diagramas de interaccin, de estado, de actividades) (Casos de uso)
Vista de la Implementacin
Describe los componentes implementables del sistema
Vista de Despliegue
(Diagramas de despliegue)
Vista del Despliegue

Indica las relaciones entre los componentes del sistema y el hardware donde ellos se instalarn
18
Diseo de Software
Estilos arquitectnicos
Cmo disean los ingenieros civiles un puente?
- Una vez establecidos los requisitos de la obra,
Determinan cul es el estilo arquitectnico que mejor satisface esos requisitos Puente colgante, de vigas voladas, de pilotes, etc. Luego usan el estilo seleccionado para disear la estructura del puente
19
Diseo de Software
Estilos arquitectnicos
Los ingenieros de software, tambin, emplean estilos arquitectnicos Un estilo arquitectnico se define como:
- Un patrn o modelo arquitectnico que es comn a una familia de arquitecturas de sistemas de software - El estilo establece un vocabulario comn de componentes y conectores - El estilo satisface un conjunto de requisitos que es comn a la familia de sistemas que l representa
20
Diseo de Software
Diseo arquitectnico
La primera fase del diseo es la descomposicin del sistema en subsistemas que interactan Estos se describen utilizando diagramas de bloques donde cada bloque representa un subsistema Se especifica este modelo utilizando estilos arquitectnicos para compartir datos, distribuir subsistemas y comunicarse
Sistema de Visin Controlador de brazo Controlador de Asidero
Sistema de identificacin de Objetos
21
Diseo de Software
Principales estilos arquitectnicos
Basado en flujo de datos

Secuencial por lote Conductos y filtros
Centrados en datos (modelo del depsito)

Bases de datos Pizarrones
Componentes independientes
Procesos comunicantes Sistemas cliente-servidor Sistemas guiados por eventos
Llamada y retorno
Programa principal y subrutinas Orientado a Objetos Capas
Mquinas virtuales
Intrpretes Sistemas basados en reglas
Basado en Niveles
Tres niveles N-niveles
22
Diseo de Software
Estilos arquitectnicos 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
Secuencial por lotes Valida Ordena Imprime
listado
Tuberas y Filtros
Principales estilos:
- Secuencial por lotes (batch) - Tuberas y Filtros (Pipe and filter)
23
Diseo de Software
Estilos arquitectnicos basados en el flujo de datos

Tubera-filtros es una arquitectura popular que conecta componentes computacionales (filtros) a travs de conectores (pipes), de modo que las cmputos se ejecutan a la manera de un flujo Los datos se transportan a travs de las tuberas El sistema tubera-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada
Tuberas y Filtros
Los datos entran al sistema y fluyen a travs de los componentes
24
25
Diseo de Software
Estilos arquitectnicos basados en el flujo de datos Este estilo arquitectnico se debe usar cuando:
Se puede especificar la secuencia de un nmero conocido de pasos No se requiere esperar la respuesta asincrnica 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)
25
Diseo de Software
Estilos arquitectnicos basados en el flujo de datos Ventajas

- Son simples de entender e implementar - Es posible implementar procesos complejos - Es fcil de envolver (wrap) en una transaccin atmica - Los filtros se pueden empaquetar y hacerlos paralelos y distribuidos
26
Diseo de Software
Estilos arquitectnicos basados en el flujo de datos Desventajas

- Pueden resultar demasiado simplistas para servicios que podran ramificar la ejecucin de la lgica del negocio de formas complicadas. - Agregar un paso suplementario afecta el rendimiento de cada ejecucin de la tubera - No es apto para manejar situaciones interactivas, sobre todo cuando se requieren actualizaciones incrementales de la representacin en pantalla - La independencia de los filtros implica que es muy posible la duplicacin de funciones de preparacin que son efectuadas por otros filtros (correccin de un objeto de fecha)
27
Diseo de Software
Estilos arquitectnicos componentes independientes

El sistema es concebido como un conjunto de procesos independientes u objetos que se comunican a travs 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 difusin (broadcast) Estilo guiado por interrupciones
- Sistemas cliente-servidor (Sistemas de control)
28
Diseo de Software

Modelo guiados por eventos - Estn basados en la invocacin implcita, sin llamada directa - En lugar de invocaciones de procedimientos explcitas o directas: un componente anuncia uno o ms eventos y otros componentes registran el inters en un evento asociando un procedimiento a dicho evento - La ocurrencia de un evento causa la invocacin implcita de procedimientos en otros mdulos - til en broadcasting
29
Diseo de Software

Modelo guiado por eventos (Difusin o Invocacin implcita):
- El sistema consta de un manejador de eventos y varios subsistemas o componentes - Los componentes registran su inters en atender eventos especficos - 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 1
Componente 2
Componente 3
Componente 4
Manejador de eventos
30
Diseo de Software

Usos Frecuentes del modelo guiado por eventos
- Integracin de herramientas - Gestores de bases de datos (mantener consistencia) - Interfaces de Usuario
31
Diseo de Software

El modelo de eventos seala que este estilo puede utilizarse cuando:
- Se desea manejar independientemente y de forma aislada diversas implementaciones de una funcin especfica - Las respuestas de una implementacin 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
32
Diseo de Software

Ventajas del estilo guiado por eventos
- Alta versatilidad al poder registrarse a eventos dinmicamente - Alta reutilizacin Introduccin de nuevos componentes nicamente registrndose - Facilita la evolucin del sistema Fcil sustitucin de componentes - Acoplamiento inexistente entre componentes - Permite que procesos de negocios que no estn relacionados sean independientes - Alienta el desarrollo en paralelo, lo que puede resultar en mejoras de rendimiento - Corren sincrnica o asincrnicamente porque no se espera una respuesta Fundamentos del Diseo de Software - Arquitecturas de Software
33
Diseo de Software
Estilos arquitectnicos componentes independientes Desventajas del estilo guiado por eventos
- Prdida de control en el comportamiento del sistema - Problemas en el intercambio de datos - Es difcil asegurar la correccin global del sistema - Proceso sin garantas Alguien registrado? Orden de ejecucin?
34
Diseo de Software
Estilos arquitectnicos componentes independientes 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
URL
Archivo en HTML XML
Cliente
Navegador Web
Internet Intranet
URL
Archivo en HTML XML
Servidor Web
Objeto Web
35
Diseo de Software
Estilos arquitectnicos 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 invocacin remota al servidor enviando una solicitud (RPC) El servidor recibe la solicitud, la procesa de manera sncrona o asncrona y responde al cliente enviando los datos solicitados - Este enfoque se puede utilizar junto con el modelo de depsito
URL
Archivo en HTML XML
Cliente
Navegador Web
Internet Intranet
URL
Archivo en HTML XML
Servidor Web
Objeto Web
36
Diseo de Software
Estilos arquitectnicos cliente servidor Ventajas

- Es una arquitectura distribuida - Es fcil agregar un nuevo servicio - Se puede modificar un servicio sin afectar al sistema
37
Diseo de Software
Estilos arquitectnicos basados en datos o repositorios

Conocido tambin como el modelo de depsito En este modelo los subsistema comparten datos a fin de trabajar de forma conjunta En este estilo arquitectnico hay dos componentes principales: una estructura de datos que representa el estado actual del sistema y una coleccin de componentes independientes que operan sobre ella
Cliente 2 Cliente 1 Base de datos Cliente n Cliente 3
Cliente i
38
Diseo de Software

Este enfoque se basa en el compartir fuentes de datos para pasar informacin Estas fuentes son: Pizarrones Base de datos central Cada subsistemas tienen sus propias bases de datos
Cliente n Cliente 2 Cliente 1 Base de datos Cliente 3
Cliente i
39
Diseo de Software

Estilo de base de datos compartida Generador - Los datos comunes o de estado de Cdigo se mantienen en una base de datos (BD) - La BD es compartida por un Editor conjunto de subsistemas (clientes) Base de - Los subsistemas determinan datos cuando acceder a la BD - La BD debe satisfacer las necesidades de Generador datos de cada uno de los Analizador subsistemas de informes1 controlar el acceso concurrente de los subsistemas
40
Diseo de Software

No existe necesidad de transmitir explcitamente los datos entre subsistema Los subsistemas que producen datos no necesitan saber como son utilizados esos datos por otros subsistemas
Generador de Cdigo Editor Base de datos
Las actividades de seguridad y control deben estar centralizadas Es difcil distribuir el depsito en varias mquinas
Analizador
Generador
de informes1
41
Diseo 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 resolucin del problema Una estrategia, que regula el orden en que operan las fuentes
- Cuando la pizarra cambia de estado, las aplicaciones responden
42
Diseo de Software

Se utiliza en exploraciones recientes de inteligencia artificial distribuida, cooperativa, en robtica, en modelos multi-agentes, en programacin evolutiva, en gramticas complejas Se puede usar en aplicaciones de optimizacin y bsqueda en programacin gentica y evolutiva que de otro modo no encontrara un estilo en el cual encuadrarse
43
Diseo de Software

Al inicio del proceso de resolucin, 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 travs de la pizarra Finalmente, si de la cooperacin resulta una solucin adecuada, sta aparece en la pizarra como paso final
44
Diseo de Software
Estilos arquitectnicos de sistemas llamada retorno

Esta familia de estilos enfatiza la facilidad a realizar modificaciones (mantenibilidad) y la escalabilidad Son los estilos ms generalizados en sistemas de gran escala Se caracterizan por definir un modelo de activacin que implica un hilo principal de control (programa principal) encargado de invocar operaciones
45
Diseo de Software

Estilo de programa principal y subrutinas - Estilo tpico de las aplicaciones procedimentales
El control se inicia en el tope de la jerarqua 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
46
Diseo de Software

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 (mtodos) las cuales son invocados por los otros objetos a travs de mensajes - Cada objeto tiene una clase que describe sus estructura y comportamiento
m1() m3(a)
:ObjetoTipo1 m2() m3()
:ObjetoTipo2 m4(a1,a2,a3) :ObjetoTipo4
Diagrama de colaboracin
:ObjetoTipo3
47
Diseo de Software
Estilos arquitectnicos estratificado o en capas

Conocido como el modelo de mquinas abstractas Organizacin jerrquica 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 mquina abstracta cuyo lenguaje de mquina se utiliza para implementar el siguiente nivel
48
Diseo de Software

Casos representativos de este estilo son muchos de los protocolos de comunicacin entre capas El ejemplo ms caracterstico es el modelo OSI con los siete niveles (nivel fsico, datos, red, transporte, sesin, presentacin y aplicacin)
Permite el desarrollo incremental del sistema Es una estilo portable y modificable
49
Diseo de Software

Ventajas
- El estilo soporta un diseo basado en niveles de abstraccin crecientes, lo cual a su vez permite la particin de un problema complejo en una secuencia de pasos incrementales - El estilo admite muy naturalmente optimizaciones y refinamientos - Proporciona amplia reutilizacin
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 estndar
50
Diseo de Software

Desventajas
- Muchos problemas no admiten un buen mapeo en una estructura jerrquica - Consideraciones de rendimiento pueden requerir acoplamientos especficos entre capas de alto y bajo nivel - Es difcil encontrar el nivel de abstraccin correcto
51
Diseo de Software
Estilos arquitectnicos en niveles Arquitectura de tres o ms niveles

- La gestin de los datos y la ejecucin de los programas de aplicacin se distribuyen entre dos o ms servidores - Los clientes se encargan de manejar todo lo relativo a la interfaz U/S
(Wikipedia, 2007)
52
Diseo de Software
Estilos arquitectnicos en niveles

La arquitectura de 3-Niveles consta de: - Capa de presentacin
Consta de uno o ms clientes que ejecutan los procesos de interfaz U/S
Presentation Layer Business Logic Layer Business Process Components Data Layer
- Capa de lgica del negocio

Consta de un servidor de aplicaciones que ejecuta los procesos de negocios automatizados
Client Side Components Web Server Components
Databases
Business Entity Components
XML Data Stores
- 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 lgica del negocio
53
Diseo de Software
Estilos arquitectnicos en niveles
Memoria a Largo Plazo
NIVEL DELIBERATIVO
rdenes de ejecucin
Eventos
Memoria a Corto Plazo
NIVEL AUTOMTICO
Sensores
Actuadores
54
Diseo de Software
Actividades prcticas
Objetivo de la actividad:
- Seleccionar uno o ms estilos arquitectnicos que sean el o los ms apropiados para la aplicacin que su grupo disear
Duracin:
- 30 minutos
Pasos a seguir:
- Analicen los requisitos funcionales y no-funcionales de su aplicacin Utilice el Documento de Requisitos o los modelos funcional, estructural y dinmico elaborados en la IR (Requisitos de Software) - Identifiquen aquellos estilos que ustedes consideren que podran ser aplicados - Seleccionen uno o ms de estos estilos y justifiquen su decisin Fundamentos del Diseo de Software - Arquitecturas de Software
56

3ra Guia Estilos Arquitectonicos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

3ra Guia Estilos Arquitectonicos

Загружено:

Авторское право:

Доступные форматы

Diseo de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Es posible construir un puente sin tener sus planos?

Fundamentos del Diseo de Software - Arquitecturas de Software

Se puede construir un sistema sin conocer su estructura?

El concepto de arquitectura de software

Fundamentos del Diseo de Software - Arquitecturas de Software

La definicin de Bass, Clemens y Bazman (2003)

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Especifica la estructura y topologa del sistema Arquitectura = {componentes, conexiones, justificacin}

Fundamentos del Diseo de Software - Arquitecturas de Software

Client Side Components

Web Server Components

Business Entity Components

XML Data Stores

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Arquitectura de Software Procesos comunes en todo diseo arquitectnico

Fundamentos del Diseo de Software - Arquitecturas de Software

Diferencia entre subsistema y mdulo Subsistema

Fundamentos del Diseo de Software - Arquitecturas de Software

Aplicacin Vista de implementacin Vista dinmica

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

El Modelo de Vistas 4+1

Vista del Comportamiento:

Vista del Despliegue

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Sistema de identificacin de Objetos

Fundamentos del Diseo de Software - Arquitecturas de Software

Principales estilos arquitectnicos

Basado en flujo de datos

Centrados en datos (modelo del depsito)

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos basados en el flujo de datos

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos basados en el flujo de datos

Los datos entran al sistema y fluyen a travs de los componentes

Fundamentos del Diseo de Software - Arquitecturas de Software

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos basados en el flujo de datos Ventajas

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos basados en el flujo de datos Desventajas

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos componentes independientes

- Sistemas guiados por eventos

- Sistemas cliente-servidor (Sistemas de control)

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos componentes independientes

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos componentes independientes

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos componentes independientes

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos componentes independientes

Fundamentos del Diseo de Software - Arquitecturas de Software

Estilos arquitectnicos componentes independientes

Fundamentos del Diseo de Software - Arquitecturas de Software