165

8 MCT, ATTENTES ET DCLENCHEMENTS

MULTIPLES

Le principe nonc la fin du chapitre prcdent, une occurrence dun message ne peut dclencher quune seule occurrence dune seule opration conceptuelle, ne doit souffrir aucune exception sous peine de confusion entre dclenchement et exploitation de la mmoire, entre organisationnel et conceptuel (avec des redondances caches, donc non gres, et au bout du compte un systme incohrent). Respecter ce principe ne pose le plus souvent pas de problme, parce que lopration conceptuelle dcrit une partie dactivit o les occurrences des messages, entrants et sortants, sont en rapport de un un. Les informations apportes par le message entrant, jointes celles consultables dans la mmoire collective, et la capacit de production1 dinformations du domaine, suffisent dcrire les informations des messages sortants. Le rapport de cause effet, entre loccurrence du message dclenchant et les rsultats, est alors clairement tabli, et le schma de lopration conceptuelle qui le dcrit, coule de source. En revanche, les cas o les messages entrants et sortants du domaine sont dans un rapport de un plusieurs, de plusieurs un, ou de zro un, posent des problmes. Les modles de communication et de donnes permettent de leur apporter une solution. Cependant, les contraintes dune description stricte des traitements conceptuels permettent parfois de constater que la description des choix de gestion faite dans les premiers modles, manque de prcision. Il faut alors modifier en consquence le modle de communication, reporter ces changements sur le modle de donnes, pour enfin dcrire une opration conceptuelle claire, et cohrente avec le reste du modle, et avec le modle de donnes. Cest donc en se reposant la question de la communication conceptuelle, que nous allons tudier les principaux problmes auxquels il arrive dtre confront. Ils sont de trois ordres : une occurrence dun message sortant se rfre plusieurs occurrences dun message entrant ; plusieurs occurrences dun message sortant se rfrent une mme occurrence dun message entrant, sans tre mises par la mme occurrence de lopration conceptuelle (il ny a aucun problme si

Par observation (des flux de matire), rgulation et dcision.

166

toutes les occurrences du rsultat sont mises par la mme occurrence du traitement) ; une occurrence dun message sortant doit tre mise parce quaucune occurrence dun message entrant na t constate.

Le premier cas est une attente conceptuelle2 ; nous en avons bauch les deux solutions au chapitre prcdent (dclenchement par dcision ou par chance). Le deuxime cas correspond une ncessit de dclencher le traitement plusieurs fois. Quant au troisime cas, faire un vnement 3 du message dont il faut constater labsence, serait pour le moins paradoxal ! Avant daborder ltude des solutions possibles, sur des exemples, il convient de rappeler quil sagit dun traitement conceptuel et non pas organisationnel. Il doit permettre une description unique de la production des informations, et de la gestion de la mmoire. Aussi, le dclenchement du traitement conceptuel est-il unique : il dcrit le cas le plus gnral. La description des cas particuliers relve des modles organisationnels : ils utilisent des descriptions redondantes mais cohrentes, parce quelles se rfrent la mme description conceptuelle.

8.1 Description du schma de base de nos exemples

Tous nos exemples sont issus dun mme schma (partiel) de Modle Conceptuel de Communication : il est dcrit par la figure 8-1 (MCC cas gnral). Les diffrences entre les exemples se font laide des descriptions fines4 des messages Commande, Bon de livraison et Facture. Nous utilisons tantt des regroupements, tantt des rfrences simples. Cependant, mme avec des descriptions de regroupements identiques, les choix de gestion associs peuvent tre diffrents ; cest la description du message Demande de facturation qui en rend compte (le nom en est alors modifi, pour tre plus explicite). Les deux derniers exemples utilisent dautres messages qui sont alors dcrits.

2 3 4

Cf. 7.4.3.5.1 Attente conceptuelle. Ce quon trouve parfois dans des schmas qui utilisent mal le concept de synchronisation. Nous en donnons des descriptions simplifies pour nous concentrer sur notre propos.

167
Commande Bon de livraison CLIENT Bon de livraison valid Facture VENDRE Commande valide STOCKER LIVRER Demande de facturation FACTURER

Figure 8-1 : MCC cas gnral

Tous ces exemples dcrivent les finalits opratoires, et les choix de gestion noncs dans les trois paragraphes suivants.

8.1.1 Vendre
Lactivit de Vendre consiste rceptionner la Commande et, aprs lavoir vrifie, par rapport aux contraintes commerciales, la mmoriser. La Commande valide est en rapport un pour un avec la Commande (message externe). Donc Commande est obligatoirement le message dclenchant dune opration conceptuelle dont Commande valide est le rsultat. Dans les exemples o Commande valide dclenche une opration conceptuelle de Stocker livrer, alors ce message dclenchant se rduit un seul identifiant : le N Commande.

8.1.2 Stocker livrer

Stocker livrer compare la Commande aux stocks, calcule et met le Bon de livraison et rceptionne le Bon de livraison valid. Nous ne nous intressons ni la confrontation de la Commande aux stocks, ni la rception5 du Bon de livraison valid, pour mieux nous concentrer sur notre problme de dclenchement des traitements ; nous nen donnons donc que des vues externes et des listes dactions partielles. Dans tous les cas, nous considrons que Bon de livraison et Bon de livraison valid sont en rapport un pour un, excluant donc les problmes de retour de marchandise a posteriori.

8.1.3 Facturer
5

Vrification des informations fournies par le partenaire, observation dun ventuel flux de matire, dcision

168

Facturer, en partant de lvnement dclenchant (qui change dun exemple lautre), consulte la mmoire pour y retrouver les informations dont il a besoin, et met une ou plusieurs occurrences de Facture. Nous navons pas reprsent les messages changs par les domaines Facturer et Vendre, pour ne pas compliquer le schma : ils ne sont pas dclenchants, et sont donc remplacs, dans le Modle Conceptuel de Traitements, par des actions de consultation de la mmoire. Ici aussi, nous limitons la liste des actions celles qui dcrivent comment lvnement dclenchant permet dexploiter la mmoire.

