DE102004008258A1

DE102004008258A1 - Konfigurierbares und dynamisch veränderbares Objektmodell

Info

Publication number: DE102004008258A1
Application number: DE102004008258A
Authority: DE
Inventors: Karlheinz Dorn; Hans-Martin von Dr. Stockhausen
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2004-02-19
Filing date: 2004-02-19
Publication date: 2005-09-01
Also published as: US20050188347A1; CN1658159A

Abstract

Die Erfindung betrifft ein Verfahren und ein System zur Generierung eines Objektmodells (10) für eine Applikation (A) in einer objekt-orientierten Umgebung, wobei das System zumindest eine generische Komponente (12) umfaßt, die eine Konfigurationsdatei (14) einliest und daraus automatisch ein Objektmodell (10) generiert. Weiterhin enthält die generische Komponente (12) ein Repository (16), das zur Verwaltung von Elementen des generierten Objektmodells (10) bestimmt ist.

Description

Die Erfindung liegt auf dem Gebiet der Objekt-orientierten Entwicklung von software-basierten Systemen und betrifft insbesondere ein Verfahren zur Generierung eines Objektmodells für eine Applikation oder für eine Applikationskomponente.
Im Gegensatz zu funktionalen und logischen Programmiersprachen, die problemorientiert sind, wie z.B. LISP, PROLOG gehen objektorientierte Programmiersprachen, wie z.B. JAVA, C++, von den Elementen der Problemstellung, den Objekten, und deren Darstellung im Lösungsraum aus. Die Anwendung ist nicht auf einen bestimmten Typ von Problemen beschränkt. Objektorientierte Ansätze ermöglichen aufgrund ihres hohen Abstraktionsgrades in Bezug auf die Problemlösung ein breites Einsatzfeld.
Das Paradigma der Objektorientierung basiert auf abstrakten Konstrukten aus dem Problemlösungsraum, den Objekten, die durch Eigenschaften (bzw. den Attributen) und deren Verhalten (bzw. den Methoden) charakterisiert sind.
Als ein grundlegendes Prinzip der objektorientierten Programmierung ist die Kapselung (encapsulation) zu nennen. Dieses Prinzip besagt, dass Methoden aus anderen Klassen nur über Objektmethoden auf die Attribute zugreifen können. Damit kann definiert werden, wer bzw. welche Instanzen auf definierte Attribute und Methoden des Objekts zugreifen darf und wer nicht. Sie können z.B. 'public' sein und für alle verfügbar oder 'private' und dürfen nur innerhalb des Objektes verwendet werden.
Als ein weiteres, grundlegendes Prinzip ist die Vererbung (inheritance) zu nennen. Das bedeutet, dass Objekte definiert werden können, die auf anderen Objekten basieren, indem sie deren Methoden und Attribute erben. Damit entsteht eine baumartige Struktur von Klassen.
Bei der Entwicklung von Softwarekomponenten für unterschiedliche Applikationen, insbesondere bei der Objekt-orientierten Programmierung von Softwarekomponenten, entstehen immer wieder Überschneidungsbereiche zwischen den einzelnen Komponenten, die eine ähnliche Struktur der Problemlösung erfordern, die aber bisher dennoch individuell implementiert werden müssen. Dies führt bei den aus dem Stand der Technik bekannten Lösungen nachteiligerweise zu Redundanzen.
Weiterhin ist es notwendig, dass ein software-basiertes System flexibel auf notwendige Änderungen reagieren kann, ohne dass die Qualität des Produktes verringert wird. Bisher war es notwendig, dass bei einer Anpassung des Systems, das Objektmodell spezifisch angepaßt werden mußte, indem eine ursprüngliche Implementierungskomponente durch eine neue, angepasste Implementierungskomponente ersetzt wurde.
Die Austauschbarkeit einer Komponente eines Objektmodells mußte bisher in dem jeweiligen Objektmodell selbst gelöst werden. Dies führt zu erhöhten Entwicklungs- und Testkosten, da stets eine individuelle Anpassung notwendig war und individueller Code implementiert werden mußte, um geänderte Module zu laden, geänderte Objekte bzw. Objektinstanzen zu generieren und diese in das Objektmodell einzufügen. Aufgrund dieser Änderungen mußte das gesamte System wieder erneut getestet werden.
Ausgehend von dem eingangs beschriebenen Stand der Technik hat sich die Erfindung zur Aufgabe gesetzt, einen Weg aufzuzeigen, mit dem ein Objektmodell dynamisch konfigurierbar wird und dessen Objekte auch zur Laufzeit austausch- und erweiterbar sind, ohne dass eine bestehende Implementierung des Objektmodells geändert werden muß.
Die Aufgabe wird durch die Merkmale der Erfindung gelöst, und insbesondere durch ein Verfahren und ein System zur Generierung eines Objektmodells für eine Applikation oder eine Applikationskomponente in einer objekt-orientierten Umgebung, wobei das Verfahren auf eine generische Komponente zugreift, die eine Konfigurationsdatei einliest und daraus ein Objektmodell generiert.
Eine weitere Aufgabenlösung sieht ein Objektmodell für eine Applikation oder eine Komponente einer Applikation in einer objekt-orientierten Umgebung vor, das auf eine generische Komponente zugreift, die ihrerseits eine Konfigurationsdatei einliest, wobei das Objektmodell aufgrund einer Verarbeitung der Konfigurationsdatei generiert wird.
Die erfindungsgemäße Lösung sieht vor, dass ein Änderung und/oder Anpassung des Objektmodells auch nach dem eigentlichen Design erfolgen kann. Damit wird es möglich, das Objektmodell auch zur Laufzeit zu verändern.
Eine individuelle Implementierung von Änderungscode ist nicht mehr notwendig. Es werden lediglich einzelne Objekte aus dem Objektmodell entfernt oder hinzugefügt.
Wichtig ist, dass die erfindungsgemäße, generische Komponente völlig unabhängig von der Applikation und/oder der Applikationskomponente ist. Vor allem enthält die generische Komponente keine applikations-bezogene Semantik und ist deshalb semantisch unabhängig von dem jeweils zu lösenden Anwendungsproblem und/oder unabhängig von dem zu generierenden Objektmodell. Die generische Komponente basiert auf einem universellen Mechanismus, der so vom Problem abstrahiert ist, dass er für unterschiedliche Applikationskomponenten verwendet werden kann.
Dies ermöglicht es, dass kein individueller Code implementiert werden muss, wenn das Objektmodell Änderungen unterworfen ist.
Es ist vorgesehen, dass die zu generierenden Objekte für die jeweilige Implementierung, bzw. die Implementierungsobjekte, nicht individuell, bzw. nicht komponenten-spezifisch, in das Objektmodell eingefügt werden müssen. Die generische Komponente liest zum Startzeitpunkt ein Konfigurationsfile ein und greift auf zumindest ein Repository zu, das seinerseits von dem Objektmodell verwaltet wird. Das Repository ist zum Verwalten der Instanzen und der Interfaces für die jeweiligen Objekte bestimmt. Dies führt zu einer wesentlich vereinfachten Entwicklung und verringert deren Kosten deutlich.
Das erfindungsgemäß generierte Objektmodell ist vorzugsweise hierarchisch strukturiert. Ein Objekt kann auf alle Interfaces zugreifen, die auf dessen Ebene liegen oder sich in einer darunter liegenden Hierarchieebene befinden. Damit entsteht der Vorteil, dass die erfindungsgemäße Lösung das Prinzip der Kapselung unterstützt. Es kann jedoch in einer alternativen Ausführungsform vorgesehen sein, dass das Kapselungs-Konzept nicht berücksichtigt ist.
Als weiterer Vorteil der erfindungsgemäßen Lösung ist zu nennen, dass das Objektmodell dynamisch konfigurierbar ist, so dass insbesondere Objekte aus dem generierten Objektmodell gelöscht und entfernt werden können. Dies ist sogar auch zur Laufzeit möglich. Dadurch kann sehr flexibel auf Änderungsanforderungen reagiert werden.
Damit das erfindungsgemäße System, insbesondere die generische Komponente, das Objektmodell erzeugen kann, liest es/sie die Konfigurationsdatei ein. Dies ist vorzugsweise eine Datei, die Anweisungen in der Extensible Markup Language (XML) enthält. Alternative Ausführungsformen sehen hier al lerdings andere Sprachen, beispielsweise mit einer HTML-basierten Syntax, vor.
Die von der generischen Komponente eingelesene Konfigurationsdatei umfaßt zumindest Daten, die sich auf folgende Datensätze beziehen:

– Namen der Module,
– Namen der zu generierenden Objektinstanzen,
– zumindest sichtbare Interfaces der Objektinstanzen und/oder Daten über Beziehungen der Objekte untereinander.

Die Objekte und gegebenenfalls deren Attribute und Methoden werden vorzugsweise automatisch von der generischen Komponente generiert. Nach der Erfindung erfolgt dies unter Zugriff auf die Konfigurationsdatei. Es ist jedoch in einer alternativen Ausführungsform ebenso möglich, vorzusehen, dass der Anwender in diesen Vorgang eingreifen kann und die Generierung des Objektmodell steuernd überwacht und/oder teilweise nicht-automatisch ausführt.
Das Verfahren umfaßt zusätzlich einen weiteren Verfahrensschritt, nämlich das Initialisieren von Objekten des generierten Objektmodells. Hier kann es einstellbar sein, ob alle Objekte initialisiert werden sollen und, falls nein, welche.
Die Reihenfolge für das Initialisieren der Objekte erfolgt – bezogen auf das Objektmodell – von innen nach außen und für Objekte auf derselben Hierarchieebene in der Konfigurationsreihenfolge. Damit kann die Initialisierung teilweise automatisiert ablaufen, unter Rückgriff auf das Konzept der Vererbung.
Notwendige Änderungen können erreicht werden, indem ein Zugriff auf eine Änderungsroutine erfolgt oder indem zusätzlich zur der initialen Konfigurationsdatei eine weitere Konfigurationsdatei, nämlich eine Änderungskonfigurationsdatei, eingelesen wird. Die Änderungen müssen nicht individuell, also nicht für jede Komponente einzeln, ausgeführt werden.
Ein wichtiges Element ist neben der generischen Komponente das Objektrepository, das für die Verwaltung von Elementen oder Modulen des Objektmodells bestimmt ist. Hier werden also die Objektinstanzen und die sichtbaren Interfaces verwaltet. In einer komplexeren Ausführungsform der Erfindung wird in dem Objektrepository noch mehr verwaltet, wie z.B. weitere Schnittstellen und/oder Daten über Klassenstruktur, Nachrichten etc. In vorteilhaften Ausführungsform sind mehrere Objektrepositories vorgesehen. In der bevorzugten Ausführungsform der Erfindung ist das Objektrepository Bestandteil der generischen Komponente und wird von dieser verwaltet.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahren können auch als Computerprogrammprodukt ausgebildet sein, mit einem von einem Computer lesbaren Medium und mit einem Computerprogramm und zugehörigen Programmcode-Mitteln, wobei der Computer nach Laden des Computerprogramms zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlaßt wird.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Zusätzliche, vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine Beispiel für ein erfindungsgemäß erzeugtes Objektmodell und
2 eine Übersicht über den prinzipiellen Ablauf eines erfindungsgemäßen Verfahrens und über wesentliche Elemente des erfindungsgemäßen Systems.
Ein allgemein mit 10 bezeichnetes Objektmodell wird erfindungsgemäß für eine Applikation A oder für einen Teil bzw. für eine Komponente einer Applikation A generiert. Dabei wird eine generische Komponente 12 eingesetzt, die auf einen universellen Mechanismus zugreift und damit für verschiedene Applikationen A und/oder zugehörige Objektmodelle 10 einsetzbar ist.
Wie in 2 dargestellt, liest die generische Komponente 12 zum Startzeitpunkt eine Konfigurationsdatei 14 ein. Die Konfigurationsdatei 14 liegt vorzugsweise in Form eines XML-Files vor. In der Konfigurationsdatei 14 sind die Namen der Module, die Namen der zu erzeugenden Objektinstanzen und ihre sichtbaren Interfaces und Daten über die Beziehungen der Objekte untereinander abgelegt. Hier wird insbesondere verwaltet, auf welche Interfaces von welchen Objekten aus zugegriffen werden kann und auf welche nicht.
Nach dem Einlesen und Verarbeiten dieser Daten generiert die generische Komponente 12 das Objektmodell 10. Die generische Komponente 12 umfaßt weiterhin ein Repository 16. Das Repository 16 kann physikalisch innerhalb der generischen Komponente angeordnet sein. Alternativ ist es möglich, das Repository 16 außerhalb der generischen Komponente anzuordnen und eine Zugriffsmöglichkeit vorzusehen.
Das Repository 16 dient zum Verwalten des Objektmodells 10, insbesondere der Instanzen und der sichtbaren Interfaces pro Objekt. Innerhalb des Objektmodells 10 erhält jedes Objekt einen eindeutigen logischen Namen, über den es vom Repository 16 angesprochen werden kann. Dieselbe Klasse kann unter ver schiedenen logischen Namen, mit jeweils unterschiedlichen Interfaces konfiguriert werden.
In 1 ist ein Beispiel eines erfindungsgemäß erzeugten Objektmodells 10 dargestellt. Aus der lediglich beispielhaft dargestellten Konfigurationsdatei 14 wird das Objektmodell 10 innerhalb der generischen Komponente 12 erzeugt. Die von den Objekten registrierten Interfaces sind jeweils unter Geschwistern, also den Objekten, die denselben Ursprung haben, und vom Ursprungsobjekt aus sichtbar. Der Ursprung aller Objekte wird vom Objektrepository 16 gebildet. Das Objektrepository 16 wird von der generischen Komponente 12 verwaltet.
Auf abstrakter Ebene könnte das XML-Konfigurationsfile 14 wie folgt aussehen, um das in 1 gezeigte Objektmodell 10 zu generieren:
Mit Kommentaren und für eine NET-basierte Implementierung des Verfahrens und/oder Systems liest sich der XML-Code, der das in 1 angedeutete Objektmodell 10 erzeugt:

Claims

Verfahren zur Generierung eines Objektmodells (10) für eine Applikation (A) oder eine Komponente der Applikation (A) in einer Objekt-orientierten Umgebung, dadurch gekennzeichnet, dass das Verfahren auf eine generische Komponente (12) zugreift, die eine Konfigurationsdatei (14) einliest und daraus automatisch ein Objektmodell (10) generiert.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die generische Komponente (12) unabhängig, vorzugsweise semantisch unabhängig, von der Applikation (A) und/oder der Applikationskomponente (A) ist.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Implementierungsobjekte nicht individuell, bzw. nicht komponenten-spezifisch, in das Objektmodell (10) eingefügt werden müssen.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Objektmodell (10) hierarchisch strukturiert ist.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Objektmodell (10) – vorzugsweise auch zur Laufzeit – dynamisch konfigurierbar ist, so dass insbesondere Objekte aus dem generierten Objektmodell (10) gelöscht und/oder hinzugefügt werden können.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Objektmodell (10) ein Prinzip der Kapselung unterstützt.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Konfigurationsdatei (14) ein XML-File ist.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren auf zumindest ein Repository (16) zugreift, das vorzugsweise von dem Objektmodell (10) verwaltet wird und zumindest zum Verwalten von Instanzen und von Interfaces in Bezug auf die jeweiligen Objekte bestimmt ist.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Verfahren zusätzlich folgenden Verfahrensschritt umfaßt: – Initialisieren von Objekten des generierten Objektmodells (10).
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Reihenfolge für das Initialisieren der Objekte bezogen auf da Objektmodell (10) von innen nach außen und für Objekte auf derselben Hierarchieebene in der Konfigurationsreihenfolge erfolgt.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Objektmodell (10) geändert wird, indem ein Zugriff auf eine Änderungsroutine erfolgt oder indem eine Änderungskonfigurationsdatei eingelesen wird.
System zur Generierung eines Objektmodells (10) für eine Applikation (A) oder eine Komponente der Applikation (A) in einer Objekt-orientierten Umgebung, dadurch gekennzeichnet, dass das System umfaßt: – zumindest eine generische Komponente (12), die eine Konfigurationsdatei (14) einliest und daraus automatisch ein Objektmodell (10) generiert.
System nach Anspruch 12, dadurch gekennzeichnet, dass die generische Komponente (12) unabhängig, vorzugsweise semantisch unabhängig, von der Applikation (A) und/oder der Applikationskomponente (A) ist.
System nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass die Implementierungsobjekte nicht individuell, bzw. nicht komponenten-spezifisch, in das Objektmodell (10) eingefügt werden müssen.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 14, dadurch gekennzeichnet, dass das Objektmodell (10) hierarchisch strukturiert ist.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 15, dadurch gekennzeichnet, dass das Objektmodell (10) – vorzugsweise auch zur Laufzeit – dynamisch konfigurierbar ist, so dass insbesondere Objekte aus dem generierten Objektmodell (10) gelöscht und/oder hinzugefügt werden können.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 16, dadurch gekennzeichnet, dass das Objektmodell (10) ein Prinzip der Kapselung unterstützt.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 17, dadurch gekennzeichnet, dass die Konfigurationsdatei (14) ein XML-File ist.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 18, dadurch gekennzeichnet, dass das System weiterhin umfaßt: – zumindest ein Repository (16), das vorzugsweise von dem Objektmodell (10) verwaltet wird und zumindest zum Verwalten von Instanzen und von Interfaces in Bezug auf die jeweiligen Objekte bestimmt ist.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 19, dadurch gekennzeichnet, dass das System zusätzlich umfaßt: – zumindest eine Initialisierungseinheit, die zur Initialisierung von Objekten des generierten Objektmodells (10) bestimmt ist.
System nach Anspruch 20, dadurch gekennzeichnet, dass die Reihenfolge für das Initialisieren der Objekte bezogen auf das Objektmodell (10) von innen nach außen und für Objekte auf derselben Hierarchieebene in der Konfigurationsreihenfolge erfolgt.
System nach zumindest einem der vorstehenden Ansprüche 12 mit 21, dadurch gekennzeichnet, dass das Objektmodell (10) geändert wird, indem ein Zugriff auf eine Änderungsroutine erfolgt oder indem eine Änderungskonfigurationsdatei eingelesen wird.
Objektmodell für eine Applikation oder eine Applikationskomponente in einer Objekt-orientierten Umgebung, dadurch gekennzeichnet, dass das Objektmodell unter Zugriff auf eine generische Komponente, die eine Konfigurationsdatei einliest, automatisch generiert worden ist.
Objektmodell nach Anspruch 23, dadurch gekennzeichnet, dass das Objektmodell (10) dynamisch konfigurierbar und/oder zumindest hinsichtlich erzeugter Objekte austausch- und/oder erweiterbar ist.