Communauté

Par Ding Yi, surnommé Sanhua chez Alibaba.

La valeur de la communication technique ne se reflète pas seulement dans la façon dont les applications sont développées par le biais de produits commerciaux et de projets open-source et dans la façon dont les divers processus de lancement d’entreprise sont accélérés. Mais, sa valeur se reflète également dans l’expérience partagée par plusieurs ingénieurs exceptionnels différents pour améliorer la productivité, optimiser les performances des produits et promouvoir l’expérience des utilisateurs. En une phrase, la communication technique est importante car elle améliore nos capacités professionnelles.

Dans cet article, un expert technique d’Alibaba, Ding Yi, partagera ses idées et son expérience dans la création de diagrammes architecturaux efficaces.

Pour décrire notre système dans un ou plusieurs diagrammes, nous rencontrons souvent les problèmes suivants :

• Nous ne savons pas par où commencer.
• Nous ne savons pas comment décrire le système dans un seul diagramme qui soit suffisamment clair pour que les équipes concernées du produit, des opérations et du développement le comprennent clairement.
• À mi-chemin, nous réalisons que nous ne savons pas qui est le public.
• Nous ne savons pas si nous représentons un diagramme fonctionnel de produit, un diagramme technique ou simplement un mélange.
• Lorsqu’il y a trop peu de cases dans le diagramme, nous ne savons pas quoi ajouter.
• Nous ne sommes jamais satisfaits de la disposition du diagramme.

Si vous avez rencontré les mêmes problèmes, cet article présente une méthodologie de dessin pour produire des diagrammes d’architecture clairs.

Concepts

Qu’est-ce qu’une architecture ?

Une « architecture » peut être définie comme une description abstraite des entités d’un système et des relations entre elles. Elle implique une série de processus de décision.

L’architecture est une structure et une vision.

Une « architecture système » est la concrétisation des concepts et la répartition des correspondances entre les fonctions des choses ou des informations et les éléments formels. Elle définit les relations entre les éléments ainsi qu’entre les éléments et le milieu environnant.

Construire une architecture solide est une tâche complexe et un grand sujet à aborder ici. Après avoir construit une architecture, les parties concernées doivent la comprendre et suivre ses diktats.

Qu’est-ce qu’un diagramme d’architecture ?

Un diagramme d’architecture est un diagramme d’un système qui est utilisé pour abstraire le contour global du système logiciel et les relations, les contraintes et les frontières entre les composants. C’est un outil important car il fournit une vue globale du déploiement physique du système logiciel et de sa feuille de route d’évolution.

Quelles sont les fonctions d’un diagramme architectural?

Un diagramme un peu comme une image vaut mille mots. En d’autres termes, un diagramme d’architecture doit remplir plusieurs fonctions différentes. Pour permettre aux utilisateurs concernés de comprendre l’architecture d’un système et de la suivre dans leur prise de décision, nous devons communiquer des informations sur l’architecture. Les diagrammes d’architecture constituent un excellent moyen d’y parvenir. Pour poser quelques fonctions majeures, un diagramme d’architecture doit :

• Battre les barrières de communication
• Atteindre un consensus
• Diminuer l’ambiguïté

Types de diagrammes d’architecture

Les diagrammes peuvent être classés en plusieurs catégories. Un type de diagramme populaire est la vue 4+1, qui comprend les vues scénario, logique, physique, processus et développement de l’architecture.

Vue scénario

La vue scénario décrit les relations entre les participants au système et les cas d’utilisation fonctionnels et reflète les exigences finales et la conception des interactions du système. Cette vue est généralement un diagramme de cas d’utilisation.

Vue logique

La vue logique est utilisée pour décrire les relations entre les composants, les contraintes des composants et les limites après la décomposition des fonctions logicielles du système. Elle reflète la composition globale du système et la façon dont le système est construit. Cette vue est généralement un diagramme de composants ou un diagramme de classes UML.

Vue physique

La vue physique décrit la correspondance entre le logiciel du système et le matériel physique et montre comment les composants du système sont déployés sur un groupe de nœuds physiques calculables. Elle fournit une orientation dans le processus de déploiement du système logiciel.

Vue du processus

La vue du processus décrit la séquence de communication et l’entrée et la sortie de données entre les composants logiciels du système et reflète les flux fonctionnels et de données du système. Cette vue est normalement présentée sous la forme d’un diagramme de séquence ou d’un organigramme.

Vue de développement

La vue de développement est utilisée pour décrire la division et la composition des modules du système et affiner la conception de la composition des paquets internes. Cette vue est utilisée par les développeurs et reflète les processus de développement et de mise en œuvre du système.

Les cinq vues architecturales ci-dessus représentent différentes caractéristiques d’un système logiciel à partir de différentes perspectives. En les combinant dans un schéma architectural, nous pouvons alors décrire très clairement l’architecture globale du système.

Qu’est-ce qui fait un diagramme d’architecture efficace ?

Comment pouvons-nous savoir si un diagramme est un bon diagramme ? Et quelles méthodes devrions-nous utiliser pour créer un diagramme?

Les diagrammes ci-dessus ont été sélectionnés pour illustrer les différents types de diagrammes, sans trop se soucier de leur qualité. Nous pensons que, pour représenter un bon diagramme architectural, nous devons savoir qui est notre public et réfléchir aux informations que nous voulons transmettre. Par conséquent, nous ne devons pas représenter une vue physique ou une vue logique pour le plaisir. Pour être efficaces, les diagrammes doivent être utilisés pour transmettre avec précision les informations requises par un certain public. Ce n’est qu’ensuite que nous devons nous préoccuper du type de diagramme. Par conséquent, la norme la plus directe par laquelle nous pouvons juger de la qualité d’un dessin est de savoir si le public peut comprendre avec précision les informations que nous avons essayé de transmettre.

Cela signifie qu’un bon et efficace diagramme architectural n’a pas besoin d’être expliqué au public. Il devrait exprimer tout ce que vous voulez dire tout seul. En outre, un bon diagramme devrait également avoir une structure cohérente, précise par rapport aux données qu’il représente et correspondre directement au code.

Des défis communs lors de la représentation de diagrammes architecturaux

Que représente un carré ?

Pourquoi utilisons-nous des carrés au lieu de cercles ? L’utilisation aléatoire de carrés ou d’autres formes peut entraîner une confusion.

Que signifient les lignes pointillées et les lignes pleines ? Que signifie une flèche ? Que signifient les couleurs ?

L’utilisation arbitraire de lignes ou de flèches peut entraîner des malentendus.

Y a-t-il des conflits entre le temps d’exécution et le temps de compilation ? Y a-t-il des conflits de niveau ?

Construire une architecture est un travail complexe. Par conséquent, l’utilisation d’un seul diagramme pour représenter l’architecture peut facilement entraîner une confusion sur des aspects spécifiques de l’architecture.

My Recommended Drawing Method

Le modèle C4 utilise des conteneurs, tels que des applications, des magasins de données et des microservices, ainsi que des composants et du code pour décrire la structure statique d’un système logiciel. Ces diagrammes sont faciles à dessiner, et leurs éléments clés sont explicites. Cependant, le plus important est qu’ils peuvent indiquer clairement le public visé et la signification de chaque diagramme.

L’exemple suivant provient du site officiel de C4. Sur cette base, nous parvenons à utiliser notre propre compréhension pour mieux exprimer l’architecture du logiciel.

Diagramme du contexte du système

Ceci est un diagramme d’un système bancaire prévu. Il utilise un système bancaire mainframe externe pour accéder aux comptes des clients et aux informations sur les transactions et envoie des courriels aux clients via un système de messagerie externe. Comme vous pouvez le voir, le diagramme est simple et clair. Il ne nécessite aucune explication supplémentaire pour que le public le comprenne. Nous pouvons également voir qu’il contient le système à construire, les clients du système, et les systèmes périphériques qui interagissent avec ce système.

Usage

Un diagramme aussi simple peut indiquer quel type de système doit être construit, qui sont ses utilisateurs, qui le manipulera, et comment il sera intégré dans un environnement informatique existant. Le public de ce diagramme peut être le personnel interne de l’équipe de développement, le personnel technique externe ou le personnel non technique. Il nous indique :

• Quel système doit être construit ?
• Qui le manipulera ?
• Comment il est intégré dans l’environnement informatique existant ?

Comment représenter le diagramme

Dans ce diagramme, votre propre système est au milieu, et les utilisateurs et les systèmes qui interagissent avec ce système sont placés autour. L’aspect clé de ce diagramme est qu’il organise et montre clairement les utilisateurs et les dépendances de haut niveau du système à construire. Une fois le travail conceptuel effectué, il ne faut que quelques minutes pour représenter le diagramme.

Diagramme de conteneur

Le diagramme de conteneur étend le système dans le diagramme de contexte de système précédent.

Dans la figure précédente, en plus des utilisateurs et des systèmes périphériques, le système à construire comprend une application web basée sur Java Spring MVC pour fournir un portail de fonctions pour le système, tandis qu’une application mobile basée sur Xamarin fournit un portail de fonctions pour les clients mobiles. Une application API basée sur Java fournit des services, et une base de données MySQL est utilisée pour le stockage. Les flèches indiquent les interactions entre les applications.

Lorsque vous regardez ce diagramme, vous ne remarquez pas si les boîtes ont des coins aigus ou arrondis ou si les flèches ont des lignes pleines ou en pointillés. Même les directions des flèches n’attirent pas beaucoup d’attention.

Il existe de nombreuses méthodes de dessin, qui définissent toutes la signification des cadres et des lignes. Il faut donc que le dessinateur et le spectateur du diagramme comprennent clairement ces définitions. Ce n’est qu’alors que toutes les informations du diagramme peuvent être comprises. Cependant, cela est exigeant, et de nombreux spectateurs ne saisiront que les concepts généraux.

Utilisation

Le public de ce diagramme peut être des développeurs internes ou externes ou du personnel O&M. Ce diagramme sert les objectifs suivants :

• Il présente la structure globale du système logiciel.
• Il reflète la prise de décision technique de haut niveau.
• Il montre comment les responsabilités sont distribuées dans le système et comment les conteneurs interagissent entre eux.
• Il indique aux développeurs où la programmation du code est nécessaire.

Comment représenter le diagramme

Ce diagramme utilise des cadres, qui peuvent inclure des noms, des choix techniques, des responsabilités et des interactions entre les cadres. Si un système externe est impliqué, il est préférable de définir la frontière.

Diagramme de composants

Un diagramme de composants est utilisé pour développer un conteneur et décrire ses modules internes.

Utilisation

Ce diagramme est destiné aux développeurs internes et leur montre comment organiser et développer le code. Ce diagramme sert les objectifs suivants :

• Il décrit les composants ou les services du système.
• Il clarifie les relations et les dépendances entre les composants.
• Il fournit un cadre qui montre comment les tâches de développement de logiciels peuvent être distribuées et livrées.

Diagramme de code ou de classe

Ce diagramme est destiné au personnel de soutien technique. C’est un type de diagramme courant, c’est pourquoi nous ne le décrirons pas en détail.

Etude de cas

La figure suivante montre l’architecture d’un outil interne de données en temps réel. Comme un diagramme d’architecture devrait être évident, il n’y a pas beaucoup de besoin d’explication. Si vous ne pouvez pas le comprendre clairement, le diagramme n’est certainement pas assez bon.

Il existe de nombreuses méthodologies pour représenter un bon diagramme architectural. Cet article présente la méthode C4, qui est cependant aussi en constante évolution. Malgré cela, quelle que soit la méthodologie de dessin, nous devons simplement considérer l’intention du dessin et mieux la communiquer au public. Nous ne devons pas être indûment limités par des règles dans le processus de dessin. En bref, avant de commencer un diagramme, demandez-vous : A qui s’adresse-t-il, de quoi est-il question, et comment le rendre intuitif et compréhensible.

À propos de l’auteur : Sanhua est un expert technique chez Alibaba. Zijing, Pengsheng et Yule ont également contribué à cet article. Ding Yi a précédemment travaillé dans le moteur de flux de travail R&D pendant de nombreuses années, mais il se concentre maintenant sur l’architecture et le développement d’applications Internet mobiles à forte monnaie. Les contributeurs à cet article sont issus du département LST d’Alibaba.

Etes-vous impatient de connaître les dernières tendances technologiques d’Alibaba Cloud ? Écoutez-le de la part de nos meilleurs experts dans notre série nouvellement lancée, Tech Show!