Je veux représenter la logique de mon programme via un diagramme, car le programme est assez complexe; J'ai besoin d'un moyen d'expliquer à une autre personne, pourquoi et comment quelque chose se passe dans mon programme. Est organigramme la seule option?
4 Réponses :
Si vous avez besoin d'expliquer les choses à un niveau pas à pas, ouais un organigramme est vraiment ce dont vous avez besoin. Si vous pouvez parler à un niveau supérieur, une autre option peut être un diagramme d'état.
Les organigrammes sont un choix populaire et conviennent souvent aux personnes non techniques.
Si vous êtes intéressé à fournir une vision plus technique de la situation, UML peut être un meilleur choix.
Un diagramme de séquence montre comment les composants interagissent les uns avec les autres.
Il existe également des diagrammes de cas. Mais sur la base de la question, je suis d'accord - les organigrammes seraient mon premier choix.
en UML, différents diagrammes sont destinés à différentes choses, en utilisant différentes méthodologies. Considérant que nous avons tendance à s'appuyer sur les méthodologies orientées objet, je vais expliquer les différents diagrammes et comment ils fonctionnent.
Utilisez le diagramme de cas - Les modèles de boîtes d'utilisation doivent identifier et définir tous les processus commerciaux élémentaires que le système doit prendre en charge. Cela vient d'un utilisateur et d'un point de vue système. Toute action unique dans votre système peut être utilisée dans un cas d'utilisation, qui permettra ensuite d'utiliser davantage de modèles explicatifs.
Schéma d'activité - Il s'agit d'un type de diagramme de flux de travail utilisé pour décrire ce qui se passe dans un diagramme de cas d'utilisation. Il s'agit essentiellement d'une méthode visuelle pour décrire le flux d'une activité ou plusieurs activités.
Schéma de séquence - Il s'agit d'un diagramme pour afficher la communication entre différents objets dans un système ou un processus. Les diagrammes de séquence sont importants dans l'analyse, car ils deviennent cruciaux pour la conception détaillée du système et la conception d'interface utilisateur. J'aime vraiment ces car ils donnent une vision fantastique sur ce qui se passe dans le système.
Diagramme de la machine à états - Cela vous permet de suivre les états d'objets tout au long de leur vie, ce qui donne une excellente perspicacité à la manière dont les objets sont destinés à travailler. Cela donne la possibilité de cartographier les événements et les mêmes efficacité dans le système.
L'utilisation des diagrammes mentionnés ci-dessus donne une excellente base pour l'analyse et la conception, et il convient de noter qu'une fois ces diagrammes créés, ils ne sont pas nécessairement complets. Dans les processus de conception, vous modifiez ces diagrammes lorsque le système évolue. J'espère que ceci vous aide. Vous trouverez ci-dessous des liens vers Wikipedia pour les différents diagrammes mentionnés.
Derrière chaque programme est un domaine problématique, dans lequel vraisemblablement un ensemble de problèmes bien compris par un groupe de personnes compétentes et bien informées et un domaine de solution, dans lequel des méthodes de résolution de tels problèmes sont collectées et utilisées pour gérer la problèmes.
expliquer quelque chose, vous devez d'abord être d'abord d'accord sur le domaine problématique. Si votre domaine de problème est le traitement du signal et que l'explication se passe à quelqu'un qui n'est pas familiarisé avec le domaine, vous êtes déjà toast.
Ensuite, vous devez expliquer le domaine de la solution (ou faire référence à un ensemble de solutions bien connu comme on peut trouver dans un manuel d'ingénierie), de sorte que vous puissiez justifier un choix particulier de solution bien adapté à ce problème particulier et à cet autre. Des contraintes pouvant être placées sur la réponse (les courses dans une petite machine peuvent être construites dans une journée, etc.). Si la personne que vous expliquez des choses ne comprend pas une transformation rapide de Fourier comme une solution possible à un problème dans votre domaine de traitement du signal choisi, vous n'allez pas être en mesure d'expirer la solution que ce soit le meilleur de votre choix.
Une fois que vous passez ces deux obstacles, alors peut-être qu'un organigramme pourrait être houleux. D'autres béquilles telles que divers types de diagrammes UML sont toutes sur l'explication de la structure de la solution de diverses perspectives. Quelle matière perspective dépend de ce que le but de l'explication est.
En ce qui concerne les organigrammes: alors qu'ils étaient populaires une fois, pour décrire des algorithmes, le code Psuedo est généralement assez bon. Les gens qui ne peuvent pas suivre le code psuedo ne sont pas susceptibles de suivre un tableau de flux grand non plus. Et si votre organigramme est trivial, vous ne avez pas besoin. Je ne l'ai pas utilisé un sérieux en 20 ans. La plupart de la littérature informatique ne semble pas l'utiliser soit.
Cela dit, quand on veut comprendre en détail très bien ce qu'est un vrai morceau de code est fait, en particulier aux fins de l'analyse du programme automatisé, ordinogrammes (sous le « flux de contrôle » du nom de colombophile) sont encore assez utiles.
Voir un graphe de flux de commande COBOL (voir cela pour une explication ). Il devrait être évident que vous ne voulez pas l'utiliser pour expliquer un algorithme à une autre personne.
