Ontología de Componentes de Software para PyMEs: Informe Final

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

Download "Ontología de Componentes de Software para PyMEs: Informe Final"

Transcripción

1 Ontología de Componentes de Software para PyMEs: Informe Final Rafael González, Miguel Torres Departamento de Ingeniería de Sistemas Pontificia Universidad Javeriana Julio, INTRODUCCIÓN ESTADO DEL ARTE...2 DE DESARROLLO CON OBJETOS A REUTILIZACIÓN CON COMPONENTES...3 Qué es un Componente?...3 De Objetos a Componentes...3 Las Implicaciones del CBD en la Reutilización...3 DESARROLLO BASADO EN COMPONENTES (CBD)...4 El CBD como Nuevo Paradigma de Desarrollo...4 Repositorios de Componentes...5 Arquitectura, Estructura y Patrones...5 DESCRIPCIÓN Y MODELADO DE COMPONENTES...6 Ontología de un Componente...6 Especificación de un Componente...7 Descripción Estática vs. Dinámica...7 Algunos Lenguajes de Descripción y Modelado...7 REQUERIMIENTOS DE PYMES...8 Requerimientos Identificados...8 JERARQUÍA DE COMPONENTES...9 Infraestructuras de Componentes...9 Jerarquía de Componentes de Software para PyMEs EVALUACIÓN Y SELECCIÓN DE LENGUAJE DE MODELADO...13 CRITERIOS DE COMPARACIÓN...13 ADLS EN GENERAL...13 ACME...15 AESOP...16 RAPIDE...17 ADML...17 XACME...18 XADML UML...19 TABLA COMPARATIVA DESCRIPCIÓN DEL LENGUAJE ELEGIDO...20 ACME PARA DESCRIBIR COMPONENTES...21 UML PARA DESCRIBIR COMPONENTES PRUEBA DEL LENGUAJE PARA COMPONENTES...24 DEFINICIÓN DE CRITERIOS...24 REPRESENTACIÓN DE COMPONENTES...25 Representación de un Componente en ACME...25 Representación de Componente en UML...29 EVALUACIÓN...32 Evaluación Acme...32 Evaluación UML...33 DISCUSIÓN CONCLUSIONES...36 REFERENCIAS...36

2 1. Introducción Algunos problemas típicos en el desarrollo de software incluyen: excesiva personalización (es decir, poca reutilización); complejidad en la integración y puesta en marcha; carencia de estándares de coordinación; carencia de interoperabilidad; dificultad para lidiar con el cambio; necesidad de reducir tiempo y costo de desarrollo; requerimientos exigentes de integración; y falta de flexibilidad en tiempo de ejecución [Hall et al, 2001: ]. Desde hace un tiempo, el desarrollo de software ha venido evolucionando de estructuras, a objetos, a componentes y el cuerpo de conocimiento y herramientas asociados a estos últimos ya tienen el suficiente potencial para lidiar con estos problemas típicos y omnipresentes. Toda esta serie de avances se han conlomerado en torno a lo que se ha concebido como un nuevo paradigma de desarrollo: el desarrollo basado en componentes (o CBD, por sus siglas en inglés). Este trabajo se ocupa de una de las partes fundamentales de la ontología de componentes: el lenguaje y la descripción de los mismos. Para ello, hemos tomado como punto de vista el nivel arquitectónico ya que partimos de la base de que en el desarrollo CBD, el énfasis está en la construcción de sistemas desde una perspectiva superior, con el armado de componentes previamente desarrollados. En este nivel, existen tres alternativas de descripción: las ad-hoc o informales, los ADLs (lenguajes de descripción arquitectónica) y las técnicas orientadas a objetos (Goulao & Brito, 2003). La primera alternativa, como es evidente carece de la formalidad necesaria para compartir, documentar y garantizar la calidad y análisis de los modelos. La segunda se va al otro extremo y exige tal formalismo que su aplicación no es general ni ampliamente adoptada a nivel industrial en la práctica. La tercera alternativa es la más popular y creciente, pero es menos expresiva en cuanto a la descripción de las conexiones entre componentes (algo fundamental, ya que aquí es donde debe estar lo nuevo en el desarrollo, los componentes idealmente todos deben estar encapsulados y frecuentemente cerrados a modificaciones). En esta investigación hemos optado por comparar los ADLs más populares o adecuados al CBD, compararlos, elegir de entre ellos el que cualitativamente ofrezca mejores posibilidades para el CBD y probar su desempeño como lenguaje de modelado para CBD. Luego, para no dejar de lado las técnicas OO, también hemos tomado al UML como otro lenguaje posible en este esfuerzo de modelar componentes. Este documento está estructurado de la siguiente manera: En la sección dos se presenta el estado del arte del desarrollo basado en componentes, teniendo en cuenta que la motivación es justificar y sopesar la necesidad de investigar en el tema de ontología (descripción, modelado, especificación) de componentes. Cabe decir que aquí también se han considerado dos aspectos fundamentales. El primero es el hecho de que este proyecto se enmarca en un campo de aplicación específico: el de las PyMEs colombianas, por lo que en el estado del arte se contextualiza este hecho como marco para el trabajo resultante. Por otra parte, se incluye una propuesta de jerarquía (que es otro de los aspectos claves en la definición de ontologías) que ha sido construida como parte de otro proyecto de investigación, vinculado a este, pero ejecutado por estudiantes de pregrado, dirigidos por el investigador principal de este proyecto. En la sección tres se evalúan y comparan algunos de los ADLs más importantes (Acme, Aesop, Rapide, ADML, xacme, xadml) junto con UML y se establece una comparación para seleccionar ACME y UML como objeto e mayor estudio, para lo cual la sección cuatro dedica unas páginas a establecer con mayor detalle la funcionalidad y posibilidades que Acme y UML ofrecen para el CBD. En la quinta sección estos conceptos se ponen a prueba mediante la representación de un componente de ejemplo y una posterior evaluación de Acme y UML que conduce a ideas sobre su adopción y eventual complementariedad. Esta discusión final conduce naturalmente a la sexta y última sección donde se ofrecen algunas conclusiones generales. 2. Estado del arte Antes de entrar en detalles del desarrollo basado en componentes, es preciso aclarar lo que es un componente y su distinción con el más tradicional y conocido concepto de objeto.

