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.
 Mtodos del Procesos de
Fuentes de Conocimiento Anlisis del Gestin
Del Dominio Dominio

Asesoramiento experto
Taxonomas
Literatura Tcnica
Anlisis de
Estndares
Imp. Req. Existentes Dominio

Requisitos de los Modelos Funcionales

Clientes
Actuales y Futuros Lenguajes de Dominio
Requerimientos

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 DARE
Por Prieto-Diaz Por Frake et al. Generative
Domain Model
Por Czarnecki et al.

ODM
Draco Por Simos et al.
FODA
Por Neighbors
Por Kang et al.
DARE
Por Frake et al.

Software Product Line

KAPTUR
Por Paul Clements et al.
Por Bailin

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 de la
Solucin
Espacio del
Problema Conocimiento de la Configuracin
Componentes
Combinaciones de caractersticas Elementales
Dominio
Especifico prohibidas
Valores por defecto. Mximo nmero
Dependencias de combinaciones
Trminos y
caractersticas Construcciones Manuales
Optimizaciones Mnimas
redundancias

LENGUAJE ESPECIFICO GENERADOR COMPONENTES +

DE DOMINIO 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/SEI-
2001-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.