UML2 par la pratique

Chronique du webmaster - UML2 par la pratique
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, moyenne: 5,00/5)
Loading...

UML2 par la pratique, de Pascal Roques

UML2 par la pratiquePhrase-résumée du livre :
“Il devient de plus en plus accessible de créer des projets informatique (applications, sites internet, logiciels), néanmoins, parfois difficile de savoir par où commencer ?
Il existe un langage permettant de mettre toutes ses idées au clair, utilisable par des personnes techniques et celles qui ne le sont pas. Celui-ci permet de faire un énorme travail avant de commencer à écrire une seule ligne de code et permet de réduire le risque d’erreurs ou d’oublis de plus de 70% (mon avis personnel).
Plus efficace qu’un Cahier des charges rempli de mots, l’UML permet de décrire des systèmes complexes de manière simple sous forme de schémas, tableaux ou de courtes descriptions.
Un atout majeur pour les personnes techniques, tout autant que pour celles qui ne le sont pas.”

Kelvin

Livre de Pascal Roques, 395 pages, publié en 2015.

Le résumé du livre

Consultant sénior et formateur chez A2 – Artal Innovation, Pascal Roques a plus de vingt ans d’expériences dans la modélisation de systèmes complexes (SAT, OMT, UML, SysML…). Il a ainsi été responsable de des formations Valtech Training sur le thème « Analyse, conception et modélisation avec UML » pendant de nombreuses années. Auteur de plusieurs livres consacrés à UML et SysML aux éditions Eyrolles, il a obtenu la certification OMG-Certified UML Advanced Professionnal proposée par l’OMG.

Note : tout au long de ce résumé de livre, je vous mettrai à disposition des illustrations et des diagrammes. Pour la réalisation de celles-ci, je me suis servi d’un logiciel en ligne gratuit et super pratique : Draw.io. Il devient facile et rapide de créer des schémas et plein d’autres rendus graphiques cool. Vous trouverez d’autres logiciels en ligne et gratuits sur ma page : La boîte à outils du webmaster.

Il existe 3 axes de modélisation

L’auteur nous accueille avec l’introduction des différents axes de modélisation, suivi des diagrammes correspondant.

Note : Ne vous inquiétez pas pour tous les noms de Diagramme qui apparaissent ci-dessous. Je vous donnerai la description au fur et à mesure du résumé de ce livre des plus importants. Pour les autres, je vous conseille de lire le livre, mais ils ne sont pas à connaitre en priorité.

  1. Le premier permet de définir tous les aspects fonctionnels du système que nous souhaitons créer, avec comme outils :
    • Diagramme de Cas d’utilisation
    • (Diagramme de Séquence)
    • (Diagramme d’Activité)
  2. Le second, nous accompagne pour structurer toute la partie statique, soit le fonctionnement des données et l’architecture du système en soi. Nous avons pour cela :
    • Diagramme de Classes
    • Diagramme de Packages
    • (Diagramme d’Objets)
    • Diagramme de Structure Composite
    • (Diagramme de Déploiement)
  3. Pour finir, nous avons la partie dynamique, ce qui représente les enchainements d’actions (ou flux d’informations) effectués dans notre système.
    • Diagramme d’États
    • Diagramme d’Activité
    • Diagramme de Séquence
    • (Diagramme de Communication)

Cela en fait des diagrammes à connaître, mais ne vous inquiétez pas, l’auteur explique chaque chose en son temps avec des exemples concrets. Nous commençons tout de suite par…

Définir les besoins d’un point de vue fonctionnel

Mais avant tout, il nous faut avoir quelques notions pour bien avancer dans l’exemple proposé plus bas par l’auteur. Regardons la…

