Diseo y Arquitectura de Software

Unidad 2. Modelos de Arquitectura.

Actividad 3. Contrastando arquitectura y patrn de diseo.
Alumno. Jernimo Coln Ortiz Matrcula. AL10506040
1.- Identifica qu es un patrn de arquitectura.

Un patrn de arquitectura es una forma de plasmar la solucin a un problema mediante el uso de
la arquitectura de software. Ofrece una descripcin de cada elemento y la relacin que tienen en
conjunto.

Los patrones de arquitectura se caracterizan por ofrecer diferentes atributos de calidad. Un patrn
es un modelo que se toma como muestra para reproducir un objeto o concepto igual.

Un patrn de arquitectura nos ayuda a la identificacin de requerimientos funcionales y de calidad
de servicio, con los patrones de arquitectura podemos identificar los riesgos y restricciones de un
sistema, identificamos los actores y casos de uso.
Durante el proceso de la definicin de una arquitectura se produce la arquitectura inicial de un
proyecto, la arquitectura de referencia, se elabora el documento de descripcin de arquitectura
(SAD) que describe componentes, subsistemas, arquitectura runtime, guas del proyecto y
estndares del diseo.

Los patrones de arquitectura nos indican los lineamientos y reglas que restringen el diseo y la
implementacin de un software. Los patrones de arquitectura son la solucin general a un
problema comn del diseo arquitectnico.


2.- Redacta reporte escrito donde se describan las diferencias
entre los distintos patrones arquitectnicos y arquitecturas.


Existen diferentes patrones, los cuales se clasifican dependiendo la naturaleza del problema que
resuelvan:
1. Patrones arquitectnicos.
2. Patrones de diseo.
3. Patrones de idioms.

Patrones Arquitectnicos.
Los patrones arquitectnicos son plantillas en las que se describen los principios estructurales
globales de las arquitecturas de software viables para la solucin de un problema, en ellos se
plantea una la organizacin estructural de un software dividindolo como un conjunto de
subsistemas especificando responsabilidades y la relacin entre sus componentes.

Patrones de diseo.
Los patrones de diseo nos proveen las herramientas para refinar componentes de un sistema de
software y la forma en que se relacionan entre ellos. Describen la estructura de comunicacin entre
los componentes que resuelven un problema de diseo general dentro de un contexto particular.

Idioms.
Se relacionan con la implementacin de diseo de problemas muy especficos. Se les llama
tambin patrones de bajo nivel especficos para un lenguaje de programacin. Los idioms
describen la forma de implementar aspectos particulares de los componentes o de sus relaciones
utilizando caractersticas propias del lenguaje de programacin.



Diseo y Arquitectura de Software
Unidad 2. Modelos de Arquitectura.
Actividad 3. Contrastando arquitectura y patrn de diseo.
Alumno. Jernimo Coln Ortiz Matrcula. AL10506040
Tipo de problema
que resuelven
Clasificacin del patrn
Arquitectura Diseo
Cimientos LAYERS PIPES-FILTER
Sistemas Distribuidos BROKER
Sistemas Interactivos MODEL-VIEW-
CONTROLLER

Sistemas Adaptables MICROKERNEL
REFLECTION

Creacin ABSTRACT FACTORY PROTOTYPE
BUILDER
Descomposicin Estructural WHOLE PART COMPOSITE
Organizacin del Trabajo CHAIN OF RESPONSIBILITY
COMMAND MEDIATOR
MASTER-SLAVE
Control de Acceso PROXY, FACADE, ITERATOR
Variacin de Servicios BRIDGE, STRATEGY, STATE
Extensin de servicios DECORATOR VISITOR
Administracin MEMENTO
Adaptacin ADAPTER
Comunicacin FORWARDER-RECEIVER
CLIENT-DISPATCHER-SERVER
PUBLISHER-SUBSCRIBER
Estructuracin y
Configuracin
EXTENSION INTERFACE
Manejo de Recursos FLYWEIGHT

