|
Il n’existe pas une seule représentation graphique universellement acceptée pour un type de programme, un fichier ou une fonction. La représentation dépend fortement du contexte et de l'objectif du diagramme. Cependant, plusieurs notations communes existent dans différentes techniques de création de diagrammes :
Pour les fichiers programme (structure globale) :
* Icônes de fichiers : La représentation la plus simple est une icône de fichier générique (souvent une page vierge ou un symbole de document) avec une étiquette indiquant le nom du fichier et éventuellement son type (par exemple, « .exe », « .py », « .java »). Ceci est courant dans les diagrammes de système de fichiers ou les organigrammes montrant le transfert de données.
* Boîtes dans les organigrammes : Dans un organigramme de niveau supérieur illustrant l'exécution d'un programme, le fichier programme peut être représenté par un rectangle ou un rectangle arrondi contenant le nom du fichier.
* Nœuds dans les diagrammes UML : Les diagrammes UML (Unified Modeling Language) peuvent représenter un fichier programme en tant que composant ou package, montrant ses relations avec d'autres composants.
* Diagrammes de flux de données (DFD) : Un fichier programme peut être affiché comme un magasin de données ou un processus dans un DFD, selon qu'il est traité comme une source de données statique ou un élément de traitement actif.
Pour les fonctions (structure interne et relations) :
* Rectangles dans les organigrammes : Les fonctions sont généralement représentées par des rectangles dans les organigrammes, avec le nom de la fonction à l'intérieur.
* Diagrammes UML (activité, séquence, classe) :
* Diagrammes d'activités : Montrez le flux de contrôle au sein d’une fonction sous la forme d’une série d’actions et de points de décision.
* Diagrammes de séquence : Illustrer les interactions entre différentes fonctions ou objets, en montrant la séquence d'appels et de transmission de messages.
* Diagrammes de classes : Si les fonctions sont des méthodes au sein des classes, elles sont affichées dans le diagramme de classes dans le cadre de la définition de la classe.
* Graphiques de flux de contrôle (CFG) : Il s'agit de représentations plus formelles utilisées dans l'analyse de programmes et la conception de compilateurs. Les nœuds représentent les blocs de code de base et les bords représentent le flux de contrôle entre les blocs. Une fonction serait représentée sous forme de sous-graphe dans le CFG.
* Graphiques d'appel : Ces diagrammes visualisent les relations d'appel entre les fonctions, montrant quelles fonctions appellent quelles autres. Les nœuds représentent des fonctions et les arêtes représentent des appels.
* Diagrammes de Nassi-Shneiderman (graphiques N-S) : Ces diagrammes de programmation structurés représentent des fonctions utilisant des rectangles imbriqués pour montrer clairement le flux et la structure de contrôle.
Le meilleur choix de représentation graphique dépend du niveau de détail souhaité et du public visé. Par exemple, une simple icône de fichier suffit pour une présentation générale du système, tandis qu'un diagramme d'activité UML ou CFG peut être nécessaire pour une conception ou une analyse détaillée.
|