INTRODUCCIN

La complejidad de los sistemas computacionales actuales nos ha

llevado a buscar la reutilizacin del software existente. El desarrollo
de software basado en componentes permite reutilizar piezas de
cdigo preelaborado que permiten realizar diversas tareas,
conllevando a diversos beneficios como las mejoras a la calidad, la
reduccin del ciclo de desarrollo y el mayor retorno sobre la inversin.
Al comparar la evolucin del ambiente de IT con el crecimiento de las
metrpolis actuales, podemos entender el origen de muchos
problemas que se han presentado histricamente en la construccin
de software y vislumbrar las posibles y probables soluciones que nos
llevarn hacia la industrializacin del software moderno.
Este proceso de industrializacin ha dado ya sus inicios con
implementaciones como la plataforma .net, la cual impulsa la idea de
industrializar el software utilizando tecnologas de componentes. Los
avances y mejoras presentados en esta plataforma van mucho ms
all de las implementaciones iniciales como COM y CORBA,
convirtiendo a los componentes .net en verdaderas piezas de
ensamblaje, en un estilo muy similar a las lneas de ensamblaje
modernas. Asimismo, los nuevos paradigmas como las Fbricas de
Software proveen de los medios para hacer la transicin desde el
'hacer a mano' hacia la fabricacin o manufactura de software.
Si hay algo que ha aprendido el ser humano desde tiempos muy
antiguos es a reutilizar el conocimiento existente para sus cada vez
ms ambiciosas empresas. En efecto, al reutilizar trozos de
experiencias, ideas y artefactos, no solo nos aseguramos de no
cometer los mismos errores del pasado, sino que logramos construir
cosas cada vez ms grandes y maravillosas, con bases firmes y
calidad incomparable. Este concepto de la reutilizacin, uno de los
primeros que se nos ensean a quienes entramos al mundo del
desarrollo de software, habremos de utilizarlo desde el mismo
instante en que escribamos nuestra primera lnea de cdigo.
Los sistemas de hoy en da son cada vez ms complejos, deben ser
construidos en tiempo rcord y deben cumplir con los estndares ms
altos de calidad. Para hacer frente a esto, se concibi y perfeccion lo
que hoy conocemos como Ingeniera de Software Basada en
Componentes (ISBC), la cual se centra en el diseo y construccin de
sistemas computacionales que utilizan componentes de software
reutilizables. Esta ciencia trabaja bajo la filosofa de "comprar, no
construir", una idea que ya es comn en casi todas las industrias

existentes, pero relativamente nueva en lo que a la construccin de

software se refiere.

COMPONENTES
DEFINICIN Y CARACTERSTICAS
Un componente de software individual es un paquete de software, un
servicio web, o un mdulo que encapsula un conjunto de funciones
relacionadas (o de datos).
Segn Philippe Krutchen de Rational Rose, un componente es una
parte no trivial, casi independiente y reemplazable de un sistema que
cumple una funcin dentro del contexto de una arquitectura bien
definida. Un componente cumple con un conjunto de interfaces y
provee la realizacin fsica de ellas.
Segn Clemens Szyperski , un componente de software es una unidad
de composicin con interfaces especificadas contractualmente y
solamente dependencias explcitas de contexto. Un componente de
software puede ser desplegado independientemente y est sujeto a
composicin por terceros.
Todos los procesos del sistema son colocados en componentes
separados de tal manera que todos los datos y funciones dentro de
cada componente estn semnticamente relacionados (justo como
con el contenimiento de clases). Debido a este principio, con
frecuencia se dice que los componentes son modulares y cohesivos.
Con respecto a la coordinacin a lo largo del sistema, los
componentes se comunican uno con el otro por medio de interfaces.
Cuando un componente ofrece servicios al resto del sistema, ste
adopta una interface proporcionada que especifica los servicios que
otros componentes pueden utilizar, y cmo pueden hacerlo. Esta
interface puede ser vista como una firma del componente - el cliente
no necesita saber sobre los funcionamientos internos del componente
(su implementacin) para hacer uso de ella. Este principio resulta en
componentes referidos como encapsulados. Las ilustraciones UML de
este artculo representan a las interfaces proporcionadas, con un
smbolo lollipop unido al borde externo del componente.

