Il est dit que l'architecture logicielle doit être stratifiée et divisée en modules, ce qui doit être fait spécifiquement (2)

Original 028 de Brother Dao

Introduction

Dans l'article précédent, nous avons principalement parlé de: Dans la conception de l' architecture d'application du système embarqué , quels aspects doivent être triés et analysés, lien de l'article: Il est dit que l'architecture logicielle doit être stratifiée et divisée en modules. Comment le faire (1) .

Cet article, nous continuons à parler de la conception du contour, de l' étape de conception détaillée , nous devrions faire quel travail? Avec quels outils font ou signifie? Quelle est la sortie ?

Par convention, pour la commodité de la description du contenu, j'utiliserai un processus de conception de passerelle IoT pour connecter tout le contenu ensemble. Si vous ne savez pas grand-chose sur les passerelles, veuillez faire défiler jusqu'à la liste de lecture recommandée au bas de l'article . Il existe plusieurs articles sur les fonctions des passerelles.

2. Recherche et analyse de la demande

1. Diagramme de cas d'utilisation

Le dernier article mentionnait que le diagramme de cas d'utilisation est un outil très, très utile lors de la recherche de la demande et de l'analyse de la demande . Grâce au diagramme de cas d'utilisation, nous pouvons présenter toutes les fonctions qui doivent être complétées dans un système en un coup d' œil dans une perspective grossière .

L'image suivante est un diagramme de cas d'utilisation de la passerelle (le cas d'utilisation dessiné ici n'est pas complet):

