1

Desarrollo de Software Basado en Componentes

122Jons

A. Montilva C., Nelson Arap y Juan Andrs Colmenares

12Universidad

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 recurrente de activos de software en la La reutilizacin de componentes de software especificacin, anlisis, diseo, es un proceso inspirado en la manera en que se implementacin y pruebas de una aplicacin o producen y ensamblan componentes en la sistema de software. ingeniera de sistemas fsicos. La aplicacin de

Varios estudios han demostrado la efectividad este concepto al desarrollo de software no es de la reutilizacin del software. Sametinger [2], nueva. Las libreras de subrutinas especializadas, en particular, describe algunos de estos comnmente utilizadas desde la dcada de los indicadores: setenta, representan uno de los primeros intentos Entre el 40 y 60% del cdigo fuente de una por reutilizar software. aplicacin es reutilizable en otra similar.

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

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 autocertificacin 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 interfaz define el conjunto de operaciones una gran variedad de aplicaciones. 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. Existe cierta confusin en la literatura Por otra parte, ntese que las interfaces referente a la terminologa de modelos y convencionales definen la firma de las frameworks de componentes. Sin embargo, hay operaciones (nombre de la operacin, tipo y orden consenso acerca de que los sistemas basados en de los argumentos, y la manera como se componentes confan en estndares y devuelven los resultados) que provee un convenciones bien definidas (modelo de componente. Las operaciones tambin se conocen

componentes) y en una infraestructura de soporte como Propiedades Funcionales. Sin embargo, (framework de componentes). estas interfaces no expresan adecuadamente Los modelos de componentes especifican las propiedades del componente relativas a, por reglas de diseo que deben obedecer los ejemplo, su desempeo, precisin, disponibilidad, componentes. Estas reglas de diseo mejoran la latencia, seguridad, entre otras. Dichas composicin, aseguran que las calidades de propiedades se conocen como Propiedades servicio se logren en todo el sistema, y que los Extrafuncionales [24]. componentes se puedan desplegar fcilmente Es til diferenciar los tipos de propiedades de tanto en entornos de desarrollo como de los componentes. Por ejemplo, Beugnard et al. produccin. [25] define cuatro tipos de propiedades Los modelos de componentes imponen relacionadas con: estndares y convenciones sobre: 1. Sintaxis: corresponden a las propiedades Tipos de Componentes: Un tipo de funcionales expresadas explcitamente a componente puede ser definido en trminos travs de la interfaz del componente. de las interfaces que implementa. Los tipos 2. Comportamiento: definen las condiciones

diferentes de componentes pueden que deben cumplir los valores de entrada

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 servicioframework ms

popular para el desarrollo de

aplicaciones de escritorio. Se concentra en la C1C2composicin visual de componentes (llamados

consume el servicioVBXs) 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

Ingeniera de DominiosIngeniera de DominiosAnlisisdel Diseo

delDesarrollodeAnlisisdel Diseo delDesarrollodeDominioDominioComponentesDominioDominioComponentesmodelos diseosmodelos diseosEspecificacincomponentesEspecificacincomponentesdegenricosdegenricosde requerimentosde

requerimentosanlisisanlisisDiseo de laEspecificacin Adapt / Des.Bsqueda deIntegracin deDiseo de laEspecificacin Adapt / Des.Bsqueda deIntegracin deArquitecturaDe ComponentesComponentesComponentesComponentesArquitecturaDe ComponentesComponentesComponentesComponentesIngeniera

de AplicacionesIngeniera 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 dePost-desarrolloAnlisis delDominio deApliacinDescubrimientodeEntrega delRequerimientosSistemaAnlisis yEspecificacin dePruebas delProcesosSistemagerencialesRequerimientosDiseo delImplementacinSistemadel SistemaDiseo deComponentes

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 [1] I. Sommerville. Software engineering. grficamente y documentarlos. 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/productreutilizacin 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, 2002. Tecnologa e Innovacin (FONACIT-Venezuela) 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/productsystem 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/forWaterbeans: 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. Addisonspecification. 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 th[25] A. Beugnard, J-M Jzquel y N. Developing Web Applications. 5 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.