Rational Developer for System z, version 7.6

Principes de base de SCLM

SCLM est le composant Software Configuration and Library Manager d'ISPF exécuté sur z/OS. Il offre les fonctions de génération et de gestion du code source d'un gestionnaire de configuration de logiciel (SCM). SCLM prend, par exemple, en charge les fonctions d'extraction et de restitution. SCLM fournit un modèle de verrouillage pessimiste de sorte que des fonctions de modification simultanées ne puissent pas avoir lieu sur un membre SCLM verrouillé. Il contient également des fonctions de génération et une hiérarchie de développement pour que le code, lors de la phase de développement et de test, puisse être promu au niveau suivant du développement. Une telle hiérarchie peut exister dans une structure arborescente, comme dans l'illustration ci-dessous. D'autres projets peuvent comporter des niveaux supplémentaires.

Figure 1. Hiérarchie de développement
Hiérarchie de développement

Les fichiers SCLM sont enregistrés dans les projets SCLM. En termes SCLM, projet désigne un ensemble de fichiers et de contrôles SCLM. D'autres systèmes, comme Eclipse, utilisent le terme projet: pour différents éléments. Les fichiers sont enregistrés dans SCLM comme des membres de fichiers partitionnés. Ces fichiers sont accessibles via trois noms qualifiés de niveau. Le premier qualificatif, le qualificatif de haut niveau, est le nom du projet SCLM. Le second qualificatif est un groupe qui agit comme un niveau dans la hiérarchie. Le troisième qualificatif, appelé type, est généralement un ensemble de composants similaires dans un groupe.

Un ou plusieurs groupes de développement peuvent également exister selon la structure du projet. Le code est développé au préalable au niveau le plus bas (par exemple DEV1 ou DEV2), et une fois généré, le code peut être promu au niveau suivant, par exemple TEST. Si le test aboutit, ce code peut être promu au niveau Production. Si le code doit être modifié au niveau Production ou Test, ce membre est à nouveau copié dans le groupe de développement des développeurs et le cycle du code recommence.

Chaque utilisateur de SCLM appartient à un groupe de développement. Ceci permet de déterminer la zone du code du projet à laquelle vous avez accès. Des outils d'administration existent pour configurer le projet SCLM. Pour plus d'informations sur ces outils, visitez le site de SCLM Administrator Toolkit : http://www.ibm.com/software/awdtools/sclmsuite/admintoolk.

Tous les membres sont décrits en fonction des quatre niveaux suivants de la hiérarchie :

Projet
Nom du projet SCLM.
Groupe
Niveau de groupe auquel le membre réside actuellement sur le serveur SCLM.
Type
Type de langage de ce membre, par exemple, COBOL, JAVASRC (code source java), binaire.
Nom du membre
Nom du membre ou du fichier.

En utilisant cette convention de dénomination à quatre niveaux, il est possible de décrire n'importe quel membre SCLM. L'utilisation du Groupe et du Type est significatif lors de l'extraction des listes de projets depuis SCLM et pour l'ajout de membres IDE à SCLM, car ces valeurs doivent être spécifiées.

Le fichier de définition d'architecture (ARCHDEF) est important dans SCLM car il constitue la principale méthode de description du mode de génération des membres SCLM. SCLM utilise le terme Génération pour le processus de création de composants de sortie depuis un composant d'entrée. Une génération est plus généralement une compilation, mais pas seulement. L'équivalent d'une ARCHDEF est un fichier Make. L'ARCHDEF décrit la configuration d'une application sous le contrôle de SCLM et la manière dont elle est construite et intégrée. Les définitions d'architecture sont créées et mises à jour par les développeurs et décrivent l'architecture d'une application. Toutefois, SCLM Developer Toolkit crée et met également à jour des membres d'une définition d'architecture lorsqu'un projet est ajouté à SCLM ou mis à jour par le développeur via l'Explorateur de package. Dans le cas d'applications Java™ enregistrées dans SCLM via SCLM Developer Toolkit, l'ARCHDEF décrit tous les composants contenus dans un projet, ainsi que leur arborescence de répertoires. Les ARCHDEF peuvent également servir à obtenir une liste de projets, à savoir quels composants constituent le projet décrit par l'ARCHDEF. L'ARCHDEF est l'élément principal du processus de génération pour SCLM. Ainsi, exécuter une génération SCLM au niveau d'une ARCHDEF génère les membres contenus dans l'ARCHDEF ou contenus dans des ARCHDEF imbriquées, car de nombreuses ARCHDEF peuvent exister et référencer d'autres ARCHDEF. Lorsque vous enregistrez un fichier dans un projet Java vers SCLM, SCLM Developer Toolkit l'ajoute à un fichier d'ARCHDEF correspondant à ce projet. Le manifeste du projet Java est ainsi toujours à jour. IBM® SCLM Developer Toolkit permet de lancer des processus de génération déjà définis ou d'utiliser les définitions de langage Java/J2EE pour générer des applications J2EE. Ces traducteurs de langage sont décrits plus en détail dans SCLM Developer Toolkit Installation and Customization Guide, les définitions d'architecture SCLM sont décrites dans Software Configuration and Library Manager (SCLM) Guide and Reference

Dans un développement SCLM traditionnel dans le grand système, le code source est souvent enregistré dans différents types comme COBOL, JCL, ASM, etc. Cette situation convient dans un environnement dans lequel il est fréquent d'avoir des composants du même nom dans un projet. Cependant, dans l'univers Java/J2EE, il est courant pour de nombreux projets Java/J2EE d'avoir des composants du même nom. Par exemple, les fichiers ear possèdent généralement un fichier application.xml. Si nous devions suivre le modèle SCLM normal de placement de l'ensemble des codes source d'un type spécifique dans la même bibliothèque, tous les fichiers nommés “application.xml” échoueraient.

Par conséquent, pour correspondre à tous ces types de nom identiques dans un projet SCLM, il est nécessaire de définir un TYPE SCLM pour chaque projet Java/J2EE enregistré dans SCLM. Ensuite, dans ce type, tous les composants peuvent être enregistrés, puisque chaque composant dans un projet Java/J2EE portera un nom unique. D'autre part, différents langages peuvent être appliqués à des fichiers pour appeler différents processus de génération ou de stockage. Un exemple est illustré ci-dessous :

Exemple de processus de stockage/génération basé sur les types de fichier

Le graphique illustre la séparation des membres par type (J2EEPRJ1, J2EEPRJ2 et SOURCE). Des fichiers différents sont enregistrés dans chaque type et sont différenciés par langage. (JAVA, HTML, XML et COB2)

Dans ce groupe de développement, DEV1, la source enregistrée dans le type J2EEPRJ1 peut être le code et les fichiers Java requis pour un projet web. De même pour la source enregistrée dans le type J2EEPRJ2. Le code source enregistré dans le type SOURCE représente les composants basés sur l'hôte COBOL pour l'application web, tous enregistrés dans le même groupe de développement.

Le code Java du premier projet web est enregistré dans SCLM dans le groupe de développement, DEV1, le type J2EEPRJ1 avec un langage JAVA.


Conditions d'utilisation | Commentaires en retour

Ce centre de documentation utilise la technologie Eclipse. (http://www.eclipse.org)