PROGRAMACION BASADA EN COMPONENTES Dr. Pedro Mejia Alvarez Claudia P. Garcia Zamora Samuel Garrido Daniel

1. PROGRAMACION BASADA EN COMPONENTESDr. Pedro Mejia AlvarezClaudia P. Garcia ZamoraSamuel Garrido Daniel

2. Parte 1Introducción

3. Capítulo 1: Introducción La programación basada en componentes es aquella que está basada en la implementación de sistemas utilizando componentes previamente programados y probados. Los componentes están bien definidos en todas las demás disciplinas de la ingeniería, sin embargo, debido a la propia naturaleza del software, en ésta disciplina aun no está todo completamente definido.

4. Los componentes son para composición La composición habilita cosas prefabricadas para ser reusadas posteriormente en nuevas composiciones cualesquiera. Para convertir un elemento en reusable, no es suficiente iniciar con un diseño monolítico de una solución completa y entonces particionarla en fragmentos. Las descripciones de los componentes deben estar generalizadas cuidadosamente para permitir la reusabilidad en un número suficiente de diferentes contextos.

5. Los componentes son para composición (ii) • Los componentes de software son unidades ejecutables de adquisición, implementación y producción independiente que pueden formar parte de un sistema funcional. • El requerimiento de la independencia y la forma ejecutable elimina muchas abstracciones del software; tales como declaraciones de tipo, macros de C ó plantillas de C++. Otras abstracciones, como procedimientos, clases, módulos, o aún aplicaciones enteras, pueden formar componentes, mientras estén en una forma ejecutable que sea integrable.(Motivo)

6. Hechos a la medida VS Software Estándar • El desarrollo tradicional de software se divide en dos partes: • Un proyecto desarrollado en su totalidad línea por línea • con solo la ayuda de herramientas de programación y • librerías. • Se compra software estándar y se parametriza para • proporcionar una solución que está muy cerca de ser lo • que requiere el cliente.

7. Ventajas y desventajas de: • La producción este tipo de software es una empresa muy costosa (mantenimiento). • La mayoría de los proyectos grandes fallan parcialmente o totalmente, conduciendo a un riesgo sustancial (interoperabilidad con otros sistemas locales). • En un mundo de rápidos y continuos cambios en los requerimientos de los negocios, este tipo de software es usualmente muy lento para ser productivo antes de convertirse en obsoleto. • (Si funciona) Puede ser adaptado al modelo del negocio del cliente.

8. Ventajas y desventajas de (ii): • Disminuye el riesgo. El vendedor de sw estándar busca disminuir losproblemas del mantenimiento, de la evolución del producto, y de la interoperabilidad. • Parametrización y configuración detallada entre las versiones (inevitable en un mundo de cte. cambio). • Implica una reorganización del proceso del negocio en cuestión. • Debido a que no está bajo control local, no es suficientemente apto para adaptarse rápidamente a cambios, en los requerimientos, que pudieran surgir.

9. El papel de los componentes • El concepto de componente de software representa una posible solución. Aunque cada componente comprado es un producto estandarizado, con todas las ventajas adjuntas, el proceso de ensamblar componentes ofrece la oportunidad de ser una actividad muy atractiva para el cliente. • En la solución basada en componentes, la evolución reemplaza la revolución, y la actualización individual de componentes que se requiera permite operaciones más suaves. Obviamente, se requiere un camino diferente para administrar los servicios, pero los beneficios potenciales son inmensos.

10. Los componentes son inevitables • Gran aceptación en su uso si ofrecen suficiente variedad y calidad. • Una vez satisfaciendo las necesidades de los clientes, el uso de componentes se vuelve inevitable. • Componentes no disponibles provoca la reinvención de nuevas soluciones. Justifidas solo si la solución creada es superior a la alternativa que se puede comprar. • Un producto que utiliza los beneficios de los componentes hace uso de una combinación de productividad e innovación de todos los vendedores de componentes.