Sin embargo, cuando un componente necesita usar otro componente

para poder funcionar, adopta una interface usada que especifica los
servicios que necesita. En las ilustraciones de UML en este artculo,
las interfaces usadas son representadas por un smbolo de zcalo
abierto unido al borde externo del componente.
Otro atributo importante de los componentes es que son sustituibles,
as que un componente puede sustituir a otro (en tiempo de diseo o
tiempo de ejecucin), si el componente sucesor cumple los requisitos
del componente inicial (expresado por medio de las interfaces). Por lo
tanto, los componentes pueden ser sustituidos por una versin
actualizada o una alternativa sin romper el sistema en el cual operan.
Como una regla de oro general para los ingenieros que sustituyen
componentes, el componente B puede sustituir inmediatamente al
componente A, si el componente B proporciona por lo menos que el
componente A provee y no usa ms cosas que las que el componente
A usa.
Los componentes de software con frecuencia toman la forma de
objetos (no clases) o de colecciones de objetos (de la programacin
orientada a objetos), en una cierta forma binaria o textual,
adhirindose a un cierto lenguaje de descripcin de interface (IDL) de
modo que el componente pueda existir autnomo de otros
componentes en una computadora.
Cuando un componente debe ser accesado o compartido a travs de
contextos de ejecucin o enlaces de red, a menudo son empleados
tcnicas tales como serializacin o marshalling para enviar el
componente a su destino.
La reusabilidad es una importante caracterstica de un componente
de software de alta calidad. Los programadores deben disear e
implementar componentes de software de una manera tal que
diversos programas puedan reutilizarlos. Adems, cuando los
componentes de software interactan directamente con los usuarios,
debe ser considerada la prueba de usabilidad basada en
componentes.
Toma un significativo esfuerzo y conciencia para escribir un
componente de software que sea efectivamente reutilizable. El
componente necesita estar:

completamente documentado

probado a fondo

robusto - con una comprensiva comprobacin para la

validez de la entrada

capaz de devolver mensajes de error apropiados o

cdigos de retorno

diseado con conciencia de que ser puesto en usos

imprevistos

BENEFICIOS DEL DESARROLLO DE SOFTWARE BASADO EN

COMPONENTES
En esencia, un componente es una pieza de cdigo preelaborado que
encapsula alguna funcionalidad expuesta a travs de interfaces
estndar . Los componentes son los "ingredientes de las
aplicaciones", que se juntan y combinan para llevar a cabo una tarea .
Es algo muy similar a lo que podemos observar en el equipo de
msica que tenemos en nuestra sala. Cada componente de aquel
aparato ha sido diseado para acoplarse perfectamente con sus
pares, las conexiones son estndar y el protocolo de comunicacin
est ya preestablecido. Al unirse las partes, obtenemos msica para
nuestros odos.
El paradigma de ensamblar componentes y escribir cdigo para hacer
que estos componentes funcionen se conoce como Desarrollo de
Software Basado en Componentes. El uso de este paradigma posee
algunas ventajas:

Reutilizacin del software. Nos lleva a alcanzar un mayor nivel

de reutilizacin de software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas
probando cada uno de los componentes antes de probar el
conjunto completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un dbil
acoplamiento entre componentes, el desarrollador es libre de
actualizar y/o agregar componentes segn sea necesario, sin
afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido
y luego mejorado continuamente por un experto u organizacin,
la calidad de una aplicacin basada en componentes mejorar
con el paso del tiempo.

REUSABILIDAD DEL COMPONENTE

Una de las caractersticas ms importantes de los componentes es

