3-arquitectura y tecnicas de integracion
Post on 15-Sep-2015
14 Views
Preview:
DESCRIPTION
TRANSCRIPT
-
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
modelos. nicamente, y por razones ya comentadas, se extender en la
arquitectura de 4+1 vistas la capacidad de expresin jerrquica de los sistemas.
UML 1.4 desarrolla estos conceptos y define una rica coleccin de vistas en forma
de diagramas orientados a objetos, permitiendo mltiples enfoques para un mismo
problema. La potencia de este lenguaje radica en su flexibilidad expresiva y
capacidad de adaptacin. Pero esta virtud le hace carecer de rigurosidad y
formalidad cuando se trata de asegurar la coherencia global del modelo y sus
instancias. Como uno de los requisitos del entorno multidisciplinar es la capacidad
de validar la correccin de las instancias respecto al metamodelo, UML 1.4 parece
incompleto como soporte de los metamodelos de dominio y sus instancias. Adems,
sigue careciendo de la jerarqua formal deseable. Como ambas carencias prometen
ser paliadas en la prxima versin del lenguaje (UML 2.0), es una posibilidad de
futuro la expresin de los metamodelos de dominio y sus instancias en este
estndar.
En la filosofa MDA (Model Driven Architecture) de OMG la definicin y relacin
entre PIM y PSM, la formalidad introducida por MOF y la serializacin de modelos e
instancias con XMI tienen a UML como punto comn de referencia. A pesar de ello,
el que UML no sea el lenguaje inicialmente elegido para el modelado de dominio en
el entorno no implica dar la espalda a todos los dems estndares. De hecho, se
propone desarrollar el entorno en sintona con esta filosofa y dejar preparado el
camino para que en un futuro UML pueda ser el lenguaje de modelado inicial y XMI
pueda tender directamente los puentes hacia la expresin en XML de esos modelos
e instancias.
XML s parece colmar conjuntamente las necesidades de expresin flexible y
adaptable a diferentes campos junto con la validacin formal de las instancias. Su
papel de metalenguaje, permitiendo la creacin de lenguajes formales a travs de
schemas, y el complemento de XSL (transformaciones entre lenguajes) le hacen
convertirse en un candidato ideal.
Incluso si UML 2.0 (y estndares asociados) cumplen todas las expectativas, XML
seguir siendo necesario para el intercambio de informacin entre diferentes
plataformas, entre diferentes herramientas MOF o entre herramientas MOF y otras
no MOF (necesidad de validacin previa).
En resumen, en lo concerniente al modelado y expresin formal de la informacin
en el entorno multidisciplinar se toman las siguientes decisiones:
Definir los metamodelos de los cuatro dominios implicados. Los modelos o instancias de los mismos sern las descripciones del sistema desde los
enfoques particulares.
Usar schemas XML para definir los metamodelos de dominio. stos fijarn todos los requisitos a cumplir por las instancias (descripciones de sistemas
particulares hechas de acuerdo al metamodelo de dominio). Estos schemas
Pg. 3-2
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
XML servirn de gramticas formales del lenguaje a emplear desde cada
dominio.
Construir los lenguajes extendiendo y especializando un ncleo expresivo comn que soporte la descripcin jerrquica del sistema en base 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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
independiente de cualquier herramienta ofrecer esta flexibilidad de cara al
usuario.
El Ncleo del Entorno debe ser flexible, para adaptarse con facilidad a necesidades futuras, y abierto para integrar en cada momento a la herramienta
especfica ms adecuada. Esto se conseguir a travs del uso de estndares
para la implementacin de los componentes anteriores
El Ncleo del Entorno se asemeja a los entornos I-CASE descritos en el captulo
anterior en que tambin debe ofrecer una arquitectura comn en la que integrar
herramientas de diferente naturaleza. Por ello, se identifican los siguientes
Componentes Bsicos, anlogos a los de dichos entornos:
Repositorio de informacin comn a todas las herramientas.
Componente de integracin de modelos. Contiene la definicin explcita de los cuatro metamodelos de dominio, sus relaciones y la relacin de los
metamodelos con las herramientas particulares en base a ciertos metadatos.
Componente DIRECTOR, desde donde se controlan todos los mecanismos de activacin, se comprueban y gestionan de forma global los errores, la integridad
y la consistencia.
Interfaces de herramientas. Debe estandarizarse el formato y protocolos de intercambio de datos entre las herramientas y el entorno.
Interfaz de usuario comn para la configuracin del entorno.
El estudio hecho en el Estado del Arte sobre algunos intentos de integracin de
dominios en forma de entornos de herramientas arroja las siguientes coincidencias
entre varias soluciones propuestas:
9 Uso de XML como formato preferido para la integracin de informacin. 9 Uso de Java como lenguaje de programacin preferido para el SW de
integracin
9 Uso de documentos (normalmente en XML) anexos a los mdulos para describir la informacin necesaria para su integracin con otros.
9 Uso generalizado de la abstraccin como concepto fundamental en el que basar la integracin.
9 Uso de gramticas abstractas con los elementos sintcticos a emplear en todo el entorno, aunque luego se le aada la semntica particular de cada
dominio.
9 Uso de entidad director o similar para coordinar las diferencias semnticas entre dominios valindose de la estructura comn de los lenguajes.
Pg. 3-5
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
9 Concepto de METAframework 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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Los componentes del Motor de Colaboracin de Herramientas incluyen los que ya
han sido mencionados, ms la novedad de la entidad DIRECTOR, ncleo del MCM.
En este componente se centralizan todas las actividades de integracin:
Control del proceso de desarrollo. En funcin de la informacin aportada por el coordinador se configurar el proceso y el DIRECTOR obligar a seguir las fases
marcadas.
Gestin de activaciones para invocar las acciones necesarias en cada momento.
Control de la trazabilidad, ntimamente ligado al proceso SW seguido.
Comprobacin global de errores, coherencias e integridad de la informacin.
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
DIRECTOR. Toda esta informacin se emplear para coordinar todo el
entorno a lo largo de la vida del proyecto.
Especialista. Usuario final de cada una de las herramientas integradas. Hace uso de una herramienta bien conocida a partir de la informacin que le
facilita el entorno y de las pautas indicadas por el coordinador.
El diagrama de componentes bsicos mostrado en la Figura 3-2 se ir completando
en ms detalle a lo largo del presente captulo y se desarrollar el diseo final de
cada bloque en el captulo siguiente.
Pg. 3-9
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Pg. 3-10
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
acorde a tecnologas estndares y ampliamente aceptadas, que se discutirn a lo
largo de este apartado.
En definitiva, se trata de llegar a acuerdos entre las partes implicadas, pero estos
acuerdos pueden ser de muy diversa naturaleza:
Acuerdos tcitos o explcitos. En ocasiones, se siguen acuerdos no escritos para hacer que se entiendan dos aplicaciones. En este trabajo se intenta
hacer explcito cualquier acuerdo porque esto es necesario para poder
modificar los trminos del acuerdo o para generalizarlo y lograr la
interaccin con otras aplicaciones cualesquiera.
Acuerdos punto a punto o genricos. Para comunicar dos aplicaciones basta con ponerse de acuerdo entre ellas, pero para lograr comunicar un nmero
indeterminado de aplicaciones no definidas de antemano, es necesario
imponer unas normas genricas que permitan interactuar a toda aplicacin
que las cumpla.
La propia interaccin entre las aplicaciones puede ser manual o guiada. Es decir,
dirigida a su libre albedro por el usuario (que indica en qu momento invocar una
aplicacin y con qu datos trabajar) o conducida por una entidad directora que siga
unas reglas prefijadas y regule los pasos a seguir, los datos a emplear y la
coherencia de todo el proceso. Como ya se ha descrito, los procesos y metodologas
para el desarrollo de SW requieren de una regulacin de las fases de su ciclo de
vida que aconseja una interaccin guiada. Por ello se propone que sea llevada a
cabo por la entidad DIRECTOR.
Una vez que las aplicaciones son capaces de interactuar (porque se han resuelto de
alguna manera los 7 puntos anteriores) se pueden definir diferentes niveles de
integracin:
Aplicaciones integrables. Por cumplir todos los requisitos para interactuar se puede escribir un SW que las integre.
Aplicaciones integradas entre tiempos de ejecucin. Cada aplicacin funciona segn sus propios tiempos pero los resultados que se obtienen al
terminar su uso se sincronizan con la informacin que ya exista. Por cada
uso de una aplicacin se comprobar la coherencia de los resultados con
todo lo anterior.
Aplicaciones integradas en tiempo de ejecucin. En el propio tiempo de ejecucin, una aplicacin es capaz de comunicase e interactuar con otras.
En definitiva, se pueden completar un poco ms las caractersticas del MCH
aadiendo las siguientes:
El MCH usar conexiones sobre TCP/IP para comunicarse con las herramientas.
Pg. 3-12
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
La informacin a intercambiar entre herramientas y MCH se expresar en formato XML. Siendo as, lo ms lgico es que los repositorios tambin
almacenen la informacin en este formato.
Se definirn gramticas XML ajustadas a las necesidades de cada uno de los dominios: Ingeniera de Control (IC), Sistemas Distribuidos (SD), Sistemas de
Tiempo Real (STR) e Ingeniera del SW (IS). De este modo, la informacin
intercambiada entre una determinada herramienta y el MCH se expresar
siempre en la gramtica propia de su dominio.
El DIRECTOR llevar a cabo una integracin entre tiempos de ejecucin, es decir, se encargar de sincronizar la informacin global cada vez que se
reporten resultados desde alguna de las herramientas.
Los acuerdos necesarios para la integracin de herramientas se hacen genricos ya que hacen referencia a las interacciones entre los diferentes
dominios especficos y no a la existente entre herramientas concretas. Estos
acuerdos se engloban en un conjunto de Modelos de Dominios que estarn
ntimamente ligados a las Gramticas de Dominio.
Los acuerdos se hacen explcitos porque se expresan en forma de modelos y gramticas modificables, y por tanto extensibles.
La Figura 3-16 muestra como queda el MCH con estas aportaciones. El DIRECTOR
lleva la iniciativa y usa los servicios que le ofrecen las aplicaciones de forma
coordinada y coherente, basndose en los modelos y gramticas de dominio.
Pg. 3-13
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Figura 3-5. Niveles de abstraccin de cada faceta.
En la especificacin de un lenguaje se anan las descripciones de varias
propiedades ortogonales. El tratamiento por separado de las mismas permite varios
niveles de compatibilidad. La definicin de un lenguaje puede dividirse en cinco
partes (servicios) agrupadas en dos bloques:
Estructura lgica:
Sintaxis abstracta. Define cmo un diseo puede dividirse en componentes interconectados. El conjunto de componentes y relaciones que
pueden aparecer en un diseo conforman una sintaxis abstracta.
Sintaxis concreta, notacin. Define cmo un diseo puede ser representado y manipulado en un formato persistente y usable por el
ordenador (XML, APIs, fichero ASCII, grfico,). Pueden existir mltiples
sintaxis concretas derivadas de una nica sintaxis abstracta.
Transformaciones sintcticas. Un conjunto de operaciones (tanto estticas como dinmicas) permiten transformar un diseo en otro.
Significado:
Sistema de tipos. Regulan los datos compartidos por los componentes y aseguran que se cumplen los requisitos que los componentes imponen a
esos datos. El polimorfismo es una cualidad conveniente para dar
generalidad a los diseos.
Semnticas (de componentes y de interaccin). Da significado a las caractersticas de cada componente y a sus conexiones con otros.
Un determinado diseo se representa con un lenguaje concreto que incluye los
cinco servicios mencionados. Sin embargo, las herramientas que se utilizan para
manejar ese modelo no tienen porque ser conscientes de todas las partes del
lenguaje. Habr herramientas que soporten slo alguna de las partes del lenguaje.
Pg. 3-17
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Por ejemplo, un visualizador grfico que muestre las relaciones entre componentes
no necesita conocer la semntica ni los tipos (le basta con conocer la sintaxis
abstracta), mientras que un motor de inferencia de tipos necesita conocer el
sistema de tipos adems de la sintaxis abstracta.
En base a estos conceptos se puede clasificar la interoperatividad entre
herramientas a diferentes niveles:
1. Sintaxis abstracta compatible. Es posible escribir SW ad hoc que convierta datos de una herramienta en datos utilizables en otra.
2. Sintaxis concreta compatible. Una herramienta puede leer datos en el formato persistente de otra (ficheros externos) sin necesidad de escribir SW
especial.
3. Transformaciones sintcticas compatibles. Es posible generar automticamente datos de entrada para una herramienta a partir de los
resultados de otra.
4. Sistema de tipos compatible. Intercambio automtico de modelos de datos completos entre herramientas.
5. Semnticas compatibles. Las herramientas pueden intercambiar datos dinmicamente, en tiempo de ejecucin.
Cuando se busca la interoperatividad entre un conjunto lo suficientemente amplio y
diverso de herramientas de diseo, enseguida es evidente que no basta con un
nico formato estndar para representar adecuadamente una sintaxis y semntica
comn para todas. Existe una variedad de modelos semnticos para sistemas
basados en componentes y cada uno tiene sus ventajas y su campo de aplicacin.
Por ello, se busca un acuerdo en lo ms bsico, la sintaxis abstracta. Una sintaxis
abstracta comn para herramientas de diseo de sistemas debe ser capaz de
describir listas de conectividad, diagramas de transicin de estados, diagramas de
bloques, modelos de objetos y estructuras grficas, adems de permitir el uso
extensivo de la jerarqua para lograr escalabilidad. stas son las caractersticas que
rene la sintaxis abstracta GSRC.
Resumen de las caractersticas del proyecto GSRC:
Definicin por separado de cada una de los cinco servicios constitutivos de un lenguaje:
Sintaxis abstracta. Definicin de componentes y posibles relaciones entre ellos, capacidades de jerarqua, conectividad e instanciacin de clases.
Sintaxis concreta. MoML es una sintaxis concreta XML para la sintaxis abstracta de GSRC. MoML no aade significado al modelo, en su lugar,
permite aadir un director al modelo. El director definir la semntica de las
conexiones pero para MoML no es ms que la referencia a una instancia que
cargar el cargador de clases.
Pg. 3-18
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Transformaciones sintcticas. Definicin de las posibles operaciones en los modelos (creacin de puertos, relaciones, enlaces, entidades, etc).
Aplicaciones como los editores visuales de modelos o las herramientas de
instanciacin hacen uso de las mismas.
Sistemas de tipos. Los propios de cada dominio para permitir el uso de interfaces polimrficos que evitan la necesidad de escribir adaptadores de
protocolo entre interfaces rgidos predefinidos.
Semnticas de componentes y de interaccin. Definicin de todos los significados posibles de los componentes: estados, procesos, threads,
ecuaciones diferenciales, requisitos, objetos, etc. Sobre esta ontologa de
componentes definida para cada dominio se especifican las semnticas de
interaccin entre componentes.
Beneficios de la ortogonalizacin:
Diferentes niveles de interoperatividad
Terminologa independiente de sintaxis concreta
Se enfatizan frameworks en lugar de lenguajes
Pg. 3-19
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
M2. Metamodelo de cada dominio especfico. A travs de mecanismos de herencia se extiende M3 particularizando el schema genrico a las
necesidades expresivas de un rea concreta. Por tanto, se crearn cuatro
schemas especficos para dar soporte a los cuatro metamodelos
M1. Modelo del sistema en desarrollo. Se especifican las caractersticas del sistema creando instancias para los cuatro schemas anteriores.
M0. Objetos de Dominio son los componentes o unidades mnimas de modelado. Difieren en cada uno de los dominios.
Esta jerarqua formal de abstraccin vertical debe acompaarse de mecanismos
para regular el flujo horizontal de informacin y la validacin horizontal de
implicaciones entre vistas. Estas necesidades se cubrirn de la siguiente forma:
Flujo horizontal de informacin: XSLT habilitar las transformaciones a nivel de modelo para sincronizar las descripciones. Es decir, para extraer de un
modelo las informaciones que incumben tambin a otro y generar la versin
bsica del segundo modelo, versin que se ir completando despus con las
aportaciones de las herramientas de dominio. Este mecanismo de
sincronizacin entre modelos de diferentes dominios se facilita porque todos los
lenguajes tienen un ncleo expresivo comn (componentes y conectores).
Validacin horizontal de implicaciones entre vistas: Adems de la formalizacin (basada en schemas) que se hace dentro de cada dominio, es
necesario formalizar las relaciones entre metamodelos para realizar
validaciones. Pero la expresin de estas relaciones cruzadas necesita de algn
mecanismo diferente al de los schemas XML porque son especificaciones en
forma de reglas ms que especificaciones sintcticas o gramaticales. Por tanto,
habr que completar la formalizacin vertical de cada dominio con un Lenguaje
para la Especificacin de Reglas (LER) que permita expresar reglas cruzadas de
validacin horizontal, involucrando a varios dominios.
La adopcin de una estructura de modelado acorde con MOF permitir
aprovecharse de las ventajas de las nuevas versiones de UML, MOF y XMI. Se
podrn expresar formalmente los cuatro niveles en MOF-UML, derivando cada nivel
del anterior. A partir de este punto, se podra comprobar la coherencia
directamente en UML, realizar anlisis, simulaciones, etc. Tambin se podran
generar automticamente con XMI los schemas que dan soporte a los metamodelos
y exportar o importar las propias instancias, generar automticamente las hojas de
estilo XSLT que implementan las transformaciones automticas entre modelos,
generar automticamente las reglas de validacin horizontal, generar cdigo para el
manejo de las estructuras de datos definidas, usar CWM como soporte formal para
los repositorios de schemas y de documentos XML, etc.
Por ltimo, tambin se pueden aplicar los conceptos de PIM y PSM de MDA al propio
entorno multidisciplinar, adems de a las vistas manejadas. Se trata de un entorno
genrico e independiente de las herramientas, que se puede denotar como TIM
Pg. 3-21
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
(Tool Independent Model), pero cuando se configura un conjunto de herramientas
concretas para su uso en un determinado proyecto se constituye un TSM (Tool
Specific Model). Es decir, el funcionamiento interno del entorno se fundamenta en
la abstraccin de las vistas y sus interacciones (TIM), pero las herramientas
concretas de desarrollo que se vayan a emplear deben engancharse a los modelos
formales para crear una instancia concreta y especfica del entorno (TSM) para un
determinado proyecto.
Pg. 3-22
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
modelos de menor nivel de abstraccin implementan correctamente los modelos de
alto nivel. Esto asegura una mayor calidad, y no slo capacidad para realizar
pruebas. Tal y como dice Dijkstra, el test demuestra la presencia de errores, no su
ausencia. Para poder entender y razonar los diseos, deben esconderse los detalles
de implementacin (SoC, Separation of Concerns). No se puede dejar que
cuestiones de microeficiencia dominen e influyan en el resultado final.
Un mtodo formal en desarrollo de SW es un mtodo que proporciona:
1. un lenguaje formal para describir los artefactos SW (especificaciones, diseos, cdigo fuente,)
2. mecanismos que permitan realizar pruebas formales sobre las propiedades del artefacto formalmente descrito
La propiedad comprobada suele ser que una implementacin es funcionalmente
correcta, es decir, cumple su especificacin. Entonces, o bien el lenguaje formal
empleado permite describir un sistema a dos niveles de abstraccin (especificacin
formal y posible implementacin), o bien se emplean dos lenguajes relacionados
para describir especificacin e implementacin respectivamente.
En ingeniera de SW, los mtodos formales son directamente aplicables durante las
fases de requisitos, diseo y codificacin y tienen importantes consecuencias para
el test y el mantenimiento. Estn entrelazados con modelos del ciclo de vida
alternativos a las aproximaciones clsicas y permiten un mayor control de la
trazabilidad.
Su aplicacin ms habitual se da en la fase de especificacin. Algunos mtodos
formales incluyen lenguajes de especificacin que permiten registrar precisa y
rigurosamente las caractersticas funcionales y no funcionales que se esperan
obtener de un sistema. Algunos ejemplos son: 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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Pese a las ventajas que proporcionan, tienen limitaciones que conviene tener en
cuenta:
Problema de requisitos.
Pueden usarse para verificar (probar que una implementacin satisface una
especificacin formal) que cada paso en el desarrollo del producto satisface los
requisitos impuestos en los pasos previos. Pero no es suficiente para validar un
sistema (probar que un producto satisface su misin operativa) porque tal y
como afirma Boehm (1981): no se puede ir de lo informal a lo formal por
mtodos formales. El problema es que no se puede probar que una
especificacin formal capture el entendimiento informal e intuitivo del sistema
por parte de un usuario. La especificacin es el contrato entre el usuario y el
desarrollador, y adems de ser formal, tiene que contener y describir todas las
caractersticas que el usuario espera obtener en el producto final.
Problema de implementacin fsica.
Los mtodos formales pueden verificar que una implementacin satisface su
especificacin cuando corre en una mquina abstracta ideal, pero no en
cualquier mquina fsica. Las pruebas formales explcitamente aslan los sitios
en que puede producirse el error. Concretamente, ser all donde se provea de
una mquina fsica para implementar a la abstracta, ya que las pruebas se
hacen suponiendo que la ejecucin se realizar en la mquina abstracta.
Requisitos de usuario
MTODOS FORMALES
Especificacin formal Diseo
Cdigo mquina abstracta
Cdigo mquina
fsica
Requisitos de usuario
MTODOS FORMALES
Especificacin formal Diseo
Cdigo mquina abstracta
MTODOS FORMALES
Especificacin formal Diseo
Cdigo mquina abstracta
Cdigo mquina
fsica
Figura 3-6. Incertidumbres a la entrada y salida de los mtodos formales.
Estas limitaciones afectan precisamente al punto inicial y final del ciclo de vida (ver
Figura 3-6). Los mtodos formales pueden automatizar y verificar las transiciones
entre las fases internas del ciclo de vida (especificacin, diseo y generacin de
cdigo para mquina abstracta), pero existen incertidumbres en los saltos de lo
informal a lo formal, y de lo formal a lo informal respectivamente, al principio y al
final del proceso. Se investigan diversas formas de minimizar la magnitud de estos
saltos; por un lado el uso de lenguajes formales pero cercanos al entendimiento
del usuario para recoger requisitos o el empleo de especificaciones grficas con
formalismo inherente; por otro lado el empleo de estndares, HW, libreras y
compiladores certificados para asegurar su adherencia a la mquina abstracta
idealizada.
Pg. 3-26
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Ni siquiera en todas las fases internas del ciclo de vida es siempre ventajoso el uso
de mtodos formales. Debe decidirse en qu fases y con qu objetivos emplearlos
para modular el grado de uso ms adecuado:
Uso puntual. En el desarrollo de algunos componentes se usan slo para la fase de diseo porque los productos requieren de una interaccin continua entre
especificacin e implementacin.
Uso generalizado. Se puede derivar todo el proceso a partir de unas especificaciones formales completas. Si todo parmetro o cambio que pueda
introducirse est recogido en las especificaciones, se podra generar el cdigo
final a partir de ellas. En este caso, se modificara la especificacin para generar
cualquier nueva versin. Esta visin sustituye a los programadores por un
conjunto inteligente de herramientas integradas dirigidas por mtodos formales
(McLean 1993).
Uso variable. Introduccin parcial de mtodos formales con nivel variable de formalidad y uso de verificacin informal. Es el caso del modelo de proceso de
sala limpia (Linger 1994).
A veces es difusa la frontera entre mtodo o lenguaje de especificacin. Un mtodo
indica qu debe decir una especificacin, mientras que un lenguaje determina cmo
pueden expresarse los conceptos de una especificacin. Algunos lenguajes soportan
ms de un mtodo, y la mayora de los mtodos pueden ser usados en varios
lenguajes de especificacin (Lamport 1989).
Los lenguajes de especificacin formal tienen un alfabeto de smbolos y reglas
gramaticales que definen frmulas de buena formacin. Estas reglas caracterizan el
dominio sintctico del lenguaje o cmo combinar los smbolos para obtener
expresiones, en principio, sin significado. El significado o interpretacin de la
frmula es parte de la semntica. El conjunto de objetos que componen el dominio
semntico del lenguaje (reglas que dictan qu objetos satisfacen la especificacin)
proveen al lenguaje de un modelo.
Una especificacin ser un conjunto de frmulas expresadas en el lenguaje
formal. Los objetos en el dominio semntico del lenguaje que satisfacen una
especificacin pueden ser varios. Por eso la especificacin est en un nivel de
abstraccin mayor que los objetos en el dominio semntico, permite abstraerse de
los detalles que distinguen diferentes implementaciones. Diferentes mtodos de
especificacin definidos sobre el mismo dominio semntico permiten especificar
diferentes aspectos de los objetos.
Todos estos conceptos pueden expresarse a travs de las matemticas, con la
ventaja de que se obtienen herramientas para razonamiento formal a partir de las
especificaciones, que pueden ser examinadas para ver si con consistentes y
completas.
En funcin de sus dominios semnticos, los lenguajes de especificacin pueden
clasificarse en:
Pg. 3-27
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Lenguajes ADT (Abstract Data Type Specification). Especificacin de lgebras. Propiedades formales de un tipo de dato sin definir caractersticas
de implementacin. Ejemplos: Z, VDM, Larch.
Lenguajes de especificacin de procesos. Secuencias de estados, eventos, mquinas de estados. Ejemplo: CSP de Hoare
Lenguajes de programacin.
Los mtodos de especificacin se pueden clasificar en:
Operacionales, constructivos u orientados a modelo. La especificacin es una descripcin del sistema que proporciona un modelo. El comportamiento
de este modelo define el deseado en el sistema. Usar estructuras
matemticas abstractas como relaciones, funciones, conjuntos y secuencias.
Puede verse como un programa escrito en un lenguaje de muy alto nivel, ya
que se pasa de un conjunto de entradas a uno de salidas.
De definicin, declarativos u orientados a la propiedad. Mnimo conjunto de condiciones que debe satisfacer un sistema para ser funcionalmente
correcto. No se determina un modelo mecnico para llegar de las entradas a
las salidas. Mtodos algebraicos (las propiedades se expresan en forma de
ecuaciones) y axiomticos (clculo de predicados).
Como conclusin, los paradigmas de ciclos de vida que confen en la transformacin
automtica desde especificacin hasta cdigo ejecutable son necesariamente
formales (por ejemplo, el ciclo de vida de sala limpia). El desarrollo de SW al
hacerse complejo se est volviendo cada vez ms dependiente de las herramientas,
y stas cada vez usan ms los mtodos formales. Entre las tcnicas que hacen uso
de ellos cabe mencionar: prototipado rpido, diseo orientado a objetos,
programacin estructurada e inspecciones formales.
El uso de los mtodos formales se est generalizado a pequea escala pero
tpicamente en organizaciones con nivel 3 o superior en el modelo de madurez del
proceso SW del SEI. Es difcil llevarlos hasta el ltimo extremo pero se pueden
implantar gradualmente e ir integrndose en el proceso habitual de las empresas.
Pg. 3-28
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
9 Reduccin del impacto de cambios. Los cambios en el SW son aditivos, no intrusivos. Se logra mejorar el comportamiento global del sistema sin
perjudicar lo anteriormente construido.
9 Ms sencilla comprensin del sistema y reduccin de la complejidad. 9 Adaptabilidad. 9 Mantenimiento ms sencillo. 9 Personalizacin y configuracin acorde a las necesidades del usuario. 9 Reutilizacin de componentes. 9 Mejor trazabilidad. 9 Integracin de componentes simplificada, uso de COTS 9 SW ms rpido, seguro, barato y de mejor calidad.
IBM ha trabajado en MDSOC y ha creado su aproximacin particular denominada
Hyperspaces (www.research.ibm.com/hyperspace/). Concretamente, proporciona
soporte para hiperespacios Java 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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
aspectos de un sistema en una forma separada y natural para despus combinar
esas descripciones separadas en la forma de un ejecutable final.
AspectJ (http://eclipse.org/aspectj/) es una extensin orientada a aspectos para el
lenguaje Java. Proporciona una modularizacin limpia para problemas
transversales, de forma que se modularizan aspectos que afectan a ms de una
clase.
Generative Programming (www.generative-programming.org). Se trata de un
conjunto de tcnicas que permiten construir los programas automticamente a
partir de programas especficos de dominio de menor tamao (Czarnecki y Ulrich
2000). Extiende los beneficios de la automatizacin al desarrollo SW.
Intentional Programming. Una tcnica que permite a los programas ser escritos
y vistos en una variedad de notaciones diferentes. Tambin permite la integracin
sin problemas de programas de dominio especfico y programas de propsito
general. Fue desarrollado por el equipo de Charles Simonyi (Simonyi 1995)
mientras trabajaba en Microsoft.
Transformational Programming. Tcnica que produce programas a partir de
especificaciones de alto nivel o especficas de dominio. El programa es derivado de
una especificacin formal empleando pasos de transformacin manejados y
controlados que garantizan que el producto final cumpla con las especificaciones
iniciales (Bauer et al 1989).
Adems de las resumidas hasta aqu, existen otras tcnicas o metodologas que
matizando ligeramente la forma, tratan el mismo problema de fondo. En la
bibliografa se entremezclan y confunden trminos como: Subject-Oriented
Programming, Product-Line Engineering, Traversal-Related Behavioral Concerns,
Component-Based Software Engineering,
Pg. 3-32
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
El uso de Generadores de Programas suele ir de la mano de la Programacin
Orientada a Componentes, en la que se emplean como constructores necesarios los
componentes, interfaces, conectores y adaptadores:
Componente. Se puede definir como una unidad de composicin con interfaces especficos y contexto explcito. Puede ser desarrollado a propsito
para una aplicacin o reutilizado tras capturarlo en un repositorio y
parametrizarlo. Existe una discusin sobre la distincin de componentes y
objetos, concretamente, UML 2.0 promete mejor soporte para los componentes
de lo que ofrece la versin actual. Un componente debe minimizar las
asunciones (dependencias) hechas sobre el entorno y los recursos y objetos
que lo rodean. Se llaman dependencias porque el componente depende de su
existencia. No se pueden eliminar todas las dependencias ya que el interfaz de
un componente usa ciertos tipos que deben ser soportados por el entorno. Por
ello los componentes a menudo se desarrollan para un determinado modelo de
componentes (por ejemplo, JavaBean). Ejemplos de dependencias: variables
globales y recursos, tipos y mecanismos de comunicacin entre procesadores.
Interfaz. Es una interaccin entre un componente y otros elementos SW. Los interfaces se suelen dividir en exports (servicios provistos por el componente) e
imports (servicios requeridos por los componentes) y se suelen graficar como
puertos de entrada y salida.
Conector. Sern compatibles aquellas conexiones entre puertos import y export que tengan el mismo tipo. Puede haber conectores sncronos (se espera
hasta que vuelva la respuesta de la llamada) y asncronos (se hace la llamada
pero no se espera la respuesta).
Adaptadores de interfaz. Necesarios para convertir entre el tipo de una salida y el de una entrada a otro componente o para conectar una salida a
varias entradas
Tanto los lenguajes ADL (Architecture Description Language) como los MIL (Module
Interconnection Language) permiten representar componentes, conectores e
interfaces, y solucionar los flujos de informacin entre ellos a travs de
adaptadores para no perder la modularidad. Adems, estos lenguajes tienen en
cuenta mecanismos de comunicacin (para sistemas distribuidos), jerarqua
(combinacin de componentes para la construccin de otros), etc. XML es muy
bueno como base de un lenguaje MIL ADL.
Todo lo anterior plantea la generacin automtica como una labor compleja que
requiere de bastante estudio y formalizacin. De hecho, parece razonable plantear
la fase de generacin de cdigo como un subproceso diferenciado dentro del
proceso general de creacin de SW. Las compensaciones que conlleva este arduo
trabajo son las siguientes:
9 Toma de decisiones en el nivel de especificacin frente al de codificacin. Es ms fcil leer, escribir, editar, depurar y entender los sistemas en la fase de
Pg. 3-34
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
especificacin y los lenguajes de especificacin (de cuarta generacin) son
ms productivos que los de programacin.
9 Favorece el SoC (Separation Of Concerns) porque permite que diferentes profesionales con tareas concretas puedan colaborar en la especificacin y
dejar la fase de generacin de cdigo al Generador de Programas (y no a un
especialista concreto).
9 Desacopla especificacin (el qu) de implementacin (el cmo) porque esta ltima parte la realiza el Generador de Programas. Podrn realizarse
diferentes implementaciones, programas alternativos o variaciones de un
mismo tipo de programa (familias de programas) para una nica
especificacin sin ms que configurar adecuadamente el Generador.
9 Proceso automtico unificado para extraer, a partir de unas especificaciones comunes, varios productos: cdigo, documentacin del SW, documentacin
de usuario, pruebas y documentos de configuracin.
9 Correccin y coherencia del producto final. El programa generado no tendr errores cometidos en la fase de codificacin y se evitarn derivas respecto a
las especificaciones.
9 Mejora continua del rendimiento del SW con la aplicacin de las ltimas tcnicas por parte del Generador de Programas.
Varias de estas ventajas recuerdan a las que se mencionaban para el uso de
metodologas formales porque en ese caso tambin se intenta generar
automticamente el cdigo a partir de una especificacin formal completa.
Mientras que para los programas generados a mano debe facilitarse la legibilidad y
facilidad de modificacin del propio cdigo, para los programas generados
automticamente es importante la legibilidad y sencillez de modificacin de las
especificaciones a partir de las cuales se crea automticamente el cdigo. Este
objetivo est asegurado si dichas especificaciones estn expresadas en XML, como
es el caso que se plantea en esta tesis. Partiendo de unas especificaciones as, la
combinacin de XSLT (W3C 1999) y XPath (W3C 1999b) supone la manera natural
de implementar la generacin de cdigo porque:
9 Ambos son estndares abiertos. 9 Tienen funcionalidades complementarias; mientras XPath se usa para
identificar y seleccionar partes de un documento XML, XSLT habilita la
transformacin de la informacin.
9 XSLT permite generar como salida documentos XML, texto estructurado (por tanto, cdigo fuente de cualquier lenguaje de programacin) o HTML, y
mediante XSL-FO tambin formatos PDF, SVG, RTF, etc.
Pg. 3-35
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
9 Ambos son lenguajes declarativos y evitan el uso de cdigo Java (o cualquier otro lenguaje imperativo de propsito general).
9 Permiten establecer un mtodo de generacin de programas independiente del lenguaje de programacin de la aplicacin final, ya que partes de cdigo
fuente de cualquier lenguaje pueden ser embebidas entre etiquetas XML que
sean interpretadas por XSLT.
Pg. 3-36
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Datos puntuales. Valores cuantitativos o cualitativos, discretos y objetivos sobre un proyecto o evento concreto.
Informacin. Datos organizados de forma que le sean til al usuario para tomar decisiones.
Conocimiento. Requiere el entendimiento de la informacin y comprende informacin, relaciones, clasificacin y metadatos. Aglutina la informacin
recogida de varios proyectos y permite su aplicacin a nuevos proyectos.
Experiencia o conocimiento aplicado. Se materializa en forma de mejores prcticas y estndares.
Tipos de conocimiento: organizacional (respecto a la compaa: recursos humanos, objetivos de negocio,), de gestin (planificacin, personal,
seguimiento, direccin proyecto), tcnico (anlisis de requisitos, diseo,
programacin, testeo, codificacin, mtodos, herramientas, lenguajes,), de
dominio (relacionado con el dominio de aplicacin y el sistema especfico bajo
desarrollo)
mbito del conocimiento. Dnde es aplicable, para quin es accesible, qu actividades soporta. Posibles mbitos: nivel individual, grupo, organizacin,
mltiples organizaciones o industria.
No es difcil identificar algunas necesidades del proceso de creacin de SCDTR que
estn directamente relacionadas con la GC:
La GC intenta convertir los datos en informacin, y sta en conocimiento pero el mayor problema es que slo una fraccin del conocimiento relacionado con el
desarrollo de SW es capturado y expresado explcitamente. La mayor parte del
conocimiento es tcito.
Diferentes proyectos o productos tienen diferentes necesidades, lo que hace que sta sea una disciplina inherentemente experimental en la que se gana
experiencia con cada nuevo proyecto. Idealmente se debera aplicar esta
experiencia a futuros proyectos, para ello hay que capturar y compartir los
resultados. El sistema debe ser adems flexible para adaptarse a la diversidad
de productos.
La gestin documental es fundamental porque la mayora de los artefactos que guan el desarrollo de un proyecto SW pueden ser representados en forma de
documentos.
Se requiere de conocimiento sobre el dominio para el que se est desarrollando SW y ese conocimiento debe integrarse en el proceso.
Colaboracin a distancia independientemente del tiempo y del espacio.
El conocimiento debe ser coleccionado, organizado, coordinado, almacenado y recuperado de forma sistemtica.
Pg. 3-38
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
La aplicacin de la GC a la Ingeniera de SW debe ser progresiva y se distinguen los
siguientes niveles (Rus et al 2001):
Primer nivel. Agrupa las tareas realizadas por un equipo para desarrollar SW de acuerdo a los requisitos impuestos por el usuario. Se deben documentar las
tomas de decisiones que van constituyendo la historia del proyecto. En este
nivel es necesario un soporte de GC que recoja los resultados de todas las
actividades del proceso. Como estos resultados toman la forma de documentos,
el sistema de GC es un sistema de gestin documental. La distribucin de
informacin sobre el proyecto es un problema de gestin de informacin y las
tecnologas basadas en web se muestran vlidas para ello. Internet es una
herramienta vital para diseminar los documentos dentro y fuera de la
organizacin. A este nivel son de utilidad herramientas para el control de
versiones (edicin concurrente) y la bsqueda de documentos.
Segundo nivel. Tareas orientadas a mejorar la capacidad del equipo para desarrollar un producto SW, o dicho de otro modo, cmo mejorar las tareas del
primer nivel. Se hacen durante y al poco de acabar un proyecto para no perder
el conocimiento potencial adquirido en el mismo.
Tercer nivel. Tareas enfocadas a mejorar la capacidad de una organizacin o industria para desarrollar SW. Actividades que analizan los resultados de varios
proyectos anteriores para identificar similitudes y diferencias. La experiencia
recogida puede formularse cualitativa (patrones, reglas heursticas, mejores
prcticas,) o cuantitativamente (modelos de estimacin basados en la medida
de atributos,) o pueden recogerse en paquetes SW que automaticen ciertos
pasos del proceso de desarrollo basndose en el conocimiento inferido. Los
resultados tambin pueden ser estndares industriales.
Pg. 3-39
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
Pg. 3-40
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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
-
Captulo 3: Arquitectura del Entorno y Tcnicas de Integracin
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.
top related