Evidencia de Aprendizaje

Alumna: Laura Wendy Díaz Rodríguez.

Matrícula: AL11509485.

Grupo: DS-DRS-1301-002.

Facilitador: Heriberto González Cazares.

Unidad 2.

Evidencia de Aprendizaje. Lenguaje Descriptor y Patrones de Arquitectura de Software.

Para demostrar tu conocimiento acerca de los tipos de patrones arquitectónicos, tú diseñarás una propuesta de arquitectura que sirva para solucionar un problema; para ello considerarás que el patrocinador (la empresa que solicitó la solución) es una tienda de conveniencia, tú analizarás sus requerimientos de software y lo contrastarás con las herramientas de diferentes tipos de sistema, siendo capaz de elaborar una propuesta.

Como parte de la evaluación de esta unidad, es necesario realizar en forma gráfica la arquitectura de una tienda de conveniencia aplicando y justificando el uso del patrón específico.

1.

Justifica el uso del patrón.

Identificación de Patrones de Arquitectura de Software.

Descripción.

Buschmann et al. (1996) define patrón como una regla que consta de tres partes, la cual expresa una relación entre un contexto, un problema y una solución.

En líneas generales, un patrón sigue el siguiente esquema:   

Contexto. Es una situación de diseño en la que aparece un problema de diseño.

Problema. Es un conjunto de fuerzas que aparecen repetidamente en el contexto.

Solución. Es una configuración que equilibra estas fuerzas. Ésta abarca:  Estructura con componentes y relaciones.  Comportamiento a tiempo de ejecución: aspectos dinámicos de la solución, como la colaboración entre componentes, la comunicación entre ellos, etc.

Partiendo de esta definición, propone los patrones arquitectónicos como descripción de un problema particular y recurrente de diseño, que aparece en contextos de diseño específico, y presenta un esquema genérico demostrado con éxito para su solución. El esquema de solución se especifica mediante la descripción de los componentes que la constituyen, sus responsabilidades y desarrollos, así como también la forma como estos colaboran entre sí.

Los patrones arquitectónicos expresan el esquema de organización estructural fundamental para sistemas de software. Provee un conjunto de subsistemas predefinidos, especifica sus responsabilidades e incluye reglas y pautas para la organización de las relaciones entre ellos. Propone que son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicación - con amplitud de todo el sistema - y tienen un impacto en la arquitectura de subsistemas. La selección de un patrón arquitectónico es, por lo tanto, una decisión fundamental de diseño en el desarrollo de un sistema de software.

Visto de esta manera, el concepto de patrón arquitectónico propuesto por Buschmann et al. (1996) equivale al establecido por Shaw y Garlan (1996) para estilo arquitectónico, quienes tratan indistintamente estos dos términos.

Barbacci et al. (1997) hacen la analogía de la construcción de una arquitectura de un sistema complejo como la inclusión de instancias de más de un patrón

arquitectónico, compuestos de maneras arbitrarias. La colección de patrones arquitectónicos debe ser estudiada en términos de factores de calidad e intereses, en anticipación a su uso. Esto quiere decir que un patrón puede ser analizado previamente, con la intención de seleccionar el que mejor se adapte a los requerimientos de calidad que debe cumplir el sistema.

De manera similar, Barbacci et al. (1997) proponen que debe estudiarse la composición de los patrones, dado que ésta puede dificultar aspectos como el análisis, o poner en conflicto otros atributos de calidad.

Listado de Patrones.

Patrón Arquitectónico Layers

Pipes and Filters

Blackboard

Broker

Características Consiste en estructurar aplicaciones que pueden ser descompuestas en grupos de subtareas, las cuales se clasifican de acuerdo a un nivel particular de abstracción.

Provee una estructura para los sistemas que procesan un flujo de datos.

Cada paso de procesamiento está encapsulado en un componente filtro (filter). El dato pasa a través de conexiones (pipes), entre filtros adyacentes.

Aplica para problemas cuya solución utiliza estrategias no determinísticas. Varios subsistemas ensamblan su conocimiento para construir una posible solución parcial o aproximada.

Puede ser usado para estructurar sistemas de software distribuido con componentes desacoplados que interactúan por invocaciones a servicios remotos. Un componente broker es responsable de coordinar la comunicación, como el reenvío de solicitudes, así como también la transmisión de

Atributos Asociados Reusabilidad Portabilidad Facilidad de Prueba

Atributos en Conflicto Desempeño Mantenibilidad

Reusabilidad Mantenibilidad

Desempeño

Modificabilidad Mantenibilidad Reusabilidad Integridad

Desempeño Facilidad de Prueba

Modificabilidad Desempeño Portabilidad Reusabilidad Escalabilidad Interoperabilidad

resultados y excepciones.

Model-View- Controler

Divide una aplicación interactiva en tres componentes. El modelo (model) contiene la información central y los datos. Las vistas (view) despliegan información al usuario. Los controladores (controlers) capturan la entrada del usuario. Las vistas y los controladores constituyen la interfaz del usuario.

Funcionalidad Mantenibilidad

Desempeño Portabilidad

Presentation Abstraction Control

Define una estructura para sistemas de software interactivos de agentes de cooperación organizados de forma jerárquica. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste de tres componentes: presentación, abstracción y control.

