Você está na página 1de 75

3 ARQUITECTURA DEL

ENTORNO Y TCNICAS DE
INTEGRACIN
En este captulo se inicia la toma de decisiones respecto al entorno multidisciplinar.
En primer lugar, se seleccionan los estndares de modelado y expresin formal
y la forma de usarlos en el entorno. As mismo, se define una primera aproximacin
a la arquitectura del entorno en un intento por sintetizar, en forma de bloques
funcionales relacionados, cada una de los requisitos identificados a lo largo del
captulo anterior.
Posteriormente, se definir lo que se entiende por integracin y se describirn
diferentes niveles de integracin. Lo que dar paso a un estudio de diferentes
tcnicas de integracin para resolver la colaboracin de gramticas, modelos,
tcnicas de desarrollo de SW, conocimiento y aplicaciones. Se valorarn
tcnicas muy dispares entre s pero con el comn denominador de servir para
integrar informacin, aunque con diferentes grados de abstraccin.
Las conclusiones del captulo servirn para seleccionar las tcnicas ms
adecuadas para cada uno de los niveles de integracin, y completar as la
arquitectura del entorno esbozada al inicio con ms detalles relativos a las tcnicas
a utilizar.

3.1 Arquitectura General del Entorno


3.1.1

Modelado y Expresin Formal en el Entorno

3.1.2

Requisitos y Componentes Bsicos del Entorno

3.1.3

Estructura General

3.2 Niveles de Integracin


3.3 Integracin de Gramticas
3.3.1

GSRC Semantics Project

3.4 Integracin de Modelos


3.5 Integracin de Tcnicas para Desarrollo de SW
3.5.1

Mtodos Formales

3.5.2

Separacin Multidimensional de Propsitos

3.5.3

Desarrollo de SW Dirigido a Dominio

3.5.4

Generacin de Programas con XSLT

3.6 Integracin de Conocimiento


3.7 Integracin de Aplicaciones
3.7.1

Conceptos bsicos sobre Servicios Web

3.7.2

Estilo de Arquitectura REST

3.7.3

Definiciones sobre Servicios Web

3.7.4

Escenarios de Uso de Servicios Web

3.7.4.1
3.7.4.2
3.7.4.3
3.7.4.4
3.7.4.5
3.7.4.6
3.7.4.7

3.7.5

Escenario
Escenario
Escenario
Escenario
Escenario
Escenario
Escenario

0:
1:
2:
3:
4:
5:
T:

Interaccin web clsica (sin servicios web)


Partes conocidas, WSD esttico
Partes conocidas obtienen WSD dinmicamente
Mltiples proveedores, descubrimiento manual
Mltiples proveedores, acceso a WSD del proveedor
Mltiples proveedores, seleccin automtica
Diagrama en tringulo

Tecnologas para Servicios Web

3.8 Conclusiones
3.8.1

Integracin de Gramticas (Gramticas XML de Dominios)

3.8.2

Integracin de Modelos (Modelos de Dominio)

3.8.3

Integracin de Tcnicas para Desarrollo de SW (DIRECTOR)

3.8.4

Integracin de Conocimiento (Repositorio)

3.8.5

Integracin de Aplicaciones (Interfaz de Herramientas)

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..11 A
GEEN
EN
NT
QU
NE
TO
UIIT
ER
OR
RA
RN
TE
AL
NO
ARRQ
EC
LD
O
CT
TU
DE
UR
EL
RA
LE
AG
Sobre las conclusiones del recorrido del Estado del Arte del captulo
anterior, conclusiones en forma de seleccin de estndares para el
modelado y la expresin formal, requisitos identificados y arquitectura de
bloques en la que se fundamentar el entorno.

3.1.1 MODELADO Y EXPRESIN FORMAL EN EL


ENTORNO
Aplicando al entorno multidisciplinar las ideas sobre niveles de abstraccin
expuestas en el captulo anterior, se identifica la necesidad de construir cuatro
jerarquas de abstraccin (en principio independientes) para representar la visin
del SCDTR desde cada uno de los dominios involucrados (IC, SD, STR e IS). Dado
un sistema concreto en desarrollo, cada dominio selecciona (a partir del conjunto
total de informacin existente) el subconjunto de datos relevantes para su campo
(objetos de dominio). Estos datos y sus relaciones se describen dando forma al
modelo particular de dominio del sistema. Por tanto, en este trabajo se
entiende por modelo la abstraccin o descripcin parcial y particular de las
caractersticas (comportamiento, estructura, funcionalidad,...) del sistema bajo
desarrollo. Para aadir formalidad a estas descripciones y tener la posibilidad de
validar la correccin de diferentes modelos de acuerdo a los parmetros propios del
dominio es necesaria la existencia de un nivel superior o metamodelo del
domino. El metamodelo define el lenguaje a emplear para construir nuevos
modelos, o descripciones de sistemas de acuerdo a las convenciones establecidas
por un dominio, y con ello introduce formalidad o mecanismos de validacin de las
descripciones.
En resumen, se plantea la necesidad de definir cuatro metamodelos porque cada
dominio usar diferentes objetos de dominio, es decir, tendr un subconjunto de
informacin diferente en el nivel de dato.
Se considera interesante la arquitectura de 4+1 vistas en tanto que esta
arquitectura coincide con la visin adelantada en el captulo inicial de esta memoria.
En ambos casos se separan los modelos en funcin del profesional que los vaya a
usar y tambin se considera necesario el empleo de una notacin o lenguaje
especializado para la descripcin del sistema desde cada uno de los dominios. Hay
que destacar el inters de construir estos lenguajes especializados utilizando en
todos los casos un ncleo comn formado por componentes y conectores. La
existencia de ese ncleo expresivo comn facilitar dar forma a las relaciones entre

Pg. 3-1

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

modelos. nicamente, y por razones ya comentadas, se extender en la


arquitectura de 4+1 vistas la capacidad de expresin jerrquica de los sistemas.
UML 1.4 desarrolla estos conceptos y define una rica coleccin de vistas en forma
de diagramas orientados a objetos, permitiendo mltiples enfoques para un mismo
problema. La potencia de este lenguaje radica en su flexibilidad expresiva y
capacidad de adaptacin. Pero esta virtud le hace carecer de rigurosidad y
formalidad cuando se trata de asegurar la coherencia global del modelo y sus
instancias. Como uno de los requisitos del entorno multidisciplinar es la capacidad
de validar la correccin de las instancias respecto al metamodelo, UML 1.4 parece
incompleto como soporte de los metamodelos de dominio y sus instancias. Adems,
sigue careciendo de la jerarqua formal deseable. Como ambas carencias prometen
ser paliadas en la prxima versin del lenguaje (UML 2.0), es una posibilidad de
futuro la expresin de los metamodelos de dominio y sus instancias en este
estndar.
En la filosofa MDA (Model Driven Architecture) de OMG la definicin y relacin
entre PIM y PSM, la formalidad introducida por MOF y la serializacin de modelos e
instancias con XMI tienen a UML como punto comn de referencia. A pesar de ello,
el que UML no sea el lenguaje inicialmente elegido para el modelado de dominio en
el entorno no implica dar la espalda a todos los dems estndares. De hecho, se
propone desarrollar el entorno en sintona con esta filosofa y dejar preparado el
camino para que en un futuro UML pueda ser el lenguaje de modelado inicial y XMI
pueda tender directamente los puentes hacia la expresin en XML de esos modelos
e instancias.
XML s parece colmar conjuntamente las necesidades de expresin flexible y
adaptable a diferentes campos junto con la validacin formal de las instancias. Su
papel de metalenguaje, permitiendo la creacin de lenguajes formales a travs de
schemas, y el complemento de XSL (transformaciones entre lenguajes) le hacen
convertirse en un candidato ideal.
Incluso si UML 2.0 (y estndares asociados) cumplen todas las expectativas, XML
seguir siendo necesario para el intercambio de informacin entre diferentes
plataformas, entre diferentes herramientas MOF o entre herramientas MOF y otras
no MOF (necesidad de validacin previa).
En resumen, en lo concerniente al modelado y expresin formal de la informacin
en el entorno multidisciplinar se toman las siguientes decisiones:

 Definir los metamodelos de los cuatro dominios implicados. Los modelos o


instancias de los mismos sern las descripciones del sistema desde los
enfoques particulares.

 Usar schemas XML para definir los metamodelos de dominio. stos fijarn
todos los requisitos a cumplir por las instancias (descripciones de sistemas
particulares hechas de acuerdo al metamodelo de dominio). Estos schemas

Pg. 3-2

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

XML servirn de gramticas formales del lenguaje a emplear desde cada


dominio.

 Construir los lenguajes extendiendo y especializando un ncleo expresivo


comn

que

soporte

la

descripcin

jerrquica

del

sistema

en

base

componentes y conectores.

 Seguir en la medida de lo posible los preceptos del MDA. Por una parte,
distinguir el nivel de abstraccin de la aplicacin independiente de detalles
(PIM), otro con detalles propios de la plataforma de desarrollo (PSM) y, por
ltimo, la implementacin final. Por otra parte, establecer mecanismos para
automatizar y formalizar el paso entre dichos niveles de abstraccin. De este
modo sern evidentes las ventajas obtenidas en cuanto a reutilizacin de
modelos y formalizacin del proceso.

 Preparar la adopcin futura de UML 2.0 como lenguaje soporte de los


metamodelos de dominio. Esto permitira :
generacin automtica desde UML de gramticas XML (schemas) e
instancias (documentos) gracias a XMI o al empleo de perfiles que modulen
la creacin de XML a voluntad del diseador
generacin automtica desde UML del cdigo que implemente los interfaces
entre herramientas y modelos de dominio para diferentes plataformas (Java,
C++, CORBA,)
adopcin del perfil de tiempo real como metamodelo de dominio para STR
(Sistemas de Tiempo Real)
Cabe destacar que aunque se descarta el empleo de UML para el modelado formal
de los dominios esto no implica que no pueda existir una herramienta UML
integrada en el entorno. Una herramienta UML podra usarse, por ejemplo, para
especificar la arquitectura SW del sistema, pero el resultado de su uso habra que
expresarlo en XML y validarlo contra su metamodelo correspondiente (schema
XML).

Pg. 3-3

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.1.2 REQUISITOS Y COMPONENTES BSICOS DEL


ENTORNO
El anlisis realizado en el Estado del Arte sobre las herramientas especficas de
dominio habituales en cada uno de los campos de estudio, ha permitido identificar
varios requisitos que deben guiar la construccin del entorno multidisciplinar de
herramientas:
La trazabilidad ha demostrado ser una propiedad fundamental cuando se trata
de coordinar diferentes fases de desarrollo y an ms cuando se emplean
diferentes herramientas. Esta propiedad deber ser intrnseca al propio entorno
y, por tanto, no basada en ninguna herramienta particular.
El Ncleo del Entorno debe ser independiente de cualquiera de las
herramientas integradas. Frente a la opcin de tomar una herramienta
suficientemente genrica como centro del entorno e ir amplindola con mdulos
paralelos que complementen su funcionalidad, se opta por disear una
arquitectura

horizontal

almacenamiento

adecuada,

propios,

ir

con

funcionamiento

acomodando

las

formato

herramientas

de

especficas

verticales a esta arquitectura y forma de trabajo.


Para cada uno de los dominios especficos se han detectado conceptos clave
que se constituyen en criterios de clasificacin de grupos de herramientas y, por
tanto, en parmetros de configuracin para el Ncleo del Entorno:

Sistemas Distribuidos. El Protocolo de Comunicacin elegido para el


sistema en desarrollo determina el grupo de herramientas de ayuda que
pueden necesitarse.

Sistemas de Tiempo Real. El Estilo de Arquitectura demuestra ser clave y


tener implicaciones directas en herramientas de anlisis, pero tambin en el
diseo. Son limitados los estilos de arquitectura empleados en Sistemas de
Tiempo Real (secuencial, dirigida a eventos, pipeline, cliente-servidor) pero
no se va a disear un entorno que soporte uno solo de ellos, sino que se
permitir seleccionar el ms adecuado en cada proyecto. El estilo elegido
para el sistema en desarrollo determinar qu subconjunto de herramientas
pueden usarse y qu sinergias existirn entre ellas. La Metodologa es un
concepto an ms amplio que engloba el estilo de arquitectura y restringir
an ms el nmero y forma de utilizar las herramientas.

Ingeniera del SW. Es necesario el uso de un Proceso de SW adaptado a las


necesidades de los SCDTR, pero configurable y modificable por el usuario en
sus detalles para que se adapte a las necesidades propias del campo de
aplicacin y al Nivel de Madurez CMM de la organizacin. La visibilidad o
expresin

Pg. 3-4

explcita

del

Proceso

su

gestin

desde

una

entidad

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

independiente de cualquier herramienta ofrecer esta flexibilidad de cara al


usuario.
El Ncleo del Entorno debe ser flexible, para adaptarse con facilidad a
necesidades futuras, y abierto para integrar en cada momento a la herramienta
especfica ms adecuada. Esto se conseguir a travs del uso de estndares
para la implementacin de los componentes anteriores
El Ncleo del Entorno se asemeja a los entornos I-CASE descritos en el captulo
anterior en que tambin debe ofrecer una arquitectura comn en la que integrar
herramientas de diferente naturaleza. Por ello, se identifican los siguientes
Componentes Bsicos, anlogos a los de dichos entornos:
Repositorio de informacin comn a todas las herramientas.
Componente de integracin de modelos. Contiene la definicin explcita de
los cuatro metamodelos de dominio, sus relaciones y la relacin de los
metamodelos con las herramientas particulares en base a ciertos metadatos.
Componente DIRECTOR, desde donde se controlan todos los mecanismos de
activacin, se comprueban y gestionan de forma global los errores, la integridad
y la consistencia.
Interfaces de herramientas. Debe estandarizarse el formato y protocolos de
intercambio de datos entre las herramientas y el entorno.
Interfaz de usuario comn para la configuracin del entorno.
El estudio hecho en el Estado del Arte sobre algunos intentos de integracin de
dominios en forma de entornos de herramientas arroja las siguientes coincidencias
entre varias soluciones propuestas:

9 Uso de XML como formato preferido para la integracin de informacin.


9 Uso de Java como lenguaje de programacin preferido para el SW de
integracin

9 Uso de documentos (normalmente en XML) anexos a los mdulos para


describir la informacin necesaria para su integracin con otros.

9 Uso generalizado de la abstraccin como concepto fundamental en el que


basar la integracin.

9 Uso de gramticas abstractas con los elementos sintcticos a emplear en


todo el entorno, aunque luego se le aada la semntica particular de cada
dominio.

9 Uso de entidad director o similar para coordinar las diferencias semnticas


entre dominios valindose de la estructura comn de los lenguajes.

Pg. 3-5

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

9 Concepto

de

METAframework

infraestructura

necesaria

para

la

composicin de frameworks. Hasta ahora el diseo se ha centrado en la


consideracin de cuatro dominios y de las relaciones entre ellos, pero por
qu slo cuatro?, cmo se integrara uno ms? Si se es capaz de expresar
el metamodelo del que emergen los cuatro dominios, la definicin de un
nuevo modelo bajo esos mismos principios asegurara su colaboracin con
los dems en el entorno. Esta idea del metamodelado se desarrollar para
formalizar los mecanismos de ampliacin de los dominios considerados en el
entorno.
El siguiente apartado definir la estructura general del entorno, que estar
compuesta por el conjunto de componentes aqu enumerados y permitir satisfacer
los requisitos identificados. La cohesin y coherencia del entorno se fundamentar
en el uso de diferentes tcnicas de integracin a varios niveles.

Pg. 3-6

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.1.3 ESTRUCTURA GENERAL


Las pautas enumeradas conducen a un diseo del entorno como el mostrado en la
Figura 3-1. Las herramientas particulares son empleadas por los especialistas en la
manera habitual, pero se conectan como clientes al Motor de Colaboracin de
Herramientas (MCH), que hace las funciones de servidor. El tipo de servicio que
ofrece el MCH es de almacenamiento, validacin y coordinacin de la informacin
del SCDTR bajo desarrollo. El MCH ofrece estos servicios apoyndose en el Motor
de Colaboracin de Modelos (MCM).
La capa ms externa del MCH gestiona un flujo de informacin vertical y en ambos
sentidos entre cada herramienta y el propio MCH, mientras que el MCM gestiona
otro flujo de informacin transversal que permite coordinar y actualizar los datos
que importan las herramientas.
Existir un amplio conjunto de herramientas particulares (siempre ampliable)
registradas en el entorno, es decir, conocidas en cuanto a su comunicacin con el
MCH, la funcin que desempean, las informaciones que requieren intercambiar,
etc.

Pero

cada

proyecto

requerir para

su

desarrollo

un

subconjunto

de

herramientas de entre las registradas y el responsable del proyecto las seleccionar


y configurar el entorno para su interaccin a lo largo del proceso particular de
dicho proyecto.

...

Especialistas

...

Herramientas

...

Interfaces

MOTOR DE COLABORACIN DE HERRAMIENTAS (MCH)


MOTOR DE COLABORACIN DE MODELOS
(MCM)
Figura 3-1. Estructura del entorno multidisciplinar

La capa ms externa del MCH debe resolver los interfaces a las herramientas
particulares, as como al coordinador (que configura el funcionamiento del entorno
para la gestin de cada proyecto).

Pg. 3-7

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Los componentes del Motor de Colaboracin de Herramientas incluyen los que ya


han sido mencionados, ms la novedad de la entidad DIRECTOR, ncleo del MCM.
En este componente se centralizan todas las actividades de integracin:

 Control del proceso de desarrollo. En funcin de la informacin aportada por el


coordinador se configurar el proceso y el DIRECTOR obligar a seguir las fases
marcadas.

 Gestin de activaciones para invocar las acciones necesarias en cada momento.


 Control de la trazabilidad, ntimamente ligado al proceso SW seguido.
 Comprobacin global de errores, coherencias e integridad de la informacin.
Especialistas

Coordinador

Interfaz
Config

Interfaz herramientas
MOTOR DE
COLABORACIN
MOTOR DE
DE
COLABORACIN HERRAMIENTAS
DE MODELOS
(MCH)
(MCM)

DIRECTOR

Modelos de Integracin
Repositorios

Metadatos
Figura 3-2. Componentes del MCH.

En la Figura 3-2 se puede apreciar cmo quedan los componentes del entorno con
la inclusin del DIRECTOR y la expresin explcita de los modelos de interaccin
para su manipulacin. Adems, se identifican dos roles de usuarios del entorno:

Coordinador de proyecto. Es quien impone al DIRECTOR, a travs de un


interfaz de configuracin, las pautas a seguir en el uso de las herramientas
externas. Tiene que conocer el funcionamiento del MCH para configurarlo.
Define el conjunto concreto de herramientas a usar, un estilo de
arquitectura o metodologa de tiempo real determinada, protocolos de
comunicacin para la distribucin del control, un determinado proceso de
SW,

etc.

Estas

decisiones,

que

determinarn

las

sinergias

incompatibilidades que entran en juego, sirven para configurar el mdulo

Pg. 3-8

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

DIRECTOR. Toda esta informacin se emplear para coordinar todo el


entorno a lo largo de la vida del proyecto.

Especialista. Usuario final de cada una de las herramientas integradas.


Hace uso de una herramienta bien conocida a partir de la informacin que le
facilita el entorno y de las pautas indicadas por el coordinador.

El diagrama de componentes bsicos mostrado en la Figura 3-2 se ir completando


en ms detalle a lo largo del presente captulo y se desarrollar el diseo final de
cada bloque en el captulo siguiente.

Pg. 3-9

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Pg. 3-10

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..22 N
NT
TE
EG
GR
RA
NIIVVEELLEESS D
AC
CII
DE
E IIN
N
N
Sobre lo que se entiende por integracin y las tcnicas disponibles para
lograrla a diferentes niveles.
Una vez establecido que las diferentes herramientas del entorno se integrarn
gracias a un Motor de Colaboracin de Herramientas (MCH) externo que gue el
proceso, cabe preguntarse qu tcnicas son las ms apropiadas para que el MCH
logre ese propsito de integracin.
Dado un conjunto de aplicaciones autnomas, cada una ejecutndose en su propio
contexto, la interaccin entre ellas se consigue si:

1. Existe una conexin fsica y un protocolo de comunicacin para que los datos
fluyan entre los contextos de ejecucin de las aplicaciones. Actualmente, la
omnipresencia de internet con sus protocolos TCP/IP hace que sea la opcin
ms estndar para el intercambio de informacin entre dos aplicaciones
cualesquiera independientemente de su ubicacin.

2. Existe un acuerdo en el formato de los datos para su intercambio (texto


ASCII, XML, representacin en memoria, chorro de bits). Por las razones
aducidas en el captulo anterior, XML se perfila como el formato ms
estndar, universal y de amplia aceptacin.

3. Existe un acuerdo en el lxico y sintaxis empleados para la expresin de la


informacin.

4. Existe un acuerdo respecto a los tipos de datos (rangos vlidos, herencia,


polimorfismo, estructuras,).

5. Existe un acuerdo en el significado que se da a los datos, lo que se espera


de ellos, las relaciones que se establecen, el procesado que se les dar.

6. Existe un acuerdo en la relacin o manera de mantener la coherencia entre


cualesquiera dos datos de dos herramientas diferentes pero con una relacin
semntica conocida.

7. Existe un acuerdo en los interfaces que cada aplicacin ofrece para la


entrada y salida de datos
Los puntos 3, 4 y 5 hacen referencia a un acuerdo en cuanto a la gramtica
empleada, que como se ver, tiene que reflejar las peculiaridades de cada campo
de aplicacin pero manteniendo un ncleo comn a todas las dems. Para lograr
una solucin abierta y flexible, los puntos 6 y 7 conviene resolverlos de forma

Pg. 3-11

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

acorde a tecnologas estndares y ampliamente aceptadas, que se discutirn a lo


largo de este apartado.
En definitiva, se trata de llegar a acuerdos entre las partes implicadas, pero estos
acuerdos pueden ser de muy diversa naturaleza:

Acuerdos tcitos o explcitos. En ocasiones, se siguen acuerdos no escritos


para hacer que se entiendan dos aplicaciones. En este trabajo se intenta
hacer explcito cualquier acuerdo porque esto es necesario para poder
modificar los trminos del acuerdo o para generalizarlo y lograr la
interaccin con otras aplicaciones cualesquiera.

Acuerdos punto a punto o genricos. Para comunicar dos aplicaciones basta


con ponerse de acuerdo entre ellas, pero para lograr comunicar un nmero
indeterminado de aplicaciones no definidas de antemano, es necesario
imponer unas normas genricas que permitan interactuar a toda aplicacin
que las cumpla.

La propia interaccin entre las aplicaciones puede ser manual o guiada. Es decir,
dirigida a su libre albedro por el usuario (que indica en qu momento invocar una
aplicacin y con qu datos trabajar) o conducida por una entidad directora que siga
unas reglas prefijadas y regule los pasos a seguir, los datos a emplear y la
coherencia de todo el proceso. Como ya se ha descrito, los procesos y metodologas
para el desarrollo de SW requieren de una regulacin de las fases de su ciclo de
vida que aconseja una interaccin guiada. Por ello se propone que sea llevada a
cabo por la entidad DIRECTOR.
Una vez que las aplicaciones son capaces de interactuar (porque se han resuelto de
alguna manera los 7 puntos anteriores) se pueden definir diferentes niveles de
integracin:

Aplicaciones integrables. Por cumplir todos los requisitos para interactuar


se puede escribir un SW que las integre.

Aplicaciones integradas entre tiempos de ejecucin. Cada aplicacin


funciona segn sus propios tiempos pero los resultados que se obtienen al
terminar su uso se sincronizan con la informacin que ya exista. Por cada
uso de una aplicacin se comprobar la coherencia de los resultados con
todo lo anterior.

Aplicaciones integradas en tiempo de ejecucin. En el propio tiempo de


ejecucin, una aplicacin es capaz de comunicase e interactuar con otras.

En definitiva, se pueden completar un poco ms las caractersticas del MCH


aadiendo las siguientes:

 El MCH usar conexiones sobre TCP/IP para comunicarse con las herramientas.

Pg. 3-12

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

 La informacin a intercambiar entre herramientas y MCH se expresar en


formato XML. Siendo as, lo ms lgico es que los repositorios tambin
almacenen la informacin en este formato.

 Se definirn gramticas XML ajustadas a las necesidades de cada uno de los


dominios: Ingeniera de Control (IC), Sistemas Distribuidos (SD), Sistemas de
Tiempo Real (STR) e Ingeniera del SW (IS). De este modo, la informacin
intercambiada entre una determinada herramienta y el MCH se expresar
siempre en la gramtica propia de su dominio.

 El DIRECTOR llevar a cabo una integracin entre tiempos de ejecucin, es


decir, se encargar de sincronizar la informacin global cada vez que se
reporten resultados desde alguna de las herramientas.

 Los acuerdos necesarios para la integracin de herramientas se hacen


genricos ya que hacen referencia a las interacciones entre los diferentes
dominios especficos y no a la existente entre herramientas concretas. Estos
acuerdos se engloban en un conjunto de Modelos de Dominios que estarn
ntimamente ligados a las Gramticas de Dominio.

 Los acuerdos se hacen explcitos porque se expresan en forma de modelos y


gramticas modificables, y por tanto extensibles.
La Figura 3-16 muestra como queda el MCH con estas aportaciones. El DIRECTOR
lleva la iniciativa y usa los servicios que le ofrecen las aplicaciones de forma
coordinada y coherente, basndose en los modelos y gramticas de dominio.

Pg. 3-13

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Gramtica de
dominio
comn para
diferentes
herramientas

IC

IC

SD

STR

IS

Informacin en la gramtica
XML de cada dominio
Informacin XML sobre
conexiones TCP/IP

Interfaz
Config

Interfaz Herramientas
Sincronizacin en instantes de
entrada / salida de informacin
desde una herramienta

DIRECTOR
Modelos
Dominios

Gramticas
XML Dominios

Repositorios
XML

Metadatos
Figura 3-3. Estructura del MCH.

En los siguientes apartados se presentarn algunas tcnicas adecuadas para la


implementacin de cada una de las partes de este esquema. Concretamente, y por
orden de aparicin de los apartados, se describirn soluciones para los bloques de
Gramticas (3.3 Integracin de Gramticas), Modelos de Dominio (3.4 Integracin
de Modelos), DIRECTOR (3.5 Integracin de Tcnicas para Desarrollo de SW),
Repositorio (3.6 Integracin de Conocimiento) e Interfaz de Herramientas (3.7
Integracin de Aplicaciones).

Pg. 3-14

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..33 IIN
NT
GRRAAM
TE
EG
M
GR
T
RA
TIIC
AC
CII
CA
ASS
N
ND
DE
EG
Sobre los niveles de servicio que puede implementar una gramtica y el
grado de compatibilidad entre gramticas distintas.
Para que varias personas se puedan comunicar y se entiendan entre s, es
necesario que empleen el mismo lenguaje. Del mismo modo, para que puedan
comunicarse entre s un conjunto de herramientas deben expresar, hasta cierto
punto, de la misma forma aquellas informaciones que pretendan intercambiar. La
solucin podra ser la creacin de un lenguaje comn, lo suficientemente rico y
extenso como para cumplir dos requisitos:

El lenguaje debe poder describir la informacin que manejen todas las


herramientas a integrar.

El lenguaje debe poder representar todas las relaciones cruzadas entre


informaciones de diferentes herramientas.

Esta solucin permitira importar y exportar toda informacin entre herramientas,


siempre que estuviera expresada en ese lenguaje. El problema surgira cada vez
que se pretenda integrar una nueva herramienta no considerada en un principio. Si
el lenguaje comn no fuera capaz de expresar algn tipo de informacin manejada
por la nueva herramienta, sera necesaria su modificacin y ampliacin.
Para ganar flexibilidad y generalidad en la solucin, conviene usar un lenguaje ms
abstracto en el que se asuman slo unos pocos elementos comunes a la
informacin de todas las herramientas que pretendan ser integradas.
Se va a profundizar a continuacin en un proyecto que trabaja en esta lnea de
investigacin, el GSRC Semantics Project.

Pg. 3-15

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.3.1 GSRC SEMANTICS PROJECT