8.2 Attente conceptuelle

Nous parlons dattente conceptuelle, quand une opration conceptuelle doit traiter ensemble plusieurs occurrences dun message reu par le domaine (dont lopration conceptuelle contribue dcrire lactivit). Une occurrence de ce message ne peut donc pas servir de dclenchement lopration conceptuelle. Il faut utiliser une autre solution, pour autoriser le traitement commun de plusieurs occurrences du message. Nous proposons quatre choix de gestion, qui ncessitent des solutions diffrentes.

8.2.1 Gestion de lattente par une chance

Considrons le Bon de livraison suivant : Nom du message Information Bon de livraison N BL N client etc. Date de livraison n* N Commande Etc.

Ce message indique quune occurrence de Bon de livraison concerne plusieurs occurrences de Commande, quil faut donc pouvoir retrouver dans la mmoire. Ces occurrences doivent avoir quelque chose en commun ; le mme Numro de client est indispensable, mais ne peut suffire. Le recours une chance est la solution normale. On pourrait aussi imaginer un dclenchement sur dcision, mais dans le cas prsent, ce ne serait probablement pas un choix de gestion judicieux. Cette chance ncessite un lien de lentit-type Commande avec une entit-type qui dcrive un vnement temporel. Cest le rle de lassociation-

169

type6 Date de livraison demande du schma de la figure 8-2 (une seule livraison regroupant plusieurs commandes). Nous considrons que cette date est dfinie par lacteur-partenaire (cest donc une donne du message Commande), et quil ny en a quune par commande7.
Client
N Cient 0,n Livr 1,1 N BL Date de livraison 1,n Rassembler 0,n Passer 1,1 0,1

Commande
N Commande 1,1 Date de livraison demande 0,n

Bon de livraison

Date
Date

Figure 8-2 : une seule livraison regroupant plusieurs commandes

Remarque. Date de livraison demande et Date de livraison ne sont pas des informations8 redondantes : la premire est une information reue de lacteurpartenaire Client dans le message Commande ; la seconde est une information observe par le systme. Thoriquement, leurs valeurs devraient tre gales, mais ne pas prvoir deux informations distinctes serait ignorer tous les alas qui peuvent entraner une diffrence entre la date reue et la date observe. La description schmatique de lopration conceptuelle Calcul Bon de livraison est donne par la figure 8-3 (livraison de plusieurs commandes la fois).
6

Date de livraison demande ne peut pas tre modlise par une proprit de Commande. Il ny a quune seule proprit qui permette daccder une entit-type : son identifiant. Faire de cette date un identifiant empcherait de livrer plus dune commande par jour (et ne rsoudrait en rien le problme de lattente conceptuelle) !
7

Nous traitons aussi ( 8.3.1 Dclenchements multiples par chances) le cas rciproque o une commande prvoit plusieurs dates de livraisons (au lieu de un bon de livraison regroupe plusieurs commandes ) ; on pourrait imaginer la conjugaison des deux, qui ne pose pas de problme de dclenchement, puisque la solution est la mme dans les deux cas : le recours un dclenchement par chance. En revanche, les actions de consultations de la mmoire aprs le premier accs devraient runir celles des deux exemples traits.
8

Nous avons bien crit informations , et non pas proprits , parce que Date de livraison demande est le nom de lassociation-type et non pas celui dune proprit porte (ce qui ne serait pas possible : lassociation-type est fonctionnelle !).

170
Date de livraison demande Calcul bon de livraison Consulter n fois Commande {valide, livre} Consulter Client Crer Bon de Livraison {livr} Bon de livraison CLIENT

Figure 8-3 : livraison de plusieurs commandes la fois

Quant sa description fine, elle commence ainsi : Nom opration Dclenchement Rsultat 9 Actions Calcul bon de livraison Echance Bon de livraison A Consulter n fois Commande, via Date de livraison demande [Date = date du jour] B Pour chaque Commande de A, consulter Client via Passer, etc. C Pour chaque occurrence de Client de B, crer une occurrence de Bon de Livraison, une occurrence de Livr , et une occurrence de Rassembler avec chacune des occurrences de Commande de A, relies loccurrence de Client par Passer. Etc. Z Emettre une occurrence de Bon de livraison [pour chaque Client de B].

Au niveau conceptuel, on ne sintresse quau cas gnral : plusieurs commandes dun mme client doivent tre livres ensemble (le mme jour). Le dclenchement par chance le dcrit bien, et rsout le problme de lattente conceptuelle. Au niveau organisationnel, les diffrentes faons dorganiser le systme permettent de dcrire aussi bien ce cas gnral, que de donner des solutions adaptes aux cas particulier (par exemple une commande urgente livrer sans attendre). Nous reprenons cet exemple au paragraphe 14.4 (Organisation des cas particuliers).

En labsence de description des choix de gestion sur la confrontation des commandes et des stocks, nous ne dcrivons pas de condition dmission.

171

8.2.2 Gestion de lattente par lopration conceptuelle mettrice

Nous nous plaons dans le cadre dun choix de gestion o une occurrence de Commande provoque plusieurs occurrences de Bon de livraison, sans nous soucier de dcrire ce choix davantage10 (parce que cest sans influence sur le problme qui nous intresse). Considrons alors le message Facture : Nom du message Information Facture N Facture N Client etc. N Commande n* N Bon de livraison Etc.

Ce message indique quune occurrence de Facture concerne plusieurs occurrences de Bon de livraison, toutes rattaches la mme occurrence de Commande. Il suppose que nous avons fait un deuxime choix de gestion : un Bon de livraison ne concerne quune seule Commande11. Mais ce message ne suffit pas pour dfinir le rapport inverse (de Commande Facture) : y a-t-il une seule occurrence de Facture pour une occurrence de Commande (mise au retour du dernier Bon de livraison valid) ou bien plusieurs ? Et dans ce dernier cas, quest-ce qui permet de runir une partie seulement des bons de livraisons valids sur une seule facture ? Nous allons noncer trois choix de gestion successifs, et voir comment on peut les dcrire au moyen des modles conceptuels. 8.2.2.1 Choix de gestion N1 : La commande ne donne lieu qu une seule facture Pour dcrire ce choix, le message Demande de facturation est renomm Commande facturer ; sa description fine commence ainsi :

