Estilos arquitectnicos: Cada estilo arquitectnico describe una categora del sistema que

contiene: un conjunto de componentes, que realiza una funcin requerida por el sistema, un
conjunto de conectores que posibilitan la comunicacin, la coordinacin y la cooperacin entre
los componentes; restricciones que definen como se puede integrar los componentes que
forman el sistema; y modelos semnticos que permiten al diseador entender las propiedades
globales de un sistema para analizar las propiedades conocidas de sus partes constituyentes.

Utilizacin de los estilos arquitectnicos

Sirven para sintetizar estructuras de soluciones.

Pocos estilos abstractos encapsulan una enorme variedad de configuraciones

concretas.

Definen los patrones posibles de las aplicaciones.

Permiten evaluar arquitecturas alternativas con ventajas y desventajas conocidas ante

diferentes conjuntos de requerimientos no funcionales

Estilos Peer-to-Peer

Esta familia, tambin llamada de componentes independientes, enfatiza la modificabilidad por

medio de la separacin de las diversas partes que intervienen en la computacin. Consiste por
lo general en procesos independientes o entidades que se comunican a travs de mensajes.
Cada entidad puede enviar mensajes a otras entidades, pero no controlarlas directamente.
Los mensajes pueden ser enviados a componentes nominados o propalados mediante
broadcast.

Arquitectura Centrada en Datos

Un almacn de datos se encuentra en el centro de esta arquitectura , otro componente tiene

acceso a l y cuentan con la opcin de gestionar los datos de ese almacn. El software cliente
tiene acceso a un almacn central, en algunos casos este es pasivo, el software cliente accede
a los datos independientemente de cualquier cambio hecho en los datos o las acciones de otro
software cliente.

Una variacin de este enfoque transforma el depsito en un pizarrn que enva notificaciones
al software cliente cuando cambian datos de inters para el cliente.

Caractersticas

Promueve la capacidad de integracin, es decir, que es posible cambiar componentes

existentes y agregar nuevos componentes a la arquitectura sin preocuparse por otros clientes,
adems es posible pasar datos entre clientes empleando el mecanismo del pizarrn. Los
componentes clientes ejecutan los procesos de manera independiente.
Arquitectura de Flujo de Datos

Es una arquitectura de computadores que contrasta directamente con la tradicional

Arquitectura de von Neumann o de estructuras de control.

Caractersticas

Las arquitecturas de flujo de datos no se basan en un contador de programa (al menos

conceptualmente) en tanto en cuanto la posibilidad de ejecucin de las instrucciones
solamente viene determinada por la disponibilidad de los argumentos de entrada de las
instrucciones.

Ventajas

La ejecucin fuera de orden se ha convertido en el paradigma computacional por excelencia

desde los aos 90. Es una forma de flujo de datos restringido. Este paradigma introdujo la idea
de ventana de ejecucin, que sigue el orden secuencial de la arquitectura de von Neumann; sin
embargo, dentro de la ventana se permite que las instrucciones sean completadas en el orden
de las dependencias de datos.

Desventajas

La complejidad lgica de mantener el rastro de las dependencias de datos de forma dinmica

restringe a los procesadores basados en ejecucin fuera de orden a un reducido nmero de
ejecuciones (de 2 a 6) y limita el tamao de la ventana de ejecucin de 32 a 200 instrucciones,
mucho menor que las utilizadas en las mquinas puras de flujo de datos.

Arquitectura de Llamada y retorno

Estilo clsico desde los aos 1960. Descomposicin jerrquica en subrutinas (componentes)
que solucionan una tarea o funcin definida. Los datos son pasados como parmetros y el
manejador principal proporciona un ciclo de control sobre las subrutinas. Reflejan la estructura
del lenguaje de programacin. Permite al diseador del software construir una estructura de
programa relativamente fcil de modificar y ajustar a escala. Se basan en la bien conocida
abstraccin de procedimientos/funciones/mtodos.

Caractersticas

Hilo de control simple soportado por los lenguajes de programacin.

