Proyectos Informaticos

UNIVERSIDAD LAICA ELOY ALFARO DE MANABI

FACULTAD DE CIENCIAS INFORMATICAS

ASIGNATURA:

GERENCIA DE PROYECTOS

TEMA/TITULO DEL TRABAJO:

PROYECTOS INFORMATICOS COMPLETOS

Alumno(a):

MOLINA AVILA LIGIA ELENA

Curso: 5 “B”

Profesor(a):

Ing. Jose A. Bazurto Roldan, MBA

MANTA-MANABÍ-ECUADOR

JUNIO, 2012

INDICE

Contenido

SIGLAS Y ABREVIATURAS iii

PROGRAMACIÓN ORIENTADA A ASPECTOS UNA EXPERIENCIA PRÁCTICA CON ASPECTJ 4

INTRODUCCION 4

DATOS GENERALES DEL PROYECTO 4

ANTECEDENTES GENERALES 4

DIAGNOSTICO 4

OBJETIVOS DE ESTUDIO 5

ESTRATEGIA METODOLÓGICA APLICADA AL PROYECTO 5

MARCO DE REFERENCIA 6

FORMULACION DE LOS RESULTADOS DE LA INVESTIGACION 7

CRONOGRAMA DE ACTIVIDADES Y PRESUPUESTO 7

EL USO DE LA MULTIMEDIA COMO MEDIO DIDÁCTICO EN EL APRENDIZAJE DEL PENSAMIENTO HISTÓRICO 8

INTRODUCCION 8

DATOS GENERALES DEL PROYECTO 8

ANTECEDENTES GENERALES 8

DIAGNOSTICO 9

OBJETIVOS DE ESTUDIO 9

ESTRATEGIA METODOLÓGICA APLICADA AL PROYECTO 10

MARCO DE REFERENCIA 11

CONCLUSIONES 13

RECOMENDACIONES 14

BIBLIOGRAFÍA 15

SIGLAS Y ABREVIATURAS

SOC : Separation Of Concerns

POO : Programación Orienta a Objetos

Programación orientada a aspectos una experiencia práctica con AspectJ

INTRODUCCION

DATOS GENERALES DEL PROYECTO

A. ACTORES INVOLUCRADOS

1. Nombre del Proyecto: Programación orientada a aspectos una experiencia practica con AspectJ

2. Cobertura y Localización: Universidad de Murcia

3. Sector y tipo del proyecto: sector informático, tipo de proyecto de desarrollo.

ANTECEDENTES GENERALES

Los continuos avances en la ingeniería del software han ido incrementando la capacidad de los desarrolladores de software para descomponer un sistema en módulos independientes cada uno con una función bien definida, esto es, facilitar la separación

De intereses (separation of concerns 1 , SOC)

Dentro de estos avances, quizás el más importante en estas dos últimas décadas ha sido la aparición de la programación orientada a objetos (POO). El paradigma orientado a objetos proporciona un potente mecanismo para separar intereses, sobre todo aquellos relacionados con la lógica del negocio de la aplicación, pero presenta dificultades a la hora de modelar otros intereses que no pueden ser encapsulados en una única entidad o clase, ya que afectan a distintas partes del sistema.

DIAGNOSTICO

B. FORMULACION DEL PROBLEMA OBJETO:

El objetivo de este proyecto es realizar un estudio y análisis en profundidad del paradigma orientado a aspectos, desde la perspectiva del lenguaje AspectJ, el lenguaje orientado a aspectos más ampliamente utilizado. Para ello, se abordará como caso práctico el desarrollo de una aplicación de terminal de punto de venta.

Puesto que son pocos los libros sobre programación orientada aspectos, y en concreto, sobre AspectJ existentes en la actualidad, y ninguno está traducido al español, otro de los objetivos de este proyecto será elaborar un documento que sirva para iniciarse en la POA mediante el uso del lenguaje AspectJ

C. SISTEMATIZACION DEL PROBLEMA:

Tras implementar este nuevo interés, las clases Punto y Línea además de realizar la función para la que fueron diseñadas, se encargan de realizar tareas de registro

(Logging). Cuando se dan este tipo de situaciones en las que un interés afecta a distintas partes de un sistema, se dice que el sistema ha sido “atravesado” (crosscutting) y a este tipo de intereses se les denomina intereses o competencias transversales (crosscutting concern). Las competencias transversales suelen estar relacionadas con la funcionalidad secundaria del sistema y ser de carácter no funcional. Pueden ir desde cuestiones de alto nivel como la seguridad o la calidad de los servicios ofrecidos, hasta cuestiones de más bajo nivel como pueden ser la sincronización, persistencia de datos, gestión de memoria, manejo de errores, logging, restricciones de tiempo, etc.