Aplica para sistemas de software que deben estar en capacidad de adaptar los requerimientos de cambio del sistema. Separa un núcleo funcional mínimo del resto de la funcionalidad y de partes específicas pertenecientes al cliente.

Provee un mecanismo para sistemas cuya estructura y comportamiento cambia dinámicamente. Soporta la modificación de aspectos fundamental como estructuras tipo y mecanismos de llamadas a funciones.

Modificabilidad Escalabilidad Integrabilidad

Desempeño Mantenibilidad

Portabilidad Escalabilidad Confiablidad Disponibilidad

Desempeño

Modificabilidad

Desempeño

Microkernel

Reflection

Patrones Complementarios.

Categorías de Patrones.

Según la escala o nivel de abstracción: -

-

Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.

Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.

Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Interacción: Son patrones que nos permiten el diseño de interfaces web.

Además también es importante reseñar el concepto de “antipatrón de diseño” que con forma semejante a la de un patrón, intenta prevenir contra errores comunes de diseño en el software. La idea de los antipatrones es dar a conocer los problemas que acarrean ciertos diseños muy frecuentes, para intentar evitar que diferentes sistemas acaben una y otra vez en el mismo callejón sin salida por haber cometido los mismos errores.

Estructuras o plantillas de patrones.

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforma entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos.

La plantilla más común es la utilizad precisamente por el GoF y consta de los siguientes apartados:        

Nombre del patrón: Nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).

Clasificación del patrón: Creacional, estructural o de comportamiento.

Intención: ¿Qué problema pretende resolver el patrón?

También conocido como: Otros nombres de uso común para el patrón.

Motivación: Escenario de ejemplo para la aplicación del patrón.

Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.

Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.

     

Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.

Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.

Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.

Código de ejemplo: Código fuente ejemplo de implementación del patrón.

Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

Patrones relacionados: Referencias cruzadas con otros patrones.

Patrones de Diseño.

Un patrón de diseño es: o Una solución estándar para un problema común de programación. o Una técnica para flexibilizar el código haciéndolo satisfacer ciertos criterios. o Un proyecto o estructura de implementación que logra una finalidad determinada. o Un lenguaje de programación de alto nivel. o Una manera más práctica de describir ciertos aspectos de la organización de un programa. o Conexiones entre componentes de programas. o La forma de un diagrama de objeto o de un modelo de objeto.

A cada diseño de proyecto le sigue el problema que trata de resolver, la solución que aporta y las posibles desventajas asociadas. Un desarrollador debe buscar un equilibrio entre las ventajas y las desventajas a la hora de decidir que patrón utilizar. Lo normal es, como observará a menudo en la ciencia computacional y en otros campos, buscar el balance entre flexibilidad y rendimiento.

Encapsulación (ocultación de datos).

Problema: los campos externos pueden ser manipulados directamente a partir del código externo, lo que conduce a violaciones del invariante de representación o a dependencias indeseables que impiden modificaciones en la implementación.

Solución: esconda algunos componentes, permitiendo sólo accesos estilizados al objeto.

Desventajas: la interfaz no puede, eficientemente, facilitar todas las operaciones deseadas. El acceso indirecto puede reducir el rendimiento.

Subclase (herencia).

Problema: abstracciones similares poseen miembros similares (campos y métodos). Esta repetición es tediosa, propensa a errores y un quebradero de cabeza durante el mantenimiento.

Solución: herede miembros por defecto de una superclase, seleccione la implementación correcta a través de resoluciones sobre qué implementación debe ser ejecutada.

Desventajas: el código para una clase está muy dividido, con lo que, potencialmente, se reduce la comprensión. La introducción de resoluciones en tiempo de ejecución introduce overhead (procesamiento extra).

Iteración Problema: los clientes que desean acceder a todos los miembros de una colección deben realizar un transversal especializado para cada estructura de datos, lo que introduce dependencias indeseables que impiden la ampliación del código a otras colecciones.

Solución: las implementaciones, realizadas con conocimiento de la representación, realizan transversales y registran el proceso de iteración. El cliente recibe los resultados a través de una interfaz estándar.

Desventajas: la implementación fija la orden de iteración, esto es, no está controlada en absoluto por el cliente.

Excepciones.

Problema: los problemas que ocurren en una parte del código normalmente han de ser manipulados en otro lugar. El código no debe desordenarse con rutinas de manipulación de error, ni con valores de retorno para identificación de errores.

Solución: introducir estructuras de lenguaje para arrojar e interceptar excepciones.

Desventajas: es posible que el código pueda continuar aún desordenado. Puede ser difícil saber dónde será gestionada una excepción. Tal vez induzca a los programadores a utilizar excepciones para controlar el flujo normal de ejecución, que es confuso y por lo general ineficaz.

Estos patrones de diseño en concreto son tan importantes que ya vienen incorporados en Java. Otros vienen incluidos en otros lenguajes, tal vez algunos nunca lleguen a estar incorporados a ningún lenguaje, pero continúan siendo útiles.

La primera regla de los patrones de diseño coincide con la primera regla de la optimización: Retrasar. Del mismo modo que no es aconsejable optimizar prematuramente, no se deben utilizar patrones de diseño antes de tiempo.

Seguramente sea mejor implementar algo primero y asegurarse de que funciona, para luego utilizar el patrón de diseño para mejorar las flaquezas; esto es cierto, sobre todo, cuando aún no ha identificado todos los detalles del proyecto (si comprende totalmente el dominio y el problema, tal vez sea razonable utilizar

patrones desde el principio, de igual modo que tiene sentido utilizar los algoritmos más eficientes desde el comienzo en algunas aplicaciones).

