Diseno Arquitectonico

Diseo Arquitectnico
Introduccin
Departamento de Informtica
Universidad Tcnica Federico Santa Mara
Introduccin
Qu es??
El diseo arquitectnico representa la estructura de datos y
los componentes del programa necesarios para construir un
sistema computacional.
Asume el estilo arquitectnico que tomar el sistema, la
estructura y las propiedades de los componentes que
constituyen el sistema y las interrelaciones entre todos los
componentes arquitectnicos del sistema.
El diseo arquitectnico corresponde al proceso de diseo
que identifica los subsistemas que conforman un sistema y
la infraestructura de control y comunicacin.
La salida de este proceso de diseo es una descripcin de
la arquitectura de Software.
Pedro Francisco Godoy Barrera
Metodologas de diseo e Implantacin
Introduccin
Quin lo hace??
Cuando se construyen sistemas grandes y
complejos se asigna un especialista, para los otros
trabajos un Ingeniero de SW puede disear los
datos y la arquitectura.
El diseador de BD o de almacn de datos crea la
arquitectura de datos del sistema.
El arquitecto del sistema selecciona un estilo
arquitectnico apropiado para los requisitos
derivados durante la ingeniera del sistema y el
anlisis de los requisitos del SW.
Introduccin
Por qu es importante?
El diseo arquitectnico proporciona una vista general del
SW y asegura que se obtenga lo que se desea.
Nadie tratara hacer una casa sin un plano.
Cules son los pasos?

El diseo arquitectnico comienza con el diseo de los datos
y luego pasa a la derivacin de una o ms representaciones
de la estructura arquitectnica del sistema.
Se analizan los estilos o patrones arquitectnicos alternos
para derivar la estructura que amolda mejor a los requisitos
del cliente.
A penas se selecciona una opcin se elabora la arquitectura
empleando un mtodo de diseo apropiado
Introduccin
Cul es el producto obtenido??
Un modelo que abarca la arquitectura de los datos y la
estructura del programa se crea durante esta etapa del
diseo.
Se describen las propiedades de los componentes y sus
relaciones (inherencias).
Cmo se puede estar seguro de que lo que he hecho

est bien?
En cada etapa se revisan los productos resultantes del
diseo del SW para verificar la claridad, la correccin, el
grado en el que se ha completado y su consistencia con los
requisitos y entre unos y otros.

1.- Arquitectura de SW
La Arquitectura de un sistema es un marco conceptual
completo que describe su forma y estructura ( sus
componentes y la manera en que se integran).
En su analoga con la edificacin, La arquitectura es
La manera en que los diversos componentes de un edificio
se integran para formar un todo cohesionado.
La manera en que un edificio se amolda a su ambiente y se
combina con otros edificios vecinos.
El grado en el cual el edificio cumple con el propsito
establecido y en que satisface las necesidades de su
propietario.

La arquitectura del SW es la estructura o las estructuras
del sistema, que incluyen los componentes del SW, las
propiedades visibles externamente de esos componentes
y las relaciones entre ellos.
No es el SW operativo. En cambio, es una representacin
que permite que un Ing. De SW:
Analice la efectividad del diseo para cumplir con los
requisitos establecidos.
Considere opciones arquitectnicas en una etapa en que
an resulta relativamente fcil hacer cambios al diseo
Reduzca los riesgos asociados con la construccin del SW

Estas definiciones destaca el papel de los
componentes
del
SW
en
cualquier
representacin arquitectnica.
En este contexto (arquitectnico), un componente
de SW es algo tan simple como un mdulo del
programa o una clase orientada a objetos, pero
tambin se extiende para incluir BD y middleware
que permita configurar una red de clientes y
servidores.
El diseo de la arquitectura considera el diseo
de datos y el diseo arquitectnico.
El diseo de datos permite representar el
componente de datos de la arquitectura en
sistemas convencionales y definiciones de clases
(atributos y operaciones de encapsulamiento) de
los sistemas orientados a objetos.
El diseo arquitectnico se concentra en la
representacin de la estructura de los
componentes del SW, sus propiedades e
interacciones.
La arquitectura de SW es la organizacin de un
sistema en trminos de sus compontes de SW,
incluyendo subsistemas y las relaciones e
interacciones entre ellos, y los principios que
guan el diseo de ese sistema de SW. (IEEE).
Esta definicin es importante porque destaca el
hecho de que un sistema puede contemplarse
desde distintas perspectivas que hacen nfasis en
los distintos aspectos del sistema.
Aspectos de la Arquitectura de
SW
Tipo de
Arquitectura
Definicin
Ejemplo de
elementos
Ejemplo de
relaciones
Conceptual
Se ocupa de la estructura del modelo Componentes Conectores

