1
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISIPLINARIA DE INGENIERÍA Y CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
PATRONES ARQUITECTÓNICOS PARA PROGRAMACIÓN DISTRIBUIDA
T E S I S
PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA
P R E S E N T A
MICHAEL ROJAS RODRÍGUEZ
DIRECTORES:
MC. ELIZABETH ACOSTA GONZAGA MC. JESÚS ANTONIO ALVAREZ CEDILLO
MEXICO, D.F. 2010
2
3
CARTA CESIÓN DE DERECHOS
En la Ciudad de México D.F el día 26 el mes de Noviembre del año 2010, el que suscribe Michael Rojas Rodríguez alumno del Programa de Maestría en Ciencias en Informática con número de registro B081882, adscrito a la Sección de Estudios de Posgrado de la UPIICSA-IPN, manifiesta que es autor intelectual del presente trabajo de Tesis bajo la dirección de la M. en C. Elizabeth Acosta Gonzaga y el M. en C. Jesús Antonio Álvarez Cedillo y cede los derechos del trabajo intitulado “Patrones Arquitectónicos Para Programación Distribuida”, al Instituto Politécnico Nacional para su difusión, con fines académicos y de investigación.
Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos del trabajo sin el permiso expreso del autor y/o director del trabajo. Este puede ser obtenido escribiendo a la siguiente dirección [email protected] Si el permiso se otorga, el usuario deberá dar el agradecimiento correspondiente y citar la fuente del mismo.
INSTITUTO POLITÉCNICO NACIONAL
SECRETARÍA DE INVESTIGACIÓN Y POSGRADO
4 AGRADECIMIENTOS
El principal agradecimiento es a mis padres quienes siempre me han apoyado y han creído en mi en todo momento, siempre los tengo presentes y en verdad sin ellos no seria la persona que ahora soy, todo el esfuerzo y motivación ellos me lo han otorgado. Muchas gracias Papá y Mamá por sus sabios y sinceros consejos.
A mis hermanos Connie y Sergio quienes me guían y apoyan. Se que puedo contar con ustedes siempre.
A mis profesores quienes con sus conocimientos, consejos y ayuda he podido lograr un paso más en mi carrera profesional.
A mis directores, Maestra Elizabeth Acosta gracias por todo el apoyo y buenos y sabios consejos que me ha dado. Maestro Jesús Álvarez, por la buena disposición y el apoyo en todo momento.
Finalmente quiero agradecer a la vida, al destino y a Dios por darme la oportunidad de concluir un paso mas en mi carrera profesional y por ponerme en mi camino siempre a todas las personas que me han guiado.
Muchas Gracias
Michael Rojas Rodríguez
5
Índice
Resumen ... 12
Summary ... 13
Introducción ... 14
Planteamiento de la problemática ... 16
Objetivos ... 17
Justificación ... 18
Alcances ... 19
Resultados Esperados ... 20
Limitaciones ... 20
Marco teórico ... 21
CAPITULO 1, Una visión esencial de la arquitectura de software y patrones ... 24
Sistemas de información distribuidos ... 25
Arquitectura de Software ... 31
Vistas Arquitectónicas... 39
Patrones ... 42
Tipos de Patrones ... 44
Patrones de diseño ... 44
Patrones de creación ... 46
Patrones estructurales ... 46
Patrones de comportamiento ... 47
Patrones arquitectónicos ... 49
El Futuro de los Patrones ... 51
Lenguajes de Descripción Arquitectónica (ADL’s) ... 54
Lenguaje Acme-Armi ... 58
CAPITULO 2, Patrones Arquitectónicos desde perspectivas actuales ... 60
Patrón Arquitectónico Modelo Vista Controlador (MVC) ... 61
Modelo (Model): ... 61
Vista (View): ... 61
Controlador (Controller): ... 62
Patrón Arquitectónico Broker ... 63
Objetivo del patrón Broker ... 64
6
Motivación ... 64
Usos Conocidos del patrón arquitectónico Broker ... 65
Características Benéficas del Patrón Arquitectónico Broker ... 66
Patrón Arquitectónico Pipes and Filters ... 67
Contexto ... 67
Motivación ... 67
Usos Conocidos ... 68
CAPITULO 3. Propuesta de solución usando el Patrón Arquitectónico Piramidal y la Arquitectura Piramidal de Sistemas Distribuidos ... 69
El Patrón Piramidal ... 70
Características de Niveles ... 71
Flujo de Operación del Patrón Piramidal ... 72
Características Generales ... 74
Ventajas del Patrón Piramidal ... 75
El Patrón Piramidal desde una perspectiva genérica ... 77
Introducción al caso de estudio ... 78
Modelo Básico de Operación ... 78
Procesamiento de Medios de Pago Electrónicos ... 80
Problemática ... 80
Explicación Técnica de la Problemática ... 81
Propuesta de Solución a la problemática ... 82
Flujo de Implementación del Patrón Piramidal ... 89
CAPÍTULO 4, Implementando el Patrón Piramidal. ... 92
Consideraciones Previas ... 93
Nivel Base ... 93
Nivel de Interpretación ... 94
Nivel Fuente ... 94
Primer Paso, Especificar Reglas a Nivel Base de Datos ... 95
Definición de Elementos de la Base de Datos ... 96
Nombre de la Instancia ... 96
Bases de Datos ... 96
Tablespace ... 97
Tablas... 97
Columnas ... 98
7
Vistas... 99
Índices ... 99
Llaves foráneas ... 100
Cluster ... 100
Trigger ... 100
Procedimiento ... 101
Función ... 101
Secuencia ... 101
Ligas de base de datos (database link) ... 102
Sinónimo ... 102
Paquete ... 102
Usuario ... 102
Role ... 103
Profile ... 103
Segundo Paso, Manipulación de la Base de Datos ... 104
Tercer Paso, Análisis y Desarrollo del Web Service ... 106
Cuarto Paso, Protocolos de Comunicación y Conexión con servicios ... 110
Protocolo de comunicación ... 110
Estándar ISO 8583, Conexión con el procesador bancario ... 111
Quinto paso, Lenguaje y medio de comunicación entre el nivel base e interpretación 117 Esquemas XSD como Lenguaje de Interpretación ... 117
Atributos ... 118
Ejemplo de un esquema XSD ... 119
Notación XSD para el nivel de interpretación ... 120
Solicitud de Cobro bancario ... 123
Solicitud de cancelación de un Cobro ... 128
Solicitud de Reimpresión ... 130
Solicitud de Consulta de Transacciones ... 132
Sexto Paso, Generar Programas Cliente ... 133
Creando Objetos para interacción con el nivel de interpretación ... 134
Componente Activex DLL ... 134
Solicitud de Cobro bancario a Nivel Base con Activex ... 137
Solicitud de cancelación de un Cobro a Nivel Base con Activex ... 139
Solicitud de Reimpresión a Nivel Base con Activex ... 140
8
Solicitud de Consulta de Transacciones a Nivel Base con Activex ... 141
Interfaces a las que aplica el control Activex ... 142
Descripción de Métodos de clases ... 146
Descripción de Beans de operación ... 147
Beans de Función ... 147
Interfaces a las que aplica el componente JAR. ... 148
Resultados Obtenidos... 149
Conclusiones... 150
Glosario ... 153
Bibliografía ... 157
9
Índice de Tablas
Tabla 1, Características del patrón arquitectónico Broker ... 64
Tabla 2, Herramientas del Nivel Base ... 93
Tabla 3, Herramientas del Nivel de Interpretación ... 94
Tabla 4, Herramientas del Nivel Fuente ... 94
Tabla 5, Descripción de Procedimientos ... 105
Tabla 6, Descripción de Clases ... 106
Tabla 7, Descripción de los Métodos de la Clase XMLServices ... 107
Tabla 8, Descripción de los Métodos de la Clase ISOServices ... 107
Tabla 9, Descripción de los Métodos de la Clase ValidateService ... 108
Tabla 10, Descripción de los Métodos de la Clase DBService ... 108
Tabla 11, Descripción de los Métodos de la Clase SecurityService ... 108
Tabla 12, Descripción de los Métodos de la Clase LogService ... 109
Tabla 13, Descripción de los Métodos de la Clase ComServices ... 109
Tabla 14, Descripción de los Métodos de la Clase TransactionServices ... 109
Tabla 15, BitMap de un mensaje ISO 8583 ... 114
Tabla 16, Definición de campos de los Data Elements. ... 115
Tabla 17, elementos del tag business ... 122
Tabla 18, Elementos del tag “transacction” de una solicitud de cobro ... 127
Tabla 19, Elementos del tag “transacction” de una cancelación ... 130
Tabla 20, tags complementarios de una reimpresión ... 131
Tabla 21, Flujo de Operación control Activex del Nivel Base ... 136
Tabla 22, Descripción de Clases ... 145
Tabla 23, Descripción de Métodos de Clases ... 146
Tabla 24, Descripción de Beans de Operación ... 147
Tabla 25, Beans de Función ... 148
10
Índice de Figuras
Figura1, Arquitectura de un Sistema de Venta de Productos. ... 32
Figura 2, Arquitectura CORBA ... 33
Figura 3, Modelo Vista Controlador ... 34
Figura 4, Pantalla de AcmeStudio. ... 59
Figura 5, Diagrama de secuencias que muestra gráficamente el patrón MVC. ... 62
Figura 6. Niveles del Patrón Piramidal ... 70
Figura 7, Patrón Piramidal, un enfoque genérico ... 77
Figura 8, Partes que conforman el modelo base ... 79
Figura 9, Arquitectura Actual de la aplicación de cobros bancarios ... 82
Figura 10, Procesamiento Electrónico de Transacciones. ... 84
Figura 11, Componentes del Nivel Base ... 85
Figura 12, El Lenguaje XML ... 86
Figura 13, Componentes del Nivel de Interpretación ... 87
Figura 14, Componentes del Nivel Fuente ... 88
Figura 15, Patrón Piramidal ... 89
Figura 16, Flujo de Implementación del Patrón Piramidal. ... 91
Figura 17, Agrupación de tablas transaccionales y no transaccionales ... 95
Figura 17 Protocolo de Comunicación entre el nivel de interpretación y el nivel fuente . 110 Figura 18, Pasó de mensajes IS0 8583 entre niveles de interpretación y fuente. ... 111
Figura 19, El estándar ISO 8583 ... 113
Figura 20, elemento business de los esquemas del nivel de interpretación ... 120
Figura 21, Esquema XSD para la operativa de cobros bancarios ... 123
Figura 22, Esquema para la cancelación de un cobro ... 129
Figura 23, Esquema para la reimpresión de un voucher ... 131
Figura 24, Referencia a componentes ... 133
Figura 25, Flujo de Operación control Activex del Nivel Base ... 137
Figura 26, Funciones de entrada en la DLL para generar un mensaje de cobro ... 138
Figura 27, Funciones de entrada en la DLL para generar un mensaje de cancelación .. 139
Figura 28, Funciones de entrada en la DLL para generar un mensaje de reimpresión... 140
Figura 29, Funciones de entrada en la DLL para generar un mensaje de consulta ... 141
Figura 30, Aplicación a 32bits del Nivel Base ... 142
11
Figura 31, Aplicación basada en Mobile ... 143
Figura 32, Aplicación Web del Nivel Base ... 143
Figura 33, Aplicación TPV Nivel Base ... 148
Figura 34, Patrón Piramidal de Venta de Tiempo Aire ... 151
12
Resumen
Hoy en día muchos de los grandes sistemas son pensados para operar en forma distribuida, con el fin de centralizar la información y así de llevar cada vez más orden y control en la operación de los comercios, el problema es que normalmente no se piensa en que tan fácil o difícil sería para un comercio adaptarse al sistema.
En este trabajo vamos a referirnos principalmente a la arquitectura de sistemas distribuidos y orientados a servicios, en los cuales la misma arquitectura pueda plantearse para diferentes problemas, con esto se pretende llegar a generar un patrón que sirva como base para generar soluciones tomando sus elementos.
Los patrones en la ingeniería de software sirven principalmente para dar orden a soluciones y plantear estructuras orientadas a resolver problemas recurrentes. Así también se tiene que los patrones arquitectónicos son un modelo a seguir para lograr objetivos y con esto basar las soluciones en experiencia que ya ha sido probada y en buenas practicas.
Dicho lo anterior en este trabajo se pretende también exhortar al uso y creación de patrones con el fin evitar orientar la solución a los problemas en aplicaciones sumamente específicas y en lugar de estos hacer soluciones flexibles y orientadas a la reutilización.
Es uno de los principales fines de este trabajo obtener un patrón base y flexible que permita ser implementado en sistemas distribuidos con información centralizada que pretendan ofrecer servicios a una gran cantidad de comercios sin importar que algún comercio maneje alguna infraestructura especial, es decir se pretende que existan componentes adaptables a diferentes necesidades. En resumen tener un patrón genérico a soluciones distribuidas orientadas a servicios.
13
Summary
Today many large systems are designed to operate in a distributed way, in order to centralize information and have more order and control in the operation of businesses, the problem is that usually we don´t think it would be easy or difficult for trade adapt to the system.
In this paper we refer mainly to the architecture of distributed systems and service- oriented, in which the same architecture may be suggested for different problems, with this we pretend to eventually generate a pattern that serves as a basis to build solutions taking its elements.
Patterns in software engineering are mainly used to give order to bring solutions and structures for solving recurring problems. This also has the architectural patterns that are a model for achieving this objective and solutions based on experience that has already been proven and best practices.
Also in this paper, we encourage the use and creation of patterns to avoid, guiding the solution to the problems in very specific applications and instead they can create flexible solutions designed for reusing.
One of the main purposes of this paper to obtain a flexible base pattern, which allows it to be implemented in distributed systems with centralized information seeking to provide services to a large number of businesses regardless of any trade drive a special infrastructure, it was use to said, intended to be components adaptable to different needs.
In short, having a generic pattern for distributed solutions, service oriented.
14
Introducción
La intención de este trabajo nace del esfuerzo de continuar con la creación de generar soluciones genéricas para problemas o situaciones recurrentes y para generación de soluciones que puedan masificarse, principalmente basadas en servicios.
Si un mismo problema se presenta en un entorno diferente no se tenga que diseñar de nuevo otra solución.
Nace con la necesidad de que un evento se presenta recurrentemente en varios contextos y se puede dar solución una sola vez y con base a un patrón poder reutilizar esa solución exitosamente. Hablamos de la solución como un todo como el esqueleto o la estructura, es decir, se piensa combatir el problema desde una perspectiva más amplia y general.
Tenemos que existen situaciones que se pueden presentar en diferentes escenarios y en forma recurrente dentro de un contexto distribuido.
Las situaciones pueden ser:
• Nuevas funcionalidades.
• Creación de componentes o módulos.
• Mejoras a las funcionalidades.
• Para lo cual se propone una forma estándar para crear un patrón arquitectónico que permita replicar una solución de una situación específica dentro de un contexto distribuido.
Para lo cual se deben tomar en cuenta varias situaciones que a continuación se describen:
1. Conocer la situación, es decir, hacer un análisis.
2. Identificar si se trata realmente de algo recurrente y se está dando en un contexto distribuido.
15 3. Verificar si existen varios escenarios en los que pueda ser aplicada la solución o se
trata de una situación única.
4. Evaluar los escenarios en los que se presenta, con el fin de analizar la forma en que podría comportarse el patrón.
5. Identificar si ya existen patrones que puedan adaptarse.
6. Generar una pseudo solución de la situación, es decir hacer un primer acercamiento a la solución.
7. Generar un formato o utilizar uno ya existente para el patrón (GoF, IBM), o incluso hacer una combinación productiva y adaptable
8. Generar el patrón con su conjunto de pasos.
9. Probar el patrón en los diferentes escenarios y evaluar el comportamiento.
10. Hacer una retroalimentación si así lo requiriera.
11. Y por último implementar el patrón.
12. Documentación con respecto a la implementación y mantenimiento.
16
Planteamiento de la problemática
Es interesante pensar que a menudo en el ámbito empresarial se presentan diversas situaciones en forma recurrente ya sea en el mismo entorno o en entornos distintos, es decir, muchas empresas en ocasiones presentan problemas parecidos en sus procesos de negocio o con sus clientes por ejemplo el llevar en orden un inventario suele ser un problema que presentan más de una empresa de producción de artículos.
Es aún más interesante cuando son empresas más grandes o que cuentan con sucursales, es difícil controlar un problema y en ocasiones como anteriormente se menciona suelen presentarse situaciones recurrentes en diferentes entornos.
El problema se centra que muchas veces se diseña una solución a la medida para cada entorno y depende de la magnitud de la empresa los módulos, herramientas, infraestructura, costos y funcionalidades adicionales, lo que ocasiona que si el mismo problema se presenta en un entorno diferente se tenga que diseñar de nuevo otra solución para dicho entorno.
En las empresas consultoras cuando se enfrentan al diseño de una solución para alguno de sus clientes, a menudo los líderes de proyecto piensan en generar la solución más óptima en el menos tiempo posible, lo que en muchas ocasiones deriva a que se olviden del aspecto de reutilizar y no hablemos exactamente del código o de los componentes sino de la solución como tal.
Muchas veces cuando se construye una solución a la medida no se piensa más allá de que satisfaga las necesidades específicas del cliente en ese momento, muchas veces no se considera la reutilización o más común no se piensa en una arquitectura como tal al momento de estar generando la solución.
17
Objetivos
Motivar al uso y construcción de patrones arquitectónicos principalmente enfocados al desarrollo de aplicaciones distribuidas en problemas empresariales.
Demostrar que la construcción correcta de un patrón arquitectónico lleva a la reutilización de la solución en casos recurrentes y su representación en formas como imágenes y diagramas.
Exponer los elementos esenciales que debe incluir un patrón arquitectónico al momento de estar siendo construido.
Mostrar los diferentes tipos de patrones arquitectónicos y entender en qué momento pueden ser aplicados.
Sugerir una técnica para la construcción de patrones arquitectónicos enfocados al desarrollo de aplicaciones distribuidas, con el fin de que al implementar esta sugerencia de técnica se pueda llegar a un mismo resultado en diferentes contextos.
18
Justificación
En la actualidad por el crecimiento de las empresas y en general por las nuevas necesidades y la masificación del internet y otros recursos, el tipo de soluciones para una empresa está más enfocado al desarrollo de aplicaciones distribuidas, es decir, que funcionen en componentes por separado y que se encuentren en diversas capas, no obstante al momento de generar dichas soluciones es necesario contemplar la posibilidad de reutilizar dicha solución, lo que implica el uso de patrones arquitecticos aplicados a soluciones distribuidas.
Con el uso de patrones se abre la posibilidad de llevar una solución a diversos entornos empresariales, implicar a los patrones como parte del diseño y construcción de una aplicación pone en ventaja a la empresa desarrolladora de la solución.
En muchas organizaciones que se dedican al desarrollo de sistemas distribuidos la mayoría de las veces no se considera el uso de patrones arquitectónicos, ya que como se comentaba anteriormente, se prefiere basar los esfuerzos en el desarrollo de aplicación rápidas y totalmente a la medida, muchas veces no se considera invertir el tiempo suficiente en diseñar un patrón que en su momento al encontrar algún problema similar puede aplicarse sin volver a centrar esfuerzos en el diseño, puesto que en ese caso la estructura de la aplicación ya estaría lista.
Es importante considerar que si una vez se trabaja como se debe no habrá necesidad de hacer lo mismo de nuevo, más cuando el problema se presenta de forma recurrente.
19
Alcances
Partiendo de la definición de patrones arquitectónicos, que dice que son aquellos que definen la estructura de un sistema software, los cuales a su vez se componen de subsistemas con sus responsabilidades, también tienen una serie de directivas para organizar los componentes del mismo sistema, con el objetivo de facilitar la tarea del diseño de tal sistema, tenemos que este trabajo tiene como fin aportar la idea de la construcción de patrones arquitectónicos principalmente en el desarrollo de aplicaciones distribuidas, con el fin de mostrar que si se trabaja una vez de forma adecuada en el futuro no es necesario centrar todos los esfuerzos en la parte de la construcción y diseño de la solución.
El trabajo mostrará los elementos esenciales de un patrón arquitectónico, las formas conocidas de hacerlo y se propondrá una alternativa basada en tres escenarios reales distintos, con el propósito de mostrar que es posible reutilizar una solución si se tiene desde un principio un enfoque genérico.
Se mostrará la forma en la que abordan el tema las dos principales empresas dedicadas al software, Microsoft y Sun Microsystems.
Es tema de este trabajo el representar los patrones propuestos a través de un ADL (Lenguaje de Descripción Arquitectónica - Architecture Description Language), con el fin de formalizar la forma de representarlo. Adicionalmente a de los ADL también se mostrarán otras formas de representar a los patrones arquitectónicos.
Se expondrán los diferentes tipos de patrones y en los casos que estos pueden ser aplicados de marea exitosa. Así de las ventajas y desventajas que tiene la construcción de patrones arquitectónicos en la programación distribuida.
20
Resultados Esperados
Se espera demostrar que el uso de patrones arquitectónicos en la construcción de aplicaciones específicamente distribuidas es muy importante y permite construir una sola vez la solución para problemas recurrentes recomendablemente en diversos contextos.
Se pretende sugerir una técnica en la construcción de patrones para aplicaciones distribuidas. Así también se pretende partir de patrones ya existentes para que sirva como apoyo en la construcción de la técnica sugerida.
Se espera demostrar a través de un experimento en tres organizaciones con el mismo problema y aplicando el mismo patrón que es posible lograr la solución del problema planteado en todos los casos.
Limitaciones
• No se expondrán a detalle patrones existentes.
• No se mostrarán a detalle especificaciones propias de los lenguajes ADL.
• No se estudiarán a detalle casos de patrones arquitectónicos no orientados a sistemas distribuidos.
• No se considerarán patrones arquitectónicos para programación paralela.
21
Marco teórico
En este trabajo se pretende hacer una investigación a base de experimentos para demostrar que la construcción y uso de patrones arquitectónicos enfocados al desarrollo de aplicaciones distribuidas permite la reutilización de la solución en diferentes contextos donde se presente un problema similar o recurrente.
El tipo de investigación que se tomará en este trabajo es la investigación aplicada ya que está basada en la búsqueda intencionada de conocimiento o soluciones a problemas y básicamente lo que en este trabajo se está buscando.
Se considera que esta investigación es aplicada, porque está relacionada con la generación de conocimientos en forma de teoría o métodos que se estima que en un período mediato podrían desembocar en aplicaciones al sector productivo.
Al momento de plantear el método para generar la técnica sugerida para la construcción de patrones arquitectónicos se tomará en cuenta el formato GoF, el cual consiste en encontrar elementos o secciones de una situación que es recurrente. Dicho formato consiste en la consideración de los siguientes elementos:
• Name
• Classification
• Intent
• Also Known As
• Motivation
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Pattern
22 Por otra parte se tomará apoyo de otro formato propuesto por F. Buschmann, R. Meunier, H. Rohnert, P.Sommerlad, y M. Stal, John Wiley and Sons para la construcción de patrones arquitectónicos, el cual consiste en los siguientes elementos:
• Name
• Problem
• Context
• Forces
• Solution
• Resulting Context
• Examples
• Rationale
• Related Patterns
• Known Uses
Se tomará en cuenta también para tomar como base el formato expuesto en el documento U.S. Treasury Architecture Development Guidance (TADG) y que es formalmente conocida como the Treasury Information System Architecture Framework ( TISAF), esta especificación describe el fundamento, estructura y taxonomía para patrones arquitectónicos y considera algunas arquitecturas de patrones enfocados a los sistemas concurrentes y distribuidos y algunos patrones enfocados a sistemas de tiempo real, lo que a este trabajo sirve como referencia para poder proponer la construcción de patrones arquitectónicos basados en aplicaciones distribuidas.
El formato definido en el documento TADG para patrones arquitectónicos, especifica que deben contener los siguientes elementos:
• Name
• Problem
• Rationale
• Assumptions
• Structure
• Interactions
• Consequences
• Implementation
23 El document TADG, considera tambien patrones ya definidos, los cuales en estre trabajo se tomarán en cuenta para apoyo a la aportación.
• Client-Proxy Server
• Customer Support
• Reactor
• Replicated Servers
• Layered Architecture
• Pipe and Filter Architecture
• Subsystem Interface
24
CAPITULO 1, Una visión esencial de la arquitectura de software y patrones
En este capítulo se expondrán temas esenciales referentes a la arquitectura de software y de los patrones, así también se busca generar una visión global del tema principal de esta tesis.
También se pretende mostrar los enfoques de estudiosos del tema como David Garlan, Paul Clements, entre otros y exponer lo que se llama el estado del arte.
Así bien en este capítulo se tocan temas como la Arquitectura de Software desde diferentes perspectivas, definición y tipos de patrones, vitas arquitectónicas, lenguajes de descripción arquitectónica, etcétera.
25
Sistemas de información distribuidos
Cuando sale a la luz el tema de los patrones arquitectónicos es posible recurrir a las aplicaciones o sistemas en los que su arquitectura está basada en programación distribuida, actualmente la mayoría de los sistemas son basados en arquitecturas distribuidas, son muy pocos los sistemas que se encuentran bajo una arquitectura monolítica.
Un sistema de información distribuido es un sistema en el cual sus componentes se transmiten información, del tipo que sea mediante mensajes, pueden intervenir varios actores, los cuales de alguna manera participan en el proceso de circulación de la información entre ellos, de forma independiente el uno del otro.
También es posible comentar que un sistema de información distribuido es una colección de elementos de que se encuentran físicamente separados y no comparten una memoria común, se comunican entre sí a través del intercambio de mensajes utilizando un medio de comunicación.
En un sistema distribuido, podemos considerar ciertos factores característicos que los definen y distinguen de otros sistemas, los cuales pueden ser:
• Cada elemento tiene su propia memoria y su propio Sistema Operativo.
• Control de recursos locales y remotos.
• Sistemas Abiertos
• Plataforma no estándar.
• Medios de comunicación.
• Capacidad de Procesamiento en paralelo.
• Dispersión y parcialidad.
26 Para que un sistema de información sea construido, deben influir ciertos factores que en su conjunto crean la necesidad de implementar un sistema distribuido, dichos factores pueden ser los siguientes:
• Avances Tecnológicos.
• Nuevos requerimientos.
• Globalización.
• Aspectos Externos.
• Integración.
Al momento de construir un sistema basado en patrones arquitectónicos distribuidos tenemos ciertas características que adquiere dicho sistema y que por ende lo hacen distinto a otro que no esté basado en este tipo de patrones. Entre dichas características están las siguientes:
• Las estaciones satisfacen las necesidades de los usuarios.
• Uso de nuevas interfaces.
• Disponibilidad de elementos de Comunicación.
• Desarrollo de nuevas técnicas.
• Respuesta Rápida.
• Ejecución Concurrente de procesos.
• Empleo de técnicas de procesamiento distribuido.
• Disponibilidad y Confiabilidad.
• Sistema poco propenso a fallas de arquitectura o definición.
• Mayores servicios que elevan la funcionalidad.
• Inclusión rápida de nuevos recursos.
• Los recursos actuales no afectan.
27 Es obvio pensar que el tener sistemas distribuidos implica tanto características benéficas como contraproducentes, entre las cuales podemos citar las siguientes:
• Se requiere poner más atención al momento del procesamiento de las instrucciones.
• La velocidad de propagación de información, en ocasiones dependiendo de la infraestructura tiende a ser lenta.
• Servicios de replicación de datos y servicios con posibilidades de fallas.
• Se debe poner más atención a los controles de acceso y a la seguridad de las aplicaciones, debido a que se encuentran más propensas a posibles hackeos o introducción de usuarios malintencionados.
• La administración suele complicarse más.
• Los costos de construcción y mantenimiento pueden ser elevados, dependiendo la planeación y negociación.
Los elementos estructurales incluyen la organización de un sistema como la composición de componentes; estructuras de control global, protocolos de comunicación, la asignación de funcionalidad a los elementos de diseño, distribución física, desempeño. Este es el nivel de arquitectura de software del diseño.
La arquitectura de software de un sistema es la estructura o estructuras del sistema, que comprenden componentes de software, las propiedades de esos componentes visibles externamente, y sus relaciones.
Las propiedades visibles externamente refieren a los supuestos que ciertos componentes pueden hacer sobre otro, como servicios, performance, manejo de errores, etcétera. Los sistemas pueden tener más de una estructura.
La arquitectura de software define componentes, agrupa información sobre cómo los componentes interactúan entre sí lo cual revela la diferencia existente entre la arquitectura de un sistema y su descripción o especificación, el comportamiento de cada componente es parte de ella en tanto es observable o deducible desde el exterior.
28 Entre los elementos estructurales que deben tomarse en cuenta existen los supuestos sobre el entorno, es decir el ambiente sobre el cual trabajará el sistema, la confiabilidad, la seguridad, la robustez, requerimientos de espacio, compatibilidad con estándares, etc.
Otros aspectos que deben ser considerados son, la naturaleza de las interacciones entre componentes, es decir la manera en la que por definición o implícitamente van a funcionar los componentes del sistema entre sí, el empaquetamiento de los componentes incluye el tipo del componente y los tipos de las interacciones que soporta, la elección es en general independiente de la funcionalidad, pero deben ser empaquetados de formas compatibles si se espera cooperación entre ellos.
A la hora de comenzar con el diseño de un patrón arquitectónico, se deben considerar dos elementos necesarios los cuales son los componentes y los conectores, estos pueden definirse como los primeros bloques de construcción de la arquitectura, se entiende que un componente es una entidad computacional que se encuentra activa, como un proceso, un objeto, etc.
Un conector se refiere al mecanismo que actúa como intermediario de la comunicación, coordinación o cooperación entre componentes.
Es importante mencionar que un patrón permite caracterizar una familia de sistemas que están relacionadas por compartir ciertas propiedades. Un patrón se puede considerar como conjunto de restricciones sobre una arquitectura.
Los patrones arquitectónicos en un ambiente distribuido, permiten con facilidad estructurar los componentes de un sistema.
Un buen diseño de un sistema de información distribuido basado en patrones arquitectónicos debe de contar con una serie de elementos tales como la transparencia, es decir cuando las peticiones de los usuarios son satisfechas, utilizando una variedad de servidores y además dichos usuarios no notan si existe un cambio en alguno de estos servicios.
En otras palabras la transparencia, significa diseñar la interfaz de llamadas al sistema de modo que no sea visible la existencia de varios procesadores.
Otro aspecto que se debe considerar en el diseño de sistemas distribuidos es la flexibilidad, es decir, al momento de ser implementado el sistema permitir cambios de
29 manera sencilla sin impactar su estructura primordial, en otras palabras debe ser adaptable.
Los sistemas distribuidos deben tomar en cuenta el aspecto de confiablidad, esto quiere decir que si una máquina falla, alguna otra debe encargarse del trabajo, esto quiere decir que el sistema siempre debe estar disponible y brindar cierta seguridad a los usuarios que lo explotan, ósea, un aspecto de la confiabilidad es la disponibilidad, que se refiere a la fracción de tiempo en que se puede utilizar el sistema.
Los datos no deben perderse o mezclarse y si los archivos se almacenan de manera redundante en varios servidores, todas las copias deben ser consistentes.
Otro aspecto de la confiabilidad general es la seguridad, lo que significa que los archivos y otros recursos deben ser protegidos contra el uso no autorizado.
Un aspecto también relacionado con la confiabilidad es la tolerancia a fallas, según la cual las fallas se deben ocultar brindando una recuperación transparente para el usuario, aunque haya cierta degradación de la performance.
El desempeño es también un factor fundamental a la hora del diseño de sistemas distribuidos, esto quiere decir que cuando se ejecuta una aplicación en un sistema distribuido no debe parecer diferente o peor que si se ejecuta de forma aislada.
El desempeño se puede parametrizar tomando algunas métricas como el tiempo de respuesta, el rendimiento, cantidad consumida de la capacidad de la red, entre otras.
Para garantizar un buen desempeño a la hora de realizar peticiones entre los módulos del sistema, se tiene que considerar el uso de protocolos de comunicación en los procesadores que intervienen en la comunicación, esto implica que se incremente el consumo del procesador.
Por lo tanto se debe considerar la minimización del número de mensajes, lo difícil es que la mejor forma de mejorar el desempeño es tener muchas actividades en ejecución al mismo tiempo, es decir, ejecución paralela en distintos procesadores.
La escalabilidad es otro aspecto, que se debe de tratar en el diseño de sistemas orientados a la programación distribuida, la tendencia indica que el tamaño de los sistemas distribuidos es hacia cientos y miles de usuarios conectados, esto implica la
30 existencia de problemas como los cuellos de botella los cuales se debe intentar evitar, algunos de estos problemas son:
• Componentes centralizados.
• Tablas centralizadas.
• Algoritmos centralizados.
Es por ello que se deben utilizar algoritmos contrarios es decir descentralizados y que cuenten con ciertas características para garantizar que un sistema distribuido cuente con un grado alto de escalabilidad.
• Ninguna máquina tiene la información completa acerca del estado del sistema.
• Las máquinas toman decisiones solo en base a la información disponible de manera local.
• El fallo de una máquina no arruina el algoritmo.
• No existe una hipótesis implícita de la existencia de un reloj global.
31
Arquitectura de Software
Existen muchas definiciones acerca de lo que es arquitectura de software, puesto que es posible agregar el tema de Arquitectura de software desde un enfoque de ingeniería o de diseño de sistemas.
Sin embargo existe una definición reconocida y aceptada de Paul Clements (Paul Clements, 1996), quien dice que: La Arquitectura de Software a grandes rasgos, es una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se le percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones.
Por su parte tenemos que David Garlan (David Garlan, 2000) establece que la Arquitectura de Software constituye un puente entre el requerimiento y el código, ocupando el lugar que en los gráficos antiguos se reservaba para el diseño, esto puede ser considerado como un enfoque demasiado amplio.
No obstante se tiene una definición formal de Arquitectura de software la cual ofrece el documento de IEEE Estándar 1471-2000 y dice de la siguiente manera:
La arquitectura de software es un conjunto de decisiones al momento del diseño del software que deben ser ejecutadas correctamente porque de lo contrario podrían cancelar todo el proyecto, es decir es un conjunto de consideraciones y de decisiones que deben ser tomadas en cuenta.
La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su diseño y evolución.
A continuación se muestra una figura que describe la arquitectura de un sistema de venta de productos y se muestra la interacción que existe entre sus diferentes componentes, desde un punto de vista de la operación del sistema.
32 Esta arquitectura se compone de cinco componentes los cuales son:
• El usuario quien es la persona física que opera el sistema y que puede ser uno o varios individuos.
• La PC que cuenta con tres periféricos, los cuales son un lector de código de barras, una impresora de tickets y un lector de tarjetas bancarias y se encargan de enviar datos al cliente procesables para el servidor. La PC también tiene instalado el software cliente que se comunica con el servidor para enviar y recibir peticiones durante la operación, pueden existir muchas PC’s con las mismas características.
• El servidor, el cual tiene instalada la base de datos donde se registran todas las operaciones realizadas por los clientes, también cuenta con salida a internet, para proveer de servicios a los clientes conectados y para enviar y recibir mensajes del componente autorizador.
• Autorizador, el cual se encarga de comunicarle al servidor el resultado de una transacción realizada con tarjeta bancaria, este es un solo componente.
• Banco es la entidad que recibe los datos del autorizador y los procesa para enviarle el resultado de la transacción, es importante mencionar que pueden existir varios bancos los cuales se comunican con el autorizador.
Figura1, Arquitectura de un Sistema de Venta de Productos.
33 Por otra parte tenemos que Mary Shaw y David Garlan (Mary Shaw, 1995), al ver que existen múltiples definiciones y enfoques de Arquitectura de Software optaron por explicar las diferencias entre las definiciones con base a distintas clases de modelos:
• Modelos Estructurales.
• Modelos de Framework.
• Modelos Dinámicos.
• Modelos de Proceso.
• Modelos Funcionales.
En cuanto a los Modelos Estructurales sostienen que la Arquitectura de Software está compuesta por componentes, conexiones entre ellos y otros aspectos tales como configuración, estilo, restricciones, semántica, análisis, propiedades, racionalizaciones, requerimientos, necesidades de los participantes, el trabajo en este modelo está caracterizado por el desarrollo de lenguajes de descripción arquitectónica. Como ejemplo podemos tomar el Sistema de la Venta de productos (Figura 1).
Para los Modelos de Framework, encontramos cierta similitud con el concepto estructural, solo que se enfoca principalmente en la estructura coherente del sistema completo, en lugar de concentrarse en su composición. Los modelos de Framework normalmente se refieren a dominios o clases de problemas específicos, es decir arquitecturas de software específicas de dominio, tales como CORBA (Figura 2).
Interfaz con el ORB Plantilla IDL
Invocación Dinámica Esqueleto IDL Esqueleto Dinámico Adaptador del Objeto
Estátio
Cliente Implementación del Objeto
Nucleo ORB
Figura 2, Arquitectura CORBA
34 Los modelos dinámicos, se concentran en la conducta de los sistemas, lo cual puede referirse a cambios en la configuración de los mismos, y su fin específicamente es que las configuraciones que contenga sean parametrizables y no fijas.
En cuanto a los modelos de proceso, estos concentran su atención en la construcción de la arquitectura y en los pasos o procesos involucrados en esa construcción, para este modelo la arquitectura de software es el resultado de seguir un script o argumento de proceso.
Los modelos funcionales ven a la arquitectura como un conjunto de componentes funcionales que se encuentran en forma de capas las cuales proporcionan servicios hacia arriba, es decir hacia los componentes que invocan a los que proporcionan el servicio, un ejemplo común de este tipo de modelo es el modelo vista controlador (Figura 3).
Figura 3, Modelo Vista Controlador
35 Para esta tesis principalmente se hará un enfoque a los modelos Estructurales basados en los ADLs y en los modelos de Framework.
Así también esta tesis está orientada a la Arquitectura basada en Patrones, que bien es un modelo que se encuentra vinculado a UML en cuanto al modelado y expresión gráfica de los componentes, en general la Arquitectura basada en patrones consiste en identificar y articular patrones preexistentes, que se definen en forma similar a los estilos arquitectónicos.
En el campo del software, la arquitectura nos identifica los elementos más importantes de un sistema así como sus relaciones. Es decir nos da una visión global del sistema.
Definir una arquitectura de software es importante porque se necesita para entender el sistema, organizar su desarrollo, plantear la reutilización del software y hacerlo evolucionar.
Generalmente las metodologías de desarrollo indican principios para identificar y diseñar una arquitectura, aunque la ayuda real que ofrecen es muy limitada al basarse en principios muy genéricos. La arquitectura de un sistema no precisamente responde requisitos estructurales, sino que está relacionada con aspectos de rendimiento, usabilidad, reutilización, restricciones económicas y tecnológicas, e incluso cuestiones estéticas.
Actualmente existen muchas metodologías de desarrollo de software, desde métodos muy pesados y burocráticos, métodos ajustables al proyecto y a las condiciones de desarrollo y métodos ligeros que surgen como respuesta a los excesos formales de otros métodos.
Evidentemente, partiendo de los principios de diversas metodologías es muy difícil sacar una visión unificada sobre el diseño arquitectónico. Sin embargo sí es posible destacar una serie de elementos comunes.
De estos elementos comunes podemos decir que el primero es la existencia de una fase en la que se establece o diseña una arquitectura base el segundo elemento es la
36 dependencia que definen entre los casos de uso y la arquitectura, definiendo un caso de uso como una interacción (secuencia de acciones) típica entre el usuario y el sistema.
Desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma importancia, destacando aquellos que nos ayudan a mitigar los riesgos más importantes y sobre todo aquellos que representan la funcionalidad básica del sistema a construir.
Esta arquitectura base estará especificada por diagramas que muestren subsistemas, interfaces entre los mismos, diagramas de componentes, clases, descripciones diversas, y por el conjunto de casos de uso básicos. Este conjunto de especificaciones permiten validar la arquitectura con los clientes y los desarrolladores, y asegurar que es adecuada para implementar la funcionalidad básica deseada.
Una visión alternativa sería identificar el tipo de sistema que se quiere construir. Es sabido que no hay dos aplicaciones iguales, pero que existen claros paralelismos entre las aplicaciones construidas para resolver problemas similares. El tomar atención en aplicaciones del mismo tipo tiene muchas ventajas ya que ayuda a entender las necesidades del cliente y las soluciones ya encontradas por otros.
Mientras que usar una metodología tradicional de desarrollo permite centrarse únicamente en parte del problema, obviando cuestiones como rendimiento, seguridad, protocolos de comunicación, restricciones de hardware, software, y económicas. Una metodología tradicional proporciona una visión estrecha, ya que frecuentemente el cliente no expone adecuadamente todos sus requisitos porque no los conoce.
Suponiendo que estamos desarrollando un portal web. La experiencia nos dice que a partir de cierto número de páginas, es útil desarrollar un sistema basado en plantillas, por la disminución de costos de mantenimiento. Esto es algo que ningún requisito funcional proporcionaría, y que probablemente tampoco surgiría de forma natural en los modelos de diseño.
A este tipo de soluciones (patrón de diseño) se llega por la experiencia en el desarrollo de sistemas y por el conocimiento de las tecnologías existentes en el mercado. Gracias a esta experiencia, desde el inicio del desarrollo de una aplicación, es posible buscar componentes que implementen ciertas tecnologías o funcionalidades, y por lo tanto
37 integrar la búsqueda de componentes y su uso dentro del proceso de desarrollo de software.
Identificar el tipo de sistema a construir permite examinar la arquitectura de sistemas ya construidos, comprender los requisitos a los que se enfrentan, y constatarlos con usuarios finales. Si se tiene en cuenta que en cualquier tipo de sistema existen necesidades similares, muchos de los componentes que se usan en su desarrollo suelen ser los mismos.
Las metodologías que gestionen de forma directa a los aspectos arquitectónicos y estructurales de un sistema, podrán producir no solo productos de mayor calidad, sino a un menor costo y en menos tiempo, esto se debe a que los riesgos arquitectónicos del proyecto son menores y están mucho más controlados, y que al poder integrar una visión orientada a componentes, las posibilidades de reutilizar software ya desarrollado son mucho mayores, con las ventajas que ello implica.
Construir una arquitectura es tanto una actividad donde desarrollar ideas nuevas como una oportunidad de usar la experiencia acumulada, siendo casi siempre responsabilidad del desarrollador crear un producto de calidad y por tanto conocer el tipo de sistema a construir. Afortunadamente para esto último, los lenguajes de patrones (ADL’s) nos pueden proporcionar mucha ayuda.
Los Lenguajes de descripción arquitectónica (ADL’s) se pueden definir como "La especificación de una serie de elementos y sus relaciones de modo que permiten describir buenas soluciones a los diferentes problemas que aparecen en un contexto específico"
(Clements, 1996).
Los patrones de diseño tienen como objetivo capturar buenas prácticas que nos permitan mejorar la calidad del diseño de un sistema, determinando elementos que soporten roles útiles en dicho contexto, encapsulando complejidad, y haciéndolo más flexible.
Por otro lado, con frecuencia se dice que la función define a la forma, es decir, que la estructura o la arquitectura de cualquier sistema está muy relacionada con lo que dicho sistema tiene que hacer. Esta es la razón por la que los sistemas con objetivos similares
38 comparten también una arquitectura común, unos procesos bien definidos, y un conjunto de elementos similares, similar funcionalidad y servicio, similar estructura.
Cuando se desarrolla un sistema que se encuadra dentro de cierto tipo, es muy útil consultar lenguajes de patrones que traten el dominio en el que estamos. Un lenguaje de patrones sirve como referencia conceptual del dominio del problema, ya que éstos parten como solución a un conjunto de casos de uso, e interacciones con actores específicos.
Además constituyen también un marco conceptual en el diseño de la arquitectura de los sistemas, ya que como la función define a la forma, sintetizan por lo general soluciones arquitectónicas y estructurales bien probadas y muy útiles dentro del tipo de problemas que modelan.
De alguna forma, los patrones nos permiten identificar y completar los casos de uso básicos expuestos por el cliente, comprender la arquitectura del sistema a construir así como su problemática, y buscar componentes ya desarrollados que cumplan con los requisitos del tipo de sistema a construir.
Un lenguaje de patrones que modele un tipo de sistema debe de ser descrito incluyendo la siguiente información:
• Características básicas que lo definen y diferencian.
• Definición de los actores principales que participan en dicho sistema así como sus casos de uso básicos, descritos evidentemente de forma genérica.
• Especificación de los principales componentes funcionales del sistema así como las relaciones entre ellos.
• Arquitectura lógica y flujos de información, que estructuran los diferentes subsistemas, el intercambio de información entre los mismos, etc.
• Arquitectura de componentes. Consiste en mapear los componentes funcionales en la arquitectura lógica de la aplicación.
• Arquitectura física. Especificación del despliegue de los componentes.
Los ADL’s deben tener una visión orientada a la construcción de software y a constituirse como elementos integrables en el proceso de desarrollo de las aplicaciones, más adelante en este capítulo se mencionaran más a detalle.
39
Vistas Arquitectónicas
Las vistas son formas que sirven para representar un aspecto parcial de una Arquitectura de Software mostrando propiedades específicas de un sistema. Se les puede considerar como parte de los bloques de un sistema.
Existen gran número de Vistas bien conocidas, cada una de las cuales revela ciertos aspectos a ser analizados de la arquitectura. Una arquitectura debe ser descrita en varias Vistas arquitectónicas relevantes.
Las Vistas pueden ser descritas gráficamente como una cantidad de componentes y conexiones, pero la semántica de estos artefactos difiere entre Vistas. De igual manera, diferentes Vistas pueden ser utilizadas para diferentes análisis.
Así también al tener un enfoque arquitectónico, tenemos que la arquitectura de un sistema consta de múltiples vistas, asociadas a diferentes dimensiones o perspectivas del sistema y ninguna de estas en particular constituye la arquitectura del sistema como tal. Estas vistas bien se encuentran dirigidas a usuarios en particular.
Tomando un enfoque del modelo de 4+1 vistas de Philippe Kruchten (Philippe Kruchten, 1995), que como su propuesta lo menciona, las vista de una arquitectura son divididas en cuatro:
• Vista Lógica.
• Vista de Proceso.
• Vista de Desarrollo.
• Vista Física.
En cada una de las vistas es notable ciertas características, como el aspecto del sistema, a quien va dirigida particularmente cada vista, así también su notación, es decir el conjunto de elementos y conectores, esenciales para generar diagramas de cada vista.
40 Cabe mencionar que para cada proyecto no todas las vistas son necesarias e importantes, pueden existir proyectos en los que por premura de tiempo, se quedan solo en Vista de Desarrollo o que se saltan la vista de proceso, etcétera.
Abundando acerca del modelo de vistas propuesto por Philippe Kruchten, tenemos que se basa mucho en la abstracción.
Por su parte la Vista Lógica, se refiere a la abstracción de las funciones del sistema y sus relaciones, la Vista Lógica se descompone en una serie de abstracciones clave, tomadas principalmente del dominio del problema en la forma de objetos o clases de objetos y se aplican los principios de abstracción, encapsulamiento y herencia.
Philippe Kruchten, considera la notación Rational/Booch, para representar la vista lógica, mediante diagramas de clases y plantillas de clases, los diagramas de clases muestran un conjunto de clases así como sus relaciones lógicas, asociaciones, uso, composición, herencia y más elementos de la Programación Orientada a Objetos (POO). Las plantillas de clases principalmente se centran en cada clase en forma individual y enfatizan las operaciones principales de la clase e identifican las principales características de los objetos.
La Vista de Procesos, toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad, principalmente esta vista se enfoca en la concurrencia y distribución, integridad del sistema y tolerancia a fallas.
En la Vista de Procesos se describe en varios niveles de abstracción donde cada nivel está enfocado a distintos intereses, se tiene que un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente. Además, los procesos pueden replicarse para aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad.
La Vista de Desarrollo, se centra en la organización de los módulos generados en ambiente de desarrollo, el software es empaquetado en pequeñas partes llamados subsistemas o bibliotecas de programas que pueden ser desarrollados por uno o más desarrolladores. Dichos subsistemas se organizan jerárquicamente en forma de capas y
41 cada capa proporciona una interfaz o componente que va apuntando hacia otras capas que se encuentra en un nivel arriba de la jerarquía.
Esta Vista, toma en cuenta aspectos como la facilidad de desarrollo, administración del software, reutilización y restricciones impuestas por el lenguaje de programación.
La Vista de Desarrollo de un sistema se debe representar en diagramas de módulos o subsistemas, la vista de desarrollo solo puede describirse completamente cuando todos los elementos han sido identificados.
Por otra parte en cuanto a la Vista Física, esta vista principalmente se refiere al mapeo del software y el hardware y sus aspectos distribuidos. Esta vista toma en cuenta requisitos que no tienen que ver con la funcionalidad del sistema como la disponibilidad, confiabilidad, performance y la escalabilidad.
En este caso como lo es el enfoque distribuido se tiene que el software se ejecuta sobre una red donde sus elementos tales como procesos, tareas y objetos, requieren ser mapeados sobre varios nodos. Con esta vista se espera que diferentes configuraciones puedan ser utilizadas, algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para diferentes usuarios, es por esto que el mapeo del software en los nodos requiere ser flexible y tener un mínimo impacto sobre el código fuente, es decir, sin tener que recompilar los módulos.
42
Patrones
Existen muchas definiciones alrededor del tema de los patrones así también muchos enfoques ya que como es sabido el tema de patrones puede aplicarse a muchas áreas del conocimiento como la arquitectura civil, la industria textil, la mecánica, etcétera. En su forma más genérica un patrón en si es un modelo a seguir que puede ser tomado en cuenta al momento de realizar algo.
Siendo exigentes con la anterior definición tenemos que en lugar de decir que el patrón se puede tomar en cuenta para hacer algo deberíamos decir que el patrón se debe tomar en cuenta el momento de hacer algo, con el fin de llevar un cierto orden y llegar a la construcción correcta de lo que se esté haciendo. Los patrones surgen de la experiencia de los seres humanos de tratar de lograr ciertos objetivos.
Los patrones son el modelo a seguir para lograr un objetivo y así basar la solución en experiencia probada y en buenas prácticas. Dicho lo anterior los patrones capturan la experiencia existente y probada para promover buenas prácticas. Los patrones fueron inicialmente concebidos por el arquitecto Christopher Alexander en su libro A Pattern Language (C. Alexander, 1977), como una manera de formalizar la solución a problemas comunes a muchos proyectos de arquitectura.
Vista la eficacia de los patrones en el campo de la arquitectura, otras disciplinas los añadieron a su repertorio de herramientas. La informática no ha sido una excepción y la adaptación de este concepto a la ingeniería del software fue con la aportación de Ward Cummingham y Kent Beck (Kent Beck, 1987) quienes adaptaron ideas de Christopher Alexander a la Ingeniería de Software y crearon cinco patrones para el diseño de las interfaces y en el año de 1995 Gamma, Helm, Johnson, Vlissides más conocidos como la pandilla de los cuatro “Gang of Four”, publican su libro Desing Patterns (Gamma, 1995), en donde hacen una recopilación de 23 patrones comunes en el diseño de software orientado a objetos. Tenemos que los patrones son una guía para la correcta arquitectura, diseño y desarrollo del software.
43 En si la generación de patrones de software se basa en capturar la experiencia de la solución a problemas que surgen en un contexto y la documentación de dicha experiencia, con el fin de que al momento de presentarse de nuevo un problema de esa índole se pueda recurrir al patrón que ayuda a la solución del problema.
Dicho de otra manera un patrón intenta capturar la experiencia, de modo que la forma correcta de resolver un problema dado pudiera ser transmitida a otras personas que aún no se ha encontrado con el problema, se trata de formalizar soluciones a distintas situaciones de modo que puedan ser entendidas por otras personas. Por lo tanto, un patrón no es más que la descripción detallada de una solución adecuada a un problema concreto.
El objetivo básico que se persigue con la idea de patrón es no tener que rehacer las cosas cada vez que se presente una cierta situación. Los patrones capturan soluciones a situaciones de especial interés, ya sea por ser muy comunes o por ser especialmente complejas. Normalmente, un patrón está compuesto por el enunciado del problema y una o varias propuestas de solución.
Para formalizar estas soluciones, se necesita una notación expresiva y rica en semántica que permita plasmar eficientemente los atributos de las mismas, para ello se utilizan herramientas como el UML o los ADL, de los cuales se hablará más a detalle.
Para que una solución sea considerada un patrón debe poseer ciertas características, una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
44
Tipos de Patrones
No existe una sola clasificación como tal, pueden ser de varios enfoques tales como:
• Patrones de Procesos (Organización, Administración, Análisis Diseño y Pruebas).
• Patrones de producto de Software (Análisis, Arquitectura, Diseño y Lenguaje de programación).
• Conjuntos de Patrones (Lenguaje de Patrones, Catalogo de Patrones, Sistema de Patrones).
• Patrones Arquitectónicos (Patrones aplicables a sistemas distribuidos).
• Patrones de diseño.
Patrones de diseño
Cuando nos referimos a patrones de diseño tenemos que son maneras de solucionar muchos problemas parecidos de una misma manera, de hecho se centran en la parte usual del componente a diseñar, y de esa forma son muy específicos.
Tenemos que son descripciones de clases cuyas instancias se relacionan y colaboran entre sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema, una arquitectura orientada a objetos está llena de patrones. Los patrones conducen a arquitecturas más pequeñas, más simples y más comprensibles, para describir un patrón debemos especificar, los siguientes elementos:
• Nombre.
• Propósito o finalidad.
• Sinónimos (otros nombres por los que puede ser conocido).
• Problema al que es aplicable.
• Estructura (diagrama de clases).
• Participantes (responsabilidad de cada clase).
45
• Colaboraciones (diagrama de interacciones).
• Implementación (consejos, notas y ejemplos).
• Otros patrones con los que está relacionado.
Aunque esta es una forma para describir el propósito, nombre y demás propiedades de los patrones existen muchos formatos o incluso se puede crear un formato propio para representar a los patrones.
Es fundamental que para apoyarse de la reutilización es necesario anticiparse a los nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada.
Cada patrón permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento.
Como se ha comentado un patrón es un esquema que supone una solución a problemas semejantes o concurrentes.
También es conveniente distinguir entre un patrón y la arquitectura del sistema como tal, por así decirlo es la misma diferencia entre el diseño de un componente y el análisis del sistema.
En general un patrón de diseño es una solución estándar para un problema común de programación, una técnica para hacer flexibilizar el código y satisfacer ciertos criterios.
Los patrones de diseño permiten a un proyecto lograr una finalidad determinada, son vistos como una manera más práctica de describir ciertos aspectos de la organización de un programa y conexiones entre componentes de programas.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten y que responden a un cierto patrón. Sería deseable tener una colección de dichos patrones con las soluciones más óptimas para cada caso.
46 Los patrones de diseño permiten que los diseños sean mucho más flexibles, modulares y reutilizables, en el libro Design Patterns (Gamma, 1995) se dice que han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos. A continuación se enlistan y describen de forma breve los patrones de diseño a objetos más habituales publicados en el libro antes mencionado.
Patrones de creación
• Abstract Factory. Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
• Builder. Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.
• Factory Method. Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.
• Prototype. Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
• Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.
Patrones estructurales
• Adapter. Convierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.
• Bridge. Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
47
• Composite. Combina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
• Decorator. Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
• Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema se más fácil de usar.
• Flyweight. Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
• Proxy. Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.
Patrones de comportamiento
• Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.
• Command. Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.
• Interpreter. Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.
• Iterator. Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
48
• Mediator. Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.
• Memento. Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.
• Observer. Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.
• State. Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
• Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.
• Template Method. Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
• Visitor. Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.
