Ingeniera del software II

Ingeniera del software

basada en componentes

IS II

ISBC

ISBC

En este tema veremos:

Descripcin de la ingeniera del

software basada en componentes.
Ejemplos de modelos de
componentes:

JavaBeans
COM (Component Object Model)

IS II

ISBC

Conceptos bsicos
Componente software

Un componente es una unidad de composicin 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 travs de su interfaz
Inmutabilidad de sus servicios
Documentacin de sus servicios
Reemplazable por otro componente

IS II

ISBC

Conceptos bsicos

Autocontenido

Un componente no debe requerir la

reutilizacin de otros componentes para
cumplir su funcin
Si el componente requiere de otros, el
conjunto de componentes o funciones,
visto como un todo, debe ser
considerado como un componente de
ms alto nivel
IS II

ISBC

Conceptos bsicos

Es accesible slo a travs de su interfaz

Es accedido a travs de una interfaz claramente

definida
La interfaz debe ser independiente de la
implementacin fsica

debe ocultar los detalles de su diseo interno

Sus servicios son inmutables

Los servicios que ofrece un componente a travs

de su interfaz no deben variar
La implementacin fsica de estos servicios
pueden ser modificadas, pero no deben afectar la
interfaz

IS II

ISBC

Conceptos bsicos

Est documentado

Debe tener una documentacin adecuada que

facilite:

la recuperacin del componente desde el repositorio,

la evaluacin del componente,
su adaptacin al nuevo ambiente y
su integracin con otros componentes del sistema en
que se reutiliza.

Es reemplazable

Puede ser reemplazado por una nueva versin o

por otro componente que proporcione los
mismos servicios

IS II

ISBC

Conceptos bsicos

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

Conceptos bsicos

Plataforma de componentes
Entorno de desarrollo y de ejecucin de componentes que
permiten aislar la mayor parte de las dificultades
conceptuales y tcnicas que conlleva la construccin 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

Conceptos bsicos

Interfaz de un componente
Determina las operaciones que el componente implementa
como las que precisa utilizar de otros componentes durante
la ejecucin.. Usualmente son los atributos y mtodos
pblicos que el componente implementa ms los eventos
que emite.

Eventos
Especifican la forma en la que el componente notifica al
exterior una respuesta a un estmulo externo o bien un
cambio en una condicin interna. Se especifica la signatura
y la condicin para que se produzca, pero no cmo tratarlo.

IS II

ISBC

Conceptos bsicos

Mecanismos de comunicacin de eventos:

Comunicacin directa: Los receptores se registran en

el emisor que les enva los eventos cuando se
producen.
Comunicacin 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

10

Conceptos bsicos

Contenedores
Entidades software que permiten contener a otras entidades
proporcionando un entorno compartido de interaccin.
Normalmente objetos y componentes visuales que a su vez
pueden contener otros componente visuales.

Formulario

IS II

Panel

Botn

Panel

StatusBar

ISBC

ScrollBar

11

Conceptos bsicos

La relacin entre el contenedor y

los elementos contenidos se puede
ver a travs del patrn de diseo
Composite

IS II

ISBC

12

Conceptos bsicos

Meta-informacin
Informacin adicional de un componente que suele hacerse
pblica. La idea es que con esta informacin un componente
puede saber cmo utilizar otro componente: Reflexin

Informacin general
Dependencias externas
Interfaces
Otros atributos del componente: uso de
memoria o consumo de procesador.

IS II

ISBC

13

Conceptos bsicos

Entornos de desarrollo integrados

IDE: Aplicacin (visual) que permite la construccin de
aplicaciones a travs de componentes. Incluyen editores,
browsers, ayudas, directorios de componentes,
compiladores, depuradores, herramientas de control de
configuracin, etc. Ejemplos:

Eclipse
Delphi
Builder C++
Visual Studio .NET
KDeveloper

IS II

ISBC

14

Conceptos bsicos

Interoperabilidad
Capacidad de dos o ms componentes para comunicarse y
cooperar de forma compatible entre s.