Patrones de arquitectura
Layers:
Este patrn se caracteriza por estructurar aplicaciones que pueden descomponerse en grupos o
subtareas, en las cuales cada grupo de subtareas tiene un nivel de abstraccin particular. Se
recomienda su utilizacin en sistemas extensos que por la complejidad que presentan su solucin
y desarrollo es ms fcil descomponindolo.

Las principales ventajas de la utilizacin de este patrn son: la reusabilidad, estandarizacin,
portabilidad y cambiabilidad.

Sus desventajas son: tener una baja eficiencia, realiza trabajo innecesario, dificultad al establecer
la correcta granularidad entre capas.

Pipes and Filters:
Es un patrn que provee una estructura para sistemas que procesan flujos de datos en donde cada
paso de procesamiento se encapsula un componente denominado filter y el flujo de datos se indica
por medio del componente pipes, este patrn permite la construccin de sistemas relacionados.

En este patrn se omite el uso de archivos intermedios pero si se quisiera investigar los datos
intermedios se podra utilizar la unin T en el pipeline. Los filters poseen interfaz simple que
permite su intercambio fcilmente dentro del procesamiento del pipeline.

El mayor beneficio de este patrn es la reusabilidad de los componentes filters lo que permite la
creacin de nuevos procesos pipelines. Pipes and filters tiene un alto grado de eficacia en
procesamiento en paralelo, por lo que si un filter en un pipeline produce y consume datos de forma
incremental se pueden realizar las funciones en paralelo.




Diseo y Arquitectura de Software
Unidad 2. Modelos de Arquitectura.
Actividad 3. Contrastando arquitectura y patrn de diseo.
Alumno. Jernimo Coln Ortiz Matrcula. AL10506040
Algunas de las desventajas principales de este patrn son: la comparticin de la informacin cara y
poco flexible, el costo de transferir datos entre filters puede ser relativamente alto comparado con
el costo de realizar cmputos en un solo filter, algunos filters consumen todas sus entradas antes
de producir cualquier salida, el manejo de errores no tiene estrategia definida.


Blackboard:
El patrn arquitectnico Blackboard es ideal para problemas que no se conocen estrategias de
solucin, ya que los subsistemas especializados comparten sus conocimientos entre s, para
construir una posible solucin. La solucin de dichos problemas requiere de diferentes
representaciones y paradigmas lo que nos puede generar diferentes soluciones alternativas. La
idea principal del patrn Blackboard es tener una coleccin de programas especializados e
independientes que trabajen en conjunto sobre una estructura de datos comn, cada programa se
especializa en resolver una parte particular de la tarea global y todos los programas trabajan en
conjunto en pos de una solucin.

La utilizacin de blackboard permite experimentar con la mayor cantidad posible de algoritmos
diferentes y con diferentes heursticas de control, soporta cambiabilidad y mantenibilidad debido a
que el algoritmo de control y la estructura de datos central estn separados, la tolerancia a fallos y
robustez son consecuencia de seleccionar nicamente las hiptesis que son fuertemente
soportadas por los datos y otras hiptesis.

El patrn Blackboard no garantiza ninguna buena solucin ya que en la prctica puede resolver
correctamente slo un porcentaje de las tareas dadas, en ocasiones los resultados no son
reproducibles, las estrategias de control no se disean de manera integra y no soporta la ejecucin
en paralelo por lo que el acceso concurrente a los datos centrales en la pizarra se debe
sincronizar.

Broker:
Es comn la utilizacin del patn brker para estructurar sistemas de software distribuidos con
componentes desacoplados que interactan por invocaciones de servicios remotos. Cada
componente en broker es responsable de coordinar la comunicacin, remitir las demandas,
transmitir resultados y excepciones. Al dividir la funcionalidad entre los componentes
independientes del sistema se torna distribuible y escalable.

