Programmes

Composition d'un programme

Choix de l'implémentation d'un module

L'écriture d'un module en Up ! 5GL est indépendante des choix suivants :

Le module sera interprété.
Le module sera compilé en langage C--.
Le module fera partie de l'exécutable ou sera demandé à Up ! Object Request Broker.

Ces choix sont faits lors de la phase de génération. De plus, si le module est distribué, la localisation du module réel est effectué en début de l'exécution : le module est-t-il disponible sur cet ordinateur ? Sinon quel est l'ordinateur qui peut offrir ce module réel dans les meilleures conditions ?

Bien que tous les choix soient possibles, il faut rester raisonnable. Ainsi, un module regroupant des petites fonctions appelées fréquemment sera préférablement compilé et rattaché au programme exécutable au lieu d'être interprété et distribué, hébergé sur une machine qui est bien chargée.

Les modules distribués seront plutôt ceux réalisant de grandes fonctions nécessitant un ordinateur spécialisé (grande puissance de calcul par exemple).

Les modules interprétés seront plutôt ceux en cours de mise au point ou ceux réalisant un interfaçage fonctionnel qui est susceptible d'être dynamique.

Le choix du type de lien dépend de vos besoins et notamment ceux inhérents à l'interfaçage avec des modules déjà existants.

Constitution d'un programme

Un programme est un assemblage de modules de différents modules. Parmi ces modules, il y en a huit obligatoires :

Up ! Virtual Technical Machine qui est le gestionnaire des modules composant le programme.
Sa fonction est de charger les bibliothèques dynamiques, d'initialiser et de terminer les autres modules, de localiser les modules distribués.
Il peut également gérer les multiples instances du programme. En effet, dans le cas d'un serveur, le programme peut avoir autant d'instances qu'il y a de clients de connectés.
Up ! System qui est l'interface avec le système d'exploitation.
Up ! Natural Language Support qui gère le multi-linguisme.
Up ! Kernel qui gère les objets du programme et qui met en oeuvre les types de base.
Up ! Object Management System qui gère le stockage des objets du programme, les concurrences d'accès entre les tâches.
Up ! Object Request Broker qui gère la distribution des objets et des traitements.
Up ! Security Manager qui gère les habilitations sur les objets et des traitements ainsi que les licences.
Un module utilisateur qui comporte la fonction principale du programme.

Il ne peut y avoir qu'un seul module comportant un fonction principale Principal. Elle est automatiquement appelée par Up ! Virtual Technical Machine pour chaque instance du programme.

Ces modules sont systématiquement inclus aux programmes Up ! Application System.

Interface d'un module

Objectif de l'interface

L'objectif est de clairement identifier les besoins du module et ce qu'il met à disposition des autres modules ou des autres programmes. Nous retrouvons en particulier dans l'interface les informations suivantes :

La version du noyau Up ! Application System ayant servie à fabriquer le module pour un module du noyau ou la version de compatibilité avec le noyau pour un module natif.
La liste des modules que Up ! Virtual Technical Machine doit charger pour gérer les éléments de ce module.
La liste des constantes exportées.
La liste des énumérés exportés.
La liste des types exportées.
La liste des variables exportées.
La liste des exceptions exportées.
La liste des files d'attente exportées.
La liste des procédures ou des fonctions exportées.

Usage de l'interface

Lorsque vous demandez de générer le module A utilisant les modules B et C, Up ! Application System analyse les interfaces des modules B et C pour connaître leurs besoins et ce qu'ils mettent à disposition du module A.

Lors de l'analyse de l'interface du module B, si son projet associé est accessible et que s'aperçoit que l'un des composants du module B a été modifié depuis la date de dernière génération citée dans l'interface de B, alors Up ! Application System déclenche automatiquement une génération du module B avant de continuer la génération du module A.

Pour connaître la gestion des modules, veuillez vous référer au chapitre intitulé Les sources des modules.

Création de l'interface

Pour un module natif, elle doit être écrite et maintenue à jour manuellement. La cohérence de l'interface et le contenu d'un module natif est de première importance. Si une interface n'est pas en phase avec les définitions, les données ou le code du module natif, des dysfonctionnements sérieux peuvent avoir lieu soit à la génération soit à l'exécution.

Pour un module généré, l'interface est automatiquement générée lors de la production du code. Elle ne doit pas être modifiée manuellement. Elle peut au plus être consultée. Pour avoir une synthèse du contenu d'un module, il est préférable de se référer au document technique généré automatiquement.

Syntaxe de l'interface d'un module

Pour connaître la syntaxe d'une interface, veuillez vous référer au chapitre intitulé La syntaxe des interfaces entre les modules.

Source d'un module

L'objectif est de clairement identifier quels sont les composants d'un module afin de pouvoir le générer. Nous retrouvons en particulier dans le source d'un module les informations suivantes :

Le type d'implémentation du module.
La liste des composants du module.
L'origine de chaque composant.

Un composant peut être natif ou écrit en Up ! Application System. S'il est natif, en ce cas Up ! Application System ne cherche pas à le compiler. Il ne fait que l'archiver dans la bibliothèque du projet.

Usage du source d'un module

Un module à générer peut comporter :

Un unique composant.
En ce cas le projet associé est module est facultatif. Up ! Application System le calculera automatiquement d'après le contenu du source et d'après les valeurs des options de génération.
Plusieurs composants.
En ce cas le projet associé est module est obligatoire. Up ! Application System se sert du projet pour savoir de quoi est composé le module.

Le source du module est donc le point d'entrée de la génération puisqu'il est rare qu'un module ne possède qu'un seul composant.

Si la génération se déroule avec succès, Up ! Application System produit alors l'implémentation du module ainsi que son interface. Pour connaître la définition de l'interface d'un module, veuillez vous référer au chapitre intitulé L'interface d'un module.

En début de génération, Up ! Application System analyse les interfaces des modules importés. Lors de l'analyse de l'interface du module A, si son projet associé est accessible et que Up ! Application System s'aperçoit que l'un des composants du module A a été modifié depuis la date de dernière génération citée dans l'interface de A, alors Up ! Application System déclenche automatiquement une génération du module A avant de continuer la génération initiale.

Autrement dit, Up ! Application System gère automatiquement la dépendance entre les modules, les générations induites et les tenues à jour des interfaces des modules via les sources des modules.

Création du source d'un module

Pour un module natif, la configuration de projet n'est pas obligatoire. La composition du module est étrangère à Up ! Application System. Seule son interface l'importe.

Pour un module généré, le source du module doit être écrite avant toute génération. Elle peut être soit écrite manuellement, soit produite automatiquement par le gestionnaire de projets Up ! Project intégré à Up ! Workbench.

Pour connaître la syntaxe d'un source d'un module, veuillez vous référer au chapitre intitulé La syntaxe du source d'un module.