IV Congreso de Automatización y Control

Mérida, 12-14 noviembre 2003 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 Aplicado
Departamento de Computación Maracaibo - Venezuela
Mérida – Venezuela
+58-274-2403811
jonas@ing.ula.ve, narape@ica.luz.ve, juancol@ica.luz.ve

Resumen-- La Orientación a Objetos Existen variadas definiciones del término

introdujo, durante la década pasada, un Reutilización de Software. Algunas de estas
cambio radical en el proceso de desarrollo de definiciones son las siguientes:
software. De un proceso caracterizado por su • Según Somerville [1], la reutilización es un
énfasis en la descripción algorítmica de la enfoque de desarrollo [de software] que trata
solución del problema, se pasó a un proceso de maximizar el uso recurrente de
orientado a la representación y manipulación componentes de software existentes.
de los objetos que caracterizan el problema. • Según Sametinger [2], la reutilización de
Este paradigma abrió, también, nuevas software es el proceso de crear sistemas de
posibilidades para desarrollar software basado software a partir de software existente, en
en la noción de reutilización de componentes. lugar de desarrollarlo desde el comienzo.
La Orientación a Objetos creó un rumbo • Según Sodhi et al. [3], la reutilización de
diferente en el proceso de reutilización a través software es el proceso de implementar o
de la producción de componentes genéricos, actualizar sistemas de software usando
fáciles de integrar, distribuidos e activos de software existentes.
independientes de las plataformas de Estas tres definiciones consideran la
desarrollo. En este artículo, de carácter reutilización como un enfoque o proceso de
tutorial, se discuten los conceptos desarrollo de software. Su principal diferencia
fundamentales de la reutilización de software, radica en el objeto de reutilización (componente,
así como los modelos de procesos y los aspectos software y activo). Tal como lo plantean Sodhi et
metodológicos que caracterizan esta nueva al. [3], la reutilización de software va más allá de
manera de producir software, denominada la reutilización de piezas de software. Ella
Desarrollo de Software basado en involucra el uso de otros elementos de software,
Componentes. tales como algoritmos, diseños, arquitecturas de
software, documentación y especificaciones de
Palabras clave—desarrollo de software, requerimientos.
reutilización de software, componentes de Con base en el análisis de estas definiciones
software. podemos establecer nuestra propia definición en
los siguientes términos:
La reutilización de software es un proceso de
I. INTRODUCCIÓN la Ingeniería de Software que conlleva al uso
La reutilización de componentes de software recurrente de activos de software en la
es un proceso inspirado en la manera en que se especificación, análisis, diseño,
producen y ensamblan componentes en la implementación y pruebas de una aplicación o
ingeniería de sistemas físicos. La aplicación de sistema de software.
este concepto al desarrollo de software no es Varios estudios han demostrado la efectividad
nueva. Las librerías de subrutinas especializadas, de la reutilización del software. Sametinger [2],
comúnmente utilizadas desde la década de los en particular, describe algunos de estos
setenta, representan uno de los primeros intentos indicadores:
por reutilizar software. • Entre el 40 y 60% del código fuente de una
aplicación es reutilizable en otra similar.
 2

• Aproximadamente el 60% del diseño y del software orientadas a reducir drásticamente el