3 De Desarrollo con Objetos a Reutilización con Componentes En esta sección presentaremos lo que es un componente y como se diferencia del concepto de objeto (o de clase). Luego, mencionaremos algunas de las ventajas o implicaciones del desarrollo basado en componentes, en torno a la reutilización en el desarrollo de software. Qué es un Componente? La definición de componente no es fácil por tratarse de un concepto amplio y potencialmente ambiguo. En el ámbito del software, se podría pensar, pues, que sin un entendimiento claro de lo que es un componente, es difícil establecer recomendaciones o esfuerzos orientados al desarrollo de software basado en componentes. Esta cuestión (la ontología de un componente) es, entonces, una de las preguntas que merece atención en el campo de la investigación. Sin embargo, existen definiciones que ayudan a situar el contexto de trabajo, para luego, poder describir ontologías que permitan estructurar y delimitar mejor el dominio del problema. Desde una perspectiva lógica, los componentes son una manera de modelar conceptos del mundo real dentro del dominio de un sistema computarizado. Con esto, se vuelven más manejables los problemas complejos, desagregándose en entidades, procesos, roles o transacciones, por ejemplo. Desde una perspectiva física (de software), los componentes son unidades independientes de software que implementan dichos conceptos lógicos. Un componente, entonces, puede ser cualquier unidad de diseño coherente que pueda ser empaquetada, vendida, guardada en una librería (repositorio), asignada (en su desarrollo) a una persona o equipo, mantenida o reutilizada [Meling et al, 2000: ]. Un intento por una definición estándar, algo críptica y recursiva, es el que hacen en [Councill & Heineman, 2001: 7]: Un componente de software es un elemento de software que se ajusta a un modelo de componentes y que puede ser independientemente desplegado y compuesto sin modificación, de acuerdo con un estándar de composición. Lo primero que hay que hacer es distinguir entre un componente y un objeto. De Objetos a Componentes Las nociones de instancia, identidad y encapsulación dan lugar al concepto de objeto, cuyas propiedades son: ser una unidad instanciada con identidad única; tener un estado que puede ser externamente observable; y encapsular su estado y comportamiento. El componente, por otra parte: es una unidad de despliegue independiente; es una unidad de composición por terceros; y no tiene un estado observable (externamente) [Szyperski, 2002: 36-37]. Desde la era de la programación estructurada, la idea tras las librerías, subrutinas y tipos abstractos de datos era la modularización. En los ochentas y noventas, con el paradigma orientado a objetos (OO) se generó la posibilidad de sistemas con alta encapsulación y facilidad de mantenimiento. En la orientación a objetos, un componente correspondería normalmente a una colección de clases interrelacionadas que proveen un conjunto de servicios con consistencia lógica [Moisan et al, 2003: 22]. Para algunos, de hecho, el CBD es un desarrollo natural del paradigma OO [Orfali et al, 1996; Brown & Wallnau, 1998]. Se habla entonces del enfoque de componentes orientados a objetos, que incluye beneficios como: interoperabilidad, extensiblidad, fácil reutilización, fácil ensamblado, flexibilidad en tiempo de ejecución, estándares de diseño integrados, flexibilidad de desarrollo, y velocidad, calidad y confiabilidad al usar componentes comerciales (Componentes-off-the-shelf, COTS) [Hall et al, 2001: 2873]. Sin embargo, parece ser que el paradigma OO todavía no ha demostrado en la práctica ser suficiente para la reutilización, ya que la mayoría de los desarrollos siguen haciéndose de cero. Por otra parte, el paradigma OO se centra en técnicas y modelos de programación, mientras que el CBD extiende estas ideas a otros ámbitos que complementan el de la programación. Por ejemplo, para poder lograr una interacción efectiva entre componentes, es preciso adoptar una disciplina rigurosa de diseño y adoptar notaciones estándar de modeladomodelado, acompañadas de unas reglas de diseño y una documentación estrictas. Esta es la noción básica del Diseño por Contrato, disciplina que fue concebida en la orientación a objetos, pero que se acopla más naturalmente al CBD (Bertolino & Mirandola, 2003). Las Implicaciones del CBD en la Reutilización Ya se ha establecido que una de las ventajas más importantes del CBD es la posibilidad de reutilización que brinda. La idea es construir sistemas a partir de componentes probados y confiables, como se hace en otras industrias (Apperly, 2001). Para ello, es preciso extender la tarea de comprensión: de comprensión de software a comprensión de componentes. Esto implica que el objetivo ya no es la comprensión del código, sino del funcionamiento del componente, sus aplicaciones y sus requerimientos de adaptación [Andrews et al, 2002:

4 362]. Esto quiere decir que además de tener un modelo que describa técnicamente al software, el componente debe entenderse pensando en su reutilización (funcionalidad, requerimientos y restricciones). Cumplido esto, será posible efectivamente construir sistemas integrando componentes y dedicando el esfuerzo de codificación a la integración (pegamento) de los componentes y no a la implementación de funcionalidad. Cabe mencionar que la reutilización aún no es la panacea que se podría esperar. Si bien la robustez, confiabilidad e interoperabilidad que se puede obtener son muy deseables, dichos beneficios deben superar el costo que implica el CBD para que la reutilización sea realmente atractiva en la práctica. De hecho, algunos estudios indican que la adaptación de componentes complejos de software puede no ser más beneficiosa que desarrollar el software desde cero [Morel & Alexander, 2003: 142]. El costo de adaptación no es el único problema potencial de la reutilización: la generalidad y adaptabilidad que deben ser inherentes a los componentes, pueden implicar que se perjudique el desempeño de los componentes: normalmente el desempeño y la genericidad son inversamente proporcionales. De hecho, un sistema basado en componentes en general tiene un menor desempeño que un sistema optimizado, desarrollado de cero (Bertolino & Mirandola, 2003). Otro impedimento para una adecuada reutilización de componentes es que el desarrollador del componente puede hacer suposiciones de sus posibles usos que queden implícitas. Si dichas suposiciones no son explícitas o son informalmente especificadas, descubrirlas será difícil o imposible para quien quiera reutilizar el componente (DePrince & Hofmeister, 2003). Por lo anterior, se puede concluir que la reutilización no es un beneficio directo del desarrollo basado en componentes. Para que sea atractiva y efectiva, debe estar acompañada de una adecuada descripción de los componentes que disminuya el costo de adaptación y permita hacer ajustes en el desempeño sin alterar la interoperabilidad o aumentar el costo significativamente. Una de las formas de conseguir esto es con una especificación formal adecuada; dicha especificación debe incluir las restricciones estáticas (consistencia) y dinámicas (secuencias permitidas, redefiniciones permitidas) del componente. Sería inocente creer que ya existe un componente en un repositorio que satisfaga totalmente las necesidades de un problema. El componente, deberá ser, entonces adaptado al problema y a la arquitectura del sistema en construcción. Desarrollo Basado en Componentes (CBD) En esta sección establecemos el desarrollo basado en componentes como un nuevo paradigma de construcción de software y la necesidad de que, para que sea exitoso, esté acompañado de un adecuado repositorio de componentes y del diseño y de la comprensión y diseño de arquitecturas, patrones y estructuras. El CBD como Nuevo Paradigma de Desarrollo El desarrollo tradicional de sistemas de información, basado en grandes equipos de trabajo y largos períodos de tiempo, ha producido resultados indeseables desde el punto de vista económico y cronológico, perjudicando la competitividad de las organizaciones. El reto más grande para el desarrollo de sistemas exitosos es, pues, la necesidad de desarrollar sistemas en corto tiempo y a bajo costo en un medio complejo y cambiante (Brown, 2000). Esto sugiere la necesidad de una solución que ofrezca a las organizaciones la posibilidad de desarrollos flexibles y adaptables a la organización y su tecnología existente. Esa solución parece ser el desarrollo basado en componentes (Allen & Frost, 1997; Apperly, 2001; Brown, 2000; Eeles & Sims, 1998; Zahavi, 2000). Dicho enfoque promete mejoras en calidad, productividad, desempeño, confiabilidad e interoperabilidad; a su vez, reduciendo el tiempo de desarrollo, documentación y mantenimiento y bajando el costo de entrenamiento (Herzum & Sims, 2000; Szyperski, 2002). Las tendencias en la investigación y práctica de la ingeniería de software, indican que los desarrollos futuros seguirán el paradigma CBD, lo que queda demostrado por el número de tecnologías de componentes disponibles hoy (CORBA, EJB, DCOM y.net) y por la cantidad de componentes disponibles en el mercado (COTS) [Andrews et al, 2002: 359]. El CBD promete el mejoramiento en la calidad, productividad y reutilización en el desarrollo de software [Yau & Dong, 2000: 369], aunque en otras industrias no es nada nuevo (Apperly, 2001). Uno de los logros de la Revolución Industrial fue precisamente éste. De allí que hoy las industrias automotriz, electrónica y de la construcción funcionen con este paradigma. Los repuestos para automóviles, los componentes interiores de un computador o los patrones de diseño arquitectónicos son reutilizados en cada nuevo proyecto, haciendo uso de una rigurosa y confiable estandarización, sin por ello (como lo demuestra el dinamismo de esos sectores) perder en innovación. En particular, en los últimos años ha surgido la ingeniería de software basada en componentes (CBSE, por sus siglas en inglés) como un nuevo paradigma de desarrollo de software plug-and-play, donde los componentes

5 se obtienen de repositorios en los cuales exponen sus interfaces. Dicho paradigma está orientado a los requerimientos de aplicaciones complejas y normalmente distribuidas, mientras que reduce los costos de mantenimiento y aumenta la confiabilidad [Meling et al, 2000: 107]. Esta forma de hacer ingeniería de software requiere de la inclusión de aspectos particulares y fundamentales para su éxito: selección de la arquitectura y de los componentes; adaptación e integración de los componentes dentro de la arquitectura elegida; y modificación de los componentes a medida que cambien los requerimientos del sistema [Griss & Pour, 2001: 37; Andrews et al, 2002: 359: Apperly, 2001: 27]. Dicha modificación, es posible que no sea tan sencilla como en un software tradicional, ya que se debe garantizar la compatibilidad entre las distintas versiones de los componentes de fuentes distintas; una recomendación valiosa para lograr esto es que la CBSE sea dividida en dos niveles: el nivel de los componentes y el nivel de la aplicación (Bertolino & Mirandola, 2003), para poder mantener una adecuada independencia que facilite el mantenimiento con componentes que son desarrollados por terceros. Esto es, por una parte se hará ingeniería de los componentes y, por otra (pero no por aparte) se hará le ingeniería de la aplicación. La ingeniería de software basada en componentes es aun una disciplina inmadura [Apperly, 2001: 22] que puede aprender mucho de otras ramas de la ingeniería y de la experiencia con orientación a objetos e ingeniería de software tradicional, pero una de las certezas es que para ser exitosa debe contar con un adecuado repositorio de componentes. Repositorios de Componentes Los repositorios son un prerrequisito de un adecuado CBD; si sus colegas no pueden encontrar sus componentes, no los usarán; si sus clientes no pueden encontrar sus componentes, no los comprarán. Por ello, el campo de investigación en recuperación (retrieval) de componentes de sus repositorios es altamente dinámico. Se requieren repositorios efectivos, fáciles de usar, lo más completos posibles y efectivos en la recuperación de componentes. Un problema que surge con el uso y mantenimiento de componentes en repositorios es el hecho de dar certeza a los usuarios de que los componentes cumplen con las mínimas expectativas de seguridad (Khan & Han, 2003). Un integrador o arquitecto de software que utilice componentes desarrollados por terceros espera que los componentes tengan las propiedades que sus desarrolladores afirman, además de mantener las normas básicas de calidad, legitimidad, abstracción, encapsulamiento, bajo acoplamiento y alta cohesión. De esto se desprende la necesidad de que exista una autoridad certificadora, la cual debe efectuar un proceso que incluya lo siguiente:...1) Outsourcing de componentes: administrar el contrato de Oursourcing para desarrollo de componentes y auditar el desempeño de la entidad desarrolladora; 2) Selección de Componentes: Seleccionar los componentes adecuados de acuerdo a los diferentes requerimientos de los usuarios, funcionalidad, confiabilidad, seguridad, desempeño, etc.; 3) Pruebas de Componentes: Confirmar que los componentes satisfacen los requerimientos con aceptable calidad y confiabilidad... (Cai et al, 2000). Las políticas que deben tenerse en cuenta para llevar a cabo este proceso de certificación serán (Ibíd.): 1) el desarrollo por Outsourcing de componentes debe estar a cargo de un administrador o contratista particular que verifique el proceso de desarrollo; 2) Todos los componentes candidatos deben ser probados contra todos los defectos conocidos además de ser probados en un ambiente simulado o igual a aquel en que será puesto en producción. Además de la certificación de conformidad de un componente, es importante también que la autoridad certificadora vele por los aspectos de seguridad de los componentes estudiándolos de la siguiente forma (Khan & Han, 2003): 1) Caracterización de los componentes atómicos de manera independiente; 2) chequeo de compatibilidad de las propiedades de seguridad entre componentes; y 3) visualización de las propiedades hacia las entidades externas. Aproximaciones adicionales como la utilización y aplicación de diferentes estándares y documentos como el Orange Book del Departamento de Defensa de Los Estados Unidos, el Common Criteria del NIST e ISO/IEC 15408, pueden apoyar la labor de la autoridad certificadora. Un ejemplo de esta aproximación de repositorio y autoridad certificadora es el proyecto CLARiFi, proyecto que no solo cubre el cumplimiento de estándares por parte de un componente sino además valida sus propiedades particulares (Brereton et al, 2002; Ci & Tsai, 2000). Arquitectura, Estructura y Patrones En los últimos años, el desarrollo de software ha orientado su enfoque hacia arriba, en dirección al nivel abstracto de especificación arquitectónica (Bertolino & Mirandola, 2003). En el nuevo ámbito de los

