Un Modèle pour la spécification des processus d’analyse des Systèmes d’Information Saïd ASSAR

Camille BEN ACHOUR

Institut National des Télécommunications 9, Rue C. Fourier 91011 Evry-France E-mail : [email protected]

Université Paris 1 - Sorbonne 90, rue de Tolbiac 75013 Paris-France Email : [email protected]

Samira SI-SAÏD Conservatoire National des Arts et Métiers 292, rue St Martin 75003 Paris-France E-mail : [email protected]

Résumé : La modélisation des processus et le guidage de leur réalisation sont des problèmes clés de la recherche sur la formalisation des méthodes. Cet article présente un formalisme - appelé modèle de cartes - permettant de modéliser les démarches méthodologiques. Les cartes de processus décrivent les intentions de l’utilisateur. Chaque intention peut être réalisée selon différentes stratégies. L’utilisateur est libre dans le choix des techniques qu’il désire appliquer. Les cartes de processus ne contraignent pas l’utilisateur dans une démarche constituée d’étapes successives; mais permettent au contraire, un grand degré de liberté dans l’ordonnancement de réalisation des intentions. Cependant, par nature, les démarches modélisées imposent certaines contraintes d’ordonnancement. Ces contraintes peuvent être exprimées à l’aide de formules logiques associées aux cartes. Le modèle de cartes, le langage d’expression des contraintes d’ordonnancement, et la sémantique opérationnelle des cartes sont présentées, formalisées et illustrées à l’aide de l’exemple d’une démarche de modélisation de schéma Entité-Association.

Mots Clés : Processus de modélisation, Démarche méthodologique, Ingénierie des processus, Guidage, Modèle de carte.

Abstract : Modelling processes and guiding their enactment are key issues in research on the formalisation of methods. This paper presents a formalism - called map - for specifying process models. Process maps describe the users intentions. Each intention can be fulfilled through different strategies. The user is free in choosing the technique he wants to apply. Process maps do not constrain the user into a process composed of successive steps; but allow a high degree of freedom in choosing the order for realising intentions. Natural ordering constraints imposed by the process can be expressed using logical formulas associated with maps. We present the map model, the logical notation for expressing ordering constraints and illustrate our approach with the Entity-Relationship modelling process.

Keywords : Process, Modelling process, Process engineering, Guiding, Maps.

Page 1

1. Introduction Les processus d’analyse des Systèmes d’Information sont complexes et de nature créative. La complexité vient d'une part de la nature imprécise et évolutive des besoins, et d'autre part de la multiplicité des solutions répondant à ces besoins. Afin de gérer cette complexité, les analystes ont recours aux méthodes d'analyse. Ces méthodes sont sensées aider les analystes en systématisant la démarche à suivre [SONG1994]. Cependant, des études sur la pratique des méthodes montrent que notre connaissance sur les démarches est restreinte [LUBA1993], [LOUC1992], [WINK1993]. En effet, les méthodes se focalisent essentiellement sur la gestion du produit et peu sur les processus. Les démarches y sont : • Peu précises et insuffisamment détaillées. Elles se limitent à des descriptions du cycle de vie peu adaptées pour apporter un guidage efficace. • Elles sont décrites sous forme de séquences d'actions. Les expériences montrent que , au contraire, les processus d'analyse sont itératifs et comportent de nombreux retours en arrière [BOEH1988], [CURT1988]. • Même détaillées, les démarches sont rigides. Elles ne traduisent pas le comportement réel des analystes et ne sont, de ce fait, que partiellement appliquées. • Elles n'évoluent pas et ne prennent pas en charge la capitalisation des connaissances acquises par expérience. La réutilisation de ces connaissances devient un acte individuel de l'analyste. La description informelle des démarches a conduit à des outils essentiellement passifs. Les outils, regroupés sous l'appellation CASE1, aident à extraire, stocker, manipuler et documenter le produit [HEND1994] mais contribuent très peu au processus intellectuel de création du produit. Il est cependant certain que les processus d'analyse des Systèmes d'Informations sont des processus intelligents et créatifs, et que des heuristiques, issues des expériences passées, devraient pouvoir être utilisées dans le guidage des démarches. Le travail présenté dans cet article s'inscrit dans cette direction. Notre objectif est de rendre les démarches associées aux méthodes plus systématiques et par conséquent plus efficaces dans le guidage des analystes. Cet article comporte quatre sections. La section 2 présente un ensemble d'heuristiques liées à la construction d'un schéma Entité-Association (E/A). Ces heuristiques peuvent être, comme nous le montrerons, regroupées sous la forme d’une démarche associée au formalisme E/A. Cette démarche est ensuite décrite dans un formalisme appelé modèle de cartes qui supporte le guidage des processus d'analyse tout en préservant la flexibilité des démarches et la créativité des analystes. La troisième section présente une description formelle du modèle de cartes. La quatrième section illustre le guidage apporté par le modèle formel associé à la démarche E/A en l’appliquant à un cas concret de modélisation.