[Échec du transfert de l'image du lien externe. Le site d'origine dispose peut-être d'un mécanisme de lien anti-sangsue. Il est recommandé d'enregistrer l'image et de la télécharger directement (img-bWTtNkvd-1615949273342) (http://iottown.sewain100.cn/iot28_usercase. png)]

2. Description du cas d’utilisation

Le diagramme de cas d'utilisation décrit uniquement les fonctions du système , mais ne décrit pas le comportement de chaque cas d'utilisation , c'est-à-dire le processus d'exécution.

Comme mentionné dans l'article précédent, nous n'avons pas besoin d'analyser tous les cas d'utilisation, mais de découvrir ces cas d'utilisation clés dans ces cas d'utilisation , puis d'écrire une description de cas d'utilisation pour ces cas d'utilisation clés , car le cas d'utilisation clé est l'architecture du système Le déterminant de.

Ensuite, une autre question se pose: si tous les cas d'utilisation sont classés par ordre de priorité en fonction de leur importance , combien ou quel pourcentage de cas d'utilisation clés devraient être sélectionnés de haut en bas? Cela dépend de la complexité de l'ensemble du système, 30% ce n'est pas trop peu, 50% ce n'est pas trop, vous pouvez le saisir librement en fonction de votre temps.

Pour le diagramme de cas d'utilisation de la passerelle dans la figure ci-dessus, je pense que les cas d'utilisation d' ajout d'équipement, de suppression d'équipement, de contrôle d'équipement, de configuration de règles et de déclenchement de règles sont plus critiques. Par conséquent, j'écrirai des descriptions de cas d'utilisation pour ces cas d'utilisation. .

(1) Ajouter la description du cas d'utilisation de l'équipement

Il y a 2 points à noter:

1. Dans le flux d'événements, nous décrivons la passerelle comme une boîte noire, car nous effectuons une analyse des exigences, pas une conception, il n'est donc pas nécessaire de considérer le processus d'exécution au sein de la passerelle;
2. La partie rouge est un organe exécutif, qui peut être une personne, une interface, un appareil, un système, etc.

Le flux d'événements peut être décrit avec des mots (comme indiqué sur la figure), ou un diagramme de séquence peut être dessiné pour montrer le processus, comme indiqué ci-dessous (le processus d'exécution plus détaillé n'est pas décrit en détail ici, et il est principalement schématique) :

(2) Supprimer la description du cas d'utilisation de l'appareil

(3) Description des cas d'utilisation des équipements de contrôle

(4) Description du cas d'utilisation de la configuration des règles

(5) Description du cas d'utilisation de déclenchement de règle

Trois, conception de contour

La conception de contour peut être comprise comme un diagramme d'architecture approximatif et abstrait pour refléter les composants de haut niveau et les connexions entre eux . Alors, que faut-il faire pour obtenir un tel diagramme d'architecture?

Les matériaux dont nous disposons maintenant sont: des diagrammes de cas d'utilisation et des descriptions de cas d'utilisation (des cas d'utilisation clés) , et dans le flux d'événements de base des descriptions de cas d'utilisation, le système à concevoir est décrit comme une boîte noire.

Ce que nous devons faire maintenant, c'est ouvrir cette boîte noire , y entrer et analyser à partir du processus d'exécution : quels modules ont besoin pour effectuer quelles actions .

Notez que c'est notre objectif. Pour atteindre cet objectif, utilisez l' outil graphique robuste .

En d'autres termes, nous devons maintenant utiliser l'outil graphique robuste pour désassembler le flux d'événements dans la description du cas d'utilisation, découvrir tous les éléments participant au système qui sont nécessaires pour compléter ce cas d'utilisation et marquer les différences entre eux. Relation .

1. Dessinez des diagrammes robustes pour les descriptions de cas d'utilisation des principaux cas d'utilisation

Permettez-moi d'abord de parler du concept déroutant: la robustesse , également connue sous le nom de robustesse, fait référence à la bonne exécution du programme même s'il y a des erreurs dans le processus en cours d'exécution. Il décrit la tolérance aux pannes du programme .

Un graphe robuste fait référence à: l'utilisation de la modélisation graphique pour décrire si une description de cas d'utilisation est correcte et complète .

Principalement à travers 3 types d'éléments: les objets de contour, les objets de contrôle et les objets d'entité , pour dessiner une description de cas d'utilisation, l'interaction entre les différents modules fonctionnels au sein du système à concevoir.

1. Objets frontières: éléments du système qui doivent interagir avec le monde extérieur. Il est responsable de la réception des entrées externes et de la sortie des résultats du traitement interne vers l'extérieur;
2. Objet de contrôle: décrivez le comportement de contrôle dynamique, en mettant l'accent sur un lien d'exécution vers un autre lien d'exécution;
3. Objet entité: décrire un élément de contenu d'information, tel que: une information de description de périphérique dans une passerelle, une information de configuration de règle, etc.

En ce qui concerne les objets frontières , il peut être plus facile à comprendre dans les projets Web, c'est-à-dire l' interface qui interagit avec les utilisateurs et les systèmes externes . Mais dans les systèmes embarqués, il n'y a pas d'interface dans la plupart des cas, mais il suffit de saisir une chose fondamentale: recevoir des entrées externes et sortir des données vers l'extérieur .

Dessinez simplement le périphérique d'ajout, le périphérique de contrôle et le déclencheur de règle ici. Ces trois cas d'utilisation décrivent les diagrammes robustes correspondants (ignorez les couleurs de ces diagrammes pour le moment):

Ajouter un appareil:

dispositif de contrôle:

Déclencheur de règle:

En ce qui concerne l'exécution de l' ajout de règles , la plupart du travail est effectué sur l'application mobile (sélectionnez le périphérique source de la condition de déclenchement de l'appareil), la passerelle stocke simplement la règle configurée, il n'y a pas d'autres opérations excessives.

La partie la plus importante de la règle est le traitement des déclencheurs de règle . Par exemple: lorsque le périphérique infrarouge (périphérique source) détecte un corps humain, s'il est actuellement à l'état armé (condition de déclenchement), il activera le son et la lumière alarme (équipement cible), donc ce qui suit Cette image décrit le processus d'exécution de l'exécution d'une règle La chaîne d'exécution de ce processus est relativement longue et permet de connecter plusieurs modules en série.

2. Catégorisez les modules dans le graphe robuste et résumez les sous-systèmes

En supposant que nous ayons maintenant dessiné les diagrammes robustes de tous les cas d'utilisation clés , l'étape suivante consiste à classer ces modules . Dans les images ci-dessus, certains modules sont marqués de différentes couleurs et la même couleur indique qu'ils appartiennent à une catégorie.

1. Les modules dans la partie jaune sont tous liés à la communication sans fil, de sorte que ces modules peuvent être classés comme sous-système de gestion de communication sans fil;
2. Les modules de la partie verte sont liés aux équipements, ils sont donc classés comme sous-système de gestion des équipements;
3. Les modules de la partie bleue sont liés aux règles, ils sont donc classés comme des sous-systèmes de gestion des règles;
4. Continuez à rechercher d'autres sous-systèmes. . .

Enfin, nous dessinons ces sous-systèmes (ou groupes fonctionnels) dans une image comme suit:

Du point de vue des composants de niveau supérieur, cette image divise l'ensemble du système en plusieurs sous-systèmes, dont chacun est un module physique indépendant et livrable .

Le rôle de cette image est assez grand, elle peut être utilisée pour rendre compte au leader (le leader n'a pas le temps de regarder la conception détaillée), elle peut également être utilisée dans la partie description de l'architecture technique du manuel du produit, et il peut également être utilisé pour la division du travail entre les membres de l'équipe, car chaque partie est une unité indépendante et le couplage avec d'autres sous-systèmes est isolé des aspects statiques et dynamiques (expliqués plus loin dans la conception de l'architecture de développement plus tard).

Ces sous-systèmes doivent communiquer . Par conséquent, après avoir dessiné ce schéma de conception, nous devons également prendre les décisions suivantes :

1. Pile technologique utilisée: langage de développement C, méthode de communication entre processus: bus de messages;
2. Concurrence: chaque sous-système s'exécute dans le système avec le processus comme unité d'exécution et implémente la bibliothèque mosquitto via le langage C du bus de messages MQTT pour se connecter au système de bus;
3. Le système ne prend pas en charge le développement secondaire;

Quatre, conception détaillée

Dans le schéma de conception ci-dessus, tous les modules fonctionnels ont été divisés en différents sous - systèmes , qui peuvent également être appelés groupes fonctionnels. L'étape suivante consiste à découvrir les objets internes, les fonctions à compléter et les processus d'interaction dans chaque groupe fonctionnel, en particulier l'analyse de l' architecture logique, de l'architecture d'exploitation et de l'architecture de développement du système .

1. Architecture logique

L'architecture logique de chaque sous-système doit être subdivisée en bloc fonctionnel plus granulaire , si vous voulez une granularité plus fine, il peut être démonté au niveau de la classe. De plus, il est également nécessaire de définir l' interface interactive entre les modules .

Conformément à la description ci-dessus, nous avons décidé de concevoir chaque sous-système comme un processus indépendant . Chaque processus échange des données via un bus de messages . Ce bus de messages est basé sur des rubriques pour le routage des messages. Par conséquent, les éléments suivants: Concevoir les interactions de données dont chaque processus a besoin gérer:

1. Entrée: Répondre aux demandes des autres modules;
2. Exportation: Afin de terminer votre travail, vous devez vous fier aux autres modules pour fournir des services;

Un résumé d'une phrase: il s'agit de découvrir chaque module, afin de mener à bien son propre travail, avec quels autres modules d'unité il faut interagir? Quelle est l'interface interactive (fonction, méthode ou protocole)?

Alors, comment trouvez-vous ces objets et ces interfaces? Utilisez des diagrammes de séquence ou des diagrammes de classes pour terminer. Voici un simple diagramme de séquence du dispositif de commande:

Chaque flèche de la figure représente une interface. Pour cette passerelle, elle représente une rubrique traitée.

Si vous utilisez des diagrammes de classes pour analyser, cela peut être plus facile à comprendre pour les langages de développement orientés objet. Par exemple, vous pouvez définir clairement les propriétés, les fonctions privées et les fonctions partagées de chaque objet , et vous pouvez clairement construire les objets. Relation .

2. Architecture opérationnelle

L'architecture d'exploitation décrit l' état dynamique de chaque unité d'exécution et le flux de contrôle pendant l'exécution.Les points clés à considérer sont: Le système est-il sûr ? La performance répond-elle aux exigences de qualité? À quel point est- ce évolutif ?

Spécifiquement pour la passerelle, chaque sous-système est basé sur un processus en tant qu'unité d'exécution, et chaque processus est connecté au bus de messages via une pièce jointe tierce (c'est-à-dire une bibliothèque dynamique), comme illustré dans la figure suivante:

La simultanéité du système est obtenue grâce à de multiples processus; la sécurité du système est principalement gérée par le mécanisme de sécurité du bus de messages.

Par exemple, lors de la phase de développement , le bus de messages permet à d'autres clients extérieurs au système d'accéder, de sorte que vous pouvez écrire un programme de débogage sur le PC, vous connecter au bus et surveiller toutes les données . À ce stade , les données peuvent être non crypté et tous sont lisibles par l'homme; mais dans la phase de publication du projet , cette autorisation est désactivée, le client sur le PC ne peut pas accéder au bus et toutes les données du bus doivent être cryptées et compressées pour continuer à s'améliorer la sécurité du système.

3. Architecture de développement

Quant à nous qui nous concentrons sur le code, l'architecture de développement est facile à comprendre, il ne s'agit que de définir la structure du projet, le processus de compilation, la procédure de test, etc.

Plus précisément, nous pouvons établir des réglementations à partir des aspects suivants:

1. Développement parallèle: chaque sous-système est un processus indépendant, il peut donc être divisé en un projet indépendant pour améliorer l'efficacité du développement;
2. Bibliothèque tierce: utilisée comme module public de base (cryptage SSL, accès au bus de messages, analyse du protocole de communication);
3. Sécurité du code: chaque développeur ne peut avoir que l'autorité pour obtenir le code dont il est responsable, et seul l'administrateur a l'autorité pour obtenir tout le code;
4. Gestion et contrôle du code: utilisez des outils tels que git et svn pour gérer les versions de code;
5. Compilation intégrée: utilisez la fonction de module Jenkins + git pour extraire automatiquement tous les codes de sous-système et compiler automatiquement. Si vous avez besoin de déployer automatiquement, vous pouvez également utiliser des scripts pour réaliser.

Cinq, vérification de l'architecture

Enfin venu au dernier lien. En fait, le projet a beaucoup expérimenté. Si l'architecture conçue ci-dessus peut répondre aux exigences fonctionnelles et de qualité mises en avant dans les exigences, nous connaissons déjà la réponse dans nos esprits.

Pour être sûrs, nous devons encore vérifier certains des éléments clés . Ce processus de vérification est précieux, ou les résultats de ce processus de vérification peuvent être soumis sous forme de code officiel.

La direction générale de la vérification comporte deux points: si le cadre du système est raisonnable et stable; si certains goulots d'étranglement techniques peuvent être résolus . Si les deux parties sont correctes, alors vous pouvez avancer hardiment.

Six, résumé

Après l'introduction de deux articles, j'ai essentiellement décrit le processus de réflexion de la conception d'architecture d'application dans mon travail quotidien .

Il est dit dans les écritures bouddhistes: Traverser une personne, c'est comme aider une personne à traverser une rivière. Après avoir traversé la rivière et être sur la rive, jetez le radeau sur lequel vous montez et arrêtez de penser au radeau dans votre cœur.

Le processus de conception présenté dans cet article n'est qu'une routine. Face à un nouveau domaine et à un nouveau projet , cette routine est comme un échafaudage , nous indiquant quoi faire à cette étape, quoi faire ensuite et quels outils utiliser.

Après avoir utilisé rigoureusement cette routine, vous pouvez continuer à transformer, optimiser, puis abandonner cette routine pour former une routine qui vous convient, et dès lors sur la route de la pensée et de la richesse!

Bonne chance!

(Si vous pensez que c'est un article sec et précieux pour d'autres amis, envoyez -le et partagez-le ! Merci beaucoup! Bienvenue également pour discuter et vous vanter dans la zone de message!)

---

Les bons articles doivent être envoyés; plus vous partagez, plus vous avez de chance!

---

---

Lecture recommandée

[Langage C]

Pointeur de langage C - des principes sous-jacents aux compétences sophistiquées, utilisez des graphiques et du code pour vous aider à expliquer
les principes de débogage sous-jacents du gdb d'origine si simple
analyse étape par étape - comment utiliser C pour implémenter la programmation orientée objet pour
améliorer le outil puissant du code: définition de macro - De l'entrée à l'abandon,
utilisez setjmp et longjmp en langage C pour implémenter la capture d'exceptions et les coroutines

【Conception d'application】

Développement de passerelle Internet des objets: processus de conception
basé sur le bus de messages MQTT (partie 1) Développement de la passerelle Internet des objets: processus de conception basé sur le bus de messages MQTT (partie 2)
Ma méthode de communication préférée entre les processus-bus de messages

【Internet des objets】

Les choses sur le cryptage et les certificats
vont profondément dans le langage de script LUA, vous permettant de comprendre pleinement le principe du débogage

[Nonsense] Basé
sur mon expérience de carrière ratée: quelques conseils pour les techniciens qui sont nouveaux sur le lieu de travail