1

Desarrollo de Software Basado en Componentes

Jonás A. Montilva C. 1, Nelson Arapé 2 y Juan Andrés Colmenares2
1 2
Universidad de Los Andes Universidad del Zulia
Facultad de Ingeniería Facultad de Ingeniería
Escuela de Ingeniería de Sistemas Instituto de Cálculo
Departamento de Computación Aplicado Maracaibo -
Mérida – Venezuela Venezuela
+58-274-2403811

jonas@ing.ula.ve, narape@ica.luz.ve, juancol@ica.luz.ve

comúnmente utilizadas desde la década de los
setenta, representan uno de los primeros intentos
Resumen-- La Orientación a Objetos por reutilizar software.
introdujo, durante la década pasada, un Existen variadas definiciones del término
cambio radical en el proceso de desarrollo de Reutilización de Software. Algunas de estas
software. De un proceso caracterizado por su definiciones son las siguientes:
énfasis en la descripción algorítmica de la • Según Somerville [1], la reutilización es un
solución del problema, se pasó a un proceso enfoque de desarrollo [de software] que trata
orientado a la representación y manipulación de maximizar el uso recurrente de
de los objetos que caracterizan el problema. componentes de software existentes.
Este paradigma abrió, también, nuevas • Según Sametinger [2], la reutilización de
posibilidades para desarrollar software basado software es el proceso de crear sistemas de
en la noción de reutilización de componentes. software a partir de software existente, en
La Orientación a Objetos creó un rumbo lugar de desarrollarlo desde el comienzo.
diferente en el proceso de reutilización a través • Según Sodhi et al. [3], la reutilización de
de la producción de componentes genéricos, software es el proceso de implementar o
fáciles de integrar, distribuidos e actualizar sistemas de software usando
independientes de las plataformas de activos de software existentes.
desarrollo. En este artículo, de carácter Estas tres definiciones consideran la
tutorial, se discuten los conceptos reutilización como un enfoque o proceso de
fundamentales de la reutilización de software, desarrollo de software. Su principal diferencia
así como los modelos de procesos y los aspectos radica en el objeto de reutilización (componente,
metodológicos que caracterizan esta nueva software y activo). Tal como lo plantean Sodhi et
manera de producir software, denominada al. [3], la reutilización de software va más allá de
Desarrollo de Software basado en la reutilización de piezas de software. Ella
Componentes. involucra el uso de otros elementos de software,
tales como algoritmos, diseños, arquitecturas de
Palabras clave—desarrollo de software, software, documentación y especificaciones de
reutilización de software, componentes de requerimientos.
software. Con base en el análisis de estas definiciones
podemos establecer nuestra propia definición en
los siguientes términos:
I. INTRODUCCIÓN La reutilización de software es un proceso de
La reutilización de componentes de software la Ingeniería de Software que conlleva al uso
es un proceso inspirado en la manera en que se recurrente de activos de software en la
producen y ensamblan componentes en la especificación, análisis, diseño,
ingeniería de sistemas físicos. La aplicación de implementación y pruebas de una aplicación o
este concepto al desarrollo de software no es sistema de software.
nueva. Las librerías de subrutinas especializadas, Varios estudios han demostrado la efectividad
de la reutilización del software. Sametinger [2],
 en particular, describe algunos de estos aplicaciones. Ejemplos de activos reutilizables
