DE10031041A1 - Bereitstellen einer Zugriffsmöglichkeit auf Anwendungsdatenelemente eines Anwendungsprogramms - Google Patents

Abstract

Ein Verfahren zum Bereitstellen einer Zugriffsmöglichkeit auf Anwendungsdatenelemente eines Anwendungsprogramms, wobei die Anwendungsdatenelemente in einer Mehrzahl miteinander verknüpfter Datenobjekte, die von dem Anwendungsprogramm verarbeitet werden, enthalten sind, weist die Schritte auf, eine Anforderung zu erhalten, die mindestens eines der Anwendungsdatenelemente betrifft, wobei sich die Anforderung auf ein Datenobjekt der Mehrzahl von Datenobjekten bezieht, die Anforderung hinsichtlich desjenigen Datenobjekts, auf das sich die Anforderung bezieht, zu erfüllen, und, falls die Anforderung mindestens ein anderes Datenobjekt der Mehrzahl von Datenobjekten betrifft, die Anforderung an das mindestens eine andere Datenobjekt zur weiteren Verarbeitung der Anforderung weiterzuleiten. Ein Computerprogrammprodukt und eine Vorrichtung weisen entsprechende Merkmale auf. Die Erfindung stellt eine Möglichkeit zum Zugriff auf Anwendungsdatenelemente bereit, die sehr flexibel ist und die insbesondere bei komplexen Anwendungsdatenstrukturen, die eine Vielzahl miteinander verknüpfter Datenobjekte aufweisen, eingesetzt werden kann.

Description

Die Erfindung betrifft das Gebiet der Anwendungsprogramme, und insbesondere das Gebiet, eine Zugriffsmöglichkeit auf Daten bereitzustellen, die von einem An­ wendungsprogramm verarbeitet werden. Die Erfindung kann für alle Arten von Anwendungsprogrammen verwendet werden, insbesondere für Programme, die komplexe Daten verarbeiten, welche intern in einer Mehrzahl von miteinander ver­ knüpften Datenobjekten gespeichert sind. Solche Programme können graphische Bearbeitungs- und Entwurfsprogramme, Dokumenten- und Textverarbeitungspro­ gramme, Planungs- und Planerstellungsprogramme (planning and scheduling programs) und so weiter sein. Insbesondere wird der Einsatz der Erfindung für Programme für den computerunterstützten Entwurf (CAD-Programme; CAD = computer aided design) vorgeschlagen, wie zum Beispiel die unter der Marke "AutoCAD" verfügbaren Produkte, die von Autodesk, Inc., San Rafael, Vereinigte Staaten von Amerika, hergestellt werden.

Die komplexen Datenstrukturen solcher Anwendungsprogramme enthalten typi­ scherweise eine große Anzahl unterschiedlicher Datenelemente, die verwendet werden, um die Hauptfunktionalität des Anwendungsprogramms zu erzielen. So enthält zum Beispiel bei CAD-Programmen jedes Modell Daten, die die Geometrie der Teile bestimmen, Werkstoffspezifikationen, Attribute der Teile, globale Daten und so weiter. Alle diese Datenelemente werden von dem CAD-Programm auf eine vorbestimmte Weise verarbeitet, um die Erzeugung graphischer Darstellun­ gen des Modells, einschließlich unterschiedlicher Arten von Teilelisten, Stücklisten (Stückliste = bill of material = BOM) und so weiter zu steuern. Diese Verarbeitung ist jedoch nicht sehr flexibel, weil sie durch das Programm selbst ausgeführt wird oder durch Zusatzmodule, die von Zulieferern hergestellt werden, die Detailwissen über Interna des Programms benötigen.

Es wäre wünschenswert, einen flexibleren Weg zum Zugreifen auf die von dem Anwendungsprogramm verarbeiteten internen Daten und zum Verwenden dieser Daten bereitzustellen. Insbesondere sollte es für den Endbenutzer oder für unab­ hängige Entwickler möglich sein, auch dann auf die Daten zuzugreifen, wenn nur ein begrenzter Wissensschatz über die interne Datenstrukturen des Programms verfügbar ist. Dies ist jedoch nicht leicht zu bewerkstelligen, weil die Daten typi­ scherweise auf komplexe Art und Weise gespeichert werden. Die einzelnen Daten­ elemente können über das Modell hinweg in unterschiedlichen Datenobjekten verteilt sein, und die Datenobjekte können in einer komplizierten Netzstruktur mit­ einander verknüpft sein. Auch dann, wenn irgendeine Art einer Datenhierarchie berücksichtigt wird (z. B. Baugruppenebene, Bauteilebene, Merkmalsebene), ist es immer noch schwierig, die passende Hierarchieebene für jedes Datenelement zu bestimmen.

Gegenwärtige Textverarbeitungsprogramme wie beispielsweise die unter der Marke Microsoft Word verkauften bieten die Möglichkeit, auf einen vorgegebenen Satz interner Datenelemente (wie beispielsweise den Titel eines Dokuments oder die aktuelle Seitennummer) unter vordefinierten Namen zuzugreifen. Diese Vor­ gehensweise ist jedoch auf vergleichsweise einfache Datenstrukturen beschränkt, wie sie in dem klar umgrenzten Gebiet der Textverarbeitung auftreten.

Die Aufgabe der vorliegenden Erfindung ist es daher, die oben erwähnten Proble­ me zumindest teilweise zu vermeiden und eine Möglichkeit zum Zugriff auf Anwen­ dungsdatenelemente bereitzustellen, die sehr flexibel ist und die insbesondere bei komplexen Anwendungsdatenstrukturen, die eine Vielzahl miteinander verknüpfter Datenobjekte enthalten, eingesetzt werden kann. Vorzugsweise soll die Erfindung auch einen Datenzugriff ermöglichen, ohne tiefgehendes Wissen über interne Aspekte des Anwendungsprogramms zu erfordern. Ein weiteres Ziel bevorzugter Ausführungsformen der Erfindung ist, daß der Datenzugriff benutzerfreundlich sein soll, so daß er von typischen Endbenutzern des Anwendungsprogramms eingesetzt werden kann.

Um zumindest einige der oben erwähnten Aufgaben zu lösen, umfaßt die Erfin­ dung ein Verfahren zum Bereitstellen einer Zugriffsmöglichkeit auf Anwendungs­ datenelemente eines Anwendungsprogramms, ein Computerprogrammprodukt und eine Vorrichtung mit den Merkmalen der unabhängigen Ansprüche. Die abhängigen Ansprüche definieren bevorzugte Ausführungsformen der Erfindung.

Die Erfindung beruht auf der Idee, Anforderungen (requests) einzusetzen, die zu­ mindest ein Anwendungsdatenelement betreffen, ohne zu verlangen, daß dieses Anwendungsdatenelement in einem Datenobjekt gespeichert ist, auf das sich die Anforderung bezieht. Die Anforderung wird möglichst weitgehend im Hinblick auf dasjenige Datenobjekt bearbeitet, auf das sich die Anforderung bezieht. Ferner wird die Anforderung zur weiteren Bearbeitung an mindestens ein anderes Daten­ objekt weitergeleitet, wenn die Anforderung ein solches anderes Datenobjekt betrifft.

