REUTILIZACIN EN EL DOMINIO DEL ANLISIS SOFTWARE

Francisco J. Soltero Domingo, Diego J. Bodas Sagi, Valentn Pozo Llorente CES Felipe II (UCM) Ingeniera Tcnica de Informtica de Sistemas

Resumen: Una introduccin al concepto de anlisis de dominio y reutilizacin del software. Una iniciacin a dos de los modelos inspirados en estos conceptos como son: Software Product Line Paradigm y Generative Domain Model. Palabras clave: Reutilizacin, anlisis de dominio, Software Product Line Paradigm, Generative Domain Model.

1.- Introduccin El concepto de reutilizacin software no es una idea nueva en el mundo de la informtica. Los primero programadores ya copiaban y pegaban lneas de cdigo realizadas en desarrollos anteriores. De hecho la reutilizacin es cualquier procedimiento que produce o ayuda a producir un sistema mediante el nuevo uso de algn elemento procedente de un esfuerzo de desarrollo anterior (Freeman, 1987). En un proyecto software intervienen una gran cantidad de procesos. La norma IEEE 12207 divide estos procesos en principales, de soporte, de organizacin y de adaptacin. 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 reutilizacin de los procesos principales y ms concretamente en el proceso de desarrollo software. Las distintas metodologas dividen este proceso en fases. En el caso de la metodologa Mtrica 3.0 estas son las siguientes: Planificacin, anlisis, diseo, cdigo e implementacin. La planificacin, se encuentra ligada con la adquisicin de los procedimientos del sistema de informacin. En cuanto al anlisis, este se centra bsicamente en tres actividades: modelado de los procedimientos, bsqueda 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 preocupacin es la obtencin de un metamodelo valido en el dominio del problema. Una vez obtenido, se pasa a la instanciacin de un modelo ptimo para la arquitectura propuesta. Aqu es donde entran en juego las siguientes fases: diseo, cdigo e implementacin. En estas, se propone y realiza la bsqueda de una buena solucin. Estas tres fases componen el denominado espacio de la solucin. Un factor diferencial de sendos espacios es su nivel de abstraccin, siendo mucho ms elevado en el espacio del problema que en el de la solucin. Esto es debido al nivel de detalle de ambos modelos. Este hecho afecta de manera determinante a la reutilizacin 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

de la solucin, este slo puede ser reutilizado en soluciones parecidas. Por tanto, conforme nuestro nivel de abstraccin sea mayor o menos elevado, la capacidad de reutilizacin ser menor. Un ejemplo de los distintos niveles de reutilizacin en los espacios propuestos lo podemos observar en la industria del automvil. Si fijamos los planos de un coche como el espacio del problema, podemos observar que estos mismos planos pueden ser utilizados en la realizacin 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 solucin. Evidentemente un modelo concreto puede tener distintos motores o distintos accesorios, por tanto en el espacio de la solucin tambin es posible la reutilizacin, pero en un grado menor debido al nivel de detalle que ya ha alcanzado el modelo. En este artculo nos centraremos en la reutilizacin en la fase de anlisis. En los siguientes captulos realizaremos una introduccin al concepto del anlisis de dominio, para posteriormente ver dos modelos basados en la misma idea y finalizaremos con las conclusiones. 2.- Anlisis de dominio (Domain Analysis). En la fase de anlisis de una aplicacin software, la principal prioridad se centra en la adquisicin de los requisitos para obtener una especificacin software correcta. En este proceso, por norma general se obtiene un modelo validado para un problema determinado. Sin embargo, en un proceso de reutilizacin para la fase de anlisis, lo que se busca es la obtencin de un modelo genrico para un dominio concreto. El cual ser aplicable a mltiples problemas dentro de ese dominio. Por tanto, la reutilizacin 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 anlisis de dominio (Domain Analysis). Para entenderlo mejor vamos a aportar varias definiciones de algunos de los autores ms importantes en esta rea. 2.1.- Definiciones de Domain Analysis: 1.- Berard nos ofrece dos caracterizaciones (Berard, 1992): 1.1.- Una coleccin de aplicaciones, actuales y futuras, que muestran un conjunto de caractersticas comunes 1.2.- Un conjunto bien definido de caractersticas que describe una familia de problemas de forma precisa, somera y completa para los cuales las aplicaciones informticas buscan solucin. 2.- Definicin segn Prieto-Daz (Arango, 1991, p 14) Un proceso por el cual la informacin utilizada en el desarrollo de sistemas software es identificada, capturada, y organizada con el propsito de hacerla reutilizable cuando generemos nuevos sistemas.

Fuentes de Conocimiento Del Dominio

Mtodos del Procesos de Anlisis del Gestin Dominio

Asesoramiento experto Taxonomas Literatura Tcnica Imp. Req. Existentes Requisitos de los Clientes Actuales y Futuros Requerimientos

Anlisis de Dominio

