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

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 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 delDominio

Desarrollo deComponentes

Diseño de laArquitectura

Especificación De Componentes

Adapt / Des.Componentes

Búsqueda deComponentes

Integración deComponentes

modelos deanálisis

diseñosgenéricos

componentes