6 componentes, una arquitectura es un conjunto de decisiones respecto de la plataforma, un conjunto de estructuras (frameworks) de componentes, y un diseño de interoperabilidad entre dichas estructuras [Szyperski, 2002: 419]. La estructura es una instancia particular de una arquitectura (dedicada y enfocada en torno a unos mecanismos particulares) (Ibíd.). Una estructura puede ser vertical u horizontal. Es vertical cuando está diseñada para un dominio de aplicaciones determinado, para un sector de la industria. Es horizontal cuando apunta a una funcionalidad general, aplicable a diversas industrias (por ejemplo, una estructura para pagos electrónicos). La transición hacia el CBD ha introducido nuevas infraestructuras tecnológicas distribuidas basadas en el modelo COM (Component Object Model) de Microsoft, la arquitectura CORBA (Common Object Request Broker Architecture) del OMG o los EJB (Enterprise Java Beans) de Sun Microsystems. Cuando estos modelos se acoplan a una arquitectura de software bien definida por capas, se convierten en el mejor soporte tecnológico para desarrollar la infraestructura de tecnologías basadas en componentes [Hall et al, 2001: 2871]. Por otro lado, están los patrones de diseño que existen para optimizar el diseño de sistemas orientados a objetos, basándose en un catálogo de estructuras genéricas orientadas a la solución de problemas recurrentes. Algunos ven los patrones como micro arquitecturas que se distinguen de las estructuras por ser más abstractos y pequeños [Szyperski, 2002: ]. Yau y Dong (2000) proponen el uso de patrones de diseño para integrar los componentes en el CBD. Luego de que los diseñadores han elegido un patrón de diseño para describir las relaciones entre los componentes (dentro de un sistema en particular), el patrón debe ser instanciado; dicha instanciación consiste en transformar las relaciones de participación (del patrón) en interacciones de diseño. Luego se verifica la estructura e interacciones, garantizando que se cumplan con las restricciones del patrón y se puede proceder a usar envoltorios (wrappers) como decoradores de los componentes. De esta manera, la arquitectura y los patrones quedan integrados formalmente al diseño del sistema. Lo que se puede rescatar de esta sección es que con componentes, la ingeniería de software centra su atención en el diseño de alto nivel con arquitecturas, estructuras y patrones (en ese orden jerárquico) para luego construir el sistema con componentes interoperables, adaptados a este diseño. Descripción y Modelado de Componentes Para que el desarrollo basado en componentes sea una realidad, proponemos que debe estar acompañado de una definición, especificación y contextualización adecuados. En esta sección abordamos algunos temas asociados con la descripción de componentes, como su ontología y los lenguajes que pueden usarse para especificarlo. Ontología de un Componente En el campo de los componentes de software, una ontología se ocupa de la definición semántica de los componentes (incluyendo comportamiento y aspectos no-funcionales). Dicha semántica tiene dos dimensiones: el conocimiento del dominio del componente y el conocimiento del software del componente (Pahl, 2003). El conocimiento del dominio provee la estructura básica (motherboard) sobre la que se especifica el conocimiento del producto [Andrews et al, 2002: 361]. Con frecuencia, este tipo de información de dominio es la que dirige el modelado de componentes [Ibíd.: 362]; dicha información se enfoca en las propiedades no-funcionales (desempeño, seguridad, etc.), con atención débil a descripciones orientadas al usuario (condiciones de acceso e istanciación, por ejemplo) (DePrince & Hofmeister, 2003). Se podría pensar que descripciones formales del código tipo caja blanca solucionarían este problema, proveyendo suficiente información para la utilización y comprensión del componente, pero el esfuerzo necesario para entender y usar estos modelos dificulta el CBD, que debe estar guiado por modelos de caja negra [Andrews et al, 2002: 360; Weinreich & Samentinger, 2001: 39]. Por ello, un modelo más adecuado, sería uno en el que se brinde un entendimiento tanto del dominio (requerimientos vs. capacidades), como del programa (interfaces, tipos de datos, sintaxis, parámetros, rangos aceptables) y de la situación (estructura, conexiones, flujos) [Andrews et al, 2002: 363]. Aunque una ontología suele asociarse a la definición de un contexto (o vocabulario), en este caso nos referimos no solo al contexto, sino a las condiciones y características internas del componente, las cuales deben ser especificadas de alguna forma.

7 Especificación de un Componente Partiendo de la definición de componente y cómo este puede integrarse en una estructura o jerarquía, se pueden describir diferentes formas de especificación de componentes para que sean fácilmente identificables dentro de dicha estructura o jerarquía. Inicialmente, el componente puede ser descrito en términos de su interfaz, además de la información básica del llamado (este es el tipo de especificación que ofrece un lenguaje de descripción de interfaces o IDL), pero no muestra información adicional del componente como: desempeño, seguridad y sincronización (DePrince & Hofmeister, 2003). Dos tipos de métodos han sido propuestos para clasificar y especificar componentes, no solo en términos de su interfaz, sino de otras características (desempeño, seguridad, requerimientos): 1) especificación informal: la cual se centra en describir mediante lenguaje natural las características del componente y su interfaz; y 2) especificación formal o semiformal la cual se orienta a los aspectos de políticas de uso así como descripción del dominio del problema, información semántica y ontológica del mismo (DePrince & Hofmeister, 2003, Morel & Alexander, 2003, Meling et al, 2000). Propuestas semiformales como Lips (DePrince & Hofmeister, 2003) presentan además información relacionada con políticas de uso del componente y características de soporte de instancias e hilos. Otra aproximación semiformal es la propuesta en CDM (Component Description Manager) (Meling et al, 2000), que presenta un framework de clasificación para la administración efectiva de componentes, basándose en el dominio del problema y en información semántica y ontológica del componente. Dicho árbol de clasificación de componentes se concentra en las características, gramática, componentes y estándares. Estos tipos de clasificación son útiles en diferentes ámbitos, por ejemplo: en los brokers o repositorios de componentes, para facilitar la búsqueda e identificación de los mismos, o en entornos de desarrollo para verificar y estudiar la compatibilidad y desempeño del componente. Descripción Estática vs. Dinámica Además del alcance de una especificación, un componente puede describirse de acuerdo a su estructura estática o su comportamiento dinámico. La estructura estática está descrita en términos de servicios prestados por el componente y es generada cuando la aplicación es ensamblada, los resultados de esta descripción son válidos para cualquier instancia de ejecución de la misma, aunque este tipo de descripción no permite identificar ciertas restricciones difíciles de especificar e imposibles de verificar (Bertolino & Mirandola, 2003). La estructura dinámica en general puede describir secuencias legítimas de llamadas dentro del componente y comportamiento de los servicios u operaciones del componente en un momento dado de ejecución del mismo [Moisan et al, 2003: 23]. Este tipo de evaluación de componentes para efectuar el chequeo del componente va en detrimento del desempeño del mismo, pero trae consigo ventajas adicionales como la simplicidad y expresividad de el comportamiento dinámico expresado por el componente (DePrince & Hofmeister, 2003). Un ejemplo de este tipo de descripción, es la proveída por el Abstract State Machine Language (AsmL) basado en la tecnología.net, que incorpora no-determinismo y transacciones, y genera lenguaje IL, para efectuar la verificación del componente en tiempo de ejecución (Barnett et al, 2003). Otra aproximación consiste en definir el componente en forma matemática y jerárquica, basado además en el uso de máquinas de estado finito, para modelar tanto las clases como los componentes que las contienen [Moisan et al, 2003: 25]. Propuestas adicionales como la hecha por Baum y Becker (2000) están orientadas a lo que se ha denominado componentes genéricos. La definición de un componente genérico se da para que el desarrollador que va a usar el componente pueda incluirlo en su sistema, configurándolo de acuerdo a sus necesidades; por ejemplo, seleccionando algún algoritmo particular o definiendo algunas variables de desempeño del componente para que se amolde al sistema implementado (Ibíd.). Algunos Lenguajes de Descripción y Modelado Ya hemos presentado modelos y alternativas de especificación de componentes, pero en la práctica se requiere que la especificación correspondiente a un modelo sea expresada por medio de un lenguaje de descripción. Estos lenguajes pueden ser formales o informales, como hemos visto; pueden estar orientados a la arquitectura o al componente de manera aislada, pero deben ser útiles y deseablemente estándares para facilitar su adopción, comprensión e interoperabilidad. Un primer candidato para ser lenguaje de descripción y modelado de componentes resulta obvio, se trata del UML, que ya sin duda se ha convertido en el lenguaje estándar para modelar software orientado a objetos. Sus fortalezas son, entre otras, que integra de manera natural varios enfoques de modelado antes dispersos y, por ello, se convierte en una alternativa más fuerte, madura e integradora. Además, su popularidad y las herramientas disponibles para trabajar con UML lo hacen atractivo en la práctica. Sin embargo, existen quienes

