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
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 componentesUn 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
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.
EventosEspecifican 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
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.
Formulario
Panel
Panel
Botón
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 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ácticasintáctica: Signatura (tipos) de los argumentos.
Interoperabilidad a nivel de protocolosnivel de protocolos: Ordenes relativos de los mensajes recibidos y la sincronización entre ellos.
Interoperabilidad semánticasemá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 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.
Top Related