Usa una estructura implcita de subsistemas.

Razonamiento jerrquico, cambios en una subrutina implican cambios en las

subrutinas que hacen la invocacin.

Pretenden incrementar el desempeo distribuyendo el trabajo en mltiples

procesadores.

Ventajas

Utilizados en grandes sistemas de software.

 La descomposicin en mdulos disminuye la complejidad.

Persiguen escalabilidad y modificabilidad.

Desventajas

Dependencia y acoplamiento entre mdulos.

La reutilizacin y el mantenimiento son difciles

Arquitectura Orientada a Objetos

Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar
para manipular los datos. La comunicacin y la coordinacin entre componentes se consiguen
a travs del paso de mensaje. La representacin de los datos y sus operaciones primitivas
asociadas son encapsuladas en un tipo de dato abstracto u objeto.

Caractersticas

En este estilo los componentes son los objetos, o instancias de tipos de datos
abstractos.

Estos objetos son de un tipo de componente denominado manager porque es

responsable por preservar la integridad de un recurso.

Los objetos interactan a travs de invocaciones a procedimientos y funciones.

Aspectos importantes

Un objeto es responsable de preservar la integridad de su representacin (usualmente

manteniendo algn invariante).

La representacin se oculta a otros objetos.

Ventajas

Como un objeto oculta su representacin a sus clientes, es posible cambiar su

implementacin sin modificar los clientes: modificabilidad.

La integracin de un conjunto de rutinas de acceso con los datos que manipulan

permite a los diseadores descomponer los problemas en colecciones de agentes que
interactan.

Desventajas

Para que un objeto interacte con otro (mediante la invocacin a un procedimiento)

debe conocer la identidad del otro objeto. Luego, cuando la identidad de un objeto cambie es
necesario modificar todas las invocaciones a tal objeto.
 Se pueden presentar efectos laterales: si los objetos A y C usan al objeto B, entonces
los efectos de C en B lucen como efectos laterales no esperados en A, y viceversa.

Patrones arquitectnicos:

son los que definen la estructura de un sistema software, los cuales a su vez se componen de
subsistemas con sus responsabilidades, tambin tienen una serie de directivas para organizar
los componentes del mismo sistema, con el objetivo de facilitar la tarea del diseo de tal
sistema.

Un patrn de arquitectura de software describe un problema particular y recurrente del

diseo, que surge en un contexto especfico, y presenta un esquema genrico y probado de su
solucin

Generalmente los patrones de diseo y arquitectura definen soluciones para medios

repetitivos.

En este momento, podemos ver la arquitectura de software como una abstraccin del sistema
que nos permite observar su estructura y sus relaciones. Para el desarrollo del diseo
arquitectnico se recomiendan seguir los siguientes pasos:

a) Estructuracin del sistema

b) Modelado de control

c) Descomposicin modular

Por otro lado, existen diferentes estilos arquitectnicos, a continuacin mencionaremos

algunos de ellos.

La Arquitectura de Flujo de Datos parte del DFD para obtener una arquitectura del sistema:

Se establece el tipo de flujo de informacin Se indican los lmites del flujo

Se convierte el DFD en una estructura del programa

Se define la jerarqua de control mediante particionamiento.

Se refina la estructura resultante utilizando heursticas de diseo.

La arquitectura centrada en datos tiene como componente principal un repositorio, del cual
surgen los dems componentes.

Las arquitecturas estratificadas son de las ms utilizadas en la actualidad, dado que dividen las
actividades y responsabilidades de sistemas por capas. El software ms elaborado como los
sistemas operativos, software de base, sistemas distribuidos y otros maneja variantes de esta
arquitectura.

El diseo se debe refinar realizando cada uno de los siguientes pasos:

a) Desarrollar una descripcin del procedimiento para cada mdulo.

b) Desarrollar una descripcin de la interfaz para cada mdulo.

c) Se definen las estructuras de datos generales y globales.

d) Se anotan todas las limitaciones/restricciones del sistema.

