4MODELECONCEPTUEL DECOMMUNICATION
Les premiers exemples de ce chapitre sont volontairement incomplets : les descriptions des informations y sont simplifiées, pour pouvoir illustrer le propos, sans être trop abstrait et sans anticiper sur la suite.
Le Modèle Conceptuel de Communication décrit l’activité du système en termes d’informations, et non plus par la simple existence d’un échange (nécessaire). Aussi remplace-t-il les flux d’activité, en particulier les flux concrets, par des flux d’informations qui les décrivent : les messages.
Le modèle a une double description :
• une description schématique, globale, qui montre l’existence des messages. Cette description ressemble au schéma du Modèle Conceptuel d’Activité : les intervenants sont les mêmes, mais les flèches représentent des messages, et non plus des flux d’activité.
• une description fine, par message, qui décrit les éléments du message : c'est-à-dire les données et les liens qui les regroupent.
Comme nous l’avons indiqué en introduction, notre démarche déductive fait du Modèle Conceptuel de Communication la source commune des modèles de données et de traitements :
• De la description fine du Modèle Conceptuel de Communication, on déduit le Modèle Conceptuel de Données ; c’est la description abstraite
de la mémoire collective du système, qui est elle-même la synthèse des mémoires des domaines.
• La description schématique du Modèle Conceptuel de Communication permet de construire la description schématique du Modèle Conceptuel de Traitements. La réception ou l’émission d’un message externe par un domaine, la communication d’un message entre deux domaines, sont des éléments de l’activité (complexe) de ces domaines. La nécessité de décrire ces activités partielles se traduit par l’existence d’un traitement du domaine qui reçoit ou émet le message. Le Modèle Conceptuel de Traitements est la synthèse des traitements des différents domaines.
Le concept fondamental du Modèle Conceptuel de Communication est le message : il contribue à décrire un flux d’activité. « Contribue » seulement parce que, dans le cas général, il faut au moins un message, éventuellement plusieurs, pour décrire un seul flux d’activité.
Le message est la transmission, en une seule fois, d’une information complexe et cohérente, entre un émetteur qui en dispose, et un récepteur qui en a besoin.
Une information est complexe, parce qu’elle est composée d’éléments d’informations : les données, et leurs regroupements. Une donnée a un nom, qui représente sa valeur (rappelons qu’au niveau conceptuel, une donnée doit avoir plusieurs valeurs possibles). Un regroupement décrit un lien unissant plusieurs données ; la façon dont les données sont regroupées dans un message en modifie la signification. Le regroupement n’a pas de nom autonome : c’est la présentation des données au sein du message qui le définit.
Une information complexe est cohérente, si elle n’est pas seulement une collection de données indépendantes. Le message est plus que cela. C’est en communiquant des données dans un même message, et en les y regroupant de telle ou telle façon, qu’on définit leur signification globale, qui est donc plus que l’ensemble des valeurs des données du message.
Le message est un triplet (émetteur, récepteur, information [complexe et cohérente]). L’information est elle-même décrite par une liste qui énumère les données élémentaireset les regroupements qui les unissent.
Remarque. Il est bon de noter que la description du message ne tient pas compte du support, c’est-à-dire du moyen de transmission de l’information. Cette notion de support n’est en effet pas conceptuelle mais organisationnelle. Nous la retrouverons donc dans les modèles organisationnels.
L’émetteur et le récepteur du message sont ceux du flux d’activité qu’il décrit, sauf dans le cas de la description d’un flux de sous-traitance. Ils sont donc différents l’un de l’autre. Il n’y a pas plus de boucles dans le Modèle Conceptuel de Communication, que dans le Modèle Conceptuel d’Activité : l’émetteur d’un message étant supposé disposer de l’information de ce message, il n’a pas besoin de se l’envoyer.
Le message a un nom. Comme pour les flux, on se sert d’un nom ou d’une groupe nominal pour nommer les messages. S’il n’y a besoin que d’un seul message pour décrire un flux d’activité, alors on donne au message le nom du flux.
Il s’agit de décrire un flux d’informations, Catalogue clients, émis par le domaine Vendre, pour un acteur-partenaire Client. Un catalogue, c’est une liste de produits accompagnés de leurs prix respectifs, et de la période de validité de ces prix. La période de validité est la même pour tous les produits :
dans une occurrence du message, on ne trouve qu’une occurrence de la description de la période de validité. En revanche, il y a plusieurs produits concernés ; une occurrence du message contient donc plusieurs occurrences de la description du produit et de son prix. C’est ce que montre la description du
| message : | |
| Nom du message | Catalogue clients |
| Emetteur | VENDRE |
| Récepteur | CLIENT |
| Information | N° du catalogue |
| Période de validité | |
| n * Description d’un produit | |
| Prix de vente unitaire HT |
Les données dont plusieurs occurrences peuvent être transmises par une même occurrence du message, sont rassemblées dans un regroupement qui est ici représenté par un décalage dans la liste précédé du symbole «n *». Ce symbole montre clairement le caractère répétitif du sous-ensemble de données ainsi repéré.
Mais peu importe l’outil de description. Ce qui compte, c’est de bien faire la part entre les données qui n’ont qu’une seule occurrence transmise par le message, et celles qui en ont plusieurs ; et, parmi celles-ci, celles qui ont le même nombre d’occurrences. C’est en effet un élément fondamental de la signification du message : il traduit les choix de gestion qui président à la conception du système d’information.
Pour une occurrence du message Catalogue clients, il y a une occurrence du N° du catalogue et une occurrence de la période de validité, qui sont donc en rapport un pour un. Mais pour une occurrence du N° du catalogue, il y a plusieurs occurrences de la description d’un produit : ils sont donc dans un rapport de un à n. En revanche la description du produit et son prix sont en rapport de un à un.
On remarque que la description de ce premier message, Catalogue clients, ne comporte pas de description d’une occurrence de Client : c’est parce que le catalogue est valable pour l’ensemble des clients. Considérons alors le message suivant : il reprend les informations du premier message, mais on y a ajouté une information, la description d’un client.
| Nom du message | Catalogue d’un client |
| Emetteur | VENDRE |
| Récepteur | CLIENT |
| Information | Description d’un client |
| N° du catalogue | |
| Période de validité | |
| n * Description d’un produit | |
| Prix de vente unitaire HT |
Leurs informations étant différentes, le message de l’exemple N° 2, et celui de l’exemple N° 1, ont des significations différentes. Le message de l’exemple N° 2 établit un rapport de un à un entre une occurrence du catalogue, et une occurrence de Client : il est donc dédié à un seul client, celui qui est décrit dans le message. Ce qui signifie que deux clients différents n’ont pas le même catalogue : ils peuvent être pour partie identiques (c’est un cas particulier), mais peuvent différer aussi bien pour la période de validité, la liste des produits, les prix.
Remarque. L’association de la description du client et de celle du catalogue, ne saurait décrire l’envoi, par courrier, de l’objet (catalogue) à chaque client. C’est un problème organisationnel (mailing) et non pas conceptuel (définir la signification précise d’informations complexes) ; il n’a donc pas à être posé dans un Modèle Conceptuel de Communication.
Il est essentiel de faire la différence entre les deux messages : leur but est de bien décrire les choix de gestion. Ainsi, à la relecture, la description du message sera interprétée sans erreur, ce qui permettra de reformuler les choix de gestion qui ont présidé à la conception du système d’information.
Ces choix étaient :
1. Pour l’exemple 1 : tous les clients sont concernés par le même catalogue.
2. Pour l’exemple 2 : chaque client a un catalogue particulier.
On aurait pu faire d’autres choix, par exemple, rassembler les clients en catégories et définir un catalogue par catégorie. Alors la description de la catégorie remplacerait celle du client dans la description de l’exemple 2 ; et un autre message définirait cette notion de catégorie (parce qu’une occurrence de catégorie n’est pas liée à une seule occurrence de catalogue).
4.3Redondance dans les messages ?
Un modèle conceptuel ne doit pas présenter de redondances, parce qu’il s’attache à décrire de manière uniquechacun des concepts du langage du système. Encore faut-il savoir ce qu’on entend, ici, par redondance.
Le but du Modèle Conceptuel de Communication est de faire apparaître toutes les informations élémentaires qui circulent dans le système : données élémentaires, et liens qui les unissent. L’ensemble de ces informations est destiné à figurer dans la mémoire collective du système.
C’est le même concept, le message, qui décrit :
• la réception d’une information émise par un acteur-partenaire, ou sa définition par un domaine, et sa communication aux intervenants qui en ont besoin ; dans un cas comme dans l’autre, il s’agit de sa première apparition dans le système, et cette première communication par un message correspond à une mise à jour de la mémoire ;
• la communication par un intervenant d’une information qu’il a reçue (par un autre message), ou qu’il a lui-même définie dans un message antérieur ; dans un cas comme dans l’autre, l’information reprise a déjà été mémorisée, et ce besoin d’une nouvelle communication suppose une consultation de la mémoire.
Il est donc normal qu’une information apparaisse plusieurs fois, comme éléments de messages différents16 : une fois pour la mise à jour, et les autres pour la consultation (c’est le contraire qui serait anormal). On ne doit pas considérer comme redondantes toutes ces apparitions.
Figure 4-1 :définition et utilisation d’une catégorie de clients
Reprenons l’exemple du catalogue, mais cette fois avec le troisième choix de gestion : le catalogue concerne une catégorie de clients. La figure 4-1 (définition et utilisation d’une catégorie de clients) montre les échanges des messages nécessaires à la mise en œuvre de ce nouveau choix de gestion.
La définition d’une catégorie de client relève de la finalité opératoire du domaine Administrer comptabiliser. Il transmet sa décision (la description de la nouvelle catégorie) au domaine Vendre, qui en a besoin pour deux éléments de son activité :
1. la validation d’un nouveau client, dont le résultat est transmis à Administrer comptabiliser par le message Client validé. Ce résultat est une information complexe, qui unit la description du client reçue par Vendre à de nouvelles informations produites par le domaine : ici, la description de la Catégorie client attribuée à ce client, par observation ou décision (selon le choix de gestion effectué).
2. la définition d’un nouveau catalogue concernant la catégorie (il y aura plusieurs occurrences de catalogue pour une occurrence de Catégorie client). Le résultat de ce traitement est transmis (par les messages Catalogue et Catalogue émis) aux deux intervenants qui en ont besoin : Client pour passer ses commandes, et Administrer comptabiliser pour les facturer.
Une première description fine du message Catalogue pourrait être la suivante (nous ne sommes pas encore à même de le décrire complètement) :
| Nom du message | Catalogue |
| Emetteur | VENDRE |
| Récepteur | CLIENT |
| Information | Description de la Catégorie client |
| N° du catalogue | |
| Période de validité | |
| n * Description d’un produit | |
| Prix de vente unitaire HT |
La Description de la Catégorie client, est une partie (éventuellement la totalité) du message Catégorie client, reçu par le domaine Vendre. Cette description est également reprise par les messages Catalogue émis, et Client validé, que nous ne détaillons pas.
Les messages (du Modèle Conceptuel de Communication) sont des descriptions des flux d’activité (du Modèle Conceptuel d’Activité). Le Modèle Conceptuel de Communication décrit donc une partition de l’activité du système global, ce que traduit le principe fondamental suivant :
Deux intervenants différents ne peuvent pas définir la même information.
Ce principe n’est valable qu’au niveau conceptuel : les descriptions de la même information par deux intervenants seraient redondantes ; une éventuelle différence entre les deux descriptions provoquerait des incohérences du système d’information.
Remarque. Il existe en effet un cas particulier, celui où un domaine définit une nouvelle information et la transmet aussitôt à plusieurs intervenants qui, tous, en ont besoin. Tous ces messages doivent alors être les résultats d’un même traitement, ce qui élimine tout risque d’incohérence. Le catalogue dédié à une catégorie de clients, de l’exemple précédent, en est une illustration : émis par le domaine Vendre, il est communiqué à Client et à Administrer comptabiliser par les deux messages Catalogue et Catalogue émis.
Les flux d’activité du Modèle Conceptuel d’Activité doivent décrire une activité réelle, c’est-à-dire une transformation : les flux sortants sont différents des flux entrants. Si le message qui décrit un flux sortant d’un intervenant, reprend une partie des informations reçues par cet intervenant, ou qu’il a luimême définies antérieurement, c’est pour l’enrichir, c’est-à-dire l’associer à de nouvelles informations.
Dans le message catalogue du paragraphe 4.3.1 (plusieurs messages peuvent communiquer les mêmes éléments d’information), les descriptions de la catégorie de client, et des produits, sont enrichies par leur présence simultanée dans le même message, et par les autres éléments d’information (données et regroupement) qui s’y trouvent. La catégorie, définie par le message Catégorie client, est un concept du langage du système : une fois définie, elle existe, donc elle va pouvoir être utilisée. La catégorie, reprise dans le message Catalogue, n’est plus un simple concept indépendant : la voilà liée à un catalogue. Ce lien (défini par la présence simultanée de N° de catalogue et de N° catégorie client dans le même message) est une nouvelle information, qui enrichit la première.
Les partitions de l’activité du système et de l’environnement, décrites dans le Modèle Conceptuel d’Activité, doivent interdire tout risque de description redondante d’un même flux. Partant, les descriptions de la mémoire et des traitements, qui en sont déduites, seront-elles aussi sans redondance. Le fait que le même flux d’activité ne puisse être émis par deux intervenants différents, est une première garantie. Mais elle n’est pas totalement suffisante, si on se contente de décrire la nécessité d’échanger des flux entre deux intervenants, pour bien préciser ce qui est du ressort de chacun, mais sans détailler tous ces flux.
Lorsqu’un intervenant a défini une information, et l’a communiquée à un autre intervenant qui en a besoin, il peut ensuite la reprendre. Ce sont là deux activités différentes : il ne faut pas qu’il y ait d’ambiguïté dans leurs descriptions conceptuelles, ce qui remettrait en cause la partition effectuée. Il faut donc veiller à ce qu’elles soient décrites séparément :
Un message qui décrit la reprise d’une information, ne peut pas être celui qui sert à décrire sa définition.
Ne pas respecter ce principe conduit presque toujours à des descriptions redondantes, sinon des données, au moins des traitements.
4.3.5Sélection d’une information reprise ?
Une information ne peut être définie qu’une seule fois (par un seul intervenant). Dans l’exemple de la figure 4-1 (définition et utilisation d’une catégorie de client), seul le domaine Administrer comptabiliser peut définir une nouvelle catégorie de clients. En revanche, il va le faire plusieurs fois : chaque occurrence du message Catégorie client en définit une nouvelle valeur. Quand un autre message, par exemple Catalogue, reprend cette information, il faut pouvoir déterminer sans ambiguïté à quelle valeur, donc à quelle occurrence du premier message (ici Catégorie client) il se réfère.
Il suffit pour cela de rajouter un numéro au premier message, celui qui définit l’information devant être reprise : Catégorie client, dans notre exemple. Numéro du message, ou bien numéro de l’information, c’est équivalent. A chaque fois qu’un autre message se réfère aux informations définies par ce premier message, ce numéro est joint aux autres informations reprises.
Nous verrons par la suite qu’il s’agit là d’un outil pratique, qui préfigure l’identifiant du Modèle Conceptuel de Données. Les exemples montreront son utilité, mais aussi qu’on peut parfois s’en passer.
L’introduction de cette identification d’une occurrence du message (parmi les autres), au moyen d’un numéro, est légèrement différente selon que ce message est émis par un domaine, ou par un acteur-partenaire. Nous allons l’illustrer à l’aide de deux exemples.
Reprenons notre exemple de catalogue. Si le domaine Vendre peut décider des prix, il faut tout de même qu’on lui communique les descriptions des produits devant figurer au catalogue. Dans le schéma d’activité de la Figure 35(vers la satisfaction des besoins…), cette communication lui est faite de façon indirecte par les flux Etat des stocks et Début commercialisation. Dans les messages correspondants, les descriptions des produits sont associées à d’autres informations (dates, quantités, etc.). Pour simplifier, nous faisons un autre choix de gestion, et considérons que le domaine Vendre reçoit une description des produits directement du domaine qui en a la responsabilité, soit Gérer les produits. Nous obtenons le schéma de la figure 4-2 (construction du catalogue), limité aux seuls messages de première définition des informations.
Figure 4-2 : construction du catalogue
Nous verrons dans le paragraphe 4.5.1.2 (Un message pour décrire le fournisseur, et un message pour décrire un produit) que le message envoyé par Gérer les produits à Vendre ne décrit le plus souvent qu’un seul produit. Le numéro du message peut alors être avantageusement remplacé par un numéro de produit. Ce numéro fera alors partie de la « description d’un produit » que l’on trouve dans les regroupements des messages.
Le domaine qui définit le nouveau numéro est celui qui a défini tous les autres ; il peut donc vérifier qu’il ne donne pas deux fois le même (ce qui est indispensable pour retrouver par la suite l’occurrence du message à laquelle on se réfère).
Les descriptions fines des différents messages sont les suivantes :
| Nom du message | Nouveau produit |
| Emetteur | GERER LES PRODUITS |
| Récepteur | VENDRE |
| Information | N° du produit |
| Nom du produit | |
| Commentaires sur produit, etc. | |
| Nom du message | Catégorie client |
| Emetteur | ADMINISTRER COMPTABILISER |
| Récepteur | VENDRE |
| Information | N° catégorie client |
| Libellé catégorie client | |
| Description catégorie | |
| Nom du message | Catalogue |
| Emetteur | VENDRE |
| Récepteur | CLIENT |
| Information | N° du catalogue |
| N° catégorie client | |
| Libellé catégorie client | |
| Période de validité | |
| n* N° du produit | |
| Nom du produit etc. | |
| Prix de vente unitaire HT |
Les descriptions dans le catalogue de la catégorie de clients, ou du produit, se réfèrent de façon explicite, grâce à leurs numéros, à des informations déjà connues. Ces informations ont déjà fait l’objet d’une communication antérieure (ici, par les messages Catégorie client et Nouveau produit). Sans aucun risque d’ambiguïté, le message peut alors reprendre une partie des informations associées au N° de la catégorie, ou du produit. Peu importe que ces associations aient été faites dans le message de définition, ou dans d’autres messages antérieurs au Catalogue, pourvu qu’elles aient été communiquées au domaine Vendre, qui doit les reprendre.
Nous verrons que ces informations seront en fait consultées dans la
Mémoire Collective. Mais pour le moment, cette mémoire n’existe pas, et il ne faut pas anticiper sur sa description. La communication par un message de toutes les informations dont le récepteur a besoin, est une condition nécessaire pour faire le bilan de son activité. Il ne faut pas s’en priver, surtout en période d’apprentissage.
Sauf exception, un acteur-partenaire est un concept qui recouvre plusieurs organismes, qui en sont autant d’occurrences. Lorsqu’une de ces occurrences commence à échanger des messages, avec le système, il doit commencer par se décrire. Cette description est indispensable pour qu’ensuite on puisse savoir, pour chaque occurrence d’un message émis par l’acteur-partenaire, quelle est occurrence de l’acteur-partenaire qui l’a émise.
Prenons l’exemple d’un client qui passe des commandes. C’est à lui, et pas à un autre, que la livraison doit être envoyée. Le message Commande doit donc se référer au message Nouveau client par lequel le client se décrit au système . Il faut donc associer un numéro au nouveau client. Mais, sauf exception, on ne peut confier la définition de cette information à un acteurpartenaire : rien ne garantit que deux occurrences de l’acteur-partenaire ne donneraient pas le même numéro. C’est donc au domaine récepteur de le faire. On peut le décrire de deux façons différentes.
Le domaine qui reçoit la description de la nouvelle occurrence de l’acteurpartenaire lui répond par un message.
Sur la figure 4-3 (description du client et de sa commande), Vendre répond par le message AR nouveau client, à la réception du message Nouveau client. Cette réponse lui permet de communiquer au client le numéro qui lui est attribué, et éventuellement d’autres informations. Ces informations peuvent aussi bien être des données nouvelles, que des liens avec des informations déjà connues.
Figure 4-3 : description du client et de sa commande
Ainsi, le N° catégorie client, et le Libellé catégorie client, communiqué par le message AR nouveau client décrit ci-dessous, ne définissent pas une nouvelle occurrence de Catégorie client : ils établissent un lien avec une occurrence déjà connue (dont la description a été reçue par le domaine Vendre).
| Nom du message | Nouveau client |
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | Nom client |
| Adresse client | |
| Numéro téléphone, etc. | |
| Nom du message | AR nouveau client |
| Emetteur | VENDRE |
| Récepteur | CLIENT |
| Information | N° client |
| Nom client | |
| N° catégorie client | |
| Libellé catégorie client | |
| Etc. |
Remarque. Nous reportons la description du message Commande au paragraphe 4.5.2 (plusieurs regroupements dans un message) où plusieurs exemples sont proposés, correspondant à des choix de gestion différents. Toutes ces descriptions ont en commun de se référer au numéro de client préalablement défini.
Le schéma du Modèle Conceptuel de Communication, qui décrit l’existence des messages, est souvent compliqué. Pour ne pas l’alourdir, il est commode de ne pas décrire la réponse du domaine (ici, Vendre) par un message séparé, mais d’utiliser une représentation condensée, où les deux messages sont confondus. C’est ce que montre la figure 4-4 (description du client, sans réponse directe).
Figure 4-4 : description du client, sans réponse directe
On réunit alors dans la description fine du message émis par l’acteurpartenaire, les informations qu’il définit, et celles que le domaine définit luimême, à sa réception. Pour bien différencier ces deux types d’informations, on met entre parenthèses les informations définies par le domaine à la réception du message :
| Nom du message | Nouveau client (sans AR) |
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | (N° client) |
| Nom client | |
| Adresse client | |
| Numéro téléphone, etc. |
La description de ce message met entre parenthèses la donnée N° client. Cette présentation de l’information suppose :
1. qu’elle n’est pas reçue de l’acteur-partenaire, mais produite par le système (observée, régulée ou décidée) ;
2. que c’est sa première apparition dans le système.
Cette dernière condition est très restrictive, mais il est indispensable de la respecter, pour qu’il n’y ait aucune ambiguïté entre la définition et la reprise d’une information. Cette condition nous interdit d’utiliser une description condensée, pour communiquer un nouveau lien avec une information déjà existante (par exemple, la catégorie attribuée au nouveau client).
Mettre le N° catégorie entre parenthèses, indiquerait que c’est le domaine Vendre qui décide de l’existence d’une nouvelle catégorie (ce serait une redondance d’activité). Et le mettre sans parenthèses, indiquerait que c’est le client qui déclare à quelle catégorie il appartient (ce qui serait un autre choix de gestion).
La description condensée d’un message reçu par le système, et des informations définies à sa réception est un outil pratique, mais à utiliser avec précautions : elle ne doit engendrer aucune incertitude sur les sources des informations.
Le regroupement est un outil simple, mais précis, de description de la signification d’informations complexes, à condition de l’utiliser avec rigueur.
4.4.1Un message ou plusieurs ?
Le regroupement d’un message doit être signifiant.
Un regroupement est un élément de l’information complexe et cohérente transmise par le message ; il doit contribuer effectivement à sa signification.
C’est bien le cas pour les regroupements des exemples précédents : ils sont donc « signifiants ». En revanche, ne sont pas signifiants les regroupements d’informations qui seraient aussi complètement décrites de façon individuelle (une occurrence du message pour chaque occurrence de l’information).
Considérons un système qui achète des produits à des fournisseurs. Dans le Modèle Conceptuel d’Activité, on peut se contenter de décrire un flux unique, tel que F5 dans le schéma de la Figure 3-2 (deux niveaux de décision). Ce qui compte alors, c’est de déterminer quel est le domaine qui reçoit les descriptions envoyées par l’acteur-partenaire. Arrivé au Modèle Conceptuel de Communication, il faut être plus précis dans la description des choix de gestion. On doit se poser deux questions successives :
1. faut-il un ou plusieurs messages pour décrire ce flux ?
2. si on utilise deux messages, un pour la description du fournisseur, l’autre pour la description des produits, alors une occurrence de ce dernier message doit-elle décrire un seul produit, ou plusieurs ?
Il y a là trois choix de gestion possibles, correspondant à trois descriptions des messages. Nous allons les examiner successivement, en montrant leur signification respective (les schémas des messages ne posent pas de problème ; nous nous en dispensons).
Cette solution est la première qui vient à l’esprit, ne serait-ce que par analogie avec la perception de la réalité. Elle semble décrire directement le document (un catalogue sur papier) envoyé par un nouveau fournisseur.
| Nom du message | Description du fournisseur et de ses produits |
| Emetteur | FOURNISSEUR |
| Récepteur | GERER LES PRODUITS |
| Information | (N° du fournisseur) |
| Nom du fournisseur | |
| Adresse fournisseur, etc. | |
| n* (N° produit) | |
| Nom produit | |
| Description produit, etc. |
Notons que le message décrit au système, pour la première fois, une information complexe comprenant un regroupement. Chaque occurrence de l’ensemble des informations concernées par le regroupement (nom et description d’un produit) doit pouvoir être repérée parmi les autres. Il faut donc que le domaine définisse deux informations à la réception du message : le numéro du fournisseur, et celui du produit. Elles sont toutes les deux décrites entre parenthèses.
La description de ce message ne présente aucune anomalie. Elle est donc tout à fait admissible ; encore faut-il savoir quelle est sa signification. C’est la traduction d’un choix de gestion peu fréquent, mais qui n’est pas impossible : le message décrit en une seule fois le fournisseur et l’ensemble de ses produits. Il ne pourra pas en décrire d’autres par la suite.
En effet, supposons qu’il essaye de décrire de nouveaux produits. Cette description ne peut pas se faire par un message séparé du premier (Description du fournisseur et de ses produits) : rien ne garantirait que les activités qui les réceptionnent soient identiques ; on s’exposerait alors à des descriptions redondantes de la mémoire ou des traitements. Nous nous l’interdisons. Il faut donc considérer que c’est le même message qui est utilisé : la première fois pour définir le fournisseur et ses premiers produits, et les fois suivantes pour reprendre la description du fournisseur (déjà connue), et définir ses nouveaux produits. Mais c’est une chose que nous avons interdite au paragraphe 4.3.4 (Une information ne peut pas être définie, et reprise, par le même message).
En choisissant un message unique pour décrire le fournisseur et ses produits, nous signifions donc qu’une occurrence de l’acteur-partenaire Fournisseur, ne peut émettre qu’une seule occurrence du message Description du fournisseur et de ses produits.
Cette unique occurrence du message décrit donc, une fois pour toutes, l’ensemble des produits du fournisseur.
Ainsi que nous l’avons annoncé au paragraphe 4.4.4.1 (Message émis par un domaine), cette solution décrit le choix de gestion le plus fréquent. L’acteur-partenaire Fournisseur émet deux messages différents, l’un pour se décrire, l’autre pour décrire un produit. Ce second message se réfère au premier, grâce à la reprise de la donnée N° du fournisseur. Plusieurs occurrences du second message se réfèrent à la même occurrence du premier message.
Nous utilisons la description condensée des informations définies par le domaine, à la réception d’un message externe (émis par un acteur-partenaire).
Nom du message Nouveau fournisseur
| Emetteur | FOURNISSEUR |
| Récepteur | GERER LES PRODUITS |
| Information | (N° du fournisseur) |
| Nom du fournisseur | |
| etc. | |
| Nom du message | Description d’un produit |
| Emetteur | FOURNISSEUR |
| Récepteur | GERER LES PRODUITS |
| Information | N° du fournisseur |
| Nom du fournisseur | |
| etc. | |
| (N° produit) | |
| Nom produit | |
| (Commentaire) | |
| etc. |
Le N° de fournisseur est défini par le domaine Gérer les produits, à la réception du message Nouveau fournisseur : c’est ce qu’indiquent les parenthèses qui l’encadrent dans la description fine du message. Il est ensuite repris par le message Description d’un produit : cette fois, l’information est déjà connue, aussi ne la met-on plus entre parenthèses.
Le N° produit, et les Commentaires, sont définis par le domaine à la réception du message : ils sont mis entre parenthèses.
Si le fournisseur ne devait décrire qu’un seul produit (jamais plusieurs), on décrirait en un seul message sa description, et celle de son unique produit, comme dans l’exemple du paragraphe 4.5.1.1 (un seul message pour décrire le fournisseur et ses produits).
Donc, si on utilise deux messages, c’est qu’il va y avoir plusieurs occurrences de produits décrites, pour une même occurrence de fournisseur. Nous sommes dans le cas annoncé au paragraphe 4.3.4 (une information ne peut pas être définie, et reprise, par le même message).
Nous appelons message spontané, un message émis par un intervenant sans que ce soit une réponse à un autre message, que cet intervenant aurait reçu.
Forts de cette définition, nous pouvons énoncer le principe fondamental suivant :
Si deux messages spontanés sont émis par un même émetteur, à destination du même receveur, et si le second message se réfère au premier, alors plusieurs occurrences du second peuvent se référer à la même occurrence du premier.
Inversement, si on ne veut pas que plusieurs occurrences de l’information décrite par le second message puissent se référer au premier, alors il ne faut décrire qu’un seul message, réunissant ces deux informations (complexes).
Compte tenu du principe précédent, l’utilisation d’un seul message pour définir plusieurs produits – au moyen d’un regroupement – peut-elle être justifiée ? Oui, mais à la condition expresse que le regroupement soit signifiant, donc que le sens de ce message soit différent de celle du message Description d’un produit de l’exemple du paragraphe 4.5.1.2.1.
La description du message Nouveau fournisseur est identique à celle du paragraphe 4.5.1.2.1 ; nous ne la répétons pas.
| Nom du message | Description de plusieurs produits |
| Emetteur | FOURNISSEUR |
| Récepteur | GERER LES PRODUITS |
| Information | N° du fournisseur |
| Nom du fournisseur | |
| Information complémentaire | |
| n* (N° produit) | |
| Nom produit | |
| Description produit, etc. |
Nous représentons par Information complémentaire, toute information qui ne serait pas reprise du message Nouveau fournisseur, qu’elle soit reçue ou définie par Gérer les produits.
4.4.1.3.2Choix de gestion décrit Ce message ne peut pas décrire l’ensemble (définitif) des produits du fournisseur : il aurait suffi d’un seul message pour décrire à la fois le fournisseur et ses produits . Donc, plusieurs occurrences du message Description de plusieurs produits, peuvent se référer à la même occurrence de
Nouveau fournisseur : chacune d’elles enrichit la liste des produits du fournisseur.
La différence entre les descriptions des deux messages (un ou plusieurs produits par message), c’est le regroupement : il est présent dans le message Description de plusieurs produits, mais pas dans l’autre. Nous considérons, bien entendu, que ce regroupement est signifiant. Il apporte donc une information que n’apporte pas le message Description d’un produit : les produits décrits par la même occurrence du message, ont donc en commun quelque chose de plus que de venir du même fournisseur.
Ce « quelque chose de plus », c’est ce que décrit l’information complexe que nous avons nommée Information complémentaire ; ce pourrait, par exemple, être la description d’une vente aux enchères (où la description d’un objet ne serait valable que pour une seule vente). Quoi qu’il en soit, le fait d’être décrit dans une occurrence du message, et pas dans une autre, est un élément important de la description du produit : l’Information complémentaire doit contenir, au minimum, un numéro de message défini par le domaine récepteur (qui doit donc être décrit entre parenthèses).
Un message contient souvent plusieurs regroupements qui peuvent être soit imbriqués l’un dans l’autre, soit juxtaposés. Imbrication et juxtaposition ont des sens différents, et nous allons les étudier sur un même exemple, une commande passée par un client, mais avec des choix de gestion différents. Pour faciliter les commentaires, nous donnerons des noms différents à ces messages qui touspourraient décrire un même flux d’activité Commande client, émis par l’acteur-partenaire Client et reçu par le domaine Vendre.
Nous verrons que dans le Modèle Conceptuel de Données et le Modèle Conceptuel de Traitements, ces messages déboucheront sur des schémas de mémoire et de traitements différents (ce qui est normal puisqu’ils n’ont pas le même sens !).
Nous ne décrivons pas le message nouveau client : il l’a été au paragraphe
4.4.1.2.1 (Le domaine communique le numéro à l’acteur-partenaire, par un message). Nous commençons avec une description de la commande qui ne contient qu’un seul regroupement, pour se familiariser avec le concept.
| Nom du message | Commande client |
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | N° client |
| Nom client etc. | |
| (N° commande) | |
| Date de la commande | |
| Date de livraison demandée | |
| Description de l’adresse de livraison | |
| n* N° produit | |
| Description du produit | |
| Quantité commandée | |
| Etc. |
Cette description met en évidence deux sous-ensembles :
1. depuis N° client jusqu’à Description de l’adresse de livraison, les informations concernent l’ensemble de la commande (chacune d’elles n’a qu’une seule valeur, pour une occurrence du message commande) ;
2. les informations du regroupement concernent, elles, une occurrence de produit commandé (N° produit, Description du produit, Quantité commandée, etc.). Il y a un rapport de un à plusieurs, entre les informations du premier sous-ensemble, et celles du regroupement.
L’ensemble de la commande doit être livrée le même jour, en un seul lieu : tel est le sens de ce message, où Date de livraison demandée, et Description de l’adresse de livraison, sont décrites en dehors du regroupement.
| Nom du message | Commande centrale d’achat |
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | N° client |
| Nom client etc. | |
| (N° commande) | |
| Date de la commande | |
| Date de livraison demandée | |
| n* N° adresse de livraison | |
| Description de l’adresse de livraison | |
| n* N° produit | |
| Description du produit | |
| Quantité commandée | |
| Etc. |
C’est l’exemple le plus classique de regroupements multiples. Il propose deux regroupements imbriqués l’un dans l’autre. Chacune des occurrences du regroupement externe est dans un rapport de un à plusieurs avec les occurrences du regroupement interne.
La commande demande des livraisons à plusieurs adresses, et pour chaque adresse, elle décrit une liste de produits à livrer. Cette liste de produits dépendd’une adresse, donc les listes concernant deux adresses différentes sont différentes (mais rien n’interdit le cas particulier où on répèterait la même liste pour deux adresses différentes).
La date de livraison demandée, qui est en dehors des regroupements, ne dépend que de la commande : elle concerne toutes les adresses de livraison.
L’adresse de livraison est associée à un numéro déjà connu (il n’est pas entre parenthèses) ; donc elle a été définie dans un autre message séparé. Peu importe que ce soit par un message autonome (le client pourra alors décrire de nouvelles adresses, à son gré), ou par un regroupement du message de description du client (toutes les adresses sont connues dès cette description). Au niveau conceptuel, on doit utiliser deux messages séparés : la définition d’une information, et sa reprise.
Ce message est proche du message Commande centrale d’achat, du paragraphe 4.5.2.2 : c’est la présentation du N° adresse de livraison, entre parenthèses, qui les rend différents.
Nom du message Commande groupée
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | N° client |
| Nom client etc. | |
| (N° commande) | |
| Date de la commande | |
| Date de livraison demandée | |
| n* (N° adresse de livraison) | |
| Description de l’adresse de livraison | |
| n* N° produit | |
| Description du produit | |
| Quantité commandée, etc. |
Ces parenthèses signifient que cette donnée n’est pas reçue, mais définie par le domaine Vendre à l’arrivée du message : on ne souhaite pas réutiliser une occurrence de l’adresse de livraison, pour une autre occurrence du message commande. En revanche, ce N° adresse de livraison peut être utilisé dans d’autres messages, postérieurs (bons de livraison par exemple).
De nouveau, ce message ressemble beaucoup à la Commande centrale d’achat du paragraphe 4.5.2.2.
| Nom du message | Commande centrale d’achat (bis) |
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | N° client |
| Nom client etc. | |
| (N° commande) |
Date de la commande n* N° adresse de livraison Description de l’adresse de livraison Date de livraison demandée
n* N° produit Description du produit
Quantité commandée, etc.
Cette fois, c’est la place de Date de livraison demandée qui a été modifiée. Elle est maintenant placée dans le regroupement de description des adresses de livraison : cela signifie qu’une date ne concerne qu’une seule adresse, donc que l’on va demander des dates différentes (potentiellement), pour chacune des adresses décrites dans le message.
Cette fois, c’est la disposition des regroupements qui est modifiée ; ils ne sont plus imbriqués mais juxtaposés. Aussi, les occurrences d’adresse de livraison sont en rapport de plusieurs à plusieurs, avec les occurrences de produit.
| Nom du message | Commande centrale d’achat (ter) |
| Emetteur | CLIENT |
| Récepteur | VENDRE |
| Information | N° client |
| Nom client etc. | |
| (N° commande) | |
| Date de la commande | |
| n* N° adresse de livraison | |
| Description de l’adresse de livraison | |
| Date de livraison demandée | |
| n* N° produit | |
| Description du produit | |
| Quantité commandée, etc. |
Cette disposition peut se retrouver pour définir des résultats de règles de gestion (par exemple cumuls des montants de TVA par taux dans une facture) et aussi, plus rarement, pour exprimer un choix de gestion analogue à celui de cet exemple.
La seule signification possible de cette description est que la commande demande de livrer la même liste de produits (avec les mêmes quantités) décrite par le second regroupement, à chacune des adresses du premier regroupement. Ce n’est pas un choix de gestion fréquent, mais rien n’empêche qu’on le fasse : ce qui compte, c’est de savoir que cette description de message correspond à ce choix de gestion et réciproquement.
La justesse d’un modèle ne peut s’apprécier que par rapport aux choix qui ont présidé à son élaboration.
4.4.3Les regroupements multiples sont-ils toujours « signifiants » ?
Nous avons remarqué, au paragraphe 4.5.1 (Un message ou plusieurs ?), que le regroupement d’un message doit être signifiant, c’est-à-dire qu’il doit enrichir la signification de l’information (complexe et cohérente) transmise par le message. Cette remarque est bien entendu valable pour des regroupements multiples, qu’ils soient imbriqués ou juxtaposés. La pertinence du regroupement vient de sa contribution à la signification du message, à l’exclusion de toute autre considération, en particulier de toute approche organisationnelle.
Dans le message Commande centrale d’achat du paragraphe 4.5.2.2 (Deux regroupements imbriqués : premier exemple), les deux regroupements sont bien signifiants parce qu’ils définissent chacun de nouveaux liens :
1. entre une adresse et la commande ;
2. entre un produit, et une occurrence du premier regroupement, donc entre un produit, une adresse, et la commande (c’est un lien ternaire).
Mais considérons les deux messages suivants :
| Nom message | Nouveau produit |
| Emetteur | Gérer produit |
| Récepteur | Vendre |
| Information | N° produit |
| Nom produit | |
| N° catégorie produit | |
| Libellé catégorie, etc. | |
| Nom message | Catalogue |
| Emetteur | Vendre |
| Récepteur | Client |
| Information | N° catalogue |
| Période de validité | |
| n* N° catégorie produit | |
| Libellé catégorie | |
| n* N° produit | |
| Nom produit | |
| Prix unitaire, etc. |
Le premier message décrit un nouveau produit ; il établit un lien entre ce produit et une catégorie, qui a été définie au préalable par un autre message.
Le second message utilise deux regroupements : c’est justifié s’ils apportent quelque chose de nouveau. La seule nouveauté possible, c’est que le second regroupement établisse un nouveau lien entre le produit et la catégorie ; mais pour que ce lien soit bien nouveau, il faudrait que la catégorie associée au produit ne soit pas la même que celle qui lui a été associée lors de la description du produit. Si ce n’est pas le cas (ce qui est le choix de gestion le plus probable), alors l’imbrication des deux regroupements n’est pas signifiante (elle n’apporte pas de sens supplémentaire).
Ici, c’est le premier regroupement qui est en trop : il ne fait que décrire l’organisation du document qui correspond au message dans les modèles organisationnels (on voudrait que dans ce document les produits soient triés par catégorie). Il s’agit d’une information redondante, légitime dans un modèle organisationnel, mais pas dans un modèle conceptuel.
La bonne description du message est donc la suivante :
| Nom message | Catalogue |
| Emetteur | Vendre |
| Récepteur | Client |
| Information | N° catalogue |
| Période de validité | |
| n* N° produit | |
| Nom produit | |
| Libellé catégorie | |
| Prix unitaire | |
| Etc. |
• Le N° produit et le Libellé catégorie sont au même niveau : il n’y a pas de nouveau lien défini (par un regroupement), et c’est donc forcément la reprise de celui qui a été défini dans le message Nouveau produit.
• Le N° catégorie n’est pas repris : il est inutile, puisque le lien a déjà été défini. Le reproduire pourrait laisser croire (lors d’une lecture rapide), qu’il s’agit d’un nouveau lien.
L’émission par un intervenant de deux messages spontanés, le second se référant au premier, décrit :
1. deux informations complexes et cohérentes ;
2. un rapport de un à plusieurs entre l’information transmise par une occurrence du premier message, et celles transmises par les occurrences du second.
Autrement dit, ces deux messages séparés transmettent des informations séquentielles.
Il y a un autre cas où l’on souhaiterait deux informations complexes et cohérentes, la seconde se référant à la première, sans qu’il y ait pour autant ce rapport de un à plusieurs : c’est celui des informations alternatives.
Des informationssont alternatives, si elles sont nécessaires pour décrire toutes les occurrences des flux, mais ne sont pas toujours simultanément utilisables.
Soit un système dont la finalité opératoire est Commercialiser. Parmi les acteurs-partenaires, on définit le concept de Client, qui réunit aussi bien des personnes physiques que des personnes morales (entreprises, administrations, etc.). La description d’une personne physique n’est pas identique à celle d’une personne morale : la première a un prénom que n’a pas la seconde tandis que la seconde a un statut qui ne convient pas à la description de la première.
Comment les décrire sans ambiguïté ?
• Utiliser deux messages différents pose des problèmes quand un autre message doit ensuite faire référence à un client, qu’il s’agisse d’une personne physique ou d’une personne morale.
• Utiliser trois messages permettrait de décrire respectivement le concept indifférencié de client et, soit les particularités liées à la personne physique, soit celles liées à la personne morale.
Mais on décrirait ainsi des rapports de un à plusieurs entre le message qui décrit le concept de client, d’une part, et ceux qui décrivent les concepts de personne physique ou de personne morale, d’autre part. Cela signifierait, par exemple, qu’une occurrence du client (indifférencié) pourrait être liée à plusieurs occurrences de personnes physiques. Ce serait une mauvaise description du choix de gestion.
Pour résoudre ce problème, il convient de définir un nouveau concept : le sous-message.
Un sous-message est une partie de la description fine d’un message, telle que :
• il est composé d’informations qui n’ont pas de sens pour chacune des occurrences du message, mais seulement pour une partie d’entre elles ;
• il décrit une information qui est elle-même complexe et cohérente ;
• il décrit une information disjointe de celles des autres sous-messages, et de celles qui ont un sens pour toutes les occurrences du message principal;
• il peut ne pas être exclusif des autres sous-messages du message principal.
Le message descriptif du Client est alors :
| Nom du message | Nouveau Client |
| Emetteur | CLIENT |
| Récepteur | COMMERCIALISER |
| Information | (N° Client) |
| Nom client | |
| Adresse client | |
| (Et les données concernant tous les clients) | |
| Sous message exclusif | Description personne physique |
| Information | Prénom client |
| Sexe | |
| (Et les données ne concernant que les | |
| personnes physiques) | |
| Sous message exclusif | Description personne morale |
| Information | Statut |
| Nom responsable | |
| (Et les données ne concernant que les | |
| personnes morales) |
Ainsi que nous l’avons annoncé en introduction, on construit le Modèle Conceptuel de Communication à partir du Modèle Conceptuel d’Activité.
Les concepts de base du Modèle Conceptuel de Communication sont les intervenants et les messages.
• Les intervenants sont ceux du Modèle Conceptuel d’Activité.
• Un message décrit un flux d’activité, et chacun des flux d’activité doit être décrit par au moins un message.
Le Modèle Conceptuel de Communication doit décrire une communication complète, et ne pas se contenter de fixer les rôles respectifs des intervenants, comme le faisait le Modèle Conceptuel d’Activité. Il y a plusieurs raisons pour qu’un flux du Modèle Conceptuel d’Activité soit décrit par plusieurs messages dans le Modèle Conceptuel de Communication ; nous les décrivons une à une, sur des exemples simples.
Un flux de matière doit faire l’objet d’une double description, de l’émetteur et du récepteur.
MCA MCC
Figure 4-5 : descriptions d’un flux de matière
Considérons la figure 4-5 (descriptions d’un flux de matière) : elle décrit une livraison d’un fournisseur au système. Il y a échange de matières. Les buts du Modèle Conceptuel d’Activité et du Modèle Conceptuel de Communication n’étant pas les mêmes, leurs descriptions différent.
Le but du Modèle Conceptuel d’Activité est de fixer les rôles et les finalités des intervenants. Un flux unique, Livraison, y suffit. C’est un flux de matière, parce que c’est cet échange de matière qui est le plus important pour décrire l’activité du système.
Le but du Modèle Conceptuel de Communication est de détailler l’ensemble des messages qui contribuent à décrire ce flux concret. Deux ou trois messages sont le plus souvent nécessaires :
1. Le Bon de livraison émis par Fournisseur pour Stocker : le fournisseur décrit son envoi, produits et quantité. La Quantité annoncée transmise par ce message, est définie par l’acteurpartenaire ; c’est une information reçue par le domaine.
2. Le Bon de livraison validé émis par Stocker pour Fournisseur : le domaine décrit la livraison, telle qu’il l’a réceptionnée, et acceptée (en totalité ou en partie). Ce message transmet deux quantités de produits : la Quantité réceptionnée, observée par le domaine, et la Quantité acceptée, qui est décidée.
3. Le bon de retour émis par Stocker pour Fournisseur permet de décrire un flux de matière dans le sens inverse, si les choix de gestion autorisent des retours différés de marchandises défectueuses. Ce message transmet alors une autre quantité : la Quantité retournée, observée ou décidée par le domaine.
4.6.1.2Informations séquentielles spontanées Un flux d’informations doit être décomposé en deux messages, si plusieurs occurrences du deuxième correspondent à une même occurrence du premier, et ne peuvent pas être réunies dans un regroupement.
FOURNISSEUR
Description fournisseur et produits
GERER LES
PRODUITS
MCA MCC
Figure 4-6 : informations séquentielles spontanées
Les schémas de la figure 4-6 (informations séquentielles spontanées), décrivent l’exemple du paragraphe 4.5.1.2 (Un message pour décrire le fournisseur, et un message pour décrire plusieurs produits). Dans le schéma du
Modèle Conceptuel d’Activité, un seul flux d’informations suffit à fixer les rôles des intervenants. En revanche, dans le Modèle Conceptuel de Communication, deux messages sont nécessaires pour décrire le choix de gestion. Nous avons suffisamment expliqué pourquoi, pour ne pas avoir besoin d’y revenir.
4.6.1.3Informations séquentielles provoquées Le but du Modèle Conceptuel d’Activité étant de faire la partition du système et de son environnement, on regroupe le plus souvent en un seul flux d’activité des échanges successifs. Il faut bien sûr que ces échanges concernent les mêmes intervenants, et que le flux unique qui sert à les représenter soit suffisamment explicite pour fixer les rôles respectifs desdits intervenants. On laisse alors au Modèle Conceptuel de Communication, le soin de détailler chacun de ces échanges par un message séparé.
MCA MCC
Figure 4-7 : informations séquentielles provoquées
Considérons les schémas de la figure 4-7 (informations séquentielles provoquées).
• Le Modèle Conceptuel d’Activité précise les rôles : le domaine émet tous les résultats de l’activité de facturation, et attend en réponse des règlements de la part du client. Dès lors qu’aucun autre domaine n’intervient dans ces activités, un flux dans chaque sens est suffisant pour fixer les idées du lecteur du schéma.
• Le Modèle Conceptuel de Communication, lui, doit détailler tous les messages nécessaires à la description précise des flux d’activité. Par exemple, pour la facturation, il faut émettre un message Facture, résultat d’une activité normale. Mais il faut prévoir aussi un message relance (reprenant les informations d’occurrences de Facture), au cas où les règlements du client ne seraient pas satisfaisants. Ce second message est la suite du premier, mais il n’est pas spontané : il est provoqué soit par un règlement insuffisant, soit par une absence de règlement (constatée après une date d’échéance communiquée par la facture).
Rappelons qu’en principe, les flux échangés par les acteurs-partenaires ne concernent pas la description du système. Il existe toutefois une exception : c’est le cas où un domaine confie la réalisation d’une partie de son activité à un acteur-partenaire.
L’exemple classique, que nous allons illustrer, est celui d’une livraison confiée à un tiers ; mais il y en a d’autres, par exemple, le recouvrement d’impayés. L’activité sous-traitée devient donc une activité externe au système. Mais son importance est telle, que le système a besoin (pour ses autres activités) qu’elle lui soit décrite : a-t-elle eu lieu ? S’est-elle ou non bien déroulée ? Etc.
Considérons les schémas de la figure 4-8 (sous-traitance) : ils décrivent comment une livraison est réalisée par un acteur-partenaire, Livreur, pour le compte du système. Dans le Modèle Conceptuel d’Activité, on représente deux flux : le premier (Mise à disposition colis), décrit le flux de matière confié au livreur. Le second décrit le flux de matière émis par l’acteurpartenaire, Livreur, et reçu par un autre, Client.
STOCKER
Demande de Avis de Avis de livraison livraison réception
LIVREUR CLIENT
MCA MCC
Figure 4-8 : sous-traitance
Le premier flux ne pose pas de problème : il est décrit, tout à fait normalement, par un message qui a le même émetteur et le même récepteur
(Demande de livraison sur le schéma du Modèle Conceptuel de
Communication). En revanche, le second flux ne peut pas être décrit par un message entre les deux acteurs-partenaires : il ne serait pas représenté dans le système d’information. Il faut que chacun des deux acteurs-partenaires en fasse la description, par un message, au domaine qui a sous-traité son activité : ce sont les messages Avis de livraison et Avis de réception, du schéma du Modèle Conceptuel de Communication.
Un flux de sous-traitance (échangé entre deux acteurs-partenaires) est décrit par deux messages émis respectivement par l’émetteur et le récepteur du flux, et reçus par un des domaines du système.
Remarque. On pourrait croire qu’un seul flux (ici, Avis de livraison) pourrait suffire, mais c’est une fausse impression. Il ne permettrait pas de traiter les litiges, erreurs de description du livreur, et, en un mot, toutes les anomalies dans la réalisation de la sous-traitance.
4.6.2Par où commencer la construction du Modèle Conceptuel de Communication ?
Il y a un ordre chronologique des messages. Dans l’exemple ci-dessus, l’Avis de livraison est postérieur à la Demande de livraison, et sera lui-même suivi de l’Avis de réception. Cet ordre est indiqué dans la description fine des informations transmises par les messages : l’Avis de livraison contiendra, parmi ses données, le numéro de la Demande de livraison, etc.
Il y a donc forcément des messages qui ne sont précédés d’aucun autre : ils ne se réfèrent à aucun message antérieur. Ce sont les descriptions de l’environnement (description de client, de fournisseur…) et du système : les décisions de pilotage, qui fixent le cadre des autres éléments de l’activité globale. Ce sont des messages spontanés. C’est par eux qu’il faut commencer.
Ensuite, on avance en décrivant les autres messages spontanés, qui se réfèrent aux premiers que l’on a décrits : ils complètent la description de l’environnement, et celle du pilotage du système.
Enfin, on s’intéresse aux messages provoqués, ceux qui répondent à ceux qui ont déjà été décrits, en suivant leur ordre chronologique.
En procédant ainsi, on est assuré d’avoir toujours décrit le message qui définit une information, avant d’en décrire un qui la reprend.
Avant de passer à la construction du Modèle Conceptuel de Données, il convient de faire une synthèse des données décrites dans les messages, pour s’assurer qu’il n’y a aucun problème de signification des informations en suspens.
Les données des messages sont destinées à devenir les informations de la mémoire. Le Modèle Conceptuel de Données, qui est la description abstraite de cette mémoire, a pour principe51 que chacune des données échangées par les intervenants doit être mémorisée une et une seule fois. Il convient de s’assurer que l’ensemble des données décrites par le Modèle Conceptuel de Communication convient bien à cette description conceptuelle de la mémoire, c’est-à-dire qu’il n’y a aucune ambiguïté dans leur description. Deux problèmes peuvent se poser : les synonymes et les polysèmes.
Des synonymes sont des informations52qui ont le même sens mais portent des noms différents.
Le cas risque de se produire lorsqu’on décrit séparément les messages concernant chacun des domaines, ou bien lorsqu’on se fonde sur une observation trop fidèle d’une organisation existante, sans faire un effort de conceptualisation suffisant. Par exemple, lors de la description des messages du domaine Fabriquer, on utilise la notion de produit dans les messages échangés, et dans celle des messages du domaine Vendre, on utilise la notion d’article. Si à chaque occurrence de produit, il correspond une et une seule occurrence d’article, on est en présence de synonymes.
Il convient alors de ne garder qu’une seule des deux données pour la suite des descriptions conceptuelles, quitte à réintroduire l’autre dans les descriptions des documents (éléments de communication organisationnelle ou opérationnelle), pour ne pas bouleverser gratuitement le langage de l’entreprise étudiée.
Un polysème est une information qui a deux significations différentes (et donc un seul nom).
Par exemple, dans la description d’un client, on trouve un taux de remise (sous-entendu permanent), et dans celle d’une commande du client, on trouve également un taux de remise. S’il ne s’agit pas de la reprise du taux de remise permanent, donc si les choix de gestion acceptent un taux de remise valable pour cette seule commande, alors on est en présence d’un polysème. Il convient dans ce cas de lever l’ambiguïté, en donnant des noms différents aux deux informations ; par exemple Taux de remise permanente et Taux de remise exceptionnelle dans le cas que nous avons soulevé.
Organisationnel de Données, le Modèle Logique de Données, et le Modèle Physique de Données.
51 Cf. chapitre 5 : Le Modèle Conceptuel de Données, concepts de base.
52 En général, le problème se pose pour chacune des données décrivant ces informations (complexes).
Dans un premier temps, on constitue une liste qui reprend toutes les données des messages. Puis on cherche à détecter, parmi elles, les synonymes et polysèmes éventuels. Pour cela, il est nécessaire de décrire les données le plus complètement possible en précisant pour chacune d’elles :
• son nom ;
• sa source, c’est-à-dire comment elle est définie (réception, observation, régulation – et dans ce cas, il faut décrire la règle avec précision – ou décision) ;
• des « mots-clefs ».
Ces mots-clefs sont les noms des intervenants concernés par la donnée, le nom des messages dans lesquels elle figure, et tout ce qui peut être utile pour préciser le sens de la donnée.
Par exemple, pour la Quantité commandée du message Commande client du paragraphe 4.5.2.1 (commande avec un seul regroupement), on ferait la description :
Quantité commandée / reçue / client, vendre, commande groupée, adresse de livraison, produit.
Ces descriptions se font par message, puis on trie la liste brute ainsi obtenue.
• Si on trouve deux fois le même nom de données, mais avec des descriptions différentes et inconciliables, alors on est en présence d’un polysème, et il faut donner un nom différent à chacune des deux informations.
• Si on repère deux descriptions semblables (l’égalité de la liste des mots clefs ne sera que rarement obtenue), pour deux données dont les noms sont différents, alors ce sont des synonymes et il faut n’en garder qu’un pour la suite de la description conceptuelle.
On doit aboutir à un dictionnaire des données sans aucune ambiguïté.
Cf. § 4.2 – Le message
Cf. § 4.2.1 – Définition du message.
Cf. Figure 1-1 : dépendance des différents modèles.
Cf. § 3.3 – Une décomposition en sous-systèmes pilotés.
Cf. § 1.2.1 – Un besoin d’information.
Cf. § 4.5.2 – Plusieurs regroupements dans un message.
La plupart de ces données seront les propriétés du Modèle Conceptuel de Données.
Cf. § 4.7.1.4 – Sous-traitance.
Il suffit d’un message pour décrire le flux ; on lui donne donc le même nom (Cf. supra).
n est le symbole de plusieurs. On le réutilisera dans les modèles de données (cardinalité) et de traitements (répétition d’une action).
C’est un choix de gestion inhabituel, mais pourquoi pas ? De toutes façons, notre but n’est pas de justifier, ou de critiquer les choix de gestion, mais de les décrire avec précision.
Cf. l’exemple de la figure 4.1 (définition et utilisation d’une catégorie de client), qui traite ce choix de gestion.
Cf. Annexe, § 17.5 – Redondance.
Des descriptions redondantes pourraient ne pas être identiques – à moins de prévoir des traitements pour les « gérer », mais c’est un problème organisationnel et non pas conceptuel. Ces différences, d’une description à l’autre, mettraient en péril la cohérence de l’ensemble.
Par l’émetteur et le récepteur du message, pourvu que ce soit des domaines (les acteurspartenaires n’ont pas accès à la mémoire du système). 16 Les messages sont différents, parce qu’ils n’ont pas la même signification globale : l’information reprise pourra y être associée à d’autres informations, en fonction de ce sens global du message (celui qui fait de l’information complexe transmise, une information cohérente).
[16] Ce ne serait pas possible pour un acteur-partenaire. En effet, c’est le domaine qui reçoit une information nouvelle qui doit la mémoriser ; si plusieurs domaines la reçoivent, ils vont tous la mémoriser… ce qui créerait des redondances.
Même dans le cas où la finalité opératoire est Transporter. Les flux de matières décrits au départ (reçu par Transporter), et à l’arrivée (émis par Transporter) sont différents. Il faut des informations indiquant le lieu où se trouve la matière, et les problèmes éventuels de transport.
Cf. § 3.8.1.3 – Jusqu’où faut-il aller ?
Cf. § 3.5 – Plusieurs domaines ou un seul ?
Pour autant qu’on cherche à les décrire précisément…
Sinon l’unique catégorie de clients serait une constante du système, qui ne donne lieu à aucune représentation dans les modèles conceptuels (Cf. § 1.2.2 – De quelle couleur étaient les Ford T noires ?).
Un numéro, ou toute autre donnée dont une occurrence ne pourrait pas être associée à deux occurrences différentes du message.
Cf. § 6.2.4 – Association-type binaire non fonctionnelle (0, n) / (0, n) : message modélisé par une association-type
Nous ne donnons pas la description du message Catalogue émis : il suffit de reprendre celle de Catalogue, et de changer le récepteur. Les informations (complexes) transmises par ces deux messages sont identiques : c’est autorisé parce qu’ils ont le même émetteur (qui est donc le seul intervenant à les définir), et que les deux récepteurs en ont besoin
Elle sera une conséquence du Modèle Conceptuel de Communication.
Il y a forcément deux messages différents (Cf. § 4.3.4 – Une information ne peut pas être définie, et reprise, par le même message).
Celles reçues, et celles produites, par le système.
Cf. § 4.2.1 – Définition du message.
Un document n’est pas un message, mais la description d’un flux organisationnel (Cf. § 12.1.2.2.1 – Regroupement de plusieurs occurrences de message(s).
Cf. § 4.4.1.2.2 – Les informations définies par le domaine, sont ajoutées à la description du message reçu.
Au moins pour décrire d’autres concepts qu’un fournisseur et ses produits ; par exemple, un immeuble et les lots de copropriété qui le composent (Cf. § 6.2.3 – Association-type binaire fonctionnelle (1,1) / (1, n)).
Nous renonçons au concept de synchronisation dans le Modèle Conceptuel de Traitements, et considérons qu’un traitement ne peut être déclenché que par un seul message.
Cf. § 4.4.1.2.2 – Les informations définies par le domaine, sont ajoutées à la description du message reçu.
Il s’agit toujours de messages spontanés, faut-il le rappeler ?
Cf. § 4.5.1.1 – Un seul message pour décrire le fournisseur et ses produits.
Alternativement mais pas ensemble !
Cf. § 4.3.4 – Une information ne peut pas être définie, et reprise, par le même message.
Cf. § 4.3.4 – Une information ne peut pas être définie, et reprise, par le même message.
Définir un nouveau lien entre un N° produit et un N° catégorie dans ce message est impossible : ce serait une redondance par rapport au message Nouveau produit, qui définit ce lien.
Données simples, ou informations complexes.
Deux messages séparés engendreraient (dans notre démarche déductive) des descriptions redondantes de la mémoire ou des traitements.
Cf. Figure 1-1 : dépendance des différents modèles.
Ceux qui apparaissent dans la description schématique.
Cf. § 4.2 – Le message.
Voire davantage, cela dépend des choix de gestion.
Les deux choix de gestion sont possibles.
Cf. le principe fondamental énoncé au paragraphe 4.5.1.2.2.
Le déclenchement du traitement qui doit émettre ce type de message est un peu délicat. Il est traité au paragraphe 8.4 (échéance et absence de message).
En fait, c’est la première description de cette mémoire, indépendante des choix d’organisation et des choix techniques. D’autres descriptions, enrichies par rapport au Modèle
Conceptuel de Données, prendront en compte ces différents choix : ce sont le Modèle
