Desarrollo Orientado al Aspecto
Desarrollo 2
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 1
Ingeniería de requerimientos orientado a
necesidades



Una aproximación a la ingeniería de
requerimientos que se enfoca las necesidades
del cliente con el desarrollo de software
orientado a aspectos.
Los Puntos de vista (discutido en el capitulo 7)
es una forma de diferenciar las necesidades de
los diferentes actores.
Los puntos de vista representan los requisitos
de los grupos de interesados.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 2
Necesidades y Puntos de Vista
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 3
Puntos De Vista en un Sistema de
Inventarios
1. Usuarios de sistemas de emergencias
Encontrar un tipo determinado de equipo (por ejemplo, tren para levantar objetos pesados)
1.1
Ver el equipamiento disponible en una tienda especifica
1.2
Equipo de caja
1.3
Equipo de mostrador
1.4
Organizar equipos para ser transportado de emergencia
1.5
Presentar Informes de Daños
1.6
Encontrar almacén cerca a la emergencia
1.7
2. Planificadores de Emergencia
2.1
2.2
2.3
2.4
2.6
Buscar un tipo determinado de equipo
Ver equipos disponibles en lugares específicos
Añadir y eliminar equipos de un almacén
Mover el equipo de una tienda a otra
Pedir nuevos equipos
3. Personal de Mantenimiento
Ver equipos para el mantenimiento.
3.1
Buscar un tipo determinado de equipo
3.2
Ver programa de mantenimiento para un artículo del equipo
3.3
registro de mantenimiento completo de un artículo del equipo
3.4
Ver equipos disponibles en cada tienda
3.5
Mostrar todos los artículos en una tienda que requieren mantenimiento
3.6
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 4
Requerimientos de Disponibilidad
AV.1
Habrá un "sistema de reserva en caliente" que esté disponible en una
ubicación que esté geográficamente separado del sistema principal.
Fundamento: La emergencia puede afectar a la localización del sistema principal.
AV.1.1
Todas las transacciones se registran en el sitio del sistema principal y en
el lugar de espera a distancia.
Justificación: Esto permite que estas transacciones sean reproducidas y el sistema
de base de datos resulte coherente.
AV.1.2
El sistema deberá la información de estado al sistema de la sala de
control de emergencias cada cinco minutos.
Justificación: Los operadores del sistema de sala de control puede cambiar a la
reserva activa si el sistema principal no está disponible.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 5
Necesidades Centrales – sistema de
inventario


C.1 El sistema debe permitir a los usuarios
autorizados ver la descripción de cualquier
elemento del equipo en el inventario de servicios
de emergencia.
C.2 El sistema debe incluir un servicio de
búsqueda para permitir a los usuarios
autorizados buscar tanto inventarios individuales
como el inventario completo para un elemento
especifico o un tipo del equipo.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 6
Sistema de inventario – requerimientos de
extensión


E1.1 Debería ser posible para los usuarios
autorizados dar ordenes a los proveedores
autorizados para remplazar elementos del
equipo.
E1.1.1 Cuando un elemento del equipo es
ordenado, este debe ser asignado a un
inventario especifico y se señalaran en el citado
inventario como ¨pedidos
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 7
Diseño y programación orientada a
aspectos

Diseño orientado a aspectos
•

El proceso de diseñar un sistema que hace uso de
aspectos para implementar los temas transversales
y extensiones que se identifican durante el proceso
de ingeniera de requerimientos.
Programación orientada a aspectos
•
La implementación de un diseño orientado a
aspectos usando un lenguaje de programación
orientada a aspectos como ser el Aspecto.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 8
Casos de Uso


Un planeamiento de casos de uso puede servir
como base para la ingeniería de software
orientada a aspectos
Cada caso de uso representa cada aspecto
• La extensión de los casos de uso naturalmente llega al
núcleo + la extensión del modelo arquitectónico del sistema.

Jacobsen y Ng desarrollaron estas ideas de usar
los casos de uso introduciendo nuevos
conceptos como ser rebanadas de casos de uso
y módulos de casos de uso
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 9
Una extensión del caso de uso
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 10
Casos de uso del inventario
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 11
Extensión de caso de uso del
inventario
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 12
Proceso AOSD
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 13
Extensiones del UML

Para Expresar un diseño orientado a aspectos
en UML se requiere:
•
•
Una modelización de aspectos usando los
estereotipos de UML
La especificación de los puntos de unión donde el
aviso del aspecto esta compuesto con el núcleo del
sistema.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 14
Diseño del modelo orientado a
aspectos
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 15
Modelo parcial de un aspecto
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 16
Verificación y validación




El proceso de demostración que un programa va de
acuerdo con su especificación (Verificación) y con las
necesidades reales de las partes interesadas
(Validación)
Como cualquier otro sistema, los sistemas orientados a
aspectos pueden ser probados como cajas negras
usando su especificación para obtener las pruebas.
Sin Embargo, inspecciones de programa y probar las
¨cajas blancas¨ que se basa en el código fuente del
programa es problemático.
Los Aspectos también introducen mas problemas en las
pruebas.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 17
Problemas de pruebas con aspectos




Como deberían ser especificados los aspectos
para que se pueda llevar a cabo pruebas?
Como pueden ser probados los aspectos
independientemente de las bases del sistema?
Como puede ser probada la interfaz de los
aspectos?
Como deben ser diseñadas las pruebas así
todos los puntos de unión son ejecutados y son
aplicadas pruebas sobre aspectos apropiados?
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 18
Problemas en los programas de
inspección



Para inspeccionar efectivamente un
programa(en un lenguaje convencional),
deberías ser capas de leerlo de derecha a
izquierda
y de en
arriba
abajo. de
Problemas
los programas
inspección
Aspectos
hacen esto imposible ya que es un
programa de la web antes que un documento
secuencial. No puedes decir en el código fuente
donde un aspecto va a ser ejecutado.
Aplanar un programa orientado a aspectos para
leerlo es prácticamente imposible
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 19
Pruebas de caja blanca


El objetivo de las pruebas de caja blanca es la
de usar el conocido código fuente para diseñar
pruebas que proporcionen un cierto nivel de
cobertura, ejemplo, cada rama lógica en el
programa debe ser ejecutada por lo menos una
vez.
Problemas en los aspectos
•
•
Como un código fuente conocido puede ser usado
para crear pruebas?
Que significa exactamente prueba de cobertura.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 20
Problemas con los Aspectos


Lograr un grafico del flujo del programa de un
programa con aspectos es imposible. Por lo
tanto, resulta difícil el diseñar pruebas
sistemáticamente que asegure que todas las
combinaciones del código base y los aspectos
son ejecutados.
Que quiere decir pruebas de cobertura?
• El código de cada aspecto es ejecutado almenas 1 vez?
• El código de cada aspecto ejecutado una vez en cada punto
en que se une el aspecto.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 21
Puntos Claves



Para identificar las necesidades, se debería usar
un Puntos de Vista orientado a la ingeniería de
requerimientos.
La transición de los requerimientos al diseño
debe realizarse usando casos de uso donde
cada caso de uso representa cada una de las
necesidades de las partes interesadas.
Los problemas de la inspección y la derivación
de pruebas para programas orientados a
aspectos es una barrera para la adopción de
AOSD.
©Ian Sommerville 2006
Software Engineering, 8th edition. Chapter 32
Slide 22
Descargar

Desarrollo de Software orientado al Aspecto (2)