DE10121790B4

DE10121790B4 - Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem

Info

Publication number: DE10121790B4
Application number: DE10121790A
Authority: DE
Inventors: Johann Pramberger
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-06-03
Filing date: 2001-05-04
Publication date: 2006-11-23
Anticipated expiration: 2021-05-05
Also published as: DE10121790A1; US20020040469A1; US7194730B2

Abstract

Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem,
a) das mindestens einen Server einschließt, der mit einer Vielzahl von Client-Computern verbunden ist, wobei der Server einen Speicher zum Speichern von Produktelementen besitzt, aus denen mit Hilfe von Werkzeugen zum Entwickeln, Testen, und/oder Aktualisieren gemäß einer Projektdefinition Softwarepakete gebildet werden,
wobei das Verfahren umfasst:
b) Definieren der Projektdefinition, die den parallelen Ablauf eines Projekts zum Entwickeln, Testen und/oder Aktualisieren von Softwarepakten auf verteilten System beschreibt,
c) Laden der Projektdefinition im Hauptsystem,
d) Validierung der Projektdefinition im Hauptsystem auf Korrektheit und Konsistenz der Definitionen,
e) Laden der validierten Projektdefinition auf die verteilte Systeme,
f) Lokale Validierung der für die verteilten Systeme relevanten Abschnitte der Projektdefinition in den verteilten Systemen,
g) Bei erfolgreicher lokaler Validierung Speichern und Sperrung der Projektdefinition in den verteilten Systemen,
h) Aktivierung der gespeicherten Projektdefinition auf den beteiligten verteilten Systemen, wobei die...

Description

Gebiet der Erfindung
Die Erfindung bezieht sich auf ein Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem.
Hintergrund der Erfindung
Softwarekonfigurationsmanagement-Umgebungen (Software Configuration Management (SCM) environments) sind als eine lose Gruppierung von zu kombinierenden Werkzeugen (Tools) implementiert. Sie sind bei jeder Installation verschieden. Es gibt keine plattformunabhängige Technologie, um solche Werkzeuge und Bibliotheken unter einem firmenspezifischen Gerüst- und Entwicklungsprozessmodell zu vereinen. Meistens sind die Quellencodehandhabung und -steuerung von der Kompilierlogik (Erstelllogik) und anderen verwendeten Werkzeugen getrennt. Außerdem pflegen die zur Verfügung stehenden Quellenkontrollbibliotheken ihr eigenes Format, sodass der Benutzer Auslagerungen und Zurückübertragungen hinsichtlich eines Dateisystems durchführen muss. Andererseits bevorzugen es die Entwickler immer, mit der Dateisystemansicht zu arbeiten, da ihnen dort die meisten Werkzeuge zur Verfügung stehen und da die Ansicht für die Entwickler transparent ist. Sie bevorzugen es, Editier-, Kompilier- (eine Form des Erstellens) und Debug-Operationen mit dem Aussehen und der Funktionalität eines Dateisystems durchzuführen, möchten aber vorzugsweise im Hintergrund alle Vorteile einer Quellenkontrollbibliothek haben, um eine Gruppenentwicklungsstruktur zu ermöglichen.

Ein Problem von Systemen nach dem Stand der Technik besteht darin, dass die bekannten Implementierungen proprietäre Implementierungen zur Verfügung stellen, denen die Kompatibilität mit anderen Systemen fehlt. Es gibt Ansätze, um dieses Problem zu lösen, aber solche Ansätze stellen keine offene und plattformunabhängige Definition zur Verfügung, die eine einzige Plattform für die Verwendung mit unterschiedlichen Betriebssystemen, Bibliothekimplementierungen und Werkzeugen ermöglicht. Ein Beispiel eines bekannten Systems, das einen deklarativen Ansatz verwendet, stellt der „Software Configuration and Library Manager (SCLM)" von IBM dar, der Teil der IBM OS/390 Betriebssystemfamilie ist und in der Veröffentlichung „Software Configuration and Library Manager (SCLM) Project Manager's Guide", OS/390 Version 2, Release 5.0, Veröffentlichungsnummer SG28-1319-02, 1998, von IBM beschrieben wird. Dieses Produkt verwendet für die Elemente, die in einem Bibliothekssystem kontrolliert werden, und für die Funktionen, die zur Verfügung gestellt werden, proprietäre Definitionen, aber es stellt keine Unterstützung für ein Bibliothekssystem und ein Betriebssystem zur Verfügung. Es fehlt außerdem die eingebaute Unterstützung des Prozessflusses.

Ein anderes bekanntes System ist durch ein als „TeamConnection" bezeichnetes Produkt vertreten, das in der Veröffentlichung „Getting Started with the TeamConnection Clients, Version 3.0", Veröffentlichungsnummer SC34-4552-02, 1998, von IBM beschrieben wird; es verwendet nicht den deklarativen Ansatz, sondern enthält bestimmte funktionelle Elemente wie Protokollierungsansätze, Datensicherheit und Benachrichtigung. Auch dieses System bietet keine plattformunabhängige Unterstützung.

Außerdem arbeiten die Entwickler in den bekannten Umgebungen auf einem Dateisystem, um ihre Arbeit zu erledigen, und sie sind nur ab und zu daran interessiert, ihre Quellen mit dem Back-End- Bibliothekssystem zu synchronisieren, um ihre Dateien zu speichern und das Bibliothekssystem zu aktualisieren, das als Basis für einen gemeinsamen Treiber dient. Es ist jedoch nicht sichergestellt, dass die Erstellungen für alle Benutzer und Back-End-Prozesse gleich sind.

Firmen, die für ihr eigenes Geschäft Softwareprodukte erstellen oder solche Produkte verkaufen, benötigen eine Entwicklungsumgebung, die sicherstellt, dass definierte Regeln und Prozesse für unterschiedliche Zwecke wie etwa Sicherheit, Qualität, Zuverlässigkeit und rechtliche Aspekte befolgt werden, und jede benötigte Technologie unterstützt. Keines der bekannten Produkte erlaubt es, alle benötigten Technologien und Prozesse abzudecken. Die existierenden Werkzeuge und Produkte mit ihren Funktionen und ihren Prozessen müssen jedoch in ein definiertes Gerüst eingebaut werden, um sie alle in einer klar definierten Lösung zu integrieren.

Build-Automationswerkzeuge „Ant" bzw. „Make" erlauben nur eine Definition von GTransformationen von einem Ursprungsformat in ein anderes Format. Es werden Abhängigkeiten (Dependencies) definiert. Diese bestehen aber nur in der Reihenfolge der Abläufe der notwendigen Transformationen und der zeitlichen Unterschiede der Entstehung der beteiligten Files. Die genannten Build-Werkzeuge definieren jedoch keine Beziehungen zu einem Sourceverwaltungssystem (Versionierungssystem) und auch nicht die Kontrolle der Sourcen und deren Versionen und Releasebildung.

Sourceverwaltungssysteme wiederum optimieren die Verwaltung und die Änderung von Sourcen, aber nicht die Erzeugung von technisch ausführbaren Programmpaketen, was die Build-Werkzeuge wiederum tun. Systeme, die Sourceverwaltung als auch Build-Automation vereinen, sind z.B. zOS SCLM und ClearCase. Allerdings erlauben diese Systeme keine gesamtheitliche Definition einer plattformübergreifenden Entwicklungsumgebung als ein Framework.

Es ist daher Aufgabe der vorliegenden Erfindung ein Softwarekonfigurationsverfahren bereit zu stellen, das ungeachtet der Entwicklung, Aktualisierung und des Tests von Produktelementen auf verschiedenen Plattformen mit unterschiedlichen Werkzeugen, die nicht miteinander kompatibel sind, eine konsistente Erzeugung von Sofwarepaketen sicherstellt.

Die Lösung dieser Aufgabe umfasst folgende Schritte:
Definieren der Projektdefinition, die den parallelen Ablauf eines Projekts zum Entwickeln, Testen und/oder Aktualisieren von Softwarepakten auf verteilten Systemen beschreibt,
Laden der Projektdefinition im Hauptsystem,
Validierung der Projektdefinition im Hauptsystem auf Korrektheit und Konsistenz der Definitionen,
Laden der validierten Projektdefinition auf die verteilte Systeme,
Lokale Validierung der für die verteilten Systeme relevanten Abschnitte der Projektdefinition in den verteilten Systemen,
Bei erfolgreicher lokaler Validierung Speichern und Sperrung der Projektdefinition in den verteilten Systemen,
Aktivierung der gespeicherten Projektdefinition auf den beteiligten verteilten Systemen, wobei die Aktivierung die Vorbereitung der physischen Umgebung, wie sie für die Projektdefinition definiert ist, umfasst,
Entsperrung der Projektdefinitionen auf den verteilten Systemen bei erfolgreicher Aktivierung genau aller Systeme, wodurch die Arbeit am Projekt auf den verteilten Systemen freigegeben wird.

Überblick über die Erfindung

Das Verfahren gemäß der Erfindung, wie in den Ansprüchen definiert, umfasst den Schritt der Definition einer gemeinsamen erweiterbaren Softwarekonfigurationsformatierungssprache (extensible software configuration markup language, XSCML), die sich dazu eignet, ein Projekt zu definieren, einen Speicherzugriff auf Produktelemente und -pakete durchzuführen, die Prozesse und die Werkzeuge auf das eine oder mehrere Bibliotheksysteme abzubilden und die Beziehungen zwischen den Produktelementen zu definieren. Durch Verwendung dieser gemeinsamen Softwarekonfigurationsformatierungssprache wird ein systemunabhängiges Softwarekonfigurationsgerüst erzeugt, um die Produktelemente und Prozesse zu beschreiben und ihre Zugriffsparameter und ihre Beziehungen untereinander zu definieren.

Das systemunabhängige Softwarekonfigurationsgerüst ist im Speicher eines oder mehrerer Server gespeichert und besitzt die zugeordneten Produktelemente, Prozesse und Werkzeuge in den Speichern. Ausgewählte Produktelemente, Werkzeuge und Prozesse werden durch mindestens einen der an den oder die Server angehängten Clients unter Verwendung der Befehle der gemeinsamen erweiterbaren Softwarekonfigurationsformatierungssprache aufgerufen, während die Benutzer ihre eigenen Sprachen zum Entwickeln, Aktualisieren oder Testen der aufgerufenen Produktelemente verwenden können. Die gemeinsame Softwarekonfigurationsformatierungssprache basiert vorzugsweise auf der erweiterbaren Formatierungssprache „XML" (XML, Extensible Markup Language).

Gemäß einem Aspekt der Erfindung wird das systemunabhängige Softwarekonfigurationsgerüst in den Speichern einer Vielzahl von geografisch verteilten Computersystemen gespeichert, die miteinander durch ein Kommunikationsnetz verbunden sind. Zugriff und Verwaltung der zugeordneten Produktelemente, Prozesse und Werkzeuge in den lokal verteilten Systemen und die Kommunikation zwischen diesen Systemen wird durch gemeinsame erweiterbare Softwarekonfigurationsformatierungssprache durchgeführt, während das Editieren von Produktelementen in anderen Sprachen erfolgen kann, die von der gemeinsamen erweiterbaren Softwarekonfigurationsformatierungssprache unabhängig sind.

Die Verwendung eines solchen Ansatzes erlaubt einen Austausch von Produktelementen mit anderen Orten, an denen jedem der zusammenarbeitenden Orte das gleiche Systemverhalten zur Verfügung gestellt wird, selbst wenn unterschiedliche Implementierungen verwendet werden, die unterschiedliche Dateisysteme und Bibliothekssysteme umfassen können. Die lokalen Bibliothekssysteme können sogar auf reine Dateisysteme reduziert werden, die in einer Datenbank, die einige Metadaten für lokale Elemente enthält, die alle im Web durch Web-Technologien wie WebDAV („Web-based Distributed Authoring and Versioning" abgedeckt werden, einen Satz an Erweiterungen des HTTP-Protokolls umfassen, der es den Benutzern ermöglicht, gemeinsam Dateien auf fernen Web-Servern zu editieren und zu verwalten.

Die XSCML-basierten Definitionen können zur Erstellung einer Umgebungsdokumentation, die gedruckt werden oder über das Web zugänglich sein soll, verarbeitet werden. Dies führt zu Umgebungsdefinitionen, die einerseits die technischen Konstrukte beschreiben, die zum Ausführen des Systems zur Softwarekonfigurationsumgebung benötigt werden, aber zugleich einen selbstdokumentierenden Ansatz desselben zur Verfügung stellen. Um die Dokumentationsmöglichkeiten zu erweitern, können zusätzliche XML-Kennungen ähnlich der HTML-Kennungen zur Ergänzung des technischen Texts zugelassen werden, um einerseits den Kommentar zu den technischen Elementen zu liefern, aber andererseits auch die Erstellung der Benutzer- und Verwaltungsdokumentation aus der gleichen Quelle zu ermöglichen.

Kurzbeschreibung der Zeichnungen
Im Folgenden wird eine bevorzugte Ausführungsart der Erfindung mit Bezug auf die Zeichnungen und auf ein Anwendungsbeispiel beschrieben. Die Zeichnungen zeigen:
1: ein schematisches Blockdiagramm eines bekannten Server-Computers, der für Implementierungen der im vorliegenden Dokument gezeigten Erfindung verwendet werden kann;
2: ein allgemeines Blockdiagramm eines Computersystems, das zur Ausführung einer Ausführungsart der Erfindung angepasst ist;
3: ein allgemeines Blockdiagramm eines verteilten Computersystems, das zur Ausführung einer anderen Ausführungsart der Erfindung angepasst ist;
4A: ein schematisches Blockdiagramm des Systems zur Softwarekonfiguration gemäß der Erfindung;
4B: ein schematisches Blockdiagramm des Datenflusses zwischen Hauptkomponenten des Systems gemäß der Erfindung;
5: ein Blockdiagramm eines vereinfachten Beispiels eines logischen Projektansichtsverlaufs, der den Datenfluss der Elemente definiert;
6: ein Blockdiagramm der logischen Projektansichtshierarchie eines Softwareprojekts, das unter Verwendung des Verfahrens und Systems gemäß der Erfindung entwickelt und getestet wird;
7: einen Unterabschnitt einer logischen Projektansichtshierarchie, der die Kombination mit einem definierten Prozessfluss zeigt;
8: eine physische Memberdarstellung eines Projekts, das unter Verwendung des Systems von 4 entwickelt und getestet wird,
9: ein Blockdiagramm der logischen Projektansicht mit mehreren Hierarchien;
10: ein Blockdiagramm der logischen Projektansicht eines Softwareprojekts, das unter Verwendung des verteilten Systems gemäß 3 entwickelt und getestet wird;
11: ein Blockdiagramm des Projektaktivierungsprozesses für die Zusammenarbeit der verteilten Systeme gemäß 3;
12: ein Flussdiagramm des Prozesses zur Initialisierung des XSCML-Systems;
13: ein Flussdiagramm des Prozesses zur Verwaltung der Projektdefinitionen; und
14: ein Flussdiagramm des Prozesses zur Durchführung von Benutzer-Client-Aktionen.
Detaillierte Beschreibung einer bevorzugten Ausführungsart der Erfindung
1 bezieht sich auf ein bekanntes Computersystem, das als Server innerhalb der beschriebenen Ausführungsart der Erfindung arbeitet. Das Computersystem umfasst mindestens einen Prozessor 10, der durch einen Datenkanal 11 mit einem System-RAM 12 und einem Speicher 14 verbunden ist, welcher ein Festplattenspeicher sein kann, der zum Speichern von mindestens einer Datenbank des Systems zur Softwarekonfiguration gemäß der Erfindung verwendet wird. Das Computersystem umfasst des Weiteren eine Tastatur- und Mauseinheit 15 zur Eingabe von Daten und Befehlen und eine Anzeigeeinheit 16, die beide mit dem Datenkanal 11 verbunden sind. Des Weiteren umfasst das System einen Netzkommunikationsadapter 17, durch den der Server eine Datenübertragung an ferne Computersysteme mittels eines digitalen Kommunikationsnetzes 18, wie etwa dem Internet, herstellen kann. Der Kommunikationsadapter 17 stellt auch die Datenübertragung an mindestens einen Client-Computer, der mit dem Server von 1 fest verbunden ist, und zu anderen Server-Systemen, die ein ähnliches Design wie das in 1 gezeigte haben können, zur Verfügung.
2 zeigt ein vereinfachtes Blockdiagramm eines Computersystems, wie es zur Ausführung einer Ausführungsart der Erfindung verwendet wird. Dieses Computersystem umfasst einen ersten Server 20, der dem Server aus 1 entspricht und ein Programm ausführt, das erweiterbarer Softwarekonfigurationsformatierungssprachprozessor 22 oder kurz XSCML-Prozessor genannt wird. Der Server 20 ist mit einem Speicher 23 verbunden und steuert diesen, der unter anderem eine Systemdatenbank 24 enthält, die Daten speichert, die vom XSCML-Prozessor 22 verwendet werden. Eine Anzahl an Workstations 25 sind mit dem Server 20 durch seine Netzadapter 17, in 2 nicht gezeigt, verbunden. Die Workstations 25 fungieren als Clients des Servers 20 und haben durch die Steuerung des XSCML-Prozessors 22 Zugriff auf die Datenbank 24 im Speicher 25. Das Computersystem von 2 umfasst des Weiteren eine Gruppe zweiter Server 27, die mit dem ersten Server 20 zum Datenaustausch mit dem ersten Server 20 und zur Durchführung des Zugriffs auf die Datenbank 24 in seinem Speicher 14 durch die Steuerung des XSCML-Prozessors 22 verbunden sind. Die zweiten Server 27, im vorliegenden Dokument auch als Erstellungsserver bezeichnet, sind in ihrem Design dem ersten Server 20 ähnlich und führen Kompilier- oder Erstellungsprogramme aus, die in den Speichern 14 in jedem der Server 27 installiert sind. Ein solcher Erstellungsserver kann selbst eine oder mehrere Verbindungen mit einem LAN-Datenserver durch einen Kommunikationsadapter 17, wie in 1 gezeigt, zum Zugriff auf Werkzeuge und Daten haben.
Eine Anzahl an Computersystemen, von denen jedes dem Computersystem von 2 entspricht, kann über ein digitales Kommunikationsnetz wie etwa das Internet verteilt und verbunden sein. 3 zeigt drei Computersysteme 30, 31 und 32, die durch ein Kommunikationsnetz 34 verbunden sind. Zwischen den Systemen 30, 31 und 32 können große Entfernungen liegen. So kann z. B. das System 30 in Deutschland, das System 31 in Indien und das System 32 in den USA installiert sein.
Das System und das Verfahren gemäß der Erfindung dienen der Entwicklung und dem Testen komplexer Softwareprodukte, von denen jedes aus einer Vielzahl von Softwarekomponenten besteht, die im vorliegenden Dokument als Softwareelemente bezeichnet werden, die unterschiedliche Versionen des gleichen Softwareprodukts bilden können. Aufgrund der Größe und der Komplexität des Produkts müssen die Softwareelemente durch eine Gruppe von Entwicklern entwickelt und getestet werden und separat kompiliert und miteinander verknüpft werden, um ein Paket zu bilden, das auf seiner höchsten Stufe das Softwareprodukt darstellt. Das Softwareprodukt und seine Elemente sind kontinuierlichen Aktualisierungen und weiteren Entwicklungen unterworfen, mit dem Effekt, dass vom gleichen Softwareprodukt und seinen Elementen immer unterschiedliche Versionen existieren, und dass zu einem gewissen Zeitpunkt eine neue Version die momentan verwendete Version des Softwareprodukts ersetzen wird. Die parallele Durchführung der Entwicklung, des Testens und der Aktualisierung eines Programmprodukts durch verschiedene Leute wird als Projekt bezeichnet. Die Erfindung stellt ein Verfahren und ein System zur Verfügung, die es erlauben, ein Projekt effektiv zu verwalten, selbst wenn die Entwicklung, das Testen und die Aktualisierungen der Softwareproduktelemente gleichzeitig unter unterschiedlichen Umgebungen an verschiedenen Orten, die voneinander weit entfernt sind, ausgeführt werden.
Eine zentrale Komponente des Systems gemäß der Erfindung ist der XSCML-Prozessor 22, der die Softwareelemente, ihre unterschiedlichen Versionen und Beziehungen verwaltet, und Zugriffe auf die Datenbank und die dem System verfügbaren Prozesse und Werkzeuge steuert. 4A zeigt die Komponenten des Systems, die durch den XSCML-Prozessor 22 gesteuert oder verwendet werden. Ein Teil der Komponenten sind die Datenabschnitte 41–45, die in der Datenbank 24 enthalten sind. Diese Komponenten umfassen Sätze von Projektmetadaten 41, die Daten einschließen, die den Status der verschiedenen Softwareelemente und ihre Beziehungen untereinander darstellen. Weitere Komponenten sind ein Abschnitt 42 mit einer Vielzahl von Produktelementen, der Software-Delta-Elemente enthält, die Änderungen an Elementen, die sich in der Entwicklung befinden oder Aktualisierungsoperationen unterworfen werden, dokumentieren. Ein Produkt- und Paketdefinitionsabschnitt 43 ist einer Vielzahl von Produktelementen zugeordnet, die zu unterschiedlichen Produktversionen gehören können. Ein Beispiel für Produktelementdefinitionen wird unten beschrieben. Ein Satz Eingabeelemente 44 und generierte Elemente 45 sind mit dem Abschnitt Paketdefinitionsblock 43 verknüpft. Der XSCML-Prozessor 22 besitzt weitere verfügbare Projektdefinitionsdaten 40, die Datenflussdefinitionen, Prozessdefinitionen und Prozessflussdefinitionen umfassen. Eine weitere Komponente des Systems ist ein Satz von Dialog- oder Befehlszeilenschnittstellen 46, die vom XSCML-Prozessor 22 als Benutzerschnittstellen oder Befehlsanwendungsschnittstellen verwendet werden und die an die Client-Workstations 25 verteilt werden. Der XSCML-Prozessor 22 kann eine Verbindung zu den Erstellungsservern 27 herstellen, die in der Lage ist, einen der mehreren auf dem Server 27 installierten oder auf einem Werkzeug-Server 50 gespeicherten Compiler auszuführen. Der XSCML-Prozessor 22, die Client-Workstations 25 und der Erstellungsserver 27 besitzen je einen Satz von Werkzeugen 48, 49 und 50, die zur Durchführung der Schritte zur aktivierten Verarbeitung verfügbar sind. Der XSCML-Prozessor 22 kann z. B. auch über ein Kommunikationsnetz mit einem weiteren XSCML-Prozessor 52 verbunden sein, der auf einem anderen Server 51 an einem fernen Ort läuft, um eine Gruppenarbeit bei der Entwicklung, dem Testen und der Aktualisierung von Softwareprojekten zu ermöglichen, wie es in Verbindung mit den 3 und 10 beschrieben wird.
Die Datenbank 24, die im Speicher 23 gespeichert ist und die die Komponenten 40–45 enthält, bildet das Bibliothekssystem des XSCML-Prozessors 22, das einen beschreibenden Satz von Definitionen in einer erweiterbaren Systemkonfigurationsformatierungssprache (Extensible System Configuration Markup Language, XSCML) zur Verfügung stellt. Diese Sprache kann zur Erzeugung von allgemeinen Definitionen aller Komponenten, die in dem Bibliothekssystem enthalten sind, verwendet werden, und wird von den Servern 20, 51 und 27 und den Clients 25 verwendet. Der XSCML-Prozessor 22 führt den Zugriff auf die Komponenten 40–45 und die zugrunde liegende Abbildung dieser Komponenten auf das Bibliothekssystem durch. Er ruft auch die verfügbaren Prozesse auf, die auf die Produktelemente, die in dem Bibliothekssystem gespeichert sind, angewendet werden. Der XSCML-Prozessor 22 identifiziert die Produktelemente selbst und ihre Beziehungen untereinander in Bezug auf Eingaben, Ausgaben und logische Abhängigkeiten und spezifische Parameter der handzuhabenden Softwarepakete, wie etwa Anwendungen, Korrekturen oder Arbeitselemente. Darüber hinaus werden die allgemeinen Definitionen, die durch den XSCML-Prozessor 22 zur Verfügung gestellt werden, auch zur Beschreibung der Zugriffsregeln für die Daten und Prozesse, des Prozessarbeitsflusses, der Fehleraufzeichnung, der Benachrichtigungsregeln, der Hochstufungsregeln, der Erstellungsregeln und der Editierregeln verwendet.
4B zeigt die Kommunikation zwischen den Hauptkomponenten des Systems gemäß 4A. Der XSCML-Prozessor 22, der auf dem Server 20 läuft, ist mit mindestens einem Client 25, mindestens einem Erstellungsserver 27 und den Werkzeugen 48 verbunden. Des Weiteren ist der XSCML-Prozessor 22 mit dem XSCML-Prozessor 52 verbunden, der auf dem Server 51 läuft. Die Kommunikation zwischen dem XSCML-Prozessor 22 und den Komponenten 25, 27, 48 und 52 findet durch Datenströme im XSCML-Format statt. Diese Datenströme umfassen Produktelemente und -pakete wie auch Projektdefinitions- und Prozessdefinitionsdaten, Statusdaten und Befehle wie etwa den Aufrufbefehl für ein ausgewähltes Werkzeug 48.
Durch Verwenden der gemeinsamen erweiterbaren Softwarekonfigurationsformatiersprache ist der XSCML-Prozessor 22 in der Lage, eine Kontrolle der Produktelemente zur Verfügung zu stellen, die Folgendes umfasst:

– Veränderungskontrolle, die Veränderungen der Produktelemente über verschiedene Versionen des Produkts und Parallelzugriffe von Elementen durch unterschiedliche Personen verfolgt;
– Versionskontrolle, die unterschiedliche Iterationen speichert und zurückholt, im vorliegenden Dokument auch als Delta-Elemente 42 der Produktelemente bezeichnet;
– Sachverwaltung, um Probleme und Merkmale zu erstellen, zu verfolgen und zu verwalten;
– Prozesskontrolle, um eine Folge von Schritten zu definieren und zu verfolgen, die eine Organisation durch den Entwicklungsprozess mit definierten Aufgaben für die an diesem Prozess beteiligten Leute auf einem vorab definierten Weg begleitet; die Prozesskontrolle adressiert auch den Datenfluss und den Fortschrittsfluss;
– Erstellungsverwaltung, die eine Automation der Übersetzung der Produktelemente 44 und 45 in andere Formen 45 zur Verfügung stellt;
– Verpackung, um zur Auslieferung des Produkts aus der Systembibliothek Daten zu extrahieren und um das Produkt für die Auslieferung in ein definiertes Format zu bringen.

Die gemeinsame erweiterbare Softwarekonfigurationsformatierungssprache XSCML basiert aus mehreren Gründen auf der Syntax der allgemein bekannten erweiterbaren Formatierungssprache (Extensible Markup Language, XML):

– XSCML ermöglicht die Verwendung einer problemorientierten, aber auf einem Standard basierenden Syntax;
– XSCML umfasst in seiner Konzeption die Web-Integration, was bedeutet, dass Bezüge zu Produktelementen nicht nur innerhalb einer Datenbank oder eines Dateisystems vorliegen können, sondern dass auch ein Bezug auf jedes Element, das über das Web oder über einen Webserver erreichbar ist, falls erforderlich, hergestellt werden könnte;
– Es gibt bereits eine Vielzahl von Werkzeugen, die die Syntaxanalyse und grafische Darstellung von XML-Implementierungen unterstützen, und auch XML-basierte Anwendungen, die die XML-Syntax, wie WebDAV, verwenden, die bei der Implementierung eines XSCML-Gerüsts verwendet werden können.
– XSCML ist plattformunabhängig definiert, besonders wenn die Programmiersprache JAVA für den Parser und die Logik verwendet wird;
– XSCML bietet die Fähigkeit zur Umwandlung zwischen verschiedenen Arten von XSCML-Anwendungen;
– XSCML ermöglicht die Erzeugung selbstdokumentierender Anwendungen, die auf dem Bildschirm oder in Form gedruckter Materialien von Menschen gelesen werden können oder zur Verteilung oder Veröffentlichung mittels des Webs verwendet werden können.

XSCML zwingt die Entwickler nicht, XML für die Softwareentwicklung und Aktualisierungsarbeit zu verwenden. In Einklang mit den Eigenschaften von XSCML ist der Inhalt eines jeden Produktelements von den durch den XSCML-Prozessor 22 gesteuerten Konfigurationsschritten unabhängig. Somit kann die Entwicklung der Produktelemente in jeder nativen Sprache durchgeführt werden. Grafische Benutzerschnittstellen können die Verwendung der XSCML-definierten Informationen erleichtern.
Mit Produktelementen arbeiten
Wie bereits erwähnt, gibt es zwei Möglichkeiten, die Umgebung aus der Perspektive eines Entwicklers zu betrachten. Die eine besteht darin, mit Dateien auf einem Dateisystem zu arbeiten und eine Organisation mit Verzeichnissen zu verwenden, die andere besteht darin, auf ein Bibliothekssystem zu blicken, um mit diesem zu arbeiten. Anstelle von Dateien kann ein Objektmodell anwendbar sein, das das weitverbreitete Dateisystemmodell erweitert und in dem die Dateien und Verzeichnisse als besondere Objekte behandelt werden. Aus Gründen der Einfachheit wird im Folgenden das Dateisystemmodell verwendet. In der Praxis arbeiten die Entwickler hauptsächlich auf Basis des Dateisystems, da sie dort die größte Flexibilität für die Verwendung unterschiedlicher Werkzeuge besitzen. Die Bibliotheksansicht ist nur wichtig, um ein Sicherungs-Repository für die Speicherung von Daten zu haben, sodass die Arbeitsergebnisse gespeichert werden.
In der Praxis arbeitet der Entwickler an Projekten, was bedeutet, dass der Entwickler für ein bestimmtes Projekt eine statische Ansicht des Projekts hat, solange das Projekt am Laufen ist und er daran interessiert ist, während dieses Zeitraums reproduzierbare Daten zur Verfügung zu haben. Die bekannten Verfahren zur Durchführung der Entwicklung von Softwareprojekten lösen nicht die Beziehung und stufen die Softwareelemente nicht zwischen den Hierarchien und der Entwicklungsumgebung des Entwicklungsteams hoch. Wenn ein solcher Ansatz auf eine Gruppe von Entwicklern erweitert wird, in der jeder Entwickler ein Einzelbenutzer-basiertes Entwicklungsarbeitsrahmenprodukt verwendet, wird jedes Projekt eines Entwicklers auf ein Datenspeicher-Verzeichnis abgebildet, das z. B. durch ein LAN erreichbar ist, in dem gemeinsame Treiber in einem gemeinsamen LAN-Verzeichnis integriert sind. Dies führt zu der in 5 gezeigten Struktur, in der die Gruppe in drei parallelen Arbeitsrahmenprodukten DEVA, DEVB und DEVC Produktelemente erzeugt. Diese Arbeit wird dann einer Testoperation unterzogen, d. h. in einem LAN-Verzeichnis TEST, deren Ergebnis das Endprodukt, d. h. in einem LAN-Verzeichnis PROD, ist. Solche Verzeichnisse werden im vorliegenden Dokument auch als Gruppen bezeichnet. Eine Grundregel ist, dass Modifikationen nur in den unteren Gruppen vorgenommen werden dürfen. Wie in 5 gezeigt, können Produktelemente nur von TEST 55 zu PROD 54 verschoben werden, und Elemente können nur von DEVA, DEVB oder DEVC zu TEST 55 verschoben werden. Editierungen können nur durch DEVA, DEVB und DEVC vorgenommen werden. Die Blöcke 54–58 stellen die in der Datenbank oder in den Speichern 14 der Client-Workstations gespeicherten Daten dar.
Wichtig ist, dass das gleiche Element eines in einer Struktur wie 5 entwickelten Produkts gleichzeitig in unterschiedlichen Modifikationsinstanzen in allen Blöcken 54 bis 58 existieren kann.
Es ist auch wichtig, die unterschiedlichen Arten von Gruppen in einer solchen Struktur zu verstehen, die unten beschrieben und auch in Tabelle 1 gezeigt ist:

– Editiergruppen: Dies sind immer die niedrigsten Gruppen in einer Gruppenhierarchie. Erstellung und Änderungen von Elementen können nur in solchen Editiergruppen durch Client-Programme über XSCML-APIs oder XML-Ströme vorgenommen werden.
– Übergangsgruppen: Dies sind Gruppen, die eine oder mehrere niedrigere Gruppen im Baum zum Empfang von Paketen haben. Sie haben nur eine in der Hierarchie höhere Gruppe, um die Pakete weiter hochzustufen.
– Zielgruppen: Diese Gruppen sind die gleichen wie die Übergangsgruppen, aber sie dürfen keine Pakete zu ihren höheren Gruppen, falls vorhanden, hochstufen.
– Grundgruppen: Diese Gruppen sind die gleichen wie die Zielgruppen, aber die Pakete werden eingefroren, was bedeutet, dass keine Hochstufungen von niedrigeren Gruppen und zu höheren Gruppen möglich sind. Mit anderen Worten: editierbare Member in diesen Gruppen können nie verändert werden.

TABELLE 1:
In Hinblick auf diese Situation definiert die Erfindung Softwareprojekte durch einen XML-Ansatz. Im Folgenden wird angenommen, dass ein Client Projektelemente oder Daten von einem XSCML-System durch eine XSCML-Projektdefinition erhält, die anzeigt, welche Dateien im Dateisystem verarbeitet werden sollen und welche Bibliotheken mit den Verzeichnissen verbunden sind, um den Inhalt und das Verschieben der Dateien innerhalb des Dateisystems zu steuern.
Die Projektdefinition enthält drei Hauptabschnitte:

– Datenflussdefinition: Diese Kennungen definieren die logische Datendarstellung zusammen mit der physischen Datenabbildung, die im realen Produkt unter Verwendung des XSCML-Prozessormodells gespeichert ist. Sie umfasst Projekt, Gruppe, Typ, Datei und Elementnotation. Dieser Hauptabschnitt ist unten im Beispiel 1 gezeigt.
– Prozessflussdefinition: Diese Kennungen definieren die Reihenfolge von Prozesszuständen, die sich mit dem Datenfluss schneiden. Jeder Prozesszustand kann sogar einige Datenflussaktivitäten auslösen, z. B. die Erstellung, die Hochstufung oder das Erstellen von Delta-Versionen des Elements oder der Pakete. Dies ist beispielhaft unten in Beispiel 2 gezeigt.
– Prozessdefinitionen: Diese Kennungen definieren die Aktionsschritte, die Elementen für Benutzeraktionen wie Editieren, Erstellen oder Hochstufen zugeordnet sind. Dies ist in den Beispielen 7 und 8 gezeigt.

Dateien sind immer in einem XSCML-geschützten Modus, der von der Fähigkeit des Dateisystems, die zumindest ein Leserecht ist, abhängt. Aktualisierungen erfolgen nur durch einen XSCML-Prozessor, der durch den Client ausgelöst wird. Das Bibliothekssystem, das einen XSCML-Prozessor implementiert, kann zur Wiederherstellung eine komplette Kopie der aktuellen Produktversion wie in dem Dateisystem enthalten. Diese Kopie wird vom Client nicht gesehen, welcher den Eindruck hat, dass er mit einem zugrunde liegenden Dateisystem arbeitet. Damit der Client unterschiedliche mögliche Dateiabbildungen nicht merkt, wird für die Arbeit ein logisches Abbildungskonzept zur Verfügung gestellt. In einem einfachen Projekt kann die logische auf die physische Abbildung eine 1:1-Abbildung sein. Dieses Konzept kann wie folgt aussehen:

Projekt: Dies ist ein Unterfangen mit vorgegebenen Aufgaben, Größe und Dauer. Ein Projekt kann in der Entwicklung eines Softwareprodukts oder in einer Aktualisierung eines existierenden Softwareprodukts bestehen. Für ein Projekt kann der Client durch eine definierte Abbildung das Stammverzeichnis kennen, mit dem er arbeitet.
Gruppe: Ein Satz von Projektdatensätzen der Elementhierarchie. Der Client kann über die definierte Abbildung das Unterverzeichnis kennen, das dem Stammverzeichnis folgt, das Idealerweise gleich dem Gruppennamen lautet. Eine Gruppe definiert eine aktive Version der definierten Qualität eines Produkts.
Typ: Ein Typ kategorisiert Elemente eines Projekts wie Module, Makros, Objektcode, Listen und Lademodule. Der Client kann über die definierte Abbildung des logischen auf den physischen Namen die Erweiterung einer Datei kennen, die zu einem Typ gehört, oder den Verzeichnisnamen eines Typs.
Member: Es identifiziert einen Datensatz oder ein Produktelement, oder es enthält mehrere Elemente und dient als deren symbolische Adresse. Es ist Atomelement, das durch das Dateisystem eines zugrunde liegenden Betriebssystems verwaltet wird. Einem Member ist eine XSCML-Sprache zugeordnet.
Element: Die Atomeinheit, die durch ein XSCML-System verwaltet werden soll. Dies könnte durch eine 1:1-Relation zwischen Element und Member erfolgen, bei der ein Element das Gleiche wie ein Member ist. Der Umfang eines Elements ist durch die in einem XSCML-System verwendete Entwicklungssprache, Produkte und Werkzeuge definiert. Einem Element ist eine XSCML-Sprache zugeordnet.
Sprache: Dies ist eine Prozessdefinition, die in einer XSCML-Syntax definiert ist, die die bei bestimmten XSCML-Aktionen aufgerufenen Werkzeuge beschreibt, die durch die Clients ausgelöst werden und sich auf Pakete, Member oder Elemente beziehen.

Neben den Datendefinitionsaktionen steht ein Satz von Aktionen zur Verfügung, um das XSCML-Gerüst zu erstellen und diese Aktionen auf die durch die Projektdefinition dem XSCML-Gerüst zugewiesenen Daten anzuwenden.
Solche Aktionen bestehen mindestens im:

Editieren: Editieraktionen liegen vor, wenn der Benutzer den Inhalt eines Elements im XSCML-System erstellt oder verändert. Eine vorab definierte Aktion von Editieren ist normalerweise eine Syntaxanalyse auf Abhängigkeiten oder auf andere statistische Informationen des Quellencodes, oder auf Synchronisation von Aktualisierungsaktionen auf Elemente. Diese Aktion wird entweder durch einen Editor aufgerufen, der von den Entwicklern verwendet wird, oder sie entspricht der Aktion Auslagern, um ein Member für das Editieren zu sperren, und Einstellen, um das veränderte Member zurück in das XSCML-System zu bringen.
Erstellen: Erstellungsaktionen liegen vor, wenn der Benutzer die Erstellungsfunktion für ein Paket ausgibt, das wiederum selbst andere Pakete enthalten kann. Das XSCML-System ruft dann für jedes Element, auf das verwiesen wird, in der Pakethierarchie die durch die Sprache in den Prozessdefinitionen festgelegten Aktionen auf. Die festgelegte Aktion der Erstellung umfasst alle Schritte der Transformation einer oder mehrerer Quellencodeelemente zu einem oder mehreren Ausgabeelementen.
Hochstufen: Hochstufungsaktionen liegen vor, wenn der Benutzer die Hochstufungsaktion für ein Paket ausgibt, das wiederum selbst andere Pakete enthalten kann. Das XSCML-System verschiebt dann alle Elemente, die sich auf ein erfolgreich erstelltes Paket oder Pakete, auf die verwiesen wird, in einer Pakethierarchie beziehen, zur im XSCML-System definierten nächsthöheren Gruppe.

Die Aktionen werden später mit Bezug auf 14 beschrieben. Die Aktionen selbst sind in der XSCML-Syntax definiert, die an den XSCML-Prozessor zur Ausführung weitergeleitet werden. Solche Definitionen können z. B. wie folgt aussehen:
Die Aktionen sind über die zugrunde liegenden implementierenden Produkte des XSCML-Gerüsts gleich. Somit wird die Abbildung auf die realen Befehle durch die Projektdefinitionen, wie in Beispiel 1 in dem Abschnitt, in dem die auf die Datenbank bezogenen Definitionen spezifiziert sind, zur Verfügung gestellt. Eine solche Abbildung kann z. B. wie folgt erfolgen:
Basierend auf solchen Definitionen kann ein ausgegebener Erstellungsbefehl auf „FLMCMD BUILD, PRODUCTA, DEVTA, CPP_PKG, HELLO,,, C, ... abgebildet werden.
Wenn eine Datei erstellt wird, müssen die logischen Elemente: „project" (Projekt), „group" (Gruppe), „type" (Typ) und „element" (Element) spezifiziert werden. Die physischen Namen werden dann von den Projektdefinitionen fallen gelassen.
Ein XSCML-Element wird durch eine Punktnotation wie „name.ext" (Name.Erweiterung) identifiziert, wobei „name" (Name) sich auf den Elementnamen selbst bezieht und „ext" (Erweiterung) den impliziten Container, in dem das Element existieren kann, angibt. Der Container kann explizit unter Verwendung einer zusätzlichen Typdefinition detaillierter definiert werden. So definiert <SINC TYPE="src">hello.cpp ein Element „hello" in einem Container mit der Bezeichnung „src". In den Abbildungsregeln wird die Verwendung von „ext" und „TYPE=" spezifiziert.
Wenn keine komplizierte Abbildung erforderlich ist, führt die logische Ansicht für auf Workstations verwaltete Dateien direkt zur physischen Ansicht von:
&root;\##project##\##group##\##member##.##type##. Für Datensätze auf einem OS/390-System führt die logische Ansicht direkt zur physischen Ansicht von:
##project##.##group##.##type##(##member##)
Für die Unterteilung von Elementen steht eine Typ-abhängige Abbildung, die von dem zu verwendenden Editor abhängt, zum Manipulieren von solchen Elementen, die in der Einheit Member gespeichert sind, zur Verfügung.
Dies ist der vorzuziehende Ansatz, da er für die Entwickler intuitiv ist. Wenn die Aktualisierung durch einen XSCML-Client erfolgt, dann kann das Stammverzeichnis sogar ein lokaler Festplattenspeicher der Entwickler sein, wenn es für dieses Projekt so eingerichtet wurde. Zur Verwendung der Gruppen gibt es Optionen. Die Inhalte der Gruppen können entweder nur die erforderlichen Unterschiede entlang der Hierarchie enthalten, oder die Gruppen enthalten eine vollständige Kopie der Pakete, an denen der Entwickler arbeitet. Im letzteren Fall wäre der Entwickler in der Lage, selbstständig zu arbeiten und mit dem zugrunde liegenden Dateisystem in der Datenbank synchronisieren, wenn der Client wieder online ist. Dies erfordert jedoch mehr Logik zur Abstimmung oder Replikation.
Gemäß der Erfindung werden, selbst wenn eine unterschiedliche Abbildung von logischen und physischen Namen für Elemente erfolgt, die Elemente dem Benutzer immer unter den Begriffen „project" (Projekt), „group" (Gruppe), „type" (Typ) und „element" (Element) präsentiert. Dies wird im folgenden Beispiel 1 gezeigt, das sich auf ein XSCML-System eines Softwareprodukts mit der Bezeichnung „My Product" (Mein Produkt) bezieht und das die Definitionen von XSCML umfasst, die zur Definition des XSCML-Systems verwendet werden. Der erste Teil des Beispiels zeigt die Datenfluss-Syntax, gefolgt durch eine Abbildung der logischen Typen, und danach die Abbildung der Produktelemente auf den physischen Speicher. Es folgt der Prozessfluss und schließlich die Sprachdefinition oder sogenannte Prozessdefinition. Die Beispiele sind selbsterklärend und basieren auf 10: BEISPIEL 1: Editieren des Softwareprodukts „My Product"
Als eine Alternative zur Definition des Datenflusses kann die Hierarchie der Produktelemente durch einen Arbeitsflussbaum definiert werden. Dies wird im folgenden Beispiel 2 gezeigt, in welchem zwei Benutzer und eine Gruppe bei der Entwicklung und dem Testen eines Softwareprodukts zusammenarbeiten, das aus dem Flussbaum resultiert, der die folgenden Flussgruppen umfasst. Das Beispiel bezieht sich auf 6. BEISPIEL 2: XSCML-Syntax für den Datenfluss, der als Flussbaum definiert ist:
Softwareelemente und -pakete
Es ist erforderlich, dass ein Paket definiert wird im Hinblick auf seine Eingabe und Ausgabe und darauf, welche Parameter an die verschiedenen Prozesse weitergegeben werden können, die benötigt werden, um von der oder den Eingaben zu der oder den Ausgaben, auch generierte Elemente genannt, zu gelangen. Eine Paketdefinition kann implizit durch ein Element mittels der zu einem Element gehörigen Prozessdefinition definiert werden.
Paket: Ein Paket kann als ein Element in der Datenbank behandelt werden und mittels Kennungen, die die explizite Beziehung zwischen Eingabeelementen und generierten Elementen beschreiben, definiert werden. Die Kennungen definieren auch die Prozessdefinition, die zur Behandlung des Eingabeelements und Generierung der Elemente aus den Eingabeelementen zugeordnet ist. Sie können des Weiteren Paketparameter definieren, die an die zugehörigen Prozessschritte in den Prozessdefinitionen weitergegeben werden. Einige der Paketdefinitionen können durch die Projektdefinitionen oder Metadaten, die zu den Elementen, auf die in dem Paket Bezug genommen wird, gehören, zu Standardvorgaben gemacht werden. Dies bedeutet, dass ein Eingabeelement eine implizite Paketdefinition sein, kann, wenn die zugehörige Prozessdefinition alle Paketdefinitionen als Standardwerte enthält, wie etwa Typen für generierte Elemente, explizite Abhängigkeiten, Parameter für Prozessschritte etc. Ein Paket kann sich auf andere Pakete als abhängige Pakete beziehen, die vor dem Paket, das den Bezug herstellt, verarbeitet werden müssen.
Die Tatsache, dass sich Pakete auf andere Pakete beziehen können, führt zu einem Erstellungsbaum und einem Hochstufungsbaum solcher Pakete. Ein Erstellungsbaum dieses Typs kann das komplette Produkt, das durch eine Erstellungsaktion verarbeitet werden soll, definieren, und er zeigt die Abhängigkeiten zwischen Paketen und Elementen.
Neben den expliziten Abhängigkeiten zwischen den Elementen, die durch Pakete definiert sind, gibt es implizite Abhängigkeiten, die von den XSCML-definierten Prozessen, entweder nach einer Speicherung von editierbaren Elementen oder nach der Erstellung eines Elements, gefunden werden. Um solche impliziten Abhängigkeiten zu bestimmen, definiert die Prozessdefinition den Aufruf der Werkzeuge, um die Abhängigkeitsinformationen zu finden und zu speichern.
Um den Benutzern die Definition von Erstellungsschritten zu ermöglichen, müssen sie in der Lage sein, außer den Paketinhalt zu definieren, auch mehrere Erstellungsprogramme als eine Einheit zu definieren und die Informationen zum Erstellen der Pakete zu definieren, die in einer Einheit behandelt werden sollen. Die Benutzer sollten in der Lage sein, eine solche Einheit durch eine Textdarstellung zu erstellen, die dann für eine grafische Darstellung verwendet werden könnte. Darüber hinaus kann der Erstellungsschritt durch eine grafische Benutzerschnittstelle unterstützt werden.
Das von der Erfindung zur Verfügung gestellte Verfahren zur Definition der Erstellungsschritte und Pakete reduziert die Komplexität des Erstellungsbaums auf ein Minimum. Die Pakete sind die einzigen Knoten in dem Erstellungsbaum. Ein Paket kann jedoch durch Erweiterung als eine Anzahl an einzelnen Bäumen dargestellt werden, um die Eingabe und Ausgaben zu zeigen und die Hierarchie zu umfassen. Allgemeine Parameter (z. B. Kompilierungsoptionen, gemeinsam benutzte Einfügeelemente) können als separate Elemente gehalten werden und durch die XSCML-Syntax in verschiedene Pakete eingeschlossen werden. Darüber hinaus wird die Wiederverwendung von definierten Erstellungsprogrammen für unterschiedliche Projekte einfach, da es möglich ist, Erstellungsprogramme mit größerer Flexibilität zu erstellen (z. B. müssen Dateierweiterungen nicht in den Erstellungsprogrammen spezifiziert werden).
Erstellungsprogramme mit mehr als einem Erstellungsschritt können durch die XSCML-Sprache mit mehreren Erstellungsschritten implementiert werden, wie in den folgenden Beispielen gezeigt. Die Mehrfachschrittprozesse sind durch ein Erstellungsskript definiert. Es sind keine Programmierkenntnisse (REXX, C++, JAVA, PERL) notwendig, um eine solche Prozessintegration zu implementieren.
Aktion ERSTELLEN für Pakete
Die Veröffentlichung „TeamConnection Users Guide" von IBM, Veröffentlichungsnummer SC34-4499-04, Seite 183, 58, enthält ein Beispiel eines Erstellungsobjektmodells für msgcat.exe. Für die nachfolgende Beschreibung der XML-basierten Definitionen wird auf dieses Beispiel für die Definitionen für die Erstellungsfunktion und die Paketdefinition von drei Pakettypen verwiesen. In dieser Beschreibung sind die Beispiele 2, 3 und 4 dargestellt, die sich auf die Erstellung eines Pakets durch die Kompilierung zweier Elemente mit einer nachfolgenden Verknüpfungsoperation beziehen. Diese Beispiele schließen die Definition der Arbeitseinheiten und Pakete ein, die für die Kompilierungsschritte zweier Elemente verwendet werden, wobei deren die Ergebnisse zu einem höheren Paket verknüpft werden.
Es wird Folgendes unterschieden:

1. Kompilierpakete für Kompiliertransformationen, genannt (C)-Pakete.
2. Verbindungspakete für Verknüpfungstransformationen, genannt (L)-Pakete. Verbindungspakete können sich auf (C)- oder (L)-Pakete beziehen.
3. Höhere Pakete, genannt (HL)-Pakete, die Anwendungen und Unteranwendungen beschreiben. Höhere Pakete können sich auf (C)-, (L)- oder (HL)-Pakete beziehen.
4. Einschließpakete, genannt (I)-Pakete, zum Teilen gemeinsamer Informationen zwischen den Paketen. Einschließpakete können Teil der (C)-, (L)-, (HL)- oder (I)-Pakete sein.

BEISPIEL 3: Verwendung des Kompilierpakets hello.cpkg zur Kompilierung des Quellencodes hello.c
BEISPIEL 4: Verwendung des Kompilierpakets bye.cpkg zur Kompilierung des Quellencodes bye.c
Der in den Beispielen 3 und 4 kompilierte Code wird zur Erstellung eines Pakets verknüpft. Dies wird im Beispiel 5 dargestellt. BEISPIEL 5: Verbindungspaket msgcat.lpkg zur Erstellung des Pakets msgcat.exe:
Im folgenden Beispiel 6 werden die Definitionen für die gesamte Anwendung durch Verwenden einer höheren Paketierung beschrieben. BEISPIEL 6: Verwendung des höheren Pakets Prod1.hpkg zur Beschreibung der gesamten Anwendung msgcat
Bisher wurden die Paketinhalte durch XML-basierte Definitionen definiert. Die Pakete beziehen sich jedoch auch explizit auf die für jedes Paket verwendeten Sprachen, die die sich darauf beziehenden festgelegten auszuführenden Aktionen im Detail enthalten, wenn ein Benutzer während einer Editierung, Erstellung oder Hochstufung auf eine höhere Entwicklungsstufe mit dem Paket arbeitet. Eine festgelegte Aktion für eine Editierung kann das syntaktische Analysieren auf Abhängigkeiten sein und für eine Erstellung die verschiedenen Erstellungsschritte zur Umwandlung der Eingabe(n) in die Ausgabe.
Prozessdefinitionen – Sammlung festgelegter Aktionen, die auf Pakete angewendet werden
Die XSCML-Projektdefinitionen enthalten jede festgelegte Aktion, die ein Benutzer auf Pakete anwenden kann. Solche Aktionen umfassen das Editieren, das Erstellen und hochstufungs-ähnliche Aktionen, um das Paket von einem Integrationszustand in einen anderen zu überführen. Die grundlegendsten Aktionen, die ein Benutzer anwenden kann, sind das Editieren und Erstellen.
Die festgelegte Aktion des Editierens ist eine Syntaxanalyse auf Abhängigkeiten oder auf andere statistische Informationen des Quellencodes oder auf Synchronisation von Aktionen. Die festgelegte Aktion des Erstellens umfasst alle Schritte der Umwandlung einer oder mehrerer Quellencodeelemente zu einem oder mehreren Ausgabeelementen.
In den hier betrachteten Beispielen werden zwei Prozesse verwendet. Ein Prozess dient der Kompilierung in C++ und der andere zur Ausführung von LINK. Beide Prozesse enthalten nur einen Erstellungsschritt.
Wenn mehrere Erstellungsschritte benötigt werden, um die Erstellungsausgaben zu erhalten, müssen mehrere Schritte von TYPE="BUILD" beschrieben werden. In diesem Fall müssen die erzeugten Ausgaben des ersten Schritts als Eingabe für den nächsten Schritt markiert werden. Ein Beispiel eines solchen Falls, der für eine OS/390-Erstellung typisch ist, wird unten dargestellt.
Um eine besondere Behandlung von Dateien besonders in einer Sprache mit mehreren Prozessschritten zu ermöglichen, werden unterschiedliche Schlüsselworte IOTYPE für die Eingaben und Ausgaben definiert. Solche Informationen werden dann von den Erstellungsprogrammen verwendet, um die Sonderbehandlung der zugeordneten Dateien zu ermöglichen:

IOTYPE=S Wird für Eingabedaten verwendet, die mit einer Kennung <SINC ...> spezifiziert sind. Dies bedeutet, dass die Dateien oder Datensätze existieren und nicht mehr durch das Erstellungsprogramm erstellt werden müssen.
IOTYPE=I Wird als Zuordnungsinformation verwendet, um Zugriff auf zusätzliche Dateien zu erhalten, die während des zugehörigen Prozesses, der in einer Kennung <SCRIPT ...> definiert ist, benötigt werden.
IOTYPE=O Wird für Ausgabedaten verwendet, die mit Kennungen wie <OBJ ...>, <LIST ...>, <LOAD ...>, <OUTx ...> spezifiziert sind. Datensätze oder Dateien werden während der Erstellung erstellt. Die Ausgabe wird nach einer erfolgreichen Erstellung in dem Elementspeicher des Systems gespeichert.
IOTYPE=W Wird für Arbeitsdatensätze verwendet, die zur temporären Verwendung in einem Schritt oder sogar in nachfolgenden Schritten bei Mehrschrittprozessen benötigt werden. Die Ausgabe wird nach einer erfolgreichen Erstellung jedoch nicht gespeichert.
IOTYPE=N Wird in einer OS/390-Sprache zur Definition eines Leereintrags & 0{f oder einer Liste der Dateidefinitionen (ddname list), die an das aufgerufene Programm weitergegeben werden soll, verwendet.
IOTYPE=A Wird für Datensätze oder Dateien verwendet, die bereits existieren und auf die von den Erstellungsschritten verwiesen wird. Sie werden normalerweise nicht durch einen zugehörigen Prozess während eines Prozessschritts erstellt und können Informationen, die in dem Elementspeicher des Systems gespeichert sind, enthalten oder nicht enthalten.

Weitere IOTYPE-Schlüsselwörter können definiert werden.
Der zur Sprache C++ gehörende Prozess c-comp.lang kann wie folgt definiert werden: BEISPIEL 7
Der zur Sprache LINK gehörende Prozess c_link.lang kann wie folgt definiert werden: BEISPIEL 8
Diese Beispiele sind nicht erschöpfend, sondern sie sollen die Prinzipien, um eine komplette Erstellung zu spezifizieren, beschreiben, die es einem Benutzer ermöglicht, Parser und Erstellungsprogramme zu erzeugen, die keine umgebungsspezifischen Informationen enthalten, sondern die alle über Parameter oder Umgebungsvariablen, die auf den XSCML-Definitionen basieren, und den im XSCML-Speicher gespeicherten Metadaten weitergegeben werden.
Prozessdefinitionen für ein Paket mit einer Mehrschrittsprache
Das folgende Beispiel zeigt, wie komplexere Sprachen mit XSCML implementiert werden. Das Beispiel basiert auf einer OS/390-Transformation mit den folgenden Erstellungsschritten:

1. CICS-Vorprozessor zum Übersetzen der EXEC CICS-Aussagen in C++-Prozeduraufrufe.
2. Aufruf des C++-Compilers, um die wirkliche Kompilierung zur Erstellung des Objekts auszuführen.
3. Der letzte Schritt sammelt alle Auflistungen, die zuvor von CICS und C++ erzeugt wurden, in einer Liste, die dann als eine Einheit gespeichert wird.

Die zentrale Definition der Kompilierparameter kann aus dem Kompilierpaket extrahiert und in einem zusätzlichen Teil der Datenbank gespeichert werden und in dem Kompilierpaket kann auf sie Bezug genommen werden:

cics.parms <PARM1> MAR(1,80) OM(1,80) </PARM1>
c370.parms <PARM2> LIST AGGREGATE </PARM2>

Das Kompilierpaket cicspart.pkg wird zum Erstellen von cicspart.mod verwendet: BEISPIEL 9
Die zugehörige Sprache cics370.lang könnte allgemein unter Verwendung von Variablen definiert werden. Indem eine Variablendefinition zur Verfügung gestellt wird, können Member-Sprachen aus wiederverwertbaren Teilen in einem Stecksystem erstellt werden. Die Sprache ist dann eine Sammlung festgelegter Erstellungen. BEISPIEL 10
Zentrale Grundbausteine wie Parser und Erstellungsschritte, die von einer zentralen Erstellungsgruppe zur Verfügung gestellt werden, können wiederverwendet werden, um mehrere Sprachen zu erstellen, die sich nur in der Anzahl der Schritte oder der unterschiedlichen Parameter unterscheiden.
Der Einfüge-Grundbaustein ist c_include.libs: BEISPIEL 11
Ein Syntaxanalyseschritt-Grundbaustein ist parse_c.step: BEISPIEL 12
Die CICS-Vorprozessorschritt-Grundbausteindefinition ist cics.step: BEISPIEL 13
Der C-Kompilierungsschritt-Grundbaustein ist c370.step: BEISPIEL 14
Der Prozess zum Zusammenfügen von Auflistungsausgaben zu einer Ausgabe lautet "packlst.step." BEISPIEL 15
Logische Projektansichthierarchie und Arbeitsfluss
6 zeigt die logische Elementhierarchie und den Datenfluss eines komplexen Projekts, das sich auf eine erste und eine zweite Version eines Produkts bezieht. Jeder Block in 6 stellt eine Dateneinheit dar. Die Entwicklung eines Produkts beginnt auf der unteren Ebene in den Gruppen DEVA, DEVB und TEAM. Diese Gruppen stellen die editierbaren Dateneinheiten dar, in denen Elemente erstellt, geändert oder aktualisiert werden können. Jede der Einheiten DEVA und DEVB wird einem einzelnen Benutzer zugeordnet, während die Einheit TEAM einer Gruppe von Benutzern zugeordnet wird. Die nächsthöheren Blöcke DEVTA, DEVTB und TEAMT werden dem Test der Elemente aus DEVA, DEVB und TEAM zugeordnet. Auf der Testebene sind keine Änderungen der Produktelemente erlaubt. Die nächsthöheren Ebenen stellen einen Funktionstest FTEST und einen Systemtest STEST der zweiten Version des Produkts dar, das sich aus den Elementen ergibt, die auf den unteren Ebenen bearbeitet und getestet wurden. Zu diesem Zeitpunkt ist die erste Version des Produkts PROD1 bereits fertig gestellt und an die Kunden ausgeliefert. Fehler, die nach der Lieferung gefunden werden, werden behoben und einem Test FIXTEST1 unterworfen und anschließend erfolgt eine Integration in das korrigierte Produkt FIXPROD1.
Parallel zu diesen Aktivitäten wird die zweite Version des Produktpakets PROD2 nach der Beendigung des Systemtests STEST fertig gestellt. Der Zugriff auf die Elemente in den lokalen Speichern der Clients 25 und 27, der Zugriff auf die Zwischenpakete und das endgültige Produkt in der Datenbank 24, und die Verknüpfung zwischen diesen Komponenten wird durch den XSCML-Prozessor 22 gesteuert, während für die Bearbeitung der Inhalte dieser Komponenten unterschiedliche Sprachen wie REXX, C++, JAVA oder PERL verwendet werden können. Der Block DEVTB umfasst einen Unterblock 61, der die Delta-Elemente der DEVTB-Daten darstellt. Dies ermöglicht einen Widerrufschritt, indem, falls erforderlich, die verarbeiteten Daten durch die vorherigen Daten ersetzt werden. Die Blöcke TEAMT, PROD1, PROD2 und FIXPROD1 haben entsprechende Unterblöcke 62, 63, 64 und 65.
7 zeigt einen Abschnitt des Prozessflusses des Projekts gemäß 6 detaillierter. Durch Verwendung der Projektmetadaten 41 (4A) steuert der XSCML-Prozessor 22 in einem Unterabschnitt Editieren 70 den Schritt 71, um die Gültigkeit und Korrektheit der Projektdaten zu überprüfen, und den Schritt 72, um das Projekt der Entwicklungseinheit DEVA zuzuweisen. Das Ergebnis des Editierprozesses, das ein Produktelement sein kann, wird in einem Unterabschnitt Bewertung 73 behandelt, in dem in Schritt 74 das Ergebnis von DEVA bestätigt und in Schritt 75 abgeschlossen wird. Wie durch Pfeil 76 angezeigt, steuert der XSCML-Prozessor 22 das Verschieben des Ergebnisses von DEVA zu DEVTA, wo es mittels Schritt 77 in einem Testabschnitt 78 des Datenflusses getestet wird.
Die Zugriffsregeln zu der Ebene und zu den Aktionen werden auch über die XSCML-Syntax als Teil der Projektdefinitionen 40 definiert, die in einem vereinfachten Beispiel 16 dargestellt sind, das Teil von Beispiel 1 wäre: BEISPIEL 16
Diese Zugriffsregeln stehen zusätzlich zu den eingebauten Zugriffsregeln des XSCML-Systems zur Verfügung. Das Hauptziel ist, die Integrität und Kontrolle der in einem XSCML-System verwalteten Daten sicherzustellen. Die Ebene der Zugriffsdefinition ist nicht Teil der Erfindung, sondern lediglich das Prinzip, diese Informationen auch über die Prozessdefinitionssyntax zur Verfügung zu stellen.
Es folgt ein Beispiel einer Prozessflussdefinition als Teil des Projektdefinitions-Beispiels 1: BEISPIEL 17
Der Prozessfluss kann komplexer sein, wie eine Zustandsmaschine mit Verzweigungen, Schleifen und Selbstverweisungen, die durch XSCML-Syntax definiert sind, und nicht nur direkte Prozesse, wie sie das Beispiel 17 zeigt.
8 bezieht sich auf die physische Darstellung der Produktelemente eines Projekts und ihre Definitionen, wie sie in den Abschnitten 42 und 43 der Datenbank 24 gespeichert sind. In 8 enthält ein Block 80 die Projektdefinition. Dieser Block entspricht dem Abschnitt 45 der Datenbank (4A). Die Editierdaten der Projektansicht 81 einschließlich der Projektmodellquellen werden syntaktisch analysiert, umgewandelt und den Projektdefinitionsdaten zugeordnet. Ein Block 82 umfasst die Projektmetadaten einschließlich der Projektstatusdaten und Elementbeziehungen und Paketbeziehungen. Die Projektstatusdaten spezifizieren auch die Sprache der Elemente, die in Block 83 für die Modellelemente A, B und C gezeigt ist, die in COBOL, CPP bzw. PLI geschrieben sind, und auch für die Makroelemente A, B und C, die in COBOLMAC, PLIMRC bzw. HPP geschrieben sind. Die Blöcke 82 und 83 entsprechen dem Abschnitt 41 der Datenbank. Ein Block 84, der den Abschnitten 42 und 43 der Datenbank entspricht, umfasst eine Vielzahl von Projektgruppen, wobei jede alle Elemente einer bestimmten Kategorie umfasst. Die Elementkategorien sind „module" (Modul), „makro" (Makro), „load" (Laden), „object code" (Objektcode) oder „code listings" (Codeauflistungen). Der XSCML-Prozessor 22 der 4A und 4B, der in 8 durch Block 86 dargestellt ist, empfängt die Projektansichtsinformationen von den Projektdefinitionen 80 und kontrolliert den Zugriff auf die angezeigten Elemente, die in Block 84 gezeigt sind.
9 zeigt die logische Elementhierarchie und den Arbeitsfluss eines komplexen Projekts, das mehrere Hierarchien für zwei unterschiedliche Produkte A und B umfasst, die am gleichen Ort von zwei getrennten Gruppen von Entwicklern entwickelt werden können, die parallel daran arbeiten. Für beide Projekte A und B wird das gleiche Softwarekonfigurationsgerüst unter Steuerung des XSCML-Prozessors 22 verwendet, wie unter Verweis auf die 6 und 7 beschrieben. Die Struktur der Hierarchiebeziehung zwischen den in 9 gezeigten Blöcken entspricht der in Verbindung mit 6 beschriebenen.
10 zeigt die logische Elementhierarchie und den Arbeitsfluss eines komplexen Projekts, das durch eine verteilte Entwicklung mittels verteilter Computersysteme 1, 2 und 3 erzeugt wird, die in 10 als Blöcke 100, 101 und 102 bezeichnet sind. Wie schon in Verbindung mit 3 beschrieben, können sich diese Systeme weit voneinander entfernt befinden. Jedes der Systeme 100, 101 und 102 umfasst einen ersten Server 20 einschließlich eines XSCML- Prozessors 22 und einer Datenbank 24 und vorzugsweise einen zweiten Server 26 zur Unterstützung der Erstellungsoperationen. Das System 102 umfasst den Editierabschnitt mit den Einheiten DEVA, DEVB und TEAM, die DEVA, DEVB und TEAM in 6 entsprechen. Darüber hinaus umfasst das System 102 den Editiertestabschnitt mit den Einheiten DEVTA, DEVTB und TEAMT, die DEVA, DEVB und TEAMT in 6 entsprechen. Das System 102 führt auch den Test der Korrekturen durch FIXTEST1 der ersten Version des Produkts durch, welcher FIXTEST1 in 6 entspricht. Das System 101 führt den Funktionstest FTEST und den Systemtest STEST der zweiten Version des gleichen Produkts durch, die FTEST und STEST in 6 entsprechen. In dem System 100 werden die Produktversionen PROD1 und PROD2 verwaltet, analog zu PROD1 und PROD2 in 6. Das System 100 führt auch den Test der Korrekturen FIXPROD1 der ersten Version analog zu FIXPROD1 durch. Der Datenfluss in den Systemen 100, 101 und 102 entspricht dem Datenfluss des in 6 gezeigten Systems. In jedem dieser Systeme werden der Datenfluss und die Prozesse durch den lokalen XSCML-Prozessor gesteuert.
Wie in 11 gezeigt, wird ein Projektmodell 110, das in XSCML-Syntax definiert ist, in ein Hauptsystem 111 geladen, das ein separates System oder eines der Systeme 112, 113 und 114 sein kann. Als einen ersten Schritt führt der XSCML-Prozessor 22 des Hauptsystems 111 eine Syntaxanalyse durch, validiert das geladene Modell und überprüft das Modell auf seine Integrität. Kopien des Modells werden dann über die Verbindungen 115 an die lokale Datenbank 24 eines jeden Systems 112, 113 und 114 übertragen, wo das Modell gesperrt wird. Die Verbindungen 115 können über ein Kommunikationsnetz 34, wie etwa das Internet oder ein Intranet, hergestellt werden. Die gesperrten Modelle in den Datenbanken der Systeme 112, 113 und 114 werden dann durch Befehle auf den Verbindungen 116 aktiviert, die auch das Kommunikationsnetz zur Synchronisation der Systeme mit einem neuen oder aktualisierten Modell mit einer Rückfallmöglichkeit umfassen können.
12 zeigt die Schritte zur Initialisierung des XSCML-Systems in einer verteilten Umgebung gemäß 11. In einem der Systeme 1, 2 oder 3 beginnt ein Client den Initialisierungsprozess wie durch 120 angezeigt, um ein Projekt auszuführen. In Schritt 121 wird die Projektdefinition, hier auch als Systemansicht bezeichnet, durch Erstellen der Projektdefinition über XSCML-Kennungen definiert, um den Datenfluss durch eine logische Elementansicht zu beschreiben, die auf einem Dateisystem oder Objektmodellsystem basiert. Dieser Schritt schließt eine Abbildung auf den Speicher des XSCML-Prozessorsystems ein. Die Projektdefinitionen umfassen auch den Prozessfluss, die Prozessdefinitionen und die Client-Zugriffsrechte auf Daten und Prozesse. Darüber hinaus bestimmt die Projektdefinition auch, welches der verteilten Systeme als das Hauptsystem ausgewählt wird. Die Erstellung wird unter Verwendung von XSCML-Kennungen direkt oder mittels eines XSCML-Kennungseditors durchgeführt. In Schritt 122 wird die Systemansicht validiert. Zu diesem Zweck leitet der initiierende Client die Projektdefinition an den XSCML-Prozessor des Hauptsystems weiter, um die Korrektheit der Kennungen und Konsistenz der Definitionen sicherzustellen. Der XSCML-Prozessor des Hauptsystems ist die Administratorschnittstelle zu den Clients verteilter XSCML-Systeme. Der XSCML-Prozessor des Hauptsystems validiert die Projektdefinition auf Korrektheit, einschließlich einer Überprüfung der Kennungen auf Korrektheit und einer Überprüfung auf Konsistenz der Definitionen. Falls Fehler gefunden werden, muss der Client die Projektdefinition korrigieren, bis die Validierung die Projektdefinition bestätigt. Schritt 123 führt ein Laden der validierten Systemansicht in die XSCML-Prozessoren der verteilten Systeme durch. Der XSCML-Prozessor des Hauptsystems wird zuerst sicherstellen, dass der Validierungsschritt erfolgreich durchgeführt wurde, und speichert dann die Projektdefinition in der Datenbank, die dem XSCML-Prozessor des Hauptsystems zugeordnet ist. Das gespeicherte Format kann sich von dem Kennungsformat unterscheiden, aber es folgt einer 1:1-Abbildung. Für die verteilten Systeme werden die Projektdefinition oder deren relevante Abschnitte an die XSCML-Prozessoren der verteilten Systeme zur lokalen Validierung weitergegeben. Wenn die lokale Validierung erfolgreich ist, werden die Projektdefinitionen im lokalen System gespeichert und gesperrt, wobei jedes System die zugehörigen Definitionen in seinem proprietären Format mit einer 1:1-Abbildungsbeziehung der kennungsbasierten Definition speichern kann. Das Hauptsystem kontrolliert die Korrektheit aller lokalen Systemvalidierungen, bevor der nächste Schritt erfolgen kann. Wenn mehr als eine Systemansicht definiert ist, werden die Systemansichten gegeneinander auf Konsistenz überprüft.
Schritt 124 aktiviert die gespeicherte Systemansicht. Der initiierende Client fordert den XSCML-Prozessor des Hauptsystems auf, die dort gespeicherten Projektdefinitionen zu aktivieren. Die Aktivierung schließt eine Vorbereitung der physischen Umgebung ein, wie sie in der Projektdefinition definiert ist. Der Prozess kann die Erstellung von Dateien und Datenbanken und eine Aktualisierung des zugehörigen Sicherheitssystems mit sich bringen. Für die verteilten Systeme wird das Hauptsystem die Aktivierung der beteiligten verteilten Systeme initiieren, mit ihrer Umgebung, wie sie in ihren gespeicherten und gesperrten Projektdefinitionen definiert ist. Wenn alle Systeme die erfolgreiche Aktivierung anzeigen, wird die Sperre der Projektdefinitionen aufgehoben. Der lokale Client wird dann zum Arbeiten am Projekt, wie in den Projektdefinitionen definiert, freigegeben, wobei die Arbeit die Verwaltung der Projektdefinitionen in Schritt 125 und die Ausführung von Benutzer-Client-Aktionen durch Schritt 126 mit sich bringen kann.
Schritt 125 ist in 13 detaillierter dargestellt. Er umfasst einen Aktualisierungsschritt 131 der Systemansicht zur Implementierung von Veränderungen einer existierenden Projektdefinition durch eine Client-Anforderung, um die aktuelle Projektdefinition vom XSCML-Prozessor des Hauptsystems abzurufen. Dieser XSCML-Prozessor gibt diese Projektdefinition im Kennungsformat zurück und sperrt sie im Aktualisierungsmodus. Der Client kann dann alle Aktionen ausführen, die durch den Systemansichtsdefinitionsschritt 121 zur Verfügung gestellt werden. Schritt 131 wird von einem neuen Validierungsschritt 132, wie oben beschrieben, gefolgt, nach welchem ein Schritt Systemansicht aktualisieren 133 durchgeführt wird, der die validierten Aktualisierungen der Projektdefinition an den XSCML-Prozessor des Hauptsystems übermittelt. Der XSCML-Hauptprozessor stellt sicher, dass die veränderte Projektdefinition geladen und auf die gleiche Art, wie sie oben für die Schritte 123 und 124 beschrieben wurde, aktiviert wird. Abhängig von den Möglichkeiten des XSCML-Hauptprozessors kann ein Delta-Format der Projektdefinition behalten werden, um eine Wiederherstellung der Projektdefinition vor ihrer Aktualisierung zu ermöglichen. Weitere Schritte, die in der 13 dargestellt sind, umfassen den Schritt 134 zur Deaktivierung einer Systemansicht, sodass Client-Aktionen vorübergehend nicht durchgeführt werden können, und Schritt 135 zur kompletten Entfernung einer Systemansicht, sodass sie nicht mehr verwendet werden kann. Schritt 125 umfasst auch die Definition einer alternativen Systemansicht durch Schritt 136, der von den Schritten 137, 138 und 139 zur Validierung, zum Laden und zur Aktivierung der alternativen Systemansicht gefolgt wird. Schritt 140 gibt die Kontrolle an den aufrufenden Client zurück.
14 zeigt Client-Aktionen von Schritt 126. Ein Client kann einen Aktionsbefehl ausgeben, der mindestens eine der Aktionen Neu, Auslagern, Editieren, Erstellen, Hochstufen, Löschen oder Abfragen aktiviert, die mit 142–148 gekennzeichnet sind. Um die Aktion Neu auszuführen, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um ein neues Element in dem Paket und in dem Elementspeicher auf der Editiergruppen-Ebene einzurichten und zu speichern. Gleichzeitig werden die zugehörigen Metadaten aktualisiert. Mindestens eine Sprache, wie sie in den Metadaten definiert ist, muss angegeben werden. Eine Anzahl an Aktionen kann angefordert und während dieses Schritts gemäß den Aktionen ausgeführt werden, die in den Prozessdefinitionen, die zu diesem Element gehören, angegeben sind.
Um die Aktion Auslagern auszuführen, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um einen Zugriff auf das Paket oder Element in seiner Editiergruppe vorzubereiten und eine Sperre zu setzen, um sicherzustellen, dass das Paket oder Element ausschließlich von diesem Client verwendet wird. Auf dem Obigen basierend, können für die Prozessdefinitionen, die zu diesem Paket oder Element gehören, eine Anzahl an Aktionen angefordert und während dieses Schritts ausgeführt werden. Der Client kann das Paket oder das Element unabhängig vom XSCML-Prozessor ändern und kann aus den Aktionen Speichern, Speichern unter oder Zurückstellen (Schließen) auswählen.
Um die Aktion Speichern auszuführen, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um das geänderte Paket oder Element im Paketspeicher 43 oder Eingabeelementspeicher 44 (4A) auf der Editiergruppen-Ebene zu speichern und die zugehörigen Metadaten zu aktualisieren. Die Aktion Speichern unter ist dem Speichern ähnlich, außer dass aus einem existierenden Element oder Paket ein neues Element oder Paket erstellt und unter einem neuen Namen mit den gleichen XSCML-Eigenschaften wie die des existierenden Elements oder Pakets gespeichert wird. Auch die Aktion Zurückstellen ist dem Speichern ähnlich, außer dass das Element oder Paket entsperrt wird, sodass auf es wieder für andere Clients verfügbar ist.
Die Aktion Editieren 144 bringt ein Auslagern des zu editierenden Elements oder Pakets mit sich und ruft dann einen Editor auf, der eine eingebaute XSCML-Unterstützung aufweist, um ein Element oder Paket in einer Editiergruppe zu editieren. Der Editor ruft die XSCML-Aktionen Neu, Auslagern, Speicher, Speichern unter und Zurückstellen immer dann auf, wenn der Client die entsprechenden Editierfunktionen verwendet. Die verwendete Editierung ist in der Projektdefinition definiert und kann sich auf den Typ eines Elements oder Pakets beziehen. Das editierte ausgelagerte Element oder Paket wird vom XSCML-Prozessor zurückgestellt.
Um eine Erstellungsaktion 145 zu initialisieren, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um zu bestimmen, ob der Typ des Pakets, das erstellt werden soll, „C", „L" oder „HL" ist. Im Fall eines „C"-Typs bestimmt der XSCML-Prozessor die zugehörigen Quellen, die Parameter, die Prozessdefinition, die zu speichernden Ausgaben und die für die Erstellungsaktion benötigten Dateien. Er bestimmt den Status der beteiligten Dateien und die für die Erstellungsaktion benötigten Informationen, falls sie durch eine vorherige Erstellungsaktion verändert wurden. Wenn irgendwelche Veränderungen gefunden werden, überträgt er die kompletten Erstellungsinformationen an den festgelegten Erstellungsserver 27, um eine „C"-Paket-Erstellungsaktion auszuführen. Der Erstellungsserver empfängt die Erstellungsinformationen für ein Paket, das Eingabe-, Parameter- und Ausgabeinformationen enthält, und die Erstellungsschritte definiert, die ausgeführt werden müssen, und die Dateien, die für diese Schritte benötigt werden. Der Erstellungsserver führt die Zuordnung der benötigten Dateien durch und erhält Zugriff auf die Quellen, die benötigt werden, um die definierte Erstellungsaktion für den auszuführenden Schritt zu starten.
Der Erstellungsserver speichert alle Ausgabeelemente, die in der Prozessdefinition gekennzeichnet sind, in den Speicher für generierte Elemente zurück. Er aktualisiert auch die Metadaten für die generierten Elemente und erstellt Erstellungsinformationen, die die Liste der Eingaben, der generierten Elemente und die Abhängigkeiten und verwendeten Parameter enthält. Der Erstellungsserver speichert alle Ausgaben, die in der Prozessdefinition gekennzeichnet sind, in Benutzerdateien für die Erstellung und Fehleranalyse, falls mindestens ein Erstellungsschritt fehlschlägt.
Im Fall eines „L"-Typs führt der XSCML-Prozessor die Aktion Erstellungsbezüge auflösen für Pakete durch, die das Paket auf Bezüge zu anderen Erstellungspaketen durchsucht und eine neue Erstellungsaktion für jedes Erstellungspaket, auf das verwiesen wird, welches noch nicht für eine Erstellung vorgesehen wurde, ausgibt. Danach bestimmt der XSCML-Prozessor die zugehörigen Ausgaben, die von den Paketen, auf die verwiesen wird, zur Verwendung als Eingabe für den Erstellungsprozess erzeugt werden, des Weiteren die Parameter, die Prozessdefinition, die zu speichernden Ausgaben und die für die Erstellungsaktion benötigten Dateien. Bevor die „L"-Paket-Erstellungsaktion begonnen wird, wird eine Überprüfung der Pakete, auf die verwiesen wird, durchgeführt, welche die Elemente generiert, die als Eingabe verwendet werden sollen, wenn eine erneute Erstellung erforderlich ist. Diese Prüfung bestimmt den Status der beteiligten Dateien und die für die Erstellung benötigten Informationen, falls sie verschieden sind von einer vorher erfolgreich ausgeführten Erstellung. In diesem Fall wird keine Erstellungsanforderung ausgegeben. Wenn Veränderungen gefunden werden, werden die kompletten Erstellungsinformationen an den festgelegten Erstellungsserver zur Ausführung einer „L"-Paket-Erstellungsaktion übertragen.
Im Fall einer Aktion Erstellen für ein Paket des „HL"-Typs führt der XSCML-Prozessor die Aktion Erstellungsbezüge auflösen für die Pakete durch.
Um die Aktion Hochstufen 146 auszuführen, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um die Elemente und Pakete zu bestimmen, die sich auf das hochzustufende Paket beziehen, und ob sie sich in der Hochstufungsgruppe befinden, von der die Hochstufungsaktion ausgegeben wird. Er bestimmt auch die Gruppe, zu der hin die Hochstufung stattfinden soll, und ihren Ort. Die Hochstufungsaktion erstellt Kopien aller Elemente und Pakete, auf die verwiesen wird, auf die nächsthöhere Gruppe und löscht sie in der aktuellen Gruppe. Die Hochstufungsaktion verschiebt nur erfolgreich erstellte Pakete. In einer verteilten Umgebung findet eine Kommunikation zwischen den XSCML-Prozessoren der verteilten Systeme statt, um deren Speicher zu synchronisieren.
Um die Aktion Löschen 147 auszuführen, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um die zu löschenden Elemente und Pakete zu bestimmen. Um die Aktion Abfragen 148 auszuführen, verwendet der XSCML-Prozessor die Projektdefinition und die Metadaten, um die Elemente und Pakete der angegebenen Abfrage zu bestimmen, um die Informationen zu bestimmen. Die Abfrageaktion ermöglicht ein weitreichendes Wiederfinden von in den Paketen, Elementen, Projektdefinitionen und Metadaten gespeicherten Informationen.
Obwohl die Erfindung mit Bezug auf verschiedene Ausführungsarten und Beispiele beschrieben wurde, liegen Änderungen oder andere Ausführungsarten der Erfindung im Geltungsbereich der Erfindung, wie sie in den Ansprüchen definiert ist.

Claims

Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem, a) das mindestens einen Server einschließt, der mit einer Vielzahl von Client-Computern verbunden ist, wobei der Server einen Speicher zum Speichern von Produktelementen besitzt, aus denen mit Hilfe von Werkzeugen zum Entwickeln, Testen, und/oder Aktualisieren gemäß einer Projektdefinition Softwarepakete gebildet werden, wobei das Verfahren umfasst: b) Definieren der Projektdefinition, die den parallelen Ablauf eines Projekts zum Entwickeln, Testen und/oder Aktualisieren von Softwarepakten auf verteilten System beschreibt, c) Laden der Projektdefinition im Hauptsystem, d) Validierung der Projektdefinition im Hauptsystem auf Korrektheit und Konsistenz der Definitionen, e) Laden der validierten Projektdefinition auf die verteilte Systeme, f) Lokale Validierung der für die verteilten Systeme relevanten Abschnitte der Projektdefinition in den verteilten Systemen, g) Bei erfolgreicher lokaler Validierung Speichern und Sperrung der Projektdefinition in den verteilten Systemen, h) Aktivierung der gespeicherten Projektdefinition auf den beteiligten verteilten Systemen, wobei die Aktivierung die Vorbereitung der physischen Umgebung, wie sie für die Projektdefinition definiert ist, umfasst, i) Entsperrung der Projektdefinitionen auf den verteilten Systemen bei erfolgreicher Aktivierung genau aller Systeme, wodurch die Arbeit am Projekt auf den verteilten Systemen freigegeben wird.
Verfahren gemäß Anspruch 1, wobei das Definieren der Projektdefinition durch Verwendung einer gemeinsamen Softwarekonfigurationsformatierungssprache erfolgt.
Verfahren gemäß Anspruch 2, wobei die gemeinsame Softwarekonfigurationsformatierungssprache auf der erweiterbaren Formatierungssprache XML (Extensible Markup Language) basiert.
Verfahren gemäß Anspruch 2, wobei eines der verteilten Systeme (30, 31, 32) als Hauptsystem verwendet wird, dessen Speicher die Projektdefinition in der gemeinsamen Softwarekonfigurationsformatierungssprache enthält.
Datenträger, auf denen ein maschinenlesbares Computerprogramm gespeichert ist, das ein Verfahren nach Anspruch 1 bis 4 ausführt, wenn es in einem Computer abgearbeitet wird.