U2 Modelos de Arquitectura

Diseo y Arquitectura de Software
Unidad 2. Modelos de Arquitectura

Ciencias Exactas, Ingenieras y Tecnologa | Ingeniera en Desarrollo de Software
1

Ingeniera en Desarrollo de software
5 Cuatrimestre

Programa de la asignatura:

Clave: 150920517/ 150920517

Universidad abierta y a distancia de Mxico


2

ndice

UNIDAD 2. MODELOS DE ARQUITECTURA.................................................................... 3
Presentacin de la unidad ........................................................................................................... 3
Propsito ........................................................................................................................................ 3
Competencia especfica .............................................................................................................. 3
2.1. Patrones y arquitectura de software .................................................................................. 3
2.1.1. Tipos de patrones y arquitectura .................................................................................... 5
2.1.2. Caractersticas de patrones y arquitectura .................................................................... 7
Actividad 1. Patrones aplicables a la arquitectura de software. ............................................ 8
2.2. Patrones de estructura ......................................................................................................... 9
2.2.1. Capas en modelos arquitectnicos .............................................................................. 10
2.2.2. Tuberas y filtros .............................................................................................................. 15
2.2.3. Tableros ............................................................................................................................ 17
Actividad 2. Caso de estudio .................................................................................................... 17
Actividad 3. Contrastando arquitectura y patrn de diseo. ................................................ 19
Autoevaluacin ........................................................................................................................... 19
Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de software 19
Autorreflexiones .......................................................................................................................... 20
Cierre de la unidad ..................................................................................................................... 20
Para saber ms ........................................................................................................................... 20
Fuentes de consulta ................................................................................................................... 21


3


Presentacin de la unidad

En esta segunda unidad revisars de manera profunda los patrones de arquitectura y su
influencia sobre la arquitectura de software, los tipos que existen y las caractersticas de
cada patrn; asimismo conocers las distintas propuestas existentes en la industria del
desarrollo de software.

Los temas desarrollados en la unidad te ayudarn a identificar el modelo adecuado a
aplicar para una determinada problemtica en el desarrollo de software.

Finalmente distinguirs diferencias primordiales en los estndares ms aplicados y
extendidos en la industria del desarrollo de software.

Bienvenido(a) a la unidad 2!

Propsito

Analizar los tipos de patrones aplicables a la arquitectura de software para poder proponer
una solucin preliminar a un problema sobre la base de los requerimientos de software
dados por el usuario o patrocinador.

Competencia especfica

Disear una propuesta de arquitectura para el diagnstico de informacin de los usuarios,
mediante el anlisis y uso de herramientas de diferentes tipos de sistema.
2.1. Patrones y arquitectura de software

Los patrones arquitectnicos son una forma clara de plasmar la solucin de un problema
mediante el uso de arquitectura de software, se usa tambin para comunicar diseo
arquitectnico a las etapas posteriores del desarrollo de software.

En el sentido estricto de la palabra, un patrn es un modelo que se toma como muestra
para reproducir un objeto o concepto igual (RAE, 2012a). Para complementar la
definicin de un patrn tenemos que, un modelo representa una realidad o un sistema
que se distinguen por ser complejos, generalmente la representacin con el uso de un
lenguaje matemtico formal (RAE, 2012b).


4

De las definiciones anteriores se puede deducir que ambas llevan a formar un estilo
propio de cmo hacer las cosas para poder explicar un sistema o una realidad compleja.
Entonces, podemos definir al estilo como Cada una de las distintas formas de realizar
algo. Esta consecucin de definiciones y deducciones nos lleva a comprender lo bsico
de los Patrones Arquitectnicos o Estilos Arquitectnicos.

En los ltimos aos la sistematizacin de los estilos arquitectnicos ha sido uno de los
temas ms recurrentes; sin embargo, solo en breves ocasiones la literatura tcnica
especializada sobre patrones arquitectnicos realmente hace un buen anlisis del vnculo
innegable entre estilos y patrones. Suele decirse que estn ntegramente comunicados, y
se deja muy poco clara la barrera de separacin entre uno y otra, pero nadie se atreve a
articular de forma sistemtica y formal su relacin.

Para no seguir con discusiones que por ahora son interminables, se abordar
directamente el tema de estilos arquitectnicos, que con las definiciones dadas al
introducir el tema se dir que es semejante a un patrn arquitectnico; adems, a manera
aclaratoria, se tiene que una diferencia bsica entre ellos se da porque aquellas personas
que trabajan con estilos se inclinan hacia un tratamiento que lleva una alta carga terica,
un enfoque acadmico y de abstraccin mucho ms elevado para su aplicacin, mientras
las personas que trabajan con patrones se inclinan por el diseo, lo prctico, la
implementacin en aspectos reales, el refinamiento y el cdigo duro.

Antes de siquiera pensar en definir lo que es un estilo arquitectnico, se debe entender
cul fue el origen. En los principios se detect repeticin en el comportamiento de las
soluciones de Arquitectura de Software (AS) aplicadas a problemas similares. El nmero
de apariciones del comportamiento fue limitado, pero repetible, y tomando como
referencia la arquitectura en edificios reales, se les llam estilos.

