Proyecto De Tecnica De Programacioin I I

PROGRAMACION ORIENTADO A ASPECTO

El término POA es usado para referirse a varias tecnologías relacionadas como los métodos adaptivos, los filtros de composición, la programación orientada a sujetos o la separación multidimensional de competencias, no es un paradigma en si, ni tampoco una expansión de la programación orientada a objetos, es una nueva metodología de programación que aspira a soportar la separación de competencias para los aspectos, esta expansión se da debido a que en a POO se escribe bastante código para realizar una acción en si, lo cual ocasiona que ese código se disperse y se vuelva difícil de controlar para programación, los objetos a modo de ejemplo se pueden hacer referencia a un animal, en este caso un perro, con sus distantas características. Difinicion

La programación orientada a aspectos es soportado por los llamados lenguajes de aspectos , que proporcionan constructores para capturar los elementos que se diseminan por todo el sistema. Los lenguajes orientados a aspectos definen una nueva unidad de programación de software para encapsular aquellos conceptos que cruzan todo el código. los diferentes mecanismos de abstracción y composición que aparecen tanto en los lenguajes de aspectos, como en los lenguajes de componentes, guiado por los puntos de enlace . Mientras que un aspecto no se puede encapsular en un procedimiento con los lenguajes tradicionales ¿Qué es un aspecto?

Los lenguajes orientados a aspectos definen una nueva unidad de programación de software para encapsular las funcionalidades que cruzan todo el código. Además, estos lenguajes deben soportar la separación de aspectos como la sincronización, la distribución, el manejo de errores, la optimización de memoria, la gestión de seguridad, la persistencia. De todas formas, estos conceptos no son totalmente independientes, y está claro que hay una relación entre los componentes y los aspectos, y que por lo tanto, El código de los componentes y de estas nuevas unidades de programación tienen que interactuar de alguna manera. El encargado de realizar este proceso de mezcla se conoce como tejedor (del término inglés weaver) . La estructura general de una implementación basada en aspectos difiere de la estructura de una implementación tradicional. Una implementación tradicional consiste de un lenguaje, un compilador, o interprete para ese lenguaje, y finalmente, un programa escrito Fundamentos de la programación orientada a aspectos

Un lenguaje para definir la funcionalidad básica. Este lenguaje se conoce como lenguaje base. Suele ser un lenguaje de propósito general, tal como C++ o Java. En general, se podrían utilizar también lenguajes no imperativos. Uno o varios lenguajes de aspectos. El lenguaje de aspectos define la forma de los aspectos – por ejemplo, los aspectos de AspectJ se programan de forma muy parecida a las clases. Un tejedor de aspectos. El tejedor se encargará de combinar los lenguajes. El proceso de mezcla se puede retrasar para hacerse en tiempo de ejecución, o hacerse en tiempo de compilación. Para tener un programa orientado a aspectos necesitamos definir los siguientes elementos:

Considera la implementación del protocolo TFTP (Trivial File Transfer Protocol) con y sin aspectos, con el objetivo de aplicar y evaluar la POA. La versión sin aspectos es la versión TFTP 0.8 de Mark Benvenuto, realizada en Java, de distribución libre. Sin embargo, se debieron introducir algunas modificaciones específicas para el tratamiento de los aspectos. La comparación de ambas implementaciones permite obtener relevantes conclusiones y evaluar con resultados concretos la verdadera dimensión de las ventajas de la POA. Aplicación de la POA

Tejiendo clases y aspectos Los aspectos describen apéndices al comportamiento de los objetos. Hacen referencia a las clases de los objetos y definen en qué punto se han de colocar estos apéndices. Puntos de enlace que pueden ser tanto métodos como asignaciones de variables. Las clases y los aspectos se pueden entrelazar de dos formas distintas: de manera estática o bien de manera dinámica:

Entrelazado estático : Implica modificar el código fuente de una clase insertando sentencias en estos puntos de enlace. Es decir, que el código del aspecto se introduce en el de la clase. Un ejemplo de este tipo de tejedor es el Tejedor de Aspectos de AspectJ . La principal ventaja de esta forma de entrelazado es que se evita que el nivel de abstracción que se introduce con la programación orientada a aspectos se derive en un impacto negativo en el rendimiento de la aplicación. Pero, por el contrario, es bastante difícil identificar los aspectos en el código una vez que éste ya se ha tejido, lo cual implica que si se desea adaptar o reemplazar los aspectos de forma dinámica en tiempo de ejecución nos encontremos con un problema de eficiencia, e incluso imposible de resolver a veces.

Entrelazado dinámico Una precodición o requisito para que se pueda realizar un entrelazado dinámico es que los aspectos existan de forma explícita tanto en tiempo de compilación como en tiempo de ejecución . Para conseguir esto, tanto los aspectos como las estructuras entrelazadas se deben modelar como objetos y deben mantenerse en el ejecutable. Dado un interfaz de reflexión, el tejedor es capaz de añadir, adaptar y borrar aspectos de forma dinámica, si así se desea, durante la ejecución. Un ejemplo de este tipo de tejedores es el Tejedor AOP/ST , que no modifica el código fuente de las clases mientras se entrelazan los aspectos. En su lugar utiliza la herencia para añadir el código específico del aspecto a sus clases .

Estado del Arte en el Diseño de Lenguajes de Aspectos En este apartado se comentan las distintas tendencias que se siguen en los lenguajes de aspectos. Hasta ahora se han distinguido dos enfoques diferentes en el diseño de los lenguajes de aspectos: los lenguajes de aspectos de dominio específico y los lenguajes de aspectos de propósito general.

Esta Compuesto por: Lenguajes de Aspectos de Propósito General vs. Dominio Específico. Un lenguaje de dominio específico: COOL Un lenguaje de propósito general: AspectJ

Lenguajes de Aspectos de Propósito General vs. Dominio Específico Los lenguajes de aspectos de dominio específico soportan uno o más de estos sistemas de aspectos que se han ido mencionando en las secciones anteriores (distribución, coordinación, manejo de errores, ...), pero no pueden soportar otros aspectos distintos de aquellos para los que fueron diseñados. Los lenguajes de aspectos de dominio específico normalmente tienen un nivel de abstracción mayor que el lenguaje base y, por tanto, expresan los conceptos del dominio específico del aspecto en un nivel de representación más alto. Estos lenguajes normalmente imponen restricciones en la utilización del lenguaje base. Esto se hace para garantizar que los conceptos del dominio del aspecto se programen utilizando el lenguaje diseñado para este fin y evitar así interferencias entre ambos. Se quiere evitar que los aspectos se programen en ambos lenguajes lo cual podría conducir a un conflicto. Como ejemplos de lenguajes de dominio específico están COOL , que trata el aspecto de sincronización, y RIDL , para el aspecto de distribución.

Un lenguaje de dominio específico: COO COOL es un lenguaje de dominio específico creado por Xerox [2] cuya finalidad es la sincronización de hilos concurrentes. El lenguaje base que utiliza es una versión restringida de Java, ya que se han de eliminar los métodos wait, notify y notifyAll, y la palabra clave synchronized para evitar que se produzcan situaciones de duplicidad al intentar sincronizar los hilos en el aspecto y en la clase. En COOL, la sincronización de los hilos se especifica de forma declarativa y, por lo tanto, más abstracta que la correspondiente codificación en Java. COOL proporciona mecanismos para trabajar con la exclusión mutua de hilos de ejecución, el estado de sincronización, la suspensión con guardas, y la notificación de forma separada de las clases.

