Arquitecturas de Software Genéricas

Otoño del 2008

Prof. Sergio Ochoa

sochoa@dcc.uchile.cl
 Objetivos de la Presentación

El Proceso de Diseño de un Software involucra

la siguientes tres fases (o actividades básicas):
– Estructuración de un Sistema.
– Diseño del Modelo de Control del Sistema.
– Decomposición Modular (diseño detallado).

DISEÑO DE LA
DINÁMICA

Ciclo de ESTRUCTURACIÓN
DEL SISTEMA
Feedback

DISEÑO
DETALLADO
Estructuración del Sistema
 Estructuración del Sistema (1)

• … una vez que los requisitos (incluyendo los de calidad) están

claramente especificados, comenzamos a hacer arquitectura
del sistema….
• Usualmente se parte por la estructuración de la solución
(sistema).
• Se refiere a la descomposición del sistema a través de un
conjunto subsistemas relacionados.
• El diseño de la arquitectura es normalmente expresado como un
diagrama de bloques, el cual, presenta una vista de la
estructura del sistema.
• Muchos modelos específicos muestran cómo los subsistemas
comparten los datos, cómo son distribuidos y cómo las
interfaces con otros subsistemas pueden ser desarrolladas.
 Estructuración del Sistema (2)

Ejemplo: Consideremos el Diseño Arquitectónico de un

software para controlar un robot, destinado a embalar
distintos tipos de productos.

1. El robot utiliza un sistema de visión para seleccionar objetos

desde una cinta transportadora.
2. Identifica objetos y selecciona el tipo de
embalaje correcto.
3. Saca los objetos de la cinta
transportadora para empaquetarlos.
4. Los empaca y los coloca en otra cinta
transportadora.

Veamos una propuesta de estructuración

para este sistema…
 Estructuración del Sistema (2)

Sistema de
Visión

Sistema de Controlador Controlador

Identificación del Brazo Repositorio
de Objetos

Subsist. de Control
Subsistema
de Empaque
Sistema de
Selección de
Paquetes Controlador
Cinta Transp.

Sistema
Empaquetador

Ejemplo: Sistema de Control de un Robot Empaquetador

 Estructuración del Sistema (3)
• Hay varias recomendaciones generales (soluciones
recurrentes) para estructurar un sistema, algunas de
ellas son:
– Modelo de depósito (o de repositorio)
– Modelo Cliente/Servidor
– Modelo de máquina abstracta
– Otros
– Mezclas de estos

• Cada uno es más apropiado para apoyar un cierto

escenario o conjunto de escenarios.
Depósito o Repositorio
El Modelo de Depósito o de Repositorio(1)

• Muchos subsistemas intercambian datos. Esto

puede darse de dos maneras:
– Los datos compartidos se colocan en una base de datos
central o repositorio y pueden ser accedidos por todos los
subsistemas.

– Cada subsistema mantiene su propia base de datos y pasa

datos explícitos a otros subsistemas.

• Cuando grandes cantidades de datos son

compartidos, el modelo de repositorio es el más
comunmente utilizado.
 Modelo Estructural Estático

Editor de Generador de
Diseños Código

Editor de
Empaquetador Repositorio de Proyectos Programas

Generador
Analizador
de Reportes
de Diseños

Ejemplo: Arquitectura de una herramienta CASE

El Modelo Depósito o de Repositorio (2)

Ejemplo: Arquitectura de una herramienta CASE

Características del Modelo de Repositorio
(1)
Como todos los modelos, éste tiene ventajas y desventajas.

• Ventajas
– Es una forma eficiente de compartir grandes cantidades de datos.
– Los sub-sistemas que producen datos no necesitan saber cómo
estos datos serán utilizados.

– Proporciona un manejo centralizado de los datos producidos, lo

cual facilita su administración (respaldo, seguridad, etc).

– El modelo permite compartir facilmente los datos del repositorio,

con todos los subsistemas (existentes o futuros).

– El sistema se vuelve más fácil de mantener, extender y escalar.

Características del Modelo de Repositorio
(2)
• Desventajas
– Los sub-sistemas deben hacer coincidir sus modelos de datos,
con el del repositorio, lo cual es inevitablemente un compromiso.

