Vous êtes sur la page 1sur 20

Tópicos Avanzados de Programación

Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Introducción

La programación Visual Basic, JavaBeans y Delphi depende de un conjunto de


componentes de arrastre y soltar, extraídos de una paleta hacia algún tipo de
superficie de trabajo. Junto con los componentes integrados, los desarrolladores
pueden crear sus propios controles personalizados para realizar funciones
adaptadas a sus propias necesidades de negocio. Los desarrolladores crean
juegos de componentes reutilizables, luego los utiliza como bloques de
construcción para crear nuevas soluciones empresariales. Esta es la base del
desarrollo basado en componentes.

Programación orientada a componentes. Extensión natural de


la programación orientada a objetos (POO) en los sistemas de aplicación abiertos,
que tiene como propósito contrarrestar las limitaciones de esta, como la falta de
una unidad concreta de composición independiente en las aplicaciones, y la
definición de interfaces a bajo nivel, que dificultan la reutilización comercial de
objetos.

El término componente quizás sea uno de los más confusos en programación.


Un componente es el responsable de exponer lógica hacia los clientes, siendo los
clientes cualquier cosa que use al componente. Un componente puede ser una
clase, siendo el cliente otra clase. Entonces, ¿en qué se diferencia la
programación orientada a componentes de la programación orientada a objetos?
Pues ahí reside la confusión que suele envolver al término componente, en saber
dónde trazar las líneas que separan:

 La clase que implementa cierta lógica.


 La entidad física que contiene a la clase (dll).
 La lógica asociada para hacer uso de la clase (información de tipos, política
de seguridad, información de versiones…).

Digamos que la programación orientada a objetos se focaliza en las relaciones


que hay entre las clases combinadas dentro de un gran ejecutable binario,
mientras que la programación orientada a componentes se centra en módulos
intercambiables que trabajan de forma independiente y de los cuales no es
necesario saber nada acerca de sus implementación interna. La diferencia entre
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

ambas técnicas es la manera que tienen ellas de ver a la aplicación final. En la


programación orientada a objetos, el resultado es un código binario monolítico,
todas las clases se localizan en él, mientras que la programación orientada
a componentes se puede imaginar como las piezas del lego, un cambio en la
implementación de una de las piezas está disponible inmediatamente para todo
cliente que la use, sin necesidad de recompilar.

El objetivo de la programación orientada a componentes (POC) es construir


un mercado global de componentes software, en donde los usuarios son los
desarrolladores de las aplicaciones que necesitan reutilizar componentes ya
hechos y testeados para construir sus aplicaciones de forma más rápida y robusta.
En general, puede verse como una extensión natural de la programación orienta a
objetos dentro del ámbito de los sistemas de aplicación abiertos y distribuidos.
Las entidades básicas de la POC son los componentes, estos pueden
interpretarse como cajas negras que encapsulan cierta funcionalidad y que son
diseñadas sin saber quién los utilizará, ni cómo, ni cuándo. Los servicios de los
componentes son conocidos mediante sus interfaces y requisitos.
La POC es un paradigma de programación que se centra en el diseño e
implementación de componentes, y en particular en los conceptos de
encapsulación, polimorfismo, composición tardía y seguridad.

Desarrollo

Los continuos avances en la Informática y las Telecomunicaciones están


haciendo cambiar la forma en la que se desarrollan actualmente las aplicaciones
software. En particular, el incesante aumento de la potencia de los ordenadores
personales, el abaratamiento de los costes del hardware y las comunicaciones, y
la aparición de redes de datos de cobertura global han disparado el uso de los
sistemas abiertos y distribuidos. Esto ha provocado, entre otras cosas, que los
modelos de programación existentes se vean desbordados, siendo incapaces de
manejar de forma natural la complejidad de los requisitos que se les exigen para
ese tipo de sistemas. Comienzan a aparecer por tanto nuevos paradigmas de
programación, como pueden ser la coordinación, la programación orientada a
componentes, o la movilidad, que persiguen una mejora en los procesos de
construcción de aplicaciones software. En ellos se trabaja tanto en extensiones de
los modelos existentes como en nuevos modelos, en la estandarización de sus
interfaces y servicios, y la pertinaz búsqueda del cada vez más necesario mercado
global de componentes software.
Estos son parte de los nuevos retos con los que se enfrenta actualmente la
ingeniera del software.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Uno de los enfoques en los que actualmente se trabaja constituye lo que se


conoce como Desarrollo de Software Basado en Componentes (DSBC), que
trata de sentar las bases para el diseño y desarrollo de aplicaciones
distribuidas basadas en componentes software reutilizables.

La programación orientada a componentes (POC)

La Programación Orientada a Componentes (POC) aparece como una variante


natural de la programación orientada a objetos (POO) para los sistemas abiertos,
en donde la POO presenta algunas limitaciones; por ejemplo, la POO no permite
expresar claramente la distinción entre los aspectos computacionales y
meramente composicionales de la aplicación, no define una unidad concreta de
composición independiente de las aplicaciones (los objetos no lo son, claramente),
y define interfaces de demasiado bajo nivel como para que sirvan de contratos
entre las distintas partes que deseen reutilizar objetos.
La POC nace con el objetivo de construir un mercado global de componentes
software, cuyos usuarios son los propios desarrolladores de aplicaciones que
necesitan reutilizar componentes ya hechos y probados para construir sus
aplicaciones de forma más rápida y robusta.

