Lenguajes de desarrollo de componentes
2. Comparativa con lenguajes orientados a objetos
3. Lenguajes orientados a componentes
Una de las primeras decisiones que deben tomarse en el proceso de desarrollo de aplicaciones de software es evaluar si es necesario desarrollar todo el software al completo o, por el contrario, si es posible construir la aplicación a partir de componentes existentes.
La creación de una aplicación desde cero solo está justificada, en todo caso, cuando las ventajas que puede ofrecer dicha solución son muy superiores a las alternativas ya disponibles.
El coste que puede tener la creación de una aplicación completa es muy superior al asociado al uso de componentes ya existentes. Por otra parte, hay que tener en cuenta que el tiempo exigido para elaborar una solución de este tipo es de tal magnitud, que un gran porcentaje de aplicaciones suele quedarse obsoleta en el propio proceso de fabricación, aparte del riesgo real de abandono, ya sea total o, en algunos casos, parcial (para, así, recuperar al menos parte de la inversión destinada) del proyecto, que suele suceder en el desarrollo de grandes aplicaciones corporativas, habitualmente causado por problemas de interoperabilidad con otros componentes existentes en la organización a la que va destinada la aplicación.
En este sentido, la mejor fórmula es crear soluciones basadas en ensamblar componentes independientes de software estándar. Una solución de este tipo, que inicialmente no aporta, al usar software preexistente, grandes cambios disruptivos, sí que favorece una evolución constante y controlada de la aplicación creada como una solución específica a una necesidad de la organización a la que va destinada dicha aplicación.
En este tipo de soluciones, es más sencillo, por ejemplo, calcular el tiempo necesario y los costes asociados para el proyecto, y el cumplimiento de estándares es más fácil de implementar. Hay que tener muy en cuenta que, como el mantenimiento del módulo o los módulos, son, en todo caso, tarea del proveedor, los costes de mantenimiento se reducen drásticamente.
Es habitual, al hablar de lenguajes de desarrollo de componentes, que se establezca cierto paralelismo con el paradigma de la orientación a objetos y que esto ocasione ciertas confusiones. Esto es debido, fundamentalmente, a que en el desarrollo de componentes se usan conceptos, metodologías, estándares, modelos de diseño, etc., muy similares a los usados en la programación orientada a objetos. Por este motivo, es necesario realizar una descripción tanto del elemento componente como del objeto, para comprender sus características comunes y sus diferencias.
El lenguaje de desarrollo de componentes se basa en el uso de componentes preexistentes reutilizables con interfaces bien definidas para comunicarse entre ellos.
El nivel de abstracción del componente es más alto que el de los objetos, ya que un objeto, como instanciación de una clase, posee características propias como su estado y las operaciones que se pueden realizar con él, mientras que un componente no se puede implementar parcialmente y se trata de una unidad independiente, cuyo funcionamiento interno no es observable desde el exterior (o al menos es trivial) a modo de caja negra. Un componente se puede considerar como una extensión de la orientación a objetos.
Para poder realizar una comparativa con los lenguajes orientados a objetos, es necesario primero aproximarse al elemento fundamental de ambos paradigmas y describirlos de un modo más exhaustivo.
En la orientación a objetos, se define una plantilla que contendrá un conjunto de estados posibles que puede tener un elemento de su tipo. Este elemento es lo que se denomina clase.
Cuando se necesita usar una clase, se definen los valores o estados de dicha plantilla para un elemento determinado. El uso de esta clase, en ese caso, es una instanciación de dicha clase y el elemento que posee dichos estados es el objeto. Una clase puede ser instanciada tantas veces como sea necesario, creando, así, diferentes objetos de la misma clase.
Un objeto es una unidad de instanciación de una clase con una identidad única, que puede tener propiedades observables (externamente y de forma unitaria), y un conjunto de operaciones. Los estados, que son los valores que toman las propiedades en un instante determinado, pueden ser modificados dinámicamente en función de la ejecución de sus operaciones.
Según C. Szyperski (Component Software. Beyond Object Oriented Programming, 1998), un componente es:
[…] 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.
Igualmente, Meyer (Seven Criteria Definition, 1999), propone una lista de siete criterios para definir un componente:
1. Puede ser usado por otro elemento de software.
2. Debe ser usado por clientes sin necesidad de la intervención del desarrollador del componente.
3. Incluye especificaciones de todas las dependencias.
4. Incluye especificaciones de las funcionalidades que ofrece.
5. Es posible usarlo teniendo únicamente como base sus especificaciones.
6. Se puede acoplar a otros componentes.
7. Se puede integrar en un sistema de forma rápida y sencilla.
Cada unidad de implementación, en este caso, debe ser autocontenida, independiente, creada por terceras partes, con especificaciones claras de requerimientos, que interaccione con otros componentes a través de interfaces bien definidas, y que no cuente con estados observables desde el exterior.
Un componente, entonces, es una unidad que posee un peso específico dentro de la aplicación, que no puede ser instanciado al existir una única copia, que no puede ser implementado parcialmente y, sobre todo, desarrollado bajo la filosofía de reusabilidad llevada al extremo.
Nota
Según esta definición, un componente puede contener clases (o no), pero también puede ser desarrollado a través del paradigma de programación funcional o, en todo caso, cualquier otro enfoque, ya que, al tener un comportamiento de tipo caja negra, lo importante son sus requerimientos y las especificaciones de las interfaces de comunicación entre ellos, lo que se denomina el contrato de especificación, que establece los criterios funcionales (protocolos de operaciones de la interfaz) y no funcionales (seguridad, calidad de servicio o prestaciones) de uso.
De modo general, una cuestión a tener muy en cuenta, que diferencia la POO (Programación Orientada a Objetos) de la POC (Programación Orientada a Componentes), es sobre las actualizaciones o modificaciones que afectan al funcionamiento y rendimiento global.
En este aspecto, bajo el paradigma de la POO, si una clase de una aplicación realizada sufre cambios, será necesario realizar de nuevo gran parte del proceso inicial de implantación de dicha clase en la aplicación (realizar pruebas unitarias y globales, recompilar la aplicación completa, revisión del comportamiento con el resto de clases relacionadas, etc.).
En el caso de sustitución de un componente o ampliación de funcionalidades, al ser modificaciones internas del propio componente, la única cuestión a tener en cuenta es que la sustitución puede realizarse aun en el caso de que la aplicación esté funcionando, siempre y cuando el componente no esté en uso en el momento del cambio.
Actividades
1. A partir de la imagen correspondiente al modelo orientado a objetos, ¿qué trascendencia tiene en el proyecto cambiar el tamaño y tipo de datos de los ítems del menú? ¿En cuántos sitios del proyecto se puede ver afectado?
2. A partir de la imagen correspondiente al modelo orientado a componentes, ¿qué trascendencia tiene en este caso incluir un modulo de pasarela de pago en el esquema? ¿Qué sucedería en el caso de tener que desarrollar el componente mediante POO?
Sobre aspectos mercadotécnicos, el componente es un elemento distribuible, empaquetable y realizado bajo estándares de funcionamiento y uso. En el caso de un objeto, solo es utilizable bajo las condiciones para las que fue creado.
El software COTS (Commercial Off The Shelf) es un mercado de componentes creado y comercializado por terceras personas (3rd Party).
Sabía que…
Actualmente, dos de los mayores mercados de COTS se pueden encontrar en:
Los componentes creados así pueden ser vendidos, alquilados o cedidos y licenciados al público en general. Las ventajas más interesantes propuestas por este mercado son:
1. El nivel de seguridad de este software es mayor que el creado desde cero y está provisto desde el proveedor de la aplicación y en función de estándares del mercado.
2. La documentación necesaria para el uso del software COTS viene incluida en la distribución, lo que reduce significativamente el coste de mantenimiento.
3. Cualquier componente de software que se introduce en este mercado es, por propia definición, de mayor calidad que cualquier desarrollo unitario, ya que entra en un mercado competitivo en el que debe destacar sobre el resto.
4. El software desarrollado es más completo, al ser fabricado por empresas especialistas de la propia industria.
5. La demanda de componentes y funcionalidades de estos por parte de los clientes favorece su desarrollo por parte de la industria, para adaptarse a dichas demandas.
6. Esta demanda hace que todos los componentes deban ser habitualmente revisados y actualizados.
7. Como se dispone de la posibilidad de escoger los componentes necesarios desde un primer momento, el tiempo de desarrollo está mucho más controlado, el cálculo de los costes es más fiable y está más garantizado el cumplimiento de los plazos de desarrollo. Por esto mismo, el coste de las aplicaciones desplegadas se ve reducido.
Actividades
3. Realice una comparativa de las siete ventajas que propone el software COTS sobre la POO. Razone cada ítem.
Partiendo de una situación en la que se precisa un componente que permita integrar un entorno de gestión de servicios de e-mails corporativos en una intranet para Microsoft SharePoint (plataforma de colaboración empresarial que provee Microsoft para acceder a espacios compartidos, almacenes de información y documentos, todo accesible a través de un explorador web), ¿qué criterios serían exigibles a dicho componente, teniendo como base los siete criterios de Meyer?
Solución
Los criterios exigibles serían los siguientes:
1. Puede ser usado por otro elemento de software. Se trata de un componente que estará integrado en una aplicación (Add-In), por lo que este requisito es indispensable en todo caso. El sistema en el que se integrará es una aplicación de Microsoft, por lo que una de las primeras cosas que hay que comprobar es su compatibilidad respecto a las versiones de SharePoint sobre las que debe trabajar y que su desarrollo esté implementado bajo las especificaciones COM. Se puede comprobar, en todo caso, si usa el framework de .NET (en función de las versiones de SharePoint, estarán también las de .NET).
2. Debe ser usado por clientes sin necesidad de la intervención del desarrollador del componente. Se trata de un componente que estará integrado dentro de la aplicación y aporta una interfaz familiar para la gestión de e-mails, por lo que, en este sentido, funciona de forma autónoma. Sería importante asegurar la integración con el resto de componentes del sistema SharePoint, para que su comportamiento sea transparente al usuario.
3. Incluye especificaciones de todas las dependencias. Se trata, en todo caso, de integrar un plugin para SharePoint, por lo que necesita a este como contenedor. En el sistema deben existir, como mínimo, especificaciones referentes a las dependencias con los módulos correspondientes de SharePoint para las siguientes funcionalidades:
4. Incluye especificaciones de las funcionalidades que ofrece. Debe incorporar especificaciones de funcionalidades específicas para la manipulación y almacenamiento local o en servicios de Internet para e-mails, así como un TINY editor mínimo para los mensajes, acceso a agenda de contactos corporativos y posibilidad de manipular archivos adjuntos. Debe comprobarse la compatibilidad e integración con el resto de componentes del sistema, tanto SharePoint como la versión Windows del sistema operativo en el que se integre.
5. Es posible usarlo teniendo únicamente como base sus especificaciones. Aquí se especifica si es posible usarlo desde el punto de vista del desarrollador. Como requisito indispensable, será necesario que aparezcan estas especificaciones incluidas en el paquete del producto como forma de contrato de especificaciones y requerimientos. Este componente debe contemplar la posibilidad de activar, desactivar, instalar y desinstalar.
Esto es totalmente independiente de las propias especificaciones del producto en lo que se refiere a sus características sobre usabilidad y accesibilidad, a nivel de usuario final. También, dentro del producto SharePoint, será necesario integrar un sistema que permita su activación/desactivación para el usuario del componente.
6. Se puede acoplar a otros componentes. Al tratarse de un Add-In integrable en un contenedor genérico para aplicaciones SharePoint, se debe acoplar a otros componentes que pertenezcan a cualquiera de los contenedores descritos en dicho apartado.
El nuevo componente que se agrega a SharePoint deberá ceñirse lo máximo posible a los requerimientos de software y hardware de la versión de Microsoft SharePoint que se esté utilizando.
Habrá que tener también en cuenta las necesidades, a nivel de sistema operativo, tanto sobre permisos como los servicios que será necesario que corran en el sistema como soporte a la aplicación.
7. Se puede integrar en un sistema de forma rápida y sencilla. El proceso de integración deseado sería a través de una actualización local del sistema. El paquete de instalación msi podría estar disponible a través de la red corporativa e instalarse intencionadamente, para los casos en que se precise actualizar algún componente más para que la integración sea absoluta.
La idea fundamental de la programación orientada a componentes es crear un sistema global de componentes de software, en el que sus usuarios son los desarrolladores de sus propias aplicaciones, a partir de componentes ya construidos y probados, de modo que ese desarrollo sea rápido y robusto.
Se trata de un paradigma de la programación centrado en el diseño e implementación de componentes, aplicando, en concreto, los conceptos de encapsulación, polimorfismo, composición tardía y seguridad.
Recuerde
La entidad básica de la programación orientada a componentes son los propios componentes; cajas negras que encapsulan determinadas funcionalidades y que se deben diseñar buscando la máxima reutilización posible; deben poderse implementar en cualquier sistema. Para ello, los servicios de estos componentes deben ser bien conocidos a través de sus interfaces y requisitos de funcionalidad.
Existe una serie de conceptos importantes a tener en cuenta sobre la programación orientada a componentes, entre los cuales cabe destacar:
Una interfaz, desde el punto de vista de la programación orientada a componentes, es una colección o conjunto de operaciones que se utiliza para especificar un servicio de un componente.
Importante
La interfaz es el elemento que, conceptualmente, determina las operaciones que debe implementar un componente y especifica las que necesita de otros componentes del sistema.
Desde este punto de vista, se puede decir que una interfaz es un contrato entre un cliente y un suministrador de software. En esta situación, un componente implementa una o varias interfaces y, a su vez, puede usar otras interfaces con otros componentes. Un mismo componente puede tener diferentes interfaces, ya sean estas en forma de peticiones de diferentes servicios o de varias peticiones del mismo servicio. Estos servicios pueden ser:
Definición
Interfaces
Desde el punto de vista de la programación orientada a objetos, son los métodos y atributos públicos que implementa el componente, y los eventos que este envía.
En el caso de que se necesite implementar algún cambio en algún componente, las especificaciones de las interfaces garantizan que el llamado “efecto onda” sea nulo o mínimo.
Importante
Las interfaces proveen de un sistema de bajo acoplamiento entre componentes que posibilita que los componentes puedan:
La información sobre el propio componente y sus propiedades (metadatos), que este pone a disposición del resto de elementos del sistema, es la que, finalmente, permite dar a conocer sus funcionalidades para poder manipularlo.
En el caso de que sea el propio componente el que revise sus propios metadatos (gracias a la capacidad reflexiva que se le presupone al componente), se denomina introspección. En el caso de que examine información de otros componentes, será inspección estática en el caso de que esta revisión se efectúe en tiempo de diseño, o dinámica en el caso de que la realice en tiempo de ejecución.
Las interfaces deben proveer de un sistema que permita la manipulación desde el exterior del componente de sus atributos y métodos públicos, así como capturar sus eventos.
El Lenguaje de Descripción de Interfaces o IDL (Interface Description Language), son las especificaciones que se usan para describir las interfaces implementadas entre componentes de software o entre sistemas de componentes (ya sea a modo de contenedores o de la propia solución final de software).
La principal función del IDL es describir la interfaz en un lenguaje estándar que permita la comunicación entre componentes de software, independientemente del lenguaje en que estos hayan sido creados e implementados.
Sabía que…
Para acceder a las especificaciones de ICL para OMG, hay que acudir al apartado correspondiente a ICL dentro de la web de la OMG:
Para establecer el ensamblado o composición de componentes, es necesario conocer previamente los elementos implicados en el proceso.
Modelo de componentes (framework)
Son los elementos que definen la forma que deben tener las interfaces de sus componentes.
Estos elementos son los que determinan en última instancia los mecanismos de comunicación y, en todo caso, posibilidades de composición entre diferentes componentes; especifican la forma en que se deben proveer los servicios (trading, seguridad, etc.)
Existen diferentes tecnologías de modelos de componentes estandarizadas, de las cuales las más conocidas o, en todo caso, las predominantes en el mercado son:
Actividades
4. En base a los cuatro modelos de framework propuestos, busque la página del fabricante donde se describen sus funcionalidades.
5. Realice una pequeña gráfica en la que aparezcan los componentes desarrollados en el mercado sobre cada una de las propuestas para los últimos cinco años.
6. Sobre esta gráfica, superponga otra con el número de aplicaciones desarrolladas con los componentes de dichas tecnologías.
Plataformas de componentes
Una vez definido el modelo de componentes, se hace necesario un sistema que posibilite la implementación de los mecanismos y de los conceptos del propio modelo. Las plataformas proporcionan entornos de desarrollo y de ejecución para los componentes. Aunque inicialmente están basadas en un modelo en concreto, ofrecen pasarelas a otros modelos y plataformas.
Ejemplos de modelos de componentes pueden ser ActiveX/OLE (COM), Enterprise Bean (Java Beans) u Orbix (CORBA).
El modo de interacción entre componentes puede ser diferente en función del elemento que se precise comunicar:
Importante
Hoy en día, se usa XML como lenguaje para definir el IDL, sobre el protocolo de transferencia HTTP, para los servicios web (SOAP o XML-RCP).
Formas de composición
Son los diferentes tipos de contratos que existen para el ensamblado de componentes. Básicamente, existen seis tipos de contratos o formas de composición:
Aplicación práctica
En una nueva implementación de un sistema cuyo software va a ser desarrollado con componentes, se estudian las posibilidades que ofrecen las formas de composición disponibles.
Se va a desarrollar un editor de textos, que está formado a su vez por diferentes módulos, entre los que cabe destacar los siguientes:
Evalúe las posibles formas de composición para el modelo descrito.
Solución
Las posibles formas de composición para el modelo descrito son:
La arquitectura de componentes permite construir y probar todos los elementos, ya sea de forma independiente o globalmente, a nivel de la propia solución de software requerida. Se trata de una representación de alto nivel de la estructura de un sistema, describiendo las partes que lo componen, las interacciones entre estas, los frameworks encargados de supervisar su composición y las restricciones inherentes a dichos patrones.
La arquitectura de software de una aplicación implementada bajo el paradigma del desarrollo de componentes consiste en ensamblar diferentes componentes prefabricados y que estos proporcionen los servicios necesarios para que la solución de software que se desarrolla cumpla las especificaciones requeridas.
Nota
Bajo el prisma de este paradigma, la interfaz es el elemento fundamental, ya que se trata del elemento que interconecta los diferentes componentes necesarios para el desarrollo de la aplicación. Cada componente debe operar con independencia de sus mecanismos internos.
La reutilización o infraestructura de componentes se define dentro de los marcos de trabajo o frameworks, que, en definitiva, son el esqueleto de la aplicación que debe ser adaptado en función de las necesidades específicas de la aplicación a la que haya sido destinado. Este framework encapsula el patrón de la arquitectura.
La representación de la arquitectura se realizará como una colección de componentes y de las interacciones entre ellos. Esta arquitectura está basada en componentes y conectores; estos últimos son los encargados, en todo caso, de encapsular los patrones de coordinación y sincronización entre dichos componentes.
La llamada configuración es la estructura formada por las instancias de los componentes y sus conectores correspondientes, y de los enlaces o bindings específicos que definen cómo será la unión entre ellos. Esta estructura, que puede ser descrita mediante la arquitectura de software, forma la jerarquía de la misma.
De modo general, la arquitectura de software basado en componentes tiene como objetivos:
Sabía que…
Existen varias propuestas de modelos de arquitectura basada en componentes. El modelo inicial parte del trabajo realizado por Allen y Garlan (1994), y de este surgen nuevos trabajos como Unicon (Shaw, 1995), Aesop (Garlan, 1994 y 1995), Darwin (Magee, 1995, y Kramer, 1996) y Executable Connectors (Ducase y Richner, 1997), entre otros.
Para poder expresar la arquitectura de la aplicación, es necesario un lenguaje que cumpla unas determinadas especificaciones. El Lenguaje de Descripción de Arquitectura, ADL (Architecture Description Language), proporcionará las herramientas y, por tanto, los modelos y notaciones, que permitan describir los componentes, conectores y enlaces que forman una aplicación.
Bajo esta definición, un ADL debe:
Importante
En el proceso general de descripción de la arquitectura y una vez seleccionados los componentes, suele ser habitual realizar adaptaciones o crear extensiones para integrarlos en el sistema. Los problemas más habituales de esta fase suelen ser de tres tipos:
Se han establecido las líneas rojas que separan la programación orientada a objetos y la programación orientada a componentes. En todo caso, cada una ofrece sus ventajas e inconvenientes, en función del proyecto, su magnitud, presupuesto, urgencia, etc. Todos estos aspectos se deben tener en cuenta a la hora de escoger un paradigma u otro para la realización de cada proyecto.
Se ha abordado el estado actual del mercado COTS y se han provisto herramientas suficientes como para poder evaluar y sopesar el uso de un componente u otro en función de unos requerimientos predefinidos y teniendo en cuenta factores como el lenguaje de desarrollo, su contrato, interacciones, etc.
La herramienta de pegado de componentes, la interfaz, ha sido descrita y se han mostrado las propuestas de lenguajes que ofrecen los diferentes fabricantes de software específicos para este mercado, en todo caso los más usados e importantes (Microsoft, Oracle y OMG). Se muestra como un elemento fundamental a la hora de desarrollar un sistema o programa basado en componentes. Por ello, se describe, de forma general, cómo es el proceso de descripción de las interfaces, sus capacidades y posibilidades de ensamblado, y cómo debe ser la descripción de la arquitectura, a partir siempre de las propuestas de los fabricantes de software que predominan en el mercado.
Ejercicios de repaso y autoevaluación
1. Relacione los siguientes elementos.
2. Ejemplos de modelos de componentes pueden ser:
3. Un framework define…
4. Palabras cruzadas: complete las definiciones relacionadas con características de la programación orientada a componentes y sitúe en el crucigrama las soluciones.
5. Complete la siguiente frase.
La principal función de ___________ es describir la interfaz en un lenguaje ___________, que permita la comunicación entre ___________, independientemente del ___________ en que estos hayan sido ___________ e ___________.
6. De las siguientes afirmaciones, diga cuál es verdadera o falsa.
El lenguaje de desarrollo de componentes se basa en el diseño de componentes reutilizables con interfaces bien definidas para comunicarse entre ellos.
Un componente es un elemento distribuible, empaquetable y realizado bajo estándares de funcionamiento y uso. En el caso de un objeto, solo es utilizable bajo las condiciones para las que fue creado.
Una interfaz es un conjunto de operaciones que se utiliza para especificar un servicio de un componente.
7. Las interfaces posibilitan que los componentes sean:
8. En función del elemento que se necesite comunicar, la interacción entre componentes puede ser:
9. Una vez seleccionados los componentes, a la hora de adaptarlos o crearles extensiones, uno de los problemas que puede aparecer, como causa de incompatibilidad de interfaces, se denomina…
10. ¿Cómo se denomina el “esqueleto” de una aplicación?
11. Complete los componentes del esquema de un componente.
12. Complete la siguiente frase.
Se trata de un paradigma de la programación centrado en el _________ e implementación de __________, aplicando, en concreto, los conceptos de encapsulación, ___________, composición tardía y ___________.
13. Relacione los siguientes elementos relacionados con los tipos de contratos.
14. Complete la siguiente frase.
Un componente es una unidad de __________ de aplicaciones software que posee un conjunto de __________ y que ha de poder ser desarrollado, adquirido, __________ al sistema y __________ con otros componentes de forma __________ en tiempo y espacio.
15. Sopa de letras: busque siete modelos y plataformas de componentes.