– Los cambios en el modelo de datos son caros y difíciles de

implementar.

– El modelo de repositorio fuerza a que todos los subsistemas

unifiquen la política de administración de sus datos.

– El repositorio se vuelve un punto vulnerable. Por otra parte, es

dificil distribuir el repositorio en diferentes máquinas, ya que
esto tiene una complejidad y un costo similar a las B.D.
distribuidas.

– El conocimiento del negocio está distribuido (y a veces

replicado) en diferentes subsistemas.
Características del Modelo de Repositorio
(3)
• El modelo de repositorio es pasivo, el control corre por
cuenta de los sistemas involucrados.

• Existe una variante a este modelo, la cual es conocida

como el modelo de pizarrón.

• Este modelo mantiene una arquitectura general, similar

a la de repositorio, pero es proactivo….

• Cada vez que llegan datos al repositorio, éste hace una

notificación inteligente a todos los subsistemas
involucrados.
Características del Modelo de Repositorio
(Pizarrón)
Cliente-Servidor
 Modelo Cliente-Servidor (1)
• Este modelo brinda otra alternativa para estructurar los
sistemas.
• Es un modelo de Sistemas Distribuido, el cual muestra
cómo los datos y el procesamiento se distribuyen entre
un rango de computadores.
• Típicamente, está compuesto por tres componentes:
– Conjunto de servidores “stand-alone”, los cuales proporcionan
servicios específicos como impresión, manejo de datos, etc.
– Conjunto de clientes que llaman a estos servicios.
– Redes que permiten que los clientes accedan a los servidores.
• Este modelo cuenta con la arquitectura básica más
utilizada en la actualidad.
 Modelo Cliente-Servidor (2)

Cliente 1 Cliente 2 Cliente 3 Cliente 4

Ancho de Banda de la red

Servidor de Servidor de Servidor de Servidor de

Catálogo Vídeo Fotografía Hipertexto

Catálogo Archivos clip Fotografía Hipertexto

de Película Digitalizada WEB

Ejemplo: Arq. de un Sistema Bibliotecario de Películas e Imágenes

 Modelo Cliente-Servidor (3)

Se puede ver desde el punto

de vista del Software o del
Hardware
 Características del Modelo Cliente-
Servidor
• Ventajas
– La distribución de datos es directa.
– Permite el uso efectivo de sistemas de red. Generalmente requiere
hardware barato.
– Es fácil añadir nuevos servidores o actualizar los existentes.
• Desventajas
– El modelo no comparte datos con los diferentes subsistemas
empleados en la organización. El intercambio de datos puede ser
ineficiente.
– Si se intercambian grandes volúmenes de datos, quien más sufrirá
será la performance.
– Hay administración redundante en cada servidor (trabajo solapado).
– No existen registros centrales de nombres y servicios, esto hace difícil
encontrar los servidores y servicios disponibles.
– Es más dificil realizar datamining, o inteligencia de negocio.
Máquina Abstracta
 Modelo de Máquina Abstracta (1)
• Este modelo también es conocido como el modelo de
capas, o estratificado.

• Es utilizado para modelar las interfaces entre los

subsistemas.

• El modelo organiza el sistema en base a un conjunto de

capas (o máquinas abstractas), cada una de las cuales
proporciona un conjunto de servicios.

• Soporta el desarrollo incremental de subsistemas en las

diferentes capas. Cuando la interfaz de una capa
cambia, solamente la capa adyacente se ve afectada.

• Sin embargo, es difícil estructurar los sistemas de esta

manera.
 Modelo de Máquina Abstracta (2)
Ejemplo: La arquitectura de un sistema de administración
de versiones, puede ser abordado utilizando el modelo
de máquina abstracta.

1. Suministra los recursos de administración de la configuración

(releases) en general.

2. Comprende la administración de versiones de objetos.

3. Para ello utiliza un sistema de administración de objetos, que
provee servicios de administración y almacenamiento de
información para los objetos.

4. Utiliza un SABD para proveer almacenamiento básico de datos

y servicios (adm. de transac., confirmación y recuperación,
control de acceso, etc.).
Modelo de Máquina Abstracta (3)
Administrador de Releases

Administrador de Versiones de Objetos

Administrador de Objetos

Sistema de Base de Datos

