comment représenter un flux de production dans un produit logiciel

Question

Je dois étudier un processus de chargement de fichier dans un de nos logiciels d'entreprise, je dois représenter les classes et les méthodes principales et le genre de travail qui y est fait et écrire un rapport à ce sujet avec une sorte de diagrammes. Quelle est la meilleure façon de décrire ce flux de travail en écrivant un document texte ou en utilisant UML et si UML quel type de diagrammes dois-je utiliser?

Answer 1

Utilisez le diagramme d'activité UML (http://www.agilemodeling.com/style/activityDiagram.htm) pour le flux des processus à un niveau élevé. Ensuite, utilisez le diagramme de séquence UML (http://www.agilemodeling.com/artifacts/sequenceDiagram.htm) pour des portions suffisamment complexes pour justifier des détails supplémentaires.

Answer 2

Le meilleur format pour toute la documentation dépend non seulement de l'information qu'elle contient, mais aussi du public visé. Si votre public est composé d'ingénieurs logiciels, je dirais que UML est un bon choix: il est standardisé, ce qui signifie que vous n'aurez pas à composer votre propre notation ou à l'expliquer, et si vous gardez les diagrammes raisonnablement simples, les chances sont bonnes que votre public pourra les lire même s'il ne s'agit pas d'experts UML complets.

Vous ne dites pas ce que la documentation est pour, mais au moins je suggère les sections suivantes dans votre rapport:

Source Voir: diagrammes de classes, peut-être avec quelques diagrammes de packages ainsi en fonction du le langage d'implémentation et le nombre et le type de paquets. (Si les paquets fournissent des abstractions fonctionnelles, comme ils peuvent le faire en Java, envisagez de les décrire, sinon ce n'est pas très important.)

Runtime View: diagrammes de séquence décrivant le flux de contrôle pour au moins les fonctions clés.

Vous pouvez également envisager d'ajouter un ou plusieurs de ces derniers:

Conception générale: un diagramme de composants décrivant les principales parties du logiciel: par exemple, une DLL et une API appelé par le code de l'utilisateur (je suppose que nous parlons d'une sorte de routine de bibliothèque). Cela ne devrait pas concerner des appels de méthodes spécifiques ou des classes d'implémentation, mais décrire le logiciel à un niveau élevé.

Vue conceptuelle: ceci devrait décrire les concepts clés, généralement en utilisant des diagrammes de classes très simples. Le fichier est probablement un tel, et vous devriez envisager d'inclure un tableau d'état décrivant les différents états d'un fichier (ouvert, fermé, eof ...).

Comme toujours lors de l'utilisation de UML pour documenter (plutôt que de générer par exemple du code), soyez généreux avec des notes dans chaque diagramme, et éparpillé avec des éléments (classes, etc.). Pour les diagrammes destinés à être collés dans des documents texte, j'essaie de ne pas mettre plus d'une demi-douzaine d'éléments dans chaque diagramme.