NDT-Suite, una solución práctica para el uso de NDT

Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 28 Referencias [1] Minoli, D. (1995). Analyzing Outsourcing: Reengineering Information and Communication Systems. McGraw-Hill. [2] Sturm, R. & Morris, W. (2000). Foundations of Service Level Management, SAMS. [3] Govekar, M. (2009). Under Pressure: Evolving IT Operations to Best Deliver Business Value, Gartner Symposium, ITxpo 2009, France. [4] Verhulst, P.F. (1845). Mathematical Researches into the Law of Population Growth Increase. Nouveaux Memoires de l'Academie Royale des Sciences et Belles-Lettres de Bruxelles, 18(1) 1-45. Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 29 NDT-Suite, una solución práctica para el uso de NDT Julián Alberto García García, Daniel Rivero Capellán, María José Escalona Cuaresma, Isabel Ramos Román Grupo IWT2. Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla Sevilla - España {julian.garcia, daniel.rivero}@iwt2.org, [email protected], [email protected].es Abstract: The importance of software engineering is well established and accepted by the research community. However, it is still common to find reticence in the business world against the discipline. There are plenty of proposals that call for agile methods for developing software. These methods propose very timely measures for the business environment but yet have not been used in large real projects. One of the most important aspects that lead to this situation is the need to implant these methodologies supported by development tools and environments that must be profitable for the business world. This paper presents a proposal framed within the paradigm of model-driven Web Engineering. This proposal has been adapted to provide a methodological environment currently is being used successfully in real environments. Resumen: La importancia de la Ingeniería del Software está ampliamente demostrada y aceptada por la comunidad investigadora. Sin embargo, todavía es frecuente encontrarse reticencias en el mundo empresarial. Hay bastante propuestas que abogan por métodos ágiles y adecuados para el desarrollo de software que proponen medidas muy oportunas para el entorno empresarial pero, que sin embargo, no han sido usadas en grandes proyectos reales. Uno de los aspectos más importantes que llevan a esta situación es la necesidad de acompañar a esas propuestas de herramientas y entornos de desarrollo que realmente sean rentables para el mundo empresarial. Este artículo presenta cómo una propuesta enmarcada dentro del paradigma de Ingeniería Web guiada por modelos se ha adaptado para ofrecer un entorno metodológico que, actualmente, está siendo utilizado de forma satisfactoria en entornos reales. Keywords: Model Driven Web Engineering, Web Requirements, Tools, Practical Experience, NDT 1. Introducción A lo largo del tiempo las metodologías web basadas en modelos han ido tomando una relevancia cada vez más importante en la Ingeniería Web, como resultado de esta evolución han surgido distintas propuestas metodológicas que han tratado y tratan de dar respuesta a las dificultades que ofrece el diseño de sistemas hipermedia y aplicaciones web. El éxito o fracaso de estas metodologías se debe a su capacidad para afrontar la realidad del desarrollo de software para la red. A diferencia de la Ingeniería del Software, la Ingeniería Web ofrece otros retos como son: Usuarios finales desconocidos. En el desarrollo de aplicaciones web no se debe asumir un rol de usuarios estándar ya que la naturaleza de la web es multicultural además de que cada usuario cuenta con capacidades y tecnología distintas. Alta disponibilidad y requisitos cambiantes. La propia naturaleza dinámica de la web obliga a que las aplicaciones estén operativas la mayor parte del tiempo y que los cambios en los requisitos o el mantenimiento no supongan un cese de las actividades del usuario. Ausencia de orientación. De forma general la web es un elemento textual en el que los únicos elementos de navegación son los hipervínculos. Debido a la gran flexibilidad de este mecanismo no es difícil diseñar aplicaciones en las que el usuario se sienta perdido por inconsistencias en la presentación o falta de contexto navegacional. Por estas razones son necesarias metodologías que se centre en el usuario y que ofrezcan modelos para la fase de requisitos, modelos para el tratamiento de la navegación y modelos de interfaz. Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 30 Junto a los problemas a los que dan respuesta las metodologías actuales cabe tener en cuenta la importancia de que estas metodologías estén soportadas por herramientas. Este soporte facilita que los equipos de trabajo se centren en el problema de su dominio de negocio en lugar de preocuparse por los detalles de funcionamiento de la metodología subyacente. Igualmente el soporte de herramientas permite que los usuarios finales puedan validar los modelos generados si las herramientas proporcionan la adaptación de la información de modo que el usuario final no tenga por qué conocer los detalles metodológicos o técnicos del desarrollo para poder validar el trabajo realizado. El presente artículo pretende ilustrar las herramientas de soporte de la metodología NDT para dar respuesta a las dificultades de desarrollo web junto a un ejemplo de uso y las experiencias derivadas de los proyectos reales realizados con NDT. 2. Trabajos Relacionados NDT (Navigational Development Techniques) no es la única propuesta existente para la ingeniería basada en modelos para la web. Entre las metodologías más relevantes y que más han influido en NDT se encuentran OOHDM (Object-Oriented Hypermedia Design Method) [2], UWE (UML-Web Engineering) [3] y WebML (Web Modelling Language) [4], todas ellas tienen en común que los metamodelos y modelos están basados en UML y en los principios de orientación a objetos. OOHDM supuso el punto de partida para las demás metodologías, esta se basa en HDM pero incluye un enfoque orientado a objetos en sus metamodelos. A su vez esta metodología ofrece tres modelos fundamentales que obligan a la separación de conceptos: modelo conceptual, modelo de navegación y modelo de interfaz abstracta. UWE es una metodología de Ingeniería Web guiada por modelos y sus principales características son: un profile en UML [5] para modelar las fases de desarrollo en particular el modelo de requisitos, modelo de contenidos, modelo de navegación y modelo de procesos. Y soporte tool UWEet (basado en la herramienta UMLet) y MagicUWE (basado en la herramienta MagicDraw). WebML es la propuesta del departamento de electrónica e informática del politécnico de Milán. Esta propuesta está formada por varios modelos (WeBML) y por una herramienta que da soporte a los modelos de WebML llamada WebRatio. La principal característica de esta metodología es su herramienta CASE webRatio basada e integrada con las herramientas de desarrollo eclipse, con capacidades para facilitar el diseño de diagramas BPMN. En la actualidad podría decirse que NDT compite en el mercado con UWE y WebML por lo que es influido por dichas metodologías y a su vez influye en ellas. 3. Visión general de NDT NDT (Navigational Development Techniques) [1] es una propuesta metodológica incluida dentro del paradigma MDE (Model-Driven Engineering, ingeniería Guiada por Modelos) que se definió inicialmente para cubrir las necesidades en el desarrollo Web. Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 31 NDT comienza con la definición de metamodelos formales para fase de requisitos y la definición de un conjunto de transformaciones definidas en QVT [12] para generar los modelos de fase Análisis. La etapa de ingeniería de requisitos comienza con la definición de los objetivos del sistema. En este sentido, NDT puede entenderse como una metodología guiada por objetivos, según la clasificación en [10]. Una vez definidos los objetivos, NDT propone ir capturando y definiendo los requisitos del sistema y propone dividirlos en diferentes tipos, de manera que puedan tratarse según su tipología. De esta forma, los requisitos se dividen en: requisitos de almacenamiento de información, requisitos de actores, requisitos funcionales, requisitos de interacción y requisitos no funcionales. La división en tipologías de requisitos sigue la línea que otras propuestas han tenido en el entorno de Ingeniería Web en otras fases, principalmente análisis y diseño, en las que se han separado los modelos para trabajar con cada uno de ellos. Así, por ejemplo, se han definido modelos conceptuales, de navegación, de adaptabilidad, etc. Este tratamiento caracterizado permite tratar de manera particular cada tipología de requisitos y separar los conceptos. De esta forma, cada uno de esos elementos se define de manera formal en NDT mediante un metamodelo en el que cada tipología de esos requisitos, así como sus atributos y las relaciones que se establecen entre ellos, son representados haciendo uso de un diagrama de clases. En su siguiente fase, el análisis, NDT trabaja de una forma similar. Siguiendo la línea de otras metodologías ampliamente aceptadas como UWE o WebML, NDT propone representar un modelo de contenido, un modelo de navegación y un modelo de interfaz abstracta. Todos ellos, también se encuentran definidos en un conjunto de metamodelos. La propuesta, analizando tanto los metamodelos de requisitos como los metamodelos de análisis, establece una serie de relaciones entre los artefactos que en ellos aparecen. En base a estas relaciones se definen un conjunto de transformaciones. Así estaba planteada inicialmente la metodología NDT. Sin embargo, en los últimos años ha evolucionado y ofrece soporte completo para todo el ciclo de vida. Abarca las fases de estudio de viabilidad, requisitos, análisis, diseño, construcción, implementación, así como las fases de mantenimiento y de pruebas durante el desarrollo de software, y además establecen nuevas reglas de transformación. En la figura 1 se muestra cómo a partir de la fase de requisitos es posible obtener los modelos de la fase de análisis y de la fase de pruebas. Las reglas de transformación de NDT están representadas en la figura 1 mediante el estereotipo «NDTTransformations», y una vez que han sido aplicadas, el equipo de analistas puede pueden realizar transformaciones controladas con el objetivo de completar y enriquecer los modelos para obtener el modelo definitivo. Este paso no es automático y requiere la experiencia del analista. Estas transformaciones están representadas en la figura 1 mediante el estereotipo «NDTSupport». Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 32 Figura 1. Generación de los modelos de análisis de pruebas desde los requisitos Por otra parte, NDT es compatible con un conjunto de procesos para llevar a cabo la gestión de proyectos, seguridad y garantía de calidad. Este conjunto de procesos se definen en detalle en el trabajo NDTQFramework, presentado en la siguiente sección. Una ventaja es que NDT se puede utilizar en el entorno empresarial de forma satisfactoria. Hoy en día, un elevado número de empresas en España trabajan con NDT en el desarrollo de software. Esto es posible debido al hecho de que NDT está totalmente apoyado por un conjunto de herramientas libres, agrupadas en NDTSuite. En las siguientes secciones se detalla el conjunto de herramientas que constituyen esta suite. 4. NDTSuite Desde su comienzo, NDT ha sido una propuesta que ha tenido una amplia aplicación en el entorno empresarial. El feedback obtenido tras las aplicaciones prácticas, demostró que la primera herramienta diseñada para dar soporte a NDT, la herramienta NDT-Tool, no resultaba una solución óptima para el trabajo en proyectos reales de gran envergadura y heterogéneos debido principalmente a que NDT-Tool no era flexible; en [6] se justifica esta falta de flexibilidad de NDT-Tool. Por estos motivos, surge la necesidad de desarrollar la nueva suite de herramientas NDT: NDT-Suite. Para desarrollar NDT-Suite lo primero que se hizo fue hacer una extensión de la propia metodología. Tomando las ideas de NDT y siguiendo las premisas marcadas por la metodología Métrica v31, UWE y OOHDM, se hizo una extensión para abordar todo el ciclo de vida. Esta extensión ha sido publicada en [[7]]. De esta forma, y aprovechando las premisas de estos entornos, suficientemente afianzados tanto en la Ingeniería del Software como la Ingeniería Web, y las ideas esenciales de NDT, se ha definido un entorno de trabajo compuesto por las fases de Requisitos, Análisis, Diseño, Construcción e Implantación, Pruebas y Mantenimiento. El hecho de que la elección haya sido Métrica se ha debido a que es la metodología de 1 www.map.es Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 33 referencia en las Administraciones Públicas españolas. UWE fue seleccionado porque es una metodología Web fundamentada sobre UML, aspecto de gran interés debido a que es el lenguaje soportado por Métrica. Y OOHDM fue elegido por ser la primera metodología para la Web, cuyos modelos han sido adaptados y aprobados por toda la comunidad investigadora. La fusión realizada se basa en definir un proceso, similar al de Métrica pero haciendo uso de los modelos de UML y de las extensiones que NDT realiza de ellos, así como de sus procesos de ingeniería guiada por modelos. A lo largo de este apartado se presentan todas las herramientas que actualmente componen NDT-Suite y otras que serán liberadas en breve. 4.1. NDT-Profile El primer trabajo que dio inicio a NDT-Suite fue seleccionar un entorno de herramientas adecuado para trabajar. Tras diferentes estudios se optó por Enterprise Architect [8] (EA en adelante). Esta herramienta, a pesar de no ser de software libre, ofrece un soporte adecuado y su precio es bastante competitivo. Además, ofrece varias ventajas importantes como la posibilidad de definir profiles, herramientas para la gestión de documentación, etc. que han resultado de gran interés para nuestro trabajo. La ampliación de la metodología NDT supuso la definición de nuevos metamodelos y transformaciones para todas las fases del ciclo de vida software. Para cada uno de los metamodelos de NDT se definió un profile en la herramienta EA. Este entorno es lo que se conoce como NDT-Profile. Así, por ejemplo, en la figura 2 se presenta una captura del entorno de trabajo en el que puede verse remarcado a la izquierda los distintos toolbox de NDT. El uso de NDT-Profile ofrece la posibilidad de disponer de todos los artefactos de NDT de una manera sencilla, puesto que están integrados en la propia herramienta pero, además, también permite utilizar todos los modelos de UML e integrarlos fácilmente en la metodología. Figura 2. Interfaz principal de NDT-Profile. Toolbox y navegador del proyecto Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 34 4.2. NDT-Quality El uso de NDT-Profile revela un problema importante y es la flexibilidad de trabajo que esta herramienta permite. Con NDT-Profile es posible infringir fácilmente las reglas y relaciones definidas en NDT, las cuales, son esenciales para trabajar con el entorno MDE de la propuesta. Por ello, se ha desarrollado otra herramienta dentro de NDT-Suite que se denomina NDT-Quality. NDT-Quality, figura 3, es una herramienta que automatiza la revisión metodológica de un proyecto desarrollado con NDT-Profile. Se encarga de revisar tanto la calidad de un entregable en cuanto al uso de la metodología NDT en cada una de las fases del ciclo de vida software, como la trazabilidad de las reglas MDE que define NDT entre las distintas fases del ciclo de vida. Además, para facilitar el trabajo en proyectos que siguen ciclos de vida iterativos, la herramienta permite mediante una ventana de conformación seleccionar qué reglas concretas se desean verificar, figura 4. Una vez realizada la revisión, la herramienta proporciona, para cada fase del ciclo de vida software revisada, un listado con los errores o inconsistencias metodológicas detectadas, figura 5. Estos errores se tipifican como leves, graves, o críticos. Entre los aspectos que son revisados por la herramienta se encuentran por ejemplo, completitud en definiciones, definiciones erróneas de restricciones, detección de ciclos en diagramas de clases, etc. Para facilitar la creación de informes, la herramienta permite exportar en un documento en diferentes formatos el listado de inconsistencias encontradas durante la revisión. Finalmente, como valor añadido, la herramienta no sólo se limita a resaltar los errores detectados durante la revisión, sino que también proporciona para cada uno de ellos una guía para resolverlo. Como conclusión final, el uso de NDT-Quality permite garantizar la calidad de cualquier proyecto que siga la metodología NDT. Figura 3. Ventana de configuración de NDT-Quality Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 35 Figura 4. Ventana de NDT-Quality Figura 5. Ventana de informe de NDT-Quality 4.3. NDT-Driver Inicialmente, NDT sólo definía la transformación del modelo de requisitos del proyecto en los modelos de la fase de análisis. A raíz de la ampliación de NDT al resto de fases del ciclo de vida, se tuvieron que definir nuevas transformaciones. Por este motivo, se hizo necesario incorporar esta nueva funcionalidad en la suite de NDT mediante una nueva herramienta: NDT-Driver. NDT-Driver, figura 3, es una de las principales herramientas de soporte de la metodología NDT. Implementa un conjunto de procedimientos automáticos para llevar a cabo cada una de las transformaciones QVT definidas en NDT. Es capaz de generar los modelos de la fase de Análisis desde el modelo de la fase de Requisitos, los modelos de la fase de Diseño desde los modelos de Análisis, y el modelo de pruebas de sistema de la fase de Pruebas desde el modelo de Requisitos. Además, NDT-Driver permite obtener el modelo Requisitos a partir de los requisitos capturados durante la fase de Estudio de Viabilidad del proyecto. Además, para facilitar el trabajo en proyectos que siguen ciclos de vida iterativos, para cada transformación, NDT-Driver le permite al usuario seleccionar el modelo concreto a generar. En la figura 6 se muestra una ventana de configuración en la que aparecen los modelos disponibles para la transformación de Requisitos a Análisis. La aplicación de alguna de las transformaciones que define NDT proporciona, sin duda, una posición aventajada al analista a la hora de desarrollar los distintos modelos de una determinada fase del ciclo de vida. Sin embargo, estos modelos generados de forma automática deben ser mejorados por el analista. Durante este Copyright © AEMES RPM 8 (1) (2011) ISSN 1698-2029 36 proceso de mejora es posible que se detecten requisitos del cliente que no han sido considerados en el modelo origen de la transformación, lo cual, conllevaría retocar el modelo origen y volver a generar el modelo en cuestión, lo cual además conllevaría la pérdida de todo el trabajo realizado por parte del analista en cuanto a la mejora del modelo generado. Como solución a este aspecto, NDT-Driver permite dos modos de transformación: Reconstrucción o Actualización. El modo Reconstrucción consiste en volver a generar un modelo desde cero partiendo del modelo origen y descartando el modelo generado, si éste ha sido previamente generado. Mientras que gracias al modo Actualización, sólo se transforman aquellos elementos del modelo original que han sido modificados. Por ejemplo, si todos los requisitos de almacenamiento han sido ya definidos en la fase de Requisitos, es posible generar el modelo conceptual de la fase de Análisis. Si llegados a este punto, se detectara que algún requisito de almacenamiento no se ha definido según las necesidades del cliente, no es necesario volver a generar de nuevo el modelo conceptual; NDT-Driver permite actualizarlo. Como conclusión final, el uso de NDT-Driver permite reducir cuantitativamente el tiempo de desarrollo de cualquier proyecto que siga la metodología NDT. Figura 6. Interfaz de NDTDriver - Ventana de NDT Driver Figura 7. Interfaz de NDTDriver - Ventana de configuración NDT Driver 4.4. NDT-Report Toda la información descrita y desarrollada en un proyecto realizado en base a la herramienta NDT-Profile, aunque práctica y funcional, no es amigable a la hora de presentar a usuarios y clientes. Por este motivo, se desarrolló y liberó en 2008 la primera versión de una herramienta de generación documental para NDT denominada NDT-Report. Esta herramienta contemplaba la generación de un documento con todos los