11. Naturaleza del SW e implementación de entidades • Inicialmente los componentes de sw fueron considerados similares a los componentes de hw, como los CI (“CI de software”). También en Mecánica e ingeniería civil. • Sin embargo, el software es diferente a los productos de todas las demás disciplinas de ingeniería. • Es importante distinguir entre el software y sus instancias para así diferenciar entre modelos y productos (plano-edif.) • Los planos pueden ser parametrizados, aplicados recursivamente, escalados, e inicializados cualquier número de veces. Actividades no aplicables a instancias. • El SW es un metaproducto genérico que puede ser usado para crear familias enteras de instancias.

12. Componentes: Unidades de Implementación La unidad de implementación es algo más estático que un obj.; como una clase, o un conjunto de clases, compilado y enlazado en algún paquete. Y debido a que los objetos casi nunca se compran o venden, éstos no constituyen unidades de implementación. La definición de objetos es puramente técnica – la encapsulación del estado y el comportamiento, el polimorfismo, y la herencia. Esta definición no incluye nociones de independencia o composición posterior. Un componente debe tener un número considerable de usos y de clientes, para que sea viable.El “uso repetido” está detrás del concepto de reusabilidad.

13. Lecciones Aprendidas • Visual Basic de Microsoft. • Java. • Enterprise JavaBeans (EJB). • COM+. • Todos los sistemas operativos modernos. • Recientemente, las arquitecturas “plugin”. • Arquitecturas en la web basadas en ASP’s • Arquitecturas en la web basadas en JSP’s • Integración de servidores alrededor de J2EE y COM+ / .NET

14. Lecciones Aprendidas (ii) • Múltiples componentes de diferentes fuentes pueden coexistir en la mima instalación. • Los componentes existen en un nivel de abstracción en el que significan algo directamente para el cliente (Visual Basic). • La mayoría de los objetos no tienen significado para los clientes que no son programadores. • Configurar e integrar un objeto individual dentro de algún sistema dado no es posible normalmente, así que los objetos no pueden ser vendidos independientemente como los componentes.

15. Capítulo 2: El mercado VS la teconología • Los componentes son activos reutilizables. • Resolver un problema general en lugar de uno específico implica más trabajo. • Los componentes son viables sólo si la inversión en su desarrollo regresa como un resultado de su venta. “Tecnología imperfecta en un mercado de trabajo es sostenible Tecnología perfecta sin ningún mercado será vana”

16. Crear un Mercado • Un nuevo producto puede crear un mercado solo si su llegada ya se estaba esperando. • Un camino elegante es el que evita crear mercados y se expande cuidadosamente en mercados ya establecidos. (estrategia de Microsoft con su V. Basic en Internet). • La producción de componentes debe ser menos costosa que la producción de soluciones completas. Además, el empaquetarlos o ligarlos con componentes relacionados ayuda a disminuir los costos de distribución; pues algunos componentes no son capaces de sostener, solos, los precios que los podrían hacer viables.

17. Propiedades fundamentales de la Tecnología de Componentes • El establecimiento de mercados de componentes descansa en la factibilidad tecnológica. • En un mercado abierto de desarrolladores de componentes independientes, el conjunto de posibles combinaciones (en el uso de componentes) no es conocido por ninguna de las partes involucradas. • Los componentes necesitan estar construidos de tal manera que permitan una comprobación modular. • La seguridad (si hay fallas no se debe colapsar el Sist.) • La funcionalidad. • El rendimiento.

18. El desarrollo de un mercado • ComponentSource ocupa un de los lugares más amplios dentro del mercado de componentes de software y desarrollo de herramientas. Preferencia por COM (ActiveX). Tabla 2.1 Productos ofrecidos en ComponentSource

19. Distribución de los componentes ofrecidos ComponentSource Figura 2.1: Mercado compartido en ComponentSource. • Flashline es otra compañía importante en el mercado de componentes de SW. Comparada con ComponentSource, se enfoca en el desarrollo de componentes para el servidor y tiene preferencia por las tecnologías basadas en Java.

20. Capítulo 3: Estándares • Los estándares son útiles para establecer acuerdos entre los modelos comunes, habilitando en un principio la interoperabilidad. • Los estándares también pueden ser usados para crear acuerdos en especificaciones concretas de interfaces, habilitando una composición efectiva.

