REUTILIZACIÓN EN EL DOMINIO DEL ANÁLISIS SOFTWARE

Transcripción

1 REUTILIZACIÓN EN EL DOMINIO DEL ANÁLISIS SOFTWARE Francisco J. Soltero Domingo, Diego J. Bodas Sagi, Valentín Pozo Llorente CES Felipe II (UCM) Ingeniería Técnica de Informática de Sistemas Resumen: Una introducción al concepto de análisis de dominio y reutilización del software. Una iniciación a dos de los modelos inspirados en estos conceptos como son: Software Product Line Paradigm y Generative Domain Model. Palabras clave: Reutilización, análisis de dominio, Software Product Line Paradigm, Generative Domain Model. 1.- Introducción El concepto de reutilización software no es una idea nueva en el mundo de la informática. Los primero programadores ya copiaban y pegaban líneas de código realizadas en desarrollos anteriores. De hecho la reutilización es cualquier procedimiento que produce o ayuda a producir un sistema mediante el nuevo uso de algún elemento procedente de un esfuerzo de desarrollo anterior (Freeman, 1987). En un proyecto software intervienen una gran cantidad de procesos. La norma IEEE divide estos procesos en principales, de soporte, de organización y de adaptación. Estos a su vez se dividen en otros subprocesos. Por tanto, en el ciclo de vida del software son muchos los elementos susceptibles de ser reutilizados (Moore, 1997). En este marco tan extenso, este articulo se va a centrar en la reutilización de los procesos principales y más concretamente en el proceso de desarrollo software. Las distintas metodologías dividen este proceso en fases. En el caso de la metodología Métrica 3.0 estas son las siguientes: Planificación, análisis, diseño, código e implementación. La planificación, se encuentra ligada con la adquisición de los procedimientos del sistema de información. En cuanto al análisis, este se centra básicamente en tres actividades: modelado de los procedimientos, búsqueda de roles y escenarios y establecimiento de una arquitectura software estable para el modelo propuesto. Estas dos fases iniciales componen, lo que algunos autores denominan el espacio del problema. En este, la principal preocupación es la obtención de un metamodelo valido en el dominio del problema. Una vez obtenido, se pasa a la instanciación de un modelo óptimo para la arquitectura propuesta. Aquí es donde entran en juego las siguientes fases: diseño, código e implementación. En estas, se propone y realiza la búsqueda de una buena solución. Estas tres fases componen el denominado espacio de la solución. Un factor diferencial de sendos espacios es su nivel de abstracción, siendo mucho más elevado en el espacio del problema que en el de la solución. Esto es debido al nivel de detalle de ambos modelos. Este hecho afecta de manera determinante a la reutilización que podemos realizar de los mismos. En el espacio del problema, contamos con un metamodelo para un dominio en particular, el cual puede ser reutilizado en distintas soluciones y para distintas arquitecturas. El metamodelo las únicas restricciones que posee son las propias de los componentes del dominio. Una vez instanciado el modelo para un problema concreto, espacio

2 de la solución, este sólo puede ser reutilizado en soluciones parecidas. Por tanto, conforme nuestro nivel de abstracción sea mayor o menos elevado, la capacidad de reutilización será menor. Un ejemplo de los distintos niveles de reutilización en los espacios propuestos lo podemos observar en la industria del automóvil. Si fijamos los planos de un coche como el espacio del problema, podemos observar que estos mismos planos pueden ser utilizados en la realización de distintos modelos de coches. Simplemente es un metamodelo de los elementos que componen el dominio de un coche y las restricciones entre los mismos. Una vez instanciado un modelo, pasamos al espacio de la solución. Evidentemente un modelo concreto puede tener distintos motores o distintos accesorios, por tanto en el espacio de la solución también es posible la reutilización, pero en un grado menor debido al nivel de detalle que ya ha alcanzado el modelo. En este artículo nos centraremos en la reutilización en la fase de análisis. En los siguientes capítulos realizaremos una introducción al concepto del análisis de dominio, para posteriormente ver dos modelos basados en la misma idea y finalizaremos con las conclusiones. 2.- Análisis de dominio ( Domain Analysis ). En la fase de análisis de una aplicación software, la principal prioridad se centra en la adquisición de los requisitos para obtener una especificación software correcta. En este proceso, por norma general se obtiene un modelo validado para un problema determinado. Sin embargo, en un proceso de reutilización para la fase de análisis, lo que se busca es la obtención de un modelo genérico para un dominio concreto. El cual será aplicable a múltiples problemas dentro de ese dominio. Por tanto, la reutilización en esta fase está ligada al estudio de los elementos de un dominio, sus dependencias y restricciones. Conceptualmente a todo este proceso se le denomina análisis de dominio ( Domain Analysis ). Para entenderlo mejor vamos a aportar varias definiciones de algunos de los autores más importantes en esta área Definiciones de Domain Analysis : 1.- Berard nos ofrece dos caracterizaciones (Berard, 1992): Una colección de aplicaciones, actuales y futuras, que muestran un conjunto de características comunes Un conjunto bien definido de características que describe una familia de problemas de forma precisa, somera y completa para los cuales las aplicaciones informáticas buscan solución. 2.- Definición según Prieto-Díaz (Arango, 1991, p 14) Un proceso por el cual la información utilizada en el desarrollo de sistemas software es identificada, capturada, y organizada con el propósito de hacerla reutilizable cuando generemos nuevos sistemas.