Un estilo es una clase o tipo de arquitectura o piezas repetibles que se dieron con el
andar de las cosas. Y no se debe hacer mucho esfuerzo por encontrar esas piezas, pues
la misma prctica va otorgndolas. Cuando se han identificado de manera clara estas
piezas (estilos) por sentido comn y lgica se puede pensar en volver a utilizarlos en
ambientes y situaciones parecidas a aquellos en los cuales surgieron.

Los identificadores comnmente dados, entre otros, a los estilos arquitectnicos son:
Cliente-servidor
Modelo-vista-controlador
Tubera-filtro
Arquitectura en capas

Si los nombres que aparecen en la lista anterior parecen conocidos, es porque se
comparten con los patrones de arquitectura; esto quiere decir que si las caractersticas de
un patrn de arquitectura son similares a las caractersticas de un estilo arquitectnico, se

5

usa el mismo nombre. Para poder hacer una clara distincin entre los estilos
arquitectnicos y los patrones de arquitectura convendr poder diferenciarlos por los
diferentes tipos que ellos tienen.

2.1.1. Tipos de patrones y arquitectura

Existen diferentes tipos de patrones aplicables en la AS, los cuales se usan dependiendo
de la naturaleza del problema a resolver; sirven para tomarlos como punto de partida, ya
que se usan como andamiaje para construir la solucin sobre una idea ya avanzada y no
comenzar siempre la solucin desde la nada.

Tratar de hacer un catlogo detallado de los tipos de estilo sera una idea poco prctica,
pues cada autor, e inclusive cada arquitecto, podran dar una lista propia a su gusto. Por
ello slo se enumerarn las consideraciones primarias de la literatura tcnica
especializada sobre patrones arquitectnicos y se podr tomar como una clasificacin de
primer orden.

La enumeracin primaria de la que se hace mencin puede llevar a preguntarse:

Cuntos estilos existen?
Cules son?
Son suficientes?

La idea de organizar los patrones y sus tipos comenz por la necesidad de hacer una
distincin clara entre ellos, pues el nmero de patrones que se estaba conociendo lleg a
ser tan alto que haba siempre confusiones. De acuerdo con Reynoso y Kicillof (2004), la
siguiente lista se puede tomar como una primera propuesta:

Arquitectura orientada a objeto
Arquitectura de estados
Arquitecturas de control de realimentacin
Arquitectura de tiempo real
Modelo de diseo de descomposicin funcional
Modelo orientado por eventos
Modelo de control de procesos
Modelo de tabla de decisin

En un segundo acercamiento, al refinar la lista anterior, surge la necesidad de replantear
la clasificacin (combinando arquitecturas y modelos de diseo), llegando a la lista
siguiente:
Tubera-filtros
Organizacin de abstraccin de datos
Invocacin implcita

6

Sistemas en capas
Repositorios
Intrpretes orientados por tablas
Procesos distribuidos.
Organizaciones programa principal-subrutina.
Arquitecturas de software especficas de dominio
Sistemas de transicin de estado
Sistemas de procesos de control
Estilos heterogneos

Para escribir los acercamientos anteriores (el primero y su refinamiento) se tom como
base la informacin contenida en el material de Reynoso y Kicillof (2004).

Ntese que las clasificaciones presentadas tienen un parecido amplio, pues ambas estn
sobre la base de listar estilos que se usan para poder expresar algn tipo de organizacin
estructural claramente definido, adems son parte sustantiva para los sistemas de
software, pues estos, por definicin basan su estructura en una organizacin jerrquica,
que con los estilos arquitectnicos se puede detallar de manera prctica y clara,
incluyendo sus subsistemas (como el software mismo en su definicin ms ortodoxa) qu
y cules son los procesos que debe seguir (especifican responsabilidades y lineamientos
para organizar las relaciones entre ellos), a continuacin se puntualizan estos patrones:
o Capas
o Tubera-filtros
o Pizarra
o Sistemas distribuidos
Brker
CAGS
Cliente-Servidor.
o Sistemas interactivos
Modelo-vista-controlador
Presentacin-abstraccin-control
o Sistemas adaptables
Reflexin
Microkernel

En los escritos de Reynoso y Kicillof (2004) sobre estilos arquitectnicos se propone una
sistematizacin en cinco grupos:
1. Flujo de datos
a. Proceso secuencial por lotes
b. Red de flujo de datos
c. Tubera-filtros
2. Llamado y retorno (estilo dominado por orden de computacin, usualmente con un
solo thread de control).
a. Programa principal / Subrutinas
b. Tipos de dato abstracto

7

c. Objetos
d. Cliente-servidor basado en llamadas
e. Sistemas en capas
3. Componentes independientes (dominado por patrones de comunicacin entre
procesos independientes, casi siempre concurrentes)
a. Sistemas orientados por eventos
b. Procesos de comunicacin
4. Centrados en datos (dominado por un almacenamiento central complejo,
manipulado por computaciones independientes)
a. Repositorio
b. Pizarra
5. Mquina virtual (caracterizado por la traduccin de una instruccin en alguna otra)
a. Intrprete

