DE60311805T2

DE60311805T2 - Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Merkmalen von Architekturen

Info

Publication number: DE60311805T2
Application number: DE60311805T
Authority: DE
Inventors: Frederic M. Klein; Eckehard Stolz; Dr. Ruppert Rebentisch
Original assignee: Accenture Global Services GmbH
Current assignee: Accenture Global Services GmbH
Priority date: 2003-08-28
Filing date: 2003-08-28
Publication date: 2007-11-22
Anticipated expiration: 2023-08-29
Also published as: US7664729B2; ATE354134T1; EP1510952A1; EP1510952B1; US20050138160A1; WO2005022425A1; DE60311805D1

Description

Die vorliegende Erfindung betrifft ein computerunterstütztes bzw. computerisiertes Informationssystem und ein Verfahren zum Erfassen, Zusammenstellen und/oder Visualisieren von Strukturdaten von Architekturen einer technischen Einrichtung bzw. Ausrüstung, wie beispielsweise Informationstechnologie-(IT) Architekturen.
Im allgemeinen mangelt es Organisationen an einem klaren Verständnis, wie ihre IT Architektur mit den Anforderungen des Geschäfts ausgerichtet ist. Die IT Architektur umfaßt gewöhnlich komplexe, voneinander abhängige Strukturen, die in einem unaufhörlichen Zustand einer Veränderung sind, welcher nicht leicht analysiert und/oder modifiziert werden kann. Insbesondere ist eine gewisse gewünschte Funktionalität mehrfach implementiert, sind andere Funktionen nicht implementiert. Oftmals gibt es ein beträchtliches Mißverständnis über das, was implementiert wurde und wie. Demgemäß ist es häufig nicht möglich, die Wechselbeziehungen zwischen mehreren Einheiten rasch zu verstehen, die Daten zu analysieren, die mit diesen Wechselbeziehungen assoziiert bzw. verbunden sind, und insbesondere die korrekten Entscheidungen basierend auf dieser Analyse abzuleiten.
Die Verfügbarkeit von genauen Architektur- und Anwendungsdaten quer über die gesamte Organisation ist beschränkt. Vieles der Information, die Architekturstrukturen betrifft, ist über einen weiten Bereich der Geschäftseinheiten verteilt und existiert häufig nur in den Köpfen einer großen Gruppe von Entwicklern bzw. Designern. Genaue Anwendungs details sind nur von den einzelnen Personen mit Betriebsverantwortlichkeit dafür verfügbar, d.h. die Daten sind nur für beschränkte Bereiche für sich gesehen verfügbar, ohne mit anderen Bereichen in Wechselbeziehung zu sein, so daß ein genereller Überblick der Struktur, der funktionelle Beziehungen beinhaltet, häufig nicht verfügbar ist. In diesen wenigen Fällen, wo strukturelle Überblicke verfügbar sind, sind sie gewöhnlich überholt, sobald sie gedruckt sind, aufgrund der raschen kombinierten Rate bzw. Geschwindigkeit einer Veränderung in den implementierten Anwendungen, organisatorischen Strukturen und gelieferten Geschäftsfunktionalität.
Außerdem ist die Fähigkeit, Änderungsprogramme in komplexen Architekturen wirksam zu planen und auszuführen, häufig durch die Kapazität beschränkt, adäquat alternative Ansätze bzw. Zugänge zu entwickeln und zu analysieren, um die gewünschten Ziele zu erreichen. Das Problem besteht selten im Darstellen des Endziels, aber im Ermangeln der Mittel, um klar die einzelnen Übergangsschritte, und die damit verbundenen Auswirkungen und Kosten entlang des Wegs zu kommunizieren. Gemeinsam damit sind die wahren Kosten, die mit einem Ändern des Wegs assoziiert sind, in welchem Erfordernisse erfüllt werden, selbst wenn die korrekte Entscheidung erreicht wurde, häufig nicht ersichtlich, bis der Änderungsprozeß unterwegs ist, weil einige bedeutsame Abhängigkeiten untereinander von der Analyse weggelassen wurden. Dies führt häufig zu übermäßigen Kosten, schlecht getimten Strategien und verschwenderischen Investitionen.
US-A-6 118 936 offenbart ein System zum Managen bzw. Handhaben von Information im bezug auf ein signalisierendes Netzwerk. Das signalisierende Netzwerk beinhaltet mehrere Netzwerkelemente, die mehrere Netzwerkereignisse generieren bzw. erzeugen. Das System umfaßt ein Netzwerkereignis empfangende Mittel, die an die Netzwerkelemente gekoppelt sind, um Netzwerkereignisse zu empfangen, beinhaltend Topologieinformation, ein Netzwerkereignis standardisierende Mittel, die auf Ereignisse reagieren, ein Netzwerkereignis korrelierende Mittel, die auf das Standardformereignis reagieren, um die Standardformereignisse zu korrelieren, ein Netzwerkinstandhaltungs-Aufstellungssystem, wodurch die ein Netzwerkereignis korrelierenden Mittel Netzwerkereignisse mit der Netzwerkinstandhaltungs-Aufstellungsinformation korrelieren, Anzeigemittel zum Anzeigen von korrelierten Standardformereignissen, Mittel, die auf die Netzwerktopologie-Datenbank reagieren bzw. antworten, um Standardformereignisse zu erzeugen, und Mittel, die die Standardformereignisse an die ein Netzwerkereignis korrelierenden Mittel koppeln.
WO 00 146618 A offenbart ein Workflow- bzw. Arbeitsablaufsystem, das Arbeitsprozesse automatisiert. Das Arbeitsablaufsystem verwendet eine offene Architektur, um zahlreiche Plattformen zu unterstützen, und beinhaltet eine Anwendung programmierende Interfaces, die Anwendungen ermöglichen, mit einer Workflow- bzw. Arbeitsablaufmaschine zu kommunizieren. Das Arbeitsablaufsystem unterstützt Datenbanken eines Relational Database Management System bzw. eines relationalen Datenbanken-Management-Systems und erlaubt ein Routen jeder Art von Arbeit. Außerdem ist seine flexible Architektur ausgelegt bzw. ausgebildet, um Änderungen an einem Arbeitsablauf dynamisch zu erleichtern und um eine Integration mit einer existierenden Infrastruktur zu unterstützen. Adapter sind bereitgestellt, die ein fixiertes Interface bzw. eine festgelegte Schnittstelle aufweisen, um Entwicklern zu ermöglichen, Klienten von variierenden Arten und Größe anzufügen, und um Entwicklern zu ermöglichen, Anwendungselemente zu mischen und abzustimmen, um ihrer Anwendung besser zu dienen.
Demgemäß ist es ein Ziel bzw. Gegenstand der vorliegenden Erfindung, eine Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Daten von Architekturen von technischer Einrichtung, wie Informationstechnologie-(IT) Architekturen, bereitzustellen, welche eine systematische Analyse und leichte Visualisierung der erhaltenen Information erlauben.
Dieses Ziel wird gemäß der Erfindung durch die Merkmale der unabhängigen Ansprüche gelöst. Bevorzugte Ausführungsformen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Gemäß der Erfindung wird ein computerunterstütztes bzw. computerisiertes Informationssystem zum Erfassen, Zusammenstellen und Visualisieren eines Daten Modells von Architekturen einer technischen Einrichtung bzw. Ausrüstung, wie Informationstechnologie-Architekturen, bereitgestellt, umfassend: wenigstens ein abstraktes Daten Modell; eine graphische Benutzer-Interface-Erzeugungsmaschine; eine Visualisierungsmaschine; und eine Szenario-Managementmaschine, die adaptiert ist, Änderungen in den Architekturen zu simulieren, zu visualisieren und auszuwerten bzw. zu evaluieren; wenigstens eine Datenaufnahmemaschine zum Aufnehmen bzw. Erfassen und Zusammenstellen bzw. Aggregieren von Daten entsprechend einem strukturierten, hierarchischen Modell, welches adaptiert ist, um eine strukturierte, hierarchische Ansicht einer Modellstruktur zur Verfügung zu stellen und um den Grundrahmen für eine Analyse und Visua lisierung aufzubauen, wobei das Modell entweder ein standardisiertes Modell oder ein kundenspezifisches Modell ist; eine Anzeigemaschine zum Generieren bzw. Erzeugen einer Mehrzahl von unterschiedlichen Anzeigen bzw. Darstellungen der erfaßten Daten gemäß dem strukturieren, hierarchischen Modell; wobei das System adaptiert ist, um jede Art von Architektur generisch zu speichern und um Beziehungsdaten zwischen Modellen zu speichern und zu analysieren; wobei das strukturierte, hierarchische Modell Tabellen umfaßt, welche entweder stark oder locker vernetzt bzw. verbunden sind, wobei starke Verbindungen Row IDs bzw. Reihen IDs benutzen, und welche adaptiert sind, für jede Aufzeichnung zur Verfügung zu stehen, daß eine Fremdschlüsselbeziehung zu einem primären bzw. Primärschlüssel einer Aufzeichnung in einer anderen Tabelle besitzen muß, und wobei lose Verbindungen von einer einzigartigen ID einer Reihe Gebrauch machen, und welche adaptiert sind, um einen Aufbau einer Fremdschlüsselbeziehung zu einer anderen Tabelle zur Verfügung zu stellen, so daß die Modelle und ihre Komponenten stark miteinander mittels wenigstens einer starken Verbindung gekoppelt sind und die Beziehungen zwischen Modellen locker mittels einer oder mehreren lockeren Verbindung(en), die adaptiert ist bzw. sind, um zu erlauben, daß die Endpunkte der entsprechenden Beziehung(en) innerhalb eines Modells bewegbar oder entfernbar sind, ohne die Beziehung zu zwingen, ebenfalls entfernt zu werden, wobei die generische Darstellung eines Modells durch starke Verbindungen zwischen Kernmodelltabellen und graphischen Repräsentationstabellen bzw. Tabellen einer graphischen Darstellung dargestellt ist.
Demgemäß erlaubt das strukturierte, hierarchische Modell eine Visualisierung von zahlreichen Aspekten der gesamten komplexen Struktur, wobei die gegenseitigen Abhängigkeiten in Betracht gezogen werden, die zwischen den verschiedenen graphischen Modellen existieren bzw. vorhanden sind.
Außerdem kann IT Managern prägnant gefilterte und gepackte Information basierend auf Betriebsdaten, welche basierend auf dem strukturierten, hierarchischen Modell erfaßt wurden, insbesondere zusammen mit der erforderlichen Information betreffend die Beziehung zwischen den spezifischen Daten (beispielsweise, welche Geschäftsfunktionen und Aktivitäten erfüllt sind bzw. werden, welche nicht erfüllt sind, bei welchen Kosten, durch welche Geschäftseinheit, unter Verwendung welcher Anwendungen, welche Daten zwischen Anwendungen bzw. Applikationen ausgetauscht sind usw.) in einer bedeutungsvollen, leicht verständlichen Struktur oder Anzeige präsentiert werden. Was-Wenn- bzw. What-if-Analyse und -Bewertung von zahlreichen Implementierungsszenarien (beispielsweise wie sich variable Kosten über die Zeit unter unterschiedlichen Architekturstrukturen ändern) kann somit vorzugsweise durchgeführt werden, um eine systematische Analyse von existierenden und künftigen Architekturen zu erlauben und um IT Managern Gewähr zu bieten, geeignete, auf Wert basierende und strategische Entscheidungen zu treffen.
Außerdem liefern, um eine Entscheidung über Änderungen an der existierenden Architektur zu erleichtern und um eine Entscheidung zu erleichtern, die durch das verantwortliche oder oberste Firmenmanagement zu treffen ist, die Architekturszenarien oder Pläne bzw. Entwürfe gemäß einer bevorzugten Ausführungsform der Erfindung einen maximalen Informationswert möglicherweise in einer einzigen Ansicht oder in wenigen Ansichten der zugrunde liegenden Architektur daten. Eine graphische Darstellung dieser Information maximiert eine Informationsdichte und liefert Entscheidungsträgern und dem obersten bzw. Topmanagement die Information, die benötigt wird, um ihr Geschäft in einer leicht verständlichen und leicht kommunizierten Art durchzuführen.
Gemäß einer bevorzugten Ausführungsform der Erfindung umfaßt die Datenerfassungsmaschine wenigstens eine Datenbank zum Speichern der Daten gemäß dem strukturierten, hierarchischen Modell.
Vorzugsweise umfaßt das strukturierte, hierarchische Modell:
eine Modell Tabelle, enthaltend ein oder mehrere Hauptattribut(e) des Modells, wie den Namen, die Art und die Version des Modells;
eine Node_Class Tabelle (Knoten_Klassen Tabelle), enthaltend Information betreffend die Arten von Knoten, welche das Modell enthält; und
eine Node Tabelle (Knoten Tabelle), enthaltend die Definition von jedem Knoten innerhalb des Modells und die entsprechende hierarchische Information des Knoten.
Weiterhin sind vorzugsweise die Modell Tabelle, die Node_Class Tabelle und die Node Tabelle miteinander mittels entsprechender starker Verbindungen verbunden, welche vorzugsweise von einer ROW id der entsprechenden Tabelle Gebrauch machen. Eine starke Verbindung gemäß der bevorzugten Ausführungsform der Erfindung ist eine Verbindung bzw. Kopplung, welche sicherstellt, daß es für jede Aufzeichnung eine Fremdschlüsselbeziehung zu dem primären bzw. Primärschlüssel einer Aufzeichnung in einer anderen Tabelle geben muß und vorzugsweise von einer Row ID Tabelle Gebrauch macht.
Am meisten bevorzugt umfaßt das strukturierte, hierarchische Modell weiterhin wenigstens eine der folgenden Tabellen:
eine Nclass_Group Tabelle, die eine Gruppe von node_classes (Knoten_Klassen) innerhalb der Node_Class Tabelle definieren, welche den Pool bzw. Vorrat von möglichen Knoten innerhalb einer Aufzeichnung bzw. Darstellung baut;
eine Domain Tabelle, die definiert, welche Datenelementarten bzw. -typen zu einem Knoten oder zu einer Aufzeichnung gehören können und insbesondere die Datenstrukturen definiert, die innerhalb des Modells gespeichert sind;
eine Attribut Tabelle, die die aktuellen Betriebsdaten enthält, die an dem Knoten oder der Aufzeichnung festgelegt sind;
eine Display Tabelle (Anzeige Tabelle), die eine graphische Repräsentation bzw. Darstellung einer spezifischen Ansicht des Modells definiert, wobei zahlreiche Ansichten auf das Modell durch ein Filtern der Anzeigeinformation erzielt werden;
eine Shape Tabelle (Form Tabelle), die einen oder mehrere graphische(n) Parameter definiert, der bzw. die erforderlich ist bzw. sind, um die Knoteninformation anzuzeigen, wobei die Knoteninformation vorzugsweise die Spezifikation einer Position, Größe und/oder Form bzw. Gestalt und Hintergrundspezifikationen beinhaltet;
eine Range Tabelle (Bereich Tabelle), die Information enthält, die steuert bzw. regelt, welche Farbe gewählte Formen haben sollten, wenn Anfrageergebnisse angezeigt sind;
eine Query Tabelle (Anfrage Tabelle), die Information enthält, die notwendig ist, um das Ergebnis einer structured query language (SQL) Statements in einem Modell anzuzeigen, wobei das SQL Statement vorzugsweise als Text gespeichert ist und vorbestimmten oder vorbestimmbaren Konventionen bzw. Vereinbarungen folgt, um sicherzustellen, daß ein Nachfrage- bzw. Anfrageergebnis exakt die Anzahl und Arten von Spalten enthält, die notwendig sind, um durch die Anwendung geeignet bearbeitet zu werden;
eine Widget Tabelle, die Information enthält, die notwendig ist, um das Layout und/oder den Inhalt der angezeigten Knoten zu steuern bzw. zu regeln; und/oder
eine Tree Tabelle (Baum Tabelle), die Information enthält, die notwendig ist, um eine Baumseite im Zusammenhang mit der Widget Tabelle zu bilden.
Gemäß einer weiteren bevorzugten Ausführungsform der Erfindung umfaßt die Datenerfassungsmaschine eine graphische Benutzer-Interface-Maschine zum Generieren bzw. Erzeugen von graphischen Benutzer-Interface-Schirmen basierend auf dem strukturierten, hierarchischen Modell, welches erlaubt, Daten einzugeben, insbesondere ein oder mehrere Datenattribut(e) und/oder Betriebsdaten, in Übereinstimmung mit dem strukturierten, hierarchischen Modell; und/oder das strukturierte, hierarchische Modell zu definieren oder zu modifizieren oder auf den Kundenbedarf zuzuschneiden bzw. an diesen anzupassen.
Vorzugsweise generiert bzw. erzeugt das graphische Benutzer-Interface die graphischen Benutzer-Interface-Schirme basierend auf der Information, die wenigstens eine der folgenden Tabellen enthält: die Display Tabelle, die Shape Tabelle, die Range Tabelle und die Query Tabelle.
Weiterhin bevorzugt umfaßt die Datenerfassungsmaschine eine Szenariomaschine zum Generieren einer visuellen Darstellung des strukturierten, hierarchischen Modells in einer Datenbank und/oder zum Generieren einer Mehrzahl von Szenarien oder fortlaufenden Änderungen des strukturierten, hierarchischen Modells.
Noch weiterhin bevorzugt umfaßt die Anzeigemaschine eine Visualisierungsmaschine zum Erzeugen einer Visualisierung des strukturierten, hierarchischen Modells, Ausführen von Benutzeranfragen, Verschmelzen der Anfrageergebnisse zur Anzeige und/oder Steuern bzw. Regeln des dynamischen Skalierens einer visuellen Ausgabe.
Am meisten bevorzugt:
liest die Visualisierungsmaschine eine oder mehrere Form(en), die an dem Modell festgelegt ist bzw. sind, von der Datenbank, vorzugsweise über eine oder mehrere Verbindung(en) und/oder ein oder mehrere erlaubte(s) Formatattribut(e) von der Attribut Tabelle, vorzugsweise über eine oder mehrere Verbindung(en); und/oder
schreibt Gestalt- bzw. Formdaten und/oder Formattributdaten zu einem Ausgabefile bzw. einer Ausgabedatei, das (die) vorzugsweise ein Ausgabe xml File ist.
Gemäß der Erfindung wird weiterhin ein computerunterstütztes bzw. computerisiertes Verfahren zum Erfassen, Zusammenstellen und Visualisieren von strukturellen Daten von Architekturen von technischer Einrichtung, wie IT Architekturen, bereitgestellt, umfassend die folgenden Schritte:
Erfassen und Zusammenstellen von Daten basierend auf einem strukturierten, hierarchischen Modell;
und
Generieren bzw. Erzeugen einer Mehrzahl von unterschiedlichen Anzeigen der erfaßten Daten in Abhängigkeit des strukturierten, hierarchischen Modells oder basierend auf Datenbeziehung(en), die durch das strukturierte, hierarchische Modell gestützt ist bzw. sind.
Gemäß einer bevorzugten Ausführungsform der Erfindung umfaßt das Verfahren einen Schritt eines Speicherns der Daten gemäß dem strukturierten, hierarchischen Modell in wenigstens einer Datenbank.
Vorzugsweise ist das strukturierte, hierarchische Modell definiert, um zu umfassen:
eine Modell Tabelle, enthaltend ein oder mehrere Hauptattribut(e) des Modells, wie den Namen, die Art und die Version des Modells;
eine Node_Class Tabelle, enthaltend Information betreffend die Arten von Knoten, welche das Modell enthält; und
eine Node Tabelle, enthaltend die Definition jedes Knotens innerhalb des Modells und die entsprechende hierarchische Information des Knotens.
Weiterhin sind vorzugsweise die Modell Tabelle, die Node_Class Tabelle und die Node Tabelle miteinander mittels entsprechender starker Verbindungen verbunden, welche vorzugsweise von einer ROW id der entsprechenden Tabelle Gebrauch machen.
Noch weiterhin vorzugsweise ist das strukturierte, hierarchische Modell definiert, um weiterhin wenigstens eine der folgenden Tabellen zu umfassen:
eine Nclass_Group Tabelle, die eine Gruppe von node_classes innerhalb einer Node_Class Tabelle definiert, welche den Pool bzw. den Vorrat von möglichen Knoten innerhalb einer Aufzeichnung bzw. Darstellung baut;
eine Domain Tabelle, welche definiert, welche Datenelementarten bzw. -typen zu einem Knoten oder einer Aufzeichnung gehören können, und insbesondere die Datenstrukturen definiert, die innerhalb des Modells gespeichert sind;
eine Attribut Tabelle, die die aktuellen Betriebsdaten enthält, die an dem Knoten oder der Aufzeichnung festgelegt sind;
eine Display Tabelle, die eine graphische Repräsentation bzw. Darstellung einer spezifischen Ansicht des Modells definiert, wobei zahlreiche Ansichten auf das Modell durch ein Filtern der Anzeigeinformation erzielt sind bzw. werden;
eine Shape Tabelle, die einen oder mehrere graphische(n) Parameter definiert, der bzw. die erforderlich ist bzw. sind, und Node- bzw. Knoteninformation anzuzeigen, wobei die Knoteninformation vorzugsweise die Spezifikation einer Position, Größe und/oder Form bzw. Gestalt und Hintergrundspezifikationen beinhaltet;
eine Range Tabelle, enthaltend Information, die steuert bzw. regelt, welche Farbe gewählte Formen haben sollten, wenn Nachfrage- bzw. Anfrageergebnisse angezeigt sind bzw. werden;
eine Query Tabelle, enthaltend Information, die notwendig ist, um das Ergebnis eines SQL Statements in einem Modell anzuzeigen, wobei das SQL Statement vorzugsweise als Text gespeichert ist und vorbestimmten oder vorbestimmbaren Konventionen bzw. Vereinbarungen folgt, um sicherzustellen, daß ein Nachfrage- bzw. Anfrageergebnis exakt die Anzahl und Arten von Spalten enthält, die notwendig sind, um durch die Anwendung geeignet bearbeitet zu werden;
eine Widget Tabelle, enthaltend die Information, die notwendig ist, um das Layout und/oder den Inhalt der angezeigten Knoten zu steuern bzw. zu regeln; und/oder
eine Tree Tabelle, enthaltend Information, die notwendig ist, um eine Baumseite im Zusammenhang mit der Widget Tabelle zu bilden.
Am meisten bevorzugt umfaßt das Verfahren weiterhin einen Schritt eines Generierens bzw. Erzeugens von graphischen Benutzer-Interface-Schirmen basierend auf dem strukturierten, hierarchischen Modell, welche erlauben,
Daten einzugeben, insbesondere ein oder mehrere Datenattribut(e) und/oder Betriebsdaten in Übereinstimmung mit dem strukturierten, hierarchischen Modell; und/oder
das strukturierte, hierarchische Modell zu definieren oder zu modifizieren oder auf den Kundenbedarf zuzuschneiden.
Gemäß einer bevorzugten Ausführungsform der Erfindung werden die graphischen Benutzer-Interface-Schirme basierend auf der Information generiert bzw. erzeugt, die wenigstens eine der folgenden Tabellen enthält: die Display Tabelle, die Shape Tabelle, die Range Tabelle und die Query Tabelle.
Vorzugsweise umfaßt das Verfahren weiterhin einen Schritt eines Generierens bzw. Erzeugen einer visuellen Darstellung des strukturierten, hierarchischen Modells in einer Datenbank und/oder eines Generierens einer Mehrzahl von Szenarien oder fortlaufenden Änderungen des strukturierten, hierarchischen Modells.
Weiterhin bevorzugt umfaßt das Verfahren weiterhin einen Schritt eines Erzeugens einer Visualisierung des strukturierten, hierarchischen Modells, Ausführens von Benutzer anfragen, Verschmelzens der Anfrageergebnisse für eine Anzeige und/oder Steuerns bzw. Regelns des dynamischen Skalierens einer visuellen Ausgabe.
Am meisten bevorzugt umfaßt das Verfahren weiterhin einen Schritt eines Lesens einer oder mehrerer Form(en), die an dem Modell von der Datenbank festgelegt ist bzw. sind, vorzugsweise über eine oder mehrere Verbindung(en); und/oder eines oder mehrerer erlaubten(r) Formatattributs(e) von der Attribut Tabelle, vorzugsweise über eine oder mehrere Verbindung(en); und/oder eines Schreibens von Formdaten und/oder Formattributdaten zu einem Ausgabefile bzw. einer Ausgabedatei, das bzw. die vorzugsweise ein Ausgabe xml File ist.
Gemäß der Erfindung wird weiterhin ein Computerprogrammprodukt bereitgestellt, insbesondere auf einem Träger und/oder auf einem computerlesbaren Speichermedium gespeichert, umfassend computerlesbare Instruktionen bzw. Anweisungen, welche, wenn sie auf einem geeigneten Computer geladen sind, ein Verfahren zum Erfassen, Zusammenstellen und Visualisieren von strukturellen Daten von Architekturen einer technischen Einrichtung, wie IT Architekturen, gemäß der Erfindung oder einer bevorzugten Ausführungsform davon durchführen.
Vorzugsweise umfaßt das strukturierte, hierarchische Modell weiterhin wenigstens eine der folgenden Tabellen:
eine Nclass_Group Tabelle, die eine Gruppe von node_classes innerhalb einer Node_Class Tabelle definiert, welche den Pool bzw. Vorrat von möglichen Knoten innerhalb einer Aufzeichnung bzw. Darstellung baut;
eine Domain Tabelle, die definiert, welche Datenelementarten bzw. -typen zu einem Knoten oder einer Aufzeichnung gehören können, und insbesondere die Datenstrukturen definiert, die innerhalb des Modells gespeichert sind;
eine Attribut Tabelle, enthaltend die aktuellen Betriebsdaten, die an dem Knoten oder der Aufzeichnung festgelegt sind;
eine Display Tabelle, die eine graphische Repräsentation bzw. Darstellung einer spezifischen Ansicht des Modells definiert, wobei zahlreiche Ansichten auf das Modell durch ein Filtern der Anzeigeinformation erzielt werden;
eine Shape Tabelle, die einen oder mehrere graphische(n) Parameter definiert, der bzw. die erforderlich ist bzw. sind, um Knoteninformation anzuzeigen, wobei die Knoteninformation vorzugsweise die Spezifikation einer Position, Größe und/oder Form bzw. Gestalt und Hintergrundspezifikationen beinhaltet;
eine Range Tabelle, die Information enthält, die steuert bzw. regelt, welche Farbe gewählte Formen haben sollten, wenn Anfrageergebnisse angezeigt sind bzw. werden;
eine Query Tabelle, die Information enthält, die notwendig ist, um das Ergebnis eines SQL Statements in einem Modell anzuzeigen, wobei das SQL Statement vorzugsweise als Text gespeichert ist und vorbestimmten oder vorbestimmbaren Konventionen bzw. Vereinbarungen folgt, um sicherzustellen, daß ein Nachfrage- bzw. Anfrageergebnis exakt die Anzahl und Arten von Spalten enthält, die notwendig sind, um durch die Anwendung geeignet bearbeitet zu werden;
eine Widget Tabelle, die Information enthält, die notwendig ist, um das Layout und/oder den Inhalt der angezeigten Knoten zu steuern bzw. zu regeln; und
eine Tree Tabelle, die Information enthält, die notwendig ist, um eine Baumseite im Zusammenhang mit der Widget Tabelle zu bilden.
Gemäß der Erfindung wird weiterhin eine Datenerfassungsmaschine für ein computerunterstütztes bzw. computerisiertes Informationssystem zum Erfassen, Zusammenstellen und/oder Visualisieren von strukturellen Daten von Architekturen einer technischen Einrichtung, wie IT Architekturen, insbesondere für ein System gemäß der Erfindung oder einer bevorzugten Ausführungsform davon zur Verfügung gestellt, wobei
die Datenerfassungsmaschine Daten basierend auf einem strukturierten, hierarchischen Modell, vorzugsweise gemäß der Erfindung oder einer bevorzugten Ausführungsform davon erfaßt bzw. aufnimmt und zusammenstellt,
die Datenerfassungsmaschine wenigstens eine Datenbank zum Speichern der Daten gemäß dem strukturierten, hierarchischen Modell umfaßt.
Gemäß der Erfindung wird weiterhin eine Anzeigemaschine für ein computerisiertes Informationssystem zum Erfassen, Zusammenstellen und/oder Visualisieren von strukturellen Daten von Architekturen einer technischen Einrichtung, wie IT Architekturen, insbesondere für ein System gemäß der Erfindung oder einer bevorzugten Ausführungsform davon bereitgestellt, wobei die Anzeigemaschine eine Mehrzahl von unterschiedlichen Anzeigen von erfaßten Daten basierend auf einem strukturierten, hierarchischen Modell, vorzugsweise gemäß der Erfindung oder einer bevorzugten Ausführungsform davon generiert bzw. erzeugt, wobei die erfaßten Daten in wenigstens einer Datenbank gemäß dem strukturierten, hierarchischen Modell gespeichert sind bzw. werden.
Somit sind bzw. werden gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung die folgenden Merkmale und Vorteile vorzugsweise möglich gemacht:

i. Maßschneidern von standardisierten Modellen, um den spezifischen Betriebs- und strategischen Erfordernissen bzw. Anforderungen des Kunden bzw. Klienten zu entsprechen;
ii. Betreiben bzw. Erzwingen einer strukturierten Datenerfassung, die mit dem auf den Kundenbedarf zugeschnittenen Modell von den Betriebseinheiten innerhalb der Organisation ausgerichtet ist;
iii. Konsolidieren bzw. Vereinigen und Filtern der Daten für eine Analyse und geeignete Kommunikation;
iv. Unterstützen der Entwicklung von zahlreichen Was-Wenn- und künftigen Szenarien innerhalb eines Klientenmodells;
v. kann innerhalb eines Körperschafts-Intranet für eine leichte Dateninstandhaltung bzw. -wartung eingesetzt werden;
vi. Bereitstellen eines Standards zum Vergleichen des gegenwärtigen Zustands der Architektur als auch irgendeines Szenarios mit Strukturen gemäß dem Zustand des Markts und Stand der Technik; und/oder
vii. Liefern der resultierenden Information in einer leicht verstandenen und klar kommunizierten graphischen Darstellung.

Demgemäß wird ein Application Management Visualisation Framework (AMVF) bzw. Anwendungsmanagement-Visualisierungsrahmenwerk bereitgestellt, das ein Verfahren, System, Computerprogrammprodukt und einzelnes oder einen Satz von Unterstützungswerkzeugen betrifft für ein Liefern, innerhalb des Kontexts eines Architekturmanagements, insbesondere Informationstechnologie-(IT) Anwendungsarchitekturmanage ments, einer konsolidierten graphischen Darstellung der komplexen Wechselbeziehungen, die zwischen den einzelnen Komponenten der Architektur existieren, insbesondere zwischen den Softwarekomponenten in einer IT Infrastruktur einer Firma, der (Daten-)Interfaces zwischen diesen Komponenten, der Geschäftsfunktionen, die diese Komponenten implementieren, der organisatorischen Strukturen, die benötigt werden, um diese Komponenten zu entwerfen bzw. auszulegen, zu bauen und/oder zu betätigen, und der betreffenden Kosten, die mit der Auswahl, dem Kauf (oder Design oder Aufbau, wenn kundenspezifisch) und dem fortlaufenden Betrieb dieser Komponenten assoziiert sind, basierend auf einer standardisierten Modelldarstellung bzw. einer Darstellung eines standardisierten Modells der technischen und/oder Geschäftsfunktionen, die eine Firma in diesem technischen Feld bzw. Gebiet oder Art eines Geschäfts typischerweise durchführt. Das Application Management Visualisation Framework umfaßt ein äußerst abstrahiertes Daten Modell, eine Generierungs- bzw. Erzeugungsmaschine eines graphischen Benutzer-Interface (GUI), eine Visualisierungsmaschine und/oder eine Szenariomanagementmaschine. Betriebsdetails der Architektur der Organisation, insbesondere der IT Landschaft, können vorzugsweise als eine graphische Zusammenfassung mit einer Nach-Unten-Bohrfähigkeit angezeigt werden, um Details niedrigeren Niveaus zu betrachten. Durch die Erzeugung von Szenarien, die die Einwirkung von verschiedenen Änderungen darstellen, die an irgendeinem der zugrunde liegenden Implementierungsdetails gemacht werden könnten, ist eine genauere Analyse der gegenwärtigen Architektur und einer Einwirkung von möglichen Änderungen möglich, so daß das Ändern einer Anwendungslandschaft der Architektur besser geplant und gemanagt bzw. gehandhabt werden kann.
Das Application Management Visualisation Framework betrifft computerisierte bzw. computerunterstützte Informationssysteme im allgemeinen und genauer die Erfassung oder Eingabe, Zusammenstellung und/oder Visualisierung von Daten oder Information, die notwendig ist bzw. sind, um die Entwicklung von Architekturen, insbesondere von IT Architekturen über die Zeit zu analysieren, zu kommunizieren und/oder zu regeln bzw. zu steuern.
Gemäß einem weiteren Aspekt der Erfindung werden ein Verfahren und System zum Erfassen, Zusammenstellen und/oder Visualisieren von strukturellen Daten eines Geschäfts bzw. Betriebs und/oder Architekturen von technischer Einrichtung, wie Informationstechnologie-(IT) Architekturen, bereitgestellt, welche die folgenden Schritte umfassen: Erfassen und Zusammenstellen von Daten gemäß einem strukturierten, hierarchischen Modell, das eine strukturierte, hierarchische Ansicht einer Modellstruktur zur Verfügung stellt, und Bauen des Grundrahmens zur Analyse und Visualisierung, wobei das Modell entweder ein standardisiertes Modell oder ein kundenspezifisches Modell ist; generisches Speichern von jeglicher Art von Architektur und Speichern und Analysieren von Beziehungsdaten zwischen Modellen; Definieren des strukturierten, hierarchischen Modells, damit es Tabellen umfaßt, welche entweder stark oder locker bzw. lose miteinander vernetzt bzw. verbunden sind, wobei starke Vernetzungen bzw. Verbindungen Row IDs bzw. Reihen IDs benutzen, und welche adaptiert sind, um jede Aufzeichnung zur Verfügung zu stellen, die eine Fremdschlüsselbeziehung zu einem primären bzw. Primärschlüssel einer Aufzeichnung in einer anderen Tabelle sein muß, und wobei lockere Verbindungen einzigartige IDs einer Reihe benutzen, und welche adaptiert sind, um eine Fremdschlüsselbeziehung zu einer anderen Tabelle derart aufzubauen, daß die Modelle und ihre Komponenten stark miteinander mittels wenigstens einer starken Verbindung gekoppelt sind, wobei sichergestellt wird, daß die Modelle, ihre Knoten und ihre unterschiedliche(n) graphische(n) Darstellung(en) eine Einheit bilden, und die Beziehungen zwischen Modellen locker mittels einer oder mehreren lockeren Verbindung(en) gekoppelt sind bzw. werden, was es den Endpunkten der entsprechenden Beziehung(en) ermöglicht, daß sie innerhalb eines Modells bewegbar oder entfernbar sind, ohne zu erzwingen, daß die Beziehung ebenfalls entfernt wird; wobei die generische Darstellung eines Modells durch starke Verbindungen zwischen Kernmodelltabellen und graphischen Repräsentationstabellen bzw. Tabellen einer graphischen Repräsentation dargestellt ist bzw. wird, und Genieren bzw. Erzeugen einer Mehrzahl von unterschiedlichen Anzeigen bzw. Darstellungen der aufgenommenen bzw. erfaßten Daten gemäß dem strukturierten, hierarchischen Modell.
Überblick der verwendeten Funktionen pro Anwendung bzw. Applikation und/oder mittels eines Anwendungsreports, der vorzugsweise Information gibt über: eine kurze Beschreibung der Anwendung; eine Clusterdarstellung, die vorzugsweise ein Anwendungsclustern ist, das einen Querverweis zu einem Cluster oder Subcluster beinhaltet; eine Funktionsdarstellung; und/oder eine Funktionsbeschreibung innerhalb eines Anwendungszusammenhangs.
Vorzugsweise wird das Analysieren und/oder Visualisieren der Daten durchgeführt, indem eine Anzeige von Anwendungs- oder Funktionsredundanzen generiert bzw. erzeugt wird, um einen Überblick von Funktionen zu erhalten, die in mehrfachen bzw. Mehrfachanwendungen implementiert sind.
Weiterhin bevorzugt wird vorzugsweise das Analysieren und/oder Visualisieren der Daten durchgeführt, indem eine Anzeige von Applikations- bzw. Anwendungskosten (Budgets, Software oder Hardwarekosten, Investitionen für Produktion, Wartung, Entwicklung, Benutzerunterstützung bzw. -support, Initiativen usw.) generiert bzw. erzeugt wird, die durch eine Anwendung oder einen oder mehrere Cluster strukturiert sind.
Noch weiter bevorzugt wird das Analysieren und/oder Visualisieren der Daten durchgeführt, indem eine Anzeige von allgemeiner Anwendungsinformation über den Typ bzw. die Art von Anwendungen (gekaufte oder kundenspezifische Software), Anzahl von Benutzern, Entwicklungs- oder Kaufkosten usw. generiert bzw. erzeugt wird.
Am meisten bevorzugt werden die Daten mittels einer oder mehrerer Wartungsmaske(n) für Funktionsdarstellungen gewartet bzw. beibehalten, welche Darstellungen zwischen Anwendungen bzw. Applikationen und Funktionen, Beschreibungen der Funktionen innerhalb des Anwendungszusammenhangs und/oder Dokumentation von Gegenständen bzw. Ausgaben/Anfragen beinhalten, und/oder mittels einer oder mehrerer Wartungsmaske(n) für Anwendungsbeschreibungen, umfassend kurze Beschreibungen für die jeweiligen Anwendungen.
Diese und andere Ziele, Merkmale und Vorteile der vorliegenden Erfindung werden beim Lesen der folgenden detaillierten Beschreibung von bevorzugten Ausführungsformen und aus den begleitenden Zeichnungen ersichtlicher werden. Es sollte verstanden werden, daß, selbst obwohl Ausführungsformen gesondert beschrieben sind bzw. werden, einzelne Merkmale davon zu zusätzlichen Ausführungsformen kombiniert werden können.
1 stellt den gesamten Arbeitsablauf dar, der innerhalb des Application Management Visualisation Framework gemäß einer bevorzugten Ausführungsform der Erfindung verkörpert ist;
2 zeigt die Hauptkomponenten des Application Management Visualisation Framework, die kundenspezifischen Haupteingaben und Komponenten, die generiert bzw. erzeugt sind, um Kundenspezifikationen der bevorzugten Ausführungsform einzuhalten;
3 zeigt die hauptsächlichen Daten-Modell-Einheiten bzw. Data Model-Einheiten und Beziehungen eines strukturierten, hierarchischen Modells gemäß einer bevorzugten Ausführungsform der Erfindung;
4 zeigt eine bevorzugte detaillierte Tabellenstruktur für das Handhaben von Modellen;
5 zeigt eine bevorzugte detaillierte Tabellenstruktur für das Handhaben von Darstellungen;
6 zeigt eine bevorzugte detaillierte Tabellenstruktur für das Handhaben von Anzeige- und/oder Editier- oder Eingabefunktionen;
7 zeigt einen allgemeinen Arbeitsablauf der graphischen Benutzer-Interface-(GUI) Generierungs- bzw. Erzeugungsmaschine gemäß einer bevorzugten Ausführungsform der Erfindung;
8 zeigt einen allgemeinen Arbeitsablauf der Visualisierungsmaschine gemäß einer bevorzugten Ausführungsform der Erfindung;
9 zeigt den allgemeinen Arbeitsablauf der Szenariomaschine gemäß einer bevorzugten Ausführungsform der Erfindung;
10 zeigt eine allgemeine Struktur von üblichen bzw. gemeinsamen Subroutinen gemäß einer bevorzugten Ausführungsform der Erfindung;
11 zeigt ein Beispiel einer visualisierten Anzeigeschablone bzw. -dokumentvorlage, die die Ausrichtung von Geschäftsanwendungen auf die Organisationen innerhalb des IT Departments bzw. der IT Abteilung darstellt, das bzw. die für ein Ausbilden bzw. Auslegen, Bauen und/oder Instandhalten bzw. Warten dieser Anwendungen verantwortlich ist;
12 zeigt ein Beispiel einer visualisierten Anzeigeschablone bzw. -dokumentvorlage, die die Darstellung von detaillierten Business- bzw. Geschäftsfunktionen auf Geschäftsbetriebsgebiete zeigt;
13 zeigt eine Musteranfragevisualisierung, in welcher Funktionen durch Anwendungen, die zu einem spezifischen IT Department "gehören", als auch die redundant implementierten Funktionen vollbracht werden. Die Basisschablone für diese Anzeige ist in 12 gezeigt;
14 zeigt ein Beispiel einer Anfragevisualisierung, in welcher Funktionen durch Anwendungen, die zu einem spezifischen IT Department "gehören", als auch die redundant implementierten Funktionen vollbracht werden; ähnlich 13 ist die Basisschablone für diese Anzeige in 12 gezeigt, aber die Details spiegeln ein alternatives Szenario wider;
15(A) bis (L) sind Beispiele von Tabellen, die in einem bevorzugten Daten Modell implementiert sind;
16 zeigt bevorzugte funktionelle Blöcke und/oder Merkmale des bevorzugten Application Management Visualisation Framework (AMVF); und
17(A) und (B) zeigen beispielhafte Anzeigen einer Data Query/Reports, Funktion (Datenabfrage/Report-Funktion) des bevorzugten Application Management Visualisation Frameworks (AMVF).
In der folgenden Beschreibung von bevorzugten Ausführungsformen der Erfindung soll die folgende Terminologie oder Verständnis angewendet werden:
Modell: Ein Modell stellt eine strukturierte, hierarchische Ansicht einer Struktur oder Architektur oder Geschäfts bereit und baut den Basis- bzw. Grundrahmen für eine Analyse und/oder Visualisierung. Ein Modell kann ein standardisiertes Modell oder ein kundenspezifisches Modell sein. Ein Standardmodell stellt die Aufgaben und Funktionen, die üblicherweise durch ein Geschäft durchgeführt werden, und ein normatives Clustern bzw. Zusammenfassen dieser Aufgaben und Funktionen dar. Ein kundenspezifisches Modell wird erzeugt, wenn ein Standardmodell adaptiert oder modifiziert (auf den Kundenbedarf zugeschnitten) ist bzw. wird, um einzuhalten, um die spezifischen Merkmale bzw. Eigenschaften und Qualitäten einer einzelnen oder beabsichtigten Struktur oder eines Geschäfts zu reflektieren bzw. widerzuspiegeln.
Meta Modell: Das Meta Modell bzw. Meta Model ist eine abstrakte Darstellung der Struktur oder des Geschäftsmodells, beinhaltend eine hierarchische Darstellung der Struktur- oder Geschäftsmodelleinheiten und/oder ihrer entsprechenden graphischen Darstellung.
Modell Daten: Modell Daten bzw. Model Data sind die kundenspezifischen Betriebsdaten, die zu einem existierenden bzw. vorhandenen Modell hinzugefügt worden sind. Diese Daten können enthalten, sind aber nicht beschränkt auf, Anwendungsnamen, konkrete Kostenwerte, organisatorische Strukturen und/oder eine Anwendung auf Anwendungsinterfaces.
Meta Daten: Meta Daten bzw. Meta Data sind Daten, die ein konkretes Auftreten des Meta Modells spezifizieren. Diese Daten beinhalten, sind aber nicht beschränkt auf tatsächliche Knotennamen, die Knotenposition in der Modellhierarchie, die Formgröße und/oder -position der graphischen Darstellung des Knotens und Typen bzw. Arten von Knoten, die existieren können.
Daten Modell: Das Daten Modell bzw. Data Model ist ein logisches Bild einer relationalen Datenbank, die die Beziehung zwischen den Komponenten des Meta Modells, der Meta Daten und/oder der Modell Daten definiert. Die relationale Datenbank, die dieses Modell implementiert, sorgt für die Speicherung aller Information, die erforderlich ist, um das Meta Modell und die Modell Daten zu repräsentieren bzw. darzustellen.
Framework: Ein Framework bzw. Rahmen ist ein Analyseparadigma, umfassend das Daten Modell, das implementierte Meta Modell, die Modell Daten und/oder die Meta Daten, zusammen mit den Anwendungen, die benötigt werden, um diese Information zu analysieren, visualisieren und/oder instand zu halten bzw. zu warten.
Tabelle: Eine Tabelle ist eine Sammlung von aufeinander bezogenen Aufzeichnungen in einer relationalen Datenbank, in welcher Beziehungen (als ein geordneter Satz von Feldern, gewöhnlich zusammenhängend gespeichert) zwischen Informationseinheiten bzw. -gegenständen explizit als zugängliche bzw. zugreifbare Attribute spezifiziert sind.
Starke Verbindungen: Begründen die Abhängigkeiten zwischen den Daten, die in 2 oder mehr Tabellen enthalten sind, die notwendig sind, um die zugrunde liegende Struktur eines Modells und die Visualisierung der hierarchischen Struktur des Modells zu erzeugen. Ein Ändern dieser Verbindungen ist möglich, schließt aber eine signifikante bzw. beträchtliche Anstrengung ein, da diese Änderungen die grundlegende, hierarchische Struktur des Modells ändern.
Lockere Verbindungen: Begründen die Abhängigkeiten zwischen den Daten, die in 2 oder mehr Tabellen enthalten sind, die notwendig sind, um die Beziehung zwischen der Modellstruktur und den detaillierten Daten und Attributen zu erzeugen, die an jedem Niveau der Modellhierarchie angezeigt werden können. Diese Verbindungen werden leicht durch den Benutzer modifiziert und diese Änderungen verändern die grundlegende, hierarchische Struktur des Modells nicht materiell.
SQL Verbindungen: Begründen die Abhängigkeiten zwischen den Daten, die in 2 oder mehr Tabellen enthalten sind, die nicht basierend auf gemeinsamen Feldern innerhalb von Tabellen implementiert sind, sondern basierend auf Attributen, die in einer SQL Anfrage spezifiziert sind.
Szenario: Ein Szenario ist eine Darstellung einer alternativen Implementierung, sowohl innerhalb des Daten Modells als auch in der Visualisierung der IT Architektur, das verwendet wird, um die What-if- bzw. Was-Wenn-Analyse der Einwirkung einer Änderung an der IT Architektur über die Zeit zu unterstützen. Szenarien können einen Punkt in der Zeit (was, wenn ich tue "A" gegenüber "B" gegenüber "C") oder eine Zeitlinie darstellen (was, wenn ich tue "A", dann "B" gegenüber "A", dann "C" gegenüber "B", dann "C"). Innerhalb dieses Kontexts bzw. Zusammenhangs können das anfängliche, auf den Kundenbedarf zugeschnittene kundenspezifische Modell und ursprüngliche bzw. Anfangsdaten als das Anfangsszenario betrachtet werden, auf welchem alle Änderungen und Alternativen basieren.
Im Folgenden wird eine detaillierte Beschreibung eines Application Management Visualisation Framework (AMVF) gemäß einer bevorzugten Ausführungsform der Erfindung unter Bezugnahme auf 1 gegeben.
In 1 ist der gesamte Arbeitsablauf für das Application Management Visualisation Framework dargestellt. In der Praxis umfaßt das Application Management Visualisation Framework vorzugsweise zwei Phasen: eine Phase 100 einer Initialisierung (Initialization) und/oder Datenerfassung (Data Capture) und eine Phase 200 einer Analyse, dynamischen Visualisierung und/oder Instandhaltung bzw. Wartung (Analysis, Dynamic Visualisation und/oder Maintenance), wodurch der Übergang von der Initialisierungs- und/oder Datenerfassungsphase 100 zu der Analysen-, dynamischen Visualisierungs- und/oder Instandhaltungs- bzw. Wartungsphase 200 nicht klar definiert ist. Dieser Arbeitsablauf bzw. Workflow wird durch die hauptsächlichen Rahmen- bzw. Frameworkkomponenten unterstützt, wie dies unter Bezugnahme auf 2 beschrieben wird, welche die Beziehung zwischen den Hauptkomponenten des Application Management Visualisation Frameworks, kundenspezifischen Eingabeerfordernissen bzw. -anforderungen und den resultierenden kundenspezifischen Kundenkomponenten darstellen. Die Hauptkomponenten des Application Management Visualisation Frameworks sind:

1. Die Datenbank bzw. Database 300/500, umfassend eine Implementierung eines strukturierten, hierarchischen Modells 10, umfassend ein Meta Modell
2. Die Visualisierungsmaschine bzw. Visualisation Engine 510
3. Die graphische Benutzer-Interface-(GUI) Erzeugungsmaschine 520 (Graphical User Interface (GUI) Generation Engine)
4. Die Szenariomaschine 530 (Scenario Engine)
5. Eine Mehrzahl von Fragebogenschablonen 430 (Questionnaire Templates).

Wenn einmal das Application Management Visualisation Framework zu verwenden ist, sind die Hauptkomponenten des grundlegenden bzw. Basis-Frameworks zu installieren oder ist es notwendig, daß sie installiert werden 800. Diese anfängliche bzw. einleitende Installation 800 kann an der Kundenstelle oder entfernt von der Stelle auftreten. Um für eine fortlaufende Verwendung des Application Management Visualisation Frameworks zu sorgen, ist es jedoch bei einem gewissen Punkt vorteilhaft, örtlich beim Kunden installiert zu sein bzw. zu werden. In Schritt 805 wird ein standardisiertes, generisches Modell ausgewählt, das sich eng dem Bereich einer Analyse der Architektur anpaßt, die durch den Kunden gewünscht ist, oder ein Defaultmodell wird festgelegt und in eine Basisdatenbank 500 geladen, welche eine physische Implementierung des Daten Modells darstellt. Das ausgewählte oder festgelegte Modell sollte vorzugsweise alle Hauptkomponenten, Funktionen und/oder Merkmale enthalten, die die Architektur vollbringen sollte (die beispielsweise der Client bzw. Kunde erfordert), die in einer hierarchischen Art und Weise organisiert sind.
Dann wird in Schritt 810 die graphische Benutzer-Interface-(GUI) Erzeugungsmaschine 520 verwendet, um GUI Schirme 440 als bevorzugte Fragebogenschablonen 430 zu erzeugen, welche verwendet werden, um dieses Anfangsmodell, seine Komponenten und/oder Struktur instand zu halten bzw. beizubehalten (oder zu aktualisieren) und/oder zu verändern. In Schritt 815 benutzt die Szenariomaschine 530 diese Schirme 440 und/oder eine manuelle Eingabe, um die Modellparameter an den Bedarf anzupassen (d.h. das Modell an die tatsächliche oder gewünschte Architektur zu adaptieren), bis sie mit den spezifischen Erfordernissen bzw. Anforderungen des Kunden ausgerichtet ist. Unter Verwendung der GUI Schirme, die durch die graphische Benutzer-Interface-(GUI) Erzeugungsmaschine 520 erzeugt sind bzw. werden, werden die Modellstruktur, unterstützte Beziehungen zwischen Modelleinheiten, Attribute und/oder graphische Darstellungen spezifiziert. Dieser auf den Kundenbedarf zuschneidende bzw. Anpassungsprozeß beinhaltet die Erzeugung eines oder mehrerer zusätzlichen(r) Modells(e) 400, das bzw. die benötigt wird bzw. werden, um die Architektur, insbesondere die IT Architektur, in ihrer Gesamtheit zu portraitieren bzw. darzustellen. Diese Modelle 400 beinhalten, sind aber nicht beschränkt auf die organisatorische Struktur und Kostenstruktur der Firmen (IT), und sind vorzugsweise in das Meta Modell bei einem so niedrig wie möglich hierarchischen Niveau verbunden bzw. gekoppelt. Dies stellt die beste Kombination einer detailanalytischen und zusammenfassenden Aufrollfähigkeit zur Verfügung.
Der beschriebene iterative Prozeß 501 eines Eingebens der Modellstruktur von unterstützten Beziehungen zwischen Modelleinheiten bzw. -entitäten, Attributen und/oder graphischen Darstellungen wandelt wirksam die anfängliche Application Management Visualisation Framework Datenbank (Bezugszeichen 500 in 2) in die kundenspezifische Datenbank (Bezugszeichen 300 in 2) um.
Sobald einmal das eine oder die mehreren Modell(e) auf den Kundenbedarf zugeschnitten worden ist bzw. sind, werden die kundenspezifischen Datenattribute und Betriebsdaten für jedes Modell in die Datenbank 500/300 geladen 825 und die endgültigen Instandhaltungs- bzw. Wartungsschirme 440 werden unter Verwendung der GUI Erzeugungsmaschine 520 erzeugt 820. Basierend auf den Datenbeziehungen, die durch das neu erzeugte Kundenmodell in der Datenbank 300 unterstützt sind bzw. werden, werden maßgeschneiderte Fragebögen (Schritt 835) basierend auf den Application Management Visualisation Framework Fragebogenschablonen 430 erzeugt und (vorzugsweise automatisch) an die geeigneten bzw. entsprechenden Experten des fraglichen Gegenstands innerhalb der Organisation des Klienten zur Vervollständigung 840 beispielsweise über E-Mail verteilt. Im Fall von auf Papier basierenden und/oder auf E-Mail basierenden Fragebögen, wird das auf diese Weise gesammelte Feedback in die Datenbank 300 importiert 845. Fragebögen können jedoch online oder offline ausgeführt werden und demgemäß importiert werden. In den letzteren Fällen kann die Information direkt in die Datenbank eingegeben werden. Es ist vorteilhaft, diese Information sammelnde Übung in einem relativ kurzen Zeitrahmen (beispielsweise weniger als 2 Monaten) zu vervollständigen, um sicherzustellen, daß das initialisierte Daten Modell genau den wahren "Zustand von Angelegenheiten" reflektiert.
Sobald einmal diese detaillierte Informationssammlung vervollständigt ist, wird die Initialisierungsphase 100 wirksam vervollständigt. Diese Initialisierungsschritte 800–845 können jedoch wiederholt durchgeführt werden (einzeln, zum Teil oder gänzlich) wie benötigt, um ein zusätzliches Modell (zusätzliche Modelle) und/oder Visualisierungen in die auf den Kundenbedarf zugeschnittene Version des Application Management Visualisation Framework für ein genaueres Reflektieren der Architektur unter Analyse zu bauen. Der Prozeß eines Erzeugens 830, 835 und Ausfüllens 840 von Fragebögen kann im Ganzen oder für spezifische Bereiche wiederholt werden, wenn gewünscht, aber typischerweise wird die in der aktiven Datenbank 300 enthaltene Information online instand gehalten bzw. gewartet oder online aktualisiert. Obwohl als eine gesonderte Phase dargestellt, können die in der Phase 200 einer Analyse, dynamischen Visualisierung und/oder Instandhaltung bzw. Wartung gezeigten fortlaufenden Aktivitäten tatsächlich zu jeder Zeit gestartet werden, nachdem Schritt 810 fertiggestellt bzw. abgeschlossen ist.
Nachfolgend auf die anfängliche bzw. Anfangseinstellung umfaßt die Phase 200 einer Analyse, dynamischen Visualisierung und Instandhaltung wenigstens eine der folgenden zusätzlichen Aktivitäten:

1. ein Bilden eines Szenario 850 (Scenario Building),
2. eine Datenanalyse 855 (Data Analysis),
3. eine Visualisierung 860 (Visualisation), und/oder
4. eine Dateninstandhaltung bzw. -wartung 865 (Data Maintenance).

