Hacia una mejor experiencia de debugging en desarrollos AOP

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

Download "Hacia una mejor experiencia de debugging en desarrollos AOP"

Transcripción

1 TESIS DE GRADO EN INGENIERÍA INFORMÁTICA Hacia una mejor experiencia de debugging en desarrollos AOP FACULTAD DE INGENIERÍA UNIVERSIDAD DE BUENOS AIRES TESISTA: Adrián EIDELMAN DIRECTORA: Lic. Rosa WACHENCHAUZER CO-DIRECTOR: Lic. Alan CYMENT NOVIEMBRE 2006

2 Resumen Las limitaciones que presenta la Programación Orientada a Objetos para encapsular las incumbencias transversales en un desarrollo de software han dado origen a nuevas técnicas de programación, entre las cuales se ha destacado en los últimos años la Programación Orientada a Aspectos (AOP). AOP introduce una nueva unidad de modularización denominada aspecto, que tiene el fin de encapsular estas funcionalidades transversales y mejorar así la comprensión y mantenibilidad de las aplicaciones. A partir de la introducción del aspecto como unidad de modularización, AOP a su vez incorpora nuevas fuentes de fallas y por lo tanto nuevos desafíos en lo que respecta al testing en desarrollos de este tipo. A pesar de esto, el aseguramiento de la calidad no ha sido objeto de atención dentro de la comunidad AOP y el escaso desarrollo de esta disciplina se manifiesta particularmente en una actividad: el debugging de aplicaciones. El objetivo de la presente tesis es exponer las fallas características que pueden presentarse en desarrollos AOP y las limitaciones en cuanto al soporte a las tareas de debugging que presentan en general las herramientas para desarrollos orientados a aspectos, para luego presentar una propuesta de solución y plasmar la misma dentro del framework conocido como SetPoint. Adrián Eidelman 2/148

3 Agradecimientos A Rosita y a Alan, directora y co-director de esta tesis, por su confianza y ayuda incondicional desde el primero hasta el último día de trabajo. A Rubén, por sus aportes, comentarios y sugerencias desde el viejo continente. A Silvina por su apoyo y compañía constantes durante todos estos años de carrera. A mis padres, Alicia y Mario, y mis hermanos Gabriel y Nadia. A todos aquellos que ayudaron desinteresadamente desde algún lugar del cyberespacio. A profesores, compañeros, amigos y todos los que me permitieron llegar a este momento. Adrián Eidelman 3/148

4 Tabla de Contenidos RESUMEN...2 AGRADECIMIENTOS...3 TABLA DE CONTENIDOS INTRODUCCIÓN...7 ORGANIZACIÓN DE LA TESIS LA PROGRAMACIÓN ORIENTADA A ASPECTOS...12 EL PROBLEMA DE LAS INCUMBENCIAS TRANSVERSALES...12 Ejemplificando el problema...13 UNA PROPUESTA DE SOLUCIÓN: AOP...15 Elementos distintivos del paradigma AOP...16 Otras ventajas que ofrece AOP...20 AOP vs. POO...20 RESUMEN EL PROYECTO SETPOINT...22 SETPOINT, LECTOR LECTOR, SETPOINT...22 UNA MOTIVACIÓN PARA SETPOINT: LA PARADOJA DE LA PROGRAMACIÓN AOP...23 SEMANTIC POINTCUTS Y CONCEPTOS DE LA WEB SEMÁNTICA...25 Conceptos de la Web semántica...26 Armando el rompecabezas hacia la implementación de setpoints...30 MODELO DE JOINPOINTS Y WEAVING...32 Completando el universo semántico de la aplicación...33 DECLARACIÓN DE ASPECTOS, ADVICES Y POINTCUTS...34 Pointcuts...35 Aspectos...36 Advices...37 ARQUITECTURA SETPOINT...38 RESUMEN ANTES DE CONTINUAR... QUÉ ENTENDEMOS EXACTAMENTE POR DEBUGGING?...40 BUGS, DEFECTOS Y FALLOS...40 DEBUGGING...41 DEBUGGERS...42 Estado del arte...43 ALGUNAS ACLARACIONES RELACIONADAS CON EL DEBUGGING...44 RESUMEN ESTADO DEL ARTE: INVESTIGACIONES SOBRE EL TEMA...46 TRABAJOS RELACIONADOS...46 TEMAS PENDIENTES DE INVESTIGACIÓN...48 RESUMEN DEFINICIÓN DEL PROBLEMA Y OBJETIVOS...51 POR QUÉ TESTEAR DESARROLLOS AOP ES DIFERENTE?...51 UN MODELO DE FALLAS PARA AOP...52 La naturaleza de las fallas en desarrollos AOP...53 Modelo de fallas candidato...54 DEBUGGEANDO APLICACIONES EN SETPOINT...56 Modelos de weaving...56 Información de debugging...59 Adrián Eidelman 4/148

5 Desentendimiento de las actividades propias de AOP...61 OBJETIVOS DE LA TESIS...64 RESUMEN MEJORANDO LA EXPERIENCIA DE DEBUGGING EN DESARROLLOS AOP...66 PROPIEDADES DE UNA SOLUCIÓN IDEAL DE DEBUGGING...67 Idempotencia...67 Desentendimiento...69 Intimidad...72 Dinamismo...73 Introducción de aspectos...74 Modificaciones en tiempo de ejecución...75 Aislamiento de fallas...76 Conocimiento del flujo de ejecución...77 Inmediatez...77 LA SITUACIÓN DE SETPOINT Y LAS RESTANTES PLATAFORMAS AOP...78 RESUMEN NUESTRO GRANO DE ARENA: DISEÑO E IMPLEMENTACIÓN DE LA SOLUCIÓN EN SETPOINT...82 DEFINIENDO EL ALCANCE DEL TRABAJO...82 Las propiedades a implementar...82 Debugger...83 SETPOINT V1.1: UN PRIMER ACERCAMIENTO...84 Idempotencia...85 Desentendimiento...88 Dinamismo...90 Conocimiento del flujo de ejecución...95 Síntesis de la primera experiencia...97 SETPOINT V2.0: PROPUESTA FINAL PARA ESTE TRABAJO...98 Idempotencia...98 Desentendimiento e Intimidad Conocimiento del flujo de ejecución Inmediatez Síntesis de la segunda experiencia RESUMEN UNIFICANDO CONCEPTOS: UN EJEMPLO DE APLICACIÓN DESCRIPCIÓN DE LA APLICACIÓN AOP Dimensión base y aspectos Implementación de los aspectos REALIZANDO EL DEBUGGING DE LA APLICACIÓN Debugging a nivel código fuente Controlando la dinámica de la aplicación Flujo de ejecución de aspectos Determinando el origen de la falla RESUMEN CONCLUSIONES ANEXO A EL FRAMEWORK PHOENIX VISIÓN GENERAL ARQUITECTURA DE PHOENIX MODO DUAL JERARQUÍA DE UNIDADES RESUMEN ANEXO B DIAGRAMAS DE SECUENCIA SETPOINT El algoritmo del weaver Obtención de matchpoint y política de weaving Adrián Eidelman 5/148

