DE69929474T2

DE69929474T2 - Eine softwareentwicklungsstruktur

Info

Publication number: DE69929474T2
Application number: DE69929474T
Authority: DE
Inventors: Albert James Mission Viejo FONTANA; Jeffrey Mark Mission Viejo TADMAN; Reginald Anthony Mission Viejo PITCHFORD; George Steven Trabuco Canyon SKINNER; Peter Joseph San Clemente STEFANIAK; Eyre Christopher Coto de Caza SMITH; Srinivasa Sridhar Irvine IVENGAR; Roy Norman Lake Forest SMITH; Marshall Douglas Newport Beach TOLBERT
Original assignee: Unisys Corp
Current assignee: Unisys Corp
Priority date: 1998-09-17
Filing date: 1999-09-17
Publication date: 2006-09-07
Anticipated expiration: 2019-09-18
Also published as: EP1114368A2; EP1114368B1; WO2000020968A3; JP2002526858A; DE69929474D1; WO2000020968A2; AU1440500A

Description

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.

Claims

Ein Verfahren zum Betreiben eines Computersystems mit einem Repository-Programm (32), das darin ausgeführt wird, zum Integrieren von Software-Entwicklungstools (36, 37, 38, 39) in das System durch Speichern von Ausgaben der Tools (36, 37, 38, 39) in das Repository (32) als Modelle, wobei die Modelle Domänen-Modelle und Geschäfts-Modelle einschließen, wobei ein Geschäfts-Modell eine deutlich bestimmte kohärente Beschreibung der Funktionalitäten in der Geschäfts-Domäne ist, wobei das System für den Aufbau, den Einsatz und die Aufrechterhaltung von Anwendungen in einem heterogenen Entwicklungs-Rahmen (5) verwendet wird, wobei das Verfahren die folgenden Schritte einschließt: a. Verfolgung des Ursprungs von einem ersten neu entwickelten Geschäfts-Modell zu einem ersten neu entwickelten Domänen-Modell (66 bis 67), indem Komponenten von beiden der neu entwickelten Modelle analysiert und die Modelle zusammen in dem Repository (32) verknüpft werden; b. Verfolgung der Bestandteil-Komponenten von einem zweiten neu entwickelten Domänen-Modell zu einem neu entwickelten Satz von Komponenten (67 bis 68), die in einem Prozess des Aufbaus und des Einsatzes neuer Anwendungen geschaffen wurden, und Verknüpfung von beiden von ihnen zusammen in dem Repository (32), damit Teile des ersten neu entwickelten Geschäfts-Modells in einzelne Komponenten für eine weitere Verfeinerung heraus gebrochen werden; c. Wiederherstellung von Bestandteil-Komponenten (68 bis 67) eines Programms aus einem bestehenden System in einer ersten heterogenen Umgebung und Wiederaufbau der Bestandteil-Komponenten in verwendbare Komponenten innerhalb eines dritten neu entwickelten Domänen-Modells und Verknüpfung der wiederaufgebauten Bestandteil-Komponenten und des dritten neu entwickelten Domänen-Modells zusammen in dem Repository (32); und d. Wiederherstellung eines vierten zuvor aufgebauten Domänen-Modells (67 bis 66) aus einer zweiten heterogenen Umgebung und Verknüpfung dessen mit einem zweiten neu ent wickelten Geschäfts-Modell in dem Repository (32) durch das Abbilden von Domänen-Modellen in Geschäfts-Modelle.
Das Verfahren gemäß Anspruch 1, das zu der Zeit der Ausführung ferner den Schritt des Betreibens eines Software-Entwicklungstools (74) zum Entwickeln von Anwendungen für eine spezifische Aufgabe in dem Rahmen durch ein zweites Software-Entwicklungstool (76) umfasst, das zum Entwickeln von Anwendungen für eine zweite Aufgabe durch Beziehungen zwischen Objekten verwendet wird, die innerhalb des Repositorys (32) erzeugt wurden.
Das Verfahren gemäß Anspruch 1, das ferner den Schritt der Verfolgung des Ursprungs von einem ersten modifizierten Geschäfts-Modell zu einem vierten neu entwickelten Domänen-Modell (66 bis 67) und der Verknüpfung des modifizierten Geschäfts-Modells mit dem vierten neu entwickelten Domänen-Modell in dem Repository (32) umfasst.
Das Verfahren gemäß Anspruch 1, das ferner den Schritt der Verfolgung des Ursprungs von einem dritten neu entwickelten Geschäfts-Modell zu einem zweiten bestehenden Domänen-Modell (66 bis 67) und der Verknüpfung des dritten neu entwickelten Geschäfts-Modells mit dem zweiten bestehenden Domänen-Modell in dem Repository (32) umfasst.
Das Verfahren gemäß Anspruch 1, das ferner den Schritt der Verfolgung des Ursprungs von einem zweiten modifizierten Geschäfts-Modell zu einem dritten bestehenden Domänen-Modell (66 bis 67) und der Verknüpfung des zweiten modifizierten Geschäfts-Modells mit dem dritten bestehenden Domänen-Modell in dem Repository (32) umfasst.
Ein computerlesbares Medium, auf dem ein Computerprogramm verkörpert ist, wobei das Computerprogramm Code-Mittel umfasst, die derart ausgestaltet sind, um sämtliche der Schritte von einem oder mehreren der Ansprüche 1-5 auszuführen, wenn das Programm auf einer Datenverarbeitungsmaschine (30) betrieben wird.
Eine Vorrichtung (5) zum Integrieren von Software-Entwicklungstools (36, 37, 38, 39) in ein Computersystem mit einem Repository-Programm (32), das darin ausgeführt wird, durch Speichern von Ausgaben der Tools (36, 37, 38, 39) in dem Repository (32) als Modelle, wobei die Modelle Domänen-Modelle und Geschäfts-Modelle einschließen, wobei ein Geschäfts-Modell eine deutlich bestimmte kohärente Beschreibung der Funktionalitäten in der Geschäfts-Domäne ist, wobei das System für den Aufbau, den Einsatz und die Aufrechterhaltung von Anwendungen in einem heterogenen Entwicklungs-Rahmen verwendet wird, wobei der Rahmen folgendes umfasst: a. ein erstes Modul (66), das zum Darstellen von Geschäfts-Modellen angeordnet ist, die aus einem Geschäfts-Modellierungstool abgeleitet wurden; b. ein zweites Modul (67), das zum Halten von Informationsbeständen angeordnet ist; c. Mittel zum Verfolgen (66 bis 67) des Ursprungs von einem ersten neu entwickelten Geschäfts-Modell in dem ersten Modul (66) zu einem ersten neu entwickelten Domänen-Modell in dem zweiten Modul (67) und Verknüpfen des Geschäfts-Modells mit dem Domänen-Modell in dem Repository (32) durch die Analyse von Komponenten von beiden der neu entwickelten Modelle; d. ein drittes Modul (68), das eine Vielzahl von Komponenten-Schnittstellen enthält, die bei dem Aufbau von Anwendungen nützlich sind; e. Mittel zum Verfolgen von Bestandteil-Komponenten (67 bis 68) von einem zweiten neu entwickelten Domänen-Modell in dem dritten Modul zu einem neu entwickelten Satz von Komponenten, die in einem Prozess des Aufbaus und des Einsatzes neuer Anwendungen geschaffen wurden, und Verknüpfen von beiden von ihnen zusammen in dem Repository (32), damit Teile des ersten neu entwickelten Geschäfts-Modells in einzelne Komponenten für eine weitere Verfeinerung heraus gebrochen werden; f. Mittel zum Wiederherstellen von Bestandteil-Komponenten (68 bis 67) eines Programms aus einem bestehenden System in einer ersten heterogenen Umgebung und Wiederaufbau der Bestandteil-Komponenten in verwendbare Komponenten innerhalb eines dritten neu entwickelten Domänen-Modells und Verknüpfen der wiederaufgebauten Bestandteil-Komponenten und des dritten neu entwickelten Domänen-Modells zusammen in dem Repository (32); und g. Mittel zum Wiederherstellen eines vierten zuvor aufgebauten Domänen-Modells aus einer zweiten heterogenen Umgebung (67 bis 66) und Verknüpfen dessen mit einem zweiten neu entwickelten Geschäfts-Modell in dem Repository (32) durch das Abbilden von Domänen-Modellen in Geschäfts-Modelle.