El concepto de componente
Actualmente existen distintas definiciones de componente. Entre todas las
definiciones hemos querido destacar las siguientes, que son quizá las más
representativas y aceptadas por la comunidad de ingeniera del software:

Una unidad de la composición con interfaces y dependencias de contexto


explícitas contractualmente especificados solamente. Un componente de software
se puede implementar de forma independiente y está sujeta por la composición de
terceras partes. (Definición acordada por los participantes de WCOP'96 [Szyperski
y Pfister, 1997]).

Un conjunto de componentes 'atómicas' desplegadas simultáneamente. Un


componente atómico es un "módulo" más un conjunto de "recursos". Un módulo
es un conjunto de clases y posiblemente otras construcciones no orientados a
objetos, tales como los procedimientos o funciones. ("definición técnica" por
Clemens Szyperski, [Szyperski, 1998]).

Un módulo lógicamente coherente, débilmente acoplado que denota una única


abstracción (Grady Booch, 1987)
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Prefabricadas, pre-probadas, autónomos, módulos de software reutilizables -


manojos de datos y procedimientos, que realizan funciones específicas (Meta
Group, 1994)

Una parte de un kit, que define un conjunto común de protocolos entre sus
miembros. Una parte genérica de software con interfaces robustas y bien definidas
(Allan C. quiere, en [Henderson Sellers et al., 1999]).

Por otro lado, existe también una confusión habitual entre el concepto de
componente con el de clase, objeto, modulo, etc. Con el fin de distinguirlas entre
sí, recogemos aquí las definiciones más aceptadas de otras entidades software,
así como sus principales diferencias.
Clase. Las clases no hacen referencia explícita a sus dependencias y requisitos.
Las clases suelen construirse mediante herencia de implementación, y por tanto
no suelen permitir una instanciación e instalación por separado de la clase base y
de sus clases hijas. Esto puede causar problemas si se realiza composición tardía
(pudiendo aparecer, por tanto, el problema de la clase base frágil).

Modulo. Un módulo es un conjunto de clases, junto con opcionalmente otros


elementos no orientados a objetos, como pueden ser procedimientos y funciones.
Paquetes/Libreras. Un paquete es un conjunto de clases, usualmente agrupadas
conceptualmente. Los paquetes no suelen ser ejecutables, y pueden ser
consideradas como la versión orientada a objetos de las libreras tradicionales.

Subsistema. Un subsistema es una agrupación de elementos de modelado que


representa una unidad de comportamiento en un sistema físico. De acuerdo a la
especificación de UML 1.3, un subsistema es una subclase de Classifier y de
Package, y por tanto no tiene un comportamiento propio, sino que organiza
elementos ejecutables que lo poseen (por ejemplo, componentes).

Recurso. Un recurso es una colección no modificable de elementos con tipo


[Szyperski, 1998].

Frameworks. Los marcos de trabajo suelen estar compuestos de componentes, de


los cuales unos están fijados por el propio marco, y otros son los que proporciona
el usuario para especializar el marco de trabajo.

Otros conceptos básicos de la POC


Composición tardía. Dícese de aquella composición que se realiza en un tiempo
posterior al de la compilación del componente, como puede ser durante su
enlazado, carga o ejecución, y por alguien ajeno a su desarrollo, es decir, que solo
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

conoce al componente por su interfaz o contrato, pero no tiene porque conocer ni


sus detalles de implementación, ni la forma en la que fue concebido para ser
usado.

Entornos. Un entorno es el conjunto de recursos y componentes que rodean a un


objeto o componente dado, y que definen las acciones que sobre ´el se solicitan,
así como su comportamiento. Se pueden definir al menos dos clases de entornos
para los componentes: el entorno de ejecución y el de diseño.

Eventos Mecanismo de comunicación por el que se pueden propagar las


situaciones que ocurren en un sistema de forma asíncrona. La comunicación entre
emisores y receptores de los eventos se puede realizar tanto de forma directa
como indirecta, siguiendo el mecanismo publish-and-subscribe que describiremos
más adelante. Los eventos suelen ser emitidos por los componentes para avisar a
los componentes de su entorno de cambios en su estado o de circunstancias
especiales, como pueden ser las excepciones.

Reutilización. Habilidad de un componente software de ser utilizado en contextos


distintos a aquellos para los que fue diseñado (reutilizar no significa usar más de
una vez). Existen 4 modalidades de reutilización, dependiendo de la cantidad de
información y posibilidades de cambio que permita el componente a ser
reutilizado: caja blanca, caja de cristal, caja gris y caja negra.

Contratos. Especificación que se añade a la interfaz de un componente y que


establece las condiciones de uso e implementación que ligan a los clientes y
proveedores del componente. Los contratos cubren aspectos tanto funcionales
(semántica de las operaciones de la interfaz) como no funcionales (calidad de
servicio, prestaciones, fiabilidad o seguridad).

