DESARROLLO DE SOFTWARE BASADO EN COMPONENTES (DSBC)

INTRODUCCIÓN

El presente trabajo trata de explicar los lineamientos generales y los conceptos básicos que presenta el Desarrollo de Software Basado en Componentes (DSBC) reutilizables y distribuidos, y los procesos de ingeniería que sugiere este modelo. Está metodología es una disciplina muy reciente, que surge como una extensión del paradigma de desarrollo Orientado a Objetos1 para arquitecturas de desarrollo donde los sistemas de aplicaciones son distribuidos y abiertos, y que presentan una complejidad inherente al sistema relativamente alta, donde este último modelo se ve seriamente limitado, como por ejemplo los sistemas de información distribuidos bajo Web o las Telecomunicaciones. Así también, se basa y extiende el modelo de objetos, y mantiene muchas de sus características principales, agregando la filosofía del “ensamblaje” de componentes de software independientes y previamente construidos y testeados, y extendiendo más aún el concepto de “reutilización” del software dentro de las aplicaciones

¿POR QUÉ SURGE ESTÁ METODOLOGÍA?

La metodología de software basada en Componentes surgió a finales de los 90's como

una aproximación basada en la reutilización al desarrollo de sistemas de software. Está metodología fue motivada por la frustración de los desarrolladores de que el modelo orientados a objetos no aplicaba una reutilización extensiva, tal como ésta sugería originalmente, debido a que la utilización de clases implica el conocimiento detallado de ellas, lo cual significa que se debía tener acceso al código fuente lo que imposibilitaba el marketing de clases para su reutilización.

Un acercamiento al concepto de Componente

Un componente es una unidad de software independiente que puede estar compuesta por otros componentes y que se utiliza para crear un sistema de software.

Existen componentes con estado y sin estado. Que un componente no tenga estado externamente observable significa que las copias de componentes son indistinguibles, estos son más sencillos de implementar. De cualquier modo se considera que la ingeniería de software basado en componentes (CBSE) debería adaptarse tanto a los componentes sin estado como los componentes con estado

Interfaces:

Los componentes se definen por sus interfaces y puede considerarse que tienen dos

Interfaces relacionadas.

1- Interfaz que proporciona: Define los servicios que proporciona el componente,

lo que se conoce como el API del componente. Define los métodos que pueden ser

llamados por el usuario del componente.

2- Interfaz que requiere: Especifica que servicios son necesarios para que el

componente funcione, estos son requeridos de otros componentes del sistema. Esto no altera la independencia del componente, debido a que los servicios que se requieren no son solicitados a un componente especifico.

DIFERENCIA ENTRE COMPONENTES Y CLASES DE OBJETOS:

Los componentes se desarrollan normalmente de forma similar a los objetos pero difieren en varios aspectos:

1- Los componentes son entidades desplegables: No son compilados, se instalan directamente en una plataforma de ejecución. Los métodos y atributos definidos en sus interfaces pueden ser accedidos por otros componentes.

2- Los componentes no definen tipos: Las clases definen un tipo de dato abstracto y los objetos son instancias de ese tipo. Un componente ya es una instancia.

3- Las implementaciones de los componentes son opacas: La implementación de componentes esta oculta para los usuarios. Los componentes se suelen entregar como unidades binarias de este modo el que lo adquiere no tiene acceso a la implementación.

4- Los componentes son independientes del lenguaje: Las clases de objetos tienen que seguir las reglas de los lenguajes orientados a objetos, y generalmente solo pueden con otras clases escritas en el mismo lenguaje. Los componentes suelen implementarse en lenguajes orientados a objetos pero también pueden implementarse en lenguajes no orientados a objetos.

5- Los componentes están estandarizados: Esto significa que los componentes deben ajustarse a un modelo que restringe su implementación, a diferencia de las clases de objetos que pueden implementarse de cualquier forma.

Ingeniería de Software Basada en Componentes (ISBC)

Tradicionalmente los ingenieros del software han seguido un enfoque de desarrollo descendente (top-down) basado en el ciclo de vida en cascada (análisis-diseño-implementación) para la construcción de sus sistemas, donde se establecen los requisitos y la arquitectura de la aplicación y luego se va desarrollando, diseñando e implementando cada parte software hasta obtener la aplicación completa implementada [Iribarne, 2003].

La ISBC parte de la idea de la integración de componentes software ya existentes (desarrollo ascendente o bottom-up).

Las tecnologías de objetos proporcionan el marco de trabajo técnico, para la ingeniería desoftware, para un modelo de proceso basado en componentes. El paradigma orientado a objetos enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos para manejar esos datos. Si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por diferentes aplicaciones. Es la reutilización la que permite a los desarrolladores construir aplicaciones sin partir desde cero, sino acercándose más al modelo de construcción de otras ingenierías, donde los productos se construyen en base al ensamblaje y adaptación de distintos componentes desarrollados por terceros

(como lo es la industria del hardware para computadoras). Por ello requiere un conjunto de estándares, guías, procesos y prácticas, para que se la considere como una ingeniería tal, y como una subdisciplina de la Ingeniería de Software [Iribarne, 2003].

FASE DE CONSTRUCCIÓN Y ADAPTACIÓN DE LA INGENIERÍA

La actividad comienza con la identificación de clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación

...