Las consecuencias directas de la existencia de competencias transversales son: ƒ código disperso (scattered code): el código que satisface una competencia transversal está esparcido por distintas partes del sistema. Podemos distinguir dos tipos de código esparcido:

- bloques de código duplicados: cuando los mismos bloques de código aparecen en distintas partes del sistema.

- bloques de código complementarios: cuando las distintas partes de una incumbencia son implementadas por módulos diferentes. ƒ Código enredado (tangled code): una clase o módulo además de implementar su funcionalidad principal debe ocuparse de otras competencias.

OBJETIVOS DE ESTUDIO

A. OBJETIVO GENERAL

El objetivo de este proyecto es realizar un estudio y análisis en profundidad del paradigma orientado a aspectos, desde la perspectiva del lenguaje AspectJ, el lenguaje orientado a aspectos más ampliamente utilizado. Para ello, se abordará como caso práctico el desarrollo de una aplicación de terminal de punto de venta.

Puesto que son pocos los libros sobre programación orientada aspectos, y en concreto, sobre AspectJ existentes en la actualidad, y ninguno está traducido al español, otro de los objetivos de este proyecto será elaborar un documento que sirva para iniciarse en la POA mediante el uso del lenguaje AspectJ.

B. OBJETIVOS ESPECIFICOS

ESTRATEGIA METODOLÓGICA APLICADA AL PROYECTO

A. DESCRIPCIÓN DE PROCEDIMIENTOS METODOLÓGICOS

En este apartado se va a comentar el método de trabajo seguido para la elaboración de este proyecto. En primer lugar se llevo a cabo una etapa de documentación acerca de la POA en la que se leyeron varios artículos [2, 6, 35, 36, 37] entre los que destaca el escrito por Gregor Kizcales, una de las personas que más ha contribuido al desarrollo de este nuevo paradigma, y que establece las bases de la programación orientada aspectos.

Una vez comprendidos los fundamentos del nuevo paradigma se comenzó a profundizar en el lenguaje orientado aspectos AspectJ, a través de los múltiples artículos publicados por el grupo Xerox PARC [4] y entre los que destacamos [18, 33, 34, 42].

Además se manejó el texto Mastering AspectJ [24] donde se describe con detalle todo lo relativo a este lenguaje.

Tras la adquisición de cierta destreza en el uso de este lenguaje, comenzó la etapa práctica de este proyecto, consistente en implementar el ejemplo de un sistema terminal punto de venta descrito en [28] aplicando el diseño orientado aspectos. La mayor parte del trabajo consistió en implementar en AspectJ los patrones GoF [21] utilizados durante el diseño del sistema, según se especifica en [22]. Una vez finalizada la aplicación se procedió a analizar los beneficios de la implementación con aspectos, frente la implementación clásica con Java. La última fase del proyecto consistió en la elaboración de esta memoria.

B. TIPO DE INVESTIGACIÓN:

C. DISEÑO DE LA INVESTIGACIÓN

D. TECNICAS DE RECOLECCIÓN DE DATOS

MARCO DE REFERENCIA

A. DEARROLLO DEL MARCO TEORICO:

En este primer capítulo se presenta el contexto y los objetivos del proyecto. En el Capítulo 2 se realiza un estudio del paradigma orientado a aspectos: fundamentos, lenguajes de programación, estado actual, etc. En el Capítulo 3 se profundiza en el lenguaje orientado aspectos AspectJ, describiendo en detalle su especificación. En el

Capítulo 4 se recogen los detalles de diseño de la aplicación terminal punto de venta con aspectos. En el Capítulo 5 se recogen las conclusiones y los posibles trabajos futuros.

Además, este documento va acompañado de tres anexos. En el Anexo I se encuentra la sintaxis de AspectJ, el Anexo II es un manual de instalación de AspectJ y el Anexo III es un tutorial de las herramientas de AspectJ: compilador, navegador, depurador y generador de documentación

B. MARCO CONCEPTUAL

La especificación de un lenguaje describe la sintaxis y la semántica de sus construcciones. En AspectJ, para expresar la funcionalidad de los aspectos se utiliza Java estándar, mientras que para especificar las reglas de entretejido (weaving rules) el lenguaje proporciona una serie de constructores. La implementación de las reglas de entretejido se suele llamar crosscutting, puesto que especifican la forma en que los aspectos “atraviesan” las clases de la aplicación principal.

Los creadores de AspectJ no pensaron en este lenguaje únicamente como una extensión de Java con un compilador para convertir ese conjunto de palabras clave en código ejecutable (byte-code) por la máquina virtual de Java, sino que veían AspectJ como una nueva plataforma de programación, que estaba integrada por otras herramientas además del compilador: ƒ un depurador para las clases generadas por el compilador (ajdb).

...