drs_u2_a3_jeco

Diseño y Arquitectura de SoftwareUnidad 2. Modelos de Arquitectura.Actividad 3. Contrastando arquitectura y patrón de diseño.Alumno. Jerónimo Colín Ortiz Matrícula. AL10506040

1.- Identifica qué es un patrón de arquitectura.

Un patrón de arquitectura es una forma de plasmar la solución a un problema mediante el uso de la arquitectura de software. Ofrece una descripción de cada elemento y la relación que tienen en conjunto.

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

Un patrón de arquitectura nos ayuda a la identificación 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 definición de una arquitectura se produce la arquitectura inicial de un proyecto, la arquitectura de referencia, se elabora el documento de descripción de arquitectura (SAD) que describe componentes, subsistemas, arquitectura runtime, guías del proyecto y estándares del diseño.

Los patrones de arquitectura nos indican los lineamientos y reglas que restringen el diseño y la implementación de un software. Los patrones de arquitectura son la solución general a un problema común del diseño arquitectónico.

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

Existen diferentes patrones, los cuales se clasifican dependiendo la naturaleza del problema que resuelvan:

1. Patrones arquitectónicos.2. Patrones de diseño.3. Patrones de idioms.

Patrones Arquitectónicos.Los patrones arquitectónicos son plantillas en las que se describen los principios estructurales globales de las arquitecturas de software viables para la solución de un problema, en ellos se plantea una la organización estructural de un software dividiéndolo como un conjunto de subsistemas especificando responsabilidades y la relación entre sus componentes.

Patrones de diseño.Los patrones de diseño 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 comunicación entre los componentes que resuelven un problema de diseño general dentro de un contexto particular.

Idioms.Se relacionan con la implementación de diseño de problemas muy específicos. Se les llama también patrones de bajo nivel específicos para un lenguaje de programación. Los idioms describen la forma de implementar aspectos particulares de los componentes o de sus relaciones utilizando características propias del lenguaje de programación.


Tipo de problema que resuelven

Clasificación del patrónArquitectura Diseño

Cimientos LAYERS PIPES-FILTERSistemas Distribuidos BROKERSistemas Interactivos MODEL-VIEW-

CONTROLLERSistemas Adaptables MICROKERNEL

REFLECTIONCreación ABSTRACT FACTORY PROTOTYPE

BUILDERDescomposición Estructural WHOLE PART COMPOSITEOrganización del Trabajo CHAIN OF RESPONSIBILITY

COMMAND MEDIATORMASTER-SLAVE

Control de Acceso PROXY, FACADE, ITERATORVariación de Servicios BRIDGE, STRATEGY, STATEExtensión de servicios DECORATOR VISITORAdministración MEMENTOAdaptación ADAPTERComunicación FORWARDER-RECEIVER

CLIENT-DISPATCHER-SERVERPUBLISHER-SUBSCRIBER

Estructuración y Configuración

EXTENSION INTERFACE

Manejo de Recursos FLYWEIGHT

Patrones de arquitecturaLayers:Este patrón se caracteriza por estructurar aplicaciones que pueden descomponerse en grupos o subtareas, en las cuales cada grupo de subtareas tiene un nivel de abstracción particular. Se recomienda su utilización en sistemas extensos que por la complejidad que presentan su solución y desarrollo es más fácil descomponiéndolo.

Las principales ventajas de la utilización de este patrón son: la reusabilidad, estandarización, 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 patrón 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 patrón permite la construcción de sistemas relacionados.

En este patrón se omite el uso de archivos intermedios pero si se quisiera investigar los datos intermedios se podría utilizar la unión “T” en el pipeline. Los filters poseen interfaz simple que permite su intercambio fácilmente dentro del procesamiento del pipeline.

El mayor beneficio de este patrón es la reusabilidad de los componentes filters lo que permite la creación 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.


Algunas de las desventajas principales de este patrón son: la compartición de la información cara y poco flexible, el costo de transferir datos entre filters puede ser relativamente alto comparado con el costo de realizar cómputos 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 patrón arquitectónico Blackboard es ideal para problemas que no se conocen estrategias de solución, ya que los subsistemas especializados comparten sus conocimientos entre sí, para construir una posible solución. La solución de dichos problemas requiere de diferentes representaciones y paradigmas lo que nos puede generar diferentes soluciones alternativas. La idea principal del patrón Blackboard es tener una colección de programas especializados e independientes que trabajen en conjunto sobre una estructura de datos común, cada programa se especializa en resolver una parte particular de la tarea global y todos los programas trabajan en conjunto en pos de una solución.

La utilización de blackboard permite experimentar con la mayor cantidad posible de algoritmos diferentes y con diferentes heurísticas de control, soporta cambiabilidad y mantenibilidad debido a que el algoritmo de control y la estructura de datos central están separados, la tolerancia a fallos y robustez son consecuencia de seleccionar únicamente las hipótesis que son fuertemente soportadas por los datos y otras hipótesis.