de clase esttico y de las conexiones
entre los componentes del modelo
Modular
Describe la forma en que el sistema Subsistemas,

est dividido en subsistemas o mdulos
mdulos y cmo se comunican
mediante la exportacin e importacin
de datos
Exportacion
es,
Importacion
es
Cdigo
Define cmo est organizado el Archivos,

cdigo del programa en archivos, directorios,
directorios y se agrupa en bibliotecas. bibliotecas
Incluye,
contiene
Ejecucin
Se centra en los aspectos dinmicos Tareas,

del sistema y en la comunicacin entre lneas,
componentes cuando se ejecutan las interacciones
tareas y las operaciones.
de objetos
Usos,
llamadas
Las 5 Perspectivas de UML

Perspectiva
Explicacin
De casos de usos
Los casos de uso importantes del sistema y los

escenarios que describen el comportamiento importante
desde el punto de vista de la arquitectura.
Lgica
Las clases e interfaces importantes de diseo de una

estructura de paquete, con diagramas de estructura
compuestos.
Implementacin
Decisiones sobre arquitecturas hechas por

implementacin en trminos de subsistemas,
componentes y de las relaciones entre ellos.
De proceso
Una descripcin de los procesos (procesos y tareas del

sistema operativo) y de las comunicaciones entre
procesos utilizando clases estereotipadas
De Despliegue
Nodos fsicos para la probable plataforma de despliegue,

los componentes desplegados y los nodos y canales de
comunicacin entre ellos, utilizando diagramas de
despliegue.
la
de
1.2 Por qu es importante?

Se han identificado 3 razones claves por las cuales la
arquitectura es importante:
Las representaciones de la arquitectura de SW permiten 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 un impacto profundo en todo el trabajo de la
ingeniera de SW que le sigue y, lo que tambin resulta
importante, en el xito final del sistema como entidad
operacional.
Constituye
un
modelo
relativamente
pequeo
e
intelectualmente comprensible de cmo est estructurado el
sistema y como trabajan juntos sus componentes
1.2 Por qu es importante?

El modelo de diseo arquitectnico y los patrones
arquitectnicos que contiene son transferibles.
Es decir, los estilos y patrones arquitectnicos se
aplican al diseo de otros sistemas y representan
un conjunto de abstracciones que permiten a los
ingenieros de SW describir la arquitectura de
maneras predecibles.

Diseo de datos
2.- Diseo de datos

La accin de diseo de datos traduce los objetos
de datos definidos en la etapa de anlisis, en
estructuras globales al nivel de componentes de
SW y, cuando es necesario, una arquitectura de
BD al nivel de aplicacin.
En algunas situaciones debe disearse y
construirse una BD especficamente para un
nuevo sistema, sin embargo, en otras, se
emplean una o ms BD existentes.

2.1 Diseo de datos al nivel

arquitectnico
La calidad de datos marca la diferencia entre un almacn
y un basurero de datos.
Hoy los negocios grandes y pequeos estn inundados de
datos.
No resulta poco comn que incluso un negocio de tamao
moderado tenga docenas de BD que sirven a muchas
aplicaciones.
El reto consiste en extraer informacin til de este entorno
de datos, sobretodo cuando la informacin deseada tiene
la funcionalidad cruzada.
Para resolver este desafo se ha desarrollado la tcnica de
minera de datos.
2.1 Diseo de datos al nivel

arquitectnico
Un almacn de datos es un entorno de datos
independiente que no est directamente integrado
en las aplicaciones cotidianas, pero que abarca
todos los datos utilizados en un negocio.
En cierto sentido, un almacn de datos es una BD
grande e independiente que tiene acceso a los
datos almacenados en las BD que sirven al
conjunto de aplicaciones requeridas en un
negocio.

2.2 Diseo de datos al nivel de

componentes
El diseo de datos al nivel de componentes se
concentra en la representacin de estructuras de
datos a las que se tiene acceso en forma directa
mediante uno o ms componentes de SW.
El diseo de datos comienza durante la creacin
del modelo de anlisis.

Estilos Arquitectnicos y
patrones
3.- Estilos y patrones arquitectnicos
Un estilo arquitectnico es una transformacin impuesta

al diseo de todo un sistema. El objetivo es establecer
una estructura para todos los componentes del sistema.
Indican
Los tipos de componentes y sus conectores involucrados

Patrones y restricciones de interconexin o composicin
entre ellos
Invariantes del estilo (restricciones)
Asociado a cada estilo hay una serie de propiedades que

lo caracterizan
Determinan sus ventajas e inconvenientes

