Desarrollo de Software Basado en Componentes

Cap tulo 1 Desarrollo de Software Basado en Componentes

c 2003, www.cotstrader.com

Un Modelo de Mediacin para el Desarrollo de Software basado en Componentes COTS o

CAP ITULO 1. DESARROLLO DE SOFTWARE BASADO EN COMPONENTES

1

Cap tulo 1

Desarrollo de Software Basado en Componentes

Contenidos1.1. Conceptos previos . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Ingenier de componentes software . . . . . . . . . . . . . . . . a 1.2.1. Denicin de componente . . . . . . . . . . . . . . . . . . . . . . . o 1.2.2. Ingenier del software basada en componentes (ISBC) . . . . . . . a 1.3. Especicacin de componentes software . . . . . . . . . . . . . . o 3 6 7 9 15

1.2.3. Etapas DSBC y tecnolog de componentes . . . . . . . . . . . . . 11 a 1.3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3.2. Comportamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.3. Protocolos (coreograf . . . . . . . . . . . . . . . . . . . . . . . . 18 a) 1.3.4. Informacin de calidad y extra-funcional (NFR) o . . . . . . . . . . 19 22 1.3.5. Contratos y credenciales . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4. Ingenier del software basada en componentes COTS . . . . . a 1.4.1. Componentes comerciales (COTS) . . . . . . . . . . . . . . . . . . 24 1.4.2. Limitaciones del desarrollo de software con componentes COTS . . 25 1.4.3. Caracter sticas de un componente comercial . . . . . . . . . . . . . 25 1.4.4. Sistemas basados en componentes COTS . . . . . . . . . . . . . . 27 1.5. Requisitos y componentes . . . . . . . . . . . . . . . . . . . . . . 30 1.5.1. Ingenier de requisitos tradicional . . . . . . . . . . . . . . . . . . 30 a 1.5.2. Prcticas de ingenier de requisitos . . . . . . . . . . . . . . . . . 32 a a 1.5.3. Ingenier de requisitos y componentes COTS . . . . . . . . . . . . 33 a 1.6. Arquitecturas de software . . . . . . . . . . . . . . . . . . . . . . 1.6.2. Vistas para una arquitectura de software 35 1.6.1. Caracter sticas de las arquitecturas de software . . . . . . . . . . . 35 . . . . . . . . . . . . . . 37 1.6.3. Lenguajes para la denicin de arquitecturas de software . . . . . 38 o 1.6.4. Componentes UML . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 1.6.5. UML-RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 1.7. El Servicio de mediacin . . . . . . . . . . . . . . . . . . . . . . . o 43

2

1.7.1. Roles de los objetos . . . . . . . . . . . . . . . . 1.7.2. Las interfaces del servicio de mediacin . . . . . o 1.7.3. Servicios y tipos de servicio . . . . . . . . . . . . 1.7.4. Oferta y consulta de servicios . . . . . . . . . . . 1.7.5. Un ejemplo . . . . . . . . . . . . . . . . . . . . . 1.7.6. Federacin de servicios de mediacin . . . . . . . o o 1.7.7. Limitaciones de la funcin de mediacin de ODP o o 1.8. UDDI: Directorio de servicios webs . . . . . . . 1.8.1. Servicios web y su tecnolog . . . . . . . . . . . a 1.8.2. El papel de UDDI en los servicios web . . . . . . 1.8.3. Modelo de informacin de UDDI . . . . . . . . . o 1.8.4. Las interfaces de UDDI y su comportamiento . . 1.8.5. Limitaciones de UDDI . . . . . . . . . . . . . . . 1.9. Resumen y conclusiones del cap tulo . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43 45 47 47 48 50 51 54 54 58 60 64 66 68



3

llo de software basado en componentes (DSBC)1 , es una aproximacin del desarrollo de o software que describe, construye y utiliza tcnicas software para la elaboracin de sistemas e o abiertos y distribuidos mediante el ensamblaje de partes software reutilizables. La aproximacin DSBC es utilizada para reducir los costes, tiempos y esfuerzos de desarrollo del softo ware, a la vez que ayuda a mejorar la abilidad, exibilidad y la reutilizacin de la aplicacin o o nal. Durante algunos aos, DSBC fue referida como una losof conocida como compre, n a y no construya promulgada por Fred Brooks en 1987 [Brooks, 1987] y que abogaba por la utilizacin de componentes prefabricados sin tener que desarrollarlos de nuevo. Hoy d o a, muchos autores que trabajan en el campo de DSBC, como [Heineman y Councill, 2001] o [Wallnau et al., 2002], entre otros, empiezan a reconocer y a aceptar el uso de estndares, a gu procesos y prcticas de ingenier sin los cuales el desarrollo de software basado en as, a a, componentes ser una mera mezcla entre competitivos y confusos lenguajes, metodolog a as y procesos. Estos estndares, gu procesos y prcticas han propiciado que se empiece a a as, a hablar del trmino de Ingenier del Software Basada en Componentes (ISBC)2 , como e a una subdisciplina de la Ingenier del Software. a En este cap tulo ofrecemos una visin global de aquellas reas de DSBC y ISBC que o a sustentan las bases de un mtodo para el desarrollo de sistemas de software basado en e un modelo de mediacin para componentes COTS para sistemas abiertos y distribuidos. o El presente cap tulo est organizado en nueve secciones, comenzando con una introduca cin histrica a los conceptos previos en entornos abiertos y distribuidos. Describiremos la o o situacin actual en el rea de la Ingenier de componentes software y veremos cmo se o a a o lleva a cabo la especicacin de un componente software. Tambin introduciremos algunas o e nociones de los componentes COTS y del rea de la ingenier de requisitos. Analizarea a mos conceptos relacionados con las arquitecturas de software y servicios de mediacin. o Finalizaremos con un breve resumen y algunas conclusiones de este cap tulo.

E l desarrollo de sistemas de software basado en componentes, o simplemente desarro-

1.1.

Conceptos previos

La disciplina de los sistemas distribuidos y abiertos empez a ser reconocida ampliamente o desde hace relativamente poco tiempo. En la dcada de los 90, los ingenieros encargados e de desarrollar y de mantener los grandes sistemas de informacin de la empresa, ven la o necesidad de escalar y ampliar sus sistemas para dar cobertura ya no solo al personal interno de una seccin, de un departamento o de una organizacin, si no tambin para dar servicio o o e a otros miembros de la organizacin ubicados en diferentes localizaciones geogrcas, y o a como no, a otros miembros externos a la organizacin. o El auge de los sistemas distribuidos coincide justo con la poca del boom de Intere net, y con ello, un cambio radical en las metodolog de desarrollo de los sistemas. En as pocos aos se pasa de una mentalidad centralizada, donde prevalec la condencialidad n a y sistemas basados en Intranet, a una mentalidad totalmente opuesta, descentralizada y basada en Internet. Evidentemente, todo esto se ve inuenciado por la ca progresiva da de los precios de los equipos hardware y materiales de comunicacin, lo cual, como hemos o dicho, permitir que en pocos aos surgiera una multitud de nueva tecnolog alrededor de a n a una unica idea: mantener sistemas descentralizados, distribuidos y abiertos, y generalmente 1 2

Sistemas centralizados frente a sistemas descentralizados

En la literatura se puede encontrar el trmino como CBD (Component-Based Development). e En la literatura se puede encontrar el trmino como CBSE (Component-Based Software Engineering). e


4

1.1. CONCEPTOS PREVIOS

En los aos 80, n el creciente aumento de los PCs, el uso de grandes computadoras y sistemas operativos Unix, y el fomento de la investigacin o paralela y concurrente, parecen ser la principal causa de descentralizacion de los sistemas

si no en su totalidad, s en una parte funcionando sobre Web. El paradigma de los sistemas distribuidos histricamente ha estado relacionado con el o paradigma de la programacin distribuida, como algoritmos distribuidos, modelos para o la implementacin abstracta de la memoria compartida distribuida, sistemas de archivos y o sistemas de gestin de bases de datos distribuidos, comunicacin y paso de mensajes entre o o procesos concurrentes, sincronizacin, seguridad, y tolerancia a fallos, entre otros factores o [Attiya y Welch, 1998] [Lynch, 1996]. Como hemos dicho, el explosivo crecimiento de Internet y la enorme variedad de informacin disponible por la red ha dado lugar a una nueva realidad, la convergencia de estas o dos disciplinas. La rpida evolucin de los sistemas de computadoras y de las tecnolog a o as de ultima generacin tiene que estar en constante sinton con las demandas reales de los o a profesionales de desarrollo de software, organizaciones y empresas. El proceso de desarrollo de sistemas informticos de empresa ha cambiado gradualmente a en pocos aos para pasar de un modelo centralizado y r n gido, hacia un modelo descentralizado, abierto y distribuido. El sistema informtico de una empresa a nivel de recursos a software, hardware y humanos sol estar localizado en un mismo espacio geogrco, en a a un departamento o una seccin de la empresa. Desde aqu el equipo de profesionales, que o , tradicionalmente estaba compuesto por las categor de analistas y programadores de sisas temas, elaboraba las aplicaciones del sistema de informacin haciendo uso de conocimientos o y prcticas tradicionales del proceso de ingenier del software. a a A mediados de los aos 80 empiezan a converger diversos factores en el mundo de la n informtica, y que ser el detonante de un cambio en el proceso de ingenier de los a an a sistemas informticos. Por un lado comienza la explosin de los PCs, que irrumpe con a o fuerza dentro de la empresa, bsicamente en los centros de clculo. Aunque la mayor parte a a de la lgica de negocio3 an resid en grandes estaciones de trabajo o en mainframes, o u a la masiva presencia de equipos de bajo coste (PCs, comparados con los grandes sistemas) permitir a los ingenieros desarrollar grandes aplicaciones desglosadas en mdulos software a o que pod estar ubicados en distintos ordenadores, propiciando un nuevo enfoque en el an desarrollo de los sistemas. Inicialmente, estos bloques software funcionaban como elementos de cmputo indepeno dientes dentro del sistema, pero pronto, los ingenieros vieron la necesidad de disponer de nuevas tcnicas para la comunicacin y transferencia de los datos entre estos elementos de e o cmputo. Precisamente por esta fecha, y ajeno a estas necesidades, empezaban a consolio darse fuertes l neas de investigacin en computacin paralela y programacin concurrente o o o [Agha et al., 1993] [Milner, 1989] motivadas, en un principio, por la masiva presencia de sistemas operativos tipo Unix en sistemas multiprocesador. Estas l neas de investigacin en programacin paralela y concurrente, junto con las o o necesidades de comunicacin de procesos en ambientes de cmputo independientes, dieron o o lugar a los primeros esfuerzos en la elaboracin de una nueva tecnolog para la prograo a macin distribuida de aplicaciones [Corbin, 1991] [Raynal, 1988]. Precisamente, uno de los o primeros resultados fue el desarrollo de la tcnica RPC (Remote Procedure Call), origen de e gran parte de la tecnolog de interconexin actual (conocida como tecnolog middleware). a o a Esta tcnica permite que los desarrolladores de software puedan disear sus aplicaciones e n mediante mdulos software comunicantes, como si fuesen un conjunto de procesos coopeo rativos independientes. Esta nueva tcnica empez a utilizarse de forma masiva en la empresa para el desarrollo e o de grandes sistemas de informacin. Pero esto provoc principalmente dos problemas. Por o o un lado, se empez a echar en falta un modelo distribuido estndar que sirviera de gu o a a3

