El desarrollo de software orientado a aspectos
0 recomendaciones864 vistas
El documento describe el enfoque de desarrollo de software orientado a aspectos propuesto por Ivar Jacobson. Este enfoque extiende el Proceso Unificado para separar los requisitos funcionales y no funcionales. Las fases incluyen la captura de requisitos funcionales y de infraestructura, análisis mediante casos de uso y paquetes, diseño refinando las estructuras, implementación generando código de clases y aspectos, y pruebas para casos de uso y slices. El resultado es un software más modularizado y fácil de mantener.
El desarrollo de software orientado a aspectos
- 1. EL DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS SEGÚN IVAR JACOBSON 1. Introducción Son muchos los intereses que un equipo de desarrollo de software debe fijar su atención: entender el problema, entender su entorno, gestión del proyecto, equipo de desarrollo, aspectos técnicos, entre otros. Los intereses referidos a aspectos técnicos como seguridad, persistencia, presentación, manejo de errores, etc. han dado origen al paradigma orientado a aspectos. El enfoque orientado a aspectos define un mecanismo que ayuda a resolver problemas de codificación en los requisitos, los cuales son un código disperso (scattered) y diseminado (tangled), que no se resuelven fácilmente usando el enfoque orientado a objetos. Este mecanismo se enfoca principalmente en la separación de intereses (separation of concerns) de un sistema para obtener una mejor modularización, tal como se muestra en la figura 1. Figura 1. Separación de intereses Ivar Jaconson, un líder del pensamiento en el mundo del software donde ha hecho varias contribuciones decisivas, no podía faltar en el revolucionario camino del enfoque orientado a aspectos. En este sentido, Jacobson y su compañero de trabajo Pan-Wei Ng (en Ivar Jacobson Consulting - IJC) publicaron, en el año 2005, el libro titulado “Aspect-Oriented Software Development with Use Cases” donde describen la extensión del Proceso Unificado para desarrollar software con aspectos. En este artículo se proporciona una breve descripción de cada fase del desarrollo de software orientado a aspectos propuesto por los autores. Esta descripción le permitirá familiarizarse con términos claves de este enfoque, invitándolo a adquirir el libro para una completa comprensión ya que ilustra un caso práctico de aplicación.
- 2. 2. Desarrollo de software orientado a aspectos El desarrollo de software orientado a aspectos (DSOA) se enfoca en crear una mejor abstracción modular del sistema. Incluye las siguientes fases: - Captura de requisitos - Análisis - Diseño - Implementación - Pruebas La primera fase trata la separación de intereses tanto los funcionales como los no funcionales; los requisitos funcionales son modelados con casos de uso que representan la función básica del sistema y los requisitos no funcionales se representan con casos de uso de infraestructura. En el análisis y el diseño los casos de uso se representan en una estructura de composición que se identifica con el estereotipo <<use case slice>> y agrupa elementos de modelo que colaboran para lograr los requisitos del sistema tanto funcionales como no funcionales. En la implementación se genera el código de las clases y aspectos. Por último en las pruebas se diseñan las pruebas tanto para los casos de uso de la aplicación como para los casos de uso slice. 2.1. Captura de requisitos En esta fase se identifican dos categorías de casos de uso: de aplicación y de infraestructura. Los casos de uso de aplicación describen las funcionalidades básicas del sistema. Los casos de uso de infraestructura describen cómo el sistema agrega cualidades como facilidad de uso, confiabilidad, de rendimiento y de soporte para cada paso de un caso de uso de aplicación. Figura 2. Casos de uso de aplicación y de infraestructura La primera actividad consiste en entender los intereses de los stakeholders. El resultado es obtener una lista de características del sistema la cual incluye requisitos funcionales y no funcionales. A continuación, se capturan los casos de uso de la aplicación. Esta actividad consiste en identificar actores y casos de usos a partir de los requisitos funcionales de la lista de características, y describir los casos de uso en las especificaciones de casos de uso contemplando posibles extensiones. La descripción de los casos de uso ayudará a identificar intereses de corte transversal. En la última actividad se capturan los casos de uso de infraestructura como extensiones modulares a los casos de uso de aplicación. Para ello, se revisa nuevamente la lista de características del sistema para identificar a los requisitos no funcionales que afectan a algún paso de los casos de uso de aplicación, los cuáles serán tratados como casos de uso de transacción (use- case transaction) si se tratan de requisitos de infraestructura para el sistema. Esta actividad termina con la descripción de estos tipos de casos de uso en una especificación contemplando también sus flujos alternativos. <Use case Transaction> Use case Infraestructure use case 1 Infraestructure use case 2 <<extend>> <<extend>>
- 3. 2.2. Análisis Durante el análisis se identifica la estructura de los elementos del análisis en términos de capas, paquetes y clases (boundary, control y entity). También se identifican las estructuras de caso de uso conformados por paquetes estereotipados con <<use-case slice>> y <<non-uc-specific slice>>. Los paquetes use-case slice y non-uc-specific slice son unidades modulares específicas y no específicas respectivamente que permiten organizar mucho mejor el sistema. Un use-case slice contiene elementos necesarios para un caso de uso específico: una colaboración, que describe la realización de un caso de uso; una o más clases específicas, que son requeridas para la realización del caso de uso; y extensiones de clase específicas para un cierto aspecto. Un non-uc-specific slice contiene clases del dominio del problema que se usan en muchos casos de uso. Figura 3. Estructura de elemento Figura 4. Estructura de caso de uso 2.3. Diseño Aquí se incluyen actividades relacionadas a refinar las dos estructuras identificadas en el análisis incluyendo detalles del ambiente de implementación. Mientras que la estructura del modelo de análisis es independiente de la plataforma (lenguajes de programación y tecnología), el modelo de diseño es específico a una plataforma que será utilizado en la implementación. Application Layer Domain Layer <<use case slice>> <<use case slice>><<non-uc-specific slice>> <<extend>> <<extend>>
- 4. El proceso de refinamiento consiste en refinar las clases con detalles de implementación y refinar los casos de uso slice incluyendo aspectos y las extensiones de clases. Figura 5. Modelando un use-case slice 2.4. Implementación En esta etapa se genera el código de las clases con un lenguaje de implementación como JAVA. Asimismo, se codifican los aspectos en un lenguaje orientado a aspectos como AspectJ. 2.5. Pruebas Las pruebas se llevan a cabo desde los requisitos hasta la codificación. Se diseñan pruebas para cada caso de uso y caso de uso slice. Por otro lado, se crean casos de prueba slice que se puedan remover al completar las pruebas. 3. Conclusiones La utilización de aspectos en el proceso de desarrollo de software proporciona un soporte avanzado para la separación de intereses introduciendo una nueva forma de modularizar el sistema. El resultado de este enfoque es obtener un producto software más fácil de mantener, extender y reutilizar. La mejor forma de entender los intereses de corte transversal durante el proceso de modelado es utilizando los mecanismos de extensión del Unified Modeling Language (UML), tal como lo hicieron los autores de este enfoque: en casos de uso, paquetes y clases. 4. Bibliografía Jacobson I. and Ng P. W. Aspect-oriented Software Development with Use Cases. Addison Wesley Professional, 2005.