Se debe refinar el diseo hasta que est completo. Se recomienda completar la arquitectura
con el diseo de interfaces.

Los patrones de diseo, tambin nos ayudarn a especificar las interfaces, identificando los
elementos claves en las interfaces y las relaciones existentes entre distintas interfaces.

El diseo de interfaces se refiere al estudio de las relaciones entre los usuarios y las
computadoras para que un sistema se pueda ejecutar. El diseo de una interfaz puede definir
el xito de cualquier proyecto, ya que la utilizacin de cualquier interfaz de usuario depende
de factores humanos.

Existen algunas reglas de oro para el buen diseo de interfaces de usuario, stas son:

dar el control al usuario;

reducir la carga de memoria del usuario;

y, construir una interfaz consecuente.

Patrones Arquitectnicos

Los patrones arquitectnicos se utilizan para expresar una estructura de organizacin base o
esquema para un software. Proporcionando un conjunto de sub-sistemas predefinidos,
especificando sus responsabilidades, reglas, directrices que determinan la organizacin,
comunicacin, interaccin y relaciones entre ellos.

Los patrones arquitectnicos heredan mucha de la terminologa y conceptos de patrones de

diseo, pero se centran en proporcionar modelos y mtodos re-utilizables especficamente
para la arquitectura general de los sistemas de informacin. En otras palabras quiere decir que
a diferencia de los patrones de diseo estas son plantillas incompletas y no se pueden aplicar
directamente al cdigo con modificaciones meramente contextuales. Los patrones
arquitectnicos a su vez se salen del cdigo puro de la aplicacin y suben e incluyen software,
hardware, redes, inclusos las personas.

Dentro de los patrones arquitectnicos podemos encontrar:

Modelo Vista Controlador: es uno de los modelos ms antiguos (Smalltalk-80) y por lo tanto
se convirti en uno de los patrones fundamentales para el desarrollo de software. MVC a
grandes trazos, separa las preocupaciones con respecto a los datos (modelo) y la interfaz de
usuario (vista/GUI), permitiendo modificaciones independientes en cada una las partes sin
afectar la otra, o sea, para que los cambios realizados en la interfaz de usuario (GUI) no afectan
el manejo de datos, y los datos pueden ser reorganizados sin cambiar la interfaz de usuario.

Inyeccin de Dependencias: es un patrn que a pesar de ser relativamente nuevo es muy

complejo. La utilizacin de inyeccin de dependencia en un proyecto es tan incidente, que
puede modificar en grandes proporciones la arquitectura, de modo que se hace prudente una
planificacin a futuro sobre la utilizacin de este patrn. Este patrn puede dar la impresin de
ir un poco al revs, porque el mismo, se trata de una aplicacin de la Inversin de Control
IoC, concepto que hace exactamente eso, se invierte el flujo de control. El nombre de la
inyeccin de dependencia en realidad se presta a confusin, ya que el modelo permite que se
inyecte no dependencias en s, sino en su lugar, la informacin para satisfacerlas la relacin a
las dependencias.

Arquitectura dirigida por eventos (Event-driven architecture o EDA): es un patrn de

arquitectura software que para orquestar su comportamiento se centra en torno a la
produccin, deteccin, consumo y respuestas ante eventos. Teniendo en cuenta que un
evento es: cualquier ocurrencia identificable que tiene un significado para el hardware o el
software del sistema, en otras palabras, cualquier cambio de estado significante para el
sistema. Y a su vez este cambio de estado puede ser conocido por otras aplicaciones en la
arquitectura, o sea, que cada evento se propaga de manera inmediata a otras partes del
sistema en la medida que sea necesario.

Arquitectura orientada a servicios: La Arquitectura Orientada a Servicios de cliente (Service

Oriented Architecture), es un concepto de arquitectura de software donde el software consta
de una composicin de servicios, prestaciones y reglas, y son los requisitos del negocio los que
dictaminan la manera en la que estas se nter-relaciona. Esta diseado para que el sistema sea
altamente escalable y flexible a nuevos requerimientos.