6 Ejecución de la RandomWeavingPolicy ANEXO C EJEMPLOS DE REPRESENTACIONES SEMÁNTICAS REPRESENTACIÓN SEMÁNTICA DE LA APLICACIÓN DOTSTACK REPRESENTACIÓN SEMÁNTICA DEL COMMON TYPE SYSTEM REFERENCIAS Adrián Eidelman 6/148

7 1. Introducción A partir de la mitad de la década de 1980 y hasta la actualidad, la POO o Programación Orientada a Objetos se ha constituido como uno de los paradigmas de programación más importantes. Las características de la POO han permitido modelar problemas complejos con gran facilidad, y hoy día el paradigma de objetos es probablemente el más utilizado a la hora de construir soluciones de software. Sin embargo, como todos los paradigmas de programación existentes, éste posee también sus puntos débiles. Este hecho ha dado lugar a la aparición de nuevas técnicas de programación, dentro de las cuales se destaca principalmente la Programación Orientada a Aspectos, también conocida como AOP por sus siglas en inglés (Aspect Oriented Programming). La Programación Orientada a Aspectos aparece como una propuesta para solucionar el problema de la separación de incumbencias transversales o crosscuting concerns, es decir, aquellas funcionalidades o cualidades del sistema que afectan a más de una clase u objeto [Kiczales et al., 1997]. Ejemplos típicos de crosscuting concerns son tracing, logging y seguridad, entre muchos otros. Generalmente, estos crosscuting concerns constituyen requerimientos no funcionales del sistema y se dispersan a lo largo de todo el código fuente 1. En la programación tradicional, ya sea mediante POO o programación procedural, la lógica principal de la aplicación se entremezcla con aspectos suplementarios o no funcionales, como los mencionados anteriormente. La propuesta de AOP se basa en permitir la modularización de estos aspectos, permitiendo a los desarrolladores construir la lógica del negocio de forma independiente a las restantes incumbencias, y luego poder relacionarlas con la ayuda automática de herramientas especialmente diseñadas para tal fin. En definitiva, lo que AOP ofrece desde la teoría- es una verdadera separación de incumbencias. Debido a la corta edad que registra la programación orientada a aspectos, y su inmadurez como técnica de desarrollo, ésta aún presenta varios desafíos que será necesario afrontar para pasar de ser una tecnología promisoria a una tecnología que se pueda utilizar en la práctica y de manera masiva a nivel industrial. Hoy 1 Algunos trabajos realizados denominan crosscuting concern a cualquier incumbencia transversal independientemente de su carácter funcional o no funcional. Consideramos que las ventajas de AOP se presentan principalmente al tomar como crosscuting concerns a los aspectos no funcionales de un sistema. Queda fuera del alcance de este trabajo entrar en una discusión sobre este tema. Adrián Eidelman 7/148

8 día, los mayores esfuerzos en investigación de este paradigma se centran en las disciplinas de análisis, diseño e implementación, y en ese sentido otras áreas de investigación han quedado relegadas. Quizás el ejemplo más concreto sea el testing. A pesar de la sabida importancia que tiene el testing en el desarrollo de soluciones informatizadas, esencial para asegurar la calidad del software, aún no se le ha prestado la atención debida en el mundo AOP y los trabajos relacionados con esta disciplina son realmente escasos. Ciertas características propias de la programación orientada a aspectos que serán abordadas a lo largo de este trabajo- hacen que las técnicas y herramientas de testing existentes en la actualidad no sean las más adecuadas para este tipo de soluciones. Encontrar técnicas y herramientas adecuadas para el desarrollo de aplicaciones AOP será sin dudas un paso fundamental e ineludible para poder construir exitosamente este tipo de soluciones. Teniendo en cuenta esta situación, con la esperanza de contribuir a la madurez de esta tecnología y conseguir herramientas prácticas que permitan desarrollar software de alta calidad, la presente tesis abordará el estudio de un tema específico dentro de la disciplina de testing: el debugging de aplicaciones. Es sabido que las herramientas modernas de debugging constituyen una parte fundamental en el desarrollo de software y seguramente son pocas las necesidades que puedan surgir al debuggear aplicaciones procedurales u orientadas a objetos y que estas herramientas no nos provean. No sucede lo mismo para AOP: las características particulares de la programación orientada a aspectos -relacionadas con la introducción del aspecto como una nueva entidad de programación, la relación e interacción entre los aspectos y los módulos tradicionales, entre otras cosas- dan lugar a nuevas fuentes de fallas en los programas, y por lo tanto resultarán en sistemas con nuevos desafíos de testing y diferentes necesidades de debugging. La gran mayoría de las herramientas AOP en la actualidad carecen de un adecuado soporte al debugging, dificultando así la tarea de diagnosticar fallas y comprender la estructura y flujo de ejecución de los programas. La posibilidad de debuggear aplicaciones AOP es crítica para la adopción de este paradigma. La intención de la presente tesis es presentar una propuesta de solución basada en propiedades de debugging que idealmente debería soportar una herramienta para desarrollos AOP, y realizar una experiencia práctica implementando aquellas Adrián Eidelman 8/148