Gigascale Silicon Research Center (http://www.gigascale.org/) es una entidad que
ana los esfuerzos de multitud de grupos de investigacin para el diseo y test de
sistemas
Uno

de

empotrados.
sus

proyectos

es

el

GSRC

Semantics

Project

(http://www.gigascale.org/semantics). Este proyecto persigue la interoperatividad


de herramientas para el diseo de sistemas.
Identifican el mismo problema que se ha descrito en el primer captulo de esta
memoria, es decir, la necesidad de enfocar un mismo sistema de diferentes formas
para tratar diferentes problemas y la dificultad de conseguir que los cambios
producidos en uno de estos enfoques sigan siendo coherentes en los dems. Tal y
como muestra la Figura 3-4, se pueden obtener mltiples facetas de un sistema al
proyectarlo respecto a diferentes ejes o puntos de vista pero si se modifica una de
esas facetas hay que conseguir que siga siendo coherente con las dems. Por otra
parte, tambin es deseable poder manejar diferentes niveles de abstraccin para
cada una de las facetas (Figura 3-5).

Figura 3-4. Proyeccin de las facetas de un sistema y su consistencia.

Estas facetas se pueden identificar con las representaciones del sistema de acuerdo
a diferentes herramientas y lograr la coherencia entre las mismas sera lo mismo
que

conseguir

interoperatividad

entre

las

herramientas.

Para

lograr

esta

interoperatividad, no buscan la creacin de un lenguaje estndar de diseo comn


para todas, si no que intentan identificar el uso de ciertos elementos comunes y
formalizarlos para establecer la base comn a todas las herramientas. De este
modo, definen modelos sintcticos y semnticos para el diseo de sistemas
basndose en el uso de componentes, su interaccin y su composicin (Lee 2000).

Pg. 3-16

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Figura 3-5. Niveles de abstraccin de cada faceta.

En la especificacin de un lenguaje se anan las descripciones de varias


propiedades ortogonales. El tratamiento por separado de las mismas permite varios
niveles de compatibilidad. La definicin de un lenguaje puede dividirse en cinco
partes (servicios) agrupadas en dos bloques:

 Estructura lgica:
Sintaxis

abstracta.

Define

cmo

un

diseo

puede

dividirse

en

componentes interconectados. El conjunto de componentes y relaciones que


pueden aparecer en un diseo conforman una sintaxis abstracta.
Sintaxis

concreta,

notacin.

Define

cmo

un

diseo

puede

ser

representado y manipulado en un formato persistente y usable por el


ordenador (XML, APIs, fichero ASCII, grfico,). Pueden existir mltiples
sintaxis concretas derivadas de una nica sintaxis abstracta.
Transformaciones

sintcticas.

Un

conjunto

de

operaciones

(tanto

estticas como dinmicas) permiten transformar un diseo en otro.

 Significado:
Sistema de tipos. Regulan los datos compartidos por los componentes y
aseguran que se cumplen los requisitos que los componentes imponen a
esos datos. El polimorfismo es

una cualidad conveniente para dar

generalidad a los diseos.


Semnticas (de componentes y de interaccin). Da significado a las
caractersticas de cada componente y a sus conexiones con otros.
Un determinado diseo se representa con un lenguaje concreto que incluye los
cinco servicios mencionados. Sin embargo, las herramientas que se utilizan para
manejar ese modelo no tienen porque ser conscientes de todas las partes del
lenguaje. Habr herramientas que soporten slo alguna de las partes del lenguaje.

Pg. 3-17

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Por ejemplo, un visualizador grfico que muestre las relaciones entre componentes
no necesita conocer la semntica ni los tipos (le basta con conocer la sintaxis
abstracta), mientras que un motor de inferencia de tipos necesita conocer el
sistema de tipos adems de la sintaxis abstracta.
En base a estos conceptos se puede clasificar la interoperatividad entre
herramientas a diferentes niveles:
1. Sintaxis abstracta compatible. Es posible escribir SW ad hoc que convierta
datos de una herramienta en datos utilizables en otra.
2. Sintaxis concreta compatible. Una herramienta puede leer datos en el
formato persistente de otra (ficheros externos) sin necesidad de escribir SW
especial.
3. Transformaciones

sintcticas

compatibles.

Es

posible

generar

automticamente datos de entrada para una herramienta a partir de los


resultados de otra.
4. Sistema de tipos compatible. Intercambio automtico de modelos de datos
completos entre herramientas.
5. Semnticas compatibles. Las herramientas pueden intercambiar datos
dinmicamente, en tiempo de ejecucin.
Cuando se busca la interoperatividad entre un conjunto lo suficientemente amplio y
diverso de herramientas de diseo, enseguida es evidente que no basta con un
nico formato estndar para representar adecuadamente una sintaxis y semntica
comn para todas. Existe una variedad de modelos semnticos para sistemas
basados en componentes y cada uno tiene sus ventajas y su campo de aplicacin.
Por ello, se busca un acuerdo en lo ms bsico, la sintaxis abstracta. Una sintaxis
abstracta comn para herramientas de diseo de sistemas debe ser capaz de
describir listas de conectividad, diagramas de transicin de estados, diagramas de
bloques, modelos de objetos y estructuras grficas, adems de permitir el uso
extensivo de la jerarqua para lograr escalabilidad. stas son las caractersticas que
rene la sintaxis abstracta GSRC.
Resumen de las caractersticas del proyecto GSRC:

 Definicin por separado de cada una de los cinco servicios constitutivos de un


lenguaje:
Sintaxis abstracta. Definicin de componentes y posibles relaciones entre
ellos, capacidades de jerarqua, conectividad e instanciacin de clases.
Sintaxis concreta. MoML es una sintaxis concreta XML para la sintaxis
abstracta de GSRC. MoML no aade significado al modelo, en su lugar,
permite aadir un director al modelo. El director definir la semntica de las
conexiones pero para MoML no es ms que la referencia a una instancia que
cargar el cargador de clases.

Pg. 3-18

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Transformaciones sintcticas. Definicin de las posibles operaciones en los


modelos

(creacin

de

puertos,

relaciones,

enlaces,

entidades,

etc).

Aplicaciones como los editores visuales de modelos o las herramientas de


instanciacin hacen uso de las mismas.
Sistemas de tipos. Los propios de cada dominio para permitir el uso de
interfaces polimrficos que evitan la necesidad de escribir adaptadores de
protocolo entre interfaces rgidos predefinidos.
Semnticas de componentes y de interaccin. Definicin de todos los
significados posibles de los componentes: estados, procesos, threads,
ecuaciones diferenciales, requisitos, objetos, etc. Sobre esta ontologa de
componentes definida para cada dominio se especifican las semnticas de
interaccin entre componentes.

 Beneficios de la ortogonalizacin:
Diferentes niveles de interoperatividad
Terminologa independiente de sintaxis concreta
Se enfatizan frameworks en lugar de lenguajes

Pg. 3-19

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..44 IIN
NT
MO
OD
TE
DE
EG
EL
GR
LO
RA
OSS
AC
CII
N
ND
DE
EM
Sobre la adopcin del paradigma de modelado 4+1 y los estndares MDA
y MOF en el entorno multidisciplinar.
Se aprecia un claro paralelismo entre el entorno multidisciplinar y la estructura
4+1 descrita en el Estado del Arte. En ambos casos hay un especialista detrs de
cada una de las vistas, las vistas sirven diferentes propsitos y existe un orden
lgico de uso:

 Vista Ingeniera de Control. El ingeniero de control especifica el sistema en


base a la funcionalidad que pretende obtener y a la interaccin de los
controladores con el proceso.

 Vista Sistema Distribuido. El especialista en redes de comunicacin parte de la


informacin anterior para distribuir los controladores, sensores y actuadores en
diferentes nodos dentro de una determinada topologa de red. Adems,
especifica las caractersticas de los enlaces de comunicacin.

 Vista Sistema de Tiempo Real. El ingeniero de tiempo real parte de las vistas
anteriores y establece un reparto adecuado de los recursos locales a cada nodo
para cumplir con los requisitos temporales que se imponen.

 Vista de Ingeniera del SW. El ingeniero de SW hereda una especificacin


completa y vlida del sistema y realiza las labores necesarias para la
integracin del cdigo y la generacin de documentacin.
Desde el punto de vista del MDA se puede asemejar la vista de Sistemas de Control
al PIM (Platform Independent Model) y el resto de las vistas al PSM (Platform
Specific Model). Esto es as porque la descripcin funcional realizada desde el punto
de vista de control no debe depender de ninguna caracterstica propia de
plataforma y debe iniciar el ciclo de desarrollo porque el objetivo prioritario del
sistema ser el de resolver algn problema de control. Las otras tres vistas van
completando esa descripcin inicial y van aadiendo todos los detalles propios de la
plataforma,

lo

que

permite

generar

el

cdigo

documentacin

de

la

implementacin final.
Aplicando las pautas de modelado de MOF para formalizar cada una de las vistas
del entorno multidisciplinar, se pueden distinguir los siguientes niveles de
abstraccin:

M3. Meta-metamodelo para la definicin de un lenguaje basado en


componentes y conectores que permita describir sistemas con jerarqua.
Este nivel toma la forma de un schema XML genrico.

Pg. 3-20

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

M2. Metamodelo de cada dominio especfico. A travs de mecanismos de


herencia se extiende M3 particularizando el schema genrico a las
necesidades expresivas de un rea concreta. Por tanto, se crearn cuatro
schemas especficos para dar soporte a los cuatro metamodelos

M1. Modelo del sistema en desarrollo. Se especifican las caractersticas del


sistema creando instancias para los cuatro schemas anteriores.

M0. Objetos de Dominio son los componentes o unidades mnimas de


modelado. Difieren en cada uno de los dominios.

Esta jerarqua formal de abstraccin vertical debe acompaarse de mecanismos


para regular el flujo horizontal de informacin y la validacin horizontal de
implicaciones entre vistas. Estas necesidades se cubrirn de la siguiente forma:

 Flujo horizontal de informacin: XSLT habilitar las transformaciones a


nivel de modelo para sincronizar las descripciones. Es decir, para extraer de un
modelo las informaciones que incumben tambin a otro y generar la versin
bsica del segundo modelo, versin que se ir completando despus con las
aportaciones

de

las

herramientas

de

dominio.

Este

mecanismo

de

sincronizacin entre modelos de diferentes dominios se facilita porque todos los


lenguajes tienen un ncleo expresivo comn (componentes y conectores).

 Validacin horizontal de implicaciones entre vistas: Adems de la


formalizacin (basada en schemas) que se hace dentro de cada dominio, es
necesario

formalizar

las

relaciones

entre

metamodelos

para

realizar

validaciones. Pero la expresin de estas relaciones cruzadas necesita de algn


mecanismo diferente al de los schemas XML porque son especificaciones en
forma de reglas ms que especificaciones sintcticas o gramaticales. Por tanto,
habr que completar la formalizacin vertical de cada dominio con un Lenguaje
para la Especificacin de Reglas (LER) que permita expresar reglas cruzadas de
validacin horizontal, involucrando a varios dominios.
La

adopcin

de

una

estructura

de

modelado

acorde

con

MOF

permitir

aprovecharse de las ventajas de las nuevas versiones de UML, MOF y XMI. Se


podrn expresar formalmente los cuatro niveles en MOF-UML, derivando cada nivel
del anterior. A partir de este punto, se podra comprobar la coherencia
directamente en UML, realizar anlisis, simulaciones, etc. Tambin se podran
generar automticamente con XMI los schemas que dan soporte a los metamodelos
y exportar o importar las propias instancias, generar automticamente las hojas de
estilo XSLT que implementan las transformaciones automticas entre modelos,
generar automticamente las reglas de validacin horizontal, generar cdigo para el
manejo de las estructuras de datos definidas, usar CWM como soporte formal para
los repositorios de schemas y de documentos XML, etc.
Por ltimo, tambin se pueden aplicar los conceptos de PIM y PSM de MDA al propio
entorno multidisciplinar, adems de a las vistas manejadas. Se trata de un entorno
genrico e independiente de las herramientas, que se puede denotar como TIM

Pg. 3-21

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

(Tool Independent Model), pero cuando se configura un conjunto de herramientas


concretas para su uso en un determinado proyecto se constituye un TSM (Tool
Specific Model). Es decir, el funcionamiento interno del entorno se fundamenta en
la abstraccin de las vistas y sus interacciones (TIM), pero las herramientas
concretas de desarrollo que se vayan a emplear deben engancharse a los modelos
formales para crear una instancia concreta y especfica del entorno (TSM) para un
determinado proyecto.

Pg. 3-22

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..55 IIN
NT
TCCN
TE
EG
NIIC
GR
RA
CA
AC
ASS PPA
CII
N
ND
AR
RA
DE
A
ET
D
DEESSAARRRRO
SW
W
OL
LL
LO
OD
DE
ES
Sobre la manera de reflejar en el cdigo final las especificaciones o
requisitos provenientes de diferentes especialistas.
Tal y como se mencionaba en el primer captulo de esta memoria, la disciplina de
Ingeniera del SW, de alguna forma, envuelve a las dems reas involucradas, en el
sentido de que el Proceso de creacin de SW debe pasar por unas fases fijadas de
antemano y seguir unas pautas que aseguren el logro de requisitos genricos como
calidad de SW, reutilizacin de componentes, trazabilidad, mantenimiento, etc.
A este respecto, el entorno multidisciplinar debe conseguir que el proceso de
desarrollo de SW respete los diferentes enfoques presentes en el desarrollo de
SCDTR. De modo que la generacin de SW responda a varios criterios, respete las
diferentes especificaciones y las diferentes restricciones impuestas por los modelos
implicados.
Hay varias aproximaciones tericas para la consecucin de este objetivo y las
siguientes pginas intentan esbozar en qu forma tratan el problema. La cuestin
central sigue siendo la integracin de informacin, pero en este caso la informacin
proveniente de mltiples dominios se pretende condensar en un nico SW final.

Pg. 3-23

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.5.1 MTODOS FORMALES


La combinacin de diagramas, texto, tablas y notaciones sencillas que se emplean
en muchos mtodos de ingeniera del SW tienen poco rigor matemtico y a veces
son ambiguas o incompletas. Las sintaxis y semnticas formales se espera que
tengan un gran impacto en la concepcin de la ingeniera del SW de los prximos
aos. Este auge vendr de la mano de la dependencia cada vez mayor de las
herramientas de ayuda a lo largo del proceso SW. Un proceso guiado por diferentes
herramientas automticas debe ser necesariamente formal. Por todo ello, es
importante el conocimiento del fundamento de los mtodos formales para valorar
de qu manera conviene emplearlos para el desarrollo de SW. Este es el objetivo de
las siguientes lneas que resumen el enfoque de Doorfman y Thayer (1996).
En la dcada de los 70 la aparicin del concepto de programacin estructurada
supuso una revolucin al llegarse a un acuerdo en el seguimiento de ciertos
preceptos para el diseo de programas. Los lenguajes imperativos actuales son
herederos de este tipo de programacin. Sin embargo, este acuerdo no es
definitivo, se abre un debate sobre la metodologa de programacin, con continuos
cambios: desarrollo top-down, descomposicin modular, abstraccin de datos,
diseo orientado a objetos, etc.
En cualquier caso, un denominador comn de estas metodologas es que mantienen
la misma nocin tradicional de programacin. Segn sta, la labor del ingeniero de
SW es desarrollar cdigo para indicar a una mquina fsica el camino hacia la
consecucin de un determinado resultado. La idiosincrasia de la mquina
(interfaces de usuario, libreras,) agregan complejidad, con el agravante de que
esta complejidad puede ser aadida en todos los

niveles de abstraccin

(especificacin, diseo, codificacin) porque el ingeniero intenta obtener mxima


velocidad y prestaciones de la mquina. Esto hace mucho ms difcil la fase de
validacin y deteccin de errores.
La nocin de los mtodos formales es la opuesta. Se traslada al ingeniero de HW,
diseador de lenguaje o escritor de compiladores la labor de proveer de cdigo
concreto para una mquina, y no a la inversa.
Originalmente conceba la mquina abstracta como una representacin de la
realidad fsica. Despus, en cambio, aprend a considerar la mquina abstracta
como la verdadera porque es la nica en la que podemos pensar. Es funcin de la
mquina fsica el suministrarnos un modelo que funcione, un modelo fsico
suficientemente preciso como para simular la verdadera mquina, la abstracta.
Sola ser labor del programa el instruir a los computadores, pero el propsito de los
computadores debe ser realmente la ejecucin de nuestros programas. (Dijkstra
1976)
En este sentido, la labor del ingeniero de SW debera ser producir modelos o
descripciones de un sistema para una mquina abstracta, con pruebas de que los

Pg. 3-24

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

modelos de menor nivel de abstraccin implementan correctamente los modelos de


alto nivel. Esto asegura una mayor calidad, y no slo capacidad para realizar
pruebas. Tal y como dice Dijkstra, el test demuestra la presencia de errores, no su
ausencia. Para poder entender y razonar los diseos, deben esconderse los detalles
de implementacin (SoC, Separation of Concerns). No se puede dejar que
cuestiones de microeficiencia dominen e influyan en el resultado final.
Un mtodo formal en desarrollo de SW es un mtodo que proporciona:
1. un lenguaje formal para describir los artefactos SW (especificaciones,
diseos, cdigo fuente,)
2. mecanismos que permitan realizar pruebas formales sobre las propiedades
del artefacto formalmente descrito
La propiedad comprobada suele ser que una implementacin es funcionalmente
correcta, es decir, cumple su especificacin. Entonces, o bien el lenguaje formal
empleado permite describir un sistema a dos niveles de abstraccin (especificacin
formal y posible implementacin), o bien se emplean dos lenguajes relacionados
para describir especificacin e implementacin respectivamente.
En ingeniera de SW, los mtodos formales son directamente aplicables durante las
fases de requisitos, diseo y codificacin y tienen importantes consecuencias para
el test y el mantenimiento. Estn entrelazados con modelos del ciclo de vida
alternativos a las aproximaciones clsicas y permiten un mayor control de la
trazabilidad.
Su aplicacin ms habitual se da en la fase de especificacin. Algunos mtodos
formales incluyen lenguajes de especificacin que permiten registrar precisa y
rigurosamente las caractersticas funcionales y no funcionales que se esperan
obtener

de

un

sistema.

Algunos

ejemplos

son:

(Spievy

1992),

CSP

(Communication Sequential Processes, Hinchley y Jarvis 1995), VDM (Vienna


Development Method, Jones 1991), Larch (Guttag y Horning 1993). Algunos de
estos mtodos pueden incluir lenguajes grficos como DFDs (Data Flow Diagrams)
redes de Petri.
La gran ventaja de la especificacin del sistema a travs de mtodos formales es la
capacidad inherente de realizar pruebas al producto final, de forma que se asegure
un comportamiento acorde con los requisitos. Las pruebas son muy difciles de
generar a posteriori, por ello, pruebas y programas deberan desarrollarse en
paralelo. Por ejemplo, todo lenguaje de programacin es, por definicin, un
lenguaje formal, ya que usan una notacin formal (BNF) para definir su sintaxis.
Esto asegura la capacidad de realizar pruebas al cdigo fuente para comprobar que
cumple con la sintaxis del lenguaje.

Pg. 3-25

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Pese a las ventajas que proporcionan, tienen limitaciones que conviene tener en
cuenta:

 Problema de requisitos.
Pueden usarse para verificar (probar que una implementacin satisface una
especificacin formal) que cada paso en el desarrollo del producto satisface los
requisitos impuestos en los pasos previos. Pero no es suficiente para validar un
sistema (probar que un producto satisface su misin operativa) porque tal y
como afirma Boehm (1981): no se puede ir de lo informal a lo formal por
mtodos formales. El problema es que no se puede probar que una
especificacin formal capture el entendimiento informal e intuitivo del sistema
por parte de un usuario. La especificacin es el contrato entre el usuario y el
desarrollador, y adems de ser formal, tiene que contener y describir todas las
caractersticas que el usuario espera obtener en el producto final.

 Problema de implementacin fsica.


Los mtodos formales pueden verificar que una implementacin satisface su
especificacin cuando corre en una mquina abstracta ideal, pero no en
cualquier mquina fsica. Las pruebas formales explcitamente aslan los sitios
en que puede producirse el error. Concretamente, ser all donde se provea de
una mquina fsica para implementar a la abstracta, ya que las pruebas se
hacen suponiendo que la ejecucin se realizar en la mquina abstracta.

MTODOS FORMALES

Requisitos
de usuario

Especificacin
Diseo
formal

Cdigo
mquina
abstracta

Cdigo
mquina
fsica

Figura 3-6. Incertidumbres a la entrada y salida de los mtodos formales.

Estas limitaciones afectan precisamente al punto inicial y final del ciclo de vida (ver
Figura 3-6). Los mtodos formales pueden automatizar y verificar las transiciones
entre las fases internas del ciclo de vida (especificacin, diseo y generacin de
cdigo para mquina abstracta), pero existen incertidumbres en los saltos de lo
informal a lo formal, y de lo formal a lo informal respectivamente, al principio y al
final del proceso. Se investigan diversas formas de minimizar la magnitud de estos
saltos; por un lado el uso de lenguajes formales pero cercanos al entendimiento
del usuario para recoger requisitos o el empleo de especificaciones grficas con
formalismo inherente; por otro lado el empleo de estndares, HW, libreras y
compiladores certificados para asegurar su adherencia a la mquina abstracta
idealizada.

Pg. 3-26

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Ni siquiera en todas las fases internas del ciclo de vida es siempre ventajoso el uso
de mtodos formales. Debe decidirse en qu fases y con qu objetivos emplearlos
para modular el grado de uso ms adecuado:

Uso puntual. En el desarrollo de algunos componentes se usan slo para la fase


de diseo porque los productos requieren de una interaccin continua entre
especificacin e implementacin.

Uso generalizado. Se puede derivar todo el proceso a partir de unas


especificaciones formales completas. Si todo parmetro o cambio que pueda
introducirse est recogido en las especificaciones, se podra generar el cdigo
final a partir de ellas. En este caso, se modificara la especificacin para generar
cualquier nueva versin. Esta visin sustituye a los programadores por un
conjunto inteligente de herramientas integradas dirigidas por mtodos formales
(McLean 1993).

Uso variable. Introduccin parcial de mtodos formales con nivel variable de


formalidad y uso de verificacin informal. Es el caso del modelo de proceso de
sala limpia (Linger 1994).

A veces es difusa la frontera entre mtodo o lenguaje de especificacin. Un mtodo


indica qu debe decir una especificacin, mientras que un lenguaje determina cmo
pueden expresarse los conceptos de una especificacin. Algunos lenguajes soportan
ms de un mtodo, y la mayora de los mtodos pueden ser usados en varios
lenguajes de especificacin (Lamport 1989).
Los lenguajes de especificacin formal tienen un alfabeto de smbolos y reglas
gramaticales que definen frmulas de buena formacin. Estas reglas caracterizan el
dominio sintctico del lenguaje o cmo combinar los smbolos para obtener
expresiones, en principio, sin significado. El significado o interpretacin de la
frmula es parte de la semntica. El conjunto de objetos que componen el dominio
semntico del lenguaje (reglas que dictan qu objetos satisfacen la especificacin)
proveen al lenguaje de un modelo.
Una especificacin ser un conjunto de frmulas expresadas en el lenguaje
formal. Los objetos en el dominio semntico del lenguaje que satisfacen una
especificacin pueden ser varios. Por eso la especificacin est en un nivel de
abstraccin mayor que los objetos en el dominio semntico, permite abstraerse de
los detalles que distinguen diferentes implementaciones. Diferentes mtodos de
especificacin definidos sobre el mismo dominio semntico permiten especificar
diferentes aspectos de los objetos.
Todos estos conceptos pueden expresarse a travs de las matemticas, con la
ventaja de que se obtienen herramientas para razonamiento formal a partir de las
especificaciones, que pueden ser examinadas para ver si con consistentes y
completas.
En funcin de sus dominios semnticos, los lenguajes de especificacin pueden
clasificarse en:
Pg. 3-27

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Lenguajes ADT (Abstract Data Type Specification). Especificacin de


lgebras. Propiedades formales de un tipo de dato sin definir caractersticas
de implementacin. Ejemplos: Z, VDM, Larch.
Lenguajes de especificacin de procesos. Secuencias de estados, eventos,
mquinas de estados. Ejemplo: CSP de Hoare
Lenguajes de programacin.
Los mtodos de especificacin se pueden clasificar en:
Operacionales, constructivos u orientados a modelo. La especificacin es
una descripcin del sistema que proporciona un modelo. El comportamiento
de este modelo define el deseado en el sistema. Usar estructuras
matemticas abstractas como relaciones, funciones, conjuntos y secuencias.
Puede verse como un programa escrito en un lenguaje de muy alto nivel, ya
que se pasa de un conjunto de entradas a uno de salidas.
De definicin, declarativos u orientados a la propiedad. Mnimo conjunto de
condiciones que debe satisfacer un sistema para ser funcionalmente
correcto. No se determina un modelo mecnico para llegar de las entradas a
las salidas. Mtodos algebraicos (las propiedades se expresan en forma de
ecuaciones) y axiomticos (clculo de predicados).
Como conclusin, los paradigmas de ciclos de vida que confen en la transformacin
automtica desde especificacin hasta cdigo ejecutable son necesariamente
formales (por ejemplo, el ciclo de vida de sala limpia). El desarrollo de SW al
hacerse complejo se est volviendo cada vez ms dependiente de las herramientas,
y stas cada vez usan ms los mtodos formales. Entre las tcnicas que hacen uso
de ellos cabe mencionar: prototipado rpido, diseo orientado a objetos,
programacin estructurada e inspecciones formales.
El uso de los mtodos formales se est generalizado a pequea escala pero
tpicamente en organizaciones con nivel 3 o superior en el modelo de madurez del
proceso SW del SEI. Es difcil llevarlos hasta el ltimo extremo pero se pueden
implantar gradualmente e ir integrndose en el proceso habitual de las empresas.

Pg. 3-28

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.5.2 SEPARACIN
PROPSITOS

MULTIDIMENSIONAL

DE

La filosofa de Separation of Concerns (separacin de propsitos) est en el ncleo


de la ingeniera del SW en general y del desarrollo de SW orientado a objeto en
particular. El uso adecuado de la orientacin a objeto, resuelve una parte, pero no
toda la complejidad asociada a los requisitos que se le imponen a los sistemas SW
actuales. Por ejemplo, el cambio en la representacin de un dato en un sistema
orientado a objeto, si se hace utilizando patrones de diseo o subclases, no tiene
porqu

ser

traumtica

para

el

sistema.

Sin

embargo,

aadir

una

nueva

funcionalidad a un sistema s suele suponer cambios intrusivos porque el cdigo de


la nueva funcionalidad se disemina en diferentes clases y se mezcla con cdigo de
otras clases, aumentando la probabilidad de error y la complejidad y dificultando la
comprensin del cdigo.
En resumen, parece necesario el uso de tcnicas complementarias a las propias de
orientacin a objeto. Dependiendo del propsito perseguido se requiere la
descomposicin

del

sistema

en

diferentes

tipos

de

mdulos:

clases,

funcionalidades, aspectos (distribucin, persistencia), roles, etc.


MDSOC (Multi-Dimensional Separation Of Concerns) intenta llevar esta filosofa
hasta sus ltimas consecuencias y se plantea como objetivos:

Tratamiento

del

sistema

desde

el

punto

de

vista

de

un

nmero

indeterminado de propsitos mltiples, arbitrarios y no prefijados. Los


propsitos, criterios o problemas varan en el tiempo y son sensibles al
contexto (diferentes actividades del desarrollo, fases del ciclo de vida,
desarrolladores). Por ello cualquier criterio debera ser posible para la
descomposicin.

Encapsulado simultneo de todos los propsitos para un sistema. El


desarrollador no elige uno o varios de ellos para su cdigo, todos pueden
coexistir.

Gestin de propsitos interrelacionados o solapados. Pocos propsitos sern


ortogonales, se debern gestionar las relaciones entre ellos porque
normalmente estarn presentes varios a la vez y puede ser que se solapen o
interfieran.

En definitiva, MDSOC enfatiza una separacin flexible e incremental, una


modularizacin y una integracin de artefactos SW basada en un nmero
indeterminado de criterios. Adems, soporta la remodularizacin para encapsular
nuevos criterios en cualquier momento. Esto conlleva los siguientes beneficios:

Pg. 3-29

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

9 Reduccin del impacto de cambios. Los cambios en el SW son aditivos, no


intrusivos. Se logra mejorar el comportamiento global del sistema sin
perjudicar lo anteriormente construido.

9 Ms sencilla comprensin del sistema y reduccin de la complejidad.


9 Adaptabilidad.
9 Mantenimiento ms sencillo.
9 Personalizacin y configuracin acorde a las necesidades del usuario.
9 Reutilizacin de componentes.
9 Mejor trazabilidad.
9 Integracin de componentes simplificada, uso de COTS
9 SW ms rpido, seguro, barato y de mejor calidad.
IBM ha trabajado en MDSOC y ha creado su aproximacin particular denominada
Hyperspaces (www.research.ibm.com/hyperspace/). Concretamente, proporciona
soporte

para

hiperespacios

Java

travs

de

Hyper/J

(www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm). Esta herramienta opera


con clases Java y un fichero de control especifica cmo mapear los miembros Java
a propsitos, qu propsitos tener en cuenta y qu relaciones de composicin
implementar (Ossher y Tarr 2000).

Pg. 3-30

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.5.3 DESARROLLO DE SW DIRIGIDO A DOMINIO


El Desarrollo Dirigido a Dominio (Domain-Driven Development, 3D) agrupa a un
conjunto de tecnologas que tienen en comn la nocin abstracta de dominio e
intentan que cada una de las partes del SW desarrollado emane desde ese nivel. Su
inters actual se ve refrendado al ser uno de los tracks de OOPSALA (Conference on
Object-Oriented Programming, Systems, Languages And Applications). Tal y como
se dice en el avance del programa de esta conferencia, el Desarrollo Dirigido a
Dominio

(http://domaindrivendesign.org/)

cubre

un

espectro

de

tecnologas

emergentes entre las que se pueden destacar Model Driven Architecture (MDA),
Aspect-Oriented Modeling, Generative Programming e Intentional Programming.
Todas ellas se centran en alinear el cdigo y el problema de dominio de forma ms
certera. Elevan la expresin del diseo e implementacin, eliminan detalles, aslan
el SW de la deriva tecnolgica, ayudan a balancear entre la personalizacin y la
generalidad del SW y permiten mayores niveles de automatizacin.
MDA ya ha sido analizado en solitario debido a su importante peso especfico. A
continuacin, se resumen los principios de otras tecnologas hermanas.
Aspect Oriented Software Development (http://aosd.net/). Los mecanismos
para definir y componer abstracciones son elementos esenciales de todo lenguaje
de programacin El estilo de diseo soportado por los mecanismos de abstraccin
de la mayora de los lenguajes de programacin comunes es el de dividir un
sistema en componentes parametrizables que pueden ser llamados para ejecutar
una

funcionalidad.

Pero

muchos

sistemas

tienen

propiedades

que

no

necesariamente se alinean con los componentes funcionales de un sistema. Algunos


ejemplos son propiedades como gestin de errores, persistencia, comunicacin,
monitorizacin,

optimizacin

del

rendimiento,

replicacin,

coordinacin,

sincronizacin, comportamiento sensible al contexto, protocolos multi-objeto,


gestin de memoria o requisitos de tiempo real. Todas estas propiedades tienden a
afectar a grupos de componentes funcionales y no se limitan a uno solo. El
desarrollo orientado a aspectos permite modularizar estos problemas. Intenta
abstraer caractersticas comunes a muchas partes del cdigo, y por tanto, mejorar
la calidad del SW, ms all de los simples mdulos funcionales.
Mientras que estos aspectos pueden ser pensados y analizados de forma
relativamente separada a la funcionalidad bsica, su programacin, empleando los
habituales lenguajes orientados a componentes, tiende a dispersar estos aspectos a
lo largo de diferentes partes del cdigo. Como resultado, el cdigo se convierte en
una maraa de instrucciones con diferentes propsitos.
Este fenmeno de maraa es el origen de parte de la complejidad en los sistemas
SW actuales. Por ello, algunos investigadores han empezado a trabajar en
aproximaciones que permitan a los programadores expresar cada uno de los

Pg. 3-31

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

aspectos de un sistema en una forma separada y natural para despus combinar


esas descripciones separadas en la forma de un ejecutable final.
AspectJ (http://eclipse.org/aspectj/) es una extensin orientada a aspectos para el
lenguaje

Java.

Proporciona

una

modularizacin

limpia

para

problemas

transversales, de forma que se modularizan aspectos que afectan a ms de una


clase.
Generative Programming (www.generative-programming.org). Se trata de un
conjunto de tcnicas que permiten construir los programas automticamente a
partir de programas especficos de dominio de menor tamao (Czarnecki y Ulrich
2000). Extiende los beneficios de la automatizacin al desarrollo SW.
Intentional Programming. Una tcnica que permite a los programas ser escritos
y vistos en una variedad de notaciones diferentes. Tambin permite la integracin
sin problemas de programas de dominio especfico y programas de propsito
general. Fue desarrollado por el equipo de Charles Simonyi (Simonyi 1995)
mientras trabajaba en Microsoft.
Transformational Programming. Tcnica que produce programas a partir de
especificaciones de alto nivel o especficas de dominio. El programa es derivado de
una especificacin formal empleando pasos de transformacin manejados y
controlados que garantizan que el producto final cumpla con las especificaciones
iniciales (Bauer et al 1989).
Adems de las resumidas hasta aqu, existen otras tcnicas o metodologas que
matizando ligeramente la forma, tratan el mismo problema de fondo. En la
bibliografa

se

entremezclan

confunden

trminos

como:

Subject-Oriented

Programming, Product-Line Engineering, Traversal-Related Behavioral Concerns,


Component-Based Software Engineering,

Pg. 3-32

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.5.4 GENERACIN DE PROGRAMAS CON XSLT


Los Generadores de Programa son un resultado de la aplicacin de tcnicas de
Ingeniera de Dominio. sta se centra en generar familias de aplicaciones (no slo
una) y engloba dos procesos (Cleaveland 2001):

1. Anlisis de Dominio. Se determina la parte comn y la que vara en el


conjunto de las aplicaciones presentes en un domino en estudio.
a. Parte comn. Recoge todas las caractersticas que se repiten en
todas y cada una de las aplicaciones en estudio. Un conjunto amplio
de caractersticas comunes aade mayor conocimiento de un dominio
pero restringe el conjunto de aplicaciones de esa familia. El resultado
de este estudio supondr la clave para la reutilizacin del SW.
b. Variabilidades. Identifican lo que es diferente entre los programas de
una misma familia. Un lenguaje de especificacin debe ser capaz de
recogerlas, y en cada caso, hacer llegar al Generador de Programas
la

informacin

de

configuracin

necesaria.

El

Generador

de

Programas automatiza la fase de generacin de cdigo a partir del


conjunto de especificaciones que fija las

variabilidades y las

parametriza para un caso concreto.

2. Implementacin de Dominio. Se crean herramientas capaces de generar


aplicaciones para ese dominio a partir de la descripcin de las variabilidades.
La aplicacin de estas tcnicas conducir la construccin de Generadores de
Programas y el diseo de los repositorios de componentes. Es evidente la necesidad
de un diseo conjunto de ambos sistemas puesto que el Generador har uso de
componentes antiguos o crear componentes nuevos, segn el caso. Y es que la
herramienta de generacin de cdigo puede utilizarse con alguno o varios de los
siguientes propsitos:

Creacin del esqueleto bsico de un proyecto o componente de una aplicacin


sobre el que el ingeniero de SW trabajar manualmente. Por ejemplo,
generacin de IDL CORBA.

Generacin

de

una

funcionalidad

especfica

dentro

de

una

aplicacin

(componente). Posteriormente el desarrollador podr tratar el resultado como


una caja negra que pueda ser incorporada en diferentes aplicaciones sin
cambios. Es imprescindible tener bien definidos los interfaces entre los
diferentes componentes de la aplicacin.

Creacin de una aplicacin completa ensamblando componentes existentes.


El generador de cdigo pega los trozos de aplicacin en base a unos
determinados parmetros.

Pg. 3-33

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

El uso de Generadores de Programas suele ir de la mano de la Programacin


Orientada a Componentes, en la que se emplean como constructores necesarios los
componentes, interfaces, conectores y adaptadores:

 Componente. Se puede definir como una unidad de composicin con


interfaces especficos y contexto explcito. Puede ser desarrollado a propsito
para una aplicacin

o reutilizado tras capturarlo en un repositorio y

parametrizarlo. Existe una discusin sobre la distincin de componentes y


objetos, concretamente, UML 2.0 promete mejor soporte para los componentes
de lo que ofrece la versin actual. Un componente debe minimizar las
asunciones (dependencias) hechas sobre el entorno y los recursos y objetos
que lo rodean. Se llaman dependencias porque el componente depende de su
existencia. No se pueden eliminar todas las dependencias ya que el interfaz de
un componente usa ciertos tipos que deben ser soportados por el entorno. Por
ello los componentes a menudo se desarrollan para un determinado modelo de
componentes (por ejemplo, JavaBean). Ejemplos de dependencias: variables
globales y recursos, tipos y mecanismos de comunicacin entre procesadores.

 Interfaz. Es una interaccin entre un componente y otros elementos SW. Los


interfaces se suelen dividir en exports (servicios provistos por el componente) e
imports (servicios requeridos por los componentes) y se suelen graficar como
puertos de entrada y salida.

 Conector. Sern compatibles aquellas conexiones entre puertos import y


export que tengan el mismo tipo. Puede haber conectores sncronos (se espera
hasta que vuelva la respuesta de la llamada) y asncronos (se hace la llamada
pero no se espera la respuesta).

 Adaptadores de interfaz. Necesarios para convertir entre el tipo de una


salida y el de una entrada a otro componente o para conectar una salida a
varias entradas
Tanto los lenguajes ADL (Architecture Description Language) como los MIL (Module
Interconnection Language) permiten representar componentes, conectores e
interfaces, y solucionar los flujos de informacin entre ellos a travs de
adaptadores para no perder la modularidad. Adems, estos lenguajes tienen en
cuenta mecanismos de comunicacin (para sistemas distribuidos), jerarqua
(combinacin de componentes para la construccin de otros), etc. XML es muy
bueno como base de un lenguaje MIL ADL.
Todo lo anterior plantea la generacin automtica como una labor compleja que
requiere de bastante estudio y formalizacin. De hecho, parece razonable plantear
la fase de generacin de cdigo como un subproceso diferenciado dentro del
proceso general de creacin de SW. Las compensaciones que conlleva este arduo
trabajo son las siguientes:

9 Toma de decisiones en el nivel de especificacin frente al de codificacin. Es


ms fcil leer, escribir, editar, depurar y entender los sistemas en la fase de

Pg. 3-34

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

especificacin y los lenguajes de especificacin (de cuarta generacin) son


ms productivos que los de programacin.

9 Favorece el SoC (Separation Of Concerns) porque permite que diferentes


profesionales con tareas concretas puedan colaborar en la especificacin y
dejar la fase de generacin de cdigo al Generador de Programas (y no a un
especialista concreto).

9 Desacopla especificacin (el qu) de implementacin (el cmo) porque esta


ltima parte la realiza el Generador de Programas. Podrn realizarse
diferentes implementaciones, programas alternativos o variaciones de un
mismo

tipo

de

programa

(familias

de

programas)

para

una

nica

especificacin sin ms que configurar adecuadamente el Generador.

9 Proceso automtico unificado para extraer, a partir de unas especificaciones


comunes, varios productos: cdigo, documentacin del SW, documentacin
de usuario, pruebas y documentos de configuracin.

9 Correccin y coherencia del producto final. El programa generado no tendr


errores cometidos en la fase de codificacin y se evitarn derivas respecto a
las especificaciones.

9 Mejora continua del rendimiento del SW con la aplicacin de las ltimas


tcnicas por parte del Generador de Programas.
Varias de estas ventajas recuerdan a las que se mencionaban para el uso de
metodologas

formales

porque

en

ese

caso

tambin

se

intenta

generar

automticamente el cdigo a partir de una especificacin formal completa.


Mientras que para los programas generados a mano debe facilitarse la legibilidad y
facilidad de modificacin del propio cdigo, para los programas generados
automticamente es importante la legibilidad y sencillez de modificacin de las
especificaciones a partir de las cuales se crea automticamente el cdigo. Este
objetivo est asegurado si dichas especificaciones estn expresadas en XML, como
es el caso que se plantea en esta tesis. Partiendo de unas especificaciones as, la
combinacin de XSLT (W3C 1999) y XPath (W3C 1999b) supone la manera natural
de implementar la generacin de cdigo porque:

9 Ambos son estndares abiertos.


9 Tienen funcionalidades complementarias; mientras XPath se usa para
identificar y seleccionar partes de un documento XML, XSLT habilita la
transformacin de la informacin.

9 XSLT permite generar como salida documentos XML, texto estructurado (por
tanto, cdigo fuente de cualquier lenguaje de programacin) o HTML, y
mediante XSL-FO tambin formatos PDF, SVG, RTF, etc.

Pg. 3-35

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

9 Ambos son lenguajes declarativos y evitan el uso de cdigo Java (o cualquier


otro lenguaje imperativo de propsito general).

9 Permiten establecer un mtodo de generacin de programas independiente


del lenguaje de programacin de la aplicacin final, ya que partes de cdigo
fuente de cualquier lenguaje pueden ser embebidas entre etiquetas XML que
sean interpretadas por XSLT.

Pg. 3-36

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..66 IIN
NT
CO
ON
TE
NO
EG
OC
GR
CIIM
RA
AC
MIIE
CII
EN
N
NT
ND
TO
O
DE
EC
Sobre las tcnicas empleadas para capturar, clasificar,almacenar y
recuperar cuando se necesite el conocimiento.
Gestin de Conocimiento (GC) o Knowledge Management (KM) es un trmino
asociado con los procesos para la recoleccin, organizacin, generacin, anlisis,
diseminacin, comprobacin y utilizacin del conocimiento en el mbito de una
organizacin. Tiene como objetivo la adaptacin sistemtica de una organizacin a
un entorno cambiante. Para ello, busca la combinacin de las capacidades de las
nuevas tecnologas para el procesado de datos e informacin con las capacidades
creativas humanas.
Dos conceptos importantes a tener en cuenta son:
Data Mining. Trata sobre la ordenacin de datos para identificar patrones y
establecer relaciones. Incluye actividades como: asociacin de eventos
conectados, anlisis de secuencias de eventos, clasificacin y bsqueda de
patrones,

clustering

agrupacin

de

hechos

con

un

nexo

comn,

predicciones en base a la informacin analizada.


Mtodos Push. En aplicaciones cliente/servidor denotan el reparto de
informacin iniciada por el servidor sin requerimiento explcito previo del
cliente o usuario de la informacin.
Pese a que en un principio parece extrao relacionar los SCDTR con la Gestin del
Conocimiento, la GC es una disciplina emergente y de propsito general aplicable a
cualquier rea. Concretamente, el desarrollo de SCDTR es una actividad de gestin
intensiva de personas y conocimiento, en la que continuamente se tienen que
tomar decisiones. La toma de decisiones se suele basar en el conocimiento y la
experiencia personal pero cuando los proyectos crecen en tamao y complejidad es
prioritaria la comunicacin y coordinacin para que esta actividad de grupo llegue a
buen fin. La filosofa central de la GC: Ninguno de nosotros es tan bueno como
todos nosotros juntos (Bennis y Biederman 1998) encaja exactamente con las
ideas expuestas en el captulo inicial de esta tesis, por tanto, es seguro que algunos
de los conceptos de GC sern de gran ayuda.
En principio, es interesante profundizar un poco en la caracterizacin del
conocimiento segn las teoras de GC:
Se distinguen diferentes niveles de refinamiento en tanto a los elementos
relacionados con el conocimiento:

Pg. 3-37

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Datos puntuales. Valores cuantitativos o cualitativos, discretos y objetivos


sobre un proyecto o evento concreto.

Informacin. Datos organizados de forma que le sean til al usuario para


tomar decisiones.

Conocimiento. Requiere el entendimiento de la informacin y comprende


informacin, relaciones, clasificacin y metadatos. Aglutina la informacin
recogida de varios proyectos y permite su aplicacin a nuevos proyectos.

Experiencia o conocimiento aplicado. Se materializa en forma de mejores


prcticas y estndares.

Tipos de conocimiento: organizacional (respecto a la compaa: recursos


humanos,

objetivos

de

negocio,),

de

gestin

(planificacin,

personal,

seguimiento, direccin proyecto), tcnico (anlisis de requisitos, diseo,


programacin, testeo, codificacin, mtodos, herramientas, lenguajes,), de
dominio (relacionado con el dominio de aplicacin y el sistema especfico bajo
desarrollo)
mbito del conocimiento. Dnde es aplicable, para quin es accesible, qu
actividades soporta. Posibles mbitos: nivel individual, grupo, organizacin,
mltiples organizaciones o industria.
No es difcil identificar algunas necesidades del proceso de creacin de SCDTR que
estn directamente relacionadas con la GC:
La GC intenta convertir los datos en informacin, y sta en conocimiento pero el
mayor problema es que slo una fraccin del conocimiento relacionado con el
desarrollo de SW es capturado y expresado explcitamente. La mayor parte del
conocimiento es tcito.
Diferentes proyectos o productos tienen diferentes necesidades, lo que hace que
sta sea una disciplina inherentemente experimental en la que se gana
experiencia con cada nuevo proyecto. Idealmente se debera aplicar esta
experiencia a futuros proyectos, para ello hay que capturar y compartir los
resultados. El sistema debe ser adems flexible para adaptarse a la diversidad
de productos.
La gestin documental es fundamental porque la mayora de los artefactos que
guan el desarrollo de un proyecto SW pueden ser representados en forma de
documentos.
Se requiere de conocimiento sobre el dominio para el que se est desarrollando
SW y ese conocimiento debe integrarse en el proceso.
Colaboracin a distancia independientemente del tiempo y del espacio.
El conocimiento debe ser coleccionado, organizado, coordinado, almacenado y
recuperado de forma sistemtica.

Pg. 3-38

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

La aplicacin de la GC a la Ingeniera de SW debe ser progresiva y se distinguen los


siguientes niveles (Rus et al 2001):
Primer nivel. Agrupa las tareas realizadas por un equipo para desarrollar SW de
acuerdo a los requisitos impuestos por el usuario. Se deben documentar las
tomas de decisiones que van constituyendo la historia del proyecto. En este
nivel es necesario un soporte de GC que recoja los resultados de todas las
actividades del proceso. Como estos resultados toman la forma de documentos,
el sistema de GC es un sistema de gestin documental. La distribucin de
informacin sobre el proyecto es un problema de gestin de informacin y las
tecnologas basadas en web se muestran vlidas para ello. Internet es una
herramienta vital para diseminar los documentos dentro y fuera de la
organizacin. A este nivel son de utilidad herramientas para el control de
versiones (edicin concurrente) y la bsqueda de documentos.
Segundo nivel. Tareas orientadas a mejorar la capacidad del equipo para
desarrollar un producto SW, o dicho de otro modo, cmo mejorar las tareas del
primer nivel. Se hacen durante y al poco de acabar un proyecto para no perder
el conocimiento potencial adquirido en el mismo.
Tercer nivel. Tareas enfocadas a mejorar la capacidad de una organizacin o
industria para desarrollar SW. Actividades que analizan los resultados de varios
proyectos anteriores para identificar similitudes y diferencias. La experiencia
recogida puede formularse cualitativa (patrones, reglas heursticas, mejores
prcticas,) o cuantitativamente (modelos de estimacin basados en la medida
de atributos,) o pueden recogerse en paquetes SW que automaticen ciertos
pasos del proceso de desarrollo basndose en el conocimiento inferido. Los
resultados tambin pueden ser estndares industriales.

Pg. 3-39

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Pg. 3-40

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..77 IIN
NT
APPLLIICCAACCIIO
TE
EG
GR
RA
AC
CII
ON
N
NE
ND
ESS
DE
EA
Sobre la manera de interactuar cada una de las herramientas con el Motor
de Colaboracin de Herramientas, independientemente de su localizacin y
plataforma de ejecucin.
Uno de los objetivos de integracin se refera a la interaccin entre aplicaciones
distribuidas en entornos heterogneos. Dado que en este trabajo de investigacin
se persigue la integracin entre tiempos de ejecucin de las herramientas, y no en
tiempo de ejecucin, los sistemas fuertemente acoplados pierden fuerza frente a
una arquitectura dbilmente acoplada.
En varios trabajos anteriores (Oberndorf 1998) se pueden encontrar referencias a
la necesidad de construir un entorno de desarrollo multiplataforma, abierto,
completo y de bajo coste. Incluso ya se ha planteado el uso de lenguajes XML como
argamasa que junte las diferentes herramientas. Por ejemplo, CASEML (Garbajosa
2002) es una extensin de XML sobre la que se construye un entorno de ingeniera
de software para desarrollar aplicaciones empotradas basadas en los mtodos,
lenguajes y procesadores empleados en la Agencia Aeroespacial Europea.
Sin embargo, la consecucin de todos los requisitos planteados requiere de algo
ms para ubicar las herramientas de acuerdo a una arquitectura comn y resolver
satisfactoriamente la comunicacin remota. La filosofa de los Servicios Web
parece ajustarse perfectamente a las necesidades enunciadas, ya que se plantea la
utilizacin de los servicios ofrecidos por las diferentes herramientas desde un
entorno.

Pg. 3-41

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.7.1 CONCEPTOS BSICOS SOBRE SERVICIOS WEB


Los Servicios Web (W3C 2003) parecen formar parte de una segunda oleada de
cambios en el desarrollo de aplicaciones distribuidas, tras la entrada de XML. De
hecho, tienen en XML su ncleo central y desarrollan sus capacidades para la
comunicacin entre aplicaciones por internet. Las fuertes inversiones que IBM,
Microsoft y Sun estn realizando en servicios web indican que van a extenderse
cada vez ms.
La idea central no difiere mucho del viejo objetivo de CORBA y Java, esto es, la
creacin de aplicaciones distribuidas que integren mdulos localizados en diferentes
plataformas a travs de un middleware que una esos mdulos distribuidos en
tiempo de ejecucin. Pero se aade un nuevo matiz a este concepto, como es la
gestin dinmica de servicios que permita seleccionar en tiempo de ejecucin entre
una variedad de servicios ofrecidos por compaas. Cada empresa se centra en
implementar lo que mejor sabe hacer y las aplicaciones se ejecutan a travs de la
red buscando y usando dinmicamente los servicios que se requieran. Por ejemplo,
ante una peticin de usuario, una aplicacin puede buscar dinmicamente el hotel y
el vuelo ms ventajoso consultando en todo el conjunto de la red (no solo entre un
conjunto esttico de empresas concertadas). Las propias aplicaciones podrn
seleccionar los servicios que necesiten para lograr sus objetivos. Aunque el usuario
percibe una nica aplicacin, en realidad est usando un conjunto de aplicaciones
(constituido dinmicamente, diferente en cada ejecucin), cada una corriendo en su
propia plataforma.
La definicin e implementacin de Servicios Web no es nica, pero se pueden
apuntar algunos aspectos comunes a cualquier implementacin:

Recursos direccionables a travs de su URL (Universal Resource Locator)


que programticamente devuelven resultados a los clientes. Un interfaz no
rgido (expresado en XML) permite que las propias aplicaciones busquen e
invoquen estos servicios.

Conjunto de estndares basados en XML que especifican un protocolo de


comunicacin, un lenguaje de definicin y un registro de publicacin y
suscripcin.

Tanto la arquitectura web como la Arquitectura de Servicios Web son instancias de


SOA (Service Oriented Architecture). Esta arquitectura favorece que los servicios se
puedan invocar remotamente cuando se necesiten. SOA define un tipo de sistema
distribuido, entendido ste como un conjunto de agentes SW que, operando en
diferentes entornos (deben comunicarse por protocolos SW/HW menos fiables que
las invocaciones directas), deben trabajar juntos para implementar alguna
funcionalidad.

Pg. 3-42

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

La Figura 3-7 muestra un sistema SOA genrico en el que los agentes implementan
operaciones bien definidas proveyendo servicios y pueden ser invocados a travs de
la red empleando protocolos y formatos de datos estndar.

Figura 3-7. Diagrama genrico de Arquitectura Orientada al Servicio.

La descripcin de un servicio SOA es esencialmente la de los mensajes que se


intercambian ya que se utilizan conexiones sin estado. Esto significa que toda la
informacin necesaria para procesar una peticin debe estar en la propia peticin.
Por tanto, los componentes SOA son los mensajes, agentes proveedores,
agentes usuarios y mecanismos de transporte compartidos. En el caso de
servicios pblicos (cuyo descubrimiento debe gestionarse de forma estndar) se
aaden las descripciones pblicas de estos componentes, que describen los
mensajes y los servicios.

Pg. 3-43

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.7.2 ESTILO DE ARQUITECTURA REST


El World Wide Web (WWW) tiene una arquitectura SOA con requisitos adicionales
(Jacobs 2003): los agentes (llamados recursos) se identifican con URIs y el estado
del recurso es representado en una variedad de formatos (XML, HTML, CSS, JPEG,
PNG) que deben ser reconocidos por los agentes.
REST (REpresentation State Transfer) supone un estilo de arquitectura ms
restringido (Fielding 2000). Es un subconjunto de WWW en el que los agentes
exponen y usan los servicios a travs de gramticas con un interfaz uniforme y
manipulan los recursos slo intercambiando representaciones de los diferentes
estados.
De este modo, se pueden clasificar los servicios web en dos grandes grupos:

 REST manipulacin directa de los recursos. El propsito principal de los


servicios es la manipulacin de representaciones XML de recursos web:
Usan un conjunto mnimo y uniforme de operaciones
Usan vocabularios y mecanismos universales para gestionar el estado
Se implementan con servidores web estndar que manipulan directamente
la informacin
XML se emplea para representar los recursos web

 Objetos distribuidos u operacin a travs de web. El propsito principal es la


ejecucin remota de un conjunto de operaciones indeterminadas sobre recursos
que pueden no estar en la web.
Usan operaciones arbitrariamente complejas
Usan vocabularios y mecanismos especficos de la aplicacin para gestionar
el estado
Se implementan con cdigo externo invocado a travs de mensajes a
servidores web
XML se emplea para representar los datos necesarios para llevar a cabo las
operaciones
Aunque ambos tipos de servicios web utilizan URIs, protocolos web y XML, difieren
en la manera de utilizarlos. La arquitectura REST est en sintona con la propia
filosofa del WWW (identifica los recursos con informacin en formato XML, servida
por un servidor web estndar y accesible a travs de un URI) mientras que la
arquitectura de objetos distribuidos usa XML (soporte de datos) y protocolos
internet

(mecanismo

de

acceso

recursos

remotos)

como

herramientas

particulares dentro de la filosofa clsica de desarrollo de una aplicacin particular.


Pg. 3-44

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.7.3 DEFINICIONES SOBRE SERVICIOS WEB


Es difcil acordar una definicin estndar de Servicio Web porque son diversas las
concepciones (desde SOAP-RPC puro hasta la manipulacin HTTP de documentos)
que pretenden ser integradas bajo una arquitectura de referencia comn.
Un Servicio Web es un sistema software diseado para ofrecer interaccin e
interoperatividad entre mquinas conectadas a travs de una red mediante el
protocolo de transporte HTTP y con una serializacin de datos en XML. La manera
de interactuar se describe en un interfaz, usando un formato procesable por las
mquinas.
La Figura 3-8 muestra los roles bsicos que toman parte en un servicio web. La
nocin abstracta del SW que proporciona un servicio a travs del envo y recepcin
de mensajes debe ser implementada por un Agente Proveedor concreto (recurso
computacional relacionado con el suministro de un servicio web a travs de una
conexin HTTP). El Agente Requeridor es el SW que accede a los servicios
ofrecidos por el Agente Proveedor. Para lograr que la comunicacin entre estas dos
entidades sea automtica e independiente de la intervencin humana es necesario
un acuerdo previo entre ambas partes respecto a dos cuestiones:
1. La lgica de los mensajes intercambiados entre la entidad proveedora y
la usuaria se describe en un documento WSD (Web Service Description)
procesable por las mquinas. El WSD define el formato de los mensajes,
tipos de datos, protocolos de transporte y formatos de serializacin que
deben usarse, as como uno o varios puntos de acceso para invocar al
agente suministrador. El WSD es el documento XML que describe el interfaz
mediante una gramtica conocida.
2. La semntica del intercambio de mensajes representa el contrato
respecto al propsito y las consecuencias. Este contrato puede ser explcito
o implcito, oral o escrito, orientado a consumo de mquina o humano.
Mientras que WSD representa un contrato que gobierna los mecanismos de
interaccin con un servicio particular, la semntica es un contrato que
gobierna el significado y propsito de la interaccin.
Estos acuerdos toman forma computacional (son programados) en los agentes
proveedor y requeridor del servicio, de forma que estos agentes puedan ser
autnomos en la peticin y provisin automtica del servicio.

Pg. 3-45

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Figura 3-8. Roles bsicos en un servicio web.

Pg. 3-46

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.7.4 ESCENARIOS DE USO DE SERVICIOS WEB


David Booth identifica escenarios de propsito general para servicios web
(www.w3.org/2002/ws/arch/2/10/roles_clean.htm).

En

cada

uno

de

estos

escenarios el autor define los roles que toman parte, los artefactos y la secuencia
de operacin.

3.7.4.1 Escenario 0: Interaccin web clsica (sin servicios web)


Un humano manualmente, con un navegador web, interacta con un servidor web
que ha sido programado para alojar una aplicacin determinada.

Figura 3-9. Escenario 0 de uso de Servicios Web.

Esencialmente se trata de una interaccin hombre-mquina porque el navegador


acta como una simple herramienta empleada por el usuario para acceder al
servidor. Cualquier patrn de interaccin que la aplicacin requiera del usuario se la
puede indicar en forma de texto para que el usuario responda activando el
siguiente paso. Por tanto, no es necesario describir formalmente, en formato legible
por las mquinas, los patrones de interaccin.

3.7.4.2 Escenario 1: Partes conocidas, WSD esttico


Dos organizaciones que se conocen desean automatizar su interaccin a travs de
Servicios Web. La semntica es especificada manualmente por humanos.

 Actores:
Requeridor humano (uno o varios)
Proveedor humano (uno o varios)
Agente requeridor (parte cliente de la aplicacin que se comunicar con el
agente proveedor)
Agente proveedor (parte servidora de la aplicacin)

Pg. 3-47

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

 Artefactos:
WSD (Web Service Description) es algn tipo de descripcin de la
interaccin deseada en un formato procesable por las mquinas. Incluir
descripciones estticas de mensajes, tipos de datos, operaciones, etc. Hoy
en da todava no es capaz de definir completamente la semntica de la
interaccin.
Semntica. Incluye toda la informacin sobre la interaccin no incluida en el
WSD: acuerdos e informaciones relevantes para la interaccin (comunicados
explcitamente o no). Puede ser acordada verbalmente o expresada en
cualquier formato. Segn se vayan adoptando lenguajes semnticamente
ricos para la descripcin de servicios web, se ir trasladando ms
informacin al WSD.

 Secuencia de operacin:
Acuerdo en semntica y WSD entre proveedor y requeridor humano sobre la
interaccin que desean de los agentes
El requeridor humano introduce el WSD y la semntica en su agente
(dinmicamente o a travs de programa)
El proveedor humano introduce el WSD y la semntica en su agente
Los agentes interactan

Figura 3-10. Escenario 1 de uso de Servicios Web.

3.7.4.3 Escenario 2: Partes conocidas obtienen WSD dinmicamente


El WSD es proporcionado dinmicamente por la entidad proveedora. Esto permite a
las entidades requeridoras asegurarse de que siempre disponen de la ltima versin
y permite al proveedor actualizar peridicamente el WSD sin necesidad de
renegociar la semntica entre humanos.

Pg. 3-48

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Figura 3-11. Escenario 2 de uso de Servicios Web.

 Secuencia de operacin:
Acuerdo en la semntica que indicar qu tipos de WSD sern adecuados
Introduccin de la semntica en los agentes
Lectura del WSD (simple mtodo HTTP GET en un URL) y comprobacin de
que concuerda con la semntica pactada
Interaccin entre agentes

3.7.4.4 Escenario 3: Mltiples proveedores, descubrimiento manual


El requeridor humano no conoce de antemano qu servicio web desea. Emplea una
herramienta de bsqueda para encontrar un servicio web semnticamente
compatible con lo que quiere lograr. Despus, selecciona uno de entre los servicios
encontrados y lo utiliza.

 Actores:
Requeridor humano
Proveedor humano
Agente requeridor
Agente proveedor
Herramienta de bsqueda (alojada en la entidad requeridora, en la
proveedora o en una tercera). Puede ser un motor de bsqueda (p.ej.
google) o un registro UDDI.

 Artefactos:
WSD
Semntica

Pg. 3-49

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

FuncID. Representa toda aquella informacin que sea necesaria para que el
agente requeridor identifique sin ambigedad la semntica o la funcionalidad
del servicio. Pueden ser unas palabras, una URI, un TModel de UDDI,

Figura 3-12. Escenario 3 de uso de Servicios Web.

 Secuencia de operacin:
Acuerdo en la semntica
Introduccin de semntica y WSD
La herramienta de bsqueda coge WSD y FuncID
El requeridor humano coge el WSD
Entrada de semntica y WSD en el agente requeridor
Interaccin entre agentes

3.7.4.5 Escenario 4: Mltiples proveedores, acceso a WSD del


proveedor
Se requiere de un artefacto adicional al escenario anterior. El WSD URL es la
informacin que necesita el agente requeridor para acceder al WSD del agente
proveedor.

Pg. 3-50

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Figura 3-13. Escenario 4 de uso de Servicios Web.

3.7.4.6 Escenario 5: Mltiples proveedores, seleccin automtica


El

agente

requeridor

dinmicamente

selecciona

uno

de

varias

entidades

proveedoras potenciales (todas ellas implementan servicios web semnticamente


compatibles). Las semnticas especificadas manualmente por humanos, han sido
previamente fijadas.
Se aade como actor un agente seleccionador, que es un componente operado por
la entidad requeridora, la proveedora o una tercera.

Figura 3-14. Escenario 5 de uso de Servicios Web.

3.7.4.7 Escenario T: Diagrama en tringulo


Abstraccin de mayor nivel de los escenarios 4 y 5. Se une la herramienta de
bsqueda y el agente seleccionador en un nico agente de bsqueda, se omite la
semntica y se abstraen los detalles de las entidades.

 Actores:
Entidad requeridora

Pg. 3-51

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Entidad proveedora
Agente buscador

 Secuencia de operacin:
La entidad proveedora publica WSD
La entidad requeridora encuentra WSD
Interaccin entre agentes

Figura 3-15. Escenario en T de uso de Servicios Web.

Pg. 3-52

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.7.5 TECNOLOGAS PARA SERVICIOS WEB


Los conceptos de SOA y Servicios Web estn relacionados con la visin del futuro
del World Wide Web de Berners-Lee (1999), la Web Semntica. La Web Semntica
consiste en organizar los documentos de tal modo que se facilite el acceso
automtico a la informacin y la bsqueda de datos de forma mucho ms
significativa de lo que permiten las actuales herramientas de bsqueda. La sencillez
de uso y utilidad de la web se mejorar gracias a:

Documentos marcados con informacin semntica. Metadatos o informacin


orientada a aplicacin y no a lectura humana.

Vocabularios

comunes

de

metadatos

(ontologas)

mapas

entre

vocabularios que describan a los creadores de documentos cmo marcarlos


para que agentes usen la informacin.

Agentes automticos que ejecuten tareas para los usuarios a travs del uso
de metadatos.

Servicios basados en web para proveer a los agentes de informacin. Es


decir, aplicaciones con arquitectura orientada al servicio.

Utilidades bsicas: URI1s, XML, Namespaces.


Ante este panorama, no muy lejano, sobre el futuro del intercambio de informacin
en internet, se puede hablar de un presente prometedor en cuanto al uso de
Servicios Web. Hoy en da ya se estn usando Servicios Web y se estn
constatando importantes ventajas en la concepcin de aplicaciones distribuidas:

9 Ana las ventajas de Java como lenguaje de programacin universal y


multiplataforma y XML como formato para el soporte de datos universal y
multiplataforma.

9 Los contratos que definen los servicios que se compromete a ofrecer una
aplicacin y el interfaz para obtenerlos, son publicados en un formato
estndar comprensible para cualquier aplicacin.

9 Por basarse principalmente en el protocolo HTTP, no tienen ningn problema


para ejecutarse a travs de cortafuegos (firewalls).

9 Permiten que los programas (en lugar de los humanos) intercambien


informacin y comandos usando mensajes XML.

Uniform Resource Identifier. Identificacin de un punto de acceso a contenido de cualquier

tipo (imagen, programa, documento,). Un caso particular es un URL (Uniform Resource


Locator), que hace referencia a una pgina web.

Pg. 3-53

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

9 Mayor sencillez de implementacin y flexibilidad que los sistemas


fuertemente acoplados tipo CORBA. Los sistemas dbilmente acoplados son
el nico modo de comunicar o hacer interoperar aplicaciones que no se
conocan cuando fueron programadas.

9 Basado en estndares internet mundialmente conocidos y establecidos:


HTTP, XML, URL
Evidentemente,

nuevas

tecnologas

han

emergido

para

llevar

cabo

la

implementacin de los Servicios Web. Aunque la mayora de ellas tienen en XML su


referente principal, XML naci con la intencin de ser un lenguaje de marcado
simple que sirviera para almacenar informacin estructurada en ficheros. Por tanto,
necesita de mayores refinamientos para responder a las necesidades de los
servicios web. Primeramente, cuando comenz a utilizarse XML para intercambiar
informacin entre aplicaciones, se le aadi el schema que describa la informacin
a intercambiar. Cuando comenz a usarse como middleware, nuevas utilidades
(lenguajes especficos XML) proliferaron alrededor de XML:

SOAP (Simple Object Access Protocol). Protocolo extensible para el


intercambio de datos XML. Propone un mecanismo de creacin de paquetes
estructurados de datos. Los servicios exponen la funcionalidad a los usuarios
a travs de este protocolo. Se identifica con la implementacin de
arquitecturas (no REST) de objetos distribuidos u operacin a travs de
red.

WSDL (Web Service Description Language). Los servicios describen sus


interfaces en documentos WSDL para que sea posible la construccin de
clientes que dialoguen con ellos. Este lenguaje define los formatos
permitidos para los mensajes intercambiados entre agentes. Se describen
los servicios web como un conjunto de puntos de acceso operables a travs
de mensajes conteniendo documentos o procedimientos (RPC).

UDDI (Universal Discovery Description and Integration). Forma de registrar


los servicios para que estn al alcance de usuarios potenciales.

La integracin de diferentes mdulos que se persigue en los servicios web lleva


necesariamente al concepto de componente como unidad mnima de composicin
del sistema distribuido. Los componentes necesitan de un Component Execution
Environment (CEE), tecnologas que provean de infraestructura tcnica en tiempo
de ejecucin. Las tecnologas CORBA y DCOM tuvieron un xito parcial facilitando la
interaccin entre componentes. Especialmente CORBA consigue la colaboracin
entre componentes distribuidos independientemente de la plataforma en la que se
ejecuten cada uno de ellos. Sin embargo, se basan en un grado de acoplamiento
grande entre componentes (en cuanto al interfaz esttico para la invocacin de
unos servicios conocidos de antemano), y de los componentes a las plataformas
(un componente implementado para una plataforma no es reutilizable en otra), lo

Pg. 3-54

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

que hace que un cambio en un componente requiera un alto grado de


reprogramacin y pruebas en los otros componentes conectados.
En el caso de los servicios web, se intenta desacoplar al mximo los componentes
entre s (los servicios ofrecidos y requeridos por los componentes pueden cambiar
dinmicamente) y stos de las plataformas. Surgen nuevos modelos especficos
para el desarrollo de aplicaciones:

 .NET. Proyecto iniciativa de Microsoft, lanzado en 2002, para crear una nueva
plataforma de desarrollo SW con intencin de lograr transparencia de red,
independencia de plataforma y desarrollo rpido de aplicaciones. Fundamentos:
CLI (Common Language Infrastructure) es una mquina virtual que ejecuta
MSIL (Microsoft Intermediate Language) y una librera estndar (Common
Language Runtime) diseada para ser independiente de lenguajes de
programacin y de sistemas operativos. CLI soporta cualquier lenguaje de
programacin orientado a objeto pero se ofrecen versiones especficas de
lenguajes para .NET como: C#, VisualBasic.NET, JScript.NET, Posibilidad
de ensamblar en MSIL cdigo de diferentes lenguajes.
Ligado a Microsoft Windows como plataforma de ejecucin.
Creacin de servicios web sobre SOAP.
Nueva

arquitectura

de

componentes

COM+

que

sustituye

COM

(Component Object Model) como fundamento de la programacin orientada


a componente.

 J2EE (Java 2 Platform Enterprise Edition). Es un estndar promovido por Sun


(versiones

desarrolladas

por

diferentes

empresas,

por

ejemplo:

IBM

WebSphere, BEA Weblogic, Oracle9iAS o Sun ONE). Entorno de desarrollo


basado en Java e independiente de plataforma para la generacin de
aplicaciones web para clientes finos (no requieren de grandes capacidades, slo
consumo de HTML y ejecucin de applets). Fundamentos:
Creacin de HTML para consumo de los clientes con JSP (Java Server Pages)
y servlets.
EJB (Enterprise JavaBeans). Servicios como concurrencia, seguridad y
gestin

de

memoria.

Tecnologa

basada

en

servidor

para

distribuir

componentes. Soporta XML.


JDBC (Java Data Base Connectivity), interfaz estndar a bases de datos
Java.
En la Tabla 3-1 se resumen los conceptos paralelos entre las aproximaciones
alternativas J2EE y .NET. En cualquier caso, el uso extensivo de cualquiera de estos
dos modelos de desarrollo est pensado slo para grandes corporaciones. En la
creacin de aplicaciones ms humildes, en las que la inversin es menor y no se
puede permitir un ciclo de aprendizaje largo ni un gasto importante en

Pg. 3-55

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

herramientas

de

desarrollo,

se

opta

por

entornos

ms

modestos

no

necesariamente ligados con un solo distribuidor. En este contexto y para la


generacin de aplicaciones web, est muy extendido el uso de un conjunto de
productos de SW libre englobados bajo las siglas LAMP (Linux, Apache, MySQL,
Perl/PHP/Python). Se trata de una plataforma que se ha convertido en estndar de
facto para el desarrollo web de cdigo abierto. Usa Linux como Sistema Operativo,
Apache

como

servidor

web,

MySQL

como

RDBMS

(Relational

Data

Base

Management System) y PHP, Perl Python como lenguaje de script. Se habla de


WAMP, cuando se sustituye el SO por Windows.
Ser necesario un tiempo para ver cul de las utilidades y plataformas perdura,
pero lo que es seguro es que XML es y seguir siendo un ingrediente presente en
cualquiera de los casos.
Frente a todas estas promesas y expectativas de los servicios web quedan an
aspectos por madurar:

XML no es un lenguaje estndar, es un metalenguaje estndar. La


estandarizacin de schemas y reglas de transformacin permitir entender
cualquier lenguaje XML.

No hay un protocolo estndar (por encima de HTTP) para el intercambio de


informacin en formato XML (SOAP, BizTalk,).
Tabla 3-1. Comparacin .NET vs. J2EE

.NET (Microsoft)

J2EE (Sun)

Mquina Virtual

CLI

JVM

Cdigo intermedio

MSIL

Java Bytecode

Lenguaje de programacin

C# (y otros)

Java

Arquitectura de componentes

COM+ (COM/DCOM)

EJB

Gestin de datos web dinmicos

ASP

JSP

Pg. 3-56

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

33..88 C
CO
ON
NC
CL
LU
USSIIO
ON
NE
ESS
Compendio de tcnicas de integracin seleccionadas para el entorno
multidisciplinar y su influencia en la arquitectura.
Arrancaba este captulo con el propsito de investigar un abanico de tcnicas que,
orientadas a la integracin desde diferentes puntos de vista, pudieran servir de
soporte a los componentes del Motor de Colaboracin de Herramientas (MCH) que
se recuerdan en la Figura 3-16.

IC

Interfaz
Config

SD

STR

IS

Interfaz Herramientas

DIRECTOR
Modelos
Dominios

Gramticas
XML Dominios

Repositorios
XML

MOTOR DE
COLABORACIN
MOTOR DE
DE
COLABORACIN HERRAMIENTAS
DE MODELOS
(MCH)
(MCM)

Metadatos
Figura 3-16. Arquitectura del entorno multidisciplinar.

En este apartado se resumen las conclusiones derivadas de ese estudio. Para cada
tcnica de integracin se obtienen unas conclusiones y se aplican al componente
del entorno ms directamente relacionado. La Tabla 3-2 muestra esta relacin
entre componentes del entorno y funcionalidades de integracin. Cada una de las
filas de esta tabla se asocia con uno de los subapartados que se exponen a
continuacin.

Pg. 3-57

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Pg. 3-58

Motor Colaboracin
Modelos (MCM)

Motor Colaboracin Herramientas


(MCH)

Tabla 3-2. Componentes del MCH y funcin de integracin que desempean.

Componente

Integracin de

Gramticas XML de
Dominios

Gramticas

Modelos de Dominio

Modelos

DIRECTOR

Tcnicas de desarrollo de
SW

Repositorio

Conocimiento

Interfaz de Herramientas

Aplicaciones

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.8.1 INTEGRACIN DE GRAMTICAS (GRAMTICAS


XML DE DOMINIOS)
Este mdulo del Motor de Colaboracin de Modelos (MCM) debe permitir describir
un lenguaje especfico y diferente para cada uno de los dominios pero manteniendo
un tronco comn entre ellos que permita su interrelacin. Se trata, por tanto, de un
problema de definicin e integracin de gramticas.
Las conclusiones del proyecto GSRC se pueden extrapolar y aplicar al mdulo de
Gramticas XML de Dominio del MCM tal como muestra la Figura 3-17:

Sintaxis Abstracta

Estructura
del
lenguaje

Sintaxis Concreta (XML)


Transformaciones Sintcticas

Significado
del lenguaje

Sistema
tipos

Sistema
tipos

Sistema
tipos

Sistema
tipos

Semntica Semntica Semntica Semntica

Gramtica
IC

Gramtica
SD

Gramtica
STR

Gramtica
IS

Figura 3-17. Diseo de las gramticas XML en base a servicios ortogonales.

 La separacin de los cinco servicios constituyentes de un lenguaje sera la


siguiente para el caso de las gramticas XML:
Sintaxis abstracta formada por la definicin de los componentes bsicos,
relaciones (a muy alto nivel), jerarqua y capacidades de instanciacin que
se vayan a usar en cualquiera de las gramticas de dominio.
Sintaxis concreta. Un lenguaje XML especfico que permita reflejar los
conceptos recogidos en la sintaxis abstracta, constituyndose en el formato
persistente para la informacin.

Pg. 3-59

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Transformaciones

sintcticas.

Mecanismos

que

permitan

realizar

transformaciones sobre las instancias de la sintaxis concreta seleccionada.


Se utilizarn tecnologas XML para ello.
Sistema de tipos y semnticas. Se trata de la parte especfica de cada uno
de los dominios. A travs de tecnologas XML se completar la estructura
comn (sintaxis abstracta, concreta y transformaciones) refinndola en el
caso particular de cada uno de los dominios. Este refinamiento consistir en
la definicin de cada sistema de tipos de datos particular y en la
especificacin de la semntica propia de cada dominio. Todo esto ser
tratado en detalle en el prximo captulo.

 De los cinco niveles de interoperatividad definidos, dada la arquitectura y modo


de

funcionamiento

del

MCM,

sera

necesario

lograr

los

primeros

(compatibilidad en sintaxis abstracta, concreta y transformaciones) para que la


entidad DIRECTOR pueda generar automticamente datos de entrada para una
herramienta a partir de los resultados de otras. En resumen, la estructura de
las cuatro gramticas debe ser la misma para lograr este grado de
interoperatividad, pero el significado es propio de cada dominio.

 La compatibilidad a nivel 4 y 5 (sistemas de tipos y semnticas) se podra


lograr entre herramientas del mismo dominio para que pudieran intercambiar
modelos de datos completos (si se basan en el mismo sistema de tipos) o
informacin en tiempo de ejecucin (si comparten adems la semntica).
Aunque ste no es objeto de la presente tesis, la ortogonalizacin que se
realiza habilita la construccin futura de esos servicios sobre los actuales.

Pg. 3-60

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.8.2 INTEGRACIN DE MODELOS (MODELOS DE


DOMINIO)
Tal y como muestra la Figura 3-18, se ha planteado una estructura de cuatro
vistas, formalizadas cada una de ellas a travs de los conceptos de MOF. XML
soporta esta estructura de la siguiente forma:

 M3, Meta-metamodelo. El Schema XML Arch.xsd define el lenguaje comn


basado en componentes y conectores con jerarqua.

 M2, Metamodelos de dominio. Los cuatro schemas especializados para las


vistas se definen extendiendo y especializando Arch.xsd. Estos schemas
definen los lenguajes especficos de domino.

 M1, Modelos de dominio. El empleo de los lenguajes especficos para describir


un sistema da lugar a instancias XML.

 M0, Objetos de dominio. Los objetos de dominio se representan con estructuras


propias de XML dentro de los documentos.
Adems, otros dos lenguajes XML como son XSLT y LER (Lenguaje para la
Especificacin de Reglas) dan soporte al flujo horizontal de informacin y a la
validacin de implicaciones horizontales (ver Figura 3-19).

Arch.xsd

Meta-Metamodelo
Metamodelos
de dominio
Modelos
de dominio

IC

SD

STR

IS

stma

stma

stma

stma

Objetos
de dominio
Figura 3-18. Formalizacin de las cuatro vistas y soporte en XML.

Pg. 3-61

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

XSLT

Meta-Metamodelo

LER

IC

SD

STR

IS

stma

stma

stma

stma

LER.xsd

Transf

Figura 3-19. Transformaciones y validaciones horizontales.

El MCH se basa en la colaboracin de herramientas a travs de las vistas de


dominio para evitar centrarse en las relaciones entre herramientas concretas. Cada
herramienta se ajusta a uno de los modelos de dominio y as pasa a estar
relacionada con otras, a travs de las relaciones entre dominios. Al formalismo
interno de colaboracin entre dominios se le denomina TIM (Tool Independent
Model) y al formalismo en el que se basa el acoplamiento de las herramientas a los
dominios se le denomina TSM (Tool Specific Model). De hecho, el Modelo de
Colaboracin de Modelos (MCM) o parte ms interna del entorno se desarrolla de
acuerdo con el TIM, y la capa exterior que lo conecta a herramientas particulares es
la que lleva a la prctica un TSM concreto. La Figura 3-20 muestra estas relaciones
junto a las concepciones de PIM (vista IC) y PSM (vistas SD, STR e IS).

Pg. 3-62

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

PIM

TIM
Tool
Independent
Model

PSM

Transformaciones
XSLT
Reglas
LER

TSM

Cdigo
final

Tool
Specific
Model

Doc.
final

TOOLS
Figura 3-20 Conceptos MDA en el entorno multidisciplinar.

Pg. 3-63

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.8.3 INTEGRACIN
DE
TCNICAS
DESARROLLO DE SW (DIRECTOR)

PARA

El entorno multidisciplinar tiene como ltimo objetivo la generacin de SW, por


tanto, la disciplina de Ingeniera del SW tiene un carcter transversal respecto al
resto de dominios, que ofrecen una aportacin ms vertical. De hecho, el ciclo de
vida del sistema bajo desarrollo se define en trminos de Ingeniera del SW para
integrar las aportaciones de todos los dominios. Esta caracterstica de gestin
transversal se materializa en la entidad DIRECTOR, que es el componente de la
arquitectura del entorno que coordina todos los esfuerzos de integracin de
informacin y los dirige de forma acorde al Proceso SW que se elija seguir. Por ello,
la Figura 3-16 ya mostraba grficamente al DIRECTOR como el componente central
de la arquitectura, un componente transversal u horizontal.
De entre las tcnicas analizadas para el seguimiento de un Proceso SW y la
inclusin en el cdigo final de todos los matices aportados desde diferentes
dominios se han seleccionado los Mtodos Formales de Especificacin y los
Generadores de Programas basados en XSLT sobre los dems. Tanto MDSC
(Multi-Dimensional Separation Of Concerns) como el conjunto de tcnicas de SW
dirigidas a dominio, estn muy centradas en la figura del programador y en el
tratamiento del problema desde su punto de vista particular. No parece sencillo su
encaje en la arquitectura general del entorno ni la colaboracin con herramientas
especficas de campos tan alejados como el control. Por el contrario, los mtodos
formales y la generacin de cdigo con XSLT pueden tener cabida en el MCH y su
relacin directa con las herramientas parece ms sencilla.
El empleo de estas tcnicas divide el Proceso de Generacin de SW, y por tanto, el
trabajo de la entidad DIRECTOR, en dos grandes fases o subprocesos:

1. Especificacin Formal. La especificacin del sistema desde cada uno de


los dominios de Ingeniera de Control, Sistemas Distribuidos y Sistemas de
Tiempo Real. Esta especificacin multi-dominio se realiza utilizando las
gramticas especficas hasta conseguir como resultado una especificacin
XML validada formalmente desde todos los puntos de vista. Esto constituye
en s un proceso cuyos pasos e iteraciones habr que definir.

2. Generacin Automtica de Cdigo. El resultado obtenido en la


especificacin formal multi-dominio es el punto de arranque para la
generacin del programa mediante tecnologas XSLT. Esta fase es propia del
dominio de Ingeniera del Software y las especificaciones que se hagan al
respecto vendrn dadas en la gramtica de dominio correspondiente.
Tambin se trata de un subproceso cuyos pasos habr que definir.
Las aportaciones de los dominios tambin son diferentes en estos dos subprocesos
o fases. La fase de generacin de cdigo es exclusiva de la disciplina de Ingeniera

Pg. 3-64

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

de SW, aunque parte de los resultados de una especificacin en la que toman parte
los otros tres dominios.
Comenzando por la primera de las fases, es factible el uso de un mtodo formal
basado en lenguajes XML para la expresin de especificaciones y el uso de
mecanismos XML para la realizacin de pruebas formales que validen el
cumplimiento de las especificaciones. Se plantea la expresin y validacin de
especificaciones de dos formas en funcin de su naturaleza:
Especificaciones Gramaticales. Hay especificaciones que se pueden recoger
y validar directamente mediante las gramticas especficas de cada dominio, ya
que su uso implica una formalizacin de los datos. Las especificaciones
introducidas desde una herramienta concreta se expresan en una gramtica
formal dando lugar a un documento XML, que puede ser validado en su
estructura, tipos de datos y relaciones entre elementos por estar todo esto
recogido en el XML Schema de esa gramtica. De este modo, se recogen
especificaciones propias de cada vista y el DIRECTOR deber comprobar que el
sistema en desarrollo va cumpliendo todas esas especificaciones.
Especificaciones

basadas

en

reglas.

Habr

especificaciones

de

otra

naturaleza que deban describirse en base a reglas. Aquellas especificaciones


que implican a ms de un dominio exceden los lmites de una gramtica
particular porque involucran a ms de una. Para stas, se requiere de un nuevo
lenguaje

XML

que

permita

expresar

reglas

comprobar

despus

su

cumplimiento (LER, Lenguaje para Especificacin de Reglas). ste ser uno de


los puntos a resolver en el siguiente captulo.
En todos los casos, el mtodo de especificacin empleado es declarativo u orientado
a la propiedad, es decir, se irn recogiendo el conjunto de condiciones
(gramaticales y basadas en reglas) que debe satisfacer el sistema para ser
correcto. El DIRECTOR ser el encargado de realizar las validaciones necesarias
durante el proceso. El grado de este mecanismo de validacin formal ser variable
segn las necesidades del usuario y el nivel de madurez CMM de su Proceso.
Concretamente, a travs del interfaz de configuracin, el coordinador del proyecto
podr definir sobre qu subsistemas aplicar la metodologa formal.

Pg. 3-65

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Especialistas
Herramientas
Interfaz
Config

xml

xml

xml

IC

SD

STR

Interfaces

DIRECTOR

subPROCESO
ESPECIFICACIN
FORMAL

LER

Figura 3-21. Labores del DIRECTOR relacionadas con el subproceso de


especificacin formal.

La Figura 3-21 muestra la gestin por parte del DIRECTOR de esta primera fase del
Proceso SW que ha sido configurada por el coordinador. A lo largo de ese
subproceso, al DIRECTOR le llega informacin de las diferentes herramientas de
cada dominio en forma de documentos XML, que deben ser validados contra el
Schema correspondiente para asegurar el cumplimiento de las reglas gramaticales
(adems de la coherencia), as mismo, el DIRECTOR validar el cumplimiento de los
requisitos expresados en LER (Lenguaje Especificacin Reglas).
En cuanto al subproceso de Generacin de Cdigo, partir de una especificacin
completa validada para lanzar alguna o varias de las siguientes tareas:
Creacin del esqueleto de la aplicacin.
Recoleccin de componentes reutilizables en el repositorio y parametrizacin de
dichos componentes para la aplicacin actual.
Recoleccin de componentes generados desde alguna de las herramientas
integradas, ya que alguna de estas herramientas tambin puede poseer
capacidades de generacin de cdigo.
Generacin de los nuevos componentes que se necesiten.
Ensamblado completo de la aplicacin juntando esqueleto, componentes
nuevos, componentes del repositorio y componentes codificados por alguna de
las herramientas del entorno.
Como comentario se puede aadir que los problemas inherentes a los mtodos
formales (en cuanto a las inexactitudes que caben en la expresin formal de
requisitos y en la implementacin fsica del sistema) se ven atenuados por la propia

Pg. 3-66

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

filosofa del entorno. En primer lugar, en el inicio del proceso los especialistas
emplean las herramientas habituales en cada uno de los dominios (adaptadas a sus
necesidades expresivas) para capturar los requisitos, con lo que se minimiza el
riesgo de la formalizacin inexacta de los requisitos del usuario. En segundo lugar,
el empleo de herramientas especializadas en la generacin de cdigo para los
dispositivos comnmente empleados minimiza el salto de mquina abstracta a
fsica.
En la Figura 3-22 se observa la labor del DIRECTOR en el subproceso de Generacin
Automtica de Cdigo. Se parte de una especificacin multi-dominio coherente y
formalmente validada y, de acuerdo a las especificaciones que relativas a la
Ingeniera del SW se han expresado (en la gramtica de dominio asociada), se dan
los pasos orientados a la construccin del cdigo final mediante la aplicacin de
hojas de estilo XSLT y el uso de componentes del repositorio y de las herramientas.
Un lenguaje ADL permitir al DIRECTOR expresar la arquitectura global y las
relaciones entre componentes.
En el prximo captulo se detallar el diseo de este subproceso.

Componentes
generados por
herramientas

Interfaz
Config.
IS
IC

SD
STR

DIRECTOR

XSLT

ADL
ESPECIFICACIN
VALIDADA

subPROCESO GENERACIN CDIGO


CDIGO Y
DOCUMENTACIN
FINAL

Repositorio
Componentes
Figura 3-22. Labores del DIRECTOR relacionadas con el subproceso de Generacin
de Cdigo.

Pg. 3-67

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.8.4 INTEGRACIN
(REPOSITORIO)

DE

CONOCIMIENTO

El mdulo repositorio es algo ms que la base de datos del entorno multidisciplinar


porque no slo se pretende el simple almacenaje y recuperacin de los datos
puntuales de un proyecto. Se pretende que el repositorio maneje mayores niveles
de abstraccin y permita almacenar y recuperar cuando se precise: informacin
(datos organizados que ayuden a tomar decisiones al usuario), conocimiento
(relaciones, clasificaciones, metadatos y componentes inferidos de unos proyectos y
de utilidad para otros futuros) y experiencia (estndares y mejores prcticas de
aplicacin genrica). La REUTILIZACIN es la facultad que se desea para el
entorno y que quiere materializarse en el mdulo repositorio. Pero reutilizacin en
el sentido ms amplio, no slo reutilizacin de componentes, sino reutilizacin de
todo el conocimiento que se pueda deducir en cada toma de decisin, cada sistema
diseado y cada proyecto o conjunto de proyectos terminados. El conocimiento
potencial adquirido en cada toma de decisin debe ser recogido para emplearlo en
subsiguientes decisiones. La reutilizacin en estos trminos tan ambicioso obliga a
plantear dos fases:
Captura de conocimiento. Los datos puntuales deben ordenarse adecuadamente
para identificar sobre ellos patrones, secuencias de eventos, clusters y
relaciones.
Recuperacin sistemtica de informacin. El conocimiento no debe permanecer
esttico hasta que alguien decida emplearlo, debe fluir hacia dnde se necesite
(hacia el proyecto y especialista adecuado) y cundo se necesite (sin necesidad
de una invocacin explcita por parte del usuario). En definitiva, debe
recuperarse sistemtica y automticamente, y dirigido a dnde y cundo pueda
ser til.
El uso de tecnologas XML facilita ambas fases porque la informacin se expresa
explcitamente en un formato estndar que favorece la captura de conocimiento y si
este conocimiento se enriquece adecuadamente con meta-informacin, queda
etiquetado para ser recuperado automticamente cuando el entorno decida que
puede ser de utilidad.
El conjunto del conocimiento gestionado se bifurca en dos tipos de salida
dependiendo de la naturaleza del destinatario que lo vaya a procesar:
Documentos dirigidos a humanos. Es muy sensato asociar labores de gestin
documental

de

generacin

automtica

de

documentos

al

entorno

multidisciplinar porque a partir de todo el volumen de informacin que almacena


el

repositorio

se

pueden

generar

automticamente

documentan el curso de un determinado proyecto

Pg. 3-68

los

informes

que

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Documentos dirigidos a programas. Todo aquel conocimiento inferido que deba


ser aplicado automticamente en un futuro deber ser expresado en un formato
procesable mediante programa.
En cualquiera de los casos, XML vuelve a mostrarse como una opcin adecuada ya
que, a partir de un formato nico (para toda la informacin en general) y
empleando las mismas tecnologas, pueden generarse bien documentos legibles
para el hombre o bien informacin procesable automticamente por un programa.
Aunque el diseo del repositorio es materia del siguiente captulo, ya se pueden
esbozar aqu alguna de sus caractersticas:

Informacin relativa al proyecto: Configuracin del proyecto (proceso SW,


herramientas usadas, usuarios), instancias para cada uno de los dominios,
ficheros binarios,

Conocimiento acumulado: componentes diseados y parametrizables para su


reutilizacin, reglas de relaciones entre elementos del mismo o de diferentes
dominios (LER, Lenguaje para Especificacin de Reglas),

Mecanismos de activacin de las reglas. Cada regla estar acompaada por


unas condiciones de activacin y cuando el DIRECTOR detecte que se cumplen
esas condiciones activar la regla.

Gestin documental. Las tomas de decisiones y resultados obtenidos se pueden


documentar automticamente y controlar las versiones, establecer mecanismos
de bsqueda, etc.

En resumen, se trata de que durante el propio uso del entorno ste se vaya
enriqueciendo con el conocimiento adquirido gracias a sus mecanismos de captura
y recuperacin automtica de la informacin.

Pg. 3-69

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

3.8.5 INTEGRACIN DE APLICACIONES (INTERFAZ


DE HERRAMIENTAS)
Tal y como ilustraba la Figura 3-16, el componente de Interfaz de Herramientas
(junto con la Interfaz de Configuracin) convierten al Motor de Colaboracin de
Modelos (MCM) en un Motor de Colaboracin de Herramientas (MCH). Es decir, este
componente acomoda las particularidades de cada herramienta a las convenciones
generales del entorno (proceso SW definido, gramticas, modelos,). Debe utilizar
un middleware estndar para que las herramientas sean capaces de leer y escribir
la informacin de los modelos de dominio o vistas del sistema.
Tal y como se ha visto, la mayora de los conceptos en los que se fundamentan los
servicios web se adaptan perfectamente a las necesidades del mdulo de Interfaz
de Herramientas. Adems, la resolucin de esta capa usando servicios web
permitir al entorno multidisciplinar favorecerse de los beneficios que reporta el uso
de estas tecnologas.
La concepcin de los servicios web no se limita a la manera de construir la interfaz
con las herramientas, el conjunto del sistema tiene que ser concebido como una
arquitectura SOA (Service Oriented Architecture). La adopcin de SOA y de los
conceptos de servicios web en el entorno implican el uso de:

 Formato de datos estndar (XML) sobre protocolo de transporte estndar


(HTTP).

 Identificacin de los servicios que se ofrecen o se requieren con recursos


accesibles en URIs.

 Agentes. La comunicacin automtica (sin intervencin del usuario) se produce


entre entidades agente. Habr un agente asociado a cada una de las
herramientas y un agente en el MCH (Agente Proveedor).
Sobre estas bases, se selecciona el estilo de arquitectura REST (Representation
State Transfer). Se considera ms adecuado para el entorno porque el servicio
ofrecido siempre toma la forma de un recurso XML, un documento que se
intercambia entre las partes. Por ello se pueden resumir en dos las operaciones
bsicas a realizar: enviar recoger un documento XML, que se implementarn a
travs de los mtodos http GET y http POST. Con lo cual, un simple servidor web
es capaz de implementar estas funcionalidades. Por otro lado, tambin se usan
documentos XML (el WSD) para exponer los servicios. Esta arquitectura concuerda
con la propia del WWW y la futura Web Semntica.
Tras analizar los diferentes escenarios de interaccin posibles que se presentan
para servicios web en el apartado 3.7.4, el escenario ms adecuado parece ser el
cuarto (acceso automtico al WSD del proveedor), con la salvedad de que en el
entorno hay un solo proveedor y no existe fase de descubrimiento ni seleccin

Pg. 3-70

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

automtica. El proveedor es siempre el MCH y las herramientas toman el papel de


requeridoras de servicio. Los roles que toman parte en el entorno son:

 Actores:
Coordinador del proyecto. Selecciona qu herramientas (de entre las que
han sido integradas) van a emplearse en un determinado proyecto.
Especialistas. Cada una de las herramientas particulares es gobernada por
un especialista.
Agente Proveedor en MCH. El Motor de Colaboracin de Herramientas
ofrece, a travs de este agente, servicios de almacenamiento, validacin,
coordinacin y traduccin de la informacin entre vistas.
Agente Requeridor en cada herramienta particular. Las herramientas
se conectan al MCH para enviar o recoger un documento XML.

 Artefactos:
URL para el WSD. Los agentes de las herramientas deben conocer el URL
desde el que acceder al WSD del MCH.
WSD. El MCH describe el interfaz a los servicios que ofrece en este
documento escrito en la gramtica XML WSDL (Web Service Description
Language) conocida de antemano por los agentes proveedor y requeridor. El
WSD especifica los ocho URIs asociados a las operaciones enviar y recoger
instancia XML para cada uno de los cuatro dominios.
Semntica. Los documentos XML intercambiados utilizan uno de los cuatro
lenguajes de dominio conocidos de antemano. Por tanto, la semntica de la
informacin es inherente al lenguaje empleado.

 Secuencia de operacin:
Se programa el agente proveedor en el MCH incluyendo el WSD y la
configuracin adecuada del servidor web para habilitar las URIs para envo y
recogida de documento XML. Este sencillo interfaz permite al MCH
interactuar

con

herramientas

desconocidas

en

el

momento

de

su

implementacin.
Se programa un agente requeridor para cada herramienta. ste deber
traducir los documentos (en ambos sentidos) entre una de las gramticas de
dominio del entorno y el formato y semntica propios de la herramienta.
El coordinador selecciona las herramientas a emplear en un proyecto.
Los especialistas recogen del MCH (a travs de la interaccin entre agentes)
la instancia actual de aquella vista propia para su herramienta. Tras trabajar
con ella, envan el nuevo estado de la instancia al MCH.

Pg. 3-71

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Aunque las nicas operaciones que los agentes requeridores piden al MCH sean
enviar o recoger una instancia XML, de forma transparente a las herramientas se
desencadenarn en el MCH toda una serie de operaciones:

validar cada instancia localmente y transversalmente (respecto a otras)

traducir las implicaciones que una vista recogida tenga en el resto

devolver el informe de los errores o incoherencias detectadas en la instancia


recogida

almacenar o leer la instancia de la base de datos global

El MCH provee almacenamiento, coordinacin y validacin de modelos y las


herramientas realizan funcionalidades particulares que se reflejan en nuevas
instancias de modelos o cambios en las mismas.
Debe remarcarse que en esta descripcin se est hablando de dos usos de XML y
en cada caso con diferentes gramticas: por una parte la propia informacin que se
intercambian las herramientas con el entorno estar expresada en alguna de las
cuatro gramticas de dominio; por otra parte el contrato WSD se expresa en el
lenguaje estndar WSDL.
Las decisiones de diseo enumeradas conducen a un escenario como el que
muestra la Figura 3-23, en donde se aprecia cmo el Interfaz de Herramientas
toma la forma de un Agente Proveedor de servicios web que relaciona las
herramientas tonel MCM. La herramienta A, relacionada con el dominio de la
Ingeniera de Control es adaptada al entorno a travs de un agente especfico. ste
accede al URL en el que encontrar el WSD del MCH (expresado segn WSDL),
donde obtiene los puntos de acceso a los servicios (URIs). A partir de ese
momento,

los

agentes

son

intercambiando instancias XML.

Pg. 3-72

capaces

de

comunicarse

travs

de

HTTP

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

Herramienta

Agente A

URL
WSD

xml

IC

Protocolo HTTP

xml

WSDL

WSD

URIs IC

URIs SD

URIs STR

Interfaz Herramientas
(Agente Proveedor)

DIRECTOR
Figura 3-23. Interfaz herramientas-MCH con sevicios web.

La Figura 3-23 ilustra cmo el Interfaz de Herramientas (Agente Proveedor) acta


como delegado del DIRECTOR (componente central del MCM) y permite el acceso
desde el exterior a aquellos servicios que el DIRECTOR quiera publicar.
Respecto a los lenguajes concretos XML (SOAP UDDI) que estn surgiendo para
intentar estandarizar la implementacin de servicios web, an no tienen una
aceptacin amplia, no son lo suficientemente estables y sufren continuas
revisiones. En el caso de SOAP, se trata de todo un protocolo complejo y con
objetivos mucho ms ambiciosos que los aqu planteados y adems no basado en
REST. UDDI, por su parte, plantea el registro universal de servicios para su
localizacin por parte de cualquier usuario potencial, lo que tambin excede los
propsitos del entorno multidisciplinar.
Por ltimo, respecto al entorno de ejecucin de componentes para los agentes, se
opta por el uso de LAMP (Linux, Apache,) obedeciendo al criterio de economa en
la implementacin del entorno.

Pg. 3-73

Você também pode gostar