3-Arquitectura y Tecnicas de Integracion

333 AAARRRQQQUUUIIITTEEECCCTTTUUURRRAAA DDDEEELLL T

EEENNNTTTOOORRRNNNOOO YYY TTTCCCNNNIIICCCAAASSS DDDEEE

IIINNNTTTEEEGGGRRRAAACCCIIINNN

En este captulo se inicia la toma de decisiones respecto al entorno multidisciplinar.

En primer lugar, se seleccionan los estndares de modelado y expresin formal

y la forma de usarlos en el entorno. As mismo, se define una primera aproximacin

a la arquitectura del entorno en un intento por sintetizar, en forma de bloques

funcionales relacionados, cada una de los requisitos identificados a lo largo del

captulo anterior.

Posteriormente, se definir lo que se entiende por integracin y se describirn

diferentes niveles de integracin. Lo que dar paso a un estudio de diferentes

tcnicas de integracin para resolver la colaboracin de gramticas, modelos,

tcnicas de desarrollo de SW, conocimiento y aplicaciones. Se valorarn

tcnicas muy dispares entre s pero con el comn denominador de servir para

integrar informacin, aunque con diferentes grados de abstraccin.

Las conclusiones del captulo servirn para seleccionar las tcnicas ms

adecuadas para cada uno de los niveles de integracin, y completar as la

arquitectura del entorno esbozada al inicio con ms detalles relativos a las tcnicas

a utilizar.

3.1 Arquitectura General del Entorno 3.1.1 Modelado y Expresin Formal en el Entorno 3.1.2 Requisitos y Componentes Bsicos del Entorno 3.1.3 Estructura General

3.2 Niveles de Integracin

3.3 Integracin de Gramticas 3.3.1 GSRC Semantics Project

3.4 Integracin de Modelos

3.5 Integracin de Tcnicas para Desarrollo de SW 3.5.1 Mtodos Formales 3.5.2 Separacin Multidimensional de Propsitos 3.5.3 Desarrollo de SW Dirigido a Dominio 3.5.4 Generacin de Programas con XSLT

3.6 Integracin de Conocimiento

3.7 Integracin de Aplicaciones 3.7.1 Conceptos bsicos sobre Servicios Web 3.7.2 Estilo de Arquitectura REST 3.7.3 Definiciones sobre Servicios Web 3.7.4 Escenarios de Uso de Servicios Web

3.7.4.1 Escenario 0: Interaccin web clsica (sin servicios web) 3.7.4.2 Escenario 1: Partes conocidas, WSD esttico 3.7.4.3 Escenario 2: Partes conocidas obtienen WSD dinmicamente 3.7.4.4 Escenario 3: Mltiples proveedores, descubrimiento manual 3.7.4.5 Escenario 4: Mltiples proveedores, acceso a WSD del proveedor 3.7.4.6 Escenario 5: Mltiples proveedores, seleccin automtica 3.7.4.7 Escenario T: Diagrama en tringulo

3.7.5 Tecnologas para Servicios Web

3.8 Conclusiones 3.8.1 Integracin de Gramticas (Gramticas XML de Dominios) 3.8.2 Integracin de Modelos (Modelos de Dominio) 3.8.3 Integracin de Tcnicas para Desarrollo de SW (DIRECTOR) 3.8.4 Integracin de Conocimiento (Repositorio) 3.8.5 Integracin de Aplicaciones (Interfaz de Herramientas)

Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin

333...111 AAARRRQQQUUUIIITTTEEECCCTTTUUURRRAAA GGGEEENNNEEERRRAAALLL DDDEEELLL EEENNNTTTOOORRRNNNOOO

Sobre las conclusiones del recorrido del Estado del Arte del captulo

anterior, conclusiones en forma de seleccin de estndares para el

modelado y la expresin formal, requisitos identificados y arquitectura de

bloques en la que se fundamentar el entorno.

33..11..11 MMOODDEELLAADDOO YY EEXXPPRREESSIINN FFOORRMMAALL EENN EELL EENNTTOORRNNOO

Aplicando al entorno multidisciplinar las ideas sobre niveles de abstraccin

expuestas en el captulo anterior, se identifica la necesidad de construir cuatro

jerarquas de abstraccin (en principio independientes) para representar la visin

del SCDTR desde cada uno de los dominios involucrados (IC, SD, STR e IS). Dado

un sistema concreto en desarrollo, cada dominio selecciona (a partir del conjunto

total de informacin existente) el subconjunto de datos relevantes para su campo

(objetos de dominio). Estos datos y sus relaciones se describen dando forma al

modelo particular de dominio del sistema. Por tanto, en este trabajo se

entiende por modelo la abstraccin o descripcin parcial y particular de las

caractersticas (comportamiento, estructura, funcionalidad,...) del sistema bajo

desarrollo. Para aadir formalidad a estas descripciones y tener la posibilidad de

validar la correccin de diferentes modelos de acuerdo a los parmetros propios del

dominio es necesaria la existencia de un nivel superior o metamodelo del

domino. El metamodelo define el lenguaje a emplear para construir nuevos

modelos, o descripciones de sistemas de acuerdo a las convenciones establecidas

por un dominio, y con ello introduce formalidad o mecanismos de validacin de las

descripciones.

En resumen, se plantea la necesidad de definir cuatro metamodelos porque cada

dominio usar diferentes objetos de dominio, es decir, tendr un subconjunto de

informacin diferente en el nivel de dato.

Se considera interesante la arquitectura de 4+1 vistas en tanto que esta

arquitectura coincide con la visin adelantada en el captulo inicial de esta memoria.

En ambos casos se separan los modelos en funcin del profesional que los vaya a

usar y tambin se considera necesario el empleo de una notacin o lenguaje

especializado para la descripcin del sistema desde cada uno de los dominios. Hay

que destacar el inters de construir estos lenguajes especializados utilizando en

todos los casos un ncleo comn formado por componentes y conectores. La

existencia de ese ncleo expresivo comn facilitar dar forma a las relaciones entre

Pg. 3-1


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

arquitectura de 4+1 vistas la capacidad de expresin jerrquica de los sistemas.

UML 1.4 desarrolla estos conceptos y define una rica coleccin de vistas en forma

de diagramas orientados a objetos, permitiendo mltiples enfoques para un mismo

problema. La potencia de este lenguaje radica en su flexibilidad expresiva y

capacidad de adaptacin. Pero esta virtud le hace carecer de rigurosidad y

formalidad cuando se trata de asegurar la coherencia global del modelo y sus

instancias. Como uno de los requisitos del entorno multidisciplinar es la capacidad

de validar la correccin de las instancias respecto al metamodelo, UML 1.4 parece

incompleto como soporte de los metamodelos de dominio y sus instancias. Adems,

sigue careciendo de la jerarqua formal deseable. Como ambas carencias prometen

ser paliadas en la prxima versin del lenguaje (UML 2.0), es una posibilidad de

futuro la expresin de los metamodelos de dominio y sus instancias en este

estndar.

En la filosofa MDA (Model Driven Architecture) de OMG la definicin y relacin

entre PIM y PSM, la formalidad introducida por MOF y la serializacin de modelos e

instancias con XMI tienen a UML como punto comn de referencia. A pesar de ello,

el que UML no sea el lenguaje inicialmente elegido para el modelado de dominio en

el entorno no implica dar la espalda a todos los dems estndares. De hecho, se

propone desarrollar el entorno en sintona con esta filosofa y dejar preparado el

camino para que en un futuro UML pueda ser el lenguaje de modelado inicial y XMI

pueda tender directamente los puentes hacia la expresin en XML de esos modelos

e instancias.

XML s parece colmar conjuntamente las necesidades de expresin flexible y

adaptable a diferentes campos junto con la validacin formal de las instancias. Su

papel de metalenguaje, permitiendo la creacin de lenguajes formales a travs de

schemas, y el complemento de XSL (transformaciones entre lenguajes) le hacen

convertirse en un candidato ideal.

Incluso si UML 2.0 (y estndares asociados) cumplen todas las expectativas, XML

seguir siendo necesario para el intercambio de informacin entre diferentes

plataformas, entre diferentes herramientas MOF o entre herramientas MOF y otras

no MOF (necesidad de validacin previa).

En resumen, en lo concerniente al modelado y expresin formal de la informacin

en el entorno multidisciplinar se toman las siguientes decisiones:

Definir los metamodelos de los cuatro dominios implicados. Los modelos o instancias de los mismos sern las descripciones del sistema desde los

enfoques particulares.

Usar schemas XML para definir los metamodelos de dominio. stos fijarn todos los requisitos a cumplir por las instancias (descripciones de sistemas

particulares hechas de acuerdo al metamodelo de dominio). Estos schemas

Pg. 3-2


XML servirn de gramticas formales del lenguaje a emplear desde cada

dominio.

Construir los lenguajes extendiendo y especializando un ncleo expresivo comn que soporte la descripcin jerrquica del sistema en base a

componentes y conectores.

Seguir en la medida de lo posible los preceptos del MDA. Por una parte, distinguir el nivel de abstraccin de la aplicacin independiente de detalles

(PIM), otro con detalles propios de la plataforma de desarrollo (PSM) y, por

ltimo, la implementacin final. Por otra parte, establecer mecanismos para

automatizar y formalizar el paso entre dichos niveles de abstraccin. De este

modo sern evidentes las ventajas obtenidas en cuanto a reutilizacin de

modelos y formalizacin del proceso.

Preparar la adopcin futura de UML 2.0 como lenguaje soporte de los metamodelos de dominio. Esto permitira :

generacin automtica desde UML de gramticas XML (schemas) e instancias (documentos) gracias a XMI o al empleo de perfiles que modulen