Ejemplo: Sistema Administrador de Versiones

Características del Modelo de Máquina
Abstracta
• Ventajas:
– Permite el desarrollo incremental.
– Es más mantenible.
– Flexible y fácil de evolucionar.
• Desventajas:
– Estructurar un sistema en capas es difícil.
– Puede haber problemas de performance debido a los
distintos niveles de interpretación de órdenes.
– Puede suceder que una capa dependa de otra, que
no es su predecesor inmediato.
Ejemplo de Modelo de Máquina Abstracta
 Ejemplo de Modelo de Máquina Abstracta

¿Cómo lo hacemos en nuestras organizaciones?

¿Cuál es el nivel de integración de Datos y Servicios?

Arquitecturas de 2/3 Capas… para Web

3-Tiers Architecture

2-Tiers Architecture
Arquitecturas de 2/3 Capas… para Web
Arquitectura de 5 Capas… para Web
 Data Access Interface (DAI)

Una alternativa para implementar la DAI:

Arquitecturas de Objetos
Distribuidos
Arquitecturas de Objectos Distribuidos
(DOA)
• No existe la distinción entre clientes y servidores, ya que cada
objeto es potencialmente cliente y servidor.
• Cada entidad dentro del sistema, provee servicios a sus compañeros
y también recibe servicios de ellos.
• La comunicación entre objetos se realiza a través de un sistema de
middleware llamado ORB (Object Request Broker), que es una
especie de bus de software que comunica a los componentes.
• Al no tener un servidor, estos sistemas son menos vulnerables que
los que implementan una arquitectura C/S.
• Por otra parte, las DOA son bastante más complejas de construir y
mantener que los sistemas C/S.
• Generalmente, también son más lentas.
 Arquitectura de Objectos Distribuidos
(DOA)
o1 o2 o3 o4

S (o1) S (o2) S (o3) S (o4)

Bus de Software (ORB)

o5 o6

S (o5) S (o6)
Arquitectura de Objectos Distribuidos
(DOA)
 Ventajas de las DOA
• Permiten que los diseñadores de estos sistemas puedan
demorar la toma de decisión respecto a dónde y cómo
deberían ser provistos los servicios.
• Es una arquitectura muy abierta, ya que permite que nuevos
recursos sean agregados en el momento que se necesite.
• Permite que los sistemas sean flexibles y escalables.
• Es posible reconfigurar el sistema dinámicamente. Para ello
sólo hay que migrar los objetos del sistema a través de la
red.
…. las principales desventajas son su complejidad y su mal
rendimiento.
“… según el dicho popular, los sistemas de objetos distribuidos
son dulces… y lentos como la miel”.
EJERCICIO
 Ejemplo de ChileMetal
Desarrollar un framework de software integrador de
políticas de administración de sistemas: Adm. de
Usuarios, Políticas de Seguridad y Respaldo,
Datos, Servicios (unificación).

Sistema 1 Sistema 5

FRAMEWORK
Sistema 2 Sistema 4

Sistema 3
 Ejemplo de ChileMetal
Requisitos Críticos:
+ Funcionalidad + Usabilidad
- Interoperabilidad - Aprendibilidad
- Seguridad - Aceptación de uso
- Pertinencia

+ Mantenibilidad + Confiabilidad (disponibilidad)

- Analizabilidad - Madurez
- Cambiabilidad - Tolerancia a fallas
- Estabilidad - Recuperabilidad

• ¿Cuál(es) cree que es el modelo más apropiado

para estructurar la solución de ChileMetal?
• ¿Qué inconvenientes tienen los otros modelos?
 … Queremos que la solución propuesta
tenga mínimo impacto sobre los sistemas
existentes.

Júntese en grupos de 2 o tres

personas y determine ¿cuál es la
mejor alternativa?.

Luego, comparta su propuesta

con el resto de nosotros.
 Sist
Sist 1 Sist 2 Sist 3 Nuevo

Servicios Estándares

Modelo de Datos Virtual

BD Sist 1 BD Sist 2 BD Sist N

…¿Cuál es la mejor propuesta???

 Sist
Sist 1 Sist 2 Sist 3 Nuevo

Traductor de Servicios

Servicios Estándares

Modelo de Datos Virtual