Condicionan la eleccin de uno u otro estilo
El estilo arquitectnico es una plantilla para la

construccin.
Los SW que se construyen tambin muestran

uno o muchos estilos arquitectnicos.
Estilo arquitectnico Colonial con sala al

centro

Estilos Arquitectnicos
Cada estilo describe una categora de sistemas que

abarca
1. Un conjunto de componentes (por ejemplo, una BD, mdulos
computacionales) que realizan una funcin requerida por el
sistema.
2. Un Conjunto de conectores que permiten la comunicacin,
coordinacin y cooperacin entre los componentes
3. Restricciones que definen cmo se integran los

componentes para formar el sistema.
4. Modelos semnticos que permiten a un diseador,
mediante el anlisis de las propiedades conocidas de
las partes que lo integran, comprender las propiedades
generales de un sistema.
Estilos Arquitectnicos
Estilos de Flujo de Datos
Tubera y filtros
Estilos Centrados en Datos

Arquitecturas de Pizarra o
Repositorio
Estilos de Llamada y Retorno

Model-View-Controller (MVC)
Arquitecturas en Capas
Arquitecturas Orientadas a
Objetos
Arquitecturas Basadas en
Componentes
Estilos de Cdigo Mvil

Arquitectura
Virtuales
de
Mquinas
Estilos heterogneos
Sistemas
de
control
procesos
Arquitecturas
Basadas
Atributos
de
en
Estilos Peer-to-Peer
Arquitecturas
Eventos
Arquitecturas
Servicios
Arquitecturas
Recursos

Basadas
en
Orientadas
Basadas
en
3.- Estilos y patrones arquitectnicos

Un patrn arquitectnico, al igual que un estilo, impone
una transformacin en el diseo de una arquitectura.
Diferencias entre patrn y estilos
El alcance de un patrn es menor, ya que se concentra en
un aspecto en lugar de hacerlo en toda la arquitectura.
Un patrn impone una regla sobre la arquitectura, pues
describe la manera en que el SW manejar algn aspecto
de su funcionalidad al nivel de la infraestructura (por
ejemplo, concurrencia).
Los patrones arquitectnicos tienden a abarcar aspectos
especficos del comportamiento dentro del contexto de la
arquitectura (por ejemplo, como maneja una aplicacin en
tiempo real la sincronizacin o las interrupciones ).
Los patrones se usan junto con un estilo arquitectnico

para determinar la forma de la estructura general de un
sistema.
Breve Taxonoma de Estilos

arquitectnicos
3.1 Una breve taxonoma de estilos

arquitectnicos
Arquitectura centrada en datos:
Un almacn de datos se encuentra en el centro de esta
arquitectura.
Otros componentes tienen acceso a l y cuentan con la
opcin de actualizar, agregar, eliminar o por otra parte,
modificar los datos de ese almacn.
El SW cliente tiene acceso a un almacn central. En algunos
casos este es pasivo, es decir, el SW cliente accede a los
datos independiente de cualquier cambio hecho a los datos
o a las acciones de otros SW cliente.
Una variacin de este enfoque transforma el depsito en un
pizarrn que enva notificaciones al SW cliente cuando
cambian los datos de inters para el cliente.

arquitectnicos
Una arquitectura centrada en datos promueve la capacidad
de integracin, esto significa que es posible cambiar
componentes existentes y agregar nuevos componentes
cliente a la arquitectura sin preocuparse por otros clientes
(ya que los componentes clientes operan en forma
independiente).
Adems es posible pasar datos entre clientes empleando el
mecanismo del pizarrn, es decir, el componente pizarrn
sirve para coordinar la transferencia de informacin entre
clientes.
Los componentes cliente ejecutan los procesos de manera
independiente.

arquitectnicos
Arquitectura centrada en datos
Software cliente
Software cliente
Software cliente
Almacn de datos
(depsito o pizarrn)
Software cliente
Software cliente

Software cliente

arquitectnicos
Ventajas
Posibilita la integracin de agentes.
Adecuado para la resolucin de problemas no
deterministas
Se puede resumir el estado de conocimiento en
cada momento del proceso.
Desventajas
Estructura de datos comn a todos los agentes
Problemas de carga a la hora de chequear y vigilar
el estado de la pizarra

