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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

El XBRL y sus aportes al intercambio de información financiera

El XBRL y sus aportes al intercambio de información financiera Universidad ORT Uruguay Facultad de Ingeniería El XBRL y sus aportes al intercambio de información financiera Entregado como requisito para la obtención del título de Licenciado en Sistemas Carlos Rial

Más detalles

Contenido. Formato SelloDigitalContElec. Se deberá utilizar el siguiente estándar XSD, validando su forma y sintaxis en un archivo con extensión XML.

Contenido. Formato SelloDigitalContElec. Se deberá utilizar el siguiente estándar XSD, validando su forma y sintaxis en un archivo con extensión XML. Contenido Formato SelloDigitalContElec Estándar del Formato SelloDigitalContElec Se deberá utilizar el siguiente estándar XSD, validando su forma y sintaxis en un archivo con extensión XML. Para poder

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

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

XML práctico Bases esenciales, conceptos y casos prácticos (2ª edición)

XML práctico Bases esenciales, conceptos y casos prácticos (2ª edición) Introducción al lenguaje XML 1. De SGML a XML 17 2. Los conceptos básicos del XML 18 2.1 Recordatorio sobre el HTML 18 2.2 Creación de un primer documento XML 19 2.3 Las ventajas del XML 21 3. La sintaxis

Más detalles

INDICE 1. Estructura, Sintaxis y Usos de XML 1. Fundamentos de XML 2. DTD: Características y Técnicas

INDICE 1. Estructura, Sintaxis y Usos de XML 1. Fundamentos de XML 2. DTD: Características y Técnicas INDICE Introducción XV 1. Estructura, Sintaxis y Usos de XML 1 1. Fundamentos de XML 3 Introducción 4 Desmitificación de la marcación 4 Qué es la marcación? 4 Definición de XML 10 Una definición estricta

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

FSE2007. Formato de fichero de Verificaciones UAFSE-FSE2007. Formato de fichero de Verificaciones. Página 1 de 8 FSE2007

FSE2007. Formato de fichero de Verificaciones UAFSE-FSE2007. Formato de fichero de Verificaciones. Página 1 de 8 FSE2007 UAFSE- Formato de fichero de Verificaciones Página 1 de 8 UAFSE- 1- Introducción Para la importación de datos masivos al sistema se dispone de un formato concreto de fichero, dependiendo de la naturaleza

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

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

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

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

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

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

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

Validación de ficheros XML de metadatos de información geográfica. Norma ISO19139

Validación de ficheros XML de metadatos de información geográfica. Norma ISO19139 Validación de ficheros XML de metadatos de información geográfica. Norma ISO19139 Amaro, Alberto (1) (1) Área de Teledetección. Departamento de Observación de la Tierra INTA Ctra. Ajalvir sn Torrejón de

Más detalles

Contenido. Complemento Nomina. Estructura

Contenido. Complemento Nomina. Estructura Contenido Complemento Nomina 1. Estándar del Complemento Nomina 2. Secuencia de Elementos a Integrar en la Cadena Original 3. del Complemento Nomina 1. Estándar del Complemento Nomina Elementos Elemento:

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

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

Apéndice 1. DMOF Y MOF 2

Apéndice 1. DMOF Y MOF 2 Apéndice C DMOF y MOF 1. DMOF Y MOF 2 PROCESO DE DESARROLLO PARA GENERAR REPOSITORIOS DE META DATA BASADOS EN MOF. 2 DMOF IMPLEMENTA LOS MAPEOS POSIBLES DE MOF 5 MOF IDL MAPPING 5 MOF XMI MAPPING 7 UN

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

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

Estructura. Elementos Elemento: Intereseshipotecarios Diagrama. Contenido. Complemento de Intereses hipotecarios

Estructura. Elementos Elemento: Intereseshipotecarios Diagrama. Contenido. Complemento de Intereses hipotecarios Contenido Complemento de Intereses hipotecarios 1. Estándar del Complemento Intereses hipotecarios 2. Secuencia de Elementos a Integrar en la Cadena Original 3. del Complemento Intereses hipotecarios 1.

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

extensible Markup Language

extensible Markup Language extensible Markup Language ISLN ISLN () XML 1 / 26 Librería LWP::Simple Bajarse el archivo de internet Para bajar archivos de internet se puede usar alguno de los módulos del CPAN http://search.cpan.org

Más detalles

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran:

Para el desarrollo de aplicaciones Web se han generado múltiples tecnologías entre ellas se encuentran: Desarrollo de aplicaciones y servicios web Cinxgler Mariaca Minda Cinxgler@udistrital.edu.co Presidente Capítulo de Computadores Rama IEEE Universidad Distrital Francisco José de Caldas Resumen: Este articulo

Más detalles

Introducción a WebMathematica

Introducción a WebMathematica Introducción a WebMathematica WebMathematica es una nueva tecnología que permite la generación de contenido web dinámico con Mathematica. Se integra en Mathematica a través de un servidor web. WebMathematica

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

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

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

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

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

Contenido. Formato balanza de comprobación

Contenido. Formato balanza de comprobación Contenido Formato balanza de comprobación 1. Estándar del formato balanza de comprobación de contabilidad electrónica 2. Generación opcional de sellos digitales 1. Estándar del formato balanza de comprobación

Más detalles

Cursos PROGRAMACIÓN DE APLICACIONES CON JAVA

Cursos PROGRAMACIÓN DE APLICACIONES CON JAVA Cursos CIÓN DE APLICACIONES CON JAVA OBJETIVOS Los cursos ofrecen al alumno fundamentos muy sólidos en la Plataformas de desarrollo Java, no solo en aspectos concretos (lenguaje java, paquetes disponibles,

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

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL MF0491_3: PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE. (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 180 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 141 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

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

HOJA TÉCNICA. SemTalk 2

HOJA TÉCNICA. SemTalk 2 HOJA TÉCNICA SemTalk 2 SemTalk 2 - Información Técnica SemTalk 2 es una herramienta para modelamiento de procesos de negocios y conocimientos orientado a objetos 100% compatible con MS Office. REQUERIMIENTOS

Más detalles

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software UML El Lenguaje de Modelado Unificado Maestría en Ingeniería de Software Agenda Model Driven Architecture (MDA) Unified Model Language (UML) Object Constraint Language (OCL) Patrones Conclusiones Contenido

Más detalles

Universidad Autónoma Metropolitana

Universidad Autónoma Metropolitana Universidad Autónoma Metropolitana Unidad Azcapotzalco División de Ciencias Básicas e Ingeniería Licenciatura en Ingeniería en Computación Propuesta de Proyecto Terminal Composición de servicios web para

Más detalles

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web

Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Ciclo Formativo de Grado Superior Desarrollo de Aplicaciones Web Proyecto Propio de Ampliación con Programación de Dispositivos Móviles e Inteligentes Paseo de la Puerta del Ángel, s/n 28011 Madrid www.iesellago.net

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

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

M. Carmen Fernández Panadero

M. Carmen Fernández Panadero <mcfp@it.uc3m.es> Introducción n a XML M. Carmen Fernández Panadero Introducción a XML 1 Objetivos Familiarizarse con conceptos y herramientas básicas de XML Conocer la estructura de un documento XML Ser capaz de diseñar

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

"Módulo OOWS para StarUML" INTRODUCCIÓN

Módulo OOWS para StarUML INTRODUCCIÓN UNA HERRAMIENTA PARA DIAGRAMAS OOWS: "Módulo OOWS para StarUML" Richard Medina Z. Universidad de Concepción, Chile INTRODUCCIÓN Una herramienta CASE (Computer Aided Software Engineering,

Más detalles

Manejando Binary XML en Oracle Database 11gR2

Manejando Binary XML en Oracle Database 11gR2 Por Francisco Riccio Introducción Manejando Binary XML en Oracle Database 11gR2 XML es un lenguaje diseñado para estructurar documentos con la finalidad de intercambiar información entre diferentes plataformas.

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

Introducción a Javato

Introducción a Javato Introducción a Javato Fº. Javier Pereñiguez Steria Iberica 20/02/2008 Índice Introducción Arquitectura Ejemplo arquitectura Plataforma Desarrollo Ejemplo de entorno de desarrollo Vías futuras Casos de

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

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

UML 2 Iniciación, ejemplos y ejercicios corregidos

UML 2 Iniciación, ejemplos y ejercicios corregidos Ediciones ENI UML 2 Iniciación, ejemplos y ejercicios corregidos (3ª edición) Colección Recursos Informáticos Contenido Contenido 1 Capítulo 1 Introducción 1. Motivaciones de la obra.....................................

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

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

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

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

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

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

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

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

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

2.1 Compuertas para Bases de Datos

2.1 Compuertas para Bases de Datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Uno de los aspectos mas importantes en un sistema multibase de datos es la forma en como llevar a cabo la comunicación

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

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

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

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

CURSO DE ADO EXPRESS/DATASNAP

CURSO DE ADO EXPRESS/DATASNAP CURSO DE ADO EXPRESS/DATASNAP EN DELPHI 7 RESUMEN DE EJERCICIOS Serie A 0 Creación de la base de datos 1 El API de ADO 2 Cadenas de conexión y propiedades 3 Tipos de cursores 4 Recuperación asíncrona 5

Más detalles

TEMA 35: Estándares SGML y XML. Entornos de aplicación.

TEMA 35: Estándares SGML y XML. Entornos de aplicación. Entornos de aplicación TEMA 35: Estándares SGML y. Entornos de aplicación. Índice 1 INTRODUCCIÓN 1 2 SGML 2 2.1 Cómo funciona SGML? 2 2.2 Definición de la sintaxis de un lenguaje SGML 3 2.3 Declaració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