BD Sist 1 BD Sist 2 BD Sist N

 Ejemplo de ChileMetal
Invocación (propietaria) de Servicios de Validación de
Usuarios:
Sist 1: Valid_User (login, password) -> True/False
Sist 2: Login (login, password) -> Rol/False
Sist 3: Acceso_User (login, password) -> OK/¬OK
Servicios Estándares:
Login (login, password)-> True/False
Rol (login)-> Rol

¿Cómo se traduce la
invocación de login de cada
sistema?
 ¿Podría ser algo así?

Client Side
Sistema de
Rec. Humanos Sistema de
Ventas
Sistema
Contable

Servicio 1

Serv 2
IDL

IDL
Serv 3
IDL
Serv n ORBs
IDL

IDL Serv 4
IDL
Serv n-1
IDL
ORBs
Servicios de IDL Serv 5
Servidor de
Respaldo Serv n-2 Usuarios
 ¿Podría ser algo así?

Client Side
Sistema de
Rec. Humanos Sistema de
Ventas
Sistema
Contable

Servicio 1

¿y los datos? IDL

IDL
Serv 2

Serv 3
IDL
Serv n ORBs
IDL

IDL Serv 4
IDL
Serv n-1
IDL
ORBs
Servicios de IDL Serv 5
Servidor de
Respaldo Serv n-2 Usuarios
Modelo de Control
 Modelos de Control
• Estos modelos son complemetarios a los de estructuración de
sistemas, ya que modelan el control de la ejecución del
sistema.
• Se refieren al control de flujo entre subsistemas. Es diferente
al modelo de descomposición de sistemas y al de
estructuración.
• Entre los modelos de control más conocidos están:
– Control Centralizado
• Hay un subsistema que tiene la responsabilidad de controlar,
iniciar y detener otros subsistemas.
– Control basado en Eventos
• Cada subsistema puede responder a eventos generados
externamente por otros subsistemas o por el ambiente del
sistema. Cada subsist. controla su propia operación.
Control Centralizado
 Control Centralizado (1)

• Hay un subsistema que es el responsable del manejo de la

ejecución de todos los otros subsistemas.
• Dependiendo de la forma de ejecución de los subsistemas
controlados (en secuencia o en paralelo), el modelo de
control puede seguir dos estrategias:
• Modelo Call-Return
– Es aplicable a sistemas secuenciales. Sigue un modelo de subrutina
Top-down, donde el control inicia en lo más alto de la jerarquía de
una subrutina y se mueve hasta la parte más baja en la jerarquía. Es
aplicable a sistemas secuenciales (donde existe in hilo de ejecución).

• Modelo Administrador
– Es aplicable a sistemas concurrentes. Un componente del sistema
controla el inicio, coordinación y la detención de procesos de otro
subsistema. Puede ser implementado en sistemas secuenciales
como una instrucción case.
Control Centralizado: llamada y retorno
(Call-Return)

Programa Principal

Rutina 1 Rutina 2 Rutina 3

Rutina 1.1 Rutina 1.2 Rutina 3.1 Rutina 3.2

Bajo este esquema, cada invocación es bloqueante

 Llamada y Retorno

• Es rígido, simple e intuitivo.

• Su naturaleza rígida y restringida puede verse como
ventaja y como desventaja.

• Es una ventaja porque el sistema es predecible, es fácil

seguir su ejecución y controlar su comportamiento.

• Además, facilita la depuración (debugging) y prueba

del sistema (testing).

• Es una desventaja porque es difícil manejar las

excepciones a las operaciones definidas, y porque limita
el accionar de los usuarios.
Control Centralizado - Administrador

Proceso de Sensor Proceso Actuador

Controlador del Sistema

Procesos de Computación Interfaz de Usuario Manejador de Fallas

Acá las invocaciones no son bloqueantes

 Modelo Administrador
• También es llamado modelo maestro-esclavo.

• Se utiliza generalmente en sistemas críticos, donde la velocidad

de respuesta es importante.

• Donde hay mucho procesamiento descentralizado y se requiere

coordinación.

• También en aquellos casos donde se quiere centralizar la

inteligencia (por ej. coordinadores de workflows).

• Otros ejemplos son: sistemas de control aereo, sistemas de tiempo