la creacin de XML a voluntad del diseador

generacin automtica desde UML del cdigo que implemente los interfaces entre herramientas y modelos de dominio para diferentes plataformas (Java,

C++, CORBA,)

adopcin del perfil de tiempo real como metamodelo de dominio para STR (Sistemas de Tiempo Real)

Cabe destacar que aunque se descarta el empleo de UML para el modelado formal

de los dominios esto no implica que no pueda existir una herramienta UML

integrada en el entorno. Una herramienta UML podra usarse, por ejemplo, para

especificar la arquitectura SW del sistema, pero el resultado de su uso habra que

expresarlo en XML y validarlo contra su metamodelo correspondiente (schema

XML).

Pg. 3-3


33..11..22 RREEQQUUIISSIITTOOSS YY CCOOMMPPOONNEENNTTEESS BBSSIICCOOSS DDEELL EENNTTOORRNNOO

El anlisis realizado en el Estado del Arte sobre las herramientas especficas de

dominio habituales en cada uno de los campos de estudio, ha permitido identificar

varios requisitos que deben guiar la construccin del entorno multidisciplinar de

herramientas:

La trazabilidad ha demostrado ser una propiedad fundamental cuando se trata de coordinar diferentes fases de desarrollo y an ms cuando se emplean

diferentes herramientas. Esta propiedad deber ser intrnseca al propio entorno

y, por tanto, no basada en ninguna herramienta particular.

El Ncleo del Entorno debe ser independiente de cualquiera de las herramientas integradas. Frente a la opcin de tomar una herramienta

suficientemente genrica como centro del entorno e ir amplindola con mdulos

paralelos que complementen su funcionalidad, se opta por disear una

arquitectura horizontal adecuada, con funcionamiento y formato de

almacenamiento propios, e ir acomodando las herramientas especficas

verticales a esta arquitectura y forma de trabajo.

Para cada uno de los dominios especficos se han detectado conceptos clave que se constituyen en criterios de clasificacin de grupos de herramientas y, por

tanto, en parmetros de configuracin para el Ncleo del Entorno:

Sistemas Distribuidos. El Protocolo de Comunicacin elegido para el sistema en desarrollo determina el grupo de herramientas de ayuda que

pueden necesitarse.

Sistemas de Tiempo Real. El Estilo de Arquitectura demuestra ser clave y tener implicaciones directas en herramientas de anlisis, pero tambin en el

diseo. Son limitados los estilos de arquitectura empleados en Sistemas de

Tiempo Real (secuencial, dirigida a eventos, pipeline, cliente-servidor) pero

no se va a disear un entorno que soporte uno solo de ellos, sino que se

permitir seleccionar el ms adecuado en cada proyecto. El estilo elegido

para el sistema en desarrollo determinar qu subconjunto de herramientas

pueden usarse y qu sinergias existirn entre ellas. La Metodologa es un

concepto an ms amplio que engloba el estilo de arquitectura y restringir

an ms el nmero y forma de utilizar las herramientas.

Ingeniera del SW. Es necesario el uso de un Proceso de SW adaptado a las necesidades de los SCDTR, pero configurable y modificable por el usuario en

sus detalles para que se adapte a las necesidades propias del campo de

aplicacin y al Nivel de Madurez CMM de la organizacin. La visibilidad o

expresin explcita del Proceso y su gestin desde una entidad

Pg. 3-4


independiente de cualquier herramienta ofrecer esta flexibilidad de cara al

usuario.

El Ncleo del Entorno debe ser flexible, para adaptarse con facilidad a necesidades futuras, y abierto para integrar en cada momento a la herramienta

especfica ms adecuada. Esto se conseguir a travs del uso de estndares

para la implementacin de los componentes anteriores

El Ncleo del Entorno se asemeja a los entornos I-CASE descritos en el captulo

anterior en que tambin debe ofrecer una arquitectura comn en la que integrar

herramientas de diferente naturaleza. Por ello, se identifican los siguientes

Componentes Bsicos, anlogos a los de dichos entornos:

Repositorio de informacin comn a todas las herramientas.

Componente de integracin de modelos. Contiene la definicin explcita de los cuatro metamodelos de dominio, sus relaciones y la relacin de los

metamodelos con las herramientas particulares en base a ciertos metadatos.

Componente DIRECTOR, desde donde se controlan todos los mecanismos de activacin, se comprueban y gestionan de forma global los errores, la integridad

y la consistencia.

Interfaces de herramientas. Debe estandarizarse el formato y protocolos de intercambio de datos entre las herramientas y el entorno.

Interfaz de usuario comn para la configuracin del entorno.

El estudio hecho en el Estado del Arte sobre algunos intentos de integracin de

dominios en forma de entornos de herramientas arroja las siguientes coincidencias

entre varias soluciones propuestas:

9 Uso de XML como formato preferido para la integracin de informacin. 9 Uso de Java como lenguaje de programacin preferido para el SW de

integracin

9 Uso de documentos (normalmente en XML) anexos a los mdulos para describir la informacin necesaria para su integracin con otros.

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

9 Uso de gramticas abstractas con los elementos sintcticos a emplear en todo el entorno, aunque luego se le aada la semntica particular de cada

dominio.

9 Uso de entidad director o similar para coordinar las diferencias semnticas entre dominios valindose de la estructura comn de los lenguajes.

Pg. 3-5


9 Concepto de METAframework o infraestructura necesaria para la composicin de frameworks. Hasta ahora el diseo se ha centrado en la

consideracin de cuatro dominios y de las relaciones entre ellos, pero por

qu slo cuatro?, cmo se integrara uno ms? Si se es capaz de expresar

el metamodelo del que emergen los cuatro dominios, la definicin de un

nuevo modelo bajo esos mismos principios asegurara su colaboracin con

los dems en el entorno. Esta idea del metamodelado se desarrollar para

formalizar los mecanismos de ampliacin de los dominios considerados en el

entorno.

El siguiente apartado definir la estructura general del entorno, que estar

compuesta por el conjunto de componentes aqu enumerados y permitir satisfacer

los requisitos identificados. La cohesin y coherencia del entorno se fundamentar

en el uso de diferentes tcnicas de integracin a varios niveles.

Pg. 3-6


33..11..33 EESSTTRRUUCCTTUURRAA GGEENNEERRAALL

Las pautas enumeradas conducen a un diseo del entorno como el mostrado en la

Figura 3-1. Las herramientas particulares son empleadas por los especialistas en la

manera habitual, pero se conectan como clientes al Motor de Colaboracin de

Herramientas (MCH), que hace las funciones de servidor. El tipo de servicio que

ofrece el MCH es de almacenamiento, validacin y coordinacin de la informacin

del SCDTR bajo desarrollo. El MCH ofrece estos servicios apoyndose en el Motor

de Colaboracin de Modelos (MCM).

La capa ms externa del MCH gestiona un flujo de informacin vertical y en ambos

sentidos entre cada herramienta y el propio MCH, mientras que el MCM gestiona

otro flujo de informacin transversal que permite coordinar y actualizar los datos

que importan las herramientas.

Existir un amplio conjunto de herramientas particulares (siempre ampliable)

registradas en el entorno, es decir, conocidas en cuanto a su comunicacin con el

MCH, la funcin que desempean, las informaciones que requieren intercambiar,

etc. Pero cada proyecto requerir para su desarrollo un subconjunto de

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

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

dicho proyecto.

MOTOR DE COLABORACIN DE HERRAMIENTAS (MCH)

Herramientas

Especialistas

. . .

. . .

. . . Interfaces

MOTOR DE COLABORACIN DE MODELOS(MCM)

MOTOR DE COLABORACIN DE HERRAMIENTAS (MCH)

Herramientas

Especialistas

. . .

. . .

. . . Interfaces

MOTOR DE COLABORACIN DE MODELOS(MCM)

Figura 3-1. Estructura del entorno multidisciplinar

La capa ms externa del MCH debe resolver los interfaces a las herramientas

particulares, as como al coordinador (que configura el funcionamiento del entorno

para la gestin de cada proyecto).

Pg. 3-7


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

han sido mencionados, ms la novedad de la entidad DIRECTOR, ncleo del MCM.

En este componente se centralizan todas las actividades de integracin:

Control del proceso de desarrollo. En funcin de la informacin aportada por el coordinador se configurar el proceso y el DIRECTOR obligar a seguir las fases

marcadas.

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

Control de la trazabilidad, ntimamente ligado al proceso SW seguido.

Comprobacin global de errores, coherencias e integridad de la informacin.

DIRECTOR

InterfazConfig

Metadatos

Modelos de Integracin

Interfaz herramientas

Repositorios

MOTOR DE MOTOR DE COLABORACIN COLABORACIN

DE DE HERRAMIENTAS HERRAMIENTAS

(MCH)(MCH)

Coordinador

Especialistas

MOTOR DE MOTOR DE COLABORACIN COLABORACIN

DE MODELOS DE MODELOS (MCM)(MCM)

Figura 3-2. Componentes del MCH.

En la Figura 3-2 se puede apreciar cmo quedan los componentes del entorno con

la inclusin del DIRECTOR y la expresin explcita de los modelos de interaccin

para su manipulacin. Adems, se identifican dos roles de usuarios del entorno:

Coordinador de proyecto. Es quien impone al DIRECTOR, a travs de un interfaz de configuracin, las pautas a seguir en el uso de las herramientas

externas. Tiene que conocer el funcionamiento del MCH para configurarlo.

Define el conjunto concreto de herramientas a usar, un estilo de

arquitectura o metodologa de tiempo real determinada, protocolos de

comunicacin para la distribucin del control, un determinado proceso de