2. Un exemple de démarche méthodologique Nous avons la conviction que la démarche de construction d’un schéma conceptuel peut - du moins en partie - reposer sur des heuristiques aidant l'analyste à raisonner de manière

1

CASE : Computer Aided Software Engineering

Page 2

systématique sur les éléments que le schéma contient déjà. Ces heuristiques résultent de la capitalisation d'expériences antérieures de modélisation. Afin de modéliser ces heuristiques, nous proposons un formalisme qui permet de systématiser la spécification des démarches. Pour illustrer notre approche, nous avons choisi la démarche de modélisation associée au formalisme E/A parce que celui-ci est simple, bien maîtrisé, et très largement utilisé. Les sous-sections suivantes présentent successivement le formalisme de description des démarches, les concepts du modèle E/A et un aperçu de la démarche que nous associons au modèle E/A basée sur un ensemble d’heuristiques issues de notre propre expérience de ce formalisme. D’autres heuristiques sont proposées dans [BATI1993].

2.1.

Introduction du modèle de carte

Le formalisme que nous proposons est centré autour du concept d’intention. Il est basé sur l’idée de progression intentionnelle que l’on peut exprimer au travers des deux faits suivants : •

toute transformation dans le schéma est la concrétisation d’une intention de l’analyste,

•

chaque nouvelle transformation peut être vue comme la progression à partir d’une intention déjà réalisée.

Lorsqu’il applique une démarche, l’utilisateur est amené à s’interroger sur les intentions qui dirigent son activité. Les intentions de l’utilisateur peuvent être réalisées de plusieurs manières différentes en fonction de ses besoins et de son activité passée. Les différentes manières de réaliser une intention sont appelées des stratégies. Chaque stratégie de réalisation d’une intention identifie de façon spécifique les heuristiques proposées par la démarche. Une démarche spécifiée à l’aide de ce formalisme s’appelle une carte. Comme le montre la figure 1, les cartes sont des graphes orientés. Les sommets décrivent les différentes intentions de l’utilisateur lorsqu’il applique la démarche méthodologique, et les arcs décrivent les stratégies qui lui sont offertes pour progresser d’une intention à l’autre. Intention I

strategy S1 strategy S2 strategy S3 Intention J

Figure 1 : Un exemple de carte Les directions indiquées par les arcs définissent une relation de précédence qui doit être vérifiée lors de la navigation. Par exemple, la carte présentée en figure 1 propose trois manières de réaliser l’intention J à partir de l’intention I : celle identifiée par la stratégie S1, celle identifiée par la stratégie S2, et celle identifiée par la stratégie S3. L’intention J ne peut être appliquée que si l’intention a été appliquée au moins une fois. Chaque triplet est appelé section. D’une part, ce formalisme est flexible. Par rapport à des travaux similaires [FINK1994] [BELK1993], les démarches spécifiées à l’aide de ce formalisme ont l’avantage d’être adaptées à l’intention de l’utilisateur qui les applique. A aucun moment l’utilisateur n’est forcé de réaliser une intention particulière ou d’appliquer une stratégie de réalisation d’intention particulière, à moins que la situation ne l’exige.

Page 3

D’autre part, il est systématique. Toute démarche méthodologique décrite peut être appliquée systématiquement en fonction des intentions et des stratégies adoptées par l’utilisateur. Enfin, il s’agit d’un formalisme multi-démarches au sens où différentes combinaisons d’intentions et de stratégies peuvent être appliquées à partir d’une même description.

2.2.

Le modèle E/A

Un schéma E/A peut être vu comme un ensemble d'entités et d'associations. Les entités et les associations sont décrites par les attributs qui les composent ; les entités peuvent être liées par des relations de spécialisation/généralisation. Le méta modèle présenté dans la figure 2 résume les concepts du modèle E/A.

Lien d ’héritage 1,1

1,1

source

cible 0,n

1,n

identifiée

0,1

Clé

1,1 1,1

Entité-type

Composée de

0,1

1,n

possède

Association-type

Attribut-type

0,1

0,1

0,n

possède 1,n

composé de

composé de

0,n

1,n

Schéma Entité-Association

Figure 2 : Composition d’un schéma E/A Cette figure indique les faits suivants : • • • •

2.3.

un schéma E/A est composé d’entités-types et d’associations-types qui associent ces entités-types, une entité-type comporte un ou plusieurs attribut-types et nécessairement un identifiant, une association-type peut avoir des attributs, les entités-types peuvent participer à des hiérarchies d’héritage (on se restreint ici à l’héritage simple).

Modélisation de la démarche par le modèle de cartes

En appliquant l'idée de progression intentionnelle à la construction d’un schéma E/A, nous arrivons à l’ensemble d'intentions suivant : • •

la construction d’un schéma E/A est une intention que l’on peut satisfaire à travers la spécification des entités et des relations types qui le composent, la spécification d’une entité-type (ou d’une association-type) consiste en son identification dans le schéma et la définition de ses attributs,

Page 4

•

à partir de la spécification d’une entité-type dans le schéma on peut progresser vers la spécification d’autres entités-types ou d'associations-types en appliquant différentes stratégies de progression.

Nous détaillons à présent quelques heuristiques de progression. Ces heuristiques ne sont ni exhaustives ni complètes. Elles sont supposées être continuellement enrichies par la capitalisation d’expériences successives. Leur application est illustrée en section 4 à travers un exemple. Progresser à partir d’une entité-type La figure 3 résume les différentes progressions que nous proposons à partir d’une entité-type. Chaque stratégie propose une manière différente de progresser à partir de la spécification d’une entité. entité-type généralisée généralisation

référence

référence

normalisation

entitétype

association -type

expansion complétude

entité-type

spécialisation

entité-type spécialisée spécialisée

Figure 3 : Progresser à partir d’une entité-type La stratégie d’expansion permet d’identifier des concepts appartenant au voisinage d’un élément du schéma. Dans le cas d’une entité-type, ce voisinage peut être une association-type. Les stratégies de spécialisation et de généralisation sont des cas particuliers de la stratégie d’expansion puisqu’en plus du voisinage elle exploite les mécanismes d’abstraction (spécialisation et de généralisation) entre les concepts. La stratégie de référence permet de détecter une erreur de modélisation qui aurait conduit à l’identification d’un attribut qui concrétise la relation entre deux entités-types du schéma. Ceci conduit à l’identification d’une association qui concrétise ce lien. Dans le cas particulier où l’entité-type référencée n’existe pas dans le schéma, cette stratégie conduit à l’identification d’une nouvelle entité-type. La stratégie de normalisation permet de transformer les attributs multi-valués en entités-types. Enfin, la stratégie de complétude permet d’offrir une flexibilité aux analystes en leur laissant la liberté de spécifier partiellement les entités-type et de les compléter ultérieurement. De manière complémentaire, la sous-section suivante présente un ensemble d’heuristiques permettant la progression à partir des associations-types.

Page 5

Progresser à partir d’une association-type La progression à partir d’une association-type se fait en utilisant quatre stratégies qui sont : la stratégie de décomposition, la stratégie d’objectification, la stratégie d’historisation et la stratégie de normalisation. associationtype décomposition

association-type

objectification

entité-type entité-type

normalisation

Figure 4 : Progresser à partir d’une association-type La stratégie de décomposition permet de décomposer une association-type en plusieurs associations-types impliquant les mêmes entités-types mais ayant des sémantiques différentes. La stratégie d’objectification permet de reconsidérer une association-type en la transformant en entité-type. La stratégie d’historisation offre le moyen de gérer l’historique d’une associationtype en la transformant en une entité-type ou en créant une entité-type date qui participera à l’association-type à historiser. Enfin, la stratégie de normalisation fonctionne de la même manière que pour l’entité-type. Afin d’exploiter ces heuristiques, nous les regroupons dans une carte qui décrit notre démarche E/A.

2.4.

Le modèle global : la carte de la démarche E/A

La démarche méthodologique associée au modèle E/A est principalement composé de deux intentions : ‘Spécifier une entité’, et ‘Spécifier une association’. En plus de ces deux intentions, il est clair que l'analyste voudra éventuellement être guidé du début à la fin de la construction du schéma. Il est donc nécessaire de considérer les intentions ‘Démarrer’, et ‘Terminer’.