9 funcionalidades que sean posibles de acuerdo a un análisis previo de factibilidad- dentro del framework de AOP SetPoint [Cyment & Altman, 2004] 2. Los pasos que se realizarán a lo largo del trabajo serán: 1. Se analizarán las fuentes de fallas que introduce la programación orientada a aspectos, particulares de este paradigma. 2. A partir del modelo de fallas planteado, y a los trabajos existentes sobre el tema, se presentarán las propiedades de debugging que debería brindar idealmente cualquier herramienta para desarrollos AOP. 3. En base a los dos puntos anteriores, se analizará qué facilidades de debugging ofrece hoy en día el framework para AOP SetPoint, y se establecerá una meta previo análisis de factibilidad- para mejorar la situación actual. 4. Se diseñaran y construirán las propiedades propuestas para el framework AOP SetPoint, describiendo de qué manera estas nuevas funcionalidades del framework facilitan la experiencia de debugging. 5. Finalmente, se expondrán las conclusiones del trabajo, intentando sentar las bases para nuevas técnicas de debugging para herramientas AOP. Organización de la tesis El trabajo se encuentra dividido en una serie de capítulos, los cuales se describen brevemente a continuación: 1. Introducción: presenta el problema y temas a ser tratados en el trabajo. 2. La Programación Orientada a Aspectos: realiza una introducción al paradigma AOP, sus conceptos principales y objetivos. 3. El proyecto SetPoint: introduce el proyecto SetPoint y sus características salientes, destacando aquellos que estén directamente relacionados con el tema de esta tesis. 4. Antes de continuar qué entendemos exactamente por debugging?: explica qué es el debugging y las diferentes técnicas existentes. Presenta 2 El proyecto SetPoint será descrito en profundidad más adelante en este trabajo. Adrián Eidelman 9/148

10 aclaraciones acerca de conceptos erróneos comúnmente utilizados sobre la actividad. 5. Estado del arte: Investigaciones sobre el tema: describe los trabajos de investigación relacionados con el tema abordado en la presente tesis y presenta los temas pendientes de resolución relacionados con el aseguramiento de la calidad en desarrollos orientados a aspectos. 6. Definición del problema y objetivos: describe en detalle un modelo de fallas para AOP y las limitaciones al debugging existentes en SetPoint muchas veces presentes en otras plataformas-, los cuales sientan las bases para determinar las necesidades de debugging de para una herramienta de desarrollo AOP. De acuerdo al problema planteado se definen formalmente en este capítulo los objetivos de la tesis. 7. Mejorando la experiencia de debugging en desarrollos AOP: presenta una propuesta de mejora basada en una serie de propiedades que debería brindar una solución ideal de debugging para AOP. En base a las propiedades planteadas se presenta la situación de SetPoint y otras herramientas de desarrollo, reflejando el estado de situación actual en relación al soporte de debugging. 8. Nuestro grano de arena: diseño e implementación de la solución en SetPoint: describe la implementación en SetPoint de cada una de las funcionalidades construidas para dar soporte a las propiedades alcanzadas dentro del trabajo, presentando los problemas y limitaciones encontradas. Compara la situación final de la herramienta en relación a su versión anterior. 9. Unificando conceptos: un ejemplo de aplicación: presenta mediante un ejemplo sencillo cómo se puede realizar la actividad de debugging en SetPoint haciendo uso de los avances alcanzados en este trabajo 10. Conclusiones: presenta los aspectos salientes del trabajo realizado proponiendo a la vez futuras líneas de investigación relacionadas. 11. Anexo A El framework Phoenix: introduce las características más importantes de la herramienta. 12. Anexo B Diagramas de secuencia SetPoint: presenta los diagramas de secuencia actualizados correspondientes a las actividades de weaving en SetPoint. Adrián Eidelman 10/148

11 13. Anexo C Ejemplos de representaciones semánticas: presenta ejemplos de ontologías con el fin de profundizar el concepto de pointcuts semánticos. Adrián Eidelman 11/148

12 2. La Programación Orientada a Aspectos La Programación Orientada a Aspectos como nueva técnica de programación se encuadra dentro de lo que se conoce de manera genérica como POP o Post-Object Programming [Elrad et al., 2001b]. La Programación Orientada a Objetos, a pesar de ser el paradigma de programación dominante en la actualidad, posee limitaciones que han dado origen a esta nueva generación de técnicas. Hemos mencionado que AOP propone desde la teoría una real separación de incumbencias. Ahora bien... cuál es el problema con POO? Qué es en definitiva AOP? Cómo propone solucionar el problema de las incumbencias transversales? AOP reemplaza POO? El presente capítulo intentará aclarar todas estas preguntas. El problema de las incumbencias transversales La programación orientada a objetos nos ha permitido desarrollar aplicaciones complejas: interfaces gráficas, sistemas operativos y aplicaciones distribuidas son sólo unos pocos ejemplos de lo que se ha podido construir utilizando POO. Sin embargo, el éxito en desarrollar este tipo de sistemas nos lleva a querer desarrollar sistemas aún más complejos, y es ahí donde surgen necesidades de nuevas técnicas y herramientas que nos permitan hacerlo. POO es una excelente idea, pero también tiene sus limitaciones: si uno se detiene a analizar la implementación en código de una solución, es posible observar que muchos requerimientos no se descomponen claramente en una unidad que agrupe esos comportamientos. La orientación a objetos presenta dificultades al intentar agrupar o localizar estos requerimientos [Kiczales et al., 1997; Elrad et al., 2001b], que en la generalidad de los casos tienden a ser requerimientos suplementarios o no funcionales. Por el contrario, estos requerimientos se encuentran dispersos a lo largo de todo el código, de forma transversal, generando de esta forma un código de mayor complejidad y más difícil comprensión. Adrián Eidelman 12/148