Die Erfindung bietet den beträchtlichen Vorteil, daß die Anforderung an ein Daten­ objekt gerichtet werden kann, das selbst nicht die angeforderten Daten enthält. Falls erforderlich, wird die Struktur miteinander verknüpfter Objekte bei der Bear­ beitung der Anforderung vollständig oder teilweise durchlaufen. Mit anderen Wor­ ten können Anforderungen aufgegeben werden, die irgendein Datenobjekt oder sogar alle Datenobjekte betreffen, und solche Anforderungen werden bearbeitet, auch wenn in der Anforderung nur auf ein einziges Datenobjekt Bezug genommen wird. Dies ermöglicht es, auf Anwendungsdatenelemente, die in komplexen Daten­ strukturen enthalten sind, auch dann zuzugreifen, wenn lediglich einige wenige Informationen über die gesamte Datenstruktur bekannt sind.

Die Ansprüche enthalten die Formulierung, daß die anfängliche Anforderung sich auf ein Datenobjekt aus der Mehrzahl von Datenobjekten, die von dem Anwen­ dungsprogramm verarbeitet werden, "bezieht". Diese Formulierung schließt die Fälle ein, daß die Anforderung einen Verweis auf dieses Datenobjekt enthält, daß die Anforderung an dieses Datenobjekt gerichtet wird, und daß die Anforderung an ein Objekt gerichtet wird, das seinerseits Wissen über das Datenobjekt hat (insbe­ sondere kann ein derartiges Objekt ein Datenlieferant oder ein Erweiterungsobjekt des Datenobjekts sein), aber die Formulierung ist nicht auf diese Fälle beschränkt. Die Anforderung braucht sich nicht nur auf ein einziges Datenobjekt zu beziehen; es ist in bevorzugten Ausführungsformen der Erfindung auch möglich, daß sich die Anforderung auf mehrere Datenobjekte bezieht.

Der Schritt des "Erfüllens" der Anforderung im Hinblick auf das eine Datenobjekt kann jedwede Verarbeitung oder Veränderung dieses Datenobjekts oder jedweden Zugriff auf dieses Datenobjekt enthalten, oder es kann nur der Schritt sein, zu be­ stimmen, daß das Datenobjekt bei der Gesamtbearbeitung der Anforderung nicht benötigt wird, so daß die Anforderung unmittelbar an andere Datenobjekte weiter­ geleitet werden kann.

Generell soll die Reihenfolge der in den Ansprüchen genannten Schritte nicht als eine Einschränkung des Bereichs der vorliegenden Erfindung verstanden werden. Die Erfindung umfaßt alle Ausführungsformen, bei denen die genannten Verfah­ rensschritte in einer anderen Reihenfolge oder in einer parallelen oder ineinander verzahnten (quasi-parallelen) Weise ausgeführt werden.

Vorzugsweise wird eine Anforderung, die von einem ersten Datenobjekt an ein zweites Datenobjekt weitergeleitet worden ist, bei dem zweiten Datenobjekt wieder wie oben beschrieben bearbeitet. Im Verlauf dieser Bearbeitung kann die An­ forderung wieder an ein drittes Datenobjekt weitergeleitet werden und so weiter, bis die Gesamtheit der Datenobjekte (oder ein Teil davon) auf rekursive oder interative Weise durchlaufen worden ist. Einige Buchhaltungsvorgänge werden ausgeführt, um sicherzustellen, daß dieser Prozeß terminiert.

In bevorzugten Ausführungsformen ist die Verknüpfungsstruktur der Datenobjekte untereinander derart, daß irgendwelche zwei Objekte entweder einander zugeord­ net sind oder nicht einander zugeordnet sind. Vorzugsweise werden beim Weiter­ leiten einer Anforderung nur zugeordnete Objekte berücksichtigt. Ein zugeordnetes Objekt kann in manchen Ausführungsformen ein übergeordnetes Objekt (Super- Objekt) oder ein untergeordnetes Objekt (Sub-Objekt) oder ein verwandtes Objekt sein. Das Weiterleiten einer Anforderung kann im Hinblick auf untergeordnete Ob­ jekte beschränkt sein, aber es umfaßt vorzugsweise alle übergeordneten Objekte und alle verwandten Objekte, die die Anforderung noch nicht erhalten haben.

Einige Ausführungsformen der Erfindung stellen die Möglichkeit bereit, daß die Anforderung eine Anforderung zur Initialisierung der Funktionalität zum Bereitstel­ len der Zugriffsmöglichkeit ist. Eine solche Anforderung bewirkt vorzugsweise, daß ein Datenlieferant für das Objekt, auf das sich die Anforderung bezieht, und für je­ des andere Objekt, an das die Anforderung letztendlich weitergeleitet wird, erzeugt wird. Erweiterungsobjekte können in manchen Ausführungsformen vorhanden sein, um diese Initialisierungsanforderungen zu verarbeiten.

Eine andere Anforderungsart, die in bevorzugten Ausführungsformen vorgesehen ist, ist eine Anforderung zum Erhalten einer Ansammlung der Namen aller Anwen­ dungsdatenelemente, auf die über das Datenobjekt, auf das die Anforderung ver­ weist, zugegriffen werden kann. Mit anderen Worten werden die Namen der zum Zugriff bereitstehenden Datenelemente von den folgenden Objekten gesammelt:

• - dem Objekt, auf das sich die Anforderung bezieht,
• - allen Objekten, die unmittelbar (d. h., indem man genau einer Zuordnungsverknüpfung folgt) diesem Objekt zugeordnet sind, und
• - allen Objekten, die transitiv (d. h., indem man mehr als einer Zuordnungsverknüpfung folgt) diesem Objekt zugeordnet sind.

Die oben erwähnte Anforderungsart zum Zusammentragen der Namen von Daten­ elementen, auf die zugegriffen werden kann, stellt einen benutzerfreundlichen Weg dar, um Informationen über das gesamte Datenobjekt-Netzwerk zusammen­ zutragen. Die Namen sind normalerweise selbsterklärend. Eine andere Anforde­ rungsart, die in manchen Ausführungsformen zur Benutzerunterstützung imple­ mentiert ist, ist eine Anforderung zum Erhalten einer Ansammlung von Beispiel­ ausdrücken. Solche Beispielausdrücke können ebenso eine wertvolle Richtschnur für den Benutzer liefern.

Weitere Anforderungsarten, die in den meisten Ausführungsformen der Erfindung vorhanden sind, sind Anforderungen zum Lesen und/oder zum Setzen des Wertes eines Anwendungsdatenelements.

Bevorzugte Ausführungsformen der Erfindung weisen ferner einen Evaluator (eine Auswertungseinrichtung) auf, der eine benutzerseitige Schnittstelle (front end) zum Verwenden der erfindungsgemäßen Datenzugriffsfunktionalität bietet. Der Evalua­ tor kann insbesondere dazu eingerichtet sein, Ausdrücke auszuwerten, die Verwei­ se auf in den unterschiedlichen Datenobjekten gespeicherte Anwendungsdaten­ elemente enthalten. Das Ergebnis des Auswertungsvorgangs kann seinerseits in einem Anwendungsdatenelement abgelegt werden und kann möglicherweise dem Benutzer angezeigt werden. Es wird besonders bevorzugt, daß der Auswertungs­ vorgang beim Auftreten eines Neuberechnungs-Ereignisses wiederholt wird, so daß die Ergebnisse automatisch allen Veränderungen in den Datenobjekten ange­ paßt werden.