Page 6

Démarrer

manuellement

pa r

par complétude

par complétude

Spécifier une association par complétude

m

par spécialisation

p pa ar ex r an r ue éfé pan s lle re m nc ion e en t

par généralisation

Terminer

pa rh

Spécifier une entité

pa rn

ob je c

tif ic or at m is io al to n is ris a at tio io n n

par complétude

par normalisation

Figure 5 : Carte spécifiant une démarche associée à la méthode E/A La Figure 5 modélise le processus associé à la démarche E/A à l’aide d’une carte. Les quatre intentions introduites ci-dessus y apparaissent clairement, ainsi que les stratégies permettant de réaliser chacune d’entre elles. Les sections dans lesquelles les stratégies apparaissent indiquent les précédences. Par exemple, les deux sections : indiquent qu’il est possible de spécifier une entité par normalisation à partir d’une entité ou d’une association qui ont été spécifiées dans le passé. Le modèle de cartes est introduit et définit plus formellement en section 3. L’exemple sera réutilisé et son utilisation illustrée de manière plus étendue.

3. Formalisation du méthodologiques

modèle

de

spécification

de

démarches

Cette section a pour objectif de formaliser les concepts du modèle de cartes afin de supporter un guidage systématique des démarches méthodologiques.

3.1.

Représentation formelle d’une carte

Une section dans une carte est représentée par un triplet . Chaque section est décrite au niveau type – i.e. au moins l’intention cible n’est pas instanciée- et peut de ce fait être exécutée un nombre indéfini de fois. Par ‘exécuter une section ’, nous entendons réaliser l’intention cible J avec la stratégie Si en exploitant le résultat d’une réalisation précédente de l’intention source I. Dès lors que l’intention I a été réalisée au moins une fois, l’intention J peut être réalisée autant de fois que nécessaire, en utilisant la stratégie Si et le résultat de la réalisation de I.

Page 7

La figure 6 présente les concepts employés pour modéliser une carte. Comme l’indique le modèle, une carte peut être formellement définie comme étant composée d’un ensemble (non vide) de sections. Chaque section est elle-même composée d’une intention source, d’une intention cible et d’une stratégie. Deux types d’intentions particulières sont définis : “ Démarrer ”, à partir de laquelle l’application de la carte débute, et “ Terminer ”, qui une fois réalisée permet de considérer que l’application de la carte est terminée.

Carte 1,n

composé de

repose sur

1,1

1,n

Stratégie

Section cible

0,n

Intention source

Démarrer

Terminer

Figure 6 : Le modèle de carte Comme l’indiquent les cardinalités des associations ‘source’ et ‘cible’, une intention peut n’être source d’aucune section (c’est par exemple le cas de l’intention “ Terminer ”), et une intention peut n’être destination d’aucune section (c’est le cas de l’intention “ Démarrer ”). Deux particularités doivent cependant être notées : 1. La réalisation d’une intention se fait à l’aide d’une stratégie qui exploite le résultat des sections déjà exécutées. Par conséquent, seule l’intention “ Démarrer ” peut n’être cible d’aucune section. La réalisation de toute autre intention ne sera pas guidée si elle n’est pas cible d’une section. Nous considérons donc ici que l’application de la démarche commence au moment où l’utilisateur a déjà démarré, mais n’a encore réalisé aucune autre intention de la carte. 2. Le fait qu’une intention ne soit source d’aucune section n’implique pas que sa réalisation bloque l’application ultérieure de la carte. Lorsqu’une une telle intention est réalisée, le résultat de sa réalisation ne sera jamais utilisé, mais toute autre section de la carte peut encore être appliquée. Une même stratégie peut apparaître dans une ou plusieurs sections. Deux sections reposant sur une même stratégie peuvent donc être similaires ou différentes selon les heuristiques qu’elles référencent. Il faut en revanche noter qu’une intention ne peut apparaître qu’une et une seule fois dans une carte. La richesse d’une carte réside dans la diversité des stratégies qu’elle propose pour réaliser les intentions qui la composent. La carte associée à la démarche E/A (figure 5) comporte ainsi quatorze sections regroupant neuf stratégies de réalisation des intentions “ Spécifier une entité ”, “ Spécifier une association ” et “ Terminer ”. Par ailleurs, un grand degré de liberté est laissé à la personne guidée dans le choix de l’ordre de réalisation de ces intentions. Ainsi la carte associée à la démarche E/A permet de spécifier une entité : • •

