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

Tamaño: px
Comenzar la demostración a partir de la página:

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

Transcripción

1 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.

2 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 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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

11 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

12 Pág. 3-10

13 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 entre los contextos de ejecución de las aplicaciones. Actualmente, la omnipresencia de internet con sus protocolos TCP/IP hace que sea la opción más estándar para el intercambio de información entre dos aplicaciones cualesquiera independientemente de su ubicación. 2. Existe un acuerdo en el formato de los datos para su intercambio (texto ASCII, XML, representación en memoria, chorro de bits ). Por las razones aducidas en el capítulo anterior, XML se perfila como el formato más estándar, universal y de amplia aceptación. 3. Existe un acuerdo en el léxico y sintaxis empleados para la expresión de la información. 4. Existe un acuerdo respecto a los tipos de datos (rangos válidos, herencia, polimorfismo, estructuras, ). 5. Existe un acuerdo en el significado que se da a los datos, lo que se espera de ellos, las relaciones que se establecen, el procesado que se les dará. 6. Existe un acuerdo en la relación o manera de mantener la coherencia entre cualesquiera dos datos de dos herramientas diferentes pero con una relación semántica conocida. 7. Existe un acuerdo en los interfaces que cada aplicación ofrece para la entrada y salida de datos Los puntos 3, 4 y 5 hacen referencia a un acuerdo en cuanto a la gramática empleada, que como se verá, tiene que reflejar las peculiaridades de cada campo de aplicación pero manteniendo un núcleo común a todas las demás. Para lograr una solución abierta y flexible, los puntos 6 y 7 conviene resolverlos de forma Pág. 3-11

14 acorde a tecnologías estándares y ampliamente aceptadas, que se discutirán a lo largo de este apartado. En definitiva, se trata de llegar a acuerdos entre las partes implicadas, pero estos acuerdos pueden ser de muy diversa naturaleza: Acuerdos tácitos o explícitos. En ocasiones, se siguen acuerdos no escritos para hacer que se entiendan dos aplicaciones. En este trabajo se intenta hacer explícito cualquier acuerdo porque esto es necesario para poder modificar los términos del acuerdo o para generalizarlo y lograr la interacción con otras aplicaciones cualesquiera. Acuerdos punto a punto o genéricos. Para comunicar dos aplicaciones basta con ponerse de acuerdo entre ellas, pero para lograr comunicar un número indeterminado de aplicaciones no definidas de antemano, es necesario imponer unas normas genéricas que permitan interactuar a toda aplicación que las cumpla. La propia interacción entre las aplicaciones puede ser manual o guiada. Es decir, dirigida a su libre albedrío por el usuario (que indica en qué momento invocar una aplicación y con qué datos trabajar) o conducida por una entidad directora que siga unas reglas prefijadas y regule los pasos a seguir, los datos a emplear y la coherencia de todo el proceso. Como ya se ha descrito, los procesos y metodologías para el desarrollo de SW requieren de una regulación de las fases de su ciclo de vida que aconseja una interacción guiada. Por ello se propone que sea llevada a cabo por la entidad DIRECTOR. Una vez que las aplicaciones son capaces de interactuar (porque se han resuelto de alguna manera los 7 puntos anteriores) se pueden definir diferentes niveles de integración: Aplicaciones integrables. Por cumplir todos los requisitos para interactuar se puede escribir un SW que las integre. Aplicaciones integradas entre tiempos de ejecución. Cada aplicación funciona según sus propios tiempos pero los resultados que se obtienen al terminar su uso se sincronizan con la información que ya existía. Por cada uso de una aplicación se comprobará la coherencia de los resultados con todo lo anterior. Aplicaciones integradas en tiempo de ejecución. En el propio tiempo de ejecución, una aplicación es capaz de comunicase e interactuar con otras. En definitiva, se pueden completar un poco más las características del MCH añadiendo las siguientes: El MCH usará conexiones sobre TCP/IP para comunicarse con las herramientas. Pág. 3-12

