Por último, se repasan los conceptos de MDA que han sido desarrollados en el entorno.

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

Download "Por último, se repasan los conceptos de MDA que han sido desarrollados en el entorno."

Transcripción

1 4 EL ENTORNO Las conclusiones del capítulo anterior esbozaban una primera aproximación a la arquitectura e identificaban las tecnologías más apropiadas para el diseño e implementación de cada uno de los componentes ó módulos del entorno. En este capítulo se definirá todo ello con mayor detalle, profundizando en cada una de las técnicas elegidas y diseñando la solución más adecuada. En cualquier caso, entre los objetivos de la investigación no se encontraba el de la construccion de un prototipo del entorno, que sera abordado en trabajos posteriores. Sin embargo, si se han implementado algunos prototipos que se describen en el Anexo D: Prototipos Desarrollados. Estos constituyen implementaciones parciales del entorno multidisciplinar, y su objetivo es demostrar la viabilidad del diseño propuesto. Comienza el capítulo ubicando el uso de XML en el entorno. Se diferencia su empleo como notación para modelos formales de su utilización como pequeño lenguaje de propósito específico. Respecto a la primera de sus aplicaciones, se describe su uso en la descripción de los metamodelos y la validación correspondiente de las instancias. Por otra parte, se identifican todos los pequeños lenguajes XML que se requieren para lograr un diseño declarativo del entorno. A continuación, se realiza una exposición paralela al capítulo anterior ya que cada apartado describe la solución planteada para resolver la integración de gramáticas, modelos, técnicas de desarrollo de SW, conocimiento y aplicaciones. Por último, se repasan los conceptos de MDA que han sido desarrollados en el entorno.

2 4.1 Uso de XML en el Entorno Notaciones para Modelos Formales Pequeños Lenguajes 4.2 Integración de Gramáticas Estructura Común Lenguajes Sintaxis Abstracta Sintaxis Concreta Transformaciones Sintácticas Significado Particular Lenguajes Ampliación y Generalización 4.3 Integración de Modelos Metamodelos para un SCDTR Metamodelo de Ingeniería de Control Metamodelo de Sistemas Distribuidos Metamodelo de Sistemas de Tiempo Real Relaciones entre Metamodelos de SCDTR Implicaciones entre Componentes Específicos de Dominio Mapeos entre Dominios 4.4 Integración de Técnicas para Desarrollo de SW Ciclo de Vida Subproceso de Especificación Formal Subproceso de Generación de Código Especificación Formal Paradigma Modelo-Vista-Control Implementación (J2EE, Struts, Cocoon) Generación Automática de Código Paradigma Workflow Implementación (Apache Ant) Lenguajes de Dominio CTWML (Code Template Wrapper Markup Language) SADML (SW Architecture Description Markup Language) SEPML (SW Engineering Process Markup Language) Configuración del Proceso SW 4.5 Integración de Conocimiento 4.6 Integración de Aplicaciones WSDL (Web Service Description Language) 4.7 Conceptos MDA en el Entorno

3 4..1 USO DE XML EN EL ENTORNO Sobre las potencialidades de XML aplicadas al entorno multidisciplinar y sobre su doble papel como notación grande para el modelado formal o como pequeño lenguaje para la solución de cuestiones muy específicas. A lo largo del capítulo anterior, en la discusión sobre las técnicas de integración, han aparecido en bastantes ocasiones los términos lenguaje y gramática aplicados a la resolución de problemas muy diferentes. Esto es así, porque ya se había establecido en el primer capítulo que uno de los criterios de diseño del entorno iba a ser el uso del estilo de programación declarativa (frente a la imperativa), enfatizando el qué en lugar del cómo, abstrayendo la funcionalidad y separándola de la implementación. En todos los casos se han enfatizado las bondades de XML como metalenguaje común en el que definir todos estos nuevos lenguajes o gramáticas específicas. La principal de las ventajas es el uso de un único intérprete estándar para todos los lenguajes XML que se empleen, no será necesario programar parsers específicos para cada una de las gramáticas. XML permite conjugar así las necesidades de adaptación a las peculiaridades expresivas que requiera cada lenguaje con el empleo de mecanismos comunes de validación para todos los lenguajes. Incluso en algunos casos, se ha aludido a la relación directa que se podía establecer con UML a través del estándar XMI. En el segundo capítulo se introdujeron algunas nociones básicas de XML, pero el anexo B.1. Tecnologías Básicas en XML profundiza un poco más en las técnicas y utilidades XML concretas que mejor se adaptan a las necesidades del entorno multidisciplinar. La lectura de este anexo es recomendable para entender dónde y cómo encajan estas tecnologías dentro del entorno y para comprender las explicaciones de diseño que se ofrezcan en este capítulo. Muy resumidamente, este anexo ensalza la utilidad de: XML Schema como lenguaje para definición de schemas en el que se expresa el modelo a seguir en las instancias (se describe lo único válido en ellas) utilizando una estructura en árbol con un detallado sistema de tipos y propiedades de orientación a objetos. Schematron como lenguaje para la definición de reglas de validación respecto a los contenidos de una o varias instancias XML. XSLT como lenguaje especializado en la transformación de un documento XML en otro con diferente estructura y/o contenidos. Pág. 4-1

4 XSL-FO como lenguaje especializado en la transformación de un documento XML con el formato de presentación final (HTML, PDF, texto plano, SVG, ). En definitiva, XML se ajusta muy bien a los criterios de diseño enumerados en el primer capítulo para el entorno: tratamiento de lo específico a partir de una estructura genérica común, extensibilidad, flexibilidad, estilo declarativo, bajo coste y uso de estándares y tecnologías con proyección de futuro. A pesar de poseer un origen común, se antoja necesario alinear todos estos lenguajes con algún criterio claro que permita ver con mayor nitidez las diferencias y el papel que juega cada uno de ellos en el entorno. En los siguientes apartados se perfila una clasificación de todo este conjunto de lenguajes basados en XML. Se diferencian las Notaciones para Modelos Formales y los Pequeños Lenguajes. Pág. 4-2

5 4.1.1 NOTACIONES PARA MODELOS FORMALES Las cuatro gramáticas asociadas a cada uno de los dominios involucrados sirven como notaciones para expresar instancias de los metamodelos o visión que tiene cada especialista de un mismo sistema. Por tanto, cada fichero XML contiene una descripción o especificación del sistema en desarrollo desde el punto de vista de un especialista. Se puede establecer un paralelismo entre el uso de la notación gráfica UML y el uso de XML para realizar dichas descripciones o especificaciones. Tanto el schema que delimita cada una de las gramáticas, como sus instancias o descripciones de sistemas concretos realizadas bajo esos parámetros, pueden ser generadas automáticamente a partir de modelos UML y empleando el estándar XMI. Concretamente, es XML Schema el lenguaje de schema que mejor permite reflejar en XML los modelos realizados en UML. XML Schema facilita la descripción de un modelo de dominio gracias a las siguientes características: propiedades de orientación a objetos (herencia, extensibilidad, polimorfismo), capacidad de instanciación, espacios de nombre, riqueza de tipos de datos predefinidos y posibilidades de personalización, expresión formal de relaciones entre elementos, estructura jerárquica en forma de árbol, atributos para recoger las propiedades de los elementos, validación formal de las instancias mediante un parser genérico y transformaciones XSLT para exportar o importar información entre modelos. XML es un meta-lenguaje que permite definir formalmente lenguajes de marcas, de forma que el lenguaje definido sirva para expresar un modelo concreto de información. Se puede sintetizar en 3 niveles la arquitectura de abstracción XML (ver Figura 4-1): Lenguaje genérico de XML Schema. Constituye un meta-modelo de datos. Permite describir descripciones de datos. Define el meta-lenguaje que puede emplearse para construir lenguajes específicos. Lenguaje particular definido en un Schema XML. Constituye un modelo de datos. Permite describir datos. Define el lenguaje que se empleará para describir ciertos datos particulares. Documento XML. Descripción de datos en base al lenguaje definido por el schema. Metamodelo de datos Modelo de datos Información (datos) XML-Schema Schema XML Documento XML Figura 4-1. Niveles de abstracción XML. Pág. 4-3

6 Dicho de otro modo, XML proporciona los recursos necesarios (XML-Schema) para expresar formalmente el modelo (Schema) que deben seguir unos datos concretos (documento XML). Es un meta-lenguaje porque permite definir lenguajes, permite crear modelos y validar sus instancias. Se puede decir que XML es una herramienta muy potente para EXPRESAR modelos en un formato estándar, validable y serializable, mientras que UML es más adecuado para DEFINIR modelos, puesto que cuenta con más recursos expresivos y más intuitivos (diferentes tipos de diagramas) aunque menor capacidad de validación. Pero pueden complementarse las cualidades de ambos, tal y como muestra el estándar XMI. Dentro de la arquitectura MDA de OMG, los niveles MOF se utilizan para describir un meta-modelo de aplicación en UML, que se instancia en modelos de aplicaciones concretas (también UML), de los que a su vez se derivan las implementaciones finales de cada aplicación (apoyándose en mapeos a CORBA, C++, ). En este contexto, XMI supone un mapeo automático entre MOF (ó UML) y XML. Mapeo que permite obtener automáticamente a partir de descripciones UML, tanto el schema con el meta-modelo de aplicación como los documentos XML con modelos concretos de aplicación (ver Figura 4-2). Meta-modelo de aplicación MOF 2-UML XMI Schema XML Modelo de aplicación MOF 1-UML Documento XML Información (Aplicación) MOF 0 Figura 4-2. Niveles MOF-UML y mapeo habitual a XML. Mientras que en el caso de MOF-UML (Figura 4-2) lo más habitual es que el nivel inferior (información a modelar) se identifique con una aplicación particular, en XML (Figura 4-1) la información que se modela son datos de cualquier naturaleza. En el caso del entorno multidisciplinar, para cada vista, la información a modelar es el conjunto de datos sobre un SCDTR relevantes para un especialista. Es decir, se alinea el nivel inferior con el conjunto de datos que describen un SCDTR. Se pretende definir formalmente la información que constituye un SCDTR para después establecer cómo una herramienta cualquiera (en principio desconocida) deberá interactuar con esa información. Así, la Figura 4-3 muestra estos niveles que identifican al schema de cada vista con un metamodelo de datos y a sus instancias como modelos de datos del SCDTR. La figura muestra sombreado en gris la situación futura en la que se liguen los schemas e instancias XML a UML y MOF a través de XMI. Pág. 4-4

7 Meta-modelo de datos Schema XML XMI MOF 2-UML Modelo de datos Documento XML MOF 1-UML Información (datos SCDTR) MOF 0 Figura 4-3. Alineación niveles para cada vista en el entorno multidisciplinar. Por tanto, utilizando la notación formal XML Schema se diseñarán los Schemas para definir las gramáticas a emplear en la descripción del SCDTR desde el punto de vista de cada dominio. Los nuevos lenguajes creados de este modo son lenguajes específicos de dominio porque sirven para reflejar las peculiaridades de un ámbito de conocimiento. Como se detalla en el siguiente apartado, se les denominará pequeños lenguajes porque no nacen con un espíritu generalista, al contrario, emplean un lenguaje generalista (XML Schema) para adaptarse a las necesidades de un problema concreto. Pág. 4-5

8 4.1.2 PEQUEÑOS LENGUAJES Es más sencillo implementar un lenguaje específico optimizado para una tarea que implementar (o adaptar) un lenguaje de propósito general y optimizarlo para cualquier tipo de uso. Esta es la idea principal que subyace tras los Pequeños Lenguajes. Little Language es un término empleado en el mundo académico de la ciencia de la computación. Fue acuñado por Jon Bentley (Bentley 1986), quien desarrolló este concepto a lo largo de varios de sus trabajos (Bentley 2000 y Bentley y Bentley 1988). Escribir código específico en un lenguaje de propósito general para solucionar un problema concreto de aplicación no siempre es lo más adecuado. En su lugar, se puede construir una solución SW óptima embebiendo en la aplicación un pequeño lenguaje especializado para la realización de esa labor concreta. El componente adicional que se necesita es el intérprete para ese lenguaje específico. El intérprete será quien realice finalmente el trabajo que se le describe a través del lenguaje ad hoc. También denominados Lenguajes Específicos de Dominio, los pequeños lenguajes son muy expresivos para un determinado tipo de problema porque están diseñados específicamente para ese tipo de problema. Se definen como contraposición a lenguajes más genéricos (p.ej. C++). Suponen una de las herramientas prácticas más potentes para configurar de forma sencilla tareas especializadas. Encajan perfectamente con la filosofía SoC (Separation of Concerns) porque permiten separar la descripción funcional de lo que hay que hacer (para lo que se utiliza un lenguaje declarativo especializado) de su implementación particular (que puede emplear un lenguaje imperativo). A continuación, se listan algunos ejemplos de lenguajes declarativos de alto nivel orientados a una aplicación o dominio particular: Descripción funcional de arquitectura SW: ADLs (Architecture Description Language). Lenguajes para describir el SW en base a componentes ó módulos interconectados. Estas descripciones son empleadas por otras herramientas para realizar labores de análisis, validación, generación de código, etc. Generación de analizadores léxicos y sintácticos (o dicho de otro modo, pequeños lenguajes para crear otros pequeños lenguajes): LEX (Lexical Analyzer Generator). Lenguaje para describir lexemas y generar los analizadores léxicos que implementan la primera etapa de compilación (separación de cadenas de caracteres en lexemas) para un lenguaje de programación. Se trata de una herramienta de UNIX. Pág. 4-6

9 YACC (Yet Another Compiler-Compiler), lenguaje para describir la estructura de los datos de entrada a un programa y generar el parser que permitirá validar ese tipo de entradas. Se trata de una herramienta de UNIX. Proceso de generación de código: Makefiles. Se emplea un lenguaje particular para especificar las instrucciones que debe seguir una herramienta Make. El objetivo es automatizar la compilación y el enlazado de aplicaciones teniendo en cuenta las dependencias entre módulos, sus versiones e instantes de modificación. Apache Ant build files. Apache Ant (http://ant.apache.org) es una herramienta de código abierto que dirige el proceso de construcción de aplicaciones SW a partir de un fichero de configuración escrito en un lenguaje XML específico. Empleando este lenguaje se pueden invocar tareas ejecutadas por clases Java. XSP (extensible Server Pages) de Cocoon (http://cocoon.apache.org). Lenguaje para la descripción de contenido XML dinámico. A través de su procesado se genera código java apropiado para el framework de publicación Cocoon. Configuración de aplicaciones: Ficheros de configuración de Apache Web Server. La sintaxis que debe seguirse para configurar los servicios de un servidor web también se considera un pequeño lenguaje. Ficheros de configuración de Jakarta Tomcat. La configuración de este motor de servlets se realiza en un pequeño lenguaje XML. Ficheros de configuración de Cocoon. Este servlet para publicación web se configura de acuerdo a varios ficheros XML con sintaxis específica. Validación documentos XML: Schematron. Tal y como se ha explicado anteriormente, Schematron es un lenguaje para la descripción de reglas sobre contenidos de ficheros XML. Transformación de documentos XML: XSLT. Se trata de un lenguaje creado para describir la tarea específica de seleccionar subconjuntos de información de documentos XML y procesarlos produciendo un documento XML de salida diferente al original. SVG. Lenguaje para obtener una representación gráfica de la información contenida en un documento XML. Servicios de Sistemas Operativos: Pág. 4-7

10 Ficheros de configuración de servicios (.ini,.sys,.dat). Existen múltiples ejemplos de pequeños lenguajes que permiten configurar ciertos servicios del SO. Lenguajes de Shell (p.ej. cts., ksh, bash, rc, csh) para enviar órdenes al intérprete de comandos del SO. Lenguajes de script: TCL (Tool Command Language) para enviar comandos a programas interactivos. Java Script para gestión de eventos de interacción con el usuario en páginas HTML Perl (Practical Extraction and Report Language) para desarrollo de CGIs (Common Gateway Interface) En general, se aprecia una tendencia cada vez más acusada en el uso de XML en lugar del texto estructurado para la implementación de los pequeños lenguajes. La adopción de XML evita la escritura de parsers específicos (se emplea siempre el mismo parser estándar XML) y permite el empleo de tecnologías asociadas, como XSLT y XPath o las APIs DOM y SAX, para la gestión de la información. La arquitectura que se ha esbozado en el capítulo anterior para el entorno multidisciplinar dejaba entrever varias necesidades que pueden ser cubiertas satisfactoriamente con la ayuda de pequeños lenguajes. Una vez que se ha seleccionado XML Schema como el lenguaje grande ó metalenguaje para la definición de los lenguajes de modelado de las vistas de Ingeniería de Control, Sistemas Distribuidos y Sistemas de Tiempo Real, resta la elección de varios pequeños lenguajes para resolver otras cuestiones específicas. También se seleccionarán lenguajes XML para estas cuestiones. A continuación, se recogen esas necesidades junto con el pequeño lenguaje ó lenguaje específico que las soluciona: Descripción del SCDTR desde el punto de vista de los especialistas de Ingeniería de Control, Sistemas Distribuidos y Sistemas de Tiempo Real. Se diseñarán los schemas que permitan definir los lenguajes de modelado ControlML, DistributionML y RTML (donde ML denota Markup Language) que servirán de soporte para crear modelos o vistas del sistema acordes a cada una de las especialidades. Un parser XML, con el schema correspondiente, validará los modelos concretos que se describan usando ControlML, DistributionML y RTML. Descripción de reglas LER (Lenguaje para Especificación de Reglas) para la validación semántica de contenidos dentro de cada modelo y entre diferentes modelos. Schematron se ha mostrado como un lenguaje de schema adecuado para realizar esta labor. El motor de validación del schematron (Schematron Schema, Skeleton, XSLT) extraerá las reglas del schema en que estén embebidas, las interpretará y las aplicará procesando los resultados. Pág. 4-8

11 Descripción de transformaciones de información entre modelos. El proceso a seguir en la fase de especificación formal obliga a comenzar describiendo la vista de Ingeniería de Control, validarla y posteriormente crear una primera instancia de las vistas de Sistemas Distribuidos y Sistemas de Tiempo Real transformando, a partir de la vista de control, aquellos datos que también aparecen en las otras vistas. De igual forma, una vez que se complete la descripción usando herramientas particulares, también hay que transformar datos de la vista de Sistemas Distribuidos a la de Sistemas de Tiempo Real. XSLT ha probado su capacidad para realizar estas transformaciones que se declararán en las hojas de estilo correspondientes (IC2SD, IC2STR y SD2STR) y serán llevadas a cabo por el procesador estándar XSLT. Descripción subproceso de generación de código, documentación y pruebas. Esta descripción le corresponde a la disciplina de Ingeniería del SW, por tanto, se trata de definir un lenguaje SEPML (Software Engineering Process Markup Language) para este fin. La naturaleza de este subproceso encaja perfectamente con las capacidades de Apache Ant y el lenguaje que se emplea en el fichero build.xlm puede ser extendido y adoptado como lenguaje SEPML. De esa forma, sería el propio motor Apache Ant quien interpretaría la descripción del subproceso acorde con SEPML y realizaría todas las tareas relacionadas. Descripción transformaciones para la generación de código, documentación y pruebas. La descripción declarativa de estas transformaciones y su realización a través de un intérprete reforzará la reutilización, flexibilidad y sencillez de mantenimiento. El lenguaje SEPML mencionado anteriormente describe las tareas a realizar en el subproceso y las dependencias entre ellas y permite invocarlas en el momento adecuado. Sin embargo, ahora nos estamos refiriendo a la forma de describir cada una de estas tareas de transformación. XSLT y XSL-FO permiten realizar esta labor y transformar ficheros XML en el código fuente que se necesite (Java, C, C++, ) y en el formato de documentación que se desee (PDF, SVG, HTML, ). Procesadores estándar XSLT y XSL-FO interpretarán y realizarán las transformaciones cuando sean invocados por Ant. Descripción de la estructura del código final. El código final es como un puzzle donde deben encajan piezas procedentes de lugares diversos. Parte del código es generado ad hoc por el propio generador del entorno, parte es generado por herramientas particulares y parte es reutilizado tras recuperarlo del repositorio e instanciarlo. El esqueleto en el que encajar cada una de estas piezas se expresará en SADML (Software Architecture Description Markup Language), un nuevo lenguaje XML que comparta el núcleo expresivo de ControlML, DistributionML y RTML y permita describir el código en base a componentes y conectores. Un parser XML validará esta descripción. Descripción de los patrones de código. Los componentes en que divide el código SADML se tendrán que concretar en trozos de código concretos que Pág. 4-9

12 cumplan los interfaces requeridos ya provengan del generador, de herramientas particulares o del repositorio. La reutilización se logra empleando patrones de código instanciables o parametrizables para la aplicación concreta en desarrollo. Estos patrones se adaptan a la aplicación (parametrización) y enlazan con los demás en la forma en que indica la estructura general expresada en SADML. Por ello, independientemente de su origen (generador, herramienta, repositorio) y del lenguaje de programación que emplee, todo patrón de código tendrá un envoltorio común que lo describa en un lenguaje CTWML (Code Template Wrapper Markup Language). Este lenguaje definirá: los parámetros que haya que concretar para adaptar el código a una aplicación específica y los interfaces en su relación con otros componentes según SADML. Un parser XML permitirá interpretar y procesar estos envoltorios. Descripción de los componentes de los repositorios. El entorno genera varios repositorios para diferentes contenidos. Se trata de gestionar la reutilización de todo tipo de componentes. Así, se emplearán los lenguajes específicos adecuados para almacenar, recuperar y parametrizar (cuando sea necesario): patrones de código (CTWML) reglas semánticas (Schematron), hojas de estilo para transformaciones entre modelos (XSLT), hojas de estilo para generación de documentación (XSL-FO), hojas de estilo para generación de código (XSLT). Al tratarse siempre de lenguajes XML, todos los repositorios se pueden gestionar desde un interfaz común con API XML. Descripción gráfica de los modelos. La redacción de un documento XML en un editor de texto es una tarea bastante tediosa. Los editores XML facilitan este trabajo pero siempre es más intuitivo el uso de un interfaz gráfico de usuario (GUI). SVG es el lenguaje XML idóneo para esta labor. Un procesador estándar SVG (integrado en los navegadores web) interpreta este formato y permite al usuario usar un interfaz gráfico para generar instancias XML acordes con el metamodelo en cuestión. Descripción del contrato WSD (Web Service Description) para el interfaz entre el Motor de Colaboración de Herramientas (MCH) y cada herramienta particular. WSDL (Web Service Description Language) regulará la redacción de estos acuerdos en los que se explicitarán las URIs para acceder a los servicios y el metamodelo al que se asocia la herramienta (IC, SD ó STR), y por tanto, el lenguaje que se empleará en las comunicaciones entre herramienta y MCH (ControlML, DistributionML ó RTML). Estas descripciones serán interpretadas a través de un API XML usando el schema WSDL.xsd y permitirán el intercambio automático de información sin la actuación del usuario. Descripción de la información de configuración del proyecto (usuarios, seguridad, perfiles, herramientas particulares, ). Cada proyecto que se desarrolla en el entorno se caracteriza por el uso concreto que se haga de los recursos, usuarios involucrados, herramientas que se van a utilizar, etc. Toda esta información debe ser tenida en cuenta a lo largo de todo el proceso para coordinar los esfuerzos. Como no podía ser de otra forma, un lenguaje XML Pág. 4-10

13 (ProjectML) es lo más adecuado para expresar esta información que se manipulará desde un API XML. Se observa cómo la descripción desde el punto de vista de Ingeniería de Software, por sus connotaciones especiales y por tratarse de una disciplina transversal a las demás, se resolverá con varios pequeños lenguajes (SEPML, XSLT, XSL-FO, SADML y CTWML) en lugar de sólo uno. Atendiendo a la arquitectura definida para el entorno multidisciplinar, toda esta colección de pequeños lenguajes se puede clasificar de la siguiente manera: Lenguajes para la gestión de los modelos. Constituyen el Motor de Colaboración de Modelos (MCM) que se gestiona desde la entidad DIRECTOR. Su uso se divide en dos subprocesos, en el primero entran en juego los lenguajes propios de tres dominios (junto con el complemento de XSLT y Schematron), mientras que el segundo es el propio de la Ingeniería del SW y se resuelve con varios pequeños lenguajes: Subproceso especificación formal: ControlML, DistributionML, RTML, Schematron y XSLT. Subproceso de generación de código: SEPML, XSLT, XSL-FO, SADML y CTWML Lenguajes para la gestión del entorno. Constituyen el fundamento para el Motor de Colaboración de Herramientas (MCH): WSDL, ProjectML, SVG En todos los casos, se agrupan en un documento XML las instrucciones sobre una labor específica y es otra entidad la que las interpreta, con lo que separa la declaración funcional de la implementación. La Tabla 4-1 resume el conjunto de lenguajes específicos, relacionándolos con la función que permiten llevar a cabo (primera columna), con la entidad intérprete (cuarta columna) y con los documentos de entrada a ésta (tercera columna). Se ha optado por un desarrollo a través de programación declarativa basada en XML como forma de solución a la especificación y verificación de requisitos. Esta solución permite comprobar que el diseño verifica la especificación de requisitos. Para el presente trabajo se han diseñado las versiones básicas de alguno de estos lenguajes con objeto de demostrar tanto la validez de la propuesta como la generalidad de la solución. Posteriores trabajos en el marco del proyecto de investigación MCYT 2003 DPI profundizarán en los diferentes dominios con el objetivo de complementar los lenguajes que aquí se presentan. Pág. 4-11

14 Tabla 4-1. Pequeños lenguajes usados en el entorno multidisciplinar. Función Lenguaje XML Entradas al intérprete Intérprete Descripción del sistema desde el punto de vista del especialista ControlML, DistributionML, RTML Schemas e instancias Parser XML Validación Reglas semánticas LER Schematron Fichero de reglas schematron y documentos XML Motor Schematron (XSLT) Transformación, flujo horizontal de datos entre modelos XSLT Hojas de estilo IC2SD, IC2STR, SD2STR y documentos XML Procesador XSLT Gestión proceso generación SW, documentación y pruebas SEPML (extensión a lenguaje de Ant) Fichero Build.xml extendido Motor Apache Ant Transformaciones para la generación de código y documentación XSLT, XSL-FO Hojas de estilo y documentos XML Procesador XSLT, XSL-FO invocado desde Ant Descripción arquitectura SW SADML Schema SADML y una instancia Descripción patrón de código CTWML Schema CTWML y una instancia Parser XML Parser XML Almacenaje, recuperación e instanciación componentes repositorio CTWML, XSL, XSL-FO, Schematron Schemas e instancias Parser XML Edición gráfica modelos SVG Instancia SVG Navegador web Gestión contrato WSD WSDL Schema WSDL.xsd y una instancia Parser XML Gestión configuración del proyecto ProjectML Schema Project.xsd e instancia Parser XML Pág. 4-12

15 4..2 INTEGRACIIÓN DE GRAMÁTIICAS Sobre la implementación en XML de cada uno de los servicios ortogonales que constituyen las gramáticas de dominio y sobre su origen común. Tal y como se describe en el capítulo anterior, la definición de un lenguaje como la conjunción de cinco servicios ortogonales permite mayor granularidad para elegir el nivel de integración o interoperatividad que se quiere lograr. En este apartado se van a diseñar estos cinco servicios (sintaxis abstracta, sintaxis concreta, transformaciones sintácticas, sistema de tipos y semántica) en base a tecnologías XML, de forma que se definan los lenguajes específicos de dominio para el entorno multidisciplinar. La Figura 4-4 muestra esta jerarquía para la definición gramatical, tal y como se describió en el capítulo anterior. Se han añadido (en rojo) las denominaciones finales para cada uno de los lenguajes específicos de dominio (ControlML, DistributionML, RTML y SADML), así como las técnicas XML sobre las que apoyarse en cada nivel. En el caso de la Ingeniería del SW (IS) son varios los pequeños lenguajes a utilizar, pero el que sirve para realizar una especificación paralela al resto de dominios es el SADML (Software Architecture Description Markup Language). Es decir, SADML permitirá describir la arquitectura del SW para el SCDTR en base a componentes y conectores. A continuación, se detalla la forma de resolver en XML cada uno de los niveles. Estructura del lenguaje Significado del lenguaje Sistema tipos Sintaxis Abstracta Sintaxis Concreta (XML) Transformaciones Sintácticas Sistema tipos Sistema tipos Sistema tipos Semántica Semántica Semántica Semántica Conceptos Componentes Schema Arch.xsd Hojas estilo XSLT Schemas ControlML, DistributionML, RTML y ADML Reglas schematron ControlML IC DistributionML SD RTML STR ADML IS Figura 4-4. Implementación XML de gramáticas en base a servicios ortogonales. Pág. 4-13

16 4.2.1 ESTRUCTURA COMÚN LENGUAJES La estructura raíz de los cuatro lenguajes queda determinada por una sintaxis abstracta, una sintaxis concreta y unas transformaciones sintácticas en común Sintaxis Abstracta La Sintaxis Abstracta debe ser lo suficientemente genérica como para servir de núcleo expresivo para cualquiera de los lenguajes específicos de dominio. Desde cualquiera de los dominios se concibe una determinada arquitectura para el sistema, si bien los elementos constitutivos de esa arquitectura y la manera de relacionarlos difieren en cada caso. Por lo tanto, el núcleo expresivo que se busca debe servir para describir arquitecturas genéricas utilizando elementos abstractos. Los lenguajes específicos de dominio se basarán en ese núcleo pero lo extenderán adaptándolo a su visión particular del sistema. Esta misma idea ya se esbozaba en el apartado 2.1.2, donde se analizaba el Modelo de 4+1 vistas, se identificaban los componentes y conectores como elementos expresivos comunes a las vistas lógica, de proceso, de desarrollo y física. Estos elementos genéricos se enriquecían y adoptaban un significado concreto en cada una de las vistas. De forma análoga, la sintaxis abstracta para el entorno multidisciplinar estará formada por: Componentes (Components). Representan cajas negras que tienen puertos como interfaces de entrada y salida. Cada componente tiene como propiedades: nombre, número de puertos de entrada y número de puertos de salida. Líneas (Lines). Representan conexiones entre componentes a través de los puertos. Tienen como propiedades: nombre, componente y puerto de origen, componente y puerto de destino. Una línea a su vez puede contener: Ramas (Branches). Permiten representar bifurcaciones en conexiones, es decir, conexiones con un único origen pero varios destinos. Heredan el componente y puerto de origen de la línea pero tienen como propiedad propia un componente y un puerto de destino diferente. Estos elementos tienen además capacidad jerárquica. Un Modelo está compuesto por un conjunto de componentes y líneas, donde cada componente puede contener, a su vez, conjuntos de componentes y líneas representando subsistemas. Y así sucesivamente, con lo que se permite la descripción de tantos niveles jerárquicos como se precise. La representación formal de esta jerarquía requiere de la inclusión de un nuevo tipo especial de componente para representar las conexiones que proceden de un nivel jerárquico superior ó van a un nivel jerárquico superior. Se trata de Puertos de Entrada (inports) y Puertos de Salida (outports). Estos elementos aparecen de forma explícita en un nivel jerárquico por cada puerto de Pág. 4-14

17 entrada ó salida que tenga el componente del nivel jerárquico superior cuyo interior se está describiendo. Con este núcleo expresivo se pueden realizar descripciones como la que se representa gráficamente en la Figura 4-5, donde aparecen componentes con sus puertos unidos por líneas (y ramas) y se representa en un segundo nivel el contenido del componente D. A C B D NIVEL 1 D2 in D1 D3 D4 NIVEL 2 Figura 4-5. Representación gráfica de un sistema descrito mediante la sintaxis abstracta. En este ejemplo se aprecia la aparición de un puerto de entrada (forma triangular) en el segundo nivel jerárquico debido a que el componente D tiene un puerto de entrada. Esta descripción explícita del interfaz permitirá validar formalmente cómo el nivel 2 de la figura es una especificación válida para el componente D que aparece en el nivel 1. Es decir, se validará formalmente el interfaz (número de puertos de entrada y salida) de todo componente contra el número de elementos inport y outport que incluya toda posible especificación en detalle de dicho componente. En definitiva, la sintaxis abstracta hasta aquí detallada permite especificar, de forma genérica, la arquitectura de cualquier sistema. Sin embargo, es importante aclarar que tanto esta sintaxis abstracta como las posteriores decisiones que en cuanto a definición de lenguajes de dominio se van a ir tomando no dejan de ser simples ejemplos que pretenden ilustrar la viabilidad del empleo de las tecnologías XML. Estas decisiones son totalmente discutibles (modificables y ampliables) ya que se busca demostrar la validez, flexibilidad y generalidad de la metodología y no la creación de exhaustivos lenguajes de dominio finales. Pág. 4-15

18 Sintaxis Concreta La sintaxis abstracta definida en el apartado anterior puede materializarse a través de notaciones muy diferentes que expresen de formas distintas cada uno de los conceptos descritos. La definición de una notación, un soporte concreto para la sintaxis abstracta determina la sintaxis concreta a utilizar. Por ejemplo, puede crearse un perfil UML que permita usar el lenguaje gráfico de UML como sintaxis concreta para componentes, líneas, ramas y puertos. También podría definirse una gramática textual para describir los sistemas de acuerdo a esa sintaxis concreta en documentos de texto plano. En definitiva, la separación entre las sintaxis abstracta y concreta permite materializar de muchas formas paralelas (sintaxis concretas) los conceptos comunes de una sintaxis abstracta. XML es la opción seleccionada en esta tesis para dar soporte a la sintaxis concreta de cualquiera de las gramáticas que se precisen. XML ofrece la posibilidad de describir en un documento (Schema) el léxico, sintaxis y conjunto de restricciones que se desean imponer al nuevo lenguaje y ofrece APIs estándar para manipular y validar contra su schema las descripciones realizadas en ese lenguaje. La definición del XML Schema Arch.xsd supone la creación de una notación textual para describir cualquier sistema de acuerdo a los conceptos de la sintaxis abstracta. Este schema debe ser lo suficientemente genérico como para servir de núcleo expresivo común para la descripción de arquitecturas en todos los lenguajes de dominio, aunque después cada lenguaje de dominio pueda matizar y adaptar esta sintaxis a las peculiaridades de su campo. El Schema Arch.xsd debe recoger todos los requisitos necesarios que definen formalmente la sintaxis concreta para la sintaxis abstracta definida anteriormente, son los siguientes: Únicos elementos válidos: component, line, branch, inport y outport. Cada elemento sólo puede tener como atributos los que han sido indicados anteriormente como propiedades. o o o o o Componentes (component): nombre, número de puertos de entrada y número de puertos de salida. Líneas (line): nombre, componente y puerto de origen, componente y puerto de destino. Ramas (branch): componente y puerto de destino. Puerto de entrada (inport): nombre y tipo de dato. Puerto de salida (outport): nombre y tipo de dato. Cada elemento y atributo deberá respetar ciertos requisitos: obligatorio u opcional, número de ocasiones que puede aparecer, tipo de dato, etc. Pág. 4-16

19 Los nombres asociados a cada elemento no pueden repetirse en un mismo nivel y debe comprobarse que las referencias entre ellos son correctas (p.ej. si una línea parte de un componente, debe comprobarse que ese componente existe realmente). La Figura 4-6 muestra la estructura del schema Arch.xsd que recoge todos estos requisitos. En esta figura se puede apreciar: Existe un elemento raíz denominado Model que tiene como único hijo el elemento Structure. Este último elemento es del tipo structuretype. El tipo reutilizable structuretype está compuesto obligatoriamente (línea continua) por un elemento component pero puede haber una cantidad ilimitada de elementos component y elementos line (línea discontinua). El tipo reutilizable linetype recoge un número indeterminado de hijos branch. El tipo reutilizable componenttype se compone de, al menos, un component y elementos opcionales line, inport y outport. El hecho de que el elemento component sea de tipo componenttype da lugar a la recurrencia necesaria para describir un sistema con un número indeterminado de niveles. Figura 4-6. Estructura del schema Arch.xsd. Se lista a continuación el código completo del Schema Arch.xsd: <?xml version="1.0" encoding="utf-8"?> <xs:schema targetnamespace="http://www.arch.org" xmlns:arch="http://www.arch.org" xmlns:xs="http://www.w3.org/2001/xmlschema" Pág. 4-17

20 elementformdefault="qualified" attributeformdefault="unqualified"> <xs:annotation> <xs:documentation> <!-- AQUI VA EL TEXTO DE INFORMACIÓN DE USUARIO SOBRE ESTE Schema --> </xs:documentation> <xs:appinfo> <schematron> <schematron xmlns="http://www.ascc.net/xml/schematron" xmlns:xsi="http://www.w3.org/2000/10/xmlschema-instance" xsi:schemalocation=" C:\TESIS\MCM\schematron1-5.xsd"> <! AQUI VAN LAS REGLAS SCHEMATRON-Arch --> </schematron> </schematron> </xs:appinfo> </xs:annotation> <! ELEMENTO RAIZ: Model --> <xs:element name="model" type="arch:model"> <xs:annotation> <xs:appinfo> </xs:appinfo> </xs:annotation> </xs:element> <!-- TIPO arch:model --> <xs:complextype name="model"> <xs:sequence> <xs:element name="structure" type="arch:structuretype"> <xs:key name="idcomp"> <xs:selector xpath="arch:component"/> <xs:field </xs:key> <xs:keyref name="refidcomp" refer="arch:idcomp"> <xs:selector xpath="arch:line arch:line/arch:branch"/> <xs:field </xs:keyref> <xs:keyref name="refidcomp1" refer="arch:idcomp"> <xs:selector xpath="arch:line"/> <xs:field </xs:keyref> </xs:element> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> </xs:complextype> <!-- TIPO arch:structuretype --> <xs:complextype name="structuretype"> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element name="component" type="arch:componenttype" maxoccurs="unbounded"> <xs:key name="idcompgroup"> <xs:selector xpath="arch:component arch:outport arch:inport"/> <xs:field </xs:key> <xs:keyref name="refidcompgroup" refer="arch:idcompgroup"> <xs:selector xpath="arch:line arch:line/arch:branch"/> <xs:field </xs:keyref> <xs:keyref name="refidcompgroup1" refer="arch:idcompgroup"> <xs:selector xpath="arch:line"/> <xs:field </xs:keyref> </xs:element> <xs:element name="line" type="arch:linetype" minoccurs="0" maxoccurs="unbounded"/> </xs:choice> Pág. 4-18

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

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

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

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

3 ARQUITECTURA DEL ENTORNO Y TÉCNICAS DE INTEGRACIÓN 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

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

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

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

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

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

Ingeniería inversa de GUIs

Ingeniería inversa de GUIs Ingeniería inversa de GUIs Existen numerosos sistemas en funcionamiento que fueron desarrollados en los años 90 utilizando entornos RAD (Rapid Application Development), tales como Delphi, Visual Basic

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

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Práctica de introducción a

Práctica de introducción a Práctica de introducción a XML El trabajo consiste en una introducción al uso del lenguaje XML y su aplicación en documentos y sistemas de caracteristicas multimedia. 1.- Qué es XML? XML (extensible Markup

Más detalles

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

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

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea

Clientes Donantonio. Especificación de requisitos software. Juan José Amor David Escorial Ismael Olea Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

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

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

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

DISEÑO DE FUNCIONES (TRATAMIENTOS)

DISEÑO DE FUNCIONES (TRATAMIENTOS) DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se

Más detalles

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

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

Semantic Annotation for WSDL and XML SAWSDL

Semantic Annotation for WSDL and XML SAWSDL 1 Universidad Rey Juan Carlos I Semantic Annotation for WSDL and XML SAWSDL Presentación: Luis Miguel Serrano Cámara Recuperación de la Información 2 Indice 1.- Introducción 2.- SAWSDL en WSDL 2.0 3.-

Más detalles

Capítulo 11. Conclusiones y trabajo futuro

Capítulo 11. Conclusiones y trabajo futuro Capítulo 11. Conclusiones y trabajo futuro En esta tesis ha realizado un entorno de desarrollo Web que proporciona herramientas para la mejora de la calidad del código de los desarrolladores. Para conseguir

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

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

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

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

Contenido. Complemento de Estado de Cuenta Bancario. Estructura

Contenido. Complemento de Estado de Cuenta Bancario. Estructura Contenido Complemento de Estado de Cuenta Bancario 1. Estándar del Complemento Estado de Cuenta Bancario 2. Secuencia de Elementos a Integrar en la Cadena Original 3. del Complemento Estado de Cuenta Bancario

Más detalles

Introducción a los Tipos Abstractos de Datos

Introducción a los Tipos Abstractos de Datos Página 1 de 8 Introducción a los Tipos Abstractos de Datos Introducción: Concepto de abstracción Abstracción funcional y abstracción de datos Construcción de tipos abstractos de datos Especificación de

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

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

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

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

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS

WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS WEBBER: USO DE COMPONENTES PARA LA ARMONIZACIÓN DE CONTENIDOS Y METADATOS Autores: Introducción Diego R. López RedIRIS diego.lopez@rediris.es El trabajo necesario para mantener un servidor de información

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

DEPARTAMENTO: Informática. MATERIA: Programación. NIVEL: 1º Desarrollo de Aplicaciones Multiplataforma

DEPARTAMENTO: Informática. MATERIA: Programación. NIVEL: 1º Desarrollo de Aplicaciones Multiplataforma DEPARTAMENTO: Informática MATERIA: Programación NIVEL: 1º Desarrollo de Aplicaciones Multiplataforma 1. Objetivos. Competencias Profesionales, Personales y Sociales 1.1 Objetivos del ciclo formativo La

Más detalles

Solución corporativa para la gestión descentralizada de metadatos: Cliente Web de administración de metadatos

Solución corporativa para la gestión descentralizada de metadatos: Cliente Web de administración de metadatos Solución corporativa para la gestión descentralizada de metadatos: Cliente Web de administración de metadatos Joan Nunes Alonso1, Ignacio Ferrero Beato 2, y Laura Sala Martín3 1 Laboratorio de Información

Más detalles

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

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

PLIEGO DE PRESCRIPCIONES TÉCNICAS ÍNDICE 1. OBJETO... 2 2. ANTECEDENTES Y SITUACIÓN ACTUAL... 2

PLIEGO DE PRESCRIPCIONES TÉCNICAS ÍNDICE 1. OBJETO... 2 2. ANTECEDENTES Y SITUACIÓN ACTUAL... 2 PROCEDIMIENTO NEGOCIADO SIN PUBLICIDAD PARA LA ADJUDICACIÓN DEL CONTRATO DE SERVICIOS PARA EL DESARROLLO DE COMPONENTES PARA LAS APLICACIONES DE ADMINISTRACIÓN ELECTRÓNICA DEL SENADO PLIEGO DE PRESCRIPCIONES

Más detalles

extensible Markup Language (XML)

extensible Markup Language (XML) extensible Markup Language (XML) 1. INTRODUCCIÓN Jennifer Pérez Benedí Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia C/Camino de Vera s/n E-46071 Valencia- España

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

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el 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

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

Características de OpenCms

Características de OpenCms Características de OpenCms Se basa en Java y Xml OpenCms está totalmente desarrollado en java bajo el estándar servlet. Por lo tanto, se puede integrar fácilmente en entornos hardware y software existentes,

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

Introducción CAPÍTULO 1

Introducción CAPÍTULO 1 Introducción CAPÍTULO 1 6 CAPÍTULO 1 - Introducción. En la actualidad hay una gran cantidad de repositorios en los que se puede alojar código fuente para poder compartirlo con los usuarios que visiten

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

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

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

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

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

Unidad V: Programación del lado del servidor

Unidad V: Programación del lado del servidor Unidad V: Programación del lado del servidor 5.1 Introducción al lenguaje La Programación del lado del servidor es una tecnología que consiste en el procesamiento de una petición de un usuario mediante

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

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

Más detalles

Desarrollo del software imposible si las tareas tuviesen que expresarse en código máquina. Lenguajes de más alto nivel: comprensibles, manejables y

Desarrollo del software imposible si las tareas tuviesen que expresarse en código máquina. Lenguajes de más alto nivel: comprensibles, manejables y 1. Paradigmas de programación Desarrollo del software imposible si las tareas tuviesen que expresarse en código máquina. Lenguajes de más alto nivel: comprensibles, manejables y automáticamente convertibles

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

FUJITSU Java Development Framework

FUJITSU Java Development Framework FUJITSU Java Development Framework DOCUMENT DETAILS Created: 10.12.2005 Version: 2.0 Author: FUJITSU ESPAÑA SERVICES S.A. 1. INTRODUCCIÓN 1.1 Arquitectura conceptos básicos La arquitectura planteada por

Más detalles

CONSTRUCCIÓN DE PORTALES

CONSTRUCCIÓN DE PORTALES Curso «Los portales de internet». Fac. Documentación. Universidad de Murcia. 29 CONSTRUCCIÓN DE PORTALES Juan Antonio Pastor Sánchez 1. Introducción La Gestión de los contenidos informativos de los portales

Más detalles

Centro de Interoperabilidad Semántica y Sistema de Gestión de Mensajes de Intercambio

Centro de Interoperabilidad Semántica y Sistema de Gestión de Mensajes de Intercambio Centro de Interoperabilidad Semántica y Sistema de Gestión de Mensajes de Intercambio Francisco José Martín Lázaro franciscojose.martin@map.es Consejero Tecnológico de Normas de Tecnología. Ministerio

Más detalles

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 SPEM 2.0 SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 Metamodelo para modelos de procesos de ingeniería de software y de ingeniería de sistemas. La idea central de SPEM

Más detalles

DISEÑO DE UN CURSO INTERACTIVO Y ADAPTATIVO DE PROCESADORES DE LENGUAJES

DISEÑO DE UN CURSO INTERACTIVO Y ADAPTATIVO DE PROCESADORES DE LENGUAJES Alfonseca, M., Carro, R.M., Pulido, E. and Rodríguez, P. (2000): Diseño de un curso interactivo y adaptativo de procesadores de lenguajes. Proceedings of JENUI 2000: VI Jornadas sobre la Enseñanza Universitaria

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

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

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

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso Diagramas de Casos de Uso Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso ( Qué es un caso de uso?) Caso de Uso? 2 Casos de Uso ( Qué es un caso de uso?) Un caso de uso

Más detalles

TEMA 5 LA FAMILIA XML EN LA NUEVA WEB

TEMA 5 LA FAMILIA XML EN LA NUEVA WEB TEMA 5 LA FAMILIA XML EN LA NUEVA WEB La Web, tanto cuantitativa como cualitativamente, se ha desarrollado extraordinariamente siendo el objeto de este texto ubicar el papel que XML juega y va a jugar

Más detalles

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

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

I. E. S. Cristóbal de Monroy. DEPARTAMENTO: Informática. MATERIA: Aplicaciones Web. NIVEL: 2º Sistemas Microinformáticos y Redes

I. E. S. Cristóbal de Monroy. DEPARTAMENTO: Informática. MATERIA: Aplicaciones Web. NIVEL: 2º Sistemas Microinformáticos y Redes DEPARTAMENTO: Informática MATERIA: Aplicaciones Web NIVEL: 2º Sistemas Microinformáticos y Redes 1. Objetivos. Competencias Profesionales, Personales y Sociales 1.1 Objetivos del ciclo formativo Según

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

IES Pablo Serrano-ASIR1D/DAM1D-B.Soler XML

IES Pablo Serrano-ASIR1D/DAM1D-B.Soler XML IES Pablo Serrano-ASIR1D/DAM1D-B.Soler Contenidos 1. Introducción 2. Quién ha creado? 3. Definición según W3C 4. Qué es? 5. Objetivos 6. Para qué sirve? 7. Con ya vale? 8. Tecnologías asociadas 9. Familia

Más detalles

Aportaciones teóricas y prácticas de la tesis y líneas de trabajo futuras que se derivan de las mismas.

Aportaciones teóricas y prácticas de la tesis y líneas de trabajo futuras que se derivan de las mismas. 5 APORTACIONES Y LÍNEAS FUTURAS Aportaciones teóricas y prácticas de la tesis y líneas de trabajo futuras que se derivan de las mismas. 5.1 Aportaciones 5.2 Líneas Futuras 5..1 APORTACIIONES Confrontación

Más detalles

Confección y publicación de páginas Web

Confección y publicación de páginas Web 2014 Confección y publicación de páginas Web Docente: Manuel Fernández Catalán 0 ÍNDICE 1 Presentación... 2 2 Objetivos... 2 3 Tecnología... 2 4 Metodología y evaluación... 3 5 Material didáctico... 3

Más detalles

Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos

Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos. Interfaces de acceso a base de datos Objetivos del curso Patrimonio Cultural Desarrollo de Herramientas de Administración y Acceso Adquirir visión generalizada de las tecnologías de desarrollo utilizadas en Sistemas de gestión del Patrimonio

Más detalles

TEMA: DESARROLLO DE APLICACIONES WEB INTERACTIVAS UTILIZANDO LA TÉCNICA AJAX AUTOR: MERY SUSANA ZAMBONINO BAUTISTA

TEMA: DESARROLLO DE APLICACIONES WEB INTERACTIVAS UTILIZANDO LA TÉCNICA AJAX AUTOR: MERY SUSANA ZAMBONINO BAUTISTA TEMA: DESARROLLO DE APLICACIONES WEB INTERACTIVAS UTILIZANDO LA TÉCNICA AJAX AUTOR: MERY SUSANA ZAMBONINO BAUTISTA AREA DEL TEMA: INGENIERÍA DE SOFTWARE OBJETIVO GENERAL Desarrollar aplicaciones web utilizando

Más detalles

Tema 3. 3.3 Tecnologías de Desarrollo

Tema 3. 3.3 Tecnologías de Desarrollo Tema 3 3.3 Tecnologías de Desarrollo HTML pronto pasa a ser insuficiente para todas las posibilidades de la Red No se puede interactuar con el servidor Aparecen los primeros scripts para propocionar dichar

Más detalles

Servidores Donantonio

Servidores Donantonio Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

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

A partir de este capítulo se introducen términos, probablemente nuevos para el

A partir de este capítulo se introducen términos, probablemente nuevos para el CAPITULO 3. PSP 0 Y PSP 0.1 A partir de este capítulo se introducen términos, probablemente nuevos para el lector que tienen que ver en su totalidad con PSP. También se dan a conocer los formatos, "scripts

Más detalles

Arquitectura de Software

Arquitectura de Software Arquitectura de Software (Estilos Arquitectónicos) Universidad de los Andes Demián Gutierrez Mayo 2011 1 Diseño Arquitectónico Diseño Arquitectónico Arquitectura del Software Estilos Arquitectónicos Frameworks

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

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

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2

INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Programa de Capacitación y Certificación. INTELIGENCIA DE NEGOCIOS CON SQL SERVER 2008 R2 Contenido PERFIL DE UN ESPECIALISTA EN BASES DE DATOS.... 3 6231. MANTENIENDO UNA BASE DE DATOS DE SQL SERVER 2008

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

Estructura Elemento: EstadoDeCuentaCombustible Diagrama

Estructura Elemento: EstadoDeCuentaCombustible Diagrama Contenido Complemento de Estado de Cuenta de Combustibles para Monederos Electrónicos Autorizados por el SAT A. Estándar del complemento EstadoDeCuentaCombustible. B. Secuencia de elementos a integrar

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