21. Extrema importancia de los (cuasi) estándares • Para que un componente encuentre un razonable número de clientes, necesita tener requerimientos que puedan ser ampliamente soportados. • También necesita proporcionar servicios que puedan ser ampliamente solicitados. • Un componente necesita sostener una porción significativa de un mercado específico en su dominio.

22. Extrema importancia de los (cuasi) estándares(ii) • Si un componente cubre las necesidades de un número pequeño de clientes, el vendedor conocerá exactamente las necesidades individuales de los clientes (el caso extremo es el desarrollo de componentes para solo un propósito y sólo para un cliente). • Como el número de usos potenciales y de clientes potenciales crece, es improbable que que cualquier componente pueda cubrir todas las necesidades mientras es implementado. • El punto medio inevitable en el que clientes y vendedores necesitan posicionarse es el que está basado en los estándares.

23. ¿Dónde está la tecnología de componentes hoy en día? • Es claro que los componentes de un dominio general se convertirán en los más provechosos de todos y esos mercados substanciales serán creados. • Sin embargo, los estándares de dominio específicos plantean hoy la mayoría de las preguntas. ¿Deben los estándares venir antes de los productos y de los mercados, o viceversa? • Ni los productos ni los bosquejos de estándares han alcanzado un nivel de madurez o de impacto que permita a cualquier predicción hoy en día.

24. Parte 2Fundamentación

25. Capítulo 4¿Qué es un componente y qué no lo es? • Los términos “componente” y “objeto” son a menudo usados de forma intercambiable. • La programación orientada a componentes se apoya de conceptos que fundamentan este paradigma, así como modelos de diseño, metodologías, estándares e incluso problemas.

26. Componente “Unidad de composición de aplicaciones de 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 propiedades características de un componente son: • Es una unidad de implementación independiente. • Es una unidad compuesta por terceras partes. • No cuenta con un estado observable desde el exterior.

27. Componente(ii) • Las terceras partes no pueden acceder a los detalles de construcción del componente. • Debe ser suficientemente autocontenido. • Especificaciones claras de lo que requiere y de lo que proporciona. • Interacciona con su entorno a través de interfaces bien definidas. • No tener estados observables desde el exterior excepto atributos no funcionales como el número de serie.

28. Componente(iii) • Son unidades de peso pesado, existe solo una copia. • Por tanto, en un proceso se puede decir si hay o no un componente, pero no varias instancias del mismo. • Propósito de rehúso bien definido. • No puede ser parcialmente implementada

29. Objeto “Un objeto es una unidad de instanciación con una identidad única, un estado y un conjunto de operaciones. El estado esta representado por el conjunto de valores que toman las propiedades en un instante de tiempo, el cual varía dinámicamente como resultado de la ejecución de sus operaciones.” En contraste con las propiedades características de un componente, las propiedades características de un objeto son las siguientes: • Es una unidad de instanciación, tiene una única identidad. • Puede tener estados y estos pueden ser observables externamente. • Encapsula su estado y comportamiento.

30. Objeto(ii) • No puede ser parcialmente instanciada. • Como los objetos son instanciados necesitan tener un plan de construcción que describa el espacio del estado, el estado inicial y el comportamiento del nuevo objeto. • La clase es la plantilla genérica que define el espacio de estados posibles del objeto y a partir de la cual se pueden instanciar los objetos.

31. Componentes y Objetos No hay necesidad para que un componente contenga clases únicamente. Un componente puede contener: • Procedimientos tradicionales, y siempre tener variables globales. • Puede ser realizado en su totalidad utilizando programación funcional. • Cualquier otro enfoque.

32. Dependencias del contexto • Interfaces requeridas • Entorno de componentes para el cuál esta preparado (COM, CORBA, .NET, J2EE). • Plataforma (Hardware/Software)

33. Interfaces Determinan las operaciones que el componente implementa como las que precisa utilizar de otros componentes durante la ejecución. Usualmente son los atributos y métodos públicos que el componente implementa más los eventos que emite. La especificación de las interfaces es un contrato. El respeto de este contrato por parte del cliente y componente asegura el éxito de la interacción

34. Contratos de Especificación Un contrato de especificación 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).

35. Estados y Contratos del Componente En su estado final el componente representa una unidad de ejecución o utilización que opera en unmodelo de componentes (CORBA, .NET, J2EE,etc.),

