INSTITUTO TECNOLÓGICO DE HERMOSILLO Ejemplos de aplicación de patrones arquitectónicos Estilos y Patrones de Arquitectura y Diseño de Software
Dr. Oscar Mario Rodríguez Elias García Jiménez Omar Francisco S9B 10330450
Contenido INTRODUCCIÓN ................................................................................................................................... 2 DESARROLLO ....................................................................................................................................... 3 Patrones de estructura .................................................................................................................... 3 Capas ........................................................................................................................................... 3 Tuberías y filtros .......................................................................................................................... 3 Blackboard ................................................................................................................................... 4 Patrones de distribución ................................................................................................................. 4 Broker .......................................................................................................................................... 4 Cliente-servidor ........................................................................................................................... 5 Peer to peer ................................................................................................................................. 5 Patrones de sistemas interactivos .................................................................................................. 6 Modelo Vista-Controlador .......................................................................................................... 6 Controlador-Supervisor ............................................................................................................... 7 Presentación abstracción-control ............................................................................................... 7 CONCLUSIONES ................................................................................................................................... 8 BIBLIOGRAFÍA ...................................................................................................................................... 9
1
INTRODUCCIÓN
A continuación se detallas algunos ejemplos de aplicación de patr ones arquitectónicos para el desarrollo de software, identificando las razones que los hacen candidatos a construirse usando dicho patrón por encima de otros, así como reconocer las diferencias entre algunos de estos que podrían percibirse como similares.
2
DESARROLLO
Patrones de estructura Capas Problema a resolver: Se desea desarrollar un sistema de inventario en ambiente de escritorio para una ferretería, la cual consistirá en la interfaz de usuario, la lógica de procesamiento, y una base de datos local. Patrón a utilizar: La arquitectura en capas, La programación por capas es un estilo de programación en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. Justificación: Es un sistema sencillo de corto alcance, por lo que un patrón simple que se ha utilizado muchísimas veces resulta ser suficiente. Descripción de la solución: División del sistema en las siguientes capas:
Capa de presentación: es la que ve el usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso. También es conocida como interfaz gráfica y debe tener la característica de ser entendible y fácil de usar para el usuario. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Aquí es donde se establecen todas las reglas que deben cumplirse. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
Tuberías y filtros Problema a resolver: Desarrollar una aplicación para comprar en línea es un procesamiento clásico de datos: el cliente hace un requerimiento; el requerimiento se valida; un Web Service toma el objeto de la base de datos; se lo convierte a HTML. Patrón a utilizar: Ha prevalecido el nombre de tubería-filtros por más que se sabe muy bien que los llamados filtros no realizan forzosamente tareas de filtrado, como ser eliminación de campos o registros, sino que ejecutan formas variables de transformación, una de las cuales puede ser el filtrado. Una tubería es una popular arquitectura que conecta componentes computacionales (filtros) a través de conectores (pipes), de modo que las computaciones se ejecutan a la manera de un flujo. El sistema tubería-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Los datos entran al sistema y fluyen a través de los componentes. Justificación: Es adecuado porque proporciona la secuencia de pasos necesaria para procesar las compras en un sitio de Web.
3
Descripción de la solución: En la primera etapa, se obtiene la información del producto de la base de datos de catálogo; en la siguiente, se procesa la dirección del comprador; otra etapa resuelve la modalidad de pago; una etapa ulterior confecciona la factura y otra más realiza el envío del pedido. Cada etapa de la tarea representa una categoría de trabajo.
Blackboard Problema a resolver: Se requiere desarrollar una aplicación para el reconocimiento del habla, con la capacidad de identificar frases, y mostrarlas en pantalla, así como la posibilidad de usarse como entrada para cualquier editor de texto. Patrón a utilizar: Blackboard, el cual es útil para problemas no determinísticos, consiste en subsistemas especializados que ensamblan su conocimiento para construir una solución parcial o aproximada. Justificación: Se eligió este patrón debido a que se prevé que la tarea de reconocimiento se divida en tareas independientes, cada una especializándose en resolver una parte del problema, las cuales posteriormente comunicarán los resultados de sus acciones entre sí. Descripción de la solución: Las ondas detectadas serían primeramente divididas en segmentos que contengan un significado reconocible, para después verificar la sintaxis de las posibles frases. Para esto se requieren conocimientos acústicos-fonéticos así como algoritmos estadísticos, por lo cual no es posible combinar todos los procesos para formar un único procedimiento para el reconocimiento. Además, se requieren tareas adicionales para el manejo de ambigüedades en el lenguaje, ruido de fondo en las grabaciones, así como el tratamiento frente a deficiencias de pronunciación y vocabulario.
Patrones de distribución Broker Problema a resolver: Se pretende desarrollar un sistema de información de una ciudad diseñado para ejecutarse en una red de área amplia. Algunas computadoras en la red hospedan uno o más servicios que mantienen información sobre eventos, restaurantes, hoteles, monumentos históricos, transporte público, entre otros. Los turistas, por toda la ciudad, pueden obtener la información que les interese, desde terminales, utilizando un browser WWW. Se espera que el sistema cambie y crezca continuamente, así que los servicios individuales deberán desacoplarse unos de otros. Además, el software de la term inal deberá accesar a los servicios sin conocer su localización, lo que permitirá moverlos, replicarlos o migrarlos. Patrón a utilizar: Broker reduce la complejidad en el desarrollo de aplicaciones distribuidas porque hace que la distribución sea transparente al desarrollador, mediante la introducción de un modelo de objetos en el que los servicios distribuidos se encapsulan en objetos. Por lo tanto, los sistemas Broker ofrecen una ruta para la integración de dos tecnologías: distribución y objetos Justificación: Cuando los componentes distribuidos se comunican entre sí, se requiere algún medio de comunicación entre procesos. Si los componentes manejan la comunicación por sí mismos, el sistema se enfrentará a diversas dependencias y limitaciones. Por ejemplo, si el sistema se vuelve
4
dependiente del mecanismo de comunicación utilizado, los clientes necesitan conocer la ubicación de los servidores, y, en muchos casos, la solución se limita a un solo lenguaje de programación. Se necesitan servicios para añadir, quitar, intercambiar, activar y localizar componentes. Descripción de la solución: El patrón Broker se utiliza para balancear las siguientes fuerzas:
Los componentes deben ser capaces de accesar a los servicios proveídos por otros a través de invocaciones de servicios remotos transparentes en ubicación. Se necesita intercambiar, añadir y quitar componentes en tiempo de ejecución. La arquitectura debe esconder los detalles específicos de implementación del sistema de los usuarios de componentes y servicios. Introducir un componente broker para lograr un mejor desacoplamiento de clientes y servidores. Los servidores se registran con el broker, y hacen sus servicios disponibles a los clientes a través interfaces de métodos. Los clientes accesan a la funcionalidad de los servidores enviándoles solicitudes vía el broker. Las tareas de un broker incluyen localizar el servidor apropiado, enviarle la solicitud, y transmitir resultados y excepciones, de regreso, al cliente.
Cliente-servidor Problema a resolver: Se requiere desarrollar un sencillo sitio web el cual servirá para consultar distintos libros, imágenes, notas de audio, videos, entre otros materiales, para conformar una biblioteca escolar virtual para cierta universidad. Patrón a utilizar: Cliente-servidor, arquitectura que consta de dos partes, el servidor la cual es una estructura que se ejecuta en una o varias máquinas con el objetivo de responder a las demandas de las máquinas clientes, para este fin se requiere la instalación de programas especializados, se le conoce como cliente a aquellos ordenadores que ejecutan una aplicación diseñada para comunicarse con el servidor, e interpretar la información recibida por éste. Justificación: Este patrón se perfila como el más adecuado ya que así se aprovecha mejor el ancho de banda y el hardware de los servidores, además de ofrecer una mayor seguridad y autonomía. Descripción de la solución: La aplicación constará de un único servidor en el que se alojará el material designado por el administrador para la consulta de los estudiantes, los cuales actuarían como clientes.
Peer to peer Problema a resolver: Diseñar un sistema de administración autónoma, el cual tenga la capacidad de unirse con otras aplicaciones para ejecutar y hacer comparaciones de datos bioinformáticos con los más de 25 diferentes servicios de análisis que ofrece. Uno de sus propósitos consiste en facilitar el intercambio de técnicas de análisis dentro de una comunidad local. Patrón a utilizar: Las redes P2P permiten el intercambio directo de información, en cualquier formato, entre los ordenadores interconectados. Las redes peer-to-peer aprovechan, administran y optimizan el uso del ancho de banda de los demás usuarios de la red por medio de la conectividad entre los mismos.
5
Justificación: En la actual Internet, el ancho de banda o las capacidades de almacenamiento y cómputo son recursos caros. En aquellas aplicaciones y servicios que requieran una enorme cantidad de recursos pueden usarse las redes P2P. Descripción de la solución: Implementar el sistema de tal forma que priorice la distribución de datos, obteniendo más rendimiento en las conexiones y transferencias que con algunos métodos centralizados convencionales, donde una cantidad relativamente pequeña de servidores provee el total del ancho de banda y recursos compartidos para un servicio o aplicación.
Patrones de sistemas interactivos Modelo Vista-Controlador Problema a resolver: Se requiere diseñar una aplicación web para la gestión de libros y revistas de una librería la cual debe incorporar un inicio de sesión para varios usuarios. Patrón a utilizar: MVC se basa en la separación de la aplicación en tres capas principales: Modelo, Vista y Controlador. Modelo: es la representación específica del dominio de la información sobre la cual funciona la aplicación. El modelo es otra forma de llamar a la capa de dominio. Vista: Se presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Justificación: Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo. Descripción de la solución: El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario. Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
6
Controlador-Supervisor Problema a resolver: Diseñar una aplicación de fotos que permita examinarlas, girarlas, recortarlas, etiquetarlas, categorizarlas, compartirlas en la red, así como sincronizarlas en varios dispositivos, se especificó que debía de ser una aplicación distribuida mediante la tienda de Windows. Patrón a utilizar: Controlador-Supervisor, ya que separa el comportamiento de la presentación, la interfaz de usuario y la lógica de negocios. El modelo representa el estado y las operaciones de los objetos de negocios que manipula la aplicación. El presentador contiene la lógica para responder a estos eventos, actualizar el modelo y, a su vez, manipular el estado de la vista. Justificación: El modelo de controlador supervisor sirvió para separar la vista de las responsabilidades del presentador. En la mayoría de las páginas de la aplicación, también usamos el modelo de mediador para separar y coordinar las responsabilidades de presentación. Esta separación permitió pruebas de la aplicación más sencillas y un mejor entendimiento del código. Descripción de la solución: A medida que se desarrolla la interfaz de usuario para una aplicación de carácter más declarativo, resulta más fácil separar las responsabilidades de la vista de las clases de presentador, y la vista puede interactuar directamente con los datos de la aplicación mediante el enlace de datos.
Presentación abstracción-control Problema a resolver: Consideremos un sistema de Información Electoral, se necesitan mostrar diferentes versiones, adaptan la interfaz de usuario a necesidades específicas, un ejemplo sería la opción de ver las bancas del parlamento en función de los partidos políticos. Patrón a utilizar: El patrón de arquitectura PAC define una estructura jerárquica de agentes cooperativos. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y está compuesto por tres componentes: presentación-abstracción-control. Esta subdivisión separa los aspectos de HCI (Human Computer interaction) de los agentes, del núcleo funcional de cada uno y de los mecanismos de comunicación con otros agentes. Justificación: Es adecuado ya que permite organizar el conjunto de agentes que forman parte de un sistema interactivo, para que funcionen en forma integrada. Los agentes normalmente mantienen su estado y sus datos, sin embargo tienen que cooperar y trabajar en conjunto. Los agentes proveen su propia interfaz de usuario pues cada uno tiene una cierta interacción prevista con el usuario. Sin embargo, las modalidades de interacción deben ser similares para que la HCI del producto sea homogénea. Separar la presentación, de la funcionalidad, para que los cambios en la interfaz no afecten demasiado al resto del sistema. Descripción de la solución: Roles de los agentes:
Los agentes de alto nivel proveen el núcleo de la funcionalidad del sistema. Este tipo de agente es quien coordina y estructura la funcionalidad del sistema (menús, barras de herramientas, etc), auto-contenidos, sobre los cuales los usuarios del sistema actúan. Los agentes de bajo nivel representan conceptos. Los agentes intermedios representan combinaciones o relaciones entre agentes de bajo nivel, en este tipo de agentes se pueden representar diversas vistas sobre los datos.
7
CONCLUSIONES
Con los ejemplos presentados en este documento, primeramente se reconoce la importancia de tener una estructura a seguir para el correcto desarrollo de una aplicación de software, que cumpla su objetivo y que sea eficiente, además de aprender a identificar el o los patrones (y sus variantes) más adecuadas a la hora de llevar a cabo un proyecto.
8
BIBLIOGRAFÍA
Mendoza, S. (2007, 05). Seminario de sistemas distribuidos. Posgrado en Ciencia e Ingeniería de la Computación. Recuperado 11, 2014, de http://www.mcc.unam.mx/~cursos/Algoritmos/javaDC992/broker.html Valle, J. (2005, 07). Definición arquitectura cliente servidor. Monografías. Recuperado 09, 2014, de http://www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-clienteservidor.shtml Hernández, P. (2010, 12). Red Peer to Peer. Ecured. Recuperado 10, 2014, de http://www.ecured.cu/index.php/Red_Peer_to_Peer#Aplicaciones_de_las_redes_P2P Reynoso, C. (2007, 10). Estilos y Patrones en la Estrategia de Arquitectura de Microsof. Estilos y Patrones. Recuperado 10, 2014, de http://carlosreynoso.com.ar/archivos/arquitectura/Estilos.PDF (2014, 03). Diseñar la experiencia del usuario con Hilo (aplicaciones de la Tienda Windows con C++ y XAML). Centro de desarrollo - Windows. Recuperado 11, 2014, de http://msdn.microsoft.com/es-es/library/windows/apps/jj160320.aspx (2010, 09). ASP.NET MVC 3 Framework. Universidad de Alicante. Recuperado 11, 2014, de http://si.ua.es/es/documentacion/asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html
9