Un lenguaje de propósito general: AspectJ AspectJ es una extensión a JavaTM orientada a aspectos y de propósito general [14]. AspectJ extiende Java con una nueva clase de módulos llamado aspecto. Los aspectos cortan las clases, las interfaces y a otros aspectos. Los aspectos mejoran la separación de competencias haciendo posible localizar de forma limpia los conceptos de diseño del corte. En AspectJ, un aspecto es una clase, exactamente igual que las clases Java, pero con una particularidad, que pueden contener unos constructores de corte, que no existen en Java. Los cortes de AspectJ capturan colecciones de eventos en la ejecución de un programa. Estos eventos pueden ser invocaciones de métodos, invocaciones de constructores, y excepciones de señales y gestión. Los cortes no definen acciones, sino que describen eventos. En defnitiva, en AspectJ los aspectos son constructores que trabajan al cortar de forma transversal la modularidad de las clases de forma limpia y cuidadosamente diseñada [18]. Por lo tanto, un aspecto puede afectar a la implementación de un número de métodos en un número de clases, lo que permite capturar la estructura de corte modular de este tipo de conceptos de forma limpia.

En general, un aspecto en AspectJ está formado por una serie de elementos Cortes : Los cortes (pointcut) capturan colecciones de eventos en la ejecución de un programa. Estos eventos pueden ser invocaciones de métodos, invocaciones de constructores, y señalización y gestión de excepciones. Los cortes no definen acciones, simplemente describen eventos. Un corte está formado por una parte izquierda y una parte derecha, separadas ambas por dos puntos. En la parte izquierda se define el nombre del corte y el contexto del corte. La parte derecha define los eventos del corte .

Los cortes se utilizan para definir el código de los aspectos utilizando avisos. A los descriptores de eventos de la parte derecha de la definición del corte se les llama designadores. Un designador puede ser: Un método. Un constructor. Un manejador de excepciones. Se pueden componer utilizando los operadores o (“|”), y (“&”) y no (“!”). También se pueden utilizar caracteres comodines en la descripción de los eventos.

Introducciones: Las introducciones (introduction) se utilizan para introducir elementos completamente nuevos en las clases dadas. Entre estos elementos podemos añadir: Un nuevo método a la clase. Un nuevo constructor. Un atributo. Varios de los elementos anteriores a la vez. Varios de los elementos anteriores en varias clases. Avisos: Las declaraciones de avisos (advice) definen partes de la implementación del aspecto que se ejecutan en puntos bien definidos. Estos puntos pueden venir dados bien por cortes con nombre, bien por cortes anónimos. En las dos siguientes figuras se puede ver el mismo aviso, primero definido mediante un corte con nombre, y después mediante uno anónimo.

El cuerpo de un aviso puede añadir en distintos puntos del código, cada uno de los cuales se define mediante una palabra clave: Aviso before .- Se ejecuta justo antes de que lo hagan las acciones asociadas con los eventos del corte. Aviso after .- Se ejecuta justo después de que lo hayan hecho las acciones asociadas con los eventos del corte. Aviso catch .- Se ejecuta cuando durante la ejecución de las acciones asociadas con los eventos definidos en el corte se ha elevado una excepción del tipo definido en la propia cláusula catch. Aviso finally .- Se ejecuta justo después de la ejecución de las acciones asociadas con los eventos del corte, incluso aunque se haya producido una excepción durante la misma. Aviso around .- Atrapan la ejecución de los métodos designados por el evento. La acción original asociada con el mismo se puede invocar utilizando thisJoinPoint.runNext(). Los avisos se pueden declarar con el modificador static, indicado esto que se ejecuta el mismo aviso para todas las instancias de las clases designadas.Si se omite indica que solamente se ejecuta para ciertas instancias.

Arquitectura orientada a servicios

La Arquitectura Orientada a Servicios (en inglés Service-Oriented Architecture o SOA), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requerimientos de software del usuario. SOA proporciona una metodología y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integración y consolidación. En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios independientes a los que tienen acceso de un modo estandarizado. La mayoría de las definiciones de SOA identifican la utilización de Servicios Web