8 argumentan que UML es aun inadecuado y que recurre a descripciones informales, debido a que los diagramas de clase son estáticos y por ello no suficientes para describir patrones sin el uso de notas ambiguas (Eden, 2002). Por ejemplo, la redefinición válida de operaciones, es una restricción que no queda formalmente modelada con UML [Moisan et al, 2003: 23]. No obstante, la utilización de UML dentro de un conjunto de prácticas y lenguajes orientados al desarrollo basado en componentes, lo convierte en una de las herramientas más adecuadas para el diseño (particularmente visual) de dichos sistemas y el modelado de componentes (Houston & Norris, 2001). Un desarrollo que extiende el UML, pensando en componentes es Catálisis (D Souza & Wills, 1999). El CBD y Catalysis son hoy ejemplos claros de técnicas de modelado que soportan el análisis y diseño de componentes [Meling et al, 2000: 108]. El aporte de Catalysis está en la definición no-ambigua de las interfaces de los componentes y en la clarificación de las interfaces de los subsistemas para asegurar que todos se adhieran al mismo modelo y reglas de negocio. En efecto, esto significa que Catalysis permite describir un componente de acuerdo con los tres niveles presentados en la sección 3.1. [Andrews et al, 2002: 364]. Su desventaja, no obstante, es que cualquier representación de un componente mediante Catalysis, obliga a que el componente haya sido desarrollado en Catalysis, impidiendo así la descripción de componentes ya existentes o creados con otro enfoque. Por último, mencionaremos al Lenguaje de Máquina de Estados Abstracta (AsmL, por sus siglas en inglés) de Microsoft Research. El AsmL es un lenguaje de especificación ejecutable, parte de la plataforma.net que incorpora no-determinismo (en comportamiento) y transacciones (Barnett et al, 2003). La posibilidad de que sea ejecutable, provee a este lenguaje de un potencial en cuanto a la verificación de componentes en tiempo de ejecución; no solo permite verificación estática, sino monitorizar el comportamiento del componente. Queda pendiente valorar la posibilidad de usar lenguajes de descripción de arquitecturas (ADLs) como una alternativa viable y suficiente para describir componentes. En principio, su alto nivel de abstracción y poco uso comercial los hacen poco atractivos, pero el enfoque del CBD hacia estructuras de alto nivel y la completitud de los ADLs para expresar estructuras y conexiones los hacen atractivos. Requerimientos de PyMEs En esta sección se describen los requerimientos de CBSD para las PyMES ubicadas en la ciudad de Bogotá. La información base proviene de las conclusiones arrojadas por un estudio llevado a cabo por estudiantes de la carrera de Ingeniería de Sistemas de la Universidad Javeriana, titulado Jerarquía Y Granularidad De Componentes De Software, además de el documento publicado por Fedesoft (Federación colombiana de la Industria del Software) titulado Descripción del Sector del Software Análisis de Mercado. Requerimientos Identificados 1. Necesidad de Adquisición de nuevo software a corto plazo 2. Necesidad de Conseguir software basado en componentes con las siguientes características a. Los componentes debe estar organizados en forma de biblioteca (Prioridad Alta) b. La biblioteca debe permitir la búsqueda de componentes por funcionalidad (Prioridad Alta), y en combinación con otras características como son el lenguaje de programación en que se desarrollo el componente, la arquitectura que soporta el componente (Prioridad Media). c. La arquitectura de soporte de los componentes existentes en la biblioteca puede en general ser de cualquier tipo, aunque la arquitectura cliente servidor es la más usada. d. Los componentes deben ser de fácil extensión, para construcción de herramientas que soporten el cambio (Prioridad Alta). e. Los componentes deben ser fácilmente modificables, por tanto se asume que los componentes que esperan obtener las PyMES sea de código abierto (Prioridad Alta). f. Los componentes deben ser potables entre diferentes plataformas (Prioridad Alta). 3. La documentación del componente debe ser clara y concreta para reducir el tiempo de acoplamiento del componente con el nuevo sistema. 4. Generidicad de los componentes para su uso más extenso y si es necesario que el usuario del componente lo extienda de acuerdo a sus necesidades.

9 Jerarquía de Componentes Como resultado de el proyecto de grado titulado: JERARQUÍA Y GRANULARIDAD DE COMPONENTES DE SOFTWARE PARA PYMES EN BOGOTÁ, trabajo realizado dentro del marco del proyecto PICS, se ha propuesto una jerarquía de componentes para las PyMEs Colombianas, basada en diferentes modelos existentes y en las características mas relevantes de ellos. Infraestructuras de Componentes Para construir una jerarquía de componentes es importante estudiar algunas de las diferentes clasificaciones existentes, a continuación son expuestas cuatro tipos de clasificaciones. Infraestructura Común de Componentes en Capas Esta clasificación surge de diseñar sistemas basados en componentes por medio de capas, donde se diferencian claramente cuatro (4) tipos diferentes de componentes (Heineman & Council, 2001: 818), que pueden integrar un sistema (ver figura 1). Figura 1. Infraestructura común de componentes por capas (Montilva, 2004) Los elementos de la capa de usuario proveen interfaces externas y el conocimiento de la interacción con el usuario (GUI Interfaces Gráficas de usuario). Estos componentes requieren de servicios que se activan a través de la solicitud por parte del usuario. Los componentes de Flujo de trabajo y procesos de control manejan procesos complejos, automatizados del negocio, que interactúan con servicios del negocio. Dentro de este tipo de componentes se pueden encontrar: Reguladores de Proceso, Administrador de Colas, etc. Los componentes de Servicios de Negocio y Adaptadores de Sistemas Legacy, proveen la implementación de reglas de negocio y la actividad operacional, a través de implementaciones de objetos de negocio o sistemas legados ubicados por debajo de nuevas interfaces de componentes. Finalmente encontramos la capa de Servicios de Sistemas Operativos y Datos, donde están presentes los componentes que proveen la funcionalidad que interactúa con el ambiente de almacenamiento persistente, incluyendo sistemas de administración de bases de datos y sistemas de archivos. Ejemplos de estos componentes son: Componentes de Datos, de Infoware, Administradores de Transacciones, entre otros. Dentro de esta definición también se encuentra la capa de Integración (Middleware), donde residen los elementos que facilitan la integración de componentes a través de las múltiples plataformas y desarrollos. Arquitectura de Sistemas de Software Basados en Componentes La Arquitectura de los Sistemas de Software Basados en Componentes, incluye tres capas (ver Fig. 2). Cada tipo de aplicación es representada como un sistema independiente, construido por medio de componentes

10 desde nivel técnico hasta componentes encargados de contener procesos de la lógica del negocio. Los componentes que hacen parte de cada capa pertenecen a un nivel específico, y apuntan a un negocio en particular o áreas de dominio de aplicación. Esta infraestructura de componentes apoya las interfaces de plataformas independientes, permitiendo flexibilidad y sistemas abiertos. Fig. 2: Capas de las aplicaciones basadas en la reutilización dirigida a la Ingeniería de Software de Negocio Los componentes específicos de negocio contienen exclusivamente funciones del dominio especializado, son componentes de alto nivel, los cuáles, por medio de su integración al sistema satisfacen una meta de negocio especial. Los componentes de integración (middleware), son elementos que interrelacionan los diferentes dominios a los que pertenecen los componentes que hacen parte del sistema. Si el componente se encuentra más cercano a los de la capa inferior, se distinguen por ser los que administran la comunicación técnica entre los componentes de negocio, por ejemplo aplicaciones que se encargan de llamadas a funciones remotas, ahora, si el componentes trabaja en mayor escala con los componentes específicos de negocio (capa superior) son componentes administradores de bases de datos, o software que puede permitir la integración de componentes de negocio para construir aplicaciones complejas, como un sistema de administración de flujo de trabajo, en otras palabras, los componentes de integración apoyan específicamente aspectos técnicos de colaboración, pero no son aspectos concretos del dominio del negocio. Los componentes del sistema de software, son componentes exclusivamente técnicos, que permiten la operabilidad del sistema. Infraestructura de Componentes Orientada a la Reutilización La Reutilización e infraestructura de Componentes de la Ingeniería de Software de Negocio (Heineman & Council, 2001), es una clasificación que busca definir las diferencias claves existentes entre los componentes, su complejidad, alcance, nivel de funcionalidad, etc. Esta clasificación se enuncia a continuación: Componentes GUI: Estos son los tipos de componentes que se encuentran con mayor frecuencia dentro del mercado. Los Componentes GUI, son aquellos que permiten construir interfaces para el usuario. La construcción de un componente GUI robusto exige por parte del desarrollador un alto nivel de conocimiento y compromiso con la Ingeniería de software basada en componentes. Componentes de Servicio: Este tipo de componentes proveen servicios comunes requeridos por diferentes aplicaciones, como acceso a bases de datos, servicios de mensajería y transacciones e integración con servicios del sistema. Una de las principales características de estos componentes, es que todos necesitan usar sistemas o infraestructura adicional para poder ejecutar su funcionalidad. Otra función común de estos componentes es facilitar la Integración de las Aplicaciones de Negocio (IBA Integration of the Business s Applications), por esta razón es común encontrar combinados estos componentes con herramienta IBA como Servidores de Transacciones, motores de transacción de datos y sistemas de flujo de trabajo. Estos componentes, por si mismos no proveen funcionalidad al sistema, son menos complejos que los componentes de dominio, y más que los componentes GUI. Componentes de Dominio: Estos componentes, cuando son reusables, pertenecen sólo a un dominio de aplicación específico, y no pueden ser reutilizados fuera de él. Estos componentes son difíciles de diseñar y construir. Por hacer parte de un dominio de aplicación en particular, deben contar con una infraestructura de aplicación propia. El encargado de diseño e implementación del componente requiere un alto grado de