Interoperabilidad sintctica:
sintctica Signatura (tipos)
de los argumentos.
Interoperabilidad a nivel de protocolos:
protocolos
Ordenes relativos de los mensajes recibidos y
la sincronizacin entre ellos.
Interoperabilidad semntica:
semntica Las anteriores y
adems la funcionalidad de las operaciones.

IS II

ISBC

15

Conceptos bsicos

Estndares de
interoperabilidad:
Garantizan la interoperabilidad, ejemplo IIOP:
El protocolo IIOP (Internet Inter-ORB Protocol) es un
estndar del sector que puede utilizarse para proporcionar
comunicacin entre programas de aplicacin orientados a
objetos que se ejecuten en diferentes procesadores. Forma
parte de la especificacin CORBA (Common Object Request
Broker Architecture).

IS II

ISBC

16

Conceptos bsicos

Otras definiciones de componente:

Wallnau: Unidad de sw con funcionalidad y

complejidad significativa, considerada como caja negra y

de grano grueso.

Meyer: Nocin fundamental: es sw orientado al

cliente: que permita ser utilizado por otros elementos de

sw sin intervencin de los autores. Implica una completa
especificacin de su comportamiento y funcionalidad

Szyperski:

Unidad binaria de composicin carente de

estado caracterizado por su interfaz, que debe definir
tanto la funcionalidad como las dependencias del
contexto

IS II

ISBC

17

Programacin Orientada a
Componentes

La programacin basada en componentes(PBC) es

aquella que se basa en la implementacin de
sistemas utilizando componentes previamente
programados y probados
La construccin de esos componentes se realiza
mediante la programacin orientada a componentes
Las entidades bsicas de la POC son los
componentes, cajas negras que encapsulan cierta
funcionalidad sin saber ni quin los utilizar, ni cmo,
ni cundo. Los usuarios conocen los servicios que
ofrecen los componentes a travs de sus interfaces y
requisitos, pero normalmente ni quieren ni pueden
modificar su implementacin

IS II

ISBC

18

POC Vs POO

La Programacin Orientada a Componentes

(POC) aparece como una variante natural de
la programacin orientada a objetos (POO)
para los sistemas abiertos
La POO no define una unidad concreta de
composicin 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

19

POC Vs POO

Reutilizacin

En POC se consigue mediante COMPOSICION

En POO se consigue mediante mecanismos
de herencia

Introspeccin: Facilidad para interrogar

al componente sobre sus propiedades y
mtodos de forma dinmica,
normalmente mediante el uso de
reflexin.
IS II

ISBC

20

POC Vs POO

Nuevas formas de comunicacin, como los

eventos y las comunicaciones asncronas frente a
los rudimentarios mecanismos de los objetos.
La POO se enfoca en las relaciones entre las
clases que estn combinadas dentro de un
programa en formato binario ejecutable
La programacin Orientada a Componentes se
enfoca en los mdulos de cdigo intercambiables
que trabajan independientemente y no requieren
que nosotros estemos familiarizados con su
forma de trabajar interna

IS II

ISBC

21

POC Vs POO

En POO: Si mltiples desarrolladores trabajan en

el mismo cdigo base, tienen que compartir los
cdigos fuentes, si en ese proyecto se modifica
alguna clase, se puede desencadenar una recomposicin de la aplicacin completa y se
necesitaran realizar nuevamente las pruebas y
una re-implementacin 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-compilacin o re-implementacin

IS II

ISBC

22

POC Vs POO

En POO: la aparicin de nuevos

requisitos suele traer aparejado un
rediseo.
En POC: Una aplicacin orientada a
componentes es fcil de extender.
Cuando se tienen nuevos
requerimientos a implementar, se
pueden proveer nuevos componentes
sin tocar los componentes existentes.
IS II

ISBC

23

POC: Conceptos bsicos

COTS (Components Off-The-Self)

Han sido definidos como una clase especial de
componentes software, normalmente de grano
grueso, que presentan las siguientes
caractersticas:

Son vendidos o licenciados al pblico en general

Los mantiene y actualiza el propio vendedor, quien
conserva los derechos de la propiedad intelectual
Estn disponibles en forma de mltiples copias, todas
idnticas entre s
Su cdigo no puede ser modificado por el usuario

IS II

ISBC

24

POC: Conceptos bsicos

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 ejecucin y el de diseo. En
primero de ellos es el ambiente para el que se ha
construido el componente, y en donde se ejecuta
normalmente. El entorno de diseo es un ambiente
restringido, que se utiliza para localizar, configurar,
especializar y probar los componentes que van a formar
parte de una aplicacin, y en donde los componentes han
de poder mostrar un comportamiento distinto a su
comportamiento normal durante su ejecucin

IS II

ISBC

25

POC: Conceptos bsicos

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

Reflexin
La reflexin es la habilidad de una entidad software
de conocer o modificar su estado. A la primera
forma se le denomina reflexin estructural, y a la
segunda reflexin de comportamiento

IS II

ISBC

26

POC: Conceptos bsicos

Composicin tarda
Composicin que se realiza en un tiempo
posterior al de la compilacin del
componente, como puede ser durante su
enlazado, carga o ejecucin, y por alguien
ajeno a su desarrollo, es decir, que slo
conoce al componente por su interfaz o
contrato, pero no tiene porqu conocer ni
sus detalles de implementacin, ni la forma
en la que fue concebido para ser usado
IS II

ISBC

27

POC: Conceptos bsicos

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 mtodos, en POC este concepto esta
basado en las interfaces:
Implementacin de varias interfaces para adaptarse
a contextos determinados
Reemplazar un componente por otro que
implemente la misma interfaz

IS II

ISBC

28

POC: Problemas

Clarividencia
Este problema se refiere a la dificultad con la
que se encuentra el diseador de un
componente al realizar su diseo, no conoce ni
quin lo utilizar, ni cmo, ni en que entorno,
ni para que aplicacin; Este problema est
intrnsecamente ligado a la composicin tarda
y reusabilidad de los componentes
Solucin: Ingeniera del Dominio.
IS II

ISBC

29

POC: Problemas

Percepcin del entorno

Esta es la habilidad de un objeto o componente de
descubrir tanto el tipo de entorno en donde se
est ejecutando (de diseo o de ejecucin), como
los servicios y recursos disponibles en l

Solucin:La inspeccin y la reflexin

estructural son dos mecanismos
comnmente utilizados para implementar
esta habilidad
IS II

ISBC

30

POC: Problemas

Falta de soporte formal

No existen mtodos formales para trabajar con las

peculiaridades de los componentes:
Composicin tarda
Polimorfismo
Evolucin de componentes

Interoperabilidad

Los contratos de los componentes se reducen a la definicin de

sus interfaces a nivel sintctico, y la interoperabilidad se
reduce a la comprobacin de los nombres y perfiles de los
mtodos. Sin embargo, es necesario ser capaces de referirnos
y buscar los servicios que necesitamos por algo ms que sus
nombres: nivel Semntico.

IS II

ISBC

31

Ingeniera de software
basada en
En la Ingeniera de Software Basada en componentes
componentes
(Component Based Software Engineering CBSE) el

desarrollo de una solucin software se percibe como un

trabajo de adaptacin y composicin a partir de
componentes, los cuales pueden tener diversos orgenes:
ya desarrollados para uso genrico, comprados, o
desarrollados a la medida. CBSE ha sido reconocida como
una nueva subdisiplina de la Ingeniera 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 adaptacin y
reemplazo de sus componentes.

IS II

ISBC

32

ISBC: Objetivos

Sistemas informticos 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 REUTILIZACIN.
La Ingeniera del Software Basada en
Componentes (ISBC) es un proceso de
desarrollo software que se centra en el
diseo y construccin utilizando
componentes software reutilizables.
IS II

ISBC

33

ISBC: Objetivos

