Post by J-P. RosenAdaControl, bien sûr. La structure est (plus ou moins) décrite dans le
programmer's manual.
Bonjour Jean-Pierre,
Oui tout à fait, le chapitre "General organization" donne en une dizaine
de lignes ce qui est utile ici, les trois principaux composants:
- A general framework that provides services that are necessary to write
rules. This includes a special module, Framework.Plugs, where rules are
plugged-in;
- A set of utilities providing useful functionalities, but not specific
to the writing of rules. Actually, the utilities packages are shared
with other programs from Adalog’s “Semtools” family of tools.
- The rules themselves.
Ce qui m'a permis d'écrire assez vite la petite description suivante au
format ArchiCheck :
Rules may use Framework
Framework.Plugs may use Rules -- exception à ce qui précède
Utilities contains Scope_Manager, Adactl_Options, etc. (il y en a une
douzaine)
Rules may use Utilities
Framework may use Utilities
L’exécution à donné les incohérences suivantes avec cette description :
- Framework.Ruler utilise Rules.Uncheckable
- Adactl_Options (que j'ai mis dans Utilities) utilise Framework.Reports
et Framework.Variables.Shared_Types
Je les ai ajouté également comme exceptions (mais je te laisse juge de
la "normalité" de la chose), et AdaControl fait désormais partie de ma
suite de test :
https://github.com/LionelDraghi/ArchiCheck/tree/master/Tests/16_AdaControl
Au passage, cela à révélé un bug (le test ci-dessus échoue).
Par ailleurs, AdaControl a répondu à une de mes questions, sur la
nécessité de traiter le cas d'un composant déclaré dans le fichier de
rules qui porte le nom d'un package existant.
Ici, on a un "composant" Utilities décrit dans la doc, composé entre
autre de packages Ada existants.
Et en même temps, il y a un package Utilities, qu'on ne peut pas
exclure. Donc exit l'idée simplificatrice d'interdire qu'un composant
porte le nom d'un package.
Super test au final, merci beaucoup.
Lionel