Capture des besoins en UML

Nous avons volontairement tourné cette présentation de façon générique et pas forcément strictement informatique afin de tendre vers SysML bien que nous nous limitions ici à UML.
En effet, UML a été créé pour répondre aux besoins de modélisation objet et à la génération de code informatique mais nous souhaitons aller plus loin que l'informatique et appréhender des systèmes complexes composés de logiciels mais aussi de hardware, de processus mécaniques, hydrauliques et autres, ce que nous verrons dans la partie SysML.

Objectif de la Capture des Besoins - 1

Avant de se lancer dans un projet il est nécessaire de bien comprendre dans quel périmètre il va se réaliser.
La capture des besoins consiste à :

• Identifier les fonctionnalités ou services que le système devra fournir à ses acteurs.
• Identifier l'ensemble des acteurs humains ou non qui participerons au fonctionnement du système.
• Définir la chronologie, le mode opératoire de chaque fonctionnalité ou service entre les acteurs et le système.
• Identifier le contexte technique, physique, légal, commercial, temporel dans lequel le système doit être réalisé.
• Cette phase permet la réalisation d'un cahier des charges pour appel et d'un cahier de recette.
  

Diagrammes / Outils / Langages Utilisés

Diagrammes utilisés :

• Use Case Diagram.
• Sequence Diagram.
• Deployement Diagram.
• State Diagram.
• Activity Diagram.

Outils utilisés :

• L'environnement de modélisation UML Rhapsody.
• Un traitement de texte.
• Un tableur.

Langages utilisés :

• UML 2.1.
• OCL.
  

Documents Collectés et Documents Livrés

Documents collectés :

Il est difficile de donner une liste précise des documents à collecter mais pour résumer il faut collecter un maximum de documents existants ou d'informations sur l'existant.
Tous les documents papiers et/ou informatiques en rapport avec le projet peuvent contenir une part d'information que le client ne soupçonne pas forcément.
Il est aussi intéressant quand c'est possible d'interroger les utilisateurs finaux du système car ils ne sont pas toujours impliqués dans le processus de conception.

Documents livrés :

Un cahier des charges contenant :
La liste et la description des acteurs qui interagissent avec le système.
La liste des fonctionnalités à livrer.
La description du fonctionnement dynamique du système.

Analyse du Métier

L'analyse du métier ou  de l'entreprise consiste en fait à essayer de s'imprégner le plus rapidement possible de la culture professionnelle dans lequel le projet sera réalisé.
Le métier dans lequel se développe le projet définit un ensemble de contraintes légales, financières, technologiques et culturelles.
La réalisation d'un projet dans l'aérospatiale, l'agroalimentaire ou le bâtiment impliqueront chacun des priorités et des aspects différents.
Bien comprendre le métier dans lequel doit s'insérer le projet c'est aussi bien comprendre les services qui doivent être rendus et comment.

Analyse de l'Infrastructure Technique

Il faut aussi comprendre le niveau technique des collaborateurs qui utiliseront et/ou maintiendront le système.
Ceci afin de donner au système le niveau de complexité et d'ergonomie adapté.
Ensuite, selon les fonctionnalités attendues et le niveau technique observé chez les collaborateurs, les manuels d'utilisation et les formations nécessaires pourront être définies.
L'état général des technologies collaborant au fonctionnement du futur système constituent elles aussi un élément important pour :
- Savoir quelle souplesse ou robustesse donner au projet.
- Préparer l'intégration du système dans son environnement.

Remarque sur la Méthode

Bien que nous séparons dans les diapos suivantes l'identification des fonctionnalités requises, des acteurs et des besoins techniques, il est bien entendu que ce sont dans la réalité des actions qui sont menées plus ou moins en parallèle.
En effet, l'identification d'un acteur peut révéler une fonctionnalité oubliée et réciproquement. De même, l'identification d'un besoin ou d'une contrainte technique peut révéler un acteur ou une fonctionnalité et réciproquement.
Cela n'empêche que les différents aspects peuvent être malgré tout exprimés dans des diagrammes et des documents clairs et distincts comme nous vous le proposons ci-dessous.

Remarque sur la Capture des Besoins

Les meilleurs résultats sont obtenus quand :

• Le consultant adopte une posture d'humilité et de curiosité maximum par rapport au sujet traité.