"Reutilizacin 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 reutilizacin es un enfoque de desarrollo [de software]

que trata de maximizar el uso recurrente de
componentes de software existentes" (Sommerville,
1995).

La reutilizacin de software es el proceso de

implementar o actualizar sistemas de software usando
activos de software existentes (Sodhi & Sodhi, 1999)

IS II

ISBC

34

ISBC: Objetivos

Varios estudios han demostrado la

efectividad de la reutilizacin del software:

40-60% del cdigo fuente es reutilizable de una

aplicacin a otra.
Aproximadamente el 60% del diseo y del cdigo de
aplicaciones administrativas es reutilizable.
Aproximadamente el 75% de las funciones son
comunes a ms de un programa.
Slo el 15% del cdigo encontrado en muchos
sistemas es nico y novedoso a una aplicacin
especfica.
El rango general de reuso potencial est entre el 15%
y el 85%.

IS II

ISBC

35

ISBC: Objetivos

Forrester Research ha estimado que:

Ms del 30% de los gastos globales en TI ocurren en

la integracin de aplicaciones existentes
Mas del 35% del tiempo de desarrollo de aplicaciones
se invierte creando interfaces para integrar la
aplicacin en desarrollo a otras existentes o a fuentes
de datos

El Gartner Group ha estimado que en los

prximos aos la mayora de proyectos de
software se ejecutarn mediante la
integracin de aplicaciones existentes en
lugar del desarrollo de nuevas aplicaciones
IS II

ISBC

36

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 ms
rpida y robusta o que quieren aadir
funcionalidad dependiente de terceros.
IS II

ISBC

37

Cuando aplicar ISBC

La ISBC se presenta cmo una alternativa

interesante en el desarrollo si es posible conseguir:

Construir sistemas complejos ensamblndolos a partir de

un catlogo de componentes reutilizables.
Desarrollos rentables y a corto plazo.
Que los ingenieros no reinventen, sino que reutilicen.
Compensar los gastos aadidos que representan la
creacin y/u obtencin de componentes software
reutilizables.
Crear una biblioteca con los componentes necesarios para
acceder rpidamente a su posible reutilizacin.
Que los interfaces de los componentes sean consistentes.

IS II

ISBC

38

ISBC: Reutilizacin

Los procesos de desarrollo basados en la

reutilizacin de software se clasifican en:

Desarrollo de software con reutilizacin de

componentes. El desarrollo de una nueva
applicacin involucra el reuso de un conjunto
de componentes existente (PBC)

Desarrollo de componentes de software

reutilizable. Adaptacin o desarrollo de
componentes con el propsito expreso de ser
reutilizados en futuras aplicaciones (POC)

IS II

ISBC

39

ISBC: Reutilizacin

Desarrollo de software con reutilizacin de

componentes

Es un enfoque de desarrollo de software que

maximiza la reutilizacin de componentes software

existentes y/o reduce el nmero de componentes
que requieren ser desarrollados desde el comienzo

Condiciones mnimas para la reutilizacin

Existencia de repositorios o bases de componentes

reutilizables
Los componentes son confiables y actun de
acuerdo a sus especificaciones
Los componentes estn debidamente documentados

IS II

ISBC

40

ISBC: Reutilizacin

Reutilizacin caja-negra:

El componente es utilizado "tal como es", sin modificaciones

y sin que se requiera conocer los detalles internos de su
implementacin
El usuario del componente slo requiere conocer la
funcionalidad del componente (qu hace) y como se usa (su
interfaz)

Reutilizacin caja-blanca:

El componente puede ser modificado para adaptarlo a las

necesidades del sistema en el que se reutiliza
Su implementacin es visible y puede ser modificada por el
usuario.
Se requiere un esfuerzo adicional al de la modificacin del
componente: debe ser verificado una vez modificado

IS II

ISBC

41

ISBC: Reutilizacin

La reutilizacin de componentes de software impacta

positivamente:
la calidad del software producido

la productividad de los grupos de desarrollo