13 Ejemplificando el problema Supongamos que nos piden construir un sistema para un estudio jurídico y, como parte de éste, modelamos utilizando los conceptos de la orientación a objetoslas siguientes clases: Abogado, Pasante y Secretaria. Entre los tantos requerimientos que nos solicitan deberemos brindar la posibilidad de enviar mensajes entre estos tres actores. Una modelización posible es la que muestra la Figura 2-1. Empleado Abogado Secretaria Pasante -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-1: Modelo de la solución para el estudio jurídico Dado que los mensajes enviados por abogados y secretarias pueden contener información crítica, nos solicitan además que todo mensaje enviado por alguno de estos actores deberá ser encriptado previo a su envío. Por supuesto accedemos al pedido y, dentro de la operación enviarmensaje de las clases Abogado y Secretaria, agregamos la siguiente línea de código: private void Abogado.enviarMensaje(string mensaje) {... string mensajeencriptado = encriptar(mensaje);... } Por supuesto nuestro modelo no ha sido alterado, pero ahora existe una particularidad en el código: las operaciones de envío de mensaje de las clases Abogado y Secretaria incluyen la encriptación de los mismos y, como se ilustra en la Figura 2-2, esta funcionalidad de encriptación se encuentra ahora dispersa a lo Adrián Eidelman 13/148

14 largo de más de una clase. En conclusión: la encriptación, en este modelo, constituye una incumbencia transversal o crosscuting concern [Kiczales et al., 1997]. Empleado Abogado Secretaria Pasante Encriptación -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-2: La encriptación de datos constituye una incumbencia transversal Existe además otra característica, producida por la aparición de esta incumbencia transversal, que no hemos mencionado aún. Las clases Abogado y Secretaria, que originalmente fueron diseñadas para resolver aspectos funcionales del estudio jurídico, se entremezclan ahora con aspectos secundarios al dominio del problema, como es en este caso la funcionalidad de encriptación. En resumen, son dos los efectos no deseables producto de la existencia de incumbencias transversales: el primero de los efectos mencionados, en donde el código correspondiente a una incumbencia no es encapsulado en un único módulo sino que se dispersa en varios puntos del programa, es conocido como Code Scattering. El segundo de los efectos, en donde en un mismo módulo encontramos código correspondiente a distintas incumbencias, se conoce con el nombre de Code Tangling [Kiczales et al., 1997] (Figura 2-3). El code scattering y el code tangling producen como consecuencia un código más complejo y complicado de entender y mantener. Puede argumentarse que la solución planteada en este ejemplo puede no ser la mejor. Es cierto que existen soluciones más elegantes al problema, probablemente mediante la especialización de las clases o el uso de patrones de diseño. No es intención del presente trabajo profundizar en esta discusión, sin embargo, como se explica en diversos trabajos relacionados, el problema sigue Adrián Eidelman 14/148

15 existiendo más allá del ejemplo que se utilice [Dedecker, 2002; Cyment & Altman, 2004]. Empleado Code Tangling Abogado Secretaria Pasante Code Scattering -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-3: Code Scattering y Code Tangling Una propuesta de solución: AOP La programación orientada a aspectos centra su propuesta en la idea de que es conveniente construir un sistema especificando las diferentes incumbencias del problema de manera separada e independientes unas de otras, y luego utilizar mecanismos propios del entorno de desarrollo para relacionarlas de forma de obtener un programa coherente. AOP introduce para esto una nueva unidad de modularización, denominada aspecto, la cual tiene como objetivo encapsular las incumbencias transversales. Basándose en esta propuesta, existirá una dimensión base del problema y otras que la cruzan, representadas por estos aspectos [Cyment & Altman, 2004]. Si suscribimos a la idea de asociar los aspectos con requerimientos no funcionales del sistema como puede ser logging, persistencia, transaccionabilidad, entre otros- entonces la dimensión base se corresponderá con la lógica del negocio, mientras que la dimensión de aspectos conformará los requerimientos suplementarios del sistema. Si logramos modularizar por un lado al negocio, y por separado a cada una de las incumbencias transversales, entonces desde la teoría- estaremos solucionando el problema del code scattering y el code tangling. Más aún, el programador de una dimensión del problema podrá ser capaz de desentenderse de las demás dimensiones y concentrarse sólo en aquella Adrián Eidelman 15/148

16 que le interesa, propiedad que se conoce con el nombre de obliviousness [Filman & Friedman, 2000]. Volviendo por un momento al ejemplo del abogado y la secretaria, quizás la tendencia en POO hubiese sido la de agrupar las funcionalidades comunes entre las clases en este caso la funcionalidad de encriptación- y empujarlas hacia arriba en el diagrama de clases, de forma de localizar el código de encriptar exclusivamente en la clase Empleado 3. AOP en cambio intenta tomar la incumbencia como un elemento de primera clase, y expulsarla horizontalmente de la estructura de clases, tal como se ilustra en la Figura 2-4. Empleado Encriptación Aspecto de Encriptación Abogado Secretaria Pasante -enviarmensaje() -enviarmensaje() -enviarmensaje() Figura 2-4: AOP modulariza las incumbencias transversales en unidades llamadas aspectos Modularizando las incumbencias de esta forma, AOP ofrece -desde la teoría- una real separación de incumbencias. Elementos distintivos del paradigma AOP 4 Hemos visto hasta el momento qué propone AOP como objetivo principal, analizando el problema de las incumbencias transversales. Esto no aclara de todas maneras de qué forma la programación orientada a aspectos lo trata de solucionar. Intentaremos comprender, mediante la presentación de los elementos 3 Si se analiza un poco más en detalle esta solución, llegará a la conclusión que el problema de code tangling no se resuelve de esta manera. 4 No existe un real consenso dentro de la comunidad sobre si AOP es en realidad un nuevo paradigma o no. Sí existe una visión común acerca de que constituye una evolución lógica en el desarrollo de software, especialmente para desarrollos orientados a objetos. Esta discusión escapa los alcances de este trabajo, a pesar que utilizaremos el término a lo largo del mismo. Adrián Eidelman 16/148