indicadores: son: algoritmos, patrones de diseño, esquemas de
• Entre el 40 y 60% del código fuente de una base de datos, arquitecturas de software,
aplicación es reutilizable en otra similar. especificaciones de requerimientos, de diseño y
de prueba, entre otros.
En los últimos años, como resultado de
presiones crecientes sobre la industria del
• Aproximadamente el 60% del diseño y del 2
código de aplicaciones administrativas es
reutilizable.
• Aproximadamente el 75% de las funciones son software orientadas a reducir drásticamente el
comunes a más de un programa. costo y tiempo de desarrollo de sistemas y
• Sólo el 15% del código encontrado en muchos aplicaciones, sin afectar los niveles de calidad del
sistemas es único y novedoso a una producto, ha surgido un nuevo activo reutilizable
aplicación específica. El rango general de uso denominado Componente de Software. Se han
recurrente potencial está entre el 15% y el propuesto numerosas definiciones a este término,
85%. entre las cuales destacan las siguientes:
A partir de estos indicadores es fácil deducir el • Según Philippe Krutchen de Rational Rose [4],
impacto y la importancia que tiene la reutilización un componente es una parte no trivial, casi
de componentes en el proceso de desarrollo de independiente y reemplazable de un sistema
software; particularmente, en tres de las variables que cumple una función dentro del contexto
más importantes de la Ingeniería de Software: el de una arquitectura bien definida. Un
costo, tiempo y esfuerzo requerido para componente cumple con un conjunto de
desarrollar un producto de software. La interfaces y provee la realización física de
aplicación apropiada de la reutilización en un ellas.
proyecto de software conduce, indiscutiblemente, • Según Clemens Szyperski [5], un componente
a una reducción significativa de los valores de de software es una unidad de composición
estas tres variables. Otros beneficios importantes con interfaces especificadas
son el incremento de la calidad del software contractualmente y solamente dependencias
producido, el aumento de la productividad de los explícitas de contexto. Un componente de
grupos de desarrollo y la reducción del riesgo software puede ser desplegado
global del proyecto. independientemente y está sujeto a
Este artículo tiene un carácter tutorial y su composición por terceros.
objetivo es describir los fundamentos y aspectos • Según Herzum y Sims [6], un componente es un
metodológicos del desarrollo de software basado artefacto de software autocontenido y
en componentes. En la sección 2 se establecen los claramente identificable que describe ó
conceptos de activo reutilizable y componente de ejecuta funciones específicas; que tiene,
software; de estos últimos se exponen las además, una interfaz claramente establecida,
características mínimas y deseables que favorecen una documentación apropiada y un status de
su reutilización. Las secciones 3, 4 y 5 discuten uso recurrente bien definido.
cómo los componentes se acoplan. Para ello se • Según el CBDi Forum [7], un componente es
describe el papel de las interfaces, modelos y una pieza de software que describe y/o libera un
frameworks de componentes, y se analizan conjunto de servicios que son usados sólo a través
algunos de los mecanismos de composición de de interfaces bien definidas.
software más utilizados. Finalmente, la sección 6 Más recientemente, el Instituto de Ingeniería
describe los modelos de procesos y los aspectos de Software (SEI, Software Engineering Institute)
metodológicos que rigen esta nueva forma de de la Universidad Carnegie-Mellon formuló una
producir software. definición con el propósito de consolidar las
diferentes opiniones acerca de lo que debía ser un
II. ACTIVOS REUTILIZABLES Y componente de software. Según el SEI [8], un
COMPONENTES DE SOFTWARE componente es “una implementación opaca de
funcionalidad, sujeta a composición por terceros y
En el contexto de Ingeniería de Software, un
que cumple con un modelo de componentes”. Con
Activo Reutilizable es un producto diseñado
respecto al primer aspecto, un componente se
expresamente para ser empleado de forma
considera una implementación opaca debido a que
recurrente en el desarrollo de muchos sistemas y
su distribución predominantemente es en formato
 binario y sus consumidores lo utilizan como una no deben afectar la interfaz.
“caja negra” a través de su interfaz. Dicho aspecto • documentado: un componente debe tener una
está alineado con el principio de encapsulamiento documentación adecuada que facilite su
de la programación orientada a objetos [9], [10]. búsqueda en repositorios de componentes,
Por otra parte, la composición por terceros evaluación, adaptación a nuevos entornos,
implica que los componentes son intrínsecamente integración con otros componentes y acceso a
reutilizables debido a que un sistema basado en información de soporte.
componentes puede ser ensamblado con relativa Adicionalmente, para favorecer su reutilización es
facilidad por un integrador empleando deseable que un componente sea: • genérico: sus
componentes suministrados por múltiples servicios pueden ser usados en una gran variedad
de aplicaciones.
3

proveedores independientes. Finalmente, la