In bevorzugten Ausführungsformen der Erfindung wird das Anwendungsprogramm verwendet, um Dokumente anzuzeigen und/oder zu bearbeiten. Das Anwendungs­ programm kann insbesondere ein CAD-Programm sein. Es ist ferner bevorzugt, daß die Zugriffsfunktionalität nicht als die Hauptfunktion, sondern als eine Hilfs­ funktion des Anwendungsprogramms bereitgestellt wird. Mit anderen Worten sind bevorzugte Ausführungsformen der vorliegenden Erfindung nicht zur Verwendung in Verbindung mit Datenbanken und Datenzugriffsprogrammen vorgesehen, son­ dern sie sind zur Verwendung bei Verarbeitungsprogrammen und Editoren für Text und Graphiken vorgesehen.

Bevorzugte Ausführungsformen des Computerprogrammprodukts und der Vorrich­ tung der vorliegenden Erfindung weisen ebenfalls Merkmale auf, die den oben be­ schriebenen Merkmalen und/oder den in den abhängigen Verfahrensansprüchen definierten Merkmalen entsprechen.

Weitere Merkmale, Aufgaben und Vorteile der Erfindung gehen aus der folgenden Detailbeschreibung mehrerer Ausführungsbeispiele der Erfindung hervor. Es wird auf die schematischen Zeichnungen Bezug genommen, in denen:

Fig. 1 einen Computer zeigt, der ein Anwendungsprogramm ausführt, in dem die vorliegende Erfindung implementiert ist,

Fig. 2 ein Klassendiagramm zeigt, das ein Beispiel der Verknüpfungsstruktur von Datenobjekten, die von dem Anwendungsprogramm verarbeitet werden, darstellt,

Fig. 3 ein Beispiel mit vier Datenobjekten und ihren zugeordneten Erweiterungs­ objekten darstellt,

Fig. 4 ein Flußdiagramm der Verarbeitung einer Initialisierungsanforderung ist,

Fig. 5 die Objekte von Fig. 3 zeigt, nachdem die Initialisierung ausgeführt worden ist,

Fig. 6 ein Flußdiagramm der Verarbeitung einer Anforderung zum Erhalten der Namen der Anwendungsdatenelemente, auf die zugegriffen werden kann, ist,

Fig. 7 ein Flußdiagramm der Verarbeitung einer Anforderung zum Zugriff auf den Wert eines zugreifbaren Datenelements ist,

Fig. 8 ein Flußdiagramm ist, das eine vom Benutzer gesteuerte Berechnungs­ prozedur darstellt, und

Fig. 9 ein Ausschnitt aus der Objektstruktur von Fig. 5 nach der Erzeugung eines Evaluators ist.

Die in Fig. 1 gezeigte Vorrichtung ist ein gut bekannter persönlicher Computer oder ein Arbeitsplatzrechner mit einer Haupteinheit 10, einer Tastatur 12, einer Maus 14 und einer Videoanzeige 16. Der Computer führt das CAD-Programm aus, das auf dem unter der Marke "AutoCAD" verkauften Pragramm beruht, welches erweitert worden ist, und die Funktionalität der vorliegenden Erfindung zu implementieren. Das CAD-Programm führt auf eine an sich gut bekannte Art und Weise eine große Funktionsvielfalt in Verbindung mit dem Anzeigen und Verarbeiten von Zeich­ nungs- und Entwurfsdokumenten aus. Jedes Zeichnungs- und Entwurfsdokument enthält mehrere Zeichnungsobjekte, und jedes der Zeichnungsobjekte spiegelt ein von dem CAD-Programm verarbeitetes Datenobjekt wieder.

Bei dem Beispiel von Fig. 1 wird ein Fenster 18 unter Steuerung des CAD-Pro­ gramms auf der Videoanzeige 16 angezeigt, und zwei Zeichnungsobjekte, nämlich ein Quader 20 und eine Sprechblase 22, werden in dem Fenster 18 angezeigt. Die Sprechblase 22 enthält einen Anmerkungstext, der eine Eigenschaft des Quaders 20 betrifft, nämlich die Fläche seiner Vorderseite. Es war bereits in früheren Ver­ sionen der "AutoCAD" CAD-Programme möglich, einen Anmerkungstext wie den in der Sprechblase 22 enthaltenen manuell einzugeben. Jedoch existierte in die­ sen Programmversionen keine direkte Verbindung zwischen dem Anmerkungstext (insbesondere dem darin genannten numerischen Wert) und den tatsächlichen Eigenschaften des entsprechenden Zeichnungsobjekts. Eine mögliche Anwendung der Erfindung ist, daß der Anmerkungstext in der Sprechblase 22 nun automatisch erzeugt und aktualisiert werden kann, weil eine Zugriffsmöglichkeit auf interne Datenelemente des dem Quader 20 entsprechenden Datenobjekts bereitgestellt wird.

Das Klassendiagramm von Fig. 2 zeigt beispielhaft die miteinander verknüpfte Klassenstruktur der von dem CAD-Anwendungsprogramm verarbeiteten Daten­ objekte. Ein Objekt der Klasse "BAUGRUPPE" (Baugruppe = assembly) ist der Eigentümer eines Objekts oder mehrerer Objekte der Klasse "BAUTEILDEFINI­ TION" (Bauteildefinition = component definition = comp. def.). Diese Eigentümer- Beziehung wird durch das kleine Rechteck auf der Verbindungslinie zwischen den Klassen "BAUGRUPPE" und "BAUTEILDEFINITION" in Fig. 2 bezeichnet. Dem­ entsprechend ist jedes Objekt der Klasse "BAUTEILDEFINITION" (oder kurz "BAUTEILDEFINITION"-Objekt) Eigentümer von null oder mehr "PARAMETER"- Objekten. Mit anderen Worten ist das "BAUGRUPPE"-Objekt ein übergeordnetes Objekt im Verhältnis zu jedem "BAUTEILDEFINITION"-Objekt, und jedes "PARA­ METER"-Objekt ist ein dem entsprechenden "BAUTEILDEFINITION"-Objekt unter­ geordnetes Objekt.

Jedes "BAUTEILDEFINITION"-Objekt kann ein verwandtes Objekt in der Klasse "STÜCKLISTENELEMENT" (Stückliste = bill of materials = BOM; Element = item) aufweisen. Das übergeordnete Objekt aller "STÜCKLISTENELEMENT"-Objekte ist ein Objekt des Typs "STÜCKLISTE", das seinerseits verwandt mit dem "BAU­ GRUPPE"- und dem "TEILELISTE"-Objekt ist. Jedes der "STÜCKLISTEN- ELEMENT"- und der "BAUTEILDEFINITION"-Objekte kann ein oder mehrere mit ihm verwandte "SPRECHBLASE"-Objekte (Sprechblase = Balloon) aufweisen. Beispielsweise entspricht der Quader 20 von Fig. 1 einem von dem CAD-Pro­ gramm verarbeiteten "BAUTEILDEFINITION"-Objekt, und die Sprechblase 22 entspricht einem verwandten "SPRECHBLASE"-Objekt.