• Un maximum d'éléments sont identifiés dès le début, même s'ils doivent ensuite être supprimés car finalement pas liés au système à modéliser.

• L'ensemble des spécifications et contraintes identifiées durant la capture des besoins sont immédiatement liées aux éléments qu'elles concernent.

Nous vous conseillons de ne consulter le cours sur le langage qu'après la lecture des diapos qui vont suivre afin de mieux comprendre comment utiliser le langage que vous aller découvrir.

Capture des Besoins Fonctionnels

Le piège le plus courant consiste à apporter une réponse technique dès le début de la capture des besoins fonctionnels.
La capture des besoins fonctionnels consiste à définir les services que doit rendre le système en tenant compte des spécifications et contraintes qui lui sont liées, au métier, aux utilisateurs et exploitants.
La capture des besoins fonctionnels passe par :

• Une identification des acteurs primaires et secondaires.

• Une identification des use cases.

• Une définition de la dynamique du système par des diagrammes de séquence, d'état et d'activité.

• Une définition des contraintes et spécifications liées.

Identification des Acteurs

Il est important d'identifier TOUS les acteurs humains et non humains qui participeront au fonctionnement, à l'utilisation, à l'exploitation et à la maintenance du système. Ces acteurs seront ensuite répartis entre la branche fonctionnelle et la branche technique de 2TUP.
Il n'est pas ridicule d'identifier plus d'acteurs que nécessaire pour les faire ensuite disparaitre s'ils s'avèrent réellement inutiles au modèle.
Les acteurs identifiés seront ensuite listés et décrits dans le Use Case Diagram « UCD » puis dans un document textuel qui pourra être réalisé manuellement ou généré directement depuis l'environnement de modélisation (voir le manuel de votre environnement de modélisation).

Exemple : identification des Acteurs

Nous souhaitons modéliser le fonctionnement d'un Distributeur Automatique de Billets : DAB qui fonctionne pour tous les détenteurs d'une carte du réseau bancaire international.
Le DAB est régulièrement alimenté en billets et rouleaux de tickets par des convoyeurs de fonds
Il est contrôlé sur site et à distance par les techniciens de maintenance du réseau bancaire.
Il est parfois ouvert par les personnels de l'agence où il est installé.
Les niveaux en billets et tickets sont consultés automatiquement à distance  pour déclencher l'approvisionnement.
Toutes les opérations effectuées sur le DAB sont enregistrées localement puis transmises à la base de donnée centrale.

Ce diagramme ne fait que récapituler l'ensemble des acteurs nommés dans la description précédente.

Le DAB au centre est en fait une classe générique qui représente le système tel qu'il sera réalisé. C'est ce qu'on appelle une représentation Black Box du système.

Questions :

• Quels acteurs risquent fort de disparaître ou de se fondre durant la suite de l'étude ?
  
• Pourquoi ?
  
• Comment ?

Identification des cas d'utilisation

Piège courant : Il ne faut pas confondre « Use Case : UC » et bloc fonctionnel d'un système. Un UC du système pourra être réalisée par plusieurs blocs fonctionnels.
Un UC est une fonctionnalité du système.
Un UC peut être très général comme « Identifier utilisateur » ou très précis comme « Saisir mot de passe de 6 caractères ».
Il est généralement admit qu'une description contenant plus de 20 UC est trop complexe. Dans ce cas on essayera de redéfinir des UC plus génériques pour ne pas dépasser les 20 UC puis on créera des sous diagrammes pour préciser les UC trop génériques.

Chaque UC va être décrit dynamiquement par un « Sequence Diagram : SD » en mode Black Box dans cette première phase puis un SD détaillé en phase d'analyse.

Il est donc indispensable de se poser les questions suivantes :

• Quels évènements pourront le déclencher et dans quelles conditions ?
• Quel va être l'enchaînement principal de ce UC ?
• Dans quel état sera le système à l'issue de la réalisation de ce UC ?

Chaque UC fera l'objet d'un contrat de réalisation avec son ou ses SD associés il est donc aussi important de savoir dire clairement quel service va rendre ce UC au système et / ou aux acteurs.

Remarque sur les Diagrammes

Il ne faut jamais oublier que le but d'une modélisation est de fournir une vue claire et synthétique d'un système et qu'elle reste claire dans le temps pour des lecteurs non imprégnés du projet.
Il vaut toujours mieux plusieurs diagrammes clairs qu'un seul gros diagramme.
Les gros diagrammes servent à la consolidation et à la vérification de la cohérence des petits.