11 conocimiento y experiencia dentro del dominio. Los casos de negocio que requieran dentro de su implementación componentes de dominio, requerirán tanto componentes GUI como de Servicio. Clasificación por Facetas La clasificación por facetas, analiza cierta área del dominio e identifica un conjunto de características básicas (facetas) de cada componente haciendo uso de un esquema de descripción [función, tipo de objeto, tipo de sistema]. La función describe el carácter operacional y funcional que cumple cada componente dentro de un sistema; se tienen en cuenta las generalidades de descripción que tendrán los componentes. El segundo aspecto de la clasificación por facetas, es el tipo de objeto, este es especificado cuando se clasifica un componente, por ejemplo, un componente J2EE puede ser clasificado como tipo: WebContainer, EJBContainer, entre otros. El tercer aspecto esta dado por el tipo de sistema, también será definido al momento de clasificar un componente, aquí se indicará a que tipos de sistemas puede ser aplicado este componente, en que sistemas es usualmente utilizado, si obedece a algún tipo de patrón o una indicación que le permita su correcto desempeño dentro de una arquitectura basada en componentes. Uno de los beneficios de la clasificación por facetas es que se puede acceder a un ítem clasificado sin saber el nombre de este, asumiendo características o nombres (Asunciones) y de esta forma se alcanza la comprensión del componente. Por otra parte, una nueva faceta puede ser agregada en cualquier momento, sin causar confusión en la clasificación de los ítems. Característica clave si desea incluirse el componente dentro de un repositorio, ya que facilita el proceso de mantenimiento de este y el de selección de componentes. Jerarquía de Componentes de Software para PyMEs Son varias las características comunes que poseen las tres primeras clasificaciones, pero existen dos en particular muy importantes en este contexto: cada una de estas clasificaciones encapsula la funcionalidad de cada componente orientada a actividades de negocio y en segundo lugar se apoyan en una arquitectura genérica de sistemas basados en componentes, esto sumado con la principal característica de la clasificación por facetas, describir un componente en términos de funcionalidades y principales atributos, da las primeras bases para la construcción de la jerarquía de componentes de software para PyMes. La Jerarquía de Componentes de Software se compone de seis (6) niveles (fig. 3), aquí se sugiere un modelo de arquitectura para las aplicaciones basadas en componentes que utilicen esta clasificación de componentes. C O M P O N E N T E S G U I C O M P O N E N T E S D E I N T E G R A C I Ó N COMPONENTES DE NEGOCIO COMPONENTES DE SERVICIO COMPONENTES OPERACIONALES DE PERSISTENCIA COMPONENTES OPERACIONALES Figura. 3: Jerarquía de Componentes de SW y Arquitectura de SW Componentes de negocio: estos componentes son los encargados de contener la lógica de negocio especializada y contienen los módulos más representativos del dominio de la solución; esta es la razón por la cual pertenecen solo a cierto tipo de aplicaciones. El mayor valor agregado de un sistema se logra por medio de la integración de estos componentes. Características principales: 1. Realizan tareas específicas que involucran requerimientos de dominios de aplicación especializados.

12 2. Su implementación suele ser compleja por la lógica de negocio que envuelven ya que proveen un conjunto de servicios bien definidos en un dominio específico. 3. El proceso de integración de este tipo de componentes requiere un proceso de Ingeniería de Dominio, este sirve para desarrollar y mantener modelos de dominio y arquitecturas del dominio 1. Componentes de Servicio: estos componentes se encargan de ejecutar procesos complejos y automatizados. Los tipos de servicios que ofrecen son requeridos por diferentes tipos de aplicaciones. Características principales: 1. Pueden administrar la interacción con un número de servicios o con uno o más componentes de negocio para completar procesos de negocio robustos. 2. Pueden ser adaptados e interactuar, en varios dominios. Componentes Operacionales de Persistencia: estos componentes se encargan de interactuar con la información persistente del sistema. No envuelven lógica del negocio, al igual que los de servicio, y pueden ser requeridos en un mayor intervalo de dominios de aplicación. Características: 1. La generalidad de las funciones que desarrollan hacen que estos componentes sean muy adaptables. 2. Por medio de la especialización de un componente de este tipo puede obtenerse un componente de servicio. 3. Se encarga del proceso de administración de transacción entre el lugar de almacenamiento (base de datos generalmente) y el negocio. 4. Se encargan del control sobre la seguridad de la información que el sistema utiliza. Componentes Operacionales: estos componentes ofrecen la base operativa para el funcionamiento de un sistema sobre el Hardware; sobre estos se crean los modelos de arquitectura de software. Son comunes a la gran mayoría de las aplicaciones. 1. Representan la infraestructura primaria para un modelo más complejo de software. 2. No involucran lógica del negocio. 3. Se encargan de la administración de recursos del hardware. Componentes de Integración: estos componentes facilitan la integración de los componentes dentro de los sistemas a través de múltiples plataformas y desarrollos. La naturaleza de estos componentes obliga a hacer uso de ellos dentro de la mayoría de los sistemas. 1. No envuelven lógica del negocio. 2. Apoya los procesos de flujo de información más allá de los límites de cada componente, permitiendo la interacción entre los elementos que integran el sistema. 3. La implementación de estos componentes no interfiere con el diseño o los servicios de los componentes que hacen parte del sistema, sólo compila las librerías de tipos de datos y la sintaxis del lenguaje de definición de sus entradas y salidas (Heineman & Council, 2001). 4. Dentro de los diferentes servicios que ofrece, no se encuentra incluido el de funcionalidad directa con usuario. Componentes GUI: estos componentes se encuentran en mayor cantidad dentro del mercado de software, se ha demostrado que no es rentable para las empresas desarrollar sus propios componentes GUI, en el año de 1999 el mercado de componentes GUI ascendía a $300 millones de dólares (Heineman & Council, 2001). 1. Proporcionan las interfaces externas de las aplicaciones y conocen el funcionamiento de la interacción con el usuario. 2. Muchos entornos de desarrollo incluyen componentes GUI, esto facilita el proceso de construcción. 3. Por si mismos, no representan un sistema funcional, ya que necesitan componentes más complejos para ejecutar las peticiones del usuario. 1 Dominio de una Aplicación: Representa todos los aspectos del problema de Usuario. Esto incluye el ambiente físico donde se ejecutará el sistema, los usuarios, y sus procesos de trabajo.

13 3. Evaluación y selección de lenguaje de modelado En esta sección se establece una comparación entre lenguajes de modelado que puedan servir para especificar componentes de software para PyMEs. Se han considerado varios ADLs además de UML. Las razones para estudiar los diferentes ADLs se presentan a continuación. Aunque los ADLs están hechos para describir arquitecturas de sistemas de software (en particular usando patrones o estilos) esto se hace mediante la representación de componentes y conectores que satisfacen unas determinadas restricciones (impuestas por el estilo). La clave en un ADL está en describir las interfaces de estos componentes pero dejar sin especificar su funcionamiento interno (Riemenschneider & Stavridou, 1999). Esto quiere decir que naturalmente se puede identificar un componente arquitectónico de bajo nivel con un componente reutilizable en el paradigma CBD (Riemenschneider & Stavridou, 1999). Sin embargo, se podría pensar que la incapacidad del ADL de describir el funcionamiento interno del componente es una limitante. Esto no es cierto, si se supone que el desarrollo basado en componente usualmente trabaja con componentes cuya especificación interna es desconocida (COTS, por ejemplo). Más aun, la tendencia va dirigida a diseñar y construir sistemas con una visión de alto nivel en que solo se tienen en cuenta las especificaciones de interfaces. Por otra parte, dado que el CBD es una a aproximación para la construcción de sistemas complejos donde distintos actores tienen distintos intereses, es preciso que exista una fuente común de información para que se puedan entender entre sí y una herramienta que permita esta comunicación y garantice la consistencia del sistema. Los ADLs entonces se ofrecen como dicha herramienta, integrada dentro del paradigma CBD (Grau, et al, 2002: 4-5). Mientras los componentes ayudan a distribuir el trabajo entre los miembros del equipo, el ADL ayuda a garantizar que las distintas restricciones sobre los componentes y la topología (arquitectura) se cumplan (Grau, et al, 2002: 5). Sin embargo, dado que muchos ADLs han sido construidos para propósitos específicos, que no han adquirido madurez y aceptación suficiente y que el nivel de manejo de detalles es siempre de alto nivel, también se ha considerado el UML dentro de la comparación. Criterios de Comparación Estos son los criterios que se han utilizado para comparar los ADLs y el UML, para establecer sus fortalezas y debilidades. Soporte de herramientas Qué herramientas hay asociadas al ADL que faciliten su uso, que tan fáciles de aprender y usar son, cómo funcionan, sobre que se instalan, son libres, están bien documentadas, son livianas? Simplicidad Qué tan simple es este ADL, es complejo de llenar? Cómo se equilibran la formalidad requerida con la simplicidad y el esfuerzo de especificación? Completitud Este ADL es capaz de describir todo lo que queremos saber? Cumple con la capacidad de especificar los componentes estándar de una arquitectura? Con qué nivel de detalle se puede describir un componente individual? Genericidad El ADL se puede usar para describir cualquier sistema o tiene un dominio de aplicación determinado? Madurez Qué tan nuevo, aceptado y usado es el ADL? Cuántos años han pasado desde que se publicó por primera vez, y por última vez? Cuál es el número de publicaciones fácilmente disponibles y visibles para este ADL? Existe una comunidad en torno a este ADL? Disponibilidad Es un ADL abierto, libre y bien documentado? Formalidad Qué tan formal es el lenguaje (uso de modelos matemáticos, lógica de predicados, etc.)? ADLs en General Pese a sus diferencias, todos los ADLS estudiados en (Graham, et al., 2000: 49-50) comparten la misma ontología:

