3 ARQUITECTURA DEL ENTORNO Y TÉCNICAS DE INTEGRACIÓN

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
 10
 
  3 ARQUITECTURA T DEL ENTORNO Y TÉCNICAS DE INTEGRACIÓN En este capítulo se inicia la toma de decisiones respecto al entorno multidisciplinar. En primer lugar, se seleccionan los estándares de modelado
Related documents
Share
Transcript
3 ARQUITECTURA T DEL ENTORNO Y TÉCNICAS DE INTEGRACIÓN En este capítulo se inicia la toma de decisiones respecto al entorno multidisciplinar. En primer lugar, se seleccionan los estándares de modelado y expresión formal y la forma de usarlos en el entorno. Así mismo, se define una primera aproximación a la arquitectura del entorno en un intento por sintetizar, en forma de bloques funcionales relacionados, cada una de los requisitos identificados a lo largo del capítulo anterior. Posteriormente, se definirá lo que se entiende por integración y se describirán diferentes niveles de integración. Lo que dará paso a un estudio de diferentes técnicas de integración para resolver la colaboración de gramáticas, modelos, técnicas de desarrollo de SW, conocimiento y aplicaciones. Se valorarán técnicas muy dispares entre sí pero con el común denominador de servir para integrar información, aunque con diferentes grados de abstracción. Las conclusiones del capítulo servirán para seleccionar las técnicas más adecuadas para cada uno de los niveles de integración, y completar así la arquitectura del entorno esbozada al inicio con más detalles relativos a las técnicas a utilizar. 3.1 Arquitectura General del Entorno Modelado y Expresión Formal en el Entorno Requisitos y Componentes Básicos del Entorno Estructura General 3.2 Niveles de Integración 3.3 Integración de Gramáticas GSRC Semantics Project 3.4 Integración de Modelos 3.5 Integración de Técnicas para Desarrollo de SW Métodos Formales Separación Multidimensional de Propósitos Desarrollo de SW Dirigido a Dominio Generación de Programas con XSLT 3.6 Integración de Conocimiento 3.7 Integración de Aplicaciones Conceptos básicos sobre Servicios Web Estilo de Arquitectura REST Definiciones sobre Servicios Web Escenarios de Uso de Servicios Web Escenario 0: Interacción web clásica (sin servicios web) Escenario 1: Partes conocidas, WSD estático Escenario 2: Partes conocidas obtienen WSD dinámicamente Escenario 3: Múltiples proveedores, descubrimiento manual Escenario 4: Múltiples proveedores, acceso a WSD del proveedor Escenario 5: Múltiples proveedores, selección automática Escenario T: Diagrama en triángulo Tecnologías para Servicios Web 3.8 Conclusiones Integración de Gramáticas (Gramáticas XML de Dominios) Integración de Modelos (Modelos de Dominio) Integración de Técnicas para Desarrollo de SW (DIRECTOR) Integración de Conocimiento (Repositorio) Integración de Aplicaciones (Interfaz de Herramientas) 3..1 ARQUIITECTURA GENERAL DEL ENTORNO Sobre las conclusiones del recorrido del Estado del Arte del capítulo anterior, conclusiones en forma de selección de estándares para el modelado y la expresión formal, requisitos identificados y arquitectura de bloques en la que se fundamentará el entorno MODELADO Y EXPRESIÓN FORMAL EN EL ENTORNO Aplicando al entorno multidisciplinar las ideas sobre niveles de abstracción expuestas en el capítulo anterior, se identifica la necesidad de construir cuatro jerarquías de abstracción (en principio independientes) para representar la visión del SCDTR desde cada uno de los dominios involucrados (IC, SD, STR e IS). Dado un sistema concreto en desarrollo, cada dominio selecciona (a partir del conjunto total de información existente) el subconjunto de datos relevantes para su campo (objetos de dominio). Estos datos y sus relaciones se describen dando forma al modelo particular de dominio del sistema. Por tanto, en este trabajo se entiende por modelo la abstracción o descripción parcial y particular de las características (comportamiento, estructura, funcionalidad,...) del sistema bajo desarrollo. Para añadir formalidad a estas descripciones y tener la posibilidad de validar la corrección de diferentes modelos de acuerdo a los parámetros propios del dominio es necesaria la existencia de un nivel superior o metamodelo del domino. El metamodelo define el lenguaje a emplear para construir nuevos modelos, o descripciones de sistemas de acuerdo a las convenciones establecidas por un dominio, y con ello introduce formalidad o mecanismos de validación de las descripciones. En resumen, se plantea la necesidad de definir cuatro metamodelos porque cada dominio usará diferentes objetos de dominio, es decir, tendrá un subconjunto de información diferente en el nivel de dato. Se considera interesante la arquitectura de 4+1 vistas en tanto que esta arquitectura coincide con la visión adelantada en el capítulo inicial de esta memoria. En ambos casos se separan los modelos en función del profesional que los vaya a usar y también se considera necesario el empleo de una notación o lenguaje especializado para la descripción del sistema desde cada uno de los dominios. Hay que destacar el interés de construir estos lenguajes especializados utilizando en todos los casos un núcleo común formado por componentes y conectores. La existencia de ese núcleo expresivo común facilitará dar forma a las relaciones entre Pág. 3-1 modelos. Únicamente, y por razones ya comentadas, se extenderá en la arquitectura de 4+1 vistas la capacidad de expresión jerárquica de los sistemas. UML 1.4 desarrolla estos conceptos y define una rica colección de vistas en forma de diagramas orientados a objetos, permitiendo múltiples enfoques para un mismo problema. La potencia de este lenguaje radica en su flexibilidad expresiva y capacidad de adaptación. Pero esta virtud le hace carecer de rigurosidad y formalidad cuando se trata de asegurar la coherencia global del modelo y sus instancias. Como uno de los requisitos del entorno multidisciplinar es la capacidad de validar la corrección de las instancias respecto al metamodelo, UML 1.4 parece incompleto como soporte de los metamodelos de dominio y sus instancias. Además, sigue careciendo de la jerarquía formal deseable. Como ambas carencias prometen ser paliadas en la próxima versión del lenguaje (UML 2.0), es una posibilidad de futuro la expresión de los metamodelos de dominio y sus instancias en este estándar. En la filosofía MDA (Model Driven Architecture) de OMG la definición y relación entre PIM y PSM, la formalidad introducida por MOF y la serialización de modelos e instancias con XMI tienen a UML como punto común de referencia. A pesar de ello, el que UML no sea el lenguaje inicialmente elegido para el modelado de dominio en el entorno no implica dar la espalda a todos los demás estándares. De hecho, se propone desarrollar el entorno en sintonía con esta filosofía y dejar preparado el camino para que en un futuro UML pueda ser el lenguaje de modelado inicial y XMI pueda tender directamente los puentes hacia la expresión en XML de esos modelos e instancias. XML sí parece colmar conjuntamente las necesidades de expresión flexible y adaptable a diferentes campos junto con la validación formal de las instancias. Su papel de metalenguaje, permitiendo la creación de lenguajes formales a través de schemas, y el complemento de XSL (transformaciones entre lenguajes) le hacen convertirse en un candidato ideal. Incluso si UML 2.0 (y estándares asociados) cumplen todas las expectativas, XML seguirá siendo necesario para el intercambio de información entre diferentes plataformas, entre diferentes herramientas MOF o entre herramientas MOF y otras no MOF (necesidad de validación previa). En resumen, en lo concerniente al modelado y expresión formal de la información en el entorno multidisciplinar se toman las siguientes decisiones: Definir los metamodelos de los cuatro dominios implicados. Los modelos o instancias de los mismos serán las descripciones del sistema desde los enfoques particulares. Usar schemas XML para definir los metamodelos de dominio. Éstos fijarán todos los requisitos a cumplir por las instancias (descripciones de sistemas particulares hechas de acuerdo al metamodelo de dominio). Estos schemas Pág. 3-2 XML servirán de gramáticas formales del lenguaje a emplear desde cada dominio. Construir los lenguajes extendiendo y especializando un núcleo expresivo común que soporte la descripción jerárquica del sistema en base a componentes y conectores. Seguir en la medida de lo posible los preceptos del MDA. Por una parte, distinguir el nivel de abstracción de la aplicación independiente de detalles (PIM), otro con detalles propios de la plataforma de desarrollo (PSM) y, por último, la implementación final. Por otra parte, establecer mecanismos para automatizar y formalizar el paso entre dichos niveles de abstracción. De este modo serán evidentes las ventajas obtenidas en cuanto a reutilización de modelos y formalización del proceso. Preparar la adopción futura de UML 2.0 como lenguaje soporte de los metamodelos de dominio. Esto permitiría : generación automática desde UML de gramáticas XML (schemas) e instancias (documentos) gracias a XMI o al empleo de perfiles que modulen la creación de XML a voluntad del diseñador generación automática desde UML del código que implemente los interfaces entre herramientas y modelos de dominio para diferentes plataformas (Java, C++, CORBA, ) adopción del perfil de tiempo real como metamodelo de dominio para STR (Sistemas de Tiempo Real) Cabe destacar que aunque se descarta el empleo de UML para el modelado formal de los dominios esto no implica que no pueda existir una herramienta UML integrada en el entorno. Una herramienta UML podría usarse, por ejemplo, para especificar la arquitectura SW del sistema, pero el resultado de su uso habría que expresarlo en XML y validarlo contra su metamodelo correspondiente (schema XML). Pág. 3-3 3.1.2 REQUISITOS Y COMPONENTES BÁSICOS DEL ENTORNO El análisis realizado en el Estado del Arte sobre las herramientas específicas de dominio habituales en cada uno de los campos de estudio, ha permitido identificar varios requisitos que deben guiar la construcción del entorno multidisciplinar de herramientas: La trazabilidad ha demostrado ser una propiedad fundamental cuando se trata de coordinar diferentes fases de desarrollo y aún más cuando se emplean diferentes herramientas. Esta propiedad deberá ser intrínseca al propio entorno y, por tanto, no basada en ninguna herramienta particular. El Núcleo del Entorno debe ser independiente de cualquiera de las herramientas integradas. Frente a la opción de tomar una herramienta suficientemente genérica como centro del entorno e ir ampliándola con módulos paralelos que complementen su funcionalidad, se opta por diseñar una arquitectura horizontal adecuada, con funcionamiento y formato de almacenamiento propios, e ir acomodando las herramientas específicas verticales a esta arquitectura y forma de trabajo. Para cada uno de los dominios específicos se han detectado conceptos clave que se constituyen en criterios de clasificación de grupos de herramientas y, por tanto, en parámetros de configuración para el Núcleo del Entorno: Sistemas Distribuidos. El Protocolo de Comunicación elegido para el sistema en desarrollo determina el grupo de herramientas de ayuda que pueden necesitarse. Sistemas de Tiempo Real. El Estilo de Arquitectura demuestra ser clave y tener implicaciones directas en herramientas de análisis, pero también en el diseño. Son limitados los estilos de arquitectura empleados en Sistemas de Tiempo Real (secuencial, dirigida a eventos, pipeline, cliente-servidor) pero no se va a diseñar un entorno que soporte uno solo de ellos, sino que se permitirá seleccionar el más adecuado en cada proyecto. El estilo elegido para el sistema en desarrollo determinará qué subconjunto de herramientas pueden usarse y qué sinergias existirán entre ellas. La Metodología es un concepto aún más amplio que engloba el estilo de arquitectura y restringirá aún más el número y forma de utilizar las herramientas. Ingeniería del SW. Es necesario el uso de un Proceso de SW adaptado a las necesidades de los SCDTR, pero configurable y modificable por el usuario en sus detalles para que se adapte a las necesidades propias del campo de aplicación y al Nivel de Madurez CMM de la organización. La visibilidad o expresión explícita del Proceso y su gestión desde una entidad Pág. 3-4 independiente de cualquier herramienta ofrecerá esta flexibilidad de cara al usuario. El Núcleo del Entorno debe ser flexible, para adaptarse con facilidad a necesidades futuras, y abierto para integrar en cada momento a la herramienta específica más adecuada. Esto se conseguirá a través del uso de estándares para la implementación de los componentes anteriores El Núcleo del Entorno se asemeja a los entornos I-CASE descritos en el capítulo anterior en que también debe ofrecer una arquitectura común en la que integrar herramientas de diferente naturaleza. Por ello, se identifican los siguientes Componentes Básicos, análogos a los de dichos entornos: Repositorio de información común a todas las herramientas. Componente de integración de modelos. Contiene la definición explícita de los cuatro metamodelos de dominio, sus relaciones y la relación de los metamodelos con las herramientas particulares en base a ciertos metadatos. Componente DIRECTOR, desde donde se controlan todos los mecanismos de activación, se comprueban y gestionan de forma global los errores, la integridad y la consistencia. Interfaces de herramientas. Debe estandarizarse el formato y protocolos de intercambio de datos entre las herramientas y el entorno. Interfaz de usuario común para la configuración del entorno. El estudio hecho en el Estado del Arte sobre algunos intentos de integración de dominios en forma de entornos de herramientas arroja las siguientes coincidencias entre varias soluciones propuestas: Uso de XML como formato preferido para la integración de información. Uso de Java como lenguaje de programación preferido para el SW de integración Uso de documentos (normalmente en XML) anexos a los módulos para describir la información necesaria para su integración con otros. Uso generalizado de la abstracción como concepto fundamental en el que basar la integración. Uso de gramáticas abstractas con los elementos sintácticos a emplear en todo el entorno, aunque luego se le añada la semántica particular de cada dominio. Uso de entidad director o similar para coordinar las diferencias semánticas entre dominios valiéndose de la estructura común de los lenguajes. Pág. 3-5 Concepto de METAframework o infraestructura necesaria para la composición de frameworks. Hasta ahora el diseño se ha centrado en la consideración de cuatro dominios y de las relaciones entre ellos, pero por qué sólo cuatro?, cómo se integraría uno más? Si se es capaz de expresar el metamodelo del que emergen los cuatro dominios, la definición de un nuevo modelo bajo esos mismos principios aseguraría su colaboración con los demás en el entorno. Esta idea del metamodelado se desarrollará para formalizar los mecanismos de ampliación de los dominios considerados en el entorno. El siguiente apartado definirá la estructura general del entorno, que estará compuesta por el conjunto de componentes aquí enumerados y permitirá satisfacer los requisitos identificados. La cohesión y coherencia del entorno se fundamentará en el uso de diferentes técnicas de integración a varios niveles. Pág. 3-6 3.1.3 ESTRUCTURA GENERAL Las pautas enumeradas conducen a un diseño del entorno como el mostrado en la Figura 3-1. Las herramientas particulares son empleadas por los especialistas en la manera habitual, pero se conectan como clientes al Motor de Colaboración de Herramientas (MCH), que hace las funciones de servidor. El tipo de servicio que ofrece el MCH es de almacenamiento, validación y coordinación de la información del SCDTR bajo desarrollo. El MCH ofrece estos servicios apoyándose en el Motor de Colaboración de Modelos (MCM). La capa más externa del MCH gestiona un flujo de información vertical y en ambos sentidos entre cada herramienta y el propio MCH, mientras que el MCM gestiona otro flujo de información transversal que permite coordinar y actualizar los datos que importan las herramientas. Existirá un amplio conjunto de herramientas particulares (siempre ampliable) registradas en el entorno, es decir, conocidas en cuanto a su comunicación con el MCH, la función que desempeñan, las informaciones que requieren intercambiar, etc. Pero cada proyecto requerirá para su desarrollo un subconjunto de herramientas de entre las registradas y el responsable del proyecto las seleccionará y configurará el entorno para su interacción a lo largo del proceso particular de dicho proyecto.... Especialistas... Herramientas... Interfaces MOTOR DE COLABORACIÓN DE HERRAMIENTAS (MCH) MOTOR DE COLABORACIÓN DE MODELOS (MCM) Figura 3-1. Estructura del entorno multidisciplinar La capa más externa del MCH debe resolver los interfaces a las herramientas particulares, así como al coordinador (que configura el funcionamiento del entorno para la gestión de cada proyecto). Pág. 3-7 Los componentes del Motor de Colaboración de Herramientas incluyen los que ya han sido mencionados, más la novedad de la entidad DIRECTOR, núcleo del MCM. En este componente se centralizan todas las actividades de integración: Control del proceso de desarrollo. En función de la información aportada por el coordinador se configurará el proceso y el DIRECTOR obligará a seguir las fases marcadas. Gestión de activaciones para invocar las acciones necesarias en cada momento. Control de la trazabilidad, íntimamente ligado al proceso SW seguido. Comprobación global de errores, coherencias e integridad de la información. Especialistas Coordinador Interfaz Config Metadatos DIRECTOR Modelos de Integración Interfaz herramientas Repositorios MOTOR DE COLABORACIÓN DE MODELOS (MCM) MOTOR DE COLABORACIÓN DE HERRAMIENTAS (MCH) Figura 3-2. Componentes del MCH. En la Figura 3-2 se puede apreciar cómo quedan los componentes del entorno con la inclusión del DIRECTOR y la expresión explícita de los modelos de interacción para su manipulación. Además, se identifican dos roles de usuarios del entorno: Coordinador de proyecto. Es quien impone al DIRECTOR, a través de un interfaz de configuración, las pautas a seguir en el uso de las herramientas externas. Tiene que conocer el funcionamiento del MCH para configurarlo. Define el conjunto concreto de herramientas a usar, un estilo de arquitectura o metodología de tiempo real determinada, protocolos de comunicación para la distribución del control, un determinado proceso de SW, etc. Estas decisiones, que determinarán las sinergias e incompatibilidades que entran en juego, sirven para configurar el módulo Pág. 3-8 DIRECTOR. Toda esta información se empleará para coordinar todo el entorno a lo largo de la vida del proyecto. Especialista. Usuario final de cada una de las herramientas integradas. Hace uso de una herramienta bien conocida a partir de la información que le facilita el entorno y de las pautas indicadas por el coordinador. El diagrama de componentes básicos mostrado en la Figura 3-2 se irá completando en más detalle a lo largo del presente capítulo y se desarrollará el diseño final de cada bloque en el capítulo siguiente. Pág. 3-9 Pág. 3-10 3..2 NIIVELES DE INTEGRACIIÓN Sobre lo que se entiende por integración y las técnicas disponibles para lograrla a diferentes niveles. Una vez establecido que las diferentes herramientas del entorno se integrarán gracias a un Motor de Colaboración de Herramientas (MCH) externo que guíe el proceso, cabe preguntarse qué técnicas son las más apropiadas para que el MCH logre ese propósito de integración. Dado un conjunto de aplicaciones autónomas, cada una ejecutándose en su propio contexto, la interacción entre ellas se consigue si: 1. Existe una conexión física y un protocolo de comunicación para que los datos fluyan en
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x