Définition des mots clés

  1. Acteur
    Un acteur représente un élément (machine ou vivant) pouvant intervenir avec le système que l’on étudie :
    – Si celui-ci est humain, l’auteur conseille d’utiliser la forme d’un Stickman (voir image, à gauche)
    – Sinon, nous utiliserons un rectangle avec le nom de l’acteur sous la forme : « Acteur » Nom de mon acteur. (voir image, à droite)UML Acteurs
  2. Cas d’utilisation
    Un cas d’utilisation (aussi appelé « use case », en anglais) est une fonction que l’on attend de notre système. Nous dressons la liste de ce que notre système doit pouvoir faire, mais sans définir comment.
    Le “Diagramme de cas d’utilisation” est un schéma dressant la liste des cas d’utilisation (ovales), reliées par des associations (traits) à leurs acteurs (sitckman / « acteur »).
    Cela prend la forme suivante :
    UML Diagramme d'utilisation
  3. Scénario
    Un scénario est une succession d’événements avec un début et une fin. Un cas d’utilisation est composé de plusieurs Scénarios, un nominal (fonctionnement normal attendu), plusieurs alternatif (pour ajouter des fonctionnalités) et des erreurs (afin de gérer les problèmes qui pourraient survenir).
    Voici donc les scénarios possibles entre le “début” et la “fin normale” d’un cas d’utilisation :
    UML Scénarios

Maintenant que ces mots clés sont précisé, nous allons tout de suite rentrer dans le sujet et…

Décrire le système souhaité avec des phrases

La première chose est de définir le système que l’on souhaite étudier et de dresser la liste des services que l’on souhaite fournir avec celui-ci. Pour cela, rien de mieux qu’un exemple pour que cela soit plus explicite.

Pascal Roques, l’auteur, prend comme exemple la version simplifié d’un distributeur de billet, un Guichet Automatique de Banque (GAB).

Un distributeur de billets est un excellent exemple pour montrer l’importance d’utiliser UML.

 

Distributeur de bill... de liquide :D
Distributeur de bill… de liquide 🙂 (Histoire de bosser sans pression)

Alors, voyons ensemble ce que doit permettre notre Guichet Automatique de Banque (GAB) :

  • Emettre de l’argent si je suis Porteur de carte de crédit
  • Consulter mon compte et déposer de l’argent, si je suis Client banque

Sans oublier que :

  • Les transactions sont sécurisées
  • Le distributeur doit être parfois rechargé

De là, l’auteur nous indique que nous allons pouvoir…

Identifier les acteurs qui interagissent avec le système

La deuxième étape consiste à définir la liste d’absolument touts les acteurs pouvant intervenir sur notre système.
Dans le cas d’un GAB, nous retrouvons donc :

  • Un utilisateur muni d’une carte (appelé Porteur de carte) => Humain
  • Un client de la banque du distributeur munis d’une carte (appelé Client banque)  =>Humain
  • Le système d’autorisation (pour contrôler que la carte est valide) => Non humain
  • La banque (pour consulter son compte en tant que Client) => Non humain
  • L’opérateur (pour dépannage et remplir/vider le distributeur) => Humain

Ce qui nous donne un premier jeu d’acteurs :

UML GAB Acteurs

Nous allons ensemble les placer dans le contexte de notre GAB. Dans ce que nous appelons un Diagramme de Contexte statique :

UML GAB Diagramme de contexte statique

Note : Mais sachant qu’un Client banque muni d’une carte est implicitement un Porteur de Carte, celui-ci disposera des mêmes informations et possibilités. De ce fait, nous indiquons par une flèche qu’un Client banque « est » un Porteur de Carte. Néanmoins, un Porteur de carte n’est pas forcement un Client Banque.

Nous pouvons donc affirmer qu’un Client Banque est un profile spécial de Porteur de Carte. Client Banque est donc une « spécialisation » de Porteur de Carte.

Ce qui nous donne :

UML GAB Diagramme de contexte statique avec héritage

Maintenant que la liste des acteurs est définie, c’est le moment pour…

Identifier les cas d’utilisation