14 Componentes: representan los elementos computacionales primarios y los almacenes de datos de un sistema. Ejemplos: clientes, servidores, filtros, objetos, bases de datos. En la mayoría de ADLs, los componentes tienen múltiples interfaces que definen el punto de interacción entre un componente y su entorno. Conectores: representan interacciones entre componentes. Ejemplos: tubos, llamadas a procedimientos, broadcast, aunque también pueden ser interacciones más complejas, como protocolos o enlaces entre una base de datos y una aplicación. Sistemas: representan configuraciones de componentes y conectores. Una propiedad clave en los ADLs modernos es que la topología tenga una representación independiente de los componentes y conectores que componen el sistema. Propiedades: representan información semántica de un sistema y sus componentes más allá de su estructura. Aunque distintos ADLs permiten distintas propiedades, casi todos proveen una manera de definir propiedades no funcionales. Restricciones: representan hechos de un diseño arquitectónico que deben permanecer verdaderos en el tiempo. Ejemplos: valores permitidos, topología, vocabulario de diseño. Estilos: representan familias de sistemas relacionados. Típicamente, un estilo arquitectónico define un vocabulario de tipos de elementos de diseño y reglas para su composición. Aplicabilidad (Medvidovic & Taylor, 2000: 78): ADL ACME AESOP RAPIDE Enfoque Intercambio Especificación de Modelado y simulación arquitectónico, arquitecturas en estilos del comportamiento predominantemente a específicos dinámico descrito por una nivel estructural arquitectura Soporte para modelar componentes (Medvidovic & Taylor, 2000: 81): Características Interfaces Tipos Semántica Restricciones Evolución Propiedades nofuncionales Componentes ADL ACME AESOP RAPIDE Componente: Independiente implementación Componente: Independiente implementación Interfaz: independiente implementación de de de Puertos Puertos de entrada y salida constituye ntes (provides, requires, action y service) Sistema extensible de tipos; parametrización con plantillas Sistema extensible de tipos Sistema extensible de tipos; contiene un sublengua je de tipos No soportada; puede usar de otros ADLs Lenguajes específicos para estilos con semánticas específicas Conjuntos parcialmente ordenados de eventos (posets) Solo mediante interfaces Mediante interfaces semántica; invariantes estilos y de Mediante interfaces y semántica; restricciones algebraicas de estados Subtipado estructural con extends Subtipado para preservar comportamiento Por herencia Permite cualquier atributo en la lista de propiedades, pero no opera sobre ellos Permite asociación de texto arbitrario a los componentes ningunas Soporte para modelar conectores (Medvidovic & Taylor, 2000: 83): Características Interfaces Tipos Semántica Restricciones Evolución Propiedades nofuncionales Componentes ADL ACME Conector; explícito Roles Sistema extensible de tipos basado en protocolos AESOP Conector; explícito Roles Sistema extensible de tipos basado en No soporta Vía interfaces o estructural para instancias Se puede Mediante especificar la interfaces y semántica semántica; con Wright invariantes de Subtipado estructural con extends Subtipado para preservar comporta- Permite cualquier atributo en la lista de propiedades, pero no opera sobre ellos Permite asociación de texto arbitrario a los componentes

15 protocolos (otro ADL) estilos miento RAPIDE Conexión; en línea ninguna ningunos posets ningunas ninguna ningunas Soporte de herramientas (Medvidovic & Taylor, 2000: 90): Especificació Vistas Análisis Refinamiento Generación de Componentes n activa múltiples código Dinamismo ADL ACME ninguna Vistas en Parser ninguno ninguna ninguno términos de construcciones de alto nivel AESOP Editor Textuales y Parser; ninguno Genera código en Ninguno orientado a la gráficas; vistas compilador C para el estilo de sintaxis para específicas específico para tubos y filtros componentes para estilos; estilos; revisión iconos distintos de tipos; revisión para de ciclos; revisión componentes y de conflictos por conectores recursos RAPIDE ninguna Textual y Parser; Compilador Genera Soporte en gráfico; compilador; para simulación tiempo de animación de filtrado de sublenguaje ejecutable en el compilación y de simulaciones eventos; revisión ejecutable sublenguaje de ejecución de restricciones simulación de Rapide ACME Descripción general: Acme es un ADL genérico que sirve como representación común de arquitecturas de software y permite la integración de herramientas de análisis de arquitecturas desarrolladas de manera independiente. (Graham, et al., 2000) Acme permite la anotación de propiedades de una arquitectura, cada una con un nombre, tipo y valor. (Graham, et al., 2000: 55-56) Un tipo especial de propiedades son las restricciones de diseño que determinan la forma en que el diseño de una arquitectura puede evolucionar, mediante lógica de predicados (por ejemplo connected(client, server) puede ser un predicado falso o verdadero). (Graham, et al., 2000: 57-58) Los estilos permiten la definición de un vocabulario de diseño específico para un dominio o para una aplicación, junto con sus restricciones de uso. Los estilos se definen fundamentalmente con tipos: tipos de propiedad, tipos de estructura y estilos. (Graham, et al., 2000: 59-60) Acme ha tenido varios casos de estudio exitosos; ha servido de base para la creación de herramientas de análisis y diseño; ha servido de base para la integración de herramientas existentes; y ha sido punto de partida para la creación de ADLs específicos a un dominio. (Graham, et al., 2000: 63-64). Soporte de Herramientas: El modelado de arquitecturas de software es crucial para el desarrollo de software de alta calidad. El soporte de herramientas es necesario para esta actividad, de tal manera que los modelos puedan ser desarrollados, vistos, analizados y refinados en implementaciones. Este soporte debe darse de manera flexible y extensible para que pueda ser integrado a los procesos y estilos arquitectónicos de una compañía. AcmeStudio es un ambiente de desarrollo de arquitecturas independiente del dominio que puede ser fácilmente especializado a diferentes dominios. (Schmerl & Garlan, 2004); AcmeStudio está implementado como plugin al IDE de Eclipse de IBM que soporta el ADL Acme. (Schmerl & Garlan, 2004) Un aspecto clave de AcmeStudio es su habilidad de crear estilos rápida y fácilmente. (Schmerl & Garlan, 2004) En un caso de estudio un modelo arquitectónico fue desarrollado tanto en UML como en Acme. Al ser revisado por pares, el modelo de UML presentó 38 defectos. El de Acme fue revisado automáticamente por AcmeStudio que encontró 11 defectos, 6 de los cuales no fueron identificados por la revisión por pares del modelo UML. Además de haber encontrado defectos nuevos, el esfuerzo de la detección automática es significativamente inferior que el de la revisión por pares (de documentos de diseño con UML). (Roshandel, et al., 2004) Simplicidad: Es completo y bien definido con terminología clara. AcmeStudio facilita mucho su utilización, aportando un ambiente gráfico para Eclipse.

16 Completitud: Acme provee un lenguaje semánticamente extensible y un conjunto de herramientas para análisis e integración; además soporta la definición de estructura, propiedades, restricciones y estilos. (Graham, et al., 2000: 52) Los elementos de una descripción Acme son (Graham, et al., 2000: 53): Genericidad: Lo más cerca que la comunidad investigativa ha llegado al consenso respecto de ADLs ha sido la aceptación de ACME como un lenguaje de intercambio arquitectónico. Sin embargo, ACME representa el mínimo común denominador de los ADLs existentes, en lugar de ser una definición de lo que es un ADL. (Medvidovic & Taylor, 2000: 72-73) Madurez: Empezó en 1995, lo que lo hace maduro. Lo que no es claro es qué tanto se usa o qué tanto le siguen trabajando a través del ABLE group de CMU. Disponibilidad: Hay suficiente documentación y página web. Hay documentación y herramientas disponibles libremente en Internet. Formalidad: Ha sido desarrollado a partir de una comprensión de varios ADLs, lo cual lo hace más formal y mejor definido que otros. Sin embargo, esa misma genericidad lo puede hacer menos formal. AESOP Descripción general: Aesop es un sistema para desarrollar ambientes de desarrollo arquitectónico específicos a un estilo. Cada uno de estos ambientes ofrece íconos con los elementos de diseño; revisión de restricciones topológicas; especificaciones semánticas opcionales; una interfaz para analizar las descripciones arquitectónicas; y múltiples visualizaciones para cada estilo. (Garlan, et al., 1994: 177) Soporte de Herramientas: El énfasis de Aesop está precisamente en ofrecer ambientes de diseño para analizar arquitecturas. Simplicidad: Requiere esfuerzo adicional para ser usado como ADL, ya que está orientado a usarse como base para desarrollar herramientas orientadas a estilos arquitectónicos. Completitud: Parece completo en cuanto a sus componentes y definición de estilos arquitectónicos. Genericidad: El énfasis de Aesop está en representaciones arquitectónicas basadas en una ontología genérica de siete entidades: componentes, conectores, configuraciones, puertos, roles, representaciones y bindings. (Garlan, et al., 1994: 180) Además, enfatiza el uso de estilos genéricos para analizar arquitecturas. Madurez: Fue desarrollado hace al menos diez años y fue ampliamente usado, ya no es soportado por el ABLE group. Disponibilidad: Aunque hay material y herramientas libremente disponibles, ya no es soportado. Es obsoleto. Formalidad: Al ser un ambiente para generar herramientas, no es muy formal, pues requiere de una especificación más concreta.

17 RAPIDE Descripción general: RAPIDE-1.0 es un lenguaje computacional para definir y ejecutar modelos de sistemas de arquitecturas. El resultado de ejecutar un modelo RAPIDE es un conjunto de eventos que ocurrieron durante la ejecución junto con sus relaciones causales y temporales. (Luckham, 1996) RAPIDE-1.0 está estructurado como un conjunto de lenguajes que consisten en tipos, patrones, arquitectura, restricciones y lenguaje ejecutable. Este conjunto de lenguajes es denominado RAPIDE language famework. (Luckham, 1996) µrapide está diseñado para soportar la especificación, análisis y verificación de arquitecturas de sistemas basadas en componentes de procesamiento de eventos. (Vestal, 1993) La semántica de µrapide puede ser descrita con conjuntos parcialmente ordenados de eventos (posets). (Vestal, 1993) El comportamiento de los componentes puede ser especificado usando máquinas de estado finitas no-deterministas. (Vestal, 1993) Las interfaces de componentes definen tipos de componentes y pueden ser declaradas estática o dinámicamente. (Vestal, 1993) Los requerimientos de un ADL según los creadores de Rapide: abstracción de componentes, abstracción de comunicación, integridad de comunicación, habilidad para modelar arquitecturas dinámicas, composición jerárquica y habilidad para relacionar comportamientos entre arquitecturas. (Medvidovic & Taylor, 2000: 72) Soporte de Herramientas: El toolkit de Rapide contiene: RapArch para modelado gráfico, Rapide Compiler para crear arquitecturas ejecutables, POV para trazar eventos; Raptor para animar las ejecuciones y varias herramientas de análisis desarrolladas independientemente. Simplicidad: Es simple, pero no tiene herramientas actualizadas e integradas a ambientes modernos. Completitud: Está orientado a eventos, aunque ofrece los elementos básicos de un ADL. Genericidad: Su orientación está en la ejecución de modelos para verificar consistencia, orientada a eventos y cronología entre ellos. Madurez: Fue desarrollado hace unos diez años, pero ya no parece ser soportado. Disponibilidad: Hay documentación y herramientas disponibles libremente, pero obsoletas. Formalidad: Es bastante formal para permitir la ejecución de modelos. ADML Descripción general: El Architecture Description Markup Language (ADML) es un lenguaje de representación de arquitecturas basado en XML, basado en el trabajo de ACME. Como estándar, ADML hace que sea posible el intercambio de modelos ADML, con las ventajas que ofrece estar construido sobre un estándar abierto y popular como XML.(Spencer, 2000) Soporte de herramientas: ADML Versión 1 ha sido probado con el parser JavaSoft ProjectX. Además es compatible con las herramientas que se ofrecen para XML. Y es soportado por Acme Studio (ABLE, 2003) Simplicidad: De acuerdo a lo encontrado la definición basada en DTD s hace que sea de fácil uso, aunque implica que debemos aprender Acme y aprender el uso de las herramientas asociadas para poder incluir en ellas el DTD de ADML. Completitud: ADML añade a ACME una representación estandarizada; la habilidad de definir enlaces a objetos fuera de la arquitectura y conexión con repositorios comerciales. Genericidad: Igual que Acme. Madurez: Es de notar que parece que ADML 1 no fue de entera aceptación en el mercado y tal vez por eso se vea un abandono de las paginas web que lo soportan además de links rotos a proyectos que lo implementaron. Disponibilidad: DTD disponible para libre uso, documentación del DTD relativamente completa, pocos ejemplos.