10

Ce pourrait tre parce que la commande demande des livraisons successives (cas dj voqu et qui sera trait plus loin), ou tre livre des adresses diffrentes ; ou bien cause dun problme de stocks, etc.
11

En fait, on peut parfaitement concevoir un choix de gestion o bons de livraison et commandes seraient dans un rapport de plusieurs plusieurs, et o dans le mme temps, une facture ne concernerait quune seule commande (conditions commerciales particulires). Il faudrait alors dfinir les notions de lignes (de commande, de bon de livraison, de facture), et les rapports qui les uniraient. Plus que jamais, une description de ce choix laide de messages simposerait, pour en dduire des modles de donnes et de traitements cohrents.

172

Commande facturer N Client etc. N Commande n* N Bon de livraison Etc. On pourrait croire que cest le mme message que la Facture prcdente, mais cest seulement parce quil nest pas complet. On y constaterait sinon une Quantit accepte la place de Quantit facture et labsence dinformations financires prix, taux de taxes, taux de remises ventuelles
Client
N Cient 0,n Passer 1,1 0,1 Concerner 1,1

Nom du message Information

Commande
N Commande 0,n Dtailler 1,1

Facture
N Facture

Bon de livraison
N BL Date de livraison

Figure 8-4 : MCD une commande livre en plusieurs fois, facture en une seule

Le schma du Modle Conceptuel de Donnes est dcrit par la figure 84 (MCD une commande livre en plusieurs fois, facture en une seule) ; si on le compare celui de la figure 8-2 (une seule livraison regroupant plusieurs commandes), on constate plusieurs diffrences. Les associations-types Dtailler et Rassembler, qui relient les mmes entits-types, nont pas les mmes cardinalits. Il ny a plus dassociation-type entre Bon de Livraison et Client : elle est inutile parce que le produit de composition des associations-types Dtailler et Passer est fonctionnel (ce qui ntait pas le cas du produit RassemblerPasser). Une association-type comme Livr serait alors redondante. Il ny a pas dassociation-type entre Facture et Bon de livraison : la Facture concernant tous les Bons de livraisons de la Commande, cette association-type serait redondante avec le produit DtaillerConcerner. Le message Commande facturer nest pas traduit par une entit-type : message dclenchant, il se rduit un unique identifiant qui est N Commande. Si donc on reprsentait le message par une entit-type autonome, il aurait le mme identifiant

Si une opration conceptuelle met comme rsultat un message interne dclenchant, il se rduit un identifiant. Si lmission de ce message est

173

rgule (et non pas dcide), alors cet identifiant est celui dune entit-type consulte ou mise jour12 par lopration conceptuelle. Si un message interne est le rsultat dune rgulation, alors il nest pas dcrit par une entit-type (autonome), mme sil est dclenchant. Le schma des oprations conceptuelles correspondantes est dcrit par la figure 8-5 (MCT une commande livre en plusieurs fois, facture en une seule).
CLIENT Bon de livraison valid Retour de bon de livraison Consulter Bon de livraison {livr, valid} Consulter Commande et n fois Bon de Livraison Si tous valids : Commande {livre, facturer} Si tous Bons de Livraisons rentrs Commande facturer Facturation Consulter Commande { facturer, facture} Consulter n fois Bon de livraison Etc. Toujours Facture

Figure 8-5 : MCT une commande livre en plusieurs fois, facture en une seule

On voit que lopration conceptuelle Facturation est dclenche par un message (qui se rduit N de Commande) : cest lopration conceptuelle mettrice, Retour de Bon de livraison, qui gre lattente, laide dune rgle, en exploitant la mmorisation des vnements antrieurs. Lopration conceptuelle Facturation ne prsentant aucun problme (nous ne regardons que ceux lis aux dclenchements), nous nous passons ici de sa description fine. En revanche, lexploitation de la mmoire par lautre opration conceptuelle mrite dtre au moins partiellement dtaille : Nom opration Dclenchement Rsultat Condition Retour bon de livraison Bon de livraison valid Facture Tous les bons de livraisons de la facture valids

12

Dans ce cas, cette entit-type dcrit le message dclenchant de lopration conceptuelle.

174

Actions

A Consulter Bon de livraison, via N Bon livraison [du message] B Mettre jour Date retour = date du jour C Consulter et mettre jour n fois Produit13, etc. D Consulter une fois Commande via Dtailler E partir de la Commande de D, consulter n fois Bon de livraison via Dtailler F Si pour une occurrence de Bon de livraison de E, Date retour nest pas renseigne, alors STOP G Sinon mettre Commande facturer [= N Commande]

Cest la double exploitation de Dtailler, depuis Bon de livraison vers Commande, puis depuis Commande vers Bon de livraison, qui permet de grer lattente conceptuelle. Chaque occurrence de Bon de livraison valid dclenche une occurrence de lopration conceptuelle ; seule la dernire, en exploitant une rgle, met le rsultat qui dclenche lopration conceptuelle Facturation. 8.2.2.2 Choix de gestion N 2 : la facturation est dcide par Stocker livrer Le dclenchement rgul de la facturation (seulement aprs le retour du dernier Bon de livraison) peut poser des problmes lorganisme dcrit. Aussi peut-on prfrer un choix de gestion o ce dclenchement pourra se faire par dcision, tout en laissant la gestion de lattente au domaine Stocker (en fonction de la connaissance des flux de matire). Cest le domaine Stocker livrer qui dcide de dclencher la facturation, si un ou plusieurs bons de livraison ont des dlais de retour trop importants. Considrons alors les regroupements des occurrences de Bon de livraison dans les messages Commande facturer (choix N 1), et Demande de facturation (choix N 2). Nom du message Information Demande de facturation N de demande de facturation N Commande n* N BL etc.