36. Estados y Contratos del Componente(ii) Especificación del Componente. Esta fase especifica el componente de manera independiente a la plataforma en la que va a ser construido. La especificación del componente se alcanza a través de la especificación de las interfaces que lo conforman.

37. Estados y Contratos del Componente(iii) Implementación del Componente. En esta fase se realiza o traduce la especificación ya definida a un entorno de implementación concreto, utilizando un lenguaje de programación determinando y respetando los reglas que establece un modelo de componentes.

38. Estados y Contratos del Componente(iv) Instalación del componente. Se ejecutan las acciones necesarias para dar disponibilidad del componente en la plataforma específica, para ser utilizado por las diferentes aplicaciones.

39. Estados y Contratos del Componente(v) Objeto Componente. Instancia de un componente ya instalado en el momento cuando este va a serinvocado para su utilización.

40. Estados y Contratos del Componente(vi) Se distinguen dos tipos de contrato: El contrato de usoque establece un acuerdo entre la interface del objeto componente y sus clientes El contrato de realizaciónque establece un acuerdo entre la especificación del componente y susimplementaciones.

41. Capitulo 5Programación Orientada a Componentes La programación basada en componentes(PBC) es aquella que se basa en la implementación de sistemas utilizando componentes previamente programados y probados. La construcción de esos componentes se realiza mediante la programación orientada a componentes.

42. Capitulo 5Programación Orientada a Componentes Variante natural de la programación orientada a objetos para los sistemas abiertos. • Objetivo:Construir un mercado global de componentes (MGC) 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 o que quieren añadir funcionalidad dependiente de terceros.

43. Programación Orientada a Componentes(ii) • Entidades básicas:Componentes - cajas negras que encapsulan cierta funcionalidad y que son diseñadas para el Mercado Global de Componentes sin saber quién las utilizará, ni cómo, ni cuándo.

44. POC frente a la POO Una diferencia entre las dos metodologías es la manera en la cuál visualizan la aplicación final. La POO se enfoca en las relaciones entre las clases que estan combinadas dentro de un programa en formato binario ejectuable. La POC se enfoca en los módulos de código intercambiables que trabajan independientemente y no requieren que nosotros estemos familiarizados con su forma de trabajar interna.

45. POC frente a la POO Si alguna clase sufre cambios: • Re-enlazamiento masivo de la aplicación completa • Realizar nuevamente las pruebas • Re-implementación de posiblemente todas las demás clases. Si es necesario modificar un componente: • Los cambios son contenidos solo en el componente. • No existiendo la necesidad de re-compilación o re-implementación.  • Pueden ser actualizados aunque la aplicación este corriendo, mientras el componente no se encuentre en uso.

46. Beneficios que proporciona la POC Una aplicación orientada a componentes es fácil de extender. Cuando se tienen nuevos requerimientos a implementar, se pueden proveer nuevos componentes, sin tocar los componentes existentes, no afectándolos así por los nuevos requerimientos. Esos factores permiten a la programación orientada a componentes reducir el costo a lo largo de la etapa de mantenimiento, esto es un factor esencial en la mayoría de los negocios, en los cuales sé esta extendiendo el uso de la tecnología de componentes.

47. Otros conceptos básicos de POC • Componentes COTS • Composición tardía • Entornos • Eventos • Polimorfismo • Reflexión

48. Tendencias de la POC • Lenguajes de programación • Java, Component Pascal, Oberon, Módula 3 y ADA 95 • Modelos de desarrollo • Aspectos de calidad en componentes

49. Problemas de la POC • Clarividencia • Percepción del entorno • Falta de soporte formal • Interoperabilidad

50. Diseño Basado en Componentes En el DSBC, pueden identificarse varias tareas específicas para la construcción de aplicaciones utilizando componentes COTS: (1) La búsqueda (trading) de componentes que satisfagan los requisitos impuestos tanto por el cliente como por la arquitectura de la aplicación (2) La evaluación de los componentes candidatos para seleccionar los más idóneos; (3) La adaptación y/o extensión de los componentes seleccionados para que se ajusten a los requisitos anteriores. (4) La integración, configuración e interconexión de dichos componentes para construir la aplicación final.