Get best of the week

UML pour les développeurs

Internet regorge d'articles sur UML, vous trouverez des centaines d'exemples pour chaque type de diagramme, et créez le vôtre sans problème, la notation n'est pas compliquée. Mais est-il vraiment nécessaire d'y consacrer du temps? Notre riche expérience dit oui. Si vous avez plus de 2 personnes dans une équipe et un projet de 3 mois ou plus, il est déjà judicieux de dessiner 2-3 types de diagrammes. Notre équipe compte plus de 30 personnes, un projet de plus de 3 ans, et nous utilisons ... 2-3 types de diagrammes.

La notation UML est redondante. En revanche, cela ne suffit pas pour la conception de systèmes distribués, et ici Archimate nous aide. Dans cet article, nous vous expliquerons ce qui est vraiment utile dans toute cette variété et nous prendrons comme exemple le cycle complet de création de diagrammes pour un projet.

Qu'allons-nous attirer?


Si votre objectif est «rapide et beau» (par exemple, pour une présentation ou pour cet article), alors Visio est plus que approprié: son éditeur est pratique et pardonne tout écart par rapport à la notation.

Si vous êtes engagé dans la conception, vous aurez besoin d'un système complet avec prise en charge des relations entre les diagrammes. Nous utilisons le produit Enterprise Architect, bon marché et joyeux.
Une comparaison des systèmes de conception et une histoire sur la façon de les utiliser correctement est un sujet pour un article séparé.

Tâche technique


Nous concevrons une application mobile hypothétique pour l'apprentissage des langues étrangères. Les termes de référence sont généralement préparés par des analystes qui prépareront le premier lot de diagrammes. Les développeurs, dans ce cas, sont uniquement tenus de les lire correctement.

Le diagramme le plus simple est le cas d'utilisation:



le diagramme montre les types d'utilisateurs et répertorie les fonctions ou groupes de fonctions qui leur sont associés. L'élément surligné en bleu qui n'est pas présent dans UML, mais qui manque souvent: Exigence - Exigence (de la notation Archimate), raffinement des fonctions.

Vous demandez - et quel est le point? Après tout, la liste des fonctions peut être spécifiée simplement dans le texte, dans une liste compacte! Et vous aurez raison, mais il y a des nuances.

  1. Certaines fonctions concernent plusieurs utilisateurs, il est difficile d'afficher le texte.
  2. Lorsque vous dessinez toutes les fonctions et exigences du système de conception, vous pouvez ensuite les télécharger sur la même Jira, puis les associer à des tâches et des bogues, ce qui simplifie la gestion de projet.

Pourquoi avons-nous mélangé UML et Archimate dans le même diagramme? Vous n'avez pas besoin de suivre strictement les notations; vous n'avez pas à passer les examens à l'université avec cela, mais à communiquer avec l'équipe, pour laquelle vous préparez tout.

Pourquoi avons-nous utilisé des lignes plutôt que des flèches pour connecter des éléments? Parce que personne ne se souvient à quoi ressemblent les flèches "Généralisation" et "Extension", et ce qu'elles sont généralement. Plus vous dessinez simple, plus les gens comprendront le tableau sans votre participation.

Le deuxième type de diagrammes que vous pouvez rencontrer dans la tâche technique est le diagramme d'activité:



Ici, tout est évident pour le développeur, sauf une chose: pourquoi l'IA fait-elle des appels aux étudiants? Ne fait pas. Ce diagramme est dessiné par des analystes, pas des programmeurs, ils ne savent pas où est le client, mais où est le serveur, et ils ne sont pas intéressés par les flux de données. Sur le diagramme d'activité, vous voyez une séquence d'actions et rien de plus. Comment en faire un code? Nous passons à la phase de conception.

Conception d'architecture


L'architecture de l'application mobile est évidente: client, serveur, base de données. Si nous concevons quelque chose de sérieux, nous devons nous occuper de diviser le projet en sous-systèmes, dans notre cas ce sera au moins:

  • Sous-système de réservation de cours
  • Sous-système de formation Web
  • Facturation
  • Sous-système de gestion de l'enregistrement vocal

Les sous-systèmes doivent être isolés les uns des autres: leurs propres bases de données sans connexions relationnelles avec d'autres sous-systèmes, la communication entre les sous-systèmes uniquement via l'API. Le sous-système peut être un ensemble de microservices ou un monolithe, à votre discrétion.

Vous pouvez confier chaque sous-système à une équipe de développement dédiée, ils se plongeront dans leur sujet et interféreront moins avec leurs collègues avec leurs commits inattendus.

Pour chaque sous-système, un schéma architectural est nécessaire , comment le dessiner correctement? Il n'y a pas de diagrammes appropriés dans UML pour cela, regardons Archimate:



Même sans connaissance de la notation, le diagramme est généralement lisible. N'oubliez pas que 90% des membres de votre équipe ne connaissent pas non plus UML, sans parler d'Archimate, et qu'ils n'apprendront jamais ces notations, alors concentrez-vous sur les inscriptions. Néanmoins,



quelques mots sur les cubes et les flèches: Vous pouvez facilement trouver la spécification complète d'Archimate.

Couleur - à votre goût, la notation ne les régule en aucune façon. Colorez le sous-système actuel avec une couleur, les sous-systèmes adjacents avec le second, les systèmes externes avec le troisième, cela améliore considérablement la lisibilité du circuit.

Le diagramme utilise seulement deux types de flèches: Flow et Access. Le flux montre la direction du transfert de données et l'appel - qui parle à qui. La flèche de flux doit être comprise correctement:



L'organigramme de l'application mobile vers le serveur n'est pas représenté dans le diagramme, bien qu'il le soit (le flux «Demande de données» passe en premier). Ceci est fait pour rendre le schéma plus facile à lire: nous ne montrons que les plus importants. Le fait qu'il existe également une demande de données initiale est déjà évident à partir du cube avec l'API d'inscription.

Détail


Les deux derniers diagrammes, qui sont très utiles (le lecteur attentif, bien sûr, a remarqué qu'il n'y a plus 2-3 types de diagrammes): diagramme de séquence (diagramme de classe) et diagramme de classe (diagramme de classe, mais pas du tout pour les classes).

Parfois, l'interaction client-serveur est en plusieurs étapes, utilisant des ressources tierces. Par exemple, l'autorisation avec Oauth2: une description textuelle de ce processus est très difficile à comprendre. Ici, le diagramme de séquence nous aidera :



cette implémentation Oauth2 n'est pas une référence, il peut y avoir de nombreuses options. La chose la plus importante à comprendre dans le diagramme est qu'il n'y a pas de flux de données dans ce diagramme, seulement des appels et des réponses aux appels. Bien que cela ne nous ait pas empêchés de spécifier les flux avec du texte sur les flèches.

Lorsque vous plongez dans l'étude du diagramme de séquence, vous constaterez qu'il vous permet d'afficher des boucles et des branches, mais ne les abusez pas: vous n'avez pas besoin de dessiner les branches "Si l'utilisateur a choisi l'autorisation locale" et "Si vous avez choisi l'autorisation FB" , à la place, dessinez deux schémas pour chaque option. Les conditions, en particulier celles imbriquées, sur le diagramme de séquence réduisent considérablement la lisibilité du circuit.

Le dernier diagramme (pas aujourd'hui, mais en général) est le diagramme de classe . Son nom parle, il a été supposé qu'avec l'aide de ses classes seraient conçues. Dans l'ancien temps des éditeurs de texte DOS, cela pouvait être justifié, mais les environnements de développement modernes vous permettent de concevoir et d'analyser des classes sans quitter leurs thèmes sombres et clairs.

Mais l'application pratique du diagramme de classes reste la conception de bases de données:



si vous savez ce que sont les bases de données relationnelles, cela est plus qu'évident. Les attributs du diagramme ne sont pas entièrement signés, seules les relations, les types de données et parfois les restrictions sont indiqués.

N'essayez pas de le dessiner dans Visio, Enterprise Architect ou équivalent. Pour la conception de bases de données, il existe de nombreux outils spécialisés adaptés à des SGBD spécifiques, utilisez-les.

C'est tout. De tous les diagrammes dans UML et Archimate, en pratique, plus qu'assez sont répertoriés. Combien de diagrammes de chaque type sont nécessaires pour un projet? Dois-je les dessiner pour chaque processus et sous-système? La règle principale est que le diagramme accompagne la description du texte, il n'est nécessaire que lorsque le texte n'est pas suffisant, c'est-à-dire où l'équipe ne vous comprend pas.

Merci de votre attention, il y avait une société de produits logiciels avec vous.

More articles:


All Articles