código de aplicaciones administrativas es costo y tiempo de desarrollo de sistemas y
reutilizable. aplicaciones, sin afectar los niveles de calidad del
• Aproximadamente el 75% de las funciones producto, ha surgido un nuevo activo reutilizable
son comunes a más de un programa. denominado Componente de Software. Se han
• Sólo el 15% del código encontrado en propuesto numerosas definiciones a este término,
muchos sistemas es único y novedoso a una entre las cuales destacan las siguientes:
aplicación específica. El rango general de uso • Según Philippe Krutchen de Rational Rose
recurrente potencial está entre el 15% y el [4], un componente es una parte no trivial,
85%. casi independiente y reemplazable de un
A partir de estos indicadores es fácil deducir sistema que cumple una función dentro del
el impacto y la importancia que tiene la contexto de una arquitectura bien definida.
reutilización de componentes en el proceso de Un componente cumple con un conjunto de
desarrollo de software; particularmente, en tres de interfaces y provee la realización física de
las variables más importantes de la Ingeniería de ellas.
Software: el costo, tiempo y esfuerzo requerido • Según Clemens Szyperski [5], un
para desarrollar un producto de software. La componente de software es una unidad de
aplicación apropiada de la reutilización en un composición con interfaces especificadas
proyecto de software conduce, indiscutiblemente, contractualmente y solamente dependencias
a una reducción significativa de los valores de explícitas de contexto. Un componente de
estas tres variables. Otros beneficios importantes software puede ser desplegado
son el incremento de la calidad del software independientemente y está sujeto a
producido, el aumento de la productividad de los composición por terceros.
grupos de desarrollo y la reducción del riesgo • Según Herzum y Sims [6], un componente es
global del proyecto. un artefacto de software autocontenido y
Este artículo tiene un carácter tutorial y su claramente identificable que describe ó
objetivo es describir los fundamentos y aspectos ejecuta funciones específicas; que tiene,
metodológicos del desarrollo de software basado además, una interfaz claramente establecida,
en componentes. En la sección 2 se establecen los una documentación apropiada y un status de
conceptos de activo reutilizable y componente de uso recurrente bien definido.
software; de estos últimos se exponen las • Según el CBDi Forum [7], un componente es
características mínimas y deseables que favorecen una pieza de software que describe y/o libera
su reutilización. Las secciones 3, 4 y 5 discuten un conjunto de servicios que son usados sólo
cómo los componentes se acoplan. Para ello se a través de interfaces bien definidas.
describe el papel de las interfaces, modelos y Más recientemente, el Instituto de Ingeniería
frameworks de componentes, y se analizan de Software (SEI, Software Engineering Institute)
algunos de los mecanismos de composición de de la Universidad Carnegie-Mellon formuló una
software más utilizados. Finalmente, la sección 6 definición con el propósito de consolidar las
describe los modelos de procesos y los aspectos diferentes opiniones acerca de lo que debía ser un
metodológicos que rigen esta nueva forma de componente de software. Según el SEI [8], un
producir software. componente es “una implementación opaca de
funcionalidad, sujeta a composición por terceros y
II. ACTIVOS REUTILIZABLES Y que cumple con un modelo de componentes”. Con
COMPONENTES DE SOFTWARE respecto al primer aspecto, un componente se
considera una implementación opaca debido a que
En el contexto de Ingeniería de Software, un
su distribución predominantemente es en formato
Activo Reutilizable es un producto diseñado
binario y sus consumidores lo utilizan como una
expresamente para ser empleado de forma
“caja negra” a través de su interfaz. Dicho aspecto
recurrente en el desarrollo de muchos sistemas y
está alineado con el principio de encapsulamiento
aplicaciones. Ejemplos de activos reutilizables
de la programación orientada a objetos [9], [10].
son: algoritmos, patrones de diseño, esquemas de
Por otra parte, la composición por terceros
base de datos, arquitecturas de software,
implica que los componentes son intrínsecamente
especificaciones de requerimientos, de diseño y
reutilizables debido a que un sistema basado en
de prueba, entre otros.
componentes puede ser ensamblado con relativa
En los últimos años, como resultado de
facilidad por un integrador empleando
presiones crecientes sobre la industria del
componentes suministrados por múltiples
 3

proveedores independientes. Finalmente, la • autocontenido: es conveniente que un