real, sistemas de defensa, y sistemas colaborativos sincrónicos, entre
otros.

• El administrador se vuelve un punto vulnerable, pero por otra

parte, sólo tengo que proteger un único administrador.

• El administrador se podría volver un cuello de botella.

 Modelo Administrador

Los sistemas de Workflow suelen seguir este

modelo
Sistemas Manejadores de Eventos
 Sistemas Manejadores de Eventos
• A diferencia de los anteriores, los SME proponen el
modelamiento descentralizado del control.
• Son manejadores de eventos generados externamente,
donde el tiempo del evento está fuera del control de los
subsistemas que lo procesan.
• Dos de los principales modelos manejadores de eventos
son:
– Modelo de Transmisión (Broadcast). Un evento es transmitido
a todos los subsistemas. Cualquier subsistema puede manejar el
evento.
– Modelos Manejadores de Interrupciones. Utilizados en
sistemas en tiempo real donde una interrupción es detectada por un
manejador de interrupciones y es pasada a otros componentes para
ser procesada.

• Ejemplos de sist. que utilizan este enfoque son: hojas de

cálculo, agentes inteligentes, sistemas colaborativos, etc.
Modelo de Transmisión o Broadcast (1)

• Este modelo es efectivo para integrar subsistemas que

están distribuidos a lo largo de diversas computadoras en
una red.
• Los subsistemas registran la petición de eventos
específicos. Cuando esto ocurre, el control es transferido a
los subsistemas que pueden manejar el evento.
• Las políticas de control no están contenidas dentro del
evento o del manejador de eventos.
• Los subsistemas deciden cuáles eventos son de su
interés.
• No obstante, los subsistemas no saben cuándo un
evento será manejado, o si será manejado.
 Modelo de Transmisión o Broadcast (2)

Subsistema Subsistema Subsistema Subsistema

1 2 3 4

Manejador de Eventos y Mensajes

Ejemplo: Transmisión Selectiva

Esquema: Publisher-Subscriber

Los manejadores de eventos nunca son bloqueantes.

Los clientes que invocan servicios podrían bloquearse

o no… Depende de cada aplicación.
Modelo de Transmisión o Broadcast (3)

• Ventajas:
– La evolución de estos sistemas es sencilla. Un nuevo sistema
sólo tiene que registrar los eventos que son de su interés, y
proveer un método de control de su ejecución.
– Cualquier sistema (o servicio) puede activar cualquier otro,
sin conocer su nombre, ni su ubicación.
– Los subsistemas pueden alojarse en distintas máquinas,
manteniendo transparente su forma de operación.

• Desventajas:
– Los subsistemas que emiten los eventos, no saben si estos se
manejarán, ni tampoco cuándo se realizará esto.
– Puede haber más de un subsistema registrado para manejar
un mismo evento. Esto puede generar problemas a la hora de
retornar los resultados del procesamiento del evento, ante una
invocación de servicio.
 Sistemas Manejados por Interrupciones
• Arquitectura utilizada en sistemas de tiempo real,
donde una respuesta rápida es esencial.

• Hay distintos tipos de interrupciones, con un manejador

definido para cada tipo.

• Cada tipo está asociado con una ubicación de memoria, un

switch de hardware dispara la ejecución del manejador
cada vez que llega una señal.

• Proveen una respuesta rápida, pero que es compleja de

programar y difícil de validar.
Sistemas Manejados por Interrupciones
Interrupciones

Vector de
Interrupciones

Manejador 1 Manejador 2 Manejador 3 Manejador 4

Proceso 1 Proceso 2 Proceso 3 Proceso 4

• El vector de interrupciones no se bloquea con cada solicitud (es sólo un

derivador).
• Permite la ejecución paralela de múltiples solicitudes.
• El manejador de eventos puede responder directamente al cliente…..
Variante del Manejador de Interrupciones
Cola de Solicitudes Interrup. /
Eventos
Vector de Interrupciones

Manejador 1 Manejador 2 Manejador 3 Manejador 4

Proceso 1 Proceso 2 Proceso 3 Proceso 4

• Aunque no es la idea, el vector de interrupciones podría bloquearse con

cada solicitud (en caso de ser necesario).
• Si se bloquea, la tasa de atención de solicitudes (transacciones) cae
notablemente.
• El manejador de eventos puede responder directamente al cliente…..
 Volvamos al Ejemplo de ChileMetal
Desarrollar un framework de software integrador de
políticas de administración de sistemas: Adm. de
Usuarios, Políticas de Seguridad y Respaldo,
Datos, Servicios (unificación)

Sistema 1 Sistema 5

FRAMEWORK
Sistema 2 Sistema 4

Sistema 3
 Volvamos al Ejemplo de ChileMetal

Júntese en grupos de 2 o tres personas y

determine ¿Qué modelo de control utilizaría
para organizar el comportamiento de la
estructura propuesta?

Luego, comparta su propuesta

con el resto de nosotros.
Estas son las Arquitecturas que
teníamos

¿Cuál es el modelo de control de ellas?

Modelos de Control para la Opción 1

¿Cuál es el mejor?
Modelos de Control para la Opción 2
Descomposición Modular (3)
 Descomposición Modular

• Es otro nivel de estructura donde los subsistemas

son descompuestos en módulos.

• Dos modelos de descomposición modular son:

– Modelo de Objetos. Donde el sistema es
descompuesto en objetos relacionados.

– Modelo de Flujo de Datos. Donde el sistema es

descompuesto en módulos funcionales, los cuales,
transforman entradas en salidas. Esto es conocido como
el modelo pipeline.

• Es posible tomar decisiones acerca del

comportamiento del sistema antes de que los
módulos sean implementados.
 Modelos de Objetos (1)
• Estructura el sistema en un conjunto de objetos
débilmente acoplados con interfaces bien definidas.
• La descomposición orientada a objetos se refiere a la
identificación de clases de objetos, sus atributos y
operaciones.
• Cuando se implementa este modelo, los objetos son
creados a partir de estas clases.
• Se utiliza un modelo de control para coordinar
operaciones entre los objetos.
• Un ADL (Lenguaje de Descripción de Arquitectura) muy
usado para esto es UML, aunque muchos reclaman es es
demasiado informal.
 Modelos de Objetos (2)
Ejemplo: Sistema de Procesamiento de Facturas

Cliente Recibo
Cliente # Factura #
Nombre Factura Fecha
Dirección Cantidad
Período de Crédito Factura # Cliente #
Fecha
Cantidad
Cliente

Emisión
Pago Envío de Recordatorio
Aceptación de Pago
Factura # Envío de Recibo
Fecha
Cantidad
Cliente #

Las clases son autónomas… pueden vivir por si solas…

Modelos de Flujo de Datos (1)
• Las entradas a procesos de transformaciones
funcionales producen salidas.

• Puede ser visto como un sistema de tubos (pipe) y

filtros (como un shell de UNIX).

• Las variaciones de este enfoque son muy

comunes. Cuando las transformaciones son
secuenciales nos encontramos con un modelo batch
secuencial, el cual es muy utilizado en sistemas de
procesamiento de datos.

• Este modelo no es realmente conveniente para

sistemas interactivos.
 Modelos de Flujo de Datos (2)
Ejemplo: Sistema de Procesamiento de Facturas
Emitir Recibos
Recibos

Leer Facturas Identificar

Emitidas Pagos
Emitir
Recordatorio de
Pago
Encontrar Pagos
Retrasados

Facturas Pagos Recordatorios

Pagos
PagosRetrasados
Retrasados

Los procesos NO son autónomos… no viven por si solos…

Modelos de Flujo de Datos (3)

Selecc.Deselecc
de Artic
1.1.4
Cliente
Administra Pedido
(Carro Virtual)

Nr ícu
de Artic

Ar
Selecc.

o . lo -
Login, Pwd,

C Ca
ar n
an o
MultiTienda 1.1.1

.-C arr
Ce

ro t
t.
de rtifica

tíc C
Identifica Clientes

Ar ro.

Ce . Ca
Para sistemas
lC
Rta lien do

Nr
N

rtif
(login)

o
te

. C ro
Cliente Carro Virtual - Archivo

te
Temporal

Or-
1.1.2

de
Web, es bastante
Ofrece Menú de

n/

Ca te
Rta

r ro
Detalle

Nr rtif. C
Artic. /
Artículos

rd

-C r ro
t.
wo

an
Art o. Ca

Ce
o.
ss
pa

íc.
Nr
más fácil trabajar Lo
gin
,
1.1.3
Procesa Compra

.
tic

de A ilidad
Ar
(Genera OC y carro

con DFD para

rtic.
virtual)

onib
1.1.7
DAO – Catalogo de
Valida Cliente

Disp
Artículos Ofrecidos

Art talle
De
ic.
realizar la

Orden de Compra
Certif. del Cliente
/
Datos Cliente

descomposición
1.1.6
1.1.5
Reserva de Artículos
Obtiene Detalle de
Artículos
DAO – Clientes

modular. Info. Artíc.

Artículos
Reserva

DAO – Catalogo de

Artíc
Ordenes de Compra

s ulo
DAO – Stock de
Artículos en Bodega
DAO – Catalogo de
Artículos Ofrecidos
 Modelos de Flujo de Datos (4)
Es más fácil separar la funcionalidad en capas

Cliente
Cliente

Login, Pwd,
MultiTienda

Ar cc.
de Sele

D
tic

es
Se cc
el
Rta

le de
/

e
sq

cc A
./ rt
Bu

ic
1.1.1 Certificado 1.1.2 Nro. Carro 1.1.4
del Cliente Artíc.-Cant.
Identifica Clientes Ofrece Menú de Administra Pedido
(login) Artículos (Carro Virtual)
t.
an
.-C
rtíc
,A
rro
Ca
o.
Nr

Ar dad
Rta
ord

Ce . Ca
de nibili
.
tic

Nr ulo-
Nr

Ar
rtif
sw

De ic. /

o.
tíc
o
le
po

. C ro
s

tal

Ca ant
pa

Art
Dis

Art talle

te

r ro
r
De
,

C
gin

-O
ic.
Lo

rde
/

n/
1.1.7
1.1.6 1.1.5 1.1.3
Valida Cliente
Reserva de Artículos Obtiene Detalle de Procesa Compra
Artículos (Genera OC y carro
virtual)
Info. Stock

Orden de Compra
Certif. del Cliente

Ce . Ca
Nr
rtif rro
Datos Cliente

o
.C
Artíc

Artículos

te
ulos
Reserva

DAO – Catalogo de Carro Virtual - Archivo

DAO – Stock de DAO – Catalogo de Ordenes de Compra Temporal
DAO – Clientes Artículos en Bodega Artículos Ofrecidos
Arquitecturas de Dominio Específico
 Arquitecturas de Dominio Específico
• Son modelos de arquitectura los cuales son específicos para
algún dominio de aplicación.

• Dos tipos de modelos de dominio específico son:

– Modelos Genéricos. Estos son abstracciones de un número de
sistemas reales y que encapsulan las características principales de
estos sistemas.
– Modelos de Referencia. Estos son más abstractos, son modelos
idealistas. Proporcionan un significado de información con respecto
a sistemas de clases y comparación de diversas arquitecturas.

• Los modelos genéricos usualmente surgen de manera bottom-

up… surgen de la práctica.

• Los modelos de referencia son modelos top-down … surgen de

estudios teóricos muy profundos.
 Modelos Genéricos (1)
• Un modelo de Compilador es un ejemplo conocido a
través de otros modelos que existen en dominios de
aplicaciones especializadas:

– Analizador Léxico

– Tabla de Símbolos

– Analizador de Sintáxis

– Analizador Semántico

– Generador/Optimizador de Código

• Un modelo de compilador genérico puede ser

organizado de acuerdo a diversos modelos de
arquitectura.
 Modelos Genéricos (2)
Tabla de
Símbolos

Analizador Analizador Analizador Generación

Léxico Sintáctico Semántico de Código

Ejemplo: Modelo de un Compilador

 Modelos Genéricos (3)

Analizador Analizador Analizador

Léxico Sintáctico Semántico

Arbol de Sintaxis Definición de la

Impresor Optimizador
Abstracto Gramática

Tabla de Definición de la
Símbolos Salida Generador de
Editor Código
Repositorio

Ejemplo: Sistema de Procesamiento de un Lenguaje

Arquitecturas de Referencia
 Arquitecturas de Referencia (1)

