Existe-t-il une norme pour documenter l'architecture de haut niveau d'un programme?


10

Je suis un développeur amateur et tous mes programmes jusqu'à présent étaient assez simples pour être documentés dans le code. En lisant le code, il était clair ce que je faisais telle ou telle action (mon test standard consistait à regarder le code 6 mois plus tard et à tout comprendre à la première lecture - et ma mémoire est courte).

Je suis maintenant confronté à un programme qui dépasse mes capacités à se souvenir des diverses interactions entre

  • le code lui-même
  • les index de la base de données
  • les interactions entre les différents modules (code de base "travailleur" et "bibliothèque")

Ma documentation actuelle est un tableau blanc où j'ai toutes sortes de boîtes et de flèches qui pointent vers du code, vers des index de base de données, vers des actions en cours d'exécution, pour changer d'état, etc. Juste pour référence, un fragment du gâchis:

entrez la description de l'image ici

Ma question est de savoir s'il existe un ensemble standard ou nommé de meilleures pratiques (nommé en ce sens qu'il s'agit d'un ensemble de pratiques regroupées sous un nom spécifique) pour la documentation de produits plus complexes.

Quels sont les mots-clés que je devrais rechercher (les tentatives générales de «documenter les normes d'architecture logicielle» et les variations similaires conduisaient généralement à des logiciels pour les workflows ou la construction de systèmes CAO d'architecture).

Je m'attends également à ce qu'il n'y ait pas de meilleures pratiques générales pour les descriptions de haut niveau et que chacun construise sa propre philosophie.


um UML et un peu de vieux texte habituellement
jk.

Si vous pouvez lire l'allemand, jetez un œil à arc42.de/template/index.html Ils montrent quelques lignes directrices pour documenter l'architecture logicielle.
Bernhard Hiller

8
"Ne pas prendre la peine de le faire du tout" est probablement le plus proche d'une norme.
whatsisname

Réponses:


13

Il n'y a pas une norme à laquelle tout le monde adhère. Les projets logiciels peuvent varier considérablement (pensez: helloworld.py vs le code de la navette spatiale).

Une méthode très courante consiste à utiliser le modèle 4 + 1 . Au lieu d'essayer de tout regrouper en un seul style de document, cette méthodologie décompose la conception en cinq composants:

  • La vue Développement
  • La vue logique
  • La vue physique
  • La vue Processus
  • Scénarios

Les différentes vues décrivent le produit selon quatre perspectives différentes. Les scénarios indiquent où vivent les cas d'utilisation et décrivent l'interaction des autres vues.

Remarque: Il s'agit d'un modèle conceptuel et n'est lié à aucun outil spécifique.

Vous pouvez lire plus ici:

  1. Modèle de vue architecturale 4 + 1 (wikipedia)
  2. Architectural Blueprints — The “4 + 1” View Model of Software Architecture (IEEE paper - pdf)

C'est une très bonne approche, merci. En prenant du recul, on pourrait penser que c'est à peu près évident, mais cela aide beaucoup à déconnecter les différentes pièces 4 + 1 que j'avais toutes sur un graphique.
WoJ

4

IMHO UML n'est pas un outil qui fonctionne bien pour documenter l'architecture des logiciels du monde réel. Les diagrammes de classes sont utiles, mais utilisent un niveau d'abstraction qui est souvent trop faible à cet effet. Les diagrammes de cas d'utilisation sont généralement trop «de haut niveau» et manquent certains aspects. D'autres types de diagrammes UML ont des problèmes similaires (pour être honnête, les diagrammes de packages, les diagrammes de déploiement, les diagrammes de composants peuvent documenter certains aspects architecturaux, mais personnellement, je ne les ai jamais trouvés très utiles).

Si vous cherchez un moyen pratique et pragmatique de documenter des architectures de haut niveau, je vous suggère de vous familiariser avec les diagrammes de flux de données . Celles-ci sont faciles à comprendre et ont l'avantage de pouvoir s'adapter à différents niveaux d'abstractions. Je les ai trouvés très utiles pour documenter différents types de systèmes. Dommage qu'ils n'aient pas trouvé leur chemin dans UML, mais vous trouverez néanmoins de nombreux outils - même gratuits comme Dia ou DrawIO - pour créer ces diagrammes.

En guise de remarque, pourquoi avez-vous besoin des "index dans la base de données" dans une documentation de haut niveau? Je pense qu'ils sont un détail d'implémentation de votre modèle de données (relationnel?), Et si vous les ajoutez ou non est - selon mon expérience - plus une question de performances et d'optimisation.


Diagrammes d'emballage? Diagrammes de déploiement? Diagrammes des composants?
Nick Keighley

3
Honnêtement, un tas de boîtes avec des flèches peuvent faire des merveilles pour communiquer un certain nombre de fonctionnalités de conception. Je suppose que les diagrammes de composants entrent dans cette catégorie, mais mes clients comprennent le flux de données avec des boîtes représentant les bits principaux. Je suis d'accord avec Doc Brown. La formalité d'UML manque la marque avec sa destination.
Berin Loritsch

@NickKeighley: voir ma modification.
Doc Brown

@BerinLoritsch: À mon humble avis, "un tas de boîtes avec des flèches" caractérise les types de diagrammes mentionnés par Nick Keighley. Cependant, les diagrammes de flux de données établissent une distinction formelle claire entre les données ou groupes / grappes de données et les processus ou composants qui transfèrent ou transforment ces données. Ce n'est rien que je puisse exprimer facilement avec l'un des diagrammes UML.
Doc Brown

1
Je dois admettre que j'ai parfois recours aux diagrammes de flux de données - en particulier ceux qui autorisent les magasins. En fait, le diagramme de niveau supérieur qui décrit notre système est essentiellement un DFD. Je trouve toujours les diagrammes de classe et le package utiles dans une certaine mesure. Je ne fais pas très attention aux parties "formelles" d'UML.
Nick Keighley

0

Le langage de modélisation unifié (UML) est un langage de modélisation de développement à usage général dans le domaine du génie logiciel, qui est destiné à fournir un moyen standard de visualiser la conception d'un système.


La spécification formelle se trouve à omg.org/spec/UML/2.5 mais il y a beaucoup de tutoriels sur le web plus convivial.
Simon B

2
Cette réponse ne constitue qu'une partie de la question, UML est, de manière définitive, le bon outil à modéliser, mais cela ne constitue pas en soi une documentation complète
Walfrat

3
Quelqu'un utilise-t-il UML très souvent?
Panzercrisis

griffonner. rétro-ingénierie.
Nick Keighley

1
@Walfrat. est-ce? Vraiment? J'ai mes doutes.
Doc Brown

-3

Je pense que nous faisions mieux. UML semblait jeter le bébé avec de l'eau du bain. En fournissant un langage de modélisation unifié, il a supprimé la distinction entre architecture et implémentation. Ou si elle n'avait pas l'intention de le faire, cela semblait être le cas.

J'ai vu des modèles UML monstres et franchement, ils ne font rien pour moi que le code ne puisse pas faire, et le font mieux.


3
ne répond pas à la question, probablement mieux en tant que commentaire sur la réponse de SuperGirl.
Newtopian

1
Il répond à la question. Je soutiens que la réponse à la question est plus "non" qu'auparavant.
Nick Keighley
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.