DISEÑO DE UN METODO PARA LA CONSTRUCCIÓN DE SISTEMAS DE INFORMACIÓN BASADO EN EL PARADIGMA DE DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS

Transcripción

1 REPUBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA COORDINACION GENERAL DE INVESTICACION Y POSTGRADO MAESTRIA EN TECNOLOGIA DE LA INFORMACIÓN DISEÑO DE UN METODO PARA LA CONSTRUCCIÓN DE SISTEMAS DE INFORMACIÓN BASADO EN EL PARADIGMA DE DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS Trabajo de Grado para optar al Grado de Magíster en Tecnología de la Información. Autor: Ing. Luis Antonio Milano Bermúdez. Tutor: Ing. Mauricio Paletta Mcs. Puerto Ordaz, Marzo de 2009

2 APROBACIÓN DEL TUTOR En mi carácter de tutor del Trabajo de grado presentado intitulado DISEÑO DE UN METODO PARA LA CONSTRUCCIÓN DE SISTEMAS DE INFORMACIÓN BASADO EN EL PARADIGMA DE DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS por el ciudadano Luis Antonio Milano Bermúdez, para optar al Grado de Magíster en Tecnología de la Información, considero que dicho trabajo reúne los requisitos y meritos suficientes para ser sometido a la aprobación pública y evaluación por parte del jurado examinador que se designe. En la ciudad de Puerto Ordaz, a los 17 días de mes de Marzo de ii

3 iii

4 INDICE GENERAL LISTA DE FIGURAS... VII LISTA DE CUADROS... XII RESUMEN...XIII INTRODUCCIÓN...1 CAPITULO I EL PROBLEMA DE INVESTIGACION...3 1) PLANTEAMIENTO DEL PROBLEMA...3 2) OBJETIVOS DE LA INVESTIGACIÓN ) Objetivo General ) Objetivos específicos...5 3) JUSTIFICACIÓN DE LA INVESTIGACIÓN...5 II ESTADO DEL ARTE ) METODOLOGÍAS DE DESARROLLO DE SISTEMAS BASADAS EN LOS PARADIGMAS DE LA ORIENTACIÓN A OBJETOS Y MODELOS ) OO-Method y OO-Hmethod ) Objectory ) Object Oriented Design ) OMT ) RUP ) METODOLOGÍAS DE DESARROLLO DE SISTEMAS BASADAS EN LOS ESQUEMAS TRADICIONALES ) Ciclo de vida de un Sistema de Información ) Metodología Estructurada para Desarrollar Sistemas de Información (MEDSI) ) MÉTRICA Versión iv

5 3) METODOLOGÍAS DE DESARROLLO DE SISTEMAS BASADOS EN EL PARADIGMA DE LAS METODOLOGÍAS AGILES ) Extreme Programing (Xp) ) Scrum ) Crystal Methodologies ) Dynamic Systems Development Method (DSDM) ) Adaptive Software Development (ASD) ) Feature-Driven Development (FDD) ) Lean Development (LD) ) HERRAMIENTAS OPERATIVAS BAJO EL PARADIGMA MDA ) CONCLUSIONES DEL ESTADO DEL ARTE...29 III MARCO TEORICO ) INTRODUCCIÓN A MDA FUNDAMENTOS DE MDA ) Meta-modelos y MOF Nivel M Nivel M Nivel M Nivel M ) Conceptos básicos de MDA Características de UML La especificación de UML ) Modelo Conceptual de UML ) Reglas de UML ) Mecanismos comunes en UML ) Mecanismos de extensibilidad: ) Técnicas de definir lenguajes de modelado ) Estereotipos y Valores Etiquetados ) El uso de marcas...67 v

6 4.10) Perfiles ) METADATA INTERCHANGE (XMI) ) FUNDAMENTOS DE OCL ) VT (QUERY/VIEW/TRANSFORMATION) ) DESARROLLO DE SOFTWARE ÁGIL ) MÉTODOS ÁGILES DE DESARROLLO DE SOFTWARE IV MARCO METODOLOGICO ) DISEÑO DEL ESTUDIO ) TIPO DE ESTUDIO ) PROCEDIMIENTOS PARA RECOLECTAR LA INFORMACIÓN ) TÉCNICA PARA EL PROCESAMIENTO Y ANÁLISIS DE LA INFORMACIÓN V MDA-UNEG INTRODUCCIÓN ) CARACTERÍSTICAS DE MDA-UNEG ) CICLO DE VIDA GENERAL DE MDA-UNEG ) DESCRIPCIÓN DEL CICLO DE VIDA DE MDA-UNEG ) Fase I: CIM: ) Fase II: PIM ) Fase III: Validación y Verificación ) Fase IV: PSM ) Fase V: Generación de Código ) Fase VI: Pruebas del Sistema ) EVALUACION DE MDA-UNEG VI CONCLUSIONES Y APORTES DE LA INVESTIGACION CONCLUSIONES APORTES DE LA INVESTIGACION REFERENCIAS BIBLIOGRAFICAS ANEXO vi

7 LISTA DE FIGURAS Figura pp. 1 Herramientas requeridas en un ambiente MDA 26 2 Pasos en el desarrollo con Visión alternativa de MDA 32 3 Visión alternativa de MDA 33 4 Ejemplo de Meta-modelo 35 5 Instancia del meta-modelo de la Figura Ejemplo de Nivel M Escenario de utilización de MDA Proceso de transformación en MDA 43 9 Figura de una clase Ejemplo de una interfaz Ejemplo de colaboración Ejemplo de caso de uso Ejemplo de clase activa Ejemplo de componente Ejemplo de Nodo Ejemplo de Interacción Ejemplo de estado Ejemplo de Paquete Ejemplo de una nota Representación de la relación de dependencia Ejemplo de una relación de asociación Ejemplo de una relación de generalización Ejemplo de una relación de realización Diagrama de Clases Diagrama de Objetos Diagrama de Casos de Usos 59 vii

8 27 Diagrama de Secuencia Diagrama de Colaboración Diagrama de Estados Diagrama de Actividades Diagrama de Componentes Diagrama de Despliegue Adornos de la definición de una clase División entre clases y objetos División entre interfaz e implementación Ejemplo de estereotipo y valor etiquetado de un perfil UML Valor etiquetado asociado a una metaclase Relación Curso/Asignaturas Implementación de Alumno Costo del cambio tradicional en ingeniería del software Costo del cambio en Xp Evolución de los ciclos de desarrollo Ciclo de vida del Método MDA-UNEG Proceso de transformación de modelos en MDA Generación de Código Multiplataforma Etapas del Modelado Independiente de la Computación Representación Gráfica de un Diagrama de Roles Representación de un Diagrama de Clases Etapas de la Verificación y Validación Caso de Estudio: Árbol de refinamiento de funciones de Alquiler 137 de vehículos 51 Caso de Estudio: Diagrama de casos de uso general Caso de Estudio: Diagrama de caso de uso de Gestión de vehículos Caso de Estudio: Diagrama de casos de uso de Gestión de tarifas Caso de Estudio: Diagrama de casos de uso de Gestión de garaje Caso de Estudio: Diagrama de casos de uso para la gestión de 141 viii

9 seguros. 56 Caso de Estudio: Diagrama de casos de uso sobre la gestión de 141 compañía de seguro 57 Caso de Estudio: Diagrama de casos de uso de gestión de 142 Operaciones 58 Caso de Estudio: Diagrama de casos de uso de gestión de clientes Caso de Estudio: Diagrama de casos de uso de gestión de contratos Caso de Estudio: Diagrama de casos de uso sobre la gestión de 143 extras 61 Caso de Estudio: Diagrama de casos de uso sobre la gestión de 144 usuarios 62 Caso de Estudio: Diagrama de secuencia asociado al escenario de 145 compra de Vehículo 63 Caso de Estudio: Diagrama de secuencia asociado al escenario de 146 venta de Vehículo 64 Caso de Estudio: Diagrama de secuencia asociado al escenario de 148 entrega de Vehículo 65 Caso de Estudio: Diagrama de secuencia asociado al escenario de 149 creación de tarifa 66 Caso de Estudio: Diagrama de secuencia asociado al escenario de 149 eliminación de tarifa 67 Caso de Estudio: Diagrama de secuencia asociado al escenario de 150 modificación de tarifa 68 Caso de Estudio: Diagrama de secuencia asociado al escenario de 151 creación de garaje 69 Caso de Estudio: Diagrama de secuencia asociado al escenario de 152 eliminación de garaje 70 Caso de Estudio: Diagrama de secuencia asociado al escenario de 153 modificación de garaje 71 Caso de Estudio: Diagrama de secuencia asociado al escenario de 154 ix

10 creación de seguro 72 Caso de Estudio: Diagrama de secuencia asociado al escenario de 154 eliminación de seguro 73 Caso de Estudio: Diagrama de secuencia asociado al escenario de 155 modificación de seguro 74 Caso de Estudio: Diagrama de secuencia asociado al escenario de 155 creación de compañía de seguro 75 Caso de Estudio: Diagrama de secuencia asociado al escenario de 156 eliminación de compañía de seguro 76 Caso de Estudio: Diagrama de secuencia asociado al escenario de 156 modificación de compañía de seguro 77 Caso de Estudio: Diagrama de secuencia asociado al escenario de 158 creación de operación 78 Caso de Estudio: Diagrama de secuencia asociado al escenario de 158 des-habilitación de vehículo 79 Caso de Estudio: Diagrama de secuencia asociado al escenario de 159 habilitación de vehículo 80 Caso de Estudio: Diagrama de secuencia asociado al escenario 160 eliminación de operación 81 Caso de Estudio: Diagrama de secuencia asociado al escenario 160 finalización de operación 82 Caso de Estudio: Diagrama de secuencia asociado al escenario 161 creación de cliente 83 Caso de Estudio: Diagrama de secuencia asociado al escenario 162 eliminación de cliente 84 Caso de Estudio: Diagrama de secuencia asociado al escenario 162 modificación de cliente 85 Caso de Estudio: Diagrama de secuencia asociado al escenario 163 alquiler de vehículo 86 Caso de Estudio: Diagrama de secuencia asociado al escenario 164 x

11 modificación de un contrato 87 Caso de Estudio: Diagrama de secuencia asociado al escenario devolución de vehículos 88 Caso de Estudio: Diagrama de secuencia asociado al escenario de creación de tipo extra 89 Caso de Estudio: Diagrama de secuencia asociado al escenario de eliminación de tipo extra 90 Caso de Estudio: Diagrama de secuencia asociado al escenario de modificación de tipo extra 91 Caso de Estudio: Diagrama de secuencia asociado al escenario de asignación de extras 92 Caso de Estudio: Diagrama de secuencia asociado al escenario de creación de usuarios 93 Caso de Estudio: Diagrama de secuencia asociado al escenario de eliminación de usuarios 94 Caso de Estudio: Diagrama de secuencia asociado al escenario de modificación de usuarios 95 Caso de Estudio: Diagrama de secuencia asociado al escenario de ascenso de usuarios 96 Caso de Estudio: Diagrama de secuencia asociado al escenario destruir administrador xi

12 LISTA DE CUADROS Cuadro pp. 1 Características de los métodos Ágiles 80 2 Aspectos comunes y diferenciadores entre los procesos 96 dirigidos por modelos y los procesos ágiles 3 Definición de características de la Método MDA-UNEG 97 4 Caso de Estudio: Plantilla correspondiente a los datos de un 132 Vehículo 5 Caso de Estudio: Plantilla correspondiente a las tarifas asociadas a un Vehículo 135 xii

13 REPUBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL EXPERIMENTAL DE GUAYANA COORDINACION GENERAL DE INVESTICACION Y POSTGRADO MAESTRIA EN TECNOLOGIA DE LA INFORMACIÓN DISEÑO DE UN METODO PARA LA CONSTRUCCIÓN DE SISTEMAS DE INFORMACIÓN BASADO EN EL PARADIGMA DE DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS Autor: Ing. Luis Antonio Milano Bermúdez. Tutor: Ing. Mauricio Paletta Mcs. Fecha: Marzo de 2009 RESUMEN Desarrollar un buen software depende de un sin número de actividades y etapas, donde el impacto de elegir la mejor metodología para un equipo en un determinado proyecto, es trascendental para el éxito del producto. El papel preponderante de las metodologías es sin duda esencial en un proyecto y el paso inicial, que debe encajar en el equipo, guiar y organizar actividades que conlleven a las metas trazadas en el grupo. La especificación MDA (de sus siglas en inglés Model Driven Architecture), es una especialización del desarrollo dirigido por modelos que separa la lógica del xiii

14 negocio del software y las plataformas tecnológicas. Para ello MDA define tres tipos de modelos: 1) los CIM (de sus siglas en inglés Computation Independent Model), asociados al dominio del negocio; 2) los PIM (de sus siglas en inglés Platform Independent Model), asociados a modelos abstractos del software, y 3) los PSM (de sus siglas en inglés Platform Specific Model), relacionados con modelos de software específicos de plataformas tecnológicas. Si bien MDA es muy utilizado hoy en día para el desarrollo de modelos, tiene como limitación el hecho que no detalla cómo deben ser los modelos CIM y tampoco describe cómo éstos deben ser transformados a modelos PIM, dejando así un vacío en relación a estos dos aspectos, razón por la cual, los usuarios de MDA deben decidir qué camino seguir para cumplir con estas necesidades. En este sentido, sería útil contar con especificaciones claras y completas que permitan a los desarrolladores de software hacer mejor uso de MDA. Como solución a dicho problema, este trabajo de investigación presenta una recomendación que propone un proceso de desarrollo de software basado en la creación de modelos de procesos del negocio, clasificados como CIM, que son asociados a los modelos iniciales del software, considerados PIM. Partiendo de una interpretación válida de MDA, la recomendación propuesta se apoya además, en la aplicación de otras disciplinas de gran actualidad, como es el caso del desarrollo ágil de software para la definición adecuada de los procesos del negocio. Descriptores: Model Driven Architecture (MDA), Computation Independent Model (CIM), Platform Independent Model (PIM), desarrollo ágil de software. xiv

15 INTRODUCCIÓN Tradicionalmente, el desarrollo de los sistemas de información en las empresas se ha centrado fundamentalmente en el conocimiento de las tecnologías de desarrollo existentes en el mercado. Esta realidad se hace mas inadecuada cada día, puesto que dicho enfoque demanda un fuerte conocimiento de la tecnología actual, dejando en segundo plano lo que realmente importa y que debe ser el centro de atención de cualquier desarrollo, que no es otra cosa que el conocimiento del entorno de la actividad o negocio. El trabajo que se presenta en el desarrollo de esta investigación se centra en desarrollar un método que guíe el desarrollo de software mediante un nuevo paradigma conocido en el mundo de la informática como MDA (de sus siglas en inglés Model Driven Architecture). Esta propuesta, identificada con el nombre de MDA-UNEG, se basa, en primer lugar, en la recolección de experiencias metodológicas tradicionales de desarrollo de software, adaptadas al paradigma de construcción de sistemas basados en modelos. En segundo lugar, MDA-UNEG se basa en la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente/usuario y al desarrollo incremental del software con iteraciones muy cortas. En el mundo de la informática, este enfoque ha venido mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo; pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. MDA es una iniciativa de modelado de software propuesta por la OMG (de sus siglas en inglés Object Management Group) que pretende dar un viraje significativo en el desarrollo de sistemas. El principal objetivo de este paradigma es

