Desarrollo del software
Páginas: 5 (1097 palabras)
Publicado: 16 de junio de 2014
EL DESARROLLO DE SOFTWARE ORIENTADO A ASPECTOS SEGÚN IVAR JACOBSON
Ing. Gisella Guzmán Mariluz
gguzman@usmp.edu.pe
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 aspectosté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 aobjetos. 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 revolucionariocamino 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 proporcionauna 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. Desarrollo de software orientado a aspectos
El desarrollo de softwareorientado 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 delsistema 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 y agrupa elementos de modelo que colaboran para lograr los requisitos del sistema tanto funcionales como no funcionales. En la implementación segenera 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 usode 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.
Use case
Infraestructure use case 1
Infraestructure use case 2
Figura 2. Casos de uso de aplicación y de infraestructura
La primera actividad consiste en entender los intereses de losstakeholders. 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...
Ing. Gisella Guzmán Mariluz
gguzman@usmp.edu.pe
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 aspectosté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 aobjetos. 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 revolucionariocamino 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 proporcionauna 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. Desarrollo de software orientado a aspectos
El desarrollo de softwareorientado 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 delsistema 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 y agrupa elementos de modelo que colaboran para lograr los requisitos del sistema tanto funcionales como no funcionales. En la implementación segenera 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 usode 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.
Use case
Infraestructure use case 1
Infraestructure use case 2
Figura 2. Casos de uso de aplicación y de infraestructura
La primera actividad consiste en entender los intereses de losstakeholders. 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...
Leer documento completo
Regístrate para leer el documento completo.