![[BIG]](../icons/zoom18.gif){kind=icon}
![[Normal]](../icons/zoom14.gif){kind=icon}
![[small]](../icons/zoom10.gif){kind=icon}
Suiv.: Partie II: Normes d'utilisation et de Sup.: Généralités Préc.: Structures de Données Index Table des matières
Suiv.: Partie II: Normes d'utilisation et de
Sup.: Généralités
Préc.: Structures de Données
Index
Table des matières
Il convient de dissocier l'aspect externe (ou fonctionnel) et l'aspect interne d'un module.
Les équations d'un problème mettent en jeu des opérateurs mathématiques. Un module est la réalisation informatique d'un tel opérateur. Il est matérialisé par un sous-programme, qui lit une ou plusieurs Structures de Données d'Entrée (SDE) et crée une ou plusieurs Structures de Données de Sortie (SDS) (figure 1.4).
Figure 1.4: Aspect externe d'un module
Lors du développement d'un module, quelques principes doivent être respectés (figure 1.5) :
Figure 1.5: Aspect interne d'un module
En règle générale, un module appelle des utilitaires de gestion des SD et des tableaux dynamiques, ainsi que des algorithmes (indépendants de ces utilitaires). En aucun cas, un algorithme ne doit appeler un utilitaire. L'appel des utilitaires est réservé aux modules.
Le respect de ce principe a l'avantage de rendre les modules plus fiables et plus lisibles. En outre, le sous-programme qui matérialise un algorithme manipule des tableaux Fortran classiques, ce qui facilite la programmation et permet de l'utiliser comme un sous-programme traditionnel.
Il arrive qu'un opérateur mathématique s'exprime comme la combinaison d'opérateurs plus élémentaires. Il convient alors de programmer autant de modules.
Par exemple, l'opérateur ``résolution par la méthode de Cholesky d'un système linéaire dont la matrice est stockée sous forme profil'' se décompose en une série d'opérateurs :
1. Construction des pointeurs de la matrice profil.
2. Assemblage de la matrice profil.
3. Prise en compte des conditions aux limites.
4. Factorisation.
5. Descente-remontée.
Lors de la programmation, une décomposition en autant de modules est respectée (1. PREPAC, 2. ASSMUA, 3. CLIMPC, 4. CHOLPC, 5. DRCHPC). Ceci répond à un souci de modularité et permet une grande souplesse d'utilisation : par exemple, dans le cas de la résolution d'un système itératif avec une matrice constante, les opérateurs 1 à 4 sont utilisés une seule fois et l'opérateur 5 autant de fois qu'il y a d'itérations.
Un module ne doit pas demander de données à l'utilisateur. En effet, il doit pouvoir être utilisé dans différents contextes, et en particulier dans une boucle d'itérations. Il serait alors particulièrement pénible de fournir autant de données qu'il y a d'appels. La solution préconisée est l'emploi de processeurs de niveau supérieurs aux modules (section 1.2). Le processeur lit une fois pour toutes les données de l'utilisateur dans des tableaux, qui sont ensuite passés en paramètre aux modules.
Les quelques règles qui suivent ont pour but de rendre aisée la lecture des programmes, et non de contraindre l'utilisateur ! Cet objectif demande un minimum de standardisation.
Tout sous-programme débute par une instruction SUBROUTINE (ou FUNCTION), suivie de commentaires qui contiennent le but du sous-programme et la signification des paramètres (figure 1.5). Il convient de bien séparer les paramètres d'entrée, de sortie, et ceux dont le contenu est modifié. Enfin, il est utile de disposer d'informations concernant le programmeur (nom, organisme, date, ...).
La lecture d'un programme est facilitée par la présence de commentaires. Ceux-ci doivent être clairs et significatifs. Il est souhaitable que leur seule lecture donne les grandes lignes de l'algorithme.
Les noms des sous-programmes doivent être le plus simple et le plus parlant possible (malgré la limite Fortran de 6 caractères !). Avant de donner un nom à un programme, il convient de s'assurer que ce nom n'existe pas déjà (par consultation d'un listing ou de la base de procédures PROIMP, cf. [Guide Modulef - 1] ``Installation'').
Les noms des variables doivent être les mêmes que ceux utilisés dans la documentation du module et, dans la mesure du possible, respecter les ``habitudes'' Modulef. Par exemple, le nombre d'éléments est désigné par NE plutôt que NELEM, NEL, etc...
Lorsqu'une erreur est détectée, elle doit être signalée par un message. Celui-ci doit être clair, contenir le nom du sous-programme qui a détecté l'erreur, et si possible indiquer le remède.
Eviter au maximum les astuces de programmation. Sinon, les expliquer clairement, au moyen de commentaires visibles !