reduce la cantidad de cdigo que debe producirse

reduce la redundancia de esfuerzo

el tiempo de entrega

incrementa la confiabilidad (% de errores presentes)

mejora el rendimiento del componente en cada
reutilizacin

reduce el tiempo de colocacin del producto en el mercado

los costos

reduce los costos de desarrollo y mantenimiento de nuevas

aplicaciones

IS II

ISBC

42

ISBC: Composicin

Composicin es el trmino utilizado en ISBD para

referirse a cmo los sistemas software se
ensamblan. Los componentes ensamblados pueden
interaccionar, un modelo de componentes
(framework) especifica los tipos de componentes y
sus patrones de interaccin.
Los diferentes tipos de contratos que existen en la
composicin reciben el nombre genrico de
formas de composicin. Se distinguen seis formas
de composicin bsicas.
IS II

ISBC

43

ISBC: Composicin

Distribucin de componentes:
Los componentes deben ser incluidos en un framework antes de ser
compuestos o ejecutados. Los contratos (1) de distribucin describen
la interfaz que el componente debe implementar para que el
framework pueda gestionar sus recursos

IS II

ISBC

44

ISBC: Composicin

Distribucin de frameworks:
Los frameworks pueden ser distribuidos dentro de otros frameworks.
Por ejemplo, la especificacin de EJB lleva a la prctica parcialmente
esta idea con los contenedores EJB incluidos en los servidores EJB. El
contrato (1) es anlogo al contrato expuesto en la distribucin de
componentes.

IS II

ISBC

45

ISBC: Composicin

Composicin simple:
Los componentes distribuidos en el mismo framework pueden ser
compuestos. El contrato de composicin (1) expresa funcionalidad
especfica del componente y de la aplicacin. Los mecanismos de
interaccin para soportar el contrato los ofrece el framework.

IS II

ISBC

46

ISBC: Composicin

Composicin heterognea:
El soporte de frameworks por capas implica una composicin de
componentes a travs de frameworks, se necesitan contratos de puente
(1) a parte de los contratos de composicin (2)

IS II

ISBC

47

ISBC: Composicin

Extensin del framework:

Los frameworks pueden tratarse como componentes, y pueden
componerse con otros componentes. Esta forma de composicin suele
darse mediante la parametrizacin del comportamiento de los
frameworks mediante plug-ins. Contratos estndares de plug-ins (1)
para proveedores de servicios son muy comunes en los frameworks
comerciales

IS II

ISBC

48

ISBC: Composicin

Composicin 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 ms
componentes. La cuestin que surge es si C2 es visible fuera de C3 y
si puede ser distribuido independientemente

IS II

ISBC

49

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
travs de:

la adaptacin de componentes existentes

la creacin de repositorios aplicando los procesos de
la Ingeniera de Dominio.

IS II

ISBC

50

ISBC: Ingeniera de
Dominio

La reutilizacin del software dentro de un dominio

de aplicacin 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
caractersticas formando una familia
IS II

ISBC

51

ISBC: Ingeniera de
Dominio

Aparecen dos procesos distintos:

la ingeniera de dominio
La ingeniera de dominio se centra en el desarrollo de elementos
reutilizables que formarn la familia de productos

la ingeniera de aplicacin
la ingeniera de aplicacin se orienta hacia la construccin o
desarrollo de productos individuales, pertenecientes a la familia de
productos, y que satisfacen un conjunto de requisitos y
restricciones expresados por un usuario especfico

IS II

ISBC

52

ISBC: Ingeniera de
Dominio

Definiciones de ingeniera de dominio:

La ingeniera de dominio se puede definir como el proceso clave que se
necesita para el diseo sistemtico de una arquitectura y de un conjunto de
elementos software reutilizables que pueden ser usados en la construccin de
una familia de aplicaciones relacionadas o subsistemas. [Griss, M. L.
(1996)]
El objetivo fundamental de la ingeniera de dominio es la optimizacin del
proceso de desarrollo del software en un espectro de mltiples aplicaciones
que representan un negocio comn o problema de dominio [Simos, M.
(1995)]

IS II

ISBC

53

ISBC: Ingeniera de
Dominio

Dentro del contexto de la ID, cada una de

las caractersticas que define un sistema es
una feature
Tanto los usuarios, como los analistas y los
desarrolladores estn involucrados en el desarrollo
pero con diferentes perspectivas. Los usuarios estn
ms preocupados por los servicios o funciones que
debe ofrecer el sistema; los analistas y diseadores se
centran en las tecnologas del dominio; y los
desarrolladores se interesan especialmente por las
tcnicas de implementacin
IS II

ISBC

54

ISBC: Ingeniera de
Dominio

Las features pueden clasificarse en 4

categoras

IS II

ISBC

55

ISBC: Ingeniera 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

56

ISBC: FODA

1. Identificacin del dominio y del

alcance
La mayora de las aplicaciones consisten en varios
subsistemas o subproblemas distintos y
reconocibles, aunque slo algunos de ellos son
econmicamente reutilizables. Por lo tanto es
importante decidir qu partes son vlidas para un
futuro tratamiento. En FODA se construye un
modelo de contexto
IS II

ISBC

57

ISBC: FODA

2. Seleccin y anlisis de ejemplos, necesidades

y tendencias
Hay un delicado equilibrio entre la reutilizacin reactiva y proactiva.
Un conjunto de elementos reutilizables debe anticiparse a las
necesidades futuras. Dado que esto es difcil de hacer, y es la razn por
la que construir software reutilizable es ms caro que construir
software convencional. El proceso de reutilizacin debe encontrar los
elementos esenciales comunes y la variabilidad, as como dar prioridad
a las partes que deben ser tenidas en cuenta en la reutilizacin. La
mayora de las aproximaciones seleccionan ejemplos clave y extraen
sus conjuntos de features esenciales. Los ejemplos relacionan el
mbito del dominio con la evaluacin de las necesidades de los
usuarios, el mercado, la tecnologa y las tendencias del negocio.

IS II

ISBC

58

ISBC: FODA

3. Identificacin, recoleccin y agrupacin de

los conjuntos de features
Utilizando modelos de anlisis, tablas y/o grficos, las features que
aparecen juntas (AND) o son variantes que seleccionar (OR, XOR) se
estructuran en un marco de decisin, de esta forma la terminologa del
dominio es almacenada. En FODA un modelo de informacin describe
las entidades de dominio y las relaciones entre ellas, un modelo de
comportamiento describe las relaciones dinmicas 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

59

ISBC: FODA

4. Desarrollo de un modelo y una arquitectura

de dominio o genricos
A partir de estos conjuntos de features, un modelo de dominio resume
las caractersticas esenciales de todas o algunas de las aplicaciones del
dominio. Tambin 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

60

ISBC: FODA

5. Representacin de las partes comunes y la

variabilidad
Se identifican los subsistemas, mdulos y funciones
genricas, relacionndose entre ellas mediante
generalizaciones, especializaciones o alternativas
6. Explotacin de las partes comunes y la variabilidad
Se emplean notaciones y mecanismos para especificar
diferentes clase de productos genricos o parametrizados.
.

IS II

ISBC

61

ISBC: FODA

7. Implementacin, certificacin y
empaquetado de los elementos
reutilizables
El subconjunto ms importante de componentes
reutilizables (assets) candidatos se implementan y se
distribuyen como elementos reutilizables certificados, bajo
una poltica de gestin de la configuracin. El resto de
elementos reutilizables sern implementados cuando se
necesiten.
IS II

ISBC

62

ISBC

Procesos gemelos
Anlisis del
Dominio

modelos
de
anlisis

Diseo de la
Arquitectura

Especificacin
De Componentes

IS II

Diseo del
Dominio

Desarrollo de
Componentes

diseos
genricos

Bsqueda de
Componentes

componentes

Adapt / Des.
Componentes

ISBC

Integracin de
Componentes

63