16 el de separar la especificación de la funcionalidad de un sistema de su implementación en una plataforma tecnológica especifica. En este escrito se presenta resumidamente, el contexto en el que surgen dos nuevos paradigmas informáticos que son, el desarrollo de software guiados por modelos y el uso metodologías ágiles para desarrollo de software. Para efectos de presentación del presente trabajo de investigación se ha tomado como referencia primaria el Manual de Tesis de la UPEL, sin embargo, por razones didácticas, el autor ha considerado conveniente introducir un capitulo adicional denominado Estado del Arte, en el que se describirá la situación actual de los temas centrales relacionados directamente con la tema desarrollado. Este documento se ha estructurado de la siguiente manera: en el capítulo I se presenta el planteamiento del problema, así como los objetivos (generales y específicos), además de la justificación y alcance de la idea proyecto; en el capítulo II se describe y analiza un conjunto de metodologías tradicionales utilizadas para el desarrollo de software; el capítulo III presenta el marco teórico de los temas relacionados con la propuesta; en el capítulo IV se presenta el Marco Metodológico utilizado para el desarrollo de la investigación y finalmente en el capitulo V se presenta los resultados de la Investigación. 2

17 CAPITULO I EL PROBLEMA DE INVESTIGACION 1) Planteamiento del Problema En los últimos años, las notaciones de modelado y posteriormente las herramientas de desarrollo, pretendieron ser los elementos fundamentales para el éxito en la construcción de software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento, la metodología de desarrollo, había sido postergada. De nada sirven buenas notaciones y herramientas si no se proveen directivas para su aplicación. Es por ello que en el mundo de la informática se ha comenzado con un creciente interés en metodologías de desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociado un marcado énfasis en el control del proceso mediante una rigurosa definición de roles y actividades, incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante y en donde se exige reducir drásticamente los tiempos de desarrollo, pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniería del software, asumiendo el riesgo que esto conlleva.

18 En este escenario, se propone la construcción de un hibrido metodológico entre los paradigmas de MDA y metodologías ágiles como una posible respuesta para llenar este vacío metodológico. La propuesta expresada en este trabajo, la cual se ha identificado con el nombre de MDA-UNEG, representa una solución a la medida, aportando una elevada simplificación que, a pesar de ello, no renuncia a las prácticas esenciales para asegurar la calidad del producto. La plataforma usada como base para la construcción de la propuesta MDA- UNEG (MDA y metodologías ágiles) es sin duda uno de los temas recientes en ingeniería de software que están acaparando gran interés. Prueba de ello, es que se están haciendo un espacio destacado en la mayoría de conferencias y workshops 1 celebrados en los últimos años. Además, ya es un área con cabida en prestigiosas revistas internacionales. En la comunidad de la ingeniería del software se está viviendo con intensidad un debate abierto entre los partidarios de las metodologías tradicionales (referidas peyorativamente como "metodologías pesadas") y aquellos que apoyan las ideas emanadas del "Manifiesto Ágil"; siendo esta última, eje fundamental sobre la que se apoya la propuesta presentada en este trabajo. 2) Objetivos de la Investigación 2.1) Objetivo General Diseñar un método completo y detallado para el desarrollo de Software basado principalmente en el paradigma del MDA, que sirva como referencia para la divulgación del tema en la Universidad Nacional Experimental de Guayana. 1 NOVATICA (Revista de la asociación de los técnicos de Informática - España); I Taller sobre desarrollos dirigidos por Modelos y sus aplicaciones (España-2004).

19 2.2) Objetivos específicos 1. Establecer un vocabulario básico que refleje la integración de los conceptos de desarrollo dirigido por modelos, metodologías ágiles y sistemas de información. 2. Identificar y evaluar las metodologías tradicionales de desarrollo de sistemas, a fin de adaptar los conceptos que apliquen para construir sistemas, basados en el paradigma de la orientación por modelos. 3. Definir los modelos, prácticas, recursos y roles que se deben considerar al realizar el análisis, diseño y desarrollo de un sistema, basado en el paradigma de la orientación por modelos. 4. Diseñar un modelo de ciclo de vida de los sistemas basados en el paradigma de la orientación por modelos. 5. Evaluar el método propuesta en función a los lineamientos establecidos por la Ingeniería del Software. 3) Justificación de la Investigación La principal motivación para realizar este trabajo de investigación es contribuir a la investigación de cuáles son las guías, los métodos y los procesos para desarrollar sistemas mediante el paradigma de orientación por modelos. En el tema específico de metodologías para sistemas basados en modelos existe muy poca información en la comunidad científica, por lo que se considera muy importante que los resultados que se obtengan en este trabajo contribuyan positivamente en este campo, lo que redundará en el fortalecimiento del conocimiento que se tiene al respecto y en la ampliación de la aplicación de este nuevo enfoque de desarrollo, haciendo que cada vez más se difunda este tipo de tecnología. Para reforzar el punto anterior, referido a la carencia de metodologías unificadas y completas que atiendan el desarrollo de software mediante la orientación por modelos, es relevante tener en cuenta lo citado por Reina en [1]: El enfoque orientado a aspectos ha demostrado ser una tecnología potente para manejar la separación de propiedades. 5

20 Esta separación de propiedades permite la construcción de software con una mayor modularidad, facilitando su reusabilidad, fiabilidad, mantenimiento y evolución. El principal problema para la adopción de estas técnicas en proyectos de gran escala es la falta de un proceso claro de desarrollo orientado a aspectos. Hasta ahora la identificación, especificación e implementación de los aspectos la realizaban los programadores, principalmente ad-hoc, en la fase de implementación, viéndose obligados a rediseñar el sistema. Al no disponer de metodologías de desarrollo suficientemente maduras los desarrolladores ven dificultada su tarea al ser sobrecargados con nuevas funciones. En el desarrollo de software dirigido por modelos (DSDM) los modelos ya no son simples medios para describir software, sino la pieza fundamental de su desarrollo. Los modelos existentes en una fase (análisis, diseño, etc.) se transforman (automática, semi-automáticamente o anualmente) sucesivamente hasta derivar la aplicación (pp. 7 8 ). Es importante resaltar que la importancia de utilizar una metodología radica en el hecho que si ésta se aplica cuidadosamente, hay una probabilidad muy alta de éxito en la realización del sistema informático y en la puesta en marcha del mismo. Esta propone analizar los siguientes aspectos referidos a las metodologías existentes para crear software, en tal sentido y a fin de determinar la idoneidad de las metodologías existentes, planteo las siguientes interrogantes: 1. Existen metodologías con amplia cobertura que sean específicas para las necesidades y desarrollos actuales? Son apropiadas? 2. Las metodologías existentes en el mercado para desarrollar software son consecuentes con lo que debe ser una buena metodología para crear las aplicaciones demandadas en la actualidad?. 3. Al elegir una metodología existente qué cambios hay que hacerle para que permita lograr un buen análisis y diseño de un sistema? A fin de utilizar argumentos técnicos que justifiquen la pertinencia de la propuesta presentada en este escrito, a continuación se presentan las fases sugeridas por las metodologías tradicionales para el desarrollo de software: 6

21 1. Determinación y recogida de requerimientos. 2. Análisis. 3. Diseño. 4. Codificación. 5. Pruebas. 6. Implementación. Aún y cuando desde el punto de vista técnico, las fases señaladas anteriormente (propuestas por las metodologías tradicionales), siguen un orden indiscutiblemente lógico para el desarrollo de un sistema de información, de las mismas se pueden identificar los siguientes problemas: 1. Productividad: El proceso tradicional produce una gran cantidad de documentos y diagramas para especificar requisitos, clases y colaboraciones; la mayoría de estos documentos pierden su valor cuando se comienza la fase de programación y gradualmente se va perdiendo la relación entre los diagramas. Más aún cuando el sistema cambia a lo largo del tiempo ya que, realizar cambios en todos los documentos utilizados se hace inmanejable; así que, por lo regular, los cambios solo se hacen en el código. Ante este planteamiento cabría preguntarse, es conveniente gastar tanto tiempo en construir diagramas y documentos de alto nivel? 2. Portabilidad: En la industria del software, cada año aparecen nuevas tecnologías y las empresas necesitan adaptarse a ellas, bien porque la demanda de esa tecnología es alta o bien porque realmente es una tecnología que resuelve problemas importantes. Esto trae como consecuencia que el software existente debe adaptarse o migrar a la nueva tecnología. 3. Mantenimiento y documentación: Regularmente, documentar un sistema requiere mucho tiempo y no interesa tanto a los que desarrollan el nuevo software, sino a aquellos que lo modificarán más adelante. Esta situación provoca que no se ponga mucho empeño en la 7

22 documentación y que generalmente no tenga buena calidad. La solución a este problema es que la documentación se genere directamente del código fuente, asegurándonos que este siempre esté actualizado. Así mismo, en contraposición a los problemas identificados en las metodologías tradicionales durante el proceso de desarrollo de software, según Kleppe [3], las metodologías orientadas por modelos han logrado resolver de manera exitosa dichas dificultades; a saber: : 1. Productividad: El desarrollo mediante el paradigma del MDA recae sobre el PIM. Los PSM se generan automáticamente a partir del PIM. Otra de las tareas fundamentales de este enfoque es el de definir las transformaciones exactas entre los modelos. Una vez que estas transformaciones son validadas e implementadas, se pueden usar en muchos desarrollos. Mediante este enfoque se aíslan los problemas específicos de cada plataforma y se hace más énfasis en los usuarios finales. 2. Portabilidad: En el enfoque de desarrollo dirigido por modelos, la portabilidad se logra enfocando el desarrollo sobre el PIM. Al ser éste un modelo independiente de la plataforma, todo lo definido en él es portable. 3. Mantenimiento y Documentación: Mediante el paradigma MDA, a partir del PIM se obtienen los PSM y a partir de los PMS se obtiene el código. Básicamente, el PIM desempeña el papel de la documentación que se necesita en cualquier desarrollo de software. Es importante señalar que bajo este paradigma, el PIM nunca se abandona tras la codificación. Los cambios realizados en el sistema se reflejaran en todos los niveles mediante la generación de los PSM y el código. Todo lo anterior conforma el planteamiento del problema, objetivos y justificación de la investigación, que se trata como un capítulo completo dentro de este documento, con objetivos muy precisos y que tiene sus propias conclusiones y referencias pertinentes para cada tema; pero, dentro del mismo, se 8

23 considera relevante acordar lo que se entiende por los términos: metodología, método, proceso de desarrollo de software, entre otros conceptos que se trabajan apropiadamente desde la Ingeniería del Software. Es importante también aclarar que, no se pretende construir una ontología para ello, sino simplemente definir lo que se entenderá cada vez que se presente uno de estos términos en este trabajo de investigación, teniendo como eje central los planteamientos de la Ingeniería del Software, por ser ésta la encargada en la Informática de proponer los conceptos relacionados con el proceso de desarrollo del software. Partiendo de lo que la Real Académica de la Lengua Española define en su diccionario de 1992, las palabras metodología y método se han definido de la siguiente forma: Metodología: 1. Ciencia del método. 2. Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal. Método: 1. Modo de decir o hacer con un orden una cosa. 2. Modo de obrar o de proceder, hábito o costumbre que cada uno tiene y observa. 3. Procedimiento que se sigue en las ciencias para hallar la verdad y enseñarla. Puede ser analítico o sintético. Si estos conceptos se trasladan al campo de la Ingeniería del Software, entonces vemos que éstos han sido utilizados en diferentes formas, sin ningún criterio. Por ejemplo, el concepto metodología es relacionado por algunos como la secuencia de actividades que se deben realizar para construir un sistema de software. Otros autores se refieren a la disciplina que estudia los métodos para hacer sistemas de software. En este último caso no hay diferencia con la definición de la Real Academia Española (RAE), sólo que para utilizarla adecuadamente se requiere especificar la connotación que se le va a dar. 9

24 Por esto, a continuación se presentan algunas definiciones relevantes. De acuerdo con los autores en [4] la palabra metodología literalmente significa el estudio de los métodos (p. 525). Sin embargo, se utiliza comúnmente como un enfoque para llevar a cabo una tarea. Por tanto, se puede hablar que, para cada una de las etapas del desarrollo del software se tienen una o varias metodologías como por ejemplo: metodologías para el análisis, metodologías para el diseño, metodologías para las pruebas, metodologías para la administración del proyecto, entre otras. Además, estos autores dicen que la metodología es una colección que debe tener 3 elementos: 1. Un lenguaje de modelado, 2. Unas heurísticas para modelar y 3. Un marco de trabajo para organizar y ejecutar el trabajo de desarrollo. Es decir que, para los autores, una metodología sin alguno de esos elementos, no es una metodología. En [5], se especifica el concepto de metodología desde el punto de vista del software diciendo que, una metodología de software es una manera de trabajar que reúne el conjunto de información, datos o elementos en un repositorio (p. 20). Por tanto, es un instrumento que permite reducir o disminuir la complejidad en la solución de un problema cuando se está tratando de resolver por medio de un sistema computarizado. Así mismo, para los autores en [6], una metodología puede definirse, en un sentido amplio, como un conjunto de métodos o técnicas que ayudan en el desarrollo de un producto de software. Sus principales actividades son: 1. La definición y descripción del problema que se desea resolver. 2. El diseño y descripción de una solución que se ajuste a las necesidades del usuario. 3. La construcción de la solución. 4. La prueba de la solución implementada (p. 224). 10

25 En [7] no se define exactamente lo que es una metodología, pero si se especifica lo que ella debe comprender. Así, dice que una metodología consiste de varias partes: 1. Un marco semántico, 2. Un esquema notacional, 3. Una serie de actividades de trabajo secuenciales y, 4. Un conjunto de componentes de trabajo para entregar. Juntos, el marco de semántico y el esquema notacional comprenden el Lenguaje de Modelado. El proceso de desarrollo describe las actividades que dirigen el uso de los elementos del lenguaje y el conjunto de componentes de diseño que resultan de la aplicación de éstos en una secuencia definida de actividades. (p. 749). Por otro lado, según los autores en [8], se utiliza el término proceso de software y se define de la siguiente forma: El proceso de software es la secuencia de pasos que se requiere para desarrollar un nuevo software o para hacerle mantenimiento a uno existente. Agrupa las consideraciones técnicas y administrativas para aplicar métodos, herramientas y personas a la tarea del software. La definición de un proceso de software es la descripción del proceso mismo, identificando los roles y las tareas específicas para hacer. (p. 20). Las anteriores, son sólo algunas percepciones que se encontraron al respecto, y dado que hay grandes diferencias entre algunas de ellas, se ha considerado en esta investigación que es muy importante mantener las bases planteadas en la Ingeniería del Software, con el vocabulario que se maneja en ese contexto, siguiendo un poco lo que se propone en FRISCO (por sus siglas en ingles A Framework of Information Systems Concepts) [9]. De acuerdo a lo anterior, la forma más adecuada de definir una metodología es la siguiente: Una metodología es un conjunto de métodos, prácticas, estilos, recursos y conocimientos que permiten desarrollar de una manera efectiva y eficiente cada 11