Dans le choix de gestion N 1, le message Commande facturer communique au domaine Facturer la liste de toutes les occurrences de Bon de Livraison, correspondant une occurrence de Commande. Il se contente donc

13

Nous ne nous attardons pas sur ces actions qui concernent des entits que nous navons pas dcrites mais il nest pas inutile den rappeler lexistence.

175

de reprendre une information dj dcrite14, au moins implicitement, au moment de la cration des diffrentes occurrences de Bon de livraison. Le regroupement de Commande facturer ne doit pas tre mmoris de nouveau : ce serait une redondance ! Dans le choix de gestion N 2, le message ne communique quune partie des occurrences de Bon de livraison correspondant une occurrence de Commande. La liste des occurrences de Bon de livraison qui sont regroupes pour tre factures ensemble, tant nouvelle (rsultat de la dcision), elle doit tre mmorise, et avoir un identifiant : le numro du message.
Client
N Cient 0,n Passer 1,1 0,n Dtail 1 1,1

Commande
N Commande 0,n Dtail 2 1,1

Facture
N Facture 1,1 Engendrer

Bon de livraison
N BL Date de livraison Date retour 0,1

Pour

1,n

Demande de facturation
N demande facturation

0,1

Figure 8-6 : MCD facturation dcide par Stocker livrer

Le Modle Conceptuel de Donnes (Figure 8-6 : MCD facturation dcide par Stocker livrer) dcrit ce message laide dune entit-type autonome. Il ny a dassociation-type ni entre Facture et Commande ni Facture et Client, parce quelles seraient redondantes. La figure 8-7 (MCT facturation dcide par Stocker livrer) dcrit le schma des deux oprations conceptuelles (mettrice et rceptrice) concernes par le message Demande de facturation. La description fine de lopration conceptuelle Facturation ne pose pas de problme particulier. Celle de Retour de bon de livraison est : Nom opration Dclenchement Rsultat Condition Actions Retour bon de livraison Bon de livraison valid Demande de facturation Tous les bons de livraison de la commande valids, ou dcision A Consulter Bon de livraison, via N Bon livraison [du message] B Mettre jour Date retour = date du jour C Consulter et mettre jour n fois Produit, etc.

14

Elle est modlise par la cardinalit n de la patte Commande de Dtailler.

176

D Consulter une fois Commande, via Dtail 1 E partir de la Commande de D, consulter n fois Bon de livraison via Dtail 1 F Si pour une occurrence de Bon de livraison de E, Date retour nest pas renseigne et dcision de lattendre, alors STOP G Sinon (tous les BL rentrs ou dcision de ne pas les attendre), crer une occurrence de Demande de Facturation, une occurrence de Dtail 2, et une occurrence de Pour avec toute occurrence de Bon de livraison atteinte en E, telle que Date retour est renseigne et nest pas lie une occurrence de Pour15 H Emettre Demande de facturation.
STOCKER LIVRER CLIENT Bon de livraison valid Retour Bon de livraison Consulter Bon de livraison {livr, valid} Consulter Commande et n fois Bon de livraison Si tous BL {valid}, ou dcison : Bon de livraison {valid, facturer} Crer Demande de facturation { facturer} Si dcision ou si tous BL rentrs Demande de facturation Facture Facturation Consulter Demande de facturation { facturer, factur} Consulter Bon de livraison { facturer, factur} Consulter Commande et Client etc. Toujours FACTURER

Figure 8-7 : MCT facturation dcide par Stocker livrer

8.2.2.3 Choix de gestion N 2 : la facturation est dcide par Facturer

15

Dans le cas contraire, la facture correspondante a dj t mise par le systme.

177

On aurait pu imaginer de rassembler (en une seule entit-type) les deux entits-types Demande de facturation et Facture, unies par une associationtype Engendrer deux fois fonctionnelle, mais ce serait une erreur : lmission dune facture est du ressort du domaine Facturer, lidentifiant de lentit-type qui la modlise ne doit pas tre dfini par un autre domaine. Ici, cela entranerait une confusion avec le modle de la figure 8-8 (MCD facturation dcide par Facturer).
Client
N Cient 0,n Passer 1,1 0,n Dtail 1

Commande
N Commande 0,n Dtail 3 1,1

Bon de livraison
N BL Date de livraison Date retour

1,1 0,1 Assembler 1,n

Facture
N Facture

Figure 8-8 : MCD facturation dcide par Facturer

Ce modle correspond un autre choix de gestion : celui o le regroupement dune partie seulement des occurrences de Bon de livraison dune Commande sur une mme Facture, serait le rsultat dune dcision du domaine Facturer (donc sur des critres financiers, et non plus sur des critres de gestion de flux de matire). Une occurrence du message Demande de facturation ne dcrit quune seule occurrence de Bon de livraison valid ; il ne donne donc pas dentit-type autonome. Non dclenchant, il disparat du schma du Modle Conceptuel de Traitements. Le nouveau regroupement dcrit par lassociation-type Assembler tant dfini par le traitement qui met la Facture, il napparat donc pas dans un message antrieur, et nest pas dcrit par une entit-type autonome comme ctait le cas dans le choix de gestion prcdent (figure 8-6 : MCD facturation dcide par Stocker livrer).

Mais un tel choix de gestion poserait dautres problmes de dclenchement : un message Demande de facturation ne dcrivant quun seul Bon de livraison valid, permettrait certes de retrouver la description de ce Bon de livraison dans les occurrences suivantes de lopration conceptuelle Facturation, si celle quil dclenche lui-mme aboutissait une dcision de ne pas mettre de Facture. Mais ce dclenchement ne permettrait pas de relancer le traitement sans une nouvelle occurrence du message dclenchant (donc, sans le retour dun nouveau Bon de livraison).