SW, etc. Estas decisiones, que determinarn las sinergias e

incompatibilidades que entran en juego, sirven para configurar el mdulo

Pg. 3-8


DIRECTOR. Toda esta informacin se emplear para coordinar todo el

entorno a lo largo de la vida del proyecto.

Especialista. Usuario final de cada una de las herramientas integradas. Hace uso de una herramienta bien conocida a partir de la informacin que le

facilita el entorno y de las pautas indicadas por el coordinador.

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

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

cada bloque en el captulo siguiente.

Pg. 3-9


Pg. 3-10


333...222 NNNIIIVVVEEELLLEEESSS DDDEEE IIINNNTTTEEEGGGRRRAAACCCIIINNN

Sobre lo que se entiende por integracin y las tcnicas disponibles para

lograrla a diferentes niveles.

Una vez establecido que las diferentes herramientas del entorno se integrarn

gracias a un Motor de Colaboracin de Herramientas (MCH) externo que gue el

proceso, cabe preguntarse qu tcnicas son las ms apropiadas para que el MCH

logre ese propsito de integracin.

Dado un conjunto de aplicaciones autnomas, cada una ejecutndose en su propio

contexto, la interaccin entre ellas se consigue si:

1. Existe una conexin fsica y un protocolo de comunicacin para que los datos fluyan entre los contextos de ejecucin de las aplicaciones. Actualmente, la

omnipresencia de internet con sus protocolos TCP/IP hace que sea la opcin

ms estndar para el intercambio de informacin entre dos aplicaciones

cualesquiera independientemente de su ubicacin.

2. Existe un acuerdo en el formato de los datos para su intercambio (texto ASCII, XML, representacin en memoria, chorro de bits). Por las razones

aducidas en el captulo anterior, XML se perfila como el formato ms

estndar, universal y de amplia aceptacin.

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

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

5. Existe un acuerdo en el significado que se da a los datos, lo que se espera de ellos, las relaciones que se establecen, el procesado que se les dar.

6. Existe un acuerdo en la relacin o manera de mantener la coherencia entre cualesquiera dos datos de dos herramientas diferentes pero con una relacin

semntica conocida.

7. Existe un acuerdo en los interfaces que cada aplicacin ofrece para la entrada y salida de datos

Los puntos 3, 4 y 5 hacen referencia a un acuerdo en cuanto a la gramtica

empleada, que como se ver, tiene que reflejar las peculiaridades de cada campo

de aplicacin pero manteniendo un ncleo comn a todas las dems. Para lograr

una solucin abierta y flexible, los puntos 6 y 7 conviene resolverlos de forma

Pg. 3-11


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

largo de este apartado.

En definitiva, se trata de llegar a acuerdos entre las partes implicadas, pero estos

acuerdos pueden ser de muy diversa naturaleza:

Acuerdos tcitos o explcitos. En ocasiones, se siguen acuerdos no escritos para hacer que se entiendan dos aplicaciones. En este trabajo se intenta

hacer explcito cualquier acuerdo porque esto es necesario para poder

modificar los trminos del acuerdo o para generalizarlo y lograr la

interaccin con otras aplicaciones cualesquiera.

Acuerdos punto a punto o genricos. Para comunicar dos aplicaciones basta con ponerse de acuerdo entre ellas, pero para lograr comunicar un nmero

indeterminado de aplicaciones no definidas de antemano, es necesario

imponer unas normas genricas que permitan interactuar a toda aplicacin

que las cumpla.

La propia interaccin entre las aplicaciones puede ser manual o guiada. Es decir,

dirigida a su libre albedro por el usuario (que indica en qu momento invocar una

aplicacin y con qu datos trabajar) o conducida por una entidad directora que siga

unas reglas prefijadas y regule los pasos a seguir, los datos a emplear y la

coherencia de todo el proceso. Como ya se ha descrito, los procesos y metodologas

para el desarrollo de SW requieren de una regulacin de las fases de su ciclo de

vida que aconseja una interaccin guiada. Por ello se propone que sea llevada a

cabo por la entidad DIRECTOR.

Una vez que las aplicaciones son capaces de interactuar (porque se han resuelto de

alguna manera los 7 puntos anteriores) se pueden definir diferentes niveles de

integracin:

Aplicaciones integrables. Por cumplir todos los requisitos para interactuar se puede escribir un SW que las integre.

Aplicaciones integradas entre tiempos de ejecucin. Cada aplicacin funciona segn sus propios tiempos pero los resultados que se obtienen al

terminar su uso se sincronizan con la informacin que ya exista. Por cada

uso de una aplicacin se comprobar la coherencia de los resultados con

todo lo anterior.

Aplicaciones integradas en tiempo de ejecucin. En el propio tiempo de ejecucin, una aplicacin es capaz de comunicase e interactuar con otras.

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

aadiendo las siguientes:

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

Pg. 3-12


La informacin a intercambiar entre herramientas y MCH se expresar en formato XML. Siendo as, lo ms lgico es que los repositorios tambin

almacenen la informacin en este formato.

Se definirn gramticas XML ajustadas a las necesidades de cada uno de los dominios: Ingeniera de Control (IC), Sistemas Distribuidos (SD), Sistemas de

Tiempo Real (STR) e Ingeniera del SW (IS). De este modo, la informacin

intercambiada entre una determinada herramienta y el MCH se expresar

siempre en la gramtica propia de su dominio.

El DIRECTOR llevar a cabo una integracin entre tiempos de ejecucin, es decir, se encargar de sincronizar la informacin global cada vez que se

reporten resultados desde alguna de las herramientas.

Los acuerdos necesarios para la integracin de herramientas se hacen genricos ya que hacen referencia a las interacciones entre los diferentes

dominios especficos y no a la existente entre herramientas concretas. Estos

acuerdos se engloban en un conjunto de Modelos de Dominios que estarn

ntimamente ligados a las Gramticas de Dominio.

Los acuerdos se hacen explcitos porque se expresan en forma de modelos y gramticas modificables, y por tanto extensibles.

La Figura 3-16 muestra como queda el MCH con estas aportaciones. El DIRECTOR

lleva la iniciativa y usa los servicios que le ofrecen las aplicaciones de forma

coordinada y coherente, basndose en los modelos y gramticas de dominio.

Pg. 3-13


InterfazConfig

Metadatos

ModelosDominios

Interfaz Herramientas

RepositoriosXML

Informacin XML sobre conexiones TCP/IP

GramticasXML Dominios

DIRECTOR

Gramtica de dominio comn para diferentes herramientas

Informacin en la gramtica XML de cada dominio

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

IC STR ISIC SD

InterfazConfig

Metadatos

ModelosDominios

Interfaz Herramientas

RepositoriosXML

Informacin XML sobre conexiones TCP/IP

GramticasXML Dominios

DIRECTOR

Gramtica de dominio comn para diferentes herramientas

Informacin en la gramtica XML de cada dominio

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

IC STR ISIC SD

Figura 3-3. Estructura del MCH.

En los siguientes apartados se presentarn algunas tcnicas adecuadas para la

implementacin de cada una de las partes de este esquema. Concretamente, y por

orden de aparicin de los apartados, se describirn soluciones para los bloques de

Gramticas (3.3 Integracin de Gramticas), Modelos de Dominio (3.4 Integracin

de Modelos), DIRECTOR (3.5 Integracin de Tcnicas para Desarrollo de SW),

Repositorio (3.6 Integracin de Conocimiento) e Interfaz de Herramientas (3.7

Integracin de Aplicaciones).

Pg. 3-14


333...333 IIINNNTTTEEEGGGRRRAAACCCIIINNN DDDEEE GGGRRRAAAMMMTTTIIICCCAAASSS

Sobre los niveles de servicio que puede implementar una gramtica y el

grado de compatibilidad entre gramticas distintas.

Para que varias personas se puedan comunicar y se entiendan entre s, es

necesario que empleen el mismo lenguaje. Del mismo modo, para que puedan

comunicarse entre s un conjunto de herramientas deben expresar, hasta cierto

punto, de la misma forma aquellas informaciones que pretendan intercambiar. La

solucin podra ser la creacin de un lenguaje comn, lo suficientemente rico y

extenso como para cumplir dos requisitos:

El lenguaje debe poder describir la informacin que manejen todas las herramientas a integrar.

El lenguaje debe poder representar todas las relaciones cruzadas entre informaciones de diferentes herramientas.

Esta solucin permitira importar y exportar toda informacin entre herramientas,

siempre que estuviera expresada en ese lenguaje. El problema surgira cada vez

que se pretenda integrar una nueva herramienta no considerada en un principio. Si

el lenguaje comn no fuera capaz de expresar algn tipo de informacin manejada

por la nueva herramienta, sera necesaria su modificacin y ampliacin.

Para ganar flexibilidad y generalidad en la solucin, conviene usar un lenguaje ms

abstracto en el que se asuman slo unos pocos elementos comunes a la

informacin de todas las herramientas que pretendan ser integradas.

Se va a profundizar a continuacin en un proyecto que trabaja en esta lnea de

investigacin, el GSRC Semantics Project.

Pg. 3-15


33..33..11 GGSSRRCC SSEEMMAANNTTIICCSS PPRROOJJEECCTT

