Ingeniería del software II

Ingeniería del software II Ingeniería del software basada en componentes ISBC

ISBC • En este tema veremos: • Descripción de la ingeniería del software basada en componentes. • Ejemplos de modelos de componentes: • JavaBeans • COM (Component Object Model) ISBC

Conceptos básicos • Componente software Un componente es una unidad 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 [Szyperski y Pfister,1997] Caracteristicas: • Autocontenido • Accesible solamente a través de su interfaz • Inmutabilidad de sus servicios • Documentación de sus servicios • Reemplazable por otro componente ISBC

Conceptos básicos • Autocontenido • Un componente no debe requerir la reutilización de otros componentes para cumplir su función • Si el componente requiere de otros, el conjunto de componentes o funciones, visto como un todo, debe ser considerado como un componente de más alto nivel ISBC

Conceptos básicos • Es accesible sólo a través de su interfaz • Es accedido a través de una interfaz claramente definida • La interfaz debe ser independiente de la implementación física • debe ocultar los detalles de su diseño interno • Sus servicios son inmutables • Los servicios que ofrece un componente a través de su interfaz no deben variar • La implementación física de estos servicios pueden ser modificadas, pero no deben afectar la interfaz ISBC

Conceptos básicos • Está documentado • Debe tener una documentación adecuada que facilite: • la recuperación del componente desde el repositorio, • la evaluación del componente, • su adaptación al nuevo ambiente y • su integración con otros componentes del sistema en que se reutiliza. • Es reemplazable • Puede ser reemplazado por una nueva versión o por otro componente que proporcione los mismos servicios ISBC

Conceptos básicos • Modelo de componentes Un Modelo de componentes definela forma de sus interfaces y los mecanismos para interconectarlos, en la actualidad existen multitud de modelos de componentes definidos: • COM • JavaBeans • VCL • CORBA • kParts • Bonobo • OpenDoc ISBC

Conceptos básicos • Plataforma de componentes Entorno de desarrollo y de ejecución de componentes que permiten aislar la mayor parte de las dificultades conceptuales y técnicas que conlleva la construcción de aplicaciones basadas en los componentes de un modelo de componentes concreto (frameworks de componentes), ejemplos: • Windows – COM • .NET • Java Virtual Machine • Orbix - CORBA ISBC

Conceptos básicos • Interfaz de un componente Determina 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. • Eventos Especifican la forma en la que el componente notifica al exterior una respuesta a un estímulo externo o bien un cambio en una condición interna. Se especifica la signatura y la condición para que se produzca, pero no cómo tratarlo. ISBC

Conceptos básicos • Mecanismos de comunicación de eventos: • Comunicación directa: Los receptores se registran en el emisor que les envía los eventos cuando se producen. • Comunicación indirecta: Usan distribuidores que notifican los eventos de otros emisores. O bien los receptores se registran en los distribuidores o bien se utiliza radiado total o parcial (broadcast - multicast) ISBC

Conceptos básicos • Contenedores Entidades software que permiten contener a otras entidades proporcionando un entorno compartido de interacción. Normalmente objetos y componentes visuales que a su vez pueden contener otros componente visuales. Panel Botón Formulario Panel StatusBar ScrollBar ISBC

Conceptos básicos • La relación entre el contenedor y los elementos contenidos se puede ver a través del patrón de diseño Composite ISBC

Conceptos básicos • Meta-información Información adicional de un componente que suele hacerse pública. La idea es que con esta información un componente puede saber cómo utilizar otro componente: Reflexión • Información general • Dependencias externas • Interfaces • Otros atributos del componente: uso de memoria o consumo de procesador. ISBC

Conceptos básicos • Entornos de desarrollo integrados IDE: Aplicación (visual) que permite la construcción de aplicaciones a través de componentes. Incluyen editores, browsers, ayudas, directorios de componentes, compiladores, depuradores, herramientas de control de configuración, etc. Ejemplos: • Eclipse • Delphi • Builder C++ • Visual Studio .NET • KDeveloper ISBC