Los patrones de diseño pueden incrementar o disminuir la capacidad de comprensión de un diseño o de una implementación, disminuirla al añadir accesos indirectos o aumentar la cantidad de código, disminuirla al regular la modularidad, separar mejor los conceptos y simplificar la descripción.

Empleo de Patrones.

Los patrones de diseño son, simplemente, en lenguaje llano, “maneras de hacer las cosas”.

Su propósito es doble: - Proporcionar una solución a un problema adaptable a variaciones del mismo y escalable a diferentes parámetros. Por ejemplo, un soporte para una colección de objetos que permita tamaños tanto del orden de decenas como de miles.

- Proporcionar soluciones robustas y bien conocidas.

Los patrones de diseño, como su nombre indica, se aplican en la fase de diseño.

Esto implica que: - La fase de análisis (¿qué es necesario hacer?) NO es cubierta por los patrones de diseño en absoluto.

- La fase de diseño (¿cómo lo vamos a hacer?), es cubierta en buena parte por esta técnica.

- Las fases de implementación y pruebas no se ven afectadas directamente por el uso de patrones, si bien se benefician de ellos (el software es más fácil de modificar y ampliar).

Tipos de Patrones. 

Creación.- Object Pool, Abstract Factory, Builder, Factory Method, Prototype, Singleton.



Estructurales.- Adapter, Bridge, Flyweight, Proxy, Módulo.



Comportamiento.- Chain of responsability, Command Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.

Composite, Decorator, Facade,

Patrones de Creación.

Object Pool:  Se obtienen objetos nuevos a través de la clonación.  Se utilizan cuando el costo de crear una clase es mayor que el de clonarla.  Especialmente con objetos muy complejos.  Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonación.  El proceso de clonación se inicia instanciando un tipo de objeto de la clase que queremos clonar.

Abstract Factory:  Se trata de presentar una separación entre las clases de la interfaz de usuario y el programa en sí.  Así, pone énfasis en la creación de objetos. Se trata de que, en un método de una clase A, una línea como:     

- B * ptrb = new B; Crea un acoplamiento excesivo entre ambas clases.

Esto se soluciona mediante una jerarquía de clases encargadas sólo de crear objetos (factorías).

El ejemplo típico para este patrón es el de dos entornos de ventanas distintos, con los cuales se desea sr compatible al mismo tiempo.

Así, el uso de estos dos GUI´s son intercambiables: basta seleccionar cuál de las dos jerarquías de clases se va a emplear.

Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.

Builder:  Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.

Factory Method:  Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear.

Prototype:  Crea nuevos objetos clonándolos de una instancia ya existente.

 

Este patrón consiste en que, en ciertas circunstancias es posible tener una misma clase que representará distintos objetos, que sin embargo, es posible subclasificar de alguna forma.

Las piezas del juego de las damas son un buen ejemplo. Cada pieza se diferencia de las otras en su posición y su color. En lugar de crear la pieza desde cero, puede ser más sencillo clonar un objeto con una nueva posición.

Singleton:  Este patrón asegura que existe una y sólo una instancia de una clase determinada.  La creación de un mecanismo de acceso global a dicha instancia.  Esto es típico cuando un recurso común, como podría ser, por ejemplo, la memoria, es tratado a lo largo de todo el programa. El recurso se encapsula en una clase, pero es necesario asegurarse de que sólo habrá un objeto de esa clase.

Patrones Estructurales.

Adapter:  Encapsula una clase, de manera que es posible normalizar su interfaz para su uso con otras clases.  El problema suele presentar cuando en una aplicación se reutilizan clases que no tienen exactamente la interfaz requerida.  La clase adaptadora se interpone entre el cliente y la clase reutilizada. La clase adaptadora presenta la interfaz que espera la aplicación, y se comunica con clase reutilizada, “traduciendo” los mensajes.

Bridge:  El puente permite separar dos aspectos distintos de una jerarquía de clases.  Básicamente, mientras una jerarquía implementa la funcionalidad real, la(s) otra(s) representan diversos aspectos, como representación en diferentes medios.

Composite:  Permite tratar objetos compuestos como si de uno, simple se tratase.

Decorator:  Añade funcionalidad a una clase dinámicamente.

Facade:  Típicamente, un diseño adecuado nos llevará a una factorización en clases más allá de la estrictamente necesaria para un sistema determinado.  En ese caso, es posible construir una clase facade (fachada), que tenga la interfaz esperada y sea el que realmente se comunique con la estructura de clases real, cuyas interfaces pueden variar.

Flyweight:  Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.

Proxy:  Mantiene un representante de un objeto.

Módulo:  Agrupa varios elementos relacionados. Como clases, singletons, y métodos, utilizados globalmente, en una entidad única.

Patrones de Comportamiento.

Chain of responsibility:  En múltiples ocasiones, un cliente necesita que se realice una función, pero o no conoce al servidor concreto de esa función o es conveniente que no lo conozca para evitar un gran acoplamiento entre cliente y servidor.  La petición se lana a una cadena de objetos que se “la van pasando” hasta que uno de los objetos la maneja.

Command:  Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.

Interpreter:  Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.