Durch das Bauen von Szenarien 850 mittels einer Szenariomaschine 530, die später zu beschreiben ist, können Unterschiede in einer Implementierung und/oder Änderungen in einer Architektur (aufgrund beispielsweise Änderungen in einer Geschäftsstrategie) simuliert, visualisiert und/oder evaluiert bzw. bewertet werden. Benutzer können Szenarien über die Szenariomaschine 530 erzeugen und/oder beibehalten. Die Szenariomaschine 530 erlaubt vorzugsweise dem Benutzer, zahlreiche Versionen eines Modells oder sogar zahlreiche Modelle zu erzeugen und/oder zu verbinden bzw. zu koppeln, um "Schnappschüsse" von möglichen künftigen Zuständen zu erzeugen.
Die Kombination von starken Verbindungen, die die Modellstruktur definieren, und losen bzw. lockeren Verbindungen, die die Beziehungen zwischen Knoten und/oder Knotenattributen definieren, bedeutet, welche es Benutzern ermöglicht, eine "Zeitlinie" dieser Schnappschüsse oder eine Sequenz bzw. Abfolge von Anzeigen zu entwickeln, die einzelne Änderungen in der Architektur reflektieren, indem die losen Verbindungen geändert werden. Dies steigert merklich die Was-Wenn-Fähigkeiten des Application Management Visualisation Frameworks bzw. Anwendungsmanagement-Visualisierungsrahmens. Für eine detailliertere Beschreibung von starken und losen Verbindungstypen bzw. -arten siehe das Beispiel, das unter Bezugnahme auf den Daten-Modell-Überblick beschrieben ist.
Die Szenariomaschine 530 stellt sicher, daß verschiedene Szenariokonstrukte unabhängig voneinander verbleiben. Durch die Entwicklung von zahlreichen Szenarien können verschiedene Wege zu gemeinsamen Zielen (beispielsweise einer gewünschten Funktionalität der Architektur) auch evaluiert bzw. bewertet werden. Auf diese Weise können optimale Ansätze bzw. Zugänge, um spezifische Ziele zu erzielen, basierend auf den Zielen, die verfolgt werden, konstruiert sein bzw. werden (beispielsweise: Optimierung von Kosten gegenüber Zeit gegenüber Risikominimierung). Innerhalb der verschiedenen Szenarien, die entwickelt sind bzw. werden, ist eines als aktiv festgelegt bzw. eingestellt. Dieses aktive Szenario repräsentiert den aktuellen bzw. tatsächlichen Status oder Basislinienstatus (Basislinienstatus kann tatsächlich einen künftigen Punkt in der Zeit repräsentieren) einer Architektur unter Analyse, beispielsweise IT Architektur eines Kunden bzw. Klienten zur Verwendung beim Vergleich mit anderen, nicht aktiven Szenarien.
In der Datenanalysefunktion 855 erlangt der Benutzer wieder und/oder filtert gegenwärtige Betriebsdaten und szenariospezifische Daten, die mit Benutzereingaben konsistent bzw. in Einklang sind. Dies kann getan werden, indem die Datenbank 300 über die eine Structured Query Language bzw. strukturierte Anfragesprache (SQL) gefragt wird und/oder indem die Visualisierungsmaschine 510 verwendet wird, um die Analyse zu führen und zu unterstützen. Im Fall einer direkten Anfrage werden die Ergebnisse nicht graphisch angezeigt, aber sie können in einen weiten Bereich von externen Tools bzw. Werkzeugen für eine weitere Anreicherung mit Daten, die nicht innerhalb der Datenbank 300 enthalten sind, und/oder zusätzliche Analyse exportiert werden. Andernfalls werden die Ergebnisse der Analyse zur Visualisierungsmaschine 510 für ein Rendern und eine Anzeige hindurchgeführt.
Die Aufgabe 860 einer Visualisierung von Daten und Analyse (Visualise Data and Analysis) verwendet auch die Visualisierungsmaschine 510, um sowohl Funktionen eines Erzeugens/Beibehaltens eines Szenarios 850 als auch Analysierens von Daten 855 zu unterstützen, indem die Daten in visuelle Darstellungen konsolidiert bzw. vereinigt werden und/oder ihre Anzeige gerendert bzw. übergeben wird. Diese visuellen Strukturen der Anzeige sind datenunabhängig dahingehend, daß mögliche Formen bzw. Gestalten und/oder die Beziehung zwischen Formen, die verwendet werden, um die hierarchischen Niveaus des Modells 10 darzustellen, während des iterativen Zuschneidens auf den Kundenbedarf 815 spezifiziert wurde(n). Die Betriebsdaten stellen lediglich die Information (Farbe, Form, Position, usw.) zur Verfügung, die benötigt wird, um die Anzeigeattribute für die verschiedenen Formen geeignet zu spezifizieren oder auszuwählen.
Innerhalb der Phase 200 einer graphischen Visualisierung und Analyse des Application Management Visualisation Framework bildet ein standardisiertes, hierarchisches, strukturelles Modell 10 der Struktur(en) oder Architektur(en) oder des Geschäfts eine Basis sowohl für die Analyse als auch Anzeigefunktionalität aus. Der innovative Aspekt der Lösung liegt bzw. besteht in der generischen Speicherung jeglicher Art von Architektur oder Geschäftsmodell und der Speicherung und Analyse von Beziehungsdaten zwischen Modellen. Während Modelle und ihre Komponenten stark mittels einer oder mehrerer starker Verbindung(en) miteinander verbunden sind, die sicherstellt (sicherstellen), daß das Modell (die Modelle), ihre Knoten und ihre unterschiedliche(n) graphische(n) Darstellung(en) eine Einheit aus bilden, sind die Beziehungen zwischen Modellen locker mittels einer oder mehrerer loser bzw. lockerer Verbindung(en) gekoppelt. Lose Verbindungen erlauben, daß die Endpunkte der entsprechenden Beziehung(en) innerhalb eines Modells bewegt werden oder sogar entfernt werden können, ohne die Beziehung zu zwingen, ebenfalls entfernt zu werden. Diese "gebrochenen Verbindungen" (lose Verbindungen ohne einen existierenden Endpunkt) bleiben sichtbar und können analysiert werden, da sie wertvolle (historische) Information über die Architektur oder das Geschäft enthalten.
Beispielsweise würde ein generisches Automobil ein derartiges Modell sein. Es weist eine definierte Form auf, ist aus spezifischen Komponenten gebildet (Räder, Motor, Rahmen, Achsen, Differential usw.), wobei jede assoziierte bzw. verbundene Merkmale bzw. Eigenschaften aufweist (Kosten, verwendete Materialien, Lieferant, Führungs- bzw. Vorhaltzeit zum Ändern, usw.) und wobei jede zu der Autoanordnung bzw. dem Autozusammenbau in einer spezifischen Reihenfolge (Arbeitsablauf bzw. Workflow) durch verschiedene Arbeiter und/oder Maschinen (Organisation) hinzugefügt ist. Die generische Darstellung dieses Modellautos kann über starke Verbindungen zwischen den 3 Kernmodelltabellen und den graphischen Darstellungstabellen repräsentiert bzw. dargestellt werden (vergleiche 4). Durch ein Anwenden dieses generischen Modells auf einen spezifischen Hersteller kann eine Hierarchie von Fahrzeugherstellern und assoziierten Modelljahren, beinhaltend Teile und Baugruppen, etc. hergestellt werden. Die individuellen bzw. einzelnen Fahrzeugtypen entsprechen Knoten in dem generischen Modell. Ein zusätzliches Modell würde die Hierarchie von Automobilteillieferanten bzw. -zulieferern sein, wo es Beziehungen zwischen den verschiedenen Knoten des Lieferantenmodells (dem Lieferant selbst) und den Knoten des Automobilmodells (dem entsprechenden Teil des Lieferanten) gibt. Daten, die mit diesen Beziehungen assoziiert bzw. verbunden sind, würden beispielsweise der Preis des Teils, Versandbedingungen, Lieferantenqualität oder andere Daten sein, welche von einem strukturellen oder Geschäftszusammenhang von Interesse sein würden und visualisiert werden müssen. Wenn beispielsweise ein Lieferant seinen Betrieb einstellt und von dem Lieferantenmodell entfernt wird, können die "gebrochenen bzw. unterbrochenen Verbindungen" der Beziehungen des Teilelieferanten detektiert werden und müssen auf existierende Lieferanten oder neue Lieferanten erneut dargestellt werden, welche zu dem Lieferantenmodell hinzugefügt worden sind. Auch analytische Anfragen über die Beziehungen können laufen gelassen werden, um kritische Abhängigkeiten herauszufinden, wo beispielsweise zu viele wichtige Teile gerade durch eine einzige Lieferantengruppe geliefert werden.
Dieselbe oder eine ähnliche Art von Modell kann für die Arten von Arbeiten, Maschinen und technischen Einrichtungen gebildet werden, die notwendig sind, um ein Kraftfahrzeug herzustellen und/oder zusammenzubauen. Demgemäß würde ein derartiges Modell erlauben, Daten einer Produktionseinrichtung von Kraftfahrzeugen, beispielsweise im Hinblick auf ein Optimieren des Arbeitsablaufs in einer Produktionslinie zu erfassen, zusammenzustellen und/oder zu visualisieren, wobei einzelne Herstellungsschritte in einer Produktion entfernt oder hinzugefügt werden, Maschinen, die spezifizierte bzw. bestimmte Arbeitseigenschaften aufweisen, durch andere Maschinen ersetzt werden, die verschiedene Arbeitseigenschaften aufweisen, usw.
Die Möglichkeit aufweisend bzw. besitzend, Modelle zu adaptieren, wird durch die Möglichkeit ergänzt, mehrere Modelle derselben oder ähnlichen Art parallel zu besitzen und sie innerhalb verschiedener Szenarien zu analysieren. Beispielsweise ändert ein Entwickeln eines neuen Fahrzeugs nicht die Basismodellstruktur und kann durch ein Editieren bzw. Bearbeiten oder Hinzufügen von Datenpunkten in dem Meta Modell erreicht werden, die miteinander über lose Verbindungen verbunden sind (siehe 5 – Darstellung von Beziehungstabellen und Daten, die mit Beziehungstabellen verbunden sind). Selbst eine Änderung von der Herstellung von Personenkraftwagen auf Personen-Vans könnte auf diese Weise erreicht werden, da die grundlegende bzw. Basismodellstruktur dieselbe bleibt. Jedoch können einige der Knoten entfernt werden (beispielsweise weist ein Personen-Van bzw. -Kombi keinen Kofferraum auf), andere können hinzugefügt sein (beispielsweise kann ein Van drei Reihen von Sitzen aufweisen). Die erzeugten Szenarien würden Änderungen in den Detailattributen des Basismodells reflektieren bzw. widerspiegeln (beispielsweise, indem die Produktion von Motoren nach Osteuropa verlegt wird, wird der Produktionspreis um < 15% verringert, die Motorknoten sind in den Modellen von beiden Szenarien, jedoch kann das Produktpreisattribut festgelegt bzw. eingestellt sein, verschieden zu sein).
Manchmal ist es notwendig, eine Planungsunterstützung für radikalere Änderungen in der zugrunde liegenden Struktur oder Architektur oder dem Geschäft bereitzustellen. Beispielsweise würden, wenn die Herstellung von Autos auf die Herstellung von Flugzeugen oder Booten geändert wird, diese Änderungen in der Struktur oder Architektur oder dem Geschäft durch Änderungen der zugrunde liegenden Basis modellstruktur begleitet sein, insbesondere, um die sich unterscheidenden graphischen Darstellungen zu berücksichtigen, die benötigt werden, um die Struktur oder Architektur oder das Geschäft zu visualisieren. Diese Modelländerung würde das Ändern von Daten erfordern, die über eine oder mehrere starke Verbindung(en) verbunden sind. Zumindest würden sich die Modell-Anzeige-Beziehungen ändern. Wenn einmal das Basismodell etabliert bzw. aufgebaut ist, wird es jedoch nicht häufig geändert, da die zugrunde liegende Struktur oder Architektur oder das Geschäft, die bzw. das das Modell repräsentiert, gewöhnlich relativ stabil ist. Jedoch werden sich die Beziehungen zwischen den Knoten des Modells mit anderen Modellen und besonders die assoziierten bzw. verbundenen Daten häufiger ändern (beispielsweise Preise für Teile werden jedes Jahr geändert, die Beziehungen zwischen Außenteilen und ihren Lieferantenfirmen sind auch flüchtig bzw. unbeständig, usw.). Und die Verwendung dieser losen Verbindungen, um diese Beziehungen zu erzeugen, verbessert die Endbenutzerverwendbarkeit und gesamte AMVF Flexibilität.
Um diese Art von Übergangsplanung zu unterstützen, würden die startenden und beendenden Modelle in die Datenbank als alternative Szenarien geladen. Die notwendige(n) Interim-Modellstruktur(en), die diesen Übergang begleitet(n), würde(n) auch als Szenarien definiert sein. Die Komplexität und Größe einer derartigen Änderung sind merklich größer als Übergänge innerhalb der Grenzen eines Modells, aber der AMVF unterstützt das Planen und die Analyse in derselben leicht zu verwendenden, leicht kommunizierten Weise.
Im Folgenden wird eine detaillierte Beschreibung einer bevorzugten Ausführungsform von zugrunde liegenden Datenstrukturen gegeben.
Die hohe Flexibilität des Daten Modells, die erforderlich ist, um fähig zu sein, verschiedene Arten von Modellen zu managen bzw. handzuhaben, wird durch eine Kombination von stark und locker verbundenen Tabellen innerhalb des Daten Modells erzielt.
Starke Verbindungen benutzen Tabellen Row IDs bzw. Reihen IDs (siehe beispielsweise 15(A)–(G), wo "rid" für Row ID steht) und stellen sicher, daß es für jede Aufzeichnung eine Fremdschlüsselbeziehung zum primären bzw. Primärschlüssel einer Aufzeichnung in einer anderen Tabelle geben muß.
Lose Verbindungen machen Gebrauch von einer einzigartigen ID einer Reihe (siehe beispielsweise 15(B)–(D)). Lose Verbindungen stellen auch eine Fremdschlüsselbeziehung zu einer anderen Tabelle her, jedoch wird die Verbindung über den Modell-Typ im Fall von Modellen getan (das korrekte Modell wird durch das "aktive Flag" ausgewählt) und/oder über die Identifizierung des einzigartigen Schlüssels (beispielsweise im Fall von Knoten). Dies erlaubt, daß mehrere verschiedene Versionen desselben Modell-Typs parallel existieren. Auf diese Weise können wir Updates bzw. Aktualisierungen an den Modellen unterstützen, um organisatorische Änderungen zu reflektieren, ohne die verbleibenden Datenbeziehungen zu verlieren.
Diese Kombination von Verbindungstypen (starke Verbindungen und lose Verbindungen) optimiert die Mühelosigkeit, das Da ten Modell auszudehnen bzw. zu erweitern, um neue Modell-Typen, neue Attribute, Datentypen usw. einzugliedern bzw. aufzunehmen.
Das Daten Modell ist, während es proprietär ist, dem Klienten oder Benutzer zugänglich gemacht, der das Application Management Visualisation Framework implementiert. Dieses offene Daten Modell erlaubt erfahrenen Leistungsbenutzern SQL zu lesen und auch einen Zugriff zu aktualisieren, wobei die Systembenutzbarkeit optimiert wird. Ein Verwenden dieses Merkmals kann jedoch erfordern, daß eine zusätzliche Zugangskontrolle bzw. -regelung und Sicherheitsrechte direkt in der Datenbank implementiert sind bzw. werden.
Zusätzliche Anfragen können vorzugsweise entwickelt und gespeichert werden, was alternative Analyseszenarien ermöglicht.
Konzeptionell ist das Daten Modell (als ein bevorzugtes strukturiertes, hierarchisches Modell) zwischen einem Meta-Daten-Niveau (welches die Struktur des Modells beschreibt) und einem Betriebsdatenniveau (d.h. Modell Daten, welche die detaillierten Attribute und/oder Implementierung und Szenariendetails bereitstellen) gespalten.

i. Das Meta-Daten-Niveau beschreibt das Modell selbst, die erlaubbare Beziehung zwischen Knoten desselben oder unterschiedlichen Modells, die graphische Darstellung von Knoten und/oder die erlaubbaren Attributtypen für Knoten.
ii. Das Meta-Daten-Modell ist auch zwischen strukturellen Daten und Visualisierungsdaten gespalten. Strukturelle Meta Daten regeln bzw. steuern, welche spezifische Betriebsdaten innerhalb der Datenbank (Modell) zulässig sind und/oder wie diese Daten zueinander in Beziehung stehen. Visualisierungs-Meta-Daten definieren, wie die zugrunde liegenden Betriebsdaten gefiltert und/oder angezeigt werden können.
iii. Die Betriebsdaten sind oder stellen im wesentlichen die gegenwärtigen und Was-Wenn- und/oder Szenario-Permutationen der Attribute dar. Diese Daten stellen den Inhalt und/oder Visualisierungsanhaltspunkte bzw. -schlüssel bereit, die durch die Erzeugungsmaschine 520 anzuzeigen sind.
iv. Aufgrund der Trennung der Betriebsdaten von dem Modell und modellspezifischen Anzeigeeigenschaften funktionieren die GUI Erzeugungsmaschine 520, die Szenariomaschine 530 und die Visualisierungsmaschine 510 unabhängig von den Betriebsdaten. Ein Filtern von Betriebsdaten stellt die Anzeigeattribute bereit (beispielsweise unterschiedliches Färben, abhängig von geschäftsrelevanten Daten, beispielsweise höheren Kosten, Anzahl von Auftreten, Kosten usw.), aber die Anzeigestruktur ist als eine Eigenschaft bzw. ein Merkmal des Modells mittels entsprechender Tabellen definiert (wie beispielsweise eine Display Tabelle 31, eine Shape Tabelle 32, die später zu beschreiben sind).