Polimorfismo. Habilidad de un mismo componente de mostrarse de diferentes


formas, dependiendo del contexto; o bien la capacidad de distintos componentes
de mostrar un mismo comportamiento en un contexto dado. Ambas acepciones
representan los dos lados de una misma moneda. En
POO el polimorfismo se relaciona con la sobre-escritura de métodos y la
sobrecarga de operadores (polimorfismo ad-hoc).

Seguridad. Por seguridad en este contexto se entiende la garantía que debe


ofrecer un componente de respetar sus interfaces y contratos, y forma el concepto
básico sobre el que se puede garantizar la seguridad (en su acepción más amplia)
de un sistema.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Reflexión. La reflexión es la habilidad de una entidad software de conocer o


modificar su estado. A la primera forma se le denomina reflexión estructural, y a la
segunda reflexión de comportamiento.

Tendencias actuales de la POC


Dentro de la POC se está trabajando en varios frentes: la adecuación de los
lenguajes de programación y modelos de objetos existentes para que incorporen
estos conceptos; el diseño de nuevos lenguajes y modelos de componentes; la
construcción de herramientas de desarrollo y marcos de trabajo para
componentes; y la aplicación de técnicas formales para razonar sobre las
aplicaciones desarrolladas a base de componentes.
En cuanto a los lenguajes de programación, solo hay unos pocos que realmente
incorporen conceptos suficientes para realizar una programación orientada a
componentes: Oberon, Java, Ada95, Modula-3 y Component Pascal.

Los primeros MTC nacieron de la idea de los documentos compuestos, en donde


la entidad básica pasa a ser el documento, en vez de la aplicación. Los usuarios
dejan as de disponer de un conjunto de aplicaciones, cada una con una idea
distinta de lo que es un documento, y pasan a disponer solo de documentos. A su
vez, un documento puede contener a su vez a otros documentos, y es la
responsabilidad del sistema manejar a cada tipo de documento con su aplicación
correspondiente.

Por ejemplo en Visual Basic todo son formularios, que pueden contener controles,
aunque la lista de los posibles controles es completamente abierta. De hecho, la
industria comenzó pronto a ofrecer desde hojas de cálculo a procesadores de
texto como controles de Visual Basic para poder integrarlos fácilmente.

En OLE se define el concepto de contenedor y se extiende el concepto de control,


que pasa a denominar cualquier tipo de servidor de documentos. De esta forma
los componentes pueden ser tanto contenedores como servidores de documentos
simultáneamente, y es posible que, por ejemplo, un documento Word se incluya
en una hoja de cálculo Excel, que a su vez forme parte de otro documento Word.

Otro ejemplo de documento compuesto es la Web, en donde es posible incluir en


páginas HTML multitud de objetos distintos, como por ejemplo los Applets de
Java. Aunque más reciente que OLE, supone un paso atrás en cuanto al concepto
que estamos tratando, pues los objetos que forman parte de las páginas Web no
pueden ser a su vez contenedores, es decir, estamos frente a una tecnología
similar a la que ofrecía Visual Basic con sus formularios y controles (aunque ya es
posible en la última versión de Visual Basic definir controles que sean
componentes ActiveX, que si son contenedores de otros componentes).
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

OpenDoc fue diseñado desde el principio como un MTC para documentos


compuestos, y por tanto ofrece numerosas ventajas frente a Visual Basic y OLE.
Sin embargo, no ha gozado de demasiado éxito comercial, aunque se espera que
vuelva a renacer tras ser incorporado por la OMG como parte de las facilidades de
CORBA.

Problemas típicos de la POC


En ese sentido, destacaremos los siguientes retos y problemas con los que se
enfrenta actualmente:

1. Clarividencia. La dificultad con la que se encuentra el diseñador de un


componente al realizar su diseño, pues no conoce ni quien lo utilizara, ni como, ni
en que entorno, ni para que aplicación; además, se encuentra también con la
paradoja de “maximizing reuse minimizes use” [Szyperski, 1998]. Este problema
está intrínsecamente ligado a la composición tarda y reusabilidad de los
componentes.
2. Evolución de los componentes. La gestión de la evolución es un problema serio,
pues en los sistemas grandes han de poder coexistir varias versiones de un
mismo componente. Existen distintos enfoques para abordar este problema
(desde la inmutabilidad de interfaces de COM a la integración de interfaces que
propugna CORBA), aunque ninguno totalmente satisfactorio.
3. Percepción del entorno (environment-awareness). Esta es la habilidad de un
objeto o componente de descubrir tanto el tipo de entorno en donde se está
ejecutando (de diseño o de ejecución), como los servicios y recursos disponibles
en ´el. La inspección y la reflexión estructural son dos mecanismos comúnmente
utilizados para implementar esta habilidad.
4. Particularización. Como particularizar los servicios que ofrece un componente
para adaptarlo a las necesidades y requisitos concretos de nuestra aplicación, sin
poder manipular su implementación. La reflexión de comportamiento es la técnica
comúnmente utilizada, componiendo el componente con envolventes (wrappers,
decorators o adapters) que le proporcionan la funcionalidad apropiada. La
composición simultanea de envolventes y el estudio de las propiedades del nuevo
componente a partir de las del antiguo son campos de investigación actualmente
abiertos.
5. Falta de soporte formal. Por otro lado, la POC también se encuentra con otro
reto añadido, como es la dificultad que encuentran los métodos formales para
trabajar con sus peculiaridades, como puede ser la composición tarda, el
polimorfismo o la evolución de los componentes.
6. El problema de la clase base frágil (FBCP). Este problema ocurre cuando la
superclase de una clase sufre modificaciones. El FBCP existe a dos niveles,
sintáctico y semántico. A nivel sintáctico ocurre cuando las modificaciones de la
superclase son puramente a este nivel, como por ejemplo sucede cuando se
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