coordinación e interacción entre componentes componente dependa lo menos posible de
exige un marco regulatorio estandarizado (modelo otros componentes para cumplir su función
de componentes) que establece la infraestructura de forma tal que pueda ser desarrollado,
de software requerida (framework) y las probado, optimizado, utilizado, entendido y
convenciones y restricciones de diseño de los modificado individualmente.
mismos. • mantenido: es deseable que un componente
Tal como lo refleja la definición anterior, un (como toda pieza de software) esté inmerso
componente de software puede ser visto desde en un proceso de mejoramiento continuo que
dos perspectivas distintas, como: le garantice al integrador nuevas versiones
1. implementación: los componentes se pueden que incluyan correctivos, optimizaciones y
ensamblar y desplegar para crear sistemas y nuevas características. Esto contribuye a que
aplicaciones que se ejecutan en un dicho componente sea seleccionado con
computador mayor frecuencia para formar parte de
2. abstracción de arquitectura: los componentes sistemas de software.
expresan las reglas de diseño que impone el • independiente de la plataforma (hardware
modelo de componentes. y sistema operativo), del lenguaje de
Están disponibles diversas tecnologías de programación y de las herramientas de
componentes típicamente asociadas con desarrollo: existen diversas plataformas de
infraestructuras de procesamiento distribuido (e.g. cómputo de uso frecuente (e.g.
Enterprise JavaBeans [11], CORBA Component Windows/Intel, Solaris/Sparc, OSX/PPC,
Model [12] y .NET [13]) y aplicaciones de Linux/Intel) y es deseable que un
escritorio (e.g. Controles ActiveX [14] y componente pueda ejecutarse en todas ellas.
JavaBeans [15]). Asimismo, ya que existe una amplia gama de
Una de las características más importantes de lenguajes de programación y herramientas de
los componentes es que son reutilizables. Para desarrollo, es natural que encontremos
ello los componentes deben satisfacer como componentes escritos empleando lenguajes y
mínimo el siguiente conjunto de características: herramientas de la preferencia del
• identificable: un componente debe tener una programador, por lo tanto es deseable que
identificación clara y consistente que facilite dichas preferencias no limiten el uso de los
su catalogación y búsqueda en repositorios de componentes.
componentes. • puede ser reutilizado dinámicamente:
• accesible sólo a través de su interfaz: el puede ser cargado en tiempo de ejecución en
componente debe exponer al público una aplicación.
únicamente el conjunto de operaciones que lo • certificado: el componente puede ser
caracteriza (interfaz) y ocultar sus detalles de certificado por una agencia de software
implementación. Esta característica permite independiente o mediante la aplicación de
que un componente sea reemplazado por otro modelos de auto-certificación que le permiten
que implemente la misma interfaz. al comprador del componente determinar la
• sus servicios son invariantes: las calidad del software adquirido [16].
operaciones que ofrece un componente, a • accedido uniformemente sin importar su
través de su interfaz, no deben variar. La localidad: la forma de invocar los servicios
implementación de estos servicios puede ser ofrecidos por los componentes debiese ser
modificada, pero no deben afectar la interfaz. independiente de su ubicación (local o
• documentado: un componente debe tener remota). Para ello el modelo de componentes
una documentación adecuada que facilite su debería estar basado en tecnologías de
búsqueda en repositorios de componentes, procesamiento distribuido tales como
evaluación, adaptación a nuevos entornos, CORBA [17], RMI [18] y .NET Remoting
integración con otros componentes y acceso a [13].
información de soporte.
Adicionalmente, para favorecer su III. LA INTERFAZ DE UN
reutilización es deseable que un componente sea: COMPONENTE
• genérico: sus servicios pueden ser usados en
una gran variedad de aplicaciones. Una interfaz define el conjunto de operaciones
que un componente puede realizar; estas
operaciones son llamadas también servicios o
 4

responsabilidades. Las interfaces proveen un (precondiciones) y salida (postcondiciones)