De la liste des acteurs, l’auteur annonce les utilisations possibles pour chacun pour la forme “Verbe d’action à l’infinitif + détails” :

  • Porteur de carte
    • Retirer de l’argent
  • Client banque
    • Retirer de l’argent (à ne pas oublier !)
    • Consulter ses comptes
    • Déposer de l’argent (chèques ou espèce)
  • Opérateur
    • Recharger le distributeur
    • Maintenir le GAB
  • Sys. autorisation
    • Néant
  • Banque
    • Néant

Ça, c’était la version texte, voyons ensemble comment le transcrire avec la…

Réalisation des diagrammes de cas d’utilisation

Comme cité plus haut, maintenant que nous avons listé la liste des cas d’utilisation, voici le moment de les mettre sous forme de diagramme :

UML GAB Diagramme de cas d'utilisation

On comprend ainsi en un coup d’oeil les cas d’utilisation possibles par chaque acteur. Il va nous falloir à partir de maintenant ajouter des détails avec la…

Description textuelle des cas d’utilisation

A partir de maintenant, nous allons définir pour chaque cas d’utilisation sa description détaillée. UML ne fournissant pas de normes à respecter sur la manière de les écrire, l’auteur nous donne le modèle modèle suivant :

  • Sommaire d’identification
    • Titre du cas d’utilisation
    • Résumé de celui-ci
    • Acteurs impliqués
    • Date de création & Date de mise à jour
    • Version du document
    • Responsable en charge de sa création
  • Description des scénarios
    • Pré-conditions pour que le cas d’utilisation puisse être lancé
    • Scénario nominal de ce cas d’utilisation
    • Enchaînements alternatifs possibles
    • Enchaînements d’erreur à prendre en compte

Note : J’ai créé un fichier en ligne qu’il ne vous reste plus qu’à remplir.

Cliquez ici pour accéder a une version Google Doc téléchargeable gratuitement
UML Description textuelle d'un cas d'utilisation

 

Chaque description textuelle permet de détailler au maximum un de nos cas d’utilisation. Cela permet de n’oublier aucun élément. Cela semble long à première abord et … Vous avez raison 😉 Néanmoins, c’est une étape cruciale même si celle-ci demande du temps et de la concentration. Une fois cette étape passée, la marge d’erreur devient minimum et vous gagnerez Beaucoup de temps par la suite (oui, Beaucoup avec un grand B)…

Déceler un problème avant le début du développement demande un peu de réflexion. Corriger un problème après le début de la programmation devient un réel problème, car cela prend beaucoup de temps, de l’argent et risque de rendre l’application (le projet) instable.

Donc, c’est une étape fastidieuse, mais à faire sérieusement.

Description graphique des cas d’utilisation

Maintenant que les descriptions sont posées sur la papier, on se rend compte que c’est détaillé, mais qu’il est difficile de s’y retrouver facilement. Nous allons pour cela ajouter une description plus graphique afin de renforcer notre documentation écrite.

Pour cela, nous allons nous aider de 2 types de schéma (diagrammes) :

  • Le Diagramme de séquence
  • Le Diagramme d’activité

Commençons avec…

Le diagramme de séquence

Le diagramme de séquence nous permet de mettre en évidence le rôle de chaque acteur et les échanges (messages) entre chacun d’entre eux. Il devient beaucoup plus facile de comprendre la responsabilité de chaque Acteur et ce qu’il attend des autres.

UML Diagramme de séquence
On retrouve par exemple notre acteur humain en train envoyer un message à notre système. (Ce message peut être une question ou un ordre). De là, notre système peut simplement envoyer une réponse ou lui aussi envoyer envoyer un message, comme dans l’exemple ci-dessous à un autre acteur (ici : Acteur non humain). Il est possible d’ajouter des détails (ce que l’on appel des “paramètres” en programmation) pour accompagner nos messages ou réponses.

Les échanges se déroule chronologiquement du haut vers le bas.

Dans l’exemple utilisé par l’auteur, cela nous donne dans le cas d’utilisation “Retirer de l’argent” :

