Sketches simples pour Diagramming votre architecture logicielle
Sketches simples pour Diagramming votre architecture logicielle
Si vous travaillez dans une équipe de développement logiciel agile au moment, jetez un oeil autour de votre environnement. Que ce soit physique ou virtuel, il est susceptible d'être un mur d'histoire ou tableau Kanban visualiser les travaux encore à lancer, en cours et fait. Visualisant votre processus de développement de logiciels est un moyen fantastique d'introduire la transparence parce que tout le monde peut voir, en un coup d'oeil, un aperçu de haut niveau de l'état d'avancement. En tant qu'industrie, nous sommes devenus très habiles à visualiser notre processus de développement de logiciels au cours des dernières années, mais il semble que nous avons oublié comment visualiser le logiciel lui-même que nous construisons. Je ne parle pas seulement de la documentation post-projet, ce qui comprend également la communication au cours du processus de développement logiciel. approches agiles parler de mouvement rapide, ce qui nécessite une bonne communication, mais il est surprenant de constater que de nombreuses équipes luttent pour communiquer efficacement la conception de leur logiciel.
Les méthodes prescrites, les cadres de processus et des notations formelles
Si vous regardez en arrière quelques années, des processus structurés et des notations formelles ont fourni un point de référence tant pour le processus de conception de logiciels et de la façon de communiquer les conceptions qui en découlent. Les exemples incluent le Rational Unified Process (RUP), l'analyse des systèmes structurés et Méthode de conception (SSADM), le langage de modélisation unifié (UML) et ainsi de suite. Bien que l'industrie du développement de logiciels a progressé à bien des égards, il semble avoir oublié quelques-unes des bonnes choses que ces anciennes approches nous ont donné. Dans le monde d'aujourd'hui de la livraison agile et start-ups maigres, certaines équipes de logiciels ont perdu la capacité de communiquer ce qu'ils construisent et il est pas surprenant que ces équipes semblent souvent manquer de leadership technique, la direction et la cohérence. Si vous voulez vous assurer que tout le monde contribue au même objectif final, vous devez être en mesure de communiquer efficacement la vision de ce que vous construisez. Et si vous voulez l'agilité et la capacité de se déplacer rapidement, vous devez être en mesure de communiquer cette vision efficace aussi.
En tant qu'industrie, nous avons le langage de modélisation unifié (UML), qui est une notation standardisée formelle pour communiquer la conception de systèmes logiciels. Je n'utilise moi-même UML, mais je ne tends à l'utiliser avec parcimonie pour ébaucher des aspects importants de la conception à faible niveau d'un système logiciel. Je ne trouve pas que fonctionne bien UML pour décrire l'architecture logicielle d'un système logiciel. Bien qu'il soit possible d'en débattre, il est souvent hors de propos parce que de nombreuses équipes ont déjà jeté UML ou ne savent tout simplement pas. Ces équipes favorisent généralement « boîtes et lignes » informelles croquis de style au lieu, mais souvent ces diagrammes ne font pas beaucoup de sens à moins d'être accompagnés d'un récit détaillé, ce qui ralentit finalement l'équipe vers le bas. prochaine fois que quelqu'un présente une conception de logiciel pour vous autour concentré un ou plusieurs croquis informels, demandez-vous si elles présentent ce qui est sur les croquis ou si elles présentent ce qui est encore dans leur tête.
Abandonnant UML est très bien, mais, dans la course à l'agilité, de nombreuses équipes de développement de logiciels ont perdu la capacité de communiquer visuellement aussi. Les croquis d'architecture logicielle exemple (ci-dessus) illustrent un certain nombre d'approches typiques pour communiquer l'architecture logicielle et ils souffrent des types de problèmes suivants:
- Le code couleur est généralement pas expliqué ou est souvent incompatible.
- Le but de éléments du diagramme (à savoir les différents styles de boîtes et des lignes) est souvent pas expliqué.
- relations clés entre les éléments du diagramme sont parfois manquants ou ambigus.
- Les termes génériques tels que « la logique métier » sont souvent utilisés.
- Les choix technologiques (ou options) sont généralement omis.
- Les niveaux d'abstraction sont souvent mélangés.
- Les diagrammes essaient souvent de montrer trop de détails.
- Les diagrammes manquent souvent de contexte ou un point de départ logique.
Quelques abstractions simples
boîtes informelles et croquis lignes peuvent fonctionnent très bien, mais il y a beaucoup de pièges associés à la communication des conceptions de logiciels de cette façon. Mon approche consiste à utiliser une petite collection de schémas simples que chacun montre une autre partie de la même histoire globale. Pour ce faire, cependant, vous devez convenir d'une façon simple de penser au système logiciel qui vous construisez. En supposant un langage de programmation orienté objet, la façon dont je me plais à penser au sujet d'un système logiciel est la suivante: un système logiciel est constitué d'un certain nombre de conteneurs, qui sont eux-mêmes constitués d'un certain nombre de composants qui sont à leur tour mis en œuvre par une ou plusieurs classes. C'est une hiérarchie simple des blocs de construction logiques techniques qui peuvent être utilisées pour illustrer la structure statique de la plupart des systèmes logiciels que j'ai jamais rencontré. Certains schémas aideront à expliquer plus loin.
Un diagramme de contexte peut être un point de départ utile pour schématisant et la documentation d'un système logiciel, ce qui vous permet de faire un pas en arrière et regarder le tableau d'ensemble. Dessiner un schéma fonctionnel simple montrant votre système comme une boîte dans le centre, entouré par ses utilisateurs et les autres systèmes que les interfaces avec.
Le détail est sans importance ici car cela est votre point de vue montrant un zoom arrière grande image du paysage du système. L'accent devrait être mis sur les personnes (acteurs, rôles, personnages, etc.) et des systèmes logiciels plutôt que les technologies, protocoles et autres détails de bas niveau. Il est le genre de schéma que vous pourriez montrer aux personnes non techniques.
Mettez simplement, techtribes.je est composé d'un serveur Web Apache Tomcat qui fournit aux utilisateurs des informations, et que l'information est tenue à jour par un processus de mise à jour de contenu autonome. Toutes les données sont stockées soit dans une base de données MySQL, une base de données MongoDB ou le système de fichiers. Il est intéressant de souligner que ce schéma ne dit rien sur le nombre d'instances physiques de chaque conteneur. Par exemple, il pourrait y avoir une ferme de serveurs Web en cours d'exécution contre un cluster MongoDB, mais ce schéma ne montre pas que le niveau d'information. Au lieu de cela, je montre des cas physiques, basculement, clusters, etc., sur un schéma de déploiement séparé. Le diagramme des conteneurs montre la forme de haut niveau de l'architecture logicielle et la façon dont les responsabilités sont réparties à travers elle. Il montre également les choix technologiques majeurs et comment les conteneurs communiquent entre eux. Il est simple, diagramme technologie de haut niveau qui est axé utile pour les développeurs de logiciels et de soutien / opérations le personnel.
Comme le montre le diagramme des conteneurs, techtribes.je comprend un processus autonome qui tire dans le contenu de Twitter, GitHub et blogs. Le schéma ci-dessous montre la structure interne de haut niveau du contenu updater en termes de composants.
En plus d'un certain nombre de composants de base, le contenu est updater composé de quatre éléments: une mise à jour du contenu programmé, un connecteur Twitter, un connecteur GitHub et un connecteur Nouvelles alimentation. Ce diagramme montre comment la mise à jour du contenu est divisé en composants, ce que chacun de ces composants sont, leurs responsabilités et les détails de la technologie / de mise en œuvre.
Ce niveau de détail en option et je vais généralement dessiner un petit nombre de diagrammes de classes UML de haut niveau si je veux expliquer comment un modèle ou d'un composant particulier sera (ou a été) mis en œuvre. Les facteurs qui me poussent à dessiner des diagrammes de classe pour les parties du système de logiciel comprennent la complexité du logiciel ainsi que la taille et l'expérience de l'équipe. Tous les diagrammes UML que je dessine des croquis ont tendance à être plutôt que des modèles complets.
Pensez à l'auditoire
Il semble y avoir une idée fausse que les « schémas d'architecture » ne doivent présenter une vue conceptuelle de haut niveau du monde, il est donc pas surprenant que les développeurs de logiciels considèrent souvent comme inutile. De la même manière que l'architecture logicielle devrait être sur le codage, le coaching et la collaboration plutôt que des tours d'ivoire, des diagrammes d'architecture de logiciels doivent être ancrés dans la réalité aussi. Y compris les choix technologiques (ou options) est généralement un pas dans la bonne direction et à la prévention des diagrammes à la recherche comme une architecture tour d'ivoire où un groupe de composants conceptuels collaboration par magie pour former un système logiciel de bout en bout.
Un schéma simple peut rapidement devenir encombré et confus, mais une collection de diagrammes simples vous permet de présenter facilement le logiciel à partir d'un certain nombre de différents niveaux d'abstraction. Et ce point est important, car il n'y a pas que les développeurs de logiciels au sein de l'équipe qui ont besoin d'informations sur le logiciel. Il y a d'autres parties prenantes et les consommateurs aussi; allant des experts du domaine non technique, les testeurs et la gestion par le personnel technique des opérations et des fonctions de soutien. Par exemple, un diagramme montrant les conteneurs est particulièrement utile pour les personnes comme les opérations et le personnel de soutien qui veulent des informations techniques sur votre système logiciel, mais ne doivent pas nécessairement savoir quoi que ce soit sur le fonctionnement interne.
abstractions communes sur une notation commune
Cette approche esquisse simple fonctionne pour moi et beaucoup des équipes de logiciels que je travaille, mais il est de fournir quelques idées d'organisation et de lignes directrices plutôt que de créer une norme prescriptive. Le but ici est d'aider les équipes à communiquer leurs conceptions logicielles de manière efficace et efficiente plutôt que de créer une autre notation de modélisation complète.
UML fournit à la fois un ensemble d'abstractions et une notation commune pour les décrire, mais je trouve rarement des équipes qui utilisent soit efficacement. Je préfère voir des équipes capables de discuter de leurs systèmes logiciels avec un ensemble d'abstractions à l'esprit plutôt que du mal à comprendre ce que les différents éléments tentent de notationnelles montrer. Pour moi, un ensemble d'abstractions est plus important qu'une notation commune. La plupart des cartes sont un excellent exemple de ce principe en action. Ils ont tous ont tendance à montrer des routes, des rivières, des lacs, des forêts, des villes, des églises, etc., mais ils utilisent souvent la notation différente en termes de codage couleur, les styles de ligne, iconographie, etc. La clé pour les comprendre est exactement cela - une clé / légende niché dans un coin quelque part. Nous pouvons faire la même chose avec nos schémas d'architecture logicielle.
Il est utile de rappeler que des croquis de boîtes informelles et lignes offrent une flexibilité au détriment de la cohérence du schéma parce que vous créez votre propre notation plutôt que d'utiliser un standard comme UML. Mon conseil est d'être conscient de codage couleur, le style de ligne, formes, etc et laisser un ensemble de notations cohérentes évoluer naturellement au sein de votre équipe. Y compris une simple clé / légende sur chaque diagramme pour expliquer la notation aidera. Oh, et si nommer est vraiment la chose la plus difficile dans le développement de logiciels, essayez d'éviter un diagramme qui est simplement une collection de boîtes étiquetées. Annoter les cases avec des responsabilités permet d'éviter toute ambiguïté, tout en offrant une belle « un coup d'oeil » vue.
« Juste assez » jusqu'à la conception avant
Illustrant la conception de votre logiciel peut être une tâche rapide et facile que, quand bien fait, peut vraiment aider à introduire le leadership technique et instiller un sentiment d'une vision technique partagée que toute l'équipe peut acheter. Sketching devrait être une compétence dans la boîte à outils de tous les développeurs de logiciels. Il est un excellent moyen de visualiser une solution et communiquer rapidement, plus il ouvre la voie à la conception collaborative et la propriété collective du code.
Logiciel Articles connexes Architecture
Logiciels connexes Architecture Livres