à tout moment avec les stratégies “ manuelle ” et de “ complétude ”, à partir d’une entité spécifiée auparavant à l’aide des stratégies de “ normalisation ”, de “ référence ”, de “ complétude ”, de “ généralisation ”, et de “ spécialisation ”, et Page 8

•

à partir d’une association spécifiée auparavant à l’aide des stratégies de “ normalisation ” et d’“ objectification ” et d’ “ historisation ”.

Il est cependant clair qu’un tel degré de liberté n’est pas forcément désirable. Ainsi, la spécification d’une entité par historisation d’une association n’a pas lieu d’être répétée plusieurs fois ; à partir du moment ou une association a été historisée une fois, la même opération ne devrait pouvoir être répétée sur la même association. Cette contrainte d’application de la carte, ainsi que d’autres contraintes d’ordonnancement, peuvent être spécifiées à l’aide du langage présenté dans la sous-section suivante.

3.2.

Contraintes de réalisation de processus spécifiés à l’aide de cartes

La capacité à appliquer une section donnée d’une carte dépend de l’historique des intentions déjà réalisées par le passé. A partir du moment où une intention a été réalisée, toute section dont cette intention est source peut être appliquée. La possibilité d’appliquer une section ou non est soumise à des contraintes d’ordonnancement avec d’autres sections. Les contraintes d’ordonnancement indiquent le contexte dans lequel une section ne peut pas être appliquée. Afin de vérifier qu’elles ne sont pas violées, elles sont vérifiées tout au long de l’application d’une carte en fonction de l’historique des sections qui ont déjà été appliquées. Pour spécifier une contrainte, il est donc nécessaire de pouvoir identifier les sections déjà réalisées ainsi que les sections qui pourraient être réalisées. Nous utilisons pour cela la notation suivante : • • • •

I : désigne une intention telle qu’elle est identifiée dans une carte. Par exemple “ Spécifier une entité ” et “ Spécifier une association ” sont les deux principales intentions de la carte décrite en Figure 5. S : désigne une stratégie. “ Par normalisation ” et “ Par objectification ” sont deux exemples de stratégie apparaissant dans la carte de la Figure 5. Ii : désigne une intention instanciée, i.e. qui a été réalisée à partir d’une situation de départ connue et dont on connaît le résultat. _ : désigne une intention ou une stratégie inconnue.

La Table 1 ci dessous résume les notations utilisées pour représenter les sections : Notation

Nom

Explication



Une section dans I et J sont des intentions et S désigne une stratégie. une carte



Une section exécutée

Une section a été exécutée à partir du résultat d’une réalisation de l’intention I. Le résultat de cette exécution réalise l’intention J. Ii et Jj font référence à des réalisations des intentions I et J (dites aussi instances de I et J)



Une section candidate

La section pourrait être exécutée en partant du résultat d’une réalisation de l’intention I référencée par Ii.

Table 1 : notations formelles pour décrire les sections

Page 9

Les contraintes d’ordonnancement des sections sont exprimées à l’aide de prédicats logiques qui doivent être vérifiés à toute date t au cours de l’application d’une démarche. Trois types de prédicats sont proposés : Prédicat

Explication

♦

est vérifié si et seulement si la section a été instanciée à une date antérieure à t

à

peut être instanciée à toute date postérieure à t.

Ο

est vérifié si et seulement si la section est candidate à la date t+1.

Table 2 : notation formelle pour exprimer les contraintes L’emploi des quantificateurs universel (∀) et d’existence (∃), combiné aux connecteurs usuels de la logique du premier ordre (et ∧, ou ∨, non ¬, implique Þ), et aux trois types de prédicats identifiés ci-dessus permet de spécifier des contraintes telles que : i. ii. iii. iv. v. vi.

‘Une association ne peut être historisée deux fois’, ‘Une association ne peut être spécifiée en utilisant la stratégie de référence à partir d’une entité qui n’a pas encore été spécifiée par normalisation’, ‘Une entité ne peut être spécifiée par spécialisation à partir d’une entité qui n’a pas été normalisée’, ‘La spécification d’une entité par objectification d’une association ne peut être réalisée à partir d’une même association’, ‘Une fois qu’une association a été utilisée pour spécifier une entité par objectification, elle ne peut plus être spécifiée par complétude’, ‘Deux entités ne peuvent être spécifiées par la généralisation une même entité’ ( héritage simple)