coordinación e interacción entre componentes • autocontenido: es conveniente que un
exige un marco regulatorio estandarizado (modelo componente dependa lo menos posible de
de componentes) que establece la infraestructura otros componentes para cumplir su función
de software requerida (framework) y las de forma tal que pueda ser desarrollado,
convenciones y restricciones de diseño de los probado, optimizado, utilizado, entendido y
mismos. modificado individualmente.
Tal como lo refleja la definición anterior, un • mantenido: es deseable que un componente
componente de software puede ser visto desde (como toda pieza de software) esté inmerso
dos perspectivas distintas, como: en un proceso de mejoramiento continuo que
1. implementación: los componentes se pueden le garantice al integrador nuevas versiones
ensamblar y desplegar para crear sistemas y que incluyan correctivos, optimizaciones y
aplicaciones que se ejecutan en un nuevas características. Esto contribuye a que
computador dicho componente sea seleccionado con
2. abstracción de arquitectura: los componentes mayor frecuencia para formar parte de
expresan las reglas de diseño que impone el sistemas de software.
modelo de componentes. • independiente de la plataforma (hardware y
Están disponibles diversas tecnologías de sistema operativo), del lenguaje de
componentes típicamente asociadas con programación y de las herramientas de
infraestructuras de procesamiento distribuido (e.g. desarrollo: existen diversas plataformas de
Enterprise JavaBeans [11], CORBA Component cómputo de uso frecuente (e.g.
Model [12] y .NET [13]) y aplicaciones de Windows/Intel, Solaris/Sparc, OSX/PPC,
escritorio (e.g. Controles ActiveX [14] y Linux/Intel) y es deseable que un
JavaBeans [15]). componente pueda ejecutarse en todas ellas.
Una de las características más importantes de los Asimismo, ya que existe una amplia gama de
componentes es que son reutilizables. Para ello lenguajes de programación y herramientas de
los componentes deben satisfacer como mínimo el desarrollo, es natural que encontremos
siguiente conjunto de características: • componentes escritos empleando lenguajes y
identificable: un componente debe tener una herramientas de la preferencia del
identificación clara y consistente que facilite programador, por lo tanto es deseable que
su catalogación y búsqueda en repositorios de dichas preferencias no limiten el uso de los
componentes. componentes.
• accesible sólo a través de su interfaz: el • puede ser reutilizado dinámicamente: puede
componente debe exponer al público ser cargado en tiempo de ejecución en una
únicamente el conjunto de operaciones que lo aplicación.
caracteriza (interfaz) y ocultar sus detalles de
• certificado: el componente puede ser
implementación. Esta característica permite
certificado por una agencia de software
que un componente sea reemplazado por otro
independiente o mediante la aplicación de
que implemente la misma interfaz.
modelos de auto-certificación que le permiten
• sus servicios son invariantes: las operaciones al comprador del componente determinar la
que ofrece un componente, a través de su calidad del software adquirido [16].
interfaz, no deben variar. La implementación
• accedido uniformemente sin importar su
de estos servicios puede ser modificada, pero
localidad: la forma de invocar los servicios
 ofrecidos por los componentes debiese ser como Propiedades Funcionales. Sin embargo,