3 Fuentes de Conocimiento Del Dominio Métodos del Análisis del Dominio Procesos de Gestión Asesoramiento experto Literatura Técnica Imp. Req. Existentes Requisitos de los Clientes Actuales y Futuros Requerimientos Análisis de Dominio Taxonomías Estándares Modelos Funcionales Lenguajes de Dominio Implementador de la Infraestructura Analista de infraestructura Analista de Dominio Experto en el Dominio del problema Figura 1. Domain Analysis Model Como podemos observar en la Figura 1, este modelo describe Domain Analysis como una actividad que toma múltiples fuentes de entrada y produce muchos tipos de salidas diferentes, y es altamente parametrizable. Las fuentes de entrada son tomadas del dominio del conocimiento: literatura técnica, implementaciones existentes, líneas expertas, actuales y futuros requerimientos, cuestiones de clientes etc.. Los participantes en el proceso pueden ser, entre otros, expertos en el dominio y en el análisis. En cuanto a las salidas nos encontramos con conceptos semiformales como: procesos de dominio, estándares, taxonomias, lenguajes de dominio etc... Por tanto, el desarrollo de un sistema en particular puede ser utilizado como fuente de conocimiento en próximos desarrollos (Prieto-Díaz, 1989). Un ejemplo de este tipo de reutilización podemos encontrarla en las tradicionales aplicaciones de gestión de sistemas de información de negocio. Supongamos la gestión de un almacén. Los elementos o entidades más importantes son siempre los mismos: productos, características y propiedades de los productos, proveedores, clientes, ventas, catálogo de productos etc. Además estas entidades se desarrollan normalmente sobre escenarios fijos. Las funcionalidades a desarrollar son: alta, baja, modificación o eliminación de cada una de ellas. Además podemos desarrollar herramientas de soporte a la toma de decisiones como: nivel mínimo de existencias, selección de mejores ofertas etc... Todos estos elementos, junto con sus restricciones y dependencias, conformarían el análisis de dominio de un almacén. Ya en el espacio de la solución se puede optar por realizar un diseño distribuido, un diseño para aplicación Web etc.... Igualmente en lo referente a la implementación del lenguajes de programación.

4 En el caso concreto de que en un futuro próximo alguna compañía estuviere interesada en la realización de un software de gestión de almacén, sólo tendríamos que revisar los productos concretos de esa empresa y posiblemente añadir alguna funcionalidad nueva en algún escenario, pero, en esencia, la mayor parte del desarrollo se encuentra en nuestro análisis de dominio. La reutilización de los distintos escenarios, también se puede ver favorecida en la selección de componentes ya realizados en niveles de abstracción inferior, como un diseño concreto y el código para implementar dicho diseño. Por tanto, y citando a uno de los pioneros en la materia (Neighbors, 1984), La llave de la reusabilidad software es capturada en el análisis de dominio y está centrada en la reusabilidad del análisis y del diseño, no en el código. 3.- Modelos basados en el Análisis de Dominio La idea del análisis de dominio ha sido desarrollada en los últimos 30 años por distintos autores, como podemos observar en la figura 2. El desarrollo histórico de estos modelos ha desembocado en varios paradigmas. En este apartado sólo se van a introducir los conceptos básicos de dos de los modelos más actuales. FORM Por Kang et al. Fsceted Classification Por Prieto-Diaz DARE Por Frake et al. Generative Domain Model Por Czarnecki et al. Draco Por Neighbors FODA Por Kang et al. ODM Por Simos et al. DARE Por Frake et al. KAPTUR Por Bailin Software Product Line Por Paul Clements et al.... FAST Por Weiss et al. Figura 2. Genealogía parcial de la ingeniería del dominio Software Product Line Paradigm Este paradigma, basado en los principios anteriormente expuestos, trata de analizar una línea de productos concretos (Clements, 2001), y a partir del estudio de estos, realizar su análisis de dominio correspondiente. En este modelo debemos asegurar las capacidades necesarias para los productos actuales. Además se debe realizar un estudio de mercado profundo de los requerimientos y variaciones de estos mismos productos en el futuro.