UML GAB Diagramme de séquence - Retrait d'argent

Le diagramme d’activité

Le diagramme d’activité nous permet quand-à lui de mettre en évidence le déroulement de chaque étape dans notre système. On y retrouve de manière graphique la liste des actions. Il devient du coup beaucoup plus simple de comprendre le cheminement de l’utilisateur (ou de l’information) au sein de notre système.

UML Diagramme d'activité

Dans l’exemple utilisé par l’auteur, cela nous donne dans le cas d’utilisation “Retirer de l’argent” :

UML GAB Diagramme d'activité

Cela demande un peu de temps avant de créer un diagramme comme ça, mais cela rend le fonctionnement beaucoup plus clair. Nous pouvons ainsi comprendre à chaque étape les possibilités que le système permet. Cela permet aussi de mettre en lumière des possibilités qu’il faudrait ajouter par exemple.

Note : Comme vous pouvez le voir, pas besoin d’être quelqu’un de technique pour comprendre le fonctionnement de notre système. Néanmoins, si vous êtes technique, vous pouvez vous rendre compte (comme je me suis rendu compte) que c’est extrêmement proche de la programmation, ce qui rend ces Diagrammes entièrement exploitables pour créer un produit numérique (application, logiciel, site internet, etc.).

Les autres descriptions possibles

Il faut savoir qu’il est possible de détailler toujours plus, l’auteur nous montre d’ailleurs très bien comment faire. Pour ma part, je pense que pour un résumé, le niveau de détail actuel suffit pour une première utilisation. Dans le cas d’un développement plus poussé,  je vous conseille de vous référer au livre 🙂

L’auteur nous montre aussi comment organiser nos premiers diagrammes et comment les enrichir tout en les connectant entre eux. Néanmoins, ce n’est à mon goût pas nécessaire à l’heure actuelle pour une première utilisation et compréhension de UML. 🙂

Maintenant que les besoins d’un point de vue fonctionnel de notre système sont clairs, voyons ensemble comment…

Définir les besoins d’un point de vue statique

Comme tout à l’heure, nous allons commencer par la…

Définition des mots clés

  1. Diagramme de classes
    C’est le principale Diagramme dans le monde de la programmation. En effet, celui-ci permet de lister et d’organiser tous les éléments qui vont intervenir entre-eux et la manière dont les informations seront conservées.
    Cela prendra la forme suivante :
     UML Diagramme de classes
  2. Classe et Objet
    L’auteur indique qu’une classe représente la description d’un ensemble d’objets possédant les mêmes caractéristiques. On peut parler également de type. (Exemples : la classe Voiture, la classe Personne.)
    Un objet est l’objet en lui-même avec son identité propres, son état actuel, son cycle de vie, etc, mais il répond à la description d’une classe. Un objet est une instance (ou occurence) d’une classe. (Exemple : Kelvin est un objet instance de la classe Personne.)
  3. Attribut et opération
    Un attribut est une information. (Exemple, la classe Personne a les attributs : prénom, nom, date de naissance, taille, etc.)
    Une opération est un comportement ou une action que peut faire un objet instance d’une classe. (Exemple : la classe voiture aurait l’opération : démarrer, éteindre, etc. Suivant nos besoins)
  4. Association
    Une association représente une relation entre deux classes.
    L’auteur utilise l’exemple d’une Personne et d’une voiture. Une Personne “possède” une voiture. Il y a donc la relation “possède” est une association entre les classe Personne et Voiture.UML Association entre deux classes
  5. Agrégation et composition
    Une agrégation est un lien entre deux classes, mais qui signifie implicitement “contient” ou “est composé de”. (je donnerai des exemple plus bas)
    Une composition est une forme de d’agrégation mais plus forte impliquant :
    – La partie qui compose ne peut être partagée avec d’autre élément
    – Si la Composite est détruite, les Parties qui lui sont liées le sont aussi.UML Agrégation & Composition
    Exemple :

    • Un répertoire et un fichier :
      Le dossier est Composite, car un fichier ne peut être que dans un seul dossier et la suppression de se dossier entraîne la suppression du fichier.
    • Une pièce les murs :
      Une pièce est Agrégation, car un mur peut appartenir à plusieurs pièces. De plus, la suppression d’une pièce n’engendre pas la suppression systématique de tous les murs.
  6. Généralisation, super-classe, sous-classe
    L’auteur explique qu’une super-classe est une classe plus générale reliée à une ou plusieurs autres classes plus spécialisées (appelé sous-classes) par une relation de généralisation. Les sous-classes “héritent” des propriétés de leur super-classe et peuvent comporter des propriétés spécifiques supplémentaires.

    Exemple : Les voitures, les bateaux et les avions sont des moyens de transports. Ils possèdent tous une marque, un modèle, une vitesse, etc.
    Par contre, seuls les bateaux ont un tirant d’eau et seuls sont avions ont une altitude…

    UML Héritage

