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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Más detalles

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

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

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

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

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

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

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

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

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

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

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN...4 Tarea 1.1: Análisis de la Necesidad del...4 Tarea 1.2: Identificación

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Capítulo VI. Diagramas de Entidad Relación

Capítulo VI. Diagramas de Entidad Relación Diagramas de Entidad Relación Diagramas de entidad relación Tabla de contenido 1.- Concepto de entidad... 91 1.1.- Entidad del negocio... 91 1.2.- Atributos y datos... 91 2.- Asociación de entidades...

Más detalles

Planificación de Sistemas de Información

Planificación de Sistemas de Información Planificación de Sistemas de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 1 ACTIVIDAD 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIÓN... 4 Tarea 1.1: Análisis de la Necesidad del... 4 Tarea 1.2: Identificació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

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

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

Convergencia, Interoperabilidad y. Fernando González-Llana Gerente de Cuenta AGE T-Systems

Convergencia, Interoperabilidad y. Fernando González-Llana Gerente de Cuenta AGE T-Systems Convergencia, Interoperabilidad y Arquitecturas de Servicios Gerente de Cuenta AGE T-Systems Palabras clave Convergencia digital, Interoperabilidad, Semántica, IDABC, SOA, Módulos Comunes, Protección de

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

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

Más detalles

UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS

UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS UNIDAD DIDACTICA 2 Lenguaje Unificado de Modelado(UML) 1. INTRODUCCIÓN Y TIPOS DE DIAGRAMAS 1.1 Qué es el UML? UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar

Más detalles

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

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

Más detalles

Introducción a los Tipos Abstractos de Datos

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

Más detalles

1.1 PROGRAMAS SECUENCIALES, INTERACTIVOS Y ORIENTADOS A EVENTOS

1.1 PROGRAMAS SECUENCIALES, INTERACTIVOS Y ORIENTADOS A EVENTOS 1. Introducción 1 1.1 Programas secuenciales, interactivos y orientados a eventos 1.2 Programas para el entorno Windows 1.2.1 Modo de Diseño y Modo de Ejecución 1.2.2 Formularios y Controles 1.2.3 Objetos

Más detalles

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS

CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS CAPÍTULO IV BREVE DESCRIPCIÓN DE LA INFRAESTRUCTURA DE CÓMPUTO VISUAL BASIC 6.0 PARA WINDOWS 4.1 Antecedentes históricos El lenguaje de programación BASIC (Beginner's All purpose Symbolic Instruction Code)

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

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking 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

Más detalles

Ingeniería del Software II

Ingeniería del Software II Ingeniería del Software II Primer cuatrimestre de 2008 Departamento de Computación Facultad de Ciencias Exactas Universidad de Buenos Aires 1 de 8 Preguntas Generales El objetivo de estas preguntas teóricas

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

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES

BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES BASES DE DATOS TEMA 4 DISEÑO DE BASES DE DATOS RELACIONALES El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que

Más detalles

Introducción a la P.O.O. Patrick Hernández Cuamatzi

Introducción a la P.O.O. Patrick Hernández Cuamatzi Introducción a la P.O.O. Patrick Hernández Cuamatzi Introducción } Debemos diferenciar entre Programación Orientada a Objetos (P.O.O.) y Lenguaje Orientado a Objetos (L.O.O.). } La P.O.O. es una filosofía,

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

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS

GUIA PROGRAMACIÓN ORIENTADA A OBJETOS GUIA PROGRAMACIÓN ORIENTADA A OBJETOS 1. Por qué la P.O.O? R= A medida que se van desarrollando los lenguajes, se va desarrollando también la posibilidad de resolver problemas más complejos. En la evolución

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

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

Qué entiende por Soporte lógico nuestra legislación tributaria? Dr. Fernando Vargas (*)

Qué entiende por Soporte lógico nuestra legislación tributaria? Dr. Fernando Vargas (*) Qué entiende por Soporte lógico nuestra legislación tributaria? Dr. Fernando Vargas (*) El ordenamiento jurídico positivo de nuestro país utiliza el concepto de Soporte Lógico para exonerar de renta a

Más detalles

Ejemplos de conversión de reales a enteros