Conceptos básicos • Interoperabilidad Capacidad de dos o más componentes para comunicarse y cooperar de forma compatible entre sí. • Interoperabilidad sintáctica: Signatura (tipos) de los argumentos. • Interoperabilidad a nivel de protocolos: Ordenes relativos de los mensajes recibidos y la sincronización entre ellos. • Interoperabilidad semántica: Las anteriores y además la funcionalidad de las operaciones. ISBC

Conceptos básicos • Estándares de interoperabilidad: Garantizan la interoperabilidad, ejemplo IIOP: El protocolo IIOP (Internet Inter-ORB Protocol) es un estándar del sector que puede utilizarse para proporcionar comunicación entre programas de aplicación orientados a objetos que se ejecuten en diferentes procesadores. Forma parte de la especificación CORBA (Common Object Request Broker Architecture). ISBC

Conceptos básicos • Otras definiciones de componente: • Wallnau: Unidad de sw con funcionalidad y complejidad significativa, considerada como caja negra y de grano grueso. • Meyer: Noción fundamental: es sw orientado al cliente: que permita ser utilizado por otros elementos de sw sin intervención de los autores. Implica una completa especificación de su comportamiento y funcionalidad • Szyperski: Unidad binaria de composición carente de estado caracterizado por su interfaz, que debe definir tanto la funcionalidad como las dependencias del contexto ISBC

Programació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 • Las entidades básicas de la POC son los componentes, cajas negras que encapsulan cierta funcionalidad sin saber ni quién los utilizará, ni cómo, ni cuándo. Los usuarios conocen los servicios que ofrecen los componentes a través de sus interfaces y requisitos, pero normalmente ni quieren ni pueden modificar su implementación ISBC

POC Vs POO • La Programación Orientada a Componentes (POC) aparece como una variante natural de la programación orientada a objetos (POO) para los sistemas abiertos • La POO 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 ISBC

POC Vs POO • Reutilización • En POC se consigue mediante COMPOSICION • En POO se consigue mediante mecanismos de herencia • Introspección: Facilidad para interrogar al componente sobre sus propiedades y métodos de forma dinámica, normalmente mediante el uso de reflexión. ISBC

POC Vs POO • Nuevas formas de comunicación, como los eventos y las comunicaciones asíncronas frente a los rudimentarios mecanismos de los objetos. • La POO se enfoca en las relaciones entre las clases que están combinadas dentro de un programa en formato binario ejecutable • La programación Orientada a Componentes 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 ISBC

POC Vs POO • En POO: Si múltiples desarrolladores trabajan en el mismo código base, tienen que compartir los códigos fuentes, si en ese proyecto se modifica alguna clase, se puede desencadenar una re-composición de la aplicación completa y se necesitaran realizar nuevamente las pruebas y una re-implementación de algunas otras clases • En POC: 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 ISBC

POC Vs POO • En POO: la aparición de nuevos requisitos suele traer aparejado un rediseño. • En 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. ISBC

POC: Conceptos básicos • COTS (Components Off-The-Self) 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 • 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 ISBC

POC: Conceptos básicos • Entornos Un entorno es el conjunto de recursos y componentes que rodean al componente dado, y que definen las acciones que sobre él 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. En primero de ellos es el ambiente para el que se ha construido el componente, y en donde se ejecuta normalmente. El entorno de diseño es un ambiente restringido, que se utiliza para localizar, configurar, especializar y probar los componentes que van a formar parte de una aplicación, y en donde los componentes han de poder mostrar un comportamiento distinto a su comportamiento normal durante su ejecución ISBC

POC: Conceptos básicos • EventosLos 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 • 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 ISBC

POC: Conceptos básicos • Composición tardía 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 sólo conoce al componente por su interfaz o contrato, pero no tiene porqué conocer ni sus detalles de implementación, ni la forma en la que fue concebido para ser usado ISBC

POC: Conceptos básicos • 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, en POO el polimorfismo esta relacionado con la herencia y la sobre-escritura de métodos, en POC este concepto esta basado en las interfaces: • Implementación de varias interfaces para adaptarse a contextos determinados • Reemplazar un componente por otro que implemente la misma interfaz ISBC