Broker logra una buena separacin de clientes y servidores. Los servidores se registran con el
broker y hacen que sus servicios estn disponibles a los clientes a travs de mtodos de
interfaces, los clientes acceden funcionalmente a los servidores enviando las solicitudes a travs
del broker.

El broker localiza al servidor apropiado, remite la solicitud al servidor y transmite respuestas y
excepciones al cliente.

El patrn brker ofrece ventajas en su utilizacin como por ejemplo: transparencia ya que el brker
es responsable de localizar al servidor usando un identificador nico por lo que los clientes no
necesitan saber la ubicacin del servidor y viceversa. Broker oculta detalles del sistema operativo
y del sistema de red a clientes y servidores usando capas de indireccin como las APIs, proxies y
bridges, maneja un protocolo comn para el intercambio de mensajes el que es interpretado y



Diseo y Arquitectura de Software
Unidad 2. Modelos de Arquitectura.
Actividad 3. Contrastando arquitectura y patrn de diseo.
Alumno. Jernimo Coln Ortiz Matrcula. AL10506040
manejado por bridges que son los responsables de traducir el protocolo especfico del broker en el
protocolo comn y viceversa, las aplicaciones estn basadas en la funcionalidad de las
aplicaciones y servicios existentes.

Las aplicaciones que usan una implementacin broker son ms lentas que las aplicaciones cuya
distribucin del componente es esttica y conocida, un sistema broker ofrece menor tolerancia a
fallos.

Model-View-Controller
El patrn arquitectnico Model-View-Controller (MVC) se caracteriza por dividir una aplicacin
interactiva en tres componentes; Modelo contiene la funcionalidad central y los datos, Vistas
despliegan la informacin al usuario y Controlador maneja la entrada del usuario.

El modelo es un componente independiente de las representaciones especficas de salidas o del
comportamiento de la entrada, encapsula los datos centrales y tiene la funcionalidad de la
aplicacin. Los controladores reciben la entrada atreves de eventos que codifican los movimientos
del mouse o entrada del teclado, los eventos se traducen para servir a las demandas del modelo o
las vistas, el usuario interacta con el sistema a travs de los controladores. Las vistas presentan
la informacin del modelo al usuario de distintas formas lo que ocasiona que puedan existir
mltiples vistas de un mismo modelo, cada vista tiene una relacin uno a uno con un controlador,
cada vista recupera los valores de datos actuales del modelo para ser mostrados y los pone en la
pantalla.

El mecanismo de propagacin de cambios lleva un registro de los componentes dependientes
dentro del modelo, todas las vistas y controladores seleccionados indican en el registro que
necesitan actualizar sobre los cambios producidos, cualquier cambio de estado del modelo hace
que se active el mecanismo de propagacin de cambios y se propaguen las modificaciones en
cada componente del sistema, dicho mecanismo es la nica conexin entre el modelo, las vistas y
los controladores.

Se pueden implementar mltiples vistas de un mismo modelo las cuales estn sincronizadas junto
con los controladores dependientes. La separacin conceptual del MVC permite el intercambio de
objetos de las vistas y los controladores en tiempo de ejecucin, la funcionalidad no se ve afectada
por el cambio de una plataforma a otra ya que solo sera necesaria la implementacin conveniente.

El uso de componentes separados del MVC en algunos casos implica aumento en la complejidad
sin ganar flexibilidad, los controladores y vistas son componentes separados pero estrechamente
relacionados que impiden en la mayora de los casos su rehso individual, la realizacin de
llamadas directas al modelo implica posibles rupturas de cdigo de vista y controlador.

Patrones de diseo
Abstract Factory:
Este patrn nos permite crear familias de objetos relacionados o dependientes sin necesidad de
especificar su clase concretamente, se recomienda su uso para el desarrollo de sistemas que:
Requiera independencia en la forma de creacin, composicin y representacin de sus
productos.



