Une commande est avant tout un nom, c'est à dire une chaîne de caractères voire un identifiant externe (connu de l'utilisateur) de la fonctionnalité. Le développeur de l'opérateur numérique définit - dans le catalogue de commandes - les propriétés de la commande et celles des mots-clés correspondant aux paramètres de l'opérateur numérique. Le catalogue d'une commande est l'ensemble des instructions Python qui décrivent la définition de la commande, c'est-à-dire les valeurs attribuées aux attributs de la commande.
Le jeu de commandes est la structure de données - organisée dans un objet Python - qui contient toutes les informations fournies par l'utilisateur final dans le fichier de commandes. Le fichier de commandes permet à l'utilisateur final de déclencher les opérateurs numériques qui portent les fonctions de Code_Aster via des commandes. L'utilisateur final pourra spécifier une valeur pour le paramètre d'une commande via le nom du mot-clé simple correspondant dans le fichier de commande.
Le développeur de la fonction Code_Aster définira les attributs du mot-clé simple dans le catalogue de la commande qui contient le mot-clé simple. Ensuite, il charge (et vérifie) éventuellement la valeur du paramètre de commande à partir du fichier de commande fourni par l'utilisateur final à l'application. Le développeur de la fonction Code_Aster définit les attributs du mot-clé factor dans le catalogue de la commande qui contient le mot-clé factor.
L'occurrence du bloc dans sa commande dépend d'une condition exprimée lors de la définition de la commande par le développeur de la fonctionnalité numérique.
Prise en charge de la maintenance
La règle PRESENT ABSENT stipule que si l'entité correspondant au nom donné est présente, toutes celles correspondant aux autres noms doivent être absentes de l'entité composée courante.
2 L’organisation sources Python
Conventions
Typologie des modules Python
Hiérarchie des répertoires des sources
- Les sources python du superviseur
Noyau
Executio Build n
Macro
Les sources de l’interface-graphique Eficas
L’environnement
- Installation de l’interpréteur Python
- Paramètres shell de configuration
- Installation de l’interface-graphique Eficas
- Mise à jour du superviseur
Editeu Ihm r
- Appel d’une fonction avec un nombre variable d’arguments
- Utilisation des espaces de nom
- Notion d’espace de noms
- Le module __builtin__
- Exécution d’une commande Python dans un espace de noms
- Une deuxième manière d’importer un module
- Module Python écrit en langage C
Un module merveilleux est le module standard __builtin__, qui – sauf cas particuliers ([bib2], page 100) – est référencé dans chaque module utilisateur par l'attribut __builtins__ en mode ReadOnly. Le module __builtin__ est importé par défaut ; toutes les données et fonctions qu'il contient sont accessibles par défaut dans tous les modules applicatifs. Par conséquent, les données et fonctions définies dans le module __builtin__ peuvent être considérées comme les plus globales pour l'application.
Il est possible d'importer et d'enrichir le module __builtin__ ; cette technique est utilisée dans Eficas dans le script Noyau/__init__.py. Dans l'exemple suivant, la variable gb définie au début du script est accessible à toutes les unités du module : elle est définie dans l'espace de noms global. Un espace de noms spécifique peut être créé et utilisé pour exécuter des instructions stockées dans une chaîne.
Lors de l'interprétation du script main.py, l'interpréteur en enrichit l'espace de noms d_context. Lorsque vous utilisez l'instruction exec, vous pouvez spécifier que les données créées doivent se trouver dans l'espace de noms local, comme indiqué dans l'exemple ci-dessous. L'instruction Python exec vous permet de créer un espace de noms en interprétant un script Python - stocké dans une chaîne - en spécifiant un espace de noms après le mot-clé dans, par exemple : exec s_script in space.
La fonction "intégrée" __import__ ([bib2], p. 100), permet d'importer un module à partir de son nom stocké dans une chaîne de caractères. En fait, cette fonction est appelée par l'interpréteur Python lorsqu'un module est importé avec l'instruction import ([bib3], p629). La fonction __import__ "intégrée" peut également être utilisée pour importer un module spécifique à partir d'un package.
Comme indiqué dans la documentation Python (http://www.python.org/doc/current/lib/built-in-funcs.html), l'instruction est. Il ne reste plus qu'à récupérer le module catalogue depuis le package, par exemple : module=getattr(package, 'cata')). La commande __import__ permet d'importer un module ou un package dont le nom n'est connu que lorsque le script en cours est interprété.
4 Le catalogue général des commandes de Code_Aster
- Exemple 1 : une factory pour construire les mots-clés simples
- Principe de la factory
- L’organisation de la factory en fichiers
- Exemple 2 : une factory pour construire une commande
- Ajout des classes PROC et PROC_ETAPE à la factory
- Notion de catalogue de commandes
- Notion de fichier de commandes
- Utilisation du catalogue et du fichier de commande
- Le fichier catalogue
- Catalogue d’une commande
- Structure générale du fichier catalogue
- Installation du catalogue dans la mémoire
- La structure de données dans le package Noyau
Dans le dictionnaire de mots clés, les chaînes de caractères utilisées pour les clés doivent obéir aux règles d'écriture d'un identifiant Python : pas d'espace blanc. Il décrit également la procédure de chargement du jeu de commandes en mémoire à partir des informations fournies par l'utilisateur final - dans le fichier de commandes. Rappelons que la définition de la classe MCSIMP doit être effectuée avant celle de la classe SIMP.
Une fois les deux modules SIMP et MCSIMP mis à disposition, le développeur de fonctions de code numérique peut désormais définir un "catalogue de mots clés application" dans le fichier dictio.py. Et l'utilisateur final peut enfin utiliser les fonctionnalités en fournissant un script, par exemple values.py. En pratique, les mots-clés ne sont pas définis séparément, mais nécessairement au sein d'une mission.
La classe PROC_ETAPE, qui modélise une commande de type "procédure", est très proche de la classe MCSIMP. Lorsqu'il est créé à partir du catalogue, l'objet PROC stocke dans le dictionnaire self.entites la composition de la commande en mots-clés simples ; Ces informations seront utilisées dans un deuxième temps - pour construire les mots-clés simples de la commande - lorsque l'objet PROC sera invoqué via sa méthode __call__. C'est aussi la méthode __call__ qui va initialiser les mots-clés de la commande avec les valeurs fournies dans le fichier de commande (le module SIMP est exactement celui présenté dans le premier exemple).
Dans le premier exemple ([§4.1]), la description des mots-clés a été faite dans le dictionnaire (espace de noms) d_context. Un fichier de commandes est également un script Python très simple destiné à être interprété dans l'espace de noms du catalogue de commandes. Dans le script commands.py ci-dessus, l'utilisateur final demande l'exécution de la routine Fortran op0010 avec MASSE_VOLUMIQUE=7800.0 et FICHIER_MAILLAGE="mailage.unv".
A la fin de quoi le jeu de commandes (ici réduit à la seule commande AFFE_MATERIAU) est défini dans l'espace de noms d_context. Dans cet exemple, tiré du véritable catalogue de commandes Code_Aster : 1) la commande décrite s'appelle ASSE_MAILLAGE. Le fichier catalogue de commandes Code_Aster – le module $TOP/Aster/Cata/cata.py – contient les informations suivantes.
Il est important de rappeler qu'une référence dans le catalogue courant est stockée dans le module dont la référence est stockée en CONTEXT. Les classes suivantes ont pour tâche de stocker en mémoire le jeu de commandes et de restaurer la valeur des mots-clés sur demande.
OBJECT
MCSIMP
MCFACT
MCBLOC
MCCOMPO
ETAPE
Toutes les classes présentées ci-dessous participent au chargement du jeu de commandes en mémoire. Et leur fonction principale est la méthode __call__, qui agit comme une fabrique d'objets.
ENTITE
SIMP
FACT
BLOC
PROC
OPER
JDC_CATA
MACRO
Le package Accas
Le package Accas est le package principal utilisé par le superviseur Code_Aster et par l'interface graphique Eficas. Il contient les modules correspondant aux classes obtenues en compilant (en utilisant l'héritage multiple) des classes d'autres packages. Les objets de la classe MCSIMP sont construits avec le constructeur de la classe A_MCSIMP.MCSIMP.
Le diagramme ci-dessus représente la contribution majeure de chaque package aux fonctionnalités de la classe MCSIMP. La méthode get_val() est utilisée par le superviseur pour récupérer la valeur du mot clé simple et la renvoyer à l'opérateur Code_Aster qui la demande. val, définition, nom, parent) get_val (): type de base. La classe MCCOMPO – qui modélise un OBJET composite – n'existe pas dans le package Accas, mais est importante car elle sert de base aux classes MCFACT et MCBLOC.
Le schéma ci-dessus met en évidence les comportements qui justifient l'existence de la classe MCCOMPO.
V_MCCOMPO.MCCO MPO
I_MCCOMPO
N_MCCOMPO.MCCO MPO
5 Les macro-commandes Python
6 Quelques questions
- Comment savoir quel fichier catalogue est utilisé par un calcul ?
- Comment le mode DEBUG est-il géré ?
- Où le catalogue de commande est-il chargé dans la mémoire
- Création de l’objet JdC
- Chargement des entités du catalogue dans l’objet JdC
- OPER : 2) PROC
- Où le jeu de commandes est-il exécuté par le superviseur ?
- A quoi sert le mot-clé _F utilisé dans le fichier de commande ?
- Où l’interface getvxx du jeu de commande se trouve-telle ?
Dans Eficas et dans le superviseur - en fait dans n'importe quel script Python - le mode DEBUG est géré via une variable par défaut définie dans l'espace de noms global __builtin__ : __debug__. Que ce soit dans le superviseur ou dans l'interface graphique JdC d'Eficas, l'objet Python contenant le catalogue est créé dans le module cata du package Cata. Pour être précis, JdC est créé lors de l'import du module cata : l'import est effectué dans la méthode d'import de la classe Execution/E_SUPERV du module SUPERV.
Une fois importé, l'objet JdC contient - dans son attribut commands, ou liste de types - la définition de toutes les commandes disponibles, ainsi que celle des éventuels mots-clés associés à chaque commande. Au début du script cata.py, le JdC est déclaré par l'instruction : JdC = JDC_CATA (code='ASTER'). Cette instruction appelle principalement la méthode __init__ de la classe N_JDC_CATA.JDC_CATA (package Core).
Dans cette méthode, l'objet JdC généré est stocké dans l'espace global __builtins__ via la variable _cata du module CONTEXT : __builtins__[ "CONTEXT" ]._cata. Une référence au catalogue actuel est toujours disponible dans l'espace de noms global __builtins__. Après création, le chargement se fait toujours lors de l'import du catalogue dans la méthode importations en créant des objets type.
Le jeu de commandes j (objet de type Accas.A_JDC.JDC) est exécuté dans la méthode Execute de la classe SUPERV dans le module E_SUPERV du package Execution. En mode PAR_LOT='OUI' (dans le script l'attribut j.par_lot du jeu de commandes est mis à 'YES'), le traitement est effectué par l'appel. Dans le fichier de commandes, un mot-clé facteur est introduit par la chaîne de caractères _F.
En fait, cette chaîne est un nom de classe qui prend en charge la création en mémoire du dictionnaire correspondant au mot clé facteur basé sur une description utilisant le signe égal '=' et des crochets au lieu des deux points ': ' et des accolades qui seraient utilisées avec un dictionnaire Python standard. Cette présentation est plus adaptée aux souhaits des utilisateurs finaux et à la tradition du langage de commande Code_Aster. Les méthodes getvxx appartiennent à la classe ETAPE définie dans le module B_ETAPE du package Build.
7 Bibliographie