17 distintivos del paradigma, cómo es que AOP logra modularizar estas incumbencias. JoinPoints, Pointcuts y Advices Mediante el uso de AOP podemos modularizar las incumbencias transversales de forma independiente, y así contar con una dimensión base del problema por un lado y otras dimensiones que lo cruzan por otro lado. En dónde se intersecan estos dos mundos? Los puntos en la ejecución de un programa donde es posible aplicar la lógica de un aspecto se denominan joinpoints. Cada plataforma AOP posee su definición particular de cuáles son los puntos de ejecución que pueden conformar un joinpoint, aunque generalmente éstos están constituidos por llamadas a métodos, accesos a propiedades de un objeto o creaciones de objetos. La definición de joinpoint no basta para completar el modelo. Es necesario contar con algún mecanismo que nos permita decir qué aspecto se debe aplicar en determinado joinpoint. Expresándolo de una manera un poco más formal, necesitamos poder predicar sobre los joinpoints para definir su pertenencia o no a un conjunto, y así definir los aspectos que deben ejecutarse en tales puntos del programa. La forma que tenemos de predicar sobre los joinpoints es denominada cuantificación [Filman & Friedman, 2000] y su implementación será también particular de cada plataforma. Mediante la facilidad de cuantificación que nos provea la herramienta AOP que utilicemos será posible definir una serie de joinpoints para luego aplicar aspectos sobre tal conjunto. El nombre que se le da a un conjunto definido de joinpoints es pointcut. Finalmente, se denomina advice a la entidad que permite definir qué aspecto se debe ejecutar en todos los joinpoints pertenecientes a un pointcut. A partir de estas tres entidades presentadas, la idea de cómo funciona AOP empieza a quedar un poco más clara. Trataremos de aplicar estos nuevos conceptos al ejemplo antes presentado 5 : De acuerdo a lo expresado anteriormente, tenemos una dimensión base del problema compuesta por la lógica de negocio del estudio jurídico y otra dimensión 5 El ejemplo utiliza los conceptos de forma general, sin entrar en detalles de implementación o referenciando a alguna herramienta AOP en particular. Adrián Eidelman 17/148

18 transversal compuesta por el aspecto de encriptación 6. Necesitamos, de acuerdo a lo solicitado por nuestro cliente, que los envíos de mensaje que realizan tanto un abogado como una secretaria sean encriptados previos a su transmisión. Suponiendo que contamos con una plataforma AOP en la que las llamadas a métodos pueden constituir un joinpoint deben ser contados los casos de herramientas en los cuales esto no es así, si efectivamente existe alguna que no lo permita- podríamos decidir aplicar el aspecto de encriptación a todas las llamadas al método enviarmensaje de instancias de las clases Abogado y Secretaria. Para eso debemos definir el pointcut que incluya a todos esos puntos de ejecución, por ejemplo de la siguiente manera: Pointcut mensajessensibles { todas las llamadas al método enviarmensaje de instancias de las clases Abogado o Secretaria } Resta definir un advice que indique que se debe aplicar el aspecto de encriptación en todos los joinpoints del pointcut mensajessensibles. Esto podría realizarse de la siguiente manera: Advice encriptarmensajessensibles { aplicar el aspecto Encriptación al pointcut mensajessensibles } De acuerdo a las definiciones de pointcuts, aspectos y advices que se realicen, la plataforma AOP deberá encargarse de relacionar todos estos elementos con el objetivo de obtener como resultado un sistema que funcione idénticamente a como lo haría si hubiésemos optado por mecanismos tradicionales de programación. En definitiva, esta modularización en aspectos tiene por objetivo facilitar la construcción y entendimiento del software, mientras que el resultado que deseamos obtener desde un punto de vista de la ejecución del mismo no 6 Lógicamente podrán existir más aspectos aparte del de encriptación. Se toma este solo para simplificar el ejemplo. Adrián Eidelman 18/148

19 varía con respecto a los restantes paradigmas. El proceso por el cual se combinan la dimensión base con las restantes dimensiones del problema se denomina weaving, término que en castellano significa entretejido. Weaving El weaving es el proceso que se encarga de que se ejecuten los aspectos que corresponden durante la ejecución del programa, de acuerdo a los advices que se hayan definido. Denominaremos al componente que realiza el proceso de weaving con el nombre de weaver. Lógicamente este proceso debe valerse de mecanismos automáticos provistos por la plataforma AOP, de forma que sea, en la mayor medida posible, invisible para el programador. Como ejemplifica la Figura 2-5, el proceso de weaving integra la dimensión base en este caso la lógica de negocio del estudio jurídico- con las dimensiones transversales encapsuladas en aspectos. SISTEMA DE ESTUDIO JURÍDICO Encriptación Visualización... weaving weaving weaving Logging weaving Abogados, Secretarias, Legajos, Escritos... weaving Persistencia weaving weaving weaving Caching Tracing Seguridad Figura 2-5: El proceso de weaving Adrián Eidelman 19/148

20 El proceso de weaving es un tema central no sólo a la programación orientada a aspectos, sino también en particular al debugging en plataformas AOP por lo que será abordado en mayor detalle a lo largo del trabajo. Otras ventajas que ofrece AOP Además de la claridad en el desarrollo que persigue la programación orientada a aspectos, podemos mencionar otras ventajas que ofrece esta técnica de programación: Reutilización de aspectos: el tener las incumbencias transversales modularizadas nos da la posibilidad de reutilizar la lógica de los aspectos en otros desarrollos. Esto se puede tornar sumamente complicado si las funcionalidades se encuentran dispersas a lo largo del código fuente. Utilización de aspectos en sistemas legacy: la independencia que poseen los aspectos de la dimensión base facilitan la incorporación de funcionalidades a sistemas de los cuales no se posee conocimiento y por lo tanto sería sumamente complicado modificar el código para lograrlo. Incluso en plataformas AOP que no se valen del código fuente para lograr el weaving, esto es posible de realizar precisamente sin la existencia del código. AOP vs. POO Es importante, para cerrar la idea de la programación orientada a aspectos, entender un último concepto: el objetivo de AOP no es reemplazar POO. Todo lo contrario, AOP se construye por sobre POO, tratando de conseguir la separación de las incumbencias que POO no logra modularizar. Al programar en AOP, se siguen utilizando objetos, métodos, atributos y todos los elementos distintivos de la programación orientada a objetos. Es cierto también que las ideas centrales que propone el paradigma pueden aplicarse de la misma manera a otros paradigmas como el imperativo o el funcional, sin embargo existe una relación mucho más cercana con POO, básicamente por el uso de clases y objetos o la asociación de joinpoints con llamadas a métodos, entre otros. Adrián Eidelman 20/148

