1  Desarrollo de Software Basado en Componentes                  Jonás A. Montilva C.1, Nelson Arapé2 y Juan Andrés Colmen...
2•    Aproximadamente el 60% del diseño y del          software orientadas a reducir drásticamente el     código de aplica...
3proveedores independientes. Finalmente, la              •   autocontenido: es conveniente que uncoordinación e interacció...
4responsabilidades. Las interfaces proveen un                (precondiciones) y salida (postcondiciones)mecanismo para int...
5     desempeñar diferentes roles en el sistema, y        Un mercado robusto de componentes de     participar en distintos...
6principales de interacción en los sistemas basados    mecanismos necesarios para que ellos se integrenen componentes [24]...
7                                                 Ingeniería de Dominios                          Análisis del            ...
8adecuado del dominio o contexto del sistema en        Software   Heterogéneos    en     Aplicacionesdesarrollo. Las fases...
9[13]   T. L. Thai and H. Lam. .NET framework      [27]   R. Duke, G. Rose y G. Smith. Object-Z:       essentials. OReilly...
Próxima SlideShare
Cargando en…5
×

Desarrollo de componentes

351 visualizaciones

Publicado el

informatica

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
351
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
10
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Desarrollo de componentes

  1. 1. 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érminointrodujo, durante la década pasada, un Reutilización de Software. Algunas de estascambio 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 tratasolución del problema, se pasó a un proceso de maximizar el uso recurrente deorientado 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 deEste paradigma abrió, también, nuevas software es el proceso de crear sistemas deposibilidades para desarrollar software basado software a partir de software existente, enen 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 dediferente en el proceso de reutilización a través software es el proceso de implementar ode la producción de componentes genéricos, actualizar sistemas de software usandofáciles de integrar, distribuidos e activos de software existentes.independientes de las plataformas de Estas tres definiciones consideran ladesarrollo. En este artículo, de carácter reutilización como un enfoque o proceso detutorial, se discuten los conceptos desarrollo de software. Su principal diferenciafundamentales 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 etmetodológicos que caracterizan esta nueva al. [3], la reutilización de software va más allá demanera de producir software, denominada la reutilización de piezas de software. EllaDesarrollo 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 definicionessoftware. 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 laes 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 oingenierí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 efectividadnueva. 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 estossetenta, 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.* Publicado en las Actas del IV Congreso de Automatización y Control (CAC03), Mérida, Noviembre, 2003.
  2. 2. 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 delel 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 dedesarrollo de software; particularmente, en tres de interfaces y provee la realización física delas variables más importantes de la Ingeniería de ellas.Software: el costo, tiempo y esfuerzo requerido • Según Clemens Szyperski [5], unpara desarrollar un producto de software. La componente de software es una unidad deaplicación apropiada de la reutilización en un composición con interfaces especificadasproyecto de software conduce, indiscutiblemente, contractualmente y solamente dependenciasa una reducción significativa de los valores de explícitas de contexto. Un componente deestas tres variables. Otros beneficios importantes software puede ser desplegadoson el incremento de la calidad del software independientemente y está sujeto aproducido, 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 esglobal 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 deconceptos 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 escaracterísticas mínimas y deseables que favorecen una pieza de software que describe y/o liberasu reutilización. Las secciones 3, 4 y 5 discuten un conjunto de servicios que son usados sólocó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íaframeworks 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ó unasoftware más utilizados. Finalmente, la sección 6 definición con el propósito de consolidar lasdescribe los modelos de procesos y los aspectos diferentes opiniones acerca de lo que debía ser unmetodológicos que rigen esta nueva forma de componente de software. Según el SEI [8], unproducir 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 formatoActivo Reutilizable es un producto diseñado binario y sus consumidores lo utilizan como unaexpresamente para ser empleado de forma “caja negra” a través de su interfaz. Dicho aspectorecurrente en el desarrollo de muchos sistemas y está alineado con el principio de encapsulamientoaplicaciones. 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 tercerosbase de datos, arquitecturas de software, implica que los componentes son intrínsecamenteespecificaciones de requerimientos, de diseño y reutilizables debido a que un sistema basado ende prueba, entre otros. componentes puede ser ensamblado con relativa En los últimos años, como resultado de facilidad por un integrador empleandopresiones crecientes sobre la industria del componentes suministrados por múltiples
  3. 3. 3proveedores independientes. Finalmente, la • autocontenido: es conveniente que uncoordinación e interacción entre componentes componente dependa lo menos posible deexige un marco regulatorio estandarizado (modelo otros componentes para cumplir su funciónde componentes) que establece la infraestructura de forma tal que pueda ser desarrollado,de software requerida (framework) y las probado, optimizado, utilizado, entendido yconvenciones 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é inmersocomponente de software puede ser visto desde en un proceso de mejoramiento continuo quedos perspectivas distintas, como: le garantice al integrador nuevas versiones1. 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 de2. 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 decomponentes típicamente asociadas con desarrollo: existen diversas plataformas deinfraestructuras 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 unescritorio (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 delos componentes es que son reutilizables. Para desarrollo, es natural que encontremosello los componentes deben satisfacer como componentes escritos empleando lenguajes ymí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 UNreutilizació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. 4. 4responsabilidades. 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 atributosimplementar el componente. Los lenguajes tales como tiempo de respuesta, uso deorientados 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 lasimplementaciones. En lenguajes procedimentales interfaces expresen mejor las propiedades(e.g. Pascal [22] y FORTRAN [23]) las interfaces extrafuncionales, tales como el lenguaje dese definen a través de declaraciones de funciones programación Eiffel [26] y el método formalo procedimientos y el uso de variables globales. Object-Z [27] para propiedades deAlgunos lenguajes neutrales de especificación de comportamiento, Object Calculus [28] parainterfaces 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 lasaplicaciones (API, Application Programming interfaces como una manera de especificar el flujoInterface) es una especificación, en un lenguaje unidireccional de dependencia que tiene unde programación, de las propiedades de un cliente con respecto a un componente. Sinmódulo de software. Los clientes del módulo sólo embargo, es mejor decir que un cliente y undeben depender exclusivamente de las componente dependen el uno del otro; un clientepropiedades definidas por el API de forma depende de la forma en que un componenteexplícita. provee sus servicios, y un componente depende Algunas tecnologías (e.g. Enterprise de cómo los clientes utilizan los servicios que ésteJavaBeans [11]) exigen que sus componentes ofrece. Esta interdependencia ha llevado a acuñarimplementen dos tipos de interfaces: el término Contrato de Interfaz [2], [8] en la1. 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 yconvencionales definen la firma de lasoperaciones (nombre de la operación, tipo y orden frameworks de componentes. Sin embargo, hayde los argumentos, y la manera como se consenso acerca de que los sistemas basados en componentes confían en estándares ydevuelven los resultados) que provee uncomponente. Las operaciones también se conocen convenciones bien definidas (modelo decomo Propiedades Funcionales. Sin embargo, componentes) y en una infraestructura de soporte (framework de componentes).estas interfaces no expresan adecuadamentepropiedades del componente relativas a, por Los modelos de componentes especifican lasejemplo, su desempeño, precisión, disponibilidad, reglas de diseño que deben obedecer los componentes. Estas reglas de diseño mejoran lalatencia, seguridad, entre otras. Dichaspropiedades se conocen como Propiedades composición, aseguran que las calidades deExtrafuncionales [24]. servicio se logren en todo el sistema, y que los componentes se puedan desplegar fácilmente Es útil diferenciar los tipos de propiedades delos 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 imponenrelacionadas 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érminos2. Comportamiento: definen las condiciones de las interfaces que implementa. Los tipos que deben cumplir los valores de entrada diferentes de componentes pueden
  5. 5. 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 soportany hacen cumplir el modelo componentes V. MECANISMOS DE COMPOSICIÓNasociado. El framework maneja recursos DE SOFTWAREcompartidos por los componentes, y proporciona Bajo el modelo de desarrollo de softwaremecanismos subyacentes que permiten la basado en componentes, las nuevas aplicacionescomunicación (interacción) entre ellos. Los se construyen mediante la integración oframeworks 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 “elciclo de vida (comenzar, suspender, reasumir, o proceso de construir aplicaciones mediante laterminar la ejecución de un componente), y otros interconexión de componentes de software arecursos. través de sus interfaces (de composición)". Nótese Existen muchos ejemplos de frameworks de que se hace especial énfasis en las interfacescomponentes, 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 unaespecificación de EJB define un framework de relación cliente-servidor entre dos componentesservidores y contenedores para dar soporte al (Figura 1). El componente cliente solicita unmodelo de componentes. Los Servidores EJB son servicio (operación) del componente servidor, elresponsables de proporcionar servicios de cual ejecuta la operación solicitada y devuelve lossistemas tales como persistencia, transacciones y resultados al cliente. El servidor produce unseguridad, mientras que los Contenedores EJB resultado que es consumido por el cliente.son responsables de manejar el ciclo de vida delcomponente. Por su parte, VBF es quizás el solicita un servicioframework más popular para el desarrollo deaplicaciones de escritorio. Se concentra en la C1 C2composición visual de componentes (llamados consume el servicioVBXs) más que en tener un entorno que garanticela calidad de servicio de éstos. VBF incluye al Figura 1. Interacción entreintérprete de VisualBasic (para ejecutar scripts y componentes.hacer composición) y el Modelo de Objetos deComponentes (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 acomunicación). composición. En consecuencia, existen tres clases
  6. 6. 6principales de interacción en los sistemas basados mecanismos necesarios para que ellos se integrenen componentes [24]: a fin de crear nuevas aplicaciones. Las preguntas1. 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, estos3. 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 enfoquecomponentes depende de los mecanismos maximiza la reutilización de componentes deespecificados por su modelo de programación. software existentes y reduce el número deTípicamente, los modelos de componentes se componentes que requieren ser desarrolladosbasan 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 condicionesalgunas características tales como relaciones entre mínimas: i) la existencia de repositorios oclases (especialización, agregación, asociación y bases de componentes reutilizables y ii) queuso) [10], polimorfismo y enlace dinámico [9]. los componentes sean confiables y actúen deAdicionalmente, dichos mecanismo de acuerdo a sus especificaciones.composición típicamente se describen mediante el El modelo de procesos descrito poruso 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 dedistribuidos, 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 doscaracterísticas orientadas a objetos dentro de sus grandes bloques paralelos, tal como se ilustra enmecanismos de composición. Por el contrario, en la Figura 2. El primer bloque, conocido comola composición de componentes distribuidos (e.g. Ingeniería de Dominios, contempla los procesosEnterprise JavaBeans [11], CORBA Component necesarios para desarrollar activos de softwareModel [12] y .NET [13]) principalmente se reutilizables en un dominio particular. El segundoemplean relaciones de uso, asociación y bloque es denominado Ingeniería deagregació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 caracterizaronlos componentes de software y se describieron los
  7. 7. 7 Ingeniería de Dominios Análisis del Diseño del Desarrollo de Dominio Dominio Componentes modelos diseños componentes Especificación de genéricos de requerimentos 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 desarrollode Aplicaciones es el modelo WATCH [34], [35]. de aplicaciones, indicando además cómo losEste modelo combina los procesos más relevantes procesos gerenciales controlan o coordinan elde la Ingeniería de Software Orientada a Objetos orden de ejecución de los procesos técnicos. Loscon el modelo de Ingeniería de Aplicaciones del procesos gerenciales están ubicados en el centrociclo de vida gemelo. Una característica de la estructura para indicar explícitamente queimportante de este modelo es la integración de los ellos programan, dirigen y controlan el proceso deprocesos gerenciales con los procesos técnicos del desarrollo. Los procesos técnicos están ubicadosdesarrollo de software basado en componentes. en el entorno siguiendo la forma que tiene el dialEsta integración facilita la labor del líder del de un reloj. Ello indica que el orden de ejecuciónproyecto, al describir cómo se debe llevar a cabo de las fases técnicas se realiza en el sentido de lasuna 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áforade 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 elsimilares a los modelos de procesos tradicionales. grupo de desarrollo adquiera un conocimiento
  8. 8. 8adecuado del dominio o contexto del sistema en Software Heterogéneos en Aplicacionesdesarrollo. Las fases de Descubrimiento, Análisis Espacio-Temporales” (G-97000824).y Especificación de Requerimientos se encargande identificar las necesidades y requerimientos de IX. REFERENCIASlos usuarios, así como analizarlos, especificarlosgrá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 withcada 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. Thesu 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. Businesscomponentes. Finalmente, la fase de Entrega se component factory : A comprehensiveencarga de la instalación, adiestramiento de overview of component-basedusuarios 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 componentisedsoftware 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-basedel proceso de desarrollo de software basado en la software engineering, 2nd edition.reutilización de componentes. Se estableció una Technical report, Software Engineeringcomparació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 ladeseables 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óncomponentes, así como también mecanismos de orientada a objetos. McGraw-Hillcomposición de software. Finalmente, se Interamericana, Diciembre 1998.discutieron algunos de los aspectos [11] Sun Microsystems, Inc. Enterprisemetodológicos que rigen el desarrollo de javabeans specification, version 2.0.componentes y de aplicaciones basadas en la http://java.sun.com/productreutilizació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, Juniosuministrado 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. 9. 9[13] T. L. Thai and H. Lam. .NET framework [27] R. Duke, G. Rose y G. Smith. Object-Z: essentials. OReilly & 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 (SCI2000),[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.

×