arquitectnicos
Arquitectura de flujo de datos:
Esta arquitectura se aplica cuando los datos de entrada se
habrn de transformar en datos de salida mediante una serie
de componentes para el clculo o la manipulacin. Una
estructura de tuberas y filtros.
Tiene un conjunto de componentes denominados filtros,
conectados por tuberas que transmiten datos de un
componente al siguiente.
Cada filtro funciona sin tomar en cuenta si los componentes
tienen flujo ascendente o descendente
Esta diseado para esperar la entrada de datos con cierta
forma y producir su salida (al siguiente filtro) de una forma
especfica. (no es necesario que el filtro conozca el
funcionamiento de los filtros vecinos.

arquitectnicos
Si el flujo de datos degenera en una sola lnea de
transformaciones se denomina procesamiento por lotes
secuencial. Esta estructura acepta un procesamiento por
lotes de datos y luego aplica una serie de componentes
secuenciales (filtro) para transformarlos.
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Tuberas
Filtro
Filtro
Filtro
Filtro

arquitectnicos
Ventajas
Permite entender el sistema global en trminos de la
combinacin de componentes
Soporta de buena manera la reutilizacin
Los filtros son independientes de sus vecinos
Facilidad de mantenimiento y mejora
Facilidad de diagnstico (rendimiento y Dead-lock)
Soportan la ejecucin concurrente
Desventajas
No aconsejable para cuando se necesita interactividad
Problemas de rendimiento ya que los datos se transmiten en
forma completa entre filtros.

arquitectnicos
Arquitectura de llamada y retorno:
Con esta arquitectura se obtiene una estructura de programa
que resulta relativamente fcil de modificar y cambiar de
tamao.
Existen dos subestilos:
Arquitectura de programa principal/subprograma: Esta
estructura de programa clsica separa la funcin en una
jerarqua de control donde un programa principal invoca a
varios componentes de programa, que a su vez pueden
invocar a otros componentes.
Arquitectura de llamada a procedimiento remoto: Los
componentes
de
una
arquitectura
de
programa
principal/subprograma
se
distribuyen
entre
varias
computadoras de una red.

arquitectnicos
Arquitectura de llamada y retorno:
Programa
Principal
Subprograma
controlador
Subprograma
de aplicacin
Subprograma
controlador
Subprograma Subprograma
de aplicacin de aplicacin
Subprograma
de aplicacin
Subprograma
controlador
Subprograma
de aplicacin
Subprograma
de aplicacin
Subprograma
de aplicacin


arquitectnicos
Arquitectura Orientada a Objetos:
Los componentes de un sistema encapsulan los
datos y las operaciones que deben aplicarse para
manipular los datos. La comunicacin y
coordinacin entre los componentes se consigue
mediante el paso de mensajes.
Restricciones
Los objetos son responsables de la integridad de
sus representaciones
Dicha representacin es ocultada al resto de los
objetos

arquitectnicos
Arquitectura Orientada a Objetos:
Ventajas
Gracias al invariante de ocultacin es posible
reemplazar la implementacin sin que afecte a los
clientes (clientes del objeto)
Desventajas
Para invocar mtodos de un objeto se debe
conocer su identidad
Parece obvio
!!!pero no lo es en absoluto!!!
Efectos colaterales

arquitectnicos
Arquitectura estratificada:
Hay varias capas definidas, cada una de ellas
realiza
operaciones
que
se
acercan
progresivamente al conjunto de instrucciones de la
mquina.
En la capa externa los componentes sirven a las
operaciones de interfaz del usuario.
En la capa interna los componentes sirven como
interfaz con el sistema operativo.
Las capas intermedias proporcionan servicios de
utilera y de SW de aplicaciones

arquitectnicos
Mdulos
Capa de la
interfaz de
usuario
Capa de la
Aplicacin
Capa de
Utileras
Capa
Central

arquitectnicos
Ventajas
Facilita la descomposicin del problema en varios niveles de
abstraccin.
Soporta fcilmente la evolucin del sistema, los cambios slo
afectan a las capas vecinas
Se pueden cambiar las implementaciones respetando las
interfaces con las capas adyacentes
Desventajas
No todos los sistemas pueden estructurarse en capas
A menudo es difcil encontrar la separacin en capas adecuadas

Patrones arquitectnicos
3.2 Patrones Arquitectnicos

Si el constructor decide construir una casa con sala al
centro slo podr aplicar un estilo arquitectnico.
Los detalles del estilo (n de chimeneas, fachada de la
casa, colocacin de puertas y ventanas) variarn
considerablemente, pero una vez que se ha tomado la
decisin de la arquitectura general de la casa, el estilo se
impondr al diseo.
Los patrones arquitectnicos difieren un poco. Por ejemplo
cada casa emplea un patrn cocina, el cual define la
necesidad de colocar los artculos bsicos de cocina, un
lavaplatos y posibles reglas para ubicar cosas
relacionadas al flujo de trabajo.
Obviamente hay ms de un diseo de cocina, pero todo
diseo se concebir dentro del contexto de la solucin
que sugiere el patrn cocina.

Cmo ya se indic, los patrones arquitectnicos para el
SW definen un enfoque especfico para el manejo de
alguna caracterstica de comportamiento del sistema.
Patrones arquitectnicos representativos:
Concurrencia: Muchas aplicaciones tienen que manejar
varias tareas de manera tal que simulen paralelismo (es
decir, cada vez que un solo procesador maneja varias tareas
paralelas o componentes).
Una aplicacin tiene varias maneras de manejar la
concurrencia, y cada una se presenta mediante un patrn
arquitectnico diferente.


Concurrencia:
Un enfoque consiste en usar un patrn de manejo de
procesos del sistema operativo que ofrece caractersticas
integradas del sistema operativo que permiten la ejecucin
concurrente de los componentes.
El patrn tambin incorpora funcionalidad del sistema
operativo que maneja la comunicacin entre los procesos, la
calendarizacin y otras funciones requeridas para alcanzar
la concurrencia.
Otro mtodo sera definir un calendarizador de tareas al
nivel de aplicacin.
Un patrn calendarizador de tareas contiene un conjunto de
objetos activos, y cada uno de ellos incluye una operacin
tic().

Concurrencia:
El calendarizador invoca peridicamente tic() para
cada objeto, que luego realiza las funciones que
debe realizar antes de regresar el control al mismo
calendarizador, que invoca de nuevo la operacin
tic() para el siguiente objeto concurrente.


Persistencia:
Los datos persisten si sobreviven despus de la ejecucin
del proceso que los cre.
Los datos persistentes se almacenan en una BD o un
archivo.
En un momento posterior, otros procesos tienen la opcin de
leerlos o modificarlos.
En los entornos orientados a objetos la idea de un objeto
persistente extiende un poco ms el concepto de
persistencia.
Los valores de todos los atributos del objeto, el estado
general de ste y otra informacin complementaria se
almacenan para su aplicacin y recuperacin posterior.

Persistencia:
En gral se emplean dos patrones arquitectnicos
para lograr la persistencia
1. Un patrn de sistema de administracin de BD que
aplica las capacidades de almacenamiento y
recuperacin de un sistema de administracin de
BD a la arquitectura de la aplicacin.
2. Un patrn de persistencia al nivel de la aplicacin
que construye caractersticas de persistencia en la
arquitectura de sta


Distribucin:
El problema de la distribucin dirige la manera en que se

comunican entre s los sistemas, o los componentes de
stos, en un entorno distribuido.
Este problema incluye dos elementos:
1.
2.
La manera en que las entidades se conectan entre si.

La naturaleza de la comunicacin
El patrn arquitectnico ms comn establecido para dirigir

el problema de la distribucin es el corredor.
Un corredor acta como Intermediario entre el
componente cliente y un componente servidor. El cliente
enva un mensaje al corredor (que contiene toda la
informacin apropiada para que se realice la
comunicacin), el cual completa la conexin. Ej CORBA.
Organizacin y refinamiento
3.3 Organizacin y refinamiento

Debido a que el proceso de diseo suele dejar varias
opciones arquitectnicas, es importante establecer un
conjunto de criterios de diseo para evaluar un diseo
arquitectnico.
Las siguientes preguntas proporcionan una visin especfica
del estilo arquitectnico que se ha derivado.
Control:
Cmo se maneja el control dentro de la arquitectura?
Existe una jerarqua de control distintiva y, si es as, cul es la
funcin de los componentes dentro de esa jerarqua de control?
Cmo transfieren los campos el control dentro del sistema?
Cmo se comparte el control de los componentes?
Cul es la topologa del control (es decir, cul es la forma
geomtrica que asume el control)?
Est sincronizado el control o los componentes operan
asincrnicamente?
3.3 Organizacin y refinamiento

Las siguientes preguntas proporcionan una visin especfica del
estilo arquitectnico que se ha derivado.
Datos:
Cmo se comunican los datos entre los componentes?
El flujo de datos es continuo o los objetos de datos se pasan
espordicamente al sistema?
Cul es el modo de transferencia de los datos (Por ejemplo, los
datos se pasan de un componente a otro o estn disponibles
globalmente para compartirse entre los componentes del
sistema)?
Existen componentes de datos (por ejemplo un pizarrn o
almacn) y de ser as, cul es su papel?
Cmo interactan los componentes funcionales con los datos?
Los componentes de los datos son pasivos o activos (es decir,
interactan activamente con otros componentes del sistema)?
Cmo interactan los datos y el control dentro del sistema?
Diseo Arquitectnico
4 Diseo Arquitectnico
Cuando se empieza el diseo arquitectnico debe ponerse
en contexto el SW que se habr de desarrollar, es decir, el
diseo debe definir las entidades externas (otros sistemas,
otros dispositivos, otras personas) con las que interacta
el SW y tambin la naturaleza de la interaccin.
Esta informacin suele adquirirse del modelo de anlisis y
toda la dems informacin reunida durante la ingeniera de
requisitos.
Una vez que se ha modelado el contexto y que se han
descrito todas las interfaces externas del SW, el diseador
especifica la estructura del sistema al definir y refinar los
componentes del SW que implementan la arquitectura.
Este proceso prosigue de manera iterativa hasta que se
obtiene la estructura arquitectnica completa.
4.1 Representacin del sistema de

contexto
En las etapas anteriores, se seal que el
Ingeniero de sistema debe modelar el contexto.
Un diagrama de contexto del sistema cumple con
este requisito al representar el flujo de la
informacin dentro y fuera del sistema, la
informacin del usuario y el procesamiento
relevante de soporte.
A nivel de diseo arquitectnico, un arquitecto de
SW aplica un diseo de contexto arquitectnico
(DCA) para modelar de manera en que el SW
interactuar con las entidades ubicadas ms all
de sus lmites.
Diagrama de contexto Arquitectnico

Sistemas Superordinados
Usadas por
Sistema de destino
Uses
Pares
Usan
Actores
Dependen de
Sistemas
Subordinados

contexto
Tomando como referencia la figura anterior, los sistemas
interactan con el sistema de destino (si el sistema para el
que se est desarrollando un diseo arquitectnico) se
representa as:
Sistemas Superodinados: los que emplean el sistema de
destino como parte de algn esquema de procesamiento de
nivel ms elevado.
Sistemas Subordinados: Los que utiliza el sistema de destino
y que proporcionan los datos o el procesamiento necesarios
para completar la funcionalidad del sistema de destino.
Sistemas a nivel de par: Los que interactan de igual a igual
(es decir, la informacin la producen o consumen los pares y el
sistema de destino)
Actores: Las entidades (personas, dispositivos) que interactan
con el sistema de destino produciendo o consumiendo
informacin necesaria para el procesamiento de requisitos

contexto
Cada una de estas entidades externas se
comunica con el sistema de destino mediante una
interfaz (los pequeos rectngulos negros). volver
Producto
Hogar Seguro
Panel de
Control
Propietario
Sistema basado
en Internet
Funcin de
Usa Vigilancia
Sistema de destino:
Funcin de seguridad
Usa
Usa
Sensores
Sensores

4.2 Refinamiento de la arquitectura

en Componentes
A medida que se refina la arquitectura del SW en
componentes, la estructura del sistema empieza a
emerger.
Para elegir estos componentes, el diseador de la
arquitectura empieza con las clases descrita como parte
del modelo de anlisis (Si se elige el enfoque
convencional, es posible que los componentes sean
derivados del modelo de flujo de datos).
Estas clases de anlisis representan entidades dentro del
dominio de la aplicacin (negocio) que deben atenderse
dentro de la arquitectura del SW.
Por tanto, el dominio de la aplicacin es una fuente para la
derivacin y el refinamiento de los componentes. Otra
fuente es el dominio de la infraestructura.

en Componentes
La arquitectura debe adecuarse a muchos componentes
de infraestructura que habilitan los componentes de la
aplicacin, pero que no tienen conexin de negocios con
el dominio de la aplicacin.
Por ejemplo: Los componentes de administracin de
memoria, de comunicacin, de BD y de administracin de
tareas, suelen integrarse en la arquitectura de SW.
La interfaz descrita en el diagrama de contexto de la
arquitectura (ver), indica que uno o ms componentes
especializados procesan los datos que fluyen por la
interfaz.
En algunos casos (por ejemplo la interfaz grfica de
usuario) debe disearse una arquitectura completa de
subsistemas con muchos componentes.

en Componentes
Director
Hogar Seguro
Manejo de
Comunicacin
Externo
Seguridad
Interfaz Grfica
De
Usuario
Vigilancia
Administracin
De la Casa
Interfaz
de Internet
Procesamiento
de panel
de control
Manejo de
detector
Procesamiento
de
Alarma
Estructura General de la Arquitectura de Casa Segura con componentes

de nivel superior.

en Componentes
Ejemplo de casa segura: Se definirn un conjunto de
componentes de nivel superior que atienden la siguiente
funcionalidad.
Administracin de comunicacin externa: Coordina la
comunicacin de la funcin de seguridad con entidades
externas; Por ej: Sistemas de Internet, notificacin externa
de alarma.
Procesamiento del panel de control: maneja toda la
funcionalidad del panel de control.
Manejo del detector: coordina el acceso a todos los
detectores conectados al sistema.
Procesamiento de alarma: Verifica todas las condiciones
de alarma y acta sobre ellas.

en Componentes
Cada uno de estos componentes de nivel superior tendra
que elaborarse iterativamente y luego posicionarse dentro
de la arquitectura general.
Para cada uno se definiran clases de diseo (con los
atributos y las operaciones apropiadas).
Sin embargo, es importante observar que los detalles de
diseo de todos los atributos y las operaciones slo se
especificaran hasta la realizacin del diseo en el nivel de
componentes.

4.3 Descripcin de la creacin de

Instancias del Sistema.
El diseo arquitectnico que se ha modelado hasta este
punto es todava de un nivel relativamente alto.
Se ha representado el contexto del sistema
Se han definido los arquetipos que indican las abstracciones
importantes dentro del dominio del problema, es evidente la
estructura general del sistema.
Y se han identificado los principales componentes del SW.
Sin embargo, an se necesita mayor refinamiento.

Esto se logra desarrollando una instancia de la
arquitectura. Es decir, la arquitectura se aplica a un
problema especfico con el propsito de demostrar que la
estructura y los componentes son apropiados.
4.3 Descripcin de la creacin de

Instancias del Sistema.
Director
Hogar Seguro
Manejo de
Comunicacin
Externo
Seguridad
Interfaz Grfica
De
Usuario
Interfaz
de Internet
Procesamiento
Manejo de
detector
de panel
de control
Protocolo de
teclado numrico
Calendarizador
Funciones de
Despliegue CP
Procesamiento
de
Alarma
Comunicacin
telefnica
Alarma
Sensor

Cmo evaluar un diseo

Arquitectnico
5.- Evaluacin de Diseos

Arquitectnicos Alternativos
5.1 Un mtodo de anlisis de Compensacin para la

Arquitectura.
El instituto de Ingeniera del SW (SEI) ha desarrollado un
mtodo de anlisis de compensacin para la Arquitectura
(MACA) que define el proceso de evaluacin iterativo
para las arquitecturas del SW.
Las siguientes actividades de anlisis del diseo se
realizan iterativamente.
1. Recopilar escenarios: Se desarrolla un conjunto de casos
de uso para representar el sistema desde el punto de vista
del usuario.
2. Deducir requisitos, restricciones y descripcin de
entornos: Esta informacin se requiere como parte de la
Ingeniera de requisitos y se usa para asegurarse de que
se atiendan todas las preocupaciones de los participantes.
5.1 Un mtodo de anlisis de

Compensacin para la Arquitectura.
3. Describir los estilos/ patrones arquitectnicos: que se
han elegido para dirigir los escenarios y requisitos.
4. Evaluar los atributos de calidad al considerar cada
atributo de manera aislada: Entre los atributos de calidad
para la evaluacin del diseo arquitectnico se incluyen
confiabilidad, desempeo, seguridad, facilidad de
mantenimiento,
flexibilidad,
facilidad
de
prueba,
portabilidad, facilidad de reutilizacin e interoperabilidad.


5. Identificar la sensibilidad de los atributos de calidad
respecto de varios atributos arquitectnicos para un
estilo arquitectnico especfico: Esto se logra haciendo
pequeos cambios en la arquitectura y determinando la
sensibilidad al cambio de un atributo de calidad, como
desempeo.
Cualquier
atributo
al
que
afecte
significativamente la variacin en la arquitectura se
considerar un punto de sensibilidad.
6. Analizar las arquitecturas alternas: (desarrolladas en el
paso 3) empleando el anlisis de sensibilidad aplicado al
paso 5.


El SEI describe este enfoque de la siguiente manera:

Una vez determinados los puntos de sensibilidad
arquitectnica se encuentran los puntos en que se requiere
compensacin con slo identificar los elementos
arquitectnicos a los que son sensibles varios atributos.
Por ejemplo: El desempeo de una arquitectura cliente
servidor sera muy sensible al nmero de servidores (el
desempeo aumentar, dentro de cierto rango, al aumentar
el nmero de servidores) por tanto, el nmero de
servidores es un punto de compensacin para esta
arquitectura.
Estos 6 pasos representan la primera iteracin MACA. Con

base en los resultados de los pasos 5 y 6 ser posible
eliminar algunas opciones arquitectnicas, modificar una o
ms de las arquitecturas restantes y representarlas con
ms detalle, y luego aplicar una nueva cuenta con los
pasos de MACA.
Complejidad de la Arquitectura
5.2 Complejidad Arquitectnica

Una tcnica til para evaluar la complejidad general de
una arquitectura determinada consiste en considerar las
dependencias entre componentes dentro de la
arquitectura.
Estas dependencias las orienta la informacin, el flujo de
control, o ambas, dentro del sistema.
Zhao sugiere 3 tipos de dependencias:
Dependencias compartidas: Que representan relaciones
de dependencia entre consumidores que usan el mismo
recurso o los productores que producen para los mismos
consumidores. Por ejemplo, supngase dos componentes u
y v que se refieren a los mismos datos globales. Entonces
existe una relacin de dependencia compartida entre u y v.

Zhao sugiere 3 tipos de dependencias:
Dependencias de flujo: que representan las relaciones de
dependencia entre los productores y consumidores de
recursos. Por ejemplo, para dos componentes u y v, si u
debe completarse antes de que el control pase a v
(prerrequisito) o si u se comunica con v mediante
parmetros, entonces existe una relacin de dependencia
de flujo entre u y v.
Dependencias restringidas: que representan restricciones
al flujo relativo de control entre un conjunto de actividades.
Por ejemplo, si los dos componentes u y v no pueden
ejecutarse al mismo tiempo (exclusin mutua), entonces
existe una relacin de dependencia restringida entre u y v.

Las dependencias compartidas y de flujo que seala Zhao
son similares al concepto de acoplamiento.
Acoplamiento es un concepto importante de diseo que se
aplica al nivel de arquitectura y de componentes.

5.3 Lenguajes de descripcin

arquitectnica.
Aunque el arquitecto de SW puede disear con notacin
UML, se necesitan otras formas de diagramacin, y unas
cuantas herramientas relacionadas, para aplicar un
enfoque ms formal a la especificacin de un diseo
arquitectnico.
El Lenguaje de Descripcin Arquitectnica (LDA)
proporciona una semntica y una sintaxis para describir
una arquitectura del SW.
Hofmann y sus colegas, sugieren que un LDA debe
proporcionar al diseador la capacidad de separar
componentes arquitectnicos, de integrar componentes
individuales en bloques arquitectnicos mayores y de
representar interfaces (mecanismos de conexin) entre los
componentes.
5.3 Lenguajes de descripcin

arquitectnica.
Una vez que se hayan establecido las tcnicas
descriptivas, basadas en el lenguaje para diseo
arquitectnico, es ms probable que se establezcan los
mtodos de evaluacin efectivos para la arquitectura a
medida que el diseo evoluciona.


Diseno Arquitectonico

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Diseno Arquitectonico

Enviado por

Direitos autorais:

Formatos disponíveis

Diseo Arquitectnico

Cules son los pasos?

Cmo se puede estar seguro de que lo que he hecho

Pedro Francisco Godoy Barrera

Pedro Francisco Godoy Barrera

Pedro Francisco Godoy Barrera

Se ocupa de la estructura del modelo Componentes Conectores

Describe la forma en que el sistema Subsistemas,

Define cmo est organizado el Archivos,

Se centra en los aspectos dinmicos Tareas,

Metodologas de diseo e Implantacin

Las 5 Perspectivas de UML

Los casos de uso importantes del sistema y los

Las clases e interfaces importantes de diseo de una

Decisiones sobre arquitecturas hechas por

Una descripcin de los procesos (procesos y tareas del

Nodos fsicos para la probable plataforma de despliegue,

1.2 Por qu es importante?

1.2 Por qu es importante?

Pedro Francisco Godoy Barrera

2.- Diseo de datos

Pedro Francisco Godoy Barrera

2.1 Diseo de datos al nivel

2.1 Diseo de datos al nivel

Pedro Francisco Godoy Barrera

2.2 Diseo de datos al nivel de

Pedro Francisco Godoy Barrera

3.- Estilos y patrones arquitectnicos

Un estilo arquitectnico es una transformacin impuesta

Los tipos de componentes y sus conectores involucrados

Invariantes del estilo (restricciones)

Asociado a cada estilo hay una serie de propiedades que

Determinan sus ventajas e inconvenientes

El estilo arquitectnico es una plantilla para la

Los SW que se construyen tambin muestran

Estilo arquitectnico Colonial con sala al

Pedro Francisco Godoy Barrera

Cada estilo describe una categora de sistemas que

3. Restricciones que definen cmo se integran los

Estilos Centrados en Datos

Estilos de Llamada y Retorno

Estilos de Cdigo Mvil

Pedro Francisco Godoy Barrera

3.- Estilos y patrones arquitectnicos

Los patrones se usan junto con un estilo arquitectnico

Breve Taxonoma de Estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

Pedro Francisco Godoy Barrera

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

Pedro Francisco Godoy Barrera

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

3.1 Una breve taxonoma de estilos

Pedro Francisco Godoy Barrera