26 una de las actividades que son necesarias para analizar, diseñar, producir, implantar y mantener un sistema u artefacto cualquiera. El concepto artefacto se refiere a cualquier documento o software que se produce durante todos los procesos que se realizan, desde que se estudia el problema hasta que la solución informática se implanta. Es así como en una metodología de software se debe indicar: 1. Qué es lo que se debe hacer, cuáles son las actividades específicas que se deben realizar? - Etapas. 2. Cuál es el orden de realización de dichas etapas, cuándo se tienen que hacer las actividades? - Ciclo de Vida. 3. Cuáles son las herramientas, conocimientos y utilidades para realizar las etapas? - Métodos. 4. Quiénes son los responsables de proporcionar las especificaciones, de hacer el análisis del problema y de proponer la mejor solución? Quiénes son los responsables de hacer el sistema informático? Es decir, quién hace cada actividad y qué hacen en el ciclo de vida? - Los roles y responsabilidades al realizar una actividad. 5. Qué se va a obtener al realizar una etapa y al finalizar el proyecto, qué se necesita obtener para solucionar o cambiar la situación actual? Los artefactos: resultados, documentos y el software. 6. Cuáles son las guías que se van a utilizar para la toma de decisiones en cada una de las etapas? - Los mecanismos de decisión. En cuanto a la palabra método, se ha considerado conveniente adoptar la siguiente definición: Un método es una serie de pasos a seguir para llevar a cabo una determinada etapa del ciclo de vida de desarrollo de software (por ejemplo: para elaborar el análisis). 12

27 Por último, es importante también definir el concepto modelo, ya que la metodología que se propone - MDA-UNEG - y sus consideraciones metodológicas, están fundamentadas en la construcción de modelos. Según los autores en [10], un modelo es una abstracción de un sistema físico, con un propósito que determina qué es lo que debe ser incluido en el modelo y qué es irrelevante. Es decir, que el modelo describe los aspectos importantes del sistema físico, para su propósito. Hay varios aspectos importantes relacionados con este concepto: 1. Un modelo sólo es una aproximación a la realidad y el nivel de detalle que debe tener es determinado por su propósito. 2. Para un mismo sistema físico, es posible definir diversos modelos, de acuerdo con el punto de vista y el nivel de abstracción que se quiera resaltar, es decir, el proceso de modelado es dependiente de las interpretaciones subjetivas del modelador y por eso se requiere que haya una confrontación con la realidad. 3. En [11], los autores indican que el proceso de modelado es un proceso cíclico, así que nuevas observaciones pueden dirigir el refinamiento, la modificación o complementación de un modelo ya construido. 13

28 CAPITULO II ESTADO DEL ARTE Como fundamento de investigación para este trabajo, se parte del estudio de una serie de tecnologías claves para el planeamiento de las consideraciones metodológicas que permiten guiar el desarrollo de Sistemas de Información y que servirán como punto de partida para el desarrollo de esta investigación. Entre los temas relevantes asociados al presente trabajo se encuentran los siguientes: Metodologías de desarrollo de Sistemas basadas en los paradigmas de orientación a Objetos. Metodologías de desarrollo de Sistemas basadas en los esquemas tradicionales. Metodologías de desarrollo de Sistemas basadas en el paradigma de las metodologías Ágiles. Herramientas operativas bajo del Paradigma MDA 1) Metodologías de desarrollo de Sistemas basadas en los paradigmas de la orientación a Objetos y Modelos. 1.1) OO-Method y OO-Hmethod: OO-Method [13] es un método orientado a objetos desarrollado en la Universidad Politécnica de Valencia que fusiona el uso de un lenguaje de especificación formal (OASIS [14]) con una notación gráfica tomada de los estándares más usados. Esta aproximación aprovecha las buenas propiedades de los lenguajes de especificación formales con la experiencia acumulada de los métodos habitualmente usados en contextos de producción industrial de software.

29 La metodología OO-Method ha evolucionado en los últimos trabajos en OOH- Method [15]. Ésta no es más que una ampliación de OO-Method en la que se añade un nuevo modelo para representar la interoperabilidad con los usuarios en sistemas Web. Los principios básicos de OO-Method se concretan en que permite dar soporte a las nociones de modelización conceptual orientado a objetos y usar conceptos de lenguajes de especificación formales y orientados a objetos. Además, OO-Method posee un avanzado entorno de prototipación automática que incluye tanto la generación automática de una especificación formal y orientada a objetos en OASIS, como la prototipación funcional equivalente al modelo conceptual y la generación completa de código en entornos imperativos como Visual C++ o Delphi. OO-Method es una técnica bastante adecuada y que cada día está teniendo mayor influencia en el campo del desarrollo de aplicaciones Web. Ofrece una importante herramienta Web cuyos esfuerzos de elaboración son muy loables. Sin embargo, OO-Method no aborda tareas como la especificación de requisitos y vuelve a ser una metodología orientada casi en su totalidad a la fase de diseño e implementación. 1.2) Objectory [16]: Es una metodología basada en el paradigma de orientación a objetos, creada por la compañía Objectory Systems, fundada en 1987 por Jacobson. Es una extensión de lo que se conoce como Método Ericsson, un lenguaje de modelado de objetos creado por la compañía Ericsson. Es un proceso organizado para la construcción industrial de software. Este proceso de diseño está guiado por casos de uso, una técnica que se centra en el entendimiento de un sistema en la forma en la cual éste es usado.

30 1. Modelo de Casos de Uso: Se basa en la descripción de elementos o usuarios externos al sistema (actores) y funcionalidad del sistema (casos de uso). 2. Modelo de objetos: Representa la estructura estática de objetos. Puede contener objetos entidad, de interfaz y de control, entre otros tipos; y relaciones de herencia. 3. Diagrama de interacción. Muestran la secuencia de eventos entre paquetes u objetos necesarios para realizar un caso de uso. 4. Diagrama de estado. Muestra los estados internos de un objeto complejo. Algunos de los conceptos más importantes de esta metodología son: 1. Objeto Entidad. Representa información del sistema que debe sobrevivir cierto período de tiempo, por ejemplo, un caso de uso. 2. Objeto de Interfaz. Modela información y comportamiento que es dependiente de la interfaz actual del sistema. 3. Objeto de Control. Modela funcionalidad que no corresponde a ningún objeto en particular y que se presenta en algunos casos de uso. Estos objetos generalmente operan sobre varios objetos entidad, realizan algún algoritmo y retornan algún resultado a un objeto de interfaz. 4. Paquete. Módulo que contiene código, traducible a un módulo en el lenguaje de implementación. 5. Unidad. En pruebas, desde una clase hasta un subsistema. 1.3) Object Oriented Design [17], es una metodología desarrollada por Grady Booch, la cual usa los siguientes tipos de diagramas para describir las decisiones de 16

31 análisis y diseño, tácticas y estratégicas, que deben ser hechas en la creación de un sistema orientado por objetos: 1. Diagrama de Clases. Consisten en un conjunto de clases y relaciones entre ellas. Puede contener clases, clases paramétricas, utilidades y metaclases. Los tipos de relaciones son asociaciones, contenencia, herencia, uso, instanciación y metaclase. 2. Especificación de Clases. Es usado para capturar toda la información importante acerca de una clase en formato texto. 3. Diagrama de Categorías. Muestra clases agrupadas lógicamente bajo varias categorías 4. Diagramas de transición de estados. 5. Diagramas de Objetos. Muestra objetos en el sistema y su relación lógica. Pueden ser diagramas de escenario, donde se muestra cómo colaboran los objetos en cierta operación; o diagramas de instancia, que muestra la existencia de los objetos y las relaciones estructurales entre ellos. 6. Diagramas de Tiempo. Aumenta un diagrama de objetos con información acerca de eventos externos y tiempo de llegada de los mensajes. 7. Diagramas de módulos. Muestra la localización de objetos y clases en módulos del diseño físico de un sistema. Un diagrama de módulos representa parte o la totalidad de la arquitectura de módulos del sistema. 8. Subsistemas. Un subsistema es una agrupación de módulos, útil en modelos de gran escala. 9. Diagramas de procesos. Muestra la localización de los procesos en los distintos procesadores de un ambiente distribuido. 1.4) OMT [18] (por sus siglas en inglés Object Modeling Technique): Desarrollada por James Rumbaugh, hace un cubrimiento de las etapas de análisis, diseño e implementación definidas por la OMG, dejando sin cubrir el modelamiento estratégico. En esta metodología se hace uso de los siguientes modelos: 17

32 1. Modelo de Objetos. Se define como un diagrama de objetos más que un diccionario de datos. El diagrama de objetos muestra clases y sus relaciones (generalización, agregación, asociación, instanciación). El diccionario de datos es el detalle de las clases en el diagrama de objetos 2. Modelo dinámico. Se define como un conjunto de diagramas de estado más que un diagrama de Flujo de eventos Global. 3. Modelo funcional. Es un diagrama de flujo con restricciones. 1.5) RUP (por sus siglas en inglés Rational Unified Process) [19]: Es un proceso que define claramente quién, cómo, cuándo y qué debe hacerse; y, como su enfoque está basado en modelos, utiliza un lenguaje bien definido para tal fin, el UML (por sus siglas en ingles Unified Modeling Language). Este proceso aporta herramientas como los casos de uso, que definen los requerimientos. Permite la ejecución iterativa del proyecto y del control de riesgos. Las características principales del proceso son: 1. Guiado por los Casos de Uso 2. Centrado en la Arquitectura 3. Guiado por los Riesgos 4. Iterativo A través de un proyecto guiado por RUP, los requerimientos funcionales son expresados en la forma de Casos de Uso, que guían la realización de una arquitectura ejecutable de la aplicación. Además, el proceso focaliza el esfuerzo del equipo en construir los elementos críticos estructuralmente y del comportamiento (llamados Elementos Arquitecturales) antes de construir elementos menos importantes. La mitigación de los riesgos más importantes guía la definición/confirmación del alcance en las primeras etapas del ciclo de vida. 18

33 Finalmente RUP particiona el ciclo de vida en iteraciones que producen versiones increméntales de los ejecutables de la aplicación. RUP implementa las siguientes mejores prácticas asociadas al proceso de Ingeniería de Software [20]: 1. Desarrollo Iterativo 2. Manejo de los Requerimientos 3. Uso de una Arquitectura basada en componentes 4. Modelización Visual 5. Verificación Continua de la Calidad 6. Manejo de los Cambios 2) Metodologías de desarrollo de Sistemas basadas en los esquemas tradicionales. 2.1) Ciclo de vida de un Sistema de Información: El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario. Según James Senn [21], existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. 19

34 2.2) Metodología Estructurada para Desarrollar Sistemas de Información (MEDSI): Es una metodología estructurada para desarrollar sistemas de información en y para organizaciones de cualquier tipo desarrollada por el profesor Jonás Montilva [22]. Esta metodología está orientada a proyectos medianos y grandes, que ameriten la integración de grupos de desarrollo conformados por tres o más personas que puedan requerir para su desarrollo varios meses. Entre las características resaltantes de esta metodología se destacan las siguientes: 1. Es Estructurada: Esta características se debe a dos razones esenciales: a) Utiliza diferentes métodos y técnicas estructuradas, que son propias de la Ingeniería de la Programación, y que han demostrado ser las más eficientes y eficaces para el desarrollo de sistemas programados. b) Guía paso a paso de arriba hacia abajo el grupo que la aplica explicando primero de forma muy general lo que debe hacerse para luego entrar en los detalles, a medida que se avanza hasta explicar las tareas esenciales que el grupo debe llevar a cabo para realizar el sistema de información. 2. Es Completa. Cubre todas las distintas fases del ciclo de desarrollo de un sistema de información, desde la definición del proyecto hasta la implantación del sistema en la organización. Guía al grupo de desarrollo a través de las fases, a un nivel bastante detallado, explicando las actividades que deben hacerse y en la mayoría de los casos, enumerando las tareas específicas que los miembros del grupo deben efectuar. 3. Es particionada. A fin de manipular mejor la inherente a un proyecto de este tipo, la metodología se divide en fases, y cada una de las fases está compuesta por pasos los cuales están orientados a algún tipo de tópicos, aspecto o elemento de un sistema de información. Cada paso a su vez agrupa a un conjunto de actividades que han de ser realizadas por el grupo de desarrollo. 20

35 2.3) MÉTRICA Versión 2.1 [23]: Esta metodología ofrece un marco de trabajo en el que se definen los siguientes elementos: 1. Una estructura de proyecto que sirva de guía al equipo de trabajo e involucre a los usuarios en su desarrollo y en sus puntos decisivos. 2. Un conjunto de productos finales a desarrollar. 3. Un conjunto de técnicas para obtener los productos finales. 4. Las diferentes responsabilidades y funciones de los miembros del equipo de proyecto y de los usuarios. Con este fin, se describe en detalle la sucesión de pasos, estructurados en Fases, Módulos, Actividades y Tareas, que se han de seguir en el desarrollo de sistemas informáticos, así como los productos que se obtienen en cada uno de dichos pasos. Estos productos pueden ser productos finales o bien productos intermedios que servirán para la realización de algún paso posterior. Por último se describe la estructura final de la documentación obtenida. Las razones que han llevado a definir esta estructura de Fases y Módulos son las siguientes: 1. El término Fase conlleva la idea de secuencia y presenta las características que a continuación se indican: a) Establece un conjunto formal de Productos que deben ser entregados por el equipo de trabajo antes de que se inicie la siguiente Fase. De esta forma, se pueden dividir los proyectos en una serie de hitos preestablecidos, que facilitarán las labores de Planificación y Control de Proyectos. b) El final de cada Fase requiere una aceptación formal de las conclusiones a las que se ha llegado al término de la misma. c) El producto final obtenido en cada Fase es un documento que se utiliza para el inicio de la siguiente fase. 21

36 2. La división en Módulos obedece a razones de homogeneidad: Un módulo es un grupo de actividades y tareas que se realizan para producir un conjunto específico de productos finales. 3) Metodologías de desarrollo de Sistemas basadas en el paradigma de las metodologías Agiles. En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágil aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Tras esta reunión se creó The Agile Alliance 2, una organización sin fines de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida fue el Manifiesto Ágil, un documento que resume la filosofía ágil. 3.1) Extreme Programing (XP): Es un método ágil de desarrollo de software pensado para equipos pequeños o medianos que se enfrentan a requisitos vagos o cambiantes. Como sugiere Beck [24], XP lleva un conjunto de prácticas de sentido común al extremo, de tal manera que: 1. El código será revisado continuamente, mediante la programación en parejas (dos personas por máquina). 2. Se harán pruebas todo el tiempo, no sólo de cada nueva clase (pruebas

37 unitarias) sino que también los clientes comprobarán que el proyecto va satisfaciendo los requisitos (pruebas funcionales). 3. Las pruebas de integración se efectuarán siempre, antes de añadir cualquier nueva clase al proyecto, o después de modificar cualquiera existente (integración continua), para lo que nos serviremos de frameworks de pruebas, como JUnit [25]. 4. Se (re)diseñará todo el tiempo ( refactoring ), dejando el código siempre en el estado más simple posible. 5. Las iteraciones serán radicalmente más cortas de lo que es usual en otros métodos, de manera que nos podamos beneficiar de la retroalimentación tan a menudo como sea posible. 3.2) Scrum [26]: Es una metodología desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos: 1) el desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días; el resultado de cada sprint es un incremento ejecutable que se muestra al cliente; 2) importancia de las reuniones a lo largo proyecto, entre las cuales destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración. 3.3) Crystal Methodologies [27]. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, 23

38 estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). 3.4) Dynamic Systems Development Method (DSDM) [28]. Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases. 3.5) Adaptive Software Development (ASD) [29]. Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. 3.6) Feature-Driven Development (FDD) [30]. Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad. 3.7) Lean Development (LD) [31]. Definida por Bob Charette s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios. 24