Software cr tico, de clculo o muy ligado a los gestores de bases de datos. a



5

para los ingenieros en la elaboracin de sus aplicaciones distribuidas. Debido a la rpida o a utilizacin de la tcnica RPC, se empez a dar forma a todo un entorno de computacin o e o o distribuida sin la elaboracin de un marco terico que lo sustentase. o o Esto propici la aparicin del primer modelo de distribucin en 1994, conocido con el o o o nombre de DCE (Distributed Computation Environment, [OSF, 1994]). Este modelo fue desarrollado por OSF (Open Systems Foundation), una organizacin formada por IBM, o DEC y Hewlett-Packard. El modelo establec las pautas y normas que los ingenieros deb a an seguir para desarrollar sus sistemas. Entre otras caracter sticas [OSF, 1994], el modelo DCE destac por ser un modelo cliente/servidor basado en el lenguaje C y que inicialmente o funcionaba para plataformas Unix4 . Posteriormente el modelo se extendi para soportar o diversos sistemas operativos, como VMS, Windows y OS/2, entre otros. Por otro lado, esta nueva mentalidad de construir aplicaciones divididas en partes comunicantes y residentes en distintos ambientes de cmputo fue un gran paso en el campo o programacin distribuida. Evidentemente, las antiguas aplicaciones del sistema no dejaron o de funcionar, pero los ingenieros s vieron pronto la necesidad de integrar las partes exis tentes del sistema con las nuevas diseadas. n Esto dio paso a la aparicin de nuevos conceptos, como los sistemas heredados (legacy o systems), que hace referencia a la integracin de partes software existentes con las del o sistema actual. Otro concepto es el de envolvente (wrapper), que son porciones de cdigo o especialmente diseados para encapsular y dar funcionalidad a otras partes del sistema ya n existentes. O el concepto de cdigo de enlace (glue), que son porciones de cdigo cuyo o o efecto es similar al de un pegamento y que sirve para unir distintas partes funcionando con envolventes. Pero el concepto ms importante que ha cambiado y sigue cambiando los procesos a de ingenier y reingenier es el concepto de componente. Inicialmente este concepto a a, surge ante la necesidad de reutilizar partes o mdulos software existentes que pod ser o an utilizadas para la generacin de nuevas extensiones de las aplicaciones, o para la generacin o o de aplicaciones completas. Pero esto supon un gran esfuerzo, pues hab que localizar a a estas partes reutilizables y almacenarlas en repositorios especiales que ms tarde pudieran a ser consultadas en fase de diseo. n Con el trmino componente se empieza a diferenciar dos estilos de desarrollo de software. e Por un lado est el estilo de desarrollo de software basado en reutilizacin, donde las a o aplicaciones se construyen a partir de otras partes software ya existentes y accesibles en repositorios conocidos. Por otro lado est el desarrollo de software de reutilizacin, donde a o se ponen en prctica procesos de ingenier para la elaboracin de partes ecientes de a a o software que luego pueden ser utilizadas para la construccin de aplicaciones (en el otro o estilo de desarrollo de software). A estas partes software se las conoce como componentes software, y han dado lugar a los paradigmas de programacin de componentes top-down o o descendente (para reutilizar) y bottom-up o ascendente (basado en reutilizacin). o Pero el uso generalizado de los componentes en procesos de ingenier de software a realmente empieza a tomar presencia y sentido con la aparicin de nuevos modelos de o distribucin, como CORBA, DCOM o EJB, modelos que actualmente se estn utilizando o a para el desarrollo de aplicaciones distribuidas. Su predecesor, el modelo DCE, empieza a ser visto por los ingenieros de sistemas como un modelo dif y costoso de llevar a la cil prctica. a Por este motivo, Object Management Organization (OMG) empez a desarrollar un oLa terna cliente/servidor + Unix + C se puso muy de moda en esas fechas. La existencia de un modelo distribuido ya reconocido hizo que la demanda de profesionales con conocimientos en estas reas se a incrementase enormemente.4

La descentralizacion de los sistemas, y por consiguiente la distribucin de o las aplicaciones, hacen que aparezcan dos problemas principales. Por un lado la falta de un modelo distribuido, y por otro, la herencia de sistemas y aplicaciones existentes. Las soluciones a ello fueron el modelo distribuido DCE y la reingenier a de componentes software

Desarrollo ascendente vs. descendente

Modelos de objetos distribuidos


6

1.2. INGENIER DE COMPONENTES SOFTWARE IA

La revolucin o industrial

La utilizacin o de estndares a hace que los sistemas abiertos sean ms adaptables a a los avances tecnolgicos y a o los continuos cambios de mercado

modelo para la distribucin y localizacin dinmica de objetos en tiempo de ejecucin, el o o a o modelo CORBA (Common Object Request Broker Architecture). Por otro lado, Sun Microsystems (tecnolog Unix) y Microsoft (tecnolog Windows) elaboran sendos modelos, a a conocidos como EJB (Enterprise Java Beans) y DCOM (Distributed Component Object Model), respectivamente. Finalmente, OMG propone el nuevo modelo de componentes de CORBA llamado CCM (CORBA Component Model). Sin embargo, la presencia de distintos modelos de objetos distribuidos dentro de la empresa, cada vez ms inuenciada por intereses de la industria intereses de soluciones a Sun frente a intereses de soluciones Microsoft y la fuerte evolucin de nuevas tecnolog o as (XML, SOAP, Servlets, UDDI, entre otros), est haciendo que los ingenieros de sistemas a tengan que hacer grandes esfuerzos de ingenier para seleccionar aquellas tecnolog adea as cuadas para el desarrollo de sus sistemas. Incluso, en la mayor de los casos, los ingenieros a se ven obligados a utilizar e incorporar mltiples mtodos y tcnicas para dar soporte a u e e distintos clientes software y humanos del sistema. Por tanto, los grandes sistemas informticos y aplicaciones software de hoy d estn a a a basados en modelos cliente/servidor con arquitecturas multicapa y que hacen uso de una gran variedad de tecnolog La tendencia actual es que estos sistemas estn distribuias. e dos y localizados en distintos lugares geogrcos, comunicndose con modelos distribuidos a a CORBA, EJB y/o DCOM, haciendo uso de normas y tcnicas de seguridad importantes, e utilizando nuevas tcnicas como XML para la representacin intermedia de la informae o cin entre componentes software, o SOAP para la localizacin y activacin automtica de o o o a servicios web, entre otras muchas nuevas tecnolog as. Esto ultimo ha sido motivo para la consolidacin del concepto abierto, y que se reere o a una coleccin de componentes software y hardware y de usuarios que interactan entre s o u , diseados para satisfacer las necesidades establecidas, con especicaciones de componente n completamente denidas, fcilmente accesibles y mantenidas por consenso, y donde las ima plementaciones de componente respetan estas especicaciones [Meyers y Oberndorf, 2001]. La tendencia en los procesos de ingenier del software para el desarrollo de sistemas a abiertos y distribuidos, es elaborar sistemas colaborativos compuestos de subsistemas, componentes y objetos especializados y coordinados para ofrecer servicios. En este sentido, estn empezando a distinguirse distintas subdisciplinas de la ingenier del software a a conocidas como ingenier basadas o ingenier orientadas, como por ejemplo la inas as genier del software basada en aspectos (Aspect-Based Software Engineering, ABSE), la a ingenier del software orientada a objetos (Object-Oriented Software Engineering, OOSE), a la ingenier del software basada en conocimiento (Knowledge-Based Software Engineering, a KBSE), o la ingenier del software basada en componentes (Component-Based Software a Engineering, CBSE), entre otros. El rea de inters en la que se enmarca nuestro trabajo es precisamente en sta ultima a e e disciplina, la ingenier del software basada en componentes (ISBC). En la siguiente seccin a o trataremos algunos conceptos relacionados con ISBC.

1.2.

Ingenier de componentes software a

Como adelantamos en el Prlogo de esta memoria, los componentes software surgen en o cierta medida de la necesidad de hacer un uso correcto de software reutilizable para la construccin de aplicaciones software mediante el ensamblaje de partes ya existentes. De hecho, o etimolgicamente hablando, el trmino componente procede de la palabra cumponere, o e que en Lat signica cum junto y ponere poner. n Desde el punto de vista de la ingenier del software, el trmino componente proa e



7

cede de las tcnicas orientadas a objetos, de los problemas de descomposicin usados en e o tcnicas de descomposicin de problemas, y de su necesidad para desarrollar sistemas e o abiertos. Con la aparicin de los modelos de componentes COM, EJB y CCM, en pocos o aos ha ido emergiendo una prctica de desarrollo basada en componentes. Sin embarn a go, su expansin se ha visto ralentizada por la falta de acuerdo entre los especialistas, a o la hora de dar una denicin concreta sobre lo que es y no es un componente software o [Bachman et al., 2000].

1.2.1.

Denicin de componente o