POC: Problemas • Clarividencia Este problema se refiere a la dificultad con la que se encuentra el diseñador de un componente al realizar su diseño, no conoce ni quién lo utilizará, ni cómo, ni en que entorno, ni para que aplicación; Este problema está intrínsecamente ligado a la composición tardía y reusabilidad de los componentes Solución: Ingeniería del Dominio. ISBC

POC: Problemas • Percepción del entorno 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 él Solución:La inspección y la reflexión estructural son dos mecanismos comúnmente utilizados para implementar esta habilidad ISBC

POC: Problemas • Falta de soporte formal No existen métodos formales para trabajar con las peculiaridades de los componentes: • Composición tardía • Polimorfismo • Evolución de componentes • Interoperabilidad 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. Sin embargo, es necesario ser capaces de referirnos y buscar los servicios que necesitamos por algo más que sus nombres: nivel Semántico. ISBC

Ingeniería de software basada en componentes En la Ingeniería de Software Basada en componentes (Component Based Software Engineering CBSE) el desarrollo de una solución software se percibe como un trabajo de adaptación y composición a partir de componentes, los cuales pueden tener diversos orígenes: ya desarrollados para uso genérico, comprados, o desarrollados a la medida. CBSE ha sido reconocida como una nueva subdisiplina de la Ingeniería de Software con tres objetivos importantes: • Desarrollar sistemas a partir de componentes ya construidos • Desarrollar componentes como entidades reusables • Mantener y evolucionar el sistema a partir de la adaptación y reemplazo de sus componentes. ISBC

ISBC: Objetivos • Sistemas informáticos complejos y de alta calidad deben ser desarrollados en periodos de tiempo muy cortos. Para reducir el tiempo de desarrollo y poder garantizar la calidad hay que emplear la REUTILIZACIÓN. • La Ingeniería del Software Basada en Componentes (ISBC) es un proceso de desarrollo software que se centra en el diseño y construcción utilizando componentes software reutilizables. ISBC

ISBC: Objetivos • "Reutilización de software es el proceso de crear sistemas de software a partir de software existente, en lugar de desarrollarlo desde el comienzo" (Sametinger, 1997) • La reutilización es un enfoque de desarrollo [de software] que trata de maximizar el uso recurrente de componentes de software existentes" (Sommerville, 1995). • “La reutilización de software es el proceso de implementar o actualizar sistemas de software usando activos de software existentes” (Sodhi & Sodhi, 1999) ISBC

ISBC: Objetivos • Varios estudios han demostrado la efectividad de la reutilización del software: • 40-60% del código fuente es reutilizable de una aplicación a otra. • Aproximadamente el 60% del diseño y del código de aplicaciones administrativas es reutilizable. • Aproximadamente el 75% de las funciones son comunes a más de un programa. • Sólo el 15% del código encontrado en muchos sistemas es único y novedoso a una aplicación específica. • El rango general de reuso potencial está entre el 15% y el 85%. ISBC

ISBC: Objetivos • Forrester Research ha estimado que: • Más del 30% de los gastos globales en TI ocurren en la integración de aplicaciones existentes • Mas del 35% del tiempo de desarrollo de aplicaciones se invierte creando interfaces para integrar la aplicación en desarrollo a otras existentes o a fuentes de datos • El Gartner Group ha estimado que en los próximos años la mayoría de proyectos de software se ejecutarán mediante la integración de aplicaciones existentes en lugar del desarrollo de nuevas aplicaciones ISBC

ISBC: Objetivos • Objetivo deseable: 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. ISBC

Cuando aplicar ISBC • La ISBC se presenta cómo una alternativa interesante en el desarrollo si es posible conseguir: • Construir sistemas complejos ensamblándolos a partir de un catálogo de componentes reutilizables. • Desarrollos rentables y a corto plazo. • Que los ingenieros no reinventen, sino que reutilicen. • Compensar los gastos añadidos que representan la creación y/u obtención de componentes software reutilizables. • Crear una biblioteca con los componentes necesarios para acceder rápidamente a su posible reutilización. • Que los interfaces de los componentes sean consistentes. ISBC

ISBC: Reutilización • Los procesos de desarrollo basados en la reutilización de software se clasifican en: • Desarrollo de software con reutilización de componentes. El desarrollo de una nueva applicación involucra el reuso de un conjunto de componentes existente (PBC) • Desarrollo de componentes de software reutilizable. Adaptación o desarrollo de componentes con el propósito expreso de ser reutilizados en futuras aplicaciones (POC) ISBC