mecanismo para interconectar componentes y de las operaciones.
controlar las dependencias entre ellos. 3. Sincronización: expresan aspectos de
La naturaleza de la interfaz varia dependiendo concurrencia.
del lenguaje programación empleado para 4. Calidad de Servicio: contempla atributos
implementar el componente. Los lenguajes tales como tiempo de respuesta, uso de
orientados a objetos (e.g. Smalltalk-80 [19], C++ memoria, precisión, confiabilidad, facilidad
[20] y Java [21]) soportan alguna forma de de mantenimiento y reutilización, entre otros.
interfaz, que por lo general están separadas de las Se han realizado algunos intentos para que las
implementaciones. En lenguajes procedimentales interfaces expresen mejor las propiedades
(e.g. Pascal [22] y FORTRAN [23]) las interfaces extrafuncionales, tales como el lenguaje de
se definen a través de declaraciones de funciones programación Eiffel [26] y el método formal
o procedimientos y el uso de variables globales. Object-Z [27] para propiedades de
Algunos lenguajes neutrales de especificación de comportamiento, Object Calculus [28] para
interfaces han sido desarrollados tales como IDL propiedades de sincronización y la notación
(Interface Definition Language) [17] de OMG NoFun [29] para las propiedades de calidad de
(Object Management Group). servicio.
En general, una interfaz de programación de Los párrafos anteriores sólo describen a las
aplicaciones (API, Application Programming interfaces como una manera de especificar el flujo
Interface) es una especificación, en un lenguaje unidireccional de dependencia que tiene un
de programación, de las propiedades de un cliente con respecto a un componente. Sin
módulo de software. Los clientes del módulo sólo embargo, es mejor decir que un cliente y un
deben depender exclusivamente de las componente dependen el uno del otro; un cliente
propiedades definidas por el API de forma depende de la forma en que un componente
explícita. provee sus servicios, y un componente depende
Algunas tecnologías (e.g. Enterprise de cómo los clientes utilizan los servicios que éste
JavaBeans [11]) exigen que sus componentes ofrece. Esta interdependencia ha llevado a acuñar
implementen dos tipos de interfaces: el término Contrato de Interfaz [2], [8] en la
1. interfaz de negocio: que refleja el rol del literatura de investigación acerca sistemas
componente en el sistema. basados en componentes.
2. interfaz de infraestructura: es impuesta por el
modelo de componentes con el fin de IV. FRAMEWORKS Y MODELOS DE
permitirle al framework interactuar con el COMPONENTES
componente.
Por otra parte, nótese que las interfaces Existe cierta confusión en la literatura
referente a la terminología de modelos y
convencionales definen la firma de las
operaciones (nombre de la operación, tipo y orden frameworks de componentes. Sin embargo, hay
de los argumentos, y la manera como se consenso acerca de que los sistemas basados en
componentes confían en estándares y
devuelven los resultados) que provee un
componente. Las operaciones también se conocen convenciones bien definidas (modelo de
como Propiedades Funcionales. Sin embargo, componentes) y en una infraestructura de soporte
(framework de componentes).
estas interfaces no expresan adecuadamente
propiedades del componente relativas a, por Los modelos de componentes especifican las
ejemplo, su desempeño, precisión, disponibilidad, reglas de diseño que deben obedecer los
componentes. Estas reglas de diseño mejoran la
latencia, seguridad, entre otras. Dichas
propiedades se conocen como Propiedades composición, aseguran que las calidades de
Extrafuncionales [24]. servicio se logren en todo el sistema, y que los
componentes se puedan desplegar fácilmente
Es útil diferenciar los tipos de propiedades de
los componentes. Por ejemplo, Beugnard et al. tanto en entornos de desarrollo como de
[25] define cuatro tipos de propiedades producción.
Los modelos de componentes imponen
relacionadas con:
1. Sintaxis: corresponden a las propiedades estándares y convenciones sobre:
funcionales expresadas explícitamente a • Tipos de Componentes: Un tipo de
través de la interfaz del componente. componente puede ser definido en términos
2. Comportamiento: definen las condiciones de las interfaces que implementa. Los tipos
que deben cumplir los valores de entrada diferentes de componentes pueden
 5

desempeñar diferentes roles en el sistema, y Un mercado robusto de componentes de

