Título: Rediseño de la arquitectura del Software BioSyS.
Trabajo de Diploma para optar por el título de Ingeniero Informático
Autor(es): Wendy Wong Iglesias.
Yuriskenia Sarmiento Reyes.
Tutor(es): Ing. Yadira Marrero López.
Ing. Adonis R. Rosales García.
Ciudad de la Habana, 11 de Junio de 2010.
“El hombre que se levanta es aún más grande que el que no ha caído." “El hombre que se levanta es aún más grande que el que no ha caído." “El hombre que se levanta es aún más grande que el que no ha caído." “El hombre que se levanta es aún más grande que el que no ha caído."
Concepción Arenal Concepción Arenal Concepción Arenal Concepción Arenal
Declaramos ser autores de la presente tesis y reconocemos a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
Wendy Wong Iglesias Yuriskenia Sarmiento Reyes.
______________ ______________
Firma del Autor Firma del Autor
Ing. Yadira Marrero López Ing. Adonis R. Rosales García.
______________ ______________
Firma del Tutor Firma del Tutor
Autoras:
Yuriskenia Sarmiento Reyes
Universidad de las Ciencias Informáticas, Habana, Cuba.
E-mail: [email protected] Wendy Wong Iglesias
Universidad de las Ciencias Informáticas, Habana, Cuba.
E-mail: [email protected]
Tutores:
Ing. Yadira Marrero López.
Universidad de las Ciencias Informáticas, Habana, Cuba.
E-mail: [email protected]
Ing. Adonis R. Rosales García.
Universidad de las Ciencias Informáticas, Habana, Cuba.
E-mail: [email protected]
I
El agradecimiento más importante de todos es para mi Querida y adorada Madre , que es la persona que me ha apoyado en cada momento de mi vida, que ha estudiado junto conmigo todo este tiempo y que es la persona más importante de mi vida.
A mi hermano Alejandro por ser la persona que siempre está junto a mí y por creer en mí, eres el mejor hermano del mundo.
A toda mi familia, a mi tía Elba, a mi abuelita linda, a mis primos Leandro y Amaia, a mi tío Leonardo, en fin a todos los que me han apoyado en los momentos buenos y malos.
A mis tutores por la ayuda incondicional que nos han brindado, sin ellos no hubiésemos podido realizar este trabajo.
A Edel y Carlos que también formaron una parte importante de este trabajo, y de verdad que se los agradezco mucho.
A mis amigas queridas Yuriskenia, Evelyn y Veylys, que este último año hemos estado más unidas que nunca tanto en los momentos buenos como en los malos.
Agradezco este trabajo y toda mi carrera primero que todo a mis amigos de la Universidad, que estuvieron ahí durante todo este tiempo y que de una manera u otra formaron parte mi formación tanto profesional como personal.
Yuriskenia Yuriskenia Yuriskenia Yuriskenia::::
Primeramente quiero agradecerle a los seres más maravillosos de la tierra mis padres pues sin su lucha incansable de hacerme saber que si se puede nada de esto fuera posible.
A mis dos grandes hermanos Yuri y Oscarito.
A las tías más bellas del mundo Elena, Lina, Francis, Dorita y mi prima Yurisma por estar ahí siempre para mí.
A mis abuelitos que de una forma u otra ayudaron en mi crecimiento.
A mi adorado novio Raúl Concepción González por soportarme todo el tiempo y por su ayuda incondicional.
A mi segunda gran familia que me acogió como su hija y que simplemente se han dedicado a darme mucho amor Alba, Raúl y Ernesto.
A mis amigas de los años que siempre pusieron su granito de arena Michy, Liyanis y Yamira.
Al club de las Supernenas que a pesar de las distancias se preocuparon por mí May, Kil, Yeni, Mire, Yas, Liset y Kenia.
A Edel y Carlos, les agradezco con la vida que nos hayan ayudado.
A nuestros tutores que nos recogieron cuando creíamos que todo estaba perdido.
A mis nuevas guerreras de lucha Wendy, Evelyn y Veylys que estuvimos muy unidas para enfrentarlo todo.
En fin a todos los que han hecho posible que este sueño se haga realidad muchas gracias.
II Wendy:
Wendy:
Wendy:
Wendy:
Le dedico este trabajo a las personas más importantes en mi vida, mi madre y a mi querido y adorado hermano, que siempre creyeron en mí. Los quiero mucho.
Yuriskenia:
Yuriskenia:
Yuriskenia:
Yuriskenia:
Quiero dedicarle esta tesis especialmente a mis padres Adela y Fidel por ser mi razón ser, por estar siempre en las buenas y en las malas y por poner todo su empeño en convertirme en una mejor persona.
A mi hermanita del alma que aunque nos veamos poco siempre está en mi corazón.
Y a mi queridísimo abuelo Rey que siempre quiso verme convertida en una profesional, esto es para él.
Amba Amba Amba Ambas:s:s:s:
A la Revolución y a nuestro comandante en jefe Fidel Castro por darnos la oportunidad de pertenecer a esta genial idea que es la Universidad de las Ciencias Informática.
III El Software para la Simulación y Análisis de los Sistemas Biológicos (alasBioSyS) es una herramienta de propósito general que facilita la modelación, edición, simulación y análisis de los sistemas biológicos. La investigación del presente trabajo surge de forma conjunta por el Centro de Inmunología Molecular (CIM) y la Universidad de las Ciencias Informáticas (UCI), dada la necesidad de obtener una integración entre los componentes del software BioSyS que contribuya a la flexibilidad del sistema. Se decidió diseñar una arquitectura que proporcione los elementos necesarios para el desarrollo de una plataforma, que brinde a los investigadores un entorno de trabajo provisto de las funcionalidades necesarias para la evolución de sus investigaciones.
La representación de la arquitectura se realiza mediante el Modelo 4 + 1 vistas de Philippe Kruchten, se identifican los elementos críticos o sensibles desde el punto de vista arquitectónico, así como también del diseño/implementación indispensables para el buen funcionamiento del sistema y se evalúa el diseño arquitectónico aplicando el método de evaluación ARID permitiendo validar que la arquitectura propuesta cumple con los atributos de calidad indispensables para el cumplimiento de la calidad del sistema.
PALABRAS CLAVE
Arquitectura de Software, Sistemas Bilógicos, Estilos Arquitectónicos, Patrones Arquitectónicos, Vistas Arquitectónicas.
V
INTRODUCCIÓN ... 1
CAPÍTULO 1 ... 4
1.1 INTRODUCCIÓN ... 4
1.2 ARQUITECTURA DE SOFTWARE ... 4
1.2.1 Surgimiento de Arquitectura de Software ... 4
1.3 ESTILOS Y PATRONES ... 7
1.3.1 Estilos ... 8
1.3.2 Patrones de Software ... 10
1.3.2.1 Patrones Arquitectónicos...………..12
1.3.2.2 Patrones de Diseño……….……….…14
1.4 LENGUAJES DE DESCRIPCIÓN ARQUITECTÓNICA………...…………...…...……... . 17
1.5 LENGUAJE UNIFICADO DE MODELADO (UML) ... 19
1.6 METODOLOGÍA, HERRAMIENTAS Y TECNOLOGÍAS ... 19
1.7 EL ROL ARQUITECTO DE SOFTWARE ... 24
1.8 CARACTERÍSTICAS DEL SISTEMA ... 25
1.9 CONCLUSIONES ... 27
CAPÍTULO 2 ... 28
2.1 INTRODUCCIÓN ... 28
2.2 REPRESENTACIÓN ARQUITECTÓNICA ... 28
2.3 METAS Y RESTRICCIONES ... 30
2.3 DISEÑO DE LAS VISTAS ARQUITECTÓNICAS ... 33
2.3.1 Vista de Caso de Uso ... 34
2.3.1.1 Vista de CU del Paquete Simulación………...………35
2.3.1.2 Vista de CU del Paquete Editor de Ecuaciones………..………...35
2.3.1.3 Vista de CU del Paquete Modelación………...…...……….…36
2.3.1.4 Vista de CU del Paquete Estimación de Parámetros……….………...36
2.3.1.5 Vista de CU del Paquete Graficador……….………...………….…....37
2.3.1.6 Vista de CU del Paquete Análisis……….……...………...37
2.3.2 Vista Lógica………...38
V
2.3.5 Vista de Implementación ... 41
CAPÍTULO 3 ... 47
3.1 INTRODUCCIÓN ... 47
3.2 EVALUANDO LA ARQUITECTURA DE SOFTWARE ... 47
3.2.1 Motivos para evaluar una Arquitectura de Software ... 47
3.2.2 Momento para evaluar la arquitectura ... 48
3.2.3 Resultados de la evaluación de la arquitectura ... 48
3.2.4 Cualidades por las que puede ser evaluada una arquitectura ... 49
3.2.5 Salidas de una evaluación arquitectónica ... 51
3.2.6 Costos y beneficios de realizar una evaluación arquitectónica ... 51
3.3 MÉTODOS DE EVALUACIÓN DE ARQUITECTURAS DE SOFTWARE ... 52
3.3.1 Método de Análisis de Arquitecturas de Software... 52
3.3.2 Método de Análisis de Acuerdos de Arquitectura ... 54
3.3.3 Método de Revisiones Activas para Diseños Intermedios ... 56
3.4 EVALUANDO LA ARQUITECTURA DEL SOFTWARE PARA LA SIMULACIÓN Y ANÁLISIS DE LOS SISTEMAS BIOLÓGICOS ... 58
3.5 CONCLUSIONES ... 61
CONCLUSIONES GENERALES ... 62
RECOMENDACIONES ... 63
REFERENCIAS BIBLIOGRÁFICAS ... 64
BIBLIOGRAFÍA ... 66
GLOSARIO DE TÉRMINOS ... 70
1
INTRODUCCIÓN
La ciencia interesada en comprender el funcionamiento de los sistemas biológicos es la Biología de Sistemas, a través de ella se han desarrollado diferentes programas con el objetivo de modelar, simular y analizar sistemas biológicos, algunos de ellos de propósito general y otros más específicos.
La Biología de Sistemas es un área de estudio emergente que se caracteriza por la integración de aproximaciones experimentales y computacionales en la comprensión de los sistemas biológicos. Esta disciplina permite estudiar los mecanismos que gobiernan los sistemas complejos y las interacciones existentes entre los diferentes niveles de información biológica [1].
Para la mejor comprensión de los Sistemas Biológicos, surge una disciplina científica emergente llamada Bioinformática. Esta área de investigación multidisciplinaria puede ser ampliamente definida como la interfase entre dos ciencias: Biología y Computación, ya que utiliza tecnología de la información para organizar, analizar y distribuir información biológica con la finalidad de responder preguntas complejas en esta rama.
En los últimos años se han creado las primeras empresas de biología de sistemas cuyos productos están estrechamente relacionados con la simulación y análisis de problemas biológicos. Gene Network Sciences, Entelos, Physiome y Genomática son ejemplos de estas empresas. Estas trabajan sobre una plataforma de software que permite integrar información, representar matemáticamente los diferentes modelos y simular sistemas biológicos, pero su estrategia de negocios está basada en la formación de alianzas comerciales con empresas biotecnológicas y no en la comercialización directa del software.
El actual desarrollo de software de forma independiente también ha ido en ascenso. Existen referencias a diferentes programas en la página Web del System Biology Markup Lenguage (SBML), que permiten modelar, simular o realizar análisis sobre modelos de sistemas biológicos, algunos de estos programas son Vcell, CellWare y BioSpice.
En Cuba se ha creado el Centro de Inmunología Molecular (CIM) que tiene como principal misión obtener y producir nuevos biofármacos destinados al tratamiento del cáncer y otras enfermedades crónicas no transmisibles e introducirlos en la Salud Pública cubana. Para este centro es muy importante realizar simulaciones para analizar el comportamiento de estas enfermedades.
Teniendo en cuenta estas razones, el Centro de Inmunología Molecular (CIM) en conjunto con la Facultad 6 de la Universidad de las Ciencias Informáticas (UCI), crean el proyecto Software para la Simulación y Análisis de los Sistemas Biológicos (BioSyS), con el objetivo de crear una herramienta de propósito general que facilite la modelación, edición, simulación y análisis de los mismos.
2 El software BioSyS cuenta con herramientas para la modelación matemática, un editor de ecuaciones y el graficador, algoritmos para la realización de simulaciones distribuidas y para el análisis de las simulaciones realizadas donde incluye la estimación de parámetro, y una base de datos para almacenar los resultados de las simulaciones. Estos algoritmos representan módulos que pueden ser utilizados como librerías genéricas en otros sistemas con las mismas características.
La primera versión del sistema funciona como un todo, lo que implica que se realice todo el trabajo desde el inicio y que los investigadores tengan que usar el sistema completo para realizar su trabajo, independientemente de las funcionalidades que desea utilizar, limitando las posibilidades de escalabilidad y excluyendo la independencia de funcionalidades.
De la situación planteada anteriormente se deriva el problema científico que guía la investigación:
¿Cómo obtener una integración entre los componentes del software BioSyS que contribuya a la flexibilidad del sistema?
En correspondencia con el problema científico planteado se define como objeto de estudio: La Arquitectura de Software, enmarcado en el campo de acción: La Arquitectura de Software para la
Simulación y Análisis de Sistemas Biológicos.
Estrechamente vinculado al campo de acción aparece como objetivo general: Diseñar la nueva arquitectura del software BioSyS.
Posteriormente y con la intención de cumplir con el objetivo general se fijan los siguientes objetivos específicos:
1. Seleccionar estilos y patrones de arquitectura.
2. Describir la arquitectura del sistema.
3. Evaluar el diseño arquitectónico propuesto.
Para cumplir con los objetivos específicos se realizarán las siguientes tareas:
1. Revisión de los estilos arquitectónicos existentes.
2. Revisión de los patrones de arquitectura existentes.
3. Identificación de los estilos arquitectónicos a utilizar, fundamentación de estos estilos, así como su aplicación.
4. Identificación de los patrones arquitectónicos a utilizar, fundamentación de estos patrones, así como su aplicación.
5. Definición y fundamentación de las herramientas a utilizar para el desarrollo del software BioSyS.
6. Representación del diseño arquitectónico propuesto.
3 7. Análisis y diseño de las vistas del sistema.
8. Selección y aplicación de un método para validar el diseño arquitectónico propuesto.
El presente documento está estructurado en tres capítulos.
Capítulo 1: Fundamentación Teórica.
En este capítulo se presentan conceptos asociados al objeto de estudio, así como los diferentes tipos de arquitectura y patrones arquitectónicos más usados mundialmente. Se aborda acerca de los lenguajes, tecnologías y herramientas ya definidas para dar solución al problema científico.
Capítulo 2: Descripción de la arquitectura.
En este capítulo se hace una propuesta de solución al problema planteado. Se diseñan las vistas arquitectónicas y se hace una descripción de la arquitectura para la plataforma, definiendo cómo debe hacerse la integración y comunicación entre los módulos.
Capítulo 3: Evaluación del diseño arquitectónico propuesto.
En este capítulo se presentan los distintos métodos para evaluar un diseño arquitectónico y a partir del método seleccionado se hace un análisis de la solución propuesta.
Fundamentación Teórica Fundamentación Teórica Fundamentación Teórica Fundamentación Teórica
CAPÍTULO 1
1.1 INTRODUCCIÓN
En este capítulo se presentan conceptos asociados al objeto de estudio, así como los diferentes tipos de arquitectura y patrones arquitectónicos más usados mundialmente. Se aborda acerca de los lenguajes, tecnologías y herramientas que serán utilizadas para dar solución al problema científico.
1.2 Arquitectura de Software
1.2.1 Surgimiento de Arquitectura de Software
La Arquitectura de Software (AS) remonta sus antecedentes a la década de 1960, su historia no ha sido continua como la del campo más amplio en la que se inscribe, la ingeniería de software. Desde ese entonces se han interpretado de muchas maneras las diferentes ideas que se plantean, permitiendo distinguir corrientes de pensamientos diversas, cuyas diferencias distan de ser triviales a la hora de plasmar las ideas.
En el año 1968 Edsger Dijkstra, de la Universidad Tecnológica de Eindhoven en Holanda y Premio Turing 1972, propuso que se establezca una estructuración correcta de los sistemas de software antes de lanzarse a programar, escribiendo código de cualquier manera. Dijkstra sostenía que las ciencias de la computación eran una rama aplicada de las matemáticas. Aunque Dijkstra no utiliza el término arquitectura para describir el diseño conceptual del software, sus conceptos sientan las bases para lo que luego serían las primeras definiciones de Arquitectura de Software [2].
En 1975, Brooks, diseñador del sistema operativo OS/360 y Premio Turing 2000, utilizaba el concepto de arquitectura del sistema para designar “la especificación completa y detallada de la interfaz de usuario” y consideraba que el arquitecto es un agente del usuario, igual que lo es quien diseña su casa, empleando una nomenclatura que ya nadie aplica de ese modo. En el mismo texto, identificaba y razonaba sobre las estructuras de alto nivel y reconocía la importancia de las decisiones tomadas a ese nivel de diseño.
También distinguía entre arquitectura e implementación; mientras aquella decía qué hacer, la implementación se ocupa de cómo y planteaba también que las decisiones tempranas de desarrollo serían las que probablemente permanecerían invariantes en el desarrollo de una solución. Esas
“decisiones tempranas” constituyen de hecho lo que hoy se llamarían decisiones arquitectónicas [2].En la década de 1980, los métodos de desarrollo estructurado demostraron no escalar suficientemente y
5 fueron dejando el lugar a un nuevo paradigma, el de la programación orientada a objetos (POO). En teoría, parecía posible modelar el dominio del problema y el de la solución en un lenguaje de implementación. Hacia fines de la década de 1980 y comienzos de la siguiente, la expresión arquitectura de software comienza a aparecer en la literatura para hacer referencia a la configuración morfológica de una aplicación [2].
Puede decirse que Perry y Wolf fundaron la disciplina, y fueron los primeros en dar el sentido que actualmente conocemos por “Arquitectura de Software”. Algunos autores proponen la AS por analogía con la arquitectura de los edificios, analogía de la que algunos abusaron, otros encontraron útil y para unos pocos inaceptables, planteando que primero se desarrolla una intuición para la AS recurriendo a diversas disciplinas arquitectónicas bien definidas.
Dando cumplimiento a las profecías de Perry y Wolf, la década de 1990 fue sin duda la de la consolidación y diseminación de la AS en una escala sin precedentes. Las contribuciones más importantes surgieron en torno del instituto de ingeniería de la información de la Universidad Carnegie Mellon (CMU SEI), antes que cualquier organismo de industria. En la misma década, demasiado pródiga en acontecimientos, surge también la programación basada en componentes, que en su momento de mayor impacto impulsó a algunos arquitectos mayores, como Paul Clements, a afirmar que la AS promovía un modelo que debía ser más de integración de componentes pre-programados que de programación [3].
Otro tema muy importante de la época fue el surgimiento de los patrones, cristalizada en dos textos fundamentales, el de la Banda de los Cuatro en 1995 y la serie POSA desde 1996. El primero de ellos promueve una expansión de la programación orientada a objetos, mientras que el segundo desenvuelve un marco ligeramente más ligado a la AS.
En el siglo XXI, la AS aparece dominada por estrategias orientadas a líneas de productos y por establecer modalidades de análisis, diseño, verificación, refinamiento, recuperación, diseño basado en escenarios, estudios de casos y hasta justificación económica, redefiniendo todas las metodologías ligadas al ciclo de vida en términos arquitectónicos. Todo lo que se ha hecho en ingeniería de software debe formularse de nuevo, integrando la AS al conjunto.
Definición de Arquitectura de Software
La Arquitectura de Software es la parte de la Ingeniería de Software que se ocupa de la descripción y el tratamiento de la estructura de un sistema como una serie de componentes, con el fin de organizar adecuadamente los distintos subsistemas, y permitir la integración de diferentes grupos de desarrollo en
6 el mismo proyecto. Habitualmente se vincula con la fase de Diseño, aunque este detalle no es estrictamente necesario; su principal objetivo es hacer énfasis en la importancia de la descripción estructural de los sistemas software, un aspecto bien conocido pero habitualmente poco tratado [4].
Incluso hoy, con la disciplina relativamente establecida pero aún joven, no es posible dar una definición o descripción de Arquitectura de Software que resulte completa, o cuando menos
suficientemente integradora.
Muchos han sido los autores que han abordado el tema de AS y al mismo tiempo han realizado diferentes definiciones por lo que se mencionan las que de alguna forma llevaron el camino a lo que se considera hoy AS.
Perry y Wolf fueron los fundadores de esta disciplina planteando que:
“Una arquitectura de software es un conjunto de elementos arquitectónicos que tienen una determinada forma. Las propiedades restringen la elección de los elementos de la arquitectura mientras que la lógica captura la motivación de la elección de los elementos y la forma [5].”
(Perry y Wolf 1992) Según Mary Shaw y David Garlan:
“Una arquitectura de software incluye la descripción de elementos a partir de los cuales se construyen los sistemas de software, interacciones entre esos elementos, patrones que guían la composición y restricciones sobre esos patrones. En general, un sistema de software particular se define en términos de una colección de componentes e interacciones entre dichos componentes. Tal sistema puede ser utilizado como un elemento en sistemas más grandes [6].”
(Garlan y Shaw 1996)
La definición oficial que es utilizada es la provista por el documento lEEE STD 1471- 2000, que expresa:
“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 [7].”
Ninguna de las definiciones de Arquitectura de Software es respaldada unánimemente por la totalidad de los arquitectos de software; a pesar de las diferencias entre las diversas definiciones es común entre todos los autores el concepto de la arquitectura como un punto de vista que concierne a un alto nivel de abstracción.
7
1.3 Estilos y Patrones
Uno de los elementos importantes en la arquitectura de software es definir los estilos y patrones. Antes de analizar estos términos es importante mencionar las diferencias que existen entre estos conceptos.
En algunas bibliografías referentes a los patrones, los autores suelen llamar de la misma manera a los estilos y patrones, mientras que la mayoría lo ven de manera separada. Ambos se refieren a formas de estructurar los sistemas y cómo relacionar los componentes de estos, la diferencia radica en el nivel de abstracción en que se aplican. Los estilos favorecen un tratamiento estructural que concierne más bien a la teoría, la investigación académica y la arquitectura en el nivel de abstracción más elevado, mientras que los patrones se ocupan de cuestiones que están más cerca del diseño, la práctica, la implementación, el proceso, el refinamiento y el código [8].
Los patrones de arquitectura están claramente dentro de la disciplina arquitectónica, solapándose con los estilos, mientras que los patrones de diseño se encuentran más bien en la periferia, si es que no decididamente afuera.
Vale la pena aclarar la relación entre estilos, patrones de diseño y patrones de arquitectura. Los patrones de diseño de software buscan codificar y hacer reutilizables un conjunto de principios a fin de diseñar aplicaciones de alta calidad. Los estilos se han aplicado en la fase de análisis arquitectónico en términos de patrones de arquitectura. Los patrones de diseños se aplican en principio solo en la fase de diseño, aunque la comunidad ha comenzado a definir y aplicar patrones a otras etapas del proceso de desarrollo.
Los patrones de arquitectura se concentran en la estructura de alto nivel del sistema y presenta similitudes con los de diseño.
Los estilos expresan la arquitectura en el sentido más formal y teórico. Son una categorización de sistemas y son independientes al contexto donde pueden ser aplicados, por lo que expresan técnicas de diseño desde una perspectiva que es independiente de la situación actual del diseño. Los patrones son soluciones generales a problemas comunes. Expresan un problema recurrente de diseño muy específico y presentan una solución para él, desde el punto de vista del contexto en que se presenta [8].
Después de analizar los elementos esenciales de los estilos y patrones se concluye que si bien existe convergencia entre ellos, los estilos se refieren más a la teoría sobre la estructura de los sistemas y los patrones se refieren más a las prácticas de reutilización.
8
1.3.1 Estilos
Los estilos sólo se manifiestan en la arquitectura teórica descriptiva de alto nivel de abstracción, constituyendo así una parte importante del sistema. Se definen como aspectos formales a partir de diversas arquitecturas específicas y encapsula decisiones esenciales sobre los elementos del sistema.
Enfatiza restricciones importantes de los elementos y sus relaciones posibles.
Se entiende por estilos a las entidades que ocurren en un nivel sumamente abstracto, puramente arquitectónico, que no coincide ni con la fase de análisis propuesta por la temprana metodología de modelado orientada a objetos (aunque sí un poco con la de diseño), ni con lo que más tarde se definirían como paradigmas de arquitectura, ni con los patrones arquitectónicos [9].
Algunos de los estilos arquitectónicos que se utilizan en la actualidad están divididos en Clases de estilos las cuales se exponen a continuación [9].
- Estilos de Flujo de Datos: Esta familia enfatiza la reutilización y la modificabilidad. Es apropiada para sistemas que implementan transformaciones de datos en pasos sucesivos.
• Tubería y filtros: El sistema tubería-filtros se percibe como una serie de transformaciones sobre sucesivas piezas de los datos de entrada. Estos datos entran al sistema y fluyen a través de los componentes.
- Estilos Centrados en Datos: Esta familia enfatiza la integración 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: En este estilo se han definidos dos subcategorías principales:
Si los tipos de transacciones en el flujo de entrada definen los procesos a ejecutar, el repositorio puede ser una base de datos tradicional (implícitamente no cliente-servidor).
Si el estado actual de la estructura de datos dispara los procesos a ejecutar, el repositorio es lo que se llama una pizarra pura o un tablero de control.
- Estilos de llamada y Retorno: Esta familia enfatiza la modificación y la escalabilidad. Dentro de esta familia se encuentran las arquitecturas de programa principal y subrutina, los sistemas basados en llamadas a procedimientos remotos, los sistemas orientados a objeto y los sistemas jerárquicos en capas.
• Modelo Vista Controlador (MVC): Este patrón separa el modelado del dominio, la presentación y las acciones basadas en datos ingresados por el usuario en tres clases diferentes:
9
Modelo. Administra el comportamiento y los datos del dominio de aplicación, responde a requerimientos de información sobre su estado y responde a instrucciones de cambiar el estado (habitualmente desde el controlador).
Vista. Maneja la visualización de la información.
Controlador. Interpreta las acciones del ratón y el teclado, informando al modelo y/o a la vista para que cambien según resulte apropiado.
• Arquitectura en capas: Definida por Garlan y Shaw como una organización jerárquica, tal que cada capa proporciona servicios a la capa inmediatamente superior y se sirve de las prestaciones que le brinda la inmediatamente inferior.
• Arquitecturas Orientadas a Objetos: Los componentes del estilo se basan en principios orientados a objetos como encapsulamiento, herencia y polimorfismo. .
• Arquitecturas Basadas en Componentes: Permite alcanzar un mayor nivel de reutilización de software y que las pruebas sean ejecutadas probando cada uno de los componentes, antes de probar el conjunto completo de componentes ensamblados. Simplifica el mantenimiento del sistema, cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.
- Estilos de Código Móvil: Esta familia enfatiza la portabilidad. Ejemplos de la misma son los intérpretes, los sistemas basados en reglas y los procesadores de lenguaje de comando.
• Arquitectura de Máquinas Virtuales (MV): Este estilo se utiliza habitualmente para construir máquinas virtuales que reducen el vacío que media entre la máquina de computación esperada por la semántica del programa y la máquina físicamente disponible.
- Estilos heterogéneos: En esta familia se clasifican aquellos sistemas que no pueden encajar exactamente en ninguno de los tipos anteriores.
• Sistemas de control de procesos: Los sistemas de control de procesos se caracterizan no sólo por los tipos de componentes, sino por las relaciones que mantienen entre ellos. El objetivo de un sistema de esta clase es mantener ciertos valores dentro de ciertos rangos especificados, llamados puntos fijos o valores de calibración.
10
• Arquitecturas Basadas en Atributos: La arquitectura basada en atributos fue propuesta para asociar a la definición del estilo arquitectónico un framework de razonamiento, basado en modelos de atributos específicos.
- Estilos Peer-to-Peer: Esta familia, también llamada de componentes independientes, enfatiza la modificabilidad por medio de la separación de las diversas partes que intervienen en la computación.
Consiste por lo general en procesos independientes o entidades que se comunican a través de mensajes.
• Arquitecturas Basadas en Eventos: Se vinculan históricamente con sistemas basados en publicación-suscripción. Los conectores de estos sistemas incluyen procedimientos de llamada tradicionales y vínculos entre anuncios de eventos e invocación de procedimientos.
• Arquitecturas Orientadas a Servicios (SOA): Es lo suficientemente flexible, elegante y ágil garantizando las soluciones que las empresas han anhelado siempre. Es una arquitectura de software que construye todo el estudio de la aplicación como una topología de interfaces, implementaciones y llamados a interfaces. Es una relación entre servicios y consumidores de servicios, ambos lo suficientemente amplios como para representar una función de negocio completa.
• Arquitecturas Basadas en Recursos: Define recursos identificables y métodos para acceder y manipular el estado de esos recursos. El caso de referencia es nada menos que la World Wide Web (www), donde los URLs identifican los recursos y HTTP es el protocolo de acceso.
En el epígrafe 1.8 luego de analizar las características del sistema se definirá el estilo arquitectónico seleccionado.
1.3.2 Patrones de Software
Los patrones de arquitectura expresan el esquema fundamental de organización para sistemas de software. Proveen un conjunto de subsistemas predefinidos; especifican sus responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos [9].
Los patrones de software son mecanismos con el objetivo de dar solución a problemas que ocurren repetidamente dentro de un contexto muy bien definido. Las soluciones propuestas a través de estos, involucran algunas clases de estructuras que permiten contemplar los requisitos no funcionales. Estos requisitos atraviesan diferentes niveles de abstracción y etapas del ciclo de vida, partiendo del análisis del
11 dominio, pasando por la arquitectura de software y llegando hasta el nivel de los lenguajes de programación [9].
Para la utilización de los patrones necesarios para crear un sistema, se deben tener en cuenta las características que debe tener un buen patrón para poder aplicarlo, basándose en [9]:
La solución de un problema planteado.
Que sea un concepto probado.
Que la solución no sea obvia.
Que describe participantes, relaciones entre ellos y un alto componente humano como estética y utilidad.
Dependiendo del autor, del nivel de abstracción y de la publicación misma se han presentado varios formatos para encapsular la información de un patrón.
Los puntos más significativos que debe contener un patrón son [9]:
Nombre: Es el nombre con el que ha sido registrado el patrón.
Problema: Es el problema específico que resuelve el patrón en cuestión y que además, ha sido el responsable del surgimiento de dicho patrón.
Solución: Es la solución que se le da al problema.
Estructura: Puede ser un diagrama que represente todos los implicados en el patrón (refiriéndonos a objetos), así como la relación existente entre estos.
Aplicación en la programación: Es un ejemplo concreto de cómo este patrón, que puede ser explicado mediante un ejemplo de la vida práctica, se aplica en un determinado sistema, es decir, un problema especifico que se presenta en una aplicación a desarrollar, y como el patrón es aplicable para resolverlo.
Ejemplo de Código: Es un pequeño ejemplo de la implementación del patrón, puede ser en cualquier lenguaje.
Contexto Resultante: El estado en el cual queda el sistema después de aplicar el patrón y las consecuencias de hacerlo
Racionalidad: Una explicación justificada de los pasos o reglas en el patrón Relaciones: Relaciones estáticas y dinámicas del patrón con otros
Usos conocidos: Describe ocurrencias del patrón conocidas y su aplicación dentro de los sistemas existentes
Los patrones se pueden dividir en varias categorías según la escala o nivel de abstracción siendo estas [9]:
12 - Patrones de arquitectura: Son aquellos que expresan un esquema organizativo estructural fundamental para sistemas.
- Patrones de diseño: Expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas software.
- Patrones de análisis: Permite el modelado del dominio, la completitud, la integración y el equilibrio de objetivos múltiples, y el planeamiento para capacidades adicionales comunes.
- Patrones de procesos o de organización: Permite la productividad y la comunicación efectiva y eficiente.
- Patrones de Idiomas: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.
Los patrones más significativos para la arquitectura se software son los patrones arquitectónicos y de diseño, a continuación se muestra el estudio referente a estos.
1.3.2.1 Patrones Arquitectónicos
Los patrones arquitectónicos son los que definen la estructura de un sistema software, los cuales a su vez se componen de subsistemas con sus responsabilidades. Tienen una serie de directivas para organizar los componentes del sistema, con el objetivo de facilitar la tarea del diseño.
Entre las principales ventajas de esto patrones podemos encontrar:
Sintetizan las soluciones arquitectónicas y estructurales dentro del tipo de problema que modelan.
Permiten identificar y comprender la arquitectura del sistema.
Permiten la reutilización de soluciones arquitectónicas de calidad.
Son de gran ayuda para controlar la complejidad de un diseño.
Facilitan la documentación de diseños arquitectónicos.
Proporcionan un vocabulario común que mejora la comunicación entre diseñadores.
Un patrón de arquitectura de software, es un esquema genérico probado para solucionar un problema particular recurrente que surge en un cierto contexto. Este esquema se especifica describiendo los componentes, sus responsabilidades, relaciones, y las formas en que colaboran.
Los patrones arquitectónicos de software más destacados son: Tubería y Filtros, Pizarra o Repositorio, Modelo-Vista-Controlador (MVC), Capas (Layers), Broker, Presentation Abstraction Control, Reflection y
13 Microkernel. Una buena referencia en este tema lo constituye el libro “Pattern-Oriented Software Architecture: A System of Patterns” de F. Buschmann. [20]
- MVC: Para el diseño de aplicaciones con sofisticadas interfaces. La lógica de una interfaz de usuario cambia con más frecuencia que los almacenes de datos y la lógica de negocio. Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la reusabilidad.
- Tuberías y Filtros: El patrón de arquitectura de tubos y filtros provee una estructura para procesar flujos de datos. Cada paso de procesamiento se encapsula en un filtro. Los datos se pasan usando los tubos entre filtros adyacentes. Combinando los filtros se puede construir distintas familias de sistemas relacionados.
- Pizarra o Repositorio: En el modelo de repositorio los datos compartidos son pasivos y el control lo manejan los componentes que lo acceden. Estos componentes del sistema deben compartir información para trabajar efectivamente. Toda la información está contenida en una base de datos central, el repositorio.
- Capas (Layers): Este patrón descompone una aplicación en un conjunto de capas independientes y ordenadas jerárquicamente. Cada nivel o capa usa los servicios de la capa inmediatamente inferior y ofrece servicios a la inmediatamente superior.
- Broker: Se usa para organizar sistemas distribuidos con componentes débilmente acoplados que interactúan entre sí invocando servicios remotos.
- Presentaction Abstract Control: Define una estructura para sistemas de software interactivos de agentes de cooperación organizados de forma jerárquica. Cada agente es responsable de un aspecto específico de la funcionalidad de la aplicación y consiste de tres componentes: presentación, abstracción y control.
- Reflection: Proporciona un mecanismo para cambiar la estructura y el comportamiento del sistema dinámicamente. Cambia dinámicamente soportando así la modificación de aspectos fundamentales como estructuras tipo y mecanismos de llamadas a funciones.
- Microkernel: Este patrón permite separar un mínimo núcleo funcional de funcionalidad extendida y partes específicas del cliente. Se aplica para sistemas de software que deben estar en capacidad de adaptar los requerimientos de cambio del sistema y separa un núcleo funcional mínimo del resto de la funcionalidad y de partes específicas pertenecientes al cliente.
14
1.3.2.2 Patrones de Diseño
Los patrones de diseño son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan. Cada patrón permite que algunos aspectos de la estructura del sistema puedan cambiar independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento.
Cuando se habla de estos patrones no se da una definición como tal, pero se considera que son un conjunto de prácticas de óptimo diseño que se utilizan para abordar problemas recurrentes en la Programación Orientada a Objetos (POO). Un patrón de diseño puede considerarse como un documento que define una estructura de clases que aborda una situación particular, permitiendo la reutilización de cada patrón las veces que sean necesarias, simplificando así el tiempo en el desarrollo del sistema [20].
Entre los patrones de diseño se destacan los patrones GRASP y los GOF. Los primeros describen los principios fundamentales de diseño de objetos para la asignación de responsabilidades y los segundos son patrones conformados por el grupo de los cuatro: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.
Siguiendo el libro de GOF los patrones se clasifican según el propósito para el que han sido definidos:
Creacionales: Solucionan problemas de creación de instancias. Nos ayudan a encapsular y abstraer dicha creación.
Estructurales: Solucionan problemas de composición/agregación de clases y objetos.
Comportamiento: Solucionan problemas respecto a la interacción y responsabilidades entre clases y objetos, así como los algoritmos de encapsulamiento.
• Patrones Creacionales [18]:
Abstract Factory: Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin especificar sus clases concretas.
Factory Method (Virtual Constructor): 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.
Singleton (Solitario): Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella.
Prototype (Prototipo): Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crear nuevos objetos copiando este prototipo.
15 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.
• Patrones Estructurales:
Composite (Compuesto): 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 (Decorador): Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
Proxy (Apoderado): Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.
Facade (Fachada): Proporciona una interfaz unificada para un conjunto de interfaces de un subsistema.
Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.
Flyweight (Peso Mosca): Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.
Adapter (Adaptador): 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 (Puente): Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.
• Patrones de Comportamiento:
Chain of Responsibility (Asignación de responsabilidad): 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.
Mediator (Mediador): 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.
Iterator (Iterador): Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.
16 Observer (Observador): 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.
Memento (Recuerdo): 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.
State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.
Strategy (Estrategia): 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.
Interpreter (Interprete): 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.
Template Method (Método Plantilla): 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 (Visitante): 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.
Los patrones GRAS o GRASP (General Responsibility Assignment Software Patterns) se dedican fundamentalmente como su nombre lo indica a asignar responsabilidades a los objetos. Como ya conocemos, las principales responsabilidades de cualquier objeto son [20]:
Conocer: Los atributos y sus relaciones con otro objetos.
Hacer: Lo relacionado con las tareas que debe cumplir un objeto.
Los principales Patrones GRASP son [19]:
1. Experto.
2. Creador.
3. Controlador.
4. Alta Cohesión.
5. Bajo Acoplamiento.
6. No hables con extraños
Experto: Asigna responsabilidades al experto de la información. Una clase tiene la información necesaria para llevar a cabo sus responsabilidades. Posibilita el encapsulamiento de la información, y por ende el bajo acoplamiento. Permite el comportamiento distribuido entre las clases.
17 Creador: Lo que define este patrón es que una instancia de un objeto la tiene que crear el objeto que tiene la información para ello, esto significa que si un objeto A utiliza específicamente otro B, o si B forma parte de A, o si A almacena o contiene B, o si simplemente A tiene la información necesaria para crear B, entonces A es el perfecto creador de B. Este patrón soporta el bajo acoplamiento.
Controlador: Es un evento generado por actores externos. Se asocian con operaciones y como respuestas a los eventos del sistema, tal como se relacionan los mensajes y los métodos.
Alta Cohesión: Este patrón permite que se incremente la claridad y facilite la comprensión, que se simplifique el mantenimiento, implica casi siempre bajo acoplamiento y además incrementa reutilización.
Bajo Acoplamiento: Asigna la responsabilidad de controlar el flujo de eventos del sistema, a clases específicas, lo que facilita la centralización de actividades (validaciones, seguridad, etc.). Permite una mejor comprensión de las clases aisladas, que sea convenientes para reutilizar y no afecta los cambios en otros componentes.
No hables con extraños: Este patrón plantea a quien debe invocar un método, permitiendo que solamente invoque métodos de sí mismo, de su área de parámetros y a un objeto creado en su propio ámbito.
En el epígrafe 1.8 luego de analizar las características del sistema se determinará la elección de los patrones.
1.4 Lenguajes de Descripción Arquitectónica
Los Lenguajes de Descripción Arquitectónica (ADLs) se remontan a la década de 1970, pero se han comenzado a desarrollar con esta definición a partir de 1992 o 1993, poco después de fundada la propia arquitectura de software como especialidad profesional. Este tipo de lenguaje es necesario para disponer de abstracciones útiles, para modelar sistemas complejos desde un punto de vista arquitectónico; a la vez que deben permitir un nivel de detalle suficiente como para describir propiedades de interés en dicho sistema.
Los ADLs son un lenguaje descriptivo de modelado, que se enfoca en la estructura de alto nivel de la aplicación, antes que en los detalles de implementación de sus módulos concretos, que debe proporcionar un modelo explícito de componentes, conectores y sus respectivas configuraciones. Son poco utilizados debido a que se necesita aprender una sintaxis especializada, siendo convenientes, pero aún no han demostrado ser imprescindibles. La presencia de UML (Lenguaje Unificado de Modelado) ha impedido que estos lenguajes no hayan ocupado el lugar que les corresponde.
18 Las principales características que presentan estos lenguajes son:
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.
Existen varios lenguajes que sí son considerados ADLs, ejemplos de ellos son:
Acme – Armani: Es una lenguaje de intercambio de arquitectura que es capaz de soportar el mapeo de especificaciones arquitectónicas. Se considera un lenguaje de descripción arquitectónica de segunda generación, es decir, un metalenguaje, que no es más que una lengua franca para el entendimiento de 2 o más ADLs, llegando a soportar 4 tipos de arquitecturas como son: la estructura, las propiedades de interés, las restricciones y los tipos y estilos.
ADML (Architecture Description Markup Language): Constituye un intento de estandarizar la descripción de arquitecturas en base XML, agrega a los ADLs una forma de representación basada en estándares establecidos en la industria, de modo que ésta puede ser leída por cualquier parser de XML.
Permite definir vínculos con objetos externos a la arquitectura, así como interactuar con diversos repositorios.
Jacal: Este lenguaje permite visualizar una simulación de cómo se comportará en la práctica un sistema basado en la arquitectura que se ha representado, puede ser utilizado para expresar arquitecturas de distintos estilos [18].
Como resultado del estudio, y a pesar de las ventajas y utilidades que ofrecen los ADLs, no se propone la utilización de ellos por el esfuerzo que representaría capacitar personas en su uso, cuando existen otras formas de cumplir sus objetivos.
19
1.5 Lenguaje Unificado de Modelado (UML)
UML es un lenguaje de modelado que proporciona un vocabulario y unas reglas para permitir una comunicación entre elementos de un software y se centra en la representación gráfica para visualizar, construir y documentar los artefactos de un sistema, proporcionando una forma estándar de representar los planos de un sistema y comprende tanto elementos conceptuales, como los procesos de negocio y las funciones del sistema en cuanto a elementos concretos, como las clases escritas de un lenguaje de programación específico, esquemas de base de datos y componentes de software reutilizables.
Se crea con el objetivo de comunicar las ideas a otros desarrolladores y para servir de apoyo en los procesos de análisis de un problema; que sea independiente del lenguaje de programación, de forma tal que los diseños realizados se puedan implementar en cualquier lenguaje que soporte las posibilidades de UML.
Este lenguaje sirve de modelo completo de sistemas complejos, tanto en el diseño de los sistemas de software, como para la arquitectura de software donde se ejecuten. Teniendo en cuenta las características de este lenguaje, se consideran como principales ventajas [20]:
Presenta mayor rigor en la especificación del sistema.
Posibilita realizar una verificación y validación del modelo realizado.
Permite que el modelado y el código estén actualizados, con lo que se puede mantener la visión en el diseño de más alto nivel de la estructura de un proyecto.
Es un lenguaje consolidado y fácil de aprender.
1.6 Metodología, Herramientas y tecnologías
A continuación se analiza la metodología, herramientas y tecnologías ya definidas en la versión anterior.
Metodología de desarrollo
Una metodología de desarrollo de software es un conjunto de pasos y procedimientos que deben seguirse para desarrollar software, no es más que una colección de documentación formal, referente a los procesos, las políticas y los procedimientos que intervienen en el desarrollo del software.
Proceso unificado abierto (OpenUp/Basic)
OpenUP/Basic es un proceso de desarrollo de software de código abierto, mínimo, completo y extensible.
Está dirigido a la gestión y el desarrollo de proyectos de software basados en desarrollo iterativo, ágil e incremental; y es aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo. Es muy útil para equipos de desarrollo pequeños y que le dan valor a la colaboración y a las necesidades de los
20 stakeholder. Esta metodología procura un equilibrio entre las necesidades de los involucrados con los resultados del proyecto y los costos técnicos.
Este proceso está organizado dentro de cuatro áreas principales de contenido: Comunicación y Colaboración, Intención, Solución y Administración.
Se caracteriza por cuatro principios básicos que se soportan mutuamente:
Colaboración para unificar intereses y compartir conocimientos.
Equilibrio de prioridades competentes a maximizar el valor de los involucrados con el resultado del proyecto.
Enfoque en la articulación de la arquitectura.
Desarrollo continuo para obtener realimentación y realizar las mejoras respectivas. OpenUP/Basic se centra en articular la arquitectura para facilitar la colaboración técnica, reducir el riesgo y minimizar el sobreesfuerzo de desarrollo.
Herramienta CASE: Visual Paradigm
Es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software:
análisis y diseño orientados a objetos, construcción, pruebas y despliegue. El software de modelado UML ayuda a una más rápida construcción de aplicaciones de calidad, mejores y a un menor coste. Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación.
Visual Paradigm es fácil de usar y soporta la última notación UML, ingeniería inversa, generación de código, importación desde Rational Rose, exportación/importación XML, generador de informes, editor de figuras, integración con Microsoft Visio, plugin, integración IDE con Visual Studio, Eclipse, NetBeans y otros. Entre sus características se incluyen el modelado colaborativo con CVS y Subversion, interoperabilidad con modelos UML2 a través de XMLI [20].
Lenguaje de programación: Java
Java fue diseñado en 1990 por James Goslin de Sun Microsystems, como software para dispositivos electrónicos de consumo. Es un lenguaje de programación que ofrece la potencia del diseño orientado a objetos con una sintaxis fácilmente accesible y un entorno robusto y agradable. Proporciona un conjunto de clases potente y flexible. Pone al alcance de cualquiera la utilización de aplicaciones que se pueden incluir directamente en páginas Web. Aporta a la Web una interactividad que se había buscado durante mucho tiempo entre usuario y aplicación.
21 Es multiplataforma lo que permite que el mismo código java que funciona en un sistema operativo, funcionará en cualquier otro sistema operativo que tenga instalada la máquina virtual java. Gracias al API de java podemos ampliar el lenguaje para que sea capaz de: comunicarse con equipos mediante red, acceder a bases de datos, crear páginas HTML dinámicas, crear aplicaciones visuales al estilo Windows.
Para el desarrollo de la plataforma se seleccionó el lenguaje de programación Java por ser multiplataforma y orientado a objetos, siendo esta una característica imprescindible que se requiere para la aplicación. La existencia de una primera versión programada en Java, influyó en la selección permitiendo de esta forma la reutilización de gran cantidad de código.
Entorno Integrado de Desarrollo (IDE): NetBeans
En su núcleo, el NetBeans IDE es una herramienta de desarrollo para Java, empleando tecnología Java pura, por lo que se ejecuta en cualquier parte donde se ejecute Java. Aparte de la filosofía de distribución y desarrollo que hay tras NetBeans, el IDE ofrece a los desarrolladores numerosas ventajas en la creación de nuevas aplicaciones multiplataforma. En una era en la cual la arquitectura orientada a servicios (SOA) demanda funciones flexiblemente conjuntas que se dirigen a procesos específicos del negocio; permite la integración de múltiples herramientas y protocolos que da motivos para la migración y brinda facilidad de empleo a lo largo de todo el ciclo de vida del desarrollo.
Gestores de Base de Datos: PostgreSQL
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases de datos de código abierto más potente del mercado. Funciona en todos los sistemas operativos importantes, incluyendo Linux, UNIX y Windows. Tiene soporte total para foreign keys, joins, views, triggers, y stored procedures (procedimientos almacenados) en múltiples lenguajes. Incluye la mayoría de los tipos de datos como son INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE e INTERVAL.
Entre sus principales características se encuentran:
DBMS Objeto-Relacional: Aproxima los datos a un modelo objeto-relacional, y es capaz de manejar complejas rutinas y reglas. Ejemplos de su avanzada funcionalidad son consultas SQL declarativas, control de concurrencia multi-versión, soporte multi-usuario, transacciones, optimización de consultas, herencia, y arreglos.
Altamente Extensible: Soporta operadores, funcionales métodos de acceso y tipos de datos definidos por el usuario.
22
Soporte SQL Comprensivo: Soporta la especificación SQL99 e incluye características avanzadas tales como las uniones SQL92.
Integridad Referencial: Soporta integridad referencial, la cual es utilizada para garantizar la validez de los datos de la base de datos.
API Flexible: La flexibilidad del API de PostgreSQL ha permitido a los vendedores proporcionar soporte al desarrollo fácilmente para el RDBMS PostgreSQL. Estas interfaces incluyen Object Pascal, Python, Perl, PHP, ODBC, Java/JDBC, Ruby, TCL, C/C++, y Pike.
Lenguajes Procedurales: Tiene soporte para lenguajes procedurales internos, incluyendo un lenguaje nativo denominado PL/pgSQL. Este lenguaje es comparable al lenguaje procedural de Oracle, PL/SQL. Otra ventaja de PostgreSQL es su habilidad para usar Perl, Python, o TCL como lenguaje procedural embebido.
Cliente/Servidor: Utiliza una arquitectura proceso-por-usuario cliente/servidor. Hay un proceso maestro que se ramifica para proporcionar conexiones adicionales para cada cliente que intente conectar a PostgreSQL.
Sistema de Control de Versiones: Subversion (SVN)
Es un sistema de control de versiones que se ha popularizado bastante dentro de la comunidad de desarrolladores de software libre. Está preparado para funcionar en red, y se distribuye bajo una licencia libre de tipo Apache. Surge con la intención de sustituir y mejorar al conocido CVS, que a pesar de sus características, constituyó el estándar de los sistemas de gestión de versiones en el ámbito del software libre. SVN mantiene las ideas fundamentales de CVS pero suple sus carencias y evita sus errores.
Entre las principales características de SVN se encuentran:
Mantiene versiones no sólo de archivos, sino también de directorios.
Se mantienen versiones de los metadatos asociados a los directorios.
Además de los cambios en el contenido de los documentos, se mantiene la historia de todas las operaciones de cada elemento, incluyendo la copia, cambio de directorio o de nombre.
Atomicidad de las actualizaciones: Una lista de cambios constituye una única transacción o actualización del repositorio. Esta característica minimiza el riesgo de que aparezcan inconsistencias entre distintas partes del repositorio.
Posibilidad de elegir el protocolo de red: Además de un protocolo propio (svn), puede trabajar sobre http (o https) mediante las extensiones WebDAV (más conocido como DAV), este es un protocolo que amplía las posibilidades del HTTP/1.1 añadiendo nuevos métodos y cabeceras.
23 La capacidad de funcionar con un protocolo tan universal como el http simplifica la implantación (cualquier infraestructura de red actual soporta dicho protocolo) y universaliza las posibilidades de acceso (si se quiere, puede utilizarse a través de Internet).
Soporte tanto de ficheros de texto como de binarios.
Mejor uso del ancho de banda, ya que en las transacciones se transmiten sólo las diferencias y no los archivos completos.
Servidor de Aplicaciones: Tomcat
Tomcat (también llamado Jakarta Tomcat o Apache Tomcat) funciona como un contenedor de servlets (objetos que corren dentro del contexto de un servidor de aplicaciones y extienden su funcionalidad), desarrollado bajo el proyecto Jakarta en la Apache Software Foundation. Se considera un servidor de aplicaciones e implementa las especificaciones de los servlets y de Java Server Pages (JSP) de Sun Microsystems. Tomcat funciona con cualquier servidor web con soporte para servlets y JSPs.
Este servidor opera de tal manera en entornos de desarrollo poco exigentes en términos de velocidad y de manejo de transacciones. Dado que fue escrito en Java, funciona en cualquier sistema operativo que disponga de la máquina virtual. Lo desarrollan y lo mantienen miembros de la Apache Software Foundation y voluntarios independientes. Los usuarios disponen de libre acceso a su código fuente y a su forma binaria en los términos establecidos en la Apache Software Licence.
Después del estudio realizado anteriormente se decidió seleccionar Tomcat como servidor de aplicaciones, pues entre otras características funciona como servidor web por sí mismo. Tomcat consume menos recursos que otros servidores de aplicaciones, además de ser gratis, cuenta con un gran número de usuarios y soporte en la comunidad mundial.
Framework: Hibernate
Hibernate es una herramienta para la plataforma Java que facilita el mapeo de atributos entre una base de datos relacional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) que permiten establecer estas relaciones. Realiza el mapeo entre el mundo orientado a objetos de las aplicaciones y el mundo entidad-relación de las bases de datos en entornos Java. El término utilizado es ORM (object/relational mapping) y consiste en la técnica de realizar la transición de una representación de los datos de un modelo relacional a un modelo orientado a objetos y viceversa [20].
Este framework ha conseguido en un tiempo record, una excelente reputación en la comunidad de desarrollo posicionándose claramente como el producto Open Source líder en este campo gracias a sus