Rational Programming Patterns propose des règles de contrôle
qualité dans l'outil Software Analyzer qui permettent d'effectuer
les contrôles les plus courants sur les fichiers COBOL générés.
Mise en oeuvre
Avant de lancer une analyse
du code COBOL, vous devez définir une configuration d'analyse au niveau
du Software Analyzer, et préciser :
- La portée (analyser tout l'espace de travail, un ensemble de projets
ou limiter l'analyse à un ou plusieurs projets),
- Les règles à prendre en compte dans l'analyse. Pour chaque règle
sélectionnée, vous pouvez préciser le niveau de gravité (recommandation,
avertissement ou grave).
Pour lancer l'analyse, faites un clic droit sur un fichier
ou projet. Sélectionnez Software Analyzer puis
la configuration créée au préalable. La vue Résultats Software
Analyzer affiche alors la liste des règles non respectées.
Il y a une arborescence pour chaque catégorie de règles. Le premier
niveau représente la catégorie, le second niveau représente la règle
et le dernier niveau affiche les instances en erreur. Pour voir le
détail d'une violation, faites un clic droit sur le fichier concerné
et sélectionnez Visualiser le résultat. Le
fichier COBOL s'ouvre dans l'éditeur à l'endroit de la violation et
la ligne en erreur est en surbrillance.
Après avoir corrigé
la ou les violations et ensuite sauvegardé, vous pouvez de nouveau
lancer l'analyse du fichier pour vérifier le respect des règles.
Pour
une information complète sur le Software Analyzer, consultez l'aide
en ligne de Rational Developer for System z, dans la rubrique Révision
du code COBOL de la section Développement.
Analyse des entités de design
Software Analyzer
propose une analyse des entités de design Rational Programming Patterns.
Il
existe trois catégories de règles pour cette analyse :
- La catégorie Entité Segment comprend les
règles suivantes :
- Un Segment ne doit pas appeler deux fois la même Rubrique
- Un Segment ne doit pas utiliser de Rubrique non définie
- La catégorie Entités Générables comprend
la règle suivante :
- Une entité générable doit avoir ses noms et noms externes équivalents
- La catégorie Toutes Entités regroupe les
règles suivantes :
- Toute entité de design doit avoir un libellé
- Toute entité de design doit porter au moins un mot-clé
Révision du code spécifique COBOL
Software
Analyzer propose des règles qui s'appliquent uniquement au code spécifique
inséré par l'utilisateur dans un programme COBOL généré.
Les
règles Rational Programming Patterns peuvent être différenciées des
règles standard Rational Developer for System z car elles sont toutes
préfixées par RPP /.
Il existe quatre catégories de règles
RPP. Les règles de la catégorie Programmation Pilotée par Pattern
sont spécifiques à Rational Programming Patterns et n'ont pas leur
équivalent dans Rational Developer for System z.
En revanche,
les règles de Conventions de dénomination, de Performance et de Structures
du programme sont équivalentes aux règles qui existent dans Rational
Developer for System z, mais restreignent le contrôle aux portions
de code spécifique.
- La catégorie RPP / Conventions de dénomination comprend
la règle "RPP / Utiliser un nom de programme qui correspond au nom
du fichier source".
- La catégorie RPP / Performance englobe
les règles suivantes :
- RPP / Eviter d'utiliser des indices pour accéder à une table.
Utiliser des index.
- RPP / Eviter les expressions OCCURS DEPENDING ON
- RPP / Eviter les instructions INITIALIZE. Utiliser des instructions
MOVE élémentaires ou des clauses VALUE.
- RPP / EXEC SQL : Eviter SELECT *
- RPP / EXEC SQL : Utiliser une clause ORDER BY pour déclarer un
curseur
- RPP / Spécifier 0 RECORDS pour les clauses BLOCK CONTAINS dans
des entrées de description de fichier
- RPP / Utiliser des indices binaires
- RPP / Utiliser une instruction EVALUATE plutôt qu'un IF imbriqué
- RPP / Utiliser un nombre impair de chiffres dans une définition
de données COMP-3 ou PACKED-DECIMAL
- La catégorie RPP / Programmation Pilotée par Pattern regroupe
les règles suivantes :
- RPP / Les fonctions utilisateur doivent avoir un commentaire.
La
règle vérifie que toute fonction écrite en spécifique est précédée
d'une ligne de commentaire non vide. Il doit y avoir au moins 1 caractère
de la colonne 8 à la colonne 72.
- RPP / Ne jamais écraser une ligne générée.
La règle
vérifie qu'aucune ligne de code généré, y compris le code issu d'une
Macro, n'est écrasée.
- RPP / Ne jamais écraser une ligne provenant d'une Macro.
La
règle vérifie qu'aucune ligne de code issue d'une Macro n'est écrasée.
- RPP / Tout code utilisateur doit être dans une fonction utilisateur.
La
règle vérifie que tout bloc de code spécifique est inséré dans une
fonction spécifique. Le bloc de code spécifique doit débuter par l'étiquette
"FXXXX" et se terminer par l'étiquette "FXXXX-FN".
Si
une ligne de code spécifique se trouve dans une fonction qui est générée
ou bien qui provient d'une Macro, il y aura violation de la règle.
- La catégorie RPP / Structures du programme comprend
les règles suivantes :
- RPP / Eviter d'utiliser des entrées de niveau 88 dans les
descriptions de données
- RPP / Eviter d'utiliser plus d'une instruction EXIT
par section
- RPP / Eviter d'utiliser SECTION en procedure division
- RPP / Eviter les clauses RESERVE dans les paragraphes FILE-CONTROL
- RPP / Eviter les expressions CORRESPONDING
- RPP / Eviter les expressions NEXT SENTENCE
- RPP / Eviter les expressions THRU dans les instructions PERFORM
- RPP / Eviter les IF sans ELSE
- RPP / Eviter les instructions ACCEPT
- RPP / Eviter les instructions ACCEPT FROM CONSOLE ou FROM SYSIN
- RPP / Eviter les instructions ALTER
- RPP / Eviter les instructions CALL avec un nom de programme littéral
- RPP / Eviter les instructions CANCEL
- RPP / Eviter les instructions de littéral STOP RUN et STOP
- RPP / Eviter les instructions DISPLAY contenant UPON CONSOLE
- RPP / Eviter les instructions ENTRY
- RPP / Eviter les instructions EXIT PROGRAM
- RPP / Eviter les instructions GO TO
- RPP / Eviter les instructions GO TO, sauf celles qui font référence
à un paragraphe EXIT
- RPP / Eviter les instructions XML PARSE
- RPP / Eviter PERFORM, sauf PERFORM de section
- RPP / EXEC CICS : Utiliser DFHRESP pour vérifier la valeur de
retour
- RPP / EXEC CICS : Utiliser l'option RESP
- RPP / EXEC CICS : Vérifier EIBRESP après NOHANDLE
- RPP / EXEC SQL : Vérifier la valeur de SQLCODE après une instruction
EXEC SQL
- RPP / Utiliser CONTINUE plutôt que NEXT SENTENCE dans un plage
de portée
- RPP / Utiliser CURRENT-DATE plutôt que ACCEPT DATE ou ACCEPT TIME
- RPP / Utiliser des expressions THRU avec les instructions PERFORM
- RPP / Utiliser des numéros de niveau 01, 05, 10, 15...
- RPP / Utiliser SEARCH ALL plutôt que SEARCH pour effectuer une
recherche dans une table
- RPP / Utiliser une expression WHEN OTHER avec une instruction
EVALUATE
- RPP / Utiliser un paragraphe EXIT dans chaque section