añade un método a una superclase, lo que en teoría deberá obligar a recompilar


todas sus clases hijas. El FBCP a nivel semántico ocurre cuando lo que se altera
es la implementación de los métodos de la superclase, lo que puede llevar a que
el comportamiento de las clases hijas se altere sustancialmente [Mikhajlov y
Sekerinski, 1998].
7. Asíncrona y carreras de eventos. En los sistemas abiertos y distribuidos, los
tiempos de comunicación no están acotados inicialmente, ni se pueden despreciar
los retrasos en las comunicaciones.
8. Interoperabilidad. Actualmente, los contratos de los componentes se reducen a
la definición de sus interfaces a nivel sintáctico, y la interoperabilidad se reduce a
la comprobación de los nombres y perfiles de los métodos.

Componentes e interfaces
Las interfaces de un componente determinan tanto las operaciones que el
componente implementa como las que precisa utilizar de otros componentes
durante su ejecución. En los modelos de componentes habituales cada interfaz va
a venir determinada por el conjunto de atributos y métodos públicos que el
componente implementa, y por el conjunto de eventos que emite. Los eventos
especifican la forma en la que el componente notifica al exterior una respuesta a
un estímulo externo o bien una cambio en una condición interna (p.e. la
modificación del estado de una variable). En la interfaz de un componente se
especifica tanto la signatura del evento como la condición que hace que ´este se
produzca, pero sin indicar ni el consumidor del evento ni la forma en la que se ha
de tratar, por ser detalles que el componente ni puede, ni quiere conocer.

Contenedores
Los componentes suelen existir y cooperar dentro de contenedores, entidades
software que permiten contener a otras entidades, proporcionando un entorno
compartido de interacción. Se aplica sobre todo para objetos y componentes
visuales, que contienen a su vez a otros objetos visuales. Por ejemplo, un control
ActiveX puede ser un contenedor de otros controles ActiveX.
Normalmente la relación entre los componentes y sus contenedores se establece
mediante eventos.

Meta-información
Los nuevos estándares de componentes ya especifican el tipo de información que
un componente debe hacer pública sobre sí mismo y sobre sus propiedades. Esa
meta-información es la que permite a los contenedores, entornos y herramientas
de desarrollo, y a otros componentes descubrir la funcionalidad que ofrece un
componente, y poder manipularlo. A la acción de examinar la meta-información de
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

un componente se le denomina inspección, y puede ser tanto estática, en tiempo


de diseño, como dinámica, en tiempo de ejecución.

Desarrollo de software basado en componentes

La disciplina de los “sistemas distribuidos y abiertos” empezó a ser reconocida


ampliamente desde hace relativamente poco tiempo. En la década de los 90, los
ingenieros encargados de desarrollar y de mantener los grandes sistemas de
información de la empresa, ven la necesidad de escalar y ampliar sus sistemas
para dar cobertura ya no solo al personal interno de una sección, de un
departamento o de una organización, sino también para dar servicio a otros
miembros de la organización ubicados en diferentes localizaciones geográficas, y
como no, a otros miembros externos a la organización.

El concepto más importante que ha cambiado y sigue cambiando los procesos de


ingeniería y reingeniería, es el concepto de “componente”. Inicialmente este
concepto surge ante la necesidad de reutilizar partes o módulos software existente
que podían ser utilizadas para la generación de nuevas extensiones de las
aplicaciones, o para la generación de aplicaciones completas. Pero esto suponía
un gran esfuerzo, pues había que localizar estas partes reutilizables y
almacenarlas en repositorios especiales que más tarde pudieran ser consultadas
en fase de diseño.

Con el término componente se empieza a diferenciar dos estilos de desarrollo de


software. Desarrollo ascendente vs. descendente Por un lado está el estilo de
desarrollo de software basado en reutilización, donde las 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 reutilización,
donde se ponen en práctica procesos de ingeniería para la elaboración de partes
eficientes de software que luego pueden ser utilizadas para la construcción de
aplicaciones (en el otro estilo de desarrollo de software). A estas partes software
se las conoce como componentes software, y han dado lugar a los paradigmas de
programación de componentes top-down o descendente (para reutilizar) y bottom-
up o ascendente (basado en reutilización). Pero el uso generalizado de los
componentes en procesos de ingeniería de software Modelos de objetos
distribuidos realmente empieza a tomar presencia y sentido con la aparición de
nuevos modelos de distribución, como CORBA, DCOM o EJB, modelos que
actualmente se están utilizando para el desarrollo de aplicaciones distribuidas.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