independiente de su ubicación (local o estas interfaces no expresan adecuadamente
remota). Para ello el modelo de componentes propiedades del componente relativas a, por
debería estar basado en tecnologías de ejemplo, su desempeño, precisión, disponibilidad,
procesamiento distribuido tales como latencia, seguridad, entre otras. Dichas
CORBA [17], RMI [18] y .NET Remoting propiedades se conocen como Propiedades
[13]. Extrafuncionales [24].
Es útil diferenciar los tipos de propiedades de
III. LA INTERFAZ DE UN los componentes. Por ejemplo, Beugnard et al.
COMPONENTE [25] define cuatro tipos de propiedades
relacionadas con:
Una interfaz define el conjunto de operaciones
1. Sintaxis: corresponden a las propiedades
que un componente puede realizar; estas
funcionales expresadas explícitamente a
operaciones son llamadas también servicios o
través de la interfaz del componente.
2. Comportamiento: definen las condiciones que
deben cumplir los valores de entrada
4
responsabilidades. Las interfaces proveen un
mecanismo para interconectar componentes y
controlar las dependencias entre ellos.
(precondiciones) y salida (postcondiciones)
La naturaleza de la interfaz varia dependiendo de las operaciones.
del lenguaje programación empleado para
3. Sincronización: expresan aspectos de
implementar el componente. Los lenguajes
concurrencia.
orientados a objetos (e.g. Smalltalk-80 [19], C++
4. Calidad de Servicio: contempla atributos tales
[20] y Java [21]) soportan alguna forma de
como tiempo de respuesta, uso de memoria,
interfaz, que por lo general están separadas de las
precisión, confiabilidad, facilidad de
implementaciones. En lenguajes procedimentales
mantenimiento y reutilización, entre otros.
(e.g. Pascal [22] y FORTRAN [23]) las interfaces
Se han realizado algunos intentos para que las
se definen a través de declaraciones de funciones
interfaces expresen mejor las propiedades
o procedimientos y el uso de variables globales.
extrafuncionales, tales como el lenguaje de
Algunos lenguajes neutrales de especificación de
programación Eiffel [26] y el método formal
interfaces han sido desarrollados tales como IDL
Object-Z [27] para propiedades de
(Interface Definition Language) [17] de OMG
comportamiento, Object Calculus [28] para
(Object Management Group).
propiedades de sincronización y la notación
En general, una interfaz de programación de NoFun [29] para las propiedades de calidad de
aplicaciones (API, Application Programming
servicio.
Interface) es una especificación, en un lenguaje
Los párrafos anteriores sólo describen a las
de programación, de las propiedades de un
interfaces como una manera de especificar el flujo
módulo de software. Los clientes del módulo sólo
unidireccional de dependencia que tiene un
deben depender exclusivamente de las
cliente con respecto a un componente. Sin
propiedades definidas por el API de forma
embargo, es mejor decir que un cliente y un
explícita.
componente dependen el uno del otro; un cliente
Algunas tecnologías (e.g. Enterprise
depende de la forma en que un componente
JavaBeans [11]) exigen que sus componentes
provee sus servicios, y un componente depende
implementen dos tipos de interfaces:
de cómo los clientes utilizan los servicios que éste
1. interfaz de negocio: que refleja el rol del
ofrece. Esta interdependencia ha llevado a acuñar
componente en el sistema.
el término Contrato de Interfaz [2], [8] en la
2. interfaz de infraestructura: es impuesta por el literatura de investigación acerca sistemas
modelo de componentes con el fin de
basados en componentes.
permitirle al framework interactuar con el
componente.
IV. FRAMEWORKS Y MODELOS DE
Por otra parte, nótese que las interfaces
COMPONENTES
convencionales definen la firma de las
operaciones (nombre de la operación, tipo y orden Existe cierta confusión en la literatura
de los argumentos, y la manera como se referente a la terminología de modelos y
devuelven los resultados) que provee un frameworks de componentes. Sin embargo, hay
componente. Las operaciones también se conocen consenso acerca de que los sistemas basados en
 componentes confían en estándares y convenciones (EJB) [11] y VisualBasic Framework (VBF) de