CAMINO HACIA LA WEB SEMÁNTICA. Jorge Alejandro Castillo Morales Universidad de Edimburgo

CAMINO HACIA LA WEB SEMÁNTICA. Jorge Alejandro Castillo Morales Universidad de Edimburgo INVESTIGACIÓN & DESARROLLO, No 5: 115 120 (2005) ISSN 1814-6333 RESUMEN CAMINO HACIA LA WEB SEMÁNTICA Jorge Alejandro Castillo Morales Universidad de Edimburgo El rápido crecimiento de la Word Wide Web

Más detalles

AOD: Una Introducción. (clase 19) Ingeniería de Software II

AOD: Una Introducción. (clase 19) Ingeniería de Software II AOD: Una Introducción (clase 19) Ingeniería de Software II Agenda Un poco de historia El problema de la separación de concerns Propuesta de AOP Aspectos de AOD Qué significa hacer AOD hoy? Anatomía de

Más detalles

Seminario Web Semántica y Ontologías

Seminario Web Semántica y Ontologías Seminario Web Semántica y Ontologías Inteligencia Artificial 5 o Informática IA curso 2012-2013 CCIA Noviembre 2012 IA 1112 (CCIA) Seminario Web Semántica Noviembre-2012 1 / 15 Web Semántica vs. Web Actual

Más detalles

Búsqueda sobre catálogos basada en ontologías

Búsqueda sobre catálogos basada en ontologías Búsqueda sobre catálogos basada en ontologías Alianis Pérez Sosa, Yuniel Eliades Proenza Arias Universidad de las Ciencias Informáticas. Carretera a San Antonio Km 2 ½, Reparto Torrens, La Lisa, Ciudad

Más detalles

Utilización de programación orientada a aspectos en aplicaciones enterprise

Utilización de programación orientada a aspectos en aplicaciones enterprise Universidad de Buenos Aires - Facultad de Ingeniería Propuesta de tesis de grado en Ingeniería en Informática Utilización de programación orientada a aspectos en aplicaciones enterprise Alumno: Nicolás

Más detalles

EVOLUCIÓN DE LA WEB. Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl)

EVOLUCIÓN DE LA WEB. Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl) EVOLUCIÓN DE LA WEB Presentado por: Pablo E. Lozada Y. (pablo.lozada@alumnos.usm.cl) Contenido Historia del Internet. La Web 1.0. Definición. Características. La Web 2.0. Definición. Tecnologías de la

Más detalles

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación.

Unidad II. - Las técnicas en las que se basó, las categorías de análisis o ejes centrales que permiten guiar el proceso de investigación. Unidad II Metodología de Solución de Problemas 2.1 Descripción del problema (enunciado). Este aspecto nos indica describir de manera objetiva la realidad del problema que se esta investigando. En la descripción

Más detalles

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

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

Más detalles

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

PATRONES. Experto. Solución:

PATRONES. Experto. Solución: PATRONES. Experto. Asignar una responsabilidad a la clase que tiene la información necesaria para cumplirla. Cuál es el principio fundamental en virtud del cual asignaremos las responsabilidades a los

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

Capítulo 1. Introducción

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

Más detalles

La Web Semántica como herramienta para e-learning

La Web Semántica como herramienta para e-learning La Web Semántica como herramienta para e-learning Lidia Marina López llopez@uncoma.edu.ar Departamento de Ciencias de la Computación Universidad Nacional del Comahue Buenos Aires 1400 8300 Neuquén Tel.

Más detalles

Introducción. Metadatos

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

Más detalles

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

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

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

Tecnologías XML y Web Semántica. Departamento de Informática Universidad de Oviedo

Tecnologías XML y Web Semántica. Departamento de Informática Universidad de Oviedo Tecnologías XML y Web Semántica Departamento de Informática Universidad de Oviedo Fundamentos de la Web Semántica Justificación Esquema General Principales Vocabularios Departamento de Informática Universidad

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

PROGRAMACION ORIENTADA A OBJETOS CON PHP

PROGRAMACION ORIENTADA A OBJETOS CON PHP PROGRAMACION ORIENTADA A OBJETOS CON PHP COMO SE DEFINE EN PHP La programación orientada a objetos es una metodología de programación avanzada y bastante extendida, en la que los sistemas se modelan creando

Más detalles

Programación orientada a

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

Más detalles

Diseño orientado a los objetos

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

Más detalles

SOFTWARE DE GESTIÓN DE MANTENIMIENTO

SOFTWARE DE GESTIÓN DE MANTENIMIENTO SOFTWARE DE GESTIÓN DE MANTENIMIENTO INTRODUCCIÓN El Mantenimiento Preventivo es una actividad que cada día es más reconocida y aceptada para asegurar una continuidad operativa, reduciendo al mínimo los

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

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

Introducción a la Web Semántica

Introducción a la Web Semántica Taller de Producción de Software 2007 Introducción a la Web Semántica Taller de Producción de Software 2º Semestre 2008 Indice Visión de la Web Semántica Arquitectura de la Web Semántica RDF Ontologías

Más detalles

4 o Ingeniería Informática

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

Más detalles

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA. Documentación de Motivación del Proyecto. JMit. Java Monitoring by Introspection Tool

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA. Documentación de Motivación del Proyecto. JMit. Java Monitoring by Introspection Tool UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA Documentación de Motivación del Proyecto JMit Java Monitoring by Introspection Tool Alumnos: 84.264 86.097 Tutor: Wachenchauzer, Rosa Graciela Indice

Más detalles

Gestión de la Información Multimedia en Internet Gestión del conocimiento DAML y ontologías consensuadas