Dentro de estas cinco clases de todos los estilos arquitectnicos, quedan fuera de ellas
algunos muy importantes, aunque en trminos generales si se presentaran ms
clasificaciones o tipos de patrones o estilos arquitectnicos se estara dando vueltas sobre
lo mismo, de tal forma que puede resumirse en la siguiente tabla:

Categoras de tipos de patrones arquitectnicos
Patrones simples
Capas
Tubera-filtro
Pizarra
Repositorio
Sistemas distribuidos
Broker
CAGS
Cliente-Servidor
Sistemas interactivos
Modelo-Vista-Controlador
Presentacin-Abstraccin-control
Patrones adaptables
Microkernel
Reflexin

La serie de listas y categoras presentadas en el apartado actual permitirn tener una
clara diferenciacin entre los tipos de patrones y en dnde ubicarlos respecto del tipo de
sistema al cual pertenecen. Otro punto a tomar en cuenta para la correcta clasificacin
son las caractersticas propias de cada tipo de patrn.

2.1.2. Caractersticas de patrones y arquitectura

La principal caracterstica de un patrn arquitectnico es la comunicacin de diseos. Una
caracterstica es un rasgo distintivo que slo posee algo (un objeto, persona, animal, entre
otros) o un grupo de ellos. Otras caractersticas que se pueden enumerar respecto a los
patrones de diseo, son:

No reinventan soluciones a patrones conocidos.
Rehsan el conocimiento experto relativo a un diseo

8

Personas inexpertas pueden fcilmente hacer un diseo de alta calidad gracias a
los patrones.
Se tienen menores errores al modelar la arquitectura de la solucin debido al uso
de diseos ya probados y que solucionaron problemas similares.
Los diseos que estn probados son fcilmente mantenibles.
A partir de los patrones, el software puede disearse para tener ciertas
caractersticas deseadas por el cliente o que la misma solucin necesite.

Adems de la lista presentada, se debe tener en cuenta algo muy importante: cuando se
trata de caractersticas de patrones de software no toda aquella solucin que tenga un
cierto parecido a esta lo es. Deben hacerse pruebas (de compatibilidad entre soluciones,
de similaridad, de homogeneidad, entre otras) a problemas que tienen las mismas
premisas, y si es aplicable, se considerar un patrn. Sin embargo, deber pasar adems
una serie de pruebas aplicadas nica y particularmente a los patrones. Antes de estas
pruebas, la mencionada solucin no dejar de ser un patrn-primigenio.

Cuando un patrn haya pasado el conjunto de pruebas que haya que aplicar, tendr las
siguientes caractersticas:
Solucionar un problema: si no puede hacer ms all de tener principios o
estrategias abstractas, entonces no ser patrn.
Ser un concepto probado: como el punto anterior, si no ofrecen soluciones
plenamente demostrables, entonces no ser patrn.
La solucin no es obvia: un patrn busca soluciones a problemas complejos de
forma que abstraen dentro de s soluciones pequeas para cada parte del
problema o de forma indirecta.
Describe participantes y relaciones entre ellos: se describe de manera clara y
detallada un sistema completo, no slo mdulos aislados. El nivel de complejidad
puede crecer sin causar problema para el patrn arquitectnico.
El patrn tiene un componente humano significativo: la principal razn de fabricar
(o disear) software es para facilitar el trabajo humano, de manera directa o
indirecta.

Otra caracterstica necesaria de los patrones arquitectnicos, mas no suficiente, es la
repeticin, si no la tiene entonces no es un patrn.

En trminos formales se definir que:
La repeticin se debe tomar como una caracterstica cuantitativa
La utilidad y adaptabilidad como caractersticas cualitativas.

Para poder comprobar la existencia o ausencia de estas caractersticas se proponen en
diferentes textos algunas formas empricas de poder hacerlo, el cual no es tema a tratar
en la presente asignatura.

Actividad 1. Patrones aplicables a la arquitectura de software.

Ahora que ya se comprendieron los temas expuestos previamente, podrs participar en la
wiki con el anlisis de patrones aplicables a la arquitectura de software, donde

9

colaborars con el resto de tus compaeros de la asignatura para formar entre todos una
arquitectura base haciendo uso de los conocimientos adquiridos.
El propsito es la construccin de conceptos para el correcto anlisis de los patrones
aplicables a la arquitectura de software.
Por la misma naturaleza de la herramienta wiki, harn en grupo esta tarea formativa y
acumulativa de los conceptos de los patrones aplicables a la arquitectura de software.

Instrucciones

