DE10121790A1 - System und Verfahren zur Konfiguration von Softwareprodukten - Google Patents
System und Verfahren zur Konfiguration von SoftwareproduktenInfo
- Publication number
- DE10121790A1 DE10121790A1 DE10121790A DE10121790A DE10121790A1 DE 10121790 A1 DE10121790 A1 DE 10121790A1 DE 10121790 A DE10121790 A DE 10121790A DE 10121790 A DE10121790 A DE 10121790A DE 10121790 A1 DE10121790 A1 DE 10121790A1
- Authority
- DE
- Germany
- Prior art keywords
- software configuration
- elements
- project
- product
- language
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Abstract
Gemäß der Erfindung wird eine gemeinsame erweiterbare Softwarekonfigurationsformatierungssprache (extensible software configuration markup language, XSCML) verwendet, die sich zur Definition eines Projekts eignet, das sich auf die Entwicklung oder Aktualisierung eines Softwareprodukts bezieht. Die gemeinsame erweiterbare Softwarekonfigurationsformatierungssprache basiert vorzugsweise auf der erweiterbaren Formatierungssprache "XML" (Extensible Markup Language). Mit Hilfe von XSCML werden eine Softwareprojektdefinition und ein systemunabhängiges Softwarekonfigurationsgerüst erzeugt. Ein XSCML-Prozessor (22) wird zur Verfügung gestellt, um auf die Projektdefinition zuzugreifen und die Produktelemente und Prozesse zu beschreiben und ihre Zugriffsparameter und ihre Beziehungen untereinander zu beschreiben. Das Gerüst ist im Speicher eines oder mehrerer Server (20, 51) und in einer Datenbank (24) gespeichert und besitzt die zugewiesenen Produktelemente, Prozesse und Werkzeuge in den Speichern. Ausgewählte Produktelemente, Werkzeuge und Prozesse werden von mindestens einer aus einer Vielzahl von Client-Workstations, die an den Server angeschlossen sind, unter Verwendung der Befehle von XSCML aufgerufen. Die Server können zu geografisch verteilten Computersystemen gehören, die durch ein Kommunikationsnetz verbunden sind. Zugriff und Verwaltung der zugeordneten Produktelemente, Prozesse und Werkzeuge in den lokal verteilten Systemen und die Kommunikation zwischen diesen ...
Description
Die Erfindung bezieht sich auf ein System und ein Verfahren zur
Softwarekonfiguration zur Verwendung in einem Computersystem,
das mindestens einen Server umfasst, der mit einer Vielzahl von
Clients verbunden ist. Das System und das Verfahren erlauben
eine effiziente Gruppenarbeit, um Produktelemente, die
miteinander zur Erzeugung verschiedener Versionen eines
Softwarepakets verknüpft sind, zu entwickeln, zu aktualisieren,
zu erstellen, hochzustufen, zu testen und auszuliefern, und sie
ermöglichen auch die Definition der Prozess- und Datenflüsse für
die Produktelemente durch das Softwarekonfigurationssystem von
der Erstellung und Aktualisierung bis hin zur Auslieferung.
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 Managers 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.
Es ist eine Aufgabe der Erfindung, ein System und ein Verfahren
zur Softwarekonfiguration zur Verfügung zu stellen, die eine
effiziente Gruppenarbeit zum Entwickeln, Aktualisieren,
Erstellen, Hochstufen, Testen und Ausliefern von
Produktelementen ermöglichen, die zum Bilden verschiedener
Versionen eines Softwarepakets miteinander verknüpft sind.
Es ist auch eine Aufgabe der Erfindung, ein System und ein
Verfahren zur Softwarekonfiguration zur Verfügung zu stellen,
die es dem Benutzer ermöglichen, Prozess- und Datenflüsse für
Produktelemente von der Erstellung und Aktualisierung bis hin
zur Auslieferung eines Softwarepakets durch das
Softwarekonfigurationssystem zu definieren.
Es ist eine weitere Aufgabe der Erfindung, eine gemeinsame
Konfigurationsformatierungssprache zur Handhabung einer Vielzahl
von Produktelementen zur Verfügung zu stellen, die in einem
Bibliothekssystem gespeichert sind. Die gemeinsame Sprache dient
zum Zugriff auf Produktelemente und zur Bestimmung, wie sich die
Elemente im Hinblick auf Eingaben, Ausgaben, logische
Abhängigkeiten und spezifische Parameter für die Softwarepakete,
die entwickelt oder aktualisiert werden sollen, aufeinander
beziehen.
Es ist eine weitere Aufgabe der Erfindung, ein System und ein
Verfahren zur Softwarekonfiguration zur Verfügung zu stellen,
die verteilte Gruppenarbeit und Erstellungsserver ermöglichen,
die von unterschiedlichen Herstellern stammen und von
unterschiedlichen Betriebssystemen gesteuert werden, um
untereinander zu kommunizieren.
Es ist auch eine Aufgabe der Erfindung, ein System und ein
Verfahren zur Verfügung zu stellen, die die Verwendung einer
zentralen Definition für Zugriffsregeln auf die Daten und
Prozesse, für den Prozessarbeitsablauf, die Problemaufzeichnung,
die Benachrichtigungsregeln, die Erstellungsregeln, die
Hochstufungsregeln und die Editierregeln innerhalb einer
Softwarekonfigurationsumgebung erlauben, an der eine Vielzahl
von Entwicklern beteiligt sind, die an verschiedenen Orten,
entfernt voneinander, residieren können.
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.
Im Folgenden wird eine bevorzugte Ausführungsart der Erfindung
mit Bezug auf die Zeichnungen und auf ein Anwendungsbeispiel
beschrieben. Die Zeichnungen zeigen:
Fig. 1 ein schematisches Blockdiagramm eines bekannten Server-
Computers, der für Implementierungen der im vorliegenden
Dokument gezeigten Erfindung verwendet werden kann;
Fig. 2 ein allgemeines Blockdiagramm eines Computersystems,
das zur Ausführung einer Ausführungsart der Erfindung angepasst
ist;
Fig. 3 ein allgemeines Blockdiagramm eines verteilten
Computersystems, das zur Ausführung einer anderen Ausführungsart
der Erfindung angepasst ist;
Fig. 4A ein schematisches Blockdiagramm des Systems zur
Softwarekonfiguration gemäß der Erfindung;
Fig. 4B ein schematisches Blockdiagramm des Datenflusses
zwischen Hauptkomponenten des Systems gemäß der Erfindung;
Fig. 5 ein Blockdiagramm eines vereinfachten Beispiels eines
logischen Projektansichtsverlaufs, der den Datenfluss der
Elemente definiert;
Fig. 6 ein Blockdiagramm der logischen
Projektansichtshierarchie eines Softwareprojekts, das unter
Verwendung des Verfahrens und Systems gemäß der Erfindung
entwickelt und getestet wird;
Fig. 7 einen Unterabschnitt einer logischen
Projektansichtshierarchie, der die Kombination mit einem
definierten Prozessfluss zeigt;
Fig. 8 eine physische Memberdarstellung eines Projekts, das
unter Verwendung des Systems von Fig. 4 entwickelt und getestet
wird,
Fig. 9 ein Blockdiagramm der logischen Projektansicht mit
mehreren Hierarchien;
Fig. 10 ein Blockdiagramm der logischen Projektansicht eines
Softwareprojekts, das unter Verwendung des verteilten Systems
gemäß Fig. 3 entwickelt und getestet wird;
Fig. 11 ein Blockdiagramm des Projektaktivierungsprozesses für
die Zusammenarbeit der verteilten Systeme gemäß Fig. 3;
Fig. 12 ein Flussdiagramm des Prozesses zur Initialisierung
des XSCML-Systems;
Fig. 13 ein Flussdiagramm des Prozesses zur Verwaltung der
Projektdefinitionen; und
Fig. 14 ein Flussdiagramm des Prozesses zur Durchführung von
Benutzer-Client-Aktionen.
Fig. 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 Fig. 1 fest verbunden ist, und zu anderen
Server-Systemen, die ein ähnliches Design wie das in Fig. 1
gezeigte haben können, zur Verfügung.
Fig. 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 Fig. 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 Fig. 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 Fig. 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 Fig. 1 gezeigt, zum Zugriff
auf Werkzeuge und Daten haben.
Eine Anzahl an Computersystemen, von denen jedes dem
Computersystem von Fig. 2 entspricht, kann über ein digitales
Kommunikationsnetz wie etwa das Internet verteilt und verbunden
sein. Fig. 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. Fig. 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
Fig. 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.
Fig. 4B zeigt die Kommunikation zwischen den Hauptkomponenten
des Systems gemäß Fig. 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.
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, dass 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 Fig. 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 Fig. 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 Fig. 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.
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.
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.
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 Fig. 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.
"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:
\##project##\##group###\##member##.##type##.
\##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##).
##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 Fig. 10:
<!DOCTYPE PROJECT [
<!-- Zu verwendende physische Dateiverzeichnisse →
<!ENTITY root " \\ producta\rel1"<
<!ENTITY tester " \\test\ producta\rel1"<
<!ENTITY product "producta"<
]<
<PROJECT NAME = "MY Product"<
<!-- Es folgt die Gruppenhierarchiedefinition, die die logische Ansicht einer physischen Verzeichnisstruktur ist. Die physische Abbildung wird später beschrieben. Im einfachsten Fall würde der Gruppenname ein Unterverzeichnis eines Stammverzeichnisses sein, bei dem das Stammverzeichnis allen Gruppen gemeinsam ist und sich auf ein Projekt bezieht. →
<GROUP NAME = "PROD" DB = "PRODLIB" AC = "REL" FILEMAP = "MO"/<
<GROUP NAME = "TEST" DB = "TESTLIB" AC = "REL" PROMOTE = "PROD" FILEMAP = "M1"/<
<GROUP NAME = "DEV1" DB = "DEVLIB" AC = "REL,TEST" PROMOTE = "TEST" FILEMAP = "M2"/<
<GROUP NAME = "DEV2" DB = "DEVLIB" AC = "REL" PROMOTE = "TEST" FILEMAP = "M2"/<
<GROUP NAME = "TEAMT" DB = "DEVLIB" AC = "REL,TEST" PROMOTE = "TEST" FILEMAP = "M3"/<
<GROUP NAME = "TEAM" DB = "DEVLIB" AC = "REL,TEST" PROMOTE = "TEAMT" FILEMAP = "M3"/<
<!-- Zu verwendende physische Dateiverzeichnisse →
<!ENTITY root " \\ producta\rel1"<
<!ENTITY tester " \\test\ producta\rel1"<
<!ENTITY product "producta"<
]<
<PROJECT NAME = "MY Product"<
<!-- Es folgt die Gruppenhierarchiedefinition, die die logische Ansicht einer physischen Verzeichnisstruktur ist. Die physische Abbildung wird später beschrieben. Im einfachsten Fall würde der Gruppenname ein Unterverzeichnis eines Stammverzeichnisses sein, bei dem das Stammverzeichnis allen Gruppen gemeinsam ist und sich auf ein Projekt bezieht. →
<GROUP NAME = "PROD" DB = "PRODLIB" AC = "REL" FILEMAP = "MO"/<
<GROUP NAME = "TEST" DB = "TESTLIB" AC = "REL" PROMOTE = "PROD" FILEMAP = "M1"/<
<GROUP NAME = "DEV1" DB = "DEVLIB" AC = "REL,TEST" PROMOTE = "TEST" FILEMAP = "M2"/<
<GROUP NAME = "DEV2" DB = "DEVLIB" AC = "REL" PROMOTE = "TEST" FILEMAP = "M2"/<
<GROUP NAME = "TEAMT" DB = "DEVLIB" AC = "REL,TEST" PROMOTE = "TEST" FILEMAP = "M3"/<
<GROUP NAME = "TEAM" DB = "DEVLIB" AC = "REL,TEST" PROMOTE = "TEAMT" FILEMAP = "M3"/<
<!-- Es folgen nun die dem Projekt bekannten logischen Typen,
die eine physische Abbildung haben, die von der Umgebung
der Quelle abhängt. →
<TYPE NAME = "CPP"<
<!-- Es könnte zusätzliche Kennungen für eine detailliertere Abbildung oder Spezifikationen auf eine physische Darstellung geben →
</TYPE<
<TYPE NAME = "HPP"<</TYPE<
<TYPE NAME = "H"<</TYPE<
<TYPE NAME = "OBJ"<</TYPE<
<TYPE NAME = "LST"<</TYPE<
<TYPE NAME = "EXE"<</TYPE<
<TYPE NAME = "DLL"<</TYPE<
<TYPE NAME = "CPP"-link<</TYPE<
<!-- Es folgt die Zuordnung, welche Datenbank und welche Elemente in der Datenbank die Gruppeninhalte in Hinblick auf Zustand und Inhalt verwalten. Wenn mehrere Datenbanken möglich wären, müsste eine Synchronisation zwischen diesen, durch diese Projektdefinition definierten, Datenbanken erfolgen. Teile, die so verwaltet werden, können nur durch eine solche Projektdefinition und nicht direkt durch Verwendung der Datenbankschnittstellen verwaltet werden. Es kann nur ein Lesezugriff durch die Datenbank auf solche Elemente erlaubt sein. →
<DB NAME = "PRODLIB"<
<!-- Es folgen spezifischere Informationen, wo das zugehörige Datenbanksystem wie TC Family, SCLM Project, etc. gefunden werden kann, das die Daten oder Metadaten zur Steuerung des Inhalts des Dateisystems, das durch das Projekt beschrieben wird, enthält. Sie können auch den Grad der Versionierung, der in der Datenbank, d. h. für Gruppen und Typen oder Assoziationen von Gruppen zu Prozessen oder Zuständen, erfolgt, definieren. Hier wird auch die Abbildung von logisch zu physisch definiert →
<TYPE NAME = "CPP"<
<!-- Es könnte zusätzliche Kennungen für eine detailliertere Abbildung oder Spezifikationen auf eine physische Darstellung geben →
</TYPE<
<TYPE NAME = "HPP"<</TYPE<
<TYPE NAME = "H"<</TYPE<
<TYPE NAME = "OBJ"<</TYPE<
<TYPE NAME = "LST"<</TYPE<
<TYPE NAME = "EXE"<</TYPE<
<TYPE NAME = "DLL"<</TYPE<
<TYPE NAME = "CPP"-link<</TYPE<
<!-- Es folgt die Zuordnung, welche Datenbank und welche Elemente in der Datenbank die Gruppeninhalte in Hinblick auf Zustand und Inhalt verwalten. Wenn mehrere Datenbanken möglich wären, müsste eine Synchronisation zwischen diesen, durch diese Projektdefinition definierten, Datenbanken erfolgen. Teile, die so verwaltet werden, können nur durch eine solche Projektdefinition und nicht direkt durch Verwendung der Datenbankschnittstellen verwaltet werden. Es kann nur ein Lesezugriff durch die Datenbank auf solche Elemente erlaubt sein. →
<DB NAME = "PRODLIB"<
<!-- Es folgen spezifischere Informationen, wo das zugehörige Datenbanksystem wie TC Family, SCLM Project, etc. gefunden werden kann, das die Daten oder Metadaten zur Steuerung des Inhalts des Dateisystems, das durch das Projekt beschrieben wird, enthält. Sie können auch den Grad der Versionierung, der in der Datenbank, d. h. für Gruppen und Typen oder Assoziationen von Gruppen zu Prozessen oder Zuständen, erfolgt, definieren. Hier wird auch die Abbildung von logisch zu physisch definiert →
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 Fig. 6.
XSCML-Syntax für den Datenfluss, der als
Flussbaum definiert ist:
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.
Die Veröffentlichung "TeamConnection Users Guide" von IBM,
Veröffentlichungsnummer SC34-4499-04, Seite 183, Fig. 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.
Der in den Beispielen 3 und 4 kompilierte Code wird zur
Erstellung eines Pakets verknüpft. Dies wird im Beispiel 5
dargestellt.
Im folgenden Beispiel 6 werden die Definitionen für die
gesamte Anwendung durch Verwenden einer höheren Paketierung
beschrieben.
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.
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.
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:
Der zur Sprache LINK gehörende Prozess c_link.lang kann wie
folgt definiert werden:
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.
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<
<PARM1< MAR(1,80) OM(1,80) </PARM1<
c370.parms
<PARM2< LIST AGGREGATE </PARM2<.
<PARM2< LIST AGGREGATE </PARM2<.
Das Kompilierpaket cicspart.pkg wird zum Erstellen von
cicspart.mod verwendet:
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.
<!DOCTYPE LANG[
<!ENTITY includes SYSTEM "c_include.libs"<
<!ENTITY parsec SYSTEM "parse c.step" <
<!-- Parameter für CICS-Vorprozessorschritt-Grundbaustein →
<!ENTITY IOTYPE_SYSIN "S"<
<!ENTITY DD_SYSIN "CICIN"<
<!ENTITY KEYREF_SYSIN "SINC"<
<!ENTITY DD_SYSPRINT "CICPRINT"<
<!ENTITY KEYREF_SYSPRINT ""<
<!ENTITY RECFM_SYSPRINT "VBA"<
<!ENTITY LRECL_SYSPRINT "137"<
<!ENTITY RECNUM_SYSPRINT "35000"<
<!ENTITY KEYREF_SYSPUNCH ""<
<!ENTITY DD_SYSPUNCH "CICPUNCH"<
<!ENTITY RECFM_SYSPUNCH "FB"<
<!ENTITY LRECL_SYSPUNCH "80"<
<!ENTITY RECNUM_SYSPUNCH "80000"<
<!ENTITY cicspre SYSTEM "cics.step"<
<!-- Parameter für CICS-Kompilierschritt-Grundbaustein →
<!ENTITY DD_COMPUNCH ""<
<!ENTITY DD_ALL "DD_ALL"<
<!ENTITY c370comp SYSTEM "c370.step"<
<!-- Parameter für Listenverknüpfer-Grundbaustein →
<!ENTITY DD_lst_cpre ""<
<!ENTITY DD_lst_comp ""<
<!ENTITY packlst SYSTEM "packlst.step"<
]<
<!ENTITY includes SYSTEM "c_include.libs"<
<!ENTITY parsec SYSTEM "parse c.step" <
<!-- Parameter für CICS-Vorprozessorschritt-Grundbaustein →
<!ENTITY IOTYPE_SYSIN "S"<
<!ENTITY DD_SYSIN "CICIN"<
<!ENTITY KEYREF_SYSIN "SINC"<
<!ENTITY DD_SYSPRINT "CICPRINT"<
<!ENTITY KEYREF_SYSPRINT ""<
<!ENTITY RECFM_SYSPRINT "VBA"<
<!ENTITY LRECL_SYSPRINT "137"<
<!ENTITY RECNUM_SYSPRINT "35000"<
<!ENTITY KEYREF_SYSPUNCH ""<
<!ENTITY DD_SYSPUNCH "CICPUNCH"<
<!ENTITY RECFM_SYSPUNCH "FB"<
<!ENTITY LRECL_SYSPUNCH "80"<
<!ENTITY RECNUM_SYSPUNCH "80000"<
<!ENTITY cicspre SYSTEM "cics.step"<
<!-- Parameter für CICS-Kompilierschritt-Grundbaustein →
<!ENTITY DD_COMPUNCH ""<
<!ENTITY DD_ALL "DD_ALL"<
<!ENTITY c370comp SYSTEM "c370.step"<
<!-- Parameter für Listenverknüpfer-Grundbaustein →
<!ENTITY DD_lst_cpre ""<
<!ENTITY DD_lst_comp ""<
<!ENTITY packlst SYSTEM "packlst.step"<
]<
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:
Ein Syntaxanalyseschritt-Grundbaustein ist parse c.step:
Die CICS-Vorprozessorschritt-Grundbausteindefinition ist
cics.step:
Der C-Kompilierungsschritt-Grundbaustein ist c370.step:
Der Prozess zum Zusammenfügen von Auflistungsausgaben zu einer
Ausgabe lautet "packlst.step."
Fig. 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 Fig. 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 Widerrufsschritt, 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.
Fig. 7 zeigt einen Abschnitt des Prozessflusses des Projekts
gemäß Fig. 6 detaillierter. Durch Verwendung der
Projektmetadaten 41 (Fig. 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:
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:
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.
Fig. 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
Fig. 8 enthält ein Block 80 die Projektdefinition. Dieser Block
entspricht dem Abschnitt 45 der Datenbank (Fig. 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, PLIMAC 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 Fig. 4A und
4B, der in Fig. 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.
Fig. 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 Fig. 6 und 7 beschrieben. Die Struktur der
Hierarchiebeziehung zwischen den in Fig. 9 gezeigten Blöcken
entspricht der in Verbindung mit Fig. 6 beschriebenen.
Fig. 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 Fig. 10 als Blöcke 100, 101 und 102
bezeichnet sind. Wie schon in Verbindung mit Fig. 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 Fig. 6 entsprechen. Darüber hinaus
umfasst das System 102 den Editiertestabschnitt mit den
Einheiten DEVTA, DEVTB und TEAMT, die DEVA, DEVB und TEAMT in
Fig. 6 entsprechen. Das System 102 führt auch den Test der
Korrekturen durch FIXTEST1 der ersten Version des Produkts
durch, welcher FIXTEST1 in Fig. 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 Fig. 6 entsprechen. In dem System 100 werden die
Produktversionen PROD1 und PROD2 verwaltet, analog zu PROD1 und
PROD2 in Fig. 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 Fig. 6 gezeigten Systems. In
jedem dieser Systeme werden der Datenfluss und die Prozesse
durch den lokalen XSCML-Prozessor gesteuert.
Wie in Fig. 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.
Fig. 12 zeigt die Schritte zur Initialisierung des XSCML-
Systems in einer verteilten Umgebung gemäß Fig. 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 Fig. 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 Aktualislerungsmodus.
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 Fig. 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.
Fig. 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 (Fig. 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 03690 00070 552 001000280000000200012000285910357900040 0002010121790 00004 03571Elemente 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 (31)
1. Softwarekonfigurationsverfahren zur Verwendung in einem
Computersystem, 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, die miteinander verbunden sind,
um ein Softwarepaket und verschiedene Versionen eines
Softwarepakets zu bilden, des Weiteren zum Speichern von
Prozessen, die von den Clients verwendet werden können, um
die Elemente zu verwalten und neue Elemente zu entwickeln,
und Werkzeuge, die von den Clients verwendet werden können,
um die Beziehung zwischen den Produktelementen zu
definieren, zu verwalten und zu aktualisieren,
wobei das Verfahren die Schritte umfasst:
Definieren einer gemeinsamen Softwarekonfigurationsformatierungssprache, die sich dafür eignet, ein Projekt (53, 60) zu definieren, einen Speicherzugriff auf Produktelemente (44, 45) und Pakete (43) durchzuführen, und die Prozesse und Werkzeuge (48, 49, 50) auf ein oder mehrere Bibliothekssysteme abzubilden und die Beziehungen zwischen den Produktelementen zu definieren;
Erzeugen und Speichern einer Projektdefinition, die Datenfluss, Prozessfluss und Projektdefinition eines Projekts unter Verwendung der gemeinsamen Softwarekonfigurationsformatierungssprache definiert;
Erzeugen und Speichern eines Softwarekonfigurationsgerüsts unter Verwendung der Projektdefinition (40) und Prozessdefinition, um die Produktelemente (43, 44, 45) und Prozesse zu beschreiben und ihre Zugriffsparameter und die Beziehungen zueinander zu definieren;
Abbilden der Produktelemente (43, 44, 45), Prozesse und Werkzeuge auf ein oder mehrere Bibliothekssysteme unter Verwendung der gemeinsamen Softwarekonfigurationsformatierungssprache;
Speichern der Produktelemente, Prozesse und Werkzeuge im Speicher des Servers (20) oder in den Speichern aller Server (20, 51), falls mehr als ein Server verwendet wird;
Zuweisen der Produktelemente, Prozesse und Werkzeuge in dem Speicher zu dem Softwarekonfigurationsgerüst; und
Aufrufen ausgewählter Produktelemente (43, 44, 45), Werkzeuge und Prozesse durch mindestens einen der Clients unter Verwendung von Befehlen der gemeinsamen Softwarekonfigurationsformatierungssprache, wobei andere Programmiersprachen zum Entwickeln, Aktualisieren oder Testen der Inhalte der aufgerufenen Produktelemente verwendet werden können.
wobei das Verfahren die Schritte umfasst:
Definieren einer gemeinsamen Softwarekonfigurationsformatierungssprache, die sich dafür eignet, ein Projekt (53, 60) zu definieren, einen Speicherzugriff auf Produktelemente (44, 45) und Pakete (43) durchzuführen, und die Prozesse und Werkzeuge (48, 49, 50) auf ein oder mehrere Bibliothekssysteme abzubilden und die Beziehungen zwischen den Produktelementen zu definieren;
Erzeugen und Speichern einer Projektdefinition, die Datenfluss, Prozessfluss und Projektdefinition eines Projekts unter Verwendung der gemeinsamen Softwarekonfigurationsformatierungssprache definiert;
Erzeugen und Speichern eines Softwarekonfigurationsgerüsts unter Verwendung der Projektdefinition (40) und Prozessdefinition, um die Produktelemente (43, 44, 45) und Prozesse zu beschreiben und ihre Zugriffsparameter und die Beziehungen zueinander zu definieren;
Abbilden der Produktelemente (43, 44, 45), Prozesse und Werkzeuge auf ein oder mehrere Bibliothekssysteme unter Verwendung der gemeinsamen Softwarekonfigurationsformatierungssprache;
Speichern der Produktelemente, Prozesse und Werkzeuge im Speicher des Servers (20) oder in den Speichern aller Server (20, 51), falls mehr als ein Server verwendet wird;
Zuweisen der Produktelemente, Prozesse und Werkzeuge in dem Speicher zu dem Softwarekonfigurationsgerüst; und
Aufrufen ausgewählter Produktelemente (43, 44, 45), Werkzeuge und Prozesse durch mindestens einen der Clients unter Verwendung von Befehlen der gemeinsamen Softwarekonfigurationsformatierungssprache, wobei andere Programmiersprachen zum Entwickeln, Aktualisieren oder Testen der Inhalte der aufgerufenen Produktelemente verwendet werden können.
2. Verfahren gemäß Anspruch 1, worin die gemeinsame
Softwarekonfigurationsformatierungssprache eine
erweiterbare Formatierungssprache ist.
3. Verfahren gemäß Anspruch 2, worin die gemeinsame
Softwarekonfigurationsformatierungssprache auf der
erweiterbaren Formatierungssprache XML (Extensible Markup
Language) basiert.
4. Verfahren gemäß Anspruch 1, das den Schritt der
Befehlserzeugung in der gemeinsamen
Softwarekonfigurationsformatierungssprache durch ein
Steuerprogramm auf dem Server umfasst, wobei das
Steuerprogramm Teil des Softwarekonfigurationsgerüst ist.
5. Verfahren gemäß Anspruch 1, worin die gemeinsame
Softwarekonfigurationsformatierungssprache zur Definition
eines Projekts (53) verwendet wird, um ein Softwareprodukt
auf einem ersten Server (20) zu entwickeln oder zu
aktualisieren, das die Schritte des Zugreifens auf
Projektdefinitionsdaten und Daten über die Projektzustände,
Benutzerzugriffsrechte und Elementbeziehungen in einer
Datenbank (24), die mit dem ersten Server zum Einrichten
des Projekts verbunden ist, und des wiederholten Zugreifens
auf und Aktualisierens der Projektzustandsdaten in der
Datenbank umfasst.
6. Verfahren gemäß Anspruch 1, worin die gemeinsame
Softwarekonfigurationsformatierungssprache zur Vorbereitung
einer Editieraktion für Produktelemente verwendet wird, das
die Schritte des Aufrufens eines Editors umfasst, an den
das Produkt und die Prozessdefinition, die Elementzustände
und Beziehungen zwischen den Elementen durch ein
Steuerprogramm auf dem ersten Server zur Verfügung gestellt
werden, wobei das Steuerprogramm dem
Softwarekonfigurationsgerüst zugeordnet ist; und des
Zugreifens auf Prozesse und Werkzeuge in der Datenbank zum
Entwickeln neuer Produktelemente oder Andern und
Aktualisieren existierender Produktelemente durch das
Steuerprogramm.
7. Verfahren gemäß Anspruch 5, worin der Editor eine Sprache
verwendet, die von der gemeinsamen
Softwarekonfigurationsformatierungssprache unabhängig ist.
8. Verfahren gemäß Anspruch 1, worin die gemeinsame
Softwarekonfigurationsformatierungssprache zum Erstellen
(Kompilieren) von Produktelementpaketen auf einem zweiten
Server (27) verwendet wird, der mit der Datenbank (24)
verbunden ist, das die Schritte des Zugreifens auf die
Prozesse und Werkzeuge in seinem eigenen Speicher oder in
der Datenbank zum Kompilieren und Verknüpfen der
Produktelemente zur Bildung von Programmpaketen umfasst.
9. Verfahren gemäß Anspruch 1, das den Schritt der Erzeugung
selbstdokumentierender Produktelemente und
Produktelementpakete und deren Aktualisierungen durch
Verwendung der gemeinsamen
Softwarekonfigurationsformatierungssprache umfasst.
10. Verfahren gemäß Anspruch 1, worin der Speicherschritt den
Schritt des Speicherns des systemunabhängigen
Softwarekonfigurationsgerüsts in den Speichern einer
Vielzahl von geografisch verteilten Computersystemen (30,
31, 32) umfasst, die durch ein Kommunikationsnetz (34)
miteinander verbunden sind, und worin der Zuweisungsschritt
den Schritt des Zuweisens der Produktelemente, Prozesse und
Werkzeuge zu dem systemunabhängigen
Softwarekonfigurationsgerüst in den Speichern eines jeden
der verteilten Computersysteme umfasst.
11. Verfahren gemäß Anspruch 10, worin jedes der verteilten
Computersysteme (30, 31, 32) Befehle in der gemeinsamen
Softwarekonfigurationsformatierungssprache durch ein
Steuerprogramm erzeugt, das Teil des
Softwarekonfigurationsgerüsts ist.
12. Verfahren gemäß Anspruch 10, das die Schritte des
Editierens der Produktelemente in jedem der verteilten
Systeme (30, 31, 32) durch Verwendung eines ersten Servers
(20), der mit einer lokal installierten Datenbank (24)
verbunden ist, und durch das Erstellen von Paketen durch
einen zweiten Server (27), der mit der Datenbank verbunden
ist, umfasst.
13. Verfahren gemäß Anspruch 10, worin der Aufrufschritt den
Schritt des Aufrufens von Elementen, Werkzeugen und
Prozessen durch mindestens einen der an die Server in jedem
der verteilten Systeme (30, 31, 32) angeschlossenen Clients
und des Editierens der Elemente durch Verwendung der
gleichen oder anderer Programmiersprachen, die von der
gemeinsamen Softwarekonfigurationsformatierungssprache
unabhängig sind, umfasst.
14. Verfahren gemäß Anspruch 10, das den Schritt der
Übertragung von Änderungen der Produktelemente, die aus der
Verarbeitung der Produktelemente durch jedes der verteilten
Systeme (30, 31, 32) resultieren, an alle anderen der
verteilten Systeme umfasst.
15. Verfahren gemäß Anspruch 10, worin eines der verteilten
Systeme (30, 31, 32) als Hauptsystem verwendet wird, dessen
Speicher die Projektdefinition und Prozessdefinitionsdaten
in der gemeinsamen
Softwarekonfigurationsformatierungssprache enthält, deren
Daten von dem Steuerprogramm verwendet werden, um das
Softwarekonfigurationsgerüst zu initialisieren.
16. Softwarekonfigurationsverfahren zur Verwendung in einem
Computersystem, das mindestens einen Server (20)
einschließt, der mit einer Vielzahl von Client-Computern
(25) verbunden ist, wobei der Server einen Speicher (14)
zum Speichern von Produktelementen besitzt, die miteinander
verbunden sind, um ein Softwarepaket oder verschiedene
Versionen eines Softwarepakets zu bilden, des Weiteren die
Prozesse, die von den Clients verwendet werden können,
speichert, um die Elemente zu verwalten und neue Elemente
zu entwickeln, und Werkzeuge, die von den Clients verwendet
werden können, um die Beziehung zwischen den
Produktelementen zu definieren, zu verwalten und zu
aktualisieren,
wobei das System Folgendes umfasst:
Mittel (40) zum Speichern der Projektdefinitionsdaten, die Datenfluss, Prozessfluss und Prozessdefinition eines Projekts unter Verwendung einer gemeinsamen Softwarekonfigurationsformatierungssprache definieren, die dazu angepasst ist, als eine Metasyntax zur Definition von einem Projekt und von Prozessen zu dienen, um das Projekt durchzuführen, die Prozesse und Werkzeuge auf eine Datenbank (24) abzubilden, und auf Produktelemente in der Datenbank zuzugreifen;
Mittel (43, 44, 45) zum Erzeugen und Speichern eines Softwarekonfigurationsgerüsts unter Verwendung der Projektdefinition, um die Produktelemente und Prozesse zu beschreiben und ihre Zugriffsparameter und die Beziehungen untereinander zu definieren;
Mittel (40, 43, 44, 45, 48, 49, 50) zum Abbilden und Speichern der Produktelemente, Prozesse und Werkzeuge in dem Speicher des Servers (20) oder in den Speichern aller Server, wenn mehr als ein Server verwendet wird;
Mittel (22) zum Zuweisen der Produktelemente, Prozesse und Werkzeuge in dem Speicher zu dem Softwarekonfigurationsgerüst; und
Mittel (25, 46) zum Aufrufen ausgewählter Produktelemente, Werkzeuge und Prozesse durch mindestens einen der Clients unter Verwendung von Befehlen der gemeinsamen Softwarekonfigurationsformatierungssprache; und Mittel (141), um dem Benutzer die Entwicklung, die Aktualisierung oder das Testen der Inhalte der aufgerufenen Produktelemente unter Verwendung einer Sprache, die von der gemeinsamen Softwarekonfigurationssprache unabhängig ist, zu ermöglichen.
wobei das System Folgendes umfasst:
Mittel (40) zum Speichern der Projektdefinitionsdaten, die Datenfluss, Prozessfluss und Prozessdefinition eines Projekts unter Verwendung einer gemeinsamen Softwarekonfigurationsformatierungssprache definieren, die dazu angepasst ist, als eine Metasyntax zur Definition von einem Projekt und von Prozessen zu dienen, um das Projekt durchzuführen, die Prozesse und Werkzeuge auf eine Datenbank (24) abzubilden, und auf Produktelemente in der Datenbank zuzugreifen;
Mittel (43, 44, 45) zum Erzeugen und Speichern eines Softwarekonfigurationsgerüsts unter Verwendung der Projektdefinition, um die Produktelemente und Prozesse zu beschreiben und ihre Zugriffsparameter und die Beziehungen untereinander zu definieren;
Mittel (40, 43, 44, 45, 48, 49, 50) zum Abbilden und Speichern der Produktelemente, Prozesse und Werkzeuge in dem Speicher des Servers (20) oder in den Speichern aller Server, wenn mehr als ein Server verwendet wird;
Mittel (22) zum Zuweisen der Produktelemente, Prozesse und Werkzeuge in dem Speicher zu dem Softwarekonfigurationsgerüst; und
Mittel (25, 46) zum Aufrufen ausgewählter Produktelemente, Werkzeuge und Prozesse durch mindestens einen der Clients unter Verwendung von Befehlen der gemeinsamen Softwarekonfigurationsformatierungssprache; und Mittel (141), um dem Benutzer die Entwicklung, die Aktualisierung oder das Testen der Inhalte der aufgerufenen Produktelemente unter Verwendung einer Sprache, die von der gemeinsamen Softwarekonfigurationssprache unabhängig ist, zu ermöglichen.
17. System gemäß Anspruch 16, worin die gemeinsame
Softwarekonfigurationsformatierungssprache eine
erweiterbare Formatierungssprache ist.
18. System gemäß Anspruch 16, worin die gemeinsame
Softwarekonfigurationsformatierungssprache auf der
erweiterbaren Formatierungssprache XML (Extensible Markup
Language) basiert.
19. System gemäß Anspruch 16, das Mittel (46) zur
Befehlserzeugung in der gemeinsamen
Softwarekonfigurationsformatierungssprache umfasst, wobei
diese Mittel Teil des Softwarekonfigurationsgerüsts sind.
20. System gemäß Anspruch 16, worin die gemeinsame
Softwarekonfigurationsformatierungssprache zur Definition
von Projektdaten eines Softwareprodukts auf einem ersten
Server (20) verwendet wird, das Mittel (22, 41) zum
Zugreifen auf Projektdefinitionsdaten und Daten über den
Projektstatus und Elementbeziehungen in einer Datenbank (24),
die mit dem ersten Server (20) zum Einrichten des
Projekts verbunden ist, und zum wiederholten Zugreifen auf
und Aktualisieren der Projektzustandsdaten in der Datenbank
umfasst.
21. System gemäß Anspruch 16, worin die gemeinsame
Softwarekonfigurationsformatierungssprache zur Vorbereitung
einer Editieraktion für die Produktelemente verwendet wird,
das Mittel (144) umfasst, um einen Editor aufzurufen; und
Steuerprogrammmittel (22), um auf die Projektdefinition und
die Prozessdefinition, die Elementzustände und die
Beziehungen zwischen den Elementen in der Datenbank
zuzugreifen und um sie für die Editieraktion verfügbar zu
machen, wobei die Steuerprogrammmittel (22) auch zum
Zugreifen auf die Prozesse (40) und Werkzeuge (48, 49, 50)
verwendet werden, um neue Produktelemente zu entwickeln
oder existierende Produktelemente zu ändern und zu
aktualisieren.
22. System gemäß Anspruch 16, worin der Editor eine
Programmiersprache verwendet, die von der gemeinsamen
Softwarekonfigurationsformatierungssprache unabhängig ist.
23. System gemäß Anspruch 16, worin die gemeinsame
Softwarekonfigurationsformatierungssprache zum Erstellen von
Paketen von Produktelementen auf einem zweiten Server (27)
verwendet wird, das Mittel (143) zum Zugreifen auf die
Prozesse und Werkzeuge in seinem eigenen Speicher (14) oder
in der Datenbank (24) und Mittel (145) zum Kompilieren und
Verknüpfen der Produktelemente, um Programmpakete zu bilden,
umfasst.
24. System gemäß Anspruch 16, das Mittel zur Erzeugung
selbstdokumentierender Produktelemente und
Produktelementpakete und deren Aktualisierungen unter
Verwendung der gemeinsamen
Softwarekonfigurationsformatierungssprache umfasst.
25. System gemäß Anspruch 16, worin die Speichermittel des
Weiteren Mittel (111, 115) zum Speichern des
systemunabhängigen Softwarekonfigurationsgerüsts in den
Speichern einer Vielzahl von geografisch verteilten Systemen
(30, 31, 32; 112, 113, 114) umfasst, die miteinander durch
ein Kommunikationsnetz (34) verbunden sind, und worin die
Zuweisungsmittel (22, 40) Mittel zum Zuweisen der
Produktelemente, Prozesse und Werkzeuge zu den
systemunabhängigen Softwarekonfigurationsgerüsten in den
Speichern der verteilten Systeme umfassen.
26. System gemäß Anspruch 25, worin jedes der verteilten Systeme
(30, 31, 32; 112, 113, 114) Mittel (46) zum Erzeugen von
Befehlen in der gemeinsamen
Softwarekonfigurationsformatierungssprache durch
Steuerprogramme (22), die mit dem verteilten
Softwarekonfigurationsgerüst verbunden und in diesem
verteilten System gespeichert sind, umfasst.
27. System gemäß Anspruch 25, das in jedem der verteilten
Systeme (112, 113, 114) Mittel (141, 144) zum Editieren von
Produktelementen unter Verwendung eines ersten Servers (20
oder 51), der mit einer lokal installierten Datenbank (24)
verbunden ist, und Mittel (141, 145) zum Erstellen von
Paketen auf einem zweiten Server (27), der mit der lokal
installierten Datenbank (24) verbunden ist, umfasst.
28. System gemäß Anspruch 25, worin die Aufrufmittel (25, 46)
des Weiteren Mittel (143) zum Aufrufen von Elementen durch
mindestens einen der Clients (25), die an die Server (20, 27)
in jedem der verteilten Systeme (112, 113, 114)
angeschlossen sind, und zum Editieren dieser Elemente unter
Verwendung der gleichen oder anderer Programmiersprachen,
die von der gemeinsamen
Softwarekonfigurationsformatierungssprache unabhängig sind,
umfassen.
29. System gemäß Anspruch 25, das Mittel (22, 52, 115) zum
Übertragen von Änderungen der Produktelemente, die aus der
Verarbeitung der Produktelemente in jedem der verteilten
Systeme (112, 113, 114) resultieren, an alle anderen der
verteilten Systeme umfasst.
30. System gemäß Anspruch 25, worin eines der verteilten Systeme
(112, 113, 114) als Hauptsystem (111) verwendet wird, dessen
Speicher die Projektdefinitionsdaten in der gemeinsamen
Softwarekonfigurationsformatierungssprache enthält, die von
dem Steuerprogramm (22) des Hauptsystems (111) zur
Initialisierung des Softwarekonfigurationsgerüsts und zur
Übertragung von dessen Kopien an andere Systeme verwendet
wird.
31. Computerprogrammprodukt, das Programmcodeteile zur
Durchführung der jeweiligen Schritte des Verfahrens gemäß
der Ansprüche 1 bis 15 umfasst, wenn das Programm auf einem
Computer ausgeführt wird.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP00111783 | 2000-06-03 | ||
EP00111783 | 2000-06-03 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10121790A1 true DE10121790A1 (de) | 2001-12-13 |
DE10121790B4 DE10121790B4 (de) | 2006-11-23 |
Family
ID=8168892
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10121790A Expired - Fee Related DE10121790B4 (de) | 2000-06-03 | 2001-05-04 | Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem |
Country Status (2)
Country | Link |
---|---|
US (1) | US7194730B2 (de) |
DE (1) | DE10121790B4 (de) |
Families Citing this family (120)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6181694B1 (en) | 1998-04-03 | 2001-01-30 | Vertical Networks, Inc. | Systems and methods for multiple mode voice and data communciations using intelligently bridged TDM and packet buses |
US6389009B1 (en) | 2000-12-28 | 2002-05-14 | Vertical Networks, Inc. | Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet buses |
US6735757B1 (en) | 1998-06-04 | 2004-05-11 | Gateway, Inc. | Apparatus and method for checking component compatibility in a build to order computer system |
US7117435B1 (en) | 2000-06-21 | 2006-10-03 | Microsoft Corporation | Spreadsheet fields in text |
US6883168B1 (en) | 2000-06-21 | 2005-04-19 | Microsoft Corporation | Methods, systems, architectures and data structures for delivering software via a network |
US7191394B1 (en) | 2000-06-21 | 2007-03-13 | Microsoft Corporation | Authoring arbitrary XML documents using DHTML and XSLT |
US7624356B1 (en) | 2000-06-21 | 2009-11-24 | Microsoft Corporation | Task-sensitive methods and systems for displaying command sets |
US7155667B1 (en) | 2000-06-21 | 2006-12-26 | Microsoft Corporation | User interface for integrated spreadsheets and word processing tables |
US7346848B1 (en) | 2000-06-21 | 2008-03-18 | Microsoft Corporation | Single window navigation methods and systems |
US6874143B1 (en) * | 2000-06-21 | 2005-03-29 | Microsoft Corporation | Architectures for and methods of providing network-based software extensions |
US6948135B1 (en) | 2000-06-21 | 2005-09-20 | Microsoft Corporation | Method and systems of providing information to computer users |
US7000230B1 (en) | 2000-06-21 | 2006-02-14 | Microsoft Corporation | Network-based software extensions |
AU2002317119A1 (en) * | 2001-07-06 | 2003-01-21 | Angoss Software Corporation | A method and system for the visual presentation of data mining models |
US8621077B2 (en) * | 2001-09-21 | 2013-12-31 | Mcafee, Inc. | Distribution of security policies for small to medium-sized organizations |
US7257620B2 (en) * | 2001-09-24 | 2007-08-14 | Siemens Energy & Automation, Inc. | Method for providing engineering tool services |
CA2358563A1 (en) * | 2001-10-05 | 2003-04-05 | Ibm Canada Limited - Ibm Canada Limitee | Method and system for managing software testing |
US20030105871A1 (en) * | 2001-11-13 | 2003-06-05 | Microsoft Corporation, | Method and system for modifying lock properties in a distributed environment |
US6748470B2 (en) * | 2001-11-13 | 2004-06-08 | Microsoft Corporation | Method and system for locking multiple resources in a distributed environment |
US7028300B2 (en) * | 2001-11-13 | 2006-04-11 | Microsoft Corporation | Method and system for managing resources in a distributed environment that has an associated object |
US7406519B2 (en) * | 2001-11-13 | 2008-07-29 | Microsoft Corporation | Method and system for locking resources in a distributed environment |
US7051036B2 (en) * | 2001-12-03 | 2006-05-23 | Kraft Foods Holdings, Inc. | Computer-implemented system and method for project development |
US7069541B2 (en) * | 2002-03-01 | 2006-06-27 | Bellsouth Intellectual Property Corporation | System and method for a web-based application development and deployment tracking tool |
JP3956128B2 (ja) * | 2002-10-31 | 2007-08-08 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 情報端末、送受信代理装置、通信システム、通信方法、プログラム、及び記録媒体 |
US6907420B2 (en) * | 2002-11-14 | 2005-06-14 | Vibren Technologies, Inc. | Parameterizing system and method |
US7739365B2 (en) | 2002-12-19 | 2010-06-15 | Converged Data Solutions, Inc. | Methods for providing a report database for a plurality of localized devices using an abstraction layer and atomic error handling |
US7908352B2 (en) | 2002-12-19 | 2011-03-15 | Converged Data Solutions, Inc. | Methods for managing a plurality of localized devices in geographically diverse locations |
US7415672B1 (en) | 2003-03-24 | 2008-08-19 | Microsoft Corporation | System and method for designing electronic forms |
US7370066B1 (en) | 2003-03-24 | 2008-05-06 | Microsoft Corporation | System and method for offline editing of data files |
US7913159B2 (en) | 2003-03-28 | 2011-03-22 | Microsoft Corporation | System and method for real-time validation of structured data files |
US7296017B2 (en) | 2003-03-28 | 2007-11-13 | Microsoft Corporation | Validation of XML data files |
EP1609148A4 (de) * | 2003-03-31 | 2011-11-23 | Samsung Electronics Co Ltd | VORRICHTUNG ZUR VERWENDUNG MIT EINEM INFORMATIONSSPEICHERMEDIUM,DAS ERWEITERTE AV-(ENAV-)PUFFERKONFIGURATIONSINFORMATIONEN ENTHûLT,WIEDERGABEVERFAHREN DAF R UND VERFAHREN ZUR VERWALTUNG DES PUFFERS |
WO2004088549A2 (de) * | 2003-04-01 | 2004-10-14 | Siemens Aktiengesellschaft | Verfahren und anordnung zur veränderung von software oder quellcode |
US20040215747A1 (en) * | 2003-04-11 | 2004-10-28 | Jonathan Maron | System and method for a configuration repository |
US7308684B2 (en) * | 2003-06-16 | 2007-12-11 | Microsoft Corporation | Classifying software and reformulating resources according to classifications |
US7496904B2 (en) * | 2003-06-26 | 2009-02-24 | Microsoft Corporation | Mining dependencies for testing and risk management |
US20040268302A1 (en) * | 2003-06-26 | 2004-12-30 | Microsoft Corporation | Framework for determining and exposing binary dependencies |
US7451392B1 (en) | 2003-06-30 | 2008-11-11 | Microsoft Corporation | Rendering an HTML electronic form by applying XSLT to XML using a solution |
US20050138150A1 (en) * | 2003-07-11 | 2005-06-23 | Computer Associates Think, Inc. | System and method for graphically presenting change and configuration management information |
US7406660B1 (en) | 2003-08-01 | 2008-07-29 | Microsoft Corporation | Mapping between structured data and a visual surface |
US7334187B1 (en) | 2003-08-06 | 2008-02-19 | Microsoft Corporation | Electronic form aggregation |
US7472422B1 (en) | 2003-09-10 | 2008-12-30 | Symantec Corporation | Security management system including feedback and control |
US7383534B1 (en) * | 2003-09-10 | 2008-06-03 | Symantec Corporation | Configuration system and methods including configuration inheritance and revisioning |
WO2005029261A2 (en) * | 2003-09-17 | 2005-03-31 | Siemens Medical Solutions Health Services Corporation | A processing device security management and configuration system and user interface |
EP1671268A4 (de) * | 2003-09-19 | 2006-12-06 | Lattix Inc | Vorrichtung und verfahren zum verwalten des entwurfs eines softwaresystems unter verwendung einer abhängigkeitsstruktur |
US20050080811A1 (en) * | 2003-10-10 | 2005-04-14 | Cendura Corporation | Configuration management architecture |
US20050102652A1 (en) * | 2003-11-07 | 2005-05-12 | Sony Corporation | System and method for building software suite |
US7437712B1 (en) * | 2004-01-22 | 2008-10-14 | Sprint Communications Company L.P. | Software build tool with revised code version based on description of revisions and authorizing build based on change report that has been approved |
US8819072B1 (en) | 2004-02-02 | 2014-08-26 | Microsoft Corporation | Promoting data from structured data files |
DE102004005730A1 (de) * | 2004-02-05 | 2005-08-25 | Robert Bosch Gmbh | Verfahren zur Konfiguration eines Computerprogramms |
US7657866B2 (en) * | 2004-04-28 | 2010-02-02 | Openlogic, Inc. | Providing documentation for assembling, installing, and supporting of software stacks |
US7496837B1 (en) | 2004-04-29 | 2009-02-24 | Microsoft Corporation | Structural editing with schema awareness |
US8429609B2 (en) * | 2004-05-21 | 2013-04-23 | Ca, Inc. | Method and system for web-based enterprise change and configuration management reports |
US7607126B2 (en) * | 2004-05-21 | 2009-10-20 | Bea Systems, Inc. | System and method for external override of annotations |
US7281018B1 (en) | 2004-05-26 | 2007-10-09 | Microsoft Corporation | Form template data source change |
US7774620B1 (en) | 2004-05-27 | 2010-08-10 | Microsoft Corporation | Executing applications at appropriate trust levels |
US9207932B2 (en) * | 2004-05-27 | 2015-12-08 | International Business Machines Corporation | Uniform references |
US7503041B2 (en) * | 2004-07-01 | 2009-03-10 | International Business Machines Corporation | Apparatus, system, and method for delivery of software |
US7692636B2 (en) | 2004-09-30 | 2010-04-06 | Microsoft Corporation | Systems and methods for handwriting to a screen |
US8487879B2 (en) | 2004-10-29 | 2013-07-16 | Microsoft Corporation | Systems and methods for interacting with a computer through handwriting to a screen |
US20060098673A1 (en) * | 2004-11-09 | 2006-05-11 | Alcatel | Input queue packet switch architecture and queue service discipline |
US7712022B2 (en) | 2004-11-15 | 2010-05-04 | Microsoft Corporation | Mutually exclusive options in electronic forms |
US7721190B2 (en) | 2004-11-16 | 2010-05-18 | Microsoft Corporation | Methods and systems for server side form processing |
US20060130047A1 (en) * | 2004-11-30 | 2006-06-15 | Microsoft Corporation | System and apparatus for software versioning |
US7904801B2 (en) | 2004-12-15 | 2011-03-08 | Microsoft Corporation | Recursive sections in electronic forms |
US7653681B2 (en) * | 2005-01-14 | 2010-01-26 | International Business Machines Corporation | Software architecture for managing a system of heterogenous network processors and for developing portable network processor applications |
US7937651B2 (en) | 2005-01-14 | 2011-05-03 | Microsoft Corporation | Structural editing operations for network forms |
US7296197B2 (en) * | 2005-02-04 | 2007-11-13 | Microsoft Corporation | Metadata-facilitated software testing |
US7725834B2 (en) | 2005-03-04 | 2010-05-25 | Microsoft Corporation | Designer-created aspect for an electronic form template |
US8010515B2 (en) | 2005-04-15 | 2011-08-30 | Microsoft Corporation | Query to an electronic form |
US8200975B2 (en) | 2005-06-29 | 2012-06-12 | Microsoft Corporation | Digital signatures for network forms |
US20070006152A1 (en) * | 2005-06-29 | 2007-01-04 | Microsoft Corporation | Software source asset management |
DE102005032944A1 (de) * | 2005-07-14 | 2007-01-18 | Robert Bosch Gmbh | Verfahren und Softwaresystem zur Konfiguration eines modularen Systems |
US8001459B2 (en) | 2005-12-05 | 2011-08-16 | Microsoft Corporation | Enabling electronic documents for limited-capability computing devices |
US8448137B2 (en) * | 2005-12-30 | 2013-05-21 | Sap Ag | Software model integration scenarios |
US7779343B2 (en) | 2006-01-30 | 2010-08-17 | Microsoft Corporation | Opening network-enabled electronic documents |
US8468496B2 (en) * | 2006-04-07 | 2013-06-18 | Ricoh Production Print Solutions LLC | Flexible attribute management in workflow processing systems |
US9128727B2 (en) * | 2006-08-09 | 2015-09-08 | Microsoft Technology Licensing, Llc | Generation of managed assemblies for networks |
US7809703B2 (en) * | 2006-12-22 | 2010-10-05 | International Business Machines Corporation | Usage of development context in search operations |
JP2008242873A (ja) * | 2007-03-28 | 2008-10-09 | Hitachi Ltd | ソフトウェア自動構成装置及び方法 |
US8015546B2 (en) * | 2007-08-03 | 2011-09-06 | International Business Machines Corporation | Rapidly assembling and deploying selected software solutions |
US8549144B2 (en) * | 2007-08-31 | 2013-10-01 | International Business Machines Corporation | Common configuration framework for applications to configure database objects and resources |
US20090089747A1 (en) * | 2007-09-07 | 2009-04-02 | Verizon Data Services Inc. | Method and system for managing configuration information |
US8357286B1 (en) | 2007-10-29 | 2013-01-22 | Semcon Tech, Llc | Versatile workpiece refining |
US20090327301A1 (en) * | 2008-06-26 | 2009-12-31 | Microsoft Corporation | Distributed Configuration Management Using Constitutional Documents |
US7774442B2 (en) * | 2008-06-26 | 2010-08-10 | Microsoft Corporation | Distributed configuration management using loosely-coupled action-style documents |
US20100058321A1 (en) * | 2008-09-04 | 2010-03-04 | Anderson Greg L | Approach for deploying software to network devices |
US20100095348A1 (en) * | 2008-10-10 | 2010-04-15 | Ciphent, Inc. | System and method for management and translation of technical security policies and configurations |
US8776020B2 (en) * | 2008-12-11 | 2014-07-08 | Sap Ag | Software configuration control wherein containers are associated with physical storage of software application versions in a software production landscape |
US20100153919A1 (en) * | 2008-12-11 | 2010-06-17 | Wolfram Kramer | Systems and methods for tracking software stands in a software production landscape |
US8285662B2 (en) * | 2009-01-29 | 2012-10-09 | International Business Machines Corporation | Framework for delta analysis during automated builds |
US8321843B2 (en) * | 2009-02-09 | 2012-11-27 | Tranxition Corporation | Automatic analysis of an application's run-time settings |
US8464242B2 (en) * | 2009-07-08 | 2013-06-11 | Tranxition Corporation | Virtualization of configuration settings |
US8499294B2 (en) * | 2009-09-30 | 2013-07-30 | Red Hat, Inc. | Persisting the changes for managed components in an application server |
US8473905B1 (en) * | 2009-09-30 | 2013-06-25 | Emc Corporation | Managing user interface characteristics in displaying data storage systems information |
CA2788990A1 (en) * | 2010-02-18 | 2011-08-25 | Sa Ignite, Inc. | Systems and methods for monitoring and enhancing software applications |
US10534624B2 (en) * | 2010-02-26 | 2020-01-14 | Red Hat, Inc. | Generating and storing translation information as package metadata |
US9152484B2 (en) | 2010-02-26 | 2015-10-06 | Red Hat, Inc. | Generating predictive diagnostics via package update manager |
US8832651B2 (en) * | 2010-03-30 | 2014-09-09 | Hewlett-Packard Development Company, L.P. | Central service provisioning system |
US9772834B2 (en) | 2010-04-27 | 2017-09-26 | Red Hat, Inc. | Exportable encoded identifications of networked machines |
US9116778B2 (en) * | 2010-04-29 | 2015-08-25 | Microsoft Technology Licensing, Llc | Remotable project |
US8566792B2 (en) * | 2010-05-07 | 2013-10-22 | Salesforce, Inc. | Validating visual components |
US8762931B2 (en) * | 2010-05-26 | 2014-06-24 | Red Hat, Inc. | Generating an encoded package profile |
US8498982B1 (en) | 2010-07-07 | 2013-07-30 | Openlogic, Inc. | Noise reduction for content matching analysis results for protectable content |
US9021392B2 (en) * | 2010-07-26 | 2015-04-28 | Sap Se | Managing extension projects with repository based tagging |
US8863097B2 (en) * | 2010-12-29 | 2014-10-14 | Sap Ag | Providing code list extensibility |
CN102799462B (zh) * | 2011-05-27 | 2015-07-29 | 深圳市金蝶中间件有限公司 | 基于Eclipse平台的脚本引擎装置及Eclipse平台的配置方法 |
US9355193B2 (en) | 2012-11-06 | 2016-05-31 | Rockwell Automation Technologies, Inc. | Object design data model |
US9563861B2 (en) | 2012-11-06 | 2017-02-07 | Rockwell Automation Technologies, Inc. | Integration of workflow and library modules |
US8898634B2 (en) * | 2012-11-06 | 2014-11-25 | Rockwell Automation Technologies, Inc. | Customized object design for industrial automation application |
US9031975B2 (en) | 2012-11-06 | 2015-05-12 | Rockwell Automation Technologies, Inc. | Content management |
US10191733B2 (en) * | 2013-06-25 | 2019-01-29 | Sap Se | Software change process orchestration in a runtime environment |
US10110594B2 (en) | 2013-09-04 | 2018-10-23 | Hewlett-Packard Development Company, L.P. | Header section download of package |
US10042742B2 (en) * | 2013-11-21 | 2018-08-07 | International Business Machines Corporation | Selective object testing in a client-server environment |
JP6192570B2 (ja) * | 2014-02-27 | 2017-09-06 | 京セラドキュメントソリューションズ株式会社 | アプリケーション開発支援プログラム及びアプリケーション開発支援システム |
US10140120B2 (en) * | 2015-06-15 | 2018-11-27 | International Business Machines Corporation | Context-specific view of a hierarchical data structure |
CN106815055B (zh) * | 2017-02-15 | 2020-06-23 | 深圳创维-Rgb电子有限公司 | 移动应用动态布局的方法与系统 |
CN107608710B (zh) * | 2017-08-31 | 2021-08-31 | 华为技术有限公司 | 基于Jenkins工具的软件项目构建任务配置方法及装置 |
US10824420B2 (en) * | 2019-02-20 | 2020-11-03 | Microsoft Technology Licensing, Llc | Caching build graphs |
CN113703827B (zh) * | 2021-07-31 | 2024-02-09 | 浪潮电子信息产业股份有限公司 | 一种依赖包管理方法、系统、设备及计算机可读存储介质 |
CN116450534B (zh) * | 2023-06-19 | 2023-08-22 | 建信金融科技有限责任公司 | 移动端应用程序的生成方法、装置、设备及介质 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6226792B1 (en) * | 1998-10-14 | 2001-05-01 | Unisys Corporation | Object management system supporting the use of application domain knowledge mapped to technology domain knowledge |
US6295531B1 (en) * | 1998-11-09 | 2001-09-25 | Unisys Corporation | Cool ICE data wizard |
US6256773B1 (en) * | 1999-08-31 | 2001-07-03 | Accenture Llp | System, method and article of manufacture for configuration management in a development architecture framework |
-
2001
- 2001-05-04 DE DE10121790A patent/DE10121790B4/de not_active Expired - Fee Related
- 2001-05-31 US US09/871,502 patent/US7194730B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
US7194730B2 (en) | 2007-03-20 |
DE10121790B4 (de) | 2006-11-23 |
US20020040469A1 (en) | 2002-04-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10121790B4 (de) | Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem | |
DE69937332T2 (de) | Verfahren und Gerät zur Software-Entwicklung | |
DE69838139T2 (de) | Verfahren und system zur schaffung von datenbankanwendungssoftware,die minimales programmieren benötigen | |
DE60311805T2 (de) | Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Merkmalen von Architekturen | |
US8112742B2 (en) | Method and system for debugging data integration applications with reusable synthetic data values | |
EP3049920A1 (de) | Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung | |
DE19705955A1 (de) | Verfahren zum Generieren einer Implementierung eines Workflow-Prozessmodells in einer Objektumgebung | |
EP2628071A1 (de) | Verfahren und system zur entwicklung von datenintegrationsanwendungen mit wiederverwendbaren semantischen typen zur darstellung und verarbeitung von anwendungsdaten | |
DE202014010938U1 (de) | Omega-Namen: Namenserzeugung und -ableitung | |
DE102006046310A1 (de) | System zur Erzeugung und zum Betrieb einer Softwareapplikation für medizinische Bildgebung | |
US20120124550A1 (en) | Facilitating database application code translation from a first application language to a second application language | |
DE69907714T2 (de) | Komponentbasiertes quellcodegeneratorverfahren | |
Schwägerl | Version control and product lines in model-driven software engineering | |
WO2007025557A1 (de) | Migration und transformation von datenstrukturen | |
DE102021116315A1 (de) | Verfahren zum Zusammenführen von Architekturinformationen | |
DE102016005519B4 (de) | Verfahren zur Erstellung eines Metadaten-Datenmodells für eine BI-Infrastruktur | |
EP1202166B1 (de) | System zur Verifikation von Software-Anwendungsmodellen in Ketten von Software-Entwurfswerkzeugen | |
EP1490762B1 (de) | Verfahren, software-produkt und system zur universellen computergestuetzten informationsverarbeitung | |
EP1343078B1 (de) | System zur Modellierung und Generierung von Softwaregenerierungssystemen | |
EP1044409B1 (de) | Programmablaufverfahren und verfahren zur erweiterung eines programmkomponentensystems | |
EP3940553A1 (de) | Verfahren zum bereitstellen sicherheitsrelevanter daten mittels eines serversystems, serversystem und computerprogrammprodukt | |
DE102004040010A1 (de) | Ablaufumgebung für graphische Programmierung von wiederverwendbaren Trägerdiensten und Komponenten | |
DE102010001765A1 (de) | Verfahren und System zum Überprüfen einer Regeltreue einer Implementierung einer Software-Architektur | |
EP1388785A1 (de) | Verfahren und Vorrichtung zur Transformation von Software- und Hardwaremodellen | |
DE19807191A1 (de) | Programmablaufverfahren und Verfahren zur Erweiterung eines Programmkomponentensystems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |