Diseo

Arquitectnico
Ing. Daniela Oyola

3k2 3k6
Recordemos algunos conceptos:
La Arquitectura se define como la organizacin
fundamental de un sistema, incluyendo sus
componentes, las relaciones entre ellos y el entorno, y los
principios que gobiernan su diseo y evolucin (ANSI /
IEEE Std 1471 2000) (repasar el concepto de arquitectura segn PUD)

El proceso de diseo inicial para identificar estos

subsistemas y establecer un marco de trabajo para
control y comunicacin de los subsistemas se llama
Diseo Arquitectnico (Ian Sommerville)
Revisa y negocia los requerimientos
Documentar la Arquitectura
Comunica la arquitectura, asegurndose que los
involucrados comprendan.
Direcciona requerimientos no funcionales a la
arquitectura
Configura la arquitectura de hardware
Se asegura que la arquitectura es respetada
Trabaja con el Administrador del Proyecto, ayudando en
la planificacin, la estimacin la distribucin de tareas y
la calendarizacin del proyecto.
Modelado de la Arquitectura
El modelo arquitectnico mapea los
requerimientos funcionales del anlisis a
una arquitectura tecnolgica.
Debe tratar con los requerimientos no
funcionales.
No existe la solucin perfecta, el
modelado arquitectnico debe escoger la
solucin ptima para el conjunto de
circunstancias existentes.
Modelado de la Arquitectura
Debe considerar informacin sobre:
Volmenes de Datos.
Funcionalidad ms demandada en el negocio.
Distribucin geogrfica.
Distribucin del Procesamiento de datos.
Dnde se guardarn los datos.
Cules procesos se ejecutarn en qu
procesadores y que tanta comunicacin se
requerir entre ellos.
Salidas del Modelo Arquitectnico
Distribucin geogrfica de los requerimientos de computacin.
Componentes de hardware para las mquinas clientes y para los
servidores.
Configuracin y cantidad de niveles de hardware.
Mecanismos y lenguajes de comunicacin de la red.
Sistema Operativo.
Paradigma de Desarrollo.
Lenguaje de Presentacin (Front end)
Lenguaje de fondo (back end)
Sistema de Administracin de Base de Datos.
Ubicacin/nes de los procesos.
Ubicacin/nes de los datos fsicos.
Estrategias de sincronizacin de los datos distribuidos fsicamente.
 Niveles de Abstraccin de la
Arquitectura
Arquitectura en pequeo: se interesa por la
arquitectura de programas individuales.
Como un programa se separa en componentes
Arquitectura en grande: arquitectura de
sistemas empresariales complejos que incluyen
sistemas, programas y componentes.
Estos sistemas son distribuidos en diferentes
computadoras, que diferentes compaas administran.
Determinar requerimientos
significativos
Antes que la solucin arquitectnica sea diseada es
necesario tener una buena idea de los requerimientos para
la arquitectura de la aplicacin, para ello debemos:

1. Identificar requerimientos significativos.

2. Priorizar los requerimientos significativos
para la arquitectura.
Identificar requerimientos significativos:

Las principales fuentes para los requerimientos de

arquitectura son:
El documento de requerimientos funcionales
Otros documentos que capturan diversas necesidades
de los stakeholders (atributos de calidad y
requerimientos no funcionales)
Determinar requerimientos significativos
Priorizar los requerimientos de arquitectura:
Es muy raro que todos los requerimientos de
arquitectura de una aplicacin sean iguales.
Frecuentemente la lista de requerimientos contiene
items que son de prioridad baja o caractersticas del
tipo sera bueno tenerla pero no necesario.
En consecuencia, es importante identificar
explcitamente estos casos y clasificar los
requerimientos en funcin de su prioridad.
Inicialmente, es suficiente ubicar cada requerimiento
en una de estas tres categoras:
Alta
Media
Baja
Priorizacin de Requerimientos
Arquitectnicos
Inicialmente es suficiente ubicar los requerimientos en
tres categoras
Alto: la aplicacin debe soportar este requerimiento.
Conducen el diseo de arquitectura.
Medio: necesitar ser soportado en alguna etapa, pero
no necesariamente en el primer release.
Bajo: estos son parte de la lista de deseos. Las
soluciones que los incluyen son deseables, pero no son
conductores del diseo.
La priorizacin es engaoso dado que los requerimientos
entran en conflicto entre s.
Disear la Arquitectura
Si bien todas las tareas para realizar la
arquitectura son importantes, lo que
realmente importa es la calidad del diseo
de la arquitectura.
Los buenos arquitectos son resultado de
muchos aos de ingeniera de software y
experiencia en diseo.
En la siguiente figura se muestran las
entradas y salidas de la actividad de
diseo de la arquitectura.
Proceso del diseo arquitectnico
Qu decisiones se toman cuando se
disea la arquitectura?
1. Existe alguna arquitectura de aplicacin genrica que acte
como plantilla?
2. Cmo se distribuir el sistema a travs de ncleos o
procesadores?
3. Qu patrones o estilos arquitectnicos pueden usarse?
4. Cul es el enfoque fundamental usado para estructurar el
sistema?
5. Cmo los componentes estructurales en el sistema se
separarn en subcomponentes?
6. Qu estrategia se usar para controlar la operacin de los
componentes en el sistema?
7. Qu organizacin arquitectnica es mejor para cumplir con
los requerimientos no funcionales del sistema?
8. Cmo se evaluar el diseo arquitectnico?
9. Cmo se documentar la arquitectura del sistema?
Proceso del diseo arquitectnico
 La mayora de las aplicaciones responden a un
pequeo nmero de arquitecturas probadas y
bien comprendidas.
Utilizar soluciones conocidas minimiza los
riesgos.
No hay una frmula mgica para disear un
framework de arquitectura.
Un pre-requisito: conocer los patrones
arquitectnicos principales para abordar ciertos
atributos de calidad.
Existen para distintos niveles de solucin.
Patrones de bajo nivel y detallados: idiomas
Patrones de nivel medio: patrones de diseo
Patrones de alto nivel: arquitectnicos

Un patrn arquitectnico es una descripcin de una

organizacin del sistema. Se puede considerar como una
descripcin abstracta utilizada de buena prctica que se
ensay y se puso a prueba en diferentes sistemas y
entornos.
 Un patrn arquitectnico es una descripcin de
una organizacin del sistema, cubre las
preguntas 4 a 6 anteriores:
Debe elegirse la estructura ms adecuada para
satisfacer los requerimientos.
Descomponer las unidades del sistema estructural
separando los componentes en subcomponentes.
Finalmente en el proceso de modelado de control se
toman decisiones sobre cmo se controla la ejecucin
de componentes, desarrollando un modelo general de
las relaciones de control sobre las diferentes partes
del sistema.
Eleccin de la estructura
La arquitectura del sistema afecta a:
La robustez
El desempeo
La mantenibilidad del sistema
por lo tanto

El estilo particular y la estructura elegida para

una aplicacin pueden depender de los
requerimientos no funcionales del sistema.
Ver cmo impacta los
Requerimientos No Funcionales en
la eleccin de la estructura (ver
presentacin)
Eleccin de la estructura
Puede existir conflicto potencial entre algunas de
estas arquitecturas
Por ej. el desempeo se mejora utilizando
componentes de grano grueso y el mantenimiento con
componentes de grano fino
Si ambos son requerimientos importantes, se debe
encontrar una solucin mediadora.
No hay una solucin perfecta, se busca la forma
ms apropiada en base a los requerimientos y a
las limitaciones que se nos dan.
 La distincin no es tajante y existen ejemplos
donde es difcil distinguirlos. A veces se los ve
como sinnimos.
Los patrones estn en una escala menor que los
estilos. Mltiples patrones pueden aparecer en
un mismo diseo.
En contraste, un sistema usualmente, tiene un
nico estilo arquitectnico dominante.
Eleccin de Patrones arquitectnicos
Patrones arquitectnicos
Arquitectura en Capas (Layered style/N-tier)
Las propiedades clave de este patrn son:
Separacin de intereses: La funcionalidad del
sistema est organizada en capas separadas y cada
una se apoya slo en los servicios ofrecidos por la
capa ubicada debajo de ella.
Soporta desarrollo incremental: A medida que se
desarrolla una capa, las funcionalidades suminis-
tradas por la misma quedan a disposicin.
Cambiable y porttil: En tanto su interfaz no vare,
una capa puede sustituirse por otra equivalente. Si
se cambia la interfaz o se agregan nuevas
funcionalidades a una capa, slo se ven afectadas
las capas adyacentes.
Arquitectura en Capas (Layered style)
Descripcin del patrn: Organiza el sistema en capas
con funcionalidad relacionada con cada capa. Una
capa da servicios a la capa de encima (capas de nivel
inferior servicios ncleo).
Cundo se utiliza?
Al construirse nuevas facilidades sobre sistemas
existentes.
Cuando el desarrollo se distribuye a travs de
distintos equipos de trabajo (cada uno
responsable de una capa de funcionalidad).
Cuando existe un requerimiento de seguridad
multinivel.
Arquitectura en Capas (Layered style)
Esquemas genricos
Interfaz de Usuario
Capa de Presentacin

Gestin de Interfaz de Usuario

Capa de Lgica de Negocio Autenticacin y autorizacin

Lgica de Negocio/
Capa de Administracin
Funcionalidad de la aplicacin
de datos

Soporte del sistema

(SO, base de datos, etc)
Arquitectura en Capas (Layered style)
Esquemas genricos
Web Web Web
Client Client Client

Web
Server

Application
Server

Databases
Arquitectura en Capas (Layered style)
Ventajas:
Modificabilidad: Permite la sustitucin de capas
completas en tanto se conserve la interfaz.
Permite aumentar la confiabilidad incluyendo
facilidades redundantes en las capas-
Portabilidad
Reusabilidad
Desventajas:
Difcil hacer separacin limpia entre capas.
El rendimiento se afecta por los mltiples niveles
de interpretacin.
Arquitectura en Capas (Layered style)
Ejemplos: Sistema de Biblioteca LIBSYS
(Permite el acceso electrnico controlado a material con derechos de
autor de un conjunto de bibliotecas universitarias)

Interfaz de Navegador Web

Gestor formatos y
Conexin LIBSYS Gestor Impresin
consulta

Bsqueda Recuperacin Gestor de

de Documentos Contabilidad
distribuida derechos

ndice de Biblioteca

Bases de datos de Biblioteca

DB1 DB2 DB3 DB4 DB5
Arquitectura en Capas (Layered style)
Ejemplo:
Sistema: Gestin de Tasa Comercio e Industria Municipal

Cliente Cliente Atencin Direccin de Procuracin

Capa Cliente Web
Web al pblico Rentas Fiscal
(Presentacin)

Capa de Servidor Web

Servicios Web

Capa de lgica de Servidor de Aplicaciones del Municipio

Negocio

Capa de
Administracin Servidor de Bases de Datos del Municipio
de datos
Arquitectura de Repositorio
(Modelo Centrado)
La mayora de los sistemas con grandes
cantidades de datos se organizan sobre una base
de datos o repositorio compartido.
Es un modelo adecuado para aplicaciones en que
un componente genere datos y otro los use.
Tambin se lo conoce como Modelo Centrado
(model-centered) y describe una arquitectura en
la cual componentes independientes
interactan con un modelo central, en lugar de
interactuar con cada uno de los otros.
Arquitectura de Repositorio (Modelo Centrado)

Descripcin del patrn: Todos los datos del sistema se

gestionan en un repositorio central, accesible a
todos los componentes del sistema.
Cundo se utiliza?
Cuando el sistema maneja grandes volmenes de
informacin que deben almacenarse durante
mucho tiempo.
En sistemas dirigidos por datos, en los que la
inclusin de datos en el repositorio active una
accin o herramienta.
Ejemplos: Sistemas de comando y control,
sistemas de informacin administrativa, etc.
Arquitectura de Repositorio (Modelo Centrado)

Ventajas:
Los componentes pueden ser independientes.
Los cambios hechos por un componente se pueden
propagar a los dems.
Se puede gestionar de manera consistente la
totalidad de los datos.
Desventajas:
El repositorio es un punto de falla nico; los
problemas en el repositorio afectan a todo el
sistema.
Puede haber ineficiencias al organizar toda la
comunicacin a travs del repositorio.
Puede ser difcil distribuir el repositorio en varias
computadoras.
Arquitectura de Repositorio (Modelo Centrado)

Ejemplo: Arquitectura para un IDE (Entorno de

Desarrollo Integrado)

Editores Generadores
UML de cdigo

Traductor Repositorio Editor de

de Diseo del proyecto Programa

Analizador Generador
de Diseo de Reportes
Patrones arquitectnicos
Arquitectura MVC(Modelo-Vista-Controlador)
Descripcin: Separa presentacin e interaccin de los
datos del sistema. El sistema se estructura en tres
componentes lgicos que interactan entre s:
Modelo: Maneja los datos del sistema y las operaciones
asociadas a esos datos.
Vista: Define y gestiona cmo se presentan los datos al
usuario.
Controlador: Dirige la interaccin del usuario y pasa esas
interacciones a Vista y Modelo.
Cundo se utiliza?
Se usa cuando existen mltiples formas de ver e
interactuar con los datos.
Cuando se desconocen los requerimientos futuros
para la interaccin y presentacin.
Arquitectura MVC(Modelo-Vista-Controlador)

Esquema genrico

Es un ejemplo de arquitectura de modelo centrado

(repositorio):
Un componente modelo
Un componente que recibe notificaciones de
actualizaciones del modelo: vista
Un componente que actualiza el modelo: controlador
Un componente que hace ambas cosas: vista/controlador
Arquitectura MVC(Modelo-Vista-Controlador)

Ventajas:
Permite que los datos cambien independiente-
mente de su representacin y viceversa.
Soporta en diferentes formas la presentacin de
los mismos datos.
Los cambios en una representacin se muestran
en todos ellos.
Desventajas:
Puede implicar cdigo adicional y complejidad en
el cdigo cuando el modelo de datos y las
interacciones son simples.
Ver el material sobre los siguientes patrones arquitectnicos:
PATRN MESSAGING
PATRN PUBLISHE SUSCRIBE
PATRN BROKER
PATRN PROCESS COORDINATOR
Ejemplo del PATRN MESSAGING
 PATRN PUBLISHE SUSCRIBE
Componentes independientes publican eventos y se suscriben a ellos
Ejemplo del PATRN PUBLISHE
SUSCRIBE
Ejemplo del PATRN BROKER
Ejemplo del PATRN PROCESS
COORDINATOR
Arquitectura Tubera y Filtro (Pipe
& Filter)
El procesamiento de datos se organiza de forma que cada
componente de procesamiento (filtro) sea discreto y realice
un tipo de transformacin de datos. Los datos fluyen (como en
una tubera) de un componente a otro para su procesamiento.
La caracterstica clave es que la red completa de tuberas y
filtros est continua e incrementalmente procesando datos.
Aplica a elementos de tiempo de ejecucin, es parte de la
vista de ejecucin (runtime)
Se utiliza en aplicaciones de procesamiento de datos (tanto
basadas en lotes [batch] como en transacciones) donde las
entradas se procesan en etapas separadas para generar
salidas relacionadas. Tambin puede usarse en software
embebido.
Arquitectura Tubera y Filtro (Pipe
& Filter)
Esquema:

La arquitectura tubera y filtro consta de cuatro

elementos: tuberas, filtros, puertos de lectura y puertos
de escritura.
Un filtro lee desde uno o ms puertos de entrada, realiza
algn procesamiento y escribe la salida en uno o ms
puertos de salida.
En una red pipe & filter lineal los datos fluyen desde un
origen a travs de los filtros hasta llegar al final.
Los datos fluyen en una direccin y los loops usualmente
estn prohibidos.
Requiere filtros independientes que no interactan entre
s y no pueden compartir estados entre s. Slo lo hacen
a travs de los filtros.
Un filtro no puede hacer asunciones respecto de los que
pasa hacia arriba o hacia debajo de la cadena.
El estilo soporta concurrencia.
Arquitectura Tubera y Filtro (Pipe & Filter)

Ventajas:
Fcil de entender y soporta reutilizacin de
transformacin
El estilo de flujo de trabajo coincide con la estructura
de muchos procesos de negocio.
La evolucin al agregar transformaciones es directa.
Puede implementarse como un sistema secuencial o
como uno concurrente.
Desventajas:
El formato para la transferencia de datos debe
acordarse entre las transformaciones que se
comunican.
Esto aumenta la carga del sistema y puede significar
que sea imposible reutilizar transformaciones
funcionales que usen estructuras de datos
incompatibles.
Arquitectura Lote-Secuencial
(Batch-Sequential)

Los datos fluyen de una etapa a otra y es procesado

incrementalmente.
A diferencia del Pipe & Filter cada etapa completa
todo su procesamiento antes de escribir su salida.
Los datos fluyen entre etapas en una cadena, pero
es ms comn escribir en un archivo o disco.
Los componentes de procesamiento son llamados
con diferentes nombres: etapas o pasos. No hay un
nombre estndar para los conectores entre etapas.
Una tarea simple que fluye a travs de un sistema
batch-sequential es llamada batch (lote) o job
(trabajo).
 Esquema:

Cada etapa lee su entrada completa y escribe su salida completa de

una vez, no incrementalmente. En consecuencia, cada etapa se
ejecuta en secuencia.
Arquitectura Lote-Secuencial
(Batch-Sequential)
Ventajas:
Modificabilidad, dado que cada etapa es
independiente de las otras.
Son conceptualmente ms simples ya que slo una
etapa se est ejecutando en un momento dado.
Pueden tener un mayor rendimiento.
Desventajas:
La salida final de un sistema batch-sequential estar
ausente o plenamente disponible lo cual tendr un
impacto en la usabilidad de un sistema.
Ofrece menos oportunidades para la concurrencia
dado que las etapas no pueden ejecutarse en paralelo
a menos que mltiples trabajos (jobs) estn fluyendo a
travs del sistema.
Un sistema distribuido es ..una coleccin de
computadoras independientes que aparecen al usuario
como un solo sistema coherente.. (Tanenbaun y Van
Steen -2007)
Virtualmente todos los sistemas grandes basados en
computadoras son ahora sistemas distribuidos.
El procesamiento de informacin est distribuido en
varias computadoras en lugar de confinarse a una nica
mquina.
 Tipos de Sistemas
Sistemas Personales: no son distribuidos y han sido
diseados para ejecutarse en una computadora
personal o estacin de trabajo.
Sistemas Embebidos: se ejecutan en un nico
procesador o en un grupo integrado de procesadores.
Sistemas Distribuidos: donde el sistema de software se
ejecuta en un grupo de procesadores cooperativos
integrado conectados por una red.
Caractersticas de los Sistemas Distribuidos

Comparticin de Recursos: recursos de hardware y software

asociados por una red.
Apertura: son abiertos, se disean sobre protocoles estndar que
combinan equipamiento y software de diferentes vendedores.
Concurrencia: varios procesos operando al mismo tiempo sobre
diferentes computadoras de la red.
Tolerancia a Fallas: la disponibilidad de varios recursos y el
potencial para reducir informacin permite esta capacidad.
Escalabilidad: los sistemas pueden crecer incrementando recursos
para cubrir demandas nuevas. Tres dimensiones de la escalabilidad:
Tamao: debe ser posible agregar ms recursos. Expandir vs
Ampliar
Distribucin: dispersar los recursos sin reducir su rendimiento.
Manejabilidad: debe poder administrarse un sistema conforme
aumenta su tamao, incluso si partes del sistema se ubican en
organizaciones diferentes.
 (ver revisin hecha en clase)

Complejidad: los hace ms difciles de

comprender y probar.
Seguridad: dificulta asegurar la integridad y la
degradacin del servicio.
Manejabilidad: Los defectos pueden propagarse
de una mquina a otra, esto implica que es ms
difcil de gestionar y administrar.
Impredecibilidad: la respuesta depende de la
cargo total en el sistema, de la organizacin y de
la red.
Ataques de los que deben defenderse los
Sistemas Distribuidos
Intercepcin: un atacante intercepta comunicaciones
entre partes del sistema, para que haya poca
confidencialidad.
Interrupcin: los servicios son atacados y no pueden
entregarse como se esperaba. Implica bombardear el
servicio con peticiones ilegtimas para que no pueda
atender las legtimas.
Modificacin: el atacante cambia los datos o el servicio
del sistema.
Fabricacin: el atacante genera informacin que no
debe existir y luego la usa para conseguir ciertos
privilegios.
 Interaccin Procedimental: una computadora solicita un
servicio conocido a otra computadora y espera a que la
otra computadora le responda.
Normalmente se implementa con RPC (Remote
Procedure Calls).
Interaccin Basada en Mensajes: la computadora
emisora define en un mensaje la informacin y lo enva a
otra computadora. No es necesario esperar la respuesta.
Normalmente se implementa con un componente que
crea un mensaje.
 Software que administra y soporta diferentes
componentes de un sistema distribuido. En esencia, se
sita en el medio del sistema.
Middleware es usualmente off-the-shelf (enlatado) en
lugar de software escrito a medida.
Ejemplos
Monitores de Procesamiento de Transacciones
Conversores de Datos
Controladores de Comunicacin
 En un sistema distribuido, por lo general brinda dos
tipos de soporte:
Soporte de Interaccin: coordina interacciones entre
diferentes componentes del sistema. Puede soportar
conversin de parmetros si se usan lenguajes de
programacin diferentes.
Provisin de Servicios comunes, por ejemplo:
Servicios de Seguridad (autenticacin y autorizacin)
Servicios de Notificacin y Nomenclatura
Servicios de Gestin de Transaccin
Eleccin de Patrones arquitectnicos
Arquitectura Maestro-esclavo (Master-Slave)

Se usan comnmente en sistemas de tiempo real donde

es importante cumplir con los tiempos de
procesamiento.
El proceso maestro es por lo general el responsable de
la computacin, coordinacin y comunicacin y controla
los procesos esclavos.
Los procesos esclavos se dedican a acciones
especficas, como adquisicin de datos de sensores.
Se usa cuando es posible predecir el procesamiento
distribuido que se requiere y cuando se puede asignar
fcilmente el procesamiento a los procesadores esclavos.
 Arquitectura Maestro-esclavo (Master-Slave)
Sistema de Control de Trfico Multiprocesador

Procesador
Sensor Traffic flow
Procesador Traffic light de
Procesador control
deprocessor
Sensor de processor
Sala de control Controlprocessor
de Semforos

Proceso Proceso
de
Sensor de Light
Proceso
Control Display
Coordinacin control
controlde yprocess
Despliegue
de
Sensor
processes process
Control
de Luces

Maestro
Esclavo Esclavo

Sensores y Cmaras Traffic lights

Semforos
Traffic flow
de Flujo sensors
de Trfico
and cameras Operator consoles
Consolas de Operador
 La aplicacin es modelada como un conjunto de
servicios que son provistos por servidores y un conjunto
de clientes que usan esos servicios.
Los clientes conocen a los servidores y deben saber
cmo buscarlos, pero los servidores no necesitan
conocer a los clientes.
Clientes y Servidores son procesos lgicos.
Los clientes inician la comunicacin.
Los servidores no conocen la identidad de los clientes
hasta que se han contactado.
 Descripcin: En una arquitectura cliente-servidor la
funcionalidad del sistema se organiza en servicios, y
cada servicio entrega un servicio independiente. Los
clientes son usuarios de dichos servicios y para
utilizarlos ingresan a los servidores.
Cuando se utiliza:
Cuando desde varias ubicaciones se tiene que
ingresasr a los datos en una base de datos
compartida.
Cuando la carga de un sistema es variable, ya que
los servidores se pueden replicar.
 Como los servidores se pueden replicar, se usa
cuando la carga de un sistema es variable
Si bien es una arquitectura distribuida, puede
implementarse tambin en una sola
computadora.
Es parte de la vista de ejecucin (runtime).
El uso ms comn es para explotar la capacidad
grfica de la PC y al mismo tiempo proteger los
datos en un host central.
 Esquema:

Caso de un servidor conectado con dos clientes. Los clientes

pueden iniciar la comunicacin pero no el servidor. El servidor no
conoce la identidad de los clientes hasta que se conectan.
 Variantes:
Los conectores pueden ser sincrnicos o asincrnicos.
Puede haber lmites en el nmero de clientes o servidores.
Las conexiones pueden ser con o sin estado (sesiones).
La topologas del sistema puede ser esttica o dinmica.
Una variante permite al servidor, luego de que el cliente
establezca contacto por primera vez, enviarle actualizaciones
posteriores.
Otra variante es el estilo N-Capas (N-Tier) que utiliza dos o ms
instancias del estilo Cliente-Servidor para formar una serie de
capas.
Los pedidos fluyen en una nica direccin
Las capas tienen responsabilidades funcionales exclusivas
Arquitectura Cliente-Servidor
Ventajas:
La principal ventaja es que los servidores se
pueden distribuir a travs de una red.
La funcionalidad general est disponible para
todos los clientes, asique no necesita
implementarse en todos los servicios.
Es fcil agregar un nuevo servidor e integrarlo o
actualizar los servidores sin afectar las otras partes
del sistema.
Aprovecha la disponibilidad de redes cada vez ms
veloces.
Arquitectura Cliente-Servidor
Desventajas:
Cada servicio es un solo punto de falla susceptible
a ataques de rechazo de servicio o fallas del
servidor.
El rendimiento es impredecible porque depende
de la red as como del sistema.
No existe un modelo compartido de datos, lo que
complica las tareas de administracin de datos,
respaldo y recuperacin.
Arquitecturas Cliente Servidor & N-Tier
 C/S y su distribucin en el Software

c2 c3 c4 c12
c11
Server process
c1
s1 s4

c10
c5
Client process
s2 s3 c9

c6 c8
c7
C/S y su distribucin en el Hardware
 Hardware: Arquitectura C/S de dos Niveles

