3-ARQUITECTURA Y TECNICAS DE INTEGRACION

3 ARQUITECTURA DEL
ENTORNO Y TÉCNICAS DE
INTEGRACIÓN
En este capítulo se inicia la toma de decisiones respecto al entorno multidisciplinar.
En primer lugar, se seleccionan los estándares de modelado y expresión formal
y la forma de usarlos en el entorno. Así mismo, se define una primera aproximación
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
capítulo anterior.
Posteriormente, se definirá lo que se entiende por integración y se describirán
diferentes niveles de integración. Lo que dará paso a un estudio de diferentes
técnicas de integración para resolver la colaboración de gramáticas, modelos,
técnicas de desarrollo de SW, conocimiento y aplicaciones. Se valorarán
técnicas muy dispares entre sí pero con el común denominador de servir para
integrar información, aunque con diferentes grados de abstracción.
Las conclusiones del capítulo servirán para seleccionar las técnicas más
adecuadas para cada uno de los niveles de integración, y completar así la
arquitectura del entorno esbozada al inicio con más detalles relativos a las técnicas
a utilizar.
3.1 Arquitectura General del Entorno
3.1.1
Modelado y Expresión Formal en el Entorno
3.1.2
Requisitos y Componentes Básicos del Entorno
3.1.3
Estructura General
3.2 Niveles de Integración
3.3 Integración de Gramáticas
3.3.1
GSRC Semantics Project
3.4 Integración de Modelos
3.5 Integración de Técnicas para Desarrollo de SW
3.5.1
Métodos Formales
3.5.2
Separación Multidimensional de Propósitos
3.5.3
Desarrollo de SW Dirigido a Dominio
3.5.4
Generación de Programas con XSLT
3.6 Integración de Conocimiento
3.7 Integración de Aplicaciones
3.7.1
Conceptos básicos 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:
Interacción web clásica (sin servicios web)
Partes conocidas, WSD estático
Partes conocidas obtienen WSD dinámicamente
Múltiples proveedores, descubrimiento manual
Múltiples proveedores, acceso a WSD del proveedor
Múltiples proveedores, selección automática
Diagrama en triángulo
Tecnologías para Servicios Web
3.8 Conclusiones
3.8.1
Integración de Gramáticas (Gramáticas XML de Dominios)
3.8.2
Integración de Modelos (Modelos de Dominio)
3.8.3
Integración de Técnicas para Desarrollo de SW (DIRECTOR)
3.8.4
Integración de Conocimiento (Repositorio)
3.8.5
Integración de Aplicaciones (Interfaz de Herramientas)
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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 capítulo
anterior, conclusiones en forma de selección de estándares para el
modelado y la expresión formal, requisitos identificados y arquitectura de
bloques en la que se fundamentará el entorno.
3.1.1 MODELADO Y EXPRESIÓN FORMAL EN EL
ENTORNO
Aplicando al entorno multidisciplinar las ideas sobre niveles de abstracción
expuestas en el capítulo anterior, se identifica la necesidad de construir cuatro
jerarquías de abstracción (en principio independientes) para representar la visión
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 información 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 abstracción o descripción parcial y particular de las
características (comportamiento, estructura, funcionalidad,...) del sistema bajo
desarrollo. Para añadir formalidad a estas descripciones y tener la posibilidad de
validar la corrección de diferentes modelos de acuerdo a los parámetros 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 validación 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
información diferente en el nivel de dato.
Se considera interesante la arquitectura de ‘4+1 vistas’ en tanto que esta
arquitectura coincide con la visión adelantada en el capítulo inicial de esta memoria.
En ambos casos se separan los modelos en función del profesional que los vaya a
usar y también se considera necesario el empleo de una notación o lenguaje
especializado para la descripción del sistema desde cada uno de los dominios. Hay
que destacar el interés de construir estos lenguajes especializados utilizando en
todos los casos un núcleo común formado por componentes y conectores. La
existencia de ese núcleo expresivo común facilitará dar forma a las relaciones entre
Pág. 3-1
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
modelos. Únicamente, y por razones ya comentadas, se extenderá en la
arquitectura de ‘4+1 vistas’ la capacidad de expresión jerárquica de los sistemas.
UML 1.4 desarrolla estos conceptos y define una rica colección de vistas en forma
de diagramas orientados a objetos, permitiendo múltiples enfoques para un mismo
problema. La potencia de este lenguaje radica en su flexibilidad expresiva y
capacidad de adaptación. 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 corrección de las instancias respecto al metamodelo, UML 1.4 parece
incompleto como soporte de los metamodelos de dominio y sus instancias. Además,
sigue careciendo de la jerarquía formal deseable. Como ambas carencias prometen
ser paliadas en la próxima versión del lenguaje (UML 2.0), es una posibilidad de
futuro la expresión de los metamodelos de dominio y sus instancias en este
estándar.
En la filosofía MDA (Model Driven Architecture) de OMG la definición y relación
entre PIM y PSM, la formalidad introducida por MOF y la serialización de modelos e
instancias con XMI tienen a UML como punto común 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 demás estándares. De hecho, se
propone desarrollar el entorno en sintonía con esta filosofía 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 expresión en XML de esos modelos
e instancias.
XML sí parece colmar conjuntamente las necesidades de expresión flexible y
adaptable a diferentes campos junto con la validación formal de las instancias. Su
papel de metalenguaje, permitiendo la creación de lenguajes formales a través de
schemas, y el complemento de XSL (transformaciones entre lenguajes) le hacen
convertirse en un candidato ideal.
Incluso si UML 2.0 (y estándares asociados) cumplen todas las expectativas, XML
seguirá siendo necesario para el intercambio de información entre diferentes
plataformas, entre diferentes herramientas MOF o entre herramientas MOF y otras
no MOF (necesidad de validación previa).
En resumen, en lo concerniente al modelado y expresión formal de la información
en el entorno multidisciplinar se toman las siguientes decisiones:
Definir los metamodelos de los cuatro dominios implicados. Los modelos o
instancias de los mismos serán las descripciones del sistema desde los
enfoques particulares.
Usar schemas XML para definir los metamodelos de dominio. Éstos fijarán
todos los requisitos a cumplir por las instancias (descripciones de sistemas
particulares hechas de acuerdo al metamodelo de dominio). Estos schemas
Pág. 3-2
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
XML servirán de gramáticas formales del lenguaje a emplear desde cada
dominio.
Construir los lenguajes extendiendo y especializando un núcleo expresivo
común
que
soporte
la
descripción
jerárquica
del
sistema
en
base
a
componentes y conectores.
Seguir en la medida de lo posible los preceptos del MDA. Por una parte,
distinguir el nivel de abstracción de la aplicación independiente de detalles
(PIM), otro con detalles propios de la plataforma de desarrollo (PSM) y, por
último, la implementación final. Por otra parte, establecer mecanismos para
automatizar y formalizar el paso entre dichos niveles de abstracción. De este
modo serán evidentes las ventajas obtenidas en cuanto a reutilización de
modelos y formalización del proceso.
Preparar la adopción futura de UML 2.0 como lenguaje soporte de los
metamodelos de dominio. Esto permitiría :
○ generación automática desde UML de gramáticas XML (schemas) e
instancias (documentos) gracias a XMI o al empleo de perfiles que modulen
la creación de XML a voluntad del diseñador
○ generación automática desde UML del código que implemente los interfaces
entre herramientas y modelos de dominio para diferentes plataformas (Java,
C++, CORBA,…)
○ adopción 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 podría usarse, por ejemplo, para
especificar la arquitectura SW del sistema, pero el resultado de su uso habría que
expresarlo en XML y validarlo contra su metamodelo correspondiente (schema
XML).
Pág. 3-3
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.1.2 REQUISITOS Y COMPONENTES BÁSICOS DEL
ENTORNO
El análisis realizado en el Estado del Arte sobre las herramientas específicas de
dominio habituales en cada uno de los campos de estudio, ha permitido identificar
varios requisitos que deben guiar la construcción del entorno multidisciplinar de
herramientas:
™ La trazabilidad ha demostrado ser una propiedad fundamental cuando se trata
de coordinar diferentes fases de desarrollo y aún más cuando se emplean
diferentes herramientas. Esta propiedad deberá ser intrínseca al propio entorno
y, por tanto, no basada en ninguna herramienta particular.
™ El Núcleo del Entorno debe ser independiente de cualquiera de las
herramientas integradas. Frente a la opción de tomar una herramienta
suficientemente genérica como centro del entorno e ir ampliándola con módulos
paralelos que complementen su funcionalidad, se opta por diseñar una
arquitectura
horizontal
almacenamiento
adecuada,
propios,
e
ir
con
funcionamiento
acomodando
las
y
formato
herramientas
de
específicas
verticales a esta arquitectura y forma de trabajo.
™ Para cada uno de los dominios específicos se han detectado conceptos clave
que se constituyen en criterios de clasificación de grupos de herramientas y, por
tanto, en parámetros de configuración para el Núcleo del Entorno:
¾
Sistemas Distribuidos. El Protocolo de Comunicación 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 análisis, pero también en el
diseño. Son limitados los estilos de arquitectura empleados en Sistemas de
Tiempo Real (secuencial, dirigida a eventos, pipeline, cliente-servidor) pero
no se va a diseñar un entorno que soporte uno solo de ellos, sino que se
permitirá seleccionar el más adecuado en cada proyecto. El estilo elegido
para el sistema en desarrollo determinará qué subconjunto de herramientas
pueden usarse y qué sinergias existirán entre ellas. La Metodología es un
concepto aún más amplio que engloba el estilo de arquitectura y restringirá
aún más el número y forma de utilizar las herramientas.
¾
Ingeniería 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
aplicación y al Nivel de Madurez CMM de la organización. La visibilidad o
expresión
Pág. 3-4
explícita
del
Proceso
y
su
gestión
desde
una
entidad
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
independiente de cualquier herramienta ofrecerá esta flexibilidad de cara al
usuario.
™ El Núcleo del Entorno debe ser flexible, para adaptarse con facilidad a
necesidades futuras, y abierto para integrar en cada momento a la herramienta
específica más adecuada. Esto se conseguirá a través del uso de estándares
para la implementación de los componentes anteriores
El Núcleo del Entorno se asemeja a los entornos I-CASE descritos en el capítulo
anterior en que también debe ofrecer una arquitectura común en la que integrar
herramientas de diferente naturaleza. Por ello, se identifican los siguientes
Componentes Básicos, análogos a los de dichos entornos:
™ Repositorio de información común a todas las herramientas.
™ Componente de integración de modelos. Contiene la definición explícita de
los cuatro metamodelos de dominio, sus relaciones y la relación de los
metamodelos con las herramientas particulares en base a ciertos metadatos.
™ Componente DIRECTOR, desde donde se controlan todos los mecanismos de
activación, 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 común para la configuración del entorno.
El estudio hecho en el Estado del Arte sobre algunos intentos de integración 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 integración de información.
9 Uso de Java como lenguaje de programación preferido para el SW de
integración
9 Uso de documentos (normalmente en XML) anexos a los módulos para
describir la información necesaria para su integración con otros.
9 Uso generalizado de la abstracción como concepto fundamental en el que
basar la integración.
9 Uso de gramáticas abstractas con los elementos sintácticos a emplear en
todo el entorno, aunque luego se le añada la semántica particular de cada
dominio.
9 Uso de entidad ‘director’ o similar para coordinar las diferencias semánticas
entre dominios valiéndose de la estructura común de los lenguajes.
Pág. 3-5
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
9 Concepto
de
METAframework
o
infraestructura
necesaria
para
la
composición de frameworks. Hasta ahora el diseño se ha centrado en la
consideración de cuatro dominios y de las relaciones entre ellos, pero ¿por
qué sólo cuatro?, ¿cómo se integraría uno más? Si se es capaz de expresar
el metamodelo del que emergen los cuatro dominios, la definición de un
nuevo modelo bajo esos mismos principios aseguraría su colaboración con
los demás en el entorno. Esta idea del metamodelado se desarrollará para
formalizar los mecanismos de ampliación 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 cohesión y coherencia del entorno se fundamentará
en el uso de diferentes técnicas de integración a varios niveles.
Pág. 3-6
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.1.3 ESTRUCTURA GENERAL
Las pautas enumeradas conducen a un diseño 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 Colaboración de
Herramientas (MCH), que hace las funciones de servidor. El tipo de servicio que
ofrece el MCH es de almacenamiento, validación y coordinación de la información
del SCDTR bajo desarrollo. El MCH ofrece estos servicios apoyándose en el Motor
de Colaboración de Modelos (MCM).
La capa más externa del MCH gestiona un flujo de información vertical y en ambos
sentidos entre cada herramienta y el propio MCH, mientras que el MCM gestiona
otro flujo de información 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 comunicación con el
MCH, la función que desempeñan, 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 interacción a lo largo del proceso particular de
dicho proyecto.
...
Especialistas
...
Herramientas
...
Interfaces
MOTOR DE COLABORACIÓN DE HERRAMIENTAS (MCH)
MOTOR DE COLABORACIÓN DE MODELOS
(MCM)
Figura 3-1. Estructura del entorno multidisciplinar
La capa más externa del MCH debe resolver los interfaces a las herramientas
particulares, así como al coordinador (que configura el funcionamiento del entorno
para la gestión de cada proyecto).
Pág. 3-7
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Los componentes del Motor de Colaboración de Herramientas incluyen los que ya
han sido mencionados, más la novedad de la entidad DIRECTOR, núcleo del MCM.
En este componente se centralizan todas las actividades de integración:
Control del proceso de desarrollo. En función de la información aportada por el
coordinador se configurará el proceso y el DIRECTOR obligará a seguir las fases
marcadas.
Gestión de activaciones para invocar las acciones necesarias en cada momento.
Control de la trazabilidad, íntimamente ligado al proceso SW seguido.
Comprobación global de errores, coherencias e integridad de la información.
Especialistas
Coordinador
Interfaz
Config
Interfaz herramientas
MOTOR DE
COLABORACIÓN
MOTOR DE
DE
COLABORACIÓN HERRAMIENTAS
DE MODELOS
(MCH)
(MCM)
DIRECTOR
Modelos de Integración
Repositorios
Metadatos
Figura 3-2. Componentes del MCH.
En la Figura 3-2 se puede apreciar cómo quedan los componentes del entorno con
la inclusión del DIRECTOR y la expresión explícita de los modelos de interacción
para su manipulación. Además, se identifican dos roles de usuarios del entorno:
•
Coordinador de proyecto. Es quien impone al DIRECTOR, a través de un
interfaz de configuración, 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 metodología de tiempo real determinada, protocolos de
comunicación para la distribución del control, un determinado proceso de
SW,
etc.
Estas
decisiones,
que
determinarán
las
sinergias
e
incompatibilidades que entran en juego, sirven para configurar el módulo
Pág. 3-8
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
DIRECTOR. Toda esta información 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 información que le
facilita el entorno y de las pautas indicadas por el coordinador.
El diagrama de componentes básicos mostrado en la Figura 3-2 se irá completando
en más detalle a lo largo del presente capítulo y se desarrollará el diseño final de
cada bloque en el capítulo siguiente.
Pág. 3-9
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Pág. 3-10
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
33..22 N
NT
TE
EG
GR
RA
NIIVVEELLEESS D
AC
CIIÓ
DE
E IIN
ÓN
N
Sobre lo que se entiende por integración y las técnicas disponibles para
lograrla a diferentes niveles.
Una vez establecido que las diferentes herramientas del entorno se integrarán
gracias a un Motor de Colaboración de Herramientas (MCH) externo que guíe el
proceso, cabe preguntarse qué técnicas son las más apropiadas para que el MCH
logre ese propósito de integración.
Dado un conjunto de aplicaciones autónomas, cada una ejecutándose en su propio
contexto, la interacción entre ellas se consigue si:
1. Existe una conexión física y un protocolo de comunicación para que los datos
fluyan entre los contextos de ejecución de las aplicaciones. Actualmente, la
omnipresencia de internet con sus protocolos TCP/IP hace que sea la opción
más estándar para el intercambio de información entre dos aplicaciones
cualesquiera independientemente de su ubicación.
2. Existe un acuerdo en el formato de los datos para su intercambio (texto
ASCII, XML, representación en memoria, chorro de bits…). Por las razones
aducidas en el capítulo anterior, XML se perfila como el formato más
estándar, universal y de amplia aceptación.
3. Existe un acuerdo en el léxico y sintaxis empleados para la expresión de la
información.
4. Existe un acuerdo respecto a los tipos de datos (rangos válidos, 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 relación o manera de mantener la coherencia entre
cualesquiera dos datos de dos herramientas diferentes pero con una relación
semántica conocida.
7. Existe un acuerdo en los interfaces que cada aplicación ofrece para la
entrada y salida de datos
Los puntos 3, 4 y 5 hacen referencia a un acuerdo en cuanto a la gramática
empleada, que como se verá, tiene que reflejar las peculiaridades de cada campo
de aplicación pero manteniendo un núcleo común a todas las demás. Para lograr
una solución abierta y flexible, los puntos 6 y 7 conviene resolverlos de forma
Pág. 3-11
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
acorde a tecnologías estándares y ampliamente aceptadas, que se discutirán 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 tácitos o explícitos. En ocasiones, se siguen acuerdos ‘no escritos’
para hacer que se entiendan dos aplicaciones. En este trabajo se intenta
hacer explícito cualquier acuerdo porque esto es necesario para poder
modificar los términos del acuerdo o para generalizarlo y lograr la
interacción con otras aplicaciones cualesquiera.
•
Acuerdos punto a punto o genéricos. Para comunicar dos aplicaciones basta
con ponerse de acuerdo entre ellas, pero para lograr comunicar un número
indeterminado de aplicaciones no definidas de antemano, es necesario
imponer unas normas genéricas que permitan interactuar a toda aplicación
que las cumpla.
La propia interacción entre las aplicaciones puede ser manual o guiada. Es decir,
dirigida a su libre albedrío por el usuario (que indica en qué momento invocar una
aplicación 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 metodologías
para el desarrollo de SW requieren de una regulación de las fases de su ciclo de
vida que aconseja una interacción 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
integración:
•
Aplicaciones integrables. Por cumplir todos los requisitos para interactuar
se puede escribir un SW que las integre.
•
Aplicaciones integradas entre tiempos de ejecución. Cada aplicación
funciona según sus propios tiempos pero los resultados que se obtienen al
terminar su uso se ‘sincronizan’ con la información que ya existía. Por cada
uso de una aplicación se comprobará la coherencia de los resultados con
todo lo anterior.
•
Aplicaciones integradas en tiempo de ejecución. En el propio tiempo de
ejecución, una aplicación es capaz de comunicase e interactuar con otras.
En definitiva, se pueden completar un poco más las características del MCH
añadiendo las siguientes:
El MCH usará conexiones sobre TCP/IP para comunicarse con las herramientas.
Pág. 3-12
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
La información a intercambiar entre herramientas y MCH se expresará en
formato XML. Siendo así, lo más lógico es que los repositorios también
almacenen la información en este formato.
Se definirán gramáticas XML ajustadas a las necesidades de cada uno de los
dominios: Ingeniería de Control (IC), Sistemas Distribuidos (SD), Sistemas de
Tiempo Real (STR) e Ingeniería del SW (IS). De este modo, la información
intercambiada entre una determinada herramienta y el MCH se expresará
siempre en la gramática propia de su dominio.
El DIRECTOR llevará a cabo una integración entre tiempos de ejecución, es
decir, se encargará de sincronizar la información global cada vez que se
reporten resultados desde alguna de las herramientas.
Los acuerdos necesarios para la integración de herramientas se hacen
genéricos ya que hacen referencia a las interacciones entre los diferentes
dominios específicos y no a la existente entre herramientas concretas. Estos
acuerdos se engloban en un conjunto de Modelos de Dominios que estarán
íntimamente ligados a las Gramáticas de Dominio.
Los acuerdos se hacen explícitos porque se expresan en forma de modelos y
gramáticas 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, basándose en los modelos y gramáticas de dominio.
Pág. 3-13
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Gramática de
dominio
común para
diferentes
herramientas
IC
IC
SD
STR
IS
Información en la gramática
XML de cada dominio
Información XML sobre
conexiones TCP/IP
Interfaz
Config
Interfaz Herramientas
Sincronización en instantes de
entrada / salida de información
desde una herramienta
DIRECTOR
Modelos
Dominios
Gramáticas
XML Dominios
Repositorios
XML
Metadatos
Figura 3-3. Estructura del MCH.
En los siguientes apartados se presentarán algunas técnicas adecuadas para la
implementación de cada una de las partes de este esquema. Concretamente, y por
orden de aparición de los apartados, se describirán soluciones para los bloques de
Gramáticas (3.3 Integración de Gramáticas), Modelos de Dominio (3.4 Integración
de Modelos), DIRECTOR (3.5 Integración de Técnicas para Desarrollo de SW),
Repositorio (3.6 Integración de Conocimiento) e Interfaz de Herramientas (3.7
Integración de Aplicaciones).
Pág. 3-14
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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 gramática y el
grado de compatibilidad entre gramáticas 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
solución podría ser la creación de un lenguaje común, lo suficientemente rico y
extenso como para cumplir dos requisitos:
•
El lenguaje debe poder describir la información que manejen todas las
herramientas a integrar.
•
El lenguaje debe poder representar todas las relaciones cruzadas entre
informaciones de diferentes herramientas.
Esta solución permitiría importar y exportar toda información entre herramientas,
siempre que estuviera expresada en ese lenguaje. El problema surgiría cada vez
que se pretenda integrar una nueva herramienta no considerada en un principio. Si
el lenguaje común no fuera capaz de expresar algún tipo de información manejada
por la nueva herramienta, sería necesaria su modificación y ampliación.
Para ganar flexibilidad y generalidad en la solución, conviene usar un lenguaje más
abstracto en el que se asuman sólo unos pocos elementos comunes a la
información de todas las herramientas que pretendan ser integradas.
Se va a profundizar a continuación en un proyecto que trabaja en esta línea de
investigación, el GSRC Semantics Project.
Pág. 3-15
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.3.1 GSRC SEMANTICS PROJECT
Gigascale Silicon Research Center (http://www.gigascale.org/) es una entidad que
aúna los esfuerzos de multitud de grupos de investigación para el diseño 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 diseño de sistemas.
Identifican el mismo problema que se ha descrito en el primer capítulo 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 demás. Tal y
como muestra la Figura 3-4, se pueden obtener múltiples 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 demás. Por otra
parte, también es deseable poder manejar diferentes niveles de abstracción para
cada una de las facetas (Figura 3-5).
Figura 3-4. Proyección 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 sería lo mismo
que
conseguir
interoperatividad
entre
las
herramientas.
Para
lograr
esta
interoperatividad, no buscan la creación de un lenguaje estándar de diseño común
para todas, si no que intentan identificar el uso de ciertos elementos comunes y
formalizarlos para establecer la base común a todas las herramientas. De este
modo, definen modelos sintácticos y semánticos para el diseño de sistemas
basándose en el uso de componentes, su interacción y su composición (Lee 2000).
Pág. 3-16
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Figura 3-5. Niveles de abstracción de cada faceta.
En la especificación de un lenguaje se aúnan las descripciones de varias
propiedades ortogonales. El tratamiento por separado de las mismas permite varios
niveles de compatibilidad. La definición de un lenguaje puede dividirse en cinco
partes (servicios) agrupadas en dos bloques:
Estructura lógica:
○ Sintaxis
abstracta.
Define
cómo
un
diseño
puede
dividirse
en
componentes interconectados. El conjunto de componentes y relaciones que
pueden aparecer en un diseño conforman una sintaxis abstracta.
○ Sintaxis
concreta,
notación.
Define
cómo
un
diseño
puede
ser
representado y manipulado en un formato persistente y usable por el
ordenador (XML, APIs, fichero ASCII, gráfico,…). Pueden existir múltiples
sintaxis concretas derivadas de una única sintaxis abstracta.
○ Transformaciones
sintácticas.
Un
conjunto
de
operaciones
(tanto
estáticas como dinámicas) permiten transformar un diseño 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 diseños.
○ Semánticas (de componentes y de interacción). Da significado a las
características de cada componente y a sus conexiones con otros.
Un determinado diseño 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 sólo alguna de las partes del lenguaje.
Pág. 3-17
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Por ejemplo, un visualizador gráfico que muestre las relaciones entre componentes
no necesita conocer la semántica ni los tipos (le basta con conocer la sintaxis
abstracta), mientras que un motor de inferencia de tipos necesita conocer el
sistema de tipos además 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
sintácticas
compatibles.
Es
posible
generar
automáticamente datos de entrada para una herramienta a partir de los
resultados de otra.
4. Sistema de tipos compatible. Intercambio automático de modelos de datos
completos entre herramientas.
5. Semánticas compatibles. Las herramientas pueden intercambiar datos
dinámicamente, en tiempo de ejecución.
Cuando se busca la interoperatividad entre un conjunto lo suficientemente amplio y
diverso de herramientas de diseño, enseguida es evidente que no basta con un
único formato estándar para representar adecuadamente una sintaxis y semántica
común para todas. Existe una variedad de modelos semánticos para sistemas
basados en componentes y cada uno tiene sus ventajas y su campo de aplicación.
Por ello, se busca un acuerdo en lo más básico, la sintaxis abstracta. Una sintaxis
abstracta común para herramientas de diseño de sistemas debe ser capaz de
describir listas de conectividad, diagramas de transición de estados, diagramas de
bloques, modelos de objetos y estructuras gráficas, además de permitir el uso
extensivo de la jerarquía para lograr escalabilidad. Éstas son las características que
reúne la sintaxis abstracta GSRC.
Resumen de las características del proyecto GSRC:
Definición por separado de cada una de los cinco servicios constitutivos de un
lenguaje:
○ Sintaxis abstracta. Definición de componentes y posibles relaciones entre
ellos, capacidades de jerarquía, conectividad e instanciación de clases.
○ Sintaxis concreta. MoML es una sintaxis concreta XML para la sintaxis
abstracta de GSRC. MoML no añade significado al modelo, en su lugar,
permite añadir un director al modelo. El director definirá la semántica de las
conexiones pero para MoML no es más que la referencia a una instancia que
cargará el cargador de clases.
Pág. 3-18
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
○ Transformaciones sintácticas. Definición de las posibles operaciones en los
modelos
(creación
de
puertos,
relaciones,
enlaces,
entidades,
etc).
Aplicaciones como los editores visuales de modelos o las herramientas de
instanciación hacen uso de las mismas.
○ Sistemas de tipos. Los propios de cada dominio para permitir el uso de
interfaces polimórficos que evitan la necesidad de escribir adaptadores de
protocolo entre interfaces rígidos predefinidos.
○ Semánticas de componentes y de interacción. Definición de todos los
significados posibles de los componentes: estados, procesos, threads,
ecuaciones diferenciales, requisitos, objetos, etc. Sobre esta ontología de
componentes definida para cada dominio se especifican las semánticas de
interacción entre componentes.
Beneficios de la ortogonalización:
○ Diferentes niveles de interoperatividad
○ Terminología independiente de sintaxis concreta
○ Se enfatizan frameworks en lugar de lenguajes
Pág. 3-19
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
33..44 IIN
NT
MO
OD
TE
DE
EG
EL
GR
LO
RA
OSS
AC
CIIÓ
ÓN
ND
DE
EM
Sobre la adopción del paradigma de modelado ‘4+1’ y los estándares 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 detrás de
cada una de las vistas, las vistas sirven diferentes propósitos y existe un orden
lógico de uso:
Vista Ingeniería de Control. El ingeniero de control especifica el sistema en
base a la funcionalidad que pretende obtener y a la interacción de los
controladores con el proceso.
Vista Sistema Distribuido. El especialista en redes de comunicación parte de la
información anterior para distribuir los controladores, sensores y actuadores en
diferentes nodos dentro de una determinada topología de red. Además,
especifica las características de los enlaces de comunicación.
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 Ingeniería del SW. El ingeniero de SW hereda una especificación
completa y válida del sistema y realiza las labores necesarias para la
integración del código y la generación de documentación.
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 descripción funcional realizada desde el punto
de vista de control no debe depender de ninguna característica propia de
plataforma y debe iniciar el ciclo de desarrollo porque el objetivo prioritario del
sistema será el de resolver algún problema de control. Las otras tres vistas van
completando esa descripción inicial y van añadiendo todos los detalles propios de la
plataforma,
lo
que
permite
generar
el
código
y
documentación
de
la
implementación 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
abstracción:
•
M3. Meta-metamodelo para la definición de un lenguaje basado en
componentes y conectores que permita describir sistemas con jerarquía.
Este nivel toma la forma de un schema XML genérico.
Pág. 3-20
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
•
M2. Metamodelo de cada dominio específico. A través de mecanismos de
herencia se extiende M3 particularizando el schema genérico a las
necesidades expresivas de un área concreta. Por tanto, se crearán cuatro
schemas específicos para dar soporte a los cuatro metamodelos
•
M1. Modelo del sistema en desarrollo. Se especifican las características del
sistema creando instancias para los cuatro schemas anteriores.
•
M0. Objetos de Dominio son los componentes o unidades mínimas de
modelado. Difieren en cada uno de los dominios.
Esta jerarquía formal de abstracción vertical debe acompañarse de mecanismos
para regular el flujo horizontal de información y la validación horizontal de
implicaciones entre vistas. Estas necesidades se cubrirán de la siguiente forma:
Flujo horizontal de información: XSLT habilitará las transformaciones a
nivel de modelo para sincronizar las descripciones. Es decir, para extraer de un
modelo las informaciones que incumben también a otro y generar la versión
básica del segundo modelo, versión que se irá completando después con las
aportaciones
de
las
herramientas
de
dominio.
Este
mecanismo
de
sincronización entre modelos de diferentes dominios se facilita porque todos los
lenguajes tienen un núcleo expresivo común (componentes y conectores).
Validación horizontal de implicaciones entre vistas: Además de la
formalización (basada en schemas) que se hace dentro de cada dominio, es
necesario
formalizar
las
relaciones
entre
metamodelos
para
realizar
validaciones. Pero la expresión de estas relaciones cruzadas necesita de algún
mecanismo diferente al de los schemas XML porque son especificaciones en
forma de reglas más que especificaciones sintácticas o gramaticales. Por tanto,
habrá que completar la formalización vertical de cada dominio con un Lenguaje
para la Especificación de Reglas (LER) que permita expresar reglas cruzadas de
validación horizontal, involucrando a varios dominios.
La
adopción
de
una
estructura
de
modelado
acorde
con
MOF
permitirá
aprovecharse de las ventajas de las nuevas versiones de UML, MOF y XMI. Se
podrán expresar formalmente los cuatro niveles en MOF-UML, derivando cada nivel
del anterior. A partir de este punto, se podría comprobar la coherencia
directamente en UML, realizar análisis, simulaciones, etc. También se podrían
generar automáticamente con XMI los schemas que dan soporte a los metamodelos
y exportar o importar las propias instancias, generar automáticamente las hojas de
estilo XSLT que implementan las transformaciones automáticas entre modelos,
generar automáticamente las reglas de validación horizontal, generar código 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, también se pueden aplicar los conceptos de PIM y PSM de MDA al propio
entorno multidisciplinar, además de a las vistas manejadas. Se trata de un entorno
genérico e independiente de las herramientas, que se puede denotar como TIM
Pág. 3-21
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
(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 abstracción 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 específica del entorno (TSM) para un
determinado proyecto.
Pág. 3-22
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
33..55 IIN
NT
TÉÉCCN
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 código final las especificaciones o
requisitos provenientes de diferentes especialistas.
Tal y como se mencionaba en el primer capítulo de esta memoria, la disciplina de
Ingeniería del SW, de alguna forma, envuelve a las demás áreas involucradas, en el
sentido de que el Proceso de creación de SW debe pasar por unas fases fijadas de
antemano y seguir unas pautas que aseguren el logro de requisitos genéricos como
calidad de SW, reutilización 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 generación de SW responda a varios criterios, respete las
diferentes especificaciones y las diferentes restricciones impuestas por los modelos
implicados.
Hay varias aproximaciones teóricas para la consecución de este objetivo y las
siguientes páginas intentan esbozar en qué forma tratan el problema. La cuestión
central sigue siendo la integración de información, pero en este caso la información
proveniente de múltiples dominios se pretende condensar en un único SW final.
Pág. 3-23
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.5.1 MÉTODOS FORMALES
La combinación de diagramas, texto, tablas y notaciones sencillas que se emplean
en muchos métodos de ingeniería del SW tienen poco rigor matemático y a veces
son ambiguas o incompletas. Las sintaxis y semánticas formales se espera que
tengan un gran impacto en la concepción de la ingeniería del SW de los próximos
años. 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 automáticas debe ser necesariamente formal. Por todo ello, es
importante el conocimiento del fundamento de los métodos formales para valorar
de qué manera conviene emplearlos para el desarrollo de SW. Este es el objetivo de
las siguientes líneas que resumen el enfoque de Doorfman y Thayer (1996).
En la década de los 70 la aparición del concepto de programación estructurada
supuso una revolución al llegarse a un acuerdo en el seguimiento de ciertos
preceptos para el diseño de programas. Los lenguajes imperativos actuales son
herederos de este tipo de programación. Sin embargo, este acuerdo no es
definitivo, se abre un debate sobre la metodología de programación, con continuos
cambios: desarrollo top-down, descomposición modular, abstracción de datos,
diseño orientado a objetos, etc.
En cualquier caso, un denominador común de estas metodologías es que mantienen
la misma noción tradicional de programación. Según ésta, la labor del ingeniero de
SW es desarrollar código para indicar a una máquina física el camino hacia la
consecución de un determinado resultado. La idiosincrasia de la máquina
(interfaces de usuario, librerías,…) agregan complejidad, con el agravante de que
esta complejidad puede ser añadida en todos los
niveles de abstracción
(especificación, diseño, codificación…) porque el ingeniero intenta obtener máxima
velocidad y prestaciones de la máquina. Esto hace mucho más difícil la fase de
validación y detección de errores.
La noción de los métodos formales es la opuesta. Se traslada al ingeniero de HW,
diseñador de lenguaje o escritor de compiladores la labor de proveer de código
concreto para una máquina, y no a la inversa.
Originalmente concebía la máquina abstracta como una representación de la
realidad física. Después, en cambio, aprendí a considerar la máquina abstracta
como la verdadera porque es la única ‘en la que podemos pensar’. Es función de la
máquina física el suministrarnos un modelo que funcione, un modelo físico
suficientemente preciso como para simular la verdadera máquina, la abstracta.
Solía ser labor del programa el instruir a los computadores, pero el propósito de los
computadores debe ser realmente la ejecución de nuestros programas. (Dijkstra
1976)
En este sentido, la labor del ingeniero de SW debería ser producir modelos o
descripciones de un sistema para una máquina abstracta, con pruebas de que los
Pág. 3-24
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
modelos de menor nivel de abstracción implementan correctamente los modelos de
alto nivel. Esto asegura una mayor calidad, y no sólo 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 diseños, deben esconderse los detalles
de implementación (SoC, Separation of Concerns). No se puede dejar que
cuestiones de microeficiencia dominen e influyan en el resultado final.
Un método formal en desarrollo de SW es un método que proporciona:
1. un lenguaje formal para describir los artefactos SW (especificaciones,
diseños, código fuente,…)
2. mecanismos que permitan realizar pruebas formales sobre las propiedades
del artefacto formalmente descrito
La propiedad comprobada suele ser que una implementación es funcionalmente
correcta, es decir, cumple su especificación. Entonces, o bien el lenguaje formal
empleado permite describir un sistema a dos niveles de abstracción (especificación
formal y posible implementación), o bien se emplean dos lenguajes relacionados
para describir especificación e implementación respectivamente.
En ingeniería de SW, los métodos formales son directamente aplicables durante las
fases de requisitos, diseño y codificación y tienen importantes consecuencias para
el test y el mantenimiento. Están entrelazados con modelos del ciclo de vida
alternativos a las aproximaciones clásicas y permiten un mayor control de la
trazabilidad.
Su aplicación más habitual se da en la fase de especificación. Algunos métodos
formales incluyen lenguajes de especificación que permiten registrar precisa y
rigurosamente las características funcionales y no funcionales que se esperan
obtener
de
un
sistema.
Algunos
ejemplos
son:
Z
(Spievy
1992),
CSP
(Communication Sequential Processes, Hinchley y Jarvis 1995), VDM (Vienna
Development Method, Jones 1991), Larch (Guttag y Horning 1993). Algunos de
estos métodos pueden incluir lenguajes gráficos como DFDs (Data Flow Diagrams)
ó redes de Petri.
La gran ventaja de la especificación del sistema a través de métodos 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 difíciles de
generar a posteriori, por ello, pruebas y programas deberían desarrollarse en
paralelo. Por ejemplo, todo lenguaje de programación es, por definición, un
lenguaje formal, ya que usan una notación formal (BNF) para definir su sintaxis.
Esto asegura la capacidad de realizar pruebas al código fuente para comprobar que
cumple con la sintaxis del lenguaje.
Pág. 3-25
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Pese a las ventajas que proporcionan, tienen limitaciones que conviene tener en
cuenta:
Problema de requisitos.
Pueden usarse para verificar (probar que una implementación satisface una
especificación 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 misión operativa) porque tal y
como afirma Boehm (1981): no se puede ir de lo informal a lo formal por
métodos formales. El problema es que no se puede probar que una
especificación formal capture el entendimiento informal e intuitivo del sistema
por parte de un usuario. La especificación es el ‘contrato’ entre el usuario y el
desarrollador, y además de ser formal, tiene que contener y describir todas las
características que el usuario espera obtener en el producto final.
Problema de implementación física.
Los métodos formales pueden verificar que una implementación satisface su
especificación cuando corre en una máquina abstracta ideal, pero no en
cualquier máquina física. Las pruebas formales explícitamente aíslan los sitios
en que puede producirse el error. Concretamente, será allí donde se provea de
una máquina física para implementar a la abstracta, ya que las pruebas se
hacen suponiendo que la ejecución se realizará en la máquina abstracta.
MÉTODOS FORMALES
Requisitos
de usuario
Especificación
Diseño
formal
Código
máquina
abstracta
Código
máquina
física
Figura 3-6. Incertidumbres a la entrada y salida de los métodos formales.
Estas limitaciones afectan precisamente al punto inicial y final del ciclo de vida (ver
Figura 3-6). Los métodos formales pueden automatizar y verificar las transiciones
entre las fases internas del ciclo de vida (especificación, diseño y generación de
código para máquina 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 gráficas con
formalismo inherente; por otro lado el empleo de estándares, HW, librerías y
compiladores certificados para asegurar su adherencia a la máquina abstracta
idealizada.
Pág. 3-26
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Ni siquiera en todas las fases internas del ciclo de vida es siempre ventajoso el uso
de métodos formales. Debe decidirse en qué fases y con qué objetivos emplearlos
para modular el grado de uso más adecuado:
•
Uso puntual. En el desarrollo de algunos componentes se usan sólo para la fase
de diseño porque los productos requieren de una interacción continua entre
especificación e implementación.
•
Uso generalizado. Se puede derivar todo el proceso a partir de unas
especificaciones formales completas. Si todo parámetro o cambio que pueda
introducirse está recogido en las especificaciones, se podría generar el código
final a partir de ellas. En este caso, se modificaría la especificación para generar
cualquier nueva versión. Esta visión sustituye a los programadores por un
conjunto inteligente de herramientas integradas dirigidas por métodos formales
(McLean 1993).
•
Uso variable. Introducción parcial de métodos formales con nivel variable de
formalidad y uso de verificación informal. Es el caso del modelo de proceso de
‘sala limpia’ (Linger 1994).
A veces es difusa la frontera entre método o lenguaje de especificación. Un método
indica qué debe decir una especificación, mientras que un lenguaje determina cómo
pueden expresarse los conceptos de una especificación. Algunos lenguajes soportan
más de un método, y la mayoría de los métodos pueden ser usados en varios
lenguajes de especificación (Lamport 1989).
Los lenguajes de especificación formal tienen un alfabeto de símbolos y reglas
gramaticales que definen fórmulas de buena formación. Estas reglas caracterizan el
dominio sintáctico del lenguaje o cómo combinar los símbolos para obtener
expresiones, en principio, sin significado. El significado o interpretación de la
fórmula es parte de la semántica. El conjunto de objetos que componen el dominio
semántico del lenguaje (reglas que dictan qué objetos satisfacen la especificación)
proveen al lenguaje de un modelo.
Una especificación será un conjunto de fórmulas expresadas en el lenguaje
formal. Los objetos en el dominio semántico del lenguaje que satisfacen una
especificación pueden ser varios. Por eso la especificación está en un nivel de
abstracción mayor que los objetos en el dominio semántico, permite abstraerse de
los detalles que distinguen diferentes implementaciones. Diferentes métodos de
especificación definidos sobre el mismo dominio semántico permiten especificar
diferentes aspectos de los objetos.
Todos estos conceptos pueden expresarse a través de las matemáticas, 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 función de sus dominios semánticos, los lenguajes de especificación pueden
clasificarse en:
Pág. 3-27
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
○ Lenguajes ADT (Abstract Data Type Specification). Especificación de
álgebras. Propiedades formales de un tipo de dato sin definir características
de implementación. Ejemplos: Z, VDM, Larch.
○ Lenguajes de especificación de procesos. Secuencias de estados, eventos,
máquinas de estados. Ejemplo: CSP de Hoare
○ Lenguajes de programación.
Los métodos de especificación se pueden clasificar en:
○ Operacionales, constructivos u orientados a modelo. La especificación es
una descripción del sistema que proporciona un modelo. El comportamiento
de este modelo define el deseado en el sistema. Usará estructuras
matemáticas 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 definición, declarativos u orientados a la propiedad. Mínimo conjunto de
condiciones que debe satisfacer un sistema para ser funcionalmente
correcto. No se determina un modelo mecánico para llegar de las entradas a
las salidas. Métodos algebraicos (las propiedades se expresan en forma de
ecuaciones) y axiomáticos (cálculo de predicados).
Como conclusión, los paradigmas de ciclos de vida que confíen en la transformación
automática desde especificación hasta código 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 más dependiente de las herramientas,
y éstas cada vez usan más los métodos formales. Entre las técnicas que hacen uso
de ellos cabe mencionar: prototipado rápido, diseño orientado a objetos,
programación estructurada e inspecciones formales.
El uso de los métodos formales se está generalizado a pequeña escala pero
típicamente en organizaciones con nivel 3 o superior en el modelo de madurez del
proceso SW del SEI. Es difícil llevarlos hasta el último extremo pero se pueden
implantar gradualmente e ir integrándose en el proceso habitual de las empresas.
Pág. 3-28
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.5.2 SEPARACIÓN
PROPÓSITOS
MULTIDIMENSIONAL
DE
La filosofía de Separation of Concerns (separación de propósitos) está en el núcleo
de la ingeniería del SW en general y del desarrollo de SW orientado a objeto en
particular. El uso adecuado de la orientación 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 representación de un dato en un sistema
orientado a objeto, si se hace utilizando patrones de diseño o subclases, no tiene
porqué
ser
traumática
para
el
sistema.
Sin
embargo,
añadir
una
nueva
funcionalidad a un sistema sí suele suponer cambios intrusivos porque el código de
la nueva funcionalidad se disemina en diferentes clases y se mezcla con código de
otras clases, aumentando la probabilidad de error y la complejidad y dificultando la
comprensión del código.
En resumen, parece necesario el uso de técnicas complementarias a las propias de
orientación a objeto. Dependiendo del propósito perseguido se requiere la
descomposición
del
sistema
en
diferentes
tipos
de
módulos:
clases,
funcionalidades, aspectos (distribución, persistencia), roles, etc.
MDSOC (Multi-Dimensional Separation Of Concerns) intenta llevar esta filosofía
hasta sus últimas consecuencias y se plantea como objetivos:
•
Tratamiento
del
sistema
desde
el
punto
de
vista
de
un
número
indeterminado de propósitos múltiples, arbitrarios y no prefijados. Los
propósitos, criterios o problemas varían en el tiempo y son sensibles al
contexto (diferentes actividades del desarrollo, fases del ciclo de vida,
desarrolladores). Por ello cualquier criterio debería ser posible para la
descomposición.
•
Encapsulado simultáneo de todos los propósitos para un sistema. El
desarrollador no elige uno o varios de ellos para su código, todos pueden
coexistir.
•
Gestión de propósitos interrelacionados o solapados. Pocos propósitos serán
ortogonales, se deberán gestionar las relaciones entre ellos porque
normalmente estarán presentes varios a la vez y puede ser que se solapen o
interfieran.
En definitiva, MDSOC enfatiza una separación flexible e incremental, una
modularización y una integración de artefactos SW basada en un número
indeterminado de criterios. Además, soporta la remodularización para encapsular
nuevos criterios en cualquier momento. Esto conlleva los siguientes beneficios:
Pág. 3-29
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
9 Reducción 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 Más sencilla comprensión del sistema y reducción de la complejidad.
9 Adaptabilidad.
9 Mantenimiento más sencillo.
9 Personalización y configuración acorde a las necesidades del usuario.
9 Reutilización de componentes.
9 Mejor trazabilidad.
9 Integración de componentes simplificada, uso de COTS
9 SW más rápido, seguro, barato y de mejor calidad.
IBM ha trabajado en MDSOC y ha creado su aproximación particular denominada
Hyperspaces (www.research.ibm.com/hyperspace/). Concretamente, proporciona
soporte
para
hiperespacios
Java
a
través
de
Hyper/J
(www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm). Esta herramienta opera
con clases Java y un fichero de control especifica cómo mapear los miembros Java
a propósitos, qué propósitos tener en cuenta y qué relaciones de composición
implementar (Ossher y Tarr 2000).
Pág. 3-30
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.5.3 DESARROLLO DE SW DIRIGIDO A DOMINIO
El Desarrollo Dirigido a Dominio (Domain-Driven Development, 3D) agrupa a un
conjunto de tecnologías que tienen en común la noción abstracta de dominio e
intentan que cada una de las partes del SW desarrollado emane desde ese nivel. Su
interés 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
tecnologías
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 código y el problema de dominio de forma más
certera. Elevan la expresión del diseño e implementación, eliminan detalles, aíslan
el SW de la deriva tecnológica, ayudan a balancear entre la personalización y la
generalidad del SW y permiten mayores niveles de automatización.
MDA ya ha sido analizado en solitario debido a su importante peso específico. A
continuación, se resumen los principios de otras tecnologías hermanas.
Aspect Oriented Software Development (http://aosd.net/). Los mecanismos
para definir y componer abstracciones son elementos esenciales de todo lenguaje
de programación El estilo de diseño soportado por los mecanismos de abstracción
de la mayoría de los lenguajes de programación 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 gestión de errores, persistencia, comunicación,
monitorización,
optimización
del
rendimiento,
replicación,
coordinación,
sincronización, comportamiento sensible al contexto, protocolos multi-objeto,
gestión 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 características comunes a muchas partes del código, y por tanto, mejorar
la calidad del SW, más allá de los simples módulos funcionales.
Mientras que estos aspectos pueden ser pensados y analizados de forma
relativamente separada a la funcionalidad básica, su programación, empleando los
habituales lenguajes orientados a componentes, tiende a dispersar estos aspectos a
lo largo de diferentes partes del código. Como resultado, el código se convierte en
una maraña de instrucciones con diferentes propósitos.
Este fenómeno de ‘maraña’ 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
Pág. 3-31
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
aspectos de un sistema en una forma separada y natural para después combinar
esas descripciones separadas en la forma de un ejecutable final.
AspectJ (http://eclipse.org/aspectj/) es una extensión orientada a aspectos para el
lenguaje
Java.
Proporciona
una
modularización
limpia
para
problemas
transversales, de forma que se modularizan aspectos que afectan a más de una
clase.
Generative Programming (www.generative-programming.org). Se trata de un
conjunto de técnicas que permiten construir los programas automáticamente a
partir de programas específicos de dominio de menor tamaño (Czarnecki y Ulrich
2000). Extiende los beneficios de la automatización al desarrollo SW.
Intentional Programming. Una técnica que permite a los programas ser escritos
y vistos en una variedad de notaciones diferentes. También permite la integración
sin problemas de programas de dominio específico y programas de propósito
general. Fue desarrollado por el equipo de Charles Simonyi (Simonyi 1995)
mientras trabajaba en Microsoft.
Transformational Programming. Técnica que produce programas a partir de
especificaciones de alto nivel o específicas de dominio. El programa es derivado de
una especificación formal empleando pasos de transformación manejados y
controlados que garantizan que el producto final cumpla con las especificaciones
iniciales (Bauer et al 1989).
Además de las resumidas hasta aquí, existen otras técnicas o metodologías que
matizando ligeramente la forma, tratan el mismo problema de fondo. En la
bibliografía
se
entremezclan
y
confunden
términos
como:
Subject-Oriented
Programming, Product-Line Engineering, Traversal-Related Behavioral Concerns,
Component-Based Software Engineering,…
Pág. 3-32
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.5.4 GENERACIÓN DE PROGRAMAS CON XSLT
Los Generadores de Programa son un resultado de la aplicación de técnicas de
Ingeniería de Dominio. Ésta se centra en generar familias de aplicaciones (no sólo
una) y engloba dos procesos (Cleaveland 2001):
1. Análisis de Dominio. Se determina la parte común y la que varía en el
conjunto de las aplicaciones presentes en un domino en estudio.
a. Parte común. Recoge todas las características que se repiten en
todas y cada una de las aplicaciones en estudio. Un conjunto amplio
de características comunes añade mayor conocimiento de un dominio
pero restringe el conjunto de aplicaciones de esa familia. El resultado
de este estudio supondrá la clave para la reutilización del SW.
b. Variabilidades. Identifican lo que es diferente entre los programas de
una misma familia. Un lenguaje de especificación debe ser capaz de
recogerlas, y en cada caso, hacer llegar al Generador de Programas
la
información
de
configuración
necesaria.
El
Generador
de
Programas automatiza la fase de generación de código a partir del
conjunto de especificaciones que fija las
variabilidades y las
parametriza para un caso concreto.
2. Implementación de Dominio. Se crean herramientas capaces de generar
aplicaciones para ese dominio a partir de la descripción de las variabilidades.
La aplicación de estas técnicas conducirá la construcción de Generadores de
Programas y el diseño de los repositorios de componentes. Es evidente la necesidad
de un diseño conjunto de ambos sistemas puesto que el Generador hará uso de
componentes antiguos o creará componentes nuevos, según el caso. Y es que la
herramienta de generación de código puede utilizarse con alguno o varios de los
siguientes propósitos:
•
Creación del esqueleto básico de un proyecto o componente de una aplicación
sobre el que el ingeniero de SW trabajará manualmente. Por ejemplo,
generación de IDL CORBA.
•
Generación
de
una
funcionalidad
específica
dentro
de
una
aplicación
(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 aplicación.
•
Creación de una aplicación completa ensamblando componentes existentes.
El generador de código “pega” los trozos de aplicación en base a unos
determinados parámetros.
Pág. 3-33
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
El uso de Generadores de Programas suele ir de la mano de la Programación
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 composición con
interfaces específicos y contexto explícito. Puede ser desarrollado a propósito
para una aplicación
o reutilizado tras capturarlo en un repositorio y
parametrizarlo. Existe una discusión sobre la distinción de componentes y
objetos, concretamente, UML 2.0 promete mejor soporte para los componentes
de lo que ofrece la versión 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 comunicación entre procesadores.
Interfaz. Es una interacción 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. Serán compatibles aquellas conexiones entre puertos import y
export que tengan el mismo tipo. Puede haber conectores síncronos (se espera
hasta que vuelva la respuesta de la llamada) y asíncronos (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 información entre ellos a través de
adaptadores para no perder la modularidad. Además, estos lenguajes tienen en
cuenta mecanismos de comunicación (para sistemas distribuidos), jerarquía
(combinación de componentes para la construcción de otros), etc. XML es muy
bueno como base de un lenguaje MIL ó ADL.
Todo lo anterior plantea la generación automática como una labor compleja que
requiere de bastante estudio y formalización. De hecho, parece razonable plantear
la fase de generación de código como un subproceso diferenciado dentro del
proceso general de creación de SW. Las compensaciones que conlleva este arduo
trabajo son las siguientes:
9 Toma de decisiones en el nivel de especificación frente al de codificación. Es
más fácil leer, escribir, editar, depurar y entender los sistemas en la fase de
Pág. 3-34
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
especificación y los lenguajes de especificación (de cuarta generación) son
más productivos que los de programación.
9 Favorece el SoC (Separation Of Concerns) porque permite que diferentes
profesionales con tareas concretas puedan colaborar en la especificación y
dejar la fase de generación de código al Generador de Programas (y no a un
especialista concreto).
9 Desacopla especificación (el qué) de implementación (el cómo) porque esta
última parte la realiza el Generador de Programas. Podrán realizarse
diferentes implementaciones, programas alternativos o variaciones de un
mismo
tipo
de
programa
(familias
de
programas)
para
una
única
especificación sin más que configurar adecuadamente el Generador.
9 Proceso automático unificado para extraer, a partir de unas especificaciones
comunes, varios productos: código, documentación del SW, documentación
de usuario, pruebas y documentos de configuración.
9 Corrección y coherencia del producto final. El programa generado no tendrá
errores cometidos en la fase de codificación y se evitarán derivas respecto a
las especificaciones.
9 Mejora continua del rendimiento del SW con la aplicación de las últimas
técnicas por parte del Generador de Programas.
Varias de estas ventajas recuerdan a las que se mencionaban para el uso de
metodologías
formales
porque
en
ese
caso
también
se
intenta
generar
automáticamente el código a partir de una especificación formal completa.
Mientras que para los programas generados a mano debe facilitarse la legibilidad y
facilidad de modificación del propio código, para los programas generados
automáticamente es importante la legibilidad y sencillez de modificación de las
especificaciones a partir de las cuales se crea automáticamente el código. Este
objetivo está asegurado si dichas especificaciones están expresadas en XML, como
es el caso que se plantea en esta tesis. Partiendo de unas especificaciones así, la
combinación de XSLT (W3C 1999) y XPath (W3C 1999b) supone la manera natural
de implementar la generación de código porque:
9 Ambos son estándares abiertos.
9 Tienen funcionalidades complementarias; mientras XPath se usa para
identificar y seleccionar partes de un documento XML, XSLT habilita la
transformación de la información.
9 XSLT permite generar como salida documentos XML, texto estructurado (por
tanto, código fuente de cualquier lenguaje de programación) o HTML, y
mediante XSL-FO también formatos PDF, SVG, RTF, etc.
Pág. 3-35
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
9 Ambos son lenguajes declarativos y evitan el uso de código Java (o cualquier
otro lenguaje imperativo de propósito general).
9 Permiten establecer un método de generación de programas independiente
del lenguaje de programación de la aplicación final, ya que partes de código
fuente de cualquier lenguaje pueden ser embebidas entre etiquetas XML que
sean interpretadas por XSLT.
Pág. 3-36
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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 técnicas empleadas para capturar, clasificar,almacenar y
recuperar cuando se necesite el conocimiento.
Gestión de Conocimiento (GC) o Knowledge Management (KM) es un término
asociado con los procesos para la recolección, organización, generación, análisis,
diseminación, comprobación y utilización del conocimiento en el ámbito de una
organización. Tiene como objetivo la adaptación sistemática de una organización a
un entorno cambiante. Para ello, busca la combinación de las capacidades de las
nuevas tecnologías para el procesado de datos e información con las capacidades
creativas humanas.
Dos conceptos importantes a tener en cuenta son:
™ Data Mining. Trata sobre la ordenación de datos para identificar patrones y
establecer relaciones. Incluye actividades como: asociación de eventos
conectados, análisis de secuencias de eventos, clasificación y búsqueda de
patrones,
clustering
o
agrupación
de
hechos
con
un
nexo
común,
predicciones en base a la información analizada.
™ Métodos Push. En aplicaciones cliente/servidor denotan el reparto de
información iniciada por el servidor sin requerimiento explícito previo del
cliente o usuario de la información.
Pese a que en un principio parece extraño relacionar los SCDTR con la Gestión del
Conocimiento, la GC es una disciplina emergente y de propósito general aplicable a
cualquier área. Concretamente, el desarrollo de SCDTR es una actividad de gestión
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 tamaño y complejidad es
prioritaria la comunicación y coordinación para que esta actividad de grupo llegue a
buen fin. La filosofía 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 capítulo inicial de esta tesis, por tanto, es seguro que algunos
de los conceptos de GC serán de gran ayuda.
En principio, es interesante profundizar un poco en la caracterización del
conocimiento según las teorías de GC:
™ Se distinguen diferentes niveles de refinamiento en tanto a los elementos
relacionados con el conocimiento:
Pág. 3-37
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
¾
Datos puntuales. Valores cuantitativos o cualitativos, discretos y objetivos
sobre un proyecto o evento concreto.
¾
Información. Datos organizados de forma que le sean útil al usuario para
tomar decisiones.
¾
Conocimiento. Requiere el entendimiento de la información y comprende
información, relaciones, clasificación y metadatos. Aglutina la información
recogida de varios proyectos y permite su aplicación a nuevos proyectos.
¾
Experiencia o conocimiento aplicado. Se materializa en forma de ‘mejores
prácticas’ y estándares.
™ Tipos de conocimiento: organizacional (respecto a la compañía: recursos
humanos,
objetivos
de
negocio,…),
de
gestión
(planificación,
personal,
seguimiento, dirección proyecto), técnico (análisis de requisitos, diseño,
programación, testeo, codificación, métodos, herramientas, lenguajes,…), de
dominio (relacionado con el dominio de aplicación y el sistema específico bajo
desarrollo)
™ Ámbito del conocimiento. Dónde es aplicable, para quién es accesible, qué
actividades soporta. Posibles ámbitos: nivel individual, grupo, organización,
múltiples organizaciones o industria.
No es difícil identificar algunas necesidades del proceso de creación de SCDTR que
están directamente relacionadas con la GC:
™ La GC intenta convertir los datos en información, y ésta en conocimiento pero el
mayor problema es que sólo una fracción del conocimiento relacionado con el
desarrollo de SW es capturado y expresado explícitamente. La mayor parte del
conocimiento es tácito.
™ 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 debería aplicar esta
experiencia a futuros proyectos, para ello hay que capturar y compartir los
resultados. El sistema debe ser además flexible para adaptarse a la diversidad
de productos.
™ La gestión documental es fundamental porque la mayoría de los artefactos que
guían 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.
™ Colaboración a distancia independientemente del tiempo y del espacio.
™ El conocimiento debe ser coleccionado, organizado, coordinado, almacenado y
recuperado de forma sistemática.
Pág. 3-38
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
La aplicación de la GC a la Ingeniería 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 gestión documental. La distribución de
información sobre el proyecto es un problema de gestión de información y las
tecnologías basadas en web se muestran válidas para ello. Internet es una
herramienta vital para diseminar los documentos dentro y fuera de la
organización. A este nivel son de utilidad herramientas para el control de
versiones (edición concurrente) y la búsqueda de documentos.
™ Segundo nivel. Tareas orientadas a mejorar la capacidad del equipo para
desarrollar un producto SW, o dicho de otro modo, cómo 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 organización 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 heurísticas, mejores
prácticas,…) o cuantitativamente (modelos de estimación basados en la medida
de atributos,…) o pueden recogerse en paquetes SW que automaticen ciertos
pasos del proceso de desarrollo basándose en el conocimiento inferido. Los
resultados también pueden ser estándares industriales.
Pág. 3-39
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Pág. 3-40
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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 Colaboración de Herramientas, independientemente de su localización y
plataforma de ejecución.
Uno de los objetivos de integración se refería a la interacción entre aplicaciones
distribuidas en entornos heterogéneos. Dado que en este trabajo de investigación
se persigue la integración ‘entre tiempos de ejecución’ de las herramientas, y no en
tiempo de ejecución, los sistemas fuertemente acoplados pierden fuerza frente a
una arquitectura débilmente 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 extensión de XML sobre la que se construye un entorno de ingeniería
de software para desarrollar aplicaciones empotradas basadas en los métodos,
lenguajes y procesadores empleados en la Agencia Aeroespacial Europea.
Sin embargo, la consecución de todos los requisitos planteados requiere de algo
más para ubicar las herramientas de acuerdo a una arquitectura común y resolver
satisfactoriamente la comunicación remota. La filosofía de los Servicios Web
parece ajustarse perfectamente a las necesidades enunciadas, ya que se plantea la
utilización de los ‘servicios’ ofrecidos por las diferentes herramientas desde un
entorno.
Pág. 3-41
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.7.1 CONCEPTOS BÁSICOS 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 núcleo central y desarrollan sus capacidades para la
comunicación entre aplicaciones por internet. Las fuertes inversiones que IBM,
Microsoft y Sun están realizando en servicios web indican que van a extenderse
cada vez más.
La idea central no difiere mucho del viejo objetivo de CORBA y Java, esto es, la
creación de aplicaciones distribuidas que integren módulos localizados en diferentes
plataformas a través de un middleware que una esos módulos distribuidos en
tiempo de ejecución. Pero se añade un nuevo matiz a este concepto, como es la
gestión dinámica de servicios que permita seleccionar en tiempo de ejecución entre
una variedad de servicios ofrecidos por compañías. Cada empresa se centra en
implementar lo que mejor sabe hacer y las aplicaciones se ejecutan a través de la
red buscando y usando dinámicamente los servicios que se requieran. Por ejemplo,
ante una petición de usuario, una aplicación puede buscar dinámicamente el hotel y
el vuelo más ventajoso consultando en todo el conjunto de la red (no solo entre un
conjunto estático de empresas concertadas). Las propias aplicaciones podrán
seleccionar los servicios que necesiten para lograr sus objetivos. Aunque el usuario
percibe una única aplicación, en realidad está usando un conjunto de aplicaciones
(constituido dinámicamente, diferente en cada ejecución), cada una corriendo en su
propia plataforma.
La definición e implementación de Servicios Web no es única, pero se pueden
apuntar algunos aspectos comunes a cualquier implementación:
•
Recursos direccionables a través de su URL (Universal Resource Locator)
que programáticamente devuelven resultados a los clientes. Un interfaz no
rígido (expresado en XML) permite que las propias aplicaciones busquen e
invoquen estos servicios.
•
Conjunto de estándares basados en XML que especifican un protocolo de
comunicación, un lenguaje de definición y un registro de publicación y
suscripción.
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.
Pág. 3-42
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
La Figura 3-7 muestra un sistema SOA genérico en el que los agentes implementan
operaciones bien definidas proveyendo servicios y pueden ser invocados a través de
la red empleando protocolos y formatos de datos estándar.
Figura 3-7. Diagrama genérico de Arquitectura Orientada al Servicio.
La descripción 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
información necesaria para procesar una petición debe estar en la propia petición.
Por tanto, los componentes SOA son los mensajes, agentes proveedores,
agentes usuarios y mecanismos de transporte compartidos. En el caso de
servicios públicos (cuyo descubrimiento debe gestionarse de forma estándar) se
añaden las descripciones públicas de estos componentes, que describen los
mensajes y los servicios.
Pág. 3-43
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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 más
restringido (Fielding 2000). Es un subconjunto de WWW en el que los agentes
exponen y usan los servicios a través de gramáticas con un interfaz uniforme y
manipulan los recursos sólo intercambiando representaciones de los diferentes
estados.
De este modo, se pueden clasificar los servicios web en dos grandes grupos:
REST ó ‘manipulación directa de los recursos’. El propósito principal de los
servicios es la manipulación de representaciones XML de recursos web:
○ Usan un conjunto mínimo y uniforme de operaciones
○ Usan vocabularios y mecanismos universales para gestionar el estado
○ Se implementan con servidores web estándar que manipulan directamente
la información
○ XML se emplea para representar los recursos web
Objetos distribuidos u ‘operación a través de web’. El propósito principal es la
ejecución remota de un conjunto de operaciones indeterminadas sobre recursos
que pueden no estar en la web.
○ Usan operaciones arbitrariamente complejas
○ Usan vocabularios y mecanismos específicos de la aplicación para gestionar
el estado
○ Se implementan con código externo invocado a través 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 sintonía con la propia
filosofía del WWW (identifica los recursos con información en formato XML, servida
por un servidor web estándar y accesible a través de un URI) mientras que la
arquitectura de objetos distribuidos usa XML (soporte de datos) y protocolos
internet
(mecanismo
de
acceso
a
recursos
remotos)
como
herramientas
particulares dentro de la filosofía clásica de desarrollo de una aplicación particular.
Pág. 3-44
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.7.3 DEFINICIONES SOBRE SERVICIOS WEB
Es difícil acordar una definición estándar de Servicio Web porque son diversas las
concepciones (desde SOAP-RPC puro hasta la manipulación HTTP de documentos)
que pretenden ser integradas bajo una arquitectura de referencia común.
Un Servicio Web es un sistema software diseñado para ofrecer interacción e
interoperatividad entre máquinas conectadas a través de una red mediante el
protocolo de transporte HTTP y con una serialización de datos en XML. La manera
de interactuar se describe en un interfaz, usando un formato procesable por las
máquinas.
La Figura 3-8 muestra los roles básicos que toman parte en un servicio web. La
noción abstracta del SW que proporciona un servicio a través del envío y recepción
de mensajes debe ser implementada por un Agente Proveedor concreto (recurso
computacional relacionado con el suministro de un servicio web a través de una
conexión HTTP). El Agente Requeridor es el SW que accede a los servicios
ofrecidos por el Agente Proveedor. Para lograr que la comunicación entre estas dos
entidades sea automática e independiente de la intervención humana es necesario
un acuerdo previo entre ambas partes respecto a dos cuestiones:
1. La lógica de los mensajes intercambiados entre la entidad proveedora y
la usuaria se describe en un documento WSD (Web Service Description)
procesable por las máquinas. El WSD define el formato de los mensajes,
tipos de datos, protocolos de transporte y formatos de serialización 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 gramática conocida.
2. La semántica del intercambio de mensajes representa el contrato
respecto al propósito y las consecuencias. Este contrato puede ser explícito
o implícito, oral o escrito, orientado a consumo de máquina o humano.
Mientras que WSD representa un contrato que gobierna los mecanismos de
interacción con un servicio particular, la semántica es un contrato que
gobierna el significado y propósito de la interacción.
Estos acuerdos toman forma computacional (son programados) en los agentes
proveedor y requeridor del servicio, de forma que estos agentes puedan ser
autónomos en la petición y provisión automática del servicio.
Pág. 3-45
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Figura 3-8. Roles básicos en un servicio web.
Pág. 3-46
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.7.4 ESCENARIOS DE USO DE SERVICIOS WEB
David Booth identifica escenarios de propósito 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 operación.
3.7.4.1 Escenario 0: Interacción web clásica (sin servicios web)
Un humano manualmente, con un navegador web, interactúa con un servidor web
que ha sido programado para alojar una aplicación determinada.
Figura 3-9. Escenario 0 de uso de Servicios Web.
Esencialmente se trata de una interacción hombre-máquina porque el navegador
actúa como una simple herramienta empleada por el usuario para acceder al
servidor. Cualquier patrón de interacción que la aplicación 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 máquinas, los patrones de interacción.
3.7.4.2 Escenario 1: Partes conocidas, WSD estático
Dos organizaciones que se conocen desean automatizar su interacción a través de
Servicios Web. La semántica es especificada manualmente por humanos.
Actores:
○ Requeridor humano (uno o varios)
○ Proveedor humano (uno o varios)
○ Agente requeridor (parte cliente de la aplicación que se comunicará con el
agente proveedor)
○ Agente proveedor (parte servidora de la aplicación)
Pág. 3-47
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Artefactos:
○ WSD (Web Service Description) es algún tipo de descripción de la
interacción deseada en un formato procesable por las máquinas. Incluirá
descripciones estáticas de mensajes, tipos de datos, operaciones, etc. Hoy
en día todavía no es capaz de definir completamente la semántica de la
interacción.
○ Semántica. Incluye toda la información sobre la interacción no incluida en el
WSD: acuerdos e informaciones relevantes para la interacción (comunicados
explícitamente o no). Puede ser acordada verbalmente o expresada en
cualquier formato. Según se vayan adoptando lenguajes semánticamente
ricos para la descripción de servicios web, se irá trasladando más
información al WSD.
Secuencia de operación:
○ Acuerdo en semántica y WSD entre proveedor y requeridor humano sobre la
interacción que desean de los agentes
○ El requeridor humano introduce el WSD y la semántica en su agente
(dinámicamente o a través de programa)
○ El proveedor humano introduce el WSD y la semántica en su agente
○ Los agentes interactúan
Figura 3-10. Escenario 1 de uso de Servicios Web.
3.7.4.3 Escenario 2: Partes conocidas obtienen WSD dinámicamente
El WSD es proporcionado dinámicamente por la entidad proveedora. Esto permite a
las entidades requeridoras asegurarse de que siempre disponen de la última versión
y permite al proveedor actualizar periódicamente el WSD sin necesidad de
renegociar la semántica entre humanos.
Pág. 3-48
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Figura 3-11. Escenario 2 de uso de Servicios Web.
Secuencia de operación:
○ Acuerdo en la semántica que indicará qué tipos de WSD serán adecuados
○ Introducción de la semántica en los agentes
○ Lectura del WSD (simple método HTTP GET en un URL) y comprobación de
que concuerda con la semántica pactada
○ Interacción entre agentes
3.7.4.4 Escenario 3: Múltiples proveedores, descubrimiento manual
El requeridor humano no conoce de antemano qué servicio web desea. Emplea una
herramienta de búsqueda para encontrar un servicio web semánticamente
compatible con lo que quiere lograr. Después, selecciona uno de entre los servicios
encontrados y lo utiliza.
Actores:
○ Requeridor humano
○ Proveedor humano
○ Agente requeridor
○ Agente proveedor
○ Herramienta de búsqueda (alojada en la entidad requeridora, en la
proveedora o en una tercera). Puede ser un motor de búsqueda (p.ej.
google) o un registro UDDI.
Artefactos:
○ WSD
○ Semántica
Pág. 3-49
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
○ FuncID. Representa toda aquella información que sea necesaria para que el
agente requeridor identifique sin ambigüedad la semántica 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 operación:
○ Acuerdo en la semántica
○ Introducción de semántica y WSD
○ La herramienta de búsqueda coge WSD y FuncID
○ El requeridor humano coge el WSD
○ Entrada de semántica y WSD en el agente requeridor
○ Interacción entre agentes
3.7.4.5 Escenario 4: Múltiples proveedores, acceso a WSD del
proveedor
Se requiere de un artefacto adicional al escenario anterior. El WSD URL es la
información que necesita el agente requeridor para acceder al WSD del agente
proveedor.
Pág. 3-50
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Figura 3-13. Escenario 4 de uso de Servicios Web.
3.7.4.6 Escenario 5: Múltiples proveedores, selección automática
El
agente
requeridor
dinámicamente
selecciona
uno
de
varias
entidades
proveedoras potenciales (todas ellas implementan servicios web semánticamente
compatibles). Las semánticas especificadas manualmente por humanos, han sido
previamente fijadas.
Se añade 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 triángulo
Abstracción de mayor nivel de los escenarios 4 y 5. Se une la herramienta de
búsqueda y el agente seleccionador en un único agente de búsqueda, se omite la
semántica y se abstraen los detalles de las entidades.
Actores:
○ Entidad requeridora
Pág. 3-51
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
○ Entidad proveedora
○ Agente buscador
Secuencia de operación:
○ La entidad proveedora publica WSD
○ La entidad requeridora encuentra WSD
○ Interacción entre agentes
Figura 3-15. Escenario en T de uso de Servicios Web.
Pág. 3-52
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.7.5 TECNOLOGÍAS PARA SERVICIOS WEB
Los conceptos de SOA y Servicios Web están relacionados con la visión del futuro
del World Wide Web de Berners-Lee (1999), la Web Semántica. La Web Semántica
consiste en organizar los documentos de tal modo que se facilite el acceso
automático a la información y la búsqueda de datos de forma mucho más
significativa de lo que permiten las actuales herramientas de búsqueda. La sencillez
de uso y utilidad de la web se mejorará gracias a:
™ Documentos marcados con información semántica. Metadatos o información
orientada a aplicación y no a lectura humana.
™ Vocabularios
comunes
de
metadatos
(ontologías)
y
mapas
entre
vocabularios que describan a los creadores de documentos cómo marcarlos
para que agentes usen la información.
™ Agentes automáticos que ejecuten tareas para los usuarios a través del uso
de metadatos.
™ Servicios basados en web para proveer a los agentes de información. Es
decir, aplicaciones con arquitectura orientada al servicio.
™ Utilidades básicas: URI1s, XML, Namespaces.
Ante este panorama, no muy lejano, sobre el futuro del intercambio de información
en internet, se puede hablar de un presente prometedor en cuanto al uso de
Servicios Web. Hoy en día ya se están usando Servicios Web y se están
constatando importantes ventajas en la concepción de aplicaciones distribuidas:
9 Aúna las ventajas de Java como lenguaje de programación 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
aplicación y el interfaz para obtenerlos, son publicados en un formato
estándar comprensible para cualquier aplicación.
9 Por basarse principalmente en el protocolo HTTP, no tienen ningún problema
para ejecutarse a través de cortafuegos (‘firewalls’).
9 Permiten que los programas (en lugar de los humanos) intercambien
información y comandos usando mensajes XML.
1
Uniform Resource Identifier. Identificación 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 página web.
Pág. 3-53
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
9 Mayor sencillez de implementación y flexibilidad que los sistemas
fuertemente acoplados tipo CORBA. Los sistemas débilmente acoplados son
el único modo de comunicar o hacer interoperar aplicaciones que no se
conocían cuando fueron programadas.
9 Basado en estándares internet mundialmente conocidos y establecidos:
HTTP, XML, URL
Evidentemente,
nuevas
tecnologías
han
emergido
para
llevar
a
cabo
la
implementación de los Servicios Web. Aunque la mayoría de ellas tienen en XML su
referente principal, XML nació con la intención de ser un lenguaje de marcado
simple que sirviera para almacenar información 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
información entre aplicaciones, se le añadió el schema que describía la información
a intercambiar. Cuando comenzó a usarse como middleware, nuevas utilidades
(lenguajes específicos XML) proliferaron alrededor de XML:
•
SOAP (Simple Object Access Protocol). Protocolo extensible para el
intercambio de datos XML. Propone un mecanismo de creación de paquetes
estructurados de datos. Los servicios exponen la funcionalidad a los usuarios
a través de este protocolo. Se identifica con la implementación de
arquitecturas (no REST) de objetos distribuidos u ‘operación a través de
red’.
•
WSDL (Web Service Description Language). Los servicios describen sus
interfaces en documentos WSDL para que sea posible la construcción 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 través
de mensajes conteniendo documentos o procedimientos (RPC).
•
UDDI (Universal Discovery Description and Integration). Forma de registrar
los servicios para que estén al alcance de usuarios potenciales.
La integración de diferentes módulos que se persigue en los servicios web lleva
necesariamente al concepto de componente como unidad mínima de composición
del sistema distribuido. Los componentes necesitan de un Component Execution
Environment (CEE), tecnologías que provean de infraestructura técnica en tiempo
de ejecución. Las tecnologías CORBA y DCOM tuvieron un éxito parcial facilitando la
interacción entre componentes. Especialmente CORBA consigue la colaboración
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 estático para la invocación 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
Pág. 3-54
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
que hace que un cambio en un componente requiera un alto grado de
reprogramación y pruebas en los otros componentes conectados.
En el caso de los servicios web, se intenta desacoplar al máximo los componentes
entre sí (los servicios ofrecidos y requeridos por los componentes pueden cambiar
dinámicamente) y éstos de las plataformas. Surgen nuevos modelos específicos
para el desarrollo de aplicaciones:
.NET. Proyecto iniciativa de Microsoft, lanzado en 2002, para crear una nueva
plataforma de desarrollo SW con intención de lograr transparencia de red,
independencia de plataforma y desarrollo rápido de aplicaciones. Fundamentos:
○ CLI (Common Language Infrastructure) es una máquina virtual que ejecuta
MSIL (Microsoft Intermediate Language) y una librería estándar (Common
Language Runtime) diseñada para ser independiente de lenguajes de
programación y de sistemas operativos. CLI soporta cualquier lenguaje de
programación orientado a objeto pero se ofrecen versiones específicas de
lenguajes para .NET como: C#, VisualBasic.NET, JScript.NET,… Posibilidad
de ensamblar en MSIL código de diferentes lenguajes.
○ Ligado a Microsoft Windows como plataforma de ejecución.
○ Creación de servicios web sobre SOAP.
○ Nueva
arquitectura
de
componentes
COM+
que
sustituye
a
COM
(Component Object Model) como fundamento de la programación orientada
a componente.
J2EE (Java 2 Platform Enterprise Edition). Es un estándar 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 generación de
aplicaciones web para clientes finos (no requieren de grandes capacidades, sólo
consumo de HTML y ejecución de applets). Fundamentos:
○ Creación de HTML para consumo de los clientes con JSP (Java Server Pages)
y servlets.
○ EJB (Enterprise JavaBeans). Servicios como concurrencia, seguridad y
gestión
de
memoria.
Tecnología
basada
en
servidor
para
distribuir
componentes. Soporta XML.
○ JDBC (Java Data Base Connectivity), interfaz estándar 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 sólo para grandes corporaciones. En la
creación de aplicaciones más humildes, en las que la inversión es menor y no se
puede permitir un ciclo de aprendizaje largo ni un gasto importante en
Pág. 3-55
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
herramientas
de
desarrollo,
se
opta
por
entornos
más
modestos
y
no
necesariamente ligados con un solo distribuidor. En este contexto y para la
generación 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 estándar de
facto para el desarrollo web de código 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 cuál 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 aún
aspectos por madurar:
•
XML no es un lenguaje estándar, es un metalenguaje estándar. La
estandarización de schemas y reglas de transformación permitirá ‘entender’
cualquier lenguaje XML.
•
No hay un protocolo estándar (por encima de HTTP) para el intercambio de
información en formato XML (SOAP, BizTalk,…).
Tabla 3-1. Comparación .NET vs. J2EE
.NET (Microsoft)
J2EE (Sun)
Máquina Virtual
CLI
JVM
Código intermedio
MSIL
Java Bytecode
Lenguaje de programación
C# (y otros)
Java
Arquitectura de componentes
COM+ (COM/DCOM)
EJB
Gestión de datos web dinámicos
ASP
JSP
Pág. 3-56
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
33..88 C
CO
ON
NC
CL
LU
USSIIO
ON
NE
ESS
Compendio de técnicas de integración seleccionadas para el entorno
multidisciplinar y su influencia en la arquitectura.
Arrancaba este capítulo con el propósito de investigar un abanico de técnicas que,
orientadas a la integración desde diferentes puntos de vista, pudieran servir de
soporte a los componentes del Motor de Colaboración de Herramientas (MCH) que
se recuerdan en la Figura 3-16.
IC
Interfaz
Config
SD
STR
IS
Interfaz Herramientas
DIRECTOR
Modelos
Dominios
Gramáticas
XML Dominios
Repositorios
XML
MOTOR DE
COLABORACIÓN
MOTOR DE
DE
COLABORACIÓN 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
técnica de integración se obtienen unas conclusiones y se aplican al componente
del entorno más directamente relacionado. La Tabla 3-2 muestra esta relación
entre componentes del entorno y funcionalidades de integración. Cada una de las
filas de esta tabla se asocia con uno de los subapartados que se exponen a
continuación.
Pág. 3-57
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Pág. 3-58
Motor Colaboración
Modelos (MCM)
Motor Colaboración Herramientas
(MCH)
Tabla 3-2. Componentes del MCH y función de integración que desempeñan.
Componente
Integración de…
Gramáticas XML de
Dominios
Gramáticas
Modelos de Dominio
Modelos
DIRECTOR
Técnicas de desarrollo de
SW
Repositorio
Conocimiento
Interfaz de Herramientas
Aplicaciones
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.8.1 INTEGRACIÓN DE GRAMÁTICAS (GRAMÁTICAS
XML DE DOMINIOS)
Este módulo del Motor de Colaboración de Modelos (MCM) debe permitir describir
un lenguaje específico y diferente para cada uno de los dominios pero manteniendo
un tronco común entre ellos que permita su interrelación. Se trata, por tanto, de un
problema de definición e integración de gramáticas.
Las conclusiones del proyecto GSRC se pueden extrapolar y aplicar al módulo de
Gramáticas XML de Dominio del MCM tal como muestra la Figura 3-17:
Sintaxis Abstracta
Estructura
del
lenguaje
Sintaxis Concreta (XML)
Transformaciones Sintácticas
Significado
del lenguaje
Sistema
tipos
Sistema
tipos
Sistema
tipos
Sistema
tipos
Semántica Semántica Semántica Semántica
Gramática
IC
Gramática
SD
Gramática
STR
Gramática
IS
Figura 3-17. Diseño de las gramáticas XML en base a servicios ortogonales.
La separación de los cinco servicios constituyentes de un lenguaje sería la
siguiente para el caso de las gramáticas XML:
○ Sintaxis abstracta formada por la definición de los componentes básicos,
relaciones (a muy alto nivel), jerarquía y capacidades de instanciación que
se vayan a usar en cualquiera de las gramáticas de dominio.
○ Sintaxis concreta. Un lenguaje XML específico que permita reflejar los
conceptos recogidos en la sintaxis abstracta, constituyéndose en el formato
persistente para la información.
Pág. 3-59
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
○ Transformaciones
sintácticas.
Mecanismos
que
permitan
realizar
transformaciones sobre las instancias de la sintaxis concreta seleccionada.
Se utilizarán tecnologías XML para ello.
○ Sistema de tipos y semánticas. Se trata de la parte específica de cada uno
de los dominios. A través de tecnologías XML se completará la estructura
común (sintaxis abstracta, concreta y transformaciones) refinándola en el
caso particular de cada uno de los dominios. Este refinamiento consistirá en
la definición de cada sistema de tipos de datos particular y en la
especificación de la semántica propia de cada dominio. Todo esto será
tratado en detalle en el próximo capítulo.
De los cinco niveles de interoperatividad definidos, dada la arquitectura y modo
de
funcionamiento
del
MCM,
sería
necesario
lograr
los
3
primeros
(compatibilidad en sintaxis abstracta, concreta y transformaciones) para que la
entidad DIRECTOR pueda generar automáticamente datos de entrada para una
herramienta a partir de los resultados de otras. En resumen, la estructura de
las cuatro gramáticas 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 semánticas) se podría
lograr entre herramientas del mismo dominio para que pudieran intercambiar
modelos de datos completos (si se basan en el mismo sistema de tipos) o
información en tiempo de ejecución (si comparten además la semántica).
Aunque éste no es objeto de la presente tesis, la ortogonalización que se
realiza habilita la construcción futura de esos servicios sobre los actuales.
Pág. 3-60
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.8.2 INTEGRACIÓN 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 través de los conceptos de MOF. XML
soporta esta estructura de la siguiente forma:
M3, Meta-metamodelo. El Schema XML “Arch.xsd” define el lenguaje común
basado en componentes y conectores con jerarquía.
M2, Metamodelos de dominio. Los cuatro schemas especializados para las
vistas se definen extendiendo y especializando “Arch.xsd”. Estos schemas
definen los lenguajes específicos de domino.
M1, Modelos de dominio. El empleo de los lenguajes específicos 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.
Además, otros dos lenguajes XML como son XSLT y LER (Lenguaje para la
Especificación de Reglas) dan soporte al flujo horizontal de información y a la
validación 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. Formalización de las cuatro vistas y soporte en XML.
Pág. 3-61
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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 colaboración de herramientas a través 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 través de las relaciones entre dominios. Al formalismo
interno de colaboración 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
Colaboración de Modelos (MCM) o parte más 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 práctica 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).
Pág. 3-62
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
PIM
TIM
Tool
Independent
Model
PSM
Transformaciones
XSLT
Reglas
LER
TSM
Código
final
Tool
Specific
Model
Doc.
final
TOOLS
Figura 3-20 Conceptos MDA en el entorno multidisciplinar.
Pág. 3-63
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.8.3 INTEGRACIÓN
DE
TÉCNICAS
DESARROLLO DE SW (DIRECTOR)
PARA
El entorno multidisciplinar tiene como último objetivo la generación de SW, por
tanto, la disciplina de Ingeniería del SW tiene un carácter transversal respecto al
resto de dominios, que ofrecen una aportación más vertical. De hecho, el ciclo de
vida del sistema bajo desarrollo se define en términos de Ingeniería del SW para
integrar las aportaciones de todos los dominios. Esta característica de gestión
transversal se materializa en la entidad DIRECTOR, que es el componente de la
arquitectura del entorno que coordina todos los esfuerzos de integración de
información y los dirige de forma acorde al Proceso SW que se elija seguir. Por ello,
la Figura 3-16 ya mostraba gráficamente al DIRECTOR como el componente central
de la arquitectura, un componente transversal u horizontal.
De entre las técnicas analizadas para el seguimiento de un Proceso SW y la
inclusión en el código final de todos los matices aportados desde diferentes
dominios se han seleccionado los Métodos Formales de Especificación y los
Generadores de Programas basados en XSLT sobre los demás. Tanto MDSC
(Multi-Dimensional Separation Of Concerns) como el conjunto de técnicas de SW
dirigidas a dominio, están 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 colaboración con herramientas
específicas de campos tan alejados como el control. Por el contrario, los métodos
formales y la generación de código con XSLT pueden tener cabida en el MCH y su
relación directa con las herramientas parece más sencilla.
El empleo de estas técnicas divide el Proceso de Generación de SW, y por tanto, el
trabajo de la entidad DIRECTOR, en dos grandes fases o subprocesos:
1. Especificación Formal. La especificación del sistema desde cada uno de
los dominios de Ingeniería de Control, Sistemas Distribuidos y Sistemas de
Tiempo Real. Esta especificación multi-dominio se realiza utilizando las
gramáticas específicas hasta conseguir como resultado una especificación
XML validada formalmente desde todos los puntos de vista. Esto constituye
en sí un proceso cuyos pasos e iteraciones habrá que definir.
2. Generación Automática de Código. El resultado obtenido en la
especificación formal multi-dominio es el punto de arranque para la
generación del programa mediante tecnologías XSLT. Esta fase es propia del
dominio de Ingeniería del Software y las especificaciones que se hagan al
respecto vendrán dadas en la gramática de dominio correspondiente.
También se trata de un subproceso cuyos pasos habrá que definir.
Las aportaciones de los dominios también son diferentes en estos dos subprocesos
o fases. La fase de generación de código es exclusiva de la disciplina de Ingeniería
Pág. 3-64
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
de SW, aunque parte de los resultados de una especificación en la que toman parte
los otros tres dominios.
Comenzando por la primera de las fases, es factible el uso de un método formal
basado en lenguajes XML para la expresión de especificaciones y el uso de
mecanismos XML para la realización de pruebas formales que validen el
cumplimiento de las especificaciones. Se plantea la expresión y validación de
especificaciones de dos formas en función de su naturaleza:
™ Especificaciones Gramaticales. Hay especificaciones que se pueden recoger
y validar directamente mediante las gramáticas específicas de cada dominio, ya
que su uso implica una formalización de los datos. Las especificaciones
introducidas desde una herramienta concreta se expresan en una gramática
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 gramática. 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 más de un dominio exceden los límites de una gramática
particular porque involucran a más de una. Para éstas, se requiere de un nuevo
lenguaje
XML
que
permita
expresar
reglas
y
comprobar
después
su
cumplimiento (LER, Lenguaje para Especificación de Reglas). Éste será uno de
los puntos a resolver en el siguiente capítulo.
En todos los casos, el método de especificación empleado es declarativo u orientado
a la propiedad, es decir, se irán 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 validación formal será variable
según las necesidades del usuario y el nivel de madurez CMM de su Proceso.
Concretamente, a través del interfaz de configuración, el coordinador del proyecto
podrá definir sobre qué subsistemas aplicar la metodología formal.
Pág. 3-65
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Especialistas
Herramientas
Interfaz
Config
xml
xml
xml
IC
SD
STR
Interfaces
DIRECTOR
subPROCESO
ESPECIFICACIÓN
FORMAL
LER
Figura 3-21. Labores del DIRECTOR relacionadas con el subproceso de
especificación formal.
La Figura 3-21 muestra la gestión 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 información 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
(además de la coherencia), así mismo, el DIRECTOR validará el cumplimiento de los
requisitos expresados en LER (Lenguaje Especificación Reglas).
En cuanto al subproceso de Generación de Código, partirá de una especificación
completa validada para lanzar alguna o varias de las siguientes tareas:
™ Creación del esqueleto de la aplicación.
™ Recolección de componentes reutilizables en el repositorio y parametrización de
dichos componentes para la aplicación actual.
™ Recolección de componentes generados desde alguna de las herramientas
integradas, ya que alguna de estas herramientas también puede poseer
capacidades de generación de código.
™ Generación de los nuevos componentes que se necesiten.
™ Ensamblado completo de la aplicación juntando esqueleto, componentes
nuevos, componentes del repositorio y componentes codificados por alguna de
las herramientas del entorno.
Como comentario se puede añadir que los problemas inherentes a los métodos
formales (en cuanto a las inexactitudes que caben en la expresión formal de
requisitos y en la implementación física del sistema) se ven atenuados por la propia
Pág. 3-66
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
filosofía 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 formalización inexacta de los requisitos del usuario. En segundo lugar,
el empleo de herramientas especializadas en la generación de código para los
dispositivos comúnmente empleados minimiza el salto de máquina abstracta a
física.
En la Figura 3-22 se observa la labor del DIRECTOR en el subproceso de Generación
Automática de Código. Se parte de una especificación multi-dominio coherente y
formalmente validada y, de acuerdo a las especificaciones que relativas a la
Ingeniería del SW se han expresado (en la gramática de dominio asociada), se dan
los pasos orientados a la construcción del código final mediante la aplicación 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 próximo capítulo se detallará el diseño de este subproceso.
Componentes
generados por
herramientas
Interfaz
Config.
IS
IC
SD
STR
DIRECTOR
XSLT
ADL
ESPECIFICACIÓN
VALIDADA
subPROCESO GENERACIÓN CÓDIGO
CÓDIGO Y
DOCUMENTACIÓN
FINAL
Repositorio
Componentes
Figura 3-22. Labores del DIRECTOR relacionadas con el subproceso de Generación
de Código.
Pág. 3-67
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.8.4 INTEGRACIÓN
(REPOSITORIO)
DE
CONOCIMIENTO
El módulo repositorio es algo más que la base de datos del entorno multidisciplinar
porque no sólo se pretende el simple almacenaje y recuperación de los datos
puntuales de un proyecto. Se pretende que el repositorio maneje mayores niveles
de abstracción y permita almacenar y recuperar cuando se precise: información
(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 (estándares y mejores prácticas de
aplicación genérica). La REUTILIZACIÓN es la facultad que se desea para el
entorno y que quiere materializarse en el módulo repositorio. Pero reutilización en
el sentido más amplio, no sólo reutilización de componentes, sino reutilización de
todo el conocimiento que se pueda deducir en cada toma de decisión, cada sistema
diseñado y cada proyecto o conjunto de proyectos terminados. El conocimiento
potencial adquirido en cada toma de decisión debe ser recogido para emplearlo en
subsiguientes decisiones. La reutilización en estos términos 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.
™ Recuperación sistemática de información. El conocimiento no debe permanecer
estático hasta que alguien decida emplearlo, debe fluir hacia dónde se necesite
(hacia el proyecto y especialista adecuado) y cuándo se necesite (sin necesidad
de una invocación explícita por parte del usuario). En definitiva, debe
recuperarse sistemática y automáticamente, y dirigido a dónde y cuándo pueda
ser útil.
El uso de tecnologías XML facilita ambas fases porque la información se expresa
explícitamente en un formato estándar que favorece la captura de conocimiento y si
este conocimiento se enriquece adecuadamente con meta-información, queda
‘etiquetado’ para ser recuperado automáticamente 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 gestión
documental
y
de
generación
automática
de
documentos
al
entorno
multidisciplinar porque a partir de todo el volumen de información que almacena
el
repositorio
se
pueden
generar
automáticamente
documentan el curso de un determinado proyecto
Pág. 3-68
los
informes
que
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
™ Documentos dirigidos a programas. Todo aquel conocimiento inferido que deba
ser aplicado automáticamente en un futuro deberá ser expresado en un formato
procesable mediante programa.
En cualquiera de los casos, XML vuelve a mostrarse como una opción adecuada ya
que, a partir de un formato único (para toda la información en general) y
empleando las mismas tecnologías, pueden generarse bien documentos legibles
para el hombre o bien información procesable automáticamente por un programa.
Aunque el diseño del repositorio es materia del siguiente capítulo, ya se pueden
esbozar aquí alguna de sus características:
•
Información relativa al proyecto: Configuración del proyecto (proceso SW,
herramientas usadas, usuarios), instancias para cada uno de los dominios,
ficheros binarios,…
•
Conocimiento acumulado: componentes diseñados y parametrizables para su
reutilización, reglas de relaciones entre elementos del mismo o de diferentes
dominios (LER, Lenguaje para Especificación de Reglas),…
•
Mecanismos de activación de las reglas. Cada regla estará acompañada por
unas condiciones de activación y cuando el DIRECTOR detecte que se cumplen
esas condiciones activará la regla.
•
Gestión documental. Las tomas de decisiones y resultados obtenidos se pueden
documentar automáticamente y controlar las versiones, establecer mecanismos
de búsqueda, 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 recuperación automática de la información.
Pág. 3-69
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
3.8.5 INTEGRACIÓN DE APLICACIONES (INTERFAZ
DE HERRAMIENTAS)
Tal y como ilustraba la Figura 3-16, el componente de Interfaz de Herramientas
(junto con la Interfaz de Configuración) convierten al Motor de Colaboración de
Modelos (MCM) en un Motor de Colaboración de Herramientas (MCH). Es decir, este
componente acomoda las particularidades de cada herramienta a las convenciones
generales del entorno (proceso SW definido, gramáticas, modelos,…). Debe utilizar
un middleware estándar para que las herramientas sean capaces de leer y escribir
la información de los modelos de dominio o vistas del sistema.
Tal y como se ha visto, la mayoría de los conceptos en los que se fundamentan los
servicios web se adaptan perfectamente a las necesidades del módulo de Interfaz
de Herramientas. Además, la resolución de esta capa usando servicios web
permitirá al entorno multidisciplinar favorecerse de los beneficios que reporta el uso
de estas tecnologías.
La concepción 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 adopción de SOA y de los
conceptos de servicios web en el entorno implican el uso de:
Formato de datos estándar (XML) sobre protocolo de transporte estándar
(HTTP).
Identificación de los servicios que se ofrecen o se requieren con recursos
accesibles en URIs.
Agentes. La comunicación automática (sin intervención 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 más 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
básicas a realizar: enviar ó recoger un documento XML, que se implementarán a
través de los métodos http GET y http POST. Con lo cual, un simple servidor web
es capaz de implementar estas funcionalidades. Por otro lado, también se usan
documentos XML (el WSD) para exponer los servicios. Esta arquitectura concuerda
con la propia del WWW y la futura Web Semántica.
Tras analizar los diferentes escenarios de interacción posibles que se presentan
para servicios web en el apartado 3.7.4, el escenario más adecuado parece ser el
cuarto (acceso automático al WSD del proveedor), con la salvedad de que en el
entorno hay un solo proveedor y no existe fase de descubrimiento ni selección
Pág. 3-70
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
automática. 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 Colaboración de Herramientas
ofrece, a través de este agente, servicios de almacenamiento, validación,
coordinación y traducción de la información 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 gramática 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.
○ Semántica. Los documentos XML intercambiados utilizan uno de los cuatro
lenguajes de dominio conocidos de antemano. Por tanto, la semántica de la
información es inherente al lenguaje empleado.
Secuencia de operación:
○ Se programa el agente proveedor en el MCH incluyendo el WSD y la
configuración adecuada del servidor web para habilitar las URIs para envío y
recogida de documento XML. Este sencillo interfaz permite al MCH
interactuar
con
herramientas
desconocidas
en
el
momento
de
su
implementación.
○ Se programa un agente requeridor para cada herramienta. Éste deberá
traducir los documentos (en ambos sentidos) entre una de las gramáticas de
dominio del entorno y el formato y semántica propios de la herramienta.
○ El coordinador selecciona las herramientas a emplear en un proyecto.
○ Los especialistas recogen del MCH (a través de la interacción entre agentes)
la instancia actual de aquella vista propia para su herramienta. Tras trabajar
con ella, envían el nuevo estado de la instancia al MCH.
Pág. 3-71
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
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
desencadenarán 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, coordinación y validación 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 descripción se está hablando de dos usos de XML y
en cada caso con diferentes gramáticas: por una parte la propia información que se
intercambian las herramientas con el entorno estará expresada en alguna de las
cuatro gramáticas de dominio; por otra parte el contrato WSD se expresa en el
lenguaje estándar WSDL.
Las decisiones de diseño enumeradas conducen a un escenario como el que
muestra la Figura 3-23, en donde se aprecia cómo 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
Ingeniería de Control es adaptada al entorno a través de un agente específico. Éste
accede al URL en el que encontrar el WSD del MCH (expresado según WSDL),
donde obtiene los puntos de acceso a los servicios (URIs). A partir de ese
momento,
los
agentes
son
intercambiando instancias XML.
Pág. 3-72
capaces
de
comunicarse
a
través
de
HTTP
Capítulo 3: Arquitectura del Entorno y Técnicas de Integración
Herramienta
‘A’
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 cómo el Interfaz de Herramientas (Agente Proveedor) actúa
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 están surgiendo para
intentar estandarizar la implementación de servicios web, aún no tienen una
aceptación 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 más ambiciosos que los aquí planteados y además no basado en
REST. UDDI, por su parte, plantea el registro universal de servicios para su
localización por parte de cualquier usuario potencial, lo que también excede los
propósitos del entorno multidisciplinar.
Por último, respecto al entorno de ejecución de componentes para los agentes, se
opta por el uso de LAMP (Linux, Apache,…) obedeciendo al criterio de economía en
la implementación del entorno.
Pág. 3-73