39 4) Herramientas operativas bajo el Paradigma MDA Aún cuando las herramientas de transformación son el corazón del desarrollo en MDA, no son las únicas que éste paradigma requiere. Según [3], las herramientas necesarias en un ambiente de desarrollo MDA son (ver Figura 1): 1. Editor de código (IDE). Las funciones que proveen los ambientes de desarrollo integrado (IDE), como la depuración, compilación y edición de código, no deben pasarse por alto. 2. Repositorio de modelos. Una base de datos de modelos. 3. Editor de modelos (herramienta CASE). Donde los modelos pueden ser construidos y modificados. 4. Validador de modelos. Los modelos usados para la generación de otros modelos deben de estar extremadamente bien definidos. Los validadores revisan los modelos contra un conjunto de reglas (predefinidas o definidas por el usuario) para asegurar que el modelo está listo para ser usado en una transformación. 5. Editor de definición de transformaciones. Un editor para crear y modificar una definición un de una transformación. 6. Repositorio de definiciones de transformación. Un lugar de almacenamiento de las definiciones de transformaciones que son utilizadas para pasar de modelo a otro. 7. Ejecución de modelos. Un motor que provee una plataforma virtual donde se pueden ejecutar los modelos. 25

40 Figura 1. Herramientas requeridas en un ambiente MDA. Fuente: Anneke Kleppe (2003). Una parte fundamental de las herramientas que soportan MDA debe ser la capacidad de clasificar los modelos (PIM y PSMs), así como el marcado de estos y la definición de las transformaciones, para después generar transformaciones entre modelos y generación de código a partir de ellos (y no solo a la generación de código a partir del diagrama de clases como manejan algunas herramientas CASE) [32]. Existen a la vez dos tipos de herramientas MDA, aquellas que generan el código y aquellas que ejecutan el modelo. El código generado del primer grupo de herramientas tiene que ser modificado en la mayoría de los casos, ya que no es código terminado que pueda ser compilado y ejecutado (es más bien un 'esqueleto'), eso sin tomar en cuenta que en la mayoría de los casos los programadores tienden a cambiar la estructura del código generado, de tal forma que el modelo queda desactualizado. Algunas herramientas intentan resolver este problema mediante lo que se conoce como ingeniería inversa, con la cual es posible volver a actualizar el modelo a partir del código modificado, sin embargo aun así debe de existir disciplina en los cambios para evitar desincronización entre modelos. El segundo tipo de herramientas utiliza UML y algunas extensiones del mismo para modelar a detalle una aplicación de tal forma que el modelo pueda ser ejecutado dentro de la herramienta. Algunas de estas herramientas generan código como Java, C++ o algún lenguaje propio y generan una serie de paquetes que pueden ser 26

41 ejecutados dentro del servidor de la misma aplicación. El principal problema de estas herramientas es que, generar un modelo UML que pueda ser ejecutado no es sencillo, se debe tener un amplio conocimiento de UML para obtener beneficios reales de una herramienta de este tipo [33]. Debido al apogeo de MDA, en la actualidad se encuentran numerosos frameworks, herramientas, lenguajes y estándares alrededor del tema; para la realización de este marco de referencia se exploró un amplio grupo de propuestas en transformación de modelos. A continuación se presentan un grupo de ella que por su difusión han alcanzado relevancia, y que tiene una relación directa con la propuesta metodológica presentada en este trabajo de investigación: 1. QVT: (de sus siglas en inglés Query/View/Transformations): Es un estándar propuesto por la OMG y basado en MOF (de sus siglas en inglés Meta Object Facility) para lenguajes de transformación en MDA [35]. 2. JMI: (de sus siglas en inglés Java Metadata Interface): Es un framework basado en MOF, para permitir la carga, manipulación y serialización de ficheros XMI (XML Metadata Interchange) y posibilitar el intercambio de modelos UML [36]. 3. UML Action Semantics: Esta propuesta incluye los lenguajes de acción (AL), para la especificación de acciones sobre diagramas de estado y operaciones sobre diagramas de clases [37]. 4. GMT: (de sus siglas en inglés Generative Modeling Tools) proyecto de Eclipse Foundation acerca del desarrollo de software dirigido por modelos (MDSD: Model Driven Software Development). Entre el grupo de subproyectos que incluye, se encuentran ATL, VIATRA2 y UMLX. 5. xuml: (executable UML) subconjunto de UML que incorpora un AL, para construir modelos de dominio ejecutables [38], se basa en la formula: xmul=uml Debilidad Semántica +AL. En este ámbito se encuentra además UMLX, sintaxis gráfica que complementa QVT [39]. 27

42 6. VIATRA: (de sus siglas en inglés VIsual Automated model TRAnsformations) ambiente de validación y verificación basado en transformación de modelos soportado por la herramienta VIATRA2 [40]. 7. GReAT: (de sus siglas en inglés Graph Rewriting and Transformations) enfoque de transformación por grafos con un conjunto de herramientas diseñadas para la rápida especificación e implementación de transformaciones de modelo a modelo [41]. 8. XDE: (IBM Rational Rose XDE Modeler) permite crear modelos UML independientes del lenguaje, se puede integrar con diversos entornos [42]. 9. Stratego: lenguaje modular para la especificación de transformaciones automáticas y completas de programas, basándose en el paradigma de estrategias de reescritura, tiene una herramienta de implementación llamada Stratego/XT [43]. 10. BOTL: (de sus siglas en inglés The Bidirectional Object oriented Transformation Language): Es una notación gráfica precisa, formal y comprensiva, que pretende fundir los lenguajes formales con la fortaleza expresiva de las representaciones gráficas [44]. 11. ArcStyler: herramienta para la transformación de modelo a modelo, generación de código y generación de archivos para pruebas y despliegue [45]. 12. Codagen Architect: herramienta que soporta la generación a partir de diagramas de clases, actividades, estados y casos de uso, importados vía XMI 1.1 [46]. 13. AToM3: (de sus siglas en inglés A Tool for Multi-formalism Meta- Modelling) herramienta para el meta-modelado y la transformación de modelos, utiliza una gramática declarativa gráfica y realiza las transformaciones reescribiendo grafos [47]. 14. KMTL: (de sus siglas en inglés Kent Model Transformation Language) 28

43 posee un framework llamado KMF (de sus siglas en inglés Kent Modelling Framework) y se integra a un ambiente de desarrollo llamado MDD Environment, construido sobre el IDE de Eclipse [48]. 15. OptimalJ de Compuware, usa notación de patrones para definir las transformaciones PSM y MOF para soportar estándares como UML y XMI. Se trata de un entorno de desarrollo que permite generar aplicaciones J2EE completas a partir de un PIM. 5) Conclusiones del Estado del Arte Un proyecto de sistemas de información tiene que ser manejado aprendiendo de la experiencia en una forma de espiral controlada. El desarrollo de simples o muy bien conocidos sistemas de información, usualmente se hace a través de una ruta fija de administración. Esto es especialmente claro en los llamados modelos de cascada de desarrollo de sistemas, que consisten en un número de estados predefinido en una secuencia definida: preparar y planear el proyecto, investigar acerca de los requerimientos del cliente, especificar y diseñar el programa del sistema, probar y entregarlo, en este orden solamente. El desarrollo por prototipos ha sido de esta forma muy popular en los sistemas de información porque le permiten aprender en el sitio y cambiar el curso cuando sea necesario, pero su inconveniente es su naturaleza ad hoc, difícil de predecir y manejar. Tradicionalmente, mucho del esfuerzo que hacían los ingenieros de información y de conocimientos estaba directamente relacionado con los aspectos técnicos del problema y de la solución. Ahora que la tecnología de sistemas ha alcanzado un buen grado de madurez y de difusión, esto ya no es su objetivo principal. Muchos factores, además del tecnológico, determinan el éxito o el fracaso de un sistema de información en la organización, pues éste no sólo tiene que ejecutar muy bien sus tareas de acuerdo con unos estándares fijados previamente, 29

44 sino que tiene que ser aceptado por el usuario final. La experiencia práctica ha mostrado que a menudo los factores críticos de éxito para los sistemas de información son, también, los puntos relevantes que en la organización han sido tratados. Muchos fallos en la automatización han resultado, no sólo de problemas con la tecnología, sino también por no tener en cuenta factores sociales y organizacionales. Aún muchas metodologías de desarrollo de sistemas se enfocan en los aspectos técnicos y no soportan el análisis de otro tipo de elementos relacionados con las personas, el entorno, la organización, la cultura y el poder, los cuales son determinantes para que el sistema tenga éxito o fracase como solución. La propuesta metodológica MDA-UNEG ofrece las herramientas para manejar todos estos aspectos. 30

45 CAPITULO III MARCO TEORICO 1) Introducción a MDA MDA [49] es un paradigma propuesto por OMG para la construcción de software en el que los modelos guían todo el proceso de desarrollo. Este nuevo paradigma se ha denominado Ingeniería de Modelos o Desarrollo de software basado en modelos. La idea base que subyace a este nuevo paradigma es que si el desarrollo está guiado por los modelos del software, se obtendrán beneficios importantes en aspectos fundamentales como son la productividad, la portabilidad, la interoperatividad y el mantenimiento. La propuesta MDA de OMG constituye un enfoque adecuado para llevar a cabo de manera estructurada y documentada el proceso de generación de código siguiendo una estrategia basada en modelos. MDA promueve la separación entre la especificación de la funcionalidad esencial del sistema y la implementación de dicha funcionalidad mediante la definición de transformaciones entre modelos de distintos niveles de abstracción. En este paradigma las transformaciones entre modelos se convierten en un elemento clave e indispensable de los métodos que siguen este enfoque. Actualmente MDA no propone de forma explícita transformaciones ni técnicas a utilizar para realizar estas transformaciones. Se está trabajando en la definición de un lenguaje estándar para la definición de transformaciones entre modelos [50, 51]. 31

46 Hasta llegar a un consenso en dicho lenguaje estándar se están proponiendo y estudiando diversas técnicas [52]. En el paradigma MDA las fases de determinación de requerimientos, pruebas e implementación siguen iguales; básicamente los cambios se reflejan en las siguientes etapas: 1 Análisis: En esta fase se desarrolla el PIM, haciendo énfasis especial en las necesidades del negocio y la funcionalidad que debe incorporar el sistema. 2 Diseño: En esta fase, el grupo de desarrollo se encarga de la transformación del PIM en uno o más PSMs. 3 Codificación: Con PSM, esta fase se reduce a generar el código del sistema mediante herramientas de transformación. Los programadores únicamente tendrán que añadir la funcionalidad que no se puede reflejar en los modelos y, si es necesario, retocar el código generado. Para el paso del PIM a PSM y PSM a código se usan herramientas de transformación para automatizar estas tareas. Una representación gráfica de este proceso se puede apreciar en la Figura 2. PIM Herramienta de transformación PSM Herramienta de transformación CODIGO Figura 2. Pasos en el desarrollo con Visión alternativa de MDA. Fuente: Universidad de Murcia, Murcia (2004) Un modelo en MDA es una descripción de todo o parte de un sistema escrito en un lenguaje de programación bien definido. El desarrollo de software puede verse como un proceso de evolución de conceptos cercanos al espacio del problema para progresivamente definir mecanismos y 32

47 elementos cercanos al espacio de la solución, pasando por etapas (análisis, diseño, programación, etc.) que permiten gestionar el avance del proceso. Dada la complejidad del desarrollo de una solución software, se hace necesario la implementación de estrategias para alcanzar beneficios fundamentales como son la productividad, la interoperabilidad, la portabilidad y la facilidad de mantenimiento, es por esto que propuestas como la de MDA se fundamentan en principios básicos como los expuestos en el manifiesto MDA planteado por IBM [53]: (a) representación directa para enfocarse en el dominio del problema más que en la tecnología, (b) automatización de las tareas mecánicas que no requieren intervención humana y (c) estándares abiertos que posibiliten la interoperabilidad de las herramientas y plataformas. Tal como se observa en la Figura 3, estos tres elementos evidencian la importancia que tienen las herramientas en el proceso de desarrollo basado en MDA, para posibilitar la construcción de modelos, apoyar su transformación y permitir la interdisciplinariedad de los participantes, a través de la integración de las diversas plataformas y herramientas que estos utilizan. Representación directa MDA Automatización Estándares Figura 3. Visión alternativa de Model Driven Architecture. Fuente: Universidad de Murcia, Murcia (2004). 33

48 2. Fundamentos de MDA 2.1) Meta-modelos y MOF El lenguaje de modelado UML es el principal mecanismo en la que se apoyan hoy en día las herramientas de diseño de aplicaciones. Sin embargo, cada vez más se exigen técnicas de diseño más especializadas, enfocadas a ciertos ámbitos de negocio sobre los que se quiere desarrollar nuevas aplicaciones. Y justo ahí es donde el UML clásico empieza a presentar sus grietas. Este escenario impulsa la necesidad de disponer de nuevos lenguajes específicos del dominio que se adapten mejor al ámbito de negocio de las aplicaciones que se quieran desarrollar. Nuevos lenguajes de modelado que puedan ser usados en el ámbito MDA, como PIMs o PSMs. Para ello, el OMG pone a disposición MOF (de sus siglas en inglés Meta Object Facility), un lenguaje para describir lenguajes de modelado. Un lenguaje de modelado puede usar MOF para definir formalmente la sintaxis abstracta de su conjunto de constructores de modelos. En otras palabras, con MOF se pueden definir tales constructores formalmente. Pero además, un meta-modelo también especifica semántica informal por medio del lenguaje natural; y es esta combinación de definiciones formales e informales a lo que se puede llamar un meta-modelo MOF, o si se prefiere simplemente un modelo MOF. MOF es un estándar hermano de UML y es una de los elementos en los que se asienta MDA incluso mucho más que UML y sus perfiles, ya que hasta éstos son definidos vía MOF. Pero la relación con UML no acaba ahí. MOF toma prestados de UML los constructores del modelo de clases orientado a objetos y los presenta como la norma para describir la sintaxis abstracta de los constructores de modelado para definir la sintaxis abstracta de un meta-modelo. Por lo tanto, los meta-modelos MOF son como los diagramas de clases UML y en consecuencia, se pueden usar herramientas de diseño UML para crearlos. Con MOF se modela un constructor de modelado como una clase y las propiedades del constructor como los atributos de la clase. Modelando además las relaciones entre constructores como asociaciones. 34

49 Para poner un poco de orden al lenguaje de meta-modelos MOF y todo lo que se puede derivar del mismo, el OMG ha establecido una arquitectura de cuatro niveles capas de modelado. Estos niveles son conocidos como M3, M2, M1 y M0. 1. Nivel M3: Está formado por un lenguaje capaz de definir nuevos metamodelos (MOF). No se necesitan más niveles por encima, puesto que el OMG estableció que MOF pudiera ser definido por sí mismo, siendo en cierto modo también un meta-modelo. 2. Nivel M2: Lo forman todos aquellos meta-modelos que son instancias de MOF, es decir, que son definidos bajo éste. Hay un gran número de estos meta-modelos, incluyendo estándares tales como UML, CWM y CCM que son construidos usando elementos tales como clases, atributos y asociaciones MOF. En la Figura 4 se puede apreciar un ejemplo de meta-modelo. Instancia de Clase MOF Instancia de Atributo MOF ElementoDelModelo nombre : String Instancias de Generalizaciones MOF +subclase 0..n Tabla +tabla 1 +columna 1..n Columna 0..n +superclase Instancia de Asociacion MOF Instancias de Clases MOF Figura 4. Ejemplo de Meta-modelo. Fuente: Francisco José Marquina, Murcia (2005). 35