Servidor
Central
on on on on on on on
si si si si si si si
er er er er er er er
V V V V V V V
L L L L L L L
IA IA IA IA IA IA IA
TR TR TR TR TR TR TR
d d d d d d d
re re re re re re re
te te te te te te te
is is is is is is is on on on on on on on
eg eg eg eg eg eg eg si si si si si si si
nr nr nr nr nr nr nr er er er er er er er
V V V V V V V
-U -U -U -U -U -U -U L L L L L L L
51 51 51 51 51 51 51 IA IA IA IA IA IA IA
3. 3. 3. 3. 3. 3. 3. TR TR TR TR TR TR TR
A A A A A A oAn on on d on d on d on d on d d d
E E E E E E sEi si s i re s i re s i re s i re s i re re re
er er e r e e r e er e er e er e te te
V V V g i s t V g i s t V g i st V g i s t V g i s t is is
L L L Ln Ln Ln Ln n g n g n
IA IA I A n r eI As io n r eIAs io n r eIAs io n r eI As io n re s io n r e s io n r e s io
TR TR T R - U T Re r - U T Re r - U T Re r - U T Re r - U e r - U e r - U e r
Mltiples
d d d Clientes d V d V d V d V V V V
re re re 5 1re L 5 1re L 5 1r e L 5 1re L 5 1 L 5 1 L 5 1 L
te te t e 3 . te I A 3 . t e I A 3 . t e I A 3 . t e I A 3 . IA 3 . I A 3 . I A
is is is A is R A is R A is R A is R A R A R A R
eg eg eg E eg T E eg T E eg T E eg T E d T E d T E d T
nr nr nr n rr e d n rr e d n rre d n rre d re re re
-U -U -U - Uste - Uste - Ust e - Uste
i i i i st
e
st
e
is
te
51 51 51 5 1e g . 5r1e g .5r1e g .5r1e g gi gi eg
3. 3. 3. 3. r
n 3 n 3 n 3 n n re n re nr
A A A AU AU AU AU U U -U
E E E E- E- E- E- - -
51 51 51 51 51 51 51
3. 3. 3. 3. 3. 3. 3.
A A A A A A A
E E E E E E E
 Hardware: Arquitectura C/S de tres Niveles

Servidor
Central
de aplicaciones
Servidor

local
on on on on on on on
si si si si si si si
er er er er er er er
V V V V V V V
L L L L L L L
IA IA IA IA IA IA IA
TR TR TR TR TR TR TR
d d d d d d d
re re re re re re re
te te te te te te te on on on on on on on
is is is is is is is si si si si si si si
eg eg eg eg eg eg eg er er er er er er er
nr nr nr nr nr nr nr L
V
L
V
L
V
L
V
L
V
L
V
L
V
-U -U -U -U -U -U -U IA IA IA IA IA IA IA
51 51 51 51 51 51 n 51 n n TnR TnR TnR TnR TR TR TR
3. 3. 3. 3. 3. 3 . io 3 . io i o di o dio dio dio d d d

Mltiples
A rs A rs r s rers rers rers rers re re re

Clientes
A A A A A
E E E E E E Ve E Ve e e e e e tVee istnVee istne e te
L L L
V iLstnV iLstnV Lisn L istn isn
IA IA IA eIAsgio reIrAsgio reIrAsgio reIrAsgio rersgio rersgio rersgio
TR TR TR nRr r nR nR nR n n n
UTV e -dUTV e -dUTV e -dUTV e - UV e - UV e - UV e
ed ed ed e-dL eL eL eL L L L
er er er 5e1rIA 5e1rIA 5e1rIA 5e1rIA 51IA 51IA .5R1IA
ist ist ist 3is.tR 3s.tR
i 3is.tR 3is.tR 3. R 3. R 3
eg eg eg Ag T Ag T Ag T Ag T A T A T A T
nr nr nr Ereed Ereed Ereed Ereed Eed Ee d Ee d
enr enr ner ner er er er
-U -U -U - sUt - sUt - Ust - Ust st st ist
gi gi gi gi gi gi eg
51 51 51 5r1e 5r1e 5r1e 5r1e re re
3. 3. 3. 3n. 3.n 3 .n 3 .n n n nr
A A A AU AU AU AU U U -U
E E E E- E- E- E- - -
51 51 51 51 51 51 51
3. 3. 3. 3. 3. 3. 3.
A A A A A A A
E E E E E E E
 de archivos
Servidores

locales
Hardware: Arquitectura C/S de n Niveles

on on on on on on on
si si si si si si si
er er er er er er er
V V V V V V V
L L L L L L L
IA IA IA IA IA IA IA
TR TR TR TR TR TR TR
d d d d d d d
re re re re re re re
te te te te te te te
is is is is is is is
eg eg eg eg eg eg eg
nr nr nr nr i o nr
n
i o nn r i o nn r i o n
i o n
i o n on
-U -U -U -U r s- U r-s U r-s U rs rs rs si
e e e e e e er
51 51 51 51 V1
5 V1
5 V1
5 V V V V
3. 3. 3. 3. L3 . L3 . L3 . L L L L
A A A A IAA IAA IAA IA IA IA IA
E E E E T RE T RE T RE T R T R T R TR
d d d d d d d

Servidor
Central
re re re re re re re
te te te te te te te
is is is is is is is
eg eg eg e gn e gn e gn e gn n n on
nr nr nr n r io n r io n r i o n r io io io si
rs rs rs rs rs rs er
-U -U -U - VUe -VUe - VUe - VUe V
e
V
e
V
51 51 51 5 1L 5 1L 5 1L 5 1L L L L
3. 3. 3. 3 .I A 3 .I A 3 . IA 3 . IA IA IA IA
A A A AR AR AR AR R R TR
E E E Ed T Ed T Ed T Ed T d
T
d
T
d
re re re re re re re
te te te te te te te
is is is is is is is
eg eg eg eg eg eg eg
nr nr nr nr nr nr nr
-U -U -U -U -U -U -U
51 51 51 51 51 51 on 51 on io
n
io
n
io
n
io
n
io
n
3. 3. 3. 3. 3. 3. rsi 3. rsi r s n r s n rs n rs n r s n
o o o o o o n on
A A A A A A e A e e i e i e i e i e i i si
E V E V V rs V rs V rs V rs V rs rs
E E E E E
L L L e L e L e L e L e e er
IA IA I AL V I AL V IAL V IAL V I AL V L
V
L
V
TR TR T RI A T RI A T RI A T RI A T RI A IA IA
d d d R d R d R d R d R R TR
re re r e T r e T r e T r e T re T T
te te te d te d te d t e d te d d d
is is is e r e is e r e is e r e is e r e is e r e r e re
eg eg e gist e gist e gist e gist e gist te te
is is
nr nr n re g n re g n re g n re g n re g eg eg
-U -U - Un r - Un r - Un r - Un r - Un r nr nr
U U U U U U -U
51 51 51 - 5 1 - .5 1 - .5 1 - .5 1 - -
3. 3. 1 3. 1
3. 3 1 3 1 3 1 51 51
A A .5 A .5 A .5 A .5 A .5
A 3. 3.
E E 3 E 3 E 3 E 3 E 3
E
 Distribucin de Software en Hardware
