Ingeniería del software II

Presentación del tema: "Ingeniería del software II"— Transcripción de la presentación:

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

2 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) IS II ISBC

3 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 IS II ISBC

4 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 IS II ISBC

5 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 IS II ISBC

6 Conceptos básicos Está documentado Es reemplazable
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 IS II ISBC

7 Conceptos básicos Modelo de componentes
Un Modelo de componentes define la 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 IS II ISBC

8 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 IS II ISBC

9 Conceptos básicos Interfaz de un componente Eventos
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. IS II ISBC

10 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) IS II ISBC

11 Conceptos básicos Contenedores Panel Botón Formulario Panel StatusBar
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 IS II ISBC

12 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 IS II ISBC

13 Conceptos básicos Meta-información Información general
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. IS II ISBC

14 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 IS II ISBC

15 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. IS II ISBC

16 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). IS II ISBC

17 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 IS II ISBC

18 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 IS II ISBC

19 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 IS II ISBC

20 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. IS II ISBC

21 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 IS II ISBC

22 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 IS II ISBC

23 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. IS II ISBC

24 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 IS II ISBC

25 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 IS II ISBC

26 POC: Conceptos básicos
Eventos 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 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 IS II ISBC

27 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 IS II ISBC

28 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 IS II ISBC

29 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. IS II ISBC

30 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 IS II ISBC

31 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. IS II ISBC

32 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. IS II ISBC

33 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. IS II ISBC

34 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) IS II ISBC

35 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%. IS II ISBC

36 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 IS II ISBC

37 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. IS II ISBC

38 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. IS II ISBC

39 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) IS II ISBC

40 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 IS II ISBC

41 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 IS II ISBC

42 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 IS II ISBC

43 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. IS II ISBC

44 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 IS II ISBC

45 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. IS II ISBC

46 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. IS II ISBC

47 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) IS II ISBC

48 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 IS II ISBC

49 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 IS II ISBC

50 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. IS II ISBC

51 ISBC: Ingeniería de Dominio
La reutilización del software dentro de un dominio de aplicación pasa por el descubrimiento de elementos comunes a los sistemas pertenecientes a dicho dominio Se produce un cambio de un desarrollo orientado a un único producto software a un desarrollo centrado en varios productos que comparten unas características formando una familia IS II ISBC

52 ISBC: Ingeniería de Dominio
Aparecen dos procesos distintos: la ingeniería de dominio La ingeniería de dominio se centra en el desarrollo de elementos reutilizables que formarán la familia de productos la ingeniería de aplicación la ingeniería de aplicación se orienta hacia la construcción o desarrollo de productos individuales, pertenecientes a la familia de productos, y que satisfacen un conjunto de requisitos y restricciones expresados por un usuario específico IS II ISBC

53 ISBC: Ingeniería de Dominio
Definiciones de ingeniería de dominio: La ingeniería de dominio se puede definir como el proceso clave que se necesita para el diseño sistemático de una arquitectura y de un conjunto de elementos software reutilizables que pueden ser usados en la construcción de una familia de aplicaciones relacionadas o subsistemas. [Griss, M. L. (1996)] El objetivo fundamental de la ingeniería de dominio es la optimización del proceso de desarrollo del software en un espectro de múltiples aplicaciones que representan un negocio común o problema de dominio [Simos, M. (1995)] IS II ISBC

54 ISBC: Ingeniería de Dominio
Dentro del contexto de la ID, cada una de las características que define un sistema es una feature Tanto los usuarios, como los analistas y los desarrolladores están involucrados en el desarrollo pero con diferentes perspectivas. Los usuarios están más preocupados por los servicios o funciones que debe ofrecer el sistema; los analistas y diseñadores se centran en las tecnologías del dominio; y los desarrolladores se interesan especialmente por las técnicas de implementación IS II ISBC

55 ISBC: Ingeniería de Dominio
Las features pueden clasificarse en 4 categorías IS II ISBC

56 ISBC: Ingeniería de Dominio
Existen diferentes propuestas para llevar a cabo el proceso de ID FODA (Feature-Oriented Domain Analysis) OODA (Object Oriented Domain Analysis) ODM (Organization Domain Modeling) FORM (Feature-Oriented Reuse Method) FeatureRSEB (Feature Reuse-Driven Software Engineering Business) IS II ISBC

57 ISBC: FODA 1. Identificación del dominio y del alcance
La mayoría de las aplicaciones consisten en varios subsistemas o subproblemas distintos y reconocibles, aunque sólo algunos de ellos son económicamente reutilizables. Por lo tanto es importante decidir qué partes son válidas para un futuro tratamiento. En FODA se construye un modelo de contexto IS II ISBC

58 ISBC: FODA 2. Selección y análisis de ejemplos, necesidades y tendencias Hay un delicado equilibrio entre la reutilización reactiva y proactiva. Un conjunto de elementos reutilizables debe anticiparse a las necesidades futuras. Dado que esto es difícil de hacer, y es la razón por la que construir software reutilizable es más caro que construir software convencional. El proceso de reutilización debe encontrar los elementos esenciales comunes y la variabilidad, así como dar prioridad a las partes que deben ser tenidas en cuenta en la reutilización. La mayoría de las aproximaciones seleccionan ejemplos clave y extraen sus conjuntos de features esenciales. Los ejemplos relacionan el ámbito del dominio con la evaluación de las necesidades de los usuarios, el mercado, la tecnología y las tendencias del negocio. IS II ISBC

59 ISBC: FODA 3. Identificación, recolección y agrupación de los conjuntos de features Utilizando modelos de análisis, tablas y/o gráficos, las features que aparecen juntas (AND) o son variantes que seleccionar (OR, XOR) se estructuran en un marco de decisión, de esta forma la terminología del dominio es almacenada. En FODA un modelo de información describe las entidades de dominio y las relaciones entre ellas, un modelo de comportamiento describe las relaciones dinámicas entre las entidades del dominio. El modelo funcional de FODA, describe el flujo de datos entre las entidades. El modelo de features mantiene todos los modelos juntos estructurando y relacionando los conjuntos de features. IS II ISBC

60 ISBC: FODA 4. Desarrollo de un modelo y una arquitectura de dominio o genéricos A partir de estos conjuntos de features, un modelo de dominio resume las características esenciales de todas o algunas de las aplicaciones del dominio. También se desarrolla una arquitectura del sistema que relaciona los mecanismos principales las features, los subsistemas y las variantes. La arquitectura cubre los subsistemas y las aplicaciones resultantes, define los servicios principales, especifica las interfaces de forma precisa y sirve como modelo de referencia y como anteproyecto funcional. IS II ISBC

61 ISBC: FODA 5. Representación de las partes comunes y la variabilidad
Se identifican los subsistemas, módulos y funciones genéricas, relacionándose entre ellas mediante generalizaciones, especializaciones o alternativas 6. Explotación de las partes comunes y la variabilidad Se emplean notaciones y mecanismos para especificar diferentes clase de productos genéricos o parametrizados. . IS II ISBC

62 ISBC: FODA 7. Implementación, certificación y empaquetado de los elementos reutilizables El subconjunto más importante de componentes reutilizables (assets) candidatos se implementan y se distribuyen como elementos reutilizables certificados, bajo una política de gestión de la configuración. El resto de elementos reutilizables serán implementados cuando se necesiten. IS II ISBC

63 ISBC Procesos gemelos Análisis del Dominio Diseño del Dominio
Desarrollo de Componentes modelos de análisis diseños genéricos componentes Diseño de la Arquitectura Especificación De Componentes Búsqueda de Componentes Adapt / Des. Componentes Integración de Componentes IS II ISBC