bien definidas (modelo de componentes) y en una Microsoft [14] son de los más representativos. La
infraestructura de soporte (framework de especificación de EJB define un framework de
componentes). servidores y contenedores para dar soporte al
Los modelos de componentes especifican las modelo de componentes. Los Servidores EJB son
reglas de diseño que deben obedecer los responsables de proporcionar servicios de
componentes. Estas reglas de diseño mejoran la sistemas tales como persistencia, transacciones y
composición, aseguran que las calidades de seguridad, mientras que los Contenedores EJB
servicio se logren en todo el sistema, y que los son responsables de manejar el ciclo de vida del
componentes se puedan desplegar fácilmente componente. Por su parte, VBF es quizás el
tanto en entornos de desarrollo como de framework más popular para el desarrollo de
producción. aplicaciones de escritorio. Se concentra en la
Los modelos de componentes imponen composición visual de componentes (llamados
estándares y convenciones sobre: VBXs) más que en tener un entorno que garantice
• Tipos de Componentes: Un tipo de la calidad de servicio de éstos. VBF incluye al
componente puede ser definido en términos intérprete de VisualBasic (para ejecutar scripts y
de las interfaces que implementa. Los tipos hacer composición) y el Modelo de Objetos de
diferentes de componentes pueden Componentes (COM, Component Object Model)
[7] (encargado de los servicios de despliegue y
comunicación).
5
desempeñar diferentes roles en el sistema, y
participar en distintos tipos de esquemas de
interacción. Un mercado robusto de componentes de
• Esquemas de Interacción: especifican cómo software requiere modelos y frameworks
los componentes son localizados, cuáles estandarizados. Sin embargo, la experiencia ha
protocolos de comunicación son utilizados, y demostrado que distintos dominios de aplicación
cómo se satisfacen las calidades de servicio tienen diferentes requisitos de funcionalidad y
(e.g. seguridad, transacciones, alta calidad de servicio (e.g. latencia, seguridad y
disponibilidad). El modelo de componentes disponibilidad). Esto sugiere la necesidad de tener
puede describir cómo interactúan los una variedad modelos y frameworks de
componentes entre sí y cómo interactúan componentes para cada dominio. EJB, CCM y
dichos componentes con el framework. .NET se han abocado al dominio de aplicaciones
• Asociación (bindings) de recursos: El proceso empresariales (ERP, BPM, e-commerce y
de composición de componentes es sistemas financieros) el cual es lo suficientemente
simplemente enlazar un componente a uno o grande y coherente para definir estándares de
más recursos. Un recurso es un servicio modelos y frameworks de componentes. Sin
ofrecido por un framework o por otro embargo, existen iniciativas que están abordando
componente desplegado en ese framework. otros dominios de aplicación. Las más notorias
Un modelo de componentes describe cuáles son las promovidas por OMG para el control de
recursos están disponibles a los componentes, tráfico aéreo, análisis de secuencias
y cómo y cuándo se asocian estos biomoleculares, mapas genómicos, infraestructura
componentes a éstos recursos. de clave pública, entre otras. Adicionalmente,
Por otra parte, los frameworks de WaterBeans [30] y SIMyO [31] son iniciativas
componentes proporcionan servicios que soportan relacionadas con tratamiento de agua, y modelado
y hacen cumplir el modelo componentes asociado. y optimización, respectivamente.
El framework maneja recursos compartidos por
los componentes, y proporciona mecanismos V. MECANISMOS DE COMPOSICIÓN
subyacentes que permiten la comunicación DE SOFTWARE
(interacción) entre ellos. Los frameworks son Bajo el modelo de desarrollo de software
activos y actúan directamente sobre componentes, basado en componentes, las nuevas aplicaciones
por ejemplo administrando su ciclo de vida se construyen mediante la integración o
(comenzar, suspender, reasumir, o terminar la composición de componentes. Sametinger [2]
ejecución de un componente), y otros recursos. define la composición de software como “el
Existen muchos ejemplos de frameworks de proceso de construir aplicaciones mediante la
componentes, entre éstos Enterprise JavaBeans interconexión de componentes de software a
 través de sus interfaces (de composición)". Nótese composición típicamente se describen mediante el
que se hace especial énfasis en las interfaces uso de patrones de diseño [32], [33].
como elementos fundamentales para lograr la Las tecnologías de componentes no
composición de componentes. distribuidos, típicamente asociadas con
La composición puede concebirse como una aplicaciones de escritorio (e.g. Controles ActiveX
relación cliente-servidor entre dos componentes [14] y JavaBeans [15]), hacen uso extensivo de
(Figura 1). El componente cliente solicita un características orientadas a objetos dentro de sus
servicio (operación) del componente servidor, el mecanismos de composición. Por el contrario, en
cual ejecuta la operación solicitada y devuelve los la composición de componentes distribuidos (e.g.
resultados al cliente. El servidor produce un Enterprise JavaBeans [11], CORBA Component
resultado que es consumido por el cliente. Model [12] y .NET [13]) principalmente se
emplean relaciones de uso, asociación y
solicita un servicio agregación.

C1 C2 consume el servicio VI. EL PROCESO DE DESARROLLO