Modelo de Cliente Liviano
En un modelo de cliente liviano (delgado), todo el
procesamiento de la aplicacin y la administracin
de los datos es ejecutado en el servidor. El cliente
es responsable nicamente para la ejecucin de la
presentacin del software.
Modelo de Cliente Pesado
En este modelo, el servidor es nicamente
responsable de la administracin de los datos. El
software del cliente implementa la aplicacin lgica
y las interacciones con el usuario del sistema.
 Utilizado cuando sistemas legados son migrados
a arquitecturas cliente servidor.
El sistema legado acta como un servidor en s
mismo con una interfaz grfica implementada en el
cliente.
La principal desventaja es que tiene una carga
de procesamiento pesada tanto en el servidor
como en la red.
 Se delega ms procesamiento al cliente dado
que el procesamiento de la aplicacin es
ejecutado localmente.
Ms adecuado para sistemas de C/S nuevos
donde las capacidades del cliente son conocidas
de ante mano.
Ms complejo que un modelo de cliente liviano
especialmente para la administracin. Nuevas
versiones de la aplicacin deben ser instaladas
en todos los clientes.
 P r e se n ta t io n
S e r ve r
T h i n - c li e n t D a t a m a n a ge m e n t
m o del C l ie nt
A p pl i ca t io n
p ro c e ss in g

P r e se n ta t io n
A p pl i ca t io n pr o c e ss in g S e r ve r
F a t - c li e n t
m o del C l ie nt Data
m a na g e m e nt
Calidad Resultante:
Mejora la mantenibilidad: Soporta cambios en las
reglas de negocio, cambiando el servidor, en lugar
de hacerlo en mltiples clientes.
Control central ayuda a la evolucin del sistema.
Puede enmascarar sistemas legados y tratarlo como
servidor.
Este estilo es similar al de repositorio, slo que el de
repositorio tiene la restriccin de que los componentes
vista y controlador no interactan.
En la prctica los clientes rara vez interactan entre s,
pero el estilo no lo prohbe.
 Arquitecturas Peer-to-peer (p2p)
En este estilo los nodos se comunican entre s
como pares y las relaciones jerrquicas estn
prohibidas.
Cada nodo tiene la habilidad (no la obligacin)
de comportarse como cliente y como servidor.
El resultado es un conjunto de nodos operando
como pares donde cada nodo puede pedir o
proveer servicios a cualquier otro nodo.
 Arquitecturas Peer-to-peer (p2p)
No es obligacin que cada nodo se comunique
con cada uno de los otros nodos.
En un momento particular, un nodo usualmente
est conectado a un subconjunto de nodos, y
las conexiones se agregan y remueven con el
sistema en ejecucin.
Las redes p2p se usan para acceder a recursos
con copias redundantes ubicadas en mltiples
nodos.
 n4 n6
n8 n1 3

n7 n1 2
n2 n3
n1 3

n9 n1 0 n1 1

n1 n5
 Servidor
(superpar)

n4
n1
n3
n6
n5
n2
 Apropiado para el procesamiento de grandes
conjuntos de datos, tales como los motores de
bsqueda de Internet o las redes sociales.
Conceptualmente, simples programas deben
ejecutar poco a poco grandes conjuntos de datos
como si se hubiera utilizado una nica
computadora.
Dado que el riesgo de falla incrementa con la
cantidad de computadoras utilizadas, este estilo
permite recuperacin frente a fallas.
cmp MapReduce

:Master

Required Reduce Control Required Reduce Control

rWrite pRead
:MapWorker :LocalFS
pWrite :ReduceWorker
pRead
:MapWorker rWrite :LocalFS
pWrite
:ReduceWorker
:MapWorker rWrite
:LocalFS

pWrite pRead

Provided FS Read Provided FS write

:GlobalFS
 Los desarrolladores solo necesitan razonar sobre
la correccin de cmo cada mquina procesa un
nico fragmento de datos.
Se realiza mucho procesamiento paralelo que es
transparente para el desarrollador.
Solo debe asegurarse que cada trabajador (map
o reduce) implemente su funcin correctamente.
 Debe distribuirse los fragmentos equitativamente dado
que la performance general del sistema se degrada si
algn map worker se demora ms que otros.
Calidad Resultante:
Escalabilidad: si el programa se escribi para este estilo puede
correr en un cluster de una o mil mquinas.
Disponibilidad: se recupera de fallas re-agendando el trabajo a
otra mquina.
Performance: tareas pueden distribuirse en varias mquinas
Arquitecturas de Hardware

98
Eleccin de Patrones arquitectnicos
 Arquitectura Espejada (Mirrored)
En este estilo se duplica hardware idntico, que
corre en paralelo.
Generalmente opera en lock-step lo que
duplica el esfuerzo, pero si uno falla el otro
puede continuar por su cuenta.
El software puede actualizarse en forma
separada uno de otro.
La disponibilidad sube porque la probabilidad de
que ambas fallen simultneamente es baja.
 Arquitectura Rack
En este estilo los servidores se acomodan en pilas, para
utilizar menos espacio del piso.
Todas las computadoras de la pila se conectan con la
misma red.
La red en cambio puede tener varias conexiones a
Internet.
La conexin de red para el rack es a menudo ms rpida
o la restriccin de ancho de banda es menor, por lo que
la comunicacin entre computadores del mismo rack es
mucho ms rpida.
 Arquitectura Granja de Servidores (Server Farm)

En este estilo muchas computadoras (usualmente

idnticas) son ubicadas en la misma habitacin.
La interconexin de las computadoras puede variar y la
granja puede componerse de varios racks.
Se las piensa como un recurso masivo que puede alojar
cualquier aplicacin.
Las aplicaciones tienen restricciones para poder
ejecutarse en una granja, como no tener estado.
Es fcilmente escalable agregando ms hardware del
mismo tipo.
Usos comunes para las granjas: capa de interfaz de
usuario y capa intermedia en un sistemas de 3 capas
donde cada granja aloja una capa diferente.
Estilos Arquitectnicos: Resumen I
Estilos Arquitectnicos: Resumen II
Estilos Arquitectnicos: Resumen III
Estilos Arquitectnicos: Resumen IV
Proceso del diseo arquitectnico
 Ya se ha seleccionado el framework arquitectnico,
basado en uno o ms patrones arquitectnicos.
Seguidamente se deben definir los componentes
principales que comprendern el diseo.
El framework define comunicacin general para los
componentes, adems debe identificarse lo siguiente:
Componentes principales de la aplicacin y como se
insertan en el framework.
Servicios o interfaces que cada componente soporta.
Responsabilidades del Componente, definiendo que
ser invocado para hacer cuando reciba un pedido.
Dependencias entre componentes.
Particiones en la arquitectura que son candidatas para
distribucin entre servidores de la red.
 Minimizar las dependencias entre componentes.
