UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS FACULTAD 2
“Arquitectura para el Sistema de Registro y Control de Cuadros”
TRABAJO PARA OPTAR POR EL TÍTULO DE INGENIERÍA EN CIENCIAS INFORMÁTICAS
AUTOR
Leinier Balmaseda Pérez
TUTOR
Tte. Yosney Hernández Hernández
Ciudad de la Habana Año 2008
DECLARACIÓN DE AUTORÍA
Declaro que soy el único autor de este trabajo y autorizo a la UCID de la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio.
Para que así conste firmo la presente a los días del mes de del Año 2008.
Leinier Balmaseda Pérez Yosney Hernández Hernández
_____________________ ______________________
Firma del autor Firma del autor
PENSAMIENTO
“…y si alguna vez nuestro trabajo nos pareciera bueno, debemos de luchar porque sea mejor, debemos de luchar porque sea perfecto, sabiendo de antemano que ninguna obra humana será lo suficientemente buena, ni lo suficientemente perfecta…”
Fidel Castro Ruz
AGRADECIMIENTOS
En primer lugar a nuestro comandante en jefe por la creación de esta Universidad.
A mis padres y hermanos por ser mis guías, mi apoyo cuando más lo necesito y ayudarme en todos estos años.
A Yarislen por apoyarme y ayudarme en todo lo que hago siempre.
A mis amigos de siempre y a los compañeros de mi aula por su ayuda en estos 5 años.
A mi tutor.
A Dairon por ayudarme en todo momento, por ser mi compañero de aula y amigo.
DEDICATORIA
Le agradezco en primer lugar a la Revolución, Fidel y a esta Universidad por permitirme ser partícipe de su idea, de estar en la Primera Universidad nacida en el seno de la Batalla de Ideas.
A mis padres por ser un ejemplo a seguir en todo momento, ayudarme siempre a dar lo mejor de mí y por confiar siempre en todo lo que hago.
“La arquitectura de software, tiene que ver con el diseño y la implementación de las estructuras de software de alto nivel. El resultado de ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistemas, así como requerimientos no funcionales, como la confiabilidad, escalabilidad, portabilidad, y disponibilidad.”
Kruchten, Philippe
RESUMEN
Este trabajo de diploma tiene un estudio de los elementos de la Arquitectura de Software, durante su desarrollo se realiza el análisis de estos elementos con el objetivo de lograr una mejora en el proceso de registro y control de los cuadros de todo el país.
El éxito de esta aplicación está basado en un trabajo arquitectónico bien desarrollado, definido con las características fundamentales de las tecnologías y aspectos importantes del diseño y dándole a los miembros del equipo una idea más clara del trabajo que están desarrollando.
Esta Arquitectura para el Sistemas de Registros y Control de Cuadros se le debe hacer una modelación que sea flexible, que satisfaga los requisitos de los Analistas del sistema, que sea fácil de construir por los programadores y diseñadores y por último que cumpla con los parámetros de la funcionalidad, eficiencia y confiabilidad.
PALABRAS CLAVES
Arquitectura de software: Es la organización fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos, el ambiente y los principios que orientan su diseño y evolución.
INDICE
Contenido
INTRODUCCION ... 9
CAPITULO 1 ... 13
1.1 Introducción ... 13
1.2 ¿Qué es la Arquitectura del Software? ... 13
1.3 Arquitecturas más Universales ... 13
1.3.1 Importancia de una Arquitectura ... 14
1.4 Niveles de Arquitectura Software: ... 14
1.5 Escenarios de usabilidad sensibles a la Arquitectura del Software... 15
1.6 Ingeniería del Software Basada en Componentes ... 15
1.7 Estilos Arquitectónicos ... 16
1.7.1 Estilos de Flujo de datos ... 17
1.7.2 Estilos centrados en datos... 18
1.7.3 Estilos de Llamada y Retorno. ... 18
1.8 Lenguajes de Descripción Arquitectónica ... 19
1.9 ¿Qué relación existe entre Estilos y Patrones? ... 20
1.10 Proceso Unificado de Desarrollo y Arquitectura de Software ... 23
1.11 Lenguaje Unificado de Modelado ... 26
1.12 Servidor Web Apache ... 26
1.13 Lenguaje de programación PHP... 28
Historia ... 28
Usos de PHP ... 29
Características de PHP ... 30
Ventajas ... 30
Desventajas ... 30
1.14 Gestor de Base de Datos PostgreSQL ... 31
Funciones ... 31
1.15 Conclusiones... 32
CAPITULO 2 ... 34
2.1 Introducción ... 34
2.2 Línea Base de la Arquitectura ... 35
2.2.1 Introducción ... 35
2.2.2 Alcance ... 35
2.2.3 Metodología de Desarrollo... 36
2.2.4 Estructura de la Arquitectura ... 36
2.3Patrones Arquitectónicos ... 40
2.3.1 Patrones GRASP ... 42
2.4 Representación Arquitectónica ... 43
2.4.1 Vista de Caso de Uso ... 44
2.4.2 Vista Lógica ... 47
2.4.3 Vista de despliegue ... 49
2.4.4 Vista de implementación ... 53
CAPITULO 3 ... 55
3.1 Introducción ... 55
3.2 Evaluando la Arquitectura de Software ... 55
3.2.1 Atributos de calidad ... 55
3.2.2 ¿Por qué evaluar una Arquitectura? ... 58
3.2.3 ¿Cuándo una Arquitectura puede ser evaluada? ... 58
3.2.4 ¿Qué resultado produce la evaluación de una Arquitectura? ... 59
3.2.5 ¿Costos y beneficios de realizar una evaluación arquitectónica? ... 59
3.2.6 Técnicas de Evaluación de la Arquitectura de Software ... 61
3.3 Métodos de Evaluación de Arquitectura de Software ... 62
3.3.1 SAAM (Software Architecture Analysis Method) ... 62
3.3.2 ATAM (Architecture Trade-Off Analysis Method) ... 63
3.3.3 ARID (Active Reviews for Intermediate Designs) ... 64
3.4 Evaluando la arquitectura del proyecto Sistema de Registro y Control de Cuadros... 65
3.4.1 Metas que se persiguen ... 66
3.5 Conclusiones ... 68
CONCLUCIONES GENERALES ... 69
RECOMENDACIONES ... 70
BIBLIOGRAFIA ... 71
REFERENCIAS BIBLIOGRAFICAS ... 73
GLOSARIO DE TERMINOS... 75
INTRODUCCION
La Informática como ciencia que estudia el tratamiento automático de la información, está sujeta a los cambios tecnológicos que aparecen continuamente con tendencia al desarrollo constante. Es una corriente innovadora, dinámica y muy popular que ha cautivado la atención de la población y de las empresas a nivel internacional.
Mediante la tecnología digital y sus avances se realizan operaciones que permiten un intercambio de información seguro, rápido, y eficiente. Para logra esto se requiere de profesionales calificados, con experiencia y conocimientos en la materia para la realización de una arquitectura sólida que soporte el perfecto funcionamiento del sistema.
En nuestro país a pesar del constante bloqueo impuesto por el gobierno de los Estados Unidos desde hace 18 años atrás, se ha trazado la tarea de informatizar la sociedad cubana, asegurando así el proceso de la automatización de las escuelas, empresas e instituciones importantes para el estado.
El objetivo de esta tarea es poner a nuestro país entre las principales potencias de la producción del software a través de la creación de instituciones productoras del mismo; por ejemplo la UCI, con la finalidad de ampliar nuestra posibilidad de una mayor competencia en los mercados más importantes del mundo como lo son la Informática y las Telecomunicaciones.
En otros países incluyendo el nuestro existe un sistema para el registro y control de personas, que sirve para salvar toda la información que se necesita de alguna persona en específico. Estos sistemas requieren una programación de alto nivel y una arquitectura que se compone de diferentes estilos arquitectónicos como: Arquitectura en Capas, Orientada a Objetos, Orientada a Servicios y Basada en Componentes. Estas aplicaciones no necesitan una arquitectura en específico sino lo que hacen es una mezcla de estilos arquitectónicos, donde se da un matiz propio, según los requerimientos a satisfacer por el sistema a realizar. También es importante una reutilización de códigos y componentes de un desarrollo regido por estándares que utilicen buenas prácticas de programación y patrones de diseño para el desarrollo de una buena aplicación Web.
Las actividades relacionadas con Proceso de Registro y Control de Cuadros se realizan en la actualidad con herramientas rudimentarias y ya casi obsoletas (sistemas MS-DOS y FoxPro como gestor de base de datos), el flujo de información que existe entre las entidades es pobre y
desactualizado, las recuperaciones que se obtienen del sistema se realizan de forma estática lo que provoca que la gestión de información correspondiente a estos procesos no sea la mejor impidiendo disponer de la misma cuando se requiere e imposibilitando un buen proceso en la toma de decisiones, y se necesita guardar más información acerca de los cuadros. Se determino la necesidad de desarrollar una aplicación donde los sistemas existentes fueran reemplazados por uno que este acorde con las nuevas concepciones de la organización que lo esté usando. Por lo que se hará el uso de las tecnologías de la información en función de este proceso. Esta tarea se concibió para dar respuesta a la necesidad de registrar, controlar y evaluar, así como recuperar información de forma dinámica.
Todo esto nos impone una concepción cualitativamente nueva y superior en cuanto al empleo de una herramienta automatizada capaz de satisfacer todas las necesidades que se llevan a cabo en las entidades del país y posibilite una manera segura y fácil para su comprensión. Como meta superior en este trabajo se propone alcanzar, la realización del Sistema de Registro y Control de Cuadros de manera que satisfaga la expectativa que se espera, se propone la realización de una aplicación web utilizando la tecnología PAP (Linux, Apache, PostgreSQL, PHP).
De lo expresado anteriormente se puede deducir que la no existencia de un sistema informático con el enfoque general del problema trae consigo una serie de problemas informativos que disminuye la eficiencia del Sistema de Registro y Control de Cuadros.
Teniendo en cuanta lo antes expuesto, surge como:
Problema Común: ¿Cómo facilitar la gestión de la información del Registro y Control de Cuadros en nuestro país?
Objeto de Estudio: Los procesos de registro y control de cuadros del país.
Campo de Acción: La información de los registros y control de cuadros de las entidades del país.
Objetivo general: Desarrollar la arquitectura para el Sistema de Registro y Control de Cuadros.
Objetivos específicos: Definir módulos principales del SRCC, definir la interacción entre dichos módulos, definir las responsabilidades que tendrán cada uno de estos módulos y los CU arquitectónicamente significativos, definir la Línea Base de la Arquitectura y evaluar la Arquitectura.
Tareas de Investigación: Priorizar las CU, análisis de la arquitectura, identificar los mecanismos de diseño, estructurar el modelo de implementación, describir la arquitectura a tiempo de ejecución.
Para realizar estas tareas de investigación se hace necesario conocer estos métodos:
Métodos Teóricos:
Análisis y Síntesis: Para el proceso de la información y arribar a las conclusiones de la investigación, así como precisar las características del modelo arquitectónico propuesto.
Histórico-Lógico: Para determinar las tendencias actuales del desarrollo de los modelos y enfoques arquitectónicos.
Métodos empíricos:
Observación: Para la percepción selectiva de las restricciones y propiedades del sistema y sistémica para el control de la evolución de la arquitectura inicial.
Este trabajo esta estructurado en tres capítulos fundamentales:
Capítulo 1: Fundamentación Teórica:
Definición del marco teórico y del modelo teórico de la investigación, estudio del arte de la arquitectura del software y el rol del arquitecto.
Capítulo 2: Diseño Arquitectónico:
En este capítulo se hace una propuesta de solución al problema plateado en el diseño teórico de la investigación.
La solución planteada esta dividida en dos tópicos importantes:
Línea Base de la Arquitectura.
Documento descripción de la Arquitectura.
Capítulo 3: Evaluación de la Arquitectura:
En este capítulo esta todo lo relacionada con la evaluación de la Arquitectura de Software.
CAPITULO 1
1.1 Introducción
En el presente capítulo se hace el análisis del surgimiento de de la arquitectura del software y sus tendencias, así como los principales conceptos asociados con otros temas importantes. También se describen las principales herramientas y tecnologías que hoy en día son imprescindible a la hora de desarrollar una buena Arquitectura del Software.
1.2 ¿Qué es la Arquitectura del Software?
Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa o aplicación.
La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La Arquitectura del Software es la organización fundamental de un sistema formada por sus componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios que orientan su diseño y evolución”.
1.3 Arquitecturas más Universales
Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de información. Lo habitual es adoptar una arquitectura conocida en función de sus ventajas e inconvenientes para cada caso en concreto. Así, las arquitecturas más universales son:
Monolítica: Donde el software se estructura en grupos funcionales muy acoplados.
Cliente-Servidor: Donde el software reparte su carga de cómputo en dos partes independientes pero sin reparto claro de funciones.
Arquitectura de n Niveles o Capas: Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente.
Otras arquitecturas menos conocidas son: En pipeline, Entre Pares, En pizarras, Orientada a Servicios y Máquinas Virtuales.
Bueno teniendo en cuenta estos tipos de arquitecturas que he mencionado, la que se decidió utilizar en el proyecto es la Arquitectura de n Niveles o Capas, porque esta es una de las arquitecturas que generaliza todas las demás que le anteceden, también presenta la característica que si se tiene que realizar cambios en cualquier elemento en unas de las capas no afecta ninguna de las otras capas, por otra parte tiene una estructura bien definida como la capa presentación, la de acceso a datos, y la capa de almacenamiento, puede o no existir más capas.
1.3.1 Importancia de una Arquitectura
Se necesita una arquitectura para:
Comprender el Sistema.
Organizar el desarrollo.
Fomentar la Reutilización.
Hacer evolucionar el sistema.
1.4 Niveles de Arquitectura Software:
Arquitectura lógica: Especificación de módulos lógicos y relaciones entre los mismos.
Arquitectura física de empaquetamiento: Especificación de módulos físicos y relaciones entre los mismos.
Arquitectura física de ejecución: Especificación de componentes ejecutables, o referenciales en tiempo de ejecución; distribución de componentes y asignación de recursos.
1.5 Escenarios de usabilidad sensibles a la Arquitectura del Software
El interés por la relación entre la arquitectura del software y la usabilidad NO ES NUEVO, recientemente han aparecido trabajos que van abriendo caminos a la investigación, en este año tanto en Viena como en Edimburgo en la International Conference on Software Engineering, un equipo liderado por Len Bass impartió tutoriales sobre el tema cuyo título es bastante llamativo (“ We can’t change That!!” Software Architecture & Usability… “Esto no se puede Cambiar” Arquitectura de Software y Usabilidad).
Hasta el momento, este inventario está compuesto por 26 escenarios que se pueden consultar en el documento CMU/SEI-2001-TR-005 de Bass y otros.
La lista completa es demasiado extensa para el objetivo del presente artículo pero, a modo de ejemplo se enumeran a continuación los cinco primeros escenarios:
Agregación de datos: Poder aplicar simultáneamente una acción a un conjunto de datos u objetos.
Agregación de comandos: Agrupar acciones que se puedan ejecutar de una sola vez.
Comandos de cancelación.
Uso de aplicaciones de forma concurrente.
Validación automática de la entrada de datos.
1.6 Ingeniería del Software Basada en Componentes
La ingeniería de software basada en Componentes (Component-Based Software Engineering, CBSE) esta enmarcada en la ingeniería de software y existe un interés mayor en ella. Este está dado primeramente por la nueva concepción de desarrollo del software y la concepción que es mucho más fácil y rápido reutilizar componentes ya desarrollados y probados, a tenerlos que hacer de cero.
Los antecedentes más significativos de las plataformas de los componentes se pueden establecer en DCE y COBRA, desarrollados por iniciativa de los consorcios OSF (Open Software Foundation) y OMG (Object Management Group) respectivamente. Aunque DCE (Distributed Computing Environment), tuvo en un principio una buena acogida por parte de la industria, alguna de las limitaciones que presenta es que (no esta orientada a objetos, no define servicios de transacciones y
solo se permite invocaciones estáticas, no dinámica), le han hecho perder gran parte de su cuota de mercado en el caso de las aplicaciones distribuidas. Sin embargo, la especificación de la arquitectura COBRA (Common Object Request BrokerArchitecture), a pesar de definir una plataforma de objetos distribuidos, asienta los principios básicos de la tecnología de componentes, habiendo consolidado en gran medida su posición. Posteriormente han aparecido diversas plataformas, entre las que debemos citar, por su importancia, COM (Component Object Model), desarrollada por Microsoft y JavaBeans, desarrollada por Sun.
Estas tres plataformas constituyen los estándares en este terreno, aunque su continua evolución ha dado lugar a numerosos modelos y productos derivados, entre los que se encuentran CCM (CORBA Component Model), EJB (Enterprise Java Beans), DCOM (Distributed COM).
Uno de los campos en los que la tecnología de componentes se ha mostrado más activa es en el desarrollo de marcos de trabajo (Frameworks). Estos se definen como un diseño reutilizable de todo o parte de un sistema, representado por un conjunto de componentes abstractos, y la forma en la que dichos componentes interactúan.
El desarrollo de aplicaciones a partir de un framework se lleva a cabo mediante la extensión del mismo, para lo cual el usuario debe tener información acerca de cuáles son sus puntos de entrada y cómo adaptarlos.
Un framework: se considera como la plantilla de la aplicación o de la parte de la aplicación que se quiera desarrollar, debe ser bien seleccionado en dependencia de las restricciones del sistema y de las posibilidades que nos brinde el framework, estos a la vez no son excluibles sino que se pueden extender y combinarse para lograr una interacción entre distintas partes de un sistema.
1.7 Estilos Arquitectónicos
La clave del trabajo arquitectónico esta relacionada con la correcta elección del estilo arquitectónico.
¿Qué es un estilo arquitectónico?
Cuando se habla del término de estilo arquitectónico en la Arquitectura del Software no queda más remedio que establecer una comparación entre estilos arquitectónicos de la arquitectura civil, por ejemplo: estilos eclécticos, barrocos, clásicos, entre otros. Los estilos de la arquitectura de software definen un conjunto de concepciones arquitectónicas comunes que identifican un momento en el desarrollo de la arquitectura.
En el caso de los “estilos arquitectónicos” de software son arquitecturas de software comunes, marcos de referencias arquitectónicas, formas comunes o clases de sistemas.
Los estilos de arquitectura se definen como las 4C:
• Components (Elementos)
• Connectors (Conectores)
• Configurations (Configuraciones)
• Constraints (Restricciones)
A la hora de definir un estilo arquitectónico es necesario tener en cuenta el tipo de aplicación ya que puede imponer restricciones que acotan la interacción de los componentes, además se tiene en cuenta el patrón de organización general.
Algunos de los principales estilos arquitectónicos se usan en la actualidad están divididos por Clases de Estilos las que engloban una serie de estilos arquitectónicos específicos:
1.7.1 Estilos de Flujo de datos: Esta familia de estilos enfatiza la reutilización y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos.
• Tuberías y Filtros (estilo arquitectónico específico): Una tubería es una popular arquitectura que conecta componentes computacionales a través de conectores, de modo que el procesamiento de datos se ejecuta como un flujo. Los datos se transportan a través de las tuberías entre los filtros, transformando gradualmente las entradas en salidas. Este estilo se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada.
1.7.2 Estilos centrados en datos: Esta familia de estilos enfatiza la integrabilidad de los datos. Se estima apropiada para sistemas que se fundan en acceso y actualización de datos en estructuras de almacenamiento.
• Arquitecturas de Pizarra o repositorio: Esta arquitectura está compuesta por dos componentes principales: una estructura de datos que representa el estado actual y una colección de componentes independientes que operan sobre él. Estos sistemas se han usado en aplicaciones que requieren complejas interpretaciones de proceso de señales (reconocimiento de patrones).
1.7.3 Estilos de Llamada y Retorno: Esta familia de estilos enfatiza la modificabilidad y la escalabilidad. Son los estilos más generalizados en sistemas en gran escala.
• Arquitectura en Capas: En este estilo arquitectónico cada capa proporciona servicios a la capa superior y se sirve de las prestaciones que le brinda la inferior, al dividir un sistema en capas, cada capa puede tratarse de forma independiente, sin tener que conocer los detalles de las demás. La división de un sistema en capas facilita el diseño modular, en la que cada capa encapsula un aspecto concreto del sistema y permite además la construcción de sistemas débilmente acoplados, lo que significa que si se minimiza las dependencias entre capas, resulta más fácil sustituir la implementación de una capa sin afectar al resto del sistema.
• Arquitectura Orientada a Objetos: Los componentes de este estilo son los objetos, o más bien instancias de los tipos de dato abstractos. En la caracterización clásica de David Garlan y Mary Shaw, los objetos representan una clase de componentes que ellos llaman managers, debido a que son responsables de preservar la integridad de su propia representación. Un rasgo importante de este aspecto es que la representación interna de un objeto no es accesible desde otros objetos.
• Arquitectura basada en Componentes: Los sistemas de software basados en componentes se basan en principios definidos por una ingeniería de software específica. Los componentes son las unidades de modelado, diseño e implementación, las interfaces están separadas de las implementaciones, y conjuntamente con sus interacciones son el centro de incumbencias en el diseño arquitectónico. Los componentes soportan algún régimen de introspección, de modo que su funcionalidad y propiedades puedan ser descubiertas y utilizadas en tiempo de ejecución.
Bueno después de mencionar estos estilos, cabe mencionar que el que utilizamos en nuestro sistema es el Estilos de Llamada y Retorno, porque este estilo incluye la arquitectura que usamos nosotros, este es fácil de utilizar, trata las capas de forma independientes es decir que si cambiamos elementos en una capa no afectara la capa que la antecede o la siguiente, y así ninguna se relaciona entre si o su relación es bastante leve.
1.8 Lenguajes de Descripción Arquitectónica
Existen herramientas de modelado que soportan desarrollos basados en arquitecturas, estos son los ADLs (Architecture Description Languages). Estos lenguajes permiten construir una estructura de alto nivel, es decir sin detalles de implementación. Los ADLs son poco utilizados aunque algunos de ellos generan la plantilla de la aplicación, la presencia de UML ha hecho que estos lenguajes no hayan ocupado el lugar que debían.
Entre las características a considerar de estos lenguajes se puede citar las siguientes:
Composición. Permiten la representación del sistema como composición de una serie de partes.
Configuración. La descripción de la arquitectura es independiente de la de los componentes que formen parte del sistema.
Abstracción. Describen los roles o papeles abstractos que juegan los componentes dentro de la arquitectura.
Flexibilidad. Permiten la definición de nuevas formas de interacción entre componentes.
Reutilización. Permiten la reutilización tanto de los componentes como de la propia arquitectura.
Heterogeneidad. Permiten combinar descripciones heterogéneas.
Análisis. Permiten diversas formas de análisis de la arquitectura y de los sistemas desarrollados a partir de ella.
Entre los principales ADLs que se usan en la actualidad están:
ACME
Armani
Jacal
CHAM
1.9 ¿Qué relación existe entre Estilos y Patrones?
Una vez que se ha decidido que estilos se van a usar en la aplicación los patrones que tienen relación con estos estilos ayudaran a derivar de esa formulación arquitectónica el diseño y posteriormente la programación correspondiente.
¿Qué son los Patrones?
Los patrones fueron sugeridos por Christopher Alexander en 1977, el cual escribió una serie de libros y artículos referentes a ¿que son los patrones?, los textos más frecuentemente encontrados se refieren a patrones arquitectónicos en cuanto a arquitectura real, o sea de edificios y ciudades y no de arquitectura de aplicaciones de software. Una de las ideas brillantes de la década de los 90 fue vincular las estructuras recurrentes, aquellas entidades que ocurrían una y otra vez; las soluciones recurrentes a problemas en determinados contextos con esta idea de Alexander que estaba referida como se dijo anteriormente a la arquitectura real.
• Un patrón es la solución a un problema en un contexto.
• Un patrón codifica conocimiento específico acumulado por la experiencia en un dominio.
• Un sistema bien estructurado está lleno de patrones.
• “Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente, y luego describe el núcleo de la solución a este problema, de tal manera que puede usar esa solución un millón de veces más, sin hacer jamás la misma cosa dos veces”
Los patrones pueden dividirse o clasificarse en:
Patrones de Arquitectura: Expresan una organización estructural para un sistema de software.
Proveen un conjunto de subsistemas predefinidos e incluyen reglas y lineamientos para conectarlos.
Patrones de Diseño: que fueron construidos dado los problemas con la claridad de diseño, multiplicación de clases, adaptabilidad a requerimientos cambiantes, proponiendo como solución:
Comportamiento de factoría, Clase-Responsabilidad-Contrato (CRC).
Patrones de Análisis: Usualmente específicos de aplicación.
Patrones de Proceso o de Organización: que tratan todo lo concerniente con el desarrollo o procesos de administración de proyectos, o técnicas, o estructuras de organización.
Patrones de Idioma: que controlan la nomenclatura en la cual se escriben, se diseñan y desarrollan nuestros sistemas.
Ejemplos de Patrones de Arquitectura
Model-View-Controller: Busca agrupar componentes de las aplicaciones en tres niveles lógicos.
Layers: Descompone una aplicación en un conjunto de capas independientes y ordenadas jerárquicamente, cada nivel o capa une los servicios de la capa inmediatamente inferior y ofrece servicios a la capa inmediatamente superior.
Broker: se utiliza para organizar sistemas distribuidos por componentes débilmente acoplados que interactúan entre si invocando servicios remotos.
Bueno el patrón de arquitectura que utilizamos en nuestro sistema es el de Layers o Capas porque trabaja esas capas de forma independientes así si realizamos cambias en una capa inferior no se afecta las capas superiores, decir que estos patrones nos permiten estructurar componentes y/o subsistemas de un sistema, también que la aplicación de patrones no garantiza el éxito o mejora de su sistema de software como todo tiene ventajas y desventajas que a continuación mencionamos:
Ventajas
1- Reutilización de un mismo nivel en varias aplicaciones.
2- Permite la estandarización.
3- El cambio de nivel no afecta al resto. Pero un mal diseño o un cambio importante de funcionalidad pueden forzar a cambios que se trasmiten en cascada de un nivel al otro.
Desventajas
1- Si el número de niveles es excesivo puede ser muy ineficiente.
2- Trabajo innecesario de paso de argumentos entre niveles.
3- Si hay pocos niveles tenemos el diseño poco organizado. Si hay excesivos niveles el sistema es muy complejo e ineficiente.
Los elementos de un patrón son:
1. Nombre
• Define un vocabulario de diseño.
• Facilita la abstracción.
2. Problema
• Describe cuando aplicar el patrón.
• Conjunto de fuerzas: objetivas y restricciones.
• Prerrequisitos.
3. Solución
• Elementos que constituyen el diseño (plantilla).
• Forma canónica para resolver fuerzas.
4. Consecuencias
• Resultados.
• Extensiones.
• Consensos.
Al contrario de los estilos arquitectónicos los patrones son muchos y a su vez muy variados y es casi imposible revisar todos los patrones que existen a la hora de hacer una determinada aplicación, por eso se recomienda el uso de los patrones que estén asociados en cada uno de los estilos que se seleccionen para el desarrollo de la arquitectura.
1.10 Proceso Unificado de Desarrollo y Arquitectura de Software
Según el Proceso Unificado de Desarrollo de Software la arquitectura involucra los elementos más significativos del sistema y está influenciada entre otros por plataformas software, sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requerimientos no funcionales. Se representa mediante varias vistas que se centran en aspectos concretos.
Todas las vistas juntas forman el llamado modelo “4+1” de la arquitectura de Philippe Kruchten, vinculado al Rational Unified Process (RUP), recibe este nombre porque lo forman las vistas lógica, de
implementación, la de proceso, la de despliegue, y existe otra que es la selección de los casos de usos o lo escenarios que los arquitectos pueden generar a partir de las anteriores vistas. En este caso no se propondrá en la solución la utilización de la vista de procesos, ya que esta es opcional dependiendo de las características del sistema.
La metodología de desarrollo RUP (Proceso Unificado de Software) plantea que el rol de arquitecto es el responsable por el desarrollo y mantenimiento de la arquitectura de software, la que incluye como hemos visto las principales decisiones técnicas y las restricciones sobre el diseño e implementación del proyecto.
El rol de arquitecto existe en otras metodologías de desarrollo, con actividades diferentes pero con el mismo objetivo dentro del equipo de desarrollo.
¿Qué características debe cumplir un arquitecto?
El arquitecto ideal debe ser una persona de letras, matemático, al corriente de estudios históricos, un estudiante diligente de la filosofía, conocido de la música, no ignorante de medicina, entendido en las respuestas de consultoría jurídica, al corriente de astronomía y de cálculos astronómicos.
El arquitecto del software debe tener visión, y una profundidad de la experiencia que permite tomar decisiones rápidamente y hacer el juicio adecuado, crítico en ausencia de la información completa.
Las principales actividades que realiza el arquitecto son:
Priorizar los Casos de Uso: Definir los Casos de Uso como: críticos, secundarios, auxiliares u opcionales, lo que permite definir los módulos, subsistemas y escenarios así como la interacción entre ellos, que permita tomar decisiones hacia donde centrar los esfuerzos de implementación.
Análisis de la arquitectura: Definir la arquitectura candidata del sistema teniendo en cuenta arquitecturas similares u otros sistemas, definir además los estilos arquitectónicos, patrones de arquitectura, los principales mecanismos de diseño arquitectónico.
Identificar mecanismos de diseño: Refinar el análisis de la arquitectura teniendo en cuenta las restricciones impuestas por el entorno de implementación.
Estructurar el modelo de implementación: Permite establecer la estructura en la que va a residir la implementación del sistema.
Reutilización de elementos de diseño existentes: Permite analizar las interacciones en los diagramas de clases del Análisis para encontrar interfaces, diseño de clases y subsistemas.
Refinar la arquitectura e incorporar elementos reutilizables si es posible, identificar problemas comunes a los que se pueda crear soluciones generales o comunes (patrones, o familias de productos).
Identificar los elementos de diseño: Analizar las interacciones entre las clases de Análisis para identificar los elementos de modelo de diseño arquitectónico.
Describir la arquitectura en tiempo de ejecución: Analizar requerimientos de concurrencia, identificar los procesos y la comunicación entre dichos procesos, identificar el ciclo de vida de dichos procesos.
Los principales artefactos a desarrollar son:
Documento Descripción de la Arquitectura (4 Vistas).
Modelo de Despliegue.
Modelo de Implementación.
Protocolos.
Interfaces.
Los artefactos que se utilizan son: documento descripción de la arquitectura (4 vistas), los modelos de despliegue e implementación.
1.11 Lenguaje Unificado de Modelado
El Lenguaje Unificado de Modelado (UML) es una notación para especificar, visualizar y documentar sistemas de software desde la perspectiva orientado a objetos. Su objetivo es representar el conocimiento acerca de los sistemas que se pretenden construir y las decisiones tomadas durante su desarrollo, tanto los representados por diagramas estáticos (Casos de Uso, diagrama de clases, etc.) como los dinámicos (Diagramas de actividades, interacción, etc.). La representación en UML de un sistema de software consta de cinco vistas o modelos parciales separados, aunque relacionados entre sí, denominadas vista de casos de uso, de lógica, de implementación, de procesos y de despliegue.
Cada uno de estos modelos representa el sistema por medio de diversos diagramas. Aunque no existe de forma explícita una vista arquitectónica, estas cinco vistas pretenden describir, en su conjunto, la arquitectura del sistema.
Como una ventaja en el UML se puede señalar que es un lenguaje gráfico con sintaxis y semántica bastante bien definidas. La sintaxis de la notación gráfica se especifica mediante su correspondencia con los elementos del modelo semántico subyacente cuya semántica se define de manera semi-formal por medio de un meta-modelo, textos descriptivos y restricciones. Existen además numerosas iniciativas para dotar a esta notación de una semántica formal pero que aun no se ha consolidado.
Según diversos autores UML no es, en sí, un lenguaje de descripción arquitectónica pues su forma de expresar ciertas características, sobre todo dinámicas de las estructuras no es suficiente para los arquitectos.
1.12 Servidor Web Apache
El servidor HTTP Apache es un software libre, de código abierto para las plataformas Unix (BSD, GNY/Linux, entre otros) Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1. Cuando comenzó su desarrollo en 1995 se baso inicialmente en código del popular NCSA HTTPd 1.3 pero más tarde fue reescrito por completo. Su nombre se debe a que Behelendorf eligió ese nombre porque quería que tuviera connotación de algo que es firme y enérgico pero no agresivo, y la tribu Apache fue la última en rendirse al que pronto se convertiría en el gobierno de los EE.UU. y es ese momento la preocupación de su grupo era que se llegasen las empresas y ¨ civilizasen ¨ el paisaje que
habían creado los primeros ingenieros de Internet. Además Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA, era en inglés (a patchy Server (un servidor ¨ emparchado ¨)). El servidor Apache se desarrolla dentro de un proyecto HTTP Server (HTTPd) de la Apache Server Foundation.
Apache presenta entre otras características mensajes de error altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración.
Apache tiene amplia aceptación en la red: en el 2005, Apache fue el servidor HTTP más usado, siendo el servidor empleado en el 48% de los sitios Web en el mundo. Sin embargo ha sufrido un descenso en su cuota de mercado en los últimos años.
La mayoría de las vulnerabilidades de la seguridad descubiertas y resueltas tan sólo pueden ser aprovechadas por usuarios locales y no remotamente. Sin embargo, algunas se pueden accionar remotamente en ciertas situaciones, o explotar por los usuarios locales malévolos en las disposiciones de recibimiento compartidas que utilizan PHP como módulo de Apache.
Algunas Ventajas
Modular.
Multi-Plataforma.
Extensible.
Popular (Fácil de conseguir ayuda/soporte).
Gratuito.
El siguiente grafico ilustra el liderazgo del producto Apache en el mercado mundial:
Fig0. Por ciento de servidores utilizados en el mercado desde octubre de 1995 hasta abril de 2007.
1.13 Lenguaje de programación PHP
PHP es un lenguaje de programación usado normalmente para la creación de páginas web dinámicas.
PHP es un acrónimo recursivo que significa "PHP Hypertext Pre-processor" (inicialmente PHP Tools, o, Personal Home Page Tools), y se trata de un lenguaje interpretado. Últimamente también puede ser utilizado para la creación de otro tipo de programas incluyendo aplicaciones con interfaz gráfica usando las bibliotecas Qt o GTK+.
Historia
PHP fue originalmente diseñado en Perl, seguidos por la escritura de un grupo de CGI binarios escritos en el lenguaje C por el programador danés-canadiense Rasmus Lerdorf en el año 1994 para mostrar
su currículum vitae* y guardar ciertos datos, como la cantidad de tráfico que su página web recibía. El 8 de junio de 1995 fue publicado "Personal Home Page Tools" después de que Lerdorf lo combinara con su propio Form Interpreter para crear PHP/FI.
Usos de PHP
Los principales usos del PHP son los siguientes:
Programación de páginas web dinámicas, habitualmente en combinación con el motor de base datos MySQL, aunque cuenta con soporte nativo para otros motores, incluyendo el estándar ODBC, lo que amplía en gran medida sus posibilidades de conexión.
Programación en consola, al estilo de Perl o Shell scripting.
Creación de aplicaciones gráficas independientes del navegador, por medio de la combinación de PHP y Qt/GTK+, lo que permite desarrollar aplicaciones de escritorio en los sistemas operativos en los que está soportado.
Palabra Clave
Curriculum vitae: (en español, currículum vítae) significa literalmente “carrera de la vida”, por analogía y contraposición a cursus honorum, la carrera profesional de los magistrados Romanos. Por simplificación se usa el término curriculum o currículum, mientras que en ocasiones se puede encontrar Curriculum vitae et studiorum (carrera de vida y estudios). Con todos ellos nos referimos al conjunto de experiencias (laborales, educacionales, vivenciales) de una persona. Se aplica comúnmente en la búsqueda de empleo, siendo requisito indispensable su presentación para solicitar empleo en la mayoría de los puestos.
Características de PHP
Ventajas
Es un lenguaje multiplataforma.
Capacidad de conexión con la mayoría de los manejadores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL
Capacidad de expandir su potencial utilizando la enorme cantidad de módulos (llamados ext's o extensiones).
Posee una amplia documentación en su página oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.
Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.
Permite las técnicas de Programación Orientada a Objetos.
Biblioteca nativa de funciones sumamente amplia e incluida
No requiere definición de tipos de variables.
Tiene manejo de excepciones.
Desventajas
No posee una abstracción de base de datos estándar, sino bibliotecas especializadas para cada motor (a veces más de una para el mismo motor).
No posee adecuado manejo de internacionalización, uni-code, etc.
Framework en PHP
Zend Framework: se trata de un framework para desarrollo de aplicaciones Web y servicios Web con PHP, te brinda soluciones para construir sitios web modernos, robustos y seguros.
Además es Open Source y trabaja con PHP 5. a diferencia de CakePHP que trabaja con PHP 4 y PHP 5.
Symfony: está desarrollado completamente con PHP 5. Ha sido probado en numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de primer nivel. Symfony es compatible con la mayoría de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y Microsoft SQL Server. Se puede ejecutar tanto en plataformas *nix (Unix, Linux, etc.) como en plataformas Windows.
CakePHP: es un framework para PHP que nos permite programar más rápido evitándonos escribir código tedioso de tareas muy comunes
Kumbia: es un web framework libre escrito en PHP5. Basado en las mejores prácticas de desarrollo web, usado en software comercial y educativo, Kumbia fomenta la velocidad y eficiencia en la creación y mantenimiento de aplicaciones web, reemplazando tareas de codificación repetitivas por poder, control y placer.
Framework UCID.
1.14 Gestor de Base de Datos PostgreSQL
PostgreSQL es un servidor de base de datos objeto relacional libre, liberado bajo la licencia BSD.
Como muchos otros proyectos open source, el desarrollo de PostgreSQL no es manejado por una sola compañía sino que es dirigido por una comunidad de desarrolladores y organizaciones comerciales las cuales trabajan en su desarrollo, dicha comunidad es denominada el PGDG (PostgreSQL Global Development Group).
Funciones
Bloques de código que se ejecutan en el servidor. Pueden ser escritos en varios lenguajes, con la potencia que cada uno de ellos da, desde las operaciones básicas de programación, tales como bifurcaciones y bucles, hasta las complejidades de la programación orientación a objetos o la programación funcional.
Los disparadores (triggers en inglés) son funciones enlazadas a operaciones sobre los datos.
Algunos de los lenguajes que se pueden usar son los siguientes:
Un lenguaje propio llamado PL/PgSQL (similar al PL/SQL de oracle).
C.
C++.
Gambas
Java PL/Java web.
PL/Perl.
plPHP.
PL/Python.
PL/Ruby.
PL/sh.
PL/Tcl.
PL/Scheme.
Lenguaje para aplicaciones estadísticas R through PL/R.
PostgreSQL soporta funciones que retornan "filas", donde la salida puede tratarse como un conjunto de valores que pueden ser tratados igual a una fila retornada por una consulta (query en inglés).
Las funciones pueden ser definidas para ejecutarse con los derechos del usuario ejecutor o con los derechos de un usuario previamente definido. El concepto de funciones, en otros DBMS, son muchas veces referidas como "procedimientos almacenados" (stored procedures en inglés).
1.15 Conclusiones
En este capítulo se ha expuesto los principales aspectos dentro de la disciplina, se ha definido la Ingeniería de Software Basada en Componentes, y como la misma tiene una relación importante con la Arquitectura de Software, al igual que un estudio del arte sobre dicho tema y ampliando sobre otros temas importantes.
Se realizó el análisis de las principales definiciones y caracterizaciones de la Arquitectura de Software, los patrones arquitectónicos para ayudar a entender conceptos como: estilos arquitectónicos, marcos de trabajo (Framework) etc.
Se analizó además los principales parámetros de calidad que debe definir la calidad de la Arquitectura de Software propuesta. Se integró la metodología de desarrollo con el objeto de estudio y la relación que existe entre ellas, así como una descripción de las actividades que realiza el arquitecto que conllevan a realizar todas las tareas definidas en esta investigación.
CAPITULO 2
2.1 Introducción
Con el inicio de este capítulo se realiza una propuesta de solución al problema planteado en el diseño teórico de la investigación. Esta solución esta dividida en dos partes principales que son los artefactos fundamentales que define el arquitecto del software:
Línea Base de la Arquitectura.
Documento descripción de la Arquitectura.
A través de estos se propone una solución arquitectónica de todo sistema y en el se incluyen los demás artefactos que define la metodología que fueron expuestos en el capítulo 1.
Rol del arquitecto:
El arquitecto de Software debe dominar la mayor cantidad de tecnologías de software y prácticas de diseño, para así poder tomar decisiones adecuadas para garantizar el mejor desempeño de las aplicaciones. El rol del arquitecto de software es crítico y sumamente importante, puesto que requiere de una gran variedad de conocimientos, tales como: ingeniería de requerimientos, teoría de arquitecturas de software, codificación, tecnologías de desarrollo, plataformas de software y hardware.
De igual manera, requiere de saber negociar intereses encontrados de múltiples involucrados en el desarrollo de un sistema de software; promover la colaboración entre el equipo; entender la relación entre atributos de calidad y estructuras; ser capaz de transmitir claramente la arquitectura a los equipos; escuchar, y entender múltiples puntos de vista. El arquitecto de software debe interaccionar con todos los involucrados en el desarrollo de un sistema de software, y ser capaz de dialogar con el analista para obtener los requerimientos significativos, diseñarlos y transmitirlos al programador para su codificación.
2.2 Línea Base de la Arquitectura 2.2.1 Introducción
La Línea Base de la Arquitectura: contiene elementos de gran importancia para lograr la máxima abstracción en el diseño arquitectónico de la aplicación.
En la misma se exponen los estilos arquitectónicos de la aplicación, así como los principales elementos de la arquitectura, se describen los principales patrones de arquitectura utilizados, las tecnologías y herramientas de software que se utilizarán en el sistema a desarrollar.
El propósito de la Línea Base de la Arquitectura es: proporcionar la información necesaria para estructurar el sistema desde el más alto nivel de abstracción. En ella se describe la estructura del sistema en cuanto a los elementos, los conectores, las configuraciones y sus restricciones.
Los usuarios de la Línea Base de la Arquitectura son:
El equipo de arquitectos del proyecto, que le sirve de guía para la toma de decisiones arquitectónicas y son los encargados del mantenimiento y refinamiento de esta línea base.
Los miembros del equipo de desarrollo encargados de desarrollar la aplicación, la utilizan como la guía para la implementación del sistema.
Los clientes tienen en ella una garantía de la calidad y el conocimiento sobre en que tecnología está desarrollada su solución.
2.2.2 Alcance
La Línea Base de la Arquitectura describe la estructura del sistema en un alto nivel de abstracción.
Describe detalladamente el organigrama de la arquitectura según los estilos arquitectónicos que se utilizarán. También los principales framework de desarrollo y como se adaptarán a la solución; se propone la utilización de un conjunto de patrones que resuelven problemas que se podrían presentar a lo largo del desarrollo del sistema.
2.2.3 Metodología de Desarrollo
Este sistema se desarrollará haciendo uso de el Proceso Unificado de Desarrollo (RUP) donde se ponen de manifiesto tres elementos de desarrollo de la arquitectura como parte de la solución de un problema.
Dirigido por Casos de Uso.
Centrado en la Arquitectura.
Iterativo e Incremental.
Que el desarrollo de la solución sea guiado por lo casos de uso nos permitirá la configuración del sistema en cuanto a módulos y subsistema, teniendo en cuenta la prioridad y la complejidad de los distintos casos de usos y la seguridad, de que el producto final satisfaga los requerimientos del cliente.
Cada una de las fases en el desarrollo definidas por la metodología de desarrollo termina con la consecución de un conjunto de hitos, la terminación de cada uno de ellos no se pretende que se realicen de una vez sino que se vayan alcanzando a medida que se vayan refinando, iterando una y otra vez de acuerdo con el plan de iteraciones definidos en el Plan de Desarrollo del Sistema.
2.2.4 Estructura de la Arquitectura
Como vimos en el capítulo anterior la arquitectura de software es la estructura del sistema desde distintos sistemas de abstracción, encarnado en sus elementos, conectores, restricciones y configuraciones.
Los estilos arquitectónicos son el nivel de abstracción mayor para estructurar el sistema, la elección del mismo está dada por el tipo de aplicación que se vaya a desarrollar. A partir de los elementos mencionados anteriormente, la arquitectura del sistema se ha estructurado a partir del estilo Arquitectura en Capas (“Layers”).
Arquitectura en Capas
Fig1. Diagrama de capas del sistema.
Componentes
Los principales componentes de esta arquitectura por tres capas son:
Presentación
En esta tenemos los Componentes de Interfaz de Usuario que contienen las interfaces necesarias para que el usuario introduzca la información al sistema, y también tenemos la Lógica de Interfaz de Usuario que no es más que la validación, control de errores y control de los eventos que realiza el sistema
Fig2. Presentación de la Aplicación del Sistema.
Negocio
Aquí tenemos los Componentes de Negocio que no es más que las clases, paquetes, módulo y aplicaciones, tenemos la Lógica del Negocio que abarca la lógica de toda la aplicación y de todos los casos de usos.
Acceso a Datos
Contiene los Componentes de Acceso a Datos que estos representan las clases persistentes realizadas en Doctrine, también contiene a Lógica de Acceso a Datos que se encarga de las lógicas de accesos a datos también realizados en Doctrine.
Base de Datos
Esta capa contiene el modelo de datos de la aplicación. Esta compuesta por tablas y sus relaciones que almacenan los datos requeridos por la aplicación.
Conectores / Configuraciones
Los conectores son las formas de comunicación entre los distintos componentes o elementos definidos en el estilo arquitectónico, no es más que la forma en que está representada la información que fluye entre ellos.
Presentación – Negocio.
Estas dos capas vana a interactuar a través de un servicio HTML (XML). En la capa de Presentación se cargan las referencias Web correspondientes al WS, y de esta forma se pueden crear objetos de tipo WS para poder visualizar los servicios que brinda esta capa.
Ejemplo:
Negocio – Acceso a Datos.
La capa Negocio carga un fichero que es la librería de datos correspondientes a la capa de acceso a Datos y es así como se puede tener visibilidad a los servicios de sus métodos.
Ejemplo:
Acceso a Datos – Base de Datos.
Esta conexión se realiza a través de ADO.NET.
Este estilo facilita la modularidad del un sistema, también mejora la localización de los errores en un gran por ciento, cada una de estas capas proporcionan servicios a la capa siguiente o superior y se sirve de presentaciones que le brinda la capa inferior y las iteraciones entre dichas capas ocurren generalmente por la invocación de métodos.
Ventajas y Desventajas.
Ventajas
Permite el desarrollo paralelo del sistema por cada capa.
Facilita el mantenimiento y soporte del proyecto.
Mayor flexibilidad (se pueden añadir nuevos módulos para dotar al sistema de nueva funcionalidad).
Soporta un diseño basado en niveles de abstracción crecientes, lo cual a su vez permite a los implementadores la partición de un problema complejo en una secuencia de pasos incrementales.
Desventajas
Muchos problemas no admiten un buen mapeo en su estructura jerárquica. Incluso cuando un sistema se puede establecer lógicamente en capas, consideraciones del performance pueden requerir acoplamientos específicos de capas de alto y bajo nivel.
Los cambios de capa de bajo nivel tienden a filtrarse hacia las de alto nivel, en especial si se utiliza una modalidad relajada; también se admite que la arquitectura en capas ayuda a controlar y encapsular aplicaciones complejas, pero complica no siempre razonablemente las aplicaciones simples.
2.3 Patrones Arquitectónicos
Los patrones arquitectónicos a diferencia de los estilos expresan un problema muy específico referente al diseño. Brindan soluciones generales a problemas comunes. 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.
A continuación se describen aquellos patrones utilizados de acuerdo a las soluciones que brindan dentro del contexto del sistema.
Capas (Layers):
Consiste en estructurar aplicaciones que pueden ser descompuestas en grupos de sub-tareas, las cuales se clasifican de acuerdo a un nivel particular de abstracción. Esta descomposición en capas fomenta la reusabilidad, portabilidad, escalabilidad y ejecución de pruebas.
De esta manera se estructura la aplicación; en tres capas. Una capa de presentación la cual permite la interacción del usuario con el sistema a través de una interfaz. Una capa lógica de negocio en la cual residen las clases encargadas de controlar las peticiones provenientes de la capa de presentación, y una capa de acceso a datos la cual accede y/o modifica los mismos.
Active record y Active table:
Este patrón propone una tabla para cada clase entidad y clases intermedias que se encargan de llevar de objetos a tablas y de tablas a objetos, de hecho el framework hace invisible prácticamente para el usuario que esta trabajando con una base de datos.
Singleton:
El patrón Singleton aplica a situaciones en las cuales hay la necesidad de ser una sola instancia de una clase. El ejemplo más común de esto es una conexión de base de datos. Implementando este patrón permite a un programador hacer esta simple instancia fácilmente accesible a muchos otros objetos.
Factory:
El patrón Factory permite la instancia de objetos en tiempo de ejecución. Es llamado el patrón Factory puesto que es responsable de "manufacturar" un objeto.
2.3.1 Patrones GRASP
Los patrones GRASP (Patrones de Software para la Asignación General de Responsabilidades) basan su utilidad en definir normas o principios fundamentales en el diseño orientado a objetos y las responsabilidades de estos de acuerdo a su comportamiento. Facilitan la comprensión y sistematicidad de las soluciones implementadas.
Dentro de los patrones GRASP suelen destacarse al menos cinco (Experto, Creador, Alta cohesión, Bajo acoplamiento, Controlador). Siendo estos los más utilizados ya sea por el contexto en el que aparecen o las soluciones que brindan. De ahí que en la etapa de diseño se definió el uso de los principales patrones de asignación de responsabilidades con el objetivo de optimizar la implementación de la propuesta realizada.
Experto:
Consiste en asignarle una responsabilidad al experto en información, un caso de ello es cuando se buscan y se muestran personas o se realiza y muestra la ficha de una persona, el experto en la información es la clase controladora, que contiene a las personas con su información.
Controlador:
Asignar un controlador para evitar que las clases del negocio y las vistas tengan una comunicación directa.
Creador:
Asignar la responsabilidad de crear una instancia a una clase que la contiene o la agrega, como un especialista puede crear reportes, etc.
Alta Cohesión:
Cuando se dice que una clase tiene alta cohesión, se quiere decir que el objeto tiene bien delimitadas sus responsabilidades. En la programación orientada a objetos, cada objeto tiene una responsabilidad
que ha de cumplir dentro de un programa, en este caso todas las responsabilidades del especialista están bien definidas, es una clase altamente cohesiva.
La cohesión de un objeto significa cuán relacionadas están las acciones del objeto, de manera que sus responsabilidades sean pocas y limitadas a su función. Las responsabilidades de un objeto se traducen después en métodos que realizan acciones.
Bajo acoplamiento:
El bajo acoplamiento hace referencia a las relaciones que tienen los objetos entre si dentro de un sistema. Teóricamente, cuando una serie de objetos tienen una relación con varios objetos, cuando estos últimos son cambiados, los objetos relacionados han de verse afectados necesariamente. El alto acoplamiento se da normalmente, cuando un objeto ha de saber demasiado detalles internos de otro para su funcionamiento, es decir, se rompe el encapsulamiento de otro objeto. Por ello cuando menos acoplamiento y mayor cohesión, mejor diseñado estará el sistema.
2.4 Representación Arquitectónica
La arquitectura será representada a través de vistas, las vistas no son más que la representación de una parte específica del sistema. Las vistas por sí solas no conforman un sistema, pero la unión de ellas si conforman el SW. La representación está guiada por el proceso de desarrollo RUP, que precisamente define la representación arquitectónica mediante 5 vistas, en este caso se retomó el modelo de las “4+1” vistas arquitectónicas del modelo se Kruchten: una vista de Casos de Uso, una vista Lógica, una vista de Procesos, una de Despliegue y una última de Implementación.
Para hacer la vista de Casos de Uso se usarán diagramas de casos de uso, con los casos de usos más significativos arquitectónicamente. En la vista Lógica se representarán las clases, paquetes y sus relaciones, también se representan los subsistemas que agrupan funcionalidad del sistema, los subsistemas pueden agrupar clases y otros subsistemas, en la arquitectura solo se representan los elementos significativos para ella.
En este caso no se representó la vista de procesos, debido a que en el sistema no existen procesos concurrentes, que son los que se representan aquí. Se puede hacer o no, todo depende de la decisión del arquitecto, es decir, que en parte es opcional.
La vista de despliegue define la arquitectura física del sistema por medio de nodos interconectados.
Estos elementos son elementos hardware sobre los cuales pueden ejecutarse los elementos software.
Se representará mediante un diagrama de despliegue en el Visual Paradim. La vista de Implementación representa los componentes que se definen en el sistema con sus relaciones y las interfaces que brinda y que otros pueden usar, se usará para su representación el diagrama de implementación.
2.4.1 Vista de Caso de Uso
La vista de casos de usos en el marco arquitectónico, representa los casos de usos arquitectónicamente significativos; seleccionados a partir de los casos de uso catalogados de críticos en cada uno de los módulos que conforman el proyecto. Serían los casos de usos que modelan las principales funcionalidades del sistema de acuerdo a las exigencias del cliente.
A continuación se muestran los casos de uso arquitectónicamente significativos dentro del módulo en que se generan.
1- Módulo Actualización:
CU_Gestionar Cuadro.
CU_Buscar Cuadro.
2- Módulo Evaluación:
CU_RealizarEvaluación.
CU_GestionarPlanilla.
3- Módulo Recuperaciones:
CU_ Recuperar Ficha.
CU_ Recuperar Resumen Cualitativo.
CU_ Recuperar Resumen Cuantitativo.
De gran importancia resulta la acertada selección de aquellos casos de uso (CU) que destacan en importancia, ya que a través de estos se desarrollan múltiples actividades esenciales en la evolución del sistema. Los CU y el desarrollo de la arquitectura tienen una estrecha relación; los CU van a contribuir al desarrollo de la arquitectura del proyecto pero de igual manera a medida que se va creando la arquitectura pueden surgir nuevos CU. Los diagramas de CU constituyen una abstracción de lo que se pretende y permiten una mejor comprensión del sistema.
La vista de CU muestra cómo es percibida la funcionalidad del sistema desde el exterior, así como también describe un grupo de escenarios y CU que tiene un significado arquitectónico como ya se ha mencionado anteriormente. Es decir, la vista de casos de usos contiene los casos y los escenarios que abarcan el comportamiento más importante o que representan un mayor riesgo debido a su complejidad.
A continuación se muestra la vista de CU de cada módulo dentro del proyecto:
Fig3. Vista de los CU Buscar_Cuadro y Gestionar_Cuadro (Modulo de Actualización).
Fig4. Vista de los CU Realizar_Evaluación y Gestionar_Plantilla (Modulo de Evaluación).
Fig5. Vista de los CU Recuperar_Resumen_Cualitativo, Recuperar_Resumen_Cuantitativo, y Recuperar_Ficha (Modulo de Recuperaciones).
2.4.2 Vista Lógica
Esta sección tratará la vista lógica del proceso de desarrollo, donde se tendrán en cuenta los elementos más significativos en el flujo de trabajo de diseño. El sistema se estructuró por subsistemas funcionales, se considera subsistema a la unidad de implementación compuestas por elementos funcionales, es decir, es la agrupación de partes funcionales del sistema. Un subsistema puede estar formado por un conjunto de clases y por otros subsistemas, todo depende de cómo el desarrollador decida estructurar la aplicación. Se puede decir que los subsistemas son un agrupamiento semántico de clases y de otros subsistemas. Esta organización se realiza porque en un proyecto de gran envergadura existen miles de clases, y generalmente se hace casi imposible representarlas en un mismo diagrama, por eso se hace una organización de más alto nivel, que sería agrupar las clases en subsistemas. Entre los subsistemas se establecen relaciones en dependencia, cada subsistema brinda a los demás interfaces que estarán bien definidas por el arquitecto. Estas interfaces definirán operaciones que uno brindará y que otro u otros usarán. Este sistema está formado por tres subsistemas que serían los más significativos en cuanto a criterios de organización arquitectónica (subsistema de Actualización, subsistema de Evaluación, subsistema de Recuperaciones). La vista lógica también contendrá las clases que son más significativas desde el punto de vista de la arquitectura, estas clases se le denominan activas. La estructuración del sistema en capas fue otra de las decisiones que se tomaron a la hora de la realización de este proyecto; se estructuró el sistema en tres capas, quiere esto decir que se usará una arquitectura de n capas. Para representar la agrupación de clases se utilizó uno de los criterios de empaquetamiento. El sistema está dividido en: capa de presentación (clases clientes), capa de lógica de negocio (clases servidoras,) y capa de datos (clase de acceso a datos y clases persistentes). Las clases se relacionan entre sí, si es que existe relación entre ellas, y la relación entre los paquetes hará referencia a si los elementos que contiene el mismo usan elementos dentro del mismo paquete o de otros paquetes. Las clases se agruparon de acuerdo a su funcionalidad, todas las clases de interfaz se agruparon en un paquete, todas las controladoras en otro paquete y por último las clases persistentes se agruparon en otro paquete, esto se hizo para cada caso de uso de cada uno de los módulos.