15 La información a intercambiar entre herramientas y MCH se expresará en formato XML. Siendo así, lo más lógico es que los repositorios también almacenen la información en este formato. Se definirán gramáticas XML ajustadas a las necesidades de cada uno de los dominios: Ingeniería de Control (IC), Sistemas Distribuidos (SD), Sistemas de Tiempo Real (STR) e Ingeniería del SW (IS). De este modo, la información intercambiada entre una determinada herramienta y el MCH se expresará siempre en la gramática propia de su dominio. El DIRECTOR llevará a cabo una integración entre tiempos de ejecución, es decir, se encargará de sincronizar la información global cada vez que se reporten resultados desde alguna de las herramientas. Los acuerdos necesarios para la integración de herramientas se hacen genéricos ya que hacen referencia a las interacciones entre los diferentes dominios específicos y no a la existente entre herramientas concretas. Estos acuerdos se engloban en un conjunto de Modelos de Dominios que estarán íntimamente ligados a las Gramáticas de Dominio. Los acuerdos se hacen explícitos porque se expresan en forma de modelos y gramáticas modificables, y por tanto extensibles. La Figura 3-16 muestra como queda el MCH con estas aportaciones. El DIRECTOR lleva la iniciativa y usa los servicios que le ofrecen las aplicaciones de forma coordinada y coherente, basándose en los modelos y gramáticas de dominio. Pág. 3-13

16 Gramática de dominio común para diferentes herramientas IC IC SD STR IS Información en la gramática XML de cada dominio Información XML sobre conexiones TCP/IP Interfaz Config Interfaz Herramientas DIRECTOR Sincronización en instantes de entrada / salida de información desde una herramienta Modelos Gramáticas Dominios XML Dominios Metadatos Repositorios XML Figura 3-3. Estructura del MCH. En los siguientes apartados se presentarán algunas técnicas adecuadas para la implementación de cada una de las partes de este esquema. Concretamente, y por orden de aparición de los apartados, se describirán soluciones para los bloques de Gramáticas (3.3 Integración de Gramáticas), Modelos de Dominio (3.4 Integración de Modelos), DIRECTOR (3.5 Integración de Técnicas para Desarrollo de SW), Repositorio (3.6 Integración de Conocimiento) e Interfaz de Herramientas (3.7 Integración de Aplicaciones). Pág. 3-14

17 3..3 INTEGRACIIÓN DE GRAMÁTIICAS Sobre los niveles de servicio que puede implementar una gramática y el grado de compatibilidad entre gramáticas distintas. Para que varias personas se puedan comunicar y se entiendan entre sí, es necesario que empleen el mismo lenguaje. Del mismo modo, para que puedan comunicarse entre sí un conjunto de herramientas deben expresar, hasta cierto punto, de la misma forma aquellas informaciones que pretendan intercambiar. La solución podría ser la creación de un lenguaje común, lo suficientemente rico y extenso como para cumplir dos requisitos: El lenguaje debe poder describir la información que manejen todas las herramientas a integrar. El lenguaje debe poder representar todas las relaciones cruzadas entre informaciones de diferentes herramientas. Esta solución permitiría importar y exportar toda información entre herramientas, siempre que estuviera expresada en ese lenguaje. El problema surgiría cada vez que se pretenda integrar una nueva herramienta no considerada en un principio. Si el lenguaje común no fuera capaz de expresar algún tipo de información manejada por la nueva herramienta, sería necesaria su modificación y ampliación. Para ganar flexibilidad y generalidad en la solución, conviene usar un lenguaje más abstracto en el que se asuman sólo unos pocos elementos comunes a la información de todas las herramientas que pretendan ser integradas. Se va a profundizar a continuación en un proyecto que trabaja en esta línea de investigación, el GSRC Semantics Project. Pág. 3-15

18 3.3.1 GSRC SEMANTICS PROJECT Gigascale Silicon Research Center (http://www.gigascale.org/) es una entidad que aúna los esfuerzos de multitud de grupos de investigación para el diseño y test de sistemas empotrados. Uno de sus proyectos es el GSRC Semantics Project (http://www.gigascale.org/semantics). Este proyecto persigue la interoperatividad de herramientas para el diseño de sistemas. Identifican el mismo problema que se ha descrito en el primer capítulo de esta memoria, es decir, la necesidad de enfocar un mismo sistema de diferentes formas para tratar diferentes problemas y la dificultad de conseguir que los cambios producidos en uno de estos enfoques sigan siendo coherentes en los demás. Tal y como muestra la Figura 3-4, se pueden obtener múltiples facetas de un sistema al proyectarlo respecto a diferentes ejes o puntos de vista pero si se modifica una de esas facetas hay que conseguir que siga siendo coherente con las demás. Por otra parte, también es deseable poder manejar diferentes niveles de abstracción para cada una de las facetas (Figura 3-5). Figura 3-4. Proyección de las facetas de un sistema y su consistencia. Estas facetas se pueden identificar con las representaciones del sistema de acuerdo a diferentes herramientas y lograr la coherencia entre las mismas sería lo mismo que conseguir interoperatividad entre las herramientas. Para lograr esta interoperatividad, no buscan la creación de un lenguaje estándar de diseño común para todas, si no que intentan identificar el uso de ciertos elementos comunes y formalizarlos para establecer la base común a todas las herramientas. De este modo, definen modelos sintácticos y semánticos para el diseño de sistemas basándose en el uso de componentes, su interacción y su composición (Lee 2000). Pág. 3-16

19 Figura 3-5. Niveles de abstracción de cada faceta. En la especificación de un lenguaje se aúnan las descripciones de varias propiedades ortogonales. El tratamiento por separado de las mismas permite varios niveles de compatibilidad. La definición de un lenguaje puede dividirse en cinco partes (servicios) agrupadas en dos bloques: Estructura lógica: Sintaxis abstracta. Define cómo un diseño puede dividirse en componentes interconectados. El conjunto de componentes y relaciones que pueden aparecer en un diseño conforman una sintaxis abstracta. Sintaxis concreta, notación. Define cómo un diseño puede ser representado y manipulado en un formato persistente y usable por el ordenador (XML, APIs, fichero ASCII, gráfico, ). Pueden existir múltiples sintaxis concretas derivadas de una única sintaxis abstracta. Transformaciones sintácticas. Un conjunto de operaciones (tanto estáticas como dinámicas) permiten transformar un diseño en otro. Significado: Sistema de tipos. Regulan los datos compartidos por los componentes y aseguran que se cumplen los requisitos que los componentes imponen a esos datos. El polimorfismo es una cualidad conveniente para dar generalidad a los diseños. Semánticas (de componentes y de interacción). Da significado a las características de cada componente y a sus conexiones con otros. Un determinado diseño se representa con un lenguaje concreto que incluye los cinco servicios mencionados. Sin embargo, las herramientas que se utilizan para manejar ese modelo no tienen porque ser conscientes de todas las partes del lenguaje. Habrá herramientas que soporten sólo alguna de las partes del lenguaje. Pág. 3-17

20 Por ejemplo, un visualizador gráfico que muestre las relaciones entre componentes no necesita conocer la semántica ni los tipos (le basta con conocer la sintaxis abstracta), mientras que un motor de inferencia de tipos necesita conocer el sistema de tipos además de la sintaxis abstracta. En base a estos conceptos se puede clasificar la interoperatividad entre herramientas a diferentes niveles: 1. Sintaxis abstracta compatible. Es posible escribir SW ad hoc que convierta datos de una herramienta en datos utilizables en otra. 2. Sintaxis concreta compatible. Una herramienta puede leer datos en el formato persistente de otra (ficheros externos) sin necesidad de escribir SW especial. 3. Transformaciones sintácticas compatibles. Es posible generar automáticamente datos de entrada para una herramienta a partir de los resultados de otra. 4. Sistema de tipos compatible. Intercambio automático de modelos de datos completos entre herramientas. 5. Semánticas compatibles. Las herramientas pueden intercambiar datos dinámicamente, en tiempo de ejecución. Cuando se busca la interoperatividad entre un conjunto lo suficientemente amplio y diverso de herramientas de diseño, enseguida es evidente que no basta con un único formato estándar para representar adecuadamente una sintaxis y semántica común para todas. Existe una variedad de modelos semánticos para sistemas basados en componentes y cada uno tiene sus ventajas y su campo de aplicación. Por ello, se busca un acuerdo en lo más básico, la sintaxis abstracta. Una sintaxis abstracta común para herramientas de diseño de sistemas debe ser capaz de describir listas de conectividad, diagramas de transición de estados, diagramas de bloques, modelos de objetos y estructuras gráficas, además de permitir el uso extensivo de la jerarquía para lograr escalabilidad. Éstas son las características que reúne la sintaxis abstracta GSRC. Resumen de las características del proyecto GSRC: Definición por separado de cada una de los cinco servicios constitutivos de un lenguaje: Sintaxis abstracta. Definición de componentes y posibles relaciones entre ellos, capacidades de jerarquía, conectividad e instanciación de clases. Sintaxis concreta. MoML es una sintaxis concreta XML para la sintaxis abstracta de GSRC. MoML no añade significado al modelo, en su lugar, permite añadir un director al modelo. El director definirá la semántica de las conexiones pero para MoML no es más que la referencia a una instancia que cargará el cargador de clases. Pág. 3-18

Enterprise Analyst: Taller de Bautizo

Enterprise Analyst: Taller de Bautizo Enterprise Analyst: Taller de Bautizo Metas Entender la Necesidad de Ejecutar los Modelos Desarrollar un caso usando UML tradicional Identificar los problemas de UML Conocer la Herramienta Enterprise Analyst

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Administración de Variabilidad en una línea de producto basada en modelos

Administración de Variabilidad en una línea de producto basada en modelos Administración de Variabilidad en una línea de producto basada en modelos Kelly Garcés Carlos Parra Hugo Arboleda Andres Yie Rubby Casallas Universidad de los Andes, Bogotá k-garces @uniandes.edu.co Universidad

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software Fundamentos de Ingeniería del Software Capítulo 11. Reutilización del software Reutilización del software. Estructura 1. Reutilización del software 2. Beneficios de la reutilización 3. Dificultades para

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

con certif icado de profesionalidad

con certif icado de profesionalidad CARACTERÍSTICAS El diseño web está cambiando en poco tiempo. Las nuevas tecnologías y estándares de programación están revolucionando tanto la forma de crear web como de interactuar con ellas. En nuestro

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Módulo Profesional 01: Bases de datos (código: 0484).

Módulo Profesional 01: Bases de datos (código: 0484). Módulo Profesional 01: Bases de datos (código: 0484). Actividades de enseñanza-aprendizaje que permiten alcanzar los objetivos del módulo. Interpretar diseños lógicos de bases de datos. Realizar el diseño

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

2 E STADO DEL ARTE Modelado Lenguajes Formales UML XML Herramientas Específicas de Dominio Aproximaciones a la Integración de Herramientas

2 E STADO DEL ARTE Modelado Lenguajes Formales UML XML Herramientas Específicas de Dominio Aproximaciones a la Integración de Herramientas 2 ESTADO S DEL ARTE Este capítulo se concibe como una exposición sobre la situación actual en cuanto al empleo de entornos multidisciplinares en el desarrollo de SW para SCDTR. Esta exposición se hace

Más detalles

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez

Más detalles

INGENIAS: Desarrollo dirigido por modelos de SMA

INGENIAS: Desarrollo dirigido por modelos de SMA INGENIAS: Desarrollo dirigido por modelos de SMA Juan Pavón Mestras jpavon@pdi.ucm.es Dep. de Ingeniería del Software e Inteligencia Artificial Universidad Complutense Madrid http://grasia.fdi.ucm.es Objetivo

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

TEMA 1: INTRODUCCIÓN

TEMA 1: INTRODUCCIÓN 1 DISEÑO Y DESARROLLO DE COMPILADORES TEMA 1: INTRODUCCIÓN Qué es un Compilador? Un compilador no es más que un traductor, es decir, un programa que nos permite pasar información de un lenguaje a otro.

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

BOA, un framework MDA de alta productividad

BOA, un framework MDA de alta productividad BOA, un framework MDA de alta productividad Padrón Lorenzo, J. 1, Estévez García A. 1, Roda García J.L. 2, García López F. 2 1 Open Canarias SL, Santa Cruz Tenerife, España http://www.opencanarias.com

Más detalles

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

Más detalles

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO

DOCUMENTACION A PRESENTAR: TRABAJADORES (RÉGIMEN GENERAL, ADMINISTRACIÓN PÚBLICA, AUTÓNOMOS) DEMANDANTES DE EMPLEO MF0492_3 PROGRAMACION WEB EN EL ENTORNO SERVIDOR (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 240 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 217 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

4 o Ingeniería Informática

4 o Ingeniería Informática Esquema del tema 1. Introducción 4 o Ingeniería Informática II26 Procesadores de lenguaje Estructura de los compiladores e intérpretes 2. Etapas del proceso de traducción 3. La interpretación 4. La arquitectura

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Una Arquitectura para una Herramienta de Patrones de Diseño

Una Arquitectura para una Herramienta de Patrones de Diseño Una Arquitectura para una Herramienta de Patrones de Diseño José Sáez Martínez 1, Jesús García Molina, Pedro J. Jiménez García Departamento de Informática, Lenguajes y Sistemas. Campus de Espinardo C.P.

Más detalles

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de GLOSARIO Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de una descripción de bajo nivel (código fuente) para generar descripciones con un mayor grado de abstracción.

Más detalles

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic

ARQUITECTURAS ORIENTADAS A SERVICIOS. SOA en la Seguridad Social. 48 boletic ARQUITECTURAS ORIENTADAS A SERVICIOS SOA en la Seguridad Social por Mario triguero garrido 48 boletic El deber de ofrecer al ciudadano el mejor servicio ha sido siempre la motivación por la cual la Gerencia

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN Tema 2. Tecnologías CASE Escuela Superior de Informática 1 Tema 2. Tecnologías CASE. Tecnologías CASE (~ 4 horas) Introducción. Conceptos, Objetivos, Herramientas

Más detalles

Informe de avance Implementación herramientas de back-end (3-III).

Informe de avance Implementación herramientas de back-end (3-III). Proyecto RG-T1684 Desarrollo e implementación de las soluciones Prueba piloto del Componente III Informe Número 1. Informe de avance Implementación herramientas de back-end (3-III). Lautaro Matas 11/04/2013

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

SUPLEMENTO EUROPASS AL TÍTULO

SUPLEMENTO EUROPASS AL TÍTULO SUPLEMENTO EUROPASS AL TÍTULO DENOMINACIÓN DEL TÍTULO Técnico Superior en Desarrollo de Aplicaciones Web --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB DENOMINACIÓN: CON TECNOLOGÍAS WEB Código: IFCD0210 Familia profesional: Informática y Comunicaciones Área profesional: Desarrollo Nivel de cualificación profesional: 3 Cualificación profesional de referencia:

Más detalles

Generación de código para Hibernate desde modelos UML

Generación de código para Hibernate desde modelos UML Generación de código para Hibernate desde modelos UML Alejandro Nogueiro Mariscal Ingeniería Técnica en Informática de Sistemas, Universidad de Cádiz 24 de Septiembre 2012 1 / 35 Índice 1 Motivación y

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

BASES DE DATOS MIS 308

BASES DE DATOS MIS 308 2. MODELOS DE DATOS Introducción 2.1 Entidad relación 2.2 Jerárquico 2.3 De red 2.4 Relacional Introducción Hoy en día las empresas manejan una gran cantidad de datos. Cualquier empresa que se precie debe

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

LENGUAJES DE PROGRAMACIÓN POR QUÉ HAY TANTOS Y APARECEN NUEVOS? Por: Hanna Oktaba

LENGUAJES DE PROGRAMACIÓN POR QUÉ HAY TANTOS Y APARECEN NUEVOS? Por: Hanna Oktaba LENGUAJES DE PROGRAMACIÓN POR QUÉ HAY TANTOS Y APARECEN NUEVOS? Por: Hanna Oktaba La computadora, a diferencia de otras herramientas que en general apoyan el esfuerzo físico de los humanos, fue inventada

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Memoria Compartida Distribuida (DSM) Sistema de Archivos

Memoria Compartida Distribuida (DSM) Sistema de Archivos Memoria Compartida Distribuida (DSM) La memoria compartida distribuida es una abstracción que se propone como alternativa a la comunicación por mensajes. Memoria compartida basada en páginas: este esquema

Más detalles

Desarrollo de Software con enfoque en el Negocio

Desarrollo de Software con enfoque en el Negocio Desarrollo de Software con enfoque en el Negocio Andrea Delgado Instituto de Computación Facultad de Ingeniería Universidad de la República 11300, Montevideo, Uruguay adelgado@fing.edu.uy Resumen Las Organizaciones

Más detalles

Capí tulo IV. Lenguajes de estilo

Capí tulo IV. Lenguajes de estilo Capí tulo IV Lenguajes de estilo Lenguajes de Estilo Hojas de estilos Mecanismos de Hojas de estilos previos a XSL Lenguaje de estilo XSL Comparación entre CSS y XSL Transformación XML/XSL en aplicativos

Más detalles

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO)

Introducción a la Programación Orientada a Objetos (POO) Introducción a la Programación Orientada a Objetos (POO) Diseño Orientado a Objetos. Metodología enfocada a la solución de problemas complejos. Complejidad del software. Problemas difíciles de precisar. Definición de requerimientos vago y cambio en el desarrollo

Más detalles

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado Diseño lógico de sistemas aplicando el lenguaje de modelado unificado No. De Registro CGPI: 20061221. Director del proyecto: Roberto De Luna Caballero. Profesores participantes: M. en C Fabiola Ocampo

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

GENERALIDADES DE LA COMUNICACIÓN DE DATOS

GENERALIDADES DE LA COMUNICACIÓN DE DATOS Comunicaciones I Capítulo 1 GENERALIDADES DE LA COMUNICACIÓN DE DATOS 1 El Sistema de Comunicación Sistema de comunicación: Lleva a cabo el intercambio de información entre dos entes ubicados en los extremos

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad

Más detalles

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz

Compiladores y Lenguajes de Programación. Maria de Guadalupe Cota Ortiz Compiladores y Lenguajes de Programación Maria de Guadalupe Cota Ortiz Organizaciones que rigen las normas para estandarización de Lenguajes de Programación IEEE (Instituto de Ingenieros Eléctricos y Electrónicos)

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA

GUÍA DE EVIDENCIA DE LA UNIDAD DE COMPETENCIA MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Programación de red con Cisco Application Centric Infrastructure

Programación de red con Cisco Application Centric Infrastructure Informe técnico Programación de red con Cisco Application Centric Infrastructure Descripción general En este documento se examina la compatibilidad de la programación de Cisco Application Centric Infrastructure

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

UNA EXPERIENCIA PRÁCTICA DE INTEGRACIÓN DE SISTEMAS HETEROGÉNEOS DIRIGIDA POR MODELOS

UNA EXPERIENCIA PRÁCTICA DE INTEGRACIÓN DE SISTEMAS HETEROGÉNEOS DIRIGIDA POR MODELOS UNA EXPERIENCIA PRÁCTICA DE INTEGRACIÓN DE SISTEMAS HETEROGÉNEOS DIRIGIDA POR MODELOS Gerente de Informática de Diputación IZFE, S.A. (Diputación Foral de Gipuzkoa) Analista IZFE, S.A. (Diputación Foral

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8 Documento de Competencias Grado en INGENIERÍA INFORMÁTICA Facultad de Informática, UPV/EHU 1 Estructura general del Grado 1.1 Fundamentos de Tecnología de los Principios de Diseño de Sistemas Digitales

Más detalles

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Ingeniería de Software I Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Quienes somos? 2 Quienes son? 3 Objetivos del Curso Entender el rol fundamental que juega la construcción y análisis

Más detalles

Capítulo 5. Implementación y Tecnologías Utilizadas

Capítulo 5. Implementación y Tecnologías Utilizadas Capítulo 5. Implementación y Tecnologías Utilizadas Cada vez más, se está utilizando Flash para desarrollar aplicaciones basadas en Web, pues permite la construcción de ambientes con mayor interacción.

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso.

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso. TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE Dr. E.T.S.I. Informática de Sistemas. 3 er Curso. Año 2004/2005 Visión General Importancia de la Ingeniería del Software. Retraso en la llegada de la Ingeniería

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

INDICE Parte I. Conceptos 1. El estudio de los lenguajes de programación 2. Cuestiones de diseño de lenguajes

INDICE Parte I. Conceptos 1. El estudio de los lenguajes de programación 2. Cuestiones de diseño de lenguajes INDICE Parte I. Conceptos 1 1. El estudio de los lenguajes de programación 1.1. Por qué estudiar lenguajes de programación? 2 1.2. Breve historia de los lenguajes de programación 1.2.1. Desarrollo de los

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 6 Situación Contraste externo Actualización

Más detalles

SPEM - Software & Systems Process Engineering Metamodel Specification

SPEM - Software & Systems Process Engineering Metamodel Specification SPEM - Software & Systems Process Engineering Metamodel Specification 1. ALCANCE: El propósito de éste documento es proporcionar una definición comprensible del meta-modelo de ingeniería de procesos de

Más detalles