La tendencia en los procesos de ingeniería del software para el desarrollo de


sistemas abiertos y distribuidos, es elaborar sistemas colaborativos compuestos
de subsistemas, componentes y objetos especializados y coordinados para ofrecer
servicios. En este sentido, están empezando a distinguirse distintas subdisciplinas
de la ingeniería del software conocidas como “ingenierías basadas” o “ingenierías
orientadas”, como por ejemplo la ingeniería del software basada en aspectos
(Aspect-Based Software Engineering, ABSE), la ingeniería del software orientada
a objetos (Object-Oriented Software Engineering, OOSE), la ingeniería del
software basada en conocimiento (Knowledge-Based Software Engineering,
KBSE), o la ingeniería del software basada en componentes (Component-Based
Software Engineering, CBSE), entre otros.

Los componentes software surgen en cierta medida de la necesidad de hacer un


uso correcto de software reutilizable para la construcción de aplicaciones software
mediante el ensamblaje de partes ya existentes. De hecho, etimológicamente
hablando, el término “componente” procede de la palabra cumponere, que en latín
significa cum “junto” y ponere “poner”. Desde el punto de vista de la ingeniería del
software, el término “componente” procede de las “técnicas orientadas a objetos”,
de los problemas de descomposición usados en “técnicas de descomposición de
problemas”, y de su necesidad para desarrollar sistemas abiertos. Con la aparición
de los modelos de componentes COM, EJB y CCM, en pocos años ha ido
emergiendo una práctica de desarrollo basada en componentes. Sin embargo, su
expansión se ha visto ralentizada por la falta de acuerdo entre los especialistas, a
la hora de dar una definición concreta sobre lo que es y no es un componente
software

Un componente es una unidad binaria de composición de aplicaciones software,


que posee un conjunto de interfaces 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. Las nociones de
“instanciación”, “identidad” y “encapsulación” son más propias de los objetos que
de los componentes, y define un objeto como: “Una unidad de instanciación que
tiene una única identidad, un estado que puede ser persistente, y que encapsula
su estado y comportamiento”. Sin embargo, un componente puede contener
múltiples objetos, clases y otros componentes.

Una práctica generalizada en un proyecto software es utilizar partes software ya


desarrolladas en proyectos previos o adquiridos por terceras partes. Esta cultura
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

de reutilización es esencial en casi todas las organizaciones que desarrollan


software.

La selección de componentes es un proceso que determina qué componentes ya


desarrollados pueden ser utilizados. Existen dos fases en la selección de
componentes: la fase de búsqueda y la fase de evaluación. En la fase de
búsqueda se identifican las propiedades de un componente, como por ejemplo, la
funcionalidad del componente (qué servicios proporciona) y otros aspectos
relativos a la interfaz de un componente (como el uso de estándares), aspectos de
calidad que son difíciles de aislar9 y aspectos no técnicos, como la cuota de
mercado de un vendedor o el grado de madurez del componente dentro de la
organización. Sin embargo, la fase de búsqueda es un proceso tedioso, donde hay
mucha información difícil de cuantificar, y en algunos casos, difícil de obtener.

Para “ensamblar” los componentes en el sistema existe una infraestructura bien


definida (conocida como middleware), la cual puede estar basada en diferentes
estilos. Los más conocidos son el bus de mensajes MOM (Message-Oriented
Middleware) y la tecnología ORB (Object Request Broker). Message-Oriented
Middleware (MOM) La tecnología MOM es una infraestructura cliente/servidor que
mejora la interoperabilidad, portabilidad y flexibilidad de los componentes de una
aplicación permitiendo que esta sea distribuida en múltiples plataformas
heterogéneas.

DSBC es un paradigma para desarrollar software, donde todos los artefactos


(desde el código ejecutable hasta los modelos de especificación de interfaces,
arquitecturas y modelos de negocio) pueden ser construidos mediante el
ensamblaje, la adaptación y la instalación de todos ellos juntos y en una variedad
de configuraciones. Sin embargo, esto no sería posible sin un comportamiento
claro y completamente especificado de los componentes. Un componente software
requiere de información de especificación para los usuarios y los implementadores
del módulo. En el contexto de reutilización del software, la especificación ayuda a
determinar si un módulo puede satisfacer las necesidades de un nuevo sistema.

Un componente software puede quedar identificado por medio de una o más


interfaces. Tradicionalmente a las interfaces se las conocían con el nombre de API
(Application Programming Interface). Una interfaz es: “una abstracción de un
servicio, que define las operaciones proporcionadas por dicho servicio, pero no
sus implementaciones”. En términos de objetos, una interfaz puede contener
también un conjunto de “atributos”, además de las operaciones proporcionadas.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Además de la información sintáctica para las interfaces del componente y de la


información semántica para el comportamiento de las operaciones de las
interfaces, se ha visto que también es necesaria otro tipo de información
semántica que concierne al orden en el que deben ser llamadas las operaciones
de las interfaces de un componente. A esta información semántica se la conoce
con el nombre de “protocolos” de interacción (también llamada “coreografía”).