Les commentaires, contraintes et spécifications :

• Ils peuvent être ajoutés à tout élément des diagrammes ainsi qu'aux diagrammes eux-même.
• Ils sont tout aussi important que les diagrammes.
• Ils feront en SysML l'objet de diagrammes spécifiques.
  

Diagramme des Cas d'Utilisation

L'ensemble des acteurs et des UC identifiés sont venus peupler un « Use Case Diagram : UCD » générique qui doit être structuré pour fournir une vision claire des relations entre le système et les acteurs ainsi que des relations entre les UC.

Le UCD montre à la fois :

• les limites du système étudié.
• Les fonctionnalités attendues du système.
• Les interactions du système avec l'extérieur.

Il est intéressant quand c'est possible de créer plusieurs UCD qui représentent simplement les grandes fonctionnalités d'un système et un UCD général qui montre la complexité globale du système.
Typiquement dans un système informatique on trouve généralement un UCD pour l'utilisation de base du système, et les UCD techniques pour l'exploitation et la maintenance du système qui feront partis de la branche technique de 2TUP.

Exemple : Use Case Diagram

 Nous avons ici le diagramme de base des cas d'utilisation qui récapitule simplement les quelques fonctionnalités décrites plus haut dans notre exemple.

 La réalisation des diagrammes de séquences qui suivrons ainsi que le développement de l'analyse des besoins vont faire apparaître des sous cas d'utilisation, des points d'extension ainsi que des dépendances et des extensions entre cas d'utilisations qui viendront compléter le diagramme ci-contre.

De même, les acteurs seront probablement liés par des relations de généralisation qui vont préciser le diagramme sans le compliquer.

Question :

Quel(s) cas d'utilisation(s) vont très probablement être supprimé(s) durant l'avancement de l'étude ?

Diagramme de Séquence Black Box

L'identification des UC a déjà permis d'imaginer grossièrement le déroulement de chacun d'entre eux, et il faut maintenant pour chaque UC définir au moins le « Sequence Diagram : SD » de son déroulement normal.
Pour modéliser la dynamique des UC nous allons considérer le système en cours de définition comme une « Black Box : BB » et nous représenterons au minimum :

• L'évènement déclenchant du UC.
• Les interactions de base entre les acteurs et la BB.
• Les traitements clés dans le déroulement du UC.
• La référence à d'autre UC ou SD sera utilisé pour simplifier la lecture des SD et éviter la redondance.

Exemple : Sequence Diagram

Nous avons ici le sequence diagram  black box correspondant à l'enchaînement le plus simple du use case « retirer de l'argent ».

Vous remarquerez les flèches obliques pour les messages asynchrones et les flèches horizontales des opérations synchrones.

Contrairement à ce qui se trouve généralement dans la littérature UML les informations comme « afficherDemandeCode » ont été ici représentées comme un traitement interne au DAB, ce qui est la réalité, et non comme un message émis en direction du porteur de carte, ce qui est communément admis, mais faux si l'on respecte la sémantique d'UML.

Par ailleurs, nous ne voyons pas apparaître ici les arguments qui sont passés dans les messages comme « saisirCode » par exemple.

Question :

Comment amélioreriez-vous ce diagramme ?

Cohérence Séquence / Classe

Les premiers SD réalisés en mode BB sont extrêmement importants car ils vont être ensuite ré-utilisés durant tout le projet.
Pour cela il est plus efficace de créer ses SD dans un environnement de développement qui génère automatiquement les méthodes et évènements d'une classe générique nommée BB correspondant aux messages des SD.
De cette façon quand il faudra vérifier la cohérence des « Class Diagram : CD » en développant les SD initiaux de la capture des besoins dans des SD détaillés, les messages initiaux pourront être ré-utilisés sans recopie et sans oubli.

Exemple : Cohérence Séquence / Classe

 Comme nous pouvons le constater dans l'image de gauche, tous les messages qui ont été utilisés dans le diagramme de séquence précédent ont donné lieu à la création d'une opération synchrone et/ou d'un événement asynchrone dans le modèle.

Nous pouvons constaté que l'acteur « Base de donnée bancaire » dispose d'une opération « demandeAutorisation » en haut de l'arborescence qui est elle-même liée à l'évènement « demandeAutorisation » en bas dans la liste des évènements traités dans ce package.

 Vous pourrez observer la même chose pour l'ensemble des opérations synchrones et asynchrones de notre classe DAB qui modélise le système tel qu'il existera à la fin.