Gigascale Silicon Research Center (http://www.gigascale.org/) es una entidad que

ana los esfuerzos de multitud de grupos de investigacin para el diseo y test de

sistemas empotrados.

Uno de sus proyectos es el GSRC Semantics Project

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

de herramientas para el diseo de sistemas.

Identifican el mismo problema que se ha descrito en el primer captulo de esta

memoria, es decir, la necesidad de enfocar un mismo sistema de diferentes formas

para tratar diferentes problemas y la dificultad de conseguir que los cambios

producidos en uno de estos enfoques sigan siendo coherentes en los dems. Tal y

como muestra la Figura 3-4, se pueden obtener mltiples facetas de un sistema al

proyectarlo respecto a diferentes ejes o puntos de vista pero si se modifica una de

esas facetas hay que conseguir que siga siendo coherente con las dems. Por otra

parte, tambin es deseable poder manejar diferentes niveles de abstraccin para

cada una de las facetas (Figura 3-5).

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

Estas facetas se pueden identificar con las representaciones del sistema de acuerdo

a diferentes herramientas y lograr la coherencia entre las mismas sera lo mismo

que conseguir interoperatividad entre las herramientas. Para lograr esta

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

para todas, si no que intentan identificar el uso de ciertos elementos comunes y

formalizarlos para establecer la base comn a todas las herramientas. De este

modo, definen modelos sintcticos y semnticos para el diseo de sistemas

basndose en el uso de componentes, su interaccin y su composicin (Lee 2000).

Pg. 3-16


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

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

propiedades ortogonales. El tratamiento por separado de las mismas permite varios

niveles de compatibilidad. La definicin de un lenguaje puede dividirse en cinco

partes (servicios) agrupadas en dos bloques:

Estructura lgica:

Sintaxis abstracta. Define cmo un diseo puede dividirse en componentes interconectados. El conjunto de componentes y relaciones que

pueden aparecer en un diseo conforman una sintaxis abstracta.

Sintaxis concreta, notacin. Define cmo un diseo puede ser representado y manipulado en un formato persistente y usable por el

ordenador (XML, APIs, fichero ASCII, grfico,). Pueden existir mltiples

sintaxis concretas derivadas de una nica sintaxis abstracta.

Transformaciones sintcticas. Un conjunto de operaciones (tanto estticas como dinmicas) permiten transformar un diseo en otro.

Significado:

Sistema de tipos. Regulan los datos compartidos por los componentes y aseguran que se cumplen los requisitos que los componentes imponen a

esos datos. El polimorfismo es una cualidad conveniente para dar

generalidad a los diseos.

Semnticas (de componentes y de interaccin). Da significado a las caractersticas de cada componente y a sus conexiones con otros.

Un determinado diseo se representa con un lenguaje concreto que incluye los

cinco servicios mencionados. Sin embargo, las herramientas que se utilizan para

manejar ese modelo no tienen porque ser conscientes de todas las partes del

lenguaje. Habr herramientas que soporten slo alguna de las partes del lenguaje.

Pg. 3-17


Por ejemplo, un visualizador grfico que muestre las relaciones entre componentes

no necesita conocer la semntica ni los tipos (le basta con conocer la sintaxis

abstracta), mientras que un motor de inferencia de tipos necesita conocer el

sistema de tipos adems de la sintaxis abstracta.

En base a estos conceptos se puede clasificar la interoperatividad entre

herramientas a diferentes niveles:

1. Sintaxis abstracta compatible. Es posible escribir SW ad hoc que convierta datos de una herramienta en datos utilizables en otra.

2. Sintaxis concreta compatible. Una herramienta puede leer datos en el formato persistente de otra (ficheros externos) sin necesidad de escribir SW

especial.

3. Transformaciones sintcticas compatibles. Es posible generar automticamente datos de entrada para una herramienta a partir de los

resultados de otra.

4. Sistema de tipos compatible. Intercambio automtico de modelos de datos completos entre herramientas.

5. Semnticas compatibles. Las herramientas pueden intercambiar datos dinmicamente, en tiempo de ejecucin.

Cuando se busca la interoperatividad entre un conjunto lo suficientemente amplio y

diverso de herramientas de diseo, enseguida es evidente que no basta con un

nico formato estndar para representar adecuadamente una sintaxis y semntica

comn para todas. Existe una variedad de modelos semnticos para sistemas

basados en componentes y cada uno tiene sus ventajas y su campo de aplicacin.

Por ello, se busca un acuerdo en lo ms bsico, la sintaxis abstracta. Una sintaxis

abstracta comn para herramientas de diseo de sistemas debe ser capaz de

describir listas de conectividad, diagramas de transicin de estados, diagramas de

bloques, modelos de objetos y estructuras grficas, adems de permitir el uso

extensivo de la jerarqua para lograr escalabilidad. stas son las caractersticas que

rene la sintaxis abstracta GSRC.

Resumen de las caractersticas del proyecto GSRC:

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

Sintaxis abstracta. Definicin de componentes y posibles relaciones entre ellos, capacidades de jerarqua, conectividad e instanciacin de clases.

Sintaxis concreta. MoML es una sintaxis concreta XML para la sintaxis abstracta de GSRC. MoML no aade significado al modelo, en su lugar,

permite aadir un director al modelo. El director definir la semntica de las

conexiones pero para MoML no es ms que la referencia a una instancia que

cargar el cargador de clases.

Pg. 3-18


Transformaciones sintcticas. Definicin de las posibles operaciones en los modelos (creacin de puertos, relaciones, enlaces, entidades, etc).

Aplicaciones como los editores visuales de modelos o las herramientas de

instanciacin hacen uso de las mismas.

Sistemas de tipos. Los propios de cada dominio para permitir el uso de interfaces polimrficos que evitan la necesidad de escribir adaptadores de

protocolo entre interfaces rgidos predefinidos.

Semnticas de componentes y de interaccin. Definicin de todos los significados posibles de los componentes: estados, procesos, threads,

ecuaciones diferenciales, requisitos, objetos, etc. Sobre esta ontologa de

componentes definida para cada dominio se especifican las semnticas de

interaccin entre componentes.

Beneficios de la ortogonalizacin:

Diferentes niveles de interoperatividad

Terminologa independiente de sintaxis concreta

Se enfatizan frameworks en lugar de lenguajes

Pg. 3-19


333...444 IIINNNTTTEEEGGGRRRAAACCCIIINNN DDDEEE MMMOOODDDEEELLLOOOSSS

Sobre la adopcin del paradigma de modelado 4+1 y los estndares MDA

y MOF en el entorno multidisciplinar.

Se aprecia un claro paralelismo entre el entorno multidisciplinar y la estructura

4+1 descrita en el Estado del Arte. En ambos casos hay un especialista detrs de

cada una de las vistas, las vistas sirven diferentes propsitos y existe un orden

lgico de uso:

Vista Ingeniera de Control. El ingeniero de control especifica el sistema en base a la funcionalidad que pretende obtener y a la interaccin de los

controladores con el proceso.

Vista Sistema Distribuido. El especialista en redes de comunicacin parte de la informacin anterior para distribuir los controladores, sensores y actuadores en

diferentes nodos dentro de una determinada topologa de red. Adems,

especifica las caractersticas de los enlaces de comunicacin.

Vista Sistema de Tiempo Real. El ingeniero de tiempo real parte de las vistas anteriores y establece un reparto adecuado de los recursos locales a cada nodo

para cumplir con los requisitos temporales que se imponen.

Vista de Ingeniera del SW. El ingeniero de SW hereda una especificacin completa y vlida del sistema y realiza las labores necesarias para la

integracin del cdigo y la generacin de documentacin.

Desde el punto de vista del MDA se puede asemejar la vista de Sistemas de Control

al PIM (Platform Independent Model) y el resto de las vistas al PSM (Platform

Specific Model). Esto es as porque la descripcin funcional realizada desde el punto

de vista de control no debe depender de ninguna caracterstica propia de

plataforma y debe iniciar el ciclo de desarrollo porque el objetivo prioritario del

sistema ser el de resolver algn problema de control. Las otras tres vistas van

completando esa descripcin inicial y van aadiendo todos los detalles propios de la

plataforma, lo que permite generar el cdigo y documentacin de la

implementacin final.

Aplicando las pautas de modelado de MOF para formalizar cada una de las vistas

del entorno multidisciplinar, se pueden distinguir los siguientes niveles de

abstraccin:

M3. Meta-metamodelo para la definicin de un lenguaje basado en componentes y conectores que permita describir sistemas con jerarqua.

Este nivel toma la forma de un schema XML genrico.

Pg. 3-20


M2. Metamodelo de cada dominio especfico. A travs de mecanismos de herencia se extiende M3 particularizando el schema genrico a las

necesidades expresivas de un rea concreta. Por tanto, se crearn cuatro

schemas especficos para dar soporte a los cuatro metamodelos

M1. Modelo del sistema en desarrollo. Se especifican las caractersticas del sistema creando instancias para los cuatro schemas anteriores.

M0. Objetos de Dominio son los componentes o unidades mnimas de modelado. Difieren en cada uno de los dominios.

Esta jerarqua formal de abstraccin vertical debe acompaarse de mecanismos

para regular el flujo horizontal de informacin y la validacin horizontal de

implicaciones entre vistas. Estas necesidades se cubrirn de la siguiente forma:

Flujo horizontal de informacin: XSLT habilitar las transformaciones a nivel de modelo para sincronizar las descripciones. Es decir, para extraer de un

modelo las informaciones que incumben tambin a otro y generar la versin

bsica del segundo modelo, versin que se ir completando despus con las

aportaciones de las herramientas de dominio. Este mecanismo de

sincronizacin entre modelos de diferentes dominios se facilita porque todos los

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

Validacin horizontal de implicaciones entre vistas: Adems de la formalizacin (basada en schemas) que se hace dentro de cada dominio, es

necesario formalizar las relaciones entre metamodelos para realizar

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

mecanismo diferente al de los schemas XML porque son especificaciones en

forma de reglas ms que especificaciones sintcticas o gramaticales. Por tanto,

habr que completar la formalizacin vertical de cada dominio con un Lenguaje

para la Especificacin de Reglas (LER) que permita expresar reglas cruzadas de

validacin horizontal, involucrando a varios dominios.

La adopcin de una estructura de modelado acorde con MOF permitir

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

podrn expresar formalmente los cuatro niveles en MOF-UML, derivando cada nivel

del anterior. A partir de este punto, se podra comprobar la coherencia

directamente en UML, realizar anlisis, simulaciones, etc. Tambin se podran

generar automticamente con XMI los schemas que dan soporte a los metamodelos

y exportar o importar las propias instancias, generar automticamente las hojas de

estilo XSLT que implementan las transformaciones automticas entre modelos,

generar automticamente las reglas de validacin horizontal, generar cdigo para el

manejo de las estructuras de datos definidas, usar CWM como soporte formal para

los repositorios de schemas y de documentos XML, etc.

Por ltimo, tambin se pueden aplicar los conceptos de PIM y PSM de MDA al propio

entorno multidisciplinar, adems de a las vistas manejadas. Se trata de un entorno

genrico e independiente de las herramientas, que se puede denotar como TIM

Pg. 3-21


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

concretas para su uso en un determinado proyecto se constituye un TSM (Tool

Specific Model). Es decir, el funcionamiento interno del entorno se fundamenta en

la abstraccin de las vistas y sus interacciones (TIM), pero las herramientas

concretas de desarrollo que se vayan a emplear deben engancharse a los modelos

formales para crear una instancia concreta y especfica del entorno (TSM) para un

determinado proyecto.

Pg. 3-22


333...555 IIINNNTTTEEEGGGRRRAAACCCIIINNN DDDEEE TTTCCCNNNIIICCCAAASSS PPPAAARRRAAA

DDDEEESSSAAARRRRRROOOLLLLLLOOO DDDEEE SSSWWW

Sobre la manera de reflejar en el cdigo final las especificaciones o

requisitos provenientes de diferentes especialistas.

Tal y como se mencionaba en el primer captulo de esta memoria, la disciplina de

Ingeniera del SW, de alguna forma, envuelve a las dems reas involucradas, en el

sentido de que el Proceso de creacin de SW debe pasar por unas fases fijadas de

antemano y seguir unas pautas que aseguren el logro de requisitos genricos como

calidad de SW, reutilizacin de componentes, trazabilidad, mantenimiento, etc.

A este respecto, el entorno multidisciplinar debe conseguir que el proceso de

desarrollo de SW respete los diferentes enfoques presentes en el desarrollo de

SCDTR. De modo que la generacin de SW responda a varios criterios, respete las

diferentes especificaciones y las diferentes restricciones impuestas por los modelos

implicados.

Hay varias aproximaciones tericas para la consecucin de este objetivo y las

siguientes pginas intentan esbozar en qu forma tratan el problema. La cuestin

central sigue siendo la integracin de informacin, pero en este caso la informacin

proveniente de mltiples dominios se pretende condensar en un nico SW final.

Pg. 3-23


33..55..11 MMTTOODDOOSS FFOORRMMAALLEESS

La combinacin de diagramas, texto, tablas y notaciones sencillas que se emplean

en muchos mtodos de ingeniera del SW tienen poco rigor matemtico y a veces

son ambiguas o incompletas. Las sintaxis y semnticas formales se espera que

tengan un gran impacto en la concepcin de la ingeniera del SW de los prximos

aos. Este auge vendr de la mano de la dependencia cada vez mayor de las

herramientas de ayuda a lo largo del proceso SW. Un proceso guiado por diferentes

herramientas automticas debe ser necesariamente formal. Por todo ello, es

importante el conocimiento del fundamento de los mtodos formales para valorar

de qu manera conviene emplearlos para el desarrollo de SW. Este es el objetivo de

las siguientes lneas que resumen el enfoque de Doorfman y Thayer (1996).

En la dcada de los 70 la aparicin del concepto de programacin estructurada

supuso una revolucin al llegarse a un acuerdo en el seguimiento de ciertos

preceptos para el diseo de programas. Los lenguajes imperativos actuales son

herederos de este tipo de programacin. Sin embargo, este acuerdo no es

definitivo, se abre un debate sobre la metodologa de programacin, con continuos

cambios: desarrollo top-down, descomposicin modular, abstraccin de datos,

diseo orientado a objetos, etc.

En cualquier caso, un denominador comn de estas metodologas es que mantienen

la misma nocin tradicional de programacin. Segn sta, la labor del ingeniero de

SW es desarrollar cdigo para indicar a una mquina fsica el camino hacia la

consecucin de un determinado resultado. La idiosincrasia de la mquina

(interfaces de usuario, libreras,) agregan complejidad, con el agravante de que

esta complejidad puede ser aadida en todos los niveles de abstraccin

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

velocidad y prestaciones de la mquina. Esto hace mucho ms difcil la fase de

validacin y deteccin de errores.

La nocin de los mtodos formales es la opuesta. Se traslada al ingeniero de HW,

diseador de lenguaje o escritor de compiladores la labor de proveer de cdigo

concreto para una mquina, y no a la inversa.

Originalmente conceba la mquina abstracta como una representacin de la

realidad fsica. Despus, en cambio, aprend a considerar la mquina abstracta

como la verdadera porque es la nica en la que podemos pensar. Es funcin de la

mquina fsica el suministrarnos un modelo que funcione, un modelo fsico

suficientemente preciso como para simular la verdadera mquina, la abstracta.

Sola ser labor del programa el instruir a los computadores, pero el propsito de los

computadores debe ser realmente la ejecucin de nuestros programas. (Dijkstra

1976)

En este sentido, la labor del ingeniero de SW debera ser producir modelos o

descripciones de un sistema para una mquina abstracta, con pruebas de que los

Pg. 3-24


modelos de menor nivel de abstraccin implementan correctamente los modelos de

alto nivel. Esto asegura una mayor calidad, y no slo capacidad para realizar

pruebas. Tal y como dice Dijkstra, el test demuestra la presencia de errores, no su

ausencia. Para poder entender y razonar los diseos, deben esconderse los detalles

de implementacin (SoC, Separation of Concerns). No se puede dejar que

cuestiones de microeficiencia dominen e influyan en el resultado final.

Un mtodo formal en desarrollo de SW es un mtodo que proporciona:

1. un lenguaje formal para describir los artefactos SW (especificaciones, diseos, cdigo fuente,)

2. mecanismos que permitan realizar pruebas formales sobre las propiedades del artefacto formalmente descrito

La propiedad comprobada suele ser que una implementacin es funcionalmente

correcta, es decir, cumple su especificacin. Entonces, o bien el lenguaje formal

empleado permite describir un sistema a dos niveles de abstraccin (especificacin

formal y posible implementacin), o bien se emplean dos lenguajes relacionados

para describir especificacin e implementacin respectivamente.

En ingeniera de SW, los mtodos formales son directamente aplicables durante las

fases de requisitos, diseo y codificacin y tienen importantes consecuencias para

el test y el mantenimiento. Estn entrelazados con modelos del ciclo de vida

alternativos a las aproximaciones clsicas y permiten un mayor control de la

trazabilidad.

Su aplicacin ms habitual se da en la fase de especificacin. Algunos mtodos

formales incluyen lenguajes de especificacin que permiten registrar precisa y

rigurosamente las caractersticas funcionales y no funcionales que se esperan

obtener de un sistema. Algunos ejemplos son: 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 mtodos pueden incluir lenguajes grficos como DFDs (Data Flow Diagrams)

redes de Petri.

La gran ventaja de la especificacin del sistema a travs de mtodos formales es la

capacidad inherente de realizar pruebas al producto final, de forma que se asegure

un comportamiento acorde con los requisitos. Las pruebas son muy difciles de

generar a posteriori, por ello, pruebas y programas deberan desarrollarse en

paralelo. Por ejemplo, todo lenguaje de programacin es, por definicin, un

lenguaje formal, ya que usan una notacin formal (BNF) para definir su sintaxis.

Esto asegura la capacidad de realizar pruebas al cdigo fuente para comprobar que

cumple con la sintaxis del lenguaje.

Pg. 3-25


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

cuenta:

Problema de requisitos.

Pueden usarse para verificar (probar que una implementacin satisface una

especificacin formal) que cada paso en el desarrollo del producto satisface los

requisitos impuestos en los pasos previos. Pero no es suficiente para validar un

sistema (probar que un producto satisface su misin operativa) porque tal y

como afirma Boehm (1981): no se puede ir de lo informal a lo formal por

mtodos formales. El problema es que no se puede probar que una

especificacin formal capture el entendimiento informal e intuitivo del sistema

por parte de un usuario. La especificacin es el contrato entre el usuario y el

desarrollador, y adems de ser formal, tiene que contener y describir todas las

caractersticas que el usuario espera obtener en el producto final.

Problema de implementacin fsica.

Los mtodos formales pueden verificar que una implementacin satisface su

especificacin cuando corre en una mquina abstracta ideal, pero no en

cualquier mquina fsica. Las pruebas formales explcitamente aslan los sitios

en que puede producirse el error. Concretamente, ser all donde se provea de

una mquina fsica para implementar a la abstracta, ya que las pruebas se

hacen suponiendo que la ejecucin se realizar en la mquina abstracta.

Requisitos de usuario

MTODOS FORMALES

Especificacin formal Diseo

Cdigo mquina abstracta

Cdigo mquina

fsica

Requisitos de usuario

MTODOS FORMALES



MTODOS FORMALES



Cdigo mquina

fsica

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

Estas limitaciones afectan precisamente al punto inicial y final del ciclo de vida (ver

Figura 3-6). Los mtodos formales pueden automatizar y verificar las transiciones

entre las fases internas del ciclo de vida (especificacin, diseo y generacin de

cdigo para mquina abstracta), pero existen incertidumbres en los saltos de lo

informal a lo formal, y de lo formal a lo informal respectivamente, al principio y al

final del proceso. Se investigan diversas formas de minimizar la magnitud de estos

saltos; por un lado el uso de lenguajes formales pero cercanos al entendimiento

del usuario para recoger requisitos o el empleo de especificaciones grficas con

formalismo inherente; por otro lado el empleo de estndares, HW, libreras y

compiladores certificados para asegurar su adherencia a la mquina abstracta

idealizada.

Pg. 3-26


Ni siquiera en todas las fases internas del ciclo de vida es siempre ventajoso el uso

de mtodos formales. Debe decidirse en qu fases y con qu objetivos emplearlos

para modular el grado de uso ms adecuado:

Uso puntual. En el desarrollo de algunos componentes se usan slo para la fase de diseo porque los productos requieren de una interaccin continua entre

especificacin e implementacin.

Uso generalizado. Se puede derivar todo el proceso a partir de unas especificaciones formales completas. Si todo parmetro o cambio que pueda

introducirse est recogido en las especificaciones, se podra generar el cdigo

final a partir de ellas. En este caso, se modificara la especificacin para generar

cualquier nueva versin. Esta visin sustituye a los programadores por un

conjunto inteligente de herramientas integradas dirigidas por mtodos formales

(McLean 1993).

Uso variable. Introduccin parcial de mtodos formales con nivel variable de formalidad y uso de verificacin informal. Es el caso del modelo de proceso de

sala limpia (Linger 1994).

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

indica qu debe decir una especificacin, mientras que un lenguaje determina cmo

pueden expresarse los conceptos de una especificacin. Algunos lenguajes soportan

ms de un mtodo, y la mayora de los mtodos pueden ser usados en varios

lenguajes de especificacin (Lamport 1989).

Los lenguajes de especificacin formal tienen un alfabeto de smbolos y reglas

gramaticales que definen frmulas de buena formacin. Estas reglas caracterizan el

dominio sintctico del lenguaje o cmo combinar los smbolos para obtener

expresiones, en principio, sin significado. El significado o interpretacin de la

frmula es parte de la semntica. El conjunto de objetos que componen el dominio

semntico del lenguaje (reglas que dictan qu objetos satisfacen la especificacin)

proveen al lenguaje de un modelo.

Una especificacin ser un conjunto de frmulas expresadas en el lenguaje

formal. Los objetos en el dominio semntico del lenguaje que satisfacen una

especificacin pueden ser varios. Por eso la especificacin est en un nivel de

abstraccin mayor que los objetos en el dominio semntico, permite abstraerse de

los detalles que distinguen diferentes implementaciones. Diferentes mtodos de

especificacin definidos sobre el mismo dominio semntico permiten especificar

diferentes aspectos de los objetos.

Todos estos conceptos pueden expresarse a travs de las matemticas, con la

ventaja de que se obtienen herramientas para razonamiento formal a partir de las

especificaciones, que pueden ser examinadas para ver si con consistentes y

completas.

En funcin de sus dominios semnticos, los lenguajes de especificacin pueden

clasificarse en:

Pg. 3-27


Lenguajes ADT (Abstract Data Type Specification). Especificacin de lgebras. Propiedades formales de un tipo de dato sin definir caractersticas

de implementacin. Ejemplos: Z, VDM, Larch.

Lenguajes de especificacin de procesos. Secuencias de estados, eventos, mquinas de estados. Ejemplo: CSP de Hoare

Lenguajes de programacin.

Los mtodos de especificacin se pueden clasificar en:

Operacionales, constructivos u orientados a modelo. La especificacin es una descripcin del sistema que proporciona un modelo. El comportamiento

de este modelo define el deseado en el sistema. Usar estructuras

matemticas abstractas como relaciones, funciones, conjuntos y secuencias.

Puede verse como un programa escrito en un lenguaje de muy alto nivel, ya

que se pasa de un conjunto de entradas a uno de salidas.

De definicin, declarativos u orientados a la propiedad. Mnimo conjunto de condiciones que debe satisfacer un sistema para ser funcionalmente

correcto. No se determina un modelo mecnico para llegar de las entradas a

las salidas. Mtodos algebraicos (las propiedades se expresan en forma de

ecuaciones) y axiomticos (clculo de predicados).

Como conclusin, los paradigmas de ciclos de vida que confen en la transformacin

automtica desde especificacin hasta cdigo ejecutable son necesariamente

formales (por ejemplo, el ciclo de vida de sala limpia). El desarrollo de SW al

hacerse complejo se est volviendo cada vez ms dependiente de las herramientas,

y stas cada vez usan ms los mtodos formales. Entre las tcnicas que hacen uso

de ellos cabe mencionar: prototipado rpido, diseo orientado a objetos,

programacin estructurada e inspecciones formales.

El uso de los mtodos formales se est generalizado a pequea escala pero

tpicamente en organizaciones con nivel 3 o superior en el modelo de madurez del

proceso SW del SEI. Es difcil llevarlos hasta el ltimo extremo pero se pueden

implantar gradualmente e ir integrndose en el proceso habitual de las empresas.

Pg. 3-28


33..55..22 SSEEPPAARRAACCIINN MMUULLTTIIDDIIMMEENNSSIIOONNAALL DDEE PPRROOPPSSIITTOOSS

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

de la ingeniera del SW en general y del desarrollo de SW orientado a objeto en

particular. El uso adecuado de la orientacin a objeto, resuelve una parte, pero no

toda la complejidad asociada a los requisitos que se le imponen a los sistemas SW

actuales. Por ejemplo, el cambio en la representacin de un dato en un sistema

orientado a objeto, si se hace utilizando patrones de diseo o subclases, no tiene

porqu ser traumtica para el sistema. Sin embargo, aadir una nueva

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

la nueva funcionalidad se disemina en diferentes clases y se mezcla con cdigo de

otras clases, aumentando la probabilidad de error y la complejidad y dificultando la

comprensin del cdigo.

En resumen, parece necesario el uso de tcnicas complementarias a las propias de

orientacin a objeto. Dependiendo del propsito perseguido se requiere la

descomposicin del sistema en diferentes tipos de mdulos: clases,

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

MDSOC (Multi-Dimensional Separation Of Concerns) intenta llevar esta filosofa

hasta sus ltimas consecuencias y se plantea como objetivos:

Tratamiento del sistema desde el punto de vista de un nmero indeterminado de propsitos mltiples, arbitrarios y no prefijados. Los

propsitos, criterios o problemas varan en el tiempo y son sensibles al

contexto (diferentes actividades del desarrollo, fases del ciclo de vida,

desarrolladores). Por ello cualquier criterio debera ser posible para la

descomposicin.

Encapsulado simultneo de todos los propsitos para un sistema. El desarrollador no elige uno o varios de ellos para su cdigo, todos pueden

coexistir.

Gestin de propsitos interrelacionados o solapados. Pocos propsitos sern ortogonales, se debern gestionar las relaciones entre ellos porque

normalmente estarn presentes varios a la vez y puede ser que se solapen o

interfieran.

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

modularizacin y una integracin de artefactos SW basada en un nmero

indeterminado de criterios. Adems, soporta la remodularizacin para encapsular

nuevos criterios en cualquier momento. Esto conlleva los siguientes beneficios:

Pg. 3-29


9 Reduccin del impacto de cambios. Los cambios en el SW son aditivos, no intrusivos. Se logra mejorar el comportamiento global del sistema sin

perjudicar lo anteriormente construido.

9 Ms sencilla comprensin del sistema y reduccin de la complejidad. 9 Adaptabilidad. 9 Mantenimiento ms sencillo. 9 Personalizacin y configuracin acorde a las necesidades del usuario. 9 Reutilizacin de componentes. 9 Mejor trazabilidad. 9 Integracin de componentes simplificada, uso de COTS 9 SW ms rpido, seguro, barato y de mejor calidad.

IBM ha trabajado en MDSOC y ha creado su aproximacin particular denominada

Hyperspaces (www.research.ibm.com/hyperspace/). Concretamente, proporciona

soporte para hiperespacios Java a travs de Hyper/J

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

con clases Java y un fichero de control especifica cmo mapear los miembros Java

a propsitos, qu propsitos tener en cuenta y qu relaciones de composicin

implementar (Ossher y Tarr 2000).

Pg. 3-30


33..55..33 DDEESSAARRRROOLLLLOO DDEE SSWW DDIIRRIIGGIIDDOO AA DDOOMMIINNIIOO

El Desarrollo Dirigido a Dominio (Domain-Driven Development, 3D) agrupa a un

conjunto de tecnologas que tienen en comn la nocin abstracta de dominio e

intentan que cada una de las partes del SW desarrollado emane desde ese nivel. Su

inters actual se ve refrendado al ser uno de los tracks de OOPSALA (Conference on

Object-Oriented Programming, Systems, Languages And Applications). Tal y como

se dice en el avance del programa de esta conferencia, el Desarrollo Dirigido a

Dominio (http://domaindrivendesign.org/) cubre un espectro de tecnologas

emergentes entre las que se pueden destacar Model Driven Architecture (MDA),

Aspect-Oriented Modeling, Generative Programming e Intentional Programming.

Todas ellas se centran en alinear el cdigo y el problema de dominio de forma ms

certera. Elevan la expresin del diseo e implementacin, eliminan detalles, aslan

el SW de la deriva tecnolgica, ayudan a balancear entre la personalizacin y la

generalidad del SW y permiten mayores niveles de automatizacin.

MDA ya ha sido analizado en solitario debido a su importante peso especfico. A

continuacin, se resumen los principios de otras tecnologas hermanas.

Aspect Oriented Software Development (http://aosd.net/). Los mecanismos

para definir y componer abstracciones son elementos esenciales de todo lenguaje

de programacin El estilo de diseo soportado por los mecanismos de abstraccin

de la mayora de los lenguajes de programacin comunes es el de dividir un

sistema en componentes parametrizables que pueden ser llamados para ejecutar

una funcionalidad. Pero muchos sistemas tienen propiedades que no

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

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

monitorizacin, optimizacin del rendimiento, replicacin, coordinacin,

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

gestin de memoria o requisitos de tiempo real. Todas estas propiedades tienden a

afectar a grupos de componentes funcionales y no se limitan a uno solo. El

desarrollo orientado a aspectos permite modularizar estos problemas. Intenta

abstraer caractersticas comunes a muchas partes del cdigo, y por tanto, mejorar

la calidad del SW, ms all de los simples mdulos funcionales.

Mientras que estos aspectos pueden ser pensados y analizados de forma

relativamente separada a la funcionalidad bsica, su programacin, empleando los

habituales lenguajes orientados a componentes, tiende a dispersar estos aspectos a

lo largo de diferentes partes del cdigo. Como resultado, el cdigo se convierte en

una maraa de instrucciones con diferentes propsitos.

Este fenmeno de maraa es el origen de parte de la complejidad en los sistemas

SW actuales. Por ello, algunos investigadores han empezado a trabajar en

aproximaciones que permitan a los programadores expresar cada uno de los

Pg. 3-31


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

esas descripciones separadas en la forma de un ejecutable final.

AspectJ (http://eclipse.org/aspectj/) es una extensin orientada a aspectos para el

lenguaje Java. Proporciona una modularizacin limpia para problemas

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

clase.

Generative Programming (www.generative-programming.org). Se trata de un

conjunto de tcnicas que permiten construir los programas automticamente a

partir de programas especficos de dominio de menor tamao (Czarnecki y Ulrich

2000). Extiende los beneficios de la automatizacin al desarrollo SW.

Intentional Programming. Una tcnica que permite a los programas ser escritos

y vistos en una variedad de notaciones diferentes. Tambin permite la integracin

sin problemas de programas de dominio especfico y programas de propsito

general. Fue desarrollado por el equipo de Charles Simonyi (Simonyi 1995)

mientras trabajaba en Microsoft.

Transformational Programming. Tcnica que produce programas a partir de

especificaciones de alto nivel o especficas de dominio. El programa es derivado de

una especificacin formal empleando pasos de transformacin manejados y

controlados que garantizan que el producto final cumpla con las especificaciones

iniciales (Bauer et al 1989).

Adems de las resumidas hasta aqu, existen otras tcnicas o metodologas que

matizando ligeramente la forma, tratan el mismo problema de fondo. En la

bibliografa se entremezclan y confunden trminos como: Subject-Oriented

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

Component-Based Software Engineering,

Pg. 3-32


33..55..44 GGEENNEERRAACCIINN DDEE PPRROOGGRRAAMMAASS CCOONN XXSSLLTT

Los Generadores de Programa son un resultado de la aplicacin de tcnicas de

Ingeniera de Dominio. sta se centra en generar familias de aplicaciones (no slo

una) y engloba dos procesos (Cleaveland 2001):

1. Anlisis de Dominio. Se determina la parte comn y la que vara en el conjunto de las aplicaciones presentes en un domino en estudio.

a. Parte comn. Recoge todas las caractersticas que se repiten en todas y cada una de las aplicaciones en estudio. Un conjunto amplio

de caractersticas comunes aade mayor conocimiento de un dominio

pero restringe el conjunto de aplicaciones de esa familia. El resultado

de este estudio supondr la clave para la reutilizacin del SW.

b. Variabilidades. Identifican lo que es diferente entre los programas de una misma familia. Un lenguaje de especificacin debe ser capaz de

recogerlas, y en cada caso, hacer llegar al Generador de Programas

la informacin de configuracin necesaria. El Generador de

Programas automatiza la fase de generacin de cdigo a partir del

conjunto de especificaciones que fija las variabilidades y las

parametriza para un caso concreto.

2. Implementacin de Dominio. Se crean herramientas capaces de generar aplicaciones para ese dominio a partir de la descripcin de las variabilidades.

La aplicacin de estas tcnicas conducir la construccin de Generadores de

Programas y el diseo de los repositorios de componentes. Es evidente la necesidad

de un diseo conjunto de ambos sistemas puesto que el Generador har uso de

componentes antiguos o crear componentes nuevos, segn el caso. Y es que la

herramienta de generacin de cdigo puede utilizarse con alguno o varios de los

siguientes propsitos:

Creacin del esqueleto bsico de un proyecto o componente de una aplicacin sobre el que el ingeniero de SW trabajar manualmente. Por ejemplo,

generacin de IDL CORBA.

Generacin de una funcionalidad especfica dentro de una aplicacin (componente). Posteriormente el desarrollador podr tratar el resultado como

una caja negra que pueda ser incorporada en diferentes aplicaciones sin

cambios. Es imprescindible tener bien definidos los interfaces entre los

diferentes componentes de la aplicacin.

Creacin de una aplicacin completa ensamblando componentes existentes. El generador de cdigo pega los trozos de aplicacin en base a unos

determinados parmetros.

Pg. 3-33


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

Orientada a Componentes, en la que se emplean como constructores necesarios los

componentes, interfaces, conectores y adaptadores:

Componente. Se puede definir como una unidad de composicin con interfaces especficos y contexto explcito. Puede ser desarrollado a propsito

para una aplicacin o reutilizado tras capturarlo en un repositorio y

parametrizarlo. Existe una discusin sobre la distincin de componentes y

objetos, concretamente, UML 2.0 promete mejor soporte para los componentes

de lo que ofrece la versin actual. Un componente debe minimizar las

asunciones (dependencias) hechas sobre el entorno y los recursos y objetos

que lo rodean. Se llaman dependencias porque el componente depende de su

existencia. No se pueden eliminar todas las dependencias ya que el interfaz de

un componente usa ciertos tipos que deben ser soportados por el entorno. Por

ello los componentes a menudo se desarrollan para un determinado modelo de

componentes (por ejemplo, JavaBean). Ejemplos de dependencias: variables

globales y recursos, tipos y mecanismos de comunicacin entre procesadores.

Interfaz. Es una interaccin entre un componente y otros elementos SW. Los interfaces se suelen dividir en exports (servicios provistos por el componente) e

imports (servicios requeridos por los componentes) y se suelen graficar como

puertos de entrada y salida.

Conector. Sern compatibles aquellas conexiones entre puertos import y export que tengan el mismo tipo. Puede haber conectores sncronos (se espera

hasta que vuelva la respuesta de la llamada) y asncronos (se hace la llamada

pero no se espera la respuesta).

Adaptadores de interfaz. Necesarios para convertir entre el tipo de una salida y el de una entrada a otro componente o para conectar una salida a

varias entradas

Tanto los lenguajes ADL (Architecture Description Language) como los MIL (Module

Interconnection Language) permiten representar componentes, conectores e

interfaces, y solucionar los flujos de informacin entre ellos a travs de

adaptadores para no perder la modularidad. Adems, estos lenguajes tienen en

cuenta mecanismos de comunicacin (para sistemas distribuidos), jerarqua

(combinacin de componentes para la construccin de otros), etc. XML es muy

bueno como base de un lenguaje MIL ADL.

Todo lo anterior plantea la generacin automtica como una labor compleja que

requiere de bastante estudio y formalizacin. De hecho, parece razonable plantear

la fase de generacin de cdigo como un subproceso diferenciado dentro del

proceso general de creacin de SW. Las compensaciones que conlleva este arduo

trabajo son las siguientes:

9 Toma de decisiones en el nivel de especificacin frente al de codificacin. Es ms fcil leer, escribir, editar, depurar y entender los sistemas en la fase de

Pg. 3-34


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

ms productivos que los de programacin.

9 Favorece el SoC (Separation Of Concerns) porque permite que diferentes profesionales con tareas concretas puedan colaborar en la especificacin y

dejar la fase de generacin de cdigo al Generador de Programas (y no a un

especialista concreto).

9 Desacopla especificacin (el qu) de implementacin (el cmo) porque esta ltima parte la realiza el Generador de Programas. Podrn realizarse

diferentes implementaciones, programas alternativos o variaciones de un

mismo tipo de programa (familias de programas) para una nica

especificacin sin ms que configurar adecuadamente el Generador.

9 Proceso automtico unificado para extraer, a partir de unas especificaciones comunes, varios productos: cdigo, documentacin del SW, documentacin

de usuario, pruebas y documentos de configuracin.

9 Correccin y coherencia del producto final. El programa generado no tendr errores cometidos en la fase de codificacin y se evitarn derivas respecto a

las especificaciones.

9 Mejora continua del rendimiento del SW con la aplicacin de las ltimas tcnicas por parte del Generador de Programas.

Varias de estas ventajas recuerdan a las que se mencionaban para el uso de

metodologas formales porque en ese caso tambin se intenta generar

automticamente el cdigo a partir de una especificacin formal completa.

Mientras que para los programas generados a mano debe facilitarse la legibilidad y

facilidad de modificacin del propio cdigo, para los programas generados

automticamente es importante la legibilidad y sencillez de modificacin de las

especificaciones a partir de las cuales se crea automticamente el cdigo. Este

objetivo est asegurado si dichas especificaciones estn expresadas en XML, como

es el caso que se plantea en esta tesis. Partiendo de unas especificaciones as, la

combinacin de XSLT (W3C 1999) y XPath (W3C 1999b) supone la manera natural

de implementar la generacin de cdigo porque:

9 Ambos son estndares abiertos. 9 Tienen funcionalidades complementarias; mientras XPath se usa para

identificar y seleccionar partes de un documento XML, XSLT habilita la

transformacin de la informacin.

9 XSLT permite generar como salida documentos XML, texto estructurado (por tanto, cdigo fuente de cualquier lenguaje de programacin) o HTML, y

mediante XSL-FO tambin formatos PDF, SVG, RTF, etc.

Pg. 3-35


9 Ambos son lenguajes declarativos y evitan el uso de cdigo Java (o cualquier otro lenguaje imperativo de propsito general).

9 Permiten establecer un mtodo de generacin de programas independiente del lenguaje de programacin de la aplicacin final, ya que partes de cdigo

fuente de cualquier lenguaje pueden ser embebidas entre etiquetas XML que

sean interpretadas por XSLT.

Pg. 3-36


333...666 IIINNNTTTEEEGGGRRRAAACCCIINNN DDDEEE CCCOOONNNOOOCCCIIIMMMIIIEEENNNTTTOOO I

Sobre las tcnicas empleadas para capturar, clasificar,almacenar y

recuperar cuando se necesite el conocimiento.

Gestin de Conocimiento (GC) o Knowledge Management (KM) es un trmino

asociado con los procesos para la recoleccin, organizacin, generacin, anlisis,

diseminacin, comprobacin y utilizacin del conocimiento en el mbito de una

organizacin. Tiene como objetivo la adaptacin sistemtica de una organizacin a

un entorno cambiante. Para ello, busca la combinacin de las capacidades de las

nuevas tecnologas para el procesado de datos e informacin con las capacidades

creativas humanas.

Dos conceptos importantes a tener en cuenta son:

Data Mining. Trata sobre la ordenacin de datos para identificar patrones y establecer relaciones. Incluye actividades como: asociacin de eventos

conectados, anlisis de secuencias de eventos, clasificacin y bsqueda de

patrones, clustering o agrupacin de hechos con un nexo comn,

predicciones en base a la informacin analizada.

Mtodos Push. En aplicaciones cliente/servidor denotan el reparto de informacin iniciada por el servidor sin requerimiento explcito previo del

cliente o usuario de la informacin.

Pese a que en un principio parece extrao relacionar los SCDTR con la Gestin del

Conocimiento, la GC es una disciplina emergente y de propsito general aplicable a

cualquier rea. Concretamente, el desarrollo de SCDTR es una actividad de gestin

intensiva de personas y conocimiento, en la que continuamente se tienen que

tomar decisiones. La toma de decisiones se suele basar en el conocimiento y la

experiencia personal pero cuando los proyectos crecen en tamao y complejidad es

prioritaria la comunicacin y coordinacin para que esta actividad de grupo llegue a

buen fin. La filosofa central de la GC: Ninguno de nosotros es tan bueno como

todos nosotros juntos (Bennis y Biederman 1998) encaja exactamente con las

ideas expuestas en el captulo inicial de esta tesis, por tanto, es seguro que algunos

de los conceptos de GC sern de gran ayuda.

En principio, es interesante profundizar un poco en la caracterizacin del

conocimiento segn las teoras de GC:

Se distinguen diferentes niveles de refinamiento en tanto a los elementos relacionados con el conocimiento:

Pg. 3-37


Datos puntuales. Valores cuantitativos o cualitativos, discretos y objetivos sobre un proyecto o evento concreto.

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

Conocimiento. Requiere el entendimiento de la informacin y comprende informacin, relaciones, clasificacin y metadatos. Aglutina la informacin

recogida de varios proyectos y permite su aplicacin a nuevos proyectos.

Experiencia o conocimiento aplicado. Se materializa en forma de mejores prcticas y estndares.

Tipos de conocimiento: organizacional (respecto a la compaa: recursos humanos, objetivos de negocio,), de gestin (planificacin, personal,

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

programacin, testeo, codificacin, mtodos, herramientas, lenguajes,), de

dominio (relacionado con el dominio de aplicacin y el sistema especfico bajo

desarrollo)

mbito del conocimiento. Dnde es aplicable, para quin es accesible, qu actividades soporta. Posibles mbitos: nivel individual, grupo, organizacin,

mltiples organizaciones o industria.

No es difcil identificar algunas necesidades del proceso de creacin de SCDTR que

estn directamente relacionadas con la GC:

La GC intenta convertir los datos en informacin, y sta en conocimiento pero el mayor problema es que slo una fraccin del conocimiento relacionado con el

desarrollo de SW es capturado y expresado explcitamente. La mayor parte del

conocimiento es tcito.

Diferentes proyectos o productos tienen diferentes necesidades, lo que hace que sta sea una disciplina inherentemente experimental en la que se gana

experiencia con cada nuevo proyecto. Idealmente se debera aplicar esta

experiencia a futuros proyectos, para ello hay que capturar y compartir los

resultados. El sistema debe ser adems flexible para adaptarse a la diversidad

de productos.

La gestin documental es fundamental porque la mayora de los artefactos que guan el desarrollo de un proyecto SW pueden ser representados en forma de

documentos.

Se requiere de conocimiento sobre el dominio para el que se est desarrollando SW y ese conocimiento debe integrarse en el proceso.

Colaboracin a distancia independientemente del tiempo y del espacio.

El conocimiento debe ser coleccionado, organizado, coordinado, almacenado y recuperado de forma sistemtica.

Pg. 3-38


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

siguientes niveles (Rus et al 2001):

Primer nivel. Agrupa las tareas realizadas por un equipo para desarrollar SW de acuerdo a los requisitos impuestos por el usuario. Se deben documentar las

tomas de decisiones que van constituyendo la historia del proyecto. En este

nivel es necesario un soporte de GC que recoja los resultados de todas las

actividades del proceso. Como estos resultados toman la forma de documentos,

el sistema de GC es un sistema de gestin documental. La distribucin de

informacin sobre el proyecto es un problema de gestin de informacin y las

tecnologas basadas en web se muestran vlidas para ello. Internet es una

herramienta vital para diseminar los documentos dentro y fuera de la

organizacin. A este nivel son de utilidad herramientas para el control de

versiones (edicin concurrente) y la bsqueda de documentos.

Segundo nivel. Tareas orientadas a mejorar la capacidad del equipo para desarrollar un producto SW, o dicho de otro modo, cmo mejorar las tareas del

primer nivel. Se hacen durante y al poco de acabar un proyecto para no perder

el conocimiento potencial adquirido en el mismo.

Tercer nivel. Tareas enfocadas a mejorar la capacidad de una organizacin o industria para desarrollar SW. Actividades que analizan los resultados de varios

proyectos anteriores para identificar similitudes y diferencias. La experiencia

recogida puede formularse cualitativa (patrones, reglas heursticas, mejores

prcticas,) o cuantitativamente (modelos de estimacin basados en la medida

de atributos,) o pueden recogerse en paquetes SW que automaticen ciertos

pasos del proceso de desarrollo basndose en el conocimiento inferido. Los

resultados tambin pueden ser estndares industriales.

Pg. 3-39


Pg. 3-40


333...777 IIINNNTTTEEEGGGRRRAACCCIIINNN DDDEEE AAAPPPLLLIIICCCAAACCCIIIOOONNNEEESSS A

Sobre la manera de interactuar cada una de las herramientas con el Motor

de Colaboracin de Herramientas, independientemente de su localizacin y

plataforma de ejecucin.

Uno de los objetivos de integracin se refera a la interaccin entre aplicaciones

distribuidas en entornos heterogneos. Dado que en este trabajo de investigacin

se persigue la integracin entre tiempos de ejecucin de las herramientas, y no en

tiempo de ejecucin, los sistemas fuertemente acoplados pierden fuerza frente a

una arquitectura dbilmente acoplada.

En varios trabajos anteriores (Oberndorf 1998) se pueden encontrar referencias a

la necesidad de construir un entorno de desarrollo multiplataforma, abierto,

completo y de bajo coste. Incluso ya se ha planteado el uso de lenguajes XML como

argamasa que junte las diferentes herramientas. Por ejemplo, CASEML (Garbajosa

2002) es una extensin de XML sobre la que se construye un entorno de ingeniera

de software para desarrollar aplicaciones empotradas basadas en los mtodos,

lenguajes y procesadores empleados en la Agencia Aeroespacial Europea.

Sin embargo, la consecucin de todos los requisitos planteados requiere de algo

ms para ubicar las herramientas de acuerdo a una arquitectura comn y resolver

satisfactoriamente la comunicacin remota. La filosofa de los Servicios Web

parece ajustarse perfectamente a las necesidades enunciadas, ya que se plantea la

utilizacin de los servicios ofrecidos por las diferentes herramientas desde un

entorno.

Pg. 3-41


33..77..11 CCOONNCCEEPPTTOOSS BBSSIICCOOSS SSOOBBRREE SSEERRVVIICCIIOOSS WWEEBB

Los Servicios Web (W3C 2003) parecen formar parte de una segunda oleada de

cambios en el desarrollo de aplicaciones distribuidas, tras la entrada de XML. De

hecho, tienen en XML su ncleo central y desarrollan sus capacidades para la

comunicacin entre aplicaciones por internet.

3-Arquitectura y Tecnicas de Integracion

Documents

Transcript of 3-Arquitectura y Tecnicas de Integracion