La reutilización de software ha venido siendo una práctica común para la


construcción de productos software. La reducción de los costes, tiempos y
esfuerzos en los procesos de elaboración han sido algunos de los motivos que
han llevado a los ingenieros de software a considerar técnicas para la reutilización
de partes software en prácticamente cualquier fase del ciclo de vida del producto
(análisis, diseño e implementación).

El término COTS, como sucede con muchos otros términos en el campo de la


informática (como por ejemplo Internet), surge desde el Ministerio de Defensa de
los Estados Unidos. Históricamente hablando, el término COTS se remonta al
primer lustro de los años 90, cuando en Junio de 1994 el Secretario de Defensa
americano, William Perry, ordenó hacer el máximo uso posible de especificaciones
y estándares comerciales en la adquisición de productos (hardware y software)
para el Ministerio de Defensa.

El uso que se hace de la definición de componente COTS conlleva una serie de


limitaciones. En primer lugar, aunque es cierto que desde 1994 se están utilizando
prácticas para la utilización de componentes comerciales en procesos de
desarrollo, la realidad es que muchas organizaciones encuentran que el uso de
componentes COTS conlleva un alto riesgo y esfuerzo de desarrollo, y para
controlar su evolución y mantenimiento dentro del sistema.

La reutilización de componentes de software es un proceso inspirado en la manera


en que se producen y ensamblan componentes en la ingeniería de sistemas
físicos. La aplicación de este concepto al desarrollo de software no es nueva.

Existen variadas definiciones del termino reutilización de software. Algunas de


estas definiciones son las siguientes:

 La reutilización es un enfoque de desarrollo que trata de maximizar el uso


recurrente de componentes de software existentes.
 La reutilización de software es el proceso de crear sistemas de software a
partir de software existente, en lugar de desarrollarlo desde el comienzo.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

 La reutilización de software es el proceso de implementar o actualizar


sistemas de software usando activos de software existentes.

ACTIVOS REUTILIZABLES Y COMPONENTES DE SOFTWARE

Unas de las características más importantes de los componentes deben satisfacer


como mínimo el siguiente conjunto de características:

 Identificable.
 Accesible solo a través de su interfaz.
 Sus servicios son invariantes.
 Documentado.
 Genérico.
 Auto contenido.
 Mantenido.
 Independiente de la plataforma (hardware y sistema operativo), del
lenguaje de programación y de las herramientas de desarrollo.
 Puede ser reutilizado dinámicamente.
 Certificado.
 Accedido uniformemente sin importar su localidad

LA INTERFAZ DE UN COMPONENTE

La interfaz de un componente

Una interfaz define el conjunto de operaciones que un componente puede realizar;


estas operaciones son llamadas también servicios o responsabilidades. La
interfaces provee un mecanismo para interconectar componentes y controlar las
dependencias entre ellos.

Es útil diferenciar los tipos de propiedades de los componentes, define cuatro tipos
de propiedades relacionadas con:

 Sintaxis.
 Comportamiento.
 Sincronización.
 Calidad de servicio.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

FRAMEWORKS Y MODELOS DE COMPONENTES

Los modelos de componentes especifican las reglas de diseño que deben


obedecer los componentes. Estas reglas de diseño mejoran la composición,
aseguran que las calidades de servicio se logren en todo el sistema, y que los
componentes se puedan desplegar fácilmente tanto en entornos de desarrollo
como de producción.

Los modelos de componentes imponen estándares y convenciones sobre:

 Tipos de componentes.
 Esquemas de interacción.
 Asociación (bindings) de recursos.

MECANISMOS DE COMPOSICION DE SOFTWARE.

Bajo el modelo de desarrollo de software basado en componentes, las nuevas


aplicaciones se construyen mediante la integración o composición de
componentes. El proceso de construir aplicaciones mediante la interconexión de
componentes de software a través de sus interfaces (de composición). Nótese que
se hace especial énfasis en las interfaces como elementos fundamentales para
lograr la composición de componentes.

La composición puede concebirse como una relación cliente-servidor entre dos


componentes. El componente cliente solicita un servicio (operación) del
componente servidor, el cual ejecuta la operación solicitada y devuelve los
resultados al cliente. El servidor produce un resultado que es consumido por el
cliente.

Existen tres clases principales de interacción en los sistemas basados en


componentes

 Componente- Componente (C-C)


 Componente- Framework (C-F)
 Framework- Framework (F-F)
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

EL PROCESO DE DESARROLLO

Las preguntas que se intentan responder en esta sección son: ¿Cómo se


desarrolla un componente? Y ¿Cómo se crea una aplicación que reutilice
componentes existentes?

Clasifica los procesos de desarrollo de software basados en la reutilización de


componentes en dos categorías:

1.- Desarrollo de componentes.

2.- Desarrollo de software con reutilización de componentes.

Un modelo alternativo al modelo de ingeniería de aplicaciones es el modelo