participar en distintos tipos de esquemas de software requiere modelos y frameworks
interacción. estandarizados. Sin embargo, la experiencia ha
• Esquemas de Interacción: especifican cómo demostrado que distintos dominios de aplicación
los componentes son localizados, cuáles tienen diferentes requisitos de funcionalidad y
protocolos de comunicación son utilizados, y calidad de servicio (e.g. latencia, seguridad y
cómo se satisfacen las calidades de servicio disponibilidad). Esto sugiere la necesidad de
(e.g. seguridad, transacciones, alta tener una variedad modelos y frameworks de
disponibilidad). El modelo de componentes componentes para cada dominio. EJB, CCM y
puede describir cómo interactúan los .NET se han abocado al dominio de aplicaciones
componentes entre sí y cómo interactúan empresariales (ERP, BPM, e-commerce y
dichos componentes con el framework. sistemas financieros) el cual es lo suficientemente
• Asociación (bindings) de recursos: El grande y coherente para definir estándares de
proceso de composición de componentes es modelos y frameworks de componentes. Sin
simplemente enlazar un componente a uno o embargo, existen iniciativas que están abordando
más recursos. Un recurso es un servicio otros dominios de aplicación. Las más notorias
ofrecido por un framework o por otro son las promovidas por OMG para el control de
componente desplegado en ese framework. tráfico aéreo, análisis de secuencias
Un modelo de componentes describe cuáles biomoleculares, mapas genómicos, infraestructura
recursos están disponibles a los componentes, de clave pública, entre otras. Adicionalmente,
y cómo y cuándo se asocian estos WaterBeans [30] y SIMyO [31] son iniciativas
componentes a éstos recursos. relacionadas con tratamiento de agua, y modelado
Por otra parte, los frameworks de y optimización, respectivamente.
componentes proporcionan servicios que soportan
y hacen cumplir el modelo componentes V. MECANISMOS DE COMPOSICIÓN
asociado. El framework maneja recursos DE SOFTWARE
compartidos por los componentes, y proporciona
Bajo el modelo de desarrollo de software
mecanismos subyacentes que permiten la
basado en componentes, las nuevas aplicaciones
comunicación (interacción) entre ellos. Los
se construyen mediante la integración o
frameworks son activos y actúan directamente
composición de componentes. Sametinger [2]
sobre componentes, por ejemplo administrando su
define la composición de software como “el
ciclo de vida (comenzar, suspender, reasumir, o
proceso de construir aplicaciones mediante la
terminar la ejecución de un componente), y otros
interconexión de componentes de software a
recursos.
través de sus interfaces (de composición)". Nótese
Existen muchos ejemplos de frameworks de
que se hace especial énfasis en las interfaces
componentes, entre éstos Enterprise JavaBeans
como elementos fundamentales para lograr la
(EJB) [11] y VisualBasic Framework (VBF) de
composición de componentes.
Microsoft [14] son de los más representativos. La
La composición puede concebirse como una
especificación de EJB define un framework de
relación cliente-servidor entre dos componentes
servidores y contenedores para dar soporte al
(Figura 1). El componente cliente solicita un
modelo de componentes. Los Servidores EJB son
servicio (operación) del componente servidor, el
responsables de proporcionar servicios de
cual ejecuta la operación solicitada y devuelve los
sistemas tales como persistencia, transacciones y
resultados al cliente. El servidor produce un
seguridad, mientras que los Contenedores EJB
resultado que es consumido por el cliente.
son responsables de manejar el ciclo de vida del
componente. Por su parte, VBF es quizás el
solicita un servicio
framework más popular para el desarrollo de
aplicaciones de escritorio. Se concentra en la C1 C2
composición visual de componentes (llamados
consume el servicio
VBXs) más que en tener un entorno que garantice
la calidad de servicio de éstos. VBF incluye al Figura 1. Interacción entre
intérprete de VisualBasic (para ejecutar scripts y componentes.
hacer composición) y el Modelo de Objetos de
Componentes (COM, Component Object Model) Además de los componentes, los frameworks
[7] (encargado de los servicios de despliegue y también se consideran entidades sujetas a
comunicación). composición. En consecuencia, existen tres clases
 6

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

Ingeniería de Dominios

Análisis del Diseño del Desarrollo de

Dominio Dominio Componentes

modelos diseños componentes

Especificación
de requerimentos
de genéricos
análisis

Diseño de la Especificación Búsqueda de Adapt / Des. Integración de

Arquitectura De Componentes Componentes Componentes Componentes

Ingeniería de Aplicaciones
Figura 2. El modelo de procesos gemelos para el desarrollo de software basado en componentes

Un modelo alternativo al modelo de Ingeniería ejecución de los procesos técnicos de desarrollo

de Aplicaciones es el modelo WATCH [34], [35]. de aplicaciones, indicando además cómo los
Este modelo combina los procesos más relevantes procesos gerenciales controlan o coordinan el
de la Ingeniería de Software Orientada a Objetos orden de ejecución de los procesos técnicos. Los
con el modelo de Ingeniería de Aplicaciones del procesos gerenciales están ubicados en el centro
ciclo de vida gemelo. Una característica de la estructura para indicar explícitamente que
importante de este modelo es la integración de los ellos programan, dirigen y controlan el proceso de
procesos gerenciales con los procesos técnicos del desarrollo. Los procesos técnicos están ubicados
desarrollo de software basado en componentes. en el entorno siguiendo la forma que tiene el dial
Esta integración facilita la labor del líder del de un reloj. Ello indica que el orden de ejecución
proyecto, al describir cómo se debe llevar a cabo de las fases técnicas se realiza en el sentido de las
una gestión del proyecto integrada a los procesos agujas del reloj. Los procesos gerenciales pueden,
técnicos del desarrollo de software. sin embargo, invertir el orden de ejecución para
La estructura del método WATCH se ilustra repetir algunas de las fases anteriores.
en la Figura 3. Esta estructura emplea la metáfora
de un reloj de pulsera para describir el orden de