Figura 1. Interacción entre En las secciones anteriores, se caracterizaron
componentes. los componentes de software y se describieron los
6
Además de los componentes, los frameworks
también se consideran entidades sujetas a
composición. En consecuencia, existen tres clases mecanismos necesarios para que ellos se integren
a fin de crear nuevas aplicaciones. Las preguntas
que se intentan responder en esta sección son:
¿cómo se desarrolla un componente? y ¿cómo se
principales de interacción en los sistemas basados crea una aplicación que reutilice componentes
en componentes [24]: existentes?
1. Componente-Componente (C-C): permite la Sommerville [1] clasifica los procesos de
interacción entre componentes. De este tipo desarrollo de software basados en la reutilización
de interacción se obtiene la funcionalidad de de componentes en dos categorías:
la aplicación, de forma tal que los contratos • Desarrollo de componentes: Este proceso
que especifican este tipo de interacción implica la adaptación o desarrollo de
pueden ser clasificados como Contratos a componentes con el propósito expreso de ser
Nivel de Aplicación. reutilizados en futuras aplicaciones. Su
2. Componente-Framework (C-F): posibilita las objetivo es producir repositorios de activos
interacciones entre el framework y sus que puedan ser reutilizados en el desarrollo
componentes. Dicha interacción permite que de software. Para ser reutilizables, estos
el framework administre los recursos de los componentes deben satisfacer las
componentes. Los contratos que especifican características descritas en la Sección 2.
estas interacciones pueden ser clasificados • Desarrollo de software con reutilización de
como Contratos a Nivel de Sistema.
componentes: Es un proceso en el cual el
3. Framework-Framework (F-F): posibilita las
desarrollo de una nueva aplicación involucra
interacciones entre framewoks y permiten la
la reutilización de un conjunto de
composición de componentes desplegados en
componentes existentes. Este enfoque
framewoks heterogéneos. Estos contratos
maximiza la reutilización de componentes de
puede ser clasificados como Contratos de
software existentes y reduce el número de
Interoperabilidad.
componentes que requieren ser desarrollados
La forma de materializar la composición entre
en su totalidad (desde cero). Para ser exitoso,
componentes depende de los mecanismos
este proceso demanda dos condiciones
especificados por su modelo de programación.
mínimas: i) la existencia de repositorios o
Típicamente, los modelos de componentes se
bases de componentes reutilizables y ii) que
basan en tecnologías orientadas a objetos, por lo
los componentes sean confiables y actúen de
tanto los mecanismos de composición emplean acuerdo a sus especificaciones.
algunas características tales como relaciones entre
El modelo de procesos descrito por
clases (especialización, agregación, asociación y
Sametinger [2] provee, sin embargo, una visión
uso) [10], polimorfismo y enlace dinámico [9].
mucho más completa y amplia del desarrollo de
Adicionalmente, dichos mecanismo de
software basado en componentes. Este modelo,
 denominado ciclo de vida gemelo (twin life cycle), reutilizables en un dominio particular. El segundo
divide el proceso de desarrollo de software en dos bloque es denominado Ingeniería de
grandes bloques paralelos, tal como se ilustra en Aplicaciones. Su propósito es el desarrollo de
la Figura 2. El primer bloque, conocido como aplicaciones basado en la reutilización de activos
Ingeniería de Dominios, contempla los procesos de software producidos a través de la Ingeniería de
necesarios para desarrollar activos de software Dominios.
Especificación
de requerimentos de
requerimentos

Análisis del Diseño del Diseño de la

Análisis del Dominio Diseño del de
Dominio Dominio de
Dominio análisis
análisis
modelos
modelos diseños
diseños Especificación
Ingeniería de
7
genéricos componentes
Dominios
genéricos componentes
Ingeniería de
Dominios Desarrollo de
Desarrollo de Búsqueda de
Componentes
Componentes

Especificación
Diseño de la De s s Componente
Arquitectur Componentes Componentes Componentes s
a De Componentes Adapt / Des. Integración de Componentes
Arquitectura Búsqueda de Adapt / Des. Integración
Especificación Componente Componente de

Ingeniería de Aplicaciones
Ingeniería de Aplicaciones
Figura 2. El modelo de procesos gemelos para el desarrollo de software basado en componentes
La estructura del método WATCH se ilustra en
Un modelo alternativo al modelo de Ingeniería la Figura 3. Esta estructura emplea la metáfora de
de Aplicaciones es el modelo WATCH [34], [35]. un reloj de pulsera para describir el orden de
Este modelo combina los procesos más relevantes
de la Ingeniería de Software Orientada a Objetos Procesos de
Post-desarrollo

con el modelo de Ingeniería de Aplicaciones del

ciclo de vida gemelo. Una característica
importante de este modelo es la integración de los Entrega del
Sistema
procesos gerenciales con los procesos técnicos del
ejecución de los procesos técnicos de desarrollo de
desarrollo de software basado en componentes. aplicaciones, indicando además cómo los
Esta integración facilita la labor del líder del
procesos gerenciales controlan o coordinan el
proyecto, al describir cómo se debe llevar a cabo
orden de ejecución de los procesos técnicos. Los
una gestión del proyecto integrada a los procesos
procesos gerenciales están ubicados en el centro
técnicos del desarrollo de software.
de la estructura para indicar explícitamente que
 ellos programan, dirigen y controlan el proceso de