Recordar: si lo cambias debes re-testearlo
Disear componentes que encapsulen un conjunto de
responsabilidades altamente cohesivas.
Esto limita los tipos de cambios y reduce esfuerzo de
mantenimiento y testing.
Aislar dependencias entre el middleware y cualquier COT de
infraestructura tecnolgica.
Es ms fcil de construir, pero introduce penalidades de
performance.
Utilizar la descomposicin para estructurar componentes
jerrquicamente.
Minimizar las llamadas entre componentes
Proceso del diseo arquitectnico
La salida del proceso de diseo
arquitectnico:
consiste en un MODELO ARQUITECTNICO
que describe la forma en que se organiza el
sistema como un conjunto de componentes en
comunicacin.
que describe cmo se estructura el sistema en
subsistemas y cmo cada subsistema se
estructura en mdulo (componente).
Sistema Subsistema Mdulo
Subsistema:
Es un sistema por s mismo cuya operacin no
depende de los servicios suministrados por otros
subsistemas.
Los subsistemas se componen de mdulos
(componentes) y tienen interfaces definidas que
se utilizan para la comunicacin con otros
subsistemas.
 Es un componente del sistema que suministra
uno o ms servicios a otros mdulos.
Utiliza los servicios suministrados por otros
mdulos (componentes).
No se considera un sistema independiente
Generalmente, los mdulos estn compuestos
de varios componentes simples del sistema.
La Arquitectura de Software es un artefacto de diseo
complejo por eso, como la mayora de los artefactos
complejos, hay varias formas de visualizar y comprender
una arquitectura.
El trmino Vistas de la Arquitectura fue introducido
por Philippe Krutchen en 1995 en su publicacin: The
4+1 View Model of Sotware Architecture (IEEE Sotware,
Nov. 1995)
Vistas de UML 2
Vistas en el PUD
Cuntas Vistas?

Modelos simplificados para mostrar el contexto

No todos los sistemas requieren todas las vistas:
Procesador nico: saltear la vista de despliegue
Procesos Simples: saltear vista de proceso
Programas muy pequeos: saltear la vista de implementacin.
Otras Vistas que se pueden agregar:
Vista de los datos, vista de seguridad
Vistas de la Arquitectura
Vistas 4 + 1 - Philippe Krutchen
La publicacin de Krutchen presenta una forma de describir y
comprender la arquitectura basada en las siguientes cuatro
vistas:
Vista Lgica
Vista de Procesos
Vista Fsica
Vista de Desarrollo
Vistas de la Arquitectura
Vistas 4 + 1 - Philippe Krutchen
Vista Lgica: Describe los elementos significativos
arquitectnicamente y las relaciones entre ellos.
Esencialmente captura la estructura de la aplicacin
utilizando diagramas de clases o equivalentes.
Vista de Procesos: Se enfoca en describir la concurrencia
y elementos de comunicacin de una arquitectura. El
inters principal en esta vista es decribir los
componentes multi-threaded (multi-hilos) o replicados
y los mecanismos de comunicacin sincrnos y
asncronos utilizados.
Vistas de la Arquitectura
Vistas 4 + 1 - Philippe Krutchen
Vista Fsica: Describe cmo se mapean los principales
procesos y componentes en los nodos de hardware.
Podra mostrar, por ej., cmo los servidores Web y de
Base de Datos para una aplicacin son distribuidos a
travs de un nmero de equipos servidores.
Vista de Desarrollo: Captura la organizacin interna de
los componentes de software, tpicamente cmo estn
contenidos en un entorno de desarrollo o una
herramienta de gestin de la configuracin. Por ej. la
descripcin de un paquete anidado y una jerarqua de
clases para una aplicacin Java representara la vista de
Desarrollo de una arquitectura.
Vistas de la Arquitectura
Vistas 4 + 1 - Philippe Krutchen
Estas cuatro vistas estn unidas por los casos de uso
arquitectnicamente significativos.
Estos casos de uso bsicamente capturan los
requerimientos para la arquitectura, de ah que estn
relacionados con ms de una vista particular.
Vistas de la Arquitectura
Vistas 4 + 1 Philippe Krutchen
Utilizaremos algunos de los diagramas provistos
por UML 2.0 para representar las vistas
arquitectnicas ms significativas.
Diagramas de Casos de Uso
Diagramas de Estructura Compuesta
Diagrama de Despliegue
Se pueden utilizar tambin diagramas de clases pero
sin entrar en detalles innecesarios a nivel del diseo
arquitectnico y diagramas de secuencia para modelar
el comportamiento de los componentes en una
arquitectura.
 Vistas de la arquitectura a trabajar desde