Un integrante del grupo de estudiantes, a voluntad o por indicacin del (la)
Facilitador(a), deber aadir un primer comentario donde explique la elaboracin
de su arquitectura base; el (la) Facilitador(a) puede designar a ms de un
estudiante para este punto, y lo har pblico dentro de la wiki.
Los dems integrantes del grupo debern verter opiniones sobre la arquitectura
presentada por el (la) primer(a) compaero(a). Estos comentarios debern
encaminarse hacia el fortalecimiento de las reas de oportunidad observadas
entre todo el grupo.
El (la) Facilitador(a) designar a los participantes que debern realizar las
correcciones pertinentes de cada arquitectura expuesta, de acuerdo a los
comentarios recibidos, y publicar de nuevo la propuesta.
Todos(as) debern aplicar en un prrafo inferior a los puntos anteriores las
mejoras pertinentes a la propia arquitectura y la habrn de subir (a manera de
descripcin escrita) a la plataforma. El (la) primero(a) que realice este punto
deber colocar el ttulo Propuestas de mejoras para comenzar su participacin.
Cada integrante del grupo de estudiantes deber comentar por lo menos una
posible mejora para cada arquitectura que est expuesta.
Al final debern elegir cul es la ms completa (despus de las mejoras) en una
votacin, de la cual el (la) Facilitador(a) publicar los resultados.
2.2. Patrones de estructura

La base sobre la cual est formado cualquier sistema es una estructura que puede ser
fsica o lgica.

Esta estructura puede ser completamente nueva, respecto al problema que se quiera
resolver, o estar tomando fundamentos de conocimientos aplicado antes a la resolucin
de problemas parecidos, en donde se esperan resultados similares, en tiempo y espacio
similar; los patrones de estructura surgen cuando se cumplen las condiciones antes
mencionadas.

La aplicacin formal de los patrones de estructura a una arquitectura de software debe
hacerse de manera sistemtica y organizada, no se puede resolver el problema al que el
arquitecto se enfrenta con la sola aplicacin de un patrn determinado. Esta organizacin
estructurada la proporcionan las capas en modelos arquitectnicos.


10

2.2.1. Capas en modelos arquitectnicos

Los sistemas computacionales organizados en capas (o arquitectura de software en
capas) es uno de los hitos que mayormente aparece referido en la literatura especializada
en arquitectura de software. La arquitectura en capas intenta hacer una discriminacin
formal de los estilos o patrones arquitectnicos separando en piezas (o subsistemas) la
solucin de software. El objetivo principal de la separacin de los distintos componentes
del software (la lgica del negocio, la vista del usuario, la capa de datos, entre muchas
otras) es tener piezas identificables y unificadas sobre la base de la labor que
desempearn dentro de la solucin completa. Cada capa de software en los modelos
arquitectnicos es una parte que coopera para lograr los objetivos del propio sistema.

La principal razn por la cual es ampliamente usado este tipo de patrn de arquitectura,
es la facilidad de mantenimiento que ofrece al software que se aplica. Como los niveles se
separan y no dependen directamente uno del otro, ni entre ellos, cuando viene un cambio
se ataca sin mayor dificultad la capa especfica a la cual se deber hacer la correccin o
mejora.

El patrn arquitectnico en capas es ms una organizacin jerrquica, de manera que
cada capa da servicio a la capa inmediatamente superior y consume los servicios de la
capa dispuesta en el inmediato inferior. Esto es muy parecido a la organizacin que se
sigue en distintos mbitos de la vida diaria no slo del software, y por eso es otra razn
por la cual su comprensin es tan fcil y natural para cualquier persona.

La manera de organizarlo tambin es igual que una estructura jerrquica (por niveles): las
capas inferiores estn ocultas para todos (por cualquier razn que el lector desee
considerar), excepto para las capas que hacen consumo de sus servicios. En trminos
prcticos, y para clarificar: una capa solo sabe de su vecino superior e inferior. En otro
tipo de sistemas las capas pueden ser parcialmente visibles. Cuando se transportan estos
conceptos a la vida diaria, una capa es una entidad compleja formada por varios paquetes
o subsistemas; en casos de extrema refinacin, una capa puede estar formada por otras
capas. Su uso est ampliamente extendido en los sistemas de software que cualquier
persona aplica en sus labores de la vida diaria.

Como en todo sistema (en su definicin ms genrica) los componentes deben tener un
canal bien establecido de comunicacin, en este caso los componentes del sistema son
las capas. La manera en que se comunican las capas son los conectores, y la forma de
comunicacin est definido por los protocolos que determinan la interaccin entre ellas.
La sensacin de pertenencia de un nivel superior con otro inferior se da de manera natural
en este patrn arquitectnico; su representacin suele hacerse con conectores y se
entiende que la relacin es de arriba abajo y de abajo a arriba. Inclusive es tan natural su
uso y representacin que se puede representar con crculos concntricos denotando
jerarqua entre sus elementos y sus pertenencias. Ahora observa la siguiente imagen para
que comprendas lo explicado:


11

Arquitectura N-Layer DDD en VS.2010 (De la Torre y otros, 2010)

Aunque no todo es perfecto: este tipo de patrn arquitectnico tiene una gran desventaja
que es su topologa. De manera natural, como ya se mencion, las capas solo conocen
entre su vecindad y esto mismo hace que solo se puedan considerar soluciones con esta
ventaja/desventaja, pues si surge la necesidad de comunicar una capa con otra y su nivel
de relacin no es de primer orden, deber recurrirse a mtodos no tan transparentes para
poder lograrlo. Si esta capacidad de comunicacin solo entre vecinos se deja un poco de
lado, pierde por completo la razn de ser y su estilo ms puro, como se debe seguir
siempre.