50 3. Nivel M1: Este nivel lo acaparan todos los modelos que son considerados instancias de M2. La Figura 5 muestra un ejemplo del meta-modelo de la Figura 4 usando un diagrama de clases UML; define una tabla Empleado con tres columnas llamadas Número, Nombre y Dirección. La tabla es una instancia del meta-elemento Tabla y sus columnas son instancias del metaelemento Columna. Empleado: Tabla tabla columna Direccion: Columna tabla tabla columna Numero: Columna columna Nombre: Columna Figura 5 Instancia del meta-modelo de la Figura 4. Fuente: Francisco José Marquina, Murcia (2005). 4. Nivel M0: En este nivel están todos los objetos y datos que son instancias de elementos del nivel M1. Aquí ya no se trata con clases ni atributos, sino solo entidades físicas. Siguiendo el ejemplo anterior, se puede tener un empleado de nombre Antonio como el de la Figura 6. e1 : Empleado Nombre: Antonio Direccion: Ronda Levante Numero: 5 Figura 6. Ejemplo de Nivel M0. Fuente: Francisco José Marquina, Murcia (2005). 36

51 3) Conceptos básicos de MDA A continuación se muestran los conceptos que conforman el núcleo de MDA. 1. Sistema: Los conceptos de MDA serán expresados en términos del sistema existente. Este sistema puede incluir: un programa, un computador, una combinación de diferentes parte de sistemas, una conjunción de sistemas cada uno con un control diferente (personas, una empresa, federación de empresas, etc.). 2. Modelo: El modelo de un sistema es la descripción o especificación de ese sistema y su adaptación a un propósito determinado. Frecuentemente se presenta a un modelo como una combinación de dibujos y texto. El texto puede estar en un lenguaje de modelado o en lenguaje natural. En el contexto de MDA, los modelos son representaciones formales del funcionamiento, comportamiento o estructura del sistema que se está construyendo [54]. El término formal especifica que el lenguaje utilizado para describir el modelo debe de tener una semántica y sintaxis bien definida. Un concepto clave a la hora de construir modelos es el de abstracción. Se debe ignorar la información que no es de interés para el dominio del problema a resolver. Los modelos representan elementos físicos o abstractos correspondientes a una realidad simplificada, adecuada al problema que se necesita resolver. 3. Dirigido por modelos: MDA es un acercamiento al diseño del sistema, para ello se incrementa la importancia de los modelos. Es dirigido por modelos porque aporta los medios para usar los modelos directamente para el entendimiento, diseño, construcción, despliegue, operación, mantenimiento y modificación. 4. Arquitectura: La arquitectura del sistema es una especificación de las partes y los conectores del sistema y las reglas para la interacción de las 37

52 partes usando conectores. El MDA prescribe algunos tipos de modelos para ser utilizados, cómo tienen que ser preparados esos modelos y las relaciones entre los tipos de modelos. 5. Punto de vista y Vista: Un punto de vista de un sistema es la técnica para la abstracción utilizando un conjunto seleccionado de conceptos de la arquitectura y reglas estructurales, para centrarse en conceptos particulares dentro del sistema. La palabra abstracción es utilizada con su significado de proceso de suprimir los detalles seleccionados para establecer un modelo simplificado. El MDA especifica tres puntos de vista sobre un sistema: un punto de vista de computación independiente, un punto de vista de plataforma independiente y un punto de vista de plataforma específica. Una Vista o un modelo de punto de vista del sistema es una representación del sistema desde la perspectiva del punto de vista elegido. 6. Plataforma: Una plataforma es un conjunto de subsistemas y tecnologías que aportan un conjunto coherente de funcionalidad a través de interfaces y patrones de uso específico. En MDA, el término plataforma se utiliza generalmente para hacer referencia a los detalles tecnológicos y de ingeniería que no son relevantes de cara a la funcionalidad esencial del sistema. Este uso del término se encuadra dentro de la separación fundamental que se realiza en MDA entre la especificación de un sistema y su plataforma de ejecución. Se define plataforma como la especificación de un entorno de ejecución para un conjunto de modelos [55]. Está formada por un conjunto de subsistemas y tecnologías que proporcionan una funcionalidad determinada a través de una serie de interfaces y patrones de uso determinados [56]. 38

53 Una aplicación soportada por la plataforma puede ser utilizada sin preocuparse por los detalles de cómo se suministra la funcionalidad por parte de la implementación de la plataforma. 7. Aplicación: En la definición de MDA se utiliza la palabra aplicación para referirse a la funcionalidad que se está diseñando. Un sistema es descrito en términos de una o más aplicaciones que son soportadas por una o más plataformas. 8. Independencia de Plataforma: Es una cualidad que el modelo debe tener. Esta característica es la que hace que el modelo sea independiente de las características de un tipo particular de plataforma. Como la mayoría de las características, la independencia de la plataforma es una cuestión de grado. Por esto, un modelo puede asumir solamente la disponibilidad de características de un tipo muy general de plataforma, tal como invocación remota, mientras que otro modelo podría asumir la disponibilidad de un sistema particular de las herramientas para la plataforma de CORBA (por sus siglas en inglés Common Object Request Broker Architecture). De igual manera, un modelo podría asumir la disponibilidad de una característica de un tipo particular de plataforma, mientras que otro modelo se pudo adaptar completamente a ese tipo de plataforma. 9. Puntos de Vista de los MDA: Punto de vista de computación independiente: se centra sobre la adaptación del sistema y los requisitos para el sistema; los detalles de la estructura y el proceso del sistema están ocultos o indeterminados. Punto de vista de independencia de plataforma: se centra en la operatividad del sistema ocultando los detalles sobre la plataforma en particular. Una vista independiente de la plataforma muestra parte de la especificación completa que no cambia de una plataforma a otra. Esta 39

54 vista puede utilizar un lenguaje de modelado de propósito general, o un lenguaje especifico al área donde el sistema será utilizado. Punto de vista de plataforma específica: combina la vista de independencia de plataforma con un enfoque adicional centrado en los detalles del uso por parte del sistema de una plataforma específica. 10. PIM: Es una vista del sistema centrada en la operación del mismo que esconde los detalles necesarios para una determinada plataforma [56]. Un PIM muestra un determinado nivel de independencia de la plataforma de forma que sea posible utilizarlo con un número de plataformas diferentes de forma similar. Una técnica muy común para conseguir la independencia de plataforma es a través de tecnología neutral de una máquina virtual [57]. Estas máquinas virtuales son especificaciones de un procesador computacional, que pueden ser realizadas sobre múltiples plataformas computacionales, siendo típicamente su desarrollo lógico [58]. Las máquinas virtuales consiguen de este modo la independencia de de los programas que ejecutan con respecto a la plataforma de ejecución final (habitualmente un sistema operativo funcionando sobre una configuración hardware determinada). Es importante señalar que MDA propone un nivel de abstracción mayor, puesto que busca la independencia de la plataforma y dichas máquinas virtuales serán consideradas plataformas de ejecución. En la Figura 7 se recoge un escenario de utilización de MDA que ilustra diferentes niveles de abstracción y los artefactos de ejecución manejados en cada uno de ellos. En este escenario típico, una herramienta MDA recoge los diferentes PIM que especifican el sistema y los transforma en un lenguaje de alto nivel soportado por la plataforma de destino. En el caso de que la plataforma destino utilice una máquina virtual que no sea un intérprete puro, se requerirá un proceso de compilación que obtenga el código máquina soportado por la máquina virtual. Este es el caso de las 40

55 plataformas Java y.net. Es habitual que, por razones de eficiencia, dicha máquina virtual sea compilada en cada sistema operativo como código máquina nativo, que será ejecutado finalmente por el hardware utilizado en cada caso. Figura 7. Escenario de utilización de MDA. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 11. PSM: Es la vista del sistema desde el punto de vista de la plataforma específica de ejecución [56]. Un PSM combina las especificaciones del PIM con los detalles que especifica cómo utiliza el sistema un tipo particular de plataforma. La diferencia entre un modelo PSM y uno PIM es el conocimiento que incorpora acerca de la plataforma final de implementación. Un PIM no incorpora ninguna información acerca de la plataforma de destino. Por su parte, un PSM contiene toda la información necesaria para hacer posible su implementación sobre una plataforma concreta. Es decir, contendrá toda la información necesaria para generar el código de la aplicación a 41

56 partir de él [59]. Existen autores que consideran el código fuente de la aplicación un modelo PIM [60]. No obstante, en la propuesta del OMG, el código fuente de la aplicación se considera un resultado de una transformación sobre el PIM [56]. Esta implementación del programa en un lenguaje de programación determinado se conoce en ocasiones como Plattorm Specific Implementation (PSI). Aunque en la guía de referencia de MDA del OMG [56] se realiza una separación clara entre los dos tipos de modelos manejados en MDA: PIM y PSM, algunos autores consideran que la distinción no siempre es posible [3]. Esto es debido a que los modelos de las aplicaciones suelen contener información relacionada con la plataforma o tipo de plataforma sobre la que se ejecutarán. Por ejemplo, al especificar que un método de una clase es transaccional, puede considerarse que el modelo se convierte en específico a una plataforma tecnológica que soporte transacciones. 12. El modelo de plataforma: Suministra un conjunto de conceptos técnicos que representan los diferentes tipos de elementos que conforman la plataforma y los servidos ofrecidos por la misma. También especifica, para la utilización de un modelo especifico de plataforma, los conceptos que representan los diferentes tipos de elementos utilizados para especificar el uso de la plataforma por una aplicación. Un modelo de plataforma especifica además los requisitos de conexión y uso de las partes de la plataforma y la conexión de una aplicación a la plataforma. Un modelo de plataforma genérica puede establecer una especificación de un estilo particular de arquitectura. 13. Transformación entre modelos. La transformación del modelo es el proceso de convertir un modelo en 42

57 otro del mismo sistema. En MDA se contemplan dos tipos fundamentales de transformaciones (Figura 8): 1. La transformación de un PIM en un PSM. 2. La transformación de un PSM en el código fuente de la aplicación. Figura 8. Proceso de transformación en MDA. Fuente: Begoña Cristina Pelayo. Oviedo (2007). En la Figura 8 se representa esta doble transformación. Una herramienta de transformación MDA recoge el modelo independiente de la plataforma PIM y lo transforma en un modelo específico a la plataforma PSM. Para realizar esta transformación, hace uso de una metainformación que especifica cómo realizar la transformación. Esta metainformación se denomina definición de la transformación [3] o mapping rules (reglas de mapeo) [56]. En general, suele utilizarse el término mapping (mapeo) para denominar transformación. Además de las definiciones de transformación, es habitual etiquetar o marcar los modelos para guiar los procesos de transformación. Por ejemplo, para diferenciar datos persistentes de datos temporales; o para distinguir entre procesos remotos o locales. Esta metainformación se denomina genéricamente como marcas (marks) [55]. Las marcas se utilizan tanto en los PIM como en los PSM. 43

58 Las dos transformaciones pueden ser realizadas por la misma herramienta de transformación o por herramientas distintas. Es precisamente cómo se aborda la construcción de dichas herramientas de transformación, junto con las definiciones de cómo se realizan las transformaciones, uno de los aspectos claves que diferencian las diversas líneas de investigación en torno al paradigma MDA. De hecho, en la Guía de Referencia de MDA [56], la información que especifica la transformación se representa con una caja blanca vacía. En el contexto MDA, una transformación es el proceso de generación de un modelo destino a partir de uno origen. Un proceso descrito por una definición de transformación, la cual consiste de un conjunto de reglas de transformación y que son ejecutadas por una herramienta de transformación. Sin embargo, una transformación no es solo un conjunto de reglas, sino que también debería llevar asociada una serie de características deseables que se presentan a continuación (de mayor a menos importancia): 1. Configuración: Es la principal de las características y describe la posibilidad de poder configurar una transformación antes de ser usada, adaptándola a las necesidades requeridas. Es muy importante que una herramienta tenga la posibilidad de definir transformaciones configurables que permitan desarrollar transformaciones entre modelos más potentes y versátiles. Así por ejemplo, una transformación de un String UML a un VARCHAR en un modelo entidad-relacional, puede permitir especificar la longitud del VARCHAR para cada String que aparezca. 2. Trazabilidad: Es la capacidad de poder seguir la traza a un elemento del modelo destino hasta el elemento o elementos del modelo origen que la generaron. 44

59 3. Consistencia Incremental: Poder mantener los cambios manuales realizados en elementos del modelo destino aunque éste vuelva a ser regenerado con la transformación que lo originó. 4. Bidireccionalidad: Esta característica describe el que se pueda ejecutar una transformación que se haya definido bidireccionalmente. Una transformación que cumple esta característica permite que su aplicación al modelo destino, dé como resultado el modelo origen. o. Servicios difundidos: Son los servicios disponibles en una amplia gama de plataformas. MDA suministra habitualmente, un modelo independiente de la plataforma de servicios difundidos que facilita el mapeado para la transformación de los modelos específicos de la plataforma mediante la utilización de los servicios suministrados por la plataforma en concreto. p. Implementación: Una implementación es una especificación que suministra toda la información necesaria para la construcción del sistema y ponerlo operativo. 4) Unified Modeling Language: UML UML (por sus siglas en ingles Unified Modeling Language) es una especificación del OMG que tiene como propósito fundamental facilitar para escribir planos de software. UML puede utilizarse para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. Además, esta especificación ha sido aceptada por ISO (por sus siglas en ingles International Organization for Standardization). UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en la Web, e incluso para sistemas empotrados de tiempo real muy exigentes. Es un lenguaje muy expresivo, que cubre todas las 45

60 vistas necesarias para desarrollar y luego desplegar tales sistemas. UML es sólo un lenguaje y por tanto es tan sólo una parte de un método de desarrollo de software. 4.1 Características de UML 1. UML es un lenguaje: Un lenguaje proporciona un vocabulario y las reglas para combinar palabras de ese vocabulario con el objetivo de posibilitar la comunicación. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un sistema. Un lenguaje de modelado como UML es por tanto un lenguaje estándar para los planos del software. El vocabulario y las reglas de un lenguaje como UML indican cómo crear y leer modelos bien formados, pero no dicen qué modelos se deben crear ni cuándo se deberían crear. Esta es la tarea del proceso de desarrollo de software. 2. UML es un lenguaje para visualizar: UML es algo más que un simple montón de símbolos gráficos. Detrás de cada símbolo en la notación UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir un modelo en UML, y otro desarrollador, o incluso otra herramienta, puede interpretar ese modelo sin ambigüedad. 3. UML es un lenguaje para especificar: En este contexto, especificar significa construir modelos precisos, no ambiguos y completos. En particular, UML cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben realizarse al desarrollar y desplegar un sistema con gran cantidad de software. 4. UML es un lenguaje para construir: UML no es un lenguaje de programación visual, pero sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programación. Esta correspondencia permite ingeniería directa: la generación de código a 46