Iterator:  En un patrón ampliamente utilizado.  Se trata de tener varias colecciones de objetos (contenedores como lista, vector…), que ´pueden ser recorridas utilizando la misma abstracción: el iterador.  Permite recorrer cada elemento de un contenedor secuencialmente.



Es ampliamente utilizado en la STL de C++.

Mediator:  Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.

Memento:  Permite volver a estados anteriores del sistema.

Observer:  Se trata de poder notificar de un cambio a varios objetos.  Al fin y al cabo, es una manera de establecer una relación de uno a muchos.  Un ejemplo claro puede encontrarse cuando, teniendo abiertas dos ventanas de exploración sobre un mismo directorio, desde una de ellas borramos un archivo, y la segunda se actualiza automáticamente. Podrían definirse ambos exploradores como dos observadores del sistema de ficheros.  En cada observador puede tomarse una acción distinta según se haya producido un cambio.

State:  Permite que un objeto modifique su comportamiento cada vez que cambie si estado interno.

Strategy:  Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.

Template Method:  Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.

Visitor:  Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.

Patrones de Interacción.

El primer intento por aplicar este concepto en el diseño de las interfaces de usuario se dio por Ward Cummingham y Kent Beck quienes adaptaron la propuesta de C. Alexander y crearon cinco patrones de interfaz: Window per

task, Few panes, Standard panes, Nouns and verbs, y Short Menu. En años más recientes investigadores como Martin Van Welie, Jennifer Tidwell, Jaime Muñoz han desarrollado colecciones de patrones de interacción para la World Wide Web. En dichas colecciones captan la experiencia de programadores y diseñadores expertos en el desarrollo de interfaces usables y condensan esta experiencia en una serie de guías o recomendaciones que puedan ser usadas por los desarrolladores novatos con el propósito de que en poco tiempo adquieran la habilidad de diseño interfaces que incidan en la satisfacción de los usuarios. Los patrones de interacción buscan la reutilización de interfaces eficaces y un manejo óptimo de los recursos de las páginas web, haciendo más eficaz el consumo de tiempo en el diseño del sitio web y permitiendo a los programadores novatos adquirir más experiencia.  

 

Patrones de interfaces de usuario, esto es, aquellos que intentan definir las mejores formas de construir interfaces hombre-máquina.

Patrones para la construcción de sistemas empresariales, en donde se requieren especiales esfuerzos en infraestructuras de software y un nivel de abstracción importante para maximizar factores como la escalabilidad o el mantenimiento del sistema.

Patrones para la integración de sistemas, es decir, para la intercomunicación y coordinación de sistemas heterogéneos.

Patrones de flujos de trabajo, esto es par a la definición, construcción e integración de sistemas abstractos de gestión de flujos de trabajo y procesos con sistemas empresariales.

Aplicación de Lenguajes a Patrones.

Descripción de la Combinación al Aplicarlos.

ADLs y Patrones.

A primera vista, daría la impresión que la estrategia arquitectónica de Microsoft reposa más en la idea de patrones y prácticas que en lenguajes de descripción de diseño; pero si 45 se examina con más cuidado el concepto de patrones se verá que dichos lenguajes engranan clara y armónicamente en un mismo contexto global. El concepto de patrón fue acuñado por Christopher Alexander entre 1977 y 1979. De allí en más fue enriqueciéndose en una multitud de sentidos, abarcando un conjunto de prácticas para capturar y comunicar la experiencia de los diseñadores expertos, documentar best practices, establecer formas recurrentes de solución de problemas comunes, etcétera.

Las clasificaciones usuales en el campo de los patrones reconocen habitualmente que hay diferentes clases de ellos; por lo común se hace referencia a patrones de análisis, organizacionales, procedurales y de diseño.

Esta última categoría tiene que ver con recurrencias específicas de diseño de software y sistemas, formas relativamente fijas de interacción entre componentes, y técnicas relacionadas con familias y estilos. En este sentido, es evidente que los ADLs denotan una clara relación con los patrones de diseño, de los que puede decirse que son una de las formas posibles de notación. Como en el caso de las heurísticas y recetas de Acme, muchas veces esos patrones son explícitos y el ADL opera como una forma regular para expresarlos en la descripción arquitectónica.

La correspondencia entre patrones, ADLs y estilos, sin embargo, no está establecida de una vez y para siempre porque no existe ni una taxonomía uniforme, ni una especificación unívoca que defina taxativamente cuántas clases de patrones y cuántos niveles existen en ingeniería, arquitectura y diseño de software desde que se concibe conceptualmente un sistema hasta que se lo programa. En la percepción de Jørgen Thelin, quien a su vez se funda en la nomenclatura y tipificación de Martin Fowler, por ejemplo: distintos niveles en los proyectos de desarrollo se vincularían con otras tantas clases de patrones: el diseño con patrones de código, el análisis con los patrones de modelos y los estilos arquitectónicos con los patrones de arquitectura. Pero aunque cada escuela y cada autor organiza la articulación del campo a su manera y se sirve de denominaciones idiosincráticas, sin duda es legítimo plantear una relación entre patrones y lenguajes de descripción de arquitectura y tratar de esclarecer la. Los ADLs mantienen asimismo una frontera difusa con lo que desde Alexander en adelante se llamaron lenguajes de patrones, que se definen como sistemas de patrones organizados en una estructura o plantilla que orienta su aplicación.