Ejemplos de conversión de reales a enteros Ejemplos de conversión de reales a enteros Con el siguiente programa se pueden apreciar las diferencias entre las cuatro funciones para convertir de reales a enteros: program convertir_real_a_entero print

Más detalles

ESPECIFICACIÓN DE VIDEOCLUB

ESPECIFICACIÓN DE VIDEOCLUB ESPECIFICACIÓN DE VIDEOCLUB 1. ANÁLISIS DEL SISTEMA Nuestro principal objetivo, lo cual implica que se trata de nuestra mayor meta a conseguir, es desarrollar un sistema software que realice una gestión

Más detalles

7. CONCLUSIONES Y TRABAJOS FUTUROS

7. CONCLUSIONES Y TRABAJOS FUTUROS 7. CONCLUSIONES Y TRABAJOS FUTUROS 7.1 CONCLUSIONES El presente trabajo ha realizado un acercamiento a JBoss AOP, un framework que permite la definición y ejecución de comportamiento aspectual. Consideramos

Más detalles

BPM: Articulando Estrategia, Procesos y Tecnología

BPM: Articulando Estrategia, Procesos y Tecnología BPM: Articulando Estrategia, Procesos y Tecnología Resumen: La competitividad es el imaginario que dirige las acciones empresariales en la actualidad. Lograr condiciones que permitan competir con mayores

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

Historia de revisiones

Historia de revisiones Especificación de Requerimientos de Software Versión 3.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2015 1.0 Especificación Inicial. Analistas 23/08/2015 1.1 Revisión de SQA. Correcciones

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

El desarrollo de aplicaciones

El desarrollo de aplicaciones e d i t o r i a l Entendiendo el desarrollo de los sistemas SOA María Consuelo Franky R. El desarrollo de aplicaciones orientadas y basadas en servicios, como estilo de arquitectura, emergió sobre la arena

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

ESPECIFICACIÓN DE SISTEMA PARA ACADEMIA DE CORTE Y CONFECCION UNIVERSIDAD DE GRANADA E.T.S INGENIERÍA INFORMÁTICA

ESPECIFICACIÓN DE SISTEMA PARA ACADEMIA DE CORTE Y CONFECCION UNIVERSIDAD DE GRANADA E.T.S INGENIERÍA INFORMÁTICA Pág.1 ESPECIFICACIÓN DE SISTEMA PARA ACADEMIA DE CORTE Y CONFECCION UNIVERSIDAD DE GRANADA E.T.S INGENIERÍA INFORMÁTICA Dpto. Lenguajes y Sistemas Informáticos Curso 2002 / 2003 Pág.2 Asignatura: Ingeniería

Más detalles

Curso de Spring Framework

Curso de Spring Framework Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Spring es un proyecto de código abierto (open source), originalmente creado por Rod Johnson y descrito en su

Más detalles

Sistema de gestión de tareas y proyectos

Sistema de gestión de tareas y proyectos Sistema de gestión de tareas y proyectos Propuesta de proyecto Seminario de Informática I Luis Muñoz Enrique Viard Contenido Introducción... 3 Descripción general... 3 Arquitectura propuesta... 5 Requisitos...

Más detalles

Ingeniería del Software I

Ingeniería del Software I - 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

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

Guía para la elaboración del marco normativo de un sistema de gestión de la seguridad de la información (SGSI)

Guía para la elaboración del marco normativo de un sistema de gestión de la seguridad de la información (SGSI) Guía para la elaboración del marco normativo de un sistema de gestión de la seguridad de la información (SGSI) Referencia Guía para la elaboración del marco normativo- Creative common FINAL.doc Creación

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 la Firma Electrónica en MIDAS

Introducción a la Firma Electrónica en MIDAS Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento

Más detalles

Para poder ingresar al mismo, es necesario tener instalado el programa Mozilla Firefox

Para poder ingresar al mismo, es necesario tener instalado el programa Mozilla Firefox Sistema de Trámites Manual del Usuario Versión Diciembre /2011 INGRESO AL SISTEMA Para poder ingresar al mismo, es necesario tener instalado el programa Mozilla Firefox Luego en la Barra de Navegacion

Más detalles

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008