Procesos de
Post-desarrollo

Análisis del
Dominio de
Apliación

Descubrimiento
Entrega del
de
Sistema
Requerimientos

Análisis y
Pruebas del Procesos
Especificación de
Sistema gerenciales
Requerimientos

Implementación Diseño del

del Sistema Sistema

Diseño de
Componentes

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

Las tres primeras fases del modelo son La fase de Análisis del Contexto permite que el
similares a los modelos de procesos tradicionales. grupo de desarrollo adquiera un conocimiento
 8

adecuado del dominio o contexto del sistema en Software Heterogéneos en Aplicaciones

desarrollo. Las fases de Descubrimiento, Análisis Espacio-Temporales” (G-97000824).
y Especificación de Requerimientos se encargan
de identificar las necesidades y requerimientos de IX. REFERENCIAS
los usuarios, así como analizarlos, especificarlos
gráficamente y documentarlos. [1] I. Sommerville. Software engineering.
Addison-Wesley Pub Co, 6ta edición,
La fase de diseño del sistema establece y
Agosto 2000.
describe la arquitectura del software. Describe
[2] J. Sametinger. Software engineering with
cada uno de los componentes que requiere tal
reusable components. Springer Verlag,
estructura y cómo esos componentes se
Agosto 1997.
interconectan para interactuar. El grupo de
[3] J. Sodhi, y P. Sodhi. Software reuse:
desarrollo debe, a partir de esta arquitectura,
Domain analysis and design process.
determinar cuáles componentes se pueden
McGraw-Hill. 1999.
reutilizar y cuáles requieren ser desarrollados en
[4] A. W. Brown and K. C.Wallnau. The
su totalidad. Los componentes reutilizados deben
current state of CBSE. IEEE Software,
ser adaptados, para satisfacer los requerimientos
15(5):37-46, Septiembre 1998.
del sistema; mientras que los componentes
[5] C. Szyperski. Component software:
nuevos, deben ser diseñados, codificados y
Beyond object-oriented programming.
probados separadamente durante la fase de
Addison-Wesley Pub Co, 2da edición,
Implementación. Las Pruebas del sistema
Noviembre 2002.
permiten detectar errores en la integración de los
[6] P. Herzum and O. Sims. Business
componentes. Finalmente, la fase de Entrega se
component factory : A comprehensive
encarga de la instalación, adiestramiento de
overview of component-based
usuarios y puesta en operación del sistema.
development for the enterprise. John
Wiley & Sons, 2000.
VII. CONCLUSIONES
[7] CDBI Forum. Component based
Los beneficios derivados de la reutilización de development: Using componentised
software están ocasionando un cambio acelerado software.
en la manera en que la industria de software http://www.cdbiforum.com,
desarrolla sus productos. Los componentes de Mayo 1999.
software reutilizables constituyen las unidades [8] F. Bachmann, L. Bass, Ch. Buhman, S.
fundamentales para el desarrollo de nuevas Comella-Dorda, F. Long, J. Robert, R.
aplicaciones. En este artículo, se ha hecho un Seacord y K. Wallnau. Volume II:
intento por destacar la importancia y caracterizar Technical concepts of component-based
el proceso de desarrollo de software basado en la software engineering, 2nd edition.
reutilización de componentes. Se estableció una Technical report, Software Engineering
comparación entre los conceptos de activos Institute, Carnegie Mellon University,
reutilizables y componentes de software. Se Julio 2000.
describieron las características requeridas y [9] T. Budd. Introducción a la
deseables de un componente de software para su programación orientada a objetos.
reutilización. Adicionalmente, se describieron los Addison-Wesley Iberoamericana. 1994.
conceptos de interfaz, modelo y framework de [10] L. Joyanes Aguilar. Programación
componentes, así como también mecanismos de orientada a objetos. McGraw-Hill
composición de software. Finalmente, se Interamericana, Diciembre 1998.
discutieron algunos de los aspectos [11] Sun Microsystems, Inc. Enterprise
metodológicos que rigen el desarrollo de javabeans specification, version 2.0.
componentes y de aplicaciones basadas en la http://java.sun.com/product
reutilización de componentes. s/ejb/docs.html, Agosto 2001.
[12] Object Management Group Inc. Corba
VIII. AGRADECIMIENTOS components.
http://www.omg.org/cgi-
Los autores agradecen el apoyo económico
bin/doc?formal/02-06-65, Junio
suministrado por el Fondo Nacional de Ciencia,
Tecnología e Innovación (FONACIT-Venezuela) 2002.
a través de el proyecto de investigación titulado
“Integración de Tecnologías y Sistemas de
 9