WATCH. Este modelo combina los procesos más relevantes de la ingeniería de
software orientada a objetos con el modelo de ingeniería de aplicaciones del ciclo
de vida gemelo. Una característica importante de este modelo es la integración de
los procesos gerenciales con los procesos técnicos del desarrollo de software
basado en componentes. Esta integración facilita la labor del líder del proyecto, al
describir como se debe llevar a cabo una gestión del proyecto integrada a los
procesos técnicos del desarrollo de software.

La fase de diseño del sistema establece y describe la arquitectura del software.


Describe cada uno de los componentes que requieren tal estructura y cómo esos
componentes se interconectan para interactuar. El grupo de desarrollo debe, a
partir de esta arquitectura, determinar cuáles componentes se pueden reutilizar y
cuáles requieren ser desarrollados en su totalidad. Los componentes reutilizados
deben ser adaptados, para satisfacer los requerimientos del sistema; mientras que
los componentes nuevos, deben ser diseñados, codificados y probados
separadamente durante la fase de Implementación.

Las Pruebas del sistema permiten detectar errores en la integración de los


componentes. Finalmente, la fase de Entrega se encarga de la instalación,
adiestramiento de usuarios y puesta en operación del sistema.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Aspectos de Calidad en el Desarrollo de Software Basado en Componentes

La creciente necesidad de realizar sistemas complejos en cortos periodos de


tiempo, a la vez que con menores esfuerzos tanto humanos como económicos,
está favoreciendo el avance de lo que se conoce como Desarrollo de Software
Basado en Componentes (DSBC). Esta nueva disciplina se apoya en
componentes software ya desarrollados, que son combinados adecuadamente
para satisfacer los requisitos del sistema. Construir una aplicación se convierte por
tanto en la búsqueda y ensamblaje de piezas prefabricadas, desarrolladas en su
mayoría por terceras casas, y cuyo código no puede modificarse. Bajo este nuevo
planteamiento, cobran especial interés los procesos de búsqueda y selección de
los componentes apropiados para construir las aplicaciones.

El desarrollo basado en componentes es un avance significativo hacia la


construcción de sistemas mediante el ensamblado de componentes prefabricados.
El DSBC trata de sentar las bases para el diseño y desarrollo de aplicaciones
distribuidas basadas en componentes software reutilizables. Dicha disciplina
cuenta actualmente con un creciente interés, tanto desde el punto de vista
académico como desde la industria, en donde la demanda de mecanismos y
herramientas de desarrollo basados en componentes es cada día mayor.

En general, el desarrollo de software basado en componentes puede verse como


una extensión natural de la programación orienta a objetos dentro del ámbito de
los sistemas abiertos y distribuidos. Este paradigma se basa en el uso de los
componentes software como entidades básicas del modelo, entendiendo por
componente “una unidad de composición de aplicaciones software que posee 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”.

Una de las principales ventajas del desarrollo de software basado en componentes


se basa en la “reutilización” de los mismos. De esta forma, los componentes se
diseñan y desarrollan con el objetivo de poder ser reutilizados en otras
aplicaciones, reduciendo el tiempo de desarrollo, mejorando la fiabilidad del
producto final (al usar componentes ya probados previamente), y siendo más
competitivos en costes. Aunque hasta ahora la reutilización suele suceder
principalmente a nivel interno dentro de las organizaciones, el uso de los
componentes comerciales comienza a extenderse.

De esta forma se habla de componentes COTS (Commercial-Off-The-Shelf), que


han sido definidos como una clase especial de componentes software,
normalmente de grano grueso, que presentan las siguientes características:
 Son vendidos o licenciados al público en general
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

 Los mantiene y actualiza el propio vendedor, quien conserva los derechos


de la propiedad intelectual
 Están disponibles en forma de múltiples copias, todas idénticas entre sí
 Su código no puede ser modificado por el usuario

Es importante señalar que un factor imprescindible en todas esas tareas es la


documentación de los componentes, pues es preciso contar con especificaciones
completas, concisas y precisas de los componentes para poder llevarlas a cabo.
La mayoría de las propuestas existentes para documentar componentes se basan
en el uso de interfaces, los cuales proporcionan un mecanismo para describir la
funcionalidad de los componentes.

La palabra calidad tiene varios significados, aunque dentro de la Ingeniería del


Software podemos adoptar la definición de la norma ISO-8402, que luego se repite
en otras (por ejemplo en ISO-14598): “La totalidad de aspectos y características
de un producto o servicio que tienen que ver con su habilidad para satisfacer las
necesidades declaradas o implícitas”.

En general, no existe un consenso a la hora de definir y clasificar las


características de calidad que debe presentar un producto software. Por tanto,
utilizaremos los estándares internacionales, fundamentalmente el ISO-9126.
Aunque actualmente en proceso de revisión, ha sido el primero en definir y
concretar este tipo de características.
Siguiendo su terminología, entendemos por característica de calidad de un
producto software a un conjunto de propiedades mediante las cuales se evalúa y
describe su calidad.
Una característica se puede refinar en múltiples niveles de sub-características.
Ejemplos de características son la funcionalidad, la fiabilidad o la facilidad de uso.
A su vez, la característica funcionalidad se puede descomponer en sub-
características como corrección, interoperabilidad y seguridad, entre otras.

Para los componentes, y teniendo en cuenta como posible objetivo la definición de


