L’état des lieux

Ce chapitre aborde la description des processus : c’est souvent une des premières tâches que l’analyste du métier entreprend. Il n’est pas obligatoire de procéder ainsi.

Le langage de modélisation UML est destiné à fournir aux architectes système, ingénieurs et développeurs logiciels des outils d’analyse, de conception et d’implémentation de systèmes (« The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes. » OMG Unified Modeling Language V2.5).

Ces outils sont des diagrammes qu’UML répartit en deux familles :

les diagrammes structuraux (destinés à décrire la structure des éléments) ;
les diagrammes comportementaux (destinés à décrire le comportement des éléments, autrement dit d’en avoir une vision dynamique et fonctionnelle).

Une partie de ces diagrammes sera utilisée pour spécifier la solution attendue chez LOCA’ROYANS.

Spécifier une solution informatique nécessite d’en fournir quatre descriptions :

la description dynamique ;
la description fonctionnelle ;
la description structurelle ;...

La notion de processus

Un processus est un ensemble coordonné des actions, réparties entre acteurs et étalées dans le temps, devant fournir un résultat tangible à un acteur. Ce résultat est la raison d’être du processus. Un processus est initié par un événement (dit déclencheur), qui lui est externe ; il cesse lorsque le résultat attendu est fourni, à moins qu’une rupture anormale interrompe son exécution (cas d’erreur)

Cette vue dynamique répond à la question : « comment les acteurs utilisent-ils (ou utiliseront-ils) la solution dans le cadre de leur métier ? » ou « comment les acteurs vont-ils se servir de la solution à construire ? »

La vue dynamique s’exprime en UML à l’aide du diagramme d’activité (activity diagram). Ce diagramme fait partie des diagrammes destinés à décrire le comportement de la (future) solution. Il est très bien adapté à décrire les processus supportés par le futur système, même si certains peuvent penser que cet outil n’est pas le meilleur pour cela et lui préféreront un diagramme BPMN (Business Process Model and Notation).

La représentation formelle de processus : trois niveaux

Le nom francisé du processus, en UML, est activité (pour activity en anglais, son nom original). Ci-après est représenté un processus simple : fournir Client, selon trois niveaux de détail à l’aide du diagramme d’activité UML.

Cet exemple permet de mettre en évidence les composants fondamentaux d’un processus tel que vu par UML.

1. La représentation minimaliste

Figure 2 : Représentation minimaliste du processus fournir Client

Cette représentation montre la décomposition du processus en un ensemble d’actions élémentaires se déroulant selon un ordre précisé (séquence d’actions). Ces actions élémentaires sont reliées par des flux de contrôle (control flow).

Un processus a un début, une fin nominale, et peut avoir plusieurs fins exceptionnelles qui ne sont atteintes que sous certaines conditions. Dans cet exemple, la fin exceptionnelle est atteinte si le client n’est pas satisfait du devis qui lui est proposé. Il y a donc deux chemins, mutuellement exclusifs, dont le parcours est contrôlé par un test. Ce test est porté par le nœud de décision : Décision client.

Figure 3 : Nœud de décision

Le processus est déclenché par un événement : c’est ce qu’indique le nœud début.

Le nœud de décision peut comprendre n flux de contrôle d’entrée et n flux de contrôle sortie : cela traduit qu’un nœud de décision, portant un test, offre plusieurs possibilités et donc que le test peut présenter plusieurs réponses. Le processus étant déterministe, il est impératif d’indiquer, sur chaque flux de contrôle, à quelle condition il est activé...

L’identification des processus d’une entreprise

Quels sont les processus que la future solution va supporter ? Quels sont les processus qui doivent être pris en charge par le futur système ?

Ce sont deux caractéristiques fondamentales d’un processus (ses événements déclencheurs, les biens ou les services fournis) qui vont permettre ce travail d’identification. Ces biens ou services étant la raison d’être de l’entreprise, il est impératif que l’analyste les connaisse.

1. Le bien ou le service fourni

Quels sont les biens livrés ou les services rendus au client de l’entreprise LOCA’ROYANS ? Répondre à cette question, c’est invoquer la finalité de LOCA’ROYANS, sa raison d’être, sa justification. Quel est son métier ? De quoi tire-t-elle ses revenus ?

M. Centplont est très clair à ce sujet : la mise à disposition auprès de ses clients de véhicules de tourisme ou utilitaires.

Quels sont les processus qui concourent à la mise à disposition d’un véhicule auprès des clients ?

Donc, tout bien ou service fourni à un client est le résultat d’un processus.

2. Les événements déclencheurs

Quels événements seraient susceptibles de déclencher la livraison d’un service ? La réponse à cette question est à chercher dans les interactions entre l’entreprise et son environnement, c’est-à-dire entre les personnes morales et physiques ayant affaire à elle. Des entreprises, des personnes physiques sont clients, ou fournisseurs, de LOCA’ROYANS.

Les autorités, essentiellement fiscales...

Quelques processus de LOCA’ROYANS

Ci-après sont mentionnés quelques processus que l’analyste du métier a identifiés :

Bien ou services fournis	Événements déclencheurs	Nom du processus
Voiture mise à disposition du client	Le client demande à louer un véhicule	louer Véhicule
	Le client restitue le véhicule	restituer Véhicule
Contrat d’embauche signé, nouveau collaborateur installé	Publication de poste	embaucher Collaborateur
Le véhicule est cédé et la trésorerie créditée	Le véhicule a franchi le 75 000e kilomètre	céder Véhicule

Tableau 2 : Identification de quatre processus de LOCA’ROYANS à partir des services fournis et des événements déclencheurs