Les contraintes i. et ii. peuvent être spécifiées formellement de la manière suivante à l’aide des contraintes suivantes : i. ∀ i, j, ♦ Þ ¬ (à ) ii. ∀ i, j, ¬ (♦ ) Þ ¬ (Ο ) Ces deux contraintes expriment respectivement l’exclusion et la précédence. On dit qu’une section est exclue par une section si elle ne peut être candidate une fois que a été exécutée. De plus, on dit qu’une section précède la section si cette dernière ne peut être candidate tant que n’a pas été exécutée. De manière générale, les contraintes d’exclusion et de précédence s’expriment de la par les formules suivantes : Exclusion : ∀ i, j, k ♦ Þ ¬ (à ) Précédence : ∀ i, j, k ¬ (♦ ) Þ ¬ (Ο ) Dans ces formules génériques, les valeurs de I, J, K, L, S1, S2, i, j, et k peuvent être égales ou différentes selon les besoins. Toutes les contraintes citées ci-dessus en association à la carte de spécification d’un modèle entité-association s’expriment d’après ces deux formules. Page 10

Ainsi les contraintes iv. et vi. sont des exclusions alors que les contraintes iii. et v. sont des précédences. Par exemple, la contrainte v. prend la forme suivante : ∀ i, j, k ♦ Þ ¬ (à )

3.3.

Mécanisme d’exécution des cartes

L’application d’une carte pour le guidage de la démarche méthodologique à laquelle elle est associée consiste en la répétition perpétuelle des deux étapes suivantes : • •

sélectionner une section, et exécuter une section.

Afin de sélectionner une section, il est nécessaire de connaître l’historique des sections qui ont déjà été exécutées. Cet historique peut être représenté simplement par un ensemble de sections instanciées. L’ensemble des sections exécutables est calculé en combinant l’ensemble des sections décrites dans la carte avec l’ensemble des intentions déjà instanciées. S’il existe dans la carte une section et que l’intention instanciée Ii existe, alors est exécutable. L’ensemble des intentions déjà instanciées peut être retrouvé par simple projection de l’historique sur les intentions cibles. Une section ne peut être candidate (i.e. sélectionnable pour l’exécution) que si elle respecte toutes les contraintes associées à la carte. L’ensemble des sections candidates est donc calculé par application de la collection de contraintes à toutes les sections exécutables qui ont pu être identifiées. Une fois la collection de sections candidates calculée, l’utilisateur choisit la section qu’il désire exécuter et celle-ci est exécutée. L’exécution des sections peut prendre diverses formes. Ainsi, il peut s’agir d’une séquence d’étapes à réaliser, du déclenchement de la fonction d’un outil supportant la méthode, ou tout simplement de l’affichage de recommandations textuelles décrivant la manière de réaliser l’intention désirée. Une fois une section appliquée, le résultat de l’application de la section est enregistré dans l’historique qui, initialement, ne contient que la section instanciée . Cette section instanciée indique qu’à tout moment, et en particulier dès le début de l’application de la carte, l’intention démarrer peut être considérée comme ayant été réalisée au moins une fois. Le mécanisme d’application de cartes est illustré dans la section ci-dessous à l’aide de l’exemple de la carte décrite en figure 5 à laquelle sont associées les contraintes présentées et spécifiées en section 3.2.

4. Exemple d’application Dans cette section, nous allons illustrer l’utilisation du formalisme de cartes en l’appliquant à un exemple. L’exemple choisi est celui du cas bien connu de gestion des prêts dans une bibliothèque. On considère qu’au départ, et après une première phase de recueil des besoins, l’analyste a obtenu le schéma suivant :

Page 11

Bibliothèque

Bibliothécaire

• Nom

• N°

Figure 7 : Le schéma E/A initial

Abonné externe

0,n

A emprunté

0,n

Exemplaire

0,n

A emprunté

0,n

Abonné interne

1,1

Correspond à 1,n

Ouvrage

Plus précisément, du point de vue de la carte présenté dans figure 5, ceci correspond à la réalisation antérieure des intentions suivantes : spécifier entité “Bibliothèque”, spécifier entité “Bibliothécaire”, spécifier entité “ouvrage”, spécifier entité “exemplaire”, spécifier entité “abonnée interne”, spécifier entité “abonné externe”, spécifier association “correspondre”, spécifier association “prêt extérieur”, spécifier association “prêt intérieur”. Maintenant, l’utilisateur peut être guidé par la carte de la figue 5 en supposant que les intentions précédentes ont été réalisées.

4.1.

Étape 1

A partir de l’intention “ spécifier entité bibliothèque ”, l’analyste choisit de progresser en appliquant la stratégie de référence qui lui permet de s’apercevoir que l’attribut “ nom ” dans l’entité bibliothèque est en fait le nom du bibliothécaire. Le résultat aboutit à la création d’une nouvelle association “ diriger ” : Dirige

Spécifier une entité

Spécifier une association

pa rr

éf ér en ce

1,1

Section de carte exécutée

4.2.

Bibliothécaire • N° • Nom

1,n

Bibliothèque • N°

Le fragment de schéma obtenu

Étape 2

Page 12

L’analyste souhaite à présent compléter le schéma en enrichissant la spécification des entités déjà présentes. Pour satisfaire cette intention, il applique la stratégie de complétude qui consiste à compléter la spécification d’une entité en rajoutant et/ou modifiant la liste de ses attributs. L’analyste choisit d’appliquer cette stratégie sur les deux entités “abonné interne” et “abonné externe” : 0,n

Exemplaire

A emprunté

0,n

A emprunté

par complétude Spécifier une entité

Section de carte exécutée

0,n

0,n

Abonné externe

Abonné interne

• N° • Nom • Université

• N° • Nom • UFR

Le fragment de schéma obtenu

4.3.

Étape 3

A partir de la spécification de l’entité “ exemplaire ”, la carte propose entre autres de progresser en appliquant la stratégie de spécialisation. L’analyste décide d’appliquer cette stratégie en s’appuyant sur les cardinalités partielles des associations “prêt interne” et “prêt externe”. Ceci aboutit à la création de deux nouvelles entités, l’introduction d’un lien de spécialisation et à la transformation du schéma comme suit : Exemplaire

Spécifier une entité

Non empruntable

Empruntable 0,n

A emprunté

en spécialisant

4.4.

A emprunté

0,n

Abonné externe

Section de carte exécutée

0,n

0,n

Abonné interne

Le fragment de schéma obtenu

Étape 4

Une autre manière de progresser à partir de la spécification d’une entité est proposée par la stratégie de généralisation. La distinction entre abonnée interne et externe suggère qu’il est possible d’effectuer une telle progression et d’introduire l’entité “abonné” : Abonné

Spécifier une entité en généralisant

Abonné interne

Section de carte exécutée

4.5.

Abonné externe

Le fragment de schéma obtenu

Étape 5

Page 13

L’analyste souhaite garder trace de tous les prêts contractés par un abonné, il décide alors de transformer les deux associations “prêt interne” et “prêt externe” en une nouvelle entité. Ceci est obtenu en appliquant la stratégie d'objectification:

Prêt

1,n

Porte sur

en

Spécifier une entité

1,1

ob je ct ifi

an t

Effectue

0,n

Spécifier une association

Abonné

Section de carte exécutée

4.6.

0,n

Exemplaire empruntable

Le fragment de schéma obtenu

Étape 6

La dernière transformation fait appel à la stratégie d’expansion qui permet de progresser à partir d’une entité déjà spécifiée pour découvrir de nouvelles associations dans son voisinage. Ainsi, par analyse des entités “bibliothèque”, “abonné” et “exemplaire”, l’utilisateur découvre deux nouvelles associations :

Est membre de

pa re xp an si on

Spécifier une entité

Spécifier une association

Bibliothèque 0,n

Contient

• N° • Nom

1,1

Abonné

1,1

Exemplaire

Le fragment de schéma obtenu

Section de carte exécutée

4.7.

0,n

Schéma final

La figure 8 présente le schéma E/A final obtenu après application des différentes transformations successives.

Page 14

Bibliothécaire • N° • Nom

Dirige

1,1

Ouvrage 1,n 1,n

Est membre de

1,1

0,n

Bibliothèque 0,n

Contient

• N° • Nom

Correspond à

Effectue

Abonné

0,n

1,1

1,1

Exemplaire 1,1

Prêt

Abonné interne

Exemplaire non empruntable

1,n

Abonné externe

Porte sur

0,n

Exemplaire empruntable

Figure 8 : Le schéma E/A obtenu après transformations successives

