Rational Developer for System z, Version 7.6

SCLM-Grundlagen

SCLM ist die Komponente "Software Configuration and Library Manager" von ISPF und wird unter z/OS ausgeführt. Diese Komponente stellt SCM-Funktionen (Software Configuration Manager) für Quellcodeverwaltung und Builds bereit. SCLM unterstützt beispielsweise die Funktionen Check-out und Check-in. SCLM arbeitet mit einem Pessimistic Locking Model, so dass simultane Bearbeitungsfunktionen für ein gesperrtes SCLM-Member nicht möglich sind. Darüber hinaus stellt SCLM Buildfunktionen und eine Deployment-Hierarchie bereit, so dass der Code in der Entwicklungs- und Testphase auf die nächste Entwicklungsebene hochgestuft werden kann. Eine solche Hierarchie kann wie in der folgenden Abbildung die Form einer Baumstruktur haben. Andere Projekte könnten zusätzliche Hierarchieebenen haben.

Abbildung 1. Entwicklungshierarchie
Entwicklungshierarchie

SCLM-Dateien werden in SCLM-Projekten gespeichert. In SCLM bezeichnet der Begriff Projekt eine Gruppe von Dateigruppen und Steuerangaben. In anderen Systemen, z. B. in Eclipse, wird das Wort Projekt in einer anderen Bedeutung verwendet. Dateien werden in SCLM als Member partitionierter Dateien gespeichert. Auf diese Dateigruppen wird über dreifach qualifizierte Namen zugegriffen. Der erste Qualifier (der High Level Qualifier) ist der Name des SCLM-Projekts. Der zweite Qualifier ist eine Gruppe, die einer Ebene in der Hierarchie entspricht. Der dritte Qualifier, der Typ, ist im Allgemeinen eine Sammlung ähnlicher Komponenten innerhalb einer Gruppe.

Es kann, je nach Struktur des Projekts, eine Entwicklungsgruppe oder mehrere Entwicklungsgruppen geben. Der Code wird anfänglich auf der niedrigsten Ebene (z. B. DEV1 oder DEV2) entwickelt. Nach einem erfolgreichen Build kann er dann auf die nächste Ebene hochgestuft werden, z. B. auf die Ebene TEST. Wenn der Test erfolgreich verläuft, kann der Code auf die Ebene PRODUKTION hochgestuft werden. Falls der Code auf der Ebene PRODUKTION oder TEST geändert werden muss, wird das Member zurück in Ihre Entwicklungsgruppe kopiert, und der Zyklus beginnt von vorn.

Jeder SCLM-Benutzer gehört zu einer Entwicklungsgruppe. Die Entwicklungsgruppe bestimmt, auf welchen Bereich des Projektcodes Sie zugreifen können. Für die Konfigurierung des SCLM-Projekts gibt es Verwaltungstools. Weitere Informationen zu diesen Tools finden Sie auf der Site zum SCLM Administrator Toolkit (http://www.ibm.com/software/awdtools/sclmsuite/admintoolk).

Alle Member werden gemäß der folgenden vierstufigen Hierarchie beschrieben:

Projekt
Der Name des gesamten SCLM-Projekts
Gruppe
Die Gruppenebene, auf der sich das Member zurzeit auf dem SCLM-Server befindet
Typ
Der Sprachtyp des Members, z. B. COBOL, JAVASRC (Java-Quellcode) oder BIN (binär)
Membername
Der Name dieses Members oder dieser Datei

Mit dieser vierstufigen Namenskonvention können alle SCLM-Member beschrieben werden. Die Verwendung von Gruppe und Typ sind von besonderer Wichtigkeit, wenn Projektlisten von SCLM abgerufen und IDE-Member zu SCLM hinzugefügt werden. Dann müssen diese Werte angegeben werden.

Die Datei mit der Architekturdefinition (ARCHDEF) spielt in SCLM eine wichtige Rolle, denn sie beschreibt, wie der Build für die SCLM-Member erstellt werden soll. In SCLM beschreibt der Begriff Build die Erstellung von Ausgabekomponenten aus einer Eingabekomponente. Im Allgemeinen ist eine Builderstellung eine Kompilierung, ohne jedoch auf einen Kompilierungsprozess beschränkt zu sein. Die Analogie zu einer ARCHDEF ist eine Makefile. Die ARCHDEF beschreibt die Konfiguration einer von SCLM gesteuerten Anwendung und gibt an, wie die Anwendung aufgebaut und integriert werden soll. Architekturdefinitionen werden von den Entwicklern erstellt und aktualisiert und beschreiben die Architektur einer Anwendung. Wenn ein Projekt zu SCLM hinzugefügt wird oder vom Entwickler über den Paket-Explorer aktualisiert wird, erstellt das SCLM Developer Toolkit jedoch auch Member von Architekturdefinitionen und aktualisiert diese. Für Java™-Anwendungen, die mit dem SCLM Developer Toolkit in SCLM gespeichert werden, beschreibt die ARCHDEF alle zu einem Projekt gehörenden Komponenten und ihre Verzeichnisstruktur. ARCHDEFs können auch zum Abrufen einer Projektliste genutzt werden, um festzustellen, welche Komponenten zu dem in der ARCHDEF beschriebenen Projekt gehören. Die ARCHDEF ist in SCLM das Hauptelement für den Buildprozess. Wenn in SCLM ein ARCHDEF-Build ausgeführt wird, werden die in der ARCHDEF oder in verschachtelten ARCHDEFs enthaltenen Member erstellt, denn es kann viele ARCHDEFs geben, die wiederum ARCHDEFs referenzieren. Wenn Sie eine Datei zu einem Java-Projekt in SCLM hinzufügen, fügt das SCLM Developer Toolkit sie zu einer ARCHDEF-Datei für das Projekt hinzu, so dass das Manifest des Java-Projekts immer auf dem neuesten Stand ist. Das IBM® SCLM Developer Toolkit gibt Ihnen die Möglichkeit, bereits definierte Buildprozesse auszuführen oder mit Hilfe der Java/J2EE-Sprachdefinitionen einen Build für J2EE-Anwendungen zu erstellen. Die entsprechenden Sprachumsetzer sind ausführlich im SCLM Developer Toolkit Installation and Customization Guide beschrieben. Eine Beschreibung der SCLM-Architekturdefinitionen finden Sie in der Veröffentlichung Software Configuration and Library Manager (SCLM) Guide and Reference.

Bei der traditionellen SCLM-Entwicklung auf dem Großrechner wird der Quellcode oft in verschiedenen Typen gespeichert, z. B. als COBOL, JCL, ASM usw. In einer Umgebung, in der Projekte normalerweise keine Komponenten mit identischen Namen enthalten, stellt dies kein Problem dar. In der Java/J2EE-Welt ist es allerdings allgemein üblich, dass viele Projekte Komponenten mit identischen Namen enthalten. EAR-Dateien enthalten beispielsweise in der Regel eine Datei application.xml. Würden wir nun das normale SCLM-Modell anwenden und alle Quellen eines bestimmten Typs in dieselbe Bibliothek stellen, käme es zu einer Kollision aller Dateien mit dem Namen application.xml.

Damit alle diese ähnlich benannten Typen in ein SCLM-Projekt aufgenommen werden können, muss für jedes Java/J2EE-Projekt, das in SCLM gespeichert werden soll, ein SCLM-TYP definiert werden. Innerhalb dieses Typs können dann alle Komponenten eines Java/J2EE-Projekts gespeichert werden, weil sie dann einen eindeutigen Namen haben. Zusätzlich können verschiedenen Dateien unterschiedliche Sprachen zugeordnet werden, um bei Bedarf verschiedene Speicherprozesse oder Buildprozesse aufzurufen. Schauen Sie sich dazu das folgende Beispiel an:

Beispiel für einen auf Dateitypen basierenden Speicher/Buildprozess

Die Abbildung zeigt die Trennung der Member nach Typ (J2EEPRJ1, J2EEPRJ2 und SOURCE). Die verschiedenen Dateien werden unter dem jeweiligen Typ gespeichert und nach ihrer Sprache unterschieden (JAVA, HTML, XML und COB2).

Innerhalb der Entwicklungsgruppe DEV1 könnte die unter dem Typ J2EEPRJ1 gespeicherte Quelle den Java-Code und die Dateien für ein Webprojekt umfassen. Ähnliches gilt für die unter dem Typ J2EEPRJ2 gespeicherte Quelle. Der unter dem Typ SOURCE gespeicherte Quellcode umfasst die hostbasierten COBOL-Komponenten für die Webanwendung. Alle diese Quellen sind in derselben Entwicklungsgruppe gespeichert.

Der Java-Code für das erste Webprojekt wird in SCLM in der Entwicklungsgruppe DEV1 unter dem Typ J2EEPRJ1 und mit der Sprache JAVA gespeichert.


Nutzungsbedingungen | Feedback

Dieses Information Center basiert auf Eclipse-Technologie. (http://www.eclipse.org)