L’auteur montre ensuite comment passer d’un cahier des charges jusqu’à obtenir un Diagramme de Classe directement utilisable pour une équipe de développement dans le cadre de la création d’une application (site internet, logiciel, etc.).

L’auteur continu tout au long de ce formidable ouvrage avec la :

  • Définition des besoins d’un point de vue dynamique
  • Réalisation d’un point de vue conception

Mais, comme je l’ai dit plus haut, afin de pouvoir commencer à profiter de la puissance d’UML, vous en savez déjà assez. 🙂 Pour aller plus loin, il est plus intéressant de lire le livre.

Passons désormais à ma…

Critique

UML2 par la pratique est une référence dans son domaine. Pascal Roques, arrive à amener progressivement des notions compliquées au premier abord. J’ai personnellement eu des cours de UML, lorsque j’étais en école d’ingénieur. A ce moment, j’ai trouvé ça compliqué et trop long à utiliser. Je regrette de ne pas être tombé sur se livre plus tôt que je trouve plus clair que les cours que j’ai eu.

C’est un excellent ouvrage pour les personnes qui souhaitent développer un produit numérique (application, logiciel, site internet) et qui ne savent pas par où commencer. J’ai rencontré des personnes qui n’étaient pas du tout initiées au domaine de l’informatique qui ont vraiment eu une révélation lorsque je leur ai enseigné UML. Je leur ai par la suite conseillé d’utiliser ce livre pour compléter mes cours.

Points forts :

  • Très bien expliqué
  • Rentre dans les détails progressivement
  • Utilisable tout de suite en situation réel (j’ai donné des cours avec)
  • Permet de coucher sur papier des idées (ou des besoins) complexes facilement

Points faibles :

  • Utilise parfois des mots techniques que seuls des développeurs connaîtrons
  • Demande un réel investissement en temps pour aborder chaque domaine
  • J’ai trouvé certaines parties plus longues que nécessaire.

Et vous, avez-vous déjà eu du mal à coucher vos idées sur le papier pour un projet numérique ou autre ? Pensez-vous que ce type de diagrammes vous seront utiles ? Si oui, dans quel cas ? Répondez au sondage et réagissez dans les commentaires !

Ma note pour ce livre : 🌟🌟🌟🌟🌟

Avez-vous lu le livre ? Combien le notez-vous ?

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, moyenne: 5,00/5)
Loading...

Lire plus de commentaires sur UML2 par la pratique sur Amazon.

La chronique du Webmaster, c’est 52 résumés de livre de référence. Les chiffres clés :

Coût du livre : 32,00 €
Coût total du projet : 32,00 €
Nombre de pages : 395
Nombre de pages totales : 395
Temps pour le lire : 6H
Temps pour écrire cet article : 10H30
Temps total du projet : 16H30
  •  
  •  
  •  
  •  
  • 6
  •  
  •  
  •  
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, moyenne: 5,00/5)
Loading...

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.