Insbesondere greift die GUI Erzeugungsmaschine 520 auf die Daten zu, die die Modell Tabelle 11, die Node_class Tabelle 12, die Node Tabelle 13, die Display Tabelle 31, die Shape Tabelle 32 und/oder die Attribut Tabelle 61 enthalten, für ein spezifiziertes bzw. bestimmtes Modell 10 durch iterativ anfragende Verbindungen 11a, 11b, 11c, 12a, 12b, 13a, 13b und/oder 31a für jedes Niveau der Hierarchie des spezifizierten Modells. Für jedes Modell werden die grundlegenden bzw. Basisanzeigestrukturen und Formen, die durch die Anfrage erhalten sind, auf ein xml File für ein Rendern ge schrieben. Eine beispielhafte Ausgabe dieser Erzeugung kann in 12 gesehen werden, welche die allgemeine Anzeigestruktur zeigt, aber keine Betriebsdatendetails.
Die Szenariomaschine 530 dient vorteilhafterweise zwei Zwecken. Während der anfänglichen Ladung einer Modellhierarchie ist die Szenariomaschine 530 für ein Etablieren der Tabelleneingänge bzw. -einträge und Verbindungen verantwortlich, die durch die oben beschriebene GUI Erzeugung verwendet werden. Während der Erzeugung von Szenarien stellt die Szenariomaschine 530 den Mechanismus zum Schreiben von detaillierten Eigenschaften und Auftreten von Knoten in die Attribut Tabelle 61 und Etablieren bzw. Aufbauen der Verbindungen zwischen diesen Details bereit (Verbindungen 12a, 13a, 13b, 13c, 62a). Die Szenariomaschine 530 schreibt auch die zugehörige Anzeigeinformation in die Mapping_class Tabelle 42, die Mapping Tabelle und/oder die Lov_group Tabelle 63 und stellt die Verbindungen zwischen ihnen her (Verbindungen 14a, 14b, 41a, 42b, 63a, 63b).
Die Visualisierungsmaschine 510 verwendet die iterativen Anfragen als die GUI Erzeugungsmaschine 520, aber greift für jeden Knoten auf die Attribut Tabelle 61 zu, indem eine Verbindung 13a verwendet wird, um die Merkmale (Anzahl von Auftreten, Labeltext, usw.) für eine Anzeige zu erhalten. Eine beispielhafte Ausgabe der Visualisierungsmaschine 510 kann in 13 und 14 gesehen werden. Da die Anzahl und Ausrichtung von Knoten der niedrigsten Niveauhierarchie zwischen den 13 und 14 abweicht, muß sich eine dynamische Modifikation des Raums, der sowohl der Form zugeteilt ist, die das niedrigste als auch nachfolgend höhere hierarchische Niveaus darstellt, ändern. Die Visualisierungsmaschine 510 handhabt diese dynamische Visualisierung, indem eine erneute Berechnung von unten nach oben des Anzeigebereichs für einzelne Formen bzw. individuelle Gestalten basierend auf der Anzahl eines Auftretens der Form (Verbindung 13b, 31a) durchgeführt wird, und bemißt die einzelnen Formen wie benötigt. Sobald einmal die gesamte Anzeige generiert bzw. erzeugt ist, wendet die Visualisierungsmaschine 510 den kundenspezifischen Skalierungsfaktor auf die Anzeige an, um die gewünschte Anzeigegröße zu erhalten.
Im Folgenden werden gemeinsame Merkmale, vorzugsweise von allen Tabellen innerhalb des Daten Modells beschrieben.
i. Künstlicher, generierter bzw. erzeugter Primärschlüssel
Alle Tabellen weisen einen primären bzw. Primärschlüssel auf, der vorzugsweise ein CHAR(20) Feld umfaßt. Dieser Schlüssel wird automatisch erzeugt und stellt eine Einzigartigkeit durch die gesamte Datenbank sicher (Beispiel: "DK-00000000-00002FAE"). Dieser Schlüssel wird auch verwendet werden, wenn Bezüge in einer eins-zu-eins oder eins-zu-vielen Beziehungen erzeugt werden (siehe beispielsweise 15(A)–(G)).
ii. Szenario Spalten
Jede Aufzeichnung weist vorzugsweise 3 auf eine Szenario bezogene Spalten auf ("Szenario_id" ("scenario_id"), "gültig_von" ("valid_from"), "gültig_bis" ("valid_to")), welche verwendet werden, um das Szenario zu identifizieren, zu dem die Aufzeichnung gehört. Szenarien werden über Views bzw. Ansichten gehandhabt.
iii. Einfache Audit Spalten
Jede Tabelle enthält vorzugsweise Spalten, um eine Audit Information zu geben ("erzeugt" ("created"), "erzeugt_durch" ("created_by"), "letztes Update" ("lastupdt"), "letztes Update_durch" ("lastupdt_by")), welche vorzugsweise automatisch ausgefüllt wird und ein gewisses Niveau von Auditing gibt. Zusätzlich könnte ein Vollniveau-Auditing-Mechanismus implementiert sein.
Im Folgenden ist eine detaillierte Beschreibung eines bevorzugten Daten Modells unter Bezugnahme auf 3 gegeben.
Das Daten Modell, das in der Datenbank 500/300 zu speichern ist, wird vorzugsweise gemäß der in 3 dargestellten Tabellenstruktur auf hohem Niveau implementiert. Das Daten Modell umfaßt vorzugsweise eine oder mehrere, vorzugsweise einen Satz von Modell Tabellen 10, die die hierarchische Darstellung des Modells, das evaluiert bzw. bewertet wird, die erlaubbaren Endpunkte (Knoten bzw. Nodes) dieser Darstellung und die physische Struktur des Modells (Domains) enthalten, welche in den Data Linked to Relationships Tabellen 60 (Tabellen von mit Beziehungen verknüpften Daten) enthalten ist. Die zugehörige Information von Graphical von Representation Tabellen 30 bzw. Tabellen graphischer Darstellung enthält gültige visuelle Konstrukte (wie beispielsweise Rechteck, Vielecke, Kreise, Ellipsen, Text, usw.) für das Modell. Die Mapping Relationship Tabellen 40 enthalten gültige Beziehungen zwischen den Modellen und ihren Komponenten (Knoten und/oder Domains). Die SQL Queries Tabellen 20 (SQL Anfragen Tabellen) enthalten die Information, die notwendig ist, um Anfragen auszuführen und/oder anzuzeigen und um eine Datenanalyse durchzuführen. Diese Tabellen regeln bzw. steuern die Daten, die von den Anzeigeeigenschaften abhängig sind. Die Data Detail und Entry Views Tabellen (Datendetails- und Eingabeansichts-Tabellen) 50 stellen Filterfunktionen bereit, um eine Dateneingabe und/oder Instandhaltung bzw. Wartung zu regeln bzw. zu steuern. Zusätzlich zu den Modell Struktur Daten enthalten die Data Linked to Relationships Tabellen 60 die kundenspezifischen detaillierten Attribute, die mit den Modellen assoziiert bzw. verbunden sind.
Starke Verbindungen innerhalb des Daten Modells erzeugen logische Einheiten umfassend, vorzugsweise bestehend aus einem spezifischen Modell, den Modell Attributen und/oder Attributdaten. Diese Verbindungen sind bzw. werden vorzugsweise während der Initialisierungsphase 100 spezifiziert und stellen die Basisanalyse und/oder den Visualisierungsrahmen bereit. Sobald sie einmal hergestellt sind, sind die starken Verbindungen ausgelegt, um einen Langzeitbestand aufzuweisen. Ein Ändern starker Verbindungen führt zur Erzeugung eines neuen Modells.
Lose Verbindungen erzeugen Beziehungen, die ausgelegt sind, um durch einen Benutzer modifizierbar zu sein. Änderungen in den losen Verbindungen stellen Änderungen oder vorgeschlagene Änderungen an der Architektur über die Zeit dar. Wenn lose Verbindungen gebrochen und/oder erneut hergestellt werden, erzeugt der Prozeß "gebrochene Verbindungen", welche eine Darstellung von früheren Modelldetails bereitstellen (historische Perspektive). Die starke Verbindung 10a zwischen den Modellen (Models) 10 und der graphischen Darstellung (Graphical Representation) 30 wird vorzugsweise während eines Imports von xml über die Szenariomaschine 530 erzeugt. Die starke Verbindung 10a bestimmt die graphische Implementierung eines spezifischen Modells. Die fakultative starke Verbindung 10b zwischen Modellen 10 und der graphischen Darstellung 30 kann verwendet werden, um eine oder mehrere unterschiedliche graphische Darstellung(en) desselben Modells anzufügen bzw. zu enthalten – mit der Fähigkeit, Information für ein unterschiedliches Niveau einer Analyse, beispielsweise abhängig von den jeweiligen Entscheidungsträgern zu filtern und/oder zusammenzustellen. Diese starke Verbindung(en) zwischen den Modell Tabellen 11–13 und den Tabellen einer graphischen Darstellung 31, 32 bestimmt die tatsächliche Form, die verwendet wird, um einen Modellknoten darzustellen. Diese Verbindung spezifiziert eine graphische Darstellung, welche definiert, wie ein Modell in seiner Gesamtheit angezeigt bzw. dargestellt werden wird. Die lose Verbindung 10d zwischen der(n) Modell Tabelle(n) 10 und der(n) Mapping Relationship Tabelle(n) 40 versieht den Benutzer mit der Flexibilität, um die logische Beziehung zwischen den Komponenten innerhalb eines Modells leicht zu verändern, neue Modellfunktionen usw. hinzuzufügen. Die lose Verbindung 10d bestimmt, welche Knotenpaare zusammen dargestellt werden können. Die fakultative starke Verbindung 10c zwischen der(n) Modell Tabelle(n) 10 und der(n) Data Linked to Relationships Tabelle(n) 60 regelt bzw. steuert oder definiert die Zuordnung von Betriebsdatendetails zu den Knoten des Modells. Wie beschrieben, erlaubt eine lose Verbindung dem Benutzer, den Dateninhalt zu ändern, ohne das Gesamtmodell zu beeinflussen. Die lose Verbindung 20a zwischen der SQL Queries Tabelle 20 und der(n) graphischen Representation Tabelle(n) 30 spezifiziert den Typ des Modells, der beim Anzeigen der Anfrageergebnisse zu verwenden ist. Die fakultative starke Verbindung 60b zwischen der(n) Data Detail und Entry Views Tabelle(n) 50 und der(n) Data Linked to Relationships Tabelle(n) 60 stellt Anzeigedetails für Modellknoten bereit. Die starke Verbindung 60a der Data Detail und Entry Views Tabelle(n) 50 und der Data Linked to Relationships Tabelle(n) 60 kann durch SQL Anfragen verwendet werden, um detaillierte Anzeigeattribute mit Anzeigestrukturen zu verbinden, wobei ein Zugriff auf die Eigenschaften bereitgestellt wird, die für jeden Knoten angezeigt werden können.
Im Folgenden werden die bevorzugten Tabellen-Struktur-Details für das Handhaben von Modellen unter Bezugnahme auf 4 beschrieben.
Vorzugsweise umfaßt die Modell Tabelle 10 eine Modell Tabelle 11, die die Hauptattribute des Modells enthält, wie den Namen, Type bzw. Art und Version des Modells. Ein fakultatives Kommentarfeld kann das Modell beschreiben (siehe 15(A)).
Außerdem umfaßt die Modell Tabelle 10 eine Node_Class Tabelle 12, die Information betreffend die Typen bzw. Arten von Knoten enthält, die das Modell enthält (siehe 15(B)). Die Node_Class Tabelle 12 enthält vorzugsweise einen Eintrag für jede Art von Knoten innerhalb des Modells und dient als ein Ankerpunkt für die entsprechenden Domäneneinträge. Ein Node Class Name identifiziert vorzugsweise den Zweck des Knotens, dient aber hauptsächlich für Informationszwecke (keine semantische Bedeutung). Kernattribute der Node_Class Tabelle 12 enthalten die row_id des Modells und eine einzigartige ID, die die Node Class bzw. Knoten Klasse identifiziert.
Die Modell Tabelle 10 umfaßt weiterhin eine Node Tabelle 13, die die Definition jedes Knotens innerhalb des Modells und die Information der entsprechenden Hierarchie des Knotens enthält (siehe 15(C)). Die Node Tabelle 13 definiert jeden Knoten des Modells mit der einzigartigen_ID bzw. unique_ID und der Hierarchieinformation, wobei jeder Knoten eine Verbindung mit einem Node_Class Eintrag besitzt, um seine Datenelemente zu bestimmen. Die Node Tabelle 13 umfaßt vorzugsweise die folgenden Attribute: ein "Modell_rid", das die row_id des Modells enthält, zu dem der Knoten gehört, eine "node_class" spezifizierend den Typ des Knotens, eine "unique_id", die den Knoten identifiziert (hat innerhalb des Modells einzigartig zu sein), eine "hierarchy_id" ("Hierarchie_id"), die die Position des Knotens in dem Baum spezifiziert und die unique_id des Elternknotens und/oder Benutzerinformation, wie Knotenbenutzertyp, Anzeigename, welcher bei einer Modellerzeugung definiert ist bzw. wird und für benutzerspezifische Zwecke verwendet werden kann.
Die Data Linked to Relationships Tabelle(n) 60 umfaßt (umfassen) vorzugsweise eine Domain Tabelle 62, welche definiert, welche Datenelementtypen zu einem Knoten oder zu einer Darstellung gehören können, und die Datenstrukturen definiert, die innerhalb des Modells gespeichert sind (siehe 15(G)). Die Domain Tabelle 62 definiert den Typ von Datenelementen, welche entweder zu einem Knoten oder einer Darstellung bzw. einem Mapping gehören. Dies ist eine der Haupteinheiten bzw. -entitäten, um die Datenstrukturen zu definieren, die in den Modellen gespeichert sind. Die Domain Tabelle 62 umfaßt vorzugsweise die folgenden Attribute: Ein "attribute_name" Attribut, welches die einzigartige Identifizierung für den Domäneneintrag ist, ein "data_type" bzw. "Daten_Typ" Attribut, welches spezifiziert, welcher Typ von Daten gespeichert ist bzw. wird, wobei Datentypen sein können "string" bzw. "Kette", "double" bzw. "doppelt", "lov" (List of predefined Values, Liste von vordefinierten Werten), "set" bzw. "festgelegt", "dictionary" bzw. "Wörterbuch" (Schlüsselwertpaare), "Object" (eine Bezugnahme auf ein Objekt), ein "attached_to" bzw. "angefügt_an" Attribut, welches spezifiziert, ob die Domäne zu einem Knoten oder einer Objekt-Knoten-Darstellung gehört, wobei abhängig von diesem Wert der Bezug bzw. die Referenz die Row ID einer node_class oder einer mapping_class enthält, und/oder andere Attribute, wie Anzeigename, mehrere Flags und/oder das "edit_field", die Handhabung der Daten definieren.
Vorzugsweise umfaßt (umfassen) weiterhin die Data Linked to Relationships Tabelle(n) 60 weiterhin eine Attribut Tabelle 61, die die tatsächlichen bzw. aktuellen Betriebsdaten enthält, die an den Knoten oder die Darstellung angefügt sind (siehe 15(F)). Die Attribut Tabelle 61 umfaßt vorzugsweise die folgenden Attribute: ein "Domain" Attribut, das den Datentyp für diesen Wert definiert, wobei eine Referenz bzw. ein Bezug entweder die row id des Knotens oder der Darstellung ist (abhängig davon, ob die Domäne an einem Knoten oder an die Darstellung angefügt ist), ein "complex_key" Attribut, das verwendet wird für "array" und "dictionary" Datentypen und/oder ein "Value" bzw. "Wert" Attribut, das einen textlichen Wert enthält, im Fall von numerischen Werten enthält das "value_num" Feld eine "dezimale" Darstellung, die in Zusammenstellungsfunktionen (beispielsweise Summe) zu verwenden ist.
Die Graphical Representation Tabelle 30 umfaßt vorzugsweise eine Display Tabelle 31, die eine graphische Darstellung einer spezifischen Ansicht des Modells definiert. Mit anderen Worten regelt bzw. steuert die Display Tabelle 31 die unterschiedlichen graphischen Darstellungen eines Modells. Zahlreiche Ansichten eines Modells werden durch ein Filtern der Anzeigeinformation erzielt (siehe 15(D)). Eine der Anzeigen, die innerhalb der Display Tabelle 31 definiert ist, sollte vorzugsweise als Defaultanzeige des Modells definiert sein. Die Display Tabelle 31 umfaßt vorzugsweise die folgenden Attribute: eine "unique_id" der Anzeige, ein Flag, das spezifiziert, ob die Anzeige die Defaultanzeige ist und/oder eine fakultative Beschreibung der jeweiligen Anzeige.
Außerdem umfaßt die Graphical Representation Tabelle 30 vorzugsweise eine Shape Tabelle 32, die graphische Parameter definiert, die benötigt werden, um Knoteninformation anzuzeigen. Diese Information beinhaltet vorzugsweise die Spezifikation von Position, Größe und Form und Hintergrundspezifikationen (siehe 15(E)). Mit anderen Worten die Shape Tabelle 32 definiert vorzugsweise die graphische Darstellung der Knoten als auch die graphische Darstellung der Hintergrundformen, wobei die unterstützten Typen einer graphischen Darstellung vorzugsweise "Rechteck" ("Rectangle"), "Text" und "freie Form" ("Freeform") (Mehrpunktpolygon). Die Shape Tabelle 32 umfaßt vorzugsweise die folgenden Attribute: eine "model_id" bzw. "Modell_id", zu der die Form gehört und die row id des Knotens, die die Form nicht repräsentiert, ein Flag, das spezifiziert, ob die Form eine Hintergrundform ist, eine Position, Größe und/oder Farbe der Form für ein Wiedergeben bzw. Rendern, und/oder ein fakultatives Label (das für "Text" und Hintergrundformen) verwendet wird.
Wie beschrieben, basiert das Application Management Visualisation Framework gemäß der bevorzugten Ausführungsform auf dem einen oder den mehreren Modell(en), und die Modellinformation, die in diesen Tabellen enthalten ist, ist stark zusammen verbunden bzw. gekoppelt, um eine konsistente bzw. in sich geschlossene logische Perspektive zu bauen von dem, was das Modell darstellt. Die starke Verbindung 11a zwischen dem Modell 11 und den Node_Class Tabellen 12, die starke Verbindung 12b zwischen der Node Tabelle 13 und der Node_Class Tabelle 12 und/oder die starke Verbindung 11b zwischen der Modell Tabelle 11 und der Node Tabelle 13 etablieren bzw. stellen die Basismodellstruktur her. Zusammen definieren die starken Verbindungen 11a, 11b und 12b über diese drei Tabellen 11–13 die Gesamtstruktur des Modells. Eine fakultativ starke Verbindung 12a zwischen der Node_Class Tabelle 12 und den Domain Tabellen 62 steigert diese Basisstruktur mit den Typen von Daten, die an einen Knoten oder eine Anpassung angefügt werden können. Eine starke Verbindung 62a zwischen der Domain Tabelle 62 und der Attribut Tabelle 61 spezifiziert, welcher Typ von Daten das Attribut ist. Eine fakultative starke Verbindung 13a zwischen der Node Tabelle 13 und der Attribut Tabelle 61 etabliert den einzigartigen Knoten oder die Darstellung, zu welchem(r) die Attributdaten gehören. Um die Visualisierung von unterschiedlichen Ansichten an einem Modell zu unterstützen, richtet die starke Verbindung 11c zwischen der Display Tabelle 31 und der Modell Tabelle 11 die unterschiedlichen graphischen Darstellungen mit dem Modell aus bzw. koordiniert sie. Die starke Verbindung 11c stellt auch vorzugsweise einen Mechanismus zum Filtern der Modellanzeige bereit, um unterschiedliche Ansichten an den Modelldaten bereitzustellen.
Bevorzugte Tabellen-Struktur-Details für die Handhabung von Darstellungen bzw. Mappings werden unter Bezugnahme auf 5 beschrieben.
Allgemein gesprochen, beziehen sich Darstellungen auf die möglichen Beziehungen, die zwischen Knoten des Modells existieren. Da nicht alle Knoten eines Modells zueinander dargestellt werden können, wird ein Mechanismus benötigt, um das Etablieren bzw. Herstellen dieser Beziehungen zu regeln bzw. zu steuern. Zusätzlich zu der Node Tabelle 13, der Node_Class Tabelle 12, der Domain Tabelle 62 und der Attribut Tabelle 61 umfaßt zum Etablieren bzw. Aufbauen des Knotens zu Knotenbeziehungen die Modelltabelle 10 die folgenden vier zusätzlichen Tabellen:
Eine Nclass_Group Tabelle 14 definiert eine Gruppe von node_classes bzw. Knoten_Klassen, welche den Pool bzw. Vorrat an möglichen Knoten innerhalb einer Darstellung bauen. Diese Einheit bzw. Entität erlaubt eine Hierarchie von Knoten_Klassen, von welcher jede ein Glied einer Darstellung sein kann. Beispielsweise gibt es verschiedene Knoten_Klassen in dem Anwendungsmodell (Anwendungen, externe Anwendungen und Infrastruktur-Anwendungen). Für eine auf Kosten bezogene Darstellung sind externe Anwendungen nicht relevant und sollten nicht fähig sein, Teil dieser Darstellungen zu sein. Externe Anwendungen sind für auf Interface bzw. eine Schnittstelle bezogene Darstellungen relevant, während sie für Infrastruktur-Anwendungen es nicht sind.
Eine mapping_class Tabelle 42 definiert die verschiedenen Mapping- bzw. Darstellungstypen von Darstellungen zwischen den Knoten von bestimmten node_classes und die Domänen für jeden Darstellungstyp. Die mapping_class Tabellen Eingänge spezifizieren vorzugsweise, welche 2 node_classes in einer Darstellung teilnehmen (siehe 15(H)). Die mapping_class Tabelle 42 umfaßt die einzigartige_id und den Typ des Modells der zwei node_classes als bevorzugte Attribute bzw. Eigenschaften.
Eine Mapping Tabelle 41 enthält die möglichen viele-zu-viele-Beziehung-Einträge zwischen den Modellknoten, und auch die Beziehungen zwischen unterschiedlichen Modellen (siehe 15(I)). Die Mapping Tabelle 41 enthält vorzugsweise eine n:m-Beziehung (viele-zu-viele-Beziehung) Einträge zwischen Modellknoten, auch von verschiedenen Modellen. Die Darstellung an den Knoten wird vorzugsweise über die einzigartige ID des Knotens und den Modell-Typ durchgeführt, nicht über die row_id des Knotens. Dies erlaubt die Handhabung von Modell-Aktualisierungen (neue Knoten, Änderung der Knotenpositionen, Knotensplitting, usw.). Eine "Speedlink" bzw. "Schnellverbindungs"-Spalte wird vorzugsweise verwendet, um einen schnelleren (Einzelspalten-)Zugriff auf die Darstellung zu erlauben. Die Mapping Tabelle 41 umfaßt die unique_id und den Typ des Modells der zwei Knoten als bevorzugte Attribute. Eine Lov_groups bzw. Lov_Gruppen Tabelle 63 enthält vordefinierte Codier-Dekodier-Paare, welche die fixierten fakultativen Werte für Datenelemente spezifizieren (siehe 15(J)). Die Codier-Dekodier-Paare sind vorzugsweise in geordneten Gruppen für Sätze fixierter Werte. Diese Daten sind für eine Benutzerauswahl während einer Dateneintragung verfügbar, um sicherzustellen, daß nur gültige Attributdaten in die Datenbank eingegeben werden. Mit anderen Worten, die Lov_Gruppen Tabelle 63 enthält vordefinierte Codier-Dekodier-Paare, welche als Werte eines festgelegten Satzes in Datenelementen verwendet werden können. LOV Gruppen sind vorzugsweise unter Verwendung von Drop-Down-Listboxes einzugeben. Außerdem werden LOV's auch in Wörterbuchdatentypen als Schlüssel für die benannten Schlüssel-Wert-Paare verwendet. Die Lov_Gruppen Tabelle 63 umfaßt vorzugsweise die folgenden Attribute: eine einzigartige Identifizierung der LOV Gruppe und der Reihenfolge des LOV Eintrags innerhalb der Gruppe (wird verwendet, um die Einträge in der List Box bzw. dem Verzeichniskasten zu ordnen), einen Code und eine Decodierung (ein Code wird in der Attributtabelle gespeichert, die Decodierung wird dem Benutzer präsentiert) und/oder einem fakultativen Kommentar.
Eine fakultative starke Verbindung 41a zwischen der Mapping Tabelle 41 und der Attribut Tabelle 61 spezifiziert die Attribute einer Darstellung in einer analogen Art und Weise zur Spezifikation von Attributen für Knoten. Eine fakultative starke Verbindung 42b zwischen der Mapping_class Tabelle 42 und der Domain Tabelle 62 spezifiziert die Domänen, die innerhalb einer Mapping- bzw. Darstellungsklasse enthalten sind. Diese Domänen können entweder knotenspezifisch oder darstellungsspezifisch sein.
Da sich die Beziehung zwischen Knoten unter verschiedenen Szenarien ändern kann, sind bzw. werden die Node Tabelle 13 und die Mapping Tabelle 41 über eine oder mehrere lose Verbindung(en) 13b, 13c vereinigt oder verbunden, um eine Verwendbarkeit bzw. Brauchbarkeit und Flexibilität zu steigern. Es gibt vorzugsweise zwei lose Verbindungen 13b, 13c zwischen der Mapping Tabelle 41 und der Node Tabelle 13.
Diese losen Verbindungen 13b, 13c definieren die Beziehungen zwischen zwei Knoten, und unterstützen das Aufbauen von viel-zu-viel-(n:m)-Beziehungen zwischen Knoten. Ähnlich zu diesen zwei losen Verbindungen 13b, 13c sind die losen Verbindungen 14a und 14b zwischen der Nclass_group Tabelle 14 und der Mapping_class Tabelle 42. Diese losen Verbindungen 14a und 14b definieren, welche Knoten_Klassen Paare in einer Darstellung sein können, und unterstützen das Bauen von viel-zu-viel-Beziehungen zwischen Knoten_Klassen. Eine starke Verbindung 14c zwischen der Node_class Tabelle 12 und der Nclass_group Tabelle 14 definiert, welche node_class Typen eine Gruppe definieren. Eine lose Verbindung 42a zwischen der Mapping_class Tabelle 42 und der Mapping Tabelle 41 definiert die unterschiedlichen Darstellungstypen, die verfügbar sind, und eine fakultative starke Verbindung 42b zwischen der Mapping_class Tabelle 42 und der Domain Tabelle 62 stellt die Domäne für jede Darstellung bereit. Zwei fakultative lose Verbindungen 63a und 63b zwischen der Attribut Tabelle 61 und der Lov_groups Tabelle 62 definieren vorzugsweise die gültigen Werte, die durch Benutzer während einer Dateneingabe ausgewählt werden können. Primitive Attribute können einen Wert eines Lov_groups Gegenstands enthalten (fakultative lose Verbindung 63a). Wörterbuchattribute können einen Schlüssel von einem Lov_groups Gegenstand enthalten (fakultative lose Verbindung 63b).
Im Folgenden werden bevorzugte Tabellenstrukturdetails für die Handhabung von Anzeige- und/oder Edit-Funktionen unter Bezugnahme auf 6 beschrieben.
Die Tabellen für die Handhabung von Anzeige- und/oder Edit-Funktionen enthalten vorzugsweise die Information, die be nötigt wird, um Detailinformationsseiten geeignet anzuzeigen.
Eine Range Tabelle 22 enthält Information, die regelt bzw. steuert, welche Farbe die Formen bzw. Gestalten aufweisen sollten, wenn Anfrageergebnisse angezeigt werden (siehe 15(K)). Unterstützt werden sowohl numerische Bereiche als auch textliche Bereiche. Im Fall eines textlichen Bereichs wird der rückgeführte bzw. rückgegebene Wert mit dem spezifizierten Schlüssel unter Verwendung von Standardoperatoren verglichen (gleich, nicht_gleich, beginnt_mit, niedriger_als, usw.). Die resultierende Farbe wird verwendet, um die entsprechende Form zu verleihen bzw. zu rendern. Die Range Tabelle 22 umfaßt vorzugsweise die folgenden Attribute: Information, um den Bereichsgegenstand zu identifizieren (range_group bzw. Bereichs_Gruppe, item_order bzw. Gegenstands_Reihenfolge, unique item_name bzw. Name des einzigartigen Gegenstands) und/oder Rang Information (niedrig/hoch Werte, Schlüsselwert, Keystring-Operator und die Formfarbe).
Eine Query Tabelle 21 enthält alle Information, die notwendig ist, um das Ergebnis eines SQL Statements in einem Modell anzuzeigen (siehe 15(L)). Das SQL Statement ist vorzugsweise als Text gespeichert, muß aber strikten Konventionen bzw. Vereinbarungen folgen, um sicherzustellen, daß das Anfrageergebnis exakt bzw. genau die Anzahl und Typen von Spalten enthält, die notwendig sind, um durch die Anwendung geeignet bzw. richtig bearbeitet zu werden. Die Query Tabelle 21 umfaßt vorzugsweise die folgenden Attribute: Information zum Regeln bzw. Steuern der Anzeige der Ergebnisse, indem das Modell spezifiziert wird, die Attribute, welche als Label bzw. Markierung verwendet werden und/oder Popups für die Formen als auch die Drill-Down URL und die Anzeigegröße, und die Range- bzw. Bereichsgruppe und das SQL Statement und/oder ein fakultativer Kommentar.
Eine lose Verbindung 31b zwischen der Query Tabelle 21 und der Display Tabelle 31 spezifiziert, welcher Typ von Modell zu verwenden ist, um die Ergebnisse einer SQL Anfrage anzuzeigen. Eine lose Verbindung 22a zwischen der Range Tabelle 22 und der Query Tabelle 21 wird vorzugsweise während oder zum Rendern von Anfrageergebnissen verwendet, um die Anzeigewerte der Modellformen zu bestimmen.
Eine Widget Tabelle 52 enthält all die Information, die notwendig ist, um das Layout und den Inhalt bzw. Content der Knoten zu regeln bzw. zu steuern, die auf der Detailebene einer Baumseite angezeigt sind. Eine Tree Tabelle 51 enthält die Information, die notwendig ist, um eine Baumseite in Verbindung mit der Widget Tabelle 52 zu bauen. Die Tree Tabelle 51 enthält eine Aufzeichnung für jede Detail/Edit-Seite in dem System. Die Haupt-"Logik" der Tree Tabelle 51 wird durch das SQL Statement bestimmt, das in dieser Tabelle enthalten ist, die eine lose Verbindung 51b zu der Attribut-Tabelle 61 erzeugt. Dieses SQL Statement muß Aufzeichnungen zurückführen, welche die Knoten des Baums definieren (beispielsweise Label bzw. Markierung, Position, Eltern, usw.), als auch die Information, die notwendig ist, um die Daten des Knotens/Darstellung wiederzuerlangen, anzuzeigen und zu aktualisieren, welche durch den Baumknoten repräsentiert bzw. dargestellt wird. Das SQL Statement wird vorzugsweise als Text gespeichert, muß aber strikten Konventionen folgen, um sicherzustellen, daß das Anfrageergebnis exakt bzw. genau die Anzahl und Typen von Spalten enthält, die notwendig sind, um durch die Anwendung geeignet bearbeitet zu werden.
Auf ähnliche Weise sind die Aufzeichnungen in der Node Tabelle 13 und der Widget Tabelle 52 nicht direkt über eine starke oder lose Verbindung verbunden, sondern müssen mittels einer losen SQL Verbindung 13d verbunden sein bzw. werden, welche SQL Statements verwendet, die in der Tree Tabelle 51 enthalten sind. Dieses SQL Statement der losen SQL Verbindung 13d ist zu erhalten, indem die lose Verbindung 51a zwischen der Tree Tabelle 51 und der Widget Tabelle 52 verwendet wird. Wegen dieser SQL basierten losen Verbindungen 13d ist es ausschließlich die Verantwortlichkeit des Administrators sicherzustellen, daß die Widget Information korrekt ist. Wenn der Widget Gegenstand eine Domäne ist, dann gibt es eine fakultative starke Verbindung 62b zu der entsprechenden Domäin Tabelle 62. Zusammen mit der Information darüber, welcher Knoten (in dem Baum) durch den Benutzer ausgewählt worden ist, können die Daten von der Attribut Tabelle 61 wiedererlangt werden und in dem Detailfeld angezeigt werden.
Das Application Management Visualisation Framework wird vorzugsweise durch bis zu 3 Anwendungsmaschinen und/oder mehrere gemeinsame Funktionen unterstützt. Diese Anwendungsmaschinen sind:

a. Eine graphische Benutzer-Interface-(GUI) Erzeugungsmaschine 520, welche für die Erzeugung von dynamischen Anzeigeschablonen verantwortlich ist, basierend auf Modell, Meta Modell und/oder Meta Daten, die in der Datenbank gespeichert sind. Basierend auf der Komplexität des Meta Modells und den Modell-Daten-Strukturen ist diese Erzeugung von Anzeigeschablonen notwendig, um eine adäquate Systemleistung zu erzielen.
b. Eine Visualisierungsmaschine 510, welche für ein Erzeugen von Visualisierungen von Modellen verantwortlich ist, und wenn gewünscht Benutzeranfragen ausführt und/oder die Anfrageergebnisse mit den geeigneten Schablonen für eine Anzeige verschmilzt. Die Visualisierungsmaschine regelt bzw. steuert auch vorzugsweise das dynamische Skalieren einer visuellen Ausgabe.
c. Eine Szenariomaschine 530, welche für die Erzeugung und/oder Instandhaltung bzw. Wartung von modellgraphischen Darstellungen von Modellen verantwortlich ist und/oder an diesen filtert.

Die hierin unten erklärten gemeinsamen Funktionen werden vorzugsweise durch alle drei Maschinen 510, 520, 530 verwendet, um wiederholte Aufgaben durchzuführen.
Im Folgenden wird ein bevorzugter Arbeitsfluß für die graphische Benutzer-Interface-(GUI) Erzeugungsmaschine 520 unter Bezugnahme auf 7 beschrieben.
Die GUI Erzeugungsmaschine 520 wird ausgelöst, nachdem ein Modell anfänglich über die Szenariomaschine 510 geladen worden ist oder wenn die fortlaufende Instandhaltung bzw. Erhaltung bzw. Wartung der Modelle innerhalb der Datenbank 300/500 zu einem neuen Modell führt, das erzeugt wird. Als Eingabe an den Erzeugungsprozeß wird das geeignete Modell ausgewählt 520a, und basierend auf diesem Modell werden die Anzeigeparameter festgelegt 520b. Für das ausgewählte Modell werden die Formen bzw. Gestalten, die an das Modell angefügt sind (zugegriffen über die starken Verbindungen 11c und 31a) iterativ von der entsprechenden Display Tabelle 31 und/oder Shape Tabelle 32 gelesen 520c, die in der Datenbank 300/500 gespeichert sind. Wenn die Formen gelesen sind bzw. werden, werden die erlaubbaren Formattribute aus der Attribut Tabelle 61 über die losen Verbindungen 13b und 13a gelesen. Dann werden die Formdaten und Formattributdaten auf ein Ausgabefile geschrieben 520d, vorzugsweise ein Ausgabe xml File. Wenn diese Lese/Schreib-Schleife alle Formen in bezug auf das ausgewählte Modell be- bzw. verarbeitet hat, wird das Ausgabe (xml) File verwendet, um eine (vorzugsweise html) GUI Schablone zu erzeugen, 520e, welche durch die Visualisierungsmaschine 510 verwendet werden wird, um die Anfrage und/oder Analyseergebnisse anzuzeigen. Probe (html) GUI Schablonen sind in 11 und 12 gezeigt. Die GUI Schablonen, die durch die GUI Erzeugungsmaschine 520 erzeugt sind (beispielsweise wie in 11 und 12 gezeigt) beinhalten eine Mehrzahl von hierarchischen Niveaus H1, H2, H3, usw., welche die Daten oder Information hierarchisch strukturieren. Beispielsweise bezieht sich in 11 eine erste (höchste) Hierarchie H1 auf eine Anzahl von IT Organisatorischen Gruppen, eine zweite Hierarchie H2 bezieht sich auf spezifische funktionelle Bereiche, für welche eine Gruppe (H1) verantwortlich ist, und eine dritte Hierarchie H3 bezieht sich auf die spezifischen Anwendungen App1, App2, App3, usw., die entwickelt worden sind. Elemente der niedrigeren Hierarchien können auch zwei oder mehreren Niveaus höherer Hierarchie zugeordnet werden (siehe beispielsweise den "Funktionellen Bereich 8" des zweiten Hierarchieniveaus H2, der der "IT Organisatorischen Gruppe 4" und der "IT Organisatorischen Gruppe 5" des ersten Hierarchieniveaus H1 zugeordnet ist, und die "Appl 57" des dritten Hierarchieniveaus H3, die der "IT Organi satorischen Gruppe 4" und der "IT Organisatorischen Gruppe 5" des ersten Hierarchieniveaus H1 zugeordnet wird). Die Hierarchieniveaus H1, H2, H3 usw. umfassen wenigstens teilweise vorzugsweise einen Namen, der den Benutzer spezifiziert, auf welchem sich das spezifische Element bezieht (beispielsweise "IT Organisatorische Gruppe 1", oder "Verkauf & Kundenservice"). Selbst obwohl sich in 11 das erste Hierarchieniveau H1 auf IT Organisatorischen Gruppen bezieht, sollte verstanden werden, daß sie sich auf andere Elemente einer Architektur oder Struktur beziehen kann, die zu analysieren ist, wie beispielsweise

i) organisatorische Geschäftseinheiten (beispielsweise Verkauf und Kundenservice, Produktion, Management von Partnerkooperation, allgemeine Geschäftsaktivitäten, Support- bzw. Unterstützungsfunktionen, Managementinformation usw. für das hierarchische Niveau H1) und Sub- bzw. Untereinheiten (beispielsweise "Personalisation", "Kontrolle von Kundeninteraktion", "allgemeine Unterstützung für Kundenservice", "Verkaufskampagnenmanagement", "Ausnahmenhandhabung", usw. für das hierarchische Niveau H2) und spezifische Prozesse innerhalb der Untereinheiten (beispielsweise "Kundenprozeßfluß", "Einstellung bzw. Aufbau des Systemzugriffs", "Verkaufsprozesse", "Verkaufsmanagement", "Verkaufsunterstützung", "Korrespondenzmanagement", "Transaktions- bzw. Abwicklungsmanagement", "Handhabung von Kundenanfragen", usw. für das dritte hierarchische Niveau H3), usw.,
ii) spezifische Automobilfabrikate (beispielsweise BMW 328i, Rover Mini, usw. für das erste hierarchische Niveau H1), Komponenten eines spezifischen Kraftfahrzeugs (beispielsweise Motor, Aufhängung, Räder, Fahrzeugkörper bzw. -karosserie, Innenelemente, usw. für das zweite hierarchische Niveau H2), Sub- bzw. Unterkomponenten (beispiels weise Motorteile, Aufhängungsteile, Reifen, Felgen, Körperrahmen, Türen, Sitze, Instrument- bzw. Armaturenbrett, Sicherheitssysteme, usw. für das dritte hierarchische Niveau H3), und die zugehörige Information (beispielsweise Lieferant(en), Kosten, allgemeines/kundenspezifisches Teil, usw. würden Attribute dieses dritten hierarchischen Niveaus sein, die angefragt und angezeigt sein können,
iii) Produktionseinrichtungen, beispielsweise für ein Fahrzeug (beispielsweise Motorherstellung, Fahrzeugkörperherstellung, Zusammenbau, Lackierlinie, Endkontrolle für das erste hierarchische Niveau H1), Subeinheiten (beispielsweise maschinelle Bearbeitung des Motorblocks, maschinelle Bearbeitung des Motorkopfs, Aufbauen der Motorkontrolleinheit, Zusammenbauen des Motors, usw. für das zweite hierarchische Niveau H2), Maschinen, die in Subeinheiten verwendet werden (beispielsweise Bohrmaschine, Gießmaschine, Formmaschine usw. für das dritte hierarchische Niveau H3), assoziierte Information und Daten (beispielsweise Lieferant(en), Kosten, allgemeine(kundenspezifische Maschine, Produktionsgeschwindigkeit, Kompatibilität/Inkompatibilität mit anderen Maschinen, usw. würden Attribute dieses dritten hierarchischen Niveaus H3 sein, die angefragt und/oder angezeigt usw. sein können, oder
iv) Softwareanwendungen (beispielsweise MS Office, Lotus123, Staroffice usw. für das erste hierarchische Niveau H1), wobei die Ausgabe gehört zu (Standard Edition bzw. Ausgabe, Small Business Edition, Professional Edition usw.) Version, usw. für das zweite hierarchische Niveau H2), Programme innerhalb der Anwendung (beispielsweise MS Word, Powerpoint, Excel, Outlook usw. für das dritte hierarchische Niveau H3), Typen von Funktionen, die enthalten sind (beispielsweise Wordprocessing bzw. Textverarbeitung, Bildgebung bzw. -rendern, Tabellenberechnung, Email management, Adreßmanagement usw. für das vierte hierarchische Niveau H4), usw. und assoziierte Information (beispielsweise Kosten, Copyright-Lizenz-Typ, usw.) würden Attribute sein, die angefragt und/oder angezeigt sein können.

Im Folgenden wird ein bevorzugter Arbeitsablauf für den Arbeitsablauf der Visualisierungsmaschinen 510 unter Bezugnahme auf 8 beschrieben.
Der Visualisierungsprozeß wird eingeleitet 510a, wenn ein Benutzer entweder ein Modell oder eine Anfrage für eine Anzeige zusammen mit der Auswahl einer Ausgabegröße auswählt. Basierend auf diesen Eingaben leitet die Visualisierungsmaschine 510 die zugrunde liegende Anzeigestruktur ein 510b, indem iterativ Schleifen durch die starken Verbindungen 11c, 31a über die Modell Tabelle 11, die Display Tabelle 31 und die Shape Tabelle 32 gemacht werden, um die Formen zu erhalten, die anzuzeigen sind, und diese Daten auf ein XML File geschrieben werden (Schritte 510k–510o). Die Parameter, die benötigt werden, um das Modell zu rendern, werden dann in Schritt 510c festgelegt. In Schritt 510d werden die Hintergrundformen und/oder Freeform- bzw. Freiform-Grenzpunkte aus der Shape Tabelle 32 gelesen. Basierend auf der Anzahl von Formen, die anzuzeigen sind, und der zugehörigen Information aus der Display Tabelle 31 wird der maximale Ausdehnungs- oder Skalierfaktor der Ausgabeanzeige vorzugsweise auch in Schritt 510d berechnet. In Schritt 510e liest die Visualisierungsmaschine 510 die Kartenformen für jeden Knoten, der eine Formdarstellung aufweist, über die fakultative starke Verbindung 13b und/oder Popup- und Label- bzw. Markierungsattribute für diese Formen. Bei diesem Punkt wurde die graphische Infor mation, die benötigt wird, um das Modell anzuzeigen, im wesentlichen erhalten und bearbeitet.
Wenn der Benutzer ein Modell für eine Anzeige in Schritt 510a verlangt hat, dann wird diese Information zu einem File, vorzugsweise einem xml File (510g) für eine Anzeige gesandt. Wenn ein Anfrageergebnis gewünscht wird, dann konstruiert die Visualisierungsmaschine 510 das notwendige SQL Statement (510h) und führt es aus, um die rohen Modell Daten aus der Attribut Tabelle 61 und der Node Tabelle 13 (über die fakultative starke Verbindung 13a) für eine Anzeige wiederzuerlangen. Basierend auf den Modelldaten, die in Schritt 510h zurückgeführt sind, erlangt die Visualisierungsmaschine 510 in Schritt 510i die geeigneten Anzeige-Attribute aus der Attribut Tabelle 61 und der Domain Tabelle 62 (über die starke Verbindung 62a), und legt die korrekten Anzeigeparameter (Farbe, Ausgabe, usw.) basierend auf diesen Daten für jede Form fest, die anzuzeigen ist. Sobald einmal vorzugsweise alle Anzeigeknoten bearbeitet worden sind, werden die Ergebnisse auf ein (vorzugsweise xml) File für eine Anzeige geschrieben 510j. Eine Musteranfrageanzeige ist in 13 gezeigt. Demgemäß erzeugt beginnend von den GUI Schablonen, die durch die GUI Erzeugungsmaschine 520 erzeugt sind, die Visualisierungsmaschine 510 spezifische Szenarien unter Verwendung der Hierarchieinformation, insbesondere der hierarchischen Niveaus H1, H2, H3 usw., die durch die GUI Erzeugungsmaschine 520 erzeugt sind. Beispielsweise ist in den in 13 und 14 gezeigten Szenarien eine Analyse von funktionellen Redundanzen für spezifische Cluster gegeben: in 13 sind beispielsweise für das Element des hierarchischen Niveaus H1, das sich auf ein "Verkaufs- und Kundenservice" bezieht (nicht in 13 und 14 gezeigt), das Element "Kunden prozeßfluß" des zweiten hierarchischen Niveaus H2 sechs Elemente (beispielsweise spezifische Anwendungen oder Funktionen) des dritten hierarchischen Niveaus H3 gegeben. Basierend auf den in Visualisierungsprozeß erhaltenen Ergebnissen wird ein Element eines vierten hierarchischen Niveaus H4 für jedes Element (beispielsweise spezifische Anwendungen oder Funktionen) des dritten hierarchischen Niveaus H3 hinzugefügt, wobei das Element des vierten hierarchischen Niveaus H4 beispielsweise die Anzahl von Malen ist, wie oft eine spezifische Anwendung oder Funktion implementiert ist (beispielsweise "6" für die am weitesten rechts befindliche Funktion innerhalb des Elements "Kundenprozeßfluß"). Wenn online betrachtet, können die detaillierten Attribute für die angezeigte Information in einem Popup- bzw. Hochziehfenster, vorzugsweise unter Verwendung einer (beispielsweise Standard html) "on mouse over" Funktionalität betrachtet werden. Ein Plazieren des Mauscursors über die am weitesten rechts befindliche Funktion innerhalb des Elements "Kundenprozeßfluß" würde in der automatischen Anzeige der 6 Anwendungsnamen resultieren, die diese Funktion implementieren.
In einigen Fällen variiert die Anzahl von Knoten, die anzuzeigen sind, von Szenario zu Szenario, wobei dies potentielle bzw. mögliche Änderungen in der Architektur reflektiert. Um diese Veränderungen aufzunehmen, ändert die Visualisierungsmaschine 510 die relative Größe der Formen, die verwendet werden, um die hierarchischen Niveaus über den Knoten darzustellen, basierend auf Eingaben, die mittels der GUI Erzeugungsmaschine 520 erhalten sind. Ein Beispiel der dynamischen Natur des Visualisierungsprozesses kann durch ein Vergleichen von 13 und 14 gesehen werden. Hier ist bzw. wird das untere Element (bei spielsweise spezifische Anwendung oder Funktion) des hierarchischen Niveaus H3 "Kundenprozeßfluß" in 13 in zwei Elemente (beispielsweise mehr verfeinerte spezifische Anwendung oder Funktion) des hierarchischen Niveaus H3 in 14 gespalten, wobei Elemente des vierten hierarchischen Niveaus H4 für jedes neu erzeugte oder gespaltene Element des dritten hierarchischen Niveaus H3 hinzugefügt sind bzw. werden, wobei die neu hinzugefügten Elemente des vierten hierarchischen Niveaus H4 für jegliche Elemente gesondert (beispielsweise verfeinertere Anwendung oder Funktion) des hierarchischen Niveaus H3 erzeugt sind bzw. werden; beispielsweise wurde in 13 die spezifische Funktion dreimal implementiert, so daß das Element des vierten hierarchischen Niveaus H4 "3" in 13 war, während nach der Änderung in der Architektur oder Struktur, die zu einem Spalten dieser Funktion in zwei verfeinertere Funktionen des dritten hierarchischen Niveaus H3 führt, gezeigt in 14, die linke Funktion des dritten hierarchischen Niveaus H3 dreimal implementiert ist bzw. wird, so daß das Element des vierten hierarchischen Niveaus H4 dafür "3" ist, während die rechte Funktion des dritten hierarchischen Niveaus H3 nur einmal implementiert wird, so daß das entsprechende Element des vierten hierarchischen Niveaus H4 "1" ist. Ein ähnliches Splitting bzw. Aufteilen hat für das Element "Personalisierung" des hierarchischen Niveaus H2 stattgefunden, welches in 13 nur fünf entsprechende Elemente (beispielsweise Anwendungen oder Funktionen) des hierarchischen Niveaus H3 aufweist, während in 14 das Element "Personalisierung" des hierarchischen Niveaus H2 verfeinert oder geändert wurde, um 15 entsprechende Elemente (beispielsweise Anwendungen oder Funktionen) des hierarchischen Niveaus H3 aufzuweisen.
Außerdem erzeugt bzw. generiert die Visualisierungsmaschine 510 vorzugsweise eine "Fingerabdruck"-Anzeige, wo wenigstens ein Element eines niedrigeren hierarchischen Niveaus (beispielsweise hierarchisches Niveau H3), welches in mehreren Elementen eines höheren hierarchischen Niveaus vorhanden ist (beispielsweise hierarchisches Niveau H2) auf dieselbe/ähnliche Weise markiert oder gerendert ist (beispielsweise hervorgehoben, ins Auge fallend gemacht, in einer spezifischen Farbe gefärbt, usw.) durch die gesamte Anzeige, womit ein "Fingerabdruck" erzeugt wird. Demgemäß kann mit dieser "Fingerabdruck"-Anzeige es sehr leicht analysiert werden, wo in einer Struktur oder Architektur ein spezifisches Element verwendet oder implementiert wird, beispielsweise wo in den IT Organisatorischen Gruppen und funktionellen Gebieten eine spezifische Anwendung verwendet oder implementiert wird, welches Teil eines Autos durch einen spezifischen Lieferanten geliefert wird, welches Teil eines Autos durch einen, zwei, drei usw. gesonderte Lieferanten geliefert wird (beispielsweise in Anbetracht eines Analysierens möglicher Probleme in einer Lieferkette, da, wenn ein Teil nur durch einen Lieferanten geliefert wird, in einem Fall, daß ein derartiger Lieferant aufgrund eines Streits, Konkurs usw. nicht fähig ist zu liefern, die Lieferkette für das spezifische Teil unterbrochen werden würde). Weiterhin wird durch Anklicken der Details der Fingerabdruckanzeige der Benutzer automatisch zu den assoziierten Instandhaltungs- bzw. Wartungsschirmen für dieses Element mitgenommen. Dies verbessert die Brauchbarkeit und leichte Instandhaltung bzw. Wartung der zugrunde liegenden Details (beispielsweise indem ein Teilelieferant hinzugefügt oder entfernt wird).
Im Folgenden wird ein bevorzugter Arbeitsablauf für die Szenariomaschine 530 unter Bezugnahme auf 9 beschrieben.
Die Szenariomaschine 530 erfüllt vorzugsweise zwei Erfordernisse, nämlich die Fähigkeit, anfänglich eine visuelle Darstellung eines Modells 10 in die Datenbank 300/500 zu laden, und die Fähigkeit, Szenarien oder fortlaufende Veränderungen von existierenden Modellstrukturen bzw. Strukturen eines existierenden Modells zu erzeugen. Das anfängliche Laden einer sichtbaren Struktur des Modells wird durch (vorzugsweise manuelles) Erzeugen 530b eines Bilds durchgeführt, wie das Modell ausschauen sollte. Dies kann typischerweise getan werden unter Verwendung von Microsoft Powerpoint, obwohl dies nicht notwendig ist. Jedes Tool bzw. Werkzeug, das eine graphische Bildgebung liefert, die auf eine definierte xml Struktur umgewandelt werden kann, würde arbeiten bzw. funktionieren. Diese Graphik wird auf xml umgewandelt 530c, und das resultierende xml wird geparsed 530d. Das geparste xml wird strukturell überprüft 530e, um sicherzustellen, daß es mit den Datenbankerfordernissen übereinstimmt. Die überprüfte Struktur wird dann in die Datenbank geladen 530f. Dieser Schritt eines Ladens 530f erzeugt die notwendigen Eingaben bzw. Einträge in die Modell Tabelle 11, die Display Tabelle 31, die Shape Tabelle 32, die Node_class Tabelle 12 und/oder die Node Tabelle 13 als auch ein Etablieren bzw. Aufbauen von starken Verbindungen (11a, 11b, 11c, 12b, 13b, 31a) zwischen diesen Eingaben in die entsprechenden Tabellen 11, 31, 32, 12, 13.
Für die Dateninstandhaltung bzw. -wartung wird ein existierendes Modell ausgewählt 530g und die entsprechende Modellhierarchie wird aus der Tree Tabelle 51 gelesen und ange zeigt 530h. Aus dieser Darstellung wird das gewünschte Niveau innerhalb der Hierarchie, die instand zu halten bzw. zu warten ist, ausgewählt 530i und die entsprechende Detailinformation von den geeigneten Tabellen (typischerweise der Attribut Tabelle 61, der Mapping Tabelle 41 und/oder der Node Tabelle 13) gelesen und angezeigt 530j. Diese Information wird (vorzugsweise online) aktualisiert 530k und dann in die Datenbank 300 zusammen mit der Audit-Trail-Information gesichert bzw. gespeichert 530l.
Die gemeinsamen, in 10 dargestellten Funktionen in:

a. Eine Schreiben xml-Subroutine 610 zum Schreiben von XML Files bzw. Dateien, welche die Basisstruktur zum Austauschen von Information innerhalb des Application Management Visualisation Frameworks bereitstellen. Während einer Ausführung müssen die Files kontinuierlich mit spezifischer Information betreffend die Graphiken aktualisiert werden, die zu erzeugen sind. Die Schreiben xml-Routine 610 weist vorzugsweise eine oder mehrere der folgenden Funktionen auf: Schreiben xml-TLHW (Write xml TLHW) (610a): Schreibt die Positionsinformation eines Objekts/einer Form (oberstes Ende, links, Breite, Höhe) zum xml File; Schreiben xml-Ausrichtlabel (Write xml Align Label) (610b): Schreibt die Einträge für das für das Objekt/Form spezifische Label und die Labelausrichtinformation zum xml File; Schreiben xml-Pfad (Write xml Path) (610c): Schreibt den Formpfad (Eckpunkte) für Freiformobjekte/Formen an das xml File; und Schreiben xml-Form (Write xml Shape) (610d): eine eingebettete gewöhnliche bzw. gemeinsame Routine zum Schreiben von Formen.
b. Eine Lese-Form-Subroutine (Read Shape Subroutine) 620 weist vorzugsweise eine oder mehrere der Funktionen auf, welche für ein Formatieren und Ausführen der SQL Statements verantwortlich sind, die notwendig sind, um die verschiedenen Objektformen von der Shape Tabelle 32 für jeden Knoten zu lesen, der anzuzeigen ist (über die fakultative starke Verbindung 13b). Da jede Form sich unterscheidende Strukturen, Attribute, usw. enthält, wird jede durch eine einzigartige Funktion innerhalb der Subroutine be- bzw. verarbeitet, die ähnlich zu den Funktionen ist, die für die gemeinsame Schreiben xml-Subroutine beschrieben sind.
c. Eine Schreiben xml-Form-Subroutine (Write xml Shape Subroutine) 630 weist vorzugsweise eine oder mehrere der Funktionen auf, welche für ein Schreiben der Formstrukturdaten zu dem xml File verantwortlich sind. Diese Funktionen bestätigen die Formattributdaten, die geschrieben werden, um sicherzustellen, daß die Formen geeignet gerendert werden können. Da jede Form sich unterscheidende Strukturen, Attribute usw. enthält, wird jede durch eine einzigartige Funktion innerhalb der Subroutine ähnlich zu den für die gemeinsame Schreiben xml-Subroutine beschriebenen Funktionen bearbeitet.
d. Eine Einleitungs-Anzeige-Subroutine (Initialize Display Subroutine) 640 weist vorzugsweise zwei Funktionen auf: Eine berechnet 640a den geeigneten Skalierfaktor, der auf eine Visualisierung anzuwenden ist, abhängig von dem berechneten Schirmraum, der verwendet wird, und der erfor derlichen Ausgabegröße; die zweite Funktion 640b liest die Hintergrundformen für das Modell, das angezeigt wird.

Im Folgenden werden bevorzugte funktionelle Blöcke, Tools bzw. Werkzeuge und/oder Merkmale des Application Management Visualisation Framework (AMVF) unter Bezugnahme auf 16 beschrieben.
Das Application Management Visualisation Framework gemäß einer bevorzugten Ausführungsform umfaßt vorzugsweise einen Access Control Manager bzw. Zugangs-Kontroll-Manager 1000, welcher Zugriffe von Benutzern auf das AMVF kontrolliert und managt und umfaßt:
eine Benutzerbeglaubigung 1010, die vorzugsweise eine "Windows" Beglaubigung des .NET Frameworks verwendet, wobei der Microsoft Internet Information Services Server (IIS) die Benutzerbeglaubigungen von dem Internet Explorer erlangt;
eine Funktionszugangkontrolle 1020, die vorzugsweise den Mechanismus verwendet, der in .NET Samples (Best Practices) verwendet wird;
eine Zugangskontrolle 1020, die über vordefinierte Benutzerrollen (User Roles) in der Datenbank realisiert wird, wobei eine Defaultgruppe festgelegt ist, wo alle Benutzer dazugehören, wenn sie nicht zu einer anderen Gruppe zugeteilt sind;
eine Datenzugangskontrolle 1030, welche über Views oder Zuweisung von Rechten an speziellen Knoten realisiert ist;
ein Benutzer-Management 1040, vorzugsweise über Datenbankaktualisierungen per SQL.
Das Application Management Visualisation Framework umfaßt weiterhin vorzugsweise ein Auditing 1050, welches Änderungen und/oder Eingaben prüft, die durch Benutzer durchgeführt werden. Insbesondere stellt das Auditing 1050 Datenänderungs-Spalten derart bereit, daß es vorzugsweise in jeder Tabelle eine Spalte "erzeugt_durch" ("created_by") und "zuletzt_aktualisiert_durch" ("last_updated_by") (vorzugsweise mit den entsprechenden Zeitstempeln) gibt, um ein Identifizieren zu unterstützen, welcher Benutzer eine bestimmte Spalte erzeugt oder aktualisiert hat, und für Daten-Updates bzw. -Aktualisierungen/Löschungen, welche vorzugsweise durch eine Audit Log Tabelle implementiert sein können, die Audit- bzw. Prüfeingänge enthält und/oder eine Audit Shadow Tabelle jeder Datentabelle, die die gelöschte oder aktualisierte Reihe vor dem Update bzw. der Aktualisierung enthält. Ein Auditing bzw. Prüfen könnte möglicherweise über Trigger bzw. Auslöser durchgeführt werden.
Das Application Management Visualisation Framework umfaßt weiterhin vorzugsweise ein Navigations/Benutzer-Interface 1100, indem beispielsweise eines von bereitgestellten .NET Portal-Beispielen als ein Startpunkt verwendet wird und die Hauptnavigation in eine Probe bzw. ein Muster integriert wird. Außerdem stellt das Navigations/Benutzer-Interface 1100 Menüeinträge bereit, welche vorzugsweise konfigurierbar sind, wenigstens in bezug auf die Detaileinträge unter den Haupteinträgen, auch abhängig von den Benutzerzugangsrechten.
Das Applikation Management Visualisation Framework umfaßt vorzugsweise weiterhin:
Eine Modell-Visualisierung 1110, welche vorzugsweise kommerziell verfügbare Komponenten für die Generierung bzw. Erzeugung von Web-basierenden Graphiken verwendet, wie PopChart^TM und Optimap^TM von Corda Technologies Inc., und ein PCXML File von der Datenbank 300/500 generiert bzw. erzeugt. Statt eines Erzeugens eines Files könnte der PCXML Strom über http durchgeleitet werden;
eine Interface-Visualisierung 1120, welche vorzugsweise kommerziell verfügbare Komponenten verwendet, um die Anwendungsbilder bzw. Application Images zu generieren bzw. zu erzeugen. Außerdem ist vorzugsweise ein Graphik-Layout-Algorithmus integriert, um die Anwendungen auszurichten und um die Interfaces bzw. Grenzflächen zwischen ihnen zu zeichnen, und/oder ein Auto-Layouter 1122 ist bereitgestellt, welcher vorzugsweise einen "Spring Embedder" artigen Graphik-Algorithmus oder dgl. verwendet.
Wenigstens ein Powerpoint-Export 1112, 1124, welcher vorzugsweise Office Automation verwendet, um ein Powerpoint von den Formdefinitionen zu generieren bzw. zu erzeugen, verwendet durch die ausgewählten kommerziell erhältlichen Graphikgenerierungskomponenten und/oder um dieses File für ein Downloaden bzw. Herunterladen am Server bereitzustellen. Alternativ oder zusätzlich können kommerziell erhältliche Graphikgenerierungskomponenten verwendet werden, um EMF zu generieren, welches in eine Powerpoint-Zeichnung umgewandelt werden kann;
Ein oder mehrere andere Visualisierungs-Plug-Ins 1130 zum Visualisieren der Daten in andere (vorbestimmte oder vorbestimmbare) Formate;
Eine Data Query bzw. Datenanfrage 140, wobei Datenanfragen vorzugsweise als einfache Text SQL Statements in der Datenbank 300/500 gespeichert sind. Diese Statements müssen vorzugsweise einer strikten Konvention folgen, um all die Attribute der Formen zurückzuführen, die gefärbt oder hervorgehoben werden sollten. Außerdem können die Anfragen eine bestimmte Anzahl von Parametern aufweisen (beispielsweise "_PAR1_"), welche durch die Parameter ersetzt werden (Stringersetzung), die hindurchgeleitet sind, wenn das Query Verfahren aufgerufen wird, um Flexibilität zu erlauben. Außerdem umfaßt die Data Query 1140 vorzugsweise eine Range Map bzw. Bereichskarte 1142, welche vorzugsweise auf den Bereichskarten basiert, die durch die ausgewählten kommerziell verfügbaren Graphikgenerierungskomponenten definiert sind; numerische Bereichskarten werden vorzugsweise aus einer vordefinierten Bereichskarte generiert bzw. erzeugt. Für textliche Karten (basierend auf Schlüsselwörtern) wird vorzugsweise eine pseudo-numerische Karte verwendet, welche jedes Schlüsselwort in einen ganzzahligen Wert darstellt.
Ein(e) Objektdaten-Anzeige/Editor 1150, die bzw. der eine Baumansicht (ähnlich dem Explorerbaum, siehe beispielsweise 17(A)) verwendet, um anzuzeigen und/oder durch das Modell zu navigieren (beispielsweise an der linken Seite der Seite); benachbart der Baumansicht bzw. Tree View (beispielsweise an der rechten Seite der Seite) wird vorzugsweise ein oberster Endabschnitt angezeigt, der die Attribute des ausgewählten Knotens enthält, und ein niedrigerer Abschnitt mit den Attributen der ausgewählten Darstellung (wenn eine ausgewählt ist). Ein oder mehrere Navigationsknopf(-knöpfe) kann (können) bereitgestellt sein, der bzw. die vorzugsweise "Expand All" bzw. "alles ausdehnen", "Collaps All" bzw. "alles zusammenbrechen", "Expand All Nodes With Data Element" bzw. "alle Knoten mit Datenelement ausdehnen", "Search" bzw. "Suchen", usw. enthält (enthalten). Außerdem kann ein Edit-Modus bereitgestellt sein, mit welchem der Benutzer Einträge löschen kann und/oder neue Einträge erzeugen kann. Wenn neue Einträge erzeugt werden, werden die Attribute mit Defaultwerten und Mandatory Fields bzw. obligatorischen Feldern aufgefüllt, als auch Maximum/Minimum-Beschränkungen, welche überprüft werden, wenn die Benutzer den Knoten sichern bzw. speichern. Dasselbe gilt, wenn der Benutzer existierende Einträge editiert. Außerdem zeigt der Objektdaten-Display/Editor 1150 vorzugsweise ein Datengitter an (siehe 17(B)) für Sätze, Wörterbücher und/oder Sammlungen: Für Sätze zeigt der Gegenstand den Index (nur lesen); für Wörterbücher wird der Schlüssel bzw. die Taste gezeigt und kann geändert werden, wobei für LOV basierendes Wörterbuch nur Schlüssel bzw. Tasten aus der LOV Gruppe ausgewählt werden können. Außerdem können Gegenstandskommentare bereitgestellt sein, so daß, wenn die Domäne Kommentare aufweist, die Kommentarspalte gezeigt wird (kann editierbar sein).
Ein Szenario-Manager 1200, welcher ein oder mehrere Szenarienfilter 1210 umfaßt, gemäß welchem(n) ein oder mehrere Szenario (Szenarien) durch Erzeugung einer Ansicht für jede Tabelle implementiert wird bzw. werden, welche alle Tabellen beinhaltet und eine "WHERE scenario_id = '<ID>'" Filterklausel aufweist. Die Ansichten weisen vorzugsweise denselben Namen wie die Tabelle mit der angefügten Szenario ID ("_<ID>") auf. Alle SQL Statements (und auch die Statements in der Datenbank 500/300) werden vorzugsweise während der Laufzeit bearbeitet, um die ursprünglichen Tabellennamen mit den Ansichtnamen zu ersetzen. Außerdem umfaßt der Szenario-Manager 1200 ein Szenario-Management 1220, gemäß welchem gespeicherte Prozeduren bzw. Verfahren erzeugt werden, um ein Szenario auf ein anderes zu kopieren (beispielsweise um die Ansicht zu erzeugen, Kopieren aller Reihen von einer Ansicht auf die andere, Aktualisieren und/oder Korrigieren der Querverweise). Andere gespeicherte Verfahren könnten bereitgestellt sein bzw. werden, um Szenarien zu löschen oder vielleicht um Szenarien zu vergleichen, und eine Staging & Authorization bzw. Inszenierung & Genehmigung 1230, gemäß welcher ein Szenario immer das "Basis"-Szenario ist. Die ID dieses Szenarios wird in einer globalen Konfigurationstabelle gespeichert. Um ein bestimmtes Szenario auf das neue Basisszenario herzustellen, muß nur sein Name in dieser Konfigurationstabelle festgelegt sein. Außerdem kann eine Funktionsverriegelung von Szenarien bereitgestellt sein, um Szenarien "zu verriegeln", um "normale Benutzer" daran zu hindern, fähig zu sein, die Daten zu ändern. Verriegelungen gelangen vorzugsweise nicht zur Anwendung, wenn Powerbenutzer SQL benutzen, um auf die Datenbank zuzugreifen.
Ein Modell-Manager 1300, umfassend eine Modell-Metadaten-Anzeige 1310 für die graphische Darstellung des Modells, worin ein Powerpoint-Slide erzeugt wird, das alle Formen enthält (Hintergrund und knotenbezogene Formen), wie beispielsweise in 11 bis 14 gezeigt. Die knotenbezogenen Formen enthalten nur die unique_id des Knotens. Dieses Slide kann editiert bzw. bearbeitet und später verwendet werden, um die graphische Darstellung zu aktualisieren. Für die Modelldaten selbst wird vorzugsweise ein XML File erzeugt, welches mit jeden beliebigen XML oder Texteditor editiert werden kann. Außerdem umfaßt der Modell-Manager 1300 einen Modell-Editor 1320 zum Kopieren und/oder Löschen von Modellen, wobei für die graphische Darstellung ein Powerpoint-Slide erzeugt wird. Der Modell-Editor 1320 enthält alle der Formen. Die Formen, welche an Knoten angefügt sind, müssen die unique_id des Knotens als Text aufweisen. Ein Powerpoint-Makro erzeugt vorzugsweise ein File, welches weiter bearbeitet wird, um die graphische Darstellung (entweder XML oder SQL Statements, usw.) in die Datenbank 500/300 zu importieren. Für das Baumodell selbst wird vorzugsweise ein XML File verwendet, um das Modell selbst zu modifizieren. Schließlich umfaßt der Modell-Manager 1300 eine Staging & Authorization Funktion 1330, wobei eine graphische Darstellung von Modellen und Modelle selbst entweder in ein existierendes Szenario mit einer neuen id oder in ein neues Szenario importiert werden können.
Einen Import/Export-Manager 1400, umfassend einen Modell-Import/Export 1410, gemäß welchem Modelle vorzugsweise über XML exportiert und/oder importiert werden, eine Modell-Validation bzw. -Gültigmachung 1420, welche eine gespeicherte Prozedur verwendet, um die Daten für ein Modell gültig zu erklären, beispielsweise, daß die Bezugsintegrität gültig ist, daß nur unterstützte Codes in codespezifischen Spalten usw. sind. Die gespeicherte Prozedur führt die Aufzeichnungen zurück, welche bestimmte Regeln verletzen und unterstützt vorzugsweise den Powerbenutzer, wenn er mit SQL arbeitet, um die Modelle zu ändern. Der Import/Export-Manager 1400 umfaßt weiterhin einen Objekt/Mapping-Import/Export 1430, gemäß welchem eine oder mehrere Objektdarstellung(en) über XML importiert und/oder exportiert wird bzw. werden, eine Object Validation 1440, welche eine gespeicherte Prozedur verwendet, um die Daten für ein Modell gültig zu erklären, beispielsweise, daß die Bezugsintegrität gültig ist, daß nur unterstützte Codes in den codespezifischen Spalten sind, usw. Die gespeicherte Prozedur gibt die Aufzeichnungen zurück, welche bestimmte Regeln verletzen, und unterstützt vorzugsweise den Powerbenutzer, wenn er mit SQL arbeitet, um die Modelle zu ändern;
Ein oder mehrere Basis-Service(s) 1500, umfassend eine oder mehrere der folgenden Funktionen: Fehlerhandhabung 1510, welche vorzugsweise die Mechanismen verwendet, die das .NET Framework bereitstellt; Logging/Tracing 1520, welches vorzugsweise die Mechanismen verwendet, die das .NET Framework bereitstellt; Concurrency Management bzw. Gleichzeitigkeits-Management 1530, welches vorzugsweise beste Praktiken anwendet, um sicherzustellen, daß zahlreiche Benutzer die Anwendung gleichzeitig verwenden können; Performance Management bzw. Leistungs-Management 1540; Operations Support bzw. Betriebsunterstützung 1550, welche vorzugsweise die .NET Framework Mechanismen verwendet (beispielsweise Windows Event Log), um ein Interface für die System Operations bzw. Systemtätigkeiten bereitzustellen; und/oder Configuration Management bzw. Konfigurations-Management 1560, gemäß welchem Konfigurations-Information in der Datenbank 300/500 gespeichert wird, außer es ist erforderlich, bevor die Datenbankverbindung etabliert bzw. hergestellt werden könnte;
Ein oder mehrere Daten-Management-Service(s) 1600, umfassend eine oder mehrere der folgenden Funktionen: Primary Key Generation bzw. Primärschlüsselgenerierung 1610, gemäß welcher, da der SQL Server nicht Sequenzen unterstützt, ein eingebettetes Verfahren eine einzige Reihe in einer Tabelle DLL erhöht, um die einzigartige ID zu erzeugen; eine oder mehrere Utility Functions 1620, welche gewöhnlich in gespeicherten Verfahren implementiert ist bzw. sind (bei spielsweise um Szenarien zu kopieren, Szenarien zu löschen, Beschränkungen zu ermöglichen/nicht zu ermöglichen usw.); Datensicherung/Wiedergewinnung bzw. Backup/Recovery 1630, welche mittels der Scripts, die Mechanismen definiert und/oder unterstützt, um die Daten zu sichern und/oder möglicherweise (Teile von) der Datenbank 500/300 wiederherzustellen; Test-Daten-Support bzw. Test Data Support 1640, welcher Utilityfunktionen umfaßt, um Testdaten zu generieren bzw. zu erzeugen, möglicherweise durch SQL Scripts und/oder gespeicherte Verfahren.
Es sollte verstanden werden, daß, selbst obwohl die Erfindung und ihre bevorzugten Ausführungsformen hauptsächlich unter Bezugnahme auf IT Architekturen und Strukturen beschrieben worden sind, das erfinderische Application Management Visualisation Framework auch auf die Erfassung, Zusammenstellung und/oder Visualisierung von strukturellen Daten von Architekturen von technischer Einrichtung und/oder Geschäften, anders als IT Architekturen angewandt werden kann.

Claims

Computerunterstütztes bzw. computerisiertes Informationssystem zum Erfassen, Zusammenstellen bzw. Aggregieren und Visualisieren eines Datenmodells von Architekturen einer technischen Einrichtung bzw. Ausrüstung, wie Informationstechnologie-Architekturen, umfassend: wenigstens ein abstraktes Datenmodell; eine graphische Benutzer-Interface-Erzeugungsmaschine (520); eine Visualisierungsmaschine (510); und eine Szenario-Managementmaschine (530), die adaptiert ist, Änderung in den Architekturen zu simulieren, zu visualisieren und auszuwerten bzw. zu evaluieren; wenigstens eine Datenaufnahmemaschine (100; 300; 500; 520) zum Aufnehmen bzw. Erfassen und Zusammenstellen bzw. Aggregieren von Daten entsprechend einem strukturierten, hierarchischen Modell (10), welches adaptiert ist, um eine strukturierte, hierarchische Ansicht einer Modellstruktur zur Verfügung zu stellen, und um den Grundrahmen für Analyse und Visualisierung aufzubauen bzw. zu erzeugen, wobei das Modell entweder ein standardisiertes Modell oder ein kundenspezifisches Modell ist; eine Anzeigemaschine (200; 510) zum Generieren bzw. Erzeugen einer Mehrzahl von unterschiedlichen Anzeigen bzw. Darstellungen der erfaßten Daten gemäß dem strukturieren, hierarchischen Modell (10); wobei das System adaptiert ist, um jede Art von Architektur generisch zu speichern und um die Beziehungsdaten zwischen Modellen zu speichern und zu analysieren; dadurch gekennzeichnet, daß das strukturierte, hierarchische Modell (10) Tabellen umfaßt, welche entweder stark oder locker vernetzt bzw. verbunden sind, wobei starke Verbindungen Row-IDs bzw. Reihen-IDs benutzen, und welche adaptiert sind, jede Aufzeichnung bzw. Eintrag zur Verfügung zu stellen, die eine Fremdschlüsselbeziehung zu einem primären bzw. Primärschlüssel einer Aufzeichnung in einer anderen Tabelle besitzt, und wobei lose Verbindungen von einer einzigartigen ID einer Reihe Gebrauch machen, und welche adaptiert sind, um einen Aufbau einer Fremdschlüsselbeziehung zu einer anderen Tabelle zur Verfügung zu stellen, so daß die Modelle und ihre Komponenten stark miteinander mittels wenigstens einer starken Verbindung gekoppelt sind, und die Beziehungen zwischen Modellen locker mittels einer oder mehreren lockeren Verbindung(en), die adaptiert ist bzw. sind, um zu erlauben, daß die Endpunkte der entsprechenden Beziehung(en) in einem Modell bewegbar oder entfernbar sind, und zwar ohne die Beziehung zu zwingen, ebenfalls entfernt zu werden, wobei die generische Darstellung eines Modells durch starke Verbindungen zwischen Kernmodelltabellen und graphischen Repräsentationstabellen dargestellt ist.
Computerunterstütztes Informationssystem nach Anspruch 1, wobei die Datenerfassungsmaschine (100; 300; 500; 520; 530) wenigstens eine Datenbank (300; 500) zum Speichern der Daten entsprechend dem strukturieren, hierarchischen Modell (10) umfaßt.
Computerunterstütztes Informationssystem nach einem der vorhergehenden Ansprüche, wobei das strukturierte, hierarchische Modell (10) umfaßt: eine Modell-Tabelle (11) enthaltend ein oder mehrere Hauptattribut(e) des Modells, wie den Namen, die Art bzw. Typ und die Version des Modells; eine Node_Class-Tabelle (12) enthaltend Information betreffend die Arten bzw. Typen von Knoten, welche das Modell (10) enthält; und eine Node-Tabelle (Knoten-Tablle) (13), enthaltend die Definition von jedem Knoten innerhalb des Modells (10) und die entsprechende hierarchische Information des Knotens.
Computerunterstütztes Informationssystem nach Anspruch 3, wobei die Modell-Tabelle (11), die Node_Class-Tabelle (12) und die Node-Tabelle (13) adaptiert sind, um miteinander mittels entsprechender starker Verbindungen (11a, 11b, 12a) ver bunden zu sein, welche vorzugsweise von einer ROW-id der entsprechenden Tabelle Gebrauch machen.
Computerunterstütztes Informationssystem nach Anspruch 3 oder 4, wobei das strukturierte, hierarchische Modell (10) weiterhin wenigstens eine der folgenden Tabellen umfaßt: eine Nclass-Group-Tabelle (14), die adaptiert ist, um eine Gruppe von node_classes (Knoten_Klassen) innerhalb einer Node_Class-Tabelle (12) zu definieren, welche den Pool bzw. den Vorrat von möglichen Knoten innerhalb einer Aufzeichnung bzw. Darstellung bzw. Mapping bauen bzw. erzeugen; eine Domain-Tabelle (62), die adaptiert ist, um zu definieren, welche Datenelementarten bzw. -typen zu einem Knoten oder einer Aufzeichnung bzw. Mapping gehören können, und insbesondere die Datenstrukturen definieren, die in dem Modell (10) gespeichert sind; eine Attribut-Tabelle (61), die adaptiert ist, um die aktuellen Betriebsdaten zu enthalten, die an dem Knoten oder der Aufzeichnung bzw. Mapping festgelegt sind; eine Display-Tabelle (Anzeige-Tabelle) (31), die adaptiert ist, um eine graphische Repräsentation bzw. Darstellung einer spezifischen Ansicht des Modells (10) zu definieren, wobei zahlreiche Ansichten des Modells (10) durch ein Filtern der Anzeigeinformation erzielt werden; eine Shape-Tabelle (Form-Tabelle) (32), die adaptiert ist, um einen oder mehrere graphische(n) Parameter zu definieren, der bzw. die erforderlich ist bzw. sind, um die Knoteninformation anzuzeigen, wo die Knoteninformation vorzugsweise die Spezifikation einer Position, Größe und/oder Form bzw. Gestalt und Hintergrundspezifikationen beinhaltet; eine Range-Tabelle (Bereichs-Tabelle) (22), die adaptiert ist, um Information zu enthalten, die steuert bzw. regelt, welche Farbe gewählte Formen haben sollten, wenn Anfrageergebnisse angezeigt sind; eine Query-Tabelle (Anfrage-Tabelle) (21), die adaptiert ist, um Information zu enthalten, die notwendig ist, um das Ergebnis eines SQL-Statements in einem Modell (10) anzuzeigen, wobei das SQL-Statement vorzugsweise adaptiert ist, um als Text gespeichert zu sein und um vorbestimmten oder vorbestimmbaren Konventionen bzw. Vereinbarungen zu folgen, um ein Nachfrage- bzw. Anfrageergebnis zur Verfügung zu stellen, das exakt die Anzahl und Arten bzw. Typen von Spalten enthält, die notwendig sind, um durch die Anwendung geeignet bearbeitet zu-werden; eine Widget-Tabelle (52), die adaptiert ist, um Information zu enthalten, die notwendig ist, um das Layout und/oder den Inhalt der angezeigten Knoten zu steuern bzw. zu regeln; und eine Tree-Tabelle (Baum-Tabelle) (51), die adaptiert ist, um Information zu enthalten, die notwendig ist, um eine Baumseite im Zusammenhang mit der Widget-Tabelle (52) zu bilden.
Computerunterstütztes Informationssystem nach einem der vorhergehenden Ansprüche, wobei die Datenerfassungsmaschine (100; 300; 500; 520) eine graphische Benutzer-Interface-Maschine (520) umfaßt, die adaptiert ist, um graphische Benutzer-Interface-Schirme (440) gemäß dem strukturierten, hierarchischen Modell (10) zu generieren bzw. zu erzeugen, welche adaptiert sind, um zu erlauben, Daten (825), insbesondere ein oder mehrere Datenattribut(e) und/oder Betriebsdaten in Übereinstimmung mit dem strukturierten, hierarchischen Modell (10) einzugeben; und/oder adaptiert sind, um das strukturierte, hierarchische Modell (10) zu definieren (810) oder zu modifizieren (820).
Computerunterstütztes Informationssystem nach Anspruch 6 und Anspruch 5, wobei das graphische Benutzer-Interface (520) adaptiert ist, um die graphischen Benutzer-Interface-Schirme (440), gemäß der Information zu generieren, die wenigstens eine der folgenden Tabellen beinhaltet: die Display-Tabelle (31), die Shape-Tabelle (32), die Range-Tabelle (22) und die Query-Tabelle (21).
Computerunterstütztes Informationssystem nach einem der vorhergehenden Ansprüche, wo die Datenerfassungsmaschine (100; 300; 500; 520) eine Szenariomaschine (530), zum Generieren einer visuellen Darstellung des strukturierten, hierarchischen Modells (10) in einer Datenbank (300; 500) und/oder zum Generieren einer Mehrzahl von Szenarien oder fortlaufenden Änderungen des strukturierten, hierarchischen Modells (10) umfaßt.
Computerunterstütztes Informationssystem nach einem der vorhergehenden Ansprüche, wobei die Anzeigemaschine (200; 510) eine Visualisierungsmaschine (510), zum Erzeugen einer Visualisierung des strukturierten, hierarchischen Modells (10), Ausführen von Benutzeranfragen, Verschmelzen bzw. Merging der Anfrageergebnisse zur Anzeige und/oder Steuern bzw. Regeln des dynamischen Skalierens der visuellen Ausgabe umfaßt.
Computerunterstütztes Informationssystem nach Anspruch 9 und Anspruch 5, wobei die Visualisierungsmaschine (510) adaptiert ist, um eine oder mehrere Form(en), die an dem Modell (10) von der Datenbank (300; 500), vorzugsweise über eine oder mehrere Verbindung(en) (11c; 31a) festgelegt ist bzw. sind, und/oder ein oder mehrere erlaubte(s) Formattribut(e) von der Attribut-Tabelle (61), vorzugsweise über eine oder mehrere Verbindung(en) (13b; 13a) zu lesen (520c); und/oder adaptiert ist, um Formdaten und/oder Formattributdaten zu einem Ausgabefile bzw. einer Ausgabedatei zu schreiben (520d), das vorzugsweise ein Ausgabe-xml-File ist.
Computerunterstütztes bzw. computerisiertes Verfahren zum Erfassen, Zusammenstellen bzw. Aggregieren und Visualisieren von strukturellen Modelldaten von Architekturen einer technischen Einrichtung bzw. Ausrüstung, wie Informationstechnologie-Architekturen, umfassend die folgenden Schritte: Erfassen und Zusammenstellen von Daten gemäß einem strukturierten hierarchischen Modell (10), das eine strukturierte, hierarchische Ansicht einer Modellstruktur zur Verfügung stellt, und Bauen bzw. Erzeugen des Grundrahmens zur Analyse und Visualisierung, wobei das Modell entweder ein standardisiertes Modell oder ein kundenspezifisches Modell ist; generisches Speichern von jeglicher Art von Architektur und Speichern und Analysieren von Beziehungsdaten zwischen Modellen; gekennzeichnet durch ein Definieren des strukturierten, hierarchischen Modells (10), damit es Tabellen umfaßt, welche entweder stark oder locker miteinander vernetzt bzw. verbunden sind, wobei starke Vernetzungen Row-IDs bzw. Reihen-IDs benutzen, und welche adaptiert sind, um jede Aufzeichnung zur Verfügung zu stellen, die eine Fremdschlüsselbeziehung zu einem primären bzw. Primärschlüssel einer Aufzeichnung bzw. Eintrag in einer anderen Tabelle aufweist, und wobei lockere Verbindungen einzigartige IDs einer Reihe benutzen, und welche adaptiert sind, um eine Fremdschlüsselbeziehung zu einer anderen Tabelle derart aufzubauen, daß die Modelle und ihre Komponenten stark miteinander mittels wenigstens einer starken Verbindung gekoppelt sind, wobei sichergestellt wird, so daß die Modelle, ihre Knoten und ihre unterschiedliche(n) graphische(n) Darstellung(en) eine Einheit bilden, und die Beziehungen zwischen den Modellen locker mittels einer oder mehreren lockeren Verbindung(en) gekoppelt werden, was es den Endpunkten der entsprechenden Beziehung(en) ermöglicht, daß sie innerhalb eines Modells bewegbar oder entfernbar sind, und zwar ohne die Beziehung zu zwingen, ebenfalls entfernt zu werden; wobei die generische Darstellung eines Modells durch starke Verbindungen zwischen Kernmodelltabellen und graphischen Repräsentationstabellen dargestellt wird, und Generieren bzw. Erzeugen einer Mehrzahl von unterschiedlichen Anzeigen bzw. Darstellungen der aufgenommenen Daten gemäß dem strukturierten, hierarchischen Modell (10).
Computerunterstütztes Verfahren nach Anspruch 11, umfassend einen Schritt eines Speichern der Daten gemäß dem strukturierten, hierarchischen Modell (10) in wenigstens einer Datenbank (300; 500).
Computerunterstütztes Verfahren nach Anspruch 11 oder 12, wobei das strukturierte, hierarchische Modell (10) definiert ist, um zu umfassen: eine Modell-Tabelle (11) enthaltend ein oder mehrere Hauptattribut(e) des Modells, wie den Namen, die Art und die Version des Modells; eine Node_Class-Tabelle (12) enthaltend Information betreffend die Arten bzw. Typen von Knoten, welche das Modell (10) enthält; und eine Node-Tabelle (Knoten-Tablle) (13), enthaltend die Definition von jedem Knoten innerhalb des Modells (10) und die entsprechende hierarchische Information des Knotens.
Computerunterstütztes Verfahren nach Anspruch 13, wobei die Modell-Tabelle (11), die Node_Class-Tabelle (12) und die Node-Tabelle (13) miteinander mittels entsprechender starker Verbindungen (11a, 11b, 12a) verbunden werden, welche vorzugsweise von einer ROW-id der entsprechenden Tabelle Gebrauch machen.
Computerprogrammprodukt, umfassend computerlesbare Instruktionen bzw. Anweisungen, welches, wenn es auf einen geeigneten Computer geladen ist, adaptiert ist, um ein Verfahren zum Erfassen, Zusammenstellen bzw. Aggregieren und Visualisieren von strukturellen Modelldaten von Architekturen einer technischen Einrichtung bzw. Ausrüstung, wie Informationstechnologie-Architekturen gemäß allen Verfahrensschritten von einem der vorhergehenden Ansprüche 11 bis 14 auszuführen.
Computerprogrammprodukt nach Anspruch 15, wobei das strukturierte, hierarchische Modell (10) adaptiert ist, um eine Erfassung, Zusammenstellung bzw. Aggregation und/oder Visualisierung von Modellstrukturdaten von Architekturen einer technischen Einrichtung, wie Informationstechnologie-Architekturen, zu ermöglichen.
Computerprogrammprodukt nach Anspruch 15, wobei die Datenerfassungsmaschine (100; 300; 500; 520) weiterhin adaptiert ist, um hierarchische, strukturelle Daten von Architekturen von technischen Einrichtungen, wie Informationstechnologie-Architekturen, sichtbar zu machen bzw. zu visualisieren.
Computerprogrammprodukt nach Anspruch 15, wobei die Anzeigemaschine (200; 510) weiterhin adaptiert ist, um eine Mehrzahl von unterschiedlichen Anzeigen bzw. Darstellungen von erfaßten Daten gemäß einem strukturierten, hierarchischen Modell (10) zu generieren, vorzugsweise nach einem der vorhergehenden Ansprüche 16 bis 18, wobei die erfaßten Daten in wenigstens einer Datenbank (300; 500) gemäß dem strukturierten, hierarchischen Modell (10) gespeichert sind.