Estndares 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 mltiples 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 tcnica, implementaciones existentes, lneas 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 anlisis. En cuanto a las salidas nos encontramos con conceptos semiformales como: procesos de dominio, estndares, taxonomias, lenguajes de dominio etc... Por tanto, el desarrollo de un sistema en particular puede ser utilizado como fuente de conocimiento en prximos desarrollos (Prieto-Daz, 1989). Un ejemplo de este tipo de reutilizacin podemos encontrarla en las tradicionales aplicaciones de gestin de sistemas de informacin de negocio. Supongamos la gestin de un almacn. Los elementos o entidades ms importantes son siempre los mismos: productos, caractersticas y propiedades de los productos, proveedores, clientes, ventas, catlogo de productos etc. Adems estas entidades se desarrollan normalmente sobre escenarios fijos. Las funcionalidades a desarrollar son: alta, baja, modificacin o eliminacin de cada una de ellas. Adems podemos desarrollar herramientas de soporte a la toma de decisiones como: nivel mnimo de existencias, seleccin de mejores ofertas etc... Todos estos elementos, junto con sus restricciones y dependencias, conformaran el anlisis de dominio de un almacn. Ya en el espacio de la solucin se puede optar por realizar un diseo distribuido, un diseo para aplicacin Web etc... . Igualmente en lo referente a la implementacin del lenguajes de programacin.

En el caso concreto de que en un futuro prximo alguna compaa estuviere interesada en la realizacin de un software de gestin de almacn, slo tendramos que revisar los productos concretos de esa empresa y posiblemente aadir alguna funcionalidad nueva en algn escenario, pero, en esencia, la mayor parte del desarrollo se encuentra en nuestro anlisis de dominio. La reutilizacin de los distintos escenarios, tambin se puede ver favorecida en la seleccin de componentes ya realizados en niveles de abstraccin inferior, como un diseo concreto y el cdigo para implementar dicho diseo. Por tanto, y citando a uno de los pioneros en la materia (Neighbors, 1984) , La llave de la reusabilidad software es capturada en el anlisis de dominio y est centrada en la reusabilidad del anlisis y del diseo, no en el cdigo. 3.- Modelos basados en el Anlisis de Dominio La idea del anlisis de dominio ha sido desarrollada en los ltimos 30 aos por distintos autores, como podemos observar en la figura 2. El desarrollo histrico de estos modelos ha desembocado en varios paradigmas. En este apartado slo se van a introducir los conceptos bsicos de dos de los modelos ms 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. Genealoga parcial de la ingeniera del dominio

3.1.- Software Product Line Paradigm Este paradigma, basado en los principios anteriormente expuestos, trata de analizar una lnea de productos concretos (Clements, 2001), y a partir del estudio de estos, realizar su anlisis de dominio correspondiente. En este modelo debemos asegurar las capacidades necesarias para los productos actuales. Adems se debe realizar un estudio de mercado profundo de los requerimientos y variaciones de estos mismos productos en el futuro.

Una definicin de este paradigma la podemos encontrar en el documento tcnico 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 generacin de un modelo requiere de un esfuerzo grande por parte de la organizacin. 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

Producto 3 DOMINIO COMN

Producto 1

Figura3. Requerimientos de la Lnea de Productos Este paradigma, una vez establecido en la lnea de productos de una compaa, permite reducir los costes para cada nuevo producto. Los beneficios de la adopcin se puede observar en las siguientes reas de desarrollo de un producto software (Weiss, 1999): Anlisis de requisitos: La mayora de los requisitos son comunes con sistemas anteriores y por lo tanto pueden ser utilizados. Viabilidad del diseo arquitectnico: Una arquitectura para un sistema de software representa una inversin grande en tiempo y recursos para cualquier organizacin. 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 diseos detallados para los componentes arquitectnicos se reutilizan de sistema en sistema, al igual que la documentacin de esos diseos. Las

estructuras y los algoritmos de datos se ahorran y no necesitan ser realizados nuevamente Modelado y Anlisis: Permite eliminar la mayor parte de trabajo que en situacin normal absorben la mayor parte de quebraderos de cabeza para cualquier empresa. Prueba: Los planes, procesos, casos, documentacin, generadores e iniciadores de la prueba, ya han sido creados. Planificacin: La estimacin de costes y la planificacin asociada a un proyecto se puede reutilizar de proyectos anteriores. Siendo lgicamente los resultados de esta estimacin y esta planificacin mucho ms confiables. Procesos: Los procedimientos y las herramientas para el control de la configuracin, ya han sido utilizados con anterioridad, por tanto, son robustos, confiables, y responden a las necesidades de la organizacin, 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 adems su experiencia puede ser utilizada en el resto de productos que desarrollemos.