un modelo de calidad específico, es fundamental primero realizar una taxonomía,
tratando de clasificar las características de calidad de acuerdo a su naturaleza y a
distintos parámetros que intervienen en su medida.

Es importante señalar que, además de las características de calidad en un


componente, hay otro conjunto de características no relacionadas directamente
con la calidad como pueden ser el precio, la asistencia técnica, las condiciones de
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

licencia, etc., que también son necesarias a la hora de valorar el componente más
adecuado.

Bosch muestra la dificultad de especificar con detalle los requisitos de calidad,


pero sí encuentra que los requisitos más importantes en la mayoría de las
propuestas existentes presentan alguna forma de lo que denomina perfil (profile).
Un perfil es un conjunto de escenarios, generalmente con alguna relativa
importancia relacionada con cada escenario.

El proceso de construcción de un producto software basado en componentes


adquiere unas especiales características como se ha mencionado anteriormente.
Entre los trabajos que tratan de forma directa el proceso de desarrollo basado en
componentes nos parecen de especial interés los que comentamos a
continuación.

Boehm y sus colaboradores han extendido al ámbito de los componentes COTS el


modelo general COCOMO II de estimación del coste (y esfuerzo) de un proyecto
software. Este nuevo modelo para componentes se ha denominado COCOTS
(Constructive COTS). El modelo se compone de cuatro submodelos que recogen
las cuatro principales fuentes de los costes de integración de componentes COTS:

 Valoración (Assessment) es el proceso mediante el cual los componentes


COTS son seleccionados para ser integrados en el sistema que se está
desarrollando.
 Adaptación (Tailoring) se refiere a las actividades que siempre hay que
realizar para particularizar el componente, independientemente del producto
donde se va a integrar.
 Por ejemplo, inicializar los valores de los parámetros, especificar pantallas
de E/S o formato de los informes, configurar protocolos de seguridad, etc.
 Código de Integración (Glue Code) es el código nuevo que hay que
desarrollar y probar, externo a los COTS, pero necesario para integrar los
componentes COTS en un sistema.
 Finalmente, la volatilidad (Volatility) tiene en cuenta la frecuencia con la cual
aparecen en el mercado nuevas versiones o actualizaciones de los
componentes COTS que se están utilizando en el sistema durante su
desarrollo y puesta en funcionamiento.

El método OTSO desarrollado por Kontio establece un proceso de selección de


“paquetes” de software reutilizables, denominados por los autores como OTS (Off-
The-Shelf) pues incluyen tanto componentes comerciales (COTS) como
componentes desarrollados internamente por las propias organizaciones. El
método OTSO facilita la búsqueda, evaluación y selección de software reutilizable.
Además, proporciona técnicas específicas para la definición de criterios de
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

evaluación, comparando los beneficios y costes de cada una de las alternativas


posibles, y consolidando los resultados de la evaluación que faciliten la toma de
decisiones.
Tópicos Avanzados de Programación
Horario: 9:00-10:00
Aula: 7SA
Actividad: Ensayo
Autores: Espinoza Olea Saúl, García Atilano Jesús, Castro Santos Eduardo

Conclusión

La programación orientada a componentes como rama de la ingeniera es otra


forma de programar que se deslinda de la programación orientada a objetos este
tipo de programación pretende junto a la ingeniería de software diseñar y construir
aplicaciones más complejas para el mundo actual en el que vivimos de mejor
entendimiento y mayor funcionalidad.
El desarrollo de software basado de componentes se convirtió en el pilar de la
Revolución Industrial del Software y se proyecta hoy en día en diversas nuevas
formas de hacer software de calidad con los costos más bajos del mercado y en
tiempos que antes eran impensables. Empresas como Microsoft entendieron el
potencial de esta metodología hace años y hoy nos ofrecen nuevas iniciativas y
herramientas que buscan llevar al proceso de construcción de software hacia el
sitial privilegiado en el que debió colocarse desde un principio.
La reutilización de software está ocasionando un cambio acelerado en la manera
en que la industria de software desarrolla sus productos. Los componentes de
software reutilizables constituyen las unidades fundamentales para el desarrollo de
nuevas aplicaciones. Se ha hecho un intento por destacar la importancia y
caracterizar el proceso de desarrollo de software basado en la reutilización de
componentes. Se estableció una comparación entre los conceptos de activos
reutilizables y componentes de software. Se describieron las características
requeridas y deseables de un componente de software para su reutilización.
Adicionalmente, se describieron los conceptos de interfaz, modelo y framework de
componentes, así como también mecanismos de composición de software. Se
discutieron algunos de los aspectos metodológicos que rigen el desarrollo de
componentes y de aplicaciones basadas en la reutilización de componentes.
No existe actualmente un tratamiento lo suficientemente exhaustivo y consolidado
de estos temas de calidad, a pesar de su gran importancia. Probablemente esto
sea debido tanto a la reciente implantación de la tecnología de componentes
software y al incipiente uso industrial de los componentes COTS, como a las
fuertes implicaciones comerciales y de marketing que conllevan los aspectos de
calidad en los componentes software.

Vous aimerez peut-être aussi