L’ingénierie des exigences orientée aspects (AORE)

L’émergence des techniques de programmation orientées aspect a soulevé la nécessité d'identifier les aspects au cours de la phase d'analyse [16]. Pour s’occuper des aspects durant l’implémentation et la modélisation de la conception, il faut en premier les identifier et cela dans une étape très précoce. De là, ils sont véritablement reflétés dans le cahier des charges des exigences [16].

3.4.1. Définition

Les approches d’analyse des exigences orientées aspects sont des approches d’analyse d’exigences qui explicitement reconnaissent l'importance d’identifier, traiter, raisonner sur des préoccupations transversales/besoins durant la phase d'analyse des exigences [16,4].

3.4.2 Objectifs de L’AORE

Malgré la grande importance qui représente l’ingénierie des exigences orientée aspect (AORE) , la plupart des praticiens dans le domaine des logiciels d'aujourd'hui ne sont pas conscients de cette nouvelle méthodologie et de ses avantages. L’AORE vise à traiter les propriétés transverses, de manière systématique afin de faciliter un raisonnement réel sur leur impact dans le domaine du problème, ainsi la modularisation de tels propriétés transversales dans la spécification des exigences permettent qu’elles puissent être effectivement projeter et donc tracer, dans le domaine de la solution[4].

3.4.2.1 limites des approches d’ingénierie des exigences non orientées aspects :

Plusieurs approches d’ingénierie des exigences existaient déjà, tel que des approches orientées objet dirigés par les cas d’utilisation, des approches orientées point de vue et des approches orientées but. les approches orientées point de vue divisent les exigences du système en diverses parties, ayant des perspectives subjectives provenant de points de vue d’intervenants, les cas d'utilisation notamment fournissent une description du système à partir des perspectives de son utilisation par des acteurs dans son environnement. D'autre part, des approches orientées objectifs (Goal-oriented) capturent et modularisent les besoins du système basées sur certain nombre d'objectifs de haut niveau du système, ce sont souvent des exigences non fonctionnels qui sont ensuite affinées dans des objectifs plus concrets, KAOS, i*, la plateforme NFR sont des exemples de méthodes orientées buts les plus connus [4]. Pourtant, ces approches ont aussi reconnu la nécessité d'une séparation effective des préoccupations similairement aux techniques de programmation et de conception [4], ces approches classiques marquent les limites suivantes qui justifient l’émergence du domaine d’AORE[4,54]:

Traitement inégal des préoccupations fonctionnelles et non fonctionnelles :

En effet, les méthodes d'ingénierie des exigences classiques ont été principalement développées pour s'attaquer à un type de préoccupations, certaines approches ont souligné l'importance des préoccupations non fonctionnelles et proposent les moyens pour assurer leurs satisfactions dans un système, d'autres approches ont mis l'accent sur la satisfaction des fonctionnalités requises d'un système. par exemple les approches Preview et NFR ont souligné l'importance des préoccupations non fonctionnelles et ont proposé des moyens pour assurer leur satisfaction dans un système, d'autre part les Problem Frames et les cas d'utilisation ont mis l'accent sur la garantie de la fonctionnalité requise d'un système [4.54].

pas de traitement des préoccupations transverses : bien que quelques

approches orientées buts et d’autres orientées point de vue ont proclamé la séparation des préoccupations fonctionnelles aussi bien que non fonctionnelles, par exemple l’approche orienté but KAOS qui utilise la logique temporelle pour spécifier les exigences fonctionnelles et non fonctionnelles et des approches orientées point de vue comme Preview qui encapsulent des préoccupations fonctionnelles et les préoccupations non fonctionnelles dans des points de vue, spécifiées par un ensemble d'exigences[4], ces approches ne traitent pas les préoccupations transversales ou la satisfaction des exigences transverses. Les exigences sont transversales par leur nature et une exigence peut avoir un effet sur plusieurs autres exigences. Ainsi, les approches classiques non orientées aspect ne traitent pas la séparation de ces exigences transversales, et ne présentent pas des mécanismes pour leurs composition d'une manière efficace sans perdre le niveau d’abstraction [4,54]. Aussi ces approches ne capturent pas clairement comment les préoccupations transverses