ISBC: Reutilización • Desarrollo de software con reutilización de componentes • Es un enfoque de desarrollo de software que • maximiza la reutilización de componentes software existentes y/o reduce el número de componentes que requieren ser desarrollados desde el comienzo • Condiciones mínimas para la reutilización • Existencia de repositorios o bases de componentes reutilizables • Los componentes son confiables y actuán de acuerdo a sus especificaciones • Los componentes están debidamente documentados ISBC

ISBC: Reutilización • Reutilización caja-negra: • El componente es utilizado "tal como es", sin modificaciones y sin que se requiera conocer los detalles internos de su implementación • El usuario del componente sólo requiere conocer la funcionalidad del componente (qué hace) y como se usa (su interfaz) • Reutilización caja-blanca: • El componente puede ser modificado para adaptarlo a las necesidades del sistema en el que se reutiliza • Su implementación es visible y puede ser modificada por el usuario. • Se requiere un esfuerzo adicional al de la modificación del componente:debe ser verificado una vez modificado ISBC

ISBC: Reutilización • La reutilización de componentes de software impacta positivamente: • la calidad del software producido • incrementa la confiabilidad (% de errores presentes) • mejora el rendimiento del componente en cada reutilización • la productividad de los grupos de desarrollo • reduce la cantidad de código que debe producirse • reduce la redundancia de esfuerzo • el tiempo de entrega • reduce el tiempo de colocación del producto en el mercado • los costos • reduce los costos de desarrollo y mantenimiento de nuevas aplicaciones ISBC

ISBC: Composición • Composición es el término utilizado en ISBD para referirse a cómo los sistemas software se ensamblan. Los componentes ensamblados pueden interaccionar, un modelo de componentes (framework) especifica los tipos de componentes y sus patrones de interacción. • Los diferentes tipos de contratos que existen en la composición reciben el nombre genérico de formas de composición. Se distinguen seis formas de composición básicas. ISBC

ISBC: Composición • Distribución de componentes: Los componentes deben ser incluidos en un framework antes de ser compuestos o ejecutados. Los contratos (1) de distribución describen la interfaz que el componente debe implementar para que el framework pueda gestionar sus recursos ISBC

ISBC: Composición • Distribución de frameworks: Los frameworks pueden ser distribuidos dentro de otros frameworks. Por ejemplo, la especificación de EJB lleva a la práctica parcialmente esta idea con los contenedores EJB incluidos en los servidores EJB. El contrato (1) es análogo al contrato expuesto en la distribución de componentes. ISBC

ISBC: Composición • Composición simple: Los componentes distribuidos en el mismo framework pueden ser compuestos. El contrato de composición (1) expresa funcionalidad específica del componente y de la aplicación. Los mecanismos de interacción para soportar el contrato los ofrece el framework. ISBC

ISBC: Composición • Composición heterogénea: El soporte de frameworks por capas implica una composición de componentes a través de frameworks, se necesitan contratos de puente (1) a parte de los contratos de composición (2) ISBC

ISBC: Composición • Extensión del framework: Los frameworks pueden tratarse como componentes, y pueden componerse con otros componentes. Esta forma de composición suele darse mediante la parametrización del comportamiento de los frameworks mediante plug-ins. Contratos estándares de plug-ins (1) para proveedores de servicios son muy comunes en los frameworks comerciales ISBC

ISBC: Composición • Composición transitiva: Un componente puede ser a su vez un compuesto. El contrato (1) se utiliza para componer C1 y C3, que contiene a su vez uno o más componentes. La cuestión que surge es si C2 es visible fuera de C3 y si puede ser distribuido independientemente ISBC

ISBC • Desarrollo de componentes de software reutilizable • Su objetivo es producir repositorios de activos o componentes de software reutilizables que puedan ser reutilizados en el desarrollo de software • El desarrollo de componentes se lleva a cabo a través de: • la adaptación de componentes existentes • la creación de repositorios aplicando los procesos de la Ingeniería de Dominio. ISBC

Ingeniería del software II