Question :

Que ce serait-il passé si nous avions représenté le message « afficherDemandeCode » par un message du « DAB » vers l'acteur « Porteur de carte bancaire » dans le précédent sequence diagramme ?

Contrats sur les Cas d'Utilisation

Le UC et son ou ses SD ne sont pas forcément d'une lecture évidente pour celui qui ne connaît pas UML et qui se retrouve seul devant ces diagrammes. Pour cette raison mais aussi pour contrôler la pertinence de l'analyse, le couple UC / SD associé est décrit dans un contrat qui servira de base à la recette finale du système.
Ainsi pour chaque UC nous résumerons textuellement :

• Titre du UC.
• Acteurs primaires et secondaires impliqués.
• Résumé du service rendu par le UC.
• Pré-conditions et Post-conditions du système.
• Évènements déclenchant et enchaînement de base.
• Enchaînement alternatif et exceptions.

Le Diagramme d'Etat ou d'Activité Black Box

Les SD représentent la dynamique particulière d'un UC mais il est parfois intéressant de représenter la dynamique globale du système par « State Diagramme : StD » ou un « Activity Diagram : AD ».
C'est une vue globale de la dynamique du système qui décrit les principaux états et les principales transitions du système.
Idéalement les transitions entre états ré-utilisent les messages déjà définis dans les SD mais cela n'est pas obligatoire ni systématique.
Le StD ou l'AD décrit ici n'a qu'un rôle strictement documentaire et ne sera pas utilisé comme d'autres pour générer du code ou des tests de système.

Exemple : Diagramme d'Activité

Ce diagramme d'activité modélise le fonctionnement global du DAB.
Il explique mieux la logique de fonctionnement global du système que les interactions avec les acteurs.
Bien qu' incomplet il a fait apparaître les notions de nombre d'essais et d'avalement  de la carte.
Il pourrait être amélioré par la prise en compte de contraintes temporelles sur les délais de saisie du code et de retrait des billets et de la carte.
Enfin, il pourrait être encore amélioré en disposant de deux points de terminaison distincts. L'un pour une annulation de transaction l'autre pour une fin normale de transaction.

Question :

Reproduisez ce diagramme et enrichissez le.

Capture des Besoins Techniques

La capture des besoins techniques regroupera tous les UCD, UC, SD et acteurs ayant un rôle strictement technique.
Par ailleurs, dans la branche technique nous définirons :

• La configuration matérielle de déploiement du système  : serveurs, cartes, réseaux, environnement etc... sera définie dans un « Deployement Diagram : DD ».
• L'organisation du déploiement des composantes pré-définies du système : séparation des données, des traitements, des interfaces d'acquisition, de restitution etc... sera définie dans un autre DD.
• Les différentes couches (3 tiers ou autre) du système, seront si nécessaire, définies par un diagramme de package.

Exemple de Diagramme de Déploiement

A gauche un exemple de la capture du contexte technique dans lequel l'application DAB devra s'intégrer.

Il n'y a pas dans ce diagramme de spécifications particulières mais les bases du contexte technologique du projet.

Les spécifications sur fond jaune montrent que le DAB lui même devra être conçu sur la base d'un automate bancaire pré-définit et que la base de donnée bancaire  comme le superviseur sont définis eux aussi selon des standards bancaires.

Question :

Qu'ajouteriez vous à ce diagramme dans le cadre de la capture des besoins techniques ?

Regroupement des Diagrammes en Packages

Plusieurs stratégies de regroupement des diagrammes sont possibles mais nous avons choisi ici d'utiliser la méthode 2TUP qui va nous servir de base de regroupement.

Exemple de Regroupements en Packages

L'extrait d'arborescence du modèle à gauche montre que l'ensemble des diagrammes de capture des besoins sont regroupés dans un package « Capture Des Besoins ».

Au plus haut niveau se trouve le container des classes avec le modèle Black Box du DAB, ses diagrammes d'activité et ses opérations.

Toujours au plus haut niveau se retrouve les évènements et les packages « Besoins Fonctionnels » et « Besoins Techniques » qui regroupent chacun les éléments qui leur correspondent.