5. Conclusion Nous avons présenté dans cet article le concept de carte. Les cartes permettent de spécifier les processus associés aux démarches méthodologiques. Toute carte contient une collection d’intentions reliées entre elles par des stratégies de réalisation de ces intentions lors de l’application de la démarche. Nous proposons une notation graphique des cartes, ainsi qu’une notation formelle supportant une spécification plus complète. Celle-ci permet notamment la spécification des contraintes sur l'ordre de réalisation des intentions. Ces deux notations, ainsi que la sémantique opérationnelle des cartes ont été illustrées à l’aide d’un exemple de spécification et d’application d’un processus associé à la démarche Entité/Association. On a pu ainsi expliciter quelques heuristiques connues de modélisation, et montrer comment le processus devient une succession d'étapes que l'analyste choisit en naviguant librement dans la carte. Cette possibilité offerte à l'utilisateur pour appliquer une démarche méthodologique selon ses désirs et selon la situation dans laquelle il se trouve, est une caractéristique essentielle de notre approche. Elle constitue un avantage majeur par rapport à d'autres propositions de modèles de processus [BAND94] [CUGO98]. Nous pensons que l’implémentation d’un outil de guidage, à la fois flexible, indépendant du modèle de produit, et capable d’interagir avec d’autres outils est plus facilement réalisable qu’avec les solutions proposées jusqu’à présent. Une première version d’un tel outil ne comportant pas les contraintes a été présentée dans [SISA1999]. De nombreuses questions doivent cependant être résolues avant d’entreprendre la réalisation d’un tel outil. Il s'agit notamment de vérifier qu’une carte est correctement spécifiée, de trouver l’ensemble complet des types de contraintes que l’on peut vouloir associer à une carte, et de démontrer la validité de notre approche en l'appliquant dans un contexte industriel.

Page 15

Références [BELK1993] N. BELKHATIR, J. ESTUBLIER, W. MELO. "Software process model and work space control in the Adele system" dans Proc. 2nd Int. Conf.on Software Process (ICSP'2), Berlin. 170 p. IEEE-CS Press, March 1993. [BAND1994] S. BANDINELLI, A. FUGGETTA, C. GHEZZI, L. LAVAZZA. "SPADE: an environment for software process analysis, design and enactment" In [Fink94], pp 223-247. [BATI1993] C. BATINI, S. CERI, S.B. NAVATHE. "Conceptual database design" The Benjamin/Cumings publishing company, Inc., 1992, ISBN 0-8053-0244-1. [BOEH1988] B. BOEHM. "A spiral model of software development and enhancement" IEEE Computer 21, 5, 1988. [CUGO1998] G. CUGOLA. “Inconsistencies and deviations in process support systems” PhD Thesis Politecnico di Milano, February 1998. [CURT1988] B. CURTIS, M. KELLNER, J. OVER. "A Field Study of the Software Design Process for Large Systems" Com. ACM, Vol. 31, No. 11, 1988. [FINK1994] A. FINKELSTEIN, J. KRAMER, B. NUSEIBEH (EDS). ”Software process modelling and technology” John Wiley Publications, 1994 [HEND1994] J. C. HENDERSON, J. G. COOPRIDER. "Dimensions of IS Planning and Design Aids: A Functional Model Of CASE Technology" In Alle, M. Scott-Monbri (Eds). "IT and the Cooperation of the 1990's : Research studies" N. Y. Oxford University Studies Press, 221-248. [LOUC1992] P. LOUCOPOULOS. "Conceptual Modelling" in "Conceptual Modelling, Databases and CASE : A Unified Approach to Information Systems" John Wiley, 1992 [LUBA1993] M. LUBARS, C. POTTS, C. RICHTER. "A Review of the State of the Practice in Requirements Modeling" Proc. Int. Symposium on Requirements Engineering, 1993. [SISA1999]

S. SI-SAÏD. "Proposition pour la modélisation et le guidage des processus d’analyse des systèmes d’information" Thèse de doctorat, Université Paris-1 La Sorbonne, Février 1999.

[SONG1994] X. SONG, L. J. OSTERWEIL. "Engineering software design processes to guide process execution" Proc. 3rd International Conference on the Software Process, Reston, VA, Oct. 1994, pp. 135-152 [WINK1993] J. D. WINKOOP, N. L. RUSSO. "System Development Methodologies: unanswered questions and the research-practice gap" Proceedings of 14th ICIS, (eds. J. I DeGros, R.P Bostrom, D. Robey), Orlando, USA, 1993, pp. 181-190.

Page 16