Description collaborative du système

L’état des lieux

La description dynamique du système a révélé comment le métier en tirait parti pour réaliser sa mission. Cette description prend en compte tous les acteurs intervenant au cours d’un processus. Le formalisme UML (diagramme d’activité) est une manière souple de traduire la collaboration des acteurs au sein de l’entreprise.

De façon à exercer leur métier, les acteurs sollicitent le système, qui leur répond sous forme de services rendus : c’est le but de la description fonctionnelle (sous forme de cas d’utilisation) de formaliser ces services.

Le système agit sur l’information ; celle-ci est portée par les entités fortes du métier (celles de l’entreprise LOCA’ROYANS sont les véhicules, le dossier de location, le catalogue...). La spécification de ces entités est confiée à la description structurale (classes, composants, associations). C’est cette description structurale (à l’aide de diagrammes de classes, et accessoirement de composants) qui est l’ébauche de la structure du système lui-même. Il ne faut pas oublier un principe fondamental : les entités du métier sont à l’origine des composants techniques du système. La conception logicielle transforme les entités...

La notion de comportement

Le comportement (behavior) du système est sa capacité à « faire quelque chose ». Il y a comportement dès lors que des valeurs de propriétés sont modifiées selon une dynamique interne ou qu’un flux d’informations est envoyé. Un comportement rend compte d’un changement dynamique du système. Ce changement résulte d’un événement, qui déclenche « quelque chose ».

On retrouve les notions de déclencheur (trigger) et d’événement (event), connues des praticiens des bases de données.

Un événement UML peut être (entre parenthèses est décrit un exemple de comportement déclenché par cet événement) :

le changement de valeur d’une propriété (par exemple, le kilométrage de la voiture atteignant 35 000 km, la procédure de cession et de remplacement est déclenchée) ;
un intervalle de temps (par exemple, tout client n’ayant rien loué chez LOCA’ROYANS depuis deux ans se voit proposer des tarifs promotionnels sur la gamme professionnelle) ;
le déclenchement d’une fonction (lors de la procédure d’entretien, l’audit électronique du véhicule provoque la purge du journal des événements) ;
la réception d’un signal (un signal est une information envoyée et reçue ; par exemple, le garage est informé que la voiture XYZ est réservée par M. Lahaie à partir du 6 janvier 9 h 00).

Donc un événement provoque, ou modifie, un comportement. Tout le problème est de connaître la cible de cet événement : quel composant va être capable d’y répondre, c’est-à-dire de modifier son comportement.

1. Spécifier un comportement en UML

UML propose trois outils de spécification des comportements.

Les deux premiers sont les machines à états et les activités. Ce sont des moyens puissants de modéliser des comportements. La figure 2 propose de modéliser le comportement : « le kilométrage de la voiture atteignant 35 000 km, la procédure de cession et de remplacement...

Les concepts UML en jeu

1. L’interaction, le fragment combiné, la ligne de vie, l’appel d’interaction (interaction use)

Une interaction est une sorte de comportement et représente essentiellement les échanges d’informations entre des instances connectées entre elles. Ces échanges sont repérables : ils font partie du système et sont implémentés soit sous forme d’événement, soit sous forme de signal.

Les instances échangeant ces informations sont représentées sous forme de lignes de vie (lifeline). La différence entre instance et ligne de vie selon UML est subtile : les instances peuvent être multiples, alors que la multiplicité d’une ligne de vie est nécessairement 1 ; et les attributs des instances sont nécessairement valorisés, alors qu’une ligne de vie n’a pas de valeur d’attribut.

En conséquence, si une interaction nécessite la collaboration de plusieurs instances quelconques de la même classe (exemple : deux agences qui s’unissent pour répondre à un besoin spécifique du client), UML impose de la représenter au moyen de deux lignes de vie distinctes (représentant les deux agences), et non au moyen de deux instances. Car choisir deux instances imposerait de les nommer, alors que les lignes de vie n’ont pas besoin de l’être, puisqu’elles n’ont pas de valeur d’attribut. C’est le moyen de montrer que cette collaboration se réalise grâce à une interaction entre deux agences quelconques, entre deux instances quelconques de la classe Agence, et peu importe lesquelles.

On dira que la ligne de vie fait référence à la dynamique de chacune des deux instances, alors que les instances font référence aussi bien à la structure qu’à la dynamique.

Cette subtilité permet de préciser la nature réelle d’un comportement.

Un fragment combiné est une interaction pilotée par un opérateur (alt, loop, seq...). Les fragments combinés prennent place au sein d’une interaction dans la mesure où un fragment combiné est une région délimitée de cette interaction. Concrètement, cela veut dire que le fragment...

Pour aller plus loin

UML propose une palette d’outils d’une très grande richesse pour modéliser les comportements. La documentation officielle UML (issue de l’OMG) offre une description détaillée, même si elle n’est pas toujours d’une clarté suffisante pour des praticiens.

L’alternative consiste à se référer aux documentations des outils de modélisation. Mais il est à noter que les spécifications officielles d’UML vont plus loin que beaucoup d’outils de modélisation.

Les sujets suivants pourraient être approfondis :

les chapitres UML décrivant les comportements (Common Behavior) et les interactions, notamment la modélisation UML de ces notions ;
la taxonomie des différents diagrammes comportementaux proposés par UML.

UML propose deux familles de diagrammes : les diagrammes structuraux et les diagrammes comportementaux. Les diagrammes décrivant la structure du système ne font pas référence au temps : la dynamique des composants est hors sujet. À l’inverse, les diagrammes comportementaux s’intéressent aux changements du système dans le temps.

Cet ouvrage propose une perspective différente. Les principales différences se résument ainsi :

La description dynamique prend en charge les interactions entre...

Conclusion

La perspective classique de la modélisation métier (business modeling), basée sur une unique vision processus, n’est plus suffisante. Il faut intégrer dans les analyses du métier les interactions avec l’extérieur. L’entreprise est confrontée à des changements majeurs imposés par l’arrivée du numérique dans les pratiques professionnelles, qui modifient ses pratiques commerciales.

C’est devenu banal : toute recherche d’un bien ou d’un service consommable lancée par un internaute est mémorisée, transmise (grâce aux cookies), puis traitée si bien que l’espace publicitaire du portail fréquenté par la personne affiche les propositions de tel ou tel fournisseur de ce bien ou de ce service, ou affiche des promotions en rapport avec les pages visitées.

Chaque personne physique est donc double source d’informations :

source active lorsqu’elle émet, via un réseau social, un simple avis, une interrogation, ou lance une alerte ;
source passive lorsque le canal, par lequel elle explore puis éventuellement commande, surveille son parcours, ses choix et les recueille pour les expédier à un collecteur qui saura les exploiter et les revendre.

Étant source d’informations, cette personne va en retour recevoir des informations...