Ambas ideas se consolidaron en una nutrida bibliografía, en la cual la obra de la llamada “Banda de los Cuatro” ha alcanzado una fama legendaria [Gof95]. En algunas contadas ocasiones, los lenguajes de patrones fueron reformulados como ADLs y también viceversa [Shaw96]. Recientemente se ha propuesto un nuevo estilo arquitectónico “de nueva generación”, ABAS (Attribute-Based Architectural Style) [KC99], que explícitamente se propone la convergencia entre la arquitectura de alto nivel expresada en los ADLs y en los estilos con el expertise, las best practices, los building blocks y los patrones decantados en la disciplina de diseño de aplicaciones.

Un estudio esencial de Mary Shaw y Paul Clements analiza la compleja influencia de la teoría y la práctica de los patrones sobre los ADLs [SC96]. Estos autores consideran que los ADLs han sido propios de la comunidad de arquitectos de software, mientras que los patrones de diseño y sus respectivos

lenguajes han prosperado entre los diseñadores de software, particularmente entre los grupos más ligados a la orientación a objetos.

Naturalmente, ambas comunidades se superponen en más de un respecto. En lo que 46 respecta a la relación entre arquitectura y diseño, las discusiones mantenidas en el seno de OOSPLA y en otros foros han consensuado que los diseñadores basados en patrones operan a niveles de abstracción más bajo que el de los arquitectos, pero por encima del propio de los programadores. Por otra parte, Buschmann ha documentado patrones utilizados como estilos arquitectónicos regidos por ADLs. Shaw y Clements concluyen su análisis alegando que los ADLs pueden beneficiarse incorporando elementos de tipo análogo a los patrones en las secciones que se refieren a estilos, plantillas y reglas de diseño. A similares conclusiones llegan Robert T. Monroe, Drew Kompanek, Ralph Melton y David Garlan.

Al lado de los ADLs, existen otros recursos para abordar la cuestión de los patrones de diseño. La estrategia arquitectónica de Microsoft contempla niveles de abstracción que hoy en día se resuelven. Un asset de este tipo incluye componentes, servicios, frameworks, artefactos asociados con el ciclo de vida de un desarrollo de software, patrones de diseño y documentación de best practices. Este paquete en particular es más un producto para desarrolladores arquitectónicamente orientados que para arquitectos que prefieran situarse en una tesitura más abstracta y alejada del código. En futuras versiones de VisualStudio.Net se prevé la incorporación de otros recursos, algunos de ellos construidos en torno de la edición Architect y otros desarrollados por terceras partes. Los ADLs complementan a estos assets y herramientas, lo mismo que lo seguirán haciendo las soluciones de modelado relacionadas con la tradición de UML.

2. Realiza la representación de la arquitectura propuesta. Para hacer esta presentación, usarás herramientas de diseño gráfico de arquitectura y, en base a los ejemplos mostrados en la unidad, hacer un diagrama con la arquitectura propuesta.

Propuesta de solución.

Caso de una Tienda Conveniencia.

Descripción Proceso Tienda de Conveniencia.

El proceso inicia de la siguiente manera: 1. El cliente se dirige a la tienda de conveniencia y solicita realizar un pago de servicio.

2. El operador en el sistema despliega el menú de todos los servicios.

3. El operador en el sistema elige la empresa y digita el importe a cobrar.

4. El operador en el pos escanea el código de barras.  Si reconoce el código el sistema detecta los campos del facturador.  Si no reconoce el código, hay opciones: a. Opción 1: finaliza la operación.

b. Opción 2: Digita la línea de captura.

5. En caso de digitar la línea de captura o el sistema detectar los campos del facturador, el operador en el sistema solicita al cliente el pago.

6. El cliente realiza el pago en efectivo y solicita ticket de venta.

7. Una vez realizado el pago, se registra la operación y se imprime el ticket.

8. El operador en el sistema entrega el ticket al cliente con sello de la caja, y termina el proceso para el cliente.

9. Una vez registrada la operación, se concentra la información a nivel nacional diariamente en el corporativo de la tienda de conveniencia.

10. En el corporativo se genera un reporte y se envía al emisor al día siguiente en la mañana.

11. El emisor (proveedor de servicio) recibe y revisa la información, y la cantidad a pagar.

12. Si aplica conciliación, el emisor realiza y revisa:  Si la conciliación es correcta, deposita el importe de la recaudación menos la comisión en el plazo acordado.  Si la conciliación no es correcta, el emisor solicita aclaración correspondiente.

13. El corporativo de la tienda de conveniencia revisa los soportes que tenga.  Si coinciden los montos, se realiza el pago y termina el proceso.  Si no coinciden los montos, verifica y soluciona y realiza el pago para finalmente terminar el proceso.

REQUISITOS Tecnológicos y Operativos: La inversión hardware – software no es necesaria en las tiendas de autoservicio y conveniencia para poder realizar los cobros de Servicios, sólo es necesario realizar una inversión en dichos rubros al ser producto de las necesidades de la actualización.

Se pueden realizar compras de software para el envío y encriptación de la información a los emisores de las facturas, para de esta manera poder proporcionarles un mejor servicio en el envío de la información.

Al momento de iniciar un acuerdo comercial con cada uno de los emisores de las facturas, el equipo de Sistemas de las tiendas de autoservicio y conveniencia realiza un desarrollo interno para cada una de estas empresas así como les proporcionan consultorías a las mismas. Todo lo anterior implica en el desarrollo y consultoría así como el recurso humano que debe hacer la labor.

