Formalisme P-SIGMA ´ etendu

Formalisme P-SIGMA initial

Comme pour les syst`emes d’information classique [Guzelian 2004], tous les be-soins des acteurs du SID ne peuvent pas ˆetre d´efinis d`es le d´ebut du processus d’ing´enierie. De ce fait, suivant l’it´eration de d´eveloppement du SID, les patrons mis en oeuvre diff`erent. Il importe de prendre en compte la variabilit´e des contextes pour lesquels un patron peut ˆetre utilis´e. Ce contexte est sp´ecifi´e dans la repr´esentation du patron.

La repr´esentation d’un patron n´ecessite l’utilisation d’un formalisme. Selon [Duong 2000], il existe deux types de formalismes : narratif et structur´e. Le premier repose sur l’expression du patron dans un texte en langage naturel tandis que le second est organis´e par rubrique au sein d’un formulaire. Nous privil´egions le formalisme structur´e en vue de syst´ematiser la r´eutilisation au cours de l’ing´enierie des SID.

Le formalisme P-SIGMA [Conte et al. 2001] est une tentative d’unification des formalismes structur´es qui ont ´et´e propos´es [Coad 1992;Gamma et al. 1995; Busch-mann et al. 1996]. Nous l’avons choisi comme la base de notre repr´esentation car il int`egre l’expression des aspects produits et processus et un grand nombre de rela-tions inter-patrons. De plus, il facilite la s´election, la r´eutilisation et l’organisation des composants. Cet avantage est bas´e sur le regroupement de l’information en trois parties. Chaque partie regroupe des rubriques, obligatoires ou non, comprenant un ou plusieurs champs. Ainsi, le nombre de rubriques par partie du formalisme varie d’un patron `a l’autre suivant les informations associ´ees. Les parties sont les suivantes :

– interface : elle permet la s´election du patron,

– r´ealisation : elle exprime la solution propos´ee par le patron, – relation : elle permet d’organiser les relations entre patrons.

Fig. 6.2 – Diagramme de classes UML du formalisme P-SIGMA

Cependant, ce formalisme ne g`ere pas la documentation projet. La d´efinition du contexte qu’il offre ne favorise pas une r´eutilisation syst´ematique des patrons. En ce sens, dans les deux sections suivantes, nous pr´esentons la proposition pour la gestion de la documentation et celle pour la formalisation du contexte. Nous utilisons le sigle du patron qui permet de l’identifier aussi. Nous les ajoutons donc dans le formalisme P-SIGMA.

Extension pour la gestion de la documentation

Le formalisme P-SIGMA permet de d´efinir de nombreuses informations li´ees

`

a la r´ealisation de la solution-d´emarche ou de la solution-mod`ele du patron. La documentation projet est indispensable dans un projet d´ecisionnel car de nombreux acteurs de types et de domaines d’activit´es diff´erents interviennent (cf. le diagramme de classe des acteurs pr´esent´e dans la figure 3.2. L’int´egration de la gestion des documents dans la sp´ecification des patrons favorise une meilleure coordination entre les diff´erents acteurs et un vocabulaire commun. Elle implique aussi la pr´esence de supports approuv´es pour une future maintenance.

Nous proposons d’´etendre le formalisme P-SIGMA pour assurer la tra¸cabilit´e de la documentation par l’ajout de deux rubriques «Documents sources » et « Docu-ments cibles». Ces rubriques pr´ecisent la documentation li´ee au probl`eme trait´e par le patron (cf. figure6.2) comme suit :

– Documents sources : la documentation qui sera utilis´ee au cours la solution-d´emarche afin d’obtenir la solution-mod`ele,

– Documents cibles : la documentation r´esultant de l’application de la solution-d´emarche.

Tout d’abord, il est possible d’envisager la sp´ecification des documents sources au niveau de la rubrique contexte de la partie interface (cf. figure 6.2). Mais cela reviendrait `a rompre les regroupements qui font la force du formalisme initial P-SIGMA. De plus, la gestion de la documentation est une tˆache parall`ele au processus de d´eveloppement qui ne peut le contraindre en raison des imp´eratifs de productivit´e des organisations. Elle est li´ee `a la r´esolution du probl`eme pos´e par le patron. Ainsi, les rubriques « Documents sources » et « Documents cibles » se rapportent `a la partie « R´ealisation » du patron. La figure 6.3 pr´esente le formalisme P-SIGMA

´etendu sous forme tabulaire que nous utilisons pour la d´efinition de notre catalogue.

Fig. 6.3 – Formalisme P-SIGMA ´etendu

Extension pour la formalisation du contexte

Dans le formalisme P-SIGMA, le contexte est une rubrique d´efinie par une agr´ e-gation de patrons et de textes exprim´es en langage naturel. Cette d´efinition du contexte rend difficile la recherche du composant lors de la r´eutilisation [Guzelian 2004] ; ce qui contraint la r´eutilisation syst´ematique des patrons.

La rubrique «Contexte » du formalisme P-SIGMA indique les situations dans lesquelles le probl`eme est r´esolu ou encore celles dans lesquelles le patron peut ˆetre est appliqu´e ainsi que les diff´erents patrons requis par ce patron. Les informations apport´ees par cette rubrique sont donc :

– les conditions d’utilisation de ce patron,

– les patrons requis pour l’utilisation de ce patron.

[Guzelian 2004] utilisent des mod`eles de buts pour formaliser le contexte, mais cette proposition de solution n’est pas ad´equate pour notre catalogue car la granula-rit´e des patrons ´etant bas´ee sur celle de notre d´emarche, le but de d´eveloppement est d´efini par l’identifiant du patron mˆeme. De plus, dans notre catalogue de patrons, les conditions d’utilisation d’un patron d´ependent de :

– x : l’it´eration en cours du processus de d´eveloppement,

– y : le nombre d’utilisations de ce patron au cours du processus de d´ eveloppe-ment complet du SID.

Les patrons p_r requis par un patron p_s d´ependent aussi des param`etres sus cit´es.

Les conditions d’utilisation d’un patron pset les conditions dans lesquelles ce patron p_s requiert un patron p_r ne sont pas n´ecessairement identiques.

Exemple : nous avons d´efini un cycle de vie bas´e sur deux it´erations de la phase d’analyse au cours du cadrage et du prototypage pour rapprocher les besoins des trois groupes d’acteurs. Puis, seules les phases de conception et d’implantation du SID sont r´eit´er´ees pour modifier le sch´ema du SID et les sch´emas de correspondances entre les sources et le SID. Autrement dit, au cours de la deuxi`eme it´eration en termes de patrons, le patron CSID «Concevoir le SID» est utilisable et il requiert le patron ASID «Analyser le du SID ». Cependant, au cours des it´erations ult´erieures, le patron CSID est toujours applicable mais il ne requiert pas ASID.

A partir de cet exemple, nous pouvons aussi noter que la relation «requiert» entre un patron p_s et un p_r peut ˆetre optionnelle. De mˆeme, la relation «requiert» entre un patron p_s et un ensemble de patrons p_ri peut ˆetre exclusive. Un patron p_s qui requiert par d´efaut nb patrons (avec nb>1) suivant la rubrique «Requiert» du formalisme P-SIGMA ´etendu peut requ´erir exclusivement p_ri (avec 1≤i<nb) suivant l’it´eration du processus de d´eveloppement et du nombre d’utilisations.

Afin de formaliser dans quelles situations un patron p_s peut ˆetre utilis´e et dans quelles conditions il requiert un patron p_r, nous proposons deux fonctions u_s et r_s.