Si se sigue el mtodo relajado de dejar al mnimo la independencia entre capas o mdulos
de ellas, se llegar al punto donde la mezcla de las capas ser muy fuerte, y entonces al
menor cambio de requerimientos se deber trabajar sobre dos (o ms) capas distintas
para poder hacer la modificacin requerida, haciendo el grado de mantenimiento muy
complejo, se pierde la capacidad de mover o reemplazar una capa completa sin afectar a
las dems, disminuyendo la flexibilidad de los grnulos y del conjunto por propia
definicin.

12

Arquitectura 3-Tier, fsica (De la Torre y otros, 2010)

En este tipo de patrn hay una premisa bsica: cada capa debe hacer algo, siempre. En
la literatura especializada se pueden encontrar argumentos a favor o en contra de esta
aseveracin. Muchas capas pueden eventualmente degradar el rendimiento de la
aplicacin; pero muchas veces se tiene que echar mano de soluciones no tan puras para
poder brindarle rendimiento a la aplicacin, por ejemplo que una regla de negocio se
programe como un procedimiento almacenado en el lado de los datos, o haciendo
sentencias de consulta a base de datos desde la capa de presentacin.

Ante todo esto es natural preguntarse por el nmero adecuado de capas, y la respuesta
es que depender de cada sistema; el nmero mnimo es dos, y el mximo lo determinar
cada problema que se quiera resolver con este patrn arquitectnico. Hay sistemas que
llegan a los cientos de capas y cada una de ellas est conformada por otro tanto.


13

Arquitectura N-Capas con Orientacin al Dominio (De la Torre y otros, 2010)

Cuando se habla de una aplicacin de N capas (De la Torre, 2010) se puede decir que
son:
Capa de Presentacin
o Subcapas de Componentes Visuales (Vistas)
o Subcapas de Proceso de Interfaz de Usuario (Controladores y similares)
Capa de Servicios Distribuidos (Servicios-Web)
o Servicios-Web publicando las Capas de Aplicacin y Dominio
Capa de Aplicacin
o Servicios de Aplicacin (Tareas y coordinadores de casos de uso)
o Adaptadores.
o Subcapa de Workflows (Opcional)
o Clases base de Capa Aplicacin (Patrn Layer-Supertype)
Capa del Modelo de Dominio
o Entidades del Dominio
o Servicios del Dominio
o Especificaciones de Consultas (Opcional)
o Contratos/Interfaces de Repositorios
o Clases base del Dominio (Patrn Layer-Supertype)
Capa de Infraestructura de Acceso a Datos
o Implementacin de Repositorios

14

o Modelo lgico de Datos
o Clases Base (Patrn Layer-Supertype)
o Infraestructura tecnologa ORM
o Agentes de Servicios externos
Componentes/Aspectos Horizontales de la Arquitectura
o Aspectos horizontales de Seguridad, Gestin de operaciones,
o Monitorizacin, Correo Electrnico automatizado, etc.

Quedarse con el concepto abstracto de capas te ser suficiente para poder lograr una
comprensin bsica de su aplicacin, pero si se trata de disear una AS de nivel
profesional, debes comprender cada concepto que las conforma y poder llevar su uso de
manera correcta en el problema especfico. A continuacin se presenta una descripcin
de las principales y ms usadas capas dentro de la AS:

Capa de presentacin al usuario
Es la primera capa donde tiene contacto el usuario y es ah donde l mismo realiza el
trabajo propio de la aplicacin; recibe informacin del exterior y la presenta dependiendo
de los resultados que haya obtenido. Se encarga de comunicar la informacin procesada
desde las capas inferiores hacia el usuario, solo presenta lo que necesita, refinando la
presentacin. Hace composicin y filtrado de datos para hacer un resumen al usuario y no
presentarle los datos en crudo.
Los componentes de las capas de presentacin implementan la funcionalidad requerida
para que los usuarios interacten con la aplicacin.

Capa de Aplicacin
Situar la realidad del software en el contexto especfico de aplicacin es importante para
saber qu es lo que har esta capa. El contexto donde trabajar el software es importante
para poder decidir qu arquitectura se utilizar para conocer el dominio de aplicacin.
Esta capa forma parte de la propuesta de arquitecturas orientadas al dominio.

Capa del Dominio
Es en esta capa donde se implementan y desarrollan todas las reglas de negocio que el
cliente haya solicitado como resultado de la etapa de anlisis del problema, es aqu donde
se establecen las reglas del juego; es responsable de representar conceptos de
negocio, informacin sobre la situacin de los procesos de negocio e implementacin de
las reglas del dominio

Capa de Infraestructura de Acceso a Datos
Los datos que genera una aplicacin deben ser independientes en su manejo respecto al
funcionamiento de la plataforma en general. Su integridad debe ser lo principal que se
busca y no debe estar mezclado su manejo dentro la lgica del negocio o de la
presentacin de los mismos.