el prctico:
Vista Arquitectnica de la Funcionalidad: Casos de
Uso significativos para la Arquitectura
Vista Arquitectnica del Diseo: Subsistemas e
Interfaces
Vista Arquitectnica del Despliegue: Nodos y
Componentes principales
Vista Arquitectnica del Despliegue: Niveles de
Hardware
Vistas de la Arquitectura - Siemens 4
View
Vistas de la Arquitectura
Siemens 4 View
El mtodo Siemens Four-Views (S4V)
(Hofmeister et al, 1999;.. Soni et al, 1995),
desarrollado en Siemens Corporate Research,
considera cuatro vistas de la arquitectura:
Vista conceptual
Vista de ejecucin
Vista de mdulo
Vista de cdigo
Las 4 vistas de la arquitectura, separan
diferentes intereses de ingeniera lo que reduce
la complejidad de la tarea de diseo de la
arquitectura.
Vistas de la Arquitectura
Siemens 4 View: Vista Conceptual
En la vista conceptual, la funcionalidad del
producto se asigna a un conjunto de componentes
y conectores interconectados. Los componentes se
ejecutan de forma independiente de sus pares, al
igual que los conectores.
Las preocupaciones principales de ingeniera en
esta vista abordan cmo el sistema cumple con los
requisitos. Los requisitos funcionales son una
preocupacin central, que incluye tanto las
necesidades actuales como mejoras futuras.
Vistas de la Arquitectura
Siemens 4 View: Vista de Mdulo
Para la vista de mdulo, los mdulos se organizan
en dos estructuras ortogonales: descomposicin y
capas.
La estructura de descomposicin capta cmo el
sistema se descompone lgicamente en
subsistemas y mdulos.
Un mdulo puede ser asignado a una capa, que
luego limita sus dependencias con otros mdulos.
Vistas de la Arquitectura
Siemens 4 View: Vista de Mdulo
Las principales preocupaciones en esta vista
son:
Minimizar las dependencias entre mdulos
Maximizar la reutilizacin de mdulos, y las pruebas
de apoyo.
Otra preocupacin clave es minimizar el impacto de
futuros cambios en el software, la plataforma de
software, hardware y software de dominio especfico
y estndares.
Vistas de la Arquitectura
Siemens 4 View: Vista de Ejecucin
La vista arquitectnica de Ejecucin describe la estructura del
sistema en trminos de elementos de la plataforma de
ejecucin (por ejemplo, tareas, procesos del sistema
operativo, hilos de control).
La tarea de esta vista es asignar la funcionalidad del sistema a
estos elementos de la plataforma, determinar cmo las
instancias resultantes en tiempo de ejecucin se comunican,
y cmo se asignan los recursos fsicos a ellas.
Otras consideraciones son la ubicacin, la migracin y
replicacin de estas instancias en tiempo de ejecucin.
Propiedades de ejecucin del sistema, el rendimiento, la
seguridad y la replicacin se deben abordar aqu.
Vistas de la Arquitectura
Siemens 4 View: Vista de Cdigo
La ltima vista, la vista arquitectnica de Cdigo, se ocupa de
la organizacin de los artefactos de software.
Los componentes fuente (source) implementan los
elementos de la vista de mdulo y los componentes de
despliegue instancian entidades de ejecucin de la vista de la
Ejecucin.
Las preocupaciones de ingeniera de esta vista consisten en
realizar versiones y lanzamientos de productos, minimizar el
esfuerzo de actualizaciones de productos, minimizar el
tiempo de construccin y dar soporte a la integracin y
pruebas.
Tipos e instancias en diferentes
vistas
Los tipos componentes existen en el tipo de vista de mdulo
y las instancias de componentes (objetos) existen en la vista
de ejecucin, tal como ocurre con las clases y la objetos.
Cmo documentar la Arquitectura?
Importancia de documentar la
Arquitectura
Permite la comunicacin entre todas las partes
(participantes) interesadas en el desarrollo de un sistema
de cmputo.
Destaca las decisiones iniciales relacionadas con el
diseo que tendrn impacto en todo el trabajo de
ingeniera de software que sigue.
Constituye un modelo relativamente pequeo e
intelectualmente comprensible de cmo est
estructurado el sistema y cmo trabajan juntos sus
componentes.
Ventajas de disear y documentar la
arquitectura (Bass)

Comunicacin con los involucrados

Anlisis del sistema
Reutilizacin a gran escala
Expresin del sistema y su evolucin
Comunicacin entre involucrados
Comprender y evaluar el diseo.
Aprender sobre la arquitectura asimilando los conceptos
detrs del diseo.
Evaluacin y comparacin de arquitectura de una forma
consistente
Planificacin, administracin y ejecucin de las actividades del
desarrollo del sistema-
Expresin de las caractersticas persistentes y soporte de los
principios que guan un cambio aceptable.
Analizar el diseo tal vez para valorar su probable
rendimiento.
Verificacin de la implementacin del sistema
Documentar las arquitecturas, puede ser
problemtico porque :
No hay una forma de documentacin estndar
universalmente aceptada.
Una arquitectura puede ser compleja y documentarla
en una manera comprensible es tiempo consumido y
no de manera trivial.
Una arquitectura tiene varias vistas posibles.
Documentar todas las potencialmente tiles es tiempo
consumido y costoso.
Un diseo de la arquitectura frecuentemente
evoluciona a medida que el sistema se desarrolla
incrementalmente y se gana ms conocimiento sobre
el dominio de problema.
 Documentacin Arquitectnica
Fecha y Estado
Aspectos de la Organizacin
Historia de Cambios
Resumen
Alcance
Contexto
Glosario
Referencias
Template para documentar la Arquitectura
Nombre del Producto
Contexto del Producto
Requerimientos Arquitectnicos
Descripcin de Objetivos Clave
Casos de Uso Arquitectnicos
Identificacin de Involucrados
Usuarios del Sistema
Compradores del Sistema
Desarrolladores del Sistema
Mantenedores del Sistema
Requerimientos arquitectnicos de los involucrados
Consideraciones del Arquitecto
El propsito o misin del sistema.
La apropiacin del sistema para cumplimentar su misin.
La factibilidad de construir el sistema.
Riesgos del desarrollo y operacin del sistema para los involucrados.
Mantenibilidad, posibilidad de despliegue y evolucin del sistema.
Restricciones
Requerimientos No Funcionales
Solucin
Patrones arquitectnicos relevantes.
Descripcin general de la arquitectura.
Vistas estructurales.
Vistas de comportamiento
Beneficios de implementacin.
Anlisis de la Arquitectura
Anlisis de escenarios
Riesgos.
 Ayuda a incrementar la confianza del equipo de diseo en que la
arquitectura cumpla con su propsito.
Debe realizarse con las restricciones de tiempo y presupuesto del
proyecto.
El truco es ser tan riguroso y eficiente como sea posible.
Es un desafo validar la arquitectura ya que finalmente es un diseo
y no puede ejecutarse ni probarse para ver si cumple los
requerimientos.
Existen dos tcnicas principales que tienen un uso probado. Ambas
ayudan a identificar fallas y debilidades, reas de riesgo potencial
para las posteriores actividades de construccin.
1) Probar Manualmente la Arquitectura utilizando escenarios.
2) Construir prototipos que crea un arquetipo de la aplicacin
deseada.
Tcnica desarrollada por el SEI.
Los escenarios estn relacionados con aspectos
arquitectnicos tales como atributos de calidad, y ellos
ayudan a destacar consecuencias de las decisiones
arquitectnicas que estn encapsuladas en el diseo.
Los escenarios son artefactos simples.
Implican la definicin de estmulos que tendrn
impacto en la arquitectura.
Se trabaja la respuesta de la arquitectura a esos
estmulos.
Destacan las implicancias de la arquitectura en las
decisiones de diseo.
Ejemplos de Escenarios
Validacin: Construccin de Prototipos
Los escenarios son una tcnica til para validar la
arquitectura, sin embargo algunos escenarios no son tan
simples.
Ejemplo: Hay que procesar 500 rdenes en 5
minutos
La pregunta es simple: Se podr?
La nica forma de contestar esta pregunta con algn
grado de confianza es construir un prototipo.
Los prototipos son versiones mnimas, restringidas de la
aplicacin, creadas especficamente para probar algn
aspecto riesgoso o pobremente comprendido del diseo.
Validacin: Construccin de Prototipos
Los prototipos son utilizados comnmente para dos
propsitos.
Prueba de Conceptos:Puede la arquitectura como fue
diseada ser construida de manera tal que satisfaga
los requerimientos?
Prueba de Tecnologa: La tecnologa elegida
(middleware, aplicaciones integradas, libreras, etc.)
para implementar la arquitectura se comporta como
es esperado?
En ambos casos proveen una evidencia que de otra
forma no se puede validar.