3.2.- Generative Domain Model Tambin considerado como un nuevo paradigma en el desarrollo del software. Este est basado en dos aspectos. Por un lado la realizacin de familias de sistemas software y, por otro, el intento de una mayor automatizacin en el desarrollo de los mismos (Czarnecki, 2004). Este modelo conocido como modelo generativo del dominio consiste en la obtencin de los siguientes elementos: a.- Un mtodo para especificar a los miembros de la familia; b.- Mdulos para que cada miembro puede ser montado. c.- El conocimiento de la configuracin 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 aplicacin y las caractersticas que los ingenieros de la aplicacin 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 configuracin. Se especifica, entre otras, aquellas caractersticas combinaciones ilegales, configuraciones por defecto, dependencias por defecto, reglas de construccin y optimizaciones. El conocimiento de esta configuracin puede ser implementada usando

diferentes formularios de meta programacin, por ejemplo dynamic reflection, object factories, y programas generadores. c.- El espacio de la solucin. Este espacio comprende la implementacin de componentes y las arquitecturas de las familias de sistemas, definiendo todas las combinaciones validas de los componentes de la implementacin. Estos componentes son diseados para una mxima combinacin y reutilizacin y una mnima redundancia.

Espacio del Problema Dominio Especifico Trminos y caractersticas

Espacio de la Solucin Conocimiento de la Configuracin Combinaciones de caractersticas prohibidas Valores por defecto. Dependencias Construcciones Manuales Optimizaciones Componentes Elementales Mximo nmero de combinaciones Mnimas 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. Tambin podemos crear nuestro propio generador usando DSLs; (Domain Specific Language). En esta rea hay muchas tendencias nuevas basadas en estndares abiertos que son creados por la OMG (Object Management Group). Siguiendo con el ejemplo del automvil se puede decir que este mtodo es algo similar a la peticin de un coche por parte de un cliente. En primer lugar rellenaramos un formulario con los componentes deseados, en este caso los componentes del dominio, lgicamente 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.

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 ingenieras tendemos a una estandarizacin de nuestros procesos, lo que permitir reducir los tiempos y costes, a la vez que aumentar la calidad de los mismos. La reutilizacin es uno de los conceptos ms importantes en el mundo de la informtica actual. Como hemos podido observar esta se hace ms efectiva en los primeros niveles de desarrollo. Conseguir un buen anlisis de dominio basado en familias de sistemas que guardan cierta similitud, permite desarrollos ms rpidos y a un coste muy inferior. Son muchas las empresas que ya utilizan en la prctica los modelos anteriormente citados, Nokia, Bosch, Boeing, Ministerio de Defensa de USA, y un largo etctera de organismos, tanto pblicos como privados. En una comparativa de los modelos propuestos, podemos observar como en el primero de ellos, la base de la reutilizacin se encuentra en un estudio inicial de mercado para la obtencin de las partes variables y comunes de los futuros productos a desarrollar. Mientras que en el segundo se enfatiza ms en la utilizacin de generadores que de forma automtica y a partir de un anlisis de dominio obtengan el cdigo final de la aplicacin. Por tanto, ambos modelos lejos de ser excluyentes, se complementan en la consecucin de productos software reutilizables. Por ejemplo, la empresa Nokia utiliza este modelo de desarrollo en todos sus telfonos mviles, lo que le permite generar ms de 90 modelos distintos al ao a un coste prcticamente irrisorio. Una vez establecido el modelo de dominio, el nmero de funcionalidades y caractersticas que incorpora de un modelo a otro es muy pequeo y por tanto slo es necesario desarrollar este pequeo conjunto, el cual una vez desarrollado pasa a ser parte del modelo del dominio, y por tanto puede ser implementado en cualquier otro telfono mvil (producto) que se desarrolle con posterioridad.

5. Bibliografa Arango, G. Prieto-Diaz, R., "Domain Analysis Concepts and Research Directions in Domain Analysis and Software Systems Modeling, IEEE Computer Society, 1991, pp. 9-33. Berard, E., Essays in Object-Oriented Software Engineering, Nueva York, Prentice Hall, 1992. Chastek, G. et al., Product Line Analysis: A Practical Introduction, tech. report CMU/SEI2001-TR-001, Pittsburgh, Software Eng. Inst., Carnegie Mellon Univ., 2001. Clements, P. Northrop, L., Software Product Lines: Practices and Patterns, Reading, Mass., Addison Wesley Longman, 2001. Czarnecki, K. Eisenecker, U., Generative Programming: Methods, Tools, and Applications, Reading, Mass., Addison Wesley Longman, 2004. Freeman, P., IEEE tutorial: Software reusability, Washington, IEEE Computer Society Press, 1987.

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, 2002. Moore J. W., Software Engineering: A User's Road Map, Los Alamitos, CA, IEEE Computer Society Press, 1997. Neighbors, J.M., The draco approach to constructing software from reusable components, IEEE Transactions of Software Engineering, SE-10(5), 1984. Prieto-Diaz, R. Arango, G., Domain Analysis: Acquisition of Reusable Information for Software Construction, Los Alamitos, IEEE Computer Society Press, 1989. Weiss D.M, Lai C.T.R., Software Product-Line Engineering: A Family-Based Software Development Process, Reading, Mass., Addison Wesley Longman, 1999.