En la literatura existe una gran diversidad de opiniones sobre lo que debe ser un componente software. Esto se pone de maniesto, por ejemplo, en el art culo What characterizes a (software) component? [Broy et al., 1998], donde se hace una variada recopilacin de o deniciones de componente y ofrece una discusin sobre lo que caracteriza a un compoo nente software. Uno de los factores que impide una denicin concreta del trmino se debe o e a la falta de un acuerdo comn sobre cuales son las caracter u sticas y propiedades que lo diferencian de un objeto [Henderson-Sellers et al., 1999]. En algunos casos, incluso, se llega a utilizar de forma indistinta los trminos componente y objeto. Algo similar sucede tame bin con el trmino agente software, donde los autores tampoco se ponen de acuerdo en e e una denicin concreta que los diferencie. o Una de las deniciones de componente software ms extendidas es la de Clemens Szypera ski, y que dice lo siguiente: Denicin 1.1 (Componente Szyperski, [Szyperski, 1998]) Un componente es una o unidad binaria de composicin de aplicaciones software, que posee un conjunto de interfaces o y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio. Segn Clemens Szyperski, las nociones de instanciacin, identidad y encapsuu o lacin son ms propias de los objetos que de los componentes, y dene un objeto como: o a Una unidad de instanciacin que tiene una unica identidad, un estado que puede ser o persistente, y que encapsula su estado y comportamiento. Sin embargo, un componente puede contener mltiples objetos, clases y otros componentes. u La nocin de componente puede variar dependiendo del nivel de detalle desde donde o se mire, conocido como granularidad de un componente. Un componente software puede ser desde una subrutina de una librer matemtica, hasta una clase en Java, un paquete a a en Ada, un objeto COM, un JavaBeans, o incluso una aplicacin que pueda ser usada por o otra aplicacin por medio de una interfaz especicada. Un componente con granularidad o gruesa se reere a que puede estar compuesto por un conjunto de componentes, o ser una aplicacin para construir otras aplicaciones o sistemas a gran escala, generalmente abiertos o y distribuidos. A medida que descendemos en el nivel de detalle, se dice que un componente es de grano no. Un ejemplo de componentes de grano grueso son los componentes Advanced Components de la arquitectura WSBC (WebSphere Business Components) de IBM. En WSBC se dene un componente de la siguiente manera: Denicin 1.2 (Componente IBM, [IBM-WebSphere, 2001]) Una implementacin o o que (a) realiza un conjunto de funciones relacionadas, (b) puede ser independientemente desarrollado, entregado e instalado, (c) tiene un conjunto de interfaces para los servicios proporcionados y otro para los servicios requeridos, (d) permite tener acceso a los datos y al comportamiento slo a travs de sus interfaces, (e) opcionalmente admite una conguo e racin controlada. o

Componente de Szyperski

Granularidad de componente

Componente WSBC de IBM


8


Otra denicin de componente es la que adopta el SEI (Software Engineering Institute), o y que dice lo siguiente:Componente SEI