On remarquera en bas un container pour les « Use Case Diagrams » qui contient le UCD général de tout le système. Ce UCD représente à la fois les UC et les acteurs des branches fonctionnelles et techniques.

Question :

Comment organiser le ou les packages de la prochaine phase d'analyse ?

Remarque sur l'Organisation du Modèle

Idéalement, il faudrait pouvoir rattacher les diagrammes de séquences relatifs à un Use Case directement sous le Use Case.
Rhapsody ne propose pas de créer les diagrammes de séquence directement dans l'arborescence des Uses Cases, en revanche, il permet d' y faire référence et c'est très important pour bien décrire le fonctionnement d'un Use Case.
Vous remarquerez que l'outil Rhapsody utilisé pour ce cours regroupe systématiquement les entités UML dans des containers ce qui n'est pas le cas de tous les environnements de modélisation.

Exercice

Vous allez maintenant mettre en pratique ce que nous venons d'étudier afin de présenter une étude des besoins complète sur le thème d'une caisse enregistreuse fonctionnant ainsi :

• Le client arrive à la caisse avec des articles.
• Le caissier enregistre le code barre et la quantité de chaque article et la caisse affiche le libellé et le prix.
• Quand tous les articles sont saisis le caissier demande le total que la caisse affiche.
• Le client peut fournir au caissier des tickets de remise que le caissier enregistre et qui modifie le total.
• Le client paye en liquide, par chèque ou par carte.
• Le caissier lui remet le ticket et attend le client suivant.
• Quand le caissier encaisse le règlement du client le stock est décrémenté de l'ensemble des articles payés.

Questions

• Pourquoi utiliser UML ?
• Qui utilise UML ?
• Que représente les acteurs ?
• Que représente les Uses Cases ?
• Qu'est ce qu'un Use Case Diagram ?
• Qu'est ce que le mode Black Box ?
• Comment représenter la dynamique d'un Use Case ?
• Comment représenter la dynamique d'un système ?
• Comment représenter l'environnement technique d'un projet ?
• Quelle attitude et quelle méthodologie pour arriver à une bonne définition des besoins ?

Projet

Vous allez modéliser une carte de télémaintenance qui sera implantée dans des machines à café existantes dotées d'un automate communicant via une RS232 selon le protocole suivant :

• Toutes les 2 secondes l'automate émet une chaîne de caractères dont la syntaxe sera décrite plus tard.
• La chaîne de caractère contient toutes les valeurs de mesures de l'automate.

L'automate mesure puis émet :

• Une ou plusieurs mesures de température et de pression (bornées sur la carte par un seuil haut et un seuil bas).
• Une ou plusieurs valeurs de compteur de doses d'eau et de capsules de boisson (bornées sur la carte par un seuil d'alerte et un seuil d'arrêt).

La carte de télémaintenance devra :

• Enregistrer localement toutes les mesures émises par l'automate dans un fichier de taille finie.
• Émettre par email pour une liste de destinataires fixe, à fréquence fixe et sous forme de tableau, les mesures enregistrées.
• Émettre par email pour une liste de destinataires fixe, des rapports d'alerte dès que les seuils d'alerte paramétrés sont dépassés. Nous distinguerons des alertes techniques pour une liste de destinataires techniques et des alertes d'approvisionnement pour une autre liste de destinataires.
• Recevoir par FTP des fichiers de configuration pour définir, le format de la chaîne de caractère à traiter, les différentes listes de destinataires, les différents seuils d'alerte, les fréquences d'envoi des rapports et tous les autres paramètres de configuration.
• Transmettre en temps réel la chaîne de caractère émise par l'automate à des techniciens connectés à distance par une session sécurisée SSH.
• Permettre au technicien de se connecter directement sur la carte quand il est sur site sans altérer son fonctionnement normal.

Vous devez réaliser toute la phase de capture des besoins fonctionnels et techniques à partir de l'énoncé précédent.

Vous serez évaluez sur :

• Votre capacité à innover et à créer.
• Le respect de la norme UML 2.1.1.
• Les diagrammes de cas d'utilisation.
• Les diagrammes de séquences.
• Les contrats de Use Cases.
• Les diagrammes de déploiement.
• L'organisation de votre modèle.
• La clarté de vos documents.
• La couverture fonctionnelle de votre projet.

Chacun doit se noter sur 20 en donnant ses points forts et ses points faibles, nous corrigerons si nécessaire.