influencent des exigences spécifiques dans le système. En outre les préoccupations transversales n'ont pas été traitées comme des unités de modularité distinctes [54].

Influence transverse des besoins: alors que certaines approches classiques non

orientées aspects ont reconnu que les exigences non fonctionnelles sont caractérisées par leur grande influence sur les autres exigences, ils ne considèrent pas les grandes influences similaires de certaines exigences fonctionnelles [54].

Influence transverse des besoins non fonctionnels : bien que les points de

vue et les cas d'utilisation offrent des perspectives subjectives sur le système, ils ne Traitent pas les propriétés non fonctionnelles, par exemple, la sécurité, les contraintes de temps réel, la mobilité…etc, de façon systématique. Ces propriétés sont souvent des bons candidats pour les aspects qui coupent les points de vue et les cas d’utilisation [4].

Influence transverse des besoins fonctionnels : les approches orientées buts,

ne saisirent pas efficacement l'influence des propriétés fonctionnelles transverses, par exemple, recherche d'information, mise à jour des informations, etc, sur d'autres exigences dans le système [4].

La composition des exigences: bien que la plupart des approches non orientées

aspects reconnaissent l’influence des exigences l’une sur l’autre, ces approches ne traitent pas le probleme de la composition des exigences. Ils ne précisent pas les relations de composition des propriétés transverses non fonctionnelles de portée générale avec les exigences touchées par eux [4,54].

Modularisation rigide du système: touts les approches non orientées aspect

ont une structure de modularisation rigide dès le début du processus de l’ingénierie des exigences. l’approche orientée cas d'utilisation par exemple se limite à des modules cas d'utilisation, dans les approches orientées point de vue tel que Preveiw, les modules sont des points de vue. un tel engagement rigide à une structure de modularisation peut être limitatif, si on suppose qu’un analyste dispose d’un ensemble de préoccupations à traiter, des points de vue et des cas d'utilisation. Il devra décider quelle unité de modularisation à utiliser et à limiter son analyse et sûrement il va perdre les avantages offerts par d'autres structures [54].

3.4.2.2 Objectifs et défis :

AORE vise à remédier aux insuffisances ci-dessus en fournissant un moyen systématique pour l'identification, la modulation, la représentation et la composition de tous les besoins fonctionnels non fonctionnels et transversales durant toute l'ingénierie des exigences [4], ainsi :

le premier objectif que l’AORE tente à atteindre est de prévoir une égalité de traitement des préoccupations fonctionnelles et non fonctionnelles. Des approches orientées aspect, tel que Cosmos[63] et l’approche [62] (An Aspectual Use Case Driven Approach) propagent l'idée que tous les types de préoccupations sont aussi importants et doivent être traitées de manière cohérente et non discriminative[54].

le deuxième objectif d’AORE est de pouvoir adresser la grande influence transversale pour les besoins fonctionnels et non fonctionnels et leur modularisation. Beaucoup d’approches orientées aspect ont indiqué cet objectif (par exemple CORE et des approches d’exigences multidimensionnelles) . aussi, les approches d’AORE tentent à adresser le problème de restriction de structures de modularisation disponibles pour chaque approche.

la quatrième insuffisance à traiter par AORE est celle de l'absence du mécanisme de composition des exigences. La composabilité est le fait de combiner les exigences individuelles avec d’autres exigences (comme prévu, par exemple par [8]), elle est une notion centrale de l’AORE. ce soutien devrait inclure une définition de modèle de point de jonction aussi bien que la sémantique de la composition.

La composabilité permet non seulement d'examiner les exigences dans leur intégralité, mais aussi la détection des conflits potentiels très tôt pour prendre des mesures correctives ou de prendre des décisions appropriées pour la prochaine étape.