Desde el punto de vista operativo, la tienda de autoservicio y conveniencia necesita realizar varios desarrollos dentro de los cuales se destacan:   

Desarrollo en Sistemas: el cual elabora el programa lógico para la aceptación del cobro.

Sistemas Punto de Venta: lleva a cabo la aplicación del programa en todos los puntos de venta.

Sistema Base 24: lay out de archivos y envío de información y liquidación.

Es necesario realizar capacitación al personal de cajas para llevar a cabo la operación del cobro de servicios

Propuesta Arquitectónica.

Diagrama de un patrón de Arquitectura por Capas para el caso de una tienda de Conveniencia.

Los tipos de componentes identificados que justifican la arquitectura del ejemplo son: Componentes de interfaz de usuario.

La mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicación. En nuestro ejemplo de la tienda conveniencia un sitio Web permite al usuario ver productos y realizar pedidos, y una aplicación basada en Windows® permite a los vendedores registrar los datos de las ventas de los clientes que ingresan a la tienda.

Las interfaces de usuario se implementan utilizando formularios de Windows Forms, páginas ASP.NET, controles u otro tipo de tecnología que permita procesar y dar

formato a los datos de las ventas del día, así como registrar y validar los datos entrantes procedentes de cada uno de los vendedores.

Componentes de proceso de interfaz.

La interacción del usuario con el sistema se realiza de acuerdo a un proceso predecible. En nuestro ejemplo de la aplicación de la tienda de conveniencia, se podría implementar un procedimiento que permita ver los datos del producto. De este modo, el vendedor puede verificar de productos disponibles para venta y los productos que son requeridos para abastecer, al elegir cada uno de los productos podrá ver los detalles correspondientes, descripción, cantidad existente, precio, proveedor, etc.

Del mismo modo, cuando un cliente realiza una compra, la interacción sigue un proceso predecible de recolección de datos por parte del vendedor, por el cual éste en primer lugar proporciona los detalles de los productos que desea adquirir, a continuación los detalles de pago y, por último, la información del producto entregado.

Para facilitar la sincronización y organización de las interacciones con la aplicación, resulta útil utilizar componentes de proceso de interfaz de usuario individuales. De este modo, el flujo del proceso y la lógica de administración de estado no se incluye en el código de los componentes de interfaz de usuario, por lo que varias interfaces (Web, Windows, terminales móviles para pago con tarjeta, etc.) podrán utilizar el mismo “motor” de interacción básica.

Flujos de negocio.

Una vez que el proceso de interfaz ha recopilado los datos necesarios, éstos se pueden utilizar para ejecutar un proceso de negocios. Por ejemplo, tras enviar los detalles del producto, el pago y el envío a la aplicación, puede comenzar el proceso de cobro del pago. Gran parte de los procesos de negocio conllevan la realización de varios pasos, los cuales se deben organizar y llevar a cabo en un orden determinado.

Por ejemplo: El sistema de la tienda de conveniencia necesita calcular el valor total del pedido, validar la información de la tarjeta de crédito, procesar el pago de la misma y la actualización del producto en el inventario.

El tiempo que este proceso puede tardar en completarse es indeterminado, por lo que sería preciso administrar las tareas necesarias, así como los datos requeridos para llevarlas a cabo. Los flujos de trabajo de negocio definen y coordinan los procesos de negocio de varios pasos de ejecución larga y se pueden implementar utilizando herramientas de administración de procesos de negocios, como BizTalk Business Process Management u otras herramientas, se encargan de automatizar flujos y procesos de negocio.

Componentes de negocio.

Independientemente de si el proceso de negocios consta de un único paso o de un flujo de trabajo organizado, la aplicación requerirá probablemente el uso de componentes que implementen reglas de negocio y realicen tareas de negocio.

Por ejemplo: en la aplicación de la tienda conveniencia, se deberá implementar una funcionalidad que calcule el precio total del pedido y agregue el costo adicional correspondiente a los pedidos que se entregan a domicilio. Los componentes de negocio implementan la lógica de negocio de la aplicación.

Agentes de servicios.

Cuando un componente de negocio requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de componentes que administren la semántica de la comunicación con dicho servicio.

Por ejemplo: los componentes de negocio de la aplicación podría utilizar un agente de servicios para administrar la comunicación con el servicio de autorización de tarjetas de crédito y utilizar un segundo agente de servicios para controlar la compra de tiempo aire de las compañías de servicio de telefonía celular.

Los agentes de servicios permiten aislar las particularidades de las compra de tiempo aire a varios servicios desde la aplicación y pueden proporcionar servicios adicionales, como el mapeo del formato de los datos que expone el servicio al formato que requiere la aplicación.

Interfaces de servicios.

