You are on page 1of 10

See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/228852721

Desarrollo de Software Basado en Componentes

Article

CITATION READS

1 652

3 authors:

Jonas Montilva Nelson Arap


University of the Andes (Venezuela) University of Zulia
55 PUBLICATIONS 93 CITATIONS 5 PUBLICATIONS 17 CITATIONS

SEE PROFILE SEE PROFILE

Juan A. Colmenares
Samsung
35 PUBLICATIONS 214 CITATIONS

SEE PROFILE

Available from: Nelson Arap


Retrieved on: 24 November 2016
1

Desarrollo de Software Basado en Componentes


Jons A. Montilva C.1, Nelson Arap2 y Juan Andrs Colmenares2
1 2
Universidad de Los Andes Universidad del Zulia
Facultad de Ingeniera Facultad de Ingeniera
Escuela de Ingeniera de Sistemas Instituto de Clculo Aplicado
Departamento de Computacin Maracaibo - Venezuela
Mrida Venezuela
+58-274-2403811
jonas@ing.ula.ve, narape@ica.luz.ve, juancol@ica.luz.ve

Resumen-- La Orientacin a Objetos Existen variadas definiciones del trmino


introdujo, durante la dcada pasada, un Reutilizacin de Software. Algunas de estas
cambio radical en el proceso de desarrollo de definiciones son las siguientes:
software. De un proceso caracterizado por su Segn Somerville [1], la reutilizacin es un
nfasis en la descripcin algortmica de la enfoque de desarrollo [de software] que trata
solucin del problema, se pas a un proceso de maximizar el uso recurrente de
orientado a la representacin y manipulacin componentes de software existentes.
de los objetos que caracterizan el problema. Segn Sametinger [2], la reutilizacin de
Este paradigma abri, tambin, nuevas software es el proceso de crear sistemas de
posibilidades para desarrollar software basado software a partir de software existente, en
en la nocin de reutilizacin de componentes. lugar de desarrollarlo desde el comienzo.
La Orientacin a Objetos cre un rumbo Segn Sodhi et al. [3], la reutilizacin de
diferente en el proceso de reutilizacin a travs software es el proceso de implementar o
de la produccin de componentes genricos, actualizar sistemas de software usando
fciles de integrar, distribuidos e activos de software existentes.
independientes de las plataformas de Estas tres definiciones consideran la
desarrollo. En este artculo, de carcter reutilizacin como un enfoque o proceso de
tutorial, se discuten los conceptos desarrollo de software. Su principal diferencia
fundamentales de la reutilizacin de software, radica en el objeto de reutilizacin (componente,
as como los modelos de procesos y los aspectos software y activo). Tal como lo plantean Sodhi et
metodolgicos que caracterizan esta nueva al. [3], la reutilizacin de software va ms all de
manera de producir software, denominada la reutilizacin de piezas de software. Ella
Desarrollo de Software basado en involucra el uso de otros elementos de software,
Componentes. tales como algoritmos, diseos, arquitecturas de
software, documentacin y especificaciones de
Palabras clavedesarrollo de software, requerimientos.
reutilizacin de software, componentes de Con base en el anlisis de estas definiciones
software. podemos establecer nuestra propia definicin en
los siguientes trminos:
La reutilizacin de software es un proceso de
I. INTRODUCCIN la Ingeniera de Software que conlleva al uso
La reutilizacin de componentes de software recurrente de activos de software en la
es un proceso inspirado en la manera en que se especificacin, anlisis, diseo,
producen y ensamblan componentes en la implementacin y pruebas de una aplicacin o
ingeniera de sistemas fsicos. La aplicacin de sistema de software.
este concepto al desarrollo de software no es Varios estudios han demostrado la efectividad
nueva. Las libreras de subrutinas especializadas, de la reutilizacin del software. Sametinger [2],
comnmente utilizadas desde la dcada 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 cdigo fuente de una
aplicacin es reutilizable en otra similar.