178

Aussi, serait-il plus sage de choisir un dclenchement par dcision16, et de reporter ltude de tous les cas particuliers 17 aux modles organisationnels, chacun faisant lobjet dun contexte dorganisation. Ce dclenchement permet de dcider de la Commande examine, puis des Bons de livraison qui la concernent18. Nous ne dtaillons pas davantage lopration conceptuelle : elle ne pose pas de problme particulier.
STOCKER LIVRER CLIENT Bon de livraison valid Retour Bon de livraison Consulter Bon de livraison {livr, valid} Mettre jour

Dcision Facturation Dcider Commande {livre} Consulter n fois Bon de livraison Si tous rentrs (Commande {livre, Facture}) ou dcision : crer Facture {mise}; Bon de livraison {valid, factur} Si fin des livraisons ou Dcision Facture FACTURER

Figure 8-9 : MCD facturation dcide par Facturer

8.3 Dclenchements multiples

Une mme occurrence dun message doit tre traite par plusieurs occurrences dune opration conceptuelle (sans y tre associe dautres occurrence dudit message : il ny a pas dattente). Le principe une occurrence dun message ne peut dclencher quune seule occurrence dun seul traitement , implique que ce traitement rptitif doit tre assur par un traitement diffrent (de celui qui mmorise le message). Il y a

16 17

Le moins contraignant au niveau conceptuel.

Permettant, par exemple, un dclenchement automatique (et non plus dcisionnel) de la facturation, au retour du dernier bon de livraison valid.
18

Consulter n fois Commande, en choisir une. Consulter n fois Bon de livraison via Dtail 1, etc.

179

donc deux oprations conceptuelles, et la seconde ne peut pas tre dclenche par un message, si cest un rsultat de la premire.

8.3.1 Dclenchements multiples par chances

Dans ce cas, cest linformation dun message qui prvoit directement la rptition des occurrences du traitement. Il faut donc utiliser lun des deux autres dclenchements possibles : dcision (rarement), ou chance, le plus souvent. Prenons lexemple dune commande qui prvoit des livraisons des dates diffrentes, ce qui permet de grer les dclenchements (des livraisons) au moyen dune chance. Commande N Client etc. (N Commande) n* Date de livraison demande (N sous-commande) n* N produit Quantit commande Etc. Le N sous-commande ne sert pas de moyen daccs la mmoire (dans le calcul du bon de livraison) : cest Date de livraison demande quest dvolu ce rle. Mais cette date ne peut pas servir didentifiant lentit-type qui dcrit le regroupement, parce que cela interdirait plusieurs occurrences de Commande de demander des livraisons la mme date19.
Client
N Cient 0,n Passer 1,1

Nom du message Information

Date de livraison demande 0,n 1,1

N BL N Commande Date de livraison 1,n 1,1 De Concerner Produit N produit 1,1 0,1 1,n 0,n Ligne commande Quantit commande

Commande

Bon de livraison

Date
Date

Sous-commande
N sous-commande

Figure 8-10 : MCD une commande, plusieurs livraisons des dates diffrentes

Le schma du Modle Conceptuel de Donnes correspondant, est donn par la figure 8-10 (MCD une commande, plusieurs livraisons des dates

19

Remarquons toutefois que ce serait possible en utilisant un identifiant relatif (Cf. 9.3 Identifiant relatif).

180

diffrentes) et celui du Modle Conceptuel de Traitements, par la figure 8-11 (MCT une commande, plusieurs livraisons des dates diffrentes). Sans le numro de sous-commande, on aurait certes pu reprsenter les deux regroupements imbriqus du message Commande, par une association-type ternaire20 reliant Commande, Produit et Date. Le Bon de livraison serait alors li Commande par une association-type binaire fonctionnelle, et Produit par une autre association-type binaire non fonctionnelle. Mais montrer dans le Modle Conceptuel de Donnes quune occurrence de Bon de livraison ne regroupe que des produits devant tre livrs la mme date, serait alors trs dlicat.
CLIENT Commande Saisie commande Crer Commande {valide} Creer n occurrences de Sous-commande {valide} Bon de livraison Date de livraison Calcul Bon de livraison Consulter Sous-commande {valide, livre} via date de livraison demande Crer Bon de livraison {livr} Toujours

Figure 8-11 : MCT une commande, plusieurs livraisons des dates diffrentes

8.3.2 Dclenchements multiples par un vnement annexe

Considrons le choix de gestion suivant : une commande ne peut tre livre que si la situation comptable du client est satisfaisante. 8.3.2.1 Construction du Modle Conceptuel de Communication Pour dcrire ce nouveau choix de gestion, il faut sensiblement modifier le schma du Modle Conceptuel de Communication de la figure 8-2 (MCC cas gnral). Une premire tentative de modification est dcrite par la figure 8-12 (Commande en attente de rglement 1er essai). Pour le domaine Administrer, nous ne nous intressons pas la description fine du traitement transformant la Commande valide en Commande livrer : nous considrons seulement que le domaine consulte les factures et rglements du client, pour tablir un bilan. Si ce bilan est satisfaisant, le domaine autorise
20

Cf. 6.3.2 Des rfrences deux messages antrieurs (non lis) dans des regroupements imbriqus.

181

la livraison (application dune rgle si le compte du client est jour, et ventuellement dune dcision, si le dficit nest pas trop lev) ; sinon, il place la commande en attente dun rglement du client (rglement dune facture antrieure bien entendu). La commande tant dj mmorise21 (par Vendre), le seul problme consiste dclencher nouveau le traitement, larrive dun rglement du client22. Le fait que le rapport entre le message sortant (Commande livrer), et les occurrences du message entrant (Rglement dune facture antrieure) napparaisse pas23 dans le Modle Conceptuel de Donnes, ne change en rien la nature du problme.
Commande VENDRE Commande valide Commande livrer Demande de facturation Commande en attente de rglement ADMINISTRER

Bon de livraison CLIENT STOCKER LIVRER Bon de livraison valid Facture

