El desarrollo de sistemas de software basado en componentes, o simplemente

“desarrollo de software basado en componentes” (DSBC) 1, es una aproximación
del desarrollo de software que describe, construye y utiliza técnicas software
para la elaboración de sistemas abiertos y distribuidos mediante el ensamblaje
de partes software reutilizables.

La aproximación DSBC es utilizada para reducir los costes, tiempos y esfuerzos
de desarrollo del software, a la vez que ayuda a mejorar la fiabilidad,
flexibilidad y la reutilización de la aplicación final. Durante algunos años, DSBC
fue referida como una filosofía conocida como “compre, y no construya”
promulgada por Fred Brooks en 1987 [Brooks, 1987] y que abogaba por la
utilización de componentes prefabricados sin tener que desarrollarlos de
nuevo. Hoy día, muchos autores que trabajan en el campo de DSBC empiezan a
reconocer y a aceptar el uso de estándares, guías, procesos y prácticas de
ingeniería, sin los cuales el desarrollo de software basado en componentes
sería una mera mezcla entre competitivos y confusos lenguajes, metodologías
y procesos. Estos estándares, guías, procesos y prácticas han propiciado que se
empiece a hablar del término de “Ingeniería del Software Basada en
Componentes” (ISBC)2, como una subdisciplina de la “Ingeniería del Software”.

En este artículo ofrecemos una visión global de aquellas áreas de DSBC y ISBC
que sustentan las bases de un método para el desarrollo de sistemas de
software basado en un modelo de mediación para componentes COTS para
sistemas abiertos y distribuidos.
El presente capítulo está organizado en nueve secciones, comenzando con una
introducción histórica a los conceptos previos en entornos abiertos y
distribuidos. Describiremos la situación actual en el área de la “Ingeniería de
componentes software” y veremos cómo se lleva a cabo la especificación de un
componente software. También introduciremos algunas nociones de los
componentes COTS y del área de la ingeniería de requisitos. Analizaremos
conceptos relacionados con las arquitecturas de software y servicios de
mediación.

(b) puede ser independientemente desarrollado. A partir de la década del ’60. en tiempo y espacio. incorporado al sistema y compuesto con otros componentes de forma independiente. Una de las primeras figuras de la historia que abordaron el concepto que ahora nos ocupa fue el gran filósofo griego Platón que realizó su propia definición de lo que él consideraba que era un paradigma. el citado pensador expuesto que esta palabra venía a determinar a lo que son las ideas o los tipos de ejemplo de una cosa en cuestión. los alcances de la noción se ampliaron y ‘paradigma’ comenzó a ser un término común en el vocabulario científico y en expresiones epistemológicas cuando se hacía necesario hablar de modelos o patrones. aporta la siguiente definición de componente: Un componente software es un fragmento de un sistema software quepuede ser ensamblado con otros fragmentos para formar piezas m´as grandes o aplicaciones completas. PARADIGMA El concepto de paradigma (un vocablo que deriva del griego paradeigma) se utiliza en la vida cotidiana como sinónimo de “ejemplo” o para hacer referencia a algo que se toma como “modelo”. se tenía en cuenta a nivel gramatical (para definir su uso en un cierto contexto) y se valoraba desde la retórica(para hacer mención a una parábola o fábula). y que ha de poder ser desarrollado. También IBM tiene su propio concepto de lo que es un componente y ellos los establecen de la siguiente manera: Es una implementación que (a) realiza un conjunto de funciones relacionadas. En principio. (e) opcionalmente admite una configuración controlada.COMPONENTE Según Szipersky un componente es una unidad binaria de composición de aplicaciones software. 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 sólo a través de sus interfaces. adquirido. . en su acepción como “modelo”. En este sentido. En este sentido. podríamos establecer un ejemplo como el siguiente: El trabajo de Valentino es un paradigma para muchos jóvenes diseñadores. que posee un conjunto de interfaces y un conjunto de requisitos. Además el SEI (Software Engineering Institute).

COMPONENTES COMERCIALES (COTS) . esta es una de las desventajas que mencionábamos antes. En los años 80 se intentó llevar a la práctica una idea similar a la que presenta la “visión optimista”. la mayoría de las iniciativas de reutilización no prosperaron por varias razones obvias: (a) la infraestructura técnica que daba soporte a la reutilización estaba aún inmadura. Sin embargo. Una visión más realista supone que las partes software (componentes) ocultan muchas de sus propiedades. (d) las interfaces y el comportamiento de los módulos software fueron “pobremente” definidos. recopilando y catalogando “módulos software” de aplicaciones para su reutilización. El sueño de los especialistas en ingeniería del software ha sido disponer de “factorías de software” donde partes software ya estandarizadas de una aplicación puedan ser automáticamente seleccionadas desde un catálogo y ensambladas e implantadas fácilmente como solución a una necesidad de desarrollo de la organización. siendo difícil su acceso a la información y al comportamiento interno (black box) en tareas de evaluación. conocidos generalmente como “artefactos” o “módulos software” (assets). (b) la catalogación de módulos software era muy difícil. y en la reutilización se usan componentes de aplicaciones ya creadas ya sea por una misma empresa o por terceros sin embargo esta última llega a presentar problemas por motivos que analizaremos más adelante. (c) los módulos software fueron muy diversos y de calidad también muy variada. la cultura de la reutilización fue infravalorada e insuficientemente apoyada por el mercado.INGENIERIA DE SOFTWARE BASADA EN COMONENTES (ISBC) La ISBC se refiere al desarrollo de software utilizando técnicas para ello. por ejemplo tenemos 2 que son: 1) Desarrollo de Software y 2) Reutilización. (e) y finalmente. y en lugar de arquitecturas de software estándares se tienen particulares notaciones que permiten definir “arquitecturas de partes software” inestables y no probadas. En el caso de desarrollo se inicia crear el software desde 0 hasta construir la aplicación en su totalidad.