[13] T. L. Thai and H. Lam. .NET framework [27] R. Duke, G. Rose y G. Smith. Object-Z:
essentials. O'Reilly & Associates, 3ra A specification language advocated for
edición, 2003. the description of standards. Computer
[14] D. Chappell. Understanding ActiveX and Standards and Interfaces, 17:511-533,
OLE. Microsoft Press, 1ra edición, Enero Septiembre 1995.
1996. [28] K. Lano, J. Bicarregui, J. Luiz Fiadeiro y
[15] Sun Microsystems, Inc. Javabeans. T. Maibaum. Composition of reactive
http://java.sun.com/product system components. En 1st Workshop on
s/javabeans/docs/spec.html, Component-Based Systems, Zurich,
Agosto 1997. Switzerland, 1997.
[16] J. Morris, G. Lee, K. Parker, G.A. [29] X. Franch. Systematic formulation of
Bundell, y C.P. Lam. Software non-functional characteristics of
component certification. IEEE software.
Computer, 34(9), Septiembre, 2001. In 3rd International Conference on
[17] Object Management Group, Inc. Requirements Engineering (ICRE),
Common object request broker pages 174-181, Colorado Springs (USA).
architecture: Core specification. [30] K. C. Wallnau and D. Plakosh.
http://www.omg.org/docs/for Waterbeans: A custom component model
mal/02-12-06.pdf, Diciembre and framework.
2002. http://www.sei.cmu.edu/cbs/
[18] Sun Microsystems, Inc. Java remote cbse2000/papers/23/23.html,
method invocation specification. 2000.
ftp://ftp.java.sun.com/docs [31] C. Arévalo, J. Colmenares, N. Queipo,
/j2se1.4/rmi-spec-1.4.pdf. N. Arapé y J. Villalobos. A CORBA and
[19] A. Goldberg and D. Robson. Smalltalk Web technology based framework for
80 : The language. Addison-Wesley Pub the analysis and optimal design of
Co, Enero 1989. complex systems in the oil industry. En
[20] B. Stroustrup. The C++ programming 3rd Internacional Conference on
language. Addison-Wesley Pub Co, 3ra Enterprise Information Systems (ICEIS
edición, Febrero 2000. 2001), Julio 2001.
[21] B. Joy, G. Steele, J. Gosling y G. [32] E. Gamma, R. Helm, R. Johnson y J.
Bracha. The Java(TM) languaje Vlissides. Design patterns. Addison-
specification. Addison-Wesley Pub Co, Wesley Pub Co, Enero 1995.
2da edición, Junio 2000.
[22] D. W. Nance. Pascal: Understanding [33] F. Marinescu. EJB design patterns:
programming and problem solving. West Advanced patterns, processes and
Information Pub Group, 4ta edición, idioms. John Wiley & Sons, Febrero
Enero 1995. 2002.
[23] D. Rev. Smorlarski, Research [34] J. Montilva, K. Hazam y M. Gharawi.
& Education Association y The Watch Model for development
Dennis Chester Smolarski. The business software in small and midsize
essentials of FORTRAN (essentials). organization. In IV World
Research & Education Assn, Mayo Multiconference on Systemics,
1994. Cybernetics and Informatics (SCI'2000),
[24] T. Digre. Business object component Orlando, Florida (USA), Julio 2000.
architecture. IEEE Software, 15(5), [35] J. Montilva and J. Barrios. A
1998. Component-Based Method for
[25] A. Beugnard, J-M Jézéquel y N. Developing Web Applications. 5th
Plouzeau. Making components contract International Conference on Enterprise
aware. IEEE Computer, 32(7):38-45, Information Systems (ICEIS’2003),
Julio 1999. Angers, France, 2003.
[26] B. Meyer. Eiffel: The language. Prentice
Hall PTR, Octubre, 1991.