que son reutilizables. Para ello los componentes deben satisfacer
como mnimo el siguiente conjunto de caractersticas:
Identificable: un componente debe tener una identificacin clara y
consistente que facilite su catalogacin y bsqueda en repositorios de
componentes.
Accesible slo a travs de su interfaz: el componente debe
exponer al pblico nicamente el conjunto de operaciones que lo
caracteriza (interfaz) y ocultar sus detalles de implementacin. Esta
caracterstica permite que un componente sea reemplazado por otro
que implemente la misma interfaz.
Sus servicios son invariantes: las operaciones que ofrece un
componente, a travs de su interfaz, no deben variar. La
implementacin de estos servicios puede ser modificada, pero no
deben afectar la interfaz.
Documentado: un componente debe tener una documentacin
adecuada que facilite su bsqueda en repositorios de componentes,
evaluacin, adaptacin a nuevos entornos, integracin con otros
componentes y acceso a informacin de soporte.
FRAMEWORKS Y MODELOS DE COMPONENTES
Existe cierta confusin en la literatura referente a la terminologa de
modelos y frameworks de componentes. Sin embargo, hay consenso
acerca de que los sistemas basados en componentes confan en
estndares y convenciones bien definidas (modelo de componentes) y
en una infraestructura de soporte (framework de componentes). Los
modelos de componentes especifican las reglas de diseo que deben
obedecer los componentes. Estas reglas de diseo mejoran la
composicin, aseguran que las calidades de servicio se logren en todo
el sistema, y que los componentes se puedan desplegar fcilmente
tanto en entornos de desarrollo como de produccin. Los modelos de
componentes imponen estndares y convenciones sobre:
Tipos de Componentes: Un tipo de componente puede ser
definido en trminos de las interfaces que implementa. Los tipos
diferentes de componentes pueden desempear diferentes roles en el
sistema, y participar en distintos tipos de esquemas de interaccin.
Esquemas de Interaccin: especifican cmo los componentes
son localizados, cules protocolos de comunicacin son utilizados, y
cmo se satisfacen las calidades de servicio (e.g. seguridad,

transacciones, alta disponibilidad). El modelo de componentes puede

describir cmo interactan los componentes entre s y cmo
interactan dichos componentes con el framework.
Asociacin (bindings) de recursos: El proceso de composicin
de componentes es simplemente enlazar un componente a uno o ms
recursos. Un recurso es un servicio ofrecido por un framework o por
otro componente desplegado en ese framework. Un modelo de
componentes describe cules recursos estn disponibles a los
componentes, y cmo y cundo se asocian estos componentes a
stos recursos.
Por otra parte, los frameworks de componentes proporcionan
servicios que soportan y hacen cumplir el modelo componentes
asociado. El framework maneja recursos compartidos por los
componentes, y proporciona mecanismos subyacentes que permiten
la comunicacin (interaccin) entre ellos. Los frameworks son activos
y actan directamente sobre componentes, por ejemplo
administrando su ciclo de vida (comenzar, suspender, reasumir, o
terminar la ejecucin de un componente), y otros recursos. Existen
muchos ejemplos de frameworks de componentes, entre stos
Enterprise JavaBeans (EJB) y VisualBasic Framework (VBF) de
Microsoft son de los ms representativos.
MECANISMOS DE INTEGRACIN O COMPOSICIN DE
SOFTWARE
Bajo el modelo de desarrollo de software basado en componentes,
las nuevas aplicaciones se construyen mediante la integracin o
composicin de componentes. Sametinger [2] define la composicin
de software como el proceso de construir aplicaciones mediante la
interconexin de componentes de software a travs de sus interfaces
(de composicin)". Ntese que se hace especial nfasis en las
interfaces como elementos fundamentales para lograr la composicin
de componentes. La composicin puede concebirse como una
relacin cliente-servidor entre dos componentes (Figura 1). El
componente cliente solicita un servicio (operacin) del componente
servidor, el cual ejecuta la operacin solicitada y devuelve los
resultados al cliente. El servidor produce un resultado que es
consumido por el cliente.
Adems de los componentes, los frameworks tambin se consideran
entidades sujetas a composicin. En consecuencia, existen tres clases
principales de interaccin en los sistemas basados en componentes:

1. Componente-Componente (C-C): permite la interaccin entre