1. Le processus louer Véhicule

a. La description littérale

Cette description a été rédigée suite à une séance de travail avec un expert du métier.

Un client se présente à l’agence et demande à louer un véhicule.

L’hôtesse lui propose le catalogue des véhicules disponibles et l’aide dans son choix : gamme ? Options ? Assurance ? Le choix étant posé, elle vérifie que le client est connu. Si non, elle crée la fiche du client et l’enregistre dans la base. Si oui, elle rédige un contrat (un projet de réservation) avec les dates de prise en charge et de restitution du véhicule ; elle précompte (à l’aide de la carte bancaire du client) le montant de la location, ainsi que le montant de la caution. Éventuellement, elle saisit l’option d’assurance (rachat franchise seule, rachat franchise et secours et assistance dépannage). Ces premières étapes étant réalisées, le véhicule est réservé : il ne peut plus être proposé à la location.

Le garage est averti dès qu’un véhicule est réservé ; en principe, un véhicule ne peut être loué (il est visible au catalogue) que si son entretien a été réalisé (les réparations éventuelles effectuées)....

Le cycle de vie des objets du métier

Lorsque le processus se déroule, chaque acteur réalise les actions qui lui sont imparties. Cela a pour effet de faire franchir des étapes dans la vie des objets du métier.

Ainsi, le véhicule est disponible, choisi, réservé, contrôlé, sous la responsabilité du client, en réparation, puis à nouveau disponible.

Énumérer les étapes de la vie d’un objet du métier, c’est énoncer le cycle de vie de cet objet.

Le chapitre Description dynamique (l’information se transforme) est consacré au cycle de vie des objets du métier.

Le diagramme d’activité représente les états des objets qui circulent entre les actions : ces états sont tous mentionnés dans le cycle de vie de chaque objet.

Le référentiel UML du projet

Chaque élément de modélisation représenté dans un diagramme est la représentation graphique d’un objet mémorisé dans une base de données. Cette base de données est appelée référentiel de modélisation du projet. Ce référentiel projet mémorise tous les éléments UML utilisés pour formaliser le système.

Les référentiels de projet sont nombreux : il peut y avoir des référentiels de suivi, d’anomalie, d’avancement...

Il est important de comprendre qu’un diagramme UML ne fait que publier un sous-ensemble des informations mémorisées (et organisées) dans le référentiel de modélisation projet.

Le modèle UML n’est pas constitué par ses diagrammes, mais par cette base de données qu’est le référentiel projet. Ainsi, le même élément d’information peut être représenté dans plusieurs diagrammes.

Exemple : action

Signer proposition est une action à la charge de l’acteur Client ; voici comment elle est symbolisée dans le référentiel du projet :

Figure 19 : Vue partielle du référentiel projet (Signer proposition, Choisir Véhicule)

Le référentiel...

Pour aller plus loin

La documentation UML est éditée par l’Object Management Group. Elle est librement téléchargeable.

Elle est exhaustive, aussi il faut sélectionner les pages utiles et les étudier de manière itérative. UML décrit d’abord les concepts, puis, via un chapitre intitulé Notation, décrit les diagrammes.

Voici une liste de questions qui peuvent être abordées pour une utilisation plus large d’UML :

Une activité est définie par UML comme un comportement (behavior) spécifié sous forme d’un graphe de nœuds interconnectés par des liens (edges).
Les nœuds sont subdivisés en trois sous-ensembles : les nœuds exécutables (executable nodes), les nœuds d’objets et les nœuds de contrôle ; si bien qu’on peut dire qu’une activité est un moyen de traiter et de contrôler des flux de données. Les seuls nœuds exécutables en UML sont les actions.
Une activité peut être paramétrée, la valeur du ou des paramètres gouvernant l’exécution. Il est également possible de spécifier des préconditions et des postconditions d’une activité. Ainsi, les objets fournis en sortie de l’activité (du processus) sont portés par un paramètre...

À retenir

Le processus formalise un acte métier complexe, mobilisant plusieurs acteurs, fournissant un bien ou un service au client, et déclenché par un événement métier. La vision processus est une vision « grosse maille » du métier.

Les actions sont confiées à des acteurs qui manipulent de l’information. Une action n’est pas interruptible, est monoacteur, s’exécute entièrement, ou pas du tout : une action est une transaction métier.

La description détaillée des actions fournit la vision « fine maille » du métier : c’est l’objet de la description des cas d’utilisation (le cœur de la vue fonctionnelle) de fournir cette vision fine du métier.

L’information manipulée par une action est constituée d’instances de concepts du métier ; une action consomme une ou plusieurs de ces instances, et en fournit une ou plusieurs.

L’enchaînement entre les actions n’est pas obligatoirement synchrone (enchaînement asynchrone).

Les prochaines étapes

La description fonctionnelle va permettre d’affiner la description du métier en dégageant les services rendus par le système aux acteurs : UML met à disposition les cas d’utilisation et le diagramme correspondant pour entamer cette description

La mise en œuvre des cas d’utilisation est décrite dans la vue fonctionnelle.

La description structurelle va reprendre les concepts du métier et les décrire sous forme de classes ; UML met à disposition le diagramme de classes, le diagramme de composants pour entamer cette description.

La mise en œuvre des classes et composants est décrite dans la vue structurelle. Pour ceux qui connaissent un peu le concept de programmation objet, les propriétés membres des classes sont déduites de la description des cas d’utilisation, tandis que les méthodes membres sont déduites de leur cycle de vie.

Description dynamique (les acteurs agissent)