61 partir de un modelo UML en un lenguaje de programación. Lo contrario también es posible: se puede reconstruir un modelo en UML a partir de una implementación. UML es lo suficientemente expresivo y no ambiguo como para permitir la ejecución directa de modelos, la simulación de sistemas y la instrumentación de sistemas en ejecución. 5. UML es un lenguaje para documentar: Una organización de software que trabaje bien produce toda clase de artefactos además de código ejecutable. Estos artefactos incluyen: a) Requisitos, b) Arquitectura, c) Diseño, d) Código fuente, e) Planificación de proyectos, f) Pruebas, g) Prototipos, h) Versiones. Dependiendo de la cultura de desarrollo, algunos de estos artefactos se tratan, más o menos formalmente que otros. Tales artefactos no son sólo los entregables de un proyecto, también son críticos en el control, la medición y comunicación que requiere un sistema durante su desarrollo y después de su despliegue. UML cubre la documentación de la arquitectura de un sistema y todos sus detalles. UML también proporciona un lenguaje para expresar requisitos y pruebas. Finalmente; UML proporciona un lenguaje para modelar las actividades de planificación de proyectos y gestión de versiones La especificación de UML El lenguaje UML viene definido por un conjunto de documentos publicados por el OMG. La versión actual de UML está compuesta por cuatro partes. a. UML Superstructure. Especifica el lenguaje desde el punto de vista de sus usuarios finales. Define 6 diagramas estructurales, 3 diagramas de comportamiento, 4 diagramas de interacción así como los elementos que todos ellos comprenden. b. UML Infrastructure. Especifica las construcciones que conforman 47

62 los cimientos de UML. Para ello, define el núcleo de un metalenguaje que podrá ser reutilizado para definir los metamodelos de otros lenguajes: alinea el metamodelo de UML con MOF. c. UML Object Constraint Language (OCL). OCL es un lenguaje que permite ampliar la semántica de los modelos UML mediante la definición de precondiciones, post-condiciones, invariantes y otras condiciones. d. UML Diagram Interchange. Extiende el metamodelo de UML con un paquete adicional que modela información de carácter gráfico asociada a los diagramas, permitiendo el intercambio de modelos conservando su representación original. 4.3) Modelo Conceptual de UML: Para comprender UML es necesario adquirir un modelo conceptual del lenguaje, y esto requiere comprender tres elementos principales: los bloques básicos de construcción de UML, las reglas que dictan cómo se pueden combinar estos bloques físicos y algunos mecanismos comunes que se aplican a través de UML. El vocabulario de UML incluye tres clases de bloques de construcción: a) Elementos, b) Relaciones y c) Diagramas. Los elementos son abstracciones que son ciudadanos de primera clase en un modelo, las relaciones ligan estos elementos entre sí y los diagramas agrupan colecciones interesantes de elementos ) Elementos en UML: Hay cuatro tipos de elementos: ) Elementos estructurales: Son los nombres de los modelos de UML. En su mayoría son las partes estáticas de un modelo, y representan cosas que son conceptuales o materiales. Son siete tipos: 1. Clase: Es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces. Gráficamente, una clase se representa como un rectángulo, generalmente incluyendo su nombre, 48

63 atributos y operaciones (ver Figura 9). Figura 9. Figura de una clase. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 2. Interfaz: es una colección de operaciones que especifican un servicio de una clase o componente. Una interfaz, por lo tanto, describe el comportamiento externo visible del elemento. Una interfaz puede representar el comportamiento completo de la clase o componente o únicamente una parte de ese comportamiento. Una interfaz define un conjunto de especificaciones de operaciones pero nunca un conjunto de operaciones de implementación. Gráficamente, una interfaz se representa como un círculo junto con su nombre. Una interfaz raramente se encuentra sola. Mejor dicho, está unida típicamente a la clase o componente que realiza la interfaz (ver Figura 10). Figura 10. Ejemplo de una interfaz. Fuente: Begoña Cristina Pelayo. 3. Colaboración: define una interacción y es una asociación de papeles y otros elementos que trabajan juntos para suministrar algún comportamiento cooperativo mayor que la suma del comportamiento de sus elementos. Por tanto, las colaboraciones tienen dimensión tanto estructural como de comportamiento. Una clase dada puede participar 49

64 en varias colaboraciones. Estas colaboraciones representan, pues, la implementación de patrones que forman un sistema. Gráficamente, una colaboración se representa como una elipse de borde discontinuo, incluyendo normalmente sólo su nombre (Figura 11). Figura 11. Ejemplo de colaboración. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 4. Caso de uso: es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo. Un caso de uso es realizado por una colaboración. Gráficamente, un caso de uso se representa como una elipse de borde continuo, incluyendo normalmente sólo su nombre (Figura 12). Figura 12. Ejemplo de caso de uso. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 5. Clase activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades de control. Una clase activa es igual que una clase, excepto en que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Gráficamente, una clase activa se representa como una clase pero con líneas más gruesas, incluyendo normalmente su nombre, atributos y operaciones (Figura 13). 50

65 Figura 13. Ejemplo de clase activa. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 6. Componente: Es una parte física y reemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto. En un sistema, se podrán encontrar diferentes tipos de componentes de despliegue, así como componentes que sean artefactos del proceso de desarrollo, tales como archivos de código fuente. Un componente representa típicamente el empaquetamiento físico de diferentes elementos lógicos, como clases, interfaces y colaboraciones. Gráficamente, un componente se representa como un rectángulo con pestaña, incluyendo normalmente sólo su nombre (Figura 14). Figura 14. Ejemplo de componente. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 7. Nodo: Es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que por lo general dispone de algo de memoria y, con frecuencia, capacidad de procesamiento. Un conjunto de componentes puede residir en un nodo y puede también migrar de un nodo a otro. Gráficamente, un nodo se representa como un cubo, incluyendo normalmente sólo su nombre (Figura 15). 51

66 Figura 15. Ejemplo de Nodo. Fuente: Begoña Cristina Pelayo. Oviedo (2007) ) Elementos de comportamiento: Son las partes dinámicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y el espacio. Hay dos tipos principales: 1. Interacción: es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un contexto particular, para alcanzar un propósito específico. El comportamiento de una sociedad de objetos o una operación individual puede especificarse con una interacción. Una interacción involucra muchos otros elementos, incluyendo mensajes, secuencias de acción (el comportamiento invocado por un mensaje) y enlaces (conexiones entre objetos). Gráficamente, un mensaje se muestra como una línea dirigida, incluyendo casi siempre el nombre de la operación (Figura 16). Visualizar Figura 16. Ejemplo de Interacción. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 2. Máquina de estados: Es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos, juntos con sus reacciones a estos eventos. El comportamiento de una clase individual o una colaboración de clases puede especificarse con una máquina de estados. Una máquina de estados involucra a tres elementos, 52

67 incluyendo estados, transiciones (el flujo de un estado a otro), eventos (que disparan una transición) y actividades (la respuesta a una transición). Gráficamente, un estado se representa como un rectángulo de esquinas redondeadas, incluyendo normalmente su nombre y sus subestados, si los tiene (Figura 17). Figura 17. Ejemplo de estado. Fuente: Begoña Cristina Pelayo. Oviedo (2007) ) Elementos de agrupación: Son las partes organizativas de los modelos UML. Son las cajas en las que puede descomponerse un modelo. Hay un único elemento principal de este tipo que son los paquetes. a. Paquete: es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, e incluso otros elementos de agrupación pueden incluirse en un paquete. Al contrario que los componentes (que existen en tiempo de ejecución), un paquete es puramente conceptual (sólo existe en tiempo de desarrollo). Gráficamente, un paquete se visualiza como una carpeta, incluyendo normalmente sólo su nombre y, a veces, su contenido (Figura 18). Figura 18. Ejemplo de Paquete. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 53

68 ) Elementos de anotación: Son las partes explicativas de los modelos UML. Son comentarios que se pueden aplicar para describir, clarificar y hacer observaciones sobre cualquier elemento de un modelo. El tipo principal de este elemento es la nota. Es simplemente un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos. Gráficamente, una nota se representa como un rectángulo con una esquina doblada, junto con un comentario textual o gráfico (Figura 19). Figura 19. Ejemplo de una nota. Fuente: Begoña Cristina Pelayo. Oviedo (2007) ) Relaciones en UML: Hay cuatro tipos de relaciones: 1. Dependencia: Es una relación semántica entre dos elementos, en la cual un cambio a un elemento (el elemento independiente) puede afectar a la semántica del otro elemento (elemento dependiente). Gráficamente, una dependencia se representa como una línea discontinua, posiblemente dirigida, ocasionalmente incluye una etiqueta (Figura 20). Figura 20. Representación de la relación de dependencia. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 2. Asociación: Es una relación estructural que describe un conjunto de enlaces, los cuales son conexiones entre objetos. La agregación es un 54

69 tipo especial de asociación que representa una relación estructural entre un todo y sus partes. Gráficamente, una asociación se representa como una línea continua, posiblemente dirigida, que a veces incluye una etiqueta y a menudo incluye otros adornos, como multiplicidad y los nombre de rol (Figura 21). Figura 21. Ejemplo de una relación de asociación. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 3. Generalización: Es una relación de especialización/generalización en la cual los objetos del elemento especializado (el hijo) pueden sustituir a los objetos del elemento general (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre. Gráficamente, una relación de generalización se representa como una línea continua con una punta flecha vacía que apunta al padre (Figura 22). Figura 22. Ejemplo de una relación de generalización. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 4. Realización: Es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá. Gráficamente, una relación de realización se representa como una mezcla entre una generalización y una relación de dependencia (Figura 23). Figura 23. Ejemplo de una relación de realización. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 55

70 ) Diagramas en UML: Un diagrama es la representación gráfica de un conjunto de elementos. Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyección de un sistema. En teoría, un diagrama puede contener cualquier combinación de elementos y relaciones. En la práctica sólo surge un pequeño número de combinaciones, las cuales son consistentes con las cinco vistas más útiles que comprenden la arquitectura de un sistema con gran cantidad de software. 1. Diagrama de clases: Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas son los diagramas más comunes en el modelado de sistemas orientados a objetos. Los diagramas de clases cubren la vista de diseño estática de un sistema. Los diagramas de clases que incluyen clases activas cubren la vista de procesos estática de un sistema. La Figura 24 presenta un ejemplo. 2. Diagrama de objetos: Muestra un conjunto de objetos y sus relaciones. Los diagramas de objetos representan fotografías de instancias de los elementos encontrados en los diagramas de clases. Estos diagramas cubren la vista de diseño estática o la vista de procesos estática de un sistema como lo hacen los diagramas de clases, pero desde la perspectiva de casos reales o prototípicos (ver un ejemplo en la Figura 25). 56

71 Figura 24. Diagrama de Clases. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 3. Diagrama de objetos: Muestra un conjunto de objetos y sus relaciones. Los diagramas de objetos representan fotografías de instancias de los elementos encontrados en los diagramas de clases. Estos diagramas cubren la vista de diseño estática o la vista de procesos estática de un sistema como lo hacen los diagramas de clases, pero desde la perspectiva de casos reales o prototípicos (ver un ejemplo en la Figura 25). 57

72 Figura 25. Diagrama de Objetos. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 4. Diagrama de casos de uso: Muestra el conjunto de casos de uso y actores (un tipo especial de clases) y sus relaciones. Los diagramas de casos de uso cubren la vista de casos de uso estática de un sistema. Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de un sistema. Se presenta un ejemplo en la Figura 26. Figura 26. Diagrama de Casos de Usos. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 58

73 5. Diagrama de interacción: Muestra una interacción que consta de un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos. Estos diagramas cubren la vista dinámica de un sistema. Los diagramas de secuencia y de colaboración son de este tipo. Además, estos diagramas son isomorfos, es decir, que se puede tomar uno y transformarlo en el otro. i. Diagrama de secuencia: es un diagrama de interacción que resalta la ordenación temporal de los mensajes (ver ejemplo en Figura 27). Figura 27. Diagrama de Secuencia. Fuente: Begoña Cristina Pelayo. Oviedo (2007). ii. Diagrama de colaboración: es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes (ejemplo en Figura 28). 59

74 Figura 28. Diagrama de Colaboración. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 6. Diagrama de estados: Muestra una máquina de estados que consta de estados, transiciones, eventos y actividades. Los diagramas de estados cubren la vista dinámica de un sistema. Son especialmente importantes en el modelado del comportamiento de una interfaz, una clase o una colaboración y resaltan el comportamiento dirigido por eventos de un objeto. La Figura 29 muestra un ejemplo. Figura 29. Diagrama de Estados. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 60

75 7. Diagrama de actividades: Es un tipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema. Los diagramas de actividades cubren la vista dinámica de un sistema. Son especialmente importantes al modelar el funcionamiento de un sistema y resaltan el flujo de control entre objetos (ver ejemplo en Figura 30). Figura 30. Diagrama de Actividades. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 8. Diagrama de componentes: Muestra la organización y las dependencias entre un conjunto de componentes. Los diagramas de componentes cubren la vista de implementación estática de un sistema. Se relacionan con los diagramas de clases en que un componente se corresponde, por lo común, con una o más clases, interfaces o colaboraciones (ejemplo en Figura 31). 61

76 Figura 31. Diagrama de Componentes. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 9. Diagrama de despliegue Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Los diagramas de despliegue cubren la vista de despliegue estática de una arquitectura. Se relacionan con los diagramas de componentes en que un nodo incluye, por lo común, uno o más componentes. Ver un ejemplo en la Figura 32. Figura 32. Diagrama de Componentes. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 4.4) Reglas de UML Los bloques de construcción de UML no pueden simplemente combinarse de 62

77 cualquier manera. Como cualquier lenguaje, UML tiene un número de reglas que especifican a qué debe parecerse un modelo bien formado. Un modelo bien formado es aquél que es semánticamente auto-consistente y está en armonía con todos sus modelos relacionados. Los modelos que no llegan a ser bien formados son inevitables, conforme los detalles de un sistema vayan apareciendo y mezclándose durante el proceso de desarrollo de software. Las reglas de UML estimulan (pero no obligan) a considerar las cuestiones más importantes de análisis, diseño e implementación que llevan a tales sistemas a convertirse en bien formados con el paso del tiempo. 4.5) Mecanismos comunes en UML UML se simplifica mediante la presencia de cuatro mecanismos comunes que se aplican de forma consistente a través de todo el lenguaje: a. Especificaciones: Detrás de cada elemento de la notación gráfica de UML hay una especificación que proporciona una explicación textual de la sintaxis y semántica de ese bloque de construcción. La notación gráfica de UML se utiliza para visualizar un sistema; la especificación de UML se utiliza para enunciar detalles del sistema. b. Adornos: Todos los elementos en la notación UML comienzan con un símbolo básico, al cual puede añadirse una variedad de adornos específicos de ese símbolo (ver Figura 33). Figura 33. Adornos de la definición de una clase. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 63

78 c. Divisiones comunes: Al modelar sistemas orientados a objetos, el mundo puede dividirse, al menos, en un par de formas: i. División entre clases y objetos, como el ejemplo que se muestra en la Figura 34. Figura 34. División entre clases y objetos. Fuente: Begoña Cristina Pelayo. Oviedo (2007). ii. División entre interfaz e implementación, como el ejemplo que se muestra en la Figura 35.) Figura 35. División entre interfaz e implementación. Fuente: Begoña Cristina Pelayo. Oviedo (2007). 4.6) Mecanismos de extensibilidad: UML proporciona un lenguaje estándar para escribir planos software, pero no es posible que un lenguaje cerrado sea siempre suficiente para expresar todos los matices posibles, de todos los modelos, en todos los dominios y en todos los momentos. Por esto, UML es abierto-cerrado, siendo posible extender el lenguaje de manera controlada. Los mecanismos de extensión son: a) Estereotipos, b) Valores 64