Diseo y Arquitectura de Software
Unidad 2. Modelos de Arquitectura.
Actividad 3. Contrastando arquitectura y patrn de diseo.
Alumno. Jernimo Coln Ortiz Matrcula. AL10506040
Una familia de objetos deban ser usados en conjunto
Sea necesario proveer una librera de una clase de productos y sea necesario revelar sus
interfaces simplemente y ocultar sus implementaciones.

Abstract Factory asla clases concretas, facilita el cambio de familias de productos y promueve la
consistencia entre productos.

Para Abstract Factory no es fcil extender una fbrica abstracta para que produzca nuevos tipos
de productos debido a que su interfaz fija el conjunto de productos que se pueden crear por tal
motivo agregar un nuevo producto requiere extender la interfaz de la fbrica implicando cambios en
el cdigo de la clase Abstract Factory y todas sus subclases.

Builder:
Este patrn separa el proceso de construccin de un objeto complejo de su representacin, para
que el mismo proceso de construccin pueda crear diferentes representaciones, es recomendable
su uso cuando:
Se necesite un algoritmo para crear objetos en el que el objeto y la forma en que son
ensamblados sea independiente de las partes que lo constituyen.
Se necesite permitir diferentes representaciones para el objeto que se construye.

Builder permite variar la representacin interna de un producto, aisla los cdigos de construccin y
representacin al mismo tiempo que provee mayor control en el proceso de construccin.

Prototype:
El patrn Prototype crea objetos nuevos copindolos, clonando una instancia creada previamente.
Se utiliza cuando:
Un sistema debe ser independiente de cmo se crean, se componen y se representan sus
productos.
Las clases a instanciar son especificadas en tiempo de ejecucin.
Se necesite evitar la construccin de una jerarqua de la clase de fbricas que se asemeja
a la jerarqua de la clase de productos.
Las instancias de una clase puedan tener una de las combinaciones de diferentes estados.
Sea necesaria la creacin de distintas variantes de un objeto.

Prototype permite incorporar una clase producto en el sistema registrando una instancia de
prototipo, en sistemas altamente dinmicos permite definir nuevos comportamientos a travs de
composicin de objetos especificando valores para variables de un objeto sin definir nuevas clases,
permite clonar un prototipo en vez de solicitar a un mtodo fbrica que cree un nuevo objeto, lo
cual evita tener toda una jerarqua de clases creadoras de objetos, al igual que permite cargar
dinmicamente las clases de una aplicacin en tiempo de ejecucin.

Cada subclase de Prototype debe ser implementada por la operacin clone, tarea que puede
resultar complicada cuando las clases ya existen y los objetos que estas incluyen no soportan ser
copiados o tienen referencias circulares.





Diseo y Arquitectura de Software
Unidad 2. Modelos de Arquitectura.
Actividad 3. Contrastando arquitectura y patrn de diseo.
Alumno. Jernimo Coln Ortiz Matrcula. AL10506040
Patrones estructurales
Adapter:
Se aplica para convertir una interfaz de una clase en otra, haciendo que una clase a la que le fuera
imposible utilizar la primer interfase, haga uso de ella por medio de la segunda permitiendo que
trabajen en conjunto, se recomienda su uso cuando:
Sea necesario el uso de una clase existente, y su interfaz es distinta a la que se necesita.
Se requiera una clase reusable con clases que no tengan interfaces compatibles.

El patrn Adapter permite reutilizacin de cdigo permitiendo la interaccin de dos o ms objetos
incompatibles, la transferencia de argumentos se hace mediante el objeto adapter que crea objetos
apropiados cuando no hay una correspondencia directa entre el target y el adapter o encapsula un
objeto para que pueda ser utilizado por el adapter.


Conclusiones:
Podemos concluir que la arquitectura a parte del modelado del software tambin juega un papel
importante en otros aspectos del desarrollo de software como por ejemplo:
Mejora la comprensin de sistemas grandes y complejos.
Permite una mejor comunicacin entre los diferentes interesados.
Mejora las posibilidades de reus.
Proporciona planos para la construccin.
Toma en cuenta la posible evolucin del sistema.