5 Una definición de este paradigma la podemos encontrar en el documento técnico CMU/SEI-2001-TR-001(Chastek, 2001, p 34) y es la siguiente: A software product line is a set of software-intensive systems sharing a common, manager set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Se hace evidente que la generación de un modelo requiere de un esfuerzo grande por parte de la organización. Por tanto, y como se puede observar en la Figura 3, hay que garantizar que éste sea rentable en un futuro para la empresa. Por tanto, el estudio de los productos actuales, y aquellos que se vayan a realizar, es fundamental para ver la viabilidad del proyecto (Kang, 2002). Producto 2 DOMINIO COMÚN Producto 3 Producto 1 Figura3. Requerimientos de la Línea de Productos Este paradigma, una vez establecido en la línea de productos de una compañía, permite reducir los costes para cada nuevo producto. Los beneficios de la adopción se puede observar en las siguientes áreas de desarrollo de un producto software (Weiss, 1999): Análisis de requisitos: La mayoría de los requisitos son comunes con sistemas anteriores y por lo tanto pueden ser utilizados. Viabilidad del diseño arquitectónico: Una arquitectura para un sistema de software representa una inversión grande en tiempo y recursos para cualquier organización. Por tanto, si iniciamos un nuevo sistema y hacemos un gran esfuerzo en el desarrollo de su arquitectura, debemos contemplar que este esfuerzo sea recuperado en el desarrollo de productos posteriores. Esto se consigue de manera satisfactoria con este paradigma. Componentes: Los diseños detallados para los componentes arquitectónicos se reutilizan de sistema en sistema, al igual que la documentación de esos diseños. Las

6 estructuras y los algoritmos de datos se ahorran y no necesitan ser realizados nuevamente Modelado y Análisis: Permite eliminar la mayor parte de trabajo que en situación normal absorben la mayor parte de quebraderos de cabeza para cualquier empresa. Prueba: Los planes, procesos, casos, documentación, generadores e iniciadores de la prueba, ya han sido creados. Planificación: La estimación de costes y la planificación asociada a un proyecto se puede reutilizar de proyectos anteriores. Siendo lógicamente los resultados de esta estimación y esta planificación mucho más confiables. Procesos: Los procedimientos y las herramientas para el control de la configuración, ya han sido utilizados con anterioridad, por tanto, son robustos, confiables, y responden a las necesidades de la organización, entre lo que se puede hallar el propio CMMI. Recursos Humanos: Debido al uso del mismo, las capacidades del personal involucrado en estos proyectos mejora, y además su experiencia puede ser utilizada en el resto de productos que desarrollemos Generative Domain Model También considerado como un nuevo paradigma en el desarrollo del software. Este está basado en dos aspectos. Por un lado la realización de familias de sistemas software y, por otro, el intento de una mayor automatización en el desarrollo de los mismos (Czarnecki, 2004). Este modelo conocido como modelo generativo del dominio consiste en la obtención de los siguientes elementos: a.- Un método para especificar a los miembros de la familia; b.- Módulos para que cada miembro puede ser montado. c.- El conocimiento de la configuración para traducir las especificaciones en implementaciones Este modelo consiste de tres espacios de desarrollo, como podemos ver en la Figura 4. a.- El espacio del problema. Consiste de conceptos orientados a la aplicación y las características que los ingenieros de la aplicación software utilizan para expresar sus necesidades. Este espacio es implementado como un lenguaje especifico de dominio (Domain Specific Language). b.- El espacio del conocimiento de la configuración. Se especifica, entre otras, aquellas características combinaciones ilegales, configuraciones por defecto, dependencias por defecto, reglas de construcción y optimizaciones. El conocimiento de esta configuración puede ser implementada usando