Para exponer lógica de negocios como un servicio, es necesario crear interfaces de servicios que soporten los contratos de comunicación (comunicación basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes.

Por ejemplo: el servicio de autorización de tarjetas de crédito debe exponer una interfaz de servicios que describa la funcionalidad que ofrece el servicio, así como la semántica de comunicación requerida para llamar al mismo. Las interfaces de servicios también se denominan fachadas de negocios.

Componentes de acceso a datos.

La mayoría de las aplicaciones y servicios necesitan obtener acceso al repositorio de datos en un momento determinado del proceso de negocios.

Por ejemplo: la aplicación empresarial necesita recuperar los datos de los productos de una base de datos para mostrar a los vendedores los detalles de los mismos, así como insertar dicha información en la base de datos cuando un usuario realiza una venta. Por lo tanto, es razonable abstraer la lógica necesaria para obtener acceso a los datos (y la estructura como están estos almacenados) en una capa independiente de componentes de acceso a datos, ya que de este modo se centraliza la

funcionalidad de acceso a datos y se facilita la configuración y el mantenimiento de la misma.

Entidades de negocio.

La mayoría de las aplicaciones requieren el paso de datos entre distintos componentes.

Por ejemplo: en la aplicación de la tienda de conveniencia es necesario pasar una lista de productos de los componentes de acceso a datos a los componentes de interfaz de usuario para que éste pueda visualizar dicha lista. Los datos se utilizan para representar entidades de negocio del mundo real, como productos o ventas. Las entidades de negocio que se utilizan de forma interna en la aplicación suelen ser estructuras de datos, como DataSets de ADO.NET, DataReader o secuencias XML, aunque también se pueden implementar utilizando clases personalizadas (patrón Data Transfer Object – DTO, que representan entidades del mundo real necesarias para la aplicación, como productos, ventas, o proveedores.

Verticales de seguridad, administración operacional y comunicaciones.

La aplicación probablemente utilice también componentes para realizar la administración de excepciones, autorizar a los vendedores a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones.

Contrastando Arquitectura y Patrón de Diseño.

El uso de un patrón arquitectónico y saber la diferencia entre la variedad de ellos es importante a la hora de seleccionar cuál es el adecuado para resolver o proponer una arquitectura.

Un patrón de arquitectura surge de la idea de organizar los patrones y sus tipos comenzaron por la necesidad de hacer una distinción clara entre ellos, pues el número de patrones que se estaba conociendo llegó a ser tan alto que había siempre confusiones, surge la necesidad de replantear la clasificación para combinar arquitecturas y modelos de diseño.

Esta relación permitirá tener una clara diferenciación entre los tipos de patrones y en dónde ubicarlos respecto del tipo de sistema, al cual pertenecen identificando las características propias de cada tipo de patrón.

Categorías de Tipos de Patrones Arquitectónicos Patrones Simples.

-Filtro.

Sistemas Distribuidos.

Sistemas Interactivos.

-Servidor.

-Vista-Controlador.

Presentación-Abstracción-Control.

Patrones Adaptables

Descripción de las Diferencias.

La Arquitectura en Capas. Intenta hacer una discriminación formal de los estilos o patrones arquitectónicos separando en piezas (o subsistemas) la solución de software. El objetivo principal de la separación de los distintos componentes del software (la lógica 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 desempeñarán dentro de la solución completa. Cada capa de software en los modelos arquitectónicos es una parte que coopera para lograr los objetivos del propio sistema.

El Patrón Arquitectónico en Capas. Es más una organización jerárquica, 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 organización que se sigue en distintos ámbitos de la vida diaria no sólo del software, y por eso es otra razón por la cual su comprensión es tan fácil y natural para cualquier persona.

La manera de organizarlo también es igual que una estructura jerárquica (por niveles): Las capas inferiores están ocultas para todos (por cualquier razón que el lector desee considerar), excepto para las capas que hacen consumo de sus servicios.

En términos prácticos, 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 refinación, 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.

Patrón de Tuberías y Filtros, este tipo de patrón arquitectónico pertenece a la familia de patrones que se centra primordialmente en la reutilización y la modificación, normalmente se le conoce como proceso por lotes. El flujo de datos va de manera secuencial, directa. Los datos se transportan de manera que se ve cómo los datos se convierten en entrada o salida (depende de la perspectiva) de un filtro a otro.

Normalmente se dice que el patrón arquitectónico de tuberías 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 podría considerarse una buena área de oportunidad es que la parte de los filtros comúnmente realiza esta tarea, filtrar; pero no es forzoso que lo haga siempre, por tanto la forma más pura no se respeta.

Este patrón arquitectónico debe ser percibido como una serie de trasformaciones sucesivas, donde el flujo de datos se da a través de las tuberías y los filtros, que son quienes realizan las dichas transformaciones. En el estilo secuencial por lotesbatch sequential) los componentes son programas independientes; el supuesto es que un paso no puede seguir hasta que el anterior esté completo.

Arquitectura de Flujo de Datos. Es una familia de estilos enfatiza la reutilización y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos.

Esta arquitectura se utiliza cuando los datos de entrada se habrán de transformar en datos de salida mediante una serie de componentes para el cálculo o manipulación.

Patrón Arquitectónico Tipo “Tablero” considera dos componentes principales:  Una estructura de datos que representa el estado actual.  Una colección de componentes independientes.

La aplicación de este tipo de estilo arquitectónico es para problemas especializados, como en la resolución de problemas concernientes a inteligencia artificial, donde actúan múltiples agentes. La diversidad de soluciones que pueden alcanzar los agentes debe manejarse en una arquitectura que soporte esta complejidad. Contrastando con estilos arquitectónicos presentados en las pantallas anteriores, en aquellos la interacción era simple y directa entre partes bien definidas, por el contrario, en los tableros se hace manejo de información de diversas fuentes (agentes). Se puede llamar arquitectura multiagentes.

Arquitectura de Pizarra.  Cuándo se utiliza: Problemas no susceptibles de tratarse analíticamente. o Reconocimiento de patrones, aprendizaje de máquina, data mining. o Firmas, huellas digitales, reconocimiento de iris, rostro, etc.  Dos formas: o Repositorio. o Pizarra pura o tablero de control.  Procesamiento de señales.  Reconocimiento de habla.  Redes neuronales, algoritmo genético, simulación de templado.  Agentes autónomos (débilmente acoplados).

Ejemplos de Uso de la Aplicaci贸n de Patrones y Lenguajes.

Lenguaje Rapide.

Mediator type mediator is interface action in recibir_mensaje(d:data;s:tipo_mensaje); out enviar_mensaje_a_colega:data:C:colega end interface; module newMediator(col1:colega;col2:colega) return mediator is primer_colega: colega is col1; segundo_colega is col2; mensaje_a_recibir_primer_colega: tipo_mensaje is primer_colega.tipo_mensaje_a_recibir; mensaje_a_recibir_segundo_colega: tipo_mensaje is col2.tipo_mensaje_a_recibir; parallel when (?dat:data?T:tipo_mensaje) recibir_mensaje(?dat,?T) where ?T=mensaje_a_recibir_primer_colega do enviar_mensaje_a_colega(?dat.primer_colega); end; || when (?dat:data; ?T:tipo_mensaje) recibir_mensaje(?dat.?T) where ?T=mensaje_a_recibir_segundo_colega do enviar mensaje_a_colega(?dat.segundo_colega); end; end;

Arquitectura global del patr贸n Mediator. architecture modelo_patron_mediator is colega1:colega is newColega(leer_entero("Tipo de mensaje a enviar:"), leer_entero("Tipo de mensaje a recibir:"), leer_entero("Cantidad de mensajes a enviar:")); colega2:colega is newColega(leer_entero("Tipo de mensaje a enviar:"), leer_entero("Tipo de mensaje a recibir:"), leer_entero("Cantidad de mensajes a enviar:")); M:mediator is newMediator(colega1,colega2); connect (?D:data:?C:colega) M.enviar_mensaje_a_colega(?D,?C) => (?C:recibir_mensaje_de_mediator(?D); (?C:colega;?D:data;?T:tipo_mensaje)?C.enviar_mensaje(?T,?D) => M.recibir_mensaje(?D,?T); end;

Lenguaje Rapide Subscriber type subscriber is interface action out eliminarse_de_registros(s:subscriber); out registrarse(s:subscriber); in recibir_mensaje_de_publisher(I;informaci贸n); in aceotado(); end interface module newsubscriber() return subscriber is tipo_mensaje_a_recibir: tipo_mensaje is leer_entero("Tipo de mensaje a recibir:"); n_mensaje_a_recibir: integer is leer_entero("Canitdad de mensajes a recibir:"); mensajes_recibidos:var integer = 0; action mensaje_recibido(I:informacion); parallel when (?informacion) recibir_mensaje_de_publisher(?|) where ?|=tipo_mensaje_a_recibir do if ($mensajes_recibidos < n_mensajes_a_recibir) then mensajes_recibidos(?I); mensajes_recibidos:=$mensajes_recibidos+1; else eliminarse_de_registro(self); end if; end; || when aceptado() do registrarse (self)) end; end;

Lenguaje Java Mediator private Mediator med; private int id; private static int num = 1; public Producer( Mediator m ) { med = m; id = num++; } public void run() { int num; while (true) { med.storeMessage( num = (int)(Math.random()*100) ); System.out.print( "p" + id + "-" + num + " " ); }

} }

Lenguaje Java Proxy private Socket socket; private BufferedReader in; private PrintWriter out; public SocketProxy( String host, int port, boolean wait ) { try { if (wait) { // 2. Encapsulate the complexity/overhead of the target in the wrapper ServerSocket server = new ServerSocket( port ); socket = server.accept(); } else socket = new Socket( host, port ); in = new BufferedReader( new InputStreamReader( socket.getInputStream())); out = new PrintWriter( socket.getOutputStream(), true ); } catch( IOException e ) { e.printStackTrace(); } } public String readLine() { String str = null; try { str = in.readLine(); } catch( IOException e ) { e.printStackTrace(); } return str; } public void writeLine( String str ) { // 4. The wrapper delegates to the target out.println( str ); } public void dispose() { try { socket.close();

} catch( IOException e ) { e.printStackTrace(); } } }

Conclusiones Los patrones son simplemente una manera de hacer las cosas, aplicándolos nos proporcionan una solución a un problema y cada patrón también describe los problemas que ocurren una infinidad de veces a través de la vida cotidiana. Gracias a ellos podemos decir que de un modo podemos dar una solución un millón de veces en próximos proyectos sin tener que volver a pensar en una solución.

Con los patrones podemos obtener diferentes parámetros. Nos proporcionan soluciones robustas y bien conocidas. También formalizan y plasman una forma práctica de conocimiento arquitectónico a través de las nuevas generaciones. Tendremos con ellos una aplicación satisfactoria y se pueden generalizar y aplicar en cualquier cultura, no solo en una situación en particular.

Y gracias a la arquitectura nos permite la validación con los clientes y los desarrolladores, asegurando una adecuada funcionalidad y la implementación deseada. AL desarrollar de forma interactiva el sistema ayudará a tener un sistema completo.