Fig. 3 stellt eine mögliche Objektstruktur dar, die zu einem Zeitpunkt während der Ausführung des CAD-Programms vorhanden sein kann. Ein Datenobjekt 30A hat ein übergeordnetes Objekt 30B, ein untergeordnetes Objekt 30C und ein verwand­ tes Objekt 30D. Bei einer Versinnbildlichung von Fig. 3 mit der Struktur von Fig. 2 kann das Datenobjekt 30A ein Objekt der Klasse "BAUTEILDEFINITION" sein, das übergeordnete Objekt 30B kann ein "BAUGRUPPE"-Objekt sein, das untergeord­ nete Objekt 30C kann ein "PARAMETER"-Objekt sein, und das verwandte Objekt 30D kann ein "SPRECHBLASE"-Objekt sein. Im hier verwendeten Sprachge­ brauch sind zwei Objekte miteinander "verwandt", wenn zumindest eines der Ob­ jekte einen Verweis auf das andere Objekt enthält, ohne als Eigentümer oder besessenes Objekt zugeordnet zu sein. Zwei Objekte sind einander "zugeordnet", wenn sie entweder in dem oben definierten Sinne miteinander verwandt sind, oder wenn sie ein Eigentümer und ein besessenes Objekt sind. Mit anderen Worten ist ein "zugeordnetes Objekt" ein übergeordnetes Objekt oder ein untergeordnetes Objekt oder ein verwandtes Objekt.

Die unterschiedlichen Namen für die Objekte 30A bis 30D sind gewählt worden, um die unterschiedlichen Rollen dieser Objekte in dem besonderen Beispiel von Fig. 3 zu beschreiben. Es versteht sich, daß alle vier Objekte 30A bis 30D Daten­ objekte sind, die von dem CAD-Programm bearbeitet werden, und daß beispiels­ weise Objekt 30C seinerseits ein übergeordnetes Objekt eines weiteren, nicht in Fig. 3 gezeigten Datenobjekts sein kann. Jedes der Objekte 30A bis 30D weist eine Mehrzahl von Anwendungsdatenelementen auf, die Eigenschaften der ent­ sprechenden Zeichnungs- oder Entwurfsobjekte darstellen. Wenn beispielsweise das Datenobjekt 30A ein "BAUTEILDEFINITION"-Objekt ist, das den Quader 20 von Fig. 1 darstellt, können zwei von diesem Datenobjekt 30A bereitgestellte Anwendungsdatenelemente die Höhe und die Breite der Quader-Vorderseite sein.

Zwar können die in Fig. 3 gezeigten Objekte 30A-30D auch in einem CAD-Pro­ gramm nach dem Stand der Technik vorhanden sein, aber ein wichtiges neues Merkmal des vorliegenden Ausführungsbeispiels ist, daß ein Erweiterungsobjekt 32A-32D für jedes der Datenobjekte 30A-30D vorgesehen ist. Die Erweiterungs­ objekte haben die Aufgabe, verschiedene Schnittstellen- und Buchhaltungsfunk­ tionen für die Datenzugriffsmöglichkeiten des vorliegenden Ausführungsbeispiels zu implementieren.

Ein wichtiger Dienst der Erweiterungsobjekte 32A-32D ist es, die eigentlichen Datenlieferanten zu erzeugen. Der entsprechende Vorgang ist in dem Flußdia­ gramm von Fig. 4 dargestellt. Es wird angenommen, daß das Erweiterungsobjekt 32A des Datenobjekts 30A eine Anforderung zum Initialisieren der Datenzugriffs­ funktionalität erhält. Diese Anforderung, die sich nur auf das Datenobjekt 30A (und nicht auf irgendein anderes zugeordnetes Objekt) bezieht, wird von einer Methode des Erweiterungsobjekts 32A bearbeitet. Der erste Schritt 40 dieser Methode ist es, einen Datenlieferanten für das Datenobjekt 30A (Datenlieferant 34A, gezeigt in Fig. 5) zu erzeugen. Es ist die primäre Funktion des Datenlieferanten, auf interne Daten des zugeordneten Datenobjekts zuzugreifen. Dies wird unten ausführlicher beschrieben.

Nachdem der Datenlieferant 34A (Fig. 5) für das Datenobjekt 30A erzeugt worden ist, leitet das Erweiterungsobjekt 32A die Initialisierungsanforderung an die ent­ sprechenden Erweiterungsobjekte 32B-32D aller dem Datenobjekt 30A zugeord­ neten Objekte weiter. Block 42 in Fig. 4 betrifft diese Weiterleitung. Zunächst wird in Schritt 44 die Initialisierungsanforderung an alle übergeordneten Objekte gesen­ det (genauer, an die jeweiligen Erweiterungsobjekte der übergeordneten Objekte). In dem vorliegenden Beispiel gibt es nur ein übergeordnetes Objekt 30B. Das entsprechende Erweiterungsobjekt 32B beginnt nach Erhalt der Initialisierungs­ anforderung selbst eine Ausführungssequenz wie die von Fig. 4 und erzeugt damit einen Datenlieferanten 34B (Fig. 5) für das übergeordnete Objekt 30B und leitet die Initialisierungsanforderung rekursiv an weitere zugeordnete Objekte weiter.

Auf ähnliche Weise wird die Initialisierungsanforderung in Schritt 46 an das Erwei­ terungsobjekt 32C des untergeordneten Objekts 30C gesendet, und sie wird in Schritt 48 an das Erweiterungsobjekt 32D des verwandten Objekts 30D weiterge­ leitet. Offensichtlich kann die genaue Reihenfolge, in der die Schritte 44 bis 48 ausgeführt werden, in Ausführungsalternativen verändert werden. Es ist jedoch er­ forderlich, gewisse Buchhaltungsschritte auszuführen, um sicherzustellen, daß bei diesem Prozeß nur die "richtigen" Datenlieferanten erzeugt werden.

Das Ergebnis des Initialisierungsprozesses ist in Fig. 5 dargestellt. Wie oben er­ wähnt, ist ein Datenlieferant 34A bis 34D für jedes der Datenobjekte 30A bis 30D erzeugt worden. Die Definitionen der Erweiterungsobjekte 32A bis 32D und der Datenlieferantenobjekte 34A bis 34D bilden zusammen ein Computerprogramm­ produkt 50, das eingesetzt werden kann, um die Funktionalität eines CAD-Pro­ gramms nach dem Stand der Technik so zu erweitern, daß die neuen Datenzu­ griffsmöglichkeiten geboten werden.

Es versteht sich, daß jede Implementierung eines Datenlieferanten normalerweise nur für eine Art von Datenobjekten (entsprechend einer Objektart in einer Zeich­ nung) geeignet ist. Mit anderen Worten müssen der Datenlieferant 34A-34D und das entsprechende Datenobjekt 30A-30D aufeinander zugeschnitten sein, damit der Datenlieferant 34A-34D die gewünschte Datenzugriffsfunktionalität ausführen kann. Andererseits können, weil die Datenobjekte 30A-30D und die Datenliefe­ rantenobjekte 34A-34D unabhängige Einheiten sind, die Datenlieferanten 34A-­ 34D von externen Entwicklern erzeugt werden, und die Datenobjekte 30A bis 30D können unabhängig davon entwickelt und verändert werden. Es ist kein "Wissen" der Datenobjekte 30A-30D über die Datenlieferanten 34A-34D erforderlich.

