-
GEBIET DER
ERFINDUNG
-
Die
vorliegende Erfindung bezieht sich allgemein auf ein Verfahren und
ein System zum Integrieren von verschiedenen Softwaretools für einen
Entwicklungs-Rahmen und insbesondere auf ein Verfahren und ein System
für eine
Tool-Integration für
Dritte für
eine Entwicklungsumgebung, wobei das Verfahren und das System den
gesamten Software-Lebenszyklus unterstützen, einschließlich Geschäftsprozess-Modellierung,
Objekt-Modellierung,
Komponenten-Verwaltung, Anwendungsentwicklung und -einsatz und Altintegrierung.
-
HINTERGRUND
DER ERFINDUNG
-
Windows
NT durchdringt zunehmend Altumgebungen, wodurch ein Bedarf erzeugt
wird, bestehende Anwendungen in neue Anwendungen auf der Basis von
Windows NT zu integrieren. Dementsprechend nimmt die Komplexität der Entwicklung
und Verwaltung von Anwendungen in heterogenen Umgebungen stark zu.
Außerdem
bewegt sich die Softwaresystem-Entwicklung weg von einer anwendungszentrierten
Sicht hin zu einer, die sich auf Geschäftsprozesse konzentriert. Der
Ausgangspunkt ist ein Satz von Geschäftsprozess-Modellen und die
Anwendungen werden dann aus den Modellen entwickelt. Dies resultiert
in dem Bedarf an einem umfassenden Satz von Tools, um bestehende
Altsysteme in Geschäfts-Modelle
zu abstrahieren und dann Anwendungen aus diesen Modellen zu erzeugen.
-
Geschäftsprozess-Modelle
bestimmen Geschäftsprozesse;
und Geschäftsprozesse
beschreiben Aktivitäten,
die innerhalb einer Organisation ausgeführt werden müssen. Beispiele
für derartige
Aktivitäten
können
die Verarbeitung von Bestellungen, die Lohnlistenverarbeitung oder
die Verarbeitung von Versicherungsansprüchen einschließen. Die
eigentlichen Software-Anwendungen
können
aus Geschäftsprozessen
abgeleitet werden. Diese Software-Anwendungen können in Verbindung mit anderen Softwaresystemen
und einem Team von Menschen einen bestimmten Geschäftsprozess
ausführen.
-
Die
Erstellung von Geschäftsanwendungen resultiert
in dem Bedarf an einer umfassenden Umgebung, die den gesamten Entwicklungsprozess
der Geschäftsanwendung
unterstützt.
Der Prozess kann mit dem Aufbau von Geschäftsmodellen beginnen und zu
der Darstellung der Geschäftsmodelle
als eine Sammlung von Objektmodellen weiterführen. Objektmodelle stellen
ein Mittel zum Beschreiben von Wechselwirkungen zwischen Funktionen
dar, die für
eine Automatisierung in einem Computersystem geeignet sind und die
gemeinsam die erforderliche Funktionalität darstellen, um ein Geschäftsmodell
zu implementieren.
-
Der
nächste
Schritt kann die Erstellung eines Quellcodes für die in dem Objekt-Modell
(Geschäfts-Logik)
bestimmten Funktionen einschließen; das
heißt,
die Erstellung von Verfahren für
die Geschäftsprozesse,
die Details davon darstellen, wie das Geschäft abläuft. Wenn zum Beispiel der
Geschäftsprozess
die Handhabung von Bestellungen ist, dann kann eine Funktion in
dem Geschäftsprozess
eine Genehmigung sein. Der Genehmigungsprozess kann als ein Teil
eines Objektmodells dargestellt werden. Ferner kann ein Detail dessen,
wie diese Funktion ausgeführt
wird, darin bestehen, dass Bestellungen über $1.000 von einem Manager
genehmigt werden müssen.
Ein Computer-Quellcode kann entwickelt werden, um die Schritte zu
implementieren, die erforderlich sind, damit Bestellungen über $1.000
zwecks Genehmigung zu einem Manager geroutet werden. Der Entwicklungsprozess
kann dann zum Aufbauen und Verpacken von Komponenten (wieder verwendbaren
Codestücken),
zum Aufbauen von Anwendungen aus den Komponenten und zum Installieren
der neuen Anwendungen und Komponenten in die passenden Umgebungen
fortschreiten.
-
Der
Entwicklungsprozess resultiert weiterhin in einem Bedarf, Altsysteme
zu erkennen, das heißt bestehende
Anwendungen, Komponenten, Geschäftsprozesse
oder andere Altsysteme, die erkannt und in neue Geschäftsmodelle
integriert werden müssen,
die wiederum neue Geschäftsanwendungen
erzeugen können.
Die Integration von bestehenden Altelementen in neue Anwendungen
trägt zum Schutz
von Investitionen bei, die bei der Erstellung der Altsysteme vorgenommen
wurden. Ein Tool zur Erkennung von Altsystemen ist ein Beispiel
für die Softwaretools,
die durch das Verfahren und das System der vorliegenden Erfindung
in andere Tools integriert werden können.
-
Die
heutige Technologie deckt den Bedarf an einer Integration verschiedener
Tools zur Verwendung in einer einzigen Umgebung, die den Prozess von
Anfang bis Ende unterstützen
würde,
nicht ausreichend. Ein weiterer Nachteil der bestehenden Technologie
ist die Unfähigkeit,
vorhandene Altelemente zu erkennen und zu rekonstruieren und sie
in neue Anwendungen einzubauen. Obwohl Tools vorhanden sind, die
eine Umwandlung von einigen Altelementen in bestimmte Arten von
Objektmodellen gestatten, verwenden diese Tools die Modelle nicht,
um Geschäftsanwendungen
zu erzeugen. Außerdem sind
diese Tools in ihrer Fähigkeit
eingeschränkt,
ein Objektmodell aus einer bestehenden Software-Implementierung zu abstrahieren, und
sind ferner nicht generalisiert, was bedeutet, dass sie ausschließlich bestimmte
Arten von Altelementen in Objektmodelle umwandeln können.
-
Ein
weiterer Nachteil der heutigen Technologie besteht darin, dass Tools
normalerweise untrennbar mit spezifischer Middleware verbunden sind,
die bei der Erstellung von Geschäftsanwendungen
die Paarung eines spezifischen Tools mit einer spezifischen Middleware
erfordert. Als ein Beispiel für
diesen Nachteil könnte
man, wenn ein Tool verwendet wird, um das Geschäftsprozess-Modell zu entwickeln,
dazu gezwungen sein, dasselbe Tool zur Erzeugung des Anwendungs-Quellcodes
für das
Modell auszuwählen.
Das Fehlen von Tool-Unabhängigkeit
besteht hauptsächlich
aufgrund der Unfähigkeit, Informationen
zwischen Tools auszutauschen.
-
Biggerstaff,
T. J., "Design recovery
for maintenance and reuse",
Computer, US, IEEE Computer Society, Long Beach, CA, US, Ausg. 22,
Nr. 7, 1. Juli 1989 (1989-07-01), Seiten 36-49, beschreibt ein Verfahren
und ein System, das sich mit Softwaretool-Integration befasst. Hierfür schlägt der Autor
des obigen Artikels die Verwendung einer Wiederherstellungs-Informationsbank
(Domänen-Modell)
vor.
-
US-A-5
587 935 beschreibt ein integriertes Software-Entwicklungssystem zur Erstellung eines Prozess-Modells
und zum Schreiben von Software auf der Basis des Prozess-Modells.
Das bekannte System schließt
ein Unterstützungs-Teilsystem
für Gruppen-Entscheidung
zum Erstellen und Anfordern eines Prozess-Protokolls gemäß einem Modell, ein Anwendungsentwicklungs-Teilsystem zum Schreiben
von Software auf der Basis der Ausgabe des Unterstützungs-Teilsystems
für Gruppen-Entscheidung und
ein Verbrückungs-Teilsystem
dazwischen ein.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Ein
System und ein Verfahren werden in einem Computersystem zum Integrieren
von Software-Entwicklungstools und Anwendungen in das Computersystem
bereitgestellt, um Unternehmens-Geschäftsprozess-Anwendungen
in einem heterogenen Entwicklungs-Rahmen aufzubauen, einzusetzen und zu
verwalten. Die Integration der Anwendungen und der Software-Entwicklungstools
wird durch Integration der Schlüsselelemente
des Computersystems erzielt, die Geschäfts-Modelle, Domänen-Modelle
und Komponenten sind. In dem Prozess der Integration wird der Ursprung
eines ersten neu entwickelten/modifizierten/bestehenden Geschäfts-Modells
auf ein erstes neu entwickeltes/modifiziertes/bestehendes Domänen-Modell zurückverfolgt
und diese Modelle werden miteinander verknüpft. Als Nächstes werden die Komponenten
eines zweiten neu entwickelten/modifizierten/bestehenden Domänen-Modells auf
einen neu entwickelten/modifizierten/bestehenden Satz von Komponenten
zurückverfolgt,
die erstellt wurden, und miteinander verknüpft. Das System beinhaltet
ferner die Rückgewinnung
von Komponenten aus einem neu entwickelten/modifizierten/bestehenden
System in einer ersten heterogenen Umgebung und diese Komponenten
werden wieder zu verwendbaren Komponenten innerhalb eines dritten
neu entwickelten/modifizierten/bestehenden Domänen-Modells aufgebaut und miteinander
verknüpft.
Der Prozess beinhaltet ferner die Wiederherstellung eines vierten
neu entwickelten/modifizierten/bestehenden Domänen-Modells aus einer zweiten
heterogenen Umgebung und seine Verknüpfung mit einem zweiten neu
entwickelten/modifizierten/bestehenden Geschäfts-Modell.
-
Es
ist eine Aufgabe dieser Erfindung, ein Verfahren und ein System
bereitzustellen, das Benutzer Geschäftsprozessanwendungen entwickeln lässt, wobei
ein derartiges Verfahren und System Altintegration und den gesamten
folgenden Software-Lebenszyklus unterstützt: (1) Geschäftsprozess-Modellierung;
(2) Objekt-Modellierung;
(3) Komponenten-Verwaltung; (4) Anwendungsentwicklung und (5) Anwendungseinsatz.
-
Eine
weitere Aufgabe der vorliegenden Erfindung ist es, ein Verfahren
und System bereitzustellen, das es einem Benutzer gestattet, Geschäftsprozessanwendungen
unter Verwendung von heterogenen Tools zu entwickeln.
-
Eine
zusätzliche
Aufgabe der vorliegenden Erfindung ist, ein Verfahren und System
bereitzustellen, das eine Vielfalt von Softwaretools integriert,
wie z.B. Geschäfts-Modellierungstools,
Komponenten-Modellierungstools, Komponenten-Verhaltenstools und
Komponenten-Verpackungstools.
-
Eine
weitere Aufgabe der vorliegenden Erfindung ist, ein Verfahren und
System bereitzustellen, das die Beschränkungen des Standes der Technik, dass
ausschließlich
die Tools von demselben Anbieter integriert werden, oder dass es
an funktionalem Anwendungsbereich zum Integrieren neu entwickelter
Tools oder an Tool-Kompatibilität
mangelt, überwindet.
-
Eine
Aufgabe der vorliegenden Erfindung ist, bestehende Softwaretools
von einer Vielfalt von Anbietern zu nehmen und auf eine Vielfalt
von Middleware abzuzielen und sie in einen kohärenten Entwicklungs-Rahmen
zu integrieren, anstatt neue Tools zu entwickeln.
-
Ein
Merkmal des Verfahrens und des Systems der vorliegenden Erfindung
ist die Fähigkeit, den
Einfluss einer Aktion von einem Tool auf andere Tools zu verfolgen,
wodurch sie kompatibel gemacht und integriert werden.
-
Ein
weiteres Merkmal des Verfahrens und des Systems der vorliegenden
Erfindung ist die Fähigkeit,
andere Tools zu aktualisieren, wenn eine Aktion von einem ersten
Tool durchgeführt
wird.
-
Noch
ein anderes Merkmal des Verfahrens und des Systems der vorliegenden
Erfindung ist die Fähigkeit,
Altprogramme zu erkennen und zu rekonstruieren.
-
Ein
Vorteil des Verfahrens und des Systems der vorliegenden Erfindung
ist die Fähigkeit,
die besten Softwaretools auf dem Markt zu integrieren, wodurch ein
zusammenwirkender Satz von Diensten in einem einheitlichen Rahmen
bereitgestellt wird. Folglich kann der Benutzer sich auf den Entwicklungsprozess
konzentrieren und wird mit der Integrierung oder Verbrückung einer
Vielfalt von Tools nicht belastet.
-
Noch
weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung
werden für
den Fachmann aus der folgenden detaillierten Beschreibung leicht
ersichtlich, in der ausschließlich
die bevorzugte Ausführungsform
der Erfindung gezeigt und beschrieben ist, und zwar einfach durch
die Darstellung der besten Art und Weise, die zum Ausführen der
Erfindung vorgesehen ist. Wie erkennbar ist, ist die Erfindung für andere
und verschiedene Ausführungsformen
geeignet, und ihre vielen Details sind für Modifikationen in verschiedenen
offensichtlichen Aspekten geeignet, von denen keine von der Erfindung abweicht.
Dementsprechend sind die Zeichnungen und die Beschreibung als erläuternd und
nicht als einschränkend
zu betrachten, und was durch die Patenturkunde geschützt werden
soll, ist in den beigefügten
Ansprüchen
dargelegt. Die vorliegende Erfindung wird deutlich, wenn sie in
Verbindung mit der folgenden Beschreibung und den beigefügten Zeichnungen
betrachtet wird, worin gleiche Zeichen gleiche Teile bezeichnen
und wobei die Zeichnungen einen Teil dieser Anmeldung bilden.
-
KURZE BESCHREIBUNG DER
ZEICHNUNGEN:
-
1 ist
ein Blockdiagramm eines Entwicklungssystems und -verfahrens aus
dem Stand der Technik.
-
2 ist
ein Blockdiagramm des Systems der vorliegenden Erfindung.
-
3A und 3B sind
logische Diagramme des Evolutions- und Entwicklungsprozesses, die von
dem Verfahren und System der vorliegenden Erfindung implementiert
werden.
-
4 ist
ein Prozess-Flussdiagramm des Verfahrens der vorliegenden Erfindung.
-
5 ist
ein Blockdiagramm, das die Beziehungen zwischen den Modulen zeigt,
die den Geschäfts-Modellierungs-Entwicklungs-Rahmen der vorliegenden
Erfindung bilden.
-
6 ist
ein Blockdiagramm des Anlagen-Modellierungs- Entwicklungs-Rahmens der vorliegenden
Erfindung.
-
7 ist
ein Blockdiagramm der Ausführungs-Zeit-Architektur
der vorliegenden Erfindung.
-
Die 8A bis 8F stellen
Bildschirme der obersten Ebene für
den Benutzer während
des Betriebs des Prozesses dar.
-
DETAILLIERTE BESCHREIBUNG
EINER AUSFÜHRUNGSFORM:
-
Bevor
mit einer Beschreibung des Systems und Verfahrens der vorliegenden
Erfindung fortgefahren wird, wird eine Zusammenfassung der hierin verwendeten
Terminologie bereitgestellt, die zum Verständnis der offenbarten Ausführungsform
hilfreich sein kann.
-
Ein
Objekt ist eine abstrakte Darstellung eines Konzeptes oder einer
Sache aus der realen Welt. Zum Beispiel kann ein Objekt verwendet
werden, um ein Kundenkonto in einer Bank-Anwendung darzustellen.
Ein Objekt weist Merkmale auf, die entweder ein Vorgang oder eine
Eigenschaft sein können.
Ein Vorgang bestimmt eine Aktion, die ein Objekt ausführen kann,
oder eine Aktion, die an dem Objekt ausgeführt werden kann. Zum Beispiel
könnte "Abhebung ausführen" als ein Vorgang
bestimmt werden, der auf ein Kundenkonto-Objekt ausgeübt wird.
Eigenschaften zeigen den Zustand eines Objekts an. Jede Eigenschaft
eines Objekts besitzt einen Wert, und es sind die Eigenschafts-Werte,
die den Zustand des Objekts bestimmen. Eine Eigenschaft kann entweder ein
Attribut oder eine Referenz sein. Ein Attribut bestimmt einen Wert,
der innerhalb des Objekts gespeichert wird. Zum Beispiel könnte "gegenwärtiger Kontostand" ein Attribut des
Kundenkonto-Objekts
sein. Der numerische Wert für
den Kontostand des Kunden würde
in dem Kundenkonto-Objekt gespeichert werden. Eine Referenz ist
eine Verknüpfung
oder ein Zeiger auf ein weiteres Objekt und bezeichnet eine Beziehung
zu diesem anderen Objekt. Eine Referenz wird typischerweise verwendet,
wenn es erwünscht ist,
Daten nicht zu duplizieren. Zum Beispiel könnte das Kundenkonto-Objekt
den Namen und die Adresse des Kunden als Attribute speichern. Wenn
jedoch der Kunde mehrere Konten eröffnet hat, dann würden der
Name und die Adresse des Kunden in mehreren Konto-Objekten erscheinen.
Deshalb ist es wünschenswert,
ein separates Kunden-Objekt zu bestimmen und den Namen und die Adresse
als Attribute des Kunden-Objekts zu platzieren. Das Kundenkonto-Objekt
würde dann
eine Referenz auf das Kunden-Objekt enthalten.
-
Ein
normales Objekt-Programm speichert Objekte in dem Speicher eines
Computersystems. Wenn das Programm beendet wird, wird der von diesen
Objekten genutzte Speicher freigegeben und von anderen Programmen
erneut verwendet, was die Objekte, die das Programm gespeichert
hat, transient macht. Eine Objekt-Datenbank speichert Objekte in einem
nicht flüchtigen
Speicher, wie z.B. eine Computerplatte. Weil die Information auf
einer Computerplatte bestehen bleibt, auch wenn der Computer ausgeschaltet
wird, bietet eine Objekt-Datenbank die Fähigkeit, Objekte beständig zu
speichern. Ein Objekt-Programm, das eine Objekt-Datenbank verwendet,
besitzt somit die Option, Objekte transient oder beständig zu
speichern.
-
Die
Bezeichnung Protokoll, wie sie hierin verwendet wird, bezieht sich
auf einen Satz von formalen Regeln, die beschreiben, wie Daten übertragen werden
sollen, insbesondere über
ein Netzwerk. Die Protokolle der unteren Ebene bestimmen die elektrischen
und physikalischen Standards, die beachtet werden sollen, die Bit-
und Byte-Anforderung und die Übertragung
und Fehlererfassung sowie die Korrektur des Bitstroms. Die Protokolle
der oberen Ebene befassen sich mit der Nachrichten-Formatierung, die die
Syntax von Nachrichten, den Anschluss-zu-Computer-Dialog, Zeichensätze, Sequenzierung
von Nachrichten usw. einschließt.
-
Die
Bezeichnung Schema, wie sie hierin verwendet wird, bezieht sich
auf die logische Beschreibung von Daten in einer Datenbank, die
die Definitionen und Beziehungen von Daten einschließt.
-
Mit
Bezug auf die Zeichnungen und insbesondere die 1 ist
ein Blockdiagramm eines Systems aus dem Stand der Technik zur Ausführung von Altprogrammen
in einer Windows NT-Umgebung gezeigt. Windows NT ist ein proprietäres Betriebssystem
der Microsoft Corporation in Redmond, WA. Eine Benutzer-Schnittstelle 20 ist
mittels eines Softwaretools 22 mit einem Repository 21 gekoppelt.
Das Tool 22 kann mittels einer Middleware 25 Zugriff
auf eine Altumgebung 24 haben und das Repository 21 kann Zugriff
auf eine Datenbank 23 haben.
-
Der
Entwickler, der das Tool 22 erstellt, prüft die Beschreibung
der Altumgebung 24, die in dem Repository 21 gespeichert
ist. Unter Verwendung der gewonnenen Informationen codiert der Entwickler
in das Tool 22 einen Satz von Aufrufen an die Middleware 25,
die die erforderliche Kommunikation mit der Altumgebung 24 erleichtern.
Während
der Betriebszeit kann das Tool 22 über die Middleware 25 Kontakt zur
Altumgebung 24 herstellen, ohne auf die Informationen zurückzugreifen,
die in dem Repository 21 gespeichert sind.
-
Mit
Bezug auf die 2 wird nun das System der vorliegenden
Erfindung in Blockdiagramm-Form dargestellt. Zum besseren Verständnis ist
das System in zwei Teilen dargestellt. Erstens gibt es einen Client 27,
der von einer gestrichelten Linie umgrenzt ist, und einen Server 28,
der ebenfalls von einer gestrichelten Linie umgrenzt ist. Der Client 27 und
der Server 28 kommunizieren über ein Netzwerk 29 miteinander.
Das Netzwerk 29 kann ein beliebiges herkömmliches
Netzwerk (z.B. TCP/IP) oder das Internet umfassen.
-
Eine
Benutzer-Schnittstelle 30, die identisch mit oder verschieden
von der in der 1 abgebildeten Benutzer-Schnittstelle 20 sein
kann, ist mit einem Arbeitsraum 31 gekoppelt und beide
sind als Teil des Clients gezeigt. Der Arbeitsraum 31 ist
eine Front-End-Komponente des Verfahrens und Systems der vorliegenden
Erfindung und ist mit dem Netzwerk 29 gekoppelt, das mit
einem Repository 32 gekoppelt ist.
-
In
der offenbarten Ausführungsform
ist das Repository 32 eine spezialisierte, erweiterbare
objektorientierte Datenbank-Anwendung,
die einem Datenbank-System einen Wert verleiht, was die kundenspezifische
Anpassung einer bestimmten Domäne (wie
z.B. die Anwendungsentwicklung) gestattet, und es kann identisch
mit dem in der 1 abgebildeten Repository 21 sein.
Das Repository 32 ist mit den Datenbanken 33, 34, 35 usw.
gekoppelt, um den Zugriff auf darin gespeicherte Modellierungs-Daten
zu ermöglichen.
-
Das
Repository 32 schließt
ferner Verfahren zum Katalogisieren, Durchblättern, Modellieren und Verwalten
von Komponenten ein, die eine Anwendung bilden. Verfahren, um diese
Dienste zu unterstützen,
sind in mehreren Patenten und Patentanmeldungen offenbart, die der
Inhaberin dieser Patentanmeldung übertragen wurden, einschließlich des U.S.
Patents 5,671,398 für
METHOD FOR COLLAPSING A VERSION TREE WHICH DEPICTS A HISTORY OF
SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE; des U.S. Patents 5,644,764
für METHOD
FOR SUPPORTING OBJECT MODELING IN A REPOSITORY; des U.S. Patents
5,581,755 für METHOD
FOR MAINTAINING A HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE;
des U.S. Patents 5,557,793 für
IN AN OBJECT ORIENTED REPOSITORY, A METHOD FOR TREATING A GROUP
OF OBJECTS AS A SINGLE OBJECT DURING EXECUTION OF AN OPERATION; des
U.S. Patents 5,889,992, für
A METHOD FOR MAPPING TYPES IN A MODEL IN A OBJECT-ORIENTED REPOSITORY
TO LANGUAGE CONSTRUCTS FOR A C BINDING FOR THE REPOSITORY; des U.S.
Patents 5,721,925, für
METHOD FOR GENERICALLY INVOKING OPERATIONS IN AN OBJECT ORIENTED
REPOSITORY; des U.S. Patents 5,848,273 für A METHOD FOR GENERATING OLE
AUTOMATION AND IDL INTERFACES FROM METADATA INFORMATION; des U.S. Patents
5,765,039 für
A METHOD FOR PROVIDING OBJECT DATABASE INDEPENDENCE IN A PROGRAM
WRITTEN USING THE C++ PROGRAMING LANGUAGE; des U. S. Patents 5,758,348,
für A METHOD
FOR GENERICALLY MANIPULATING PROPERTIES OF OBJECTS IN AN OBJECT
ORIENTED REPOSITORY; des U.S. Patents 5,701,472 für A METHOD
FOR LOCATING A VERSIONED OBJECT WITHIN A VERSION TREE DEPICTING
A HISTORY OF SYSTEM DATA AND PROCESSES FOR AN ENTERPRISE und der
schwebenden US-Anmeldung Nr. 08/934,833, eingereicht am 22. September
1997, für
TOOL-INDEPENDENT APPLICATION DEVELOPMENT; von denen jedes hierin
durch Bezugnahme eingeschlossen ist, als ob es hierin vollständig dargelegt
wäre.
-
Die
Tools 36 bis 39 (innerhalb des Clients 27) sind
mit dem Arbeitsraum 31 gekoppelt und werden zum Ausführen einer
Vielfalt von Aufgaben bereitgestellt. Zum Beispiel kann das Tool 36 ein
Visual Basic-Tool umfassen. Das Tool 36 ist als unmittelbar mit
dem Netzwerk 29 gekoppelt dargestellt, das mit dem Repository 32 verbunden
ist. Das Tool 37 kann zum Beispiel Select Component Manager
umfassen, das bei Select Software Tools, Ltd., in Gloucestershire,
GB, erhältlich
ist. Das Tool 38 kann zum Beispiel Select Enterprise umfassen,
das ebenfalls bei Select Software Tools, Ltd., erhältlich ist.
Das Tool 39 kann zum Beispiel Rational Rose umfassen, das
bei der Rational Software Corporation in Santa Clara, CA, erhältlich ist.
-
Die
Tools 37, 38 und 39 sind mit dem Repository 32 über eine
XML-Komponente 41 ("eXtended Markup
Language") verbunden,
die sich innerhalb des Clients 27 befindet. XML wird typischerweise
verwendet, um über
das Internet-Protokoll Zugriff auf Informationen zu ermöglichen,
die in Datenbanken gespeichert sind (z.B. in den Datenbanken 33, 34 und 35).
Außerdem
können
die Tools 38 und 39 mit einem weiteren XML-Tool 41 gekoppelt
sein, das sich innerhalb des Servers 28 zum Ausführen der
Server-Komponententools des Rahmens befindet, z.B. UML, RDB usw.
XML wird typischerweise für
den Nachrichtenaustausch im passenden Format verwendet.
-
Die
XML-Komponente 40 ist mit zwei Modellen innerhalb des Repository 32 verbunden.
Das erste ist ein Modell 43 einer relationalen Datenbank ("RDB") und das zweite
ist ein Unified Modeling Language ("UML")-Modell 44.
Das UML-Modell 44 basiert auf einem Satz von Analyse- und
Design-Notationen, die sich zu einem De-facto-Industriestandard für objektorientierte
Analyse und Design entwickeln. Ein weiteres exemplarisches Modell,
das SCM-Modell 46, ist ebenfalls innerhalb des Repository 32 dargestellt.
Das SCM-Modell 46 basiert auf Select Component Manager,
das ein Tool ist, welches Komponenten verwaltet.
-
Aus
dem oben Erwähnten
ist zu erkennen, dass während
der Entwicklungszeit jedes Tool innerhalb des Rahmens auf jedes
beliebige Modell zugreifen kann, einschließlich Altintegrationstools,
die die Modifikation, Aktualisierung und Verwaltung des Systems
ermöglichen.
Es ist ferner zu beachten, dass der Client und der Server heterogen
sein können,
das heißt,
sie können
vollständig
verschieden oder ohne Wechselbeziehung sein oder sie können von
unterschiedlichen Herstellern stammen.
-
Einer
der Hauptvorteile der vorliegenden Erfindung ist die Fähigkeit,
die Entwicklung von Anwendungen zu gestatten, um eine neue oder
verbesserte Funktionalität
bereitzustellen. Folglich sind das hierin offenbarte und beanspruchte
Verfahren und System von den grundlegenden Prinzipien abgeleitet,
die an dem Evolutionsprozess beteiligt sind. Evolution tritt auf,
wenn sich etwas in eine neue Richtung entwickelt. In einer technischen
Umgebung findet Evolution durch einen bewussten Prozess der Rückgewinnung
statt, das heißt,
die Erkennung und Abstraktion von bestehenden Vermögenswerten über das
Reverse Engineering. Nachdem die Vermögenswerte rückgewonnen wurden, können sie
durch Forward Engineering zu neuen Anwendungen entwickelt werden.
Der Prozess wird wiederholt, wodurch er einen Zyklus bildet, der
an jedem beliebigen Punkt zugänglich
ist.
-
Die
oben dargelegten Konzepte werden durch Bezug auf die 3A und 3B verdeutlicht. Das
Verfahren und System der vorliegenden Erfindung bestimmt fünf Schichten:
Geschäfts-Modelle, Technologie-unabhängige Vermögenswerte,
Technologie-abhängige
Vermögenswerte,
Anwendungen und Geschäfts-Artefakte.
Diese Schichten werden entlang der linken Seite der beiden 3A und 3B bestimmt.
Um den Anwendungsbereich der Bezeichnung Geschäfts- Modell zu verstehen, ist es wichtig,
die Bezeichnung Geschäfts-Domäne zu verstehen.
Eine Geschäfts-Domäne wird
definiert als eine Einheit in einer Organisation, die spezifische Aufgaben
ausführt,
damit die Organisation als Ganzes korrekt arbeiten kann. Beispiele
für Geschäfts-Domänen sind
der Vertrieb, das Personalwesen oder die Informationstechnologie-Abteilung.
Eine typische Geschäfts-Domäne umfasst
allgemein einen großen
Bereich an Funktionalitäten,
die zusammen die gesamten Funktionen einer Geschäfts-Domäne bilden. Eine klar definierte
kohärente
Beschreibung von derartigen Funktionalitäten wird als Geschäfts-Modelle bezeichnet.
Sie sind die Bausteine einer Organisation. Beispiele für Geschäfts-Modelle können die
Einstellungs-Funktion des Personalwesens, die Intranet-Verwaltungsfunktion
von IT und die Vorhersagefunktion für den Absatz sein. Ein Geschäfts-Modell
schließt
Beschreibungen der Aufgaben von Menschen, Prozesse und Prozeduren
und Geschäftsvorschriften
ein.
-
Ein
geschäftlicher
Vermögenswert
wird definiert als ein bestimmter Aspekt eines Geschäfts, wie z.B.
Workflow, Regeln, Komponenten, Transaktion, Datenbank, Menschen,
Strategie, Gesetze usw. Je nachdem, ob ein Vermögenswert unabhängig oder abhängig von
Technologie ist, werden sie als Technologieabhängige und Technologie-unabhängige Vermögenswerte
klassifiziert. Beispiele für
Technologie-unabhängige
Vermögenswerte
sind Menschen und Strategie, während
Beispiele für
Technologie-abhängige
Vermögenswerte
Datenbanken und Workflow sind.
-
Ein
Geschäfts-Artefakt
wird definiert als jede Sache, die erforderlich ist, um ein Unternehmen
zu betreiben, einschließlich
der Programme, Modelle, Geschäftsregeln,
Dokumentation, Prozeduren und Interaktionen. Artefakte werden zum
Beispiel als Teil des Anwendungsentwicklungs-Lebenszyklus erstellt.
-
Weil.
es fünf
Schichten gibt, gibt es vier Grenzen (oder Stufen) zwischen ihnen,
die die unterschiedlichen Stufen des Anwendungsentwicklungs-Prozesses
darstellen. Jede der vier Stufen (auf der rechten Seite der 3A dargestellt)
besitzt ihren eigenen Satz von Wiederherstellungs/Wiederaufbau-,
Erstellungs/Modifikations- und Abbildungs/Spezialisierungs-Tools. In den unteren Schichten
besteht der Reverse-Engineering-Prozess primär in der
Erkennung von Anwendungen, d.h. der Lokalisierung und Katalogisierung
von bestehenden Geschäfts-Artefakten. In den
mittleren Schichten besteht er primär in der Rückgewinnung (sowohl Technologie-abhängig als
auch -unabhängig) – der Abstraktion
von Vermögenswerten
in weniger spezialisierte Modelle. In den oberen Schichten besteht
er primär
im Wiederaufbau – dem
Prozess der Kombination von Informationen über Anwendungen, Prozesse und
Menschen zu Unternehmens-Modellen.
-
Ein
wichtiges Konzept ist, dass der Prozess, je weiter sich eine Anwendung
entwickeln muss, im Allgemeinen umso weiter in den Schichten nach oben
gehen muss. Zum Beispiel erfordert die bloße Rekonfigurierung oder der
Wiedereinsatz einer Anwendung sehr wenig Abstraktion. Eine ernsthaftere Adaptierung
oder Verbesserung einer Anwendung unter Verwendung derselben Umgebung
(gleiche Sprache, gleiches Betriebssystem, gleiche Datenbank usw.)
erfordert mehr Abstraktion in irgendeine Form von Technologie-abhängiger Modellierung.
Die Änderung
von Technologien oder der Anwendungs-Architektur erfordert einen
weiteren Schritt der Abstraktion – die Anwendung muss von der
alten Technologie unabhängig
gemacht werden, bevor sie zu der neuen entwickelt wird. Schließlich erfordert der
innerbetriebliche Strukturwandel eines gesamten Geschäfts-Prozesses die Abstraktion
bis hinauf zu einem Modell des bestehenden Prozesses, bevor er entwickelt
werden kann.
-
Mit
Bezug auf die 4 wird die erste der fünf Schichten,
Geschäfts-Artefakte,
durch einen Block 50 dargestellt, und die zweite Schicht,
Anwendungen, wird durch einen Block 51 dargestellt. Die erste
der vier Stufen ist die Anwendungs-Verwaltung, dargestellt durch einen
Kreis 52. Die dritte Schicht, Technologie-abhängige Vermögenswerte,
wird durch einen Block 53 dargestellt, und die zweite Stufe,
Vermögenswerte
erstellen, wird durch einen Kreis 54 dargestellt. Die vierte
Schicht, Technologie-unabhängige
Vermögenswerte,
wird durch einen Block 55 dargestellt, und die dritte Stufe,
Vermögenswerte
modellieren, wird durch einen Kreis 56 dargestellt. Die
fünfte
Schicht, Geschäfts-Modelle,
wird durch einen Block 57 dargestellt, und die vierte Stufe,
Geschäft modellieren,
wird durch einen Kreis 58 dargestellt.
-
Die
Rekonfigurierung oder der Wiedereinsatz einer Anwendung erfordert
sehr wenig Abstraktion, wie zuvor erwähnt. Dieser Zyklus des Prozesses findet
innerhalb der Anwendungs-Schicht 51, der Anwendungs-Verwaltungs-Stufe 52 und
der Geschäfts-Artefakte-Schicht 50 durch
die Verbindung über
einen Rekonfigurations/Wiedereinsatz-Weg (Block 60) statt.
Eine Adaptierung oder Verbesserung einer Anwendung, während noch
dieselbe Umgebung verwendet wird, erfordert die Verwendung der Technologie-abhängigen Vermögenswerte 53,
der Vermögenswerteerstellen-Stufe 54 und
der Schichten und Stufen darunter durch die Verbindung über einen
Adaptations-/Verbesserungs-Weg (Block 61). Wenn die Anwendung
von der alten Technologie unabhängig
gemacht werden muss, bevor sie zu der neuen weiterentwickelt wird,
dann erfordert das die Verwendung der Technologieunabhängige-Vermögenswerte-Schicht 55,
der Vermögenswertemodellieren-Stufe 56 und
der Schichten und Stufen darunter durch die Verbindung über einen
Neue-Technologie/Neue-Anwendungs-Architektur-Weg
(Block 62). Zum innerbetrieblichen Strukturwandel eines
gesamten Geschäfts-Prozesses
sind die Geschäfts-Modell-Schicht 57,
die Geschäft-modellieren-Stufe 58 und
sämtliche
Schichten und Stufen darunter erforderlich. Dieser letztere Zyklus
wird durch die Verbindung über
den Neuer-Geschäftsprozess/Neues-Geschäfts-Weg
(Block 63) vervollständigt.
-
Mit
Bezug auf die 5 sind nun die Wechselbeziehungen
der Module, die den Entwicklungs-Rahmen der vorliegenden Erfindung
bilden, in einem Blockdiagramm dargestellt. In das Repository 32 eingeschlossen
ist ein Geschäfts-Modell-Modul 66.
Wie bereits erwähnt,
kann das Modul 66 in UML mit Erweiterungen geschrieben
sein, die hiernach erweitert werden. Ferner ist dort ein Domänen-Modell-Modul 67 dargestellt,
das ebenfalls in UML geschrieben sein kann. Schließlich ist
dort ein Komponenten-Modul 68 gezeigt,
das ebenfalls in UML mit SCM-Erweiterungen geschrieben ist. Beispiele
für die
Tools 36 bis 39 (2) sind
in der 5 wie folgt dargestellt. Ein Rahmen-Verwaltungstool
für vertikale Anwendungen 70 ist
mit dem Repository 32 mittels einer Schnittstelle 71 gekoppelt.
Das Rahmen-Verwaltungstool für
vertikale Anwendungen 70 kann typischerweise Tools, wie
z.B. die SAP R/3-Anwendungsfolge, die bei der SAP AG in Walldorf,
Deutschland, erhältlich
ist, oder PeopleSoft-HRMS-Pakete umfassen, die bei PeopleSoft in
Pleasanton, CA, erhältlich
sind. Ein Geschäfts-Modellierungstool
in einem Client-PC 72 ist mit dem Repository 32 mittels einer
Schnittstelle 73 gekoppelt. Das Geschäfts-Modellierungstool 72 kann
typischerweise ein Select Enterprise umfassen, das bei Select Software
Tools, Ltd., erhältlich
ist.
-
Ein
Domänen-Modellierungstool
in der Administration 74 ist mit dem Repository 32 mittels
einer Schnittstelle 75 gekoppelt. Ein zweites Domänen-Modellierungstool
in der Administration 76 ist mit dem Repository 32 mittels
einer Schnittstelle 77 gekoppelt. Die Domänen-Modellierungstools 74 und 76 können typischerweise
jede beliebige verfügbare
Datenbank umfassen, für
die ein Domänen-Modell
in dem Repository vorhanden ist. Ein Komponenten-Erkennungstool für Altsystem 78 ist
mit dem Repository 32 mittels einer Schnittstelle 79 gekoppelt.
Ein Komponenten-Erkennungstool,
das für
Altsystem 78 nützlich
sein kann, ist bei der Inhaberin hiervon erhältlich. Altsystem 78 ist
ein Softwaretool, das Komponenten-Beschreibungen für Altanwendungen
erkennt und sie in das Repository 32 importiert. Schließlich ist ein
Komponenten-Verwaltungstool für
Altanwendungen 80 mit dem Repository 32 über eine
Schnittstelle 81 gekoppelt. Das Komponenten-Verwaltungstool
für Altanwendungen 80 kann
typischerweise Select Component Manager umfassen, das bei Select Software
Tools, Ltd., erhältlich
ist.
-
Die
Schnittstellen 71, 73, 75, 77, 79 und 81 sind
typischerweise ein XML-Tool (siehe 40 und 41, 2)
oder ein Tool-Wrapper. Ein Tool-Wrapper, der für die Verwendung mit der vorliegenden
Erfindung ausreichend ist, ist ein Verfahren und System, das die
Verwendung eines Softwaretools in heterogenen Umgebungen und von
Anwendungs-Kategorien in einem Software-Entwicklungs-Rahmen vereinfacht, der über eine
Speichervorrichtung verfügt.
Zuerst wird ein Kontext-Objekt zum Speichern sämtlicher Zwischeninformationen
erstellt, die während
der Verwendung des Tools erzeugt wurden. Als Nächstes wird die spezifische
Umgebung bestimmt, in der das Tool verwendet werden soll, und Informationen über die
Umgebung werden in dem Kontext-Objekt gespeichert. Die spezifischen
Aufgaben, die das Tool typischerweise ausführt, werden bestimmt, und es
wird in dem Rahmen nach eventuellen zuvor ausgeführten Aufgaben gesucht. Die
Ergebnisse der Suche werden in dem Kontext-Objekt gespeichert. Informationen,
die benötigt
werden, damit das Tool arbeiten kann, werden aus dem Repository
abgerufen, und die Informationen werden als Eingabe-Dateien an das
Tool geliefert. Das Tool wird mit den Eingabe-Dateien ausgeführt, und
die gewonnene Ausgabe wird als Ergebnis der Toolausführung gespeichert.
Das Kontext-Objekt
wird durch die Analyse der Ausgabe aktualisiert, die aus dem Tool
gewonnen wurde. Dann wird die analysierte Ausgabe des von dem Tool
ausgeführten
Vorgangs in dem Repository für
die Umgebung gespeichert.
-
Ein
Hauptvorteil des Verfahrens und des Systems der vorliegenden Erfindung
ist die Fähigkeit, das
Geschäfts-Modell 66 mit
dem Domänen-Modell 67 zu
verbinden oder dorthin zu verfolgen oder das Domänen-Modell 67 zu dem
Komponenten-Modul 68 zu verbinden oder dorthin zu verfolgen.
Ferner können
dieses Verfahren und dieses System das Komponenten-Modul 68 mit
dem Domänen-Modell 67 verbinden
oder dorthin verfolgen oder das Domänen-Modell 67 mit
dem Geschäfts-Modell 66 verbinden
oder dorthin verfolgen. Insbesondere bietet das Verfahren dieser
Erfindung eine Rückverfolgbarkeit der
Geschäfts-Modelle
auf die Domänen-Modelle oder
eine Rückverfolgbarkeit
der Domänen-Modelle auf
die Komponenten. In ähnlicher
Art und Weise bietet das Verfahren eine Rückverfolgbarkeit der Komponenten
auf die Domänen-Modelle
oder der Domänen-Modelle
auf die Geschäfts-Modelle.
-
Mit
Bezug auf die 6 wird der Vermögenswert-Modellierungs-Entwicklungs-Rahmen
der vorliegenden Erfindung gezeigt. Das Repository 32 hat ein
daran gekoppeltes Komponenten-Modell 84. Ein Komponenten-Generator 85 ist
ebenfalls mit dem Repository 32 gekoppelt, das ein "Leiter" des Aufbau-Prozesses
ist. Ein für
den Generator 85 passender Generator ist bei Unisys Corporation
erhältlich, der
Inhaberin hiervon. Im Wesentlichen ist der Generator 85 ein
Verfahren und ein System, das mehrere Komponenten zum Erfassen und
Berichtigen einer nicht aktuellen Komponente erstellt. Eine Komponente
wird als nicht aktuell betrachtet, wenn eine ihrer Bestandteil-Dateien
neuer als die Komponenten ist. An diesem Punkt ist ein Aufbau der
Komponente im Ablauf. Eine Komponente, die von einer anderen abhängig ist,
wird als nicht aktuell betrachtet, wenn sich die öffentlichen
Schnittstellen zu der Komponente ändern. Die Schnittstellen der
abhängigen
Komponente müssen
nicht notwendigerweise von der fraglichen Komponente verwendet werden,
um die Aufbausituation zu beeinflussen. Eine Komponente wird als
aktuell betrachtet, wenn sämtliche
Bestandteil-Dateien einen früheren
Zeitstempel als die Komponente aufweisen und keine abhängigen Komponenten
ihre Schnittstellen verändert
haben. Jede der betreffenden Komponenten wird auf eine der Situationen
reagieren, um zu bestimmen, ob ein Aufbau erfolgen sollte.
-
Der
Generator 85 kann Aktualisierungen an dem Komponenten-Modell 84 vornehmen.
Zum Beispiel kann die in der Entwicklung befindliche Anwendung bestimmte
Ergänzungen
zu oder Änderungen an
dem Modell erfordern. Ferner erstellt der Generator 85 eine
Schnittstelle zu den verschiedenen Tools. Ein Vermögenswert-Generatortool 86 ist
mit dem Komponenten-Generator 85 über eine Schnittstelle 87 verbunden.
Das Vermögenswert-Generatortool unterstützt den
Aufbau von neuen Vermögenswert-Objekten
in dem Komponenten-Modell 84 über das Repository 32.
Als Nächstes
wird ein Altkomponenten-Rückgewinnungstool 88 mit
dem Komponenten-Generator 85 über eine
weitere Schnittstelle 89 verbunden. Das Rückgewinnungstool 88 nimmt
Kontakt zu Altkomponenten auf und verbindet sie mit dem Komponenten-Modell 84.
Ein Komponenten-Erstellungstool 90 wird
mit dem Komponenten-Generator 85 über eine Schnittstelle 91 verbunden.
Das Komponenten-Erstellungstool 90 unterstützt den
Aufbau von neuen Komponenten und verbindet sie mit dem Komponenten-Modell 84.
-
An
dieser Verbindungsstelle entwickelt ein Benutzer, der über eine
GUI (d.h. Graphic User Interface, graphische Benutzer-Schnittstelle) 92 an
einer Client-Station arbeitet, eine neue Anwendung unter Verwendung
der Vermögenswerte
in der Datenbank und der Modelle in dem Repository 32.
Danach wird die neue Anwendung eingesetzt, wie durch ein rundes
Feld 93 dargestellt.
-
Mit
Bezug auf die 7 ist ein Blockdiagramm der
Ausführung-Zeit-Architektur
der vorliegenden Erfindung dargestellt. An dieser Verbindungsstelle
sind die Fakten über
eine Umgebung gesammelt und für
den Aufbau einer Anwendung verwendet worden. Beispiele für eine derartige
Anwendung sind die vertikalen Anwendungen 100, die Kunden-Anwendungen 101 oder
die Altanwendungen 102. Die Verbindungs-Protokolle 104,
die zwischen den Diensten und den Anwendungen angeordnet sind, werden
zum Austauschen von Nachrichten zwischen den Anwendungen (z.B. den
vertikalen Anwendungen 100, den Kunden-Anwendungen 101 und
den Altanwendungen 102) verwendet. Ein erstes Beispiel
für die
Protokolle 104 ist COM+ 105, das eine Weiterentwicklung
des COM-Protokolls
von der Microsoft Corporation in Redmond, WA, ist. Ein weiteres
Beispiel ist Enterprise Java Beans 106, das bei Sun Microsystems
in Mountain View, CA, erhältlich ist.
Andere ähnliche
Verbindungs-Protokolle können auf ähnliche
Art und Weise verwendet werden, wie das HTTP NG 103 oder
ein CORBA-Komponenten-Modell 107.
-
Innerhalb
des Servers befindet sich eine Vielfalt von Diensten. Zunächst gibt
es Directory Services 108, der ein interner System-Dienst
für die
Dateiverwaltung ist. Ein Directory Services-Produkt, das für die Verwendung
als Directory Services 108 geeignet ist, ist bei der Unisys
Corporation erhältlich,
die Anmelderin hiervon ist. Im Wesentlichen ist Directory Services 108 ein
Verfahren zum Steuern und Verfolgen von Client-Zugriff auf Server-Software,
die von dem System ausgeführt
wird. Das Verfahren schließt die
Initiierung eines ersten Aufrufs von einem oder mehreren Clienten
an den Server und das Instanziieren einer Server-Komponente innerhalb
einer Server-Anwendung für
jeden Client-Aufruf ein. Die Server-Komponenten instanziieren Maschinen-Komponenten,
die sich zwecks Zuweisung von Sitzungs-IDs bei einer Speicher-Vorrichtung anmelden.
Die Sitzungs-IDs werden zu den Maschinen-Komponenten zurückgeführt und
zurück
an die Server-Komponenten gegeben und eingegeben und an eine gemeinsam
verwendete permanente Ressource angehängt, wonach die Verbindung
zwischen jeder Server-Komponente und jeder Maschinen-Komponente abgebrochen
wird. Die Sitzungs-IDs werden an die jeweiligen Client-Komponenten
als Referenz zurückgegeben, wann
ein nächster
Aufruf an den Server durchgeführt werden
soll, und die Verbindung zwischen jeder Server-Komponente und jeder
Client-Komponente wird unterbrochen. Wenn ein nachfolgender Aufruf
von einem Client an den Server initiiert wird, der eine Sitzungs-ID
einschließt,
dann wird eine weitere Server-Komponente
innerhalb der Server-Anwendung instanziiert. Auf die gemeinsam verwendete
permanente Ressource wird zugegriffen und eine Anforderung für die Referenz
auf die entsprechende Maschinen-Komponente wird vorgenommen, die
Zugriff auf die Speicher-Vorrichtung ermöglicht und der Server-Komponente
gestattet, jede Arbeit durchzuführen,
die von dem Client angefordert wurde. Nach Abschluss der Arbeit,
die von jedem Client angefordert wurde, wird die Verbindung zwischen
dem Client und dem Server unterbrochen.
-
Mit
erneutem Bezug auf die Beschreibung der 7 sind Repository
Services 109 eingeschlossen. Beispiele für Letztere sind
Name Service, Composite Object Service, Version Service, Metadata Service
usw. Siehe die zuvor genannten Patente und Anmeldungen, die das
Repository 32 betreffen. Die Transaction Services 110 werden
für jede
Transaktion über
den Rahmen verwendet und können
einen Transaktions-Server wie das MTS der Microsoft Corporation
verwenden. Data-warehouse Services 111 werden zum Speichern
von Daten verwendet, auf die durch das Verfahren der vorliegenden
Erfindung zugegriffen werden kann. Es ist zu beachten, dass ein Altsystem 112 mit
den Protokollen 104 über
die Transaction Services 110 oder die Data-warehouse Services 111 verbunden
ist.
-
Zusätzlich zu
den Obigen sind die Web Services 113 und die System Management
Services 114 mit den Protokollen 104 für beliebige
Dienste über das
Internet verbunden und können
den Internet Information Server verwenden. Schließlich ist
ein so genanntes Front Office 115 mit den Protokollen 104 verbunden,
um die Benutzer-Bildschirme und die Toolverwaltung zu handhaben.
-
Mit
Bezug auf die 8A bis 8F ist
eine Reihe von Fenstern der obersten Ebene für den Arbeitsraum, wie er von
einem Benutzer gesehen wird, für
den Tool-Zeit-Prozess dargestellt. Die 8A stellt
das Basis-Fenster dar, das nach der System-Initialisierung erscheint. Die 8B stellt
das Einlog-Fenster dar, in dem ein Benutzer eine LogIn-ID und ein
Kennwort eingibt, um Zugriff auf den Rahmen und das Repository zu
erlangen. Die 8C stellt das Fenster für die Geschäfts-Modellierung
dar, das erscheint, wenn der Benutzer die Business Modeling-Schaltfläche 120 (8B)
anklickt. Die 8D stellt das Fenster für Komponenten
dar, das erscheint, wenn der Benutzer die Component Modeling-Schaltfläche 122 (8B)
anklickt. Die 8E stellt das Fenster für das Komponenten-Modell-Verhalten
dar, das erscheint, wenn ein Benutzer die Behavior-Schaltfläche 124 (8D)
anklickt. Die 8F stellt das Aufbau-Fenster
dar, das erscheint, wenn ein Benutzer die Reconstruct-Schaltfläche 126 (8D)
anklickt.
-
Die
Verfahren und die Vorrichtung der vorliegenden Erfindung oder bestimmte
Aspekte oder Teile davon können
die Form von Programm-Code (d.h. Anweisungen) annehmen, der auf
greifbaren Medien ausgeführt
ist, wie z.B. Floppy-Disketten, CD-ROMs, Festplatten oder einem
beliebigen anderen maschinenlesbaren Speicher-Medium, worin, wenn
der Programm-Code in eine Maschine, wie z.B. einen Computer, geladen
und von dieser ausgeführt
wird, die Maschine zu einer Vorrichtung zur Ausübung der Erfindung wird. Die
Verfahren und die Vorrichtung der vorliegenden Erfindung können ferner
in Form von Programm-Code ausgeführt
werden, der über
ein beliebiges Übertragungsmedium übertragen
wird, wie z.B. über
eine elektrische Verdrahtung oder Verkabelung, über Glasfaseroptik oder über eine
beliebige andere Form von Übertragung,
worin, wenn der Programm-Code in einer Maschine, wie z.B. einem
Computer, empfangen und geladen und von dieser ausgeführt wird,
die Maschine zu einer Vorrichtung zur Ausübung der Erfindung wird. Bei
der Implementierung auf einem Allzweck-Prozessor wird der Programm-Code
mit dem Prozessor verbunden, um eine einzigartige Vorrichtung bereitzustellen,
die analog zu spezifischen Logikschaltungen arbeitet.
-
An
Stellen, an denen in irgendeinem Anspruch erwähnte technische Merkmale von
Bezugszeichen gefolgt sind, wurden diese Bezugszeichen nur zu dem
Zweck der Verbesserung der Verständlichkeit
der Ansprüche
eingeschlossen, und dementsprechend haben solche Bezugszeichen keine
einschränkende
Wirkung auf den Schutzumfang jedes Elements, das exemplarisch durch
solche Bezugszeichen gekennzeichnet ist.