Un ejemplo claro de esto es: en donde la aplicacin est alojada en un servidor en Los
ngeles, California, y los datos que usa esta aplicacin estn alojados en Argentina. La
independencia entre los datos debe ser total. As pues, esta capa de persistencia de datos
expone el acceso a datos a las capas superiores (normalmente las capas del dominio).
Esta exposicin deber realizarse de una forma desacoplada.


15

En este mismo escrito (De la Torre, 2010) se hace una importante mencin del
desacoplamiento de las capas. La dependencia entre ellas debe ser hasta cierto punto
nula y en un mundo ideal poder trabajar solamente la capa realizando su funcin de
presentar informacin al usuario, manipular, obtener y guardar datos y as cada capa no
depender de alguna otra, y aunque el sistema est cohesionado, el grado de
desacoplamiento asegurar que su funcionamiento sea el correcto, de tal manera que es
fundamental destacar que no solo se deben de delimitar los componentes de una
aplicacin entre diferentes capas. Adicionalmente, tambin debe tenerse especial
atencin en cmo interaccionan unos componentes/objetos con otros, es decir, cmo se
consumen y en especial cmo se instancian unos objetos desde otros. En general, este
desacoplamiento debera realizarse entre todos los objetos (con lgica de ejecucin y
dependencias) pertenecientes a las diferentes capas, pues existen ciertas capas que
puede interesar mucho el que se integren en la aplicacin de una forma desacoplada.
Este es el caso de la mayora de capas de Infraestructura (ligadas a unas tecnologas
concretas), como puede ser la propia capa de persistencia de datos, que puede haberse
ligado a una tecnologa concreta de ORM (por sus siglas en ingls, Object-Relational
mapping) o incluso a un acceso a backend externo. En definitiva, para poder integrar esa
capa de forma desacoplada, no se deben instanciar directamente sus objetos.

Pero la esencia final de la separacin de las partes del software en capas, realmente trata
del desacoplamiento entre cualquier tipo/conjunto de objetos, bien sean conjuntos de
objetos diferentes dentro del propio Dominio, o bien, en los componentes de Capa de
presentacin poder simular la funcionalidad de Servicios-Web, o en la Capa de
Persistencia poder tambin simular otros Servicios-Web externos y en todos esos casos
realizarlo de forma desacoplada para poder cambiar de la ejecucin real a la simulada o a
otra ejecucin real diferente, con el menor impacto. En todos esos ejemplos tiene mucho
sentido un desacoplamiento de por medio.

La organizacin de las capas debe tener una comunicacin clara u homognea para ser
transparente en su acoplamiento.

2.2.2. Tuberas y filtros

Este tipo de patrn arquitectnico pertenece a una clasificacin (familia) de patrones que
se centra primordialmente en la reutilizacin y la modificacin. Por ejemplo: si se est
realizando alguna arquitectura de un banco donde sus datos necesitan una serie de
condiciones (paso del tiempo, sucesiones anteriores, entre otras) la arquitectura de
tuberas y filtros es la indicada. Lo que normalmente se conoce como proceso por lotes.

Por lo descrito en el prrafo anterior, normalmente se dice que el patrn arquitectnico de
tuberas y filtros pertenece a las llamadas arquitecturas de flujo de datos. Se relaciona con
redes de procesos y procesos secuenciales (procesos por lotes). Una idea que ha
persistido y que podra considerarse una buena rea de oportunidad es que la parte de
los filtros comnmente realiza esta tarea, filtrar; pero no es forzoso que lo haga siempre,
por tanto la forma ms pura no se respeta.

Para conectar componentes computacionales, se ha apoyado de muchas tcnicas y
protocolos diferentes, desde el paso de mensajes entre objetos hasta los mtodos

16

asncronos ms modernos. En el caso de este patrn arquitectnico, el mtodo de
comunicacin son las tuberas. La nomenclatura especfica es, en correspondencia
directa:

Objeto Descripcin
Componentes computacionales Filtros
Conectores Tubos/tuberas

La tabla anterior obedece al orden en que el flujo de datos va de manera secuencial,
directa. Los datos se transportan de manera que se ve cmo los datos se convierten en
entrada o salida (depende de la perspectiva) de un filtro a otro. Como puedes observar, la
simplicidad de este patrn arquitectnico es obvia y puede tomarse muy a la ligera, pero
la potencia de resolucin de problemas es muy amplia debido a que gran parte de los
problemas a los que se enfrentan las soluciones basadas en software en la actualidad
obedecen a este tipo de estructura organizacional.

La siguiente imagen representa algo muy familiar para cualquier persona:

La numeracin presentada en la imagen obedece al flujo que sigue el agua cuando es
distribuida en una casa habitacin, algo bastante normal de conceptualizar para
cualquiera.
Esta misma familiaridad y sencillez del patrn arquitectnico da para poder aplicarlo a
muchos escenarios del mbito de la arquitectura de software. Nota cmo el flujo del agua
(datos, en nuestro caso) es simple y muy fcil de deducir hacia donde ser la siguiente
iteracin.