7 diferentes formularios de meta programación, por ejemplo dynamic reflection, object factories, y programas generadores. c.- El espacio de la solución. Este espacio comprende la implementación de componentes y las arquitecturas de las familias de sistemas, definiendo todas las combinaciones validas de los componentes de la implementación. Estos componentes son diseñados para una máxima combinación y reutilización y una mínima redundancia. Espacio del Problema Dominio Especifico Términos y características Conocimiento de la Configuración Combinaciones de características prohibidas Valores por defecto. Dependencias Construcciones Manuales Optimizaciones Espacio de la Solución Componentes Elementales Máximo número de combinaciones Mínimas redundancias LENGUAJE ESPECIFICO DE DOMINIO GENERADOR COMPONENTES + ARQUITECTURA DE LA FAMILIA DE SISTEMAS Figura 4. Modelo generativo del dominio Hay varios sistemas generadores, uno de ellos es ANGIE, un sistema generador que abarca un lenguaje especifico de dominio, un compilador y un sistema runtime asociado. Es un sistema modular extensible para los generadores del software. También podemos crear nuestro propio generador usando DSLs; ( Domain Specific Language ). En esta área hay muchas tendencias nuevas basadas en estándares abiertos que son creados por la OMG (Object Management Group). Siguiendo con el ejemplo del automóvil se puede decir que este método es algo similar a la petición de un coche por parte de un cliente. En primer lugar rellenaríamos un formulario con los componentes deseados, en este caso los componentes del dominio, lógicamente con las dependencias y restricciones entre ellos. Posteriormente un experto se encarga del montaje del coche. Idealmente, el procedimiento de montaje debe ser ejecutado tan automatizado como sea posible. En nuestro caso el encargado de montar el software es el generador.

8 4. Conclusiones Estos nuevos paradigmas del software nos ofrecen las bases del desarrollo software en el futuro. Es evidente que, como en el resto de las ingenierías tendemos a una estandarización de nuestros procesos, lo que permitirá reducir los tiempos y costes, a la vez que aumentar la calidad de los mismos. La reutilización es uno de los conceptos más importantes en el mundo de la informática actual. Como hemos podido observar esta se hace más efectiva en los primeros niveles de desarrollo. Conseguir un buen análisis de dominio basado en familias de sistemas que guardan cierta similitud, permite desarrollos más rápidos y a un coste muy inferior. Son muchas las empresas que ya utilizan en la práctica los modelos anteriormente citados, Nokia, Bosch, Boeing, Ministerio de Defensa de USA, y un largo etcétera de organismos, tanto públicos como privados. En una comparativa de los modelos propuestos, podemos observar como en el primero de ellos, la base de la reutilización se encuentra en un estudio inicial de mercado para la obtención de las partes variables y comunes de los futuros productos a desarrollar. Mientras que en el segundo se enfatiza más en la utilización de generadores que de forma automática y a partir de un análisis de dominio obtengan el código final de la aplicación. Por tanto, ambos modelos lejos de ser excluyentes, se complementan en la consecución de productos software reutilizables. Por ejemplo, la empresa Nokia utiliza este modelo de desarrollo en todos sus teléfonos móviles, lo que le permite generar más de 90 modelos distintos al año a un coste prácticamente irrisorio. Una vez establecido el modelo de dominio, el número de funcionalidades y características que incorpora de un modelo a otro es muy pequeño y por tanto sólo es necesario desarrollar este pequeño conjunto, el cual una vez desarrollado pasa a ser parte del modelo del dominio, y por tanto puede ser implementado en cualquier otro teléfono móvil (producto) que se desarrolle con posterioridad. 5. Bibliografía Arango, G. Prieto-Diaz, R., "Domain Analysis Concepts and Research Directions in Domain Analysis and Software Systems Modeling, IEEE Computer Society, 1991, pp Berard, E., Essays in Object-Oriented Software Engineering, Nueva York, Prentice Hall, Chastek, G. et al., Product Line Analysis: A Practical Introduction, tech. report CMU/SEI TR-001, Pittsburgh, Software Eng. Inst., Carnegie Mellon Univ., Clements, P. Northrop, L., Software Product Lines: Practices and Patterns, Reading, Mass., Addison Wesley Longman, Czarnecki, K. Eisenecker, U., Generative Programming: Methods, Tools, and Applications, Reading, Mass., Addison Wesley Longman, Freeman, P., IEEE tutorial: Software reusability, Washington, IEEE Computer Society Press, 1987.

9 Kang, K. et al., Using a Marketing and Product Plan as a Key Design Driver for Product Line Asset Development G. Chastek, ed., Proc. 2nd Software Product Line Conf., Springer Lecture Notes in Computer Science, vol. 2379, Moore J. W., Software Engineering: A User's Road Map, Los Alamitos, CA, IEEE Computer Society Press, Neighbors, J.M., The draco approach to constructing software from reusable components, IEEE Transactions of Software Engineering, SE-10(5), Prieto-Diaz, R. Arango, G., Domain Analysis: Acquisition of Reusable Information for Software Construction, Los Alamitos, IEEE Computer Society Press, Weiss D.M, Lai C.T.R., Software Product-Line Engineering: A Family-Based Software Development Process, Reading, Mass., Addison Wesley Longman, 1999.