componentes. De este tipo de interaccin se obtiene la funcionalidad
de la aplicacin, de forma tal que los contratos que especifican este
tipo de interaccin pueden ser clasificados como Contratos a Nivel de
Aplicacin.
2. Componente-Framework (C-F): posibilita las interacciones
entre el framework y sus componentes. Dicha interaccin permite que
el framework administre los recursos de los componentes. Los
contratos que especifican estas interacciones pueden ser clasificados
como Contratos a Nivel de Sistema.
3. Framework-Framework (F-F): posibilita las interacciones entre
framewoks y permiten la composicin de componentes desplegados
en framewoks heterogneos. Estos contratos puede ser clasificados
como Contratos de Interoperabilidad.
La forma de materializar la composicin entre componentes depende
de los mecanismos especificados por su modelo de programacin.
Tpicamente, los modelos de componentes se basan en tecnologas
orientadas a objetos, por lo tanto los mecanismos de composicin
emplean algunas caractersticas tales como relaciones entre clases
(especializacin, agregacin, asociacin y uso), polimorfismo y enlace
dinmico. Adicionalmente, dichos mecanismo de composicin
tpicamente se describen mediante el uso de patrones de diseo. Las
tecnologas de componentes no distribuidos, tpicamente asociadas
con aplicaciones de escritorio (e.g. Controles ActiveX y JavaBeans),
hacen uso extensivo de caractersticas orientadas a objetos dentro de
sus mecanismos de composicin. Por el contrario, en la composicin
de componentes distribuidos (e.g. Enterprise JavaBeans, CORBA
Component Model y .NET) principalmente se emplean relaciones de
uso, asociacin y agregacin.

DISEO DE COMPONENTES BASADOS EN CLASES

cuando se elige un metodo de ingenieria de software basado en componentes el nivel de
diseo de estos se concentra en la elaboracion de clases de analisis y la definicion y afinacion
de clases de infraestructura.
hay cuatro principios basicos basados en el nivel de diseo de componentes
1. El principio abierto ceraddo PAC un modulo debe estar abiero para extenciones pero cerrado
para modificaciones.
2. Principio de sustitucion de Liskov PSL debe tenerse la opcion de sustituir las subclases con
sus clases principales.

3. Principio de la inversion de la dependencia PID dependa de las abstracciones no de las

concreciones, mientras un componentes dependa mas de de otros componentes concretos es
mas dificil extenderlos.
4. Principio de la segregacion de la interfaz es mejor tener tener muchas interfaces especificas
del cliente que una interfaz de proposito general.
existen tambien principios de empaquetamiento los cuales son
Principio de equivalencia entre reutilizacion y version, la esencia de la reutilizacion es la misma
que la version
Principio del cierre comun, las clases que cambian juntas deben mantenerse juntas
Principio comun de la reutilizaicon PCR las clases que no se reutilizan juntas no deben
mantenerse juntas
Existen distintas lineas generales que se pueden seguir durante el diseo de componentes
1. los componentes deben definirse convensiones de asignacion de nombres, los cuales
provengan del dominio del sistema y tener algun significado para los participantes
2. interfaces proporcionan informacion importante acerca de la comunicacion y colaboracion,
aun que al tener muchas se puede crear confucion en el diagrama uml por lo que se
recomienda entre otras cosas al tener demasiadas usar circulos en ves de rectangulos y
mostrar solo las mas importantes
3. las dependencias de izquierda a derecha y las herencias la clase principal arriba y deribadas
abajo
COHESION
Implica que un componente o una clase encapsula unicamente atributos y operaciones
relacionadas estrechamente entre si y con la clase del propio componente.
existen distintos tipos de cohesion
Funcional, cuando un modulo realiza un solo calculo y devuelve el resultado
De capa, cuando una capa superior tienen acceso a una inferior pero no al reves
De comunicacion, todas las operaciones con acceso a los mismos datos se definen dentro
de una clase.
Secuencial, las operaciones estan agrupadas de manera que primero permita la entrada al
siguiente y asis sucesivamente.
Procedimental
Temporal
Utilitaria
ACOPLAMIENTO
Es una medida cualitativa del grado al que las clases se conectan entre si a medida que las
clases se vuelven mas interdependientes el acoplamiento aumenta.
Acoplamiento comun
Acoplamiento del contenido
Acoplamiento de control
Acoplamiento de estampa
Acoplamiento de datos
Acoplamiento de llamada a rutina
Acoplamiento de uso de tipo

Acoplamiento de incursion o aportacion

Acoplamiento externo
NOTACION GRAFICA DEL DISEO