Definiciones SOA Servicio Una función sin estado auto-contenida, que acepta una(s) llamada(s) y devuelve una(s) respuesta(s) mediante una interfaz bien definida. Los servicios pueden también ejecutar unidades discretas de trabajo como serían editar y procesar una transacción. Los servicios no dependen del estado de otras funciones o procesos. Orquestación Secuenciar los servicios y proveer la lógica adicional para procesar datos. No incluye la presentación de los datos. Coordinación. Sin estado No mantiene ni depende de condición pre-existente alguna. En una SOA los servicios no son dependientes de la condición de ningún otro servicio. Reciben en la llamada toda la información que necesitan para dar una respuesta. Proveedor La función que brinda un servicio en respuesta a una llamada o petición desde un consumidor. Consumidor La función que consume el resultado del servicio provisto por un proveedor.

Diseño y desarrollo de SOA La metodología de modelado y diseño para aplicaciones SOA se conoce como análisis y diseño orientado a servicios. La arquitectura orientada a servicios es tanto un marco de trabajo para el desarrollo de software como un marco de trabajo de implantación. Cuando la mayoría de la gente habla de una arquitectura orientada a servicios están hablando de un juego de servicios residentes en Internet o en una intranet, usando servicios Web. Hay un juego de estándares de los que se habla ligados a los servicios Web. Incluyen los siguientes:

XML Es extensible, lo que quiere decir que una vez diseñado un lenguaje y puesto en producción, igual es posible extenderlo con la adición de nuevas etiquetas de manera de que los antiguos consumidores de la vieja versión todavía puedan entender el nuevo formato. Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo. Mejora la compatibilidad entre aplicaciones. La tecnología XML busca dar solución al problema de expresar información estructurada de la manera más abstracta y reutilizable posible.

HTTP es el protocolo usado en cada transacción de la Web. HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado.

SOAP desarrolladores de aplicaciones pueden utilizar la infraestructura de correo electrónico de Internet para transmitir mensajes SOAP ya sean como mensajes de correo electrónico de texto o como adjuntos. Los ejemplos que se muestran a continuación muestran un modo de transmitir mensajes SOAP, y deben ser tomados como el modo estándar de hacerlo. Las especificaciones SOAP Versión 1.2 no especifican tal vínculo

WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados en su catálogo. Las operaciones y mensajes que soporta se describen en abstracto y se ligan después al protocolo concreto de red y al formato del mensaje. Así, WSDL se usa a menudo en combinación con SOAP y XML Schema . Un programa cliente que se conecta a un servicio web puede leer el WSDL para determinar que funciones están disponibles en el servidor.

UDDI son las siglas del catálogo de negocios de Internet denominado Universal Description, Discovery and Integration . El registro en el catálogo se hace en XML. UDDI es una iniciativa industrial abierta (sufragada por la OASIS ) entroncada en el contexto de los servicios Web . El registro de un negocio en UDDI tiene tres partes: Páginas blancas - dirección, contacto y otros identificadores conocidos. Páginas amarillas - categorización industrial basada en taxonomías. Páginas verdes - información técnica sobre los servicios que aportan las propias empresas.

Nos permite observar también, que los lenguajes orientados a aspectos actuales, no cuentan con mecanismos lingüísticos suficientemente poderosos. Estos mecanismos son necesarios para respetar por completo todos los principios de diseño, como por ejemplo, el encapsulamiento. Debido a esto, plantea nuevas líneas de investigación tales como: analizar como aplicar aspectos en las otras etapas del ciclo de vida del software, en el análisis, en el diseño. En primer termino, al separar la funcionalidad básica de los aspectos, se aplica con mayor intensidad el principio de dividir y conquistar. Conclusiones

Proyecto De Tecnica De Programacioin I I

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Proyecto De Tecnica De Programacioin I I (20)

Último (20)

Proyecto De Tecnica De Programacioin I I