18 Formalidad: Basado en definiciones de propiedades y tipos XML XAcme Descripción general: xarch es un esquema de XML que define como representar instancias de arquitecturas en XML. xarch define un espacio de nombres llamado archinstances que permite definir una instancia de una arquitectura de software usando: componentes, conectores, interfaces, enlaces, subarquitecturas y grupos. (xarch, 2005) Una de las motivaciones para el desarrollo de xarch fue que fuera extensible para que ADLs particulares pudieran codificarse con extensiones de xarch. La extensión xacme de xarch provee las facilidades necesarias para codificar arquitecturas Acme. (xacme, 2001) Soporte de herramientas: El soporte para xacme ha sido añadido a la versión 1.6 de AcmeStudio (ABLE, 2003). Simplicidad: Las cinco extensiones Acme que se han hecho a xarch para obtener xacme son (Schmerl, 2001): propiedades: añade propiedades (nombre, valor y tipo) a instancias xarch propiedades Acme: corresponde a valores y tipos de propiedades de Acme. familias: añade soporte a tipos de componentes, conectores, interfaces y propiedades. restricciones: añade soporte a restricciones restricciones Acme: extiende las restricciones para soportar restricciones de Acme. Completitud: Incluye todas las características proveídas por Acme 3.0 (Schmerl, 2001) Genericidad: La extensibilidad de xarch consiste en el uso del concepto de herencia para proveer XML schema adicionales. Madurez: xacme es la evolución natural de Acme, hacia el uso de XML schema en lugar de las plantillas DTD. Disponibilidad: Los esquemas XML están disponibles en: (xacme, 2001) Formalidad: XML, no formalismo matemático. XADML 2.0 Descripción general: Los ADLs tradicionales típicamente soportan un pequeño número de elementos de modelado, pero adaptan otros pobremente. XML provee una plataforma ideal para desarrollar un lenguaje de modelado extensible para arquitecturas. XADL 2.0 es un ADL basado en XML que soporte el modelado en tiempo de diseño y en tiempo de ejecución, la gestión de configuración de una arquitectura y la instanciación de sistemas basados en modelos. Adicionalmente, xadl provee un conjunto de herramientas para crear, manipular y compartir documentos de xadl 2.0. (Dashofy, et al., 2001) Soporte de herramientas: xadl 2.0 está soportado por herramientas que proveen la infraestructura necesaria para almacenar, manipular y compartir especificaciones hechas en xadl 2.0. Este conjunto de herramientas oculta a los usuarios de las peculiaridades del XML y de la estructura interna de los documentos xadl 2.0. (xadl, 2003) Además se cuenta con: xarch/xadl 2.0 Data Binding Library Librerías de Java para crear y manipular documentos de xarch y xadl 2.0. Visio para C2 y xadl (Ren, 2004) Simplicidad: xadl 2.0 es altamente extensible, ya que hereda la extensibilidad de XML. Ya que es definido como una serioe de extensiones a xarch, sus características no deseadas o no usadas pueden ser dejadas por fuera de una descripción arquitectónica hecha con xadl 2.0. No obstante, no es preciso conocer a fondo los mecanismos de extensión de xadl, a menos que se quiera extender con esquemas propios. (Dashofy, et al., 2001) Completitud: Representa conceptos muy similares a los expresados por Acme.

19 Genericidad: Comparte la misma característica de genericidad heredada de xarch, puede agregar nuevos esquemas. Hace una separación clara entre prescripción arquitectural (la plantilla en tiempo de diseño usada para crear instancias de la misma) y la descripción arquitectural (que describe el estado del sistema en tiempo real) (Dashofy, et al., 2001). Madurez: Utilizado y referenciado por (AFRL, 2005) Disponibilidad: La documentación es incompleta y su última actualización es de enero (xadl, 2003) XML Schema de libre uso. Formalidad: XML, no lógica formal. UML Descripción general: UML (ya sea en su forma normal o con extensiones) como lenguaje para documentar arquitecturas de software ha sido desilusionante, ya que no tiene una forma natural de representar niveles (capas), conectores (en su sentido arquitectónico) o componentes (que en UML 1.4 eran más un concepto de implementación que de arquitectura). (Ivers, et al., 2004: 2) Las desventajas de usar UML 1.4 (Ivers, et al., 2004: 9): UML 1.4 no tiene un concepto de primera clase (sin extensiones) para representar conectores. El concepto de interfaz no permite la representación de múltiples puntos de interacción en tiempo de ejecución. La descomposición jerárquica es difícil: no hay manera de proveer un modelo más detallado de un componente individual. No hay un constructor específico para representar estilos arquitectónicos. Las modificaciones y características nuevas en UML 2.0, combinadas con aquellas heredadas de otras versiones de UML, proveen un vocabulario rico para documentar arquitecturas de software y ayudar a solucionar los problemas de las versiones anteriores. (Ivers, et al., 2004: 19) Al comparar UML 2.0 con sus predecesores, podemos ver que la situación ha mejorado considerablemente. Varios de los problemas asociados a la documentación de componentes y conectores en UML 1.4 han sido solucionados y las opciones para solucionar otros problemas se han reducido. (Ivers, et al., 2004: 37) Sin embargo, algunos problemas persisten en UML 2.0: los conectores todavía no son elementos de primera clase y es difícil asociarles descripciones; por otro lado, sigue sin haber una forma natural para representar componentes. (Ivers, et al., 2004: 37) Soporte de Herramientas: UML tiene muchas herramientas diversas con distintos alcances, costos y posibilidades. Su popularidad hace de existan herramientas de modelado, análisis, generación de código, intercambio de todos los tamaños para UML. Sobra aclarar este punto. Simplicidad: El UML es bastante simple, pero a medida que surgen exigencias de arquitectura, hay que empezar a usar construcciones más complejas. Completitud: Es bastante completo, pero no es muy detallado a la hora de modelar componentes en su sentido genérico de diseño. Genericidad: Pese a ser UML un lenguaje genérico para modelar sistemas (especialmente de software), lo que se llama componentes en UML no es un concepto tan abstracto como lo es en términos de arquitectura de software. Es genérico en cuanto a dominio de aplicación, pero no suficientemente genérico en términos de arquitectura y sus componentes deseables. Madurez: Su versión 2.0 ya es bastante madura y ofrece soluciones a problemas presentados en versiones anteriores. Disponibilidad: Toda la documentación está disponible libremente. propietarias. Hay herramientas libres y otras Formalidad: Aunque el UML se ha hecho popular para especificar sistemas conviene aclarar que este es un lenguaje semiformal y que algunos consideran que carece de una formalidad desagradable pero necesaria para

20 el análisis automático de los modelos. (Roshandel, et al., 2004) Lo que se gana en simplicidad y claridad para compartir los modelos, aumentando su comprensibilidad, se pierde con la presencia de ambigüedades o anotaciones que no pueden ser procesadas por una herramienta. Tabla comparativa ADL Criterio Soporte de herramientas Simplicidad Completitud Genericidad ACME AESOP RAPIDE ADML xacme xadml AcmeStudio, plug-in de ECLIPSE Completo, bien documentado y fácil de usar con AcmeStudio. Completo, aunque genérico; pero extensible. Mucho, es un esfuerzo de integración de ADLs. Ofrece creación de ambientes de análisis de arquitecturas. Es base para desarrollar herramientas, no para usar puro. Completo en elementos y estilos soportados. Enfatiza el uso de estilos genéricos. Madurez Desde Desde 1995 o antes. Disponibilidad Suficiente. Documentación obsoleta. Formalidad Es formal, pero de propósito múltiple. Muy formal. Un toolkit completo para diseño, modelado, simulación... Simple, pero no fácil de usar con herramientas modernas. Ofrece los elementos básicos. Poca; orientado a eventos o antes. Obsoleto? Documentación disponible, pero obsoleta. Bastante formal. Compatible con herramientas XML y Acme Studio. El uso de DTDs facilita su apropiación, aunque requiere de aprendizaje de ACME antes. Igual que ACME. Igual que ACME. Parece que no es muy popular. DTD libre y documentación completa, aunque con pocos ejemplos. Entre ACME y XML. Soportado por última versión de Acme Studio. Extensión de xarch. Igual que ACME. Extensión de xarch y ACME. - - Esquemas XML disponibles. XML. Librerías de Java, Visio y herramientas para XML. Extensible, pero no fácilmente. Separa El diseño del sistema en tiempo real del diseño en tiempo de ejecución Igual que xarch ero extensible. Documentación incompleta y un poco obsoleta. Esquema XML libre. XML 4. Descripción del lenguaje elegido De la anterior comparación se obtuvo que, dentro de los ADLs, la mejor opción para explorar la descripción de componentes es ACME. Quizá su mayor ventaja en el contexto de este proyecto, es que haya sido establecido como lenguaje común de ADLs, lo que evita caer en la dificultad que tienen los otros de haber sido diseñados para un propósito muy específico. Por otra parte, su aceptación, documentación y herramientas disponibles lo hacen también atractivo para continuar trabajando con él, dentro del programa de investigación de PICS. Por otra parte, como ya ha quedado aclarado, nos parece casi inevitable considerar el UML (en particular la versión 2.0) como la otra alternativa de lenguaje para explorar su potencial. Las ventajas de UML son bien conocidas, por ello no ahondaremos más en este momento. En esta sección, pues, haremos un breve recuento de estos lenguajes que complemente el que ya se hizo en la comparación anterior, haciendo énfasis en el potencial y posibilidades que tienen para describir componentes de software.

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

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

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

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