Gestión de la Información Multimedia en Internet Gestión del conocimiento DAML y ontologías consensuadas Gestión de la Información Multimedia en Internet Gestión del conocimiento DAML y ontologías consensuadas Autor: Pablo Barrera González Profesor: Carlos Delgado Kloos Fecha de presentación: 7 de Febrero

Más detalles

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

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

Más detalles

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

Lenguajes y Compiladores

Lenguajes y Compiladores Información: http://www.cs.famaf.unc.edu.ar/wiki/ Profesores: Héctor Gramaglia, Miguel Pagano, Demetrio Vilela Régimen de regularidad y Promoción Se tomarán 2 parciales Promoción: obteniendo al menos 7

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

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

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

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Introducción a las Ontologías

Introducción a las Ontologías Introducción a las Ontologías Gtión del Conocimiento Dr. Ariel Monterin ISISTAN Facultad de Ciencias. Exactas- UNICEN Conceptos principal Lenguaj para la construcción de Razonamiento con Conclusion Conceptos

Más detalles

INTRODUCCIÓN AL WEB. Pag. 1 de 10

INTRODUCCIÓN AL WEB. Pag. 1 de 10 INTRODUCCIÓN AL WEB La World Wide Web o simplemente WWW o Web es uno de los métodos más importantes de comunicación que existe en Internet. Consiste en un sistema de información basado en Hipertexto (texto

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

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

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

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

Más detalles

Un largo etcétera de desventajas respecto a otros lenguajes de programación.

Un largo etcétera de desventajas respecto a otros lenguajes de programación. HISTORIA DE VISUAL BASIC El lenguaje de programación BASIC (Beginner's All purpose Symbolic Instruction Code) nació en el año 1964 como una herramienta destinado a principiantes, buscando una forma sencilla

Más detalles

Computing, nuevos horizontes para

Computing, nuevos horizontes para Acuerdo de Bibliotecas Universitarias de Córdoba Seminario 27 y 28 de septiembre de 2012 Web semántica ntica,, Web 3.0 y entornos Cloud Computing, nuevos horizontes para bibliotecarios, documentalistas

Más detalles

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

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

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

Más detalles

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

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

Más detalles

XML. El nuevo lenguaje universal

XML. El nuevo lenguaje universal Tema: XML el nuevo lenguaje universal. Autor: Marlene Melián Montalvo Institución: CITMATEL. Este trabajo consiste en una introducción al lenguaje XML. En el mismo se da a conocer su surgimiento, definiciones

Más detalles

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

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

Más detalles

Tema 3: Bases de datos en Entorno Web

Tema 3: Bases de datos en Entorno Web Tema 3: Bases de datos en Entorno Web 1. Introducción. Un sistema de bases de datos proporciona un control centralizado de los datos. Esto contrasta con la situación que prevalece actualmente, donde a

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

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

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

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

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi BPMN 2.0 Bizagi Suite BPMN 2.0 1 Tabla de Contenido Scope... 2 BPMN 2.0... 2 Qué es BPMN?... 2 Por qué es importante modelar con BPMN?... 3 Conceptos clave... 3 Proceso De Solicitud De Crédito... 3 Proceso

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

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

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

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

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

INGENIERIA DE SOFTWARE I INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE

INGENIERIA DE SOFTWARE I INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE INGENIERIA DE SOFTWARE I INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE Agenda El software. Definición de software Dominios de aplicación Software heredado La naturaleza de las webapps Ingeniería del software

Más detalles

Migración de datos automática a partir de la información de los esquemas conceptuales 1

Migración de datos automática a partir de la información de los esquemas conceptuales 1 Migración de datos automática a partir de la información de los esquemas conceptuales 1 J.Pérez 1, J.A.Carsí 1, I.Ramos 1, V.Anaya 1, J.Silva 1, Departamento de Sistemas Informáticos y Computación Universidad

Más detalles

Proyecto de Normalización Automática de Base de Datos

Proyecto de Normalización Automática de Base de Datos Proyecto de Normalización Automática de Base de Datos Lic. Beatriz Steimberg * Resumen En el primer cuatrimestre del año 2003 se encaró el proyecto de Normalización Automática de Base de Datos. El objetivo

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

Análisis del Sistema de Información

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

Más detalles

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis

Servidores web. Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web Qué es un servidor web? Tipos de servidores. Lic. Lorena Bernis Servidores web 2 SERVIDOR En informática, un servidor es un tipo de software que realiza ciertas tareas en nombre de los usuarios.

Más detalles

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS

SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Universidad de Carabobo Facultad Experimental de Ciencias y Tecnología Departamento de Computación Unidad Académica Base de Datos SISTEMAS DE GESTIÓN DE BASE DE DATOS SGBD / DBMS Integrantes: Fidel Gil

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

Programa de Asignatura

Programa de Asignatura Programa de Asignatura 01 Carrera: Tecnología Informática 02 Asignatura: Programación I 03 Año lectivo: 2013 04 Año de cursada: 2 05 Cuatrimestre: Primero 06 Hs. Totales: 5 07 Profesor: Martín Duhalde

Más detalles

TEMA 1: INTRODUCCIÓN

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

Más detalles

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Isaac Gutiérrez Gómez, Salvador Otón Tortosa Universidad de Alcalá, Departamento de Ciencias de la Computación, 28871 Alcalá de Henares, Spain igutierrez09@yahoo.es, salvador.oton@uah.es

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

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

Más detalles

Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA

Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA Sistema para Gestión de Conocimiento Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA Contenido Introducción... 3 Antecedentes... 4 Ediciones... 4 Empresarial... 4 Personal...

Más detalles

CAPÍTULO NOVENO PUPPET

CAPÍTULO NOVENO PUPPET CAPÍTULO NOVENO PUPPET En el capítulo anterior se han mostrado las 4 herramientas de software libre más representativas para la gestión de configuraciones. Al finalizarlo se optó por elegir a Puppet como

Más detalles

Java Inicial (20 horas)

Java Inicial (20 horas) Java Inicial (20 horas) 1 Temario 1. Programación Orientada a Objetos 2. Introducción y Sintaxis Java 3. Sentencias Control Flujo 4. POO en Java 5. Relaciones entre Objetos 6. Polimorfismo, abstracción

Más detalles

Buscadores basados en agentes inteligentes

Buscadores basados en agentes inteligentes Buscadores basados en agentes inteligentes Los buscadores de contenido Estos han sido esenciales a lo largo de todo el desarrollo de la web. Basados en coincidencias de palabras o frases. Desventajas Escasa

Más detalles

ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL

ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL ABAP IV. ORIENTACIÓN A OBJETOS, UNA VISIÓN GLOBAL 1 Reservados todos los derechos. El contenido de esta obra está protegido por la Ley, que establece penas de prisión y/o multas, además de las correspondientes

Más detalles

Según se afirma en [Santacruz,03], las tendencias de desarrollo de la Web semántica se centran en tres áreas aplicadas a la educación: la

Según se afirma en [Santacruz,03], las tendencias de desarrollo de la Web semántica se centran en tres áreas aplicadas a la educación: la Según se afirma en [Santacruz,03], las tendencias de desarrollo de la Web semántica se centran en tres áreas aplicadas a la educación: la informática, el diseño instructivo y los sistemas de bibliotecas.

Más detalles

Diagrama de Clases. Diagrama de Clases

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

Más detalles

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

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

Más detalles

PLAN DE ESTUDIOS Y CONTENIDOS MÍNIMOS

PLAN DE ESTUDIOS Y CONTENIDOS MÍNIMOS CARRERAS DE DOS AÑOS TECNICATURA EN PROGRAMACIÓN DE COMPUTADORAS PLAN DE ESTUDIOS Y CONTENIDOS MÍNIMOS Resolución UB 004/14 ANEXO Tabla general de asignaturas del Plan de Estudios y Obligaciones Académicas

Más detalles

Desarrollo de Aplicaciones Windows Con Visual Studio 2010

Desarrollo de Aplicaciones Windows Con Visual Studio 2010 Desarrollo de Aplicaciones Windows Con Visual Studio 2010 (.NET FRAMEWORK 4.0) ACERCA DEL CURSO: Esta Especialidad está diseñado para desarrollar los conocimientos y habilidades para el desarrollo de aplicaciones

Más detalles

SERVICIO SaaS DE FIRMA ELECTRONICA AVANZADA

SERVICIO SaaS DE FIRMA ELECTRONICA AVANZADA SERVICIO SaaS DE FIRMA ELECTRONICA AVANZADA matedi 2014. TITULO 1 ÍNDICE 1. ANTECEDENTES. 2.CONSULTORÍA. 3. VALORACIÓN. 4. RESUMEN. matedi 2015. 2 1. ANTECEDENTES. Las empresas llevan a cabo una serie

Más detalles

Programación orientada a objetos TEMA 1 INTRODUCCIÓN AL PARADIGMA ORIENTADO A OBJETOS POO

Programación orientada a objetos TEMA 1 INTRODUCCIÓN AL PARADIGMA ORIENTADO A OBJETOS POO Programación orientada a objetos TEMA 1 INTRODUCCIÓN AL PARADIGMA ORIENTADO A OBJETOS Cristina Cachero Pedro J. Ponce de León (1 Sesión) Versión 0.7 POO Indice El progreso de la abstracción Definición

Más detalles

Servidores Donantonio

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

Más detalles

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUIA DISPONIBLE EN: http://preparadorivan.blogspot.com/ - http://preparadormssi.50webs.com/inicio.html La World Wide Web o la Web, es una de las múltiples

Más detalles

Introducción a RDF. Fundamentos de la Web Semántica. Documentos. Breve historia. Objetivos RDF. Modelo de datos RDF. Pablo R.

Introducción a RDF. Fundamentos de la Web Semántica. Documentos. Breve historia. Objetivos RDF. Modelo de datos RDF. Pablo R. Introducción a RDF RDF Pablo R. Fillottrani Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Segundo Cuatrimestre 2013 Objetivos Objetivos Breve historia Breve historia Objetivos

Más detalles

Anexo I: Detalles sobre Diseño WEB y Diseño Interactivo

Anexo I: Detalles sobre Diseño WEB y Diseño Interactivo Anexo I: Detalles sobre Diseño WEB y Diseño Interactivo Anexo I: Detalles sobre Diseño WEB y Diseño Interactivo... 1 1. Los ejes alrededor de un diseño interactivo... 2 2. Los problemas de Adobe Flash...

Más detalles

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

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

Más detalles

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

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación Trabajo Final de Graduación para optar por el título Bachiller en Ingeniería en Computación Migración del Módulo de Inventario del Sistema Business Advance Víctor Guzmán Alfaro Carrera Ingeniería en Computación

Más detalles

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen)

Bases de Datos Tema 4 Modelo Entidad/Interrelación (ERM de Chen) Departamento de Lenguajes y Sistemas Informáticos E.T.S. Ingeniería Informática. Universidad de Sevilla Avda Reina Mercedes s/n. 402 Sevilla Tlf/Fax 954 557 39 E-mail lsi@lsi.us.es Web www.lsi.us.es E.T.S.

Más detalles

5.1. Estructura de las enseñanzas. Explicación general de la planificación del plan de estudios.

5.1. Estructura de las enseñanzas. Explicación general de la planificación del plan de estudios. 5.1. Estructura de las enseñanzas. Explicación general de la planificación del plan de estudios. Distribución del plan de estudios en créditos ECTS, por tipo de materia para los títulos de grado. TIPO

Más detalles

TFC -.NET Portal buscador de empleo Memoria

TFC -.NET Portal buscador de empleo Memoria TFC -.NET Portal buscador de empleo Memoria Alumno: Javier Cózar Campoy Consultor: Jairo Sarrias Guzman 25/05/ 1 Justificación y objetivo del proyecto Con este proyecto se pretende crear un portal web

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

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

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

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES Denominación de la materia SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES créditos ECTS = 36 carácter = OBLIGATORIA Ubicación dentro del plan de estudios y duración La materia está formada por 6 asignaturas

Más detalles