In dem vorliegenden Ausführungsbeispiel gibt es keine Beschränkung hinsichtlich der maximalen Tiefe, bis zu der Verknüpfungen zu zugeordneten Objekten wäh­ rend der Initialisierung der Datenlieferanten verfolgt werden. In Ausführungsalter­ nativen wird jedoch erwogen, solche Beschränkungen einzuführen. Während es normalerweise wünschenswert sein wird, alle (unmittelbar und transitiv zugeord­ nete) übergeordneten und alle (unmittelbar und transitiv zugeordnete) verwandten Objekte eines gegebenen Datenobjekts abzudecken, kann es empfehlenswert sein, Verbindungen zu untergeordneten Objekten nur in einem beschränkten Maße zu verfolgen. Beispielsweise kann ein einziges Bauteil, daß das Datenobjekt darstellt, eine Mehrzahl Löcher aufweisen, die in das Bauteil eingearbeitet sind. Während es nützlich sein kann, die Datenlieferanten für jedes der Löcher zu initialisieren (beispielsweise, um Volumeninformationen zu erhalten, um eine genauere Berechnungsmöglichkeit des Gewichts des Bauteils bereitzustellen), ist es möglicherweise nicht wünschenswert, irgendwelche Daten über untergeordnete Objekte der Löcher zusammenzutragen, so daß der Initialisierungsvorgang abgebrochen werden kann, wenn dieses Niveau erreicht wird.

Das Flußdiagramm von Fig. 6 stellt die Bearbeitung einer Anforderung zum Erhal­ ten einer Liste der Namen aller Datenelemente dar, auf die über das Objekt 30A zugegriffen werden kann. Dieses Verfahren weist eine sehr ähnliche Struktur wie das von Fig. 4 auf. Im vorliegenden Fall wird jedoch die Anforderung an den Da­ tenlieferanten 34A des Datenobjekts 30A geschickt. Der Datenlieferant 34A gibt in Schritt 60 die Namen derjenigen Datenelemente aus, die das Datenobjekt 30A beinhaltet. Dies ist möglich, weil der Datenlieferant 34A speziell auf den Typ des Datenobjekts 30A zugeschnitten ist und somit weiß, welche Datenelemente von diesem Datenobjekt 30A verfügbar gemacht werden ("freigelegt" sind).

In den Schritten von Block 62 wird dann eine Suche nach weiteren Namen von Anwendungsdatenelementen durchgeführt, die von anderen Datenobjekten, die dem Datenobjekt 30A zugeordnet sind, verfügbar gemacht werden. Die Suche beginnt wiederum, in Schritt 64, indem bei den Datenlieferanten aller übergeord­ neter Objekte angefragt wird (in dem vorliegenden Beispiel erfolgt die Anfrage nur an den einzigen Datenlieferanten 34B des übergeordneten Objekts 30B). Jeder Datenlieferant, der die weitergeleitete Anforderung erhält, beginnt seinerseits mit dem Ausführen des Verfahrens von Fig. 6, und alle Datenelementnamen werden der Liste hinzugefügt. Der Vorgang setzt sich in Schritt 66 mit der Anfrage an Datenlieferanten jeweiliger untergeordneter Objekte fort (im vorliegenden Beispiel Datenlieferant 34C des untergeordneten Objekts 30C). Schließlich wird die Anfra­ ge an die Datenlieferanten aller verwandten Objekte weitergeleitet (im vorliegen­ den Beispiel Datenlieferant 34D des verwandten Objekts 30D).

Schritt 66 ist in Fig. 6 mit gestrichelten Linien gezeigt worden, weil das Zusammen­ tragen von Namen von den Datenlieferanten untergeordneter Objekte normaler­ weise an einer gewissen Stufe abgebrochen wird, um Namenskonflikte zu vermei­ den. In Fortführung des oben gegebenen Beispiels, bei dem ein einzelnes Bauteil mehrere durch untergeordnete Objekte dargestellte Löcher aufwies, kann jedes dieser Löcher ein Anwendungsdatenelement mit dem Namen "Durchmesser" auf­ weisen. Eine Unterscheidung zwischen diesen Variablen würde schwierige Namenskonflikte auslösen. Daher wird in dem vorliegenden Ausführungsbeispiel keines der "Durchmesser"-Datenelemente der Liste hinzugefügt. In Ausführungs­ alternativen ist ein Verfahren implementiert, um solche Namenskonflikte zu lösen, so daß als Reaktion auf die Anfrage mehr Datenelementnamen zusammengetra­ gen werden können.

Kurz wieder zu Fig. 2 zurückkehrend, soll das Beispiel betrachtet werden, daß eine Anforderung zum Zusammentragen der Namen verfügbarer Anwendungsdateriele­ mente an den Datenlieferanten des "SPRECHBLASE"-Objekts gerichtet wird, das dem "STÜCKLISTENELEMENT"-Objekt verwandt ist. Das "SPRECHBLASE"-Ob­ jekt selbst stellt keine internen Daten zur Verfügung, aber es leitet die Anfrage an den Datenlieferanten des verwandten "STÜCKLISTENELEMENT"-Objekts weiter. Dieser Datenlieferant stellt die Variablennamen "ELEMENT" (Element = item) und "MENGE" (Menge = quantity = qty.) zur Verfügung und leitet die Anforderung an die Datenlieferanten des übergeordneten Objekts "STÜCKLISTE" und des ver­ wandten Objekts "BAUTEILDEFINITION" weiter. Der Datenlieferant des "STÜCK­ LISTE"-Objekts stellt beispielsweise die Masse aller Elemente in der Stückliste unter dem Namen "STÜCKLISTE:MASSE" bereit. Der Datenlieferant des "BAU­ TEILDEFINITION"-Objekts stellt die Masse dieses Bauteils unter dem Namen "BAUTEIL : MASSE" und andere Attribute, zum Beispiel "MATERIAL", bereit und leitet die Anforderung ferner an die Datenlieferanten aller untergeordneten Objekte "PARAMETER" und des übergeordneten Objekts "BAUGRUPPE" weiter. Der Datenlieferant jedes "PARAMETER"-Objekts stellt den Parameterwert mit seinem Namen zur Verfügung und fügt ihn der Liste hinzu. Der Datenlieferant des "BAU­ GRUPPE"-Objekts fügt schließlich globale Variablen hinzu, zum Beispiel den Namen "GLOBALHÖHE" (Globalhöhe = global height = globheight).

Insgesamt wird die folgende Liste verfügbarer Variablennamen als Antwort auf die Anforderung erzeugt: "ELEMENT, MENGE, STÜCKLISTE : MASSE, BAU­ TEIL : MASSE, MATERIAL, BAUTEIL : LÄNGE, GLOBALHÖHE". Offensichtlich stellt diese Liste eine große Menge an Informationen über die betreffenden An­ wendungsdatenelemente dar. Unter Verwendung des Verfahrens des vorliegen­ den Ausführungsbeispiels war es möglich, diese Informationen auf Grundlage eines Bezugs auf ein einziges Datenobjekt, nämlich das "SPRECHBLASE"-Objekt, zu erhalten. Keine Informationen über die interne Struktur der Anwendungsdaten war erforderlich.

Außer dem Dienst, die Namen aller zugreifbaren Anwendungsdatenelemente zu erhalten, dienen die Datenlieferanten 34A-34D auch zur Implementierung unter­ schiedlicher Datenzugriffs- und Datenmanipulationsdienste. Beispielsweise kann auf den Wert eines Anwendungsdatenelements des Datenobjekts 30A oder jedes zugeordneten Objekts 30B-30D zugegriffen werden.