79 etiquetados y c) Restricciones. 4.7) Técnicas de definir lenguajes de modelado Debido a esta gran variedad de propuestas de transformación y a la ausencia de un estándar que guíe todo el proceso, han surgido multitud de arquitecturas y técnicas para definir lenguajes de modelado. En MDA y hasta discusiones recientes, siempre se ha supuesto la existencia de tres niveles de modelado, pero siempre ha quedado abierta la cuestión de qué usar en cada nivel. Diferentes autores abogan por usar el meta-modelado para crear nuevos modelos que se ajusten más a la realidad de los problemas que se intenten reflejar, para otros bastaría con usar perfiles UML, otros abogan por el uso de perfiles con novedosos sistemas de marcas y así sucesivamente. En esta sección se intentará dar un vistazo a los principales modos de trabajo que se pueden utilizar, analizando brevemente las características de cada uno de ellos. Todas estas técnicas requieren de un alto conocimiento de UML pues están ligadas a él de un modo u otro. UML es un lenguaje de modelado estándar de nivel M2, definido bajo MOF y es el de uso más extendido. Su estructura y la de MOF son muy parecidas con lo que resulta de gran ayuda conocer previamente UML antes de estudiar MOF. Por otro lado, UML es el meta-modelo por excelencia para el diseño preliminar de los sistemas, es decir, para el diseño de los modelos PIMs, pues carece de estar orientado a ninguna plataforma o tecnología particular. 4.8) Estereotipos y Valores Etiquetados Los estereotipos pueden extender cualquier tipo de elementos del metamodelo UML. Vienen definidos por un nombre y por el conjunto de elementos del meta-modelado sobre el que pueden asociarse. Gráficamente se definen dentro de clases haciendo uso de la sintaxis <<stereotype>> y pueden llevar asociados valores etiquetados. 65

80 Un valor etiquetado es un meta-atributo adicional que se asocia a una metaclase del meta-modelo extendido por un perfil. Tiene un nombre y un tipo. La Figura 36 presenta un ejemplo de un estereotipo y un valor etiquetado. Figura 36. Ejemplo de estereotipo y valor etiquetado de un perfil UML. Fuente: Francisco José Marquina, Murcia (2005). Aunque en el ejemplo de la Figura 31 se ven los valores etiquetados asociados a un estereotipo, esto no tiene porque ser siempre así. Se pueden definir valores etiquetados que no formen parte de ningún estereotipo y que extiendan a su vez propiedades de los elementos del meta-modelo UML. Por ejemplo, para el caso anterior, se podría definir el valor etiquetado istx para indicar que el elemento Operation especifica una operación transaccional, de manera que, si no se ejecuta con éxito, se le aplica un roll back a todos los cambios realizados por la misma, como se ve en la Figura 37. Figura 37. Valor etiquetado asociado a una metaclase. Fuente: Francisco José Marquina, Murcia (2005). 66

81 4.9) El uso de marcas MDA propone la conversión de un PIM sin detalles, que capte la funcionalidad y estructura del sistema, a otro PSM que mantenga toda la información del predecesor pero que, a su vez, contenga los detalles suficientes para transformarlo a código. Sin embargo, este mapeo no está exento de problemas. En uno de los diagramas del PIM se pueden tener una relación como la de la Figura 38, en la cual se ve cómo un Alumno tendrá una colección de asignaturas, lo cual podría dar lugar a un mapeo en el que Alumno tendría un método getasignaturas() para obtener dicho conjunto. Pero, a la hora de realizar esta transformación a una plataforma dada, por ejemplo J2EE, se presenta el problema de cómo representar ese conjunto, teniendo en cuenta que se pueden tener distintos tipos de colecciones en Java (interfaz Collection) dependiendo, por ejemplo, de si pueden albergar objetos duplicados o no. Figura 38. Relación Curso/Asignaturas. Fuente: Francisco José Marquina, Murcia (2005). Si se utiliza la aproximación de parametrizar la transformación para que todas las colecciones se transformen al mismo tipo concreto, sólo quedaría la alternativa de que una vez obtenido el PSM, un desarrollador curtido en la tecnología a implementar lo modificará para que cada colección tenga el tipo que se desee. La solución podría pasar por parametrizar el modelo PIM añadiendo marcas o etiquetas a los elementos del modelo de manera que, como se ve en la Figura 39, se puede indicar qué colección usar. Claro está, de esta manera el PIM deja de ser un modelo independiente, con lo que lo ideal sería disponer de herramientas que permitan añadir diferentes tipos de etiquetado al modelo, pero que a la vez facilite 67

82 conservarlo independiente de este etiquetado para seguir manteniendo la ventaja de la abstracción. De este modo se puede disponer del PIM original y de un conjunto de PIM parametrizados según la alternativa elegida para cada plataforma. Figura 39. Implementación de Alumno. Fuente: Francisco José Marquina, Murcia (2005). Si se etiqueta un PIM se puede realizar su transformación a su correspondiente modelo en código. De manera que ya no se vería el PSM como un paso intermedio en el proceso de transformación sino que se podría conseguir el modelo implementado directamente. Así se tendrían dos niveles de modelos en el proceso de desarrollo, uno de ellos sí sería el PIM, con diferentes variantes etiquetadas. De todas formas se podría seguir pensando en generar el PSM. Un PSM de solo lectura pero que proporcionara el beneficio de tener una ayuda visual de la implementación en la plataforma elegida, que pueda ayudar a la depuración y fase de pruebas del modelo, por ejemplo, si se quisiera añadir alguna pre o post-condición. O si por ejemplo (y también lo más probable) la herramienta solo genera parte del código, el PSM puede servir a los programadores de la aplicación como una excelente guía-manual de lo que ya hay implementado. Así pues y aunque pueda que no sea estrictamente necesario, el nivel de PSM se justifica en este trabajo gracias a las ventajas que aporta. 68

83 4.10) Perfiles Otra posibilidad planteada es extender el meta-modelo UML mediante su mecanismo de perfiles que presenta para tal tarea. Los diseñadores de UML tomaron la decisión de no hacer UML como un lenguaje de modelado para cualquier cosa que la gente necesitara. Por ello prefirieron hacerlo lo más sencillo posible y a la vez dotarlo de un mecanismo de extensión. Este mecanismo de extensión permite, a través de una herramienta UML, definir constructores de modelado adicionales basándose en los ya definidos por UML. Un conjunto de extensiones constituye esencialmente un dialecto de UML, lo cual es denominado un perfil. UML podría ser visto no como un lenguaje, sino como la base para una familia de lenguajes basados en él. MDA hace fuerte uso del mecanismo de perfiles debido a la necesidad de soportar diferentes aspectos del sistema y niveles de abstracción. El mecanismo de extensión que UML proporciona se basa en estereotipos (stereotypes) y valores etiquetados (tagged values), a los que se debe añadir las condiciones que deben cumplir los elementos del modelo para que esté bien formado mediante restricciones OCL. Un perfil UML es la definición de un conjunto de estereotipos y valore etiquetados que extienden los elementos del meta-modelo de UML. 5) Metadata Interchange (XMI) XMI [61] es un estándar del OMG para el intercambio de información vía XML. Puede ser utilizado para todos los metadatos de los metamodelos que estén expresados en MOF. El uso más común de XMI es como formato de intercambio de modelos UML, es decir, se puede utilizar para la serialización de metamodelos. Desde la perspectiva de modelado de OMG, los datos se dividieron en modelos abstractos y modelos concretos. Los modelos abstractos representan la información semántica, mientras que los modelos concretos representan diagramas 69

84 visuales. Los modelos abstractos son instancias de lenguaje de modelado basado en MOF como puede ser UML. Para los diagramas se utiliza el XMI. El propósito de XMI es facilitar el intercambio de los metadatos entre las herramientas de modelado UML y los repositorios de metadatos MOF en entornos heterogéneos. XMI integra cuatro estándares: XML, UML, MOF y la correspondencia entre MOF y XMI La integración de estos cuatro estándares dentro de XMI permite herramientas de desarrollo para sistemas distribuidos de modelos de objetos y otros metadatos. 6) Object Constraint Language (OCL) OCL [62] es un lenguaje para la descripción textual precisa de restricciones que se aplican a los modelos gráficos UML. Fue desarrollado por IBM y adoptado en octubre de 2003 por el grupo OMG como parte de UML. El lenguaje OCL puede ser utilizado para diferentes propósitos: 1. Como lenguaje de consulta. 2. Dentro del modelo de clase para expresar invariantes sobre clases y tipos. 3. Para especificar tipos invariantes para Estereotipos. 4. Para describir pre y postcondiciones sobre Operaciones y Métodos. 5. Para describir controles. 6. Para especificar objetivos para mensajes y acciones. 7. Para especificar restricciones sobre operaciones. 8. Para especificar reglas de derivación de atributos para una expresión sobre el modelo UML. 70

85 6.1) Fundamentos De OCL 6.1.1) Expresiones, tipos y valores en OCL En OCL, cada valor, ya sea un objeto una instancia de un componente o un valor de datos, tiene un tipo que define qué operaciones pueden ser aplicadas al objeto. Los tipos se dividen dentro de dos grupos: tipos predefinidos en la biblioteca estándar y tipos definidos por el usuario. Dentro de los tipos predefinidos se pueden distinguir los básicos y de colección. Los tipos básicos son Integer, Real, String y Boolean, cuyas definiciones son similares a otros lenguajes. Dentro de las colecciones están Collection, Set, Bag, OrdenedSet y Sequence. Las colecciones se utilizan para especificar exactamente los resultados de navegación a través de las asociaciones en el diagrama de clases. Los tipos definidos por el usuario se definen en los diagramas UML. Cada elemento instanciable del modelo, es decir, cada clase, interfaz, componente o tipo de datos en un diagrama UML es automáticamente un tipo de OCL. Las expresiones OCL representan un valor, por tanto tiene un tipo, ya sea definido por el usuario o predefinido. Además, cada expresión tiene un resultado que será el valor que resulta de evaluar la expresión. El tipo del resultado es igual al tipo de la expresión. OCL distingue entre tipos de valores y tipos de objetos. Ambos son tipos, ambos especifican instancias, pero hay una diferencia importante: los tipos de valor definen instancias que no cambian. Por ejemplo si tenemos un Integer con valor 1 siempre tendrá ese valor. En cambio los tipos de objetos o Classifiers representan tipos que definen instancias que pueden cambiar su valor o valores. Por ejemplo: una instancia de la clase Persona puede cambiar el valor del atributo Edad pero seguirá siendo la misma instancia. Esta diferencia se puede explicar en otros términos, por ejemplo Martin Fowler [63] llama a los tipos de objetos, referencia de objetos y a los tipos de valor, objetos valor. Otra característica es que los tipos de valor suponen una identidad. Para un 71

86 tipo de valor, el valor identifica la instancia, de ahí el nombre. Dos ocurrencias de un tipo valor que tenga el mismo valor son por definición la misma instancia. Dos ocurrencias de un tipo objeto son solamente la misma instancia si tienen la misma identidad. Por tanto, los tipos valor tienen identidad basada en valor, y los tipos de objeto tienen identidad basada en la referencia. Cada uno de los tipos básicos tiene una serie de operaciones. Además, dentro de las operaciones existen unas reglas de precedencia. Dentro de los operadores también se puede utilizar los operadores infijos ) Tipos definidos por el usuario Cuando se define un tipo en un diagrama UML, a un tipo de usuario se le otorgan una serie de características. Cada una de estas características puede ser utilizada en una expresión OCL. Las características de un tipo definido por el usuario incluye: 1. Atributos. 2. Operaciones. 3. Atributos de Clase. 4. Operaciones de Clase. 5. Extremos de asociaciones que derivan de las asociaciones y las agregaciones. Los atributos de un tipo definido por el usuario pueden ser utilizados en expresiones escribiendo un punto seguido del nombre del atributo. De forma similar, las operaciones de este tipo también se pueden utilizar en las expresiones. Existe una restricción, al ser OCL un lenguaje libre de efectos laterales, no está permitido el cambio de un objeto. Solamente se pueden realizar operaciones de consulta, que retornan un valor pero no cambian nada. De acuerdo con la especificación UML, cada operación tiene una etiqueta denominada isquery, cuyo valor verdadero indica que la operación no tiene efectos laterales y puede ser utilizada en expresiones. 72

87 La notación del punto utilizada para hacer referencia a los atributos se utiliza también para hacer referencia a las operaciones. No obstante, el nombre de la operación va seguida siempre de paréntesis que encierran los argumentos opcionales de la operación, pero los paréntesis son obligatorios tanto si hay o no hay argumentos. Esto es debido a que es necesario distinguir entre atributos y operaciones, dado que UML permite atributos y operaciones con nombres idénticos. La visibilidad de los atributos y las operaciones se ignora por defecto en OCL. Opcionalmente OCL puede utilizar reglas dadas en la especificación UML. En este caso un atributo privado no puede utilizarse en una expresión OCL, dado que no es visible en la instancia contextual. Las operaciones de clase y los atributos de clase también pueden utilizarse en expresiones. La sintaxis para referirse a los atributos de clase u operaciones será el nombre de la clase seguido por dos puntos y el nombre del atributo u operación y sus parámetros. Otra de las características de los tipos definidos por el usuario se deriva de las asociaciones del modelo de clases. Cada asociación tiene un número de extremos. Cada extremo tiene una multiplicidad, un tipo al que está conectado y un orden opcional, además también tiene un nombre, se llama rol (rolename). Conceptualmente un extremo de una asociación define una característica de la clase conectada a otros extremos de asociación. Los extremos de asociación se pueden utilizar para navegar de una objeto a otro del sistema, por esto se denominan navegadores (navigations). Si no existe el nombre del extremo, se utiliza el tipo de conexión, pero entonces es obligatoria la definición de un rol. Los navegadores son tratados igual que los atributos, utilizando la notación del punto para referirse a ellos. Existe un tipo definido por el usuario especial, el tipo enumeración (enumeration). Este tipo se utiliza habitualmente como un tipo para los atributos. Se define dentro de un diagrama de clase de UML usando el estereotipo de enumeración. 73

88 El valor definido en la enumeración puede ser utilizado dentro de una expresión OCL. 7) QVT (Query/View/Transformation) QVT es la propuesta del OMG para resolver el problema de la transformación de modelos. Se trata de un estándar para la definición de transformaciones sobre modelos MOF. El proceso de definición del estándar culminó a finales de 2005 con la primera versión final de la especificación [64], en la que convergieron las 8 propuestas inicialmente presentadas. Cuando surgió la iniciativa MDA, los estándares UML, XMI y MOF ya gozaban de un cierto grado de madurez y fueron soportados, en mayor o menor medida, por parte de los fabricantes de herramientas. Sin embargo, las reglas de transformación que implementan dichas herramientas eran definidas en torno a un conjunto de tecnologías propietarias no estándares, tales como el uso de plantillas, la generación de metaclases específicas y el uso de otros sistemas propietarios. La consecuencia es que un elemento tan importante de MDA, como es la realización de los sistemas, depende totalmente de la herramienta utilizada. Este es el problema que QVT pretende solucionar. El estándar QVT define tres abstracciones fundamentales, que se corresponden con sus siglas [65]: 1. Consultas (Queries) Una consulta es una expresión que se evalúa sobre un modelo. Los resultados de una consulta son una o varias instancias de los tipos definidos en el modelo transformado, o en el propio lenguaje de consulta. Para la realización de consultas se utilizará un lenguaje de consultas. 2. Vistas (Views) Una vista es un modelo obtenido en su totalidad a partir de otro modelo base. Las consultas son un tipo restringido de vistas. 3. Transformaciones (Transformations) Una transformación genera un modelo a partir de otro modelo de origen. Ambos modelos podrán ser 74

