Facultad # 3
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas.
Tema: Diseño e implementación del módulo Reglas del plugin Génesis.
Autor: Armando Palacio Vázquez Tutor: Ing. Yulier Matías León
La Habana
Junio de 2011
«Los grandes espíritus siempre han encontrado la violenta oposición de las mentes mediocres. Estos últimos no pueden entender que un hombre no se someta irreflexivamente a los prejuicios hereditarios sino que emplee honestamente y con coraje su inteligencia.»
Albert Einstein
I
Declaración de autoría
Declaración de autoría Declaro que soy el único autor del trabajo titulado: Diseño e Implementación del módulo Reglas del plugins Génesis y autorizo a la Universidad de las Ciencias Informáticas los derechos patrimoniales del mismo, con carácter exclusivo. Para que así conste firmo la presente a los _______ días del mes de ________ del año ________.
____________________________
Autor: Armando Palacio Vázquez
____________________________
Tutor: Ing. Yulier Matías León
II
Datos del contacto:
Tutor: Ing. Yulier Matías León.
Clasificación: Profesional.
Clasificación del área de desarrollo: CEIGE.
Síntesis de la Tutor: Graduado en la Universidad de las Ciencias Informáticas con título de oro.
Actualmente es Analista y Diseñador del proyecto SAGEB perteneciente al Dpto. Soluciones Financieras.
Categoría Científica: Ingeniero. Categoría Docente: Instructor
II A mi madre y a Rodo por su constancia y dedicación; por ser todo el tiempo mi faro, mi luz y mi guía, a mi abuela por ser la miel que endulza mis días, fuente de ternura, sencillez y sacrificio, para ti, la Súper abuela mi corazón; a mi novia por llenarme la vida de ilusiones y alegrías, por ser uno de los regalos más hermosos que me ha dado la vida; a mis amigos por hacer que cada día sea para recordar, a todos muchas gracias, lo que soy hoy es por ustedes... más; quisiera dar un especial agradecimiento aquellos que hoy no están entre nosotros pero que no por ello están olvidados, esas personas que me enseñaron a superar los obstáculos y hacerme crecer ante las dificultades haciendo de mí una mejor persona.
A mi madre por ser un ejemplo de fortaleza, por ser la mejor mujer de este mundo, por darme lo que más necesita un ser humano, su eterno amor y su confianza.
A Rodo mi segundo padre pero de cariño como si fuese el primero, muchas gracias por tus consejos y por adoptarme como uno más de tus hijos.
A mi padre y mi abuelo por ser un modelo, un ejemplo de todo lo que un hombre necesita para ser de bien, muchas gracias… donde sea que estén quiero que sepan que los quiero mucho, que nunca los olvido y que estoy muy orgulloso de haber contado con su presencia, por ser los mejores recuerdos de mi vida, quiero que sepan que aunque pasen muchos años siempre serán parte de mi pues gracias a ustedes hoy soy una mejor persona.
A mis amigos, gracias por sus consejos y por brindarme uno de los regalos más bellos que puede tener las personas… la confianza… Gracias mis hermanos de sentimiento, cada uno tiene un lugar especial en mi corazón… y si hoy no menciono ningún nombre es porque nunca me perdonaría dejar de mencionar alguno, cada uno me ha dejado una enseñanza, y cada cual sabe el lugar que ocupa en mi corazón.
A mi familia por estar siempre al tanto de mis acciones y decisiones, por estar siempre presente y bríndame sus ayuda incondicional cuando más lo necesitaba, a todos muchas gracias.
A mi tutor, motor impulsor de esta idea, por estar siempre presente y brindarme su ayuda incondicional en todo momento, gracias, muchas gracias, si hoy soy lo que soy en gran parte también es por usted.
Gracias a todos los que una manera u otra han formado parte de mi vida, a todas esas personas que en algún
momento nos han dado.
III
Resumen
En los últimos años el paradigma de desarrollo dirigido por modelos MDD (por sus siglas en inglés) ha cobrado fuerza con el objetivo de lograr un mayor nivel de abstracción en el desarrollo de software. El desarrollo dirigido por modelos promete mejorar el proceso de construcción de software basándose en un proceso guiado por modelos y soportado por potentes herramientas. MDD promete solucionar los problemas tales como la interoperabilidad y portabilidad, y mejorar la productividad y la calidad del software generado.
Por tales motivos y después de una previa investigación, el Departamento de Soluciones Financieras del centro CEIGE concibe la necesidad de la creación de una solución informática personalizada que permita la gestión de un modelo de reglas independiente de la plataforma en el que se almacenen los datos de las reglas, manteniendo así el principio básico detrás del desarrollo basado en modelos. Esta solución es denominada Génesis y tiene como objetivo el llevar a cabo la creación de modelos que recojan toda la información necesaria sobre el sistema. Se realizó un estudio de los diferentes conceptos relacionados con el tema y un estudio de los diferentes sistemas que permiten llevar a cabo un desarrollo dirigido por modelos en la actualidad.
PALABRAS CLAVE
Reglas, MDD, plataforma, gestión, desarrollo de software, modelos, Génesis.
4
Índice
RESUMEN ... III
INTRODUCCIÓN ... 8
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA ... 13
1.1 Introducción ... 13
1.2 Marco Conceptual ... 13
1.3 Desarrollo de software dirigido por modelos ... 14
1.3.1 Ingeniería Dirigida por Modelos (MDE)... 15
1.3.2 Desarrollo Dirigido por Modelo (MDD) ... 15
1.3.3 Arquitectura Dirigida por Modelos (MDA) ... 16
1.3.4 Sistemas de desarrollo de software dirigido por modelos ... 19
1.4 Metodologías, Tecnologías y Herramientas de desarrollo de software. ... 23
1.4.1 Rational Unified Process (RUP) ... 24
1.4.2 Lenguaje de modelado ... 25
1.4.3 Herramienta de modelado ... 26
1.5 Herramientas, Tecnologías y Lenguajes para el desarrollo de una aplicación. ... 27
1.5.1 Lenguaje de programación ... 27
1.5.2 Entorno de Desarrollo Integrado (IDE) ... 28
1.6 Plugins ... 30
1.6.1 Estructura de un plugin ... 31
1.6.2 Herramientas de Desarrollo Java (JDT) ... 31
1.6.3 Entorno de Desarrollo de Plugins (PDE) ... 32
1.7 Herramienta de desarrollo colaborativo ... 32
1.7.1 Control de versiones ... 32
1.8 Mecanismo de Reutilización: Los Patrones ... 33
1.8.1 Definición de Patrón de Arquitectura ... 34
1.8.2 Definición de Patrón de Diseño ... 34
1.8.3 Patrones en Génesis ... 34
1.5 Conclusiones del capitulo ... 36
CAPÍTULO 2: DISEÑO DE LA SOLUCIÓN ... 37
2.1 Introducción ... 37
2.2 Arquitectura de la solución ... 37
5
2.2.1 Vista lógica del Módulo Reglas ... 37
2.3.2 Modelo Vista Controlador (MVC) ... 39
2.4 Modelado del Sistema ... 41
2.4.1 Breve descripción de los Casos de Uso (CU) del sistema. ... 41
2.5 Modelo de Diseño ... 42
2.5.1 Diagrama de paquetes ... 43
2.5.2 Diagrama de clases del diseño ... 45
2.5.3 Diagrama de interacción: diagrama de secuencia ... 47
2.5.4 Diagrama de clases persistentes (Metamodelo) ... 47
2.6 Patrones de diseño empleados ... 48
2.7 Conclusiones ... 50
CAPÍTULO 3: IMPLEMENTACIÓN Y PRUEBAS ... 51
3.1 Introducción ... 51
3.2 Implementación ... 51
3.2.1 Estándares de codificación ... 52
3.2.2 Modelo de implementación ... 54
3.2.3 Diseño de las interfaces de usuario ... 56
3.3 Validación de la implementación de los subsistemas... 56
3.3.1 Validación del modelo de diseño propuesto ... 57
3.4 Pruebas de Software ... 65
3.5 Métodos de prueba ... 66
3.5.1 Aplicación de la Prueba de Caja Blanca o Estructural. ... 67
3.5.2 Pruebas de Caja Negra o Funcionales ... 71
3.6 Conclusiones parciales ... 74
CONCLUSIONES GENERALES ... 75
RECOMENDACIONES ... 76
REFERENCIA BIBLIOGRÁFICA ... 77
BIBLIOGRAFÍA ... 80
ANEXO ... 81
Anexo # 1 ... 81
6
Índice de Figuras
Figura_ 1: Arquitectura de Eclipse para el desarrollo de plug-ins. ... 29
Figura_ 2: Estructura simple de un plugin de Eclipse. ... 30
Figura_ 3: Arquitectura del plugin Génesis ... 38
Figura_ 4: Arquitectura MVC. ... 40
Figura_ 5: Estructura de paquetes del módulo Reglas. ... 43
Figura_ 6: Diagrama de Paquetes del sistema. ... 44
Figura_ 7: Diagrama de clases auxiliares y de diseño. ... 46
Figura_ 8: Diagrama de secuencia: Crear regla a la entidad (GCreateRuleEntity). ... 47
Figura_ 9: Diagrama de clases del dominio (Metamodelo). ... 48
Figura_ 10: Ejemplo donde se evidencia la aplicación del Patrón de diseño Singlenton. ... 49
Figura_ 11: Diagrama de componentes del módulo Reglas del plugin Génesis. ... 55
Figura_ 12: Diagrama de despliegue del Plugin Génesis. ... 55
Figura_ 13: Resultado de la aplicación del instrumento de evaluación de la métrica TOC. .... 60
Figura_ 14: Resultados de la evaluación de la métrica TOC para los atributo Complejidad. .. 61
Figura_ 15: Resultados de la evaluación de la métrica TOC para el atributo Reutilización. .... 61
Figura_ 16: Resultados de la evaluación de la métrica TOC para los atributo Responsabilidad. ... 61
Figura_ 17: Resultado de la aplicación del instrumento de evaluación de la métrica TOC. .... 62
Figura_ 18: Resultados de la evaluación de la métrica RC para el atributo Acoplamiento. ... 62
Figura_ 19: Resultados de la evaluación de la métrica RC para el atributo Complejidad de Mantenimiento. ... 63
Figura_ 20: Resultados de la evaluación de la métrica RC para el atributo Cantidad de Pruebas. ... 63
Figura_ 21: Resultados de la evaluación de la métrica RC para el atributo Reutilización. ... 63
Figura_ 22: Representación de pruebas de Caja Blanca y Caja Negra. ... 67
Figura_ 23: Código fuente de la funcionalidad eliminar Grupo de reglas... 68
Figura_ 24: Grafo de flujo asociado a la funcionalidad eliminar Grupo de reglas. ... 68
Figura_ 25: Crear regla a una Entidad. ... 81
Figura_ 26: Crear regla. ... 81
7
Índice de Tablas
Tabla_ I: Atributos de calidad evaluados por la métrica TOC. ... 58
Tabla_ II: Atributos de calidad evaluados por la métrica RC. ... 58
Tabla_ III: Atributos de calidad evaluados por la métrica RC. ... 59
Tabla_ IV: Atributos de calidad evaluados por la métrica RC. ... 59
Tabla_ V: Criterios de evaluación para la métrica RC. ... 59
Tabla_ VI: Instrumento de evaluación de la métrica TOC. ... 60
Tabla_ VII: Instrumento de evaluación de la métrica RC. ... 62
Tabla_ VIII: Resultados de la evaluación de la relación atributo/métrica. ... 64
Tabla_ IX: Rango de valores para la evaluación de la relación atributo/métrica ... 64
Tabla_ X: Resultados obtenidos de la evaluación de los atributos de calidad. ... 64
Tabla_ XI: Diseño del Caso de Prueba del Crear componente regla. ... 73
Tabla_ XII: Comparativo de herramientas MDA (AndroMDA, ArcStyler, OptimalJ). ... 82
8
Introducción
En el siempre cambiante mundo de la computación, donde cada día las computadoras son más veloces y la complejidad de los sistemas a desarrollar incrementa constantemente, el éxito de los departamentos y compañías de tecnología de Información y Comunicación (TICs) están siendo juzgados por la habilidad de construir sistemas de acuerdo a las cada vez más estrictas restricciones de tiempo y calidad que impone el mercado, exigiendo además que estos sistemas sean lo suficientemente flexibles para responder de forma ágil a los cambios de requerimientos tecnológicos o del negocio mismo. Es fácil suponer entonces, que todos los métodos, tecnologías, arquitecturas y lenguajes existentes, buscan brindar a la gente que trabaja con TIC herramientas y/o procesos capaces de acelerar la construcción de sistemas de software de calidad.
A finales del siglo XX el modelado Orientado a Objetos alcanzó su madurez, llevando a UML1 como uno de sus estándares más avanzados. A pesar del progreso notable que esto representó, la industria del desarrollo de software aún no puede responder con la velocidad necesaria a las organizaciones que requieren cambiar rápidamente sus reglas de negocio. (1)
En el entorno de las reglas de negocio no existe una definición estándar del término regla de negocio.
En este trabajo se presenta la definición redactada por el grupo de reglas de negocio o BRG2, la cual es la más utilizada por los expertos en el tema: “una regla de negocio es una declaración que define u obliga un cierto aspecto del negocio. Con estas se pretende imponer la estructura del negocio o controlar o influenciar el comportamiento del negocio”, además de garantizar la correcta ejecución de los procesos y la seguridad de los datos.
Y si agregamos a esto la rápida evolución de la tecnología en un ambiente altamente interconectado con diversas plataformas, el integrar los diversos sistemas de una organización se vuelve complejo y demandante. Es en este tipo de problemas donde no basta con las nuevas tendencias en la industria de cómputo, pues el desarrollo rápido de aplicaciones (RAD por sus siglas en inglés), la arquitectura orientada a servicios (SOA) y la computación en nube no son suficientes. (1)
1 LUM o UML: Unified Modeling Language (acrónimo inglés de Lenguaje Unificado de Modelado)
2BRG: Business Rules Group (acrónimo inglés de grupo de reglas del negocio)
9
Para poder integrar sistemas de software con tecnologías diversas (EJB/J2EE3, .NET4, XML5, SOAP6, etc.) y que puedan adaptarse rápidamente a los negocios cambiantes, la tendencia es apostar al desarrollo dirigido por modelos (Model Driven Development, MDD) liderada por el OMG (Object Management Group), siendo esta la propuesta más avanzada de la Ingeniería Basada en Modelos (Model Driven Engineering, MDE), la cual está basada en los estándares UML [3], XMI [4], MOF [5], donde los artefactos principales del desarrollo son los modelos (no los programas) y la transformación de modelos, o sea MDD propone esquemas de desarrollo en los cuales los modelos, antes que el código, son los actores centrales del proceso de desarrollo y donde se proveen mecanismos y herramientas de trabajo integradas que asisten al desarrollador en la construcción y transformación progresivas de modelos hasta llegar a la solución final. (1)La Universidad de las Ciencias Informáticas (UCI) actualmente mantiene convenios de producción de software tanto con organismos y entidades nacionales como extranjeras. Está llamada a insertarse en el mercado como potencial desarrolladora y comercializadora de productos informáticos. Sin embargo su proceso de desarrollo de software, a pesar de su consolidación paulatina, presenta algunas limitaciones ya que a partir de un estudio realizado en los proyectos de nuestra facultad se evidenció la ausencia de un desarrollo dirigido por modelos y la no existencia de un modelo de reglas independiente de la plataforma que permita representar las reglas de un sistema por lo cual una vez que se realice un cambio en las reglas del negocio se debe ir directamente a modificar el código, lo cual entorpece el desarrollo de cualquier software; generalmente la implementación de la reglas de un sistema se llevan a cabo manualmente lo que consume tiempo en el desarrollo.
Otro aspecto importante sobre el Desarrollo Dirigido por Modelos es que el mismo presenta una serie de ventajas sobre el desarrollo tradicional de aplicaciones, el desarrollo software se encuentra actualmente en una etapa en la que debe superar un importante número de problemas. Hoy en día, debido a la gran cantidad de tecnologías existentes, escribir software es una tarea difícil.
3EJB/J2EE: Los Enterprise JavaBeans (también conocidos por sus siglas EJB) son una de las API que forman parte del
estándar de construcción de aplicaciones empresariales J2EE .
4.NET: framework de Microsoft que hace un énfasis en la transparencia de redes, con independencia de plataforma de
hardware y que permita un rápido desarrollo de aplicaciones.
5XML: eXtensible Markup Language (acrónimo inglés Lenguaje de Marcas Extensible)
6SOAP: Simple Object Access Protocol (acrónimo inglés de Protocolo de Acceso a Objetos Simples) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.
10
Con cada nueva tecnología se requiere mucho trabajo para poder emplearla teniendo en cuenta el tiempo de aprendizaje, el tiempo de desarrollo, etc. Por otro lado, la mayoría de los sistemas actuales usan más de una tecnología, y necesitan comunicarse con otros sistemas. También hay que tener en cuenta que los requisitos cambian continuamente, algunos de los problemas más importantes encontrados durante el desarrollo tradicional de software están (6):1. El problema de la productividad
El proceso de desarrollo de software tradicional, es conducido a menudo por el diseño de bajo nivel y el código. Aún si el proceso es iterativo e incremental, los documentos y los diagramas se producen sólo en las fases tempranas (requerimientos, análisis). Los documentos y los diagramas correspondientes creados en las primeras fases pierden rápidamente su valor tan pronto como la codificación comienza. La conexión entre los diagramas y el código se pierde mientras se progresa la fase de codificación.
2. El problema de la portabilidad
Las nuevas tecnologías ofrecen beneficios concretos para las compañías y muchas de ellas no pueden quedarse atrás, por lo tanto, tienen que utilizarlas muy rápidamente. Como consecuencia del cambio, las inversiones en tecnologías anteriores pierden valor. El software ya existente puede seguir sin cambios, pero necesitará comunicarse con los nuevos sistemas que serán construidos usando una nueva tecnología.
3. El problema de la interoperabilidad
Los sistemas de software raramente funcionan en forma aislada. La mayoría de los sistemas necesitan comunicarse con otros que generalmente ya existen. Incluso cuando los sistemas se construyen completamente, usan a menudo múltiples tecnologías, a veces mezclando viejas y nuevas.
4. El problema del mantenimiento y la documentación
Generar documentación durante el desarrollo cuesta tiempo y retrasa el proceso; sin embargo ayudará en su tarea, a los encargados de integrar el proyecto en etapas finales. Así pues, escribir documentación se ve como algo para el futuro, no para el presente. Dada la complejidad de los sistemas que se construyen, la documentación en un nivel más alto de la abstracción resulta obligatoria.
11
Es por todo ello que el desarrollo dirigido por modelos representa una de las soluciones más viables para llevar a cabo un desarrollo de software exitoso, MDD promete mejorar el proceso de construcción de software basándose en un proceso guiado por modelos y soportado por potentes herramientas. De esta manera, MDD promete solucionar los problemas planteados anteriormente y mejorar la productividad y la calidad del software generado, debido a que se reduce el salto semántico entre el dominio del problema y de la solución. Se reducen los tiempos de desarrollo y las herramientas de generación pueden aplicar frameworks, patrones y técnicas con éxito ya comprobado. (6)Teniendo en cuenta toda esta situación explicada anteriormente, en el Departamento de Soluciones Financieras del centro CEIGE se decidió realizar un sistema llamado Génesis, que permita llevar a cabo un desarrollo dirigido por modelos y que posibilite crear un modelo único y flexible, en el que se almacenen los datos de las reglas. Por otra parte el modelo que implementaría este sistema sería independiente de la plataforma o arquitectura que se utilice para el desarrollo de la aplicación final, reduciendo de esta manera el tiempo, costo y complejidad asociada con aplicaciones desplegadas en diferentes tecnologías.
Dada la situación antes planteada surge el siguiente problema a resolver: ¿Cómo lograr la gestión de las reglas del negocio teniendo en cuenta los requisitos propuestos en Génesis de forma tal que contribuya a agilizar el desarrollo de software?
Teniendo en cuenta el problema anterior se declara como objeto de estudio de la investigación: las herramientas de gestión de modelos de reglas.
Del objeto de estudio derivamos que el campo de acción que abarca este trabajo, es: la gestión de modelos de reglas en el plugin7 Génesis.
Con el fin de resolver el problema planteado con anterioridad, se ha trazado como objetivo general:
desarrollar el módulo Reglas de Génesis para el entorno de desarrollo Eclipse.
Para dar cumplimiento a este objetivo se han propuesto las siguientes tareas a realizar:
1. Caracterización de algunos sistemas que implementan un desarrollo dirigido por modelos.
2. Realización del meta-modelo de reglas del plugins Génesis.
3. Realización del diseño de clases visuales y auxiliares del módulo Reglas del plugins Génesis.
7Plugin: programa que interactúa con una aplicación principal para proveerle de cierta función normalmente muy específica.
12
4. Realización del modelo de componentes del módulo Reglas del plugins Génesis5. Implementación del modelo de componentes del módulo Reglas del plugins Génesis.
6. Realización de pruebas unitarias a la implementación del módulo Reglas del plugins Génesis.
Todo esto puede traer como posibles resultados: obtener el módulo Reglas del plugins Génesis para el entorno de desarrollo Eclipse.
La idea a defender queda planteada de la siguiente manera: si se lograra la gestión de las reglas del negocio teniendo en cuenta los requisitos propuestos en Génesis, se reduciría el tiempo invertido por los desarrolladores actualmente en la implementación y acabado de las reglas de los diferentes módulos de una aplicación de gestión, contribuyendo a agilizar el desarrollo de software.
Para lograr la comprensión y claridad de los contenidos de la investigación realizada se ha estructurado el documento en tres capítulos; en el Capítulo 1 se realiza la fundamentación teórica de la investigación, la cual incluye un estudio de la metodología que guiará el proceso de desarrollo del software, las herramientas a utilizar y el estado del arte del tema relacionado a la creación de modelos de reglas y la transformación de estos hacia una arquitectura específica durante la implementación de los diferentes módulos de una aplicación web de gestión. El Capítulo 2 constituye la propuesta de solución, en el mismo se exponen las características del sistema a desarrollar además de los artefactos generados durante el diseño del mismo, así como se construirá el metamodelo de las reglas.
En el Capítulo 3 se exponen los artefactos generados durante la implementación de la solución así como las métricas y pruebas utilizadas para la validación de la misma.
Como métodos científicos de investigación utilizados para la obtención del diseño e implementación del módulo, están: Teóricos:
Análisis Histórico - Lógico: Se comienza la investigación con un análisis del surgimiento y trayectoria de las metodologías basadas en modelos, orientada a objetos, patrones de diseño, herramientas CASE y estudio de los plugins a nivel mundial y nacional.
Analítico-Sintético: resultó importante a la hora de fundamentar los elementos más significativos de la investigación determinando los aspectos esenciales y el arribo a conclusiones prácticas y teóricas.
Método de la modelación: Proceso mediante el cual se pueden crear modelos (propuestas, alternativas, estrategias), con vista a aproximaciones de la realidad.
Empíricos
Observación: utilización en el proceso de diagnóstico del estado actual de nuestro objeto de estudio.
13
Capítulo 1: Fundamentación teórica
1.1 Introducción
El presente capítulo define el conjunto de actividades a llevar a cabo para la realización del diseño y la posterior implementación del módulo Reglas del plugin Génesis. Se incluye además, un estudio relacionado con los diferentes sistemas existentes en la actualidad para la gestión de modelos de interfaces, así como las herramientas a utilizar con el fin de lograr de forma productiva los objetivos propuestos.
1.2 Marco Conceptual
En el presente capítulo se describen los conceptos fundamentales asociados al dominio del problema y el objeto de estudio, haciéndose un análisis de la situación actual. Se presenta la fundamentación de las tecnologías utilizadas para el diseño del sistema y las propuestas para su implementación y desarrollo.
Conceptos básicos asociados al dominio del problema:
Según el Análisis Orientado a Objetos, para cada objeto del sistema se debe definir cuál es su estructura y cual su comportamiento. Para definir el comportamiento de un objeto se usan las Reglas.
Regla: define como se valida una entidad del negocio, por ejemplo el formato del correo electrónico, un valor numérico dentro de un rango, los valores obligatorios, etc.
Validación: En el mundo del software la palabra validación consiste en comprobar que tanto el algoritmo como el programa cumplen la especificación del problema. También es el proceso de comprobar la precisión de los datos; conjunto de reglas que se pueden aplicar a un control para especificar el tipo y el intervalo de datos que los usuarios pueden especificar.
Validación de datos: Proceso por el cual los datos son filtrados y aceptados o rechazados en base a procedimientos definidos. Los datos deben ser validados por personal calificado y autorizado siguiendo un procedimiento operativo estándar. Al validar los datos se pueden detectar potenciales problemas en el análisis, eventos inusuales durante el muestreo y errores en la transcripción de los datos y en la presentación de los mismos.
14
Para las aplicaciones de negocios, validación de datos se puede definir a través declarativa integridad de los datos normas o procedimientos basados en reglas de negocio. Los datos que no se ajustan a estas normas afectarán negativamente proceso de ejecución del negocio. Por lo tanto, la validación de datos debe comenzar con la definición de procesos de negocio y un conjunto de reglas de negocio dentro de este proceso.Regla de validación: Una regla de validación es un criterio utilizado en el proceso de validación de datos, llevada a cabo después de que los datos han sido codificados en un medio de entrada.
Pruebas de validación: En el ámbito del software, se conoce como pruebas de validación al proceso de revisión al que se somete un programa informático para comprobar que cumple con sus especificaciones. Dicho proceso, que suele tener lugar al final de la etapa de desarrollo, se realiza principalmente con la intención de confirmar que el software esté en condiciones de desarrollar las tareas que el usuario que lo adquiere planea llevar a cabo. (2)
1.3 Desarrollo de software dirigido por modelos
La rápida evolución de Internet presenta un mercado cada vez más competitivo donde ha aumentado de forma exponencial el volumen de negocio y el número de usuario. Esto provoca que cada día las aplicaciones de gestión sean más complejas y se deban desarrollar en el menor tiempo posible y si a esto se le suma la ausencia de la arquitectura del software, falta de trazabilidad entre las fases de desarrollo y la gran variedad de notaciones funcionales para aplicaciones web lo cual ha generado una baja compatibilidad entre cada una de las propuestas lo cual impide que las representaciones de aplicaciones web realizadas por una propuesta sean reutilizables por proyectos que trabajan con una propuesta diferente.(3)
En general se puede llegar a varias conclusiones; primero, para asegurar la viabilidad de los métodos para el desarrollo de las aplicaciones de gestión , las diferentes propuestas deben incorporar de forma explícita los aspectos de la arquitectura del software dentro de su proceso de desarrollo; con ello se puede concluir que existe la necesidad de proporcionar mecanismos de estandarización que permitan los modelos propuestos por las diferentes aproximaciones y permitir su uso en un mayor número de herramientas.(3). Dada la relevancia que tiene hoy en día el Desarrollo de Software Dirigido por Modelos (DSDM),no es extraño que aparezcan constantemente nuevas propuestas basadas en este esquema de desarrollo enfocadas a los más diversos dominios de aplicación.
15
1.3.1 Ingeniería Dirigida por Modelos (MDE)La presente investigación se ha basado en la Ingeniería Dirigida por Modelos (MDE) (12) para la definición de los artefactos producidos a lo largo de desarrollo para la obtención de las aplicaciones Web; y más concretamente, en su propuesta estandarizada por la OMG llamada MDA (Model Drive Development) (13) que permiten la definición de los artefactos producidos siguiendo los estándares. En este sentido es importante conocer en lo que consiste el concepto de MDE y su influencia en el presente trabajo.
MDE es un frameworks conceptual definido por Stuart Kent (12) “aborda el escurridizo problema del desarrollo de sistemas, promoviendo el uso de los modelos como primer artefacto para su construcción y su mantenimiento”. Sin embargo, el artefacto realmente novedoso definido por MDE son las transformaciones que permiten establecer un mapeo trazable desde los modelos definidos hasta la implementación final. Esta nueva tendencia es llamada también Ingeniería de Modelos por Bezivin (14).
En la actualidad existen muchas puntos de vista respecto MDE algunas la muestran como un frameworks conceptual, otras como un paradigmas mientras que algunas se refieren más a esta como una metodología, a continuación se enuncia otra de las definiciones que se le ha dado MDE. La Ingeniería Dirigida por Modelos, Model Driven Engineers (MDE), es una metodología de desarrollo de software, que se centra en la creación de modelos o abstracciones. El uso de modelos permite aumentar el nivel de abstracción con que se realizan los sistemas.
1.3.2 Desarrollo Dirigido por Modelo (MDD)
El Desarrollo Dirigido por Modelo, en ingles Model-Driven Development (MDD), considera como principales elementos del proceso de desarrollo a los modelos para representar diferentes aspectos de un sistema software con el fin de elevar el nivel de abstracción y de automatización, es decir establece que solo el modelo de una aplicación se ha de desarrollar, y que el resto de la aplicación se generará desde este modelo.
(4)
16
A lo largo de la pasada década el Desarrollo Dirigido por Modelos se convirtió en un nuevo paradigma de software. Su objetivo es separar la especificación de la funcionalidad del sistema de su implementación sobre una plataforma concreta. Para ello, el MDD identifica dos tipos principales de modelos: modelos con alto nivel de abstracción e independientes de cualquier tecnología de implementación, y modelos que especifican el sistema en términos de construcciones de implementación disponibles en alguna tecnología específica. De esta manera, MDD promete solucionar los problemas planteados anteriormente y mejorar la productividad y la calidad del software generado, debido a que se reduce el salto semántico entre el dominio del problema y de la solución.Se reducen los tiempos de desarrollo y las herramientas de generación pueden aplicar frameworks, patrones y técnicas con éxito ya comprobado.
Han aparecido varios enfoques dentro del ámbito de MDD, pero sin duda la iniciativa más conocida y extendida es la Model Driven Architecture en español Arquitectura Dirigida por Modelos (MDA), presentada por el OMG en noviembre de 2000 con el objetivo de afrontar los desafíos de integración de las aplicaciones y los continuos cambios tecnológicos.
1.3.3 Arquitectura Dirigida por Modelos (MDA)
La Arquitectura Dirigida por Modelos (MDA) se estableció por primera vez en la especificación definida por la OMG [8] en donde se indicaba que: “MDA define una aproximación para la especificación de sistemas de información que separa la funcionalidad del sistema de la implementación para una plataforma tecnológica específica“.
Para conseguir este fin, MDA define una arquitectura de modelos que provee las guías para estructurar las especificaciones expresadas como modelos. Esta separación entre la operación del sistema y los detalles específicos de la propia plataforma proporciona las siguientes ventajas:
Especificar el sistema independientemente de la plataforma que la soporta.
Especificar diferentes plataformas.
Elegir una plataforma específica para el sistema y transformar la especificación del sistema en una plataforma particular.
17
Como se indica la MDA guide (5), los tres principales objetivos de MDA son la interoperabilidad, la usabilidad y la reutilización a través de la separación de aspectos. MDA especifica una arquitectura de modelos que se incorpora a los procesos de desarrollo tradicionales, reduciendo el trabajo en las fases de elaboración y acelerando este proceso. A continuación, se muestran cuáles son los conceptos principales en los que se basa MDA.Conceptos Básicos de MDA
A continuación se realiza un recorrido sobre aquellos conceptos más relevantes que constituyen la especificación MDA y sobre los que se basa el plugin Génesis para especificar sus artefactos dentro de su proceso de desarrollo.
Sistema
Los conceptos de MDA se definen centrados en la existencia o planteamiento de un sistema, que puede contener un simple sistema informático, o combinaciones de componentes en diferentes sistemas informáticos, o diferentes sistemas en diferentes organizaciones, etc.
Aplicación
En MDA se define el término aplicación como una funcionalidad que tiene que ser desarrollada. Por tanto podemos definir un sistema en términos de la implementación de una o más aplicaciones, soportadas por una o más plataformas.
Modelo
Un modelo es una representación abstracta de alguna cosa que puede o no existir en la realidad; es una simplificación que muestra ciertos aspectos de lo que se desea modelar, escondiendo aquellos elementos que no son de interés a los que usaran el modelo. (7)
Pero que se desea indicar exactamente cuándo se utiliza la palabra modelo. Llegar a una definición que abarque todos los tipos de modelos es muy difícil. Además, la definición necesita ser lo suficientemente específica para que ayude a especificar la información necesaria para obtener una transformación automática de un modelo a otro. Un modelo está siempre escrito en un lenguaje. Este lenguaje podría ser UML, un lenguaje natural, un lenguaje de programación o cualquier otro lenguaje que se pueda imaginar.
18
Pero para permitir una transformación automática desde un modelo, en MDA se restringe a aquellos modelos que estén escritos en un lenguaje bien definido. Un lenguaje tiene una forma y una semántica bien definida cuando este puede ser interpretado automáticamente por un computador. En este sentido, no se pueden considerar los lenguajes naturales como bien definidos, porque no pueden ser interpretados por las computadoras. De esta manera, para los propósitos de este trabajo se adopta la siguiente definición de modelo:“Una descripción (o parte) de un sistema escrito en un lenguaje bien definido“. Kepple et al. (8)
Siendo un lenguaje bien definido un lenguaje con la sintaxis y la semántica bien definidas, cuya interpretación puede automatizarse por un computador. En este sentido aunque en Génesis se han definido los modelos basándose en el estándar UML, MDA no está restringido a UML. Dentro de MDA existe una topología de modelos que permite identificarlos según su función dentro del proceso de desarrollo del software. Estos modelos no se definen de forma aislada sino que están vinculados entre ellos mediante transformaciones (CIM8, PIM9, PSM10).
Metamodelo
Como se indicaba en el punto anterior, los lenguajes que requiere MDA deben ser lenguajes bien definidos, es decir, deben poder ser interpretados por el computador. En el pasado, esto estaba establecido representado el lenguaje mediante BNF11el cual escribía la serie de tokens que seguían una expresión correcta. Sin embargo, BNF se restringe a aquellos lenguajes que son puramente texto y en este caso la mayoría de modelos que se utilizan en MDA tienen una sintaxis gráfica, como UML.
Para ellos se utiliza un mecanismo denominado metamodelo.
Como se define en la especificación de UML 2.0 (9) “un metamodelo es un modelo que especifica el lenguaje para expresar un modelo“.
Según esta definición, todos los elementos que un modelador puede usar en su modelo deben estar definidos previamente en el metamodelo del lenguaje que el modelador usa. Así por ejemplo, en el modelo de clases de UML se pueden utilizar clases, atributos, operaciones,
8CIM: Computation Independent Model (acrónimo inglés de Modelo Independiente de Computación )
9PIM: Platform Independent Model (acrónimo inglés de Modelo Independiente de Plataforma)
10PSM: Platform Specific Model (acrónimo inglés de Modelo Específico de Plataforma)
11 BNF: Backus-Naur Form (acrónimo inglés que especifica Forma de Juan Backus y Meter Naur)
19
asociaciones, etc. gracias a que en el metamodelo de UML está definido el concepto de clase, como esa clase contiene un conjunto de elementos llamados atributos, además como la clase se relaciona a través de conceptos como asociación o herencia. Debido a que un metamodelo es también un modelo, el mismo metamodelo debe estar escrito en un lenguaje bien definido.1.3.4 Sistemas de desarrollo de software dirigido por modelos
La existencia de una metodología y de un marco de trabajo que guíen el proceso de creación de modelos y la generación del código necesario correspondiente, ha contribuido al surgimiento de un conjunto de herramientas que crean aplicaciones a partir de la definición de modelos. Actualmente existe una gran variedad de herramientas que soportan MDA; algunas de estas se encuentran disponibles en la web como son el caso de VIATRA (VIsual Automated model TRAnsformations) framework, Epsilon, Kent Model Transformation Language, Tefkat, ATL (Atlas Transformation Language), AToM3 (A Tool for Multi-formalism and Meta-Modeling) mientras que otras son comerciales, entre estas se encuentran OptimalJ, ArcStyler, Codagen Architect.
En la presente tesis se caracterizan sólo algunas de estas herramientas fundamentalmente aquellas que resultaron de vital importancia para el futuro desarrollo plugin Génesis. Existe también una breve descripción del resto de las herramientas en el glosario de términos. (Glosario)
AndroMDA
Sigue el paradigma de arquitectura MDA. AndroMDA (pronunciado
“Andrómeda”) es de código abierto, pero los modelos utilizados son los obtenidos utilizando UML [20], por lo que no es posible registrar toda la información de un sistema, como los aspectos visuales, las reglas de validación, las expresiones booleanas, los orígenes de datos, entre otras necesidades. Por lo que esta herramienta no soportaría todos los requisitos necesarios [21]. Hace uso de diversos estándares abiertos para llevar a cabo sus funciones: Struts, Netbeans MDR, Hybernate, entre otros. Admite cualquier lenguaje de programación como salida, y admite código propio para la generación de código.
Dadas sus características se puede considerar un Framework para el desarrollo con MDA más que una herramienta en sí misma. Debido a que su generador de código soporta plataformas actuales, se ha convertido en la principal herramienta de código abierto de MDA para el desarrollo de aplicaciones empresariales. (16)
20
GeneXusGeneXus es una herramienta inteligente de desarrollo para construir y mantener sistemas, de una manera simple, la misma ha avanzado mucho en el tema de la generación de aplicaciones, ya que hace posible que los clientes tengan sistemas actualizados, tanto a la realidad empresarial como tecnológica, y pueden concentrarse en su negocio sin preocuparse por la evolución de la tecnología, permitiéndoles migrar hacia cualquier plataforma, gracias al diseño de una base de conocimiento independiente de cualquier lenguaje, base de datos, sistema operativo o arquitectura siguiendo para esto el paradigma MDD.(17) Un aspecto importante dentro de GeneXus son las especificaciones de las reglas, en el mismo las reglas son el medio para definir la lógica del negocio asociada a cada objeto. Son escritas en forma declarativa es decir, el orden en el cual se escriben no es necesariamente el orden en el cual se van a ejecutar. El orden de ejecución adecuado es automáticamente determinado por GeneXus.
OptimalJ
OptimalJ es la herramienta que se puede considerar que mejor adapta la visión MDA, es decir en ella podemos encontrar los niveles bien diferenciados de PIM, PSM y código. Genera aplicaciones J2EE partiendo de los modelos. Está desarrollado en Java, lo que le hace portable a cualquier plataforma para su ejecución. OptimalJ dispone de plugins para los entornos de desarrollo integrado Eclipse y NetBeans. Admite XMI tanto para la importación de ficheros como para su salida. [23]. OptimalJ:
gracias a la clara separación entre el PIM y los PSM OptimalJ puede considerarse como una herramienta que refleja fielmente el proceso MDA, con una clara separación entre el PIM y los PSM. A partir de un modelo de clases permite crear de forma sencilla y en poco tiempo, una aplicación básica para la plataforma J2EE, generando código de buena calidad. (16)
Codagen Architect 3.2
Codagen Architect Permite la transformación de modelos y la automatización de la generación de código partiendo de los modelos CIM. Como integración con herramientas de modelado, Codagen incorpora plugins para Microsoft Visio, Rational Rose y Borland Together Control. Admite como entrada ficheros XMI y ficheros MDL de Rational Rose. Entre los estándares libres soportados tenemos únicamente Struts, pero como
21
contrapartida, los lenguajes de salida que admite son Java, C#, C++ y Visual Basic, admitiendo también la incorporación de código propio al código generado. (16)AToM3 (A Tool for Multi-formalism and Meta-Modeling)
AToM3 (Una herramienta para multi-formalismo y Meta-Modelado) es una herramienta para modelado en muchos paradigmas bajo el desarrollo de MSDL (Modelling Simulation and Design Lab) Laboratorio de Simulación y Modelización de diseño en la escuela de ciencias de la computación de la universidad de McGill. Las dos tareas principales de AToM3 son metamodelado y transformación de modelos. El metamodelado se refiere a la descripción o modelado de diferentes clases de formalismos usados para modelar sistemas (aunque se enfoca en formalismos de simulación y sistemas dinámicos, las capacidades de AToM3 no se restringen a solo esos). Transformación de modelos se refiere al proceso automático de convertir, traducir o modificar un modelo en un formalismo dado en otro modelo que puede o no estar descrito en el mismo formalismo. (6)
EPSILON
Epsilon es una plataforma desarrollada como un conjunto de plug-ins (editores, asistentes, pantallas de configuración, etc.) sobre Eclipse.
Presenta el lenguaje metamodelo independiente Epsilon Object Language que se basa en OCL. Puede ser utilizado como lenguaje de gestión de modelos o como infraestructura a extender con nuevos lenguajes específicos de dominio. Tres son los lenguajes definidos en la actualidad: Epsilon Comparison Language (ECL), Epsilon Merging Language (EML), Epsilon Transformation Language (ETL), para comparación, composición y transformación de modelos respectivamente. Soporta mecanismos de herencia, traceability e introduce mecanismos de comprobación automática del resultado en composición y transformación de modelos. (6)
E-Platero (Eclipse PLugin Aiding Traceability in an Environment with Refinement- Orientation)
e-Platero es el acrónimo para “Plugin de Eclipse para Ayudar a la Trazabilidad en un entorno con Refinamiento-Orientación”. Es una herramienta de código abierto implementada como plugins para la plataforma de Eclipse, que soporta el proceso de desarrollo conducido por modelos usando una notación gráfica con base formal y corre
22
sobre el framework para metamodelado EMF. Es la evolución de PAMPERO (Precise Assistant for the Modeling Process in an Environment with Refinement Orientation) en español Asistente Preciso para el Proceso de Modelado en un Entorno con el Refinamiento de Orientación, un plugin implementado para la versión de Eclipse 2.1. Puede interoperar con cualquier herramienta que soporte como arquitectura la Model Driven Architecture (MDA)Los principales objetivos de e_Platero son:
Creación y edición gráfica de modelos UML
Edición y validación de restricciones OCL (Lenguaje de Restricciones para Objetos) en el nivel del metamodelo, incluyendo reglas de buena formación para modelos
Edición y validación de restricciones OCL en el nivel de modelos (reglas de negocio)
Edición y validación de relaciones de refinamiento entre modelos.
ArcStyler 5.5
ArcStyler es una de las herramientas MDA comerciales más extendida. Puede generar código a partir de modelos para cualquier plataforma como .NET o J2EE, siendo una herramienta
genérica que nos permite transformaciones de modelo a código sin restricciones. Es un sistema basado en uso de cartuchos para descripción de transformaciones que permite generar aplicaciones de n capas codificadas en java/J2EE y c#/.NET a partir de diagramas UML y la especificación de los procesos del negocio. Permite extender las capacidades de transformación, generando nuevos cartuchos a partir de UML, cuyo objetivo sea cualquier plataforma o lenguaje. Usa Rose como herramienta de modelado UML, soportando directamente los ficheros MDL ,aunque es independiente de cualquier versión UML ya que se apoya en otra herramienta que le proporciona dicha funcionalidad, MagicDraw12. Se apoya en MOF para definir sus propios modelos y en XMI para almacenarlos, lo que le permite exportar e importar los distintos modelos usados. (16)
12MagicDraw es una herramienta de modelado visual para hacer diagramas de software y procesos de negocio.
23
A pesar de la gran ventaja que representa el desarrollo de un sistema basado en modelos con la caracterización de algunos de estos sistemas se identificaron ciertas limitaciones lo cual hace de Génesis una solución más viable para algunas de estas dificultades; entre las que se encuentran: Muchos de estos sistemas solo cubren una parte del desarrollo del software ya que solo pueden utilizarse en las fases iniciales del desarrollo de los mismos, algunos de estos sistemas son por ejemplo Enterprise Architect, el cual es una herramienta comercial que se especializa en la gestión de requisitos pero solo se puede utilizar durante las fases de análisis y diseño.
No se encontraron sistemas que cumplan y se adapten satisfactoriamente a la arquitectura propuesta por Génesis, lo cual viene dado porque cada vez son más las herramientas MDA que se están desarrollando pero cada una de ellas define su propia arquitectura de trabajo.
Muchos de estos sistemas tienen un alto nivel de dependencia con la plataforma o arquitectura para la cual se cree, esto imposibilita la reutilización de los mismos para dar solución a problemáticas similares en un ambiente diferente.
La gran mayoría de los sistemas estudiados son comerciales, lo cual afecta directamente a nuestro país ya que no nos brinda las mismas posibilidades que aquellas que son de software libre, además de que muchos de estos sistemas limitan la reutilización de modelos mientas que otros presentan cierta dificultad para llevar a cabo integración de dichos modelos.(Ver Anexo # 2)
Con el estudio de estos sistemas se demuestra la necesidad de una herramienta para la creación de aplicaciones a partir de la definición de modelos, independientemente de la plataforma o arquitectura que se utilice para el desarrollo de la aplicación final, la misma deberá ser capaz de auxiliar a los desarrolladores durante proceso de desarrollo de software ahorrándose de esa manera parte del tiempo invertido en la gestión y creación de reglas de validación de datos para un sistema informático.
1.4 Metodologías, Tecnologías y Herramientas de desarrollo de software.
Las herramientas, tecnologías y metodologías utilizadas en el desarrollo del módulo fueron definidas a partir de las políticas establecidas por el Departamento de Soluciones Financieras del centro CEIGE;
es por tal motivo en este fragmento del capítulo no se definen dichas herramientas, sino que se realiza una resumida caracterización de cada una de ellas y de los beneficios que aportan en el trabajo de diseño e implementación del módulo Reglas del plugin Génesis.
24
Durante el desarrollo de software, muchas tareas y actividades se tornan engorrosas, trayendo esto consigo que el proceso de desarrollo de software se convierta en riesgoso, difícil de controlar y de no dársele un tratamiento correcto, lo que se obtiene son clientes insatisfechos con el resultado obtenido.La forma para solucionar o tratar de llevar a cabo un eficiente desarrollo es aplicando una metodología de desarrollo de software, que son un conjunto de pasos y procedimientos que deben seguirse para desarrollar software; indican quién debe hacer cada actividad, cuándo hacerla y qué debe hacer (Letelier, 2003). Para el desarrollo de Génesis como metodología se eligió el Proceso Unificado de Desarrollo (RUP), creado por la empresa Rational, que intenta asegurar la producción de software de alta calidad que satisfaga las necesidades de los usuarios finales. (Jacobson, y otros, 2000).
1.4.1 Rational Unified Process (RUP)
El proceso unificado de desarrollo (RUP) es una metodología para la ingeniería de software que va más allá del mero análisis y diseño orientado a objetos para proporcionar una familia de técnicas que soportan el ciclo completo de desarrollo de software. El resultado es un proceso basado en componentes, dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. Su principal objetivo es desarrollar software de alta calidad y que cumpla con los requisitos de los usuarios dentro de una planificación y presupuestos definidos. Actualmente es una de las metodologías de desarrollo de software más exitosa, según la Organización Internacional de Estándar (ISO siglas en inglés).
Características principales de RUP
"Centrado en la arquitectura: Los modelos son proyecciones del análisis y el diseño constituye la arquitectura del producto a desarrollar. [BAR05]"
"Centrado en los modelos: Los diagramas son un vehículo de comunicación más expresivo que las descripciones en lenguaje natural. Se trata de minimizar el uso de descripciones y especificaciones textuales del sistema. [BAR05]"
"Guiado por los Casos de Uso: Los Casos de Uso son el instrumento para validar la arquitectura del software y extraer los casos de prueba. [BAR05]"
25
"Iterativo e incremental: Durante todo el proceso de desarrollo se producen versiones incrementales (que se acercan al producto terminado) del producto en desarrollo. [BAR05]"RUP define cuatro fases para el desarrollo de un software:
Inicio: se define y delimita el proyecto.
Elaboración: su objetivo es obtener la arquitectura candidata del sistema.
Construcción: obtención del producto, apoyado en una fuerte documentación.
Transición: se alcanza el reléase del producto, listo para su instalación.
RUP también delimita el proceso de desarrollo en flujos de trabajo, por los cuales hay que transitar, al igual que por las fases, en cada iteración; pero particularmente los diferentes flujos de trabajo van a tener más peso en algunas etapas. (18) Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software.
1.4.2 Lenguaje de modelado
Los sistemas complejos son difíciles de entender si no se cuenta con un modelo que los describa. Un lenguaje de modelado es un lenguaje para especificar, construir, visualizar y documentar ingenios software. (34)
Lenguaje Unificado de Modelado (UML)
Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado, que permite modelar analizar y diseñar sistemas orientados a objetos. Es el lenguaje de modela de sistemas de software más conocido y utilizado en la actualidad (Jacobson Ivar, et al., 2000). Ofrece un estándar para describir un panorama del sistema modelo, incluyendo aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables y aspectos conceptuales como los procesos de negocios y funciones del sistema. UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. (35) El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas.
26
La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Es importante recalcar que UML no es una guía para realizar el análisis y diseño orientado a objetos, es decir, no es un proceso.1.4.3 Herramienta de modelado
Las herramientas de modelado asisten a los desarrolladores de software a construir los modelos. El objetivo principal de las herramientas de modelado es ocultar a los desarrolladores la sintaxis de los lenguajes de programación, y proveer una interfaz conveniente para que los desarrolladores especifiquen la gran cantidad de información que se almacena en los modelos. (36)
Visual Paradigm
El 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. La herramienta UML CASE también proporciona abundantes tutoriales de UML, demostraciones interactivas de UML y proyectos UML. (19) Debido a las funcionalidades brindadas por el Visual Paradigm al permitir crear diagramas usando las notaciones UML y BPMN13 y por ser una herramienta multiplataforma que se integra fácilmente con varios entornos de desarrollo integrado (IDEs), se decidió por parte del autor usarla como herramienta durante todo el proceso de modelado. Se utiliza el Visual Paradigm en su versión 3.6.
Herramienta Ecore
EMF14 es un marco de trabajo de Eclipse que unifica Java, XML y UML, permitiendo a los desarrolladores construir rápidamente aplicaciones robustas basadas en modelos simples. El metamodelo usado para representar modelos en EMF se llama Ecore. Ecore es en sí mismo, un metamodelo EMF, y así es su propio metamodelo, es decir, un metamodelo. (20) Se utiliza el Ecore en su versión 3.6.
13 BPMN: Business Process Modeling Notation (acrónimo inglés de Notación para el Modelado de Procesos de Negocio)
14 EMF: siglas del inglés Eclipse Modelling Framework (acrónimo inglés de Plataforma de Modelado de Eclipse)
27
Ecore es un subconjunto pequeño y simplificado de UML (se utiliza un subconjunto de UML en vez del mismo porque este es demasiado ambicioso modelando, más de lo que el núcleo de EMF puede soportar).Las herramientas de componente Ecore proporciona un completo entorno para crear, editar y mantener Ecore modelos. Este componente facilita la manipulación de los modelos Ecore con un editor gráfico y puentes a otras herramientas existentes Ecore (Emfatic, generadores...). La gráfica Ecore Editor implementa soporte multi-diagrama, una vista personalizada propiedades con fichas, comentarios de validación, las capacidades de refactorización. El objetivo a largo plazo es proporcionar el mismo nivel de servicios al igual que JDT para Java (21)1.5 Herramientas, Tecnologías y Lenguajes para el desarrollo de una aplicación.
Las herramientas de programación, son aquellas que permiten realizar aplicativos, programas, rutinas, utilitarios y sistemas para que la parte física del computador u ordenador, funcione y pueda producir resultados. En la actualidad existen múltiples herramientas de programación en el mercado, tanto para analistas expertos como para analistas inexpertos. Las herramientas de programación más comunes del mercado, cuentan hoy en día con programas de depuración, que permiten detectar los posibles errores en tiempo de ejecución o corrida de rutinas y programas.
1.5.1 Lenguaje de programación
El término lenguaje de programación está dado por un lenguaje que puede ser utilizado para controlar el comportamiento de una computadora. Consiste en un conjunto de símbolos y reglas sintácticas y semánticas que definen la estructura, el significado de sus elementos y expresiones.
Lenguajes del lado del cliente
Un lenguaje del lado cliente es totalmente independiente del servidor, lo cual permite que la página pueda ser albergada en cualquier sitio. El código, tanto del hipertexto como de los scripts, es accesible a cualquiera y ello puede afectar a la seguridad. (Torre, 2006)
XML
Es el metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Permite definir la gramática de lenguajes específicos. No es un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definición son XHTML, SVG, MathML.
28
Es un lenguaje muy similar a HTML pero su función principal es describir datos y no mostrarlos. XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. XML permite al programador y los soportes dedicar sus esfuerzos a las tareas importantes cuando trabaja con los datos, ya que algunas tareas tediosas como la validación de estos o el recorrido de las estructuras corre a cargo del lenguaje y está especificado por el estándar, de modo que el programador no tiene que preocuparse por ello. XML tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil.Lenguajes del lado del servidor
Los lenguajes de programación del lado servidor son aquellos lenguajes que son reconocidos, ejecutados e interpretados por el propio servidor y que se envían al cliente en un formato comprensible para él. (Torre, 2006)
Java
Java es un lenguaje de programación orientado a objetos, que permite a los programadores realizar aplicaciones de múltiples tipos, ya sean de escritorio o web. Se caracteriza por ser un lenguaje simple, robusto y poderoso que se torna fácil de aprender, debido a que elimina sentencias de bajo nivel además del Garbage Collector (Recolector de Basura) haciendo transparente para los programadores el manejo de la memoria. Se destaca por ser un lenguaje de código abierto, multiplataforma por lo cual ha logrado una gran expansión por todo el mundo. En la actualidad incluye un gran número de librerías para múltiples trabajos como: el trabajo con la red, tratamiento de excepciones, hilos para el procesamiento concurrente entre otras.
1.5.2 Entorno de Desarrollo Integrado (IDE)
Un ambiente o entorno de desarrollo integrado o IDE, es un programa compuesto por un conjunto de herramientas que proveen facilidades a los programadores para agilizar el proceso de desarrollo de software. Estos proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación, tales como, C++, C#, Java Object Pascal, Visual Basic, entre otros. (23)
29
Eclipse Helio (Versión 3.6)En noviembre de 1998, una de las transnacionales más grandes del mundo IBM15, otorgó la tarea a uno de sus grupos de desarrollo de software denominado Object Technology International (OTI16), de crear una plataforma de desarrollo común para confeccionar sus productos, basados en el lenguaje de programación Java, uno de los populares de ese momento. Fue así como surgió el denominado proyecto Eclipse. En la web oficial de Eclipse, el mismo se define como “una plataforma (IDE), abierta para todo y para nada en particular”. Eclipse es un plataforma porque no es una aplicación acabada de por sí, pero está diseñada para ser extendida indefinidamente con herramientas sofisticadas. El eclipse es un ambiente de desarrollo integrado (IDE) porque provee herramientas para administrar áreas de trabajo (o workspaces en inglés), para construir, lanzar y depurar aplicaciones, para compartir artefactos con un equipo y versionar el código fuente.
Eclipse es abierto porque su diseño le permite ser extendido fácilmente por terceras partes. Eclipse es un producto singular por la versatilidad que ofrece. Pero, ¿qué es lo que le permite a Eclipse tener estas características? Todo esto es posible debido a la poderosa arquitectura basada en plugins con el cual fue diseñado. (23) Se utiliza el Eclipse en su versión Helio 3.6.
Arquitectura de Eclipse
Cuando la plataforma Eclipse es un producto inigualable por su arquitectura madura, bien diseñada y extensible basada en plugins. (GALLARDO 2002) (Ver Figura_1)
Figura_ 1: Arquitectura de Eclipse para el desarrollo de plug-ins.
15IBM (International Business Machines): conocida coloquialmente como el Gigante Azul.
16 OTI (Object Technologies International): acrónimo ingles de Tecnologías de Objetos Internacional.
30
Bancos de trabajo e Interfaces de usuario (Workbench and UI Toolkits)La plataforma Eclipse construye la interfaz de usuario alrededor de una mesa de trabajo que proporciona la estructura general y presenta una interfaz de usuario extensible para el usuario. Debido a este papel central y definitorio, el banco de trabajo es sinónimo de la interfaz de usuario de la plataforma Eclipse en su conjunto.
El banco de trabajo de la API y la aplicación se construyen a partir de dos herramientas:
SWT: un conjunto de widgets y la biblioteca de gráficos integrados con el sistema de ventanas nativo, pero con un sistema operativo independiente de la API.
JFace: un conjunto de herramientas de interfaz de usuario en ejecución usando SWT que simplifica las tareas comunes de programación de la interfaz de usuario. (23)
1.6 Plugins
Plugins y puntos de extensión
Un plugin es la unidad más atómica y extensible de Eclipse. Está escrito puramente en el lenguaje de programación Java (Ver Figura_2) y típicamente consiste en código Java empaquetado en un archivo de Java (JAR17), con algunos archivos de solo lectura, y otros recursos como imágenes, catálogo de mensajes, etc.
Figura_ 2: Estructura simple de un plugin de Eclipse.
17 JAR: por sus siglas en inglés, Java ARchive es un tipo de archivo que permite ejecutar aplicaciones escritas en lenguaje Java.