Denicin 1.3 (Componente SEI, [Brown, 1999]) Un componente software es un o fragmento de un sistema software que puede ser ensamblado con otros fragmentos para formar piezas ms grandes o aplicaciones completas. a Esta denicin se basa en tres perspectivas de un componente: (a) la perspectiva de o empaquetamiento (packaging perspective) que considera un componente como una unidad de empaquetamiento, distribucin o de entrega. Algunos ejemplos de componente de esta o perspectiva son los archivos, documentos, directorios, librer de clases, ejecutables, o as archivos DLL, entre otros; (b) la perspectiva de servicio (service perspective) que considera un componente como un proveedor de servicios. Ejemplos son los servicios de bases de datos, las librer de funciones, o clases COM, entre otros; (c) la perspectiva de integridad as (integrity perspective) que considera un componente como un elemento encapsulado, como por ejemplo una base de datos, un sistema operativo, un control ActiveX, una applet de Java, o cualquier aplicacin en general. o En [Cheesman y Daniels, 2001] se identican diferentes visiones en las que puede aparecer el trmino componente en las etapas de desarrollo de un sistema software. Cone cretamente se identican hasta cinco formas de componente, mostrados en la gura 1.1. En primer lugar est la especicacin de componente, que representa la especicacin a o o de una unidad software que describe el comportamiento de un conjunto de objetos componente y dene una unidad de implementacin. El comportamiento se dene por un o conjunto de interfaces. Una especicacin de componente es realizada como una impleo mentacin de componente. o En segundo lugar est la interfaz de componente, que es una denicin de un conjunto a o de comportamientos (normalmente operaciones) que pueden ser ofrecidos por un objeto componente. En tercer lugar est la implementacin de componente, que es una realizacin de una a o o especicacin de componente que puede ser implantada, instalada y reemplazada de forma o independiente en uno o ms archivos y puede depender de otros componentes. a En cuarto lugar est el componente instalado, que es una copia instalada de una a implementacin de componente. o Y en quinto y ultimo lugar est el objeto componente, que es una instancia de un a componente instalado. Es un objeto con su propio estado e identidad unica y que lleva a cabo el comportamiento implementado. Un componente instalado puede tener mltiples u objetos componente o uno solo. Para nalizar est la visin de componente EDOC (Enterprise Distributed Object Coma o puting) [OMG, 2001] del OMG (Object Management Group). EDOC es una especicacin o para la computacin de objetos distribuidos que se ajusta al modelo de la arquiteco tura de objetos de OMG denominado OMA (Object Management Architecture, vase en e http://www.omg.org). La denicin de componente que se ofrece en este ambiente dice o simplemente lo siguiente: Denicin 1.4 (Componente EDOC, [OMG, 2001]) Un componente es algo que se o puede componer junto con otras partes para formar una composicin o ensamblaje. o

Componente UML

Componente EDOC de OMG

Componente Software

Como conclusin de estas deniciones podemos hacer las siguientes valoraciones. Los o componentes son partes software que se pueden combinar con otros componentes para generar un conjunto an mayor (p.e. otro componente, subsistema o sistema). Un compou nente juega el papel de una unidad software reutilizable que puede interoperar con otros



9

*

Especificacion de Componente

1

1..*

interfaces

*

realizacion

Interfaz de Componente

Implementacion de Componente1 * instalacion

Componente instalado1 *instancia

Objeto Componente

Figura 1.1: Formas en las que puede presentarse el trmino componente e mdulos software mediante sus interfaces. Un componente dene una o mas interfaces desde o donde se puede tener acceso a los servicios que ste ofrece a los dems componentes. e a Un componente puede presentarse en forma de cdigo fuente o cdigo objeto; puede o o estar escrito en un lenguaje funcional, procedural o en un lenguaje orientado a objetos; y puede ser tan simple como un botn GUI o tan complejo como un subsistema. o

1.2.2.

Ingenier del software basada en componentes (ISBC) a

Una prctica generalizada en un proyecto software es utilizar partes software ya desarrollaa das en proyectos previos o adquiridos por terceras partes. Esta cultura de reutilizacin es o esencial en casi todas las organizaciones que desarrollan software. Sin embargo, la mayor a de los desarrolladores de software suelen utilizar mtodos de desarrollo internos a la orgae nizacin que conducen, en la mayor de los casos, a aplicaciones mal construidas, retrasos o a en los plazos de nalizacin del proyecto, y un aumento en los costes nales del desarrollo. o Esto se debe a la falta de procesos y tcnicas bien denidas que gu a los desarrolladores e en de software durante la construccin de la aplicacin basada en reutilizacin. o o o El sueo de los especialistas en ingenier del software ha sido disponer de factor n a as de software donde partes software ya estandarizadas de una aplicacin puedan ser auo tomticamente seleccionadas desde un catlogo y ensambladas e implantadas fcilmente a a a como solucin a una necesidad de desarrollo de la organizacin. o o En cierta medida este desarrollo de software ideal se corresponde con la visin optio mista de [Wallnau et al., 2002], como muestra la gura 1.2. El desarrollo de un sistema software es visto como fases en la resolucin de un problema planteado, y que coinciden o con las tradicionales del ciclo de vida (anlisis, diseo e implementacin). Una visin opa n o o timista del desarrollo de un producto software supone la utilizacin de partes software o (componentes) bien especicadas, con interfaces descritas como contratos, con arquitecturas de software estndares para hacer el diseo abstracto de la aplicacin que hay que a n o construir, y con herramientas y entornos adecuados, aceptados y orientados a la composicin de las partes (componentes) implementadas y/o reutilizadas y extra o das previamente desde repositorios reconocidos por procesos de seleccin y bsqueda. o u Por otro lado, una visin pesimista del desarrollo quiz la mas realista supone o a que las partes software (componentes) ocultan muchas de sus propiedades, siendo dif su cil acceso a la informacin y al comportamiento interno (black box) en tareas de evaluacin; o o y en lugar de arquitecturas de software estndares se tienen particulares notaciones que a


10


permiten denir arquitecturas de partes software inestables y no probadas; nalmente, en lugar de tener entornos altamente cualicados que soporten la metfora composicional a para el desarrollo de sistemas y que utilicen mltiples lenguajes (C, C++, Java, Perl, entre u otros), se tienen herramientas y entornos de desarrollo especializados y particulares, por ejemplo un entorno de desarrollo Microsoft (.NET, DCOM, herramientas Visual, ASP, entre otros) y no Microsoft (CORBA, EJB, Servlets, entre otros).VistasPropiedades de componente inestables y ocultas Vista Pesimista ANALISIS Ensamblaje de componentes no probado DISEO Herramientas y entornos no integrados y heterogeneos IMPLEMENTACION

Interfaces de componente especificadas en contrato Vista Optimista ANALISIS

Arquitecturas de componentes estandares DISEO

Herramientas y entornos de composicion de componentes IMPLEMENTACION

Requisitos Problema

Modelos de solucion ESTABLECE EL PROBLEMA

Planes de fabricacion RESOLUCION DEL PROBLEMA

FORMACION DEL PROBLEMA

Evolucion del sistema (T)

Figura 1.2: Vistas en la evolucin del desarrollo de software o En los aos 80 se intent llevar a la prctica una idea similar a la que presenta la n o a visin optimista, recopilando y catalogando mdulos software de aplicaciones para su o o reutilizacin, conocidos generalmente como artefactos o mdulos software (assets). Sin o o embargo, la mayor de las iniciativas de reutilizacin no prosperaron por varias razones a o obvias: (a) la infraestructura tcnica que daba soporte a la reutilizacin estaba an inmadue o u ra; (b) la catalogacin de mdulos software era muy dif (c) los mdulos software fueron o o cil; o muy diversos y de calidad tambin muy variada; (d) las interfaces y el comportamiento e de los mdulos software fueron pobremente denidos; (e) y nalmente, la cultura de la o reutilizacin fue infravalorada e insucientemente apoyada por el mercado. o La conuencia de varios factores, como la madurez en los conceptos y tcnicas oriene tadas a objetos, la consolidacin del software de interconexin de componentes (mido o dleware) como CORBA, o el progresivo aumento de Internet, entre otros factores, hace que a nales de los aos 90 se empiece a hablar con fuerza del trmino componente softn e ware y del desarrollo basado en componentes software (Componet-Based Development). Algunos de los autores que han colaborado al impulso de este estilo de desarrollo han sido por ejemplo [Broy et al., 1998], [Cottman, 1998], [Garlan et al., 2000], [Kiely, 1998], [Krieger, 1998], [Meyer, 1999], o [Szyperski, 1998], entre otros. Incluso en estos ultimos aos hemos podido comprobar cmo se est haciendo un n o a uso continuo del trmino ingenier del software basada en componentes (Componente a Based Software Engineering, CBSE) como una subdisciplina de la ingenier del software a para construir sistemas distribuidos y abiertos con componentes software. Algunos autores que promueven el uso del trmino ISBC son por ejemplo [Brown y Wallnau, 1998], e [Heineman y Councill, 2001] o [Wallnau et al., 2002], entre otros autores. Estos creen que hoy d ya existen metodolog a as, tcnicas y herramientas basadas en componentes que e empiezan a estar lo sucientemente maduras como para poder empezar a hablar de una ingenier de componentes ISBC. a

Emerge ISBC



11

Algunas de estas metodolog utilizan componentes software para la construccin de as o 5 (Capability Maturity Model) del SEI (Software sistemas. Ejemplos de ellas son: CMM Engineering Institute) o RUP6 (Rational Unied Process) de Rational Software. En la tabla 1.1 resumimos algunas categor de inters en la ISBC7 . as eL neas de inters en ISBC e Procesos de desarrollo de componentes Ingenier de requisitos basada en componentes a Construccin de sistemas con componentes o Evaluacin de componentes o Composicin de componentes o Entornos y herramientas de desarrollo Mtricas software basadas en componentes e Reutilizacin de componentes o Diseo, prueba e implementacin de componentes n o Especicacin de componentes o Arquitecturas basadas en componentes Tecnolog y modelos de componentes as COTS (Commercial O-The-Shelf) Casos de estudios en ISBC

Tabla 1.1: Categor de inters dentro de ISBC as e

1.2.3.

Etapas DSBC y tecnolog de componentes a

Tradicionalmente los ingenieros del software han seguido un enfoque de desarrollo descendente (top-down) basado en el ciclo de vida en cascada (anlisis-diseo-implementacin) a n o para la construccin de sus sistemas, donde se establecen los requisitos y la arquitectura o de la aplicacin y luego se va desarrollando, diseando e implementando cada parte softo n ware hasta obtener la aplicacin completa implementada. En ISBC, la idea de construir o un sistema escribiendo cdigo ha sido sustituida por una idea basada en el ensamblaje e o integracin de componentes software ya existentes (desarrollo ascendente o bottom-up). o El proceso desarrollo de sistemas basados en componentes (DSBC) est compuesto por a diferentes etapas, aunque en la literatura podemos encontrar distintas categor y formas a as la hora de referirse a estas etapas. Por ejemplo en [Dean y Vigder, 1997] se identican cuatro procesos de desarrollo de sistemas basados en componentes, que son: (a) la bsqueda de u componentes software (residentes en repositorios) que pueden satisfacer las necesidades del usuario o de la arquitectura de software de la aplicacin; (b) la evaluacin de componentes o o segn algunos criterios; (c) la adaptacin o extensin de los componentes seleccionados u o o para que se ajusten a las necesidades de la arquitectura del sistema; y (d) el ensamblaje o la integracin de estos componentes. o Otra clasicacin de las etapas del desarrollo de los sistemas basados en componentes, o es la de RUP (Rational Unied Process) [Jacobson et al., 1999], un proceso de desarrollo adoptado por Rational (http://www.rational.com) y por los Componentes UML [Cheesman y Daniels, 2001] (vase seccin 1.6.4). En este caso el proceso se divide en seis e o etapas, que son: (a) fase de requisitos, donde se identican los requisitos de los componentes, de la arquitectura de software y del sistema en general; (b) fase de especicacin, donde se o 8 ; (c) fase de realiza la especicacin de los componentes y de la arquitectura de software o aprovisionamiento de componentes, donde se buscan y seleccionan componentes; (d) fase de ensamblaje de los componentes encontrados; (e) fase de pruebas; y (f) fase de implantacin o de la aplicacin del sistema. oCMM: http://www.cmu.sei.edu RUP: http://www.rational.com 7 Estas categor han sido obtenidas de Conferencias en ISBC, como el Component-Based Software as Engineering Track de las Conferencias del EUROMICRO. 8 En RUP el concepto de especicacin coincide con aspectos de diseo, y se utilizan diagramas de casos o n de uso, diagramas de clases y diagramas de colaboracin de UML. En la seccin 1.6.4 se tratar todo esto. o o a6 5

En el tiempo han sido numerosas las propuestas para el Desarrollo Basado en Componentes. El mtodo RUP e es uno de las ms conocidos, a y actualmente el mtodo e est siendo a usando como prctica en a Rational y en los Componentes UML


12


Por ultimo, tambin destacamos la clasicacin de [Brown, 1999]. En este caso el pro e o ceso de desarrollo est compuesto de cuatro etapas: (a) la seleccin de componentes; (b) la a o adaptacin de componentes; (c) el ensamblaje de los componentes al sistema; y (d) la o evolucin del sistema. o En la gura 1.3 hemos preparado un cuadro comparativo entre diferentes visiones del proceso de desarrollo de los sistemas basados en componentes. Dada su similitud con otras propuestas, hemos tomado como referencia la visin de clasicacin de [Brown, 1999] como o o la ms extendida en el proceso de desarrollo de los sistemas basados en componentes. En a la parte superior de la gura hemos incluido la visin del ciclo de vida clsico. Tambin o a e hemos incluido la visin RUP (por su relacin con los Componentes UML que veremos ms o o a adelante) y una visin del proceso de desarrollo de sistemas basados en componentes coo merciales; para este caso hemos seleccionado la que se ofrece en [Meyers y Oberndorf, 2001] por ser una de las ms extendidas en el campo de los componentes comerciales. Estas etaa pas sern descritas en la seccin 1.4.4 (pgina 27), cuando tratemos los sistemas basados a o a en componentes COTS.Ciclo de vida tradicional CBD [Brown, 1999] RUP [Jacobson, 1999] COTS [Meyers and Oberndorf, 2001]

Analisis Seleccion de componentes Especificacion

Diseo

Implementacion Ensamblaje Ensamblaje Diseo y Codificacion

Mantenimiento Evolucion

Adaptacion Aprovisionamiento

Requisitos

Prueba Prueba

Implantacion

Evaluacion de componentes (Adquisicion) Busqueda y Seleccion Evaluacion

Deteccion Actualizacion Gestion componentes de config. de fallos

Figura 1.3: Comparacin entre diferentes procesos de desarrollo basados en componentes o Como vemos, aunque no existe un consenso generalizado en las etapas del proceso de desarrollo de un sistema basado en componentes software, s que podemos observar que algunas de ellas coinciden (aunque con distinto nombre) o estn englobadas en dos o ms a a etapas. Esto ultimo sucede por ejemplo con la etapa de Seleccin de componentes de o CBD, que cubre las etapas de Requisitos, Anlisis y parte de la etapa de Aprovisiona amiento del proceso RUP. En otros casos el trmino conlleva las mismas tareas pero con e distinto nombre. Por ejemplo, la etapa de Evaluacin en el proceso COTS es similar al o trmino Adaptacin en CBD, y parecido al Aprovisionamiento en RUP, aunque como e o vemos, ste ultimo requiere una parte de seleccin en los otros procesos. e o 1.2.3.1. Seleccin de componentes o

La seleccin de componentes es un proceso que determina qu componentes ya desarroo e llados pueden ser utilizados. Existen dos fases en la seleccin de componentes: la fase de o bsqueda y la fase de evaluacin. En la fase de bsqueda se identican las propiedades de u o u un componente, como por ejemplo, la funcionalidad del componente (qu servicios propore ciona) y otros aspectos relativos a la interfaz de un componente (como el uso de estndares), a 9 y aspectos no tcnicos, como la cuota de aspectos de calidad que son dif ciles de aislar e mercado de un vendedor o el grado de madurez del componente dentro de la organizacin. o Sin embargo, la fase de bsqueda es un proceso tedioso, donde hay mucha informacin u o dif de cuanticar, y en algunos casos, dif de obtener. cil cil Por otro lado, para la fase de evaluacin, existen tcnicas relativamente maduras para o e efectuar el proceso de seleccin. Por ejemplo ISO (International Standards Organization) o describe criterios generales para la evaluacin de productos [ISO/IEC-9126, 1991]. En o9

Como la abilidad, la predicibilidad, la utilidad, o la certicacin [Voas, 1998], entre otros. o



13

[IEEE, 1993] y en [Poston y Sexton, 1992] se denen tcnicas que tienen en cuenta las e necesidades de los dominios de aplicacin. Estas evaluaciones se basan en el estudio de o los componentes a partir de informes, discusin con otros usuarios que han utilizado estos o componentes, y el prototipado. 1.2.3.2. Adaptacin de componentes o

Siguiendo con las cuatro actividades del ISBC, en segundo lugar est la actividad de a adaptacin de componentes. Para este caso, debido a que los componentes son creao dos para recoger diferentes necesidades basadas en el contexto donde se crearon, estos tienen que ser adaptados cuando se usan en un nuevo sistema. En funcin del grado de aco cesibilidad a la estructura interna de un componente, podemos encontrar diferentes aproximaciones de adaptacin [Valetto y Kaiser, 1995]: o (a) de caja blanca (white box), donde se permite el acceso al cdigo fuente de un compoo nente para que sea reescrito y pueda operar con otros componentes; (b) de caja gris (grey box), donde el cdigo fuente del componente no se puede modicar, o pero proporciona su propio lenguaje de extensin o API; o (c) de caja negra (black box), donde el componente slo est disponible en modo ejeo a cutable (binario) y no se proporciona ninguna extensin de lenguaje o API desde o donde se pueda extender la funcionalidad. 1.2.3.3. Ensamblaje de componentes

En tercer lugar, para ensamblar10 los componentes en el sistema existe una infraestructura bien denida (conocida como middleware), la cual puede estar basada en diferentes estilos. Los ms conocidos son el bus de mensajes MOM (Message-Oriented Middleware) a y la tecnolog ORB (Object Request Broker). a Message-Oriented Middleware (MOM) La tecnolog MOM es una infraestructura cliente/servidor que mejora la interoperabilidad, a portabilidad y exibilidad de los componentes de una aplicacin permitiendo que esta sea o distribuida en mltiples plataformas heterogneas. Es tambin conocida como tecnolog u e e a Queuing de encolado de mensajes, incorporado por ejemplo en el modelo de objetos COM+ de Windows 2000 y Windows NT, y en el ultimo modelo .NET para Windows NT y XP. La tecnolog MOM es una tecnolog as a a ncrona que reduce la complejidad de desarrollo al ocultar al desarrollador detalles del sistema operativo y de las interfaces de red. MOM est basada en el uso de colas de mensajes que ofrecen almacenamiento temporal cuando a el componente destino est ocupado o no est conectado. a a

Componente Cola de entrada Cola de salida

Figura 1.4: Cola de mensajes de un objeto basado en MOM10 En la literatura, en ocasiones podemos encontrar el trmino Ensamblaje referido como fase de Ine tegracin de componentes software. o


14


Como ilustra la gura 1.4, un objeto basado en MOM puede hacer uso de dos colas: una de entrada, donde se almacenan los mensajes que recibe de otros; y otra de salida, donde se almacenan los mensajes hacia otros. La tecnolog MOM es apropiada para aplicaciones basadas en eventos (como las que a propugna ahora Microsoft). Cuando un evento tiene lugar, la aplicacin cliente delega a la o aplicacin intermedia (la aplicacin con servicio MOM) la responsabilidad de noticar al o o servidor que se tiene que llevar a cabo alguna accin dentro del sistema. o Object Request Broker (ORB) Un ORB (Object Request Broker) es una tecnolog de interconexin (conocido como mida o dleware) que controla la comunicacin y el intercambio de datos entre objetos. Los ORBs o mejoran la interoperabilidad de los objetos distribuidos ya que permiten a los usuarios construir sistemas a partir de componentes de diferentes vendedores. Los detalles de implementacin del ORB generalmente no son de importancia para los o desarrolladores. Estos slo deben conocer los detalles de las interfaces de los objetos, oculo tando de esta forma ciertos detalles de la comunicacin entre componentes. Las operaciones o que debe permitir por tanto un ORB son bsicamente tres: (a) la denicin de interfaces, a o (b) la localizacin y activacin de servicios remotos, y (c) la comunicacin entre clientes y o o o servicios. La denicin de interfaces se lleva a cabo mediante el uso de un lenguaje de denicin o o de interfaces (IDL). Debe proporcionar al desarrollador un programa desde donde poder denir las interfaces de los componentes. Tambin es necesario un programa que compile la e interfaz y genere cdigo ORB (desde C, Java, Tcl, y otros, dependiendo de la versin ORB) o o para posteriormente implementar la funcionalidad del servicio que se est construyendo. e En la gura 1.5 se puede ver la utilidad de un programa ORB. Antes de funcionar la aplicacin cliente, un programa ORB debe estar en ejecucin, accesible desde el programa o o cliente. El cliente delega al programa ORB la tarea de localizar el servicio remoto (1). La ubicacin es desconocida por el cliente. Una vez localizado, el ORB se encarga de activar el o servicio remoto en su ubicacin correspondiente (2). El proceso de activacin del servicio o o genera una especie de cdigo unico interno de identicacin de dicho servicio. Finalmente el o o ORB pasa este cdigo al programa cliente (3) que lo utiliza para conectarse punto-a-punto o con el servicio remoto requerido (4).

Figura 1.5: Funcionamiento bsico de un ORB a Como muestra la tabla 1.2, existen bsicamente tres tecnolog ORB ampliamente a as utilizadas, como son CORBA, COM y EJB. El hecho de utilizar un tipo de modelo u otro para ensamblar componentes, puede depender de mltiples factores; por ejemplo, por las u necesidades actuales de los requisitos del sistema, o por las preferencias profesionales de los ingenieros, o por restricciones econmicas, entre otros factores. o



15

ORB CORBA

Descripcin o Common Object Request Broker Architecture del OMG (Object Managament Group), que la engloba en el modelo distribuido CCM (CORBA Component Model). Est basado en el protocolo para objetos distribuidos IIOP (Internet a Inter-ORB Protocol).

COM/DCOM/COM+ Es el modelo de componentes de Microsoft (Component Object Model), que la engloba dentro de su modelo distribuido .NET, basado en lenguaje C#. Est basado a en el protocolo para objetos distribuidos ORPC (Object Remote Procedure Call). Java/RMI RMI (Remote Method Invocation) es una parte de JVM de Sun, que la engloba dentro de su modelo distribuido EJB (Enterprise JavaBeans). Est basado en a el protocolo para objetos distribuidos JRMP (Java Remote Method Protocol).

Tabla 1.2: Tecnolog ORB para el ensamblaje de componentes aORB Plataforma COM/DCOM Plataforma PC bsicamente; a aunque existen variaciones para otras plataformas Arquitecturas de sistemas distribuidos basados en PC APIs y DLLs Una. Microsoft mantiene la unica implementacin o para PC, aunque trabaja con otros vendedores para otras plataformas CORBA Plataformas independientes y plataformas que permiten interoperabilidad Arquitecturas de sistemas distribuidos en general Especicacin de tecnolog o a de objetos distribuidos Muchas: Orbix (IONA) Neo (Sun) VisiBroker (Visigenic) DSOM (IBM), etc. RMI Toda aquella que ejecute Java Virtual Machine (JVM) Arquitecturas de sistemas distribuidos en general y en Internet basado en Web Implementacin de tecnolog o a de objetos distribuidos Varias

Aplicable

Mecanismo Implementaciones

Tabla 1.3: Comparacin de los ORBs DCOM-CORBA-RMI o 1.2.3.4. Evolucin del sistema o

Los sistemas basados en componentes deber ser fcilmente evolucionables y actualizaan a bles. Cuando un componente falla (por cualquier motivo) ste debe poder cambiarse por e otro equivalente y con las mismas prestaciones. De igual forma, si un componente del sistema debe ser modicado, para que incluya nuevas funcionalidades o elimine algunas de ellas, esto se puede hacer sobre un nuevo componente que luego ser cambiado por el que a hay que modicar. Sin embargo, este punto de vista es poco realista. La sustitucin de un o componente por otro suele ser una tarea tediosa y que consume mucho tiempo, ya que el nuevo componente nunca ser idntico al componente sustituido, y antes de ser incorporado a e en el sistema, ste debe ser perfectamente analizado de forma aislada y de forma conjunta e con el resto de los componentes con los que debe ensamblar dentro del sistema.

1.3.

Especicacin de componentes software o

Como adelantamos, DSBC es un paradigma para desarrollar software, donde todos los artefactos (desde el cdigo ejecutable hasta los modelos de especicacin de interfaces, o o arquitecturas y modelos de negocio) pueden ser construidos mediante el ensamblaje, la adaptacin y la instalacin de todos ellos juntos y en una variedad de conguraciones. Sin o o embargo, esto no ser posible sin un comportamiento claro y completamente especicado a de los componentes.


16

1.3. ESPECIFICACION DE COMPONENTES SOFTWARE

Un componente software requiere de informacin de especicacin para los usuarios y los o o implementadores del mdulo. En el contexto de reutilizacin del software, la especicacin o o o ayuda a determinar si un mdulo puede satisfacer las necesidades de un nuevo sistema. En o el contexto de interoperacin del mdulo, la especicacin se utiliza para determinar si dos o o o mdulos pueden interoperar. o Por lo tanto, podemos decir que un componente software C puede quedar caracterizado de la siguiente forma [Han, 1998]:C = (Atr + Oper + Even) + Comp + (Prot Esc) + Prop

Segn esto, los atributos (Atr ), las operaciones o mtodos (Oper ) y los eventos (Even) u e son parte de la interfaz de un componente, y representa su nivel sintctico. El compora tamiento (Comp) de estos operadores representa la parte semntica del componente. Otros a autores se reeren a estos niveles como nivel esttico y nivel dinmico [Konstantas, 1995], a a o como componentes plug y play [Bastide y Sy, 2000]. Los protocolos (Prot) determinan la interoperabilidad del componente con otros, es decir, la compatibilidad de las secuencias de los mensajes con otros componentes y el tipo de comportamiento que va a tener el componente en distintos escenarios (Esc) donde puede ejecutarse. Finalmente, el trmino Prop se reere a las propiedades extra-funcionales que e puede tener el componente (como propiedades de seguridad, abilidad o rendimiento, entre otras). Veamos a continuacin algunos detalles de estas partes o aspectos que caracterizan o a un componente software.

1.3.1.

Interfaces

Un componente software puede quedar identicado por medio de una o ms interfaces. a Tradicionalmente a las interfaces se las conoc con el nombre de API (Application Proan gramming Interface). Una interfaz es: una abstraccin de un servicio, que dene las opeo raciones proporcionadas por dicho servicio, pero no sus implementaciones. En trminos e de objetos, una interfaz puede contener tambin un conjunto de atributos, adems de e a las operaciones proporcionadas. Por ejemplo, en la gura 1.6 se muestra un estereotipo de interfaz en notacin UML para un buer con un atributo y dos operaciones. o Buffer #name:StringAtributos

+read() : long +write(x) : void

Signaturas de las operaciones

Figura 1.6: Elementos de una interfaz en notacin UML o Los atributos son uno de los aspectos relevantes de una interfaz ya que son los elementos que forman parte de la vista externa del componente (los representados como pblicos). u Estos elementos observables son particularmente importantes desde el punto de vista del control y del uso del componente, y son la base para el resto de los aspectos que caracterizan a un componente. En general, una interfaz puede presentarse de distintas maneras, dependiendo del nivel de detalle que se quiera describir o de la perspectiva desde donde se mire. Por ejemplo, en CORBA las interfaces de los objetos siguen un enfoque orientado a objetos, formadas por



17

el conjunto de las variables y mtodos del objeto accesibles de forma pblica. En COM e u los objetos pueden tener ms de una interfaz, cada una de ellas con las signaturas de las a operaciones que admite el componente. Esto sucede tambin en el nuevo modelo de compoe nentes de CORBA (CCM [OMG, 1999]), en donde adems, se contemplan las operaciones a que los objetos necesitan de otros, y los eventos que emite y recibe el componente. De esta forma, en los actuales modelos de componentes las interfaces estn formadas a por el conjunto de las signaturas de las operaciones entrantes y salientes de un componente. Las primeras determinan las operaciones que un componente implementa, mientras que las salientes son las que precisa utilizar de otros componentes durante su ejecucin. o Una interfaz contiene slo informacin sintctica de las signaturas de las operaciones o o a entrantes y salientes de un componente, con las cuales otros componentes interactan con u l. A este tipo de interaccin se le conoce con el nombre de control proactivo las e o operaciones de un componente son activadas mediante las llamadas de otro. Como ejemplo, en la tabla 1.4 mostramos las interfaces de un componente buer de una sola celda denidas utilizando el IDL de CORBA. El componente se corresponde con el comportamiento de un buer con dos operaciones usuales: write() y read(). Estas dos operaciones se muestran en la columna de la izquierda como una interfaz ofrecida por el componente. El buer tambin hace uso de otro componente que imprime los valores de e su celda utilizando la operacin print() cada vez que un nuevo valor es escrito (columna o de la derecha).Interfaz ofertada interface OnePlaceBuffer { void write(in long x); long read(); }; Interfaz requerida interface out { oneway void print(in long x); };

Tabla 1.4: Interfaces ofrecidas y requeridas por un componente buer de una sola celda Adems del control proactivo en general la forma en la que se llama a una operacin a o existe otra forma que se denomina control reactivo y que se reere a los eventos de un componente, como el que permite por ejemplo el modelo de componentes EJB (Enterprise JavaBeans). En el control reactivo, un componente puede generar eventos que se corresponden con una peticin de llamada a operaciones; ms tarde otros componentes del o a sistema recogen estas peticiones y se activa la llamada a la operacin. Un s o mil de este funcionamiento ser por ejemplo cuando un icono de escritorio cambia de forma al pasar a por encima el cursor del ratn. En este caso, el componente icono est emitiendo un evento o a asociado a una operacin que cambia la forma del icono. o

1.3.2.

Comportamiento

Sin embargo, no todas las secuencias de invocacin de operaciones estn permitidas. Exiso a ten restricciones operacionales que especican los patrones de operacin permisibles. Este o aspecto es similar por ejemplo al que captura el diagrama de transiciones de un objeto. Por tanto, a la hora de construir aplicaciones no basta con tener especicaciones de componente que contengan slo el nombre las signaturas y de los atributos del componente o [Yellin y Strom, 1997] [Zaremski y Wing, 1997]. Cuando desarrollamos software, tambin e es necesario incluir especicacin semntica de las interfaces, para el signicado de las o a operaciones y la especicacin de su comportamiento [Vallecillo et al., 1999]. o


18


La informacin a nivel semntico se puede describir con formalismos como las pre/post o a condiciones, como por ejemplo Larch [Dhara y Leavens, 1996] [Zaremski y Wing, 1997], JML (Java Modeling Language o JavaLarch, ftp://ftp.cs.iastate.edu/pub/leavens/ JML) [Leavens et al., 1999] y OCL (Object Constraints Language) [Warmer y Kleppe, 1998]. Lenguajes de programacin como Eiel [Meyer, 1992] y SPARK [Barnes, 1997] permiten o escribir especicaciones de comportamiento utilizando pre/post condiciones dentro del cdigo. Otros formalismos para la especicacin semntica son las ecuaciones algebraicas o o a [Goguen et al., 1996], el clculo de renamiento [Mikhajlova, 1999], y otras extensiones a de mtodos formales orientados a objetos tradicionales que estn siendo usados para la e a especicacin de componentes software, como OOZE [Alencar y Goguen, 1992], VDM++ o [Drr y Plat, 1994] y Object-Z [Duke et al., 1995]. u A modo de ejemplo, en la gura 1.7 mostramos una descripcin pre/post, en JML o (JavaLarch), del comportamiento de las operaciones del componente buer (visto anteriormente), ofrecidas dentro de la interfaz OnePlaceBuffer. Como vemos, esta denicin o combina cdigo Java, para la descripcin de la interfaz (l o o neas 3, 12, 20 y 21), y notacin o JML, expresada entre comentarios (// o /* */) y comenzando cada l nea JML por el s mbolo @. Como vemos en la tabla, la descripcin JML se coloca por encima de la descripo cin abstracta de cada operacin. o o1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: //@ model import edu.iastate.cs.jml.models.*; public interface OnePlaceBuffer { /*@ public model JMLValueSequence unBuffer; (* un OnePlaceBuffer *) @ initially unBuffer != null && unBuffer.isEmpty(); @*/ /*@ public normal behavior @ requires unBuffer.isEmpty(); @ ensures unBuffer@post == unBuffer.insertBack((JMLInteger) x); @*/ public void write(JMLInteger x); /*@ public normal behavior @ requires !unBuffer.isEmpty(); @ ensures result == ((JMLInteger) unBuffer.first()) && @ unBuffer@post == unBuffer.removePrefix(1) && @ [email protected](); @*/ public JMLInteger read(); };

Figura 1.7: Comportamiento en JavaLarch de un buer de una sola celda

1.3.3.

Protocolos (coreograf a)

Adems de la informacin sintctica para las interfaces del componente y de la informaa o a cin semntica para el comportamiento de las operaciones de las interfaces, se ha visto o a que tambin es necesaria otro tipo de informacin semntica que concierne al orden en e o a el que deben ser llamadas las operaciones de las interfaces de un componente. A esta informacin semntica se la conoce con el nombre de protocolos de interaccin (tambin o a o e llamada coreograf a). Los protocolos de interaccin pueden variar dependiendo del tipo o



19

de componente con el que interacciona y tambin del escenario donde se lleva a cabo la e interaccin. En este caso, a las interfaces se las denominan roles. Por tanto, un compoo nente puede ser usado en diferentes escenarios, donde sus interfaces pueden jugar un papel diferente en cada uno de ellos. As pues, desde el punto de vista del componente, se podr a hablar de diferentes protocolos de interaccin en funcin del escenario donde pueda ser o o utilizado [Han, 1998]. Para especicar informacin de protocolos existen diferentes propuestas dependiendo o del formalismo como redes de Petri [Bastide et al., 1999], mquinas de estados nitas a [Yellin y Strom, 1997], lgica temporal [Han, 1999] [Lea y Marlowe, 1995] o el -clcuo a lo [Canal et al., 2001] [Canal et al., 2003] [Henderson, 1997] [Lumpe et al., 1997]. Existen otros lenguajes para la sincronizacin de componentes (otra forma de referirse a los protoo colos), como Object Calculus [Lano et al., 1997], Piccola [Acherman et al., 1999] o ASDL (Architectural Style Description Language) [Riemenschneider y Stavridou, 1999]. A modo de ejemplo, en la gura 1.8 mostramos una descripcin de un protocolo para o el caso del componente buer de una sola celda, visto en la seccin anterior. Para la o descripcin se ha utilizado la notacin de -clculo. o o aOnePlaceBuffer(ref,out) = ref?write(x,rep).out!print(x).rep!().Full(ref,out,x); Full(ref,out,x) = ref?read(rep).rep!(x).OnePlaceBuffer(ref,out);

Figura 1.8: Protocolo en pi-calculus de un buer de una sola celda

1.3.4.

Informacin de calidad y extra-funcional (NFR) o

Otro aspecto importante es la informacin de calidad de un componente, recogido en la o literatura como atributos de calidad. Un atributo de calidad se reere tanto a informacin o de calidad de servicio11 p.e., el tiempo mximo de respuesta, la respuesta media y la a precisin como a atributos relacionados con la funcionalidad y la extra-funcionalidad o de un componente, como por ejemplo la interoperabilidad y la seguridad para el caso de los atributos funcionales, o la portabilidad y la eciencia para el caso de los atributos extra-funcionales, entre otros muchos [ISO/IEC-9126, 1991]; aunque la mayor parte de los atributos de calidad estn relacionados con la informacin extra-funcional. a o La informacin extra-funcional se puede clasicar de muy diversas formas. Por ejemplo, o en [Franch, 1998] se utiliza una notacin NoFun que clasica la informacin extra-funcional o o en tres categor (a) atributos extra-funcionales o propiedades (NF-attributes); (b) comas: portamiento extra-funcional de una implementacin de componente (NF-behavior); y (c) reo quisitos extra-funcionales de un componente software (NF-requirements). La informacin extra-funcional tambin viene recogida con otros trminos en la liteo e e ratura tradicional, como informacin extra-funcional, restricciones extra-funcionales NFR o (Non-Functional Restrictions), o ilities [Bass et al., 1998, Thompson, 1998]. Para este ulti mo caso, el trmino ilities hace referencia a todas aquellas propiedades extra-funcionales, e originarios del ingls, y que generalmente terminan por ility, como por ejemplo: reliae bility, portability, usability, o predictability; sin embargo hay otros que no terminan as y que tambin son de la misma categor extra-funcional, por ejemplo: safety o , e a maturity, entre otros. En la literatura existen dos referencias clsicas en el concepto de a11

QoS, Quality of Service


20


Planicacin o Robustez - Integridad conceptual - Completitud - Coherencia Permisibilidad - Precio de compra - Coste de mantenimiento - Coste de integracin o

Diseo n Portabilidad Reutilidad Comprobable Extensibilidad Congurable Escalabilidad Interoperabilidad

Ejecucin o Prestaciones - Ancho de banda - Tiempo de respuesta - Recursos que consume Fiabilidad - Disponibilidad - Vulnerabilidad - Seguridad - Tolerancia a fallos Utilidad

Tabla 1.5: Atributos extra-funcionales en las etapas de desarrollo [Bass et al., 1998] ilities: [Azuma, 2001] y [Chung et al., 1999]. El primero es un estndar ISO 9126, y el a segundo recoge y clasica ms de 100 ilities. a La tabla 1.5 muestra algunas propiedades extra-funcionales que pueden ser tratadas en distintas fases del ciclo de vida en la construccin de un sistema [Bass et al., 1998]. Por sus o caracter sticas, la informacin extra-funcional puede hacer que su especicacin sea dif o o cil de llevar a cabo [Chung et al., 1999], por ejemplo: (1) La informacin extra-funcional puede o ser subjetiva, ya que sta puede ser interpretada y evaluada por diferentes personas e (analistas, diseadores, programadores); (2) La informacin extra-funcional puede ser ren o lativa, ya que su importancia y su descripcin puede variar dependiendo del dominio de o aplicacin (planicacin, diseo, ejecucin); (3) La informacin extra-funcional puede ser o o n o o derivada, en el sentido de que pueden aparecer nuevas propiedades funcionales a partir de una determinada, como por ejemplo para la propiedad Prestaciones o la propiedad Fiabilidad (vase tabla 1.5). e Pero adems de sus caracter a sticas, algunas tareas como la elicitacin, anlisis y evao a luacion de la informacin extra-funcional se ven dicultadas por la conveniencia de una o notacin adecuada para recoger esta clase de informacin en los componentes software, o o como se pone de maniesto en [Franch, 1997]. En la seccin 1.5.3 veremos algunos trabajos o relacionados con informacin extra-funcional de los componentes COTS. o

1.3.5.

Contratos y credenciales

Los contratos y las credenciales son otra forma de referirse a la informacin funcional o (concretamente la semntica) y a la informacin extra-funcional de la especicacin de un a o o componente software, como vimos anteriormente en la seccin 1.3.1. o Los contratos son una forma de garantizar que las partes software de un sistema, desarrolladas por diferentes personas y posiblemente de diferentes organizaciones, puedan funcionar correctamente de forma conjunta. Si consideramos un componente como una pieza software que proporciona y requiere unos servicios para su funcionamiento, tambin podr e amos considerar una relacin similar o entre las compa que desarrollan software y los componentes. En este sentido, las comnas pa se ver como entidades que proporcionan servicios (componentes) a sus clientes nas an (que pueden ser otras compa organizaciones o clientes independientes) y que tambin nas, e pueden depender de los servicios de otras compa De igual forma que en la vida real los nas. contratos sirven para cerrar acuerdos alcanzados entre dos o ms partes (compa ora nas, ganizaciones, personas), stos (los contratos) tambin pueden ser utilizados como acuerdos e e formales de especicacin entre partes software. o



21

Los contratos son una metfora cuyo signicado es muy util en el rea del desarrollo de a a software basado en componentes (DSBC) [Bachman et al., 2000]. Por ejemplo: (a) En la vida real los contratos tienen lugar entre dos o ms partes; (b) estas partes normalmente a negocian los detalles del acuerdo antes de rmar un contrato; (c) adems los contratos a estn sujetos a normativas y convenios de comportamiento sobre todos los rmantes; (d) y a que una vez rmadas, las condiciones del contrato no pueden ser modicadas, a no ser que los cambios puedan ser renegociados por todas partes rmantes del actual contrato. Esta visin realista del trmino contrato aparece de diferentes formas en DSBC. Por o e ejemplo, la perspectiva (a) inspira un caso de contrato que se da en coordinacin de como ponentes, como en la composicin de componentes. En este caso, mltiples componentes se o u ponen de acuerdo (contractualmente) para implementar un n comn, como por ejemplo, u un componente ms simple, o un subsistema. La perspectiva (b) inspira un caso de contraa to que se da en colaboracin entre componentes. En este caso los contratos son utilizados o como acuerdos para negociar las condiciones de interaccin entre mltiples componentes o u que colaboran para conseguir un bien particular, en lugar de uno comn (como en el caso u anterior). Ejemplo de estos ultimos son los agentes burstiles. La perspectiva (c) tiene im a plicaciones en el rea de la certicacin de componentes. Por ultimo, la perspectiva (d) tiene a o implicaciones en el rea del desarrollo de estndares para el mercado de componentes. En a a nuestro caso, slo nos centraremos en los contratos de la primera perspectiva. o Como hemos adelantado antes, las interfaces de un componente contienen la denicin o abstracta de las operaciones y atributos. Originariamente, las interfaces pod ser descritas an imponiendo tambin condiciones de uso en un solo sentido, y que especicaban cmo un e o cliente pod acceder o utilizar los servicios (operaciones) implementados por un compoa nente. Sin embargo, en el desarrollo de sistemas basados en componentes, estas condiciones de uso en un solo sentido (del componente al cliente) se convierten en condiciones rec procas de doble sentido entre el cliente y el componente. Por regla general, el papel del cliente es asumido por otro componente software, y que tambin impone sus condiciones de uso. e Por lo tanto, de igual forma que un componente servidor (el componente que ofrece servicios) impone sus restricciones de uso, un componente cliente (aquel que consume o utiliza los servicios ofertados por el componente servidor) tambin podr exigir al componente e a servidor que describa lo que sucede tras consumir el servicio. Estas co-dependencias se suelen denir mediante pre y post condiciones para especicar el comportamiento de las operaciones (similar al ejemplo de la gura 1.7). Su uso garantiza que un cliente pueda interpretar el comportamiento de las implementaciones de una interfaz de componente. A la forma de describir las co-depedencias entre dos o ms partes se le conoce con a el nombre de contrato de interfaz, introducidos originariamente como contratos de interaccin [Holland, 1993]. Estos especican las obligaciones rec o procas (co-dependencias) a travs de los tipos de interfaces que pueden ser implementados por un componente. e Los contratos de interaccin juegan el papel de especicaciones de diseo que debern o n a ser cumplidas por los componentes. Adems, como un componente puede implementar a mltiples tipos de interfaces, ste tambin puede tomar diferentes roles. Por lo tanto, cada u e e contrato de interaccin describe un patrn de interaccin a travs de los diferentes roles. o o o e En 1997 Bertrand Meyer [Meyer, 1997] introduce el concepto de diseo por contran to, una forma de construccin de software que asegura que el software es able desde sus o comienzos, construyndolo como colecciones de elementos que cooperan entre s sobre la e base de precisas obligaciones de cada uno de ellos (los contratos). Esto gu en los procea sos de anlisis, diseo, implementacin, documentacin y prueba, entre otros. El diseo a n o o n por contrato est siendo utilizado como base para desarrollar componentes de cona anza (trusted components) [Meyer et al., 1998]. El concepto de componente de conanza

La concepcin o realista del trmino e contrato ha inspirado su aplicacin en o a reas de los componentes software como en la composicin, la o colaboracin o o la certicacin, o entre otros

Algunos modelos de componentes como EJB denen modelos de interaccin o (considerados como contratos) entre por ejemplo los contenedores (Containers) y los componentes (SessionBeans)


22

1.4. INGENIER DEL SOFTWARE BASADA EN COMPONENTES COTS IA

est siendo investigado en el proyecto Trusted Components for the Software Industry de a Bertrand Meyer, Christine Mingins y Heinz Schmidt (en http://www.trusted-components. org existe abundante informacin de la iniciativa). Como objetivo, el proyecto persigue la o creacin de una fundacin slida para la industria del software con amplias librer de o o o as componentes software reutilizables y de conanza (componentware). El calicativo conanza se consigue combinando diferentes aproximaciones, como el uso de Diseo por n contrato, pruebas de correccin matemtica, o mtricas de evaluacin, entre otros. o a e o Por lo que hemos visto hasta el momento, podr amos decir que hay dos tipos de contratos: (a) los contratos entre las interfaces y los clientes (usuarios o componentes software) que utilizan dichas interfaces; y (b) los contratos entre las interfaces y sus implementaciones. Los primeros se corresponden con los contratos de interaccin de Holland o [Holland, 1993], y son contratos en tiempo de ejecucin. Los segundos se corresponden o con el diseo por contrato de Meyer [Meyer, 1997], y son contratos (como su nombre n indica) en tiempo de diseo. De hecho, en [Bachman et al., 2000] podemos encontrar estos n dos tipos de contratos como contratos de interaccin y contratos de componente. Y o en [Cheesman y Daniels, 2001] como contratos de uso y contratos de realizacin. La o gura 1.9 resume las dos vistas de contrato referidas. Implementacion de componente realizacion

Especificacion de componente

usa

Cliente

Figura 1.9: Diferentes tipos de contratos Un contrato de uso describe la relacin entre una interfaz del objeto componente y un o cliente, y se describe (el contrato) en forma de interfaz. La especicacin contiene descripo cin sintctica de las operaciones de la interfaz y la descripcin del comportamiento de las o a o operaciones en la forma de pre/post condiciones. Por otro lado, un contrato de realizacin o describe la relacin entre una especicacin de componente y una implementacin de como o o ponente, que debe ser asumida por la persona que cre la implementacin (el realizador). o o Por ultimo, las credenciales son una forma de recoger las propiedades extra-funcionales de un componente [Shaw, 1996]. Una credencial (propiedad extra-funcional) se dene como una terna , donde property es el nombre de la propiedad de componente, valor es el valor de esta propiedad para un componente en particular, y confianza es el grado de certeza del valor dado para esta propiedad.

La interfaz de un componente dene el comportamiento de las operaciones. La especicacin de o un componente dene las caracter sticas de implementacin o e implantacin o del componente, y cmo o interacta con u otros componentes (p.e., mediante diagramas de colaboracin) o

1.4.

Ingenier del software basada en componentes COTS a

Desde hace tiempo, la reutilizacin de software ha venido siendo una prctica comn para o a u la construccin de productos software. La reduccin de los costes, tiempos y esfuerzos en o o los procesos de elaboracin han sido algunos de los motivos que han llevado a los ingenieros o de software a considerar tcnicas para la reutilizacin de partes software en prcticamente e o a cualquier fase del ciclo de vida del producto (anlisis, diseo e implementacin). Estas a n o partes software, generalmente, se corresponden con fragmentos de cdigo, procedimientos, o librer y programas desarrollados en otros proyectos dentro de la organizacin, y que as o pueden ser utilizados de nuevo para ser incorporados en ciertas partes del nuevo producto que hay que desarrollar. Adems, en estos ultimos aos hemos podido comprobar un aumento en el uso de a n componentes comerciales en prcticas de reutilizacin de software. Concretamente, estos a o



23

componentes comerciales, que comnmente se conocen con el nombre de componentes u COTS (Commercial O-The-Shelf), estn siendo considerados con mayor asiduidad para a la construccin de sistemas complejos, distribuidos y abiertos. Para la elaboracin de estos o o sistemas, los ingenieros utilizan metodolog procesos y tcnicas de desarrollo basados en as, e componentes (DSBC). El sistema a desarrollar estar compuesto por una o ms aplicaciones a a software, que pueden ser consideradas o no como componentes. Incluso puede que algunas de estas aplicaciones software hayan sido construidas mediante la composicin de otras o partes software (componentes) durante el desarrollo del sistema. Estas partes software ensambladas han podido ser obtenidas de muy diversas formas: a) Desarrolladas. En este caso los componentes son construidos directamente por la organizacin dentro del proyecto de desarrollo del sistema, y todav sigue siendo o a (aunque cada vez menos) la prctica habitual y tradicional en la elaboracin de un a o producto software. b) Reutilizadas. Otra posibilidad es que los componentes hayan sido reutilizados a partir de repositorios, propios a la organizacin, que contienen cdigo (fuente y ejecutable) o o bien denido, desarrollado en otros proyectos de la organizacin, y que pueden ser o utilizados en nuevos proyectos. Sin embargo, esta no es una prctica muy habitual a dentro de las organizaciones, ya que por regla general no se disponen de estos repositorios internos con partes software (componentes) con especicaciones bien denidas, y en ocasiones hay que aplicar prcticas de reingenier inversa, donde a partir del a a cdigo y de la documentacin comentada dentro del cdigo (si lo hay) se intenta o o o extraer sus caracter sticas de funcionamiento para comprender su comportamiento. c) Adquiridas. Una ultima posibilidad consiste en adquirir el componente software a travs de terceras partes, en lugar de construirlo, reduciendo con ello el tiempo, coste e y esfuerzo que conlleva el desarrollo del componente. No obstante, esto supone tambin disponer de repositorios y catlogos de componentes comerciales conocidos, con e a especicaciones bien denidas y estandarizadas, con adecuadas tcnicas y procesos e de bsqueda, seleccin y evaluacin de componentes: en denitiva, disponer de un u o o mercado de componentes comerciales consolidado. Desafortunadamente, todo esto no sucede en la realidad, aunque es cierto que en el rea ISBC existen grandes esfuerzos a de investigacin en estos ultimos aos para llegar a conseguir estos objetivos. o n Como adelantamos en el prlogo de esta memoria, el trabajo que hemos desarrollado o se enmarca precisamente dentro de esta rea de la ingenier del software basada en coma a ponentes (ISBC). En el trabajo proponemos un mtodo para elaborar sistemas de software e a partir de componentes COTS, basada en un modelo de mediacin (trading) que efecta o u labores de bsqueda y seleccin de componentes dentro de un repositorio, con documentos u o de especicacin de componentes COTS que tambin hemos desarrollado. o e Como una justicacin a los siguientes apartados de este cap o tulo, debemos decir que el proceso se caracteriza bsicamente por tres aspectos: (a) Los requisitos de los coma ponentes, que se establecen a partir un modelo de documentacin de componentes COTS; o (b) La denicin de la arquitectura de software del sistema que hay que construir en base o a los componentes COTS; y (c) Un servicio de mediacin (trading service) que localiza o documentos de componentes COTS ya existentes que coinciden con aquellos documentos necesitados y denidos en la arquitectura de software. En esta seccin vamos estudiar algunas de las propiedades que caracterizan a un como ponente COTS, su relacin con los sistemas abiertos y estndares, y de forma general, el o a estado actual en los procesos de desarrollo de software con este tipo de componente.


24


1.4.1.

Componentes comerciales (COTS)

El principio bsico de los a sistemas abiertos es el uso de interfaces estndares junto a con el uso de implementaciones que se adecuan dichas interfaces

El trmino COTS, como sucede con muchos otros trminos en el campo de la informtica e e a (como por ejemplo Internet), surge desde el Ministerio de Defensa de los Estados Unidos [Oberndorf, 1997]. Histricamente hablando, el trmino COTS se remonta al primer luso e tro de los aos 90, cuando en Junio de 1994 el Secretario de Defensa americano, William n Perry, orden hacer el mximo uso posible de especicaciones y estndares comerciales o a a en la adquisicin de productos (hardware y software) para el Ministerio de Defensa. En o Noviembre de 1994, el Vicesecretario de Defensa para la Adquisicin y Tecnolog Paul o a, Kaminski, orden utilizar estndares y especicaciones de sistemas abiertos como una noro a ma extendida para la adquisicin de sistemas electrnicos de defensa. A partir de entonces, o o los trminos comercial, sistemas abiertos, estndar y especicacin han estado e a o muy ligados entre s (aunque un trmino no implica los otros), estando muy presentes en e estos ultimos aos en ISBC. n El trmino componente comercial puede ser referido de muy diversas formas, coe mo por ejemplo, software Commercial O-The-Shelf (COTS), o Non-Developmental Item (NDI), o incluso Modiable O-The-Shelf (MOTS) [Carney y Long, 2000]. En realidad existen unas pequeas diferencias entre ellos, diferencias que reejamos en la tabla 1.6. En n cualquier caso, nos referiremos a las tres categor como componentes COTS. asCategor Descripcin a o COTS NDI Software que (a) existe a priori, posiblemente en repositorios; (b) est disponible a al pblico en general; y (c) puede ser comprado o alquilado. u Software desarrollado inicialmente sin un inters comercial por unas orgae nizaciones para cubrir ciertas necesidades internas, y que puede ser requerido por otras organizaciones. Por tanto es un software que (a) existe tambin a prie ori, aunque no necesariamente en repositorios conocidos; (b) est disponible, a aunque no necesariamente al pblico en general; y (c) puede ser adquirido, u aunque ms bien por contrato. a Un tipo de software O-The-Shelf donde se permite tener acceso a una parte del cdigo del componente, a diferencia del componente COTS, cuya naturaleza es o de caja negra, adquirido en formato binario, y sin tener posibilidad de acceder al cdigo fuente. o

MOTS

Tabla 1.6: Tipos de software comercial Como sucede para el caso de los componentes software, en la literatura tampoco existe una denicin concreta y comnmente usada para el trmino COTS. Una denicin o u e o h brida del trmino componente COTS la podemos encontrar utilizando, por un lado, e la denicin de componente de [Szyperski, 1998], visto anteriormente (vase denicin o e o Szyperski, pgina 7), y por otro lado la denicin de elemento COTS del SEI, que dice a o lo siguiente: Denicin 1.5 (Elemento COTS del SEI, [Brown y Wallnau, 1998]) Un elemeno to COTS se reere a un tipo particular de componente software, probado y validado, caracterizado por ser una entidad comercial, normalmente de grano grueso y que reside en repositorios software, y que es adquirido mediante compra o alquiler con licencia, para ser probado, validado e integrado por usuarios de sistemas. Existen otros autores, como [Addy y Sitaraman, 1999] o [Meyers y Oberndorf, 2001], que tambin consideran que un componente comercial no tiene necesariamente que ser e



25

adquirido mediante compra o licencia, sino que tambin puede ser adquirido como software e de dominio pblico o desarrollado fuera de la organizacin. Segn estas perspectivas, para u o u nuestros propsitos, entendemos por componente COTS lo siguiente: o Denicin 1.6 (Componente COTS) Un componente COTS es una unidad de eleo mento software en formato binario, utilizada para la composicin de sistemas de software o basados en componentes, que generalmente es de grano grueso, que puede ser adquirido mediante compra, licencia, o ser un software de dominio pblico, y con una especicacin u o bien denida que reside en repositorios conocidos.

1.4.2.

Limitaciones del desarrollo de software con componentes COTS

Sin embargo, el uso que se hace de la denicin de componente COTS conlleva una serie de o limitaciones. En primer lugar, aunque es cierto que desde 1994 se estn utilizando prcticas a a para la utilizacin de componentes comerciales en procesos de desarrollo, la realidad es que o muchas organizaciones encuentran que el uso de componentes COTS conlleva un alto riesgo y esfuerzo de desarrollo, y para controlar su evolucin y mantenimiento dentro del sistema o [Dean y Vigder, 1997]. Estos problemas se deben en cierta medida, a que las organizaciones utilizan procesos y tcnicas tradicionales para el desarrollo basado en componentes, pero e no para componentes comerciales. Otro inconveniente, es que los fabricantes de componentes COTS tampoco documentan de forma adecuada sus productos para que puedan ser consultados por usuarios desarrolladores que necesitan conocer detalles de especicacin del componente, como informacin o o acerca de sus interfaces, protocolos de comunicacin, caracter o sticas de implantacin (tipos o de sistemas operativos y procesadores donde funciona, lenguaje utilizado, dependencias con otros programas, etc.) y propiedades extra-funcionales, como las tratadas en la seccin o 1.3.4. Por ultimo, dado que no existen formas globalmente conocidas para documentar los componentes COTS, tambin son inexistentes los repositorios que almacenen especicae ciones de componentes COTS, y por tanto, en mayor medida, no se puede pensar en procesos de mediacin que permitan por un lado a los fabricantes de componentes COTS o poder anunciar sus productos, y por otro a los usuarios de componentes COTS poder buscar los componentes COTS que necesitan. Nuestra trabajo presentado en los prximos cap o tulos pretende ofrecer una propuesta de solucin para estas deciencias planteadas, y ser consecuentes as con la denicin de o o componente COTS ofrecida anteriormente (ver denicin 1.6). Veamos a continuacin o o algunas caracter sticas ms acerca de esta clase de componente. a

1.4.3.

Caracter sticas de un componente comercial

Por regla general, existe una gran diversidad de parmetros que caracterizan a un compoa nente COTS, pero sin embargo, dos son los ms comunes en la literatura de componentes a COTS. En primer lugar, un componente COTS suele ser de grano grueso y de naturaleza de caja negra sin posibilidad de ser modicado o tener acceso al cdigo fuente. Una de o las ventajas de un software comercial es precisamente que se desarrolla con la idea de que va a ser aceptado como es, sin permitir modicaciones. Hay algunos desarrolladores de componentes que permiten la posibilidad de soportar tcnicas de personalizacin que no e o requieren una modicacin del cdigo fuente, por ejemplo mediante el uso de plug-ins y o o scripts. Y en segundo lugar, un componente COTS puede ser instalado en distintos lugares y por distintas organizaciones, sin que ninguna de ellas tenga el completo control sobre


26


Se pretende utilizar los componentes COTS como partes ensamblables en la construccin o de sistemas, en lugar de considerarlos unicamente como programas nales de usuario. Por este motivo los desarrolladores de componentes COTS se estn a interesando en disponer de especicaciones estandarizadas para sus productos

la evolucin del componente software. Es slo el vendedor de componentes COTS quien o o decide su evolucin y venta. o Son muy numerosas las ventajas aunque tambin lo son los inconvenientes de e utilizar componentes COTS en lugar de componentes de fabricacin propia. Comentemos o algunas de ellas, empezando por las ventajas. Una de las ventajas ms claras es el factor econmico, relacionado con el coste de a o desarrollo. Puede ser mucho ms barato comprar

Desarrollo de Software Basado en Componentes

Documents

Transcript of Desarrollo de Software Basado en Componentes