Adems de la sencillez explicada con el ejemplo del flujo del agua, otro punto importante
a considerar es que este patrn arquitectnico debe ser percibido como una serie de
transformaciones sucesivas, donde el flujo de datos se da a travs de las tuberas y los
filtros, que son quienes realizan las dichas transformaciones. En el estilo secuencial por
lotes (batch sequential) los componentes son programas independientes; el supuesto es
que un paso no puede seguir hasta que el anterior est completo, como sucede en la
distribucin del agua, si no ha llegado al repositorio de la casa habitacin, no puede
distribuirse a los aparatos que requieran de ella.

17

Cmo y cundo se debe aplicar este tipo de patrn arquitectnico? Este estilo debe
aplicarse cuando:
Se puede especificar la secuencia de un nmero conocido de pasos.
No se requiere esperar la respuesta asincrnica de cada paso.
Se busca que todos los componentes situados corriente abajo sean capaces de
inspeccionar y actuar sobre los datos que vienen de corriente arriba (pero no
viceversa).

De igual manera, se reconocen como ventajas del estilo tubera-filtros:
Es fcil de implementar.
Obliga a que el proceso se lleve a travs de una forma secuencial.
Es fcil aislar en una operacin con un nico resultado.
Los filtros se hacer fcilmente distribuibles.
Desventajas:
El patrn puede resultar demasiado simplista, especialmente la ejecucin de la
lgica de negocios de formas complicadas.
No maneja con demasiada eficiencia lgica de negocios donde se involucren
decisiones o repeticiones para el control del flujo.
Eventualmente puede llegar requerir almacenamiento de tamao no conocido.
No es apto para manejar situaciones de relacin entre distintos actores, sobre todo
cuando se necesita la presentacin de datos a una salida estndar, como una
pantalla de computadora.

2.2.3. Tableros

Cuando se habla del patrn arquitectnico tipo tablero se deben considerar dos
componentes principales siguientes:

Una estructura de datos que representa el estado actual.

Una coleccin de componentes independientes.

La aplicacin de este tipo de estilo arquitectnico es para problemas especializados,
como en la resolucin de problemas concernientes a inteligencia artificial, donde actan
mltiples agentes. La diversidad de soluciones que pueden alcanzar los agentes debe
manejarse en una arquitectura que soporte esta complejidad. Contrastando con estilos
arquitectnicos presentados en las pantallas anteriores, en aquellos la interaccin era
simple y directa entre partes bien definidas, por el contrario, en los tableros se hace
manejo de informacin de diversas fuentes (agentes). Se puede llamar arquitectura multi
agentes.

Actividad 2. Caso de estudio


18

La aplicacin de los modelos arquitectnicos debe hacerse sobre ejemplos que se
presentan en la vida diaria.

A continuacin se te presenta un caso de estudio en donde debers poner en prctica los
conceptos aprendidos hasta el momento. Debers considerar diferentes escenarios de
solucin al problema propuesto sobre la base del anlisis de los diferentes modelos y
decidir cul es el mejor para poder resolver el problema propuesto; la finalidad de la
actividad es que tengas de manera clara la aplicacin de los modelos arquitectnicos
comenzando con ejemplos sencillos, como el que se presenta. Cuando se haya
completado el temario hasta este punto, se presenta un FORO de discusin, creado para
que participes en l. La idea del foro es que con base en el conocimiento adquirido con la
consecucin de la unidad, seas capaz de hacer una propuesta de arquitectura con
relacin al caso de estudio que se describe enseguida:

Una tienda de conveniencia necesita automatizar sus procesos de compra, venta y
seguimiento de clientes. Lo desea hacer a travs de venta en lnea para sus clientes y
que sus proveedores puedan acceder a un sitio privado y vean automticamente las
existencias del producto que surten, al mismo tiempo los usuarios podrn comentar sobre
su experiencia de compra en lnea o en el sitio; estos comentarios los podrn hacer a
travs de un equipo de cmputo convencional o mediante un dispositivo mvil que ser
capaz de conectarse al sitio de la tienda. El gerente de la tienda necesita que se obtengan
tendencias de ventas y que se haga una posible sugerencia a los compradores sobre la
base a sus compras anteriores, y sobre todo considerando su perfil (se entiende que el
sistema deber generar ese perfil en el que se incluya la edad, el sexo, la ubicacin, los
amigos, las fotografas, su grado escolar y comentarios hechos). Deber ser fcil de usar
para todos los usuarios y deber manejar diferentes tipos de roles (administrador del sitio,
gerente general, gerente de tienda, vendedor, proveedor, usuario normal) y cada uno
tendr acceso a diferentes privilegios asignados por el administrador del sitio

1. Identifica qu ADLs (Lenguaje de Definicin de Arquitectura) ser el ms
apropiado para usar en este caso.
2. Identificar qu patrn ser el que se utilizar para representar esta arquitectura
propuesta.
3. Redactar en un archivo de cualquier procesador de texto una justificacin amplia
del por qu es el mejor patrn para solventar el caso de estudio presentado. Esto
implica proponer una Arquitectura base para el problema expuesto.
4. Guarda la actividad con el nombre DRS_U2_A2_XXYZ, y enva tu archivo de
propuesta al foro.
5. Participa en el foro comentando y enriqueciendo las propuestas de tus
compaeros(as).