* Publicado en las Actas del IV Congreso de Automatizacin y Control (CAC03), Mrida, Noviembre, 2003.
2

Aproximadamente el 60% del diseo y del software orientadas a reducir drsticamente el


cdigo 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 ms de un programa. denominado Componente de Software. Se han
Slo el 15% del cdigo encontrado en propuesto numerosas definiciones a este trmino,
muchos sistemas es nico y novedoso a una entre las cuales destacan las siguientes:
aplicacin especfica. El rango general de uso Segn 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 fcil deducir sistema que cumple una funcin dentro del
el impacto y la importancia que tiene la contexto de una arquitectura bien definida.
reutilizacin de componentes en el proceso de Un componente cumple con un conjunto de
desarrollo de software; particularmente, en tres de interfaces y provee la realizacin fsica de
las variables ms importantes de la Ingeniera de ellas.
Software: el costo, tiempo y esfuerzo requerido Segn Clemens Szyperski [5], un
para desarrollar un producto de software. La componente de software es una unidad de
aplicacin apropiada de la reutilizacin en un composicin con interfaces especificadas
proyecto de software conduce, indiscutiblemente, contractualmente y solamente dependencias
a una reduccin significativa de los valores de explcitas 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 composicin por terceros.
grupos de desarrollo y la reduccin del riesgo Segn Herzum y Sims [6], un componente es
global del proyecto. un artefacto de software autocontenido y
Este artculo tiene un carcter tutorial y su claramente identificable que describe
objetivo es describir los fundamentos y aspectos ejecuta funciones especficas; que tiene,
metodolgicos del desarrollo de software basado adems, una interfaz claramente establecida,
en componentes. En la seccin 2 se establecen los una documentacin apropiada y un status de
conceptos de activo reutilizable y componente de uso recurrente bien definido.
software; de estos ltimos se exponen las Segn el CBDi Forum [7], un componente es
caractersticas mnimas y deseables que favorecen una pieza de software que describe y/o libera
su reutilizacin. Las secciones 3, 4 y 5 discuten un conjunto de servicios que son usados slo
cmo los componentes se acoplan. Para ello se a travs de interfaces bien definidas.
describe el papel de las interfaces, modelos y Ms recientemente, el Instituto de Ingeniera
frameworks de componentes, y se analizan de Software (SEI, Software Engineering Institute)
algunos de los mecanismos de composicin de de la Universidad Carnegie-Mellon formul una
software ms utilizados. Finalmente, la seccin 6 definicin con el propsito de consolidar las
describe los modelos de procesos y los aspectos diferentes opiniones acerca de lo que deba ser un
metodolgicos que rigen esta nueva forma de componente de software. Segn el SEI [8], un
producir software. componente es una implementacin opaca de
funcionalidad, sujeta a composicin 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 implementacin opaca debido a que
En el contexto de Ingeniera de Software, un
su distribucin predominantemente es en formato
Activo Reutilizable es un producto diseado
binario y sus consumidores lo utilizan como una
expresamente para ser empleado de forma
caja negra a travs 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 programacin orientada a objetos [9], [10].
son: algoritmos, patrones de diseo, esquemas de
Por otra parte, la composicin por terceros
base de datos, arquitecturas de software,
implica que los componentes son intrnsecamente
especificaciones de requerimientos, de diseo y
reutilizables debido a que un sistema basado en
de prueba, entre otros.
componentes puede ser ensamblado con relativa
En los ltimos aos, como resultado de
facilidad por un integrador empleando
presiones crecientes sobre la industria del
componentes suministrados por mltiples
3

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