desarrollo. Los procesos técnicos están ubicados
en el entorno siguiendo la forma que tiene el dial
de un reloj. Ello indica que el orden de ejecución
de las fases técnicas se realiza en el sentido de las Análisis del
Dominio de

agujas del reloj. Los procesos gerenciales pueden, Apliación

sin embargo, invertir el orden de ejecución para Descubrimiento

de

repetir algunas de las fases anteriores. Requerimientos

Requerimientos
Procesos
gerenciales

Pruebas del
Sistema Diseño del
Sistema

Diseño de
Componentes
Análisis y
Implementación
Especificación de
del Sistema

Figura 3. El modelo de procesos WATCH [34], [35]

en la manera en que la industria de software
Las tres primeras fases del modelo son desarrolla sus productos. Los componentes de
similares a los modelos de procesos tradicionales. software reutilizables constituyen las unidades
La fase de Análisis del Contexto permite que el fundamentales para el desarrollo de nuevas
grupo de desarrollo adquiera un conocimiento aplicaciones. En este artículo, se ha hecho un
intento por destacar la importancia y caracterizar
el proceso de desarrollo de software basado en la
reutilización de componentes. Se estableció una
adecuado del dominio o contexto del sistema en comparación entre los conceptos de activos
desarrollo. Las fases de Descubrimiento, Análisis reutilizables y componentes de software. Se
y Especificación de Requerimientos se encargan describieron las características requeridas y
de identificar las necesidades y requerimientos de deseables de un componente de software para su
los usuarios, así como analizarlos, especificarlos reutilización. Adicionalmente, se describieron los
gráficamente y documentarlos. conceptos de interfaz, modelo y framework de
La fase de diseño del sistema establece y componentes, así como también mecanismos de
describe la arquitectura del software. Describe composición de software. Finalmente, se
cada uno de los componentes que requiere tal discutieron algunos de los aspectos
estructura y cómo esos componentes se metodológicos que rigen el desarrollo de
interconectan para interactuar. El grupo de componentes y de aplicaciones basadas en la
desarrollo debe, a partir de esta arquitectura, reutilización de componentes.
determinar cuáles componentes se pueden
reutilizar y cuáles requieren ser desarrollados en VIII. AGRADECIMIENTOS
su totalidad. Los componentes reutilizados deben
ser adaptados, para satisfacer los requerimientos Los autores agradecen el apoyo económico
del sistema; mientras que los componentes suministrado por el Fondo Nacional de Ciencia,
nuevos, deben ser diseñados, codificados y Tecnología e Innovación (FONACIT-Venezuela)
probados separadamente durante la fase de a través de el proyecto de investigación titulado
Implementación. Las Pruebas del sistema “Integración de Tecnologías y Sistemas de
permiten detectar errores en la integración de los 8
componentes. Finalmente, la fase de Entrega se
encarga de la instalación, adiestramiento de
usuarios y puesta en operación del sistema. Software Heterogéneos en Aplicaciones
Espacio-Temporales” (G-97000824).
VII. CONCLUSIONES
IX. REFERENCIAS
Los beneficios derivados de la reutilización de
[1] I. Sommerville. Software engineering.
software están ocasionando un cambio acelerado
Addison-Wesley Pub Co, 6ta edición,
 Agosto 2000. [15] Sun Microsystems, Inc. Javabeans.