El patrón Blackboard no garantiza ninguna buena solución ya que en la práctica puede resolver correctamente sólo un porcentaje de las tareas dadas, en ocasiones los resultados no son reproducibles, las estrategias de control no se diseñan de manera integra y no soporta la ejecución en paralelo por lo que el acceso concurrente a los datos centrales en la pizarra se debe sincronizar.

Broker:Es común la utilización del patón bróker para estructurar sistemas de software distribuidos con componentes desacoplados que interactúan por invocaciones de servicios remotos. Cada componente en broker es responsable de coordinar la comunicación, 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 separación de clientes y servidores. Los servidores se registran con el broker y hacen que sus servicios estén disponibles a los clientes a través de métodos de interfaces, los clientes acceden funcionalmente a los servidores enviando las solicitudes a través del broker.

El broker localiza al servidor apropiado, remite la solicitud al servidor y transmite respuestas y excepciones al cliente. El patrón bróker ofrece ventajas en su utilización como por ejemplo: transparencia ya que el bróker es responsable de localizar al servidor usando un identificador único por lo que los clientes no necesitan saber la ubicación del servidor y viceversa. Broker oculta detalles del sistema operativo y del sistema de red a clientes y servidores usando capas de indirección como las API’s, proxies y bridges, maneja un protocolo común para el intercambio de mensajes el que es interpretado y manejado por bridges que son los responsables de traducir el protocolo específico del broker en el


protocolo común y viceversa, las aplicaciones están basadas en la funcionalidad de las aplicaciones y servicios existentes.

Las aplicaciones que usan una implementación broker son más lentas que las aplicaciones cuya distribución del componente es estática y conocida, un sistema broker ofrece menor tolerancia a fallos.

Model-View-ControllerEl patrón arquitectónico Model-View-Controller (MVC) se caracteriza por dividir una aplicación interactiva en tres componentes; “Modelo” contiene la funcionalidad central y los datos, “Vistas” despliegan la información al usuario y “Controlador” maneja la entrada del usuario.

El modelo es un componente independiente de las representaciones específicas de salidas o del comportamiento de la entrada, encapsula los datos centrales y tiene la funcionalidad de la aplicación. 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 interactúa con el sistema a través de los controladores. Las vistas presentan la información del modelo al usuario de distintas formas lo que ocasiona que puedan existir múltiples vistas de un mismo modelo, cada vista tiene una relación 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 propagación 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 propagación de cambios y se propaguen las modificaciones en cada componente del sistema, dicho mecanismo es la única conexión entre el modelo, las vistas y los controladores.

Se pueden implementar múltiples vistas de un mismo modelo las cuales están sincronizadas junto con los controladores dependientes. La separación conceptual del MVC permite el intercambio de objetos de las vistas y los controladores en tiempo de ejecución, la funcionalidad no se ve afectada por el cambio de una plataforma a otra ya que solo sería necesaria la implementación 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 mayoría de los casos su rehúso individual, la realización de llamadas directas al modelo implica posibles rupturas de código de vista y controlador.

Patrones de diseño

Abstract Factory:Este patrón 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 creación, composición y representación de sus productos.

Una familia de objetos deban ser usados en conjunto


Sea necesario proveer una librería de una clase de productos y sea necesario revelar sus interfaces simplemente y ocultar sus implementaciones.

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

Para Abstract Factory no es fácil extender una fábrica 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 fábrica implicando cambios en el código de la clase Abstract Factory y todas sus subclases.

Builder:Este patrón separa el proceso de construcción de un objeto complejo de su representación, para que el mismo proceso de construcción 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 representación interna de un producto, aisla los códigos de construcción y representación al mismo tiempo que provee mayor control en el proceso de construcción.

Prototype:El patrón Prototype crea objetos nuevos copiándolos, clonando una instancia creada previamente.Se utiliza cuando:

Un sistema debe ser independiente de cómo se crean, se componen y se representan sus productos.

Las clases a instanciar son especificadas en tiempo de ejecución. Se necesite evitar la construcción de una jerarquía de la clase de fábricas que se asemeja

a la jerarquía de la clase de productos. Las instancias de una clase puedan tener una de las combinaciones de diferentes estados. Sea necesaria la creación de distintas variantes de un objeto.

Prototype permite incorporar una clase producto en el sistema registrando una instancia de prototipo, en sistemas altamente dinámicos permite definir nuevos comportamientos a través de composición de objetos especificando valores para variables de un objeto sin definir nuevas clases, permite clonar un prototipo en vez de solicitar a un método fábrica que cree un nuevo objeto, lo cual evita tener toda una jerarquía de clases creadoras de objetos, al igual que permite cargar dinámicamente las clases de una aplicación en tiempo de ejecución.

Cada subclase de Prototype debe ser implementada por la operación “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.

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 patrón Adapter permite reutilización de código permitiendo la interacción de dos o más 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 también juega un papel importante en otros aspectos del desarrollo de software como por ejemplo:

Mejora la comprensión de sistemas grandes y complejos. Permite una mejor comunicación entre los diferentes interesados. Mejora las posibilidades de reusó. Proporciona planos para la construcción. Toma en cuenta la posible evolución del sistema.

drs_u2_a3_jeco

Documents