coordinacin e interaccin entre componentes componente dependa lo menos posible de
exige un marco regulatorio estandarizado (modelo otros componentes para cumplir su funcin
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 diseo de los modificado individualmente.
mismos. mantenido: es deseable que un componente
Tal como lo refleja la definicin 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. implementacin: los componentes se pueden que incluyan correctivos, optimizaciones y
ensamblar y desplegar para crear sistemas y nuevas caractersticas. Esto contribuye a que
aplicaciones que se ejecutan en un dicho componente sea seleccionado con
computador mayor frecuencia para formar parte de
2. abstraccin de arquitectura: los componentes sistemas de software.
expresan las reglas de diseo que impone el independiente de la plataforma (hardware
modelo de componentes. y sistema operativo), del lenguaje de
Estn disponibles diversas tecnologas de programacin y de las herramientas de
componentes tpicamente asociadas con desarrollo: existen diversas plataformas de
infraestructuras de procesamiento distribuido (e.g. cmputo 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 caractersticas ms importantes de lenguajes de programacin 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
mnimo el siguiente conjunto de caractersticas: herramientas de la preferencia del
identificable: un componente debe tener una programador, por lo tanto es deseable que
identificacin clara y consistente que facilite dichas preferencias no limiten el uso de los
su catalogacin y bsqueda en repositorios de componentes.
componentes. puede ser reutilizado dinmicamente:
accesible slo a travs de su interfaz: el puede ser cargado en tiempo de ejecucin en
componente debe exponer al pblico una aplicacin.
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
implementacin. Esta caracterstica permite independiente o mediante la aplicacin de
que un componente sea reemplazado por otro modelos de auto-certificacin 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
travs de su interfaz, no deben variar. La localidad: la forma de invocar los servicios
implementacin de estos servicios puede ser ofrecidos por los componentes debiese ser
modificada, pero no deben afectar la interfaz. independiente de su ubicacin (local o
documentado: un componente debe tener remota). Para ello el modelo de componentes
una documentacin adecuada que facilite su debera estar basado en tecnologas de
bsqueda en repositorios de componentes, procesamiento distribuido tales como
evaluacin, adaptacin a nuevos entornos, CORBA [17], RMI [18] y .NET Remoting
integracin con otros componentes y acceso a [13].
informacin de soporte.
Adicionalmente, para favorecer su III. LA INTERFAZ DE UN
reutilizacin es deseable que un componente sea: COMPONENTE
genrico: 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 tambin 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. Sincronizacin: expresan aspectos de
La naturaleza de la interfaz varia dependiendo concurrencia.
del lenguaje programacin 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, precisin, confiabilidad, facilidad
[20] y Java [21]) soportan alguna forma de de mantenimiento y reutilizacin, entre otros.
interfaz, que por lo general estn 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 travs de declaraciones de funciones programacin Eiffel [26] y el mtodo formal
o procedimientos y el uso de variables globales. Object-Z [27] para propiedades de
Algunos lenguajes neutrales de especificacin de comportamiento, Object Calculus [28] para
interfaces han sido desarrollados tales como IDL propiedades de sincronizacin y la notacin
(Interface Definition Language) [17] de OMG NoFun [29] para las propiedades de calidad de
(Object Management Group). servicio.
En general, una interfaz de programacin de Los prrafos anteriores slo describen a las
aplicaciones (API, Application Programming interfaces como una manera de especificar el flujo
Interface) es una especificacin, en un lenguaje unidireccional de dependencia que tiene un
de programacin, de las propiedades de un cliente con respecto a un componente. Sin
mdulo de software. Los clientes del mdulo slo 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
explcita. provee sus servicios, y un componente depende
Algunas tecnologas (e.g. Enterprise de cmo los clientes utilizan los servicios que ste
JavaBeans [11]) exigen que sus componentes ofrece. Esta interdependencia ha llevado a acuar
implementen dos tipos de interfaces: el trmino Contrato de Interfaz [2], [8] en la
1. interfaz de negocio: que refleja el rol del literatura de investigacin 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, ntese que las interfaces Existe cierta confusin en la literatura
referente a la terminologa de modelos y
convencionales definen la firma de las
operaciones (nombre de la operacin, 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 confan en estndares y
devuelven los resultados) que provee un
componente. Las operaciones tambin 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 desempeo, precisin, disponibilidad, reglas de diseo que deben obedecer los
componentes. Estas reglas de diseo mejoran la
latencia, seguridad, entre otras. Dichas
propiedades se conocen como Propiedades composicin, aseguran que las calidades de
Extrafuncionales [24]. servicio se logren en todo el sistema, y que los
componentes se puedan desplegar fcilmente
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 produccin.
Los modelos de componentes imponen
relacionadas con:
1. Sintaxis: corresponden a las propiedades estndares y convenciones sobre:
funcionales expresadas explcitamente a Tipos de Componentes: Un tipo de
travs de la interfaz del componente. componente puede ser definido en trminos
2. Comportamiento: definen las condiciones de las interfaces que implementa. Los tipos
que deben cumplir los valores de entrada diferentes de componentes pueden
5

desempear diferentes roles en el sistema, y Un mercado robusto de componentes de


participar en distintos tipos de esquemas de software requiere modelos y frameworks
interaccin. estandarizados. Sin embargo, la experiencia ha
Esquemas de Interaccin: especifican cmo demostrado que distintos dominios de aplicacin
los componentes son localizados, cules tienen diferentes requisitos de funcionalidad y
protocolos de comunicacin son utilizados, y calidad de servicio (e.g. latencia, seguridad y
cmo 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 cmo interactan los .NET se han abocado al dominio de aplicaciones
componentes entre s y cmo interactan empresariales (ERP, BPM, e-commerce y
dichos componentes con el framework. sistemas financieros) el cual es lo suficientemente
Asociacin (bindings) de recursos: El grande y coherente para definir estndares de
proceso de composicin de componentes es modelos y frameworks de componentes. Sin
simplemente enlazar un componente a uno o embargo, existen iniciativas que estn abordando
ms recursos. Un recurso es un servicio otros dominios de aplicacin. Las ms notorias
ofrecido por un framework o por otro son las promovidas por OMG para el control de
componente desplegado en ese framework. trfico areo, anlisis de secuencias
Un modelo de componentes describe cules biomoleculares, mapas genmicos, infraestructura
recursos estn disponibles a los componentes, de clave pblica, entre otras. Adicionalmente,
y cmo y cundo 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 optimizacin, respectivamente.
componentes proporcionan servicios que soportan
y hacen cumplir el modelo componentes V. MECANISMOS DE COMPOSICIN
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
comunicacin (interaccin) entre ellos. Los
se construyen mediante la integracin o
frameworks son activos y actan directamente
composicin de componentes. Sametinger [2]
sobre componentes, por ejemplo administrando su
define la composicin de software como el
ciclo de vida (comenzar, suspender, reasumir, o
proceso de construir aplicaciones mediante la
terminar la ejecucin de un componente), y otros
interconexin de componentes de software a
recursos.
travs de sus interfaces (de composicin)". Ntese
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
composicin de componentes.
Microsoft [14] son de los ms representativos. La
La composicin puede concebirse como una
especificacin de EJB define un framework de
relacin 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 (operacin) del componente servidor, el
responsables de proporcionar servicios de
cual ejecuta la operacin 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 quizs el
solicita un servicio
framework ms popular para el desarrollo de
aplicaciones de escritorio. Se concentra en la C1 C2
composicin visual de componentes (llamados
consume el servicio
VBXs) ms que en tener un entorno que garantice
la calidad de servicio de stos. VBF incluye al Figura 1. Interaccin entre
intrprete de VisualBasic (para ejecutar scripts y componentes.
hacer composicin) y el Modelo de Objetos de
Componentes (COM, Component Object Model) Adems de los componentes, los frameworks
[7] (encargado de los servicios de despliegue y tambin se consideran entidades sujetas a
comunicacin). composicin. En consecuencia, existen tres clases
6

principales de interaccin 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 seccin son:
interaccin entre componentes. De este tipo cmo se desarrolla un componente? y cmo se
de interaccin se obtiene la funcionalidad de crea una aplicacin que reutilice componentes
la aplicacin, de forma tal que los contratos existentes?
que especifican este tipo de interaccin Sommerville [1] clasifica los procesos de
pueden ser clasificados como Contratos a desarrollo de software basados en la reutilizacin
Nivel de Aplicacin. de componentes en dos categoras:
2. Componente-Framework (C-F): posibilita las Desarrollo de componentes: Este proceso
interacciones entre el framework y sus implica la adaptacin o desarrollo de
componentes. Dicha interaccin permite que componentes con el propsito 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 caractersticas descritas en la Seccin 2.
composicin de componentes desplegados en Desarrollo de software con reutilizacin de
framewoks heterogneos. Estos contratos componentes: Es un proceso en el cual el
puede ser clasificados como Contratos de desarrollo de una nueva aplicacin involucra
Interoperabilidad. la reutilizacin de un conjunto de
La forma de materializar la composicin entre componentes existentes. Este enfoque
componentes depende de los mecanismos maximiza la reutilizacin de componentes de
especificados por su modelo de programacin. software existentes y reduce el nmero de
Tpicamente, los modelos de componentes se componentes que requieren ser desarrollados
basan en tecnologas orientadas a objetos, por lo en su totalidad (desde cero). Para ser exitoso,
tanto los mecanismos de composicin emplean este proceso demanda dos condiciones
algunas caractersticas tales como relaciones entre mnimas: i) la existencia de repositorios o
clases (especializacin, agregacin, asociacin y bases de componentes reutilizables y ii) que
uso) [10], polimorfismo y enlace dinmico [9]. los componentes sean confiables y acten de
Adicionalmente, dichos mecanismo de acuerdo a sus especificaciones.
composicin tpicamente se describen mediante el El modelo de procesos descrito por
uso de patrones de diseo [32], [33]. Sametinger [2] provee, sin embargo, una visin
Las tecnologas de componentes no mucho ms completa y amplia del desarrollo de
distribuidos, tpicamente 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
caractersticas orientadas a objetos dentro de sus grandes bloques paralelos, tal como se ilustra en
mecanismos de composicin. Por el contrario, en la Figura 2. El primer bloque, conocido como
la composicin de componentes distribuidos (e.g. Ingeniera 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, asociacin y bloque es denominado Ingeniera de
agregacin. Aplicaciones. Su propsito es el desarrollo de
aplicaciones basado en la reutilizacin de activos
VI. EL PROCESO DE DESARROLLO de software producidos a travs de la Ingeniera
de Dominios.
En las secciones anteriores, se caracterizaron
los componentes de software y se describieron los
7

Ingeniera de Dominios

Anlisis del Diseo del Desarrollo de


Dominio Dominio Componentes

modelos diseos componentes


Especificacin
de genricos
de requerimentos
anlisis

Diseo de la Especificacin Bsqueda de Adapt / Des. Integracin de


Arquitectura De Componentes Componentes Componentes Componentes

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

Un modelo alternativo al modelo de Ingeniera ejecucin de los procesos tcnicos de desarrollo


de Aplicaciones es el modelo WATCH [34], [35]. de aplicaciones, indicando adems cmo los
Este modelo combina los procesos ms relevantes procesos gerenciales controlan o coordinan el
de la Ingeniera de Software Orientada a Objetos orden de ejecucin de los procesos tcnicos. Los
con el modelo de Ingeniera de Aplicaciones del procesos gerenciales estn ubicados en el centro
ciclo de vida gemelo. Una caracterstica de la estructura para indicar explcitamente que
importante de este modelo es la integracin de los ellos programan, dirigen y controlan el proceso de
procesos gerenciales con los procesos tcnicos del desarrollo. Los procesos tcnicos estn ubicados
desarrollo de software basado en componentes. en el entorno siguiendo la forma que tiene el dial
Esta integracin facilita la labor del lder del de un reloj. Ello indica que el orden de ejecucin
proyecto, al describir cmo se debe llevar a cabo de las fases tcnicas se realiza en el sentido de las
una gestin del proyecto integrada a los procesos agujas del reloj. Los procesos gerenciales pueden,
tcnicos del desarrollo de software. sin embargo, invertir el orden de ejecucin para
La estructura del mtodo WATCH se ilustra repetir algunas de las fases anteriores.
en la Figura 3. Esta estructura emplea la metfora
de un reloj de pulsera para describir el orden de

Procesos de
Post-desarrollo

Anlisis del
Dominio de
Apliacin

Descubrimiento
Entrega del
de
Sistema
Requerimientos

Anlisis y
Pruebas del Procesos
Especificacin de
Sistema gerenciales
Requerimientos

Implementacin Diseo del


del Sistema Sistema

Diseo de
Componentes

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

Las tres primeras fases del modelo son La fase de Anlisis 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 Heterogneos en Aplicaciones


desarrollo. Las fases de Descubrimiento, Anlisis Espacio-Temporales (G-97000824).
y Especificacin de Requerimientos se encargan
de identificar las necesidades y requerimientos de IX. REFERENCIAS
los usuarios, as como analizarlos, especificarlos
grficamente y documentarlos. [1] I. Sommerville. Software engineering.
Addison-Wesley Pub Co, 6ta edicin,
La fase de diseo 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 cmo 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 cules componentes se pueden
McGraw-Hill. 1999.
reutilizar y cules 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 diseados, codificados y
Beyond object-oriented programming.
probados separadamente durante la fase de
Addison-Wesley Pub Co, 2da edicin,
Implementacin. Las Pruebas del sistema
Noviembre 2002.
permiten detectar errores en la integracin de los
[6] P. Herzum and O. Sims. Business
componentes. Finalmente, la fase de Entrega se
component factory : A comprehensive
encarga de la instalacin, adiestramiento de
overview of component-based
usuarios y puesta en operacin del sistema.
development for the enterprise. John
Wiley & Sons, 2000.
VII. CONCLUSIONES
[7] CDBI Forum. Component based
Los beneficios derivados de la reutilizacin de development: Using componentised
software estn 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 artculo, 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.
reutilizacin de componentes. Se estableci una Technical report, Software Engineering
comparacin entre los conceptos de activos Institute, Carnegie Mellon University,
reutilizables y componentes de software. Se Julio 2000.
describieron las caractersticas requeridas y [9] T. Budd. Introduccin a la
deseables de un componente de software para su programacin orientada a objetos.
reutilizacin. Adicionalmente, se describieron los Addison-Wesley Iberoamericana. 1994.
conceptos de interfaz, modelo y framework de [10] L. Joyanes Aguilar. Programacin
componentes, as como tambin mecanismos de orientada a objetos. McGraw-Hill
composicin de software. Finalmente, se Interamericana, Diciembre 1998.
discutieron algunos de los aspectos [11] Sun Microsystems, Inc. Enterprise
metodolgicos que rigen el desarrollo de javabeans specification, version 2.0.
componentes y de aplicaciones basadas en la http://java.sun.com/product
reutilizacin 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 econmico
bin/doc?formal/02-06-65, Junio
suministrado por el Fondo Nacional de Ciencia,
Tecnologa e Innovacin (FONACIT-Venezuela) 2002.
a travs de el proyecto de investigacin titulado
Integracin de Tecnologas 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
edicin, 2003. the description of standards. Computer
[14] D. Chappell. Understanding ActiveX and Standards and Interfaces, 17:511-533,
OLE. Microsoft Press, 1ra edicin, 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. Arvalo, 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
edicin, 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 edicin, 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 edicin, 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 Jzquel y N. Developing Web Applications. 5th
Plouzeau. Making components contract International Conference on Enterprise
aware. IEEE Computer, 32(7):38-45, Information Systems (ICEIS2003),
Julio 1999. Angers, France, 2003.
[26] B. Meyer. Eiffel: The language. Prentice
Hall PTR, Octubre, 1991.