INTRODUCCIÓN. Estructura de Datos Tipos Abstractos de Datos (TAD S) Profs. Lorna Figueroa M. Mauricio Solar F. UTFSM 1 / 2008 INTRODUCCIÓN Estructura de Datos Tipos Abstractos de Datos (TAD S) Para poder obtener un programa que resuelva un problema dado, son necesarios varios pasos : La formulación y especificación del problema

Más detalles

Arquitectura y seguridad

Arquitectura y seguridad En el desarrollo del SIGOB nos hemos enfrentado a diversos problemas que nos han llevado a investigar y desarrollar nuestras propias tecnologías. En este documento presentamos cada uno de los desarrollos

Más detalles

CONSTRUCCIÓN DE PORTALES

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

Más detalles

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes

Más detalles

Desarrollo de Ontologías

Desarrollo de Ontologías Desarrollo de Ontologías ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Desarrollo de Ontologías Curso 2014/2015 1 / 31 Índice 1 Introducción 2 Metodologías de desarrollo ECSDI (LSI-FIB-UPC

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

Manual del Usuario. Sistema de Help Desk

Manual del Usuario. Sistema de Help Desk Manual del Usuario Sistema de Help Desk Objetivo del Manual El siguiente manual tiene como objetivo proveer la información necesaria para la correcta utilización del sistema Help Desk. Describe los procedimientos

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

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

Más detalles

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

Capítulo 2. Marco Teórico

Capítulo 2. Marco Teórico Capítulo 2. Marco Teórico 2.1. Frameworks para Aplicaciones Web en Java Con el crecimiento exponencial de Internet en los últimos años, las aplicaciones Web se han convertido en una parte básica y común

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

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008

GeneXus BPM Suite X. Última actualización: 01 de Setiembre de 2008 Última actualización: 01 de Setiembre de 2008 Copyright Artech Consultores S. R. L. 1988-2008. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento

Más detalles

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

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

Más detalles

12/07/2010. INGENIERIA DE SOFTWARE Tema 7: Mantenimiento del software. Contenido. 1. Aspectos Generales. 1. Aspectos Generales. 1. Aspectos Generales

12/07/2010. INGENIERIA DE SOFTWARE Tema 7: Mantenimiento del software. Contenido. 1. Aspectos Generales. 1. Aspectos Generales. 1. Aspectos Generales Contenido INGENIERIA DE SOFTWARE Tema 7: Mantenimiento del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Aspectos generales 2. Características

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

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

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

Lineamientos Para Redactar Un Escrito Para Su Publicacion

Lineamientos Para Redactar Un Escrito Para Su Publicacion Lineamientos Para Redactar Un Escrito Para Su Publicacion John P. Fisher, PhD John A. Jansen, DDS, PhD Peter C. Johnson, MD Antonios G. Mikos, PhD Co-Editors-in Chief Tejido Ingenieril Parte A, Parte B

Más detalles

La ventana de Microsoft Excel

La ventana de Microsoft Excel Actividad N 1 Conceptos básicos de Planilla de Cálculo La ventana del Microsoft Excel y sus partes. Movimiento del cursor. Tipos de datos. Metodología de trabajo con planillas. La ventana de Microsoft

Más detalles

Análisis por simulación de un sistema estocástico

Análisis por simulación de un sistema estocástico Análisis por simulación de un sistema estocástico José Carlos Cimorra Velilla David Ordóñez Arévalo ÍNDICE 1. Planteamiento del problema... 2 2. Modelo... 4 2.1 Diagrama de flujo... 4 2.2 Modelo de colas...

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

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

forma de entrenar a la nuerona en su aprendizaje.

forma de entrenar a la nuerona en su aprendizaje. Sistemas expertos e Inteligencia Artificial,Guía5 1 Facultad : Ingeniería Escuela : Computación Asignatura: Sistemas expertos e Inteligencia Artificial Tema: SISTEMAS BASADOS EN CONOCIMIENTO. Objetivo

Más detalles

Capítulo 4 Análisis y Resultados

Capítulo 4 Análisis y Resultados 58 Capítulo 4 Análisis y Resultados Al terminar la aplicación desarrollada con Django se han cumplido los objetivos planteados al principio de la propuesta. Los objetivos fueron planteados para cumplir

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