Escolar Documentos
Profissional Documentos
Cultura Documentos
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.2
3.1.3
Estructura General
Mtodos Formales
3.5.2
3.5.3
3.5.4
3.7.2
3.7.3
3.7.4
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:
3.8 Conclusiones
3.8.1
3.8.2
3.8.3
3.8.4
3.8.5
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.
Pg. 3-1
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
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.
Pg. 3-3
horizontal
almacenamiento
adecuada,
propios,
ir
con
funcionamiento
acomodando
las
formato
herramientas
de
especficas
Pg. 3-4
explcita
del
Proceso
su
gestin
desde
una
entidad
Pg. 3-5
9 Concepto
de
METAframework
infraestructura
necesaria
para
la
Pg. 3-6
Pero
cada
proyecto
requerir para
su
desarrollo
un
subconjunto
de
...
Especialistas
...
Herramientas
...
Interfaces
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
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:
etc.
Estas
decisiones,
que
determinarn
las
sinergias
Pg. 3-8
Pg. 3-9
Pg. 3-10
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.
Pg. 3-11
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:
El MCH usar conexiones sobre TCP/IP para comunicarse con las herramientas.
Pg. 3-12
Pg. 3-13
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.
Pg. 3-14
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:
Pg. 3-15
de
empotrados.
sus
proyectos
es
el
GSRC
Semantics
Project
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
Pg. 3-16
Estructura lgica:
Sintaxis
abstracta.
Define
cmo
un
diseo
puede
dividirse
en
concreta,
notacin.
Define
cmo
un
diseo
puede
ser
sintcticas.
Un
conjunto
de
operaciones
(tanto
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
Pg. 3-17
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
Pg. 3-18
(creacin
de
puertos,
relaciones,
enlaces,
entidades,
etc).
Beneficios de la ortogonalizacin:
Diferentes niveles de interoperatividad
Terminologa independiente de sintaxis concreta
Se enfatizan frameworks en lugar de lenguajes
Pg. 3-19
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 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.
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:
Pg. 3-20
de
las
herramientas
de
dominio.
Este
mecanismo
de
formalizar
las
relaciones
entre
metamodelos
para
realizar
adopcin
de
una
estructura
de
modelado
acorde
con
MOF
permitir
Pg. 3-21
Pg. 3-22
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
niveles de abstraccin
Pg. 3-24
de
un
sistema.
Algunos
ejemplos
son:
(Spievy
1992),
CSP
Pg. 3-25
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.
MTODOS FORMALES
Requisitos
de usuario
Especificacin
Diseo
formal
Cdigo
mquina
abstracta
Cdigo
mquina
fsica
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
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:
Pg. 3-28
3.5.2 SEPARACIN
PROPSITOS
MULTIDIMENSIONAL
DE
ser
traumtica
para
el
sistema.
Sin
embargo,
aadir
una
nueva
del
sistema
en
diferentes
tipos
de
mdulos:
clases,
Tratamiento
del
sistema
desde
el
punto
de
vista
de
un
nmero
Pg. 3-29
para
hiperespacios
Java
travs
de
Hyper/J
Pg. 3-30
(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
optimizacin
del
rendimiento,
replicacin,
coordinacin,
Pg. 3-31
Java.
Proporciona
una
modularizacin
limpia
para
problemas
se
entremezclan
confunden
trminos
como:
Subject-Oriented
Pg. 3-32
informacin
de
configuracin
necesaria.
El
Generador
de
variabilidades y las
Generacin
de
una
funcionalidad
especfica
dentro
de
una
aplicacin
Pg. 3-33
Pg. 3-34
tipo
de
programa
(familias
de
programas)
para
una
nica
formales
porque
en
ese
caso
tambin
se
intenta
generar
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
Pg. 3-36
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,
Pg. 3-37
objetivos
de
negocio,),
de
gestin
(planificacin,
personal,
Pg. 3-38
Pg. 3-39
Pg. 3-40
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
Pg. 3-42
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.
Pg. 3-43
(mecanismo
de
acceso
recursos
remotos)
como
herramientas
Pg. 3-45
Pg. 3-46
En
cada
uno
de
estos
escenarios el autor define los roles que toman parte, los artefactos y la secuencia
de operacin.
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
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
Pg. 3-48
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
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
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,
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
Pg. 3-50
agente
requeridor
dinmicamente
selecciona
uno
de
varias
entidades
Actores:
Entidad requeridora
Pg. 3-51
Entidad proveedora
Agente buscador
Secuencia de operacin:
La entidad proveedora publica WSD
La entidad requeridora encuentra WSD
Interaccin entre agentes
Pg. 3-52
Vocabularios
comunes
de
metadatos
(ontologas)
mapas
entre
Agentes automticos que ejecuten tareas para los usuarios a travs del uso
de metadatos.
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.
Pg. 3-53
nuevas
tecnologas
han
emergido
para
llevar
cabo
la
Pg. 3-54
.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
desarrolladas
por
diferentes
empresas,
por
ejemplo:
IBM
de
memoria.
Tecnologa
basada
en
servidor
para
distribuir
Pg. 3-55
herramientas
de
desarrollo,
se
opta
por
entornos
ms
modestos
no
como
servidor
web,
MySQL
como
RDBMS
(Relational
Data
Base
.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
ASP
JSP
Pg. 3-56
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
Pg. 3-58
Motor Colaboracin
Modelos (MCM)
Componente
Integracin de
Gramticas XML de
Dominios
Gramticas
Modelos de Dominio
Modelos
DIRECTOR
Tcnicas de desarrollo de
SW
Repositorio
Conocimiento
Interfaz de Herramientas
Aplicaciones
Sintaxis Abstracta
Estructura
del
lenguaje
Significado
del lenguaje
Sistema
tipos
Sistema
tipos
Sistema
tipos
Sistema
tipos
Gramtica
IC
Gramtica
SD
Gramtica
STR
Gramtica
IS
Pg. 3-59
Transformaciones
sintcticas.
Mecanismos
que
permitan
realizar
funcionamiento
del
MCM,
sera
necesario
lograr
los
primeros
Pg. 3-60
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
XSLT
Meta-Metamodelo
LER
IC
SD
STR
IS
stma
stma
stma
stma
LER.xsd
Transf
Pg. 3-62
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
3.8.3 INTEGRACIN
DE
TCNICAS
DESARROLLO DE SW (DIRECTOR)
PARA
Pg. 3-64
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
XML
que
permita
expresar
reglas
comprobar
despus
su
Pg. 3-65
Especialistas
Herramientas
Interfaz
Config
xml
xml
xml
IC
SD
STR
Interfaces
DIRECTOR
subPROCESO
ESPECIFICACIN
FORMAL
LER
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
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
Repositorio
Componentes
Figura 3-22. Labores del DIRECTOR relacionadas con el subproceso de Generacin
de Cdigo.
Pg. 3-67
3.8.4 INTEGRACIN
(REPOSITORIO)
DE
CONOCIMIENTO
de
generacin
automtica
de
documentos
al
entorno
repositorio
se
pueden
generar
automticamente
Pg. 3-68
los
informes
que
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
Pg. 3-70
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
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:
los
agentes
son
Pg. 3-72
capaces
de
comunicarse
travs
de
HTTP
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.
Pg. 3-73