• Los modelos de referencias son derivados del

estudio del dominio de una aplicación, en
lugar del estudio de sistemas existentes.

• Pueden ser utilizados como una base para… la

implementación de un sistema o para comparar
sistemas diversos.

• Actúan como un estándar, contra el cual los

sistemas que pueden ser evaluados.

• El modelo OSI es un modelo en capas para

sistemas de comunicación, y además, es un modelo
de referencia.
 Arquitecturas de Referencia (2)
7 Aplicación Aplicación

6 Presentación Presentación

5 Sesión Sesión

4 Transporte Transporte
Red
3 Red Red
Liga de Datos
2 Vínculo de Datos Vínculo de Datos
Físico
1 Físico Físico

Medio de Comunicación

Ejemplo: Modelo de referencia OSI

Arquitecturas de Referencia (2)

7 Aplicación

6 Presentación

5 Sesión

4 Transporte

3 Red
2 Vínculo de Datos

1 Físico

Ejemplo: Modelo de referencia OSI

¿Para qué sirven los Modelos Genéricos y los
de Referencia?

• Para no reinventar la rueda

• Para generar Líneas (Familias) de Productos de Software
 Resumen (1)
• La arquitectura de software es la responsable de la
derivación de un modelo de sistema estructural, un
modelo de control y un modelo de descomposición en
subsistemas.
• Los sistemas grandes rara vez conforman un modelo
simple de arquitectura.
• Los modelos de estructuración de un sistema incluyen
modelos repositorios, los modelos cliente-servidor y los
modelos de máquina abstracta.
• Los modelos de control incluyen control centralizado y
modelos manejadores de eventos.
• Los modelos de descomposición modular incluyen los
modelos orientados a objetos y los modelos de flujo
de datos.
 Resumen (2)

• Los modelos de dominio

específico son
abstracciones sobre el
dominio de una aplicación.

• Estos pueden ser

construidos mediante la
abstracción de sistemas
existentes o pueden estar
basados en modelos de
referencia (ideales).
 Recomendaciones Generales
• Desempeño (performance).
– Si el desempeño es un requisito crítico, la arquitectura debe estar
diseñada para albergar las operaciones críticas, dentro de un número
reducido de subsistemas y evitar (reducir el número de) cambios de
estado.
– Ojalá con poca comunicación entre estos subsistemas.
– Esto significa utilizar componentes de grano grueso, de esa
manera habrá menos componentes en el sistema.

• Seguridad.
– Si la seguridad es un requisito crítico, se debe utilizar una
arquitectura estratificada (por capas).
– Los recursos más críticos deben alojarse en las capas más internas.
– Cada capa debe proveer un mecanismo de validación, de acuerdo a la
información que ésta maneja.
 Recomendaciones Generales

• Protección.
– Si la protección es un requisito crítico, la arquitectura debe
estar diseñada de tal forma que las operaciones relacionadas
con la protección, se localicen en único subsistema o en
un conjunto muy reducido de estos.
– Esto reduce los costos y los problemas de validación, y hace
posible crear sistemas de protección relacionados.

• Disponibilidad.
– Si la disponibilidad es un requisito crítico, como parte de la
arquitectura se deben incluir componentes redundantes.
– Estos podrán reemplazar a los componentes con problemas,
en caso de fallas.
 Recomendaciones Generales

• Mantenibilidad.
– Si la mantenibilidad es un requisito crítico, la arquitectura debe
estar diseñada utilizando componentes autocontenidos de
grano fino.
– Estos componentes pueden ser módulos o componentes de
software bien definidos.
– Estos podrán cambiarse o reemplazarse con facilidad, y con un
mínimo efecto sobre el resto del sistema.
– Los productores de datos deben estar separados de los
consumidores.
– Las estructuras de datos compartidas deben evitarse.
– La circulación de órdenes de control entre módulos o
subsistemas, también debe evitarse.
 Ejercicio 1
• Diseñe la estructura estática y la dinámica de un Chat.

• ¿Qué implicancias tendría en el diseño, el hacer un chat con

persistencia o sin persistencia?
 Ejercicio 2
• Qué pasaría si fuera un foro de discusión?? …. Diseñe la
estructura estática y la dinámica.