Rglement

Figure 8-12 : Commande en attente de rglement 1er essai

Le message Commande valide est un message dclenchant, dune opration conceptuelle qui doit mettre, soit un message Commande livrer, soit un message Commande en attente de rglement. Le message Rglement opration conceptuelle qui autoriser un nouvel examen du rglement (c'est--dire Commande valide). est galement un message dclenchant, dune doit mmoriser la description du rglement, et des ventuelles commandes en attente de lauteur le mme traitement que celui dclench par

Lautorisation de livrer, ou non, relve dune dcision ; elle ne peut donc pas tre faite par deux oprations conceptuelles diffrentes car elles seraient redondantes24. Cette opration doit donc tre dclenche par un rsultat de la
21

Il faut deux oprations conceptuelles diffrentes, car une occurrence de Commande ne peut tre traite quune seule fois par Vendre, et plusieurs fois par Administrer.
22

Rappelons une fois de plus que le bien-fond des choix de gestion ne nous intresse pas ; seule compte lutilisation des outils des modles conceptuels pour les dcrire convenablement.
23 24

Il ny a pas de rfrence au rglement dans le message Commande livrer.

Sil sagissait dune rgulation, on pourrait le faire, parce que la rgle ayant t dcrite avant la construction du Modle Conceptuel de Traitements, elle peut tre applique sans risque

182

saisie dun rglement. Il faut donc un message entre les deux traitements (lun dclenchant lautre), ce qui implique deux domaines diffrents (un domaine ne senvoie pas de message lui-mme). Nous devons donc modifier le Modle Conceptuel de Communication pour dcomposer le domaine Administrer en deux sous-domaines, puis dcrire un concept qui permette de dclencher lautorisation de livraison par un message mis soit par Vendre, soit par lun des deux sous-domaines. Ce nouveau concept, cest la fusion de messages internes dclenchants. Il ressemble une synchronisation, mais dans des conditions si restrictives quil nen a pas les inconvnients. 8.3.2.2 Dcomposition dun domaine en sous-domaines Pour la part de son activit qui nous concerne, la finalit opratoire du domaine Administrer peut tre dcrite par deux finalits opratoires secondaires (et complmentaires) : Comptabiliser et Grer les attentes. Elles dfinissent deux sous-domaines : Administrer doit mettre les factures et rceptionner les rglements. Grer les attentes doit contrler la situation de lmetteur dune commande, et dcider ou non dautoriser la livraison.

Le partage de lactivit du domaine Administrer, va permettre de dcrire de nouveaux messages, dont celui qui doit permettre de dclencher un nouvel examen dune commande. Chacun des deux sous-domaines met et reoit une partie des messages mis ou reus par le domaine Administrer (dont ils contribuent dcrire lactivit).
ADMINISTRER Commande valide Demande de facturation COMPTABILISER Rglement Facture GERER ATTENTES Commande livrer

Figure 8-13 : partition des messages du domaine Administrer

Ainsi que le montre la figure 8-13 (partition des messages du domaine Administrer), les activits dcrites par ces seuls messages sont disjointes, donc non cohrentes. Pour que ce ne soit plus le cas, il faut que les deux sousdomaines se dcrivent mutuellement leurs activits (lun contrle lautre, et rciproquement). Cest le rle des messages Compte client, Commande en
dincohrence par plusieurs traitements, de plusieurs domaines.

183

attente et Commande retraiter, de la figure 8-14 (MCC aprs dcomposition du domaine Administrer). Le message Compte client regroupe, pour un N de client, lensemble des occurrences de Facture et lensemble de celles de Rglement qui le concernent. Cest une information obtenue par rgulation, partir des informations produites antrieurement par le sous-domaine. Ce message nest pas dclenchant, et ne comporte aucune information nouvelle non rgule ; il nest donc dcrit ni dans le Modle Conceptuel de Donnes, ni dans le Modle Conceptuel de Traitements (il y est remplac par des actions de consultation de la mmoire par le sous-domaine Grer attentes). Commande en attente, Commande en attente de rglement et Commande retraiter reprennent la description dune Commande ; la seule information nouvelle (et qui doit donc tre mmorise) est la dcision de placer une commande en attente.
VENDRE Commande valide Commande livrer Commande STOCKER LIVRER Bon de livraison valid Bon de livraison Demande de facturation Facture CLIENT Rglement Commande en attente de rglement GERER ATTENTES Commande en attente Compte client Commande retraiter COMPTABILISER

Figure 8-14 : MCC aprs dcomposition du domaine Administrer

8.3.2.3 Modle Conceptuel de Donnes Comment modliser la mmorisation de cette dcision de placer une commande en attente ? On pourrait penser utiliser une proprit non toujours renseigne de lentit-type Commande, mais ce ne serait pas un moyen daccs, dans un modle conceptuel. Or il faut, quand un client a envoy un rglement, retrouver les commandes en attente pour, ventuellement en autoriser la livraison. Il sagit l dune partie de lactivit de Comptabiliser, qui doit mettre le message Commande retraiter, partir dun message Rglement (qui se rfre au client). Donc le N

184

client doit permettre de consulter le N commande dune occurrence mise en attente. Cest une association-type binaire qui le permet : nous la nommons En attente, comme dans la figure 8-15 (MCD commande en attente). Elle est cre par lopration conceptuelle Autorisation de rglement, et supprime par Saisie rglement. On a donc deux associations-types entre les mmes entits-types ; cela ne pose aucun problme, pourvu que leurs significations soient bien diffrentes.

Client
N Cient 0,n Pay 1,1

0,n 0,n

Passe 1,1 En attente 0,1

Bon de livraison
N BL 1,1

Commande
N Commande 0,1

0,1

Livr

Rglement
N rglement

1,n

Rpartition Facture 0,n 1,1 Montant rgl N Facture

Concerner

Figure 8-15 : MCD commande en attente

On a considr que Facture et Rglement sont en rapport de n n, ce qui implique lexistence de lassociation-type Rpartition, pour pouvoir exploiter la mmoire (des proprits de Facture et de Rglement seraient insuffisantes). Montant rgl est une donne du regroupement du message Rglement25. 8.3.2.4 Construction du Modle Conceptuel de Traitements Les activits des domaines Vendre et Stocker livrer ne posent aucun problme que nous nayons tudi ; nous ne les dcrivons donc pas. Lactivit du domaine Administrer est plus complique. Il sagit de recevoir les messages Commande valide, Demande de facturation et Rglement, et dmettre les messages Commande retraiter, Commande en attente de rglement, Commande livrer et Facture. Trois oprations conceptuelles sont ncessaires : deux correspondent lactivit du sous-domaine Comptabiliser, et la troisime celle du sous-domaine Grer attentes. Toutes sont dclenches par des messages dclenchants : Facturation, dclenche par Demande de facturation, a pour rsultat Facture ;

25

Le Modle Organisationnel de Traitements dcrit comment reconstituer cette information, si elle manque dans le document mis par le client ; mais dans lapproche conceptuelle, on considre que le message est exact (Cf. 7.4.3.1.3).

185

Saisie rglement, dclenche par Rglement, a pour rsultat Commande retraiter ; Autorisation de livraison, dclenche par Commande valide ou bien par Commande retraiter, a pour rsultat Commande livrer.
Fusion de messages dclenchants

8.3.2.4.1

Les deux premires oprations conceptuelles ne posent pas de problme de dclenchement. En revanche, la troisime opration conceptuelle, Autorisation de livraison, pose un problme nouveau : il faut pouvoir la dclencher par deux messages diffrents, ce quoi nous avons renonc en abandonnant le concept de synchronisation. Mais il faut y regarder de plus prs : Commande valide est un message dclenchant interne qui se rduit donc un unique identifiant, celui de Commande ; Commande retraiter est galement un message dclenchant interne qui se rduit, lui aussi, un seul identifiant, celui de Commande.

Donc nos deux messages dclenchants ont exactement le mme contenu : lidentifiant N Commande, qui doit servir de moyen daccs la mmoire, pour y consulter les autres informations ncessaires au traitement. Nous pouvons fusionner ces deux messages internes dclenchants pour nen faire quun, parce que lactivit dcrite sera exactement la mme, quel que soit lmetteur (Vendre ou Comptabiliser). Sur le schma de la figure 8-16 (Modle Conceptuel de Traitements du domaine Administrer, dcompos en deux sous-domaines Facturer et Grer attente), ils deviennent Commande valide, commande retraiter, message dclenchant fusionn qui a donc deux metteurs et un rcepteur26.

26

Un message ne peut avoir deux metteurs que dans cet unique cas : la fusion de deux messages du Modle Conceptuel de Communication, en un message dclenchant du Modle Conceptuel de Traitements.

186
STOCKER LIVRER Demande de facturation Facturation Consulter Commande { facturer, facture} Facture Rglement VENDRE Saisie rglement Crer Rglement etc. Consulter Client Consulter n fois Commande {en attente, valide} Si commande en attente FACTURER Commande valide, retraiter Autorisation de livraison Consulter Commande {valide} Calculer total commande (RG) et compte client (RG) Si compte ok ou dcision : Commande {valide, livrer} sinon : Commande {valide, en attente} Si bilan correct Si bilan incorrect GERER ATTENTES Commande livrer Commande en attente de rglement CLIENT

Figure 8-16 : Modle Conceptuel de Traitements du domaine Administrer, dcompos en deux sous-domaines Facturer et Grer attente

Il faut bien diffrencier cette fusion dune synchronisation avec la condition OU, qui autoriserait des vnements dcrits par des informations diffrentes, induisant donc des actions diffrentes. Cette fusion, elle, implique quil sagit de messages internes rduits un seul identifiant, le mme dans chacun des messages fusionns. Le traitement est donc exactement le mme quel que soit lmetteur ! Il ny a que dans ce cas quon peut faire fusionner deux messages. La description fine de Facturation ne pose pas de problme nouveau ; nous nous en dispensons. Et nous rduisons la description fine des deux autres oprations conceptuelles, aux seules actions qui permettent de grer la mise en attente dune commande et son retraitement. Nom opration Dclenchement Autorisation de livraison Commande valide, commande retraiter

187

Rsultat 1 Condition 1 Rsultat 2 Condition 2 Actions

Commande livrer Si bilan correct Commande en attente de rglement Si bilan incorrect A Consulter Commande, via N Commande (reu) B Consulter n fois Produit etc. Calculer Total commande (Rgle) C Consulter Client, via Passe D Consulter n fois Commande, via Passe ; pour chacune, consulter Facture via Concerner, et calculer Total facture (Rgle) E Pour chaque Facture du D, consulter n fois Rglement, via Rpartition, et calculer Total pay (rgle) F Calculer Bilan comptable client partir des totaux de D et E (rgle) G Si bilan correct (Rgle ou dcision), mettre Commande livrer (N Commande de A) H Si bilan incorrect, crer une occurrence de En attente entre Commande de A et Client de C, mettre une occurrence de Commande en attente de rglement (N Commande de A, etc.).

Remarque. Si le choix de gestion veut quune commande passe automatiquement en attente, quand il y en a dj une pour le mme client, alors on peut ajouter laction C une consultation de Commande via En attente puis, si cette consultation est fructueuse, passer tout de suite laction H. En revanche, il faut bien se garder dinclure ces actions (C modifie et H) dans le traitement Saisie de commande, parce que cela aboutirait dcrire deux oprations conceptuelles qui produiraient la mme information (mise jour de En attente) : cest interdit dans un modle conceptuel (non redondant). Nom opration Dclenchement Rsultat Condition Actions Saisie rglement Rglement Commande valide, commande retraiter Si Commande en attente A Consulter Client via N Client (du message) B Crer une occurrence de Rglement et une occurrence de Pay C Consulter n fois Facture via N Facture (du message) D Pour chaque Facture de C, crer une occurrence de Rpartition, Montant rgl = donne du message

188

E A partir de Client, consulter n fois Commande via En attente F Pour chaque Commande de E, supprimer En attente et mettre Commande valide, Commande retraiter (N Commande)27 Laction E prsente une nouvelle forme daction de mise jour : la suppression. A vrai dire, elle est assez rare dans un modle vraiment conceptuel, parce que la dure de vie dune information en mmoire est en principe un problme dorganisation et non pas de smantique. Mais dans le cas o une information (association-type en loccurrence) mmorise une possibilit de traitement voue disparatre, alors sa suppression est lgitime. Nous en verrons un autre cas dans la description fine de la gestion des relances (exemple suivant).

8.4 Echance et absence de message

Tous les exemples prcdents sintressaient des cas o lon constatait des rapports de un plusieurs entre les occurrences de messages entrants et sortants dun domaine. Il y a un autre cas o lon ne peut dcrire un traitement dclench par un message, et produisant en une seule fois toutes les occurrences du rsultat, cest celui o le traitement doit constater labsence dun message qui aurait d arriver, et qui ne saurait donc tre le dclencheur de ce traitement. Le rsultat est donc labor partir de la mmoire, de rgles, et dventuelles dcisions du systme. La seule possibilit de dclencher l'opration conceptuelle, est alors de recourir une dcision du pilote ou une chance. Nous ne donnons un exemple que pour cette dernire ; lautre ne pose aucun problme : on peut dcider, donc on na pas de problme daccs la mmoire. Supposons que lon veuille envoyer une relance un client, si son rglement nest pas parvenu (ou sil tait insuffisant) au bout dun laps de temps prdfini. Cette information (la date butoir28) est alors transmise dans le message Facture, et mmorise au moyen dune association-type : Echance facture, comme le montre le Modle Conceptuel de Donnes de la figure 8-17 (MCD chance pour constater labsence de message).
27

Lopration conceptuelle ne doit pas faire elle-mme lexamen du compte (pour nmettre le message que si la commande peut effectivement tre honore). Sinon on aurait deux descriptions du mme traitement de production dune information (mise en attente).
28

Ou le dlai coul, cela revient au mme : on calcule lun partir de lautre et de la date de facturation.

189

Cette association-type permet le dclenchement par chance, donc lmission dun message Relance qui reprend les informations de Facture et la date denvoi de la relance, qui peut tre diffrente de la date dchance (respect dun dlai dacheminement). Si on ne prvoit quune seule relance, alors cette date de relance peut tre une proprit (non renseigne au dpart) de Facture, comme cest le cas de la figure 8-17 (MCD chance pour constater labsence de message). Si on choisissait de faire jusqu trois relances (Premier rappel, Deuxime rappel, Dernier avis avant saisie), alors chacune delles serait dcrite dans le Modle Conceptuel de Communication par un message diffrent (ils nont pas le mme sens), puis reprsente dans le Modle Conceptuel de Donnes par une entit-type. Chacune de ces trois entits-types serait relie Facture, par une association-type deux fois fonctionnelle, et Date, par une association-type semblable Echance Facture ce qui entranerait des actions ad hoc. Enfin, si on prvoyait un nombre variable de relances29, alors Echance facture deviendrait une association-type non fonctionnelle, porteuse dune proprit (Date de relance) non toujours renseigne.
Facture
N Facture Date relance 0,1 Echance facture 0,n 0,n Rpartition Montant rgl 1,n

Rglement
N Rglement

Date
Date

Figure 8-17 : MCD chance pour constater labsence de message

La cration dune occurrence de Echance facture est faite par lopration conceptuelle Facturation, comme dans la figure 8-18 (MCT chance pour constater labsence de message). Ensuite, cette association-type est consulte lors du dclenchement de lopration conceptuelle Etablissement relance : sa premire action scrit Consulter Facture via Echance facture (Date = date du jour - x) . La rgle30 est destine prvoir les dlais dacheminement. Notons dans cette opration conceptuelle une action de dcision : une rgle trop stricte provoque des effets ridicules quun choix de gestion sens ne saurait admettre.

29 30

A opposer un nombre fixe de relances individualises, comme dans le choix prcdent. Date du jour - x .

190

Enfin, lassociation-type est supprime lorsque le total rgl (par un ou plusieurs paiements) est gal au montant de la facture. Une action Supprimer est donc dcrite dans lopration conceptuelle Saisie rglement. Cest cette action de suppression qui justifie la cardinalit minimale 0 sur la patte Facture de Echance facture, cardinalit inhabituelle puisque laction de cration systmatique de lassociation-type dans lopration conceptuelle Facturation, sous-entend en principe une cardinalit minimale gale 1. Mais il ne faut pas oublier que le Modle Conceptuel de Donnes est une synthse. Ici la vue externe de lopration conceptuelle Facturation pourrait utiliser une contrainte plus stricte : 1 au lieu de 0.
STOCKER LIVRER
Dem ande de facturation

Date chance

Emission relance Facturation Crer Facture {mise} Crer Echance facture Toujours
Rglem ent

Consulter Facture {mise} via chance Consulter n fois Rglement et calculer total d Dcider de relancer ou pas Si dcision
Relance

Saisie rglement Crer Rglement Consulter n fois Facture {mise} Calculer montant Facture et total rgl Si galit supprimer Echance facture Facture {mise, rgle}
Facture

CLIENT

Figure 8-18 : MCT chance pour constater labsence de message

Les diffrents exemples de ce chapitre montrent comment un Modle Conceptuel de Communication bien conu permet de : dcrire convenablement le dclenchement des oprations conceptuelles, sans confondre vnement et consultation de la mmoire ; construire un Modle Conceptuel convenablement la smantique induite ; de Donnes qui dcrit

191

tre certain que le Modle Conceptuel de Donnes et le Modle Conceptuel de Traitements sont cohrents.