[2] J. Sametinger. Software engineering with http://java.sun.com/product
reusable components. Springer Verlag, s/javabeans/docs/spec.html,
Agosto 1997. Agosto 1997.
[3] J. Sodhi, y P. Sodhi. Software reuse: [16] J. Morris, G. Lee, K. Parker, G.A.
Domain analysis and design process. Bundell, y C.P. Lam. Software
McGraw-Hill. 1999. component certification. IEEE
[4] A. W. Brown and K. C.Wallnau. The Computer, 34(9), Septiembre, 2001.
current state of CBSE. IEEE Software, [17] Object Management Group, Inc.
15(5):37-46, Septiembre 1998. Common object request broker
[5] C. Szyperski. Component software: architecture: Core specification.
Beyond object-oriented programming. http://www.omg.org/docs/for
Addison-Wesley Pub Co, 2da edición, mal/02-12-06.pdf, Diciembre
Noviembre 2002. 2002.
[6] P. Herzum and O. Sims. Business [18] Sun Microsystems, Inc. Java remote
component factory : A comprehensive method invocation specification.
overview of component-based ftp://ftp.java.sun.com/docs
development for the enterprise. John /j2se1.4/rmi-spec-1.4.pdf. [19] A.
Wiley & Sons, 2000. Goldberg and D. Robson. Smalltalk 80 : The
[7] CDBI Forum. Component based language. Addison-Wesley Pub Co, Enero 1989.
development: Using componentised [20] B. Stroustrup. The C++ programming
software. language. Addison-Wesley Pub Co, 3ra edición,
http://www.cdbiforum.com, Febrero 2000.
Mayo 1999. [21] B. Joy, G. Steele, J. Gosling y G.
[8] F. Bachmann, L. Bass, Ch. Buhman, S. Bracha. The Java(TM) languaje
Comella-Dorda, F. Long, J. Robert, R. Seacord specification. Addison-Wesley Pub Co,
y K. Wallnau. Volume II: 2da edición, Junio 2000.
Technical concepts of component-based [22] D. W. Nance. Pascal: Understanding
software engineering, 2nd edition. programming and problem solving. West
Technical report, Software Engineering Information Pub Group, 4ta edición,
Institute, Carnegie Mellon University, Enero 1995.
Julio 2000. [23] D. Rev. Smorlarski, Research &
[9] T. Budd. Introducción a la Education Association y
programación orientada a objetos. Dennis Chester Smolarski. The
Addison-Wesley Iberoamericana. 1994. [10] L. essentials of FORTRAN (essentials).
Joyanes Aguilar. Programación orientada a Research & Education Assn, Mayo
objetos. McGraw-Hill 1994.
Interamericana, Diciembre 1998. [24] T. Digre. Business object component
[11] Sun Microsystems, Inc. Enterprise architecture. IEEE Software, 15(5),
javabeans specification, version 2.0. 1998.
http://java.sun.com/product [25] A. Beugnard, J-M Jézéquel y N. Plouzeau.
s/ejb/docs.html, Agosto 2001. Making components contract aware. IEEE
[12] Object Management Group Inc. Corba Computer, 32(7):38-45,
components. Julio 1999.
http://www.omg.org/cgi [26] B. Meyer. Eiffel: The language. Prentice
bin/doc?formal/02-06-65, Junio Hall PTR, Octubre, 1991.
2002. 9

[27] R. Duke, G. Rose y G. Smith. Object-Z: A

[13] T. L. Thai and H. Lam. .NET framework specification language advocated for
essentials. O'Reilly & Associates, 3ra the description of standards. Computer
edición, 2003. Standards and Interfaces, 17:511-533,
[14] D. Chappell. Understanding ActiveX and Septiembre 1995.
OLE. Microsoft Press, 1ra edición, Enero [28] K. Lano, J. Bicarregui, J. Luiz Fiadeiro y T.
1996. Maibaum. Composition of reactive system
 components. En 1st Workshop on
Component-Based Systems, Zurich,
Switzerland, 1997.
[29] X. Franch. Systematic formulation of
non-functional characteristics of
software.
In 3rd International Conference on
Requirements Engineering (ICRE),
pages 174-181, Colorado Springs (USA).
[30] K. C. Wallnau and D. Plakosh. Waterbeans:
A custom component model and framework.
http://www.sei.cmu.edu/cbs/
cbse2000/papers/23/23.html,
2000.
[31] C. Arévalo, J. Colmenares, N. Queipo, N.
Arapé y J. Villalobos. A CORBA and Web
technology based framework for the analysis and
optimal design of
complex systems in the oil industry. En
3rd Internacional Conference on
Enterprise Information Systems (ICEIS
2001), Julio 2001.
[32] E. Gamma, R. Helm, R. Johnson y J.
Vlissides. Design patterns. Addison
Wesley Pub Co, Enero 1995.

[33] F. Marinescu. EJB design patterns:

Advanced patterns, processes and
idioms. John Wiley & Sons, Febrero
2002.
[34] J. Montilva, K. Hazam y M. Gharawi.
The Watch Model for development
business software in small and midsize
organization. In IV World
Multiconference on Systemics,
Cybernetics and Informatics (SCI'2000),
Orlando, Florida (USA), Julio 2000.
[35] J. Montilva and J. Barrios. A
Component-Based Method for
Developing Web Applications. 5 th
International Conference on Enterprise
Information Systems (ICEIS’2003),
Angers, France, 2003.