19

Actividad 3. Contrastando arquitectura y patrn de diseo.

El uso de un patrn arquitectnico y saber la diferencia entre la variedad de ellos es
importante a la hora de seleccionar cul es el adecuado para resolver o proponer una
arquitectura. En esta actividad debers realizar una redaccin en donde expliques esta
diferencia entre los que se citan en el desarrollo del tema. El alumno deber investigar por
lo menos otros tres patrones arquitectnicos que no se encuentren descritos en el mismo
tema desarrollado en esta unidad. Redactar reporte escrito donde se explique y justifique
la razn por la cual se decidi utilizar el patrn de diseo seleccionado para la
construccin de la arquitectura.

Instrucciones:
1. Identifica qu es un patrn de arquitectura.
2. Redacta reporte escrito donde se describan las diferencias entre los distintos
patrones arquitectnicos y arquitecturas.
3. Guarda la actividad con el nombre DRS_U2_A3_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y
la Z por la inicial de tu segundo apellido.
4. Ingresa al apartado de Tareas.
5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

Autoevaluacin

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta
primera unidad del curso, es necesario que resuelvas el cuestionario de Autoevaluacin.
Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y
elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje. Lenguaje descriptor y patrones de
arquitectura de software

Para demostrar tu conocimiento acerca de los tipos de patrones arquitectnicos, t
disears una propuesta de arquitectura que sirva para solucionar un problema; para ello
considerars que el patrocinador (la empresa que solicit la solucin) es una tienda de
conveniencia, t analizars sus requerimientos de software y lo contrastars con las
herramientas de diferentes tipos de sistema, siendo capaz de elaborar una propuesta.

Como parte de la evaluacin de esta unidad, es necesario realizar en forma grfica la
arquitectura de una tienda de conveniencia aplicando y justificando el uso del patrn
especfico.


20

1. Justifica el uso del patrn.
2. Realiza la representacin de la arquitectura propuesta. Para hacer esta
presentacin, usars herramientas de diseo grfico de arquitectura y, en base a
los ejemplos mostrados en la unidad, hacer un diagrama con la arquitectura
propuesta.
3. Guarda la actividad con el nombre DRS_U2_EA_XXYZ. Sustituye las XX por las
dos primeras letras de tu primer nombre, la Y por la inicial de tu primer apellido y
la Z por la inicial de tu segundo apellido.
4. Enva el archivo a tu Facilitador(a) a travs de la seccin Evidencia de
aprendizaje.

Autorreflexiones

Adems de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses
al foro Preguntas de Autorreflexin y consultes las interrogantes que presenta tu
Facilitador(a), a partir de ellas elabora tu Autorreflexin en un archivo de texto llamado
DRS_U2_ATR_XXYZ. Recuerda sustituirlas XX por las dos primeras letras de tu primer
nombre, la Y por la inicial de tu primer apellido y la Z por la inicial de tu segundo apellido.
Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad

Has concluido la Unidad 2. Modelos de arquitectura. La revisin de este tema te sirvi
para conocer los patrones arquitectnicos, su correcto uso y aplicacin dentro de la
solucin de un problema en un mbito especfico, lo cual ayuda a que esta solucin sea
confiable y adherida a buenas prcticas de armado de arquitectura. La aplicacin de los
patrones dar la flexibilidad y la facilidad de uso, con la experiencia, para hacer gil la
implementacin de una arquitectura confiable a la hora de disear la solucin. El
aprendizaje no debe quedarse en las explicaciones tan cortas y mejorables que se
presentan en el desarrollo del tema o a lo largo de las unidades, es importante que se
ample con la prctica y la consulta de fuentes bibliogrficas externas para hacer un
trabajo complementario.

Para saber ms

Es importante que identifiques un software de cdigo libre y realices una descripcin
formal de arquitectura basndote en un lenguaje de definicin de arquitectura, instlalo
en tu computadora personal para que realices pruebas de descripcin y veas la aplicacin
de los conceptos presentados.

21

Fuentes de consulta

De la Torre Llorente, C., Zorrilla Castro, U., Calvarro Nelson, J., Ramos Barroso,
M. A. (2010). Gua de Arquitectura N-Capas orientada al Dominio con .NET 4.0.
Espaa: Krasis PRESS.

Real Academia Espaola. (2012a). Disquisicin. En Diccionario de la lengua
espaola (22.a ed.). Recuperado de
http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=Patr%C3%B3n

Reynoso, C., Kicillog, N. (2004). Estilos y Patrones en la Estrategia de Arquitectura
de Microsoft. Argentina: Universidad de Buenos Aires.

U2 Modelos de Arquitectura

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

U2 Modelos de Arquitectura

Încărcat de

Drepturi de autor:

Formate disponibile

Diseo y Arquitectura de Software

Unidad 2. Modelos de Arquitectura

S-ar putea să vă placă și