89 dependientes o independientes, según exista o no una relación que mantenga ambos sincronizados una vez se produzca la transformación. Las vistas son un tipo específico de transformación. Si se modifica una vista, la correspondiente transformación debe ser bidireccional para reflejar los cambios en el modelo fuente. Las transformaciones se definirán utilizando un lenguaje de transformación. El lenguaje de transformación debe servir para generar vistas de un metamodelo, debe ser capaz de expresar toda la información necesaria para generar automáticamente la transformación de un modelo origen a uno destino, y debe además, soportar cambios incrementales en un modelo origen que se ven reflejados en el modelo destino [64]. De estas abstracciones se desprenden por lo tanto dos lenguajes, de consulta y de transformación, a los que se impuso como requisito que estuvieran definidos como metamodelos MOF 2.0. Un último requisito fundamental de la propuesta QVT es relativo a los modelos manipulados: todos los modelos manipulados por los mecanismos de transformación serán además instancias de metamodelos MOF 2.0. Una vez descrito el planteamiento conceptual de QVT conviene describir la solución propuesta por la especificación finalmente adoptada [65]. Como lenguaje de consulta se definen extensiones al estándar OCL 2. Para la especificación de transformaciones se propone una solución de naturaleza híbrida declarativa e imperativa. La parte declarativa se divide en una arquitectura de 2 capas, que sirve como marco para la semántica de ejecución de la parte imperativa. Las dos capas de la parte declarativa son: 1. Relations. Define un lenguaje declarativo para expresar relaciones entre modelos MOF. Este lenguaje soporta reconocimiento de patrones, la creación de plantillas de objetos y la creación implícita de las trazas necesarias para registrar los cambios que se producen cuando se transforman modelos. 75

90 2. Core. Define un lenguaje declarativo de menor nivel de abstracción que Relations pero con la misma potencia. La especificación de QVT define las reglas que permiten mapear la semántica de Relations a la de Core, y dichas reglas las define en base a transformaciones descritas utilizando a su vez Core. En este lenguaje, los objetos de traza deben definirse explícitamente y sólo soporta reconocimiento de patrones sobre un conjunto plano de variables, no sobre objetos complejos como en Relations. En cuanto a la parte imperativa de QVT, se definen dos mecanismos para invocar implementaciones imperativas de transformaciones desde los lenguajes Relations o Core: 3. Operational Mapping. Se trata de un lenguaje estándar que permite definir procedimientos imperativos de transformación. Dichos procedimientos deben emitir los mismos modelos de traza que el lenguaje Relations. Se trata de un lenguaje procedural, definido en torno a un conjunto de extensiones del lenguaje OCL que permiten efectos laterales, e incluye construcciones imperativas tales como bucles y condiciones. 4. Black-box MOF Operation. No se trata de un lenguaje, sino de un mecanismo que permite enlazar código escrito en cualquier lenguaje. Para ello, se utiliza el lenguaje Relations para derivar una operación MOF de una transformación. Esta operación será el punto de enlace con el lenguaje deseado, que deberá definir la operación a ejecutar con la misma signatura, y soportar un enlace con la implementación de MOF que se esté utilizando. QVT define por lo tanto tres DSL: Relations, Core y Operational Mappings. Para todos ellos define una sintaxis abstracta en base a sus metamodelos MOF 2. La semántica de su ejecución se define mediante descripciones en texto plano. Para cada uno de ellos se proporciona una sintaxis textual concreta definida mediante gramáticas EBNF [66]. Para el lenguaje Relations se define además una notación 76

91 gráfica específica. Finalmente, para los lenguajes Relations y Operational Mappings se definen diversas extensiones de OCL 2. 8) Desarrollo De Software Ágil La comunidad de la ingeniería del software siempre se encuentra a la búsqueda de nuevas formas de desarrollar software en este contexto hicieron su aparición los llamados métodos ágiles de desarrollo. El caso paradigmático, y también el más conocido es, sin duda, Extreme Programming, también conocido como XP [67]. Estos métodos, llamados inicialmente ligeros, por contraposición a los tradicionales métodos pesados o burocráticos, asumen el cambio como algo inevitable, para lo cual se hace necesaria una nueva forma de abordar el desarrollo de software que facilite el acomodo a los nuevos requisitos a medida que éstos surjan, en vez de pretender ser capaces de analizar inicialmente el dominio a modelar de forma tan exhaustiva que ya no se produzca luego ningún cambio o éstos sean mínimos [68]. El desarrollo de software dista cada vez más de ser algo predecible, por ello éste debe ser cada vez más flexible. Para esto se debe dotar a los participantes en los proyectos informáticos (clientes, jefes de proyecto, programadores, etc.) de las herramientas y técnicas necesarias para que dichos cambios continuos en las especificaciones no sean traumáticos, sino que puedan llevarse a cabo de manera natural (o ágil). Así, estos métodos ágiles de desarrollo constituyen por sí mismos una respuesta a dicha realidad cambiante; pero, como métodos que son, lo hacen fundamentalmente desde la perspectiva de la gestión de proyectos y, en todo caso, del análisis y el diseño. La orientación a objetos ha contribuido a incrementar significativamente la flexibilidad en el desarrollo de software, pero sigue sin ofrecer el grado de flexibilidad requerido para abordar la complejidad (requisitos cambiantes) de las aplicaciones modernas. Se hace necesario un nuevo paradigma de programación que venga a suavizar ese salto todavía muy grande que existe entre el diseño y el código. Se trata, en definitiva, de ir un paso más allá e incrementar aún más el nivel de 77

92 abstracción de los lenguajes de programación, de forma que resulten mucho más cercanos al dominio a modelar. La aparición de los Patrones de Diseño es una respuesta a esa falta de flexibilidad dado que muchos de ellos responden más bien a determinadas carencias de los lenguajes de programación orientados a objetos en los que son implementados. En este sentido, en presencia de ciertos mecanismos de programación con los que sí cuentan otros lenguajes (no necesariamente, como se verá, orientados a objetos) muchos de los patrones existentes verían notablemente simplificada su implementación, llegando incluso en algunos casos a desaparecer, por triviales. En este ámbito, los MDA ágiles se basan en que el código y los modelos ejecutables son operacionalmente lo mismo. Un modelo ejecutable puede ser construido, ejecutado, probado y modificado en ciclos cortos e incrementales. 9) Métodos Ágiles De Desarrollo De Software Los métodos ágiles o ligeros se encuentran en contraposición a los métodos pesados tradicionales. Este tipo de métodos surgieron como respuesta al caos en el que estaba sumido el desarrollo de software, hasta el punto de que muchas veces la única planificación existente consistía en codificar primero y arreglar después. Frente a esa actitud, estos métodos trataron de imponer una disciplina en el proceso de desarrollo, con el objetivo de que éste fuese así más predecible. Para ello tomaron como fuente de inspiración otras ingenierías y crearon procesos con un fuerte componente de planificación y de documentación. Frente a estos métodos pesados, han aparecido una serie de métodos denominados ligeros o ágiles que tratan de una solución de compromiso entre la ausencia de proceso y el exceso de éste. La diferencia más obvia entre este tipo de métodos y los pesados es que generan mucha menos documentación que aquellos. Estos métodos ligeros están centrados en el código, de tal forma que éste se convierte en la principal documentación del proyecto. Sin embargo, no debemos quedarnos con esta llamativa característica como la principal diferencia entre ambos. Lo que esta ausencia de documentación pone de manifiesto son dos diferencias mucho más 78

93 significativas, como afirma Fowler [69]: Los métodos ágiles son adaptables, más que predictivos. Los métodos pesados tienden a planificar con gran detalle todo el proceso de desarrollo, pero esto sólo funciona mientras las cosas no cambien. Frente a esta resistencia al cambio, los métodos ágiles asumen que éste se va a producir, y se preparan para recibirlo. Los métodos ágiles se centran más en las personas que en el proceso. A nuestro juicio, ésta constituye una de las principales características de este tipo de métodos, que explicitan así la necesidad de tener en cuenta la naturaleza de las personas en vez de ir contra ella. Las características de estos métodos se muestran en el Cuadro 1. Estas características están extraídas del Manifiesto para el Desarrollo de Software Ágil [70], firmado en febrero de 2001 por representantes de Extreme Programming, SCRUM, DSDM y otros métodos ágiles. Cuadro 1. Características de los métodos Ágiles. Se refiere Las personas y las relaciones EL software que funciona La colaboración del cliente Responder a los cambios Frente a Los procesos y las herramientas La documentación Los contratos Seguir un plan El nuevo proceso -iterativo, incremental, involutivo y oportunista-alentado por la tecnología de objetos, los entregables evolutivos y las variaciones del ciclo de vida en espiral pretenden conseguir un refinamiento continuo del sistema software en proceso de modelado, de forma que la construcción por bloques (la basada en fases terminales aisladas y estrictamente secuenciales) se ha trocado en una creación de software sobre plastilina, en la que en cualquier momento pueden matizarse detalles o insertar cambios sin que se produzcan rupturas o impactos de quiebra. 79

94 Muchos de los principios de XP suponen procesos y relaciones con el cliente y su mantenimiento, no código. En este sentido, los principios ágiles de desarrollo de código pueden ser aplicables a la construcción de modelos ejecutables [55]. Bajo esta perspectiva se puede asumir que un modelo ejecutable es código. Los MDAs ágiles emplean modelos ejecutables como primer artefacto, que tienen mayor nivel de abstracción que el código, lo que significa que estos modelos aumentan la comunicación con los clientes y mejora la interacción con el dominio del cliente. Existen métodos ágiles existentes son: 1. Extreme Programming (XP) 2. Scrum 3. Adaptive Software Development (ASD) 4. Crystal Clear y otras metodologías de la familia Crystal 5. DSDM 6. Feature Driven Development 7. Lean software development Con el objeto de comprender la forma de actuar con estos métodos, este trabajo de investigación se centra en el estudio del más representativo de ellos: Extreme Programming (XP). 7.2 Extreme Programming (XP) XP es un método ágil de desarrollo de software pensado para equipos pequeños o medianos que se enfrentan a requisitos vagos o cambiantes. Como sugiere Beck [71], XP lleva un conjunto de prácticas de sentido común al extremo, de tal manera que: 1. El código será revisado continuamente, mediante la programación en parejas (dos personas por máquina). 2. Se harán pruebas todo el tiempo, no sólo de cada nueva clase (pruebas unitarias) sino que también los clientes comprobarán que el proyecto va 80

95 satisfaciendo los requisitos (pruebas funcionales). 3. Las pruebas de integración se efectuarán siempre, antes de añadir cualquier nueva clase al proyecto, o después de modificar cualquiera existente (integración continua), para lo que se usarán frameworks de pruebas, como JUnit [72]. 4. Se (re)diseñará todo el tiempo ( refactoring ), dejando el código siempre en el estado más simple posible. 5. Las iteraciones serán radicalmente más cortas de lo que es usual en otros métodos, de manera que se pueda beneficiar de la retroalimentación tan a menudo como sea posible. 7.3) El costo del cambio El costo del cambio en el desarrollo de software se incrementaba exponencialmente en el tiempo (Figura 40). En concreto, el costo de detectar y corregir un error se multiplica por un factor de aproximadamente 10 al pasar de la fase de análisis a la especificación de requisitos, de ésta al diseño y así sucesivamente. Por tanto, los esfuerzos de los métodos pesados han ido encaminados a invertir grandes cantidades de tiempo y documentación durante las primeras fases de desarrollo (especialmente en el establecimiento de los requisitos), en la creencia de que este esfuerzo bien valdría la pena al ahorrar un tiempo mucho mayor en fases posteriores. 81

96 Figura 40. Coste del cambio tradicional en ingeniería del software. Fuente: Begoña Cristina Pelayo, Oviedo (2007). Sin embargo, una de las asunciones más innovadoras de XP es que esta curva ya no es válida y que, con una adecuada combinación de herramientas y tecnología (velocidad de los computadores, disminución del ciclo de compilación y pruebas de días a segundos, bases de datos, orientación a objetos, etc.) es posible obtener la curva de costo del cambio que se muestra en la Figura 41 [73]. Figura 41. Coste del cambio en XP. Fuente: Begoña Cristina Pelayo, Oviedo (2007). Pero esta afirmación no es demostrada y además hay quien, como Cockburn [74], no está de acuerdo con ella y sostiene que la curva tradicional sigue siendo 82

97 válida, pero que eso no supone una crítica a XP, sino todo lo contrario, ya que, según él, XP no sólo no depende de la ausencia de dicha curva exponencial, sino que sus ventajas provienen precisamente de la existencia de la misma y de cómo este hecho es manejado por el método mucho mejor que los tradicionales métodos pesados. No obstante, lo realmente importante aquí no es si la curva sigue siendo o no exponencial, sino cuál debería ser la actitud al enfrentarse al desarrollo de software si la curva fuese la propuesta originalmente por XP. 7.4) Consecuencias del nuevo coste del cambio 1. Si resulta que el coste del cambio no crece drásticamente en el tiempo, entonces: 2. No será necesario hacer gran cantidad de análisis inicial, eliminando así gran parte de las suposiciones -muchas de ellas erróneas- sobre las futuras necesidades del proyecto. 3. No tratar de adivinar el futuro, planificando algo que posiblemente nunca sea necesario. 4. Tratar de retrasar todas las decisiones hasta el último momento posible, de manera que el cliente sólo pagará por aquello que realmente vaya a usar. Es decir, la idea fundamental aquí es que, en vez de diseñar para tratar de anticipar al cambio, diseñar tan sencillo como sea posible, para hacer sólo lo que sea imprescindible en un momento dado, pues la propia simplicidad del código, junto con la factorización y, sobre todo, las pruebas y la integración continua, hacen posible que los cambios puedan ser llevados a cabo tan a menudo como sea necesario. XP es un método que reduce el riesgo de tomar decisiones de diseño erróneas en las fases más tempranas del proyecto, con el consiguiente costo que ello representa, no sólo del tiempo empleado en programar una funcionalidad que no será utilizada, sino sobre todo el coste de oportunidad de no haber dedicado ese tiempo a programar lo realmente necesario. 83

98 7.5) Ciclo de Vida XP es un método centrado en el código pero sobre todo es un método de gestión de proyectos de software [75]. Si se acepta que el desarrollo de software es un proceso caótico, XP no trata de buscar un determinismo inexistente y sí de poner los medios necesarios para manejar esa complejidad, aceptándola. En definitiva, lo que XP propugna es que la planificación no consiste en predecir el futuro, como hacen los métodos pesados, porque para cuando el software hubiera sido desarrollado el cliente ya no querría lo planificado: sus necesidades habrían cambiado entretanto. Figura 42. Evolución de los ciclos de desarrollo. Fuente: Begoña Cristina Pelayo, Oviedo (2007). El ciclo de vida de XP se basa en ciclos de desarrollo más cortos, de hecho es una de las ideas centrales de XP. En la Figura 42 puede verse la evolución de los largos ciclos de desarrollo del modelo en cascada (a) a los ciclos iterativos más cortos de, por ejemplo, el modelo en espiral (b) y, finalmente, a la mezcla que XP (c) hace de todas estas actividades a lo largo de todo el proceso de desarrollo de software [70]. XP define cuatro variables para cualquier proyecto software: costo, tiempo, calidad y alcance. Además, especifica que, de estas cuatro variables, sólo tres de ellas podrán ser fijadas por las fuerzas externas al proyecto (clientes y jefes de proyecto), mientras que el valor de la variable libre será establecido por el equipo de desarrollo en función de los valores de las otras tres. XP hace a las cuatro variables visibles para todo el mundo (programadores, 84