Révision du modèle pivot

Le modèle pivot permet de factoriser l’ensemble des formalismes utilisés par les sources de besoins. La révision du modèle pivot permet d’obtenir un modèle proche des vocabulaires

4. Le modèle conceptuel de l’ESBF

Figure 5.3 – Le framework OntoUseCase : connexion du modèle des cas d’utilisation aux mo-dèles ontologiques

Figure 5.4 – Le méta-modèle pivot [28].

contrôlés utilisés par les entreprises lors de la définition des besoins, et assez proche du langage naturel. Nous commençons par détailler les limites du modèle pivot initial.

Comme expliqué précédemment, le modèle pivot présenté ci-dessus présentent certaines

limites. Pour illustrer notre propos, prenons l’exemple de deux besoins, B₁₇ et B₁₇0, définis à

partir du document des besoins CMS:

B₁₇:”The system shall allow students to create teams”.

B170 :”The system shall allow lecturers to create teams”.

L’analyse des deux besoins, définis dans l’exemple avec la première version du modèle

pivot, montre que les deux besoins B₁₇et B₁₇0ont les mêmes actions {Action₁₇ =(create teams),

Action170 = (create teams)} mais n’ont aucun résultat et aucun critère. L’analyse de ces deux

besoins montre que les deux besoins sont égaux (B17EqualB170).

Ceci est un résultat erroné car la réalisation des deux besoins a une influence différente sur le

système conçu : les deux besoins B17et B170ont deux différents acteurs internes qui interagissent

avec le système : students, lecturers. Ces deux besoins sont donc différents. Nous avons ainsi

4. Le modèle conceptuel de l’ESBF Afin de remédier à cette limite, nous avons proposé un nouveau modèle de besoins que nous appelons le modèle pivot enrichi (MPE) et qui est illustré en figure 5.5. Ce modèle permet de détailler toutes les composantes d’un besoin. Pour ce faire, nous nous sommes inspirés de la formalisation dirigée par les tâches. Celle-ci est utilisée dans les applications centrées utilisateur qui considèrent les utilisateurs et leurs besoins tout au long du processus de développement d’applications, comme par exemple les applications de crowdsourcing, le design collaboratif et les SMA. Chaque besoin (Requirement) précise une tâche détaillée en un triplet (sujet, verbe, objet). Un besoin est ainsi modélisé d’une façon plus proche de la représentation d’une phrase en langage naturel.

Ce modèle nous permet de représenter tous les éléments détaillés des besoins, ce qui facilite ainsi leur intégration et permet un raisonnement plus précis sur les besoins.

Figure 5.5 – Modèle pivot enrichi (MPE) Nous formalisons le modèle pivot enrichi MPE comme suit : Formalisation 6

EPivotModele: < Actor, Requirement, Relationships >, dans lequel :

– Actor = {act1, act2, .., actN} est un ensemble d’acteurs qui interagissent avec le

sys-tème. Nous distinguons deux types d’acteurs : l’acteur qui définit le besoin (acteur système) ou l’acteur précisé dans le besoin (sujet). Un acteur peut correspondre à une

personne, une entité administrative ou de gestion dans l’organisation ou bien un sys-tème autonome.

– Requirement = {B1, B2, ..., Bn} correspond à l’ensemble des besoins exprimés par un

acteur. Nous définissons un besoin Bi par le quadruplet : < TASK, R, C, T > est tel

que :

– TASK = {task1, task₂, ..., taskm}, un ensemble de tâches qu’exprime un besoin.

Chaque taski=< S ub ject, Action, Ob ject >, tel que :

– S ub ject : est un acteur qui utilise le besoin afin d’obtenir un résultat ;

– Action : est une action représentée par un verbe que le système exécute pour avoir un résultat observable ;

– ob ject : est le concept (physique ou mental) concerné par l’action du besoin (verbe) ;

– R= {r1, r₂, ..., rp}: ce sont les résultats réalisés par le système ;

– C= {c1, c₂, ..., ck}: un ensemble de critères qui quantifient le résultat ;

– T: le type du formalisme de représentation du besoin, dans notre cas T ∈ { Goal, U secase, T reatment }.

– Relationships= {relation1,..., relationn} est l’ensemble de relations entre les besoins.

Chaque relationi = { Equals | Contain | Re f ine | Require | Con f licts | partiallyRe f ine

| Include | Extend | Not | And | Or }. Ces relations peuvent être explicitement expri-mées ou obtenues à partir des relations entre les besoins.

Pour illustrer l’intérêt du modèle enrichi, nous projetons l’exemple des deux besoins expli-cités précédemment sur ce modèle :

B₁₇: ”The system shall allow students to create teams”.

B₁₇0:”The system shall allow lecturers to create teams”.

L’instanciation de ces deux besoins sur notre MPE montre que les deux besoins B17 et

B₁₇0 ont les mêmes actions {Action₁₇ =(create), (Action170 = create} et les mêmes objets

{Object₁₇ =(teams), (Object170 = teams)}, mais ils ont des sujets différents : {Subject17 =(students),

(Subject₁₇0 = lecturers)}. Ces deux besoins ont donc des tâches différentes qui sont TASK= <

students, create, teams> et TASK= < lecturers, create, teams>. Ils n’ont aucun résultat et aucun

critère.

Le résultat de l’analyse de ces deux besoins avec le nouveau modèle montre que les deux

besoins sont différents car ils ont une influence différente sur le système conçu, et plus

précisé-ment sur les acteurs internes : students et lecturers.

Les relations représentées dans le modèle sont de plusieurs types. Nous avons recensé les re-lations définies dans la littérature exprimant les liens qui peuvent exister entre deux ou plusieurs besoins. Six types de relations sont identifiés (Equals, Conflicts, Contains, Refines, Partially-Refines, Requires). Nous détaillerons ces relations durant la phase de raisonnement, où leur utilisation sera utile pour inférer de nouveaux faits sur les besoins et à vérifier leur consistance.

4. Le modèle conceptuel de l’ESBF Nous représentons deux relations particulières dans un graphe que nous appelons graphe de précédence. Ces relations décrivent des relations spécifiques entre les tâches qui composent les besoins, à savoir : la contenance et l’ordonnancement entre les tâches. Ces relations sont définies dans un graphe de précédence, ou les noeuds représentent les verbes et les arcs représentent les relations entre ces noeuds (Contain, Require). Notons que le verbes utilisés sont disponibles

dans l’ontologie linguistique/conceptuelle partagée (cf. chapitre 4, section cf.4). Pour établir

son graphe de précédence, le concepteur se réfère à l’organisation interne de l’entreprise. Dans l’exemple suivant, nous illustrons la notion de graphe de précédence :

Exemple 5

B1: The system shall allow students to create an account.

B2: The system shall allow students to connect to account.

B₃: The system shall allow students to register in courses.

La figure 5.6 présente le graphe de précédence des tâches que définissent les besoins B1,

B₂ et B₃. Ce graphe montre qu’un étudiant ne peut pas se connecter à son compte avant qu’il

ne crée un compte et un étudiant ne peut pas s’enregistrer dans un cours avant qu’il ne crée un compte et qu’il ne se connecte à ce compte.

Figure 5.6 – Exemple de graphe de précedence d’une source.

Pour représenter le graphe de précédence, le modèle pivot initial est ainsi étendu par la classe PrecedenceGraphAction qui définit les relations (Contains et Requires) entre les actions des besoins.