Más detalles

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

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

Más detalles

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

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

Más detalles

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

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

Más detalles

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

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

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

Tecnologías de componentes y proceso de diseño de aplicaciones basado en componentes

Tecnologías de componentes y proceso de diseño de aplicaciones basado en componentes Tecnologías de y proceso de diseño de aplicaciones basado en Programación orientada a objetos : Lenguajes, Tecnologías y Herramientas Master de Computación Santander, 2009 Patricia López Grupo de Computadores

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

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

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

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

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

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

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

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

Más detalles

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

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

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

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos

Boletín de Asesoría Gerencial SOA: enfoque técnico orientado a procesos Espiñeira, Sheldon y Asociados No. 4-2010 Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección 4 Introducción 4 Qué

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

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

UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS

UNIVERSIDAD CENTROCCIDENTAL LISANDRO ALVARADO DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS UNIVERSIDAD CENTROCCIDENTAL "LISANDRO ALVARADO" DECANATO DE CIENCIAS Y TECNOLOGIA MAESTRIA EN CIENCIAS DE LA COMPUTACION MENCION REDES DE COMPUTADORAS MODELO DE GESTION WBEM PARA ADMINISTRACION DE REDES

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

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V

Tecnología de objetos distribuidos y arquitectura de componentes. Índice. Bibliografía. Introducción. Tema V Bibliografía Tema V Tecnología de objetos distribuidos y arquitectura de componentes. Szyperski, C. 1998. Component Software. Addison-Wesley. Ruiz Cortés, 1998. A. CORBA: Una visión general. http://www.lsi.us.es/~aruiz

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

Ingeniería de Software

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

Más detalles

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

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

Más detalles

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

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

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

Estilos y Patrones Arquitectónicos

Estilos y Patrones Arquitectónicos Lic. Ariel Trellini Estilos y Patrones Arquitectónicos Llamando a las cosas por su nombre Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Arquitectura y Diseño de Sistemas

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

2.1 Ingeniería de Software

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

Más detalles

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

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

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Rational Unified Process (RUP)

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

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

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

Más detalles

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

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

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

Más detalles

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes.

Especificación de la secuencia de mensajes que se han de intercambiar. Especificación del formato de los datos en los mensajes. SISTEMAS DISTRIBUIDOS DE REDES 2.- MODELOS ORIENTADOS A OBJETOS DISTRIBUIDOS 2.1. Tecnologías de sistemas distribuidos Para la implementación de sistemas distribuidos se requiere de tener bien identificados

Más detalles

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

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

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN El desarrollo de software basado en componentes permite reutilizar piezas de código pre-elaborado que permiten realizar diversas tareas, conllevando

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

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

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA)

MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) MIGRACIÓN DE UNA ARQUITECTURA TRADICIONAL A UNA ARQUITECTURA ORIENTADA A SERVICIOS (SOA) Nelson Beltran Galvis Grupo de Investigación de Ingeniería de Software, Universidad Francisco de Paula Santander.

Más detalles

ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA:

ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA: UNIDAD 04: PATRONES DE DISEÑO WEB. ASIGNATURA: Ingeniería de software II DOCENTE: Licda.Carla Milagro López Vásquez RESPONSABLE: Rodolfo Alberto Palma Ramos CARRERA: Técnico en Ingeniería en Sistemas y

Más detalles

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx

MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx MIDDLEWARE: Arquitectura para Aplicaciones Distribuidas Dr. Víctor J. Sosa Sosa vjsosa@tamps.cinvestav.mx Contenido Middleware: Introducción Definición Genealogía Aplicaciones actuales: Servicios Web Computación

Más detalles

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad.

Brindar al alumno un marco teórico y práctico para el desarrollo de software bajo estándares de calidad. Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS290T. Ingeniería de Software I (Obligatorio) 2012-2 1. DATOS GENERALES 1.1

Más detalles

El Framework de desarrollo del Consejo

El Framework de desarrollo del Consejo El Framework de desarrollo del Consejo Superior de Investigaciones Científicas Director de la OPCSIC Centro Técnico de Informática (CSIC) Directora Centro Técnico de Informática (CSIC) Palabras clave Framework,

Más detalles

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com

Modelos de los sistemas distribuidos. Jorge Iván Meza Martínez jimezam@gmail.com Modelos de los sistemas distribuidos Jorge Iván Meza Martínez jimezam@gmail.com Especialización en Gestión de Redes de Datos Universidad Nacional de Colombia Sede Manizales 1/36 Contenidos Modelo arquitectónico

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

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

Más detalles

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

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

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

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

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

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la

La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la Servicios web Introducción Un servicio web es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Programación generativa

Programación generativa ujuarez@itorizaba.edu.mx Instituto Tecnológico de Orizaba 15 de octubre de 2010 Agenda 1 Introducción Panorama general Problemática 2 Implementación generativa Bibliotecas activas Bibliotecas activas:

Más detalles

MODELADO DE OBJETOS DE DATOS

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

Más detalles

Capítulo II. Arquitectura del Software

Capítulo II. Arquitectura del Software Capítulo II. Arquitectura del Software Después de un cuidadoso análisis de los objetivos del proyecto, se determinó que la mejor manera de estructurar el sistema era haciendo uso del muy famoso patrón

Más detalles

Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica

Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica C1. Capacidad para la resolución de los problemas matemáticos que puedan plantearse en la ingeniería. Aptitud para aplicar

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

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

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

Más detalles

Arquitectura cliente/servidor

Arquitectura cliente/servidor Departamento de Lenguajes y Sistemas Informáticos Arquitectura cliente/servidor Programación en Internet Curso 2007-2008 Índice Introducción Tipos de servidores Ventajas Desventajas Arquitectura de una

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

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

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

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

Enterprise Analyst: Taller de Bautizo

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

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: DOCUMENTO DE VISIÓN SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA

SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: DOCUMENTO DE VISIÓN SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA SISTEMATIZACIÓN DE LA GENERACIÓN DE PRESUPUESTOS PARA PROYECTOS DE OBRA: SISTEMA DE ADMINISTRACIÓN DE MATERIALES DE TUBERÍA PARA INARGOS LTDA. DOCUMENTO DE VISIÓN VERSIÓN 1.3 BOGOTÁ, COLOMBIA, ENERO 2012

Más detalles

La Arquitectura de las Máquinas Virtuales.

La Arquitectura de las Máquinas Virtuales. La Arquitectura de las Máquinas Virtuales. La virtualización se ha convertido en una importante herramienta en el diseño de sistemas de computación, las máquinas virtuales (VMs) son usadas en varias subdiciplinas,

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

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

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

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

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

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

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

Desarrollo de Software Basado en Líneas de Productos de Software

Desarrollo de Software Basado en Líneas de Productos de Software IEEE Computer Society Región n 9 Capítulo Argentina Programa DVP Desarrollo de Software Basado en Líneas de Productos de Software Jonás A. Montilva C., Ph.D. IEEE Member Universidad de Los Andes Facultad

Más detalles

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

CARRERA TITULO DEL TRABAJO CURSO

CARRERA TITULO DEL TRABAJO CURSO CARRERA Ingeniería Informática TITULO DEL TRABAJO TOGAF CURSO Tópicos de Ingeniería del Software CÉSAR ESTRADA CONDORI MAYRA GOMEZ QUEVEDO LUIS MUǸOS ESCAPA ALAN A. ROJAS MARROQUIN SEMESTRE IX 2010 Los

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

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

Más detalles

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do.

Gobernabilidad de TI. Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. 2do. Gobernabilidad de TI COBIT Elsa Estevez Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur 2do. Cuatrimestre 2010 T. 2 Contenido Introducción a la Gobernabilidad de TI

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

PROGRAMACIÓN DE SISTEMAS INFORMÁTI- COS

PROGRAMACIÓN DE SISTEMAS INFORMÁTI- COS IFCT0609: PROGRAMACIÓN DE SISTEMAS INFORMÁTI- COS CÓDIGO ESPECIALIDAD C.P. PRESEN- CIALES TELEFORMA- CIÓN TOTALES TIPO DE FORMACIÓN IFCT0609 PROGRAMACIÓN DE SISTE- MAS INFORMÁTICOS SI 210 210 420 SEMIPRESENCIAL

Más detalles

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

Más detalles

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

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

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

Capítulo 1. Componentes de CORBA.

Capítulo 1. Componentes de CORBA. Capítulo 1. Componentes de CORBA. La OMA (Object Management Architecture) define en alto nivel de abstracción las reglas necesarias para la distribución de la computación orientada a objetos (OO) en entornos

Más detalles

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables.

Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Modelado de tácticas de atributos de calidad para la generación de arquitecturas ejecutables. Para obtener el grado de Maestro en Ciencias (Ciencias y Tecnologías de la Información) P R E S E N T A Lic.

Más detalles

Service Oriented Architecture

Service Oriented Architecture Programación Concurrente y Distribuida Ingeniería en Informática Service Oriented Architecture José Carlos Cortizo Pérez josecarlos.cortizo@uem.es http://www.esp.uem.es/jccortizo D. Sistemas Informáticos

Más detalles