Ein erstes Ausführungsbeispiel für ein Verfahren zum Bearbeiten einer solchen Anforderung für einen Datenzugriff ist in Fig. 7 gezeigt. Wenn der Datenlieferant 34A des Datenobjekts 30A die Anforderung empfängt, wird in Test 70 überprüft, ob das Datenobjekt 30A ein Datenelement mit dem in der Anforderung gegebenen Namen beinhaltet. Wenn ein solches Datenelement verfügbar ist ("JA"-Zweig von Test 70), wird sein Wert in Schritt 72 ermittelt und der Verfahrensablauf endet. Wenn das Datenobjekt 30A kein geeignet benanntes Datenelement enthält, wird die Anforderung in Block 74 an alle zugeordneten Objekte weitergeleitet. Dies umfaßt in dem vorliegend beschriebenen Ausführungsbeispiel das Weiterleiten der Anforderung an die Datenlieferanten aller übergeordneten Objekte (Schritt 76), an die Datenlieferanten aller untergeordneten Objekte (Schritt 78) und an die Daten­ lieferanten aller verwandten Objekte (Schritt 80). Die Datenlieferanten der Objekte, an die die Anforderung weitergeleitet wird, beginnen wiederum mit der Ausführung des Verfahrens von Fig. 7.

Offensichtlich kann dieses erste Ausführungsbeispiel der Datenzugriffsfunktionali­ tät gemäß dem Verfahren von Fig. 7 bei großen Netzen miteinander verbundener Datenobjekte unnötig viel Rechenzeit beanspruchen. Daher werden mehrere Aus­ führungsalternativen erwogen, bei denen die Datenzugriffsanforderung selektiver weitergeleitet wird. In einer zweiten Ausführungsform gibt jedes Objekt, das eine weitergeleitete Datenzugriffsanforderung erhält, einen Hinweis zurück, ob die An­ forderung erfolgreich erfüllt werden konnte oder nicht. Dies ermöglicht es, die Aus­ führung von Block 74 zu beenden, sobald der erste erfolgreiche Datenzugriff von einem zugeordneten Objekt mitgeteilt wird. Diese optionale Möglichkeit einer früh­ zeitigen Beendigung von Block 74 ist in Fig. 7 durch den gestrichelten Pfeil 82 angezeigt. In anderen Ausführungsalternativen verwaltet der Datenlieferant jedes Datenobjekts Informationen über die Namen derjenigen Datenelemente, die von anderen zugeordneten Datenobjekten verfügbar sind. In diesem Fall kann eine Datenzugriffsanforderung auf direktere Art und Weise als in Fig. 7 angezeigt an den zuständigen Datenlieferanten weitergeleitet werden.

Es ist wiederum bemerkenswert, daß die Datenzugriffsfunktionalität verwendet werden kann, um Zugriff auf sehr viele von dem Anwendungsprogramm verarbei­ tete Anwendungsdatenelemente zu erhalten, sogar wenn die interne Organisation der Datenelemente und insbesondere die Verbindungsstruktur zwischen den Datenobjekten nicht bekannt ist. Es reicht aus, mit der Anforderung einen Verweis auf ein einziges Datenobjekt 30A zu liefern.

Eine weitere wichtige Funktionalität, die vom Datenlieferantobjekt bereitgestellt wird, ist die des Setzens oder Änderns einzelner Datenelemente. Die Bearbeitung einer solchen Anforderung zum Einstellen von Daten weist auch die in Fig. 7 gezeigte Struktur auf, natürlich mit der Änderung, daß Schritt 72 ein Schritt ist, bei dem das Datenelement geschrieben wird. Es sind auch dieselben Ausführungs­ alternativen, wie sie oben in Verbindung mit Fig. 7 beschrieben worden sind, möglich.

Andere Funktionen, die von den Datenlieferanten 34A bis 34D implementiert wer­ den, sind unter anderem eine Überprüfung, ob ein Datenelement mit einem ange­ gebenen Namen in dem Datenobjekt eines Datenlieferanten oder in einem zuge­ ordneten Objekt existiert, die Überprüfung, ob ein Datenelement veränderbar ist, und die Überprüfung, ob neue Datenelemente dem Datenobjekt hinzugefügt werden können.

Die Erweiterungsobjekte 32A bis 32D und die Datenlieferanten 34A bis 34D sind Routinen auf einer relativ niedrigen Ebene zum Zugriff auf interne Anwendungs­ daten des CAD-Programms. Während diese Routinen von externen Entwicklern und auch vom Endanwender eingesetzt werden können, um Erweiterungen des CAD-Programms zu programmieren, weist eine bevorzugte Ausführungsform des Computersoftwareprodukts (Bezugszeichen 50 in Fig. 5) ferner einen Evaluator auf, um die erfindungsgemäße Funktionalität auf benutzerfreundlichere Art und Weise bereitzustellen. Der Evaluator kann verwendet werden, um Textausdrücke, die Namen von Datenelementen (in spitzen Klammern eingeschlossen), einfache mathematische Operatoren (z. B. "+", "-", ".", "/") und beliebigen Text zur Erläute­ rung aufweisen, auszuwerten. Beispielsausdrücke, die durch den Evaluator verar­ beitet werden können, sind zum Beispiel:
"Titel der Zeichnung: <SI : TITEL<"
"= <ST : TITEL<: Der Titel der aktuellen Zeichnung"
oder allgemeiner:
"= freier_Text_1 <Ausdruck1< freier_Text_2 <Ausdruck2< . . .".

Um eine verbesserte Benutzerunterstützung bereitzustellen, bietet der Evaluator auch die Funktionalität an, voreingestellte Ausdrücke für jedes Datenobjekt vor­ zuschlagen. Solche voreingestellten Ausdrücke sind Ausdrücke, die normalerweise in Verbindung mit einem bestimmten Datenobjekt als nützlich angesehen werden. Auch wenn der Benutzer unmittelbar keinen der voreingestellten Ausdrücke benö­ tigt, dienen sie zumindest als Vorlagen, um den Benutzer beim Formulieren seiner oder ihrer eigenen Ausdrücke zu unterstützen, und sie enthalten auch alle oder mindestens einige der Namen der verfügbaren Datenelemente.

Eine Anforderung zum Erhalten von Beispielsausdruck-Zeichenketten, die der Evaluator empfängt, wird an das Erweiterungsobjekt eines Datenobjekts weiterge­ leitet, für das der Evaluator erzeugt worden ist. Dieses Erweiterungsobjekt führt dann ein Verfahren aus, das dem in Fig. 6 gezeigten ähnelt, das heißt, es gibt seine eigene Beispielsausdruck-Zeichenkette oder -Zeichenketten aus und leitet die Anforderung an die Erweiterungsobjekte der anderen zugeordneten Objekte weiter. Im Gegensatz zum Verfahren nach Fig. 6 wird die Anforderung jedoch von den Erweiterungsobjekten 32A-32D (und nicht von den Datenlieferantobjekten 34A-34D) bearbeitet, weil die Erweiterungsobjekte 32A-32D geeigneter dafür sind, Datenelementnamen, die von einer Vielzahl unterschiedlicher Datenobjekte stammen, zu sammeln und zu einzelnen Beispielsausdrücken zu kombinieren.

Eine mögliche Ausführungssequenz eines den Evaluator verwendenden Verfah­ rens gemäß einem Ausführungsbeispiel der Erfindung ist in Fig. 8 gezeigt. Der Beispielsablauf wird dadurch begonnen, daß der Benutzer auf ein Datenobjekt zeigt und für dieses Objekt einen Beispielsausdruck anfordert (Benutzeraktion 90). Beispielsweise, und auf Fig. 1 Bezug nehmend, kann der Benutzer mit Hilfe der Maus 14 auf die auf der Videoanzeige 16 gezeigte Sprechblase 22 zeigen und über ein Kontextmenü mögliche Beispielsausdrücke anfordern.

In Reaktion auf die Zeigeaktion des Benutzers wird in Schritt 92 der Pfad des Datenobjekts, auf das gezeigt wird, bestimmt. Dieser Pfad, der der vollständige hierarchisch strukturierte Identifikator des Datenobjekts ist, wird verwendet, um einen Evaluator für das Datenobjekt zu erzeugen und um ihn mit dem entspre­ chenden Datenlieferanten und dem Erweiterungsobjekt zu initialisieren. Fig. 9 zeigt beispielhaft einen solchen Evaluator 120, der erzeugt worden ist, um einen Daten­ zugriff auf das Datenobjekt 30A (das im vorliegenden Beispiel der Sprechblase 22 entspricht) bereitzustellen, und der im Hinblick auf das Erweiterungsobjekt 32A und den Datenlieferanten 34A initialisiert worden ist. Die Definition des Evaluators 120 ist auch Bestandteil des Computerprogrammprodukts 50 des vorliegend be­ schriebenen Ausführungsbeispiels.

Zum Flußdiagramm von Fig. 8 zurückkehrend, erhält der Evaluator nun die Liste der Beispielsausdrücke (Schritt 96) von dem Erweiterungsobjekt 32A des Daten­ objekts 30A. Die in diesem Zusammenhang ausgeführten Verarbeitungsschritte sind bereits oben allgemein beschrieben worden. Im vorliegenden Beispiel, und unter Hinweis auf Fig. 1, bietet die Sprechblase 22 (für die der Evaluator initialisiert worden ist) keinen Beispielsausdruck an, aber sie leitet die Anforderung auf das Erweiterungsobjekt des zugeordneten Datenobjekts, das den Quader 20 darstellt, weiter. Der erste in Verbindung mit dem Quader 20 zurückgelieferte Beispiels­ ausdruck kann der Ausdruck "Fläche der Vorderseite: <HÖHE.BREITE< m^∧2" sein, der die Fläche der sichtbaren Vorderseite des Quaders 20 ergibt. Dieser erste Beispielsausdruck wird in Schritt 98 dargestellt, und dem Benutzer wird Gelegenheit gegeben, die anderen möglichen Beispielsausdrücke zu durchlaufen.

Wenn der Benutzer die Auswahl eines Beispielsausdrucks in einer Benutzeraktion 100 bestätigt, wird der ausgewählte Ausdruck in dem Datenobjekt, auf das sich der Benutzer bezieht, verwendet. Im vorliegenden Fall wird dieser Ausdruck in das­ jenige Datenobjekt aufgenommen, das die Sprechblase 22 darstellt. Der Ausdruck wird nun in Schritt 104 ausgewertet und das Auswertungsergebnis wird dem Be­ nutzer als Inhalt der Sprechblase 22 dargestellt (Schritt 106).

Das in der Sprechblase 22 gezeigte Ergebnis bleibt so lange unverändert, wie sich die Werte der in dem entsprechenden Ausdruck verwendeten Datenelemente nicht verändern (Wartezustand 108). Immer wenn eine solche Veränderung stattgefun­ den hat oder stattgefunden haben könnte, wird automatisch ein Neuberechnungs­ ereignis 110 ausgelöst. Zusätzlich wird eine Neuberechnung aller Ausdrücke auch auf manuelle Anforderung des Benutzers ausgeführt, oder wenn die gesamte Zeichnung neu dargestellt wird. Die Schritte 104 und 106 werden im Verlauf der Neuberechnung wiederholt. Dies stellt sicher, daß die in der Zeichnung angezeig­ ten Werte von Ausdrücken immer korrekt sind und daß sie automatisch jede Modifikation oder Veränderung der Zeichnungsobjekte widerspiegeln.

Die Fähigkeit des vorliegenden Ausführungsbeispiels zur Auswertung von Aus­ drücken ist oben am Beispiel eines in der Sprechblase 22 enthaltenen Ausdrucks beschrieben worden. Es ist jedoch offensichtlich, daß Ausdrücke ebensogut bei einer Vielzahl anderer Zeichnungsobjekte verwendet werden können, insbeson­ dere in "STÜCKLISTE"- und "STÜCKLISTENELEMENT"-Objekten sowie in "TEILELISTE"- und "ANMERKUNG"-Objekten (Anmerkung = note). Als weiteres Beispiel könnte der Titelblock einer Zeichnung Datenelemente des zugeordneten "STÜCKLISTE"-Objekts verwenden, um den voreingestellten Maßstab darzustel­ len oder um Informationen wie beispielsweise die Gesamtmasse, den Namen der Stückliste, den zum Erstellen der Zeichnung verwendeten Standard darzustellen. Es ist ferner ohne weiteres möglich, parametrische "ANMERKUNG"-Objekte für jedes Zeichnungsobjekt zu erzeugen, und eine intelligente Annotierung von Fasen und Kehlen (die immer die richtigen Größen anzeigt) ist möglich. Die von den Zeichnungsobjekten erhaltenen Daten können auch in ein Rechenblatt exportiert werden, und die Oberflächenbeschaffenheit kann das tatsächlich der Oberfläche zugeordnete Attribut anzeigen, wenn ein solches Attribut existiert.

In weiteren Ausführungsalternativen verarbeitet der Evaluator nicht nur dimen­ sionslose Zahlen, sondern auch Einheiten. Funktionen werden bereitgestellt, um die sich ergebenden Einheiten aus einem Ausdruck zu berechnen, um Werte mit unterschiedlichen Grundeinheiten (z. B. Millimeter und Zoll) ineinander umzuwan­ deln, und um Rechnungen mit unterschiedlichen abgeleiteten Einheiten (z. B. Milli­ meter, Meter, Kilometer) korrekt auszuführen.

Es ist offensichtlich, daß die oben beschriebenen Anwendungsmöglichkeiten und Ausführungsalternativen lediglich einige Beispiele darstellen, und daß ein weiter Bereich weiterer Anwendungen der Lehren der vorliegenden Erfindung sowohl im Zusammenhang mit CAD-Programmen als auch hinsichtlich anderer Anwendungs­ programme besteht.

Claims (19)

1. Ein Verfahren zum Bereitstellen einer Zugriffsmöglichkeit auf Anwendungs­ datenelemente eines Anwendungsprogramms, wobei die Anwendungsdatenele­ mente in einer Mehrzahl miteinander verknüpfter und von dem Anwendungspro­ gramm verarbeiteter Datenobjekte (30A-30D) enthalten sind und das Verfahren die Schritte aufweist:

• - Empfangen einer Anforderung, die mindestens eines der Anwendungs­ datenelemente betrifft, wobei sich die Anforderung auf ein Datenobjekt der Mehr­ zahl von Datenobjekten bezieht,
• - Erfüllen der Anforderung im Hinblick auf dasjenige Datenobjekt, auf das sich die Anforderung bezieht, und
• - wenn die Anforderung mindestens ein anderes Datenobjekt der Mehrzahl von Datenobjekten betrifft, Weiterleiten der Anforderung an das mindestens eine andere Datenobjekt zur Weiterverarbeitung der Anforderung.

2. Das Verfahren nach Anspruch 1, bei dem das Weiterverarbeiten der Anforderung durch ein anderes Datenobjekt, an das die Anforderung weitergeleitet worden ist, die Schritte aufweist:

• - Erfüllen der Anforderung im Hinblick auf das andere Datenobjekt, an das die Anforderung weitergeleitet worden ist, und
• - wenn die Anforderung mindestens ein weiteres Datenobjekt betrifft, Weiter­ leiten der Anforderung an das mindestens eine weitere Datenobjekt zur Weiterver­ arbeitung der Anforderung.

3. Das Verfahren nach Anspruch 1 oder Anspruch 2, bei dem die Datenobjekte miteinander auf eine Weise verknüpft sind, daß jedem Datenobjekt null oder mehr Datenobjekte zugeordnet sind, und bei dem jede Anforderung als zumindest einige derjenigen Datenobjekte betreffend angesehen wird, die demjenigen Datenobjekt zugeordnet sind, auf das sich die Anforderung bezieht.

4. Das Verfahren nach einem der Ansprüche 1 bis 3, bei dem die Datenobjekte miteinander auf eine Weise verknüpft sind, daß jedem Datenobjekt null oder mehr Datenobjekte als übergeordnete Objekte zugeordnet sind, und null oder mehr Datenobjekte als untergeordnete Objekte zugeordnet sind, und null oder mehr Datenobjekte als verwandte Objekte zugeordnet sind, und bei dem jede Anforderung als zumindest diejenigen Datenobjekte betreffend ange­ sehen wird, die demjenigen Datenobjekt, auf das sich die Anforderung bezieht, als Superobjekte zugeordnet sind, und als zumindest diejenigen Datenobjekte betref­ fend, die dem Datenobjekt, auf das sich die Anforderung bezieht, als verwandte Objekte zugeordnet sind.

5. Das Verfahren nach Anspruch 4, bei dem jede Anforderung zusätzlich als zumindest diejenigen Datenobjekte be­ treffend angesehen wird, die mit demjenigen Datenobjekt, auf das sich die Anfor­ derung bezieht, als untergeordnete Objekte verknüpft sind.

6. Das Verfahren nach einem der Ansprüche 1 bis 5, bei dem die Anforderung eine Anforderung zur Initialisierung der Zugriffsbereitstel­ lungsfunktionafität ist, und bei dem der Schritt des Erfüllens der Anforderung für ein Datenobjekt (30A-30D) die Erzeugung (40) eines Datenlieferanten (34A-34D) umfaßt, der dem Datenobjekt (30A-30D) zugeordnet ist.

7. Das Verfahren nach Anspruch 6, bei dem die Anforderung zur Initialisierung der Zugriffsbereitstellungsfunktionalität von mindestens einem Erweiterungsobjekt (32A-32D) verarbeitet wird, das dem Datenobjekt (30A-30D), auf das sich die Anforderung bezieht, zugeordnet ist.

8. Das Verfahren nach einem der Ansprüche 3 bis 7, bei dem die Anforderung eine Anforderung zum Erhalten einer Ansammlung mit den Namen aller Anwendungsdatenelemente ist, auf die über das Datenobjekt, auf das sich die Anforderung bezieht, zugegriffen werden kann.

9. Das Verfahren nach einem der Ansprüche 3 bis 8, bei dem die Anforderung eine Anforderung zum Erhalten einer Ansammlung von Beispielsausdrücken ist, wobei die Beispielsausdrücke mindestens einige der Namen der Anwendungsdatenelemente enthalten, auf die über das Datenobjekt, auf das sich die Anforderung bezieht, zugegriffen werden kann.

10. Das Verfahren nach Anspruch 8 oder Anspruch 9, bei dem die über das Datenobjekt, auf das sich die Anforderung bezieht, zugreif­ baren Anwendungsdatenelemente die in dem Datenobjekt, auf das sich die Anfor­ derung bezieht, enthaltenen Anwendungsdatenelemente und die in irgendeinem der diesem Objekt zugeordneten Datenobjekte enthaltenen Anwendungsdaten­ elemente aufweisen.

11. Das Verfahren nach einem der Ansprüche 3 bis 10, bei dem die Anforderung eine Anforderung zum Erhalten (72) des Werts eines in dem Datenobjekt, auf das sich die Anforderung bezieht, oder in irgendeinem der diesem Objekt zugeordneten Datenobjekte enthaltenen Anwendungsdatenele­ ments ist:

12. Das Verfahren nach Anspruch 11, ferner mit den Schritten:

• - Erzeugen (94) eines Evaluators (120) für ein Datenobjekt;
• - Aufrufen des Evaluators (120) mit einem Ausdruck, der mindestens einen Namen eines Anwendungsdatenelements enthält, das in dem Datenobjekt oder in irgendeinem der diesem Objekt zugeordneten Datenobjekte enthalten ist,
• - Auswerten (104) des Ausdrucks unter Verwendung erhaltener Werte der Anwendungsdatenelemente, deren Namen in dem Ausdruck enthalten sind, und
• - Ausgeben (106) des Auswertungsergebnisses.

13. Das Verfahren nach Anspruch 12, bei dem die Schritte des Auswertens (104) des Ausdrucks und des Ausgebens (106) des Ergebnisses beim Auftreten eines Neuberechnungsereignisses (110) wiederholt werden.

14. Das Verfahren nach Anspruch 12 oder Anspruch 13, bei dem das Ergebnis der Auswertung als ein Anwendungsdatenelement eines der von dem Anwendungsprogramm verarbeiteten Datenobjekte ausgegeben wird.

15. Das Verfahren nach einem der Ansprüche 1 bis 14, bei dem die Hauptfunktionalität des Anwendungsprogramms die graphische und/oder textuelle Anzeige und/oder Verarbeitung von Dokumenten ist, die die Datenobjekte widerspiegeln.

16. Das Verfahren nach einem der Ansprüche 1 bis 15, bei dem das Anwendungsprogramm ein CAD-Programm ist und die Anwendungs­ daten die Zeichnungs- und/oder Designdaten sind, die von dem CAD-Programm verarbeitet werden.

17. Das Verfahren nach einem der Ansprüche 1 bis 16, bei dem die Zugriffsmöglichkeit als eine Hilfsfunktion des Anwendungsprogramms bereitgestellt wird.

18. Ein Computerprogrammprodukt (50) zur Ausführung durch einen Computer zum Bereitstellen einer Zugriffsmöglichkeit auf Anwendungsdatenelemente eines Anwendungsprogramms, wobei das Computerprogrammprodukt (50) Befehle auf­ weist, die den Computer veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 17 auszuführen.

19. Eine Vorrichtung mit mindestens einem Computer, der dazu programmiert ist, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 17 auszuführen.