DE10245018A1

DE10245018A1 - Verfahren und Gerät zum Präsentieren von Ressourcen in einer Computersystemumgebung

Info

Publication number: DE10245018A1
Application number: DE10245018A
Authority: DE
Inventors: Morrie Gasser; Clifford E Kahn
Original assignee: EMC Corp
Current assignee: EMC Corp
Priority date: 2001-09-28
Filing date: 2002-09-26
Publication date: 2003-04-17
Also published as: US7032186B1; GB2382185B; JP4040411B2; JP2007287178A; GB2382185A; GB0219742D0; JP2003208349A; JP4512620B2

Abstract

Ein Computersystem und Computerverfahren liefern Systeme zum Repräsentieren einer Ressource oder von Ressourcen in einer Computersystemumgebung, indem ein Objekt erzeugt wird, um eine Ressource in der Computersystemumgebung zu repräsentieren und um einen Objektidentifizierer dem Objekt zuzuordnen. Der Objektidentifizierer enthält wenigstens einen einfachen Namen des Objektes und ein Heim des Objektes. Das System stellt wenigstens eine Repräsentation des Objektes an einem graphischen Anwenderinterface dar. Jede Repräsentation des Objektes enthält den einfachen Namen des Objektes und, wenn eine Heimbedingung für diese Repräsentation des Objektes existiert, welches an dem graphischen Anwenderinterface dargestellt wird, enthält die Repräsentation ferner das Heim des Objektes, und, wenn eine Heimbedingung für diese Repräsentation des Objektes nicht existiert, enthält die Repräsentation des Objektes, welches an dem graphischen Anwenderinterface dargestellt wird, nicht das Heim des Objektes. Das graphische Anwenderinterface kann auch Gruppen vermitteln, die transparent sind und als Terminal bezeichnet werden, um eine Sichtanordnung der Ressourcenrepräsentationen ohne Beeinflussung solcher Ressourcen zuzulassen.

Description

IN BEZIEHUNG STEHENDE ANMELDUNGEN, DIE DURCH BEZUGNAHME MIT EINBEZOGEN WERDEN

Die vorliegende Erfindung betrifft eine gleichlaufende US-Patentanmeldung mit dem Titel "VERFAHREN UND GERÄT ZUM GRAPHISCHEN MANAGEN VON RESSOURCEN" mit der Anwalts-Docket-Nr. EMC01-07(01042), eingereicht am selben Tag wie die vorliegende Anmeldung. Die vorliegende Erfindung betrifft auch eine gleichlaufende US-Patentanmeldung mit der Seriennummer 09/547510 mit dem Titel "VERFAHREN UND GERÄT ZUM PRÄSENTIEREN VON INFORMATIONEN FÜR EINEN ANWENDER EINES COMPUTERSYSTEMS" mit der Anwalts-Docket-Nr. EMC00-02(00012), eingereicht am 12. April 2000. Diese in Beziehung stehenden Patentanmeldungen sind der Anmelderin der vorliegenden Erfindung zugeordnet. Die gesamten Lehren und Inhalte dieser Bezugspatentanmeldungen werden hier unter Bezugnahme darauf vollständig mit einbezogen.

GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft allgemein Computer- und Softwaresysteme zum Managen von Ressourcen in einer Computer- und/oder Speichersystemumgebung, und betrifft spezieller einen Mechanismus und Techniken, die Repräsentationen solch einer Ressource über ein graphisches Anwenderinterface liefern.

HINTERGRUND DER ERFINDUNG

Viele Typen von herkömmlichen Computersystemen arbeiten mit Hilfe von Softwareprogrammen, die ein graphisches Anwenderinterface (GUI) enthalten, welches die Möglichkeit schafft, daß ein Anwender des Computersystems vielfältige Typen von Hardware oder Softwareressourcen in einer Umgebung graphisch sehen, managen, steuern und/oder konfigurieren kann, in welcher Umgebung das Computersystem arbeitet. Das graphische Anwenderinterface kann beispielsweise die Möglichkeit bieten, daß ein Anwender des Computersystems mit dem Computersystem interagiert und auch mit dessen zugeordneten Softwareanwendungen, Dateisystem(en), Daten, Vorrichtungen und/oder peripheren Geräten. Das Computersystem kann in einer Netzwerkumgebung arbeiten und das Softwareprogramm kann eine Netzwerkmanagementanwendung sein, welches das graphische Anwenderinterface vorsieht, um dem Anwender die Möglichkeit zu gelben, von der Ferne aus andere Computersysteme und/oder Ressourcen zu managen und zu steuern, die über ein Netzwerk fernangekoppelt sind. Die Ressourcen, die graphisch auf diese Weise gemanagt werden können, können ein Speichersystem und Vorrichtungsressourcen, wie beispielsweise Platten, Dateisysteme, Volumen und ähnliches, Netzwerkvorrichtungsressourcen, wie beispielsweise Schaltstellen, Hostcomputersystemressourcen, wie beispielsweise Clients oder Server, und Softwareanwendungen umfassen, die mit einer oder mit mehreren solchen Komponenten arbeiten. Ein Anwender betrachtet, managt und konfiguriert oder bearbeitet auf andere Weise derartige Ressourcen vermittels einer Manipulation einer Repräsentation der Ressourcen, welche die Softwareanwendung liefert (z. B. Darstellungen oder Übermittlungen), und zwar auf dem graphischen Anwenderinterface.
Herkömmliche Ressourcenmanagementsoftwareanwendungen (z. B. Netzwerk- oder Vorrichtungsmanagersoftware) liefert in typischer Weise eine Repräsentation von jeder Ressource auf dem graphischen Anwenderinterface unter Verwendung eines jeweiligen Icons, gepaart mit einem Ressourcenidentifizierer. Das Icon liefert eine kleine graphische Repräsentation der Ressource, während der Ressourcenidentifizierer einen Text oder einen aus Zeichen bestehenden Folgenamen für die Ressource bildet. Die Softwareanwendung stellt den Ressourcenidentifizierer in einer voll qualifizierten Weise dar. Ein voll qualifizierter Ressourcenidentifizierer übermittelt das Namensgebungsschema, welches die Software oder das Betriebssystem den Ressourcen aufdrückt. Beispielsweise kann ein voll qualifizierter Ressourcenidentifizierer eine Folge von alphanumerischen Zeichen enthalten (z. B. Text und/oder Ziffern), die eine bestimmte Datei und Pfad angeben, und zwar für diese Datei in einem Dateisystem, um jede Ressource in einer einmaligen Weise zu identifizieren.
Bei vielen Computersystemumgebungen haben die Ressourcen hierarchische Beziehungen mit anderen Ressourcen (z. B. Dateien in einer Dateisystemhierarchie). Auf Grund solcher hierarchischer Beziehungen und um die Einmaligkeit für jeden Ressourcenidentifizierer zu gewährleisten, enthält ein voll qualifizierter Ressourcenidentifizierer für eine Ressource in einem herkömmlichen Ressourcenmanagementsystem bzw. -anwendung eine "Hierarchieörtlichkeit oder -lage", wie beispielsweise einen Pfadnamen für die Ressource in der Ressourcenhierarchie (z. B. den Directory- oder Verzeichnispfad einer Datei in einer Dateisystemhierarchie), gefolgt von dem "einfachen Namen" der Ressource, welches der Name der Ressource ist (z. B. der Dateiname der Datei in dem Dateisystem). Wenn als Beispiel die Ressource aus einer Textdatei besteht, die einen einfachen Namen hat "myfile.txt" und eine hierarchische Dateisystemörtlichkeit oder -lage "/user/person/home/textfiles/" hat, so erscheint ein voll qualifizierter Ressourcenidentifizierer dieser Ressource in der folgenden Form "user/person/home/textfiles/myfile.txt" in dem graphischen Anwenderinterface.
Herkömmliche Ressourcenmanagementanwendungen, die graphische Anwenderinterfaces enthalten, welche solche Namensgebungsschemata für Ressourcen darstellen, ermöglichen es einem Anwender in typischer Weise, den einfachen Namen für eine Ressource auszuwählen oder zu modifizieren. Beispielsweise kann es dem Anwender gestattet werden, die Datei "myfile.txt" in "ourfile.txt" umzubenennen. Jedoch ordnet die Ressoureenmanagementanwendung in typischer Weise automatisch den hierarchischen Örtlichkeitsabschnitt des voll qualifizierten Ressourcenidentifizierers zu, und zwar basierend darauf, wo die Ressource tatsächlich in der Ressourcenhierarchie gelegen ist. Ein Anwender kann den hierarchischen Örtlichkeitsabschnitt eines voll qualifizierten Ressourcenidentifizierers dadurch ändern, indem er den Namen oder die Namen des Directory (oder Directories) oder des Verzeichnisses oder der Verzeichnisse ändert, welche die hierarchische Örtlichkeit der Ressource in der Ressourcenhierarchie ausmachen oder indem er aktiv die Ressource (z. B. die Datei) zu einer neuen Stelle (einem neuen Directory) innerhalb der Ressourcenhierarchie bewegt.
Die Windowsfolgen von Betriebssystemen (z. B. Windows 95, Windows 98, Windows NT, Windows 2000, die kollektiv hier als Windows bezeichnet werden) und von der Microsoft Corporation of Redmond Washington, USA, hergestellt werden, liefern eine Ressourcenidentifizierung und ein Namensgebungsschema, welches in einer Weise arbeitet ähnlich demjenigen, welches oben beschrieben ist. Windows 95, Windows 98, Windows NT und Windows 2000 sind Markennamen der Microsoft Corporation.
Im allgemeinen bietet Windows Zugriff auf Computersystemressourcen über eine graphische Repräsentation der Computersystemressourcen, die als Desktop bezeichnet werden. Der Windowsdesktop ermöglicht es einem Anwender des Computersystems, beispielsweise innerhalb des Dateisystems zu navigieren und Dateien innerhalb von Dateisystemen zu managen, die innerhalb einer oder mehrerer Speichervorrichtungen (z. B. Platten) enthalten sind, welche dem Computersystem zugeordnet sind. Ein begrenztes Vorrichtungsmanagement wird ebenfalls über den Windowsdesktop ermöglicht und ist Windowsanwendungen zugeordnet, die graphische Anwenderinterfaces für Vorrichtungsmanagementfunktionen bieten. Ein Beispiel einer Softwareanwendung, die in Windows enthalten ist und solche Dateisystem- und Vorrichtungsmanagementmöglichkeiten über ein graphisches Anwenderinterface bietet, ist das Windows-Explorer-Anwendungsprogramm.
Ein Anwender kann den Windows-Explorer verwenden, um bestimmte Ressourcen zu betrachten und graphisch darin zu navigieren und diese zu managen, die dem Computersystem bzw. dem Betriebssystem Windows, welches auf dem System läuft, zugeordnet sind. Um dies auszuführen, liefert die linke Seite des graphischen Anwenderinterfaces innerhalb des Windows-Explorers eine hierarchische und graphische Repräsentation der Ressourcen, die das Computersystem betreffen. Beispielsweise kann der Windows-Explorer Directories auf der Platte (den Platten) präsentieren, die für das Computersystem zugreifbar sind, und zwar als eine hierarchische Anordnung von Verzeichnis-Icons gepaart mit einem einfachen Namen des Directory, der diesem Verzeichnis entspricht. Jedes Verzeichnis-Icon und Einfach-Name-Paar in der Hierarchie entspricht direkt dem Directory auf der Platte, der den einfachen Namen besitzt und die Dateien enthält und/oder andere Verzeichnisse (das heißt Subdirectories) enthält. Ein Anwender kann auf ein Verzeichnis-Icon/Einfach-Name-Paar klicken oder doppelklicken (im folgenden als Verzeichnis-Icon bezeichnet), und zwar in der Hierarchie, um dieses Verzeichnis zu öffnen oder zu schließen.
Im Ansprechen auf das Klicken des Anwenders auf das Verzeichnis-Icon, um dieses Verzeichnis in der Hierarchie zu "öffnen", stellt der Windows-Explorer das Verzeichnis-Icon in der Hierarchie auf der linken Seite der GUI erneut dar, so daß dieses Verzeichnis als "offenes" Verzeichnis-Icon erscheint und es wird die linksseitige Hierarchie modifiziert, so daß sie eine Anzeige von irgendwelchen untergeordneten Verzeichnis-Icons und Einfach-Name-Paaren der Subdirectories enthält, die hierarchisch unterhalb oder "innerhalb" des geöffneten Verzeichnisses existieren. Zusätzlich werden auf der rechten Seite des Windows-Explorers bzw. des graphischen Anwenderinterfaces die Windows-Explorer-Anzeigeressourcenidentifizierer für jegliche Verzeichnisse bzw. Dateien oder Verzeichnisse dargestellt, die innerhalb des ausgewählten (das heißt des geöffneten) Verzeichnisses in der Hierarchie existieren.
Einige graphische Anwenderinterfaces von Softwareanwendungen ermöglichen es einem Anwender, eine Steuerung durchzuführen, ob die Ressourcenidentifizierer gezeigt werden, und zwar unter Verwendung von einfachen Namen, oder durch Verwendung von voll qualifizierten Ressourcenidentifizierern. Wenn in einigen Fällen viele Ressourcenidentifizierer dargestellt werden müssen, kann das graphische Anwenderinterface die Ressourcenidentifizierer (voll qualifiziert oder mit lediglich dem einfachen Namen) in einer aufwärts/abwärts-scrollfähigen Liste der Ressourcenidentifizierer darstellen. Wenn zusätzlich die Ressourcen dargestellt werden, und zwar unter Verwendung von deren voll qualifiziertem Ressourcenidentifizierer und des hierarchischen Örtlichkeitsabschnitts eines Ressourcenidentifizierers (das heißt dem Pfadnamen einer Datei) und viele Directorynamen enthalten sind, so kann der voll qualifizierte Ressourcenidentifizierer alphanumerische Zeichen enthalten, die sich in der Länge jenseits der Grenzen erstrecken (z. B. jenseits der äußerst rechten Seite) eines Fensters in dem graphischen Anwenderinterface. Mit anderen Worten kann die gesamte Kombination aus der hierarchischen Örtlichkeit, gefolgt von dem einfachen Namen einer Datei oder des Directory oder einer anderen Ressource, nicht vollständig in dem Fenster sichtbar sein. In solchen Fällen kann das graphische Anwenderinterface auch einen Rechts/Links- Scrollbar vorsehen, um es dem Anwender zu ermöglichen, die Liste der Ressourcenidentifizierer durchzuscrollen, und zwar nach links, um dem Anwender die Möglichkeit zu geben, den einfachen Namen zu sehen, der auf die hierarchische Örtlichkeit oder Lage folgt, und zwar innerhalb des voll qualifizierten Ressourcenidentifizierers.
Viele auf dem Anwenderinterface basierende Anwendungen wie der Windows- Explorer ermöglichen es auch einem Anwender, eine Liste von Icons/Ressourcenidentifiziererpaaren auszuwählen und anzuordnen, welches das graphische Anwenderinterface darstellt, was in Einklang mit bestimmten vordefinierten Darstellungen erfolgt. Beispielsweise kann der Anwender die Wahl treffen, daß das graphische Anwenderinterface die Icon/Ressourcenidentifiziererpaare alphabetisch darstellt oder gemäß einem bestimmten Datum, einer Größe, eines Autors usw. Wenn ein Anwender die Wahl trifft, eine Ansicht so anzuordnen, daß die Icon/Ressourcenidentifiziererpaare auf einem dieser Attribute dargestellt werden, stellt der Windows-Explorer die sortierte Liste der Icons gemäß dem vom Anwender ausgewählten Attribut (z. B. Größe, Datum usw.) innerhalb der graphischen Anwenderinterfaceanzeige dar.
Betriebssysteme wie Windows und Variationen von Unix liefern andere graphische Anwenderinterfacemerkmale, die es einem Anwender ermöglichen, einen "Shortcut" oder "Alias" für eine bestimmte Ressource zu kreieren, wie beispielsweise für eine Datei oder für einen Directory-Shortcut. Ein Shortcut oder Alias besteht im wesentlichen aus einem einfachen Namensplatzhalter oder Verbindungsglied, welches zu der ursprünglichen Kopie der Datei oder dem Directory innerhalb des Dateisystems zurück zeigt. Ein Anwender kann einen einfachen Namen einem Shortcut oder Alias zuweisen, welcher der gleiche ist oder welcher verschieden ist von dem einfachen Namen der ursprünglichen Ressource, auf die der Shortcut oder Aliasname hinweist. Der Anwender kann dann den Shortcut oder Aliasnamen kopieren oder bewegen, und zwar zu einer anderen Stelle in dem Dateisystem hin. Wenn ein graphisches Anwenderinterface des Betriebssystems beispielsweise eine Ressourcenidentifiziererauflistung für einen Directory darstellt, der den Shortcut oder den Alias enthält, so listet das graphische Anwenderinterface für den Anwender den einfachen Namen für den Shortcut oder Alias auf, der auf die aktuelle Ressource (z. B. die reale Datei oder Directory) verweist, der in einem anderen Abschnitt der Hierarchie des Dateisystems gelegen ist.

ZUSAMMENFASSUNG DER ERFINDUNG

Jede der zuvor erwähnten herkömmlichen Techniken, die Repräsentationen von Ressourcen innerhalb von graphischen Anwenderinterfaces liefern, sind mit bestimmten Nachteilen und/oder Einschränkungen behaftet. Solche Einschränkungen ergeben sich zum Teil aus den betrieblichen Einschränkungen der herkömmlichen graphischen Anwenderinterfaces, die durch solche Anwendungen geliefert werden, und ergeben sich speziell in Verbindung mit den Einschränkungen in der Fähigkeit der herkömmlichen graphischen Anwenderinterfaces, die Namensressourcen in einer präzisen und flexiblen Weise zu präsentieren.
Beispiel erfordert das zuvor genannte herkömmliche hierarchische Namensgebungsschema, welches durch typische herkömmliche, auf das graphische Anwenderinterface gestützte Betriebssysteme verwendet wird, dass ein voll qualifizierter Ressourcenidentifizierer für eine Ressource die hierarchische Örtlichkeit, gefolgt von dem einfachen Namen der Ressource enthält. Solch ein Namensgebungsschema kann es für einen Anwender schwierig machen, schnell den einfachen Namen zu erfassen, welcher der Ressource von der hierarchischen Lage der Ressource zugeordnet ist. Diese Sicht- Unsicherheit kann beispielsweise aus vielen einfachen Namen resultieren, und zwar von vielen Ressourcen (z. B. einer Liste von Dateien), die an unterschiedlichen Stellen in einer Liste der voll qualifizierten Ressourcenidentifizierer erscheinen, von denen jede eine unterschiedliche Länge hat. Es sei beispielsweise der Fall betrachtet, wenn der Windows-Explorer eine lange Liste von Dateien darstellt, mit Pfadnamen, von denen jeder unterschiedliche Lagen oder Örtlichkeiten der jeweiligen Dateien in einem Dateisystem anzeigen. Da jeder Pfadname (das heißt jede hierarchische Örtlichkeit) eine unterschiedliche Länge haben kann, sind die einfachen Namen von jeder Datei (das heißt die Dateinamen) nicht miteinander vertikal aufgereiht, da jeder einfache Namen an das Ende des Ressourcenidentifizierers angehängt ist (das heißt nach der hierarchischen Örtlichkeit oder dem Pfadnamen). Dies macht es für einen Anwender schwierig, schnell eine optische Obenabschnitt- und Bodenabschnittabtastung der Ressourcenidentifiziererliste in dem graphischen Anwenderinterface durchzuführen, um den einfachen Namen von jeder Datei festzustellen. Der Anwender muß nämlich an das am weitesten rechts liegende Ende von jedem Ressourcenidentifizierer blicken, um jeden einfachen Namen zu erkennen, und, da die Ressourcenidentifizierer voll qualifiziert sind und unterschiedliche Längen besitzen, muß der Anwender auch sowohl vertikal (das heißt nach unten) als auch horizontal entweder nach links oder nach rechts blicken, um den einfachen Namen des nächsten voll qualifizierten Ressourcenidentifizierers zu erkennen. Dies kann für einen Anwender eines herkömmlichen graphischen Anwenderinterfaces ziemlich mühsam werden.
Wenn darüber hinaus ein Fenster in einem herkömmlichen graphischen Anwenderinterface den voll qualifizierten Ressourcenidentifizierer für eine Ressource darstellt, dieses Fenster jedoch nicht ausreichend groß ist, und zwar in der horizontalen Richtung, um die gesamte alphanumerische Folge für den voll qualifizierten Ressourcenidentifizierer vollständig darzustellen, kann der einfache Name der Ressource nicht für den Anwender des graphischen Anwenderinterfaces sichtbar sein. Der Anwender muß dann den horizontalen Scrollbalken betätigen, um die Darstellung nach links zu scrollen, so daß der einfache Name der Ressource sichtbar erscheint.
Da Softwareanwendungen im allgemeinen Ressourcen in einer voll qualifizierten Weise in Bezug bringen müssen, müssen Anwender Ressourcenidentifizierer in einem voll qualifizierten Format vorsehen oder zuführen, was es erforderlich macht, daß der Anwender einen fehlerfreien Eintrag (das heißt Eintippen) der vollständigen hierarchischen Lage oder Örtlichkeit durchführt, wie beispielsweise einen vollständigen Pfadnamen, gefolgt von dem korrekten einfachen Namen einer bestimmten Ressource eingeben muß. Dies kann ziemlich mühsam sein, wenn auf viele Ressourcen oder lediglich eine einzelne Ressource mit einer langen hierarchischen Lage Bezug genommen wird.
Wenn sich ein Anwender dazu entscheidet, einen Aliasnamen oder Shortcut- Merkmal eines herkömmlichen Betriebssystems zu verwenden, um einen zweiten Identifizierer einer Ressource in einer Lage oder Örtlichkeit vorzusehen, die verschieden ist von der wahren Lage dieser Ressource innerhalb der Hierarchie (z. B. innerhalb des Dateisystems) kann der Aliasname oder Shortcut für dies Ressource keine Anzeige der tatsächlichen Lage dieser Ressource, auf die er Bezug nimmt, liefern. Wenn, mit anderen Worten, ein Anwender einen Shortcut erzeugt und diesem Shortcut einen Namen gibt, wie beispielsweise "myfile", zeigt das graphische Anwenderinterface nicht automatisch die tatsächliche oder wahre Lage der Datei ein, die dem myfile-Shortcut entspricht. Um diese Information festzulegen, muß der Anwender den Aliasnamen oder Shortcut auswählen und muß (z. B. über den rechten Mausklick) ein Pull-down-Menü aktivieren, um ein "Eigenschaften"-Merkmal auszuwählen, um die tatsächliche Dateisystemörtlichheit der Ressource zu bestimmen, auf die sich der Aliasname oder Shortcut bezieht. Wenn viele Shortcuts den gleichen einfachen Namen haben, kann es für den Anwender unklar werden, welcher Shortcut auf welche Ressource verweist. Mit anderen Worten, indem er den einfachen Namen des Alias oder des Shortcuts selbst betrachtet, wird der Anwender nicht automatisch über die wahre Identität oder Örtlichkeit der Ressource informiert, auf die sich der Alias oder Shortcut bezieht. Wenn der Anwender einen Alias wünscht, um die wahre Identität der Ressource anzuzeigen, auf die der Alias verweist, dann muß der Anwender von Hand den Alias oder Shortcut nennen, und zwar mit einer Anzeige der hierarchischen Lage oder Ressourcenidentität. Da dieser Prozeß nicht automatisiert ist, können sich Inkonsequenzen aus einem Alias oder Shortcut ergeben, und zwar von einem zum anderen, und es wird auch keine Warnanzeige geliefert, wenn der Name, den der Anwender auswählt, bereits durch eine andere Ressource in Verwendung ist.
Darüber hinaus liefern herkömmliche Softwareanwendungen und Betriebssysteme keinen ausreichenden Mechanismus dafür, eine Gruppierung oder Kategorie für Ressourcen zu erzeugen, und zwar innerhalb einer Ressourcenhierarchie, wie beispielsweise einem Dateisystem, ohne daß diese Gruppierung oder Kategorie in der Ressourcenhierarchieörtlichkeit enthalten ist. Beispielsweise kann ein Anwender eines herkömmlichen Betriebssystems einen Subdirectory erzeugen, um Dateien eines bestimmten Typs zu halten. Um jedoch auf solche Dateien Bezug zu nehmen, muß der Anwender den Directorynamen als Teil des Pfades der Dateiein angeben. Es gibt bei einem herkömmlichen, auf das graphische Anwenderinterface gestützten Betriebssystem keine Technik, einen Gruppierungsdirectory für die Plazierung von Dateien zu erzeugen und dann auf diese Dateien Bezug zu nehmen, ohne auf die Gruppierung Bezug nehmen zu müssen. Zusätzlich isolieren die Directories oder andere Gruppierungskonstruktionen, die durch herkömmliche Softwareanwendungen gebogen werden, nicht die Ressourcen, die unterhalb dieses Directory gelegen sind, von Anwenderoperationen. Beispielsweise kann ein Anwender Datei ein nicht in einem Directory plazieren und dann diesen Directory entfernen, ohne dabei die Dateien zu entfernen. Dies ist deshalb der Fall, da herkömmliche Gruppierungstechniken, wie das Erzeugen von Directories, zum Gruppieren von Dateien oder anderen Ressourcen den Directory zwingen, Teil der hierarchischen Örtlichkeit zu werden oder Teil des Pfadnamens der Dateien oder der Ressource zu werden. Es gibt keine einfachen Wege, eine Gruppierungsstruktur zu erzeugen, wie beispielsweise einen Directory innerhalb eines herkömmlichen Betriebssystems, oder stattdessen eine Ressource in diesem Directory zu haben, der dann als Teil eines anderen Directory betrachtet werden kann.
Diese und andere Mängel, die bei den herkömmlichen Software- und Betriebssystemnamensgebungsschemata und den Ressourcenbezugnahmetechniken gemeinsam vorhanden sind, können zu Anwenderfehlern führen, da ein Anwender eine Operation an einer Ressource durchführen kann (z. B. Löschen einer Datei), ohne sich dabei über die Identität der Ressource voll bewußt zu sein. Der Anwender kann zufällig Bezug auf eine falsche Ressource nehmen (z. B. als Ergebnis eines Tippfehlers, wenn er einen langen Ressourcenidentifizierer eingibt). Um derartige Fehler zu vermeiden, muß der Anwender fortwährend das Namensgebungsschema und die hierarchische Struktur, die den Ressourcenidentifizierern auferlegt ist, im Kopf haben, um ein zufälliges Bezugnehmen auf eine falsche Ressource zu vermeiden. Wenn darüber hinaus die Ressourcenidentifizierer lang; sind, muß der Anwender in signifikanter Weise mehr von Hand durchgeführte graphische Anwenderinterfaceoperationen durchführen (z. B. durchscrollen zum Identifizieren der einfachen Namen), um in richtiger Weise auf die Ressourcen Bezug zu nehmen.
Demgegenüber liefern die Ausführungsformen der vorliegenden Erfindung eine einmalige Ressourcenidentifizierung, Namensgebung, Gruppierung und Bezugnahmetechniken, welches ein Betriebssystem und/oder eine Softwareanwendung, die ein graphisches Anwenderinterface verwendet, verwenden kann, um in signifikanter Weise viele der Probleme zu überwinden, die bei den herkömmlichen graphischen Anwenderinterfaces auftreten, welche für das Management der Ressourcen in einem Computersystem, Datenspeichersystem, einer Computernetzwerkumgebung verwendet werden. Bevorzugte Ausführungsformen der Erfindung arbeiten innerhalb eines Managementstationscomputersystems, wie beispielsweise einer Speicherbereichsnetzwerkmanagementstation. Solch ein Computersystem kann beispielsweise eine Ressourcenmanagementanwendung betreiben bzw. in Betrieb nehmen, die ein graphisches Anwenderinterface liefert, und auch Ressourcenpräsentationstechniken und Mechanismen liefert, wie sie im folgenden erläutert werden.
Insbesondere ermöglicht das System der Erfindung Ausführungsformen eines Verfahrens, die in einem Computersystem arbeiten, mit einem Speichersystem und einer Anzeige, die ein graphisches Anwenderinterface für das Management von Netzwerkressourcen darstellt. Die Ausführungsformen des Verfahrens arbeiten derart, um eine oder mehrere Ressourcen in einer Computersystemumgebung zu präsentieren. Eine solche Ausführungsform des Verfahrens umfaßt die Schritte gemäß dem Erzeugen eines Objektes, um eine Ressource in einer Computersystemumgebung wiederzugeben. Ein Anwender des Computersystems kann die Managementsoftware instruieren, ein Objekt zu erzeugen oder alternativ kann die Managementstation mit der Software konfiguriert sein, welche Ressource "entdeckt", die gemanagt werden können, und die Objekte für jede entdeckte Ressource erzeugen kann. Die Einzelheiten des Prozesses der Entdeckung der Ressourcen sind in den parallel laufenden Patentanmeldungen erläutert, die der gleichen Anmelderin wie der Anmelderin der vorliegenden Erfindung zugeordnet sind. Das Objekt, welches gemäß diesem Verfahren erzeugt wird, besteht allgemein aus einer Spezialisierung bzw. einer objektorientierten Programmierung (instantiation) einer Datenstruktur, wie beispielsweise einer objektorientierten Programmierung (instantiation) einer Java- oder C++-Klasse, welche Datendefinitionen und Verfahren enthält, die die Ressource beschreiben, welche das Objekt repräsentiert.
Diese Ausführungsform des Verfahrens umfaßt ferner einen Schritt der Zuordnung eines Objektidentifizierers zu dem Objekt. Der Objektidentifizierer enthält wenigstens einen einfachen Namen des Objektes und eine Heimadresse (home) des Objektes. Allgemein repräsentiert der gesamte Objektidentifizierer (das heißt der einfach Name, gefolgt von dem Heim bzw. Heimatort des Objektes) einen voll qualifizierten Ressourcenidentifizierer für die Ressource, die durch das Objekt repräsentiert wird. Ein Anwender kann einen einfachen Namen dem Objekt zuweisen oder alternativ kann der Auffindmechanismus den Prozeß der Zuordnung des einfachen Namens zu einem Objekt beispielsweise dadurch automatisieren, indem er eine Seriennummer der Ressource verwendet (z. B. die Seriennummer eines Datenspeichersystems), und zwar als einfachen Namen. Ein graphisches Anwenderinterface, welches gemäß dieser Ausführungsform der Erfindung arbeitet, kann einen einfachen Namen darstellen, der einem Objekt zugeordnet ist, und zwar in einzigartiger Weise für dieses Objekt. Ferner ist ein einfacher Name für ein Objekt einzigartig für dieses Objekt in diesem Heimkontext des Objektes. Der Heimkontext des Objektes ist als Heimat oder Heim des Objektes innerhalb des Ressourcenidentifizierers für das Objekt definiert. Das Heim des Objektes repräsentiert oder verweist auf ein anderes Objekt (z. B. ein Elternobjekt, was noch später erläutert wird) in einem Satz von Objekten (z. B. bevorzugt einer Objekthierarchie), zu denen das erzeugte Objekt gehört.
Die Ausführungsform dieses Verfahrens umfaßt ferner den Schritt der Darstellung von wenigstens einer Präsentation des Objektes an einem graphischen Anwenderinterface. Jede Präsentation des Objektes enthält den einfachen Namen des Objektes. Wie noch erläutert wird, kann, obwohl eine Objekthierarchie verwendet wird, um die Objekte hierarchisch anzuordnen, und zwar in Relation zu anderen Objekten, ein Objekt in mehr als einer Stelle in der Objekthierarchie erscheinen. Da jedoch jede Präsentation des Objektes in einem graphischen Anwenderinterface wenigstens den einfachen Namen des Objektes enthält, kann ein Anwender des graphischen Anwenderinterfaces unmittelbar die Objekthierarchie betrachten und kann für jede Präsentation von jedem Objekt den einfachen Namen für dieses Objekt sehen.
Wenn darüber hinaus bei dieser Ausführungsform des Verfahrens eine Heimbedingung (home condition) (was noch erläutert wird) für eine der Präsentationen des oder der Objekte existiert, die an dem graphischen Anwenderinterface dargestellt wird bzw. werden, enthalten solche Präsentationen der Objekte (für die eine Heimbedingung existiert), ferner das Heim oder die Heimatadresse des Objektes. Mit anderen Worten, wenn eine Präsentation des Objektes dargestellt wird, geliefert wird oder auf andere Weise an einem graphischen Anwenderinterface vorgesehen wird, welches gemäß dieser Ausführungsform arbeitet, dann enthält, wenn eine Heimbedingung oder Heimzustand existiert oder für eine bestimmte Präsentation eines Objektes an dem graphischen Anwenderinterface auftritt, diese Präsentation sowohl den einfachen Namen als auch des Heims des Objektes derart, daß die Präsentation an dem graphischen Anwenderinterface in einer voll qualifizierten Weise dargestellt wird.
Bei einer anderen Ausführungsform umfaßt das Verfahren einen Schritt der Zuordnung des Objektes zu wenigstens einer Örtlichkeit innerhalb einer Objekthierarchie in solcher Weise, daß das Objekt zu einem Kindobjekt von wenigstens einem Elternobjekt in der Objekthierarchie wird. Die Objekthierarchie präsentiert Beziehungen zwischen Ressourcen in der Computersystemumgebung, die durch die Objekte in der Objekthierarchie repräsentiert werden. Somit wird eine Objekthierarchie gebildet (oder existiert inhärent) durch die hierarchischen Beziehungen, die zwischen jeder Ressource gebildet werden, und das Objekt, welches solche Ressourcen repräsentiert, enthält Verweise (z. B. Zeiger oder Vererbungen (inheritances) von Klassen von anderen Objekten) für solche Beziehungen. Wenigstens eine Örtlichkeit, welcher das Objekt in der Objekthierarchie zugeordnet ist, enthält eine Heimörtlichkeit, die ein Heimobjekt identifiziert, und zwar in der Objekthierarchie, unter welcher das Objekt anfänglich als Kindobjekt zugeordnet wurde, um dadurch einen Heimkontext für das Objekt zu definieren. Somit wird in einer Ausführungsform das Objekt innerhalb der Objekthierarchie gebildet und ein Kindobjekt, von welchem dieses Objekt in der Hierarchie abgeleitet ist, und zwar in der Hierarchie absteigend, wird zu dem Heimobjekt des neuerlich kreierten Objektes. Dieser Heimbereich (das heißt die Schicht in der Hierarchie, in welcher das Objekt erzeugt wird) wird zu dem Heimkontext für dieses Objekt. Da der einfache Name in dem Heimkontext einmalig ist, kann der einfache Name einzigartig dieses Objekt an seinem Heimkontext identifizieren.
Somit existiert bei den bevorzugten Ausführungsformen eine Heimbedingung oder Heim zustand für eine Präsentation eines Objektes, welches an einem graphischen Anwenderinterface dargestellt wird, wenn diese Präsentation des Objektes an der Stelle oder Örtlichkeit in einer Objekthierarchie in dem graphischen Anwenderinterface dargestellt wird, wobei nur einer der folgenden Fälle herbeigeführt wird, i) das darzustellende Objekt fällt außerhalb eines Heimkontextes des Objektes und/oder ii) das darzustellende Objekt ist nicht einzigartig in einem Kontext enthalten, in welchem das Objekt dargestellt wird. Demzufolge bewirkt das Auftreten eines Heimzustandes oder einer Heimbedingung für eine Präsentation des Objektes, dass die Präsentation in einer qualifizierten Weise dargestellt wird (das heißt sowohl den einfachen Namen als auch das Heim des Objektes enthaltend), und zwar in der Stelle oder Örtlichkeit in der Objekthierarchie, wobei die Darstellung an dem graphischen Anwenderinterface erfolgt.
Dies ermöglicht einem Anwender des graphischen Anwenderinterfaces zu wissen oder zu verstehen, wie die wahre Identität des Objektes lautet (das heißt dessen voll qualifizierte Identität), und zwar ungeachtet der Tatsache, ob die Präsentation des Objektes in der Objekthierarchie in dem graphischen Anwenderinterface dargestellt wird. Somit ermöglichen die Ausführungsformen der Erfindung, daß ein Anwender intuitiv in offensichtlicher Weise verstehen kann, was ein Objektname (das heißt dessen Präsentation in dem graphischen Anwenderinterface) bedeutet, ohne daß er dabei hierarchische Namensgebungsschemata oder Pfadnamenstrukturen lernen muß, und es wird dabei auch vermieden, daß der Anwender über die Objekthierarchie in großen Einzelheiten nachdenken muß.
Ferner wird durch die Ausführungsformen der Erfindung das Einlippen minimiert, welches von einem Anwender vorgenommen werden muß, da der Anwender lediglich einen einfachen Namen für ein Objekt in dem Objektheimkontext spezifizieren muß oder in anderen Bereichen spezifizieren muß, wo ein Heimzustand nicht existiert, in solcher Weise, daß der einfache Name in einmaliger Weise dieses Objekt in diesem Kontext identifiziert, ohne daß dabei komplexe Pfadnamen erforderlich sind. Wenn die Identität des Objektes voll qualifiziert werden muß, braucht der Anwender dennoch lediglich noch das Heim des Objektes zu geben, welches ebenfalls aus einem einfachen Namen des Heimobjektes für das zu identifizierende Objekt bestehen kann. Somit braucht der Anwender für eine einmalige Identifizierung eines Objektes irgendwo in der Objekthierarchie lediglich als äußerste Maßnahme zwei einfache Namen einzugeben und ein Verbindungszeichen einzugeben, wie beispielsweise "@"-Symbol. Die Syntax kann dann für eine vollständige Qualifizierung zum Identifizieren eines Objektes beispielsweise wie folgt aussehen: objekt-einfacher-name@heim (object-simple- Name@home).
Ferner braucht bei den Ausführungsformen der Erfindung ein Anwender nicht ein Namensgebungsschema aufzustellen, die verschieden sind von den Namen, die der Anwender wählt. Da jeder Objektidentifizierer den einfachen Namen enthält, der durch den Anwender definiert oder festgelegt werden kann, und das Heim eines Objektes aus dem einfachen Namen des anderen Objektes besteht, auf welches sich das neue Objekt bezieht, kann ein Anwender nach seiner oder ihrer Willkür sowohl den einfachen Namen für das Objekt als auch das Heim des Objektes festlegen (einen anderen einfachen Namen eines anderen Objektes, das Heimobjekt).
Das Namensgebungsschema, welches durch die Ausführungsformen der Erfindung geschaffen wird und welche einen Namensgebungskontext liefern, ist für eine Managementsoftwareanwendung oder -system zum Identifizieren eines Objektes in irgendeinem Kontext ausreichend oder, mit anderen Worten, für eine irgendeine Stelle oder Örtlichkeit innerhalb der Objekthierarchie ausreichend.
Bevorzugte Ausführungsformen geben auch Präsentationen von Objekten wieder unter Verwendung des einfachen Namens, gefolgt von dem Heim des Objektes. Dies zeigt zuerst den wichtigen Teil des Objektidentifizierers - den einfachen Namen, der schnell und in vielen Fällen in einmaliger Weise den wichtigen Aspekt des Objektes identifiziert, auf den diese Präsentation Bezug nimmt - anders als zuletzt, wie bei den herkömmlichen Namensgebungsschemata, bei denen die Pfadnamen vor den Namen der Dateien plaziert sind oder vor anderen Ressourcen. Indem der einfache Name zuerst plaziert wird, werden der wichtige Teil der Objektidentifizierer oder die Objektnamen zuerst ausgerichtet, beispielsweise in einer Liste der Objektpräsentationen, anstatt zuletzt. Dies vermeidet eine Fehlausrichtung der einfachen Namen der Objekte in solchen Listen und ermöglicht es einem Anwender, schnell den Teil des Objektidentifizierers zu erblicken, der für den Anwender wichtig ist (nämlich den einfachen Namen - als erstes in der Liste, auf den dann das Heim des Objektes nachfolgt).
Andere Ausführungsformen der Erfindung umfassen ein Computersystem, wie beispielsweise ein Server-Computersystem, eine Workstation, Datenspeichersystem, Netzwerkvorrichtung oder andere Typen eines Computersystems oder einer -vorrichtung, die dafür konfiguriert sind, alle Verfahrensoperationen zu verarbeiten, die hier in Form der Ausführungsformen der Erfindung offenbart sind. Die Ausführungsformen der Erfindung sind bei jeder computerisierten Vorrichtung anwendbar, die ein Graphikanwenderinterface für die Präsentation von Ressourcen verwendet. Bei solchen Ausführungsformen umfaßt das Computersystem ein Interface, ein Speichersystem, einen Prozessor und einen Verbindungsmechanismus, der das Interface, den Prozessor und das Speichersystem verbindet. Das Speichersystem kann flüchtig sein (z. B. ein RAM) oder auch nichtflüchtig sein (z. B. eine Platte) oder kann auch aus einer Kombination dieser Speichervorrichtungen bestehen. Bei diesen Ausführungsformen wird das Speichersystem mit einer Ressourcenmanagementanwendung kodiert, die dann, wenn sie auf dem Prozessor läuft, einen Ressourcenmanagementprozeß erzeugt, bei dem die Ressource oder die Ressourcen in einer Computersystemumgebung präsentiert werden, indem das Computersystem unter der Steuerung des Ressourcenmanagementprozesses veranlaßt wird, alle Ausführungsformen des Verfahrens bzw. dessen Schritte durchzuführen und Operationen auszuführen, die hier als Ausführungsform der Erfindung erläutert sind.
Andere Ausgestaltungen der Ausführungsformen der Erfindung, die hier offenbart sind, umfassen Softwareprogramme, um die Verfahrensschritte der Ausführungsform durchzuführen und auch die Operationen durchzuführen, die oben zusammengefaßt dargestellt sind und weiter unten mehr in Einzelheiten offenbart werden. Spezieller gesagt, ist ein Computerprogrammprodukt offenbart, welches ein vom Computer lesbares Medium umfaßt mit einer Computerprogrammlogik, welche darauf kodiert ist, um eine Technik für die Präsentation einer Ressource oder von Ressourcen in einer Computersystemumgebung zu schaffen, wie dies noch erläutert wird. Die Computerprogrammlogik bewirkt, wenn sie auf wenigstens einem Prozessor in einem Computersystem ausgeführt wird, daß der Prozessor die Verarbeitungsoperationen durchführt (z. B. die Verfahren, Schritte und/oder Operationen), die hier als Ausführungsformen der Erfindung dargestellt sind. Solche Ausgestaltungen oder Anordnungen der Erfindung werden in typischer Weise durch einen Software einen Kode und/oder andere Daten realisiert, die dafür ausgebildet sind oder auf einem vom Computer lesbaren Medium kodiert sind, wie beispielsweise einem optischen Medium (z. B. CD-ROM), einer Diskette oder Festplatte oder einem, anderen Medium, wie beispielsweise einer Firmware oder einem Mikrokode in einem oder mehreren ROM- oder RAM- oder PROM-Chips oder als eine anwendungsspezifische integrierte Schaltung (ASIC). Die Software oder Firmware oder die anderen solchen Konfigurationen können auf einem Computersystem installiert werden, um das Computersystem zu veranlassen, die Techniken auszuführen, die hier als Ausführungsformen der Erfindung erläutert sind.
Es sei darauf hingewiesen, daß das System der Erfindung strikt als Softwareprogramm, als Software und Hardware oder als Hardware alleine realisiert werden kann. Als Beispiel gewählte Ausführungsformen der Erfindung können in einer EMC-Steuerzentrum-(ECC)-Softwareanwendung implementiert sein, die ein Management der Ressourcen innerhalb einer Speicherbereichsnetzwerkumgebung liefern. Die ECC wird durch die EMC Corporation of Hopkinton, Massachusetts, USA, hergestellt.
Es sei auch darauf hingewiesen, daß andere Vorrichtungstypen, wie beispielsweise Datenspeichersysteme, gemäß der Erfindung arbeiten können und mit den Ausführungsformen der Erfindung konfiguriert werden können. Das heißt, es ist nicht erforderlich, daß die hier erläuterten Techniken innerhalb eines Computersystems, wie einer Netzwerkmanagementstation, arbeiten. Vielmehr kann bei solchen anderen Ausführungsformen ein Datenspeichersystem, wie eines der Symmetrix Line of Data Systems, hergestellt von EMC Corporation, eine Betriebssoftware bzw. Kode, Logik und/oder Schaltung enthalten, um die Verarbeitung der Ausführungsformen der Erfindung, wie sie hier erläutert sind, durchzuführen. Bei solchen Ausführungsformen kann eine Datenzugriffsanfrage in einem offenen Systemformat direkt durch das Datenspeichersystem von einer Vorrichtung, wie beispielsweise einem Computersystem, empfangen werden, welches an das Datenspeichersystem gekoppelt ist. Das Datenspeichersystem kann somit als ein Cachemanager arbeiten, wie dies noch erläutert wird, und kann die Geschichte und Partitionscacheörtlichkeit aufrecht erhalten, und zwar innerhalb eines Speichersystems, z. B. einem Cachespeichersystem, innerhalb des Datenspeichersystems. Das Datenspeichersystem kann auch die Daten speichern (z. B. in einem nicht offenen Systemformat), und zwar örtlich mit Hilfe von Speichervorrichtungen, wie beispielsweise Plattenlaufwerken, die innerhalb des Datenspeichersystems enthalten sind und in diesem Datenspeichersystem arbeiten.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die zuvor erläuterten und andere Ziele, Merkmale und Vorteile der Erfindung ergeben sich klarer aus der folgenden Beschreibung von bevorzugten Ausführungsformen der Erfindung, wie sie in den beigefügten Zeichnungen veranschaulicht ist, in welchen gleiche Bezugszeichen gleiche Teile in allen unterschiedlichen Darstellungen bezeichnen. Die Zeichnungen sind nicht notwendigerweise maßstabsgetreu gehalten, wobei stattdessen die Darstellung der Ausführungsformen, Prinzipien und Konzepte der Erfindung in den Vordergrund gestellt sind.
Fig. 1 veranschaulicht ein als Beispiel gewähltes Speicherbereichsnetzwerk und eine Computersystemumgebung mit einem Computersystem als Managementstation, welches so konfiguriert ist, um gemäß den Ausführungsformen der Erfindung zu arbeiten;
Fig. 2 veranschaulicht ein Flußdiagramm der Verarbeitungsschritte auf hoher Schicht und der Betriebsweisen zum Erzeugen von Präsentationen der Objekte gemäß den Ausführungsformen der Erfindung;
Fig. 3 veranschaulicht ein Beispiel einer Architektur des Computersystems von Fig. 1;
Fig. 4 veranschaulicht ein Beispiel einer Objektdatenstruktur, die für die Verwendung bei den Ausführungsformen der Erfindung geeignet ist;
Fig. 5 veranschaulicht eine Betriebsumgebung, in der ein Ressourcenmanager eine Eingangsgröße von einem Anwender empfängt und optional von einem Aufsuchprozeß in Einklang mit den Ausführungsformen der Erfindung;
Fig. 6 ist ein Flußdiagramm von Prozeßschritten, die ein Ressourcenmanager gemäß den Ausführungsformen der Erfindung durchführen kann, um einem Anwender zu erlauben oder auch einem Auffindprozeß zu erlauben, ein Objekt innerhalb einer Objekthierarchie zu erzeugen;
Fig. 7 ist ein Flußdiagramm von Prozeßschritten, die der Ressourcenmanager gemäß den Ausführungsformen der Erfindung durchführt, um die Objekthierarchie zum Erzeugen von Präsentationen von Objekten mit einem graphischen Anwenderinterface zu durchqueren.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN

Die Ausführungsformen der vorliegenden Erfindung betreffen Mechanismen und Techniken, die ein einmaliges Ressourcenpräsentationsschema liefern, welches beispielsweise innerhalb einer Softwareanwendung oder einem Betriebssystem verwendet werden kann, welches ein graphisches Anwenderinterface bietet, um Präsentationen von Objekten zu liefern, die Ressourcen repräsentieren. Die bevorzugten Ausführungsformen der Erfindung sind mit einem Ressourcenmanagementsoftwareprogramm (das heißt einer Anwendung und/oder Prozeß) implementiert, welches auf einem Computersystem, wie beispielsweise einer an ein Netzwerk angeschlossenen Workstation ausgeführt wird, die so konfiguriert ist, daß eine Management- oder Steuerstation für ein Fernmanagement darstellt und auch für eine Fernkonfiguration und Fernsteuerung der Ressourcen innerhalb eines Computersystems und einer Netzwerkumgebung wie einem Speicherbereichsnetzwerk. Die Ressourcen, die durch die Ausführungsformen des Ressourcenmanagementprogramms der Erfindung präsentiert werden können, können beispielsweise Netzwerkvorrichtungen, Computersysteme (das heißt Hosts, Server und Clientcomputersysteme), periphere Geräte, Datenspeichersysteme und andere Vorrichtungsressourcen enthalten als auch Softwareprogramme oder Prozesse, die in solchen Ressourcen arbeiten. Spezifischer ausgedrückt, liefern die Ausführungsformen der Erfindung eine einzigartige Namensgebung, Gruppierung und graphische Präsentationstechniken für solche Ressourcen in einem graphischen Anwenderinterface, welches das Ressourcenmanagementprogramm an einer Anzeige darstellen kann, die an das Managementstationscomputersystem gekoppelt ist.
In einer Umgebung, wie beispielsweise einer Speicherbereichsnetzwerkumgebung, haben solche Ressourcen (Software und Hardware) häufig komplexe physikalische, funktionelle (das heißt betriebsmäßige) und organisatorische Wechselbeziehungen mit anderen, die eine Ressourcenhierarchie festlegen. Beispielsweise kann eine Datenspeichersystemressource mit hoher Kapazität viele andere Ressourcen umfassen, wie beispielsweise Hardware (z. B. Front-Ende- und Heck-Ende-Directors, Controller, Platten usw.) und Softwarekomponenten (z. B. Betriebssystemprozesse, Volumenkonstruktionen usw.), die in dem Datenspeichersystem arbeiten. Bestimmte dieser Ressourcen können einen Zugriff (z. B. Management-, Steuer- oder Lese-/Schreibzugriff) durch unterschiedliche Departments innerhalb einer Organisation erfordern, welche die Datenspeichersystemressourcen in Betrieb nehmen. Eine Ressourcenhierarchie kann, wenn eine graphische Darstellung erfolgt, visuell diese physikalischen betriebsmäßigen und organisatorischen Beziehungen zwischen den Ressourcen in der Ressourcenhierarchie definieren und liefern.
Gemäß einem kurz zu schildernden beispielhaften Betrieb einer Ausführungsform der Erfindung kann ein Anwender des Systems der Erfindung, wie beispielsweise ein System- oder Netzwerkmanager oder -administator eine Managementanwendung in Betrieb nehmen, die ein graphisches Anwenderinterface bietet, und zwar in Einklang mit den Ausführungsformen der Erfindung, um effizient Präsentationen der zuvor erwähnten Ressourcen in der Ressourcenhierarchie zu erzeugen und darzustellen. Die Ausführungsformen der Erfindung liefern solche Ressourcenrepräsentationen unter Verwendung eines einmaligen Ressourcenidentifizier- und Gruppierungsmechanismus der in effizienter Weise die Identitäten und Beziehungen der Ressourcen in der Ressourcenhierarchie liefert, und zwar mit einem minimalen Aufwand einer Anwenderinteraktion und bei minimaler erforderlicher Anwenderkompliziertheit.
Die Ausführungsformen der Erfindung ermöglichen für die Erzeugung von Objekten, die die zuvor erwähnten Typen der Ressourcen oder Gruppen von solchen Ressourcen wiedergeben. Die Ressourcenhierarchie wird somit in einem Computersystem dadurch präsentiert, indem Objekte erzeugt werden, die in einer Objekthierarchie angeordnet sind. Objekte in der Objekthierarchie können objektorientierte Programmierungen (instantiations) beispielsweise von Klassen (z. B. Java- oder C++-Klassen) in einer objektorientierten Softwareumgebung sein, die einander in Eltern-Kinder-Beziehungen in Beziehung setzen, und zwar je nach Anforderung, um die hierarchischen Ressourcenbeziehungen zu reflektieren. Nach der Erzeugung eines Objektes ordnen die Ausführungsformen der Erfindung jedes Objekt einem Objektidentifizierer zu, der sowohl einen einfachen Namen als auch ein Heim des Objektes enthält. Die Ausführungsformen liefern ein graphisches Anwenderinterface, welches graphisch eine Präsentation des Objektes in der Objekthierarchie darstellen kann, und zwar unter Verwendung von entweder dem einfachen Namen oder von beiden Größen, nämlich dem einfachen Namen und dem Heim des Objektes (als voll qualifizierte Präsentation bezeichnet), was von dem Kontext abhängt, in welchem die Präsentation des Objektes dargestellt werden soll. Der einfache Name eines Objektes kann aus einem kurzen, vom Anwender definierten Namen bestehen oder kann aus einem automatisch generierten Namen bestehen (z. B. der Seriennummer einer Hardwareressource), der in einmaliger Weise das Objekt in einem Heimkontext des Objektes identifiziert. Die Ausführungsformen der Erfindung bestimmen das Heim eines Objektes, basierend auf einer Anfangserzeugungsörtlichkeit des Objektes innerhalb der Objekthierarchie (z. B. das Plazieren eines neuen Objektes in der Objekthierarchie als Kind eines existierenden Objektes). Das Heim (home) für ein Objekt wird somit durch den Kontext des Heimes des Objektes definiert. Beispielsweise kann eine Datenspeichersystemressource durch ein Objekt repräsentiert werden, welches aus einem Heim für andere Objekte besteht, die Ressourcen innerhalb des Datenspeichersystems wiedergeben, wie beispielsweise Volumina, Platten, Controller oder ähnliches.
Ein Anwender oder eine automatisierte Prozedur kann andere Beziehungen (neben der Heim-Eltern-Kinder-Beziehung) festlegen, für die dafür ein Objekt existieren, welches eine Ressource repräsentiert, und es ermöglichen somit die Ausführungsformen der Erfindung eine Präsentation dieses Objektes, welches in der Objekthierarchie an anderen Stellen neben der Örtlichkeit von dessen Heimkontext zu plazieren ist. Wenn solche Ausführungsformen mit einem graphischen Anwenderinterface arbeiten, um die Objekthierarchie an einer Anzeige darzustellen (z. B. einem Computermonitor), und zwar einer Anzeige des Managementcomputersystems, können diese Ausführungsformen die Repräsentation des Objektes anzeigen, und zwar unter Verwendung des einfachen Namens des Objektes (und möglicherweise eines Objekt-Icons), beispielsweise dann, wenn dieser einfache Name einzigartig in der Objekthierarchie ist oder einzigartig innerhalb des Kontextes der Örtlichkeit ist, an welcher diese Repräsentation des Objektes in dem graphischen Anwenderinterface dargestellt wird.
Bei anderen Situationen können die Ausführungsformen bestimmen, daß die Repräsentation des Objektes in dem graphischen Anwenderinterface sowohl den einfachen Namen als auch das Heim des Objektes enthält, um dadurch eine "voll qualifizierte" Identität des Objektes zu erreichen, welches durch diese Repräsentation repräsentiert wird. In solchen Situationen wird angenommen, daß ein "Heimzustand oder Heimbedingung" existiert, der eine Anzeige des Heimes des Objektes an dem graphischen Anwenderinterface erfordert. Eine Heimbedingung oder Heimzustand existiert beispielsweise, wenn zwei Objekte, die in dem gleichen Kontext (z. B. innerhalb der gleichen Schicht oder Örtlichkeit) in der Objekthierarchie dargestellt werden sollen, den gleichen einfachen Namen haben, in welchem Fall eine Ausführungsform der Erfindung eine Repräsentation von jedem Objekt in einer voll qualifizierten Weise darstellt, unter Verwendung von sowohl den einfachen Namen (welche die gleichen sind) als auch deren Heime (homes) (die verschieden sind), und zwar von den Objektidentifizierern für solche Objekte. Auf diese Weise kann ein Anwender Repräsentationen des gleichen Objektes an vielen Stellen an einem graphischen Anwenderinterface plazieren und das System der Erfindung kann bestimmen, welche Teile der Identität der Objekte (z. B. der einfache Name und das Heim) erforderlich sind, um solche Örtlichkeiten darzustellen, um dem Anwender die Identität des Objektes zu vermitteln.
Ausführungsformen der Erfindung liefern auch einen Suffixmechanismus in einem Fall, daß zwei Heimressourcen den gleichen Namen enthalten. Wenn beispielsweise ein Speichersystem ein Heimobjekt mit dem Namen "MASTER" enthält und ein Hostsystem ein Heimobjekt enthält, welches ebenfalls den Namen "MASTER" hat, dann können Ressourcen, wie beispielsweise ein Speichervolumen, welches mit "DATA" in dem MASTER-Speichersystem bezeichnet wird, und eine Softwareanwendung, die "DATA" genannt wird, dem MASTER-Hostsystem zugeordnet werden und kann in einer Objekthierarchie präsentiert werden und jedes Objekt hat den gleichen einfachen Namen und den gleichen Heimnamen. Wenn die Ausführungsformen nach der Erfindung Repräsentationen dieser Objekte an dem graphischen Anwenderinterface darstellen, so können diese Ausführungsformen den einfachen Namen, gefolgt von dem Heim dieser Objekte darstellen (wie z. B. DATA@MASTER) und die Ausführungsformen nach der Erfindung können auch ein Suffix anhängen, und zwar an jedes MASTER-Heim, wie beispielsweise MASTER#1 und MASTER#2, um dem Anwender die Information zu vermitteln, daß zwei Heimressourcen vorhanden sind, die den gleichen Namen teilen. Die Repräsentationen können somit in dem graphischen Anwenderinterface erscheinen als DATA@MASTER#1 und als DATA@MASTER#2. Das #1 und das #2 vermitteln dem Anwender die Information, daß zwei Heimobjekte mit dem gleichen Namen vorhanden sind.
Neben dem einzigartigen Namensgebungsschema kann ein Computersystem, welches gemäß einer Ausführungsform der Erfindung arbeitet, ein Objekt (oder Vielfachobjekte) in der Objekthierarchie als Gruppenobjekt definieren. Ein Gruppenobjekt kann beispielsweise eine Kategorie in der Objekthierarchie wiedergeben, unter welcher andere bezogene Objekte plaziert sind, um solche anderen Objekte gemäß der Beziehung oder den Beziehungen, die durch das Gruppenobjekt definiert ist bzw. sind, miteinander in Beziehung zu setzen. Beispielsweise kann ein Anwender eine "UNIX"- Gruppe definieren, um alle Ressourcen zu kategorisieren, die das UNIX-Betriebssystem betreiben. Ein Anwender kann Subgruppen in einer Objekthierarchie erzeugen, und zwar unter der UNIX-Gruppe der obersten Ebene für jede Kategorie der Ressourcen, wie beispielsweise Unix-Volumina, Unix-Hostsysteme, Unix-Anwendungen und ähnliches. Wenn die Ausführungsformen der Erfindung dafür ausgelegt sind, spezifische Ressourcen innerhalb dieser Gruppen darzustellen, trifft das Namensgebungsschema, welches weiter oben kurz ausgeführt ist, und zwar mit Verwendung des einfachen Namens oder des einfachen Namens und des Heimes für das Objekt, so daß der Anwender schnell und intuitiv verstehen kann, auf welche Unix-Ressourcen Bezug genommen wird.
Die Ausführungsformen nach der Erfindung unterstützen unterschiedliche Typen von Gruppenobjekten, wie beispielsweise transparente Gruppenobjekte und Terminalgruppenobjekte. Insbesondere kann ein Anwender ein Gruppenobjekt erzeugen, um eine Gruppe von Objekten wiederzugeben, die eine gemeinsame Beziehung teilen, und kann dieses Gruppenobjekt zu einem transparenten Gruppenobjekt machen. Danach werden irgendwelchen Objekten, die zu Beginn innerhalb dieser Gruppe erzeugt werden (das heißt unter oder unterhalb dieses Gruppenobjektes in der Objekthierarchie), ein Heim zugeordnet (das heißt zugewiesen), welches nicht gleich ist dem Transparentgruppenobjekt, unter welchem die neuen Objekte als Kinderobjekte hinzugefügt werden, sondern vielmehr wird das Heim für die neuen Objekte auf das erste nicht transparente Heimobjekt eingestellt, und zwar über dem transparenten Objekt in der Objekthierarchie. Auf diese Weise können Anwender Gruppen für eine visuelle Organisation von Repräsentationen der Ressourcen auf einem graphischen Anwenderinterface erzeugen, ohne die Heimbeziehungen zu beeinflussen, die aufrecht erhalten werden müssen. Mit anderen Worten liefern transparente Objekte einen Mechanismus dafür, um visuelle hierarchische Beziehungen zu erzeugen, ohne den Namen oder den Objektidentifizierer eines Objektes zu beeinflussen.
Zusätzlich zu den transparenten Objekten unterstützen die Ausführungsformen der Erfindung eine Konstruktion, die als "Terminal"-Objekt bezeichnet wird. Wenn ein Anwender ein Gruppenobjekt als Terminal erstellt, dann werden Aktionen, die an diesem Gruppenobjekt ausgeführt werden, nicht an Mitgliedern der Gruppe ausgeführt. Mit anderen Worten werden Objekte, die auf das Terminalgruppenobjekt bezogen sind (das heißt welches unterhalb dem Terminalgruppenobjekt in der Objekthierarchie existiert) nicht durch die Aktionen beeinflußt, die durch einen Anwender oder einen Prozeß an dem Terminalobjekt durchgeführt werden. Als Beispiel kann es erforderlich sein, eine Gruppe von Speichervolumina durch ein Terminalgruppenobjekt unter einer speziellen Repräsentation eines Departmentobjektes zu repräsentieren, um diese Daten in solchen Speichervolumina darzubieten, die auf ein bestimmtes Projekt in diesem Department bezogen sind. Wenn jedoch das Terminalgruppenobjekt, welches solche Volumina repräsentiert (die Volumenobjekte liegen unterhalb des Gruppenobjektes in der Objekthierarchie), unter dem Departmentobjekt (z. B. als ausgewählt) beeinflußt wird, dann werden die Objekte, die unter diese Gruppe fallen (das heißt die Volumina in diesem Beispiel) nicht ebenfalls weggelassen.
Es werden nun mehr spezifische Einzelheiten der Konfiguration und der Betriebsweise der Ausführungsformen der Erfindung unter Hinweis auf die Fig. 1 bis 7 erläutert.
Fig. 1 veranschaulicht ein Beispiel einer Computersystemumgebung 100, die dafür geeignet ist, zur Erläuterung der Betriebsweise der als Beispiel gewählten Ausführungsformen der Erfindung verwendet zu werden. Die Computersystemumgebung 100 bei diesem Beispiel besteht aus einem Speicherbereichsnetzwerk, welches ein Netzwerkmedium 101, wie beispielsweise ein Hochgeschwindigkeitsdatenkommunikationsmedium enthält (z. B. Ethernet, optisches Netzwerk oder anderen Typen eines Netzwerks), welches eine Vielzahl von Ressourcen 102 bis 110 miteinander verbindet und die Möglichkeit schafft, daß die Ressourcen miteinander kommunizieren können. Die Ressourcen enthalten eine Vielfalt an Datenspeichersystemen 102-1 bis 102-N, Speicherbereichsnetzwerkschalter 103-1 bis 103-M, Hostcomputersysteme 104-1 bis 104-B, Clientcomputersysteme 105-1 bis 105-S und ein Computersystem 110, welches bei diesem Beispiel als eine Speicherbereichsnetzwerkmanagementstation konfiguriert ist, die durch einen Netzwerkmanager 108 betrieben wird (das heißt einer Person, die für das Management der Ressourcen innerhalb des Speicherbereichsnetzwerks 100 verantwortlich ist). Obwohl nicht in Einzelheiten in dieser Figur dargestellt, können bestimmte Ressourcen auch eine oder mehrere interne Vorrichtungen enthalten oder betreiben als auch Softwareanwendungen enthalten oder betreiben oder auch Prozesse, die innerhalb oder in Verbindung mit den veranschaulichten Ressourcen arbeiten. Solche anderen Komponenten sollen ebenfalls als Ressourcen betrachtet werden, und zwar für Zwecke dieser Erläuterung.
Von speziellem Interesse bei dieser Erläuterung ist das Managementstationscomputersystem 110, weiches einen Ressourcenmanager 121 betreibt, der gemäß den Ausführungsformen der Erfindung konfiguriert ist. Der Ressourcenmanager 121 liefert ein graphisches Anwenderinterface 150 an einer Anzeige 130 (z. B. einem Monitor oder einer anderen Anzeigevorrichtung), die an das Computersystem 110 gekoppelt ist. Das graphische Anwenderinterface 150 enthält eine Anzeige einer als Beispiel gewählten Ressourcenhierarchie mit einer Vielzahl von Repräsentationen von Objekten, die durch Objektnamen dargestellt sind, die Zeile um Zeile in einer erforderlichen oder hierarchischen Weise angeordnet sind. Jede Zeile in der Objekthierarchie entspricht einer managefähigen Ressource oder einer Gruppe von solchen Ressourcen innerhalb der Computersystemumgebung 100. Beispielsweise repräsentiert die "ALL STORAGE SYSTEM"- Repräsentation ein Gruppenobjekt in einer Objekthierarchie, unter welcher die Objekte für jedes Speichersystem 102-1 bis 102-N enthalten sind.
Fig. 2 veranschaulicht ein Flußdiagramm der Verarbeitungsschritte auf einer hohen Ebene und Betriebe der bevorzugten Ausführungsformen der Erfindung, bei denen Repräsentationen von Objekten erzeugt werden, beispielsweise in solcher Weise, wie dies bei dem als Beispiel gewählten graphischen Anwenderinterface 150 in Fig. 1 gezeigt ist. In bevorzugter Weise führt der Ressourcenmanager 121, der in dem Computersystem 110 arbeitet, die Verarbeitungsoperationen und Schritte durch, die in Fig. 2 dargestellt sind. Die Verarbeitung in Fig. 2 wird unter Hinweis auf die Erzeugung einer Repräsentation eines einzelnen Objektes erläutert. Jedoch können andere Ausführungsformen wiederholt solche Operationen durchführen, um vielfältige Repräsentationen von vielen Objekten zu erzeugen, um eine Objekthierarchie zu bilden, die einige oder alle der Ressourcen in einer Computersystemumgebung (z. B. 100) repräsentieren.
Bei dem Schritt 200 erzeugt der Ressourcenmanager 121 ein Objekt, um eine Ressource (z. B. eine der 102 bis 110) in einer Computersystemumgebung (z. B. 100) zu repräsentieren. Allgemein gesagt, kann die Erzeugung eines Objektes eine objektorientierte Programmierung (instantiation) einer Objektklasse involvieren (z. B. Java- oder C++-Klasse) oder einer anderen Datenstruktur, die Informationen enthält, die auf die Ressource bezogen sind, welche das spezialisierte Objekt repräsentiert. Unterschiedliche Techniken zum Auswählen oder Identifizieren einer Ressource oder von Ressourcen, für die der Ressourcenmanager 121 ein Objekt erzeugt, werden mehr in Einzelheiten an späterer Stelle erläutert. Zum Zwecke der vorliegenden Beschreibung liefert möglicherweise der Anwender 108 des Computersystems 110 eine Identifikation einer spezifischen Ressource, wie beispielsweise ein Volumen eines Datenspeichers, welches dieser Anwender darzustellen wünscht, und zwar innerhalb des als Beispiel gewählten graphischen Anwenderinterfaces 150, welches in Fig. 1 gezeigt ist.
Bei dem Schritt 201 ordnet der Ressourcenmanager 121 einen Objektidentifizierer dem Objekt zu. Der Objektidentifizierer enthält wenigstens einen einfachen Namen des Objektes als auch ein Heim des Objektes. Wie weiter oben kurz erläutert wurde, kann der einfache Name eines Objektes vom Anwender definiert werden oder kann aus einem automatisch generierten Namen, Text oder Zeichenfolge bestehen oder einer ähnlichen Folge, welchen Namen diese Ausführungsform dem Objekt zuordnet, um die Ressource zu identifizieren, die dieses Objekt repräsentiert. Das Heim des Objektes ist äquivalent einer Heimörtlichkeit in einer Objekthierarchie, welche ein Heimobjekt (ein Elternobjekt) in der Objekthierarchie identifiziert, unter der (entweder direkt unter oder stammbaummäßig darunter) das Objekt anfänglich als Kindobjekt zugeordnet wurde (das heißt erzeugt wurde). Ein Heimobjekt definiert somit einen Heimkontext für das Objekt. Als solches ordnet der Ressourcenmanager 121 das Heim des Objektes als Heimörtlichkeit zu, wobei das Heimobjekt für dieses Objekt in der Objekthierarchie identifiziert wird. Es sei in Verbindung mit diesem Beispiel angenommen, daß eine Objekthierarchie Objekte enthält, die bereits teilweise existieren, und daß dieses Objekt der Objekthierarchie unter einem Heimobjekt hinzugefügt werden soll.
Als ein Beispiel der Schritte 200 und 201 sei in Verbindung mit dem graphischen Anwenderinterface 150 in Fig. 1 angenommen, daß der Anwender 108 wünscht, die "VOL02"-Volumenpräsentation 230 unter der STORAGE SYSTEM A Präsentation 231 zu erzeugen. Um dies durchzuführen, erzeugt diese Ausführungsform bei dem Schritt 200 ein Objekt (nicht gezeigt), um das Volumen zu repräsentieren, und bei dem Schritt 201 liefert der Anwender den einfachen Namen VOL02 für den Objektidentifizierer. Es sei bei diesem Beispiel angenommen, daß die VOLUMES-Repräsentation 232 aus einem transparenten Gruppenobjekt besteht, welches einfach dazu verwendet wird, um eine Sichtorganisation für die Ressourcen zu liefern, welches jedoch die Heime der Objekte nicht beeinflußt, die unterhalb der VOLUMES-Repräsentation 232 plaziert sind. Dabei ordnet bei dem Schritt 201 der Ressourcenmanager 121 das Heim der VOL02- Repräsentation 230 zu, und zwar als einen Hinweis (z. B. als Zeiger), zu einem Objekt, welches durch die STORAGE SYSTEM A Repräsentation 231 repräsentiert wird, anstatt diese dem Objekt zuzuordnen, welches durch die VOLUMES-Repräsentation 232 repräsentiert wird, da die VOLUMES-Repräsentation 232 transparent ist.
Als nächstes stellt der Ressourcenmanager 121 bei dem Schritt 202 wenigstens eine Repräsentation des Objektes auf einem graphischen Anwenderinterface dar (das heißt 150 in Fig. 1). Die Repräsentation des Objektes enthält als minimale Größe den einfachen Namen des Objektes, der bei diesem Beispiel "VOL02" lautet.
Als nächstes bestimmt der Ressourcenmanager 121 bei dem Schritt 203, ob eine Heimbedingung für die Repräsentation des Objektes existiert. Eine Heimbedingung kann für eine Repräsentation eines Objektes beispielsweise existieren, wenn diese Repräsentation des Objektes, welches an dem graphischen Anwenderinterface dargestellt werden soll, und zwar aus einem Heimkontext des Objektes heraus, oder wenn die Repräsentation des Objektes an dem graphischen Anwenderinterface in nicht einzigartiger Form in einem Kontext dargestellt werden soll, bei dem die Objektrepräsentation dargestellt wird. Mit anderen Worten, wenn innerhalb des graphischen Anwenderinterfaces 150 der einfache Name eines Objektes als eine Repräsentation des Objektes in einem graphischen. Anwenderinterface dargestellt wird, ist es ausreichend in einzigartiger Weise die Ressource zu identifizieren, die diese Objektrepräsentation repräsentiert, der Ressourcenmanager 121 verwendet den einfachen Namen zu Darstellungszwecken ohne das Heim des Objektes. Wenn alternativ jedoch der Anwender 108, der das graphische Anwenderinterface 150 betrachtet, unfähig ist, eine einzigartige Identifizierung der Repräsentation eines Objektes aus dem einfachen Namen alleine zu bestimmen (z. B. können mehrere Objekte in der Objekthierarchie mit dem gleichen Kontext vorhanden sein, die alle den gleichen einfachen Namen tragen), dann existiert eine Heimbedingung für die Repräsentation dieses Objektes, die es erforderlich macht, daß der Ressourcenmanager 121 das Heim des Objektes in Verbindung mit dem einfachen Namen an dem graphischen Anwenderinterface 150 darstellt, um die Identität des Objektes auf Seiten des Anwenders 108 klarzustellen.
Wenn bei dem Schritt 203 eine Heimbedingung existiert, fährt der Ressourcenmanager 121 zu dem Prozeßschritt 204 weiter fort, um das Heim des Objektes in der Repräsentation des Objektes mit einzuschließen, welche an dem graphischen Anwenderinterface 150 dargestellt wird. Bei dem gewählten Beispiel der Repräsentation gemäß VOL02 230 wird das Heim (STORAGE SYSTEM A) nicht nachfolgend dem einfachen Namen gemäß VOL02 dargestellt, da die VOL02-Repräsentation 230 in seinem Heimkontext dargestellt wird (das heißt, es wird der Schritt 204 übersprungen). Es sei jedoch angemerkt, daß eine andere Repräsentation 233 dieses gleichen Volumens VOL02 unter der VOLUMES-Repräsentation 234 (unter der ALL GROUPS OS STYPE und UNIX- Repräsentationen) in einer voll qualifizierten Weise dargestellt wird, und zwar als "VOL02a STORAGE SYSTEM A", da diese Repräsentation 233 aus ihrem Heimkontext heraus dargestellt wird und da ferner diese Repräsentation 233 einen einfachen Namen "VOL02" hat, welches der gleiche ist wie der einfache Name "VOL02" der Repräsentation 235. Da zwei Repräsentationen 233 und 235 den gleichen einfachen Namen haben, wird jede in einer voll qualifizierten Weise dargestellt und enthält ihr Heim. Auf diese Weise ist es mit Hilfe des Betriebes der Ausführungsformen der Erfindung möglich, die Repräsentation eines Objektes an dem graphischen Anwenderinterface 150 zu ändern, um entweder den einfachen Namen des Objektes zu liefern oder um den Objektidentifizierer in einer voll qualifizierten Weise vorzusehen, enthaltend den einfachen Namen und das Heim des Objektes, abhängig von den Anforderungen, die erforderlich sind, um in einzigartiger Weise eine Ressource zu identifizieren, die durch solche Repräsentationen wiedergegeben wird.
Wenn bei dem Schritt 203 der Ressourcenmanager 121 bestimmt, daß kein Heimzustand oder Heimbedingung für die Repräsentation des Objektes existiert, oder nach der Vervollständigung des Verarbeitungsschrittes 204, schreitet die Verarbeitung zu dem Schritt 205 voran, bei dem der Ressourcenmanager 121 die Schritte 200 bis 204 für alle Ressourcen in einer Computersystemumgebung wiederholen kann, um eine Objekthierarchie zu kreieren und um eine Anzeige der Hierarchie innerhalb des graphischen Anwenderinterfaces 150 zu liefern. Wie oben jedoch dargelegt wurde, kann die Objekthierarchie zu Beginn mit einer minimalen Zahl von Objekten existieren, wie beispielsweise lediglich als ein Wurzelobjekt. Dabei können die wiederholten Verarbeitungsschritte 200-204 in einer Erzeugung einer gesamten Objekthierarchie resultieren, um alle Ressourcen in einer Computersystemumgebung 100 durch Repräsentationen von Objekten an den graphischen Anwenderinterface 150 zu präsentieren.
Jede Repräsentation kann entweder den einfachen Namen des Objektes oder den einfachen Namen und das Heim des Objektes enthalten, abhängig vom Kontext, in welchem diese Repräsentation dargestellt wird. Wenn die Repräsentation des Objektes dargestellt wird, und zwar beispielsweise in ihrem Heimkontext (das heißt, dargestellt unter der Repräsentation des Heimobjektes, welches das Heim für dieses Objekt ist), dann kann der einfache Name dazu verwendet werden, um in einzigartiger Weise die Repräsentation des Objektes zu identifizieren, da diese Repräsentation in einem Heimkontext für dieses Objekt dargestellt wird (oder in anderer Weise einzigartig in dem Kontext identifizierbar ist, in welchem es darzustellen ist). Wenn alternativ ein Anwender oder ein anderer Prozeß bestimmt, daß eine Repräsentation des gleichen Objektes innerhalb des graphischen Anwenderinterfaces enthalten sein soll oder irgendwo innerhalb des graphischen Anwenderinterfaces dargestellt werden soll (beispielsweise, um andere Beziehungen zu bieten, die für eine Ressource anwendbar sind, die diese Repräsentation wiedergibt), dann bestimmen die Ausführungsformen der Erfindung bestimmte Umstände, daß ein Heimzustand oder Heimbedingung existiert, die auch die Darstellung des Heimes des Objektes erfordert.
Um nun kurz die Aufmerksamkeit zurück auf das als Beispiel gewählte graphische Anwenderinterface 150 zu lenken, welches in Fig. 1 gezeigt ist, so erzeugt der Ressourcenmanager 121 jede Repräsentation eines Objektes auf einer getrennten Zeile, und zwar als Zeichenfolge bei diesem Beispiel, und stellt diese auch in der Zeile dar. Beispielsweise ist die ALL STORAGE SYSTEMS Repräsentation 236 eine Repräsentation eines Gruppenobjektes, welches einen Gruppierungsmechanismus liefert, um die Speichersystemobjekte zu gruppieren, die jeweils durch die Repräsentationen STORAGE SYSTEM A bis STORAGE SYSTEM N dargestellt sind. Jedes Speichersystem in der Computersystemumgebung 100 in Fig. 1 ist somit durch eine jeweilige Repräsentation in dem graphischen Anwenderinterface 150 gezeigt. Auch bei diesem Beispiel stellt der Ressourcenmanager 121 unter STORAGE SYSTEM A und STORAGE SYSTEM B eine jeweilige VOLUMES-Gruppenobjektrepräsentation 232, 237 dar, um dem Anwender 108 eine Information zu vermitteln, welche Volumina in jedem jeweiligen Speichersystem gelegen sind. Spezifischer ausgedrückt, sind die Volumina, die durch die Repräsentationen VOL01 bis VOL03 identifiziert werden, innerhalb von STORAGE SYSTEM A enthalten und die Volumina, die durch die Repräsentationen VOL01 und VOL02 identifiziert werden, sind innerhalb von STORAGE SYSTEM B enthalten.
Die Repräsentationen der Volumina VOL01 und VOL02 innerhalb jedes Speichersystems A und B werden unter Verwendung von lediglich den einfachen Namen der Objektidentifizierer für jedes dieser Volumina dargestellt. Wie in Verbindung mit VOL02 230 weiter oben erläutert wurde, ist dies deshalb der Fall, da diese Volumenrepräsentationen innerhalb oder unter ihren Heimkontexts in dem graphischen Anwenderinterface 150 gezeigt werden. Mit anderen Worten versteht der Anwender 108 intuitiv durch Betrachten der einfachen Namen, daß VOL01 und VOL02 für STORAGE SYSTEM A klar auf die Gruppenobjektrepräsentation VOLUMES 232 unter der STORAGE SYSTEM A Repräsentation bezogen sind, während VOL01 und VOL02 für STORAGE SYSTEM B klar auf die Gruppenobjektrepräsentation VOLUMES 237unter der STORAGE SYSTEM B Repräsentation bezogen sind. Da der Ressourcenmanager 121 diese Volumenrepräsentationen innerhalb von deren Heimkontext darstellt, wird lediglich der einfache Name zum Repräsentieren oder Wiedergeben dieser Ressourcen verwendet.
Im Gegensatz dazu repräsentieren die "VOLUMES"-Repräsentationen 234 und 238 Gruppierungen von irgendwelchen Unix- oder MVS-Volumina, die innerhalb der Computersystemumgebung existieren. Da die einfachen Namen VOL01 und VOL02 für unterschiedliche Volumina in unterschiedlichen Speichersystemen existieren, stellt der Ressourcenmanager 121 die spezifischen Volumenrepräsentationen für die Volumina VOL01@STORAGE SYSTEM A, VOL01@STORAGE SYSTEM B, VOL02@STORAGE SYSTEM B und VOL01@STORAGE SYSTEM A in einer voll qualifizierten Weise dar, unter Verwendung von sowohl dem einfachen Namen als auch dem Heim der Objekte (nicht gezeigt), die diesen Volumina entsprechen (das heißt diesen Ressourcen), um dem Anwender 108 Informationen zu liefern, welche spezifischen Volumina UNIX- und MVS-Volumina sind. Bei diesem Beispiel sind der einfache Name und das Heim des Objektes mit einem "@"-Symbol getrennt, welches es dem Anwender 108 ermöglicht, schnell zwischen dem einfachen Namen und dem Heim eines Volumens zu unterscheiden.
Die voll qualifizierte Syntax einer Repräsentation eines Objektes in einem graphischen Anwenderinterface erscheint bei dieser beispielhaften Ausführungsform wie folgt:

OBJEKT-ICON OBJECT-SIMPLE-NAME@HOME-OF-OBJECT
Da abgesehen von einem Objekt-Icon (welches in dem graphischen Anwenderinterface optional vorgesehen wird und in dem Beispiel von Fig. 1 nicht gezeigt ist), der einfache Name des Objektes zuerst in der Repräsentation des Objektes dargestellt wird, kann ein Anwender, der ein graphisches Anwenderinterface betrachtet, welches viele Repräsentationen von vielen Objekten enthält, die in dieser Syntax ausgedrückt sind, schnell und in einfacher Weise die Identität von jeder Objektrepräsentation in der Liste erkennen und bestimmen, da jeder einfache Name eines Objektes, der den wichtigsten Teil des Objektidentifizierers, welcher diesem Objekt zugeordnet ist, darstellt, und zwar von der Sicht des Anwenders aus zuerst erscheint. Wenn das graphische Anwenderinterface viele Objekte in einer vertikalen Weise (das heißt einer Liste von spezifischen Volumina) auflistet, liegen die einfachen Namen von jeder Objektrepräsentation in einer Linie (z. B. links und von oben nach unten), so daß es für den Anwender einfach wird, eine Objektrepräsentation von einer anderen zu unterscheiden.
Fig. 3 veranschaulicht eine als Beispiel gewählte Architektur des Computersy- stems 110, welches gemäß den Ausführungsformen der Erfindung konfiguriert ist. Das Computersystem 110 kann aus irgendeinem Typ einer computerisierten Vorrichtung bestehen, wie beispielsweise einem Personalcomputer, einer Workstation, einer tragbaren Computervorrichtung oder ähnlichem. Das Computersystem 110 enthält einen Verbindungsmechanismus 111, der eine Speichersystem 112, einen Prozessor 113, ein Eingabe/Ausgabeinterface 114 und ein Kommunikationsinterface 115 koppelt. Das Eingabe/Ausgabeinterface 114 ermöglicht es peripheren Vorrichtungen, wie beispielsweise der Anzeige 130 (z. B. einem Computermonitor, Fig. 1), an das Computersystem angeschlossen zu werden, um das graphische Anwenderinterface 150 zu liefern. Zusätzlich kann eine periphere Eingabevorrichtung 116, wie beispielsweise eine Maus oder ein Keyboard, an das Eingabe/Ausgabeinterface 114 gekoppelt sein. Das Kommunikationsinterface 115 ermöglicht es dem Computersystem 110, mit einer Software oder mit Hardwarevorrichtungen (das heißt Ressourcen) zu kommunizieren, die innerhalb des Netzwerks 100 in Betrieb sind.
Ein Speichersystem 112 ist mit einer Ressourcenmanagementanwendung 120 kodiert. Die Ressourcenmanagementanwendung 120 repräsentiert einen Softwarekode, wie beispielsweise Daten- und/oder logische Befehle (z. B. in dem Speicher abgespeichert oder in einem anderen vom Computer lesbaren Medium wie einer Platte), welche die Verarbeitungsfunktionalität der Ausführungsformen der Erfindung verkörpern. Der Prozessor 113 kann auf das Speichersystem 112 über den Verbindungsmechanismus 111 zugreifen, um logische Befehle abzusetzen, laufen zu lassen, auszuführen oder zu interpretieren oder in anderer Weise durchzuführen, und zwar von der Ressourcenmanagementanwendung 120, um einen Ressourcenmanager 121 zu erzeugen. Mit anderen Worten, repräsentiert der Ressourcenmanager 121 einen oder mehrere Abschnitte einer Ressourcenmanagementanwendung 120 (oder die gesamte Anwendung 120, die innerhalb oder mit Hilfe des Prozessors 113 in dem Computersystem 110 durchgeführt oder ausgeführt wird).
Es sei darauf hingewiesen, daß die Ausführungsformen der Erfindung die Ressourcenmanagementanwendung 120 enthalten (das heißt die nicht ausgeführten oder nicht durchgeführten logischen Befehle und/oder Daten), die innerhalb eines vom Computer lesbaren Mediums, wie beispielsweise einer Diskette, einer Festplatte oder einem optischen Medium, kodiert sind, oder in einem Speichertypsystem, wie beispielsweise in einer Firmware, einem Nur-Lese-Speicher (ROM) oder wie bei dem vorliegenden Beispiel als ausführbarer Kode innerhalb des Speichersystems 112 (z. B. innerhalb eines Speichers mit wahlfreiem Zugriff oder RAM). Es sei auch darauf hingewiesen, daß andere Ausführungsformen der Erfindung die Ressourcenmanagementanwendung 120 enthalten, die mit dem Prozessor 113 als Ressourcenmanagementprozeß 121 zusammenarbeitet. Obwohl bei diesem Beispiel nicht gezeigt ist, können Fachleute verstehen, daß das Computersystem 110 andere Prozesse und/oder Software und Hardwarekomponenten enthalten kann, wie beispielsweise ein Betriebssystem, welche Komponenten aus dieser Darstellung zum Zwecke einer Vereinfachung der Beschreibung weggelassen wurden.
Wie in Fig. 3 veranschaulicht ist, erzeugt der Ressourcenmanager 121 ein als Beispiel gewähltes graphisches Anwenderinterface 150, welches eine Repräsentation 151 einer anderen als Beispiel gewählten Objekthierarchie (in dieser Figur nicht gezeigt) liefert. Einzelheiten der Repräsentation 151, die für die Ausführungsformen der Erfindung spezifisch sind, werden nach einer Erläuterung erklärt, und zwar anhand der Fig. 4 und 5 gemäß einem Beispiel einer einzelnen Objektdatenstruktur (Fig. 4) und gemäß einer als Beispiel gewählten Objekthierarchie (Fig. 5), die der Repräsentation 151 in Fig. 3 entspricht.
Fig. 4 veranschaulicht ein Beispiel einer Objektdatenstruktur 302 (z. B. einer Klassendefinition), die für die Verwendung bei den Ausführungsformen der Erfindung geeignet ist. Das Objekt 302 umfaßt eine Vielzahl von Feldern 303 bis 326, die einen Objektidentifizierer 303, eine Liste von einem oder mehreren Elternobjekten 309, einen Gruppenobjektindikator 316, eine Referenz zu einem oder mehreren Kindobjekten 322, eine Referenz zu einem oder mehreren Objekteigenschaften 324 und eine Referenz zu einem oder mehreren Objektverfahren 326 enthalten. Der Objektidentifizierer enthält einen einfachen Namen 304, ein Heim des Objektes 305, einen Suffixabschnitt 306 (wenn dies erforderlich, wie noch erläutert wird) und ein optionales Icon 307. Diese Felder 304 bis 307 umfassen allgemein die Informationen, die der Ressourcenmanager 121 an der Anzeige 130 darstellen kann, um eine Repräsentation des Objektes in dem graphischen Anwenderinterface 150 zu liefern. Einige oder alle der Informationen aus den Objektidentifiziererfeldern 304 bis 307 können dazu verwendet werden, um eine Ressource in einem graphischen Anwenderinterface 150 zu repräsentieren.
Wie an früherer Stelle bereits erwähnt wurde, enthält der einfache Name 304 allgemein eine alphanumerische Folge von Zeichen, die in einmaliger Weise eine Ressource identifizieren, welche dieses Objekt 302 innerhalb seines Heimkontextes repräsentiert. Der Heimkontext ist durch das Heim des Objektes 305 festgelegt, welches aus einem Hinweis auf das Heimobjekt 310 erhalten wird. Wenn der Ressourcenmanager 321 zu Beginn das Objekt 302 erzeugt, identifiziert ein Anwender oder ein anderer Prozeß (z. B. ein Auffindprozeß, der noch erläutert wird) ein anderes Objekt 302 innerhalb einer Objekthierarchie, unter welcher dieses Objekt 302 erzeugt werden soll. Die anfängliche Plazierungsörtlichkeit innerhalb einer Objekthierarchie bestimmt, welches Objekt 302 innerhalb einer Hierarchie zu Beginn ein Heimobjekt 310 wird, und zwar für das Objekt 302, und definiert somit das Heim 305 des Objektes 302.
Der Ressourcenmanager 121 kann eine Repräsentation des Objektes 302 an anderen Stellen innerhalb einer Objekthierarchie erfordern. Um für solche anderen Repräsentationen Rechnung zu tragen, zeigen Elternobjektindikatoren 312 die Identität von anderen Objekten 302 neben dem Heimobjekt 310 an, unter welcher eine Repräsentation dieses Objektes 302 erzeugt werden sollte, um die Repräsentation an dem graphischen Anwenderinterface 150 mit einem Ressourcenmanager 121 zu ermöglichen, und zwar in Form von Darstellungen an dem graphischen Anwenderinterface 150. Für jeden Elternobjektindikator 312 ist ein entsprechender Heimzustand oder Heimbedingung 314 enthalten, welche der Ressourcenmanager 121 verwendet, um zu bestimmen, ob das Heim des Objektes 305 in der Repräsentation des Objektes mit enthalten sein muß oder nicht, wenn es innerhalb des graphischen Anwenderinterfaces 150 dargestellt wird.
Der Gruppenobjektindikator 316 zeigt an, ob das Objekt 302 als ein Gruppenobjekt zu betrachten ist oder nicht. Wie oben erläutert wurde, repräsentiert ein Gruppenobjekt allgemein keine einzelne bestimmte physikalische Ressource (das heißt repräsentiert keine spezifische Software oder Hardwareressource), sondern repräsentiert stattdessen eine Kollektion oder Gruppe von solchen Ressourcen, die präsentiert werden können und auf die kollektiv eingewirkt werden kann. Der Gruppenobjektindikator 316 enthält transparente und Terminalindikatoren 318 und 320. Im allgemeinen enthalten die transparenten und die Terminalindikatoren 318 und 320 beispielsweise Boolsche Werte, die anzeigen, ob dieses Objekt 302 als transparent und/oder als Terminal in bezug zu seiner Plazierung innerhalb einer Objekthierarchie in Relation zu anderen Objekten 302 zu betrachten ist oder nicht. Wie oben angeführt ist, wirkt ein transparentes Objekt nicht oder dient als ein Heim für Objekte, die darunter in einer Objekthierarchie plaziert sind. Ein Terminalobjekt, dessen Zweck noch später mehr in Einzelheiten erläutert werden soll, verhindert allgemein Aktionen, die bei dem Terminalgruppenobjekt angewendet werden, daß diese bei den Kinderobjekten dieses Terminalgruppenobjekts angewendet wird. Mit anderen Worten, wenn ein Anwender versucht, eine Managementfunktion oder eine Aktion an einem Objekt durchzuführen, welches aus einem Terminalobjekt besteht, so wird diese Funktion oder Aktion nicht auf Objekte angewendet, die unter diesem Objekt in einer Objekthierarchie liegen.
Die Kindobjektverweise 322 liefern Zeiger, Hinweise oder andere Indikatoren von jeglichen Kindobjekten, die unter diesem Objekt 302 liegen, und zwar innerhalb einer Objekthierarchie. Die Objekteigenschaftsfelder 324 identifizieren jegliche anderen Eigenschaften, die auf eine Ressource bezogen sind, welche dieses Objekt 302 repräsentiert. Als ein Beispiel kann das Objekteigenschaftsfeld 324 spezifische Ressourceninformationen enthalten, wie beispielsweise Vorrichtungskonfigurationsinformationen, Softwareversionsinformationen oder Betriebsinformationen, Vorrichtungs- oder Softwareseriennummern oder irgendwelche anderen Informationen, die zutreffend sind oder nützlich sind, damit das Objekt 302 eine spezifische Ressource innerhalb einer Computersystemumgebung 100 wiedergibt. Zusätzlich enthalten die Objektverfahren 326 Referenzen zu jeglichen Funktionen, Operationen, Verfahren, Routinen, Programmbibliotheken oder -prozeduren, die logische Operationen definieren, die die Ressource betreffen, welche dieses Objekt 302 repräsentiert. Innerhalb einer Ressourcenmanagementanwendung 120 können die Objektverfahren 326 beispielsweise die Managementfunktionalität oder Aktionen definieren, die ein Anwender 108 anwenden kann oder aufrufen kann, um eine spezifische Ressource zu managen, die dem Objekt 302 zugeordnet ist.
Fig. 5 veranschaulicht eine Betriebsumgebung 300, in welcher der Ressourcenmanager 121 eine Eingangsgröße von einem Anwender 108 empfangen kann und optional von einem Aufsuchprozeß 310, um auf einen Ressourcenpool 308 zuzugreifen, um eine Objekthierarchie 301 zu erzeugen, die Objekte 302 enthält, welche verschiedene Ressourcen oder Gruppierungen von Ressourcen in dem Ressourcenpool 308 repräsentieren. Bei diesem Beispiel enthält die Objekthierarchie 301 ein Objekt für jede Repräsentation von dem graphischen Anwenderinterface 150 in Fig. 3. Das heißt, es gibt eine Eins-zu-Eins-Entsprechung zwischen jedem Objekt 302 in der Objekthierarchie 301 in Fig. 3 und jeder Repräsentation eines Objektes (z. B. 350 bis 362), die in dem hierarchischen graphischen Anwenderinterface 150 in Fig. 3 gezeigt sind.
In Fig. 5 repräsentiert der Ressourcenpool 308 einen Satz von Ressourcen (z. B. 102 bis 110 in Fig. 1) innerhalb einer Computersystemumgebung 100, auf die durch den Ressourcenmanager 121 zugegriffen werden kann, und zwar zum Zwecke der Darstellung und des Managements innerhalb des graphischen Anwenderinterfaces 150. Während der Erzeugung und Präsentation der Objekte 302, wie dies an früherer Stelle in bezug auf Fig. 2 erläutert wurde, kann der Anwender 108 den Ressourcenmanager 121 dazu verwenden, den Ressourcenpool 308 nach verfügbaren managefähigen Ressourcen abzufragen, um die Objekte 302 an geeigneten Stellen innerhalb der Objekthierarchie 301 zu erzeugen. Der Ressourcenmanager 121 kann auch in Verbindung mit einem Auffind- oder Aufsuchprozeß 310 arbeiten.
Im allgemeinen ist der Suchprozeß 310 befähigt, automatisch Ressourcen in dem Ressourcenpool 308 abzufragen (z. B. Abfragen von Vorrichtungen in einem Speicherbereichsnetzwerk), um Informationen über jede Ressource zu erhalten, und ist dann dazu befähigt, den Ressourcenmanager 121 in Einklang mit den Techniken aufzurufen, wie sie hier erläutert sind, um ein Objekt 302 zu erzeugen, welches jeder entdeckten Ressource entspricht, und um ferner eine Repräsentation dieses Objektes an dem graphischen Anwenderinterface 150 darzustellen. Dieser Prozeß wird für jede Ressource in dem Ressourcenpool 308 wiederholt, was zu einer automatisierten Erzeugung der Objekthierarchie 301 und dem graphischen Anwenderinterface 150 führt, welches die Repräsentation 151 der Objekthierarchie enthält.
Um erneut auf Fig. 3 einzugehen und speziell auf das graphische Anwenderinterface 150, so enthält die Beispielrepräsentation 151 der Objekthierarchie eine Repräsentation von jedem bestimmten Objekt 302 in der Objekthierarchie 301 von Fig. 5. Das heißt, jedes Objekt 302 wird durch eine entsprechende Repräsentation eines Objektes in dem graphischen Anwenderinterface 150 gezeigt. Um das graphische Anwenderinterface 150 darzustellen, ist der Ressourcenmanager 121 dazu befähigt, die Objekthierarchie 301 zu durchwandern, und ist befähigt, für jedes Objekt 302, welches in der Objekthierarchie 301 enthalten ist, eine Repräsentation dieses Objektes 302 an dem graphischen Anwenderinterface 150 in Einklang mit der Namensgebung und den Gruppierungstechniken, die hier erläutert sind, anzuzeigen.
Der Ressourcenmanager 121 stellt die meisten Repräsentationen von Objekten aus der Objekthierarchie 301 dar, und zwar unter Verwendung von lediglich dem einfachen Rahmen 304 des Objektes, wenn der einfache Name in einzigartiger Weise ein Objekt 302 in dem Kontext identifiziert, in welchem es innerhalb des graphischen Anwenderinterfaces 150 dargestellt wird. Als Beispiel besitzen bei dem graphischen Anwenderinterface 150 in Fig. 3 die Repräsentationen 350, 351 der Volumenobjekte 302-13 und 302-22 von Fig. 5 den gleichen einfachen Namen "VOL001" und brauchen daher nicht ihre jeweiligen Heime 305 zu enthalten (z. B. "BIG BERTHA" und "LITTLE BERTHA"), da jeder in seinem Heimkontext dargestellt wird (das heißt unter den Repräsentationen von deren Heimobjekten 302-28 und 302-29 (Fig. 5)).
Die Notierung des Heimkontextes kann variieren abhängig von den spezifischen Ausführungsformen der Erfindung. Bei dem gewählten Beispiel wird die Bezeichnung "Kontext" oder "Heimkontext" durch eine spezifische Ebene definiert (z. B. die rechte Verkettungsebene in der als Beispiel gewählten Hierarchie, die in Fig. 3 gezeigt ist), und zwar in der Hierarchie in Verbindung mit einer gemeinsamen Liste der Repräsentationen der Objekte an oder auf dieser Ebene (das heißt an der gleichen Örtlichkeit in der Hierarchie). Mit anderen Worten, das, was durch eine gemeinsame Liste von zwei Objekten mit dem gleichen Kontext gemeint ist, ist die Existenz von zwei oder mehreren Repräsentationen von Objekten in der gleichen Ebene und an der gleichen Örtlichkeit oder Stelle in der Objekthierarchie. Beispielsweise sind gemäß Fig. 3 unter der UNIX- Gruppenrepräsentation 354 die Repräsentationen 355 bis 357 von UNIX-Host- und Speichersystemressourcen je in einer voll qualifizierten Weise gezeigt, und zwar unter Verwendung von sowohl den einfachen Namen und der Heime der entsprechenden Objekte 302-11 bis 302-13 in der Objekthierarchie 301. Der Ressourcenmanager 121 stellt die Repräsentationen 355 und 356 in einer voll qualifizierten Weise dar, und zwar in Form von "BIGBERTHA@HOSTS" und "BIGBERTHA@STORAGE", da der einfache Name "BIGBERTHA" nicht dazu verwendet werden kann, in einzigartiger Weise jede dieser Ressourcen in dem Kontext zu identifizieren, die zusammen dargestellt werden (das heißt an der gleichen Örtlichkeit und Ebene), und zwar unter der UNIX-Gruppenrepräsentation 354 innerhalb der Repräsentation 150 der Objekthierarchie 301 in dem graphischen Anwenderinterface 150.
Um nun die Aufmerksamkeit auf die Repräsentation 357 des Volumenobjektes "VOL001.@BIGBERTHA#1" zu lenken, so sind zwei einzigartige Aspekte der Ausführungsformen der Erfindung durch diese Repräsentation 357 veranschaulicht. Insbesondere enthält diese beispielhafte Ausführungsform des Ressourcenmanagers 121 das Heim des Volumenobjektes "BIGBERTHA" in der Repräsentation 356, da es eine Vielzahl an Objekten 302-13 und 302-22 gibt, die Volumenressourcen wiedergeben, die den einfachen Namen VOL001 haben. Wenn somit lediglich der einfache Name VOL001 in der Repräsentation 357 verwendet werden würde, so wäre der Anwender nicht darüber informiert, auf welche spezielle Volumenressource hier hingewiesen wird.
Zusätzlich veranschaulicht die Repräsentation 357 eine Beispieloperation der Ausführungsform der Erfindung, bei der ein Suffix an das Ende des Heimes 305 eines Objektes für den Fall angehängt wird, daß ein Heimzustand oder Heimbedingung ebenfalls anzeigt, daß es viele Heimressourcen gibt, die den gleichen einfachen Namen haben. Spezifischer gesagt, hängt der Ressourcenmanager 121 in Fig. 3 eine Suffix "#1" an das Heim "BIGBERTHA" an, um in einzigartiger Weise eine Identifizierung zu erreichen, welche die "BIGBERTHA"-Heimressource spezifiziert, zu der die Volumenressource VOL001 zugeordnet ist. Dies ist deshalb so, da es zwei BIGBERTHA-Heimressourcenrepräsentationen 357 und 352 gibt. Mit anderen Worten kann diese Ausführungsform des Ressourcenmanagers 121 eine Suffix an das Ende des Heimes eines Objektes innerhalb des graphischen Anwenderinterfaces 150 anhängen, wenn der Ressourcenmanager 121 bestimmt, daß das Heim 305 nicht einzigartig innerhalb der Objekthierarchie 301 ist. Die Suffix "#1" bei diesem Beispiel zeigt dem Anwender 108 an, daß es eine Vielzahl an BIGBERTHA-Heimressourcen gibt, die das Computersystem 110 repräsentieren kann, und der Anwender kann somit den Wunsch haben, zu prüfen, um sicher zu sein, welche VOL001 durch die Repräsentation 356 repräsentiert wird.
Bei einer Ausführungsform der Erfindung kann eine Anwenderaktion, wie beispielsweise das Bewegen einer Maus über die Repräsentation 356 den Ressourcenmanager 121 triggern, um eine Werkzeugspitze oder Aufklappfenster (pop-up window) vorzusehen, welches eine detailliertere Erläuterung anzeigt oder liefert, auf welche spezielle Volumenressource VOL001 hinweist, und zwar an dieser Stelle 356 innerhalb des graphischen Anwenderinterfaces 150. Die Pop-up oder Werkzeugspitze kann den vollständigen Pfadnamen der VOL01-Ressource innerhalb der Objekthierarchie 301 wiedergeben. Im allgemeinen können dabei Ausführungsformen der Erfindung ein Suffix dem Heim eines Objektes zuweisen, wenn das Heim des Objektes in Konflikt mit einem Heim eines anderen Objektes innerhalb der Computersystemumgebung steht, derart, daß die Heime von jedem Objekt voneinander unterschieden werden.
Andere Aspekte der als Beispiel gewählten Repräsentation 151 der Objekthierarchie 301 umfassen die Fähigkeit oder Möglichkeit, unterschiedliche Typen von Beziehungen zwischen den gleichen Repräsentationen von Objekten durch Gruppen oder durch Gruppenbildung darzubieten. Insbesondere enthält die als Beispiel gewählte Repräsentation 151 der Objekthierarchie einen Bereich 380, der physikalische Beziehungen zwischen den Ressourcen liefert, die durch die Objekte 302 in der Objekthierarchie 301 repräsentiert werden. Zusätzlich werden software-logische oder Operationsbeziehungen dem Anwender durch die Repräsentationen in dem Bereich 381 dargeboten, die Ressourcen kategorisieren oder gruppieren, und zwar in Einklang mit unterschiedlichen Typen eines Betriebssystems, welches mit solchen Ressourcen arbeitet. Schließlich sind in dem Bereich 382 Repräsentationen von Ressourcen dadurch angeordnet, indem organisatorische, Department- oder Anwenderfunktionen verwendet werden. Spezifischer gesagt, sind innerhalb des Bereiches 382 die Ressourcen durch Projekte und Anwender angeordnet, die diesen Ressourcen zugeordnet sind. Es sei darauf hingewiesen, daß ein Ressourcenmanager 121 gemäß den Ausführungsformen der Erfindung so konfiguriert sein kann, daß er eine Repräsentation einer einzelnen Ressource zulässt, die an vielen Stellen innerhalb der Gesamtrepräsentation 151 einer Objekthierarchie 301 erscheint. Dies wird dann als Gruppe oder Gruppenbildung bei den Ausführungsformen der Erfindung bezeichnet.
Als ein Beispiel einer Gruppenbildung kann ein Anwender ein Objekt 302 erzeugen, welches keine physikalische Ressource repräsentiert, sondern eine Gruppe von solchen Ressourcen repräsentiert. Der Anwender kann dann ein Feld 322 mit Kindobjekten ableiten, und zwar von diesem Gruppenobjekt 302 mit Hinweisen auf tatsächliche physikalische oder logische Ressourcenobjekte 302. Allgemein ausgedrückt, kann ein Gruppenobjekt und eine Repräsentation desselben einen Hinweis oder Bezugnahme auf irgendeine Zahl von Kindobjekten 302 in der Objekthierarchie 301 enthalten, von denen einige oder alle den Ressourcen oder anderen Gruppen der Ressourcen entsprechen können.
Als ein spezifisches Beispiel in Verbindung mit dem graphischen Anwenderinterface 150, welches in Fig. 3 gezeigt ist, ist die Repräsentation des Gruppenobjektes MISSILES 358 unter der Repräsentation des Gruppenobjektes PROJECTS 359 definiert und ist auch an der Stelle 360 definiert bzw. mit Hinweis versehen, und zwar als eine Zahl von MORRIE'S GROUPS 361. Es sei darauf hingewiesen, daß die Repräsentation 360 der MISSILES-Gruppe in einer voll qualifizierten Weise dargestellt ist, da diese Repräsentation 360 außerhalb ihres Heimkontextes steht, und daß eine zweite Repräsentation eines Objektes 362 vorhanden ist, welches ebenfalls den einfachen Namen "MISSILES" trägt. Somit zeigt der Ressourcenmanager 121 dieser Ausführungsform der Erfindung dem Anwender 108 an, daß die Repräsentation 360 gemäß "MISSILES@PROJECTS" auf die MISSILES-Repräsentation 358 verweist, anstatt auf die MISSILES-Repräsentation 362.
Unter Verwendung der zuvor erläuterten Techniken der Verwendung von einfachen Namen, Heimen des Objekts, Gruppenbildung und von Suffixes ist ein Ressourcenmanager 121, der gemäß den Ausführungsformen der Erfindung konfiguriert ist, dazu befähigt, Repräsentationen von Objekten zu liefern, die in dem Kontext einzigartig sind, in welchem sie innerhalb eines graphischen Anwenderinterface 150 dargestellt werden, und die auch einen kurzen präzisen Weg dafür liefern, dem Anwender 108 anzuzeigen, welche Ressource durch die spezielle Repräsentation gemeint ist bzw. auf welche verwiesen wird. Ferner erlauben diese Ausführungsformen, daß eine einzelne Ressource durch Vielfachrepräsentationen an unterschiedlichen Örtlichkeiten oder Stellen innerhalb eines graphischen Anwenderinterfaces 150 wiedergegeben werden, während jedoch sichergestellt wird, daß der Anwender 108 eine Identifizierung durchführen kann, auf welche Ressource an einer spezifischen Stelle verwiesen wird, und zwar in Situationen, bei denen entweder Vielfachressourcen mit den gleichen einfachen Namen vorhanden sind, oder in Situationen, bei denen es nicht vollständig intuitiv für einen Anwender ist, zu erkennen, welche Ressource gemeint ist bzw. auf welche verwiesen wird.
Fig. 6 zeigt ein Flußdiagramm von Verarbeitungsschritten, die ein Ressourcenmanager 121 gemäß den Ausführungsformen der Erfindung durchführen kann, um einem Anwender 108 oder einem Aufsuchprozeß 310 die Möglichkeit zu bieten, ein Objekt 302 innerhalb der Objekthierarchie 301 zu erzeugen.
Bei dem Schritt 400 empfängt der Ressourcenmanager 121 eine Identifikation einer ausgewählten Ressource, für die ein Objekt 302 in der Ressourcenhierarchie hergestellt werden soll. Wie weiter oben angeführt wurde, kann entweder der Anwender 108 oder ein Suchprozeß (discover process) 310 solch eine Identifikation einer Ressource liefern.
Als nächstes fragt bei dem Schritt 401 der Ressourcenmanager 121 bei der ausgewählten Ressource nach irgendwelchen Ressourceneigenschaften an, die dieser Ressource zugeordnet sind. Die Ressourceneigenschaften können beispielsweise den Typ der Ressource (z. B. Hardware, Software, Vorrichtung usw.), eine Seriennummer, den Namen oder eine andere Identifikation enthalten, die der Ressource zugeordnet ist bzw. sind, oder kann irgendeine andere Information enthalten, die für den Anwender der Ressourcenmanagementanwendung 120 von Bedeutung oder relevant ist.
Bei dem Schritt 402 empfängt der Ressourcenmanager 121 einen einfachen Namen für das Objekt 302, der die Ressource repräsentiert. Als ein Beispiel kann der Ressourcenmanager 121 die Seriennummer von den Ressourceneigenschaften verwenden, und zwar als den einfachen Namen 304 für das Objekt 302. Alternativ kann der Anwender 108 den einfachen Namen 304 als Textfolge eingeben. Der einfache Name sollte einzigartig hinsichtlich seines Heimkontextes sein. Wenn dies nicht der Fall ist, kann der Ressourcenmanager 121 den Anwender darauf aufmerksam machen oder diesen auffordern, einen einzigartigen einfachen Namen für das Objekt 302 einzugeben, der die Ressource wiedergeben soll.
Bei dem Schritt 403 bestimmt der Ressourcenmanager, ob das Objekt 302 eine vorgewählte oder vorbestimmte Heimstelle innerhalb der Objekthierarchie 301 besitzt. Diese Bestimmung kann beispielsweise unter Verwendung einer spezifischen Ressourceneigenschaft durchgeführt werden, die anzeigt, daß die Ressource, die dieses Objekt 302 repräsentiert, auf eine andere bestimmte Ressource bezogen ist. Wenn als Beispiel die Ressource, für die das Objekt 302 eine Repräsentation liefert, ein Plattenlaufwerk in einem Datenspeichersystem ist, dann dient möglicherweise die Datenspeichersystemressource selbst (das heißt ein Objekt 302, welches dem Datenspeichersystem entspricht) als Heimstelle in der Objekthierarchie 301 für das Plattenressourcenobjekt 302. Allgemein gesagt, können einige Ressourcen vordefinierte Heimstellen oder Heimörtlichkeiten haben, die von vorexistierenden Beziehungen zu anderen Ressourcen abhängen. Beispielsweise können Softwareanwendungen, die in einem speziellen Computersystem installiert sind, ein Objekt 302 verwenden, welches dieses Computersystem in der Objekthierarchie 301 repräsentiert, und zwar als deren Heim 305. Um das Heimkonzept mit zusätzlichen Beispielen zu veranschaulichen, so können Platten und Volumina vordefinierte Heime von Speichersystemen darstellen, in denen sie vorkommen. Verzeichnisse oder Dateien können ein vorbestimmtes Heim eines Volumens oder eines Abschnitts enthalten, in welchem sie vorkommen. Ports können ein Heim eines Schalters oder eines Routers besitzen, in welchem sie vorkommen usw.
Wenn der Ressourcenmanager 121 bei dem Schritt 403 bestimmt, daß kein vorgewähltes oder vorbestimmtes Heim 305 zugeordnet ist oder es für die Ressource offensichtlich ist, die durch das Objekt 302 repräsentiert wird, schreitet die Verarbeitung zu dem Schritt 404 voran, bei dem der Ressourcenmanager 121 eine Anwenderauswahl einer Heimörtlichkeit für das Objekt 302 innerhalb der Objekthierarchie 301 empfängt. Beispielsweise kann der Ressourcenmanager 121 einem Anwender 108 erlauben, ein bestimmtes Heimobjekt 302 innerhalb der Objekthierarchie 301 auszuwählen (z. B. über die Darstellung der momentanen Hierarchie 301 an dem graphischen Anwenderinterface 150), um als ein Heim für das neue Objekt zu dienen, welches erzeugt wird, entsprechend den Verarbeitungsschritten in Fig. 6.
Nach dem Verarbeitungsschritt 404 oder nachdem der Ressourcenmanager bei dem Schritt 403 eine vorbestimmte Heimörtlichkeit oder Stelle bestimmt hat, verläuft der Prozeß zu dem Schritt 405, bei dem der Ressourcenmanager 121 bestimmt, ob das Heimobjekt, welches an der ausgewählten Heimstelle oder Örtlichkeit innerhalb der Objekthierarchie 301 liegt, "transparent" ist. Wie weiter oben erläutert wurde, wenn ein Objekt 302 als transparent 318 (Fig. 4) angezeigt wird, kann dieses Objekt 302 nicht als Heimobjekt dienen. Somit können neue Kindobjekte, die anfänglich erzeugt werden oder unter ein transparentes Objekt in der Objekthierarchie 301 eingeschoben werden, kein Heim 305 haben, welches dem transparenten Objekt zugeordnet ist. Vielmehr werden solche neuen Objekte einem Heim zugeordnet, welches gleich ist mit dem ersten nichttransparenten Objekt, welches hierarchisch über dem transparenten Objekt innerhalb der Objekthierarchie 301 liegt. Auf diese Weise kann das transparente Objekt dazu verwendet werden, Ressourcen zu kategorisieren oder zu gruppieren, ohne dem Erfordernis, daß die Gruppenobjekte in einem Heim enthalten sein müssen, welches einen Pfad zu dem Objekt in der Objekthierarchie 301 definiert.
Wenn bei dem Schritt 405 der Ressourcenmanager 121 bestimmt, daß das Heimobjekt 302 an der ausgewählten Heimstelle in der Objekthierarchie 301 transparent ist, schreitet die Verarbeitung bzw. Prozeß zu dem Schritt 406 voran, bei dem der Ressourcenmanager 121 die Objekthierarchie 301 nach oben hin durchläuft, und zwar beginnend von der ausgewählten Heimobjektstelle aus (das heißt beginnend an dem transparenten Objekt), bis der Ressourcenmanager 121 das erste nichttransparente Heimobjekt innerhalb der Objekthierarchie 301 auffindet und somit eine richtige Heimstelle oder Heimörtlichkeit identifiziert wird, die das erste nichttransparente Heimobjekt in der Objekthierarchie 301 ist.
Wenn bei dem Schritt 405 das Heimobjekt an der ausgewählten Heimstelle nicht transparent ist oder nach dem Verarbeitungsschritt 606, um ein Heim für das nichttransparente Objekt zu finden, welches über dem transparenten Objekt in der Objekthierarchie 301 existiert, schreitet der Ressourcenmanager 121 zu dem Verarbeitungsschritt 407 voran, bei welchem der Ressourcenmanager 121 das Heim des Objektes 305 auf die momentane oder laufende (das heißt identifizierte) Heimstelle innerhalb der Objekthierarchie 301 einstellt.
Als nächstes stellt der Ressourcenmanager 121 bei dem Schritt 408 (das heißt unter der Lenkung des Anwenders 108) die Objektgruppen-316-, Transparent-318- und Terminal-320-Eigenschaften für das neu erzeugte Objekt 302 ein. Mit anderen Worten fordert der Ressourcenmanager 121 den Anwender 108 auf, anzuzeigen, ob das gerade erzeugte neue Objekt 302 aus einem Gruppenobjekt bestehen soll oder nicht, und wenn dies der Fall ist, ob das Gruppenobjekt transparent sein soll oder ein Terminalobjekt sein soll. Wenn, wie weiter oben erläutert wurde, ein Objekt durch einen Anwender 108 als Terminalobjekt angezeigt wird, werden die Aktionen, die durch den Anwender 108 an diesem Objekt vorgenommen werden, nicht auf den Kindobjekten durchgeführt, die hierarchisch unter dem Terminalgruppenobjekt liegen. Dies liefert einen Mechanismus für einen Anwender 108, ein Gruppenobjekt in der Objekthierarchie zu erzeugen, um beispielsweise Ressourcen zu kategorisieren. Wenn dann dieses Gruppenobjekt beispielsweise auf ein anderes Gruppenobjekt bezogen wird, auf das in einer gewissen Weise Einfluß genommen wird oder bearbeitet wird, so bleiben jegliche Kindobjekte, die von dem Gruppenobjekt abhängen (das heißt hierarchisch darunter in Beziehung liegen) und welches als Terminalobjekt markiert ist, durch solche Aktionen unbeeinflußt. Die Terminalgruppenobjekte bilden somit einen Sicherheitsmechanismus, durch den ein Anwender eine Repräsentation von Ressourcen innerhalb des graphischen Anwenderinterface 150 plazieren kann, ohne die Befürchtung haben zu müssen, daß er zufällig irgendwelche Aspekte solcher Ressourcen manipuliert, darauf einwirkt oder anderweitig ändert.
Fig. 7 zeigt ein Flußdiagramm von Prozeßschritten, die der Ressourcenmanager 121 gemäß einer Ausführungsform der Erfindung durchführt, um die Objekthierarchie 301 zu durchlaufen, um Repräsentationen von Objekten innerhalb eines graphischen Anwenderinterfaces 150 zu erzeugen.
Bei dem Schritt 470 beginnt der Ressourcenmanager 121 mit einem Objekthierarchie-301-Baumdurchlaufprozeß. Der Ressourcenmanager 121 kann irgendeinen Typen eines Baum- oder Zweigdurchlaufalgorithmus verwenden, um Information hinsichtlich jedes Objektes 302 innerhalb der Objekthierarchie 301 zu erhalten.
Als nächstes gibt der Ressourcenmanager 121 bei dem Schritt 471 eine Ausführungsschleife ein, die auf jedes Objekt 302 innerhalb der Objekthierarchie 301 angewendet wird.
Innerhalb der Schleife 471 erzeugt der Ressourcenmanager 121 bei dem Schritt 472 (z. B. in dem Speicher 112) eine Repräsentation des Objektes 302 (wobei das Objekt aus dem Baumdurchlaufprozeß erhalten wird) und schließt in die Repräsentation den einfachen Namen des Objektes 304 ein.
Als nächstes führt der Ressourcenmanager 121 die Schritte 473 bis 475 durch, um zu bestimmen, ob eine Heimbedingung für das Objekt 302 existiert.
Spezifischer gesagt, bestimmt der Ressourcenmanager 121 bei dem Schritt 473, ob die Objektstelle des Objektes 302 in der Objekthierarchie 301 das Heim 305 des Objektes ist. Mit anderen Worten prüft der Ressourcenmanager 121 bei dem Schritt 473 die momentane örtliche Lage des Objektes 302 in dem Baum (von dem Baumdurchlaufprozeß her) und vergleicht diesen Lagewert mit dem Heim des Objektes 305, wie dies innerhalb des Objektes 302 definiert oder festgelegt ist. Wenn diese gleich sind, schreitet der Prozeß zu dem Schritt 476 voran. Wenn jedoch die Lage innerhalb des Baumes nicht die gleiche ist wie das Heim 305 des Objektes 302, dann bedeutet dies, daß eine Repräsentation des Objektes außerhalb von dessen Heimkontext darzustellen ist, und die Verarbeitung schreitet zu dem Schritt 474 voran.
Bei dem Schritt 474 bestimmt der Ressourcenmanager 121, ob der einfache Name des Objektes 304 einzigartig in dem Nicht-Heimobjektkontext ist, in welchem diese Repräsentation darzustellen ist. Mit anderen Worten bestimmt der Ressourcenmanager 121, ob der einfache Name einzigartig in der hierarchischen Plazierung oder Örtlichkeit in Relation zu anderen Objekten in diesem gleichen Kontext oder hierarchischen örtlichen Lage ist. Dies kann beispielsweise dadurch geschehen, indem der einfach Name 304 innerhalb der einfachen Namen 304 von allen anderen Objekten 302 an dieser gleichen Stelle in der Objekthierarchie 301 verglichen wird. Wenn der einfache Name 304 nicht einzigartig ist, schreitet die Verarbeitung zu dem Schritt 475 voran.
Bei dem Schritt 475 hängt der Ressourcenmanager 121 das Heim des Objektes 305 an die Repräsentation des Objektes an (das heißt in Aufbewahrung oder Erinnerung in der Erwartung einer Darstellung), welches innerhalb des graphischen Anwenderinterfaces 150 dargestellt wird. Wenn auf diese Weise der Ressourcenmanager 121 eine Repräsentation eines Objektes 302 darstellt, die außerhalb ihres Heimkontextes liegt und deren einfacher Name 304 nicht einzigartig ist, so enthält dann die Repräsentation sowohl den einfachen Namen des Objektes 304 als auch das Heim des Objektes 305.
Nach der Verarbeitung von entweder dem Schritt 473 und möglicherweise dem Schritt 474 und dann ebenfalls möglicherweise des Schrittes 475 schreitet der Prozeß zu dem Schritt 476 voran.
Bei dem Schritt 476 bestimmt der Ressourcenmanager 121, ob das Heim des Objektes 305 einzigartig innerhalb der gesamten Objekthierarchie 301 ist. Mit anderen Worten bestimmt der Ressourcenmanager 121 bei dem Schritt 476, ob ein anderes Objekt 302 in der Ressourcenhierarchie 301 existiert, bei dem ein Heim für das andere Objekt in Betracht zu ziehen ist und welches den gleichen einfachen Namen wie der Name des Heimes 305 des Objektes 302 hat, welches gemäß dem Schritt in Fig. 7 verarbeitet wird. Beispielsweise erzeugt ein Datenspeichersystem, welches durch ein Heimobjekt 302 repräsentiert wird, und zwar mit einem einfachen Namen, der der gleiche ist wie ein einfacher Name eines Hostsystems oder einer Netzwerkvorrichtung, die durch ein anderes Objekt 302 repräsentiert wird, eine Situation, bei der zwei Ressourcen beide Heime in Verbindung mit anderen Ressourcen bilden und von denen jedes den gleichen einfachen Namen 304 hat. Da bei solchen Umständen jede Ressource ein Heim zu anderen Ressourcen bildet und den gleichen einfachen Namen trägt, existiert ein Heim, welches nicht einzigartig für die Objekte ist, die unter solchen Ressourcen in der Objekthierarchie 301 in einem Sinn liegen, daß zwei Heime für andere Ressourcen mit dem gleichen einfachen Namen existieren. Bei solchen Fällen schreitet die Verarbeitung des Ressourcenmanagers 121 zu dem Schritt 474 voran, um ein Suffix an das Heim des Objektes 305 anzuhängen, welches in der Schleife 471 verarbeitet wird. Wie oben bereits angegeben wurde, zeigt ein Suffix (wenn eine Darstellung an dem graphischen Anwenderinterface erfolgt) dem Anwender 108 an, daß es wenigstens zwei Heimressourcen mit dem gleichen Namen gibt.
Bei dem Schritt 477 hängt der Ressourcenmanager 121 ein Suffix an das Heim des Objektes 305 an und schließt das Heim des Objektes 305 in der Repräsentation des Objektes mit ein, welches in Einklang mit der Verarbeitung der Schleife 471 erzeugt wird. Das Suffix kann aus irgendeiner Zeichenfolge bestehen, einem Symbol oder einer anderen Bezeichnung, die einem Anwender anzeigen kann, daß dieses Heim nicht einzigartig in der Computersystemumgebung 100 ist.
Nach der Verarbeitung des Schrittes 476 und möglicherweise des Schritts 477 (wenn ein Suffix erforderlich ist) schreitet die Verarbeitung zu dem Schritt 478 voran, an welcher Stelle der Ressourcenmanager 121 eine Repräsentation des Objektes 302 in einem graphischen Anwenderinterface 150 an einer Stelle darstellt, die der Objektlage innerhalb der Objekthierarchie 301 entspricht. Auf diese Weise wird dann das Objekt 302 sichtbar an dem graphischen Anwenderinterface 150 dargestellt.
Die Verarbeitung kehrt dann zu dem Schritt 472 zurück, an welcher Stelle der Ressourcenmanager 121 den Baum durchläuft, um eine Repräsentation des nächsten Objektes 302 in der Objekthierarchie 301 zu verarbeiten und darzustellen, um eine Darstellung innerhalb des graphischen Anwenderinterfaces 150 zu bewirken. Unter Anwendung dieser Techniken sind die Ausführungsformen der Erfindung dazu befähigt, in richtiger Weise die Objekte mit Hilfe eines graphischen Anwenderinterfaces darzustellen, und zwar unter Verwendung von einmaligen Namensgebungs- und Gruppierungstechniken, die hier erläutert sind.
Fachleute können verstehen, daß viele andere Abwandlungen bei den Operationen der Ausführungsformen, die oben erläutert sind, vorgenommen werden können, wobei jedoch die gleichen Ziele der Erfindung erreicht werden. Solche Variationen und Abwandlungen sollen mit unter den Rahmen der Erfindung fallen. In diesem Zusammenhang ist die vorangegangene Beschreibung der Ausführungsformen der Erfindung nicht als einschränkend zu interpretieren. Vielmehr werden jegliche Einschränkungen der Ausführungsformen der Erfindung durch die folgenden Ansprüche gegeben.

Claims

1. Computersystem, mit:
einer Anzeige;
einem Speichersystem;
einem Prozessor; und
einem Verbindungsmechanismus, der die Anzeige, den Prozessor und das Speichersystem miteinander verbindet;
bei dem das Speichersystem mit einer Ressourcenmanagementanwendung kodiert ist, die dann, wenn sie auf dem Prozessor ausgeführt wird, einen Ressourcenmanagementprozeß erzeugt, der ein graphisches Anwenderinterface enthält, um eine Ressource in einer Computersystemumgebung an der Anzeige des Computersystems darzustellen, wobei der Ressourcenmanagementprozeß das Computersystem veranlaßt, die folgenden Operationen auszuführen:
Erzeugen eines Objektes in dem Speichersystem, um eine Ressource in der Computersystemumgebung wiederzugeben;
Zuordnen eines Objektidentifizierers zu dem Objekt in dem Speichersystem, wobei der Objektidentifizierer wenigstens einen einfachen Namen des Objektes und ein Heim des Objektes enthält;
Darstellen von wenigstens einer Repräsentation des Objektes an dem graphischen Anwenderinterface an der Anzeige des Computersystems, wobei jede der wenigstens einen Repräsentation des Objektes den einfachen Namen des Objektes enthält, und
bei dem dann, wenn eine Heimbedingung für eine der wenigstens einen Repräsentation des Objektes, welches an dem graphischen Anwenderinterface dargestellt wird, existiert, die Repräsentation der wenigstens einen Repräsentation des Objektes ferner das Heim des Objektes enthält, welches an dem graphischen Anwenderinterface dargestellt wird, und wenn eine Heimbedingung nicht existiert, die Wiedergabe der wenigstens einen Repräsentation des Objektes, die an dem graphischen Anwenderinterface dargestellt wird, kein Heim des Objektes enthält.

2. Computersystem nach Anspruch 1, bei dem dann, wenn der Ressourcenmanagementprozeß das Computersystem veranlaßt, die Operation gemäß dem Erzeugen eines Objektes durchzuführen, der Ressourcenmanagementprozeß das Computersystem veranlaßt, die folgenden Operationen auszuführen:
Zuordnen des Objektes zu wenigstens einer Lage oder Örtlichkeit innerhalb einer Objekthierarchie in dem Speichersystem in solcher Weise, daß das Objekt zu einem Kindobjekt von wenigstens einem Elternobjekt in der Objekthierarchie wird, wobei die Objekthierarchie die Beziehungen zwischen den Ressourcen in der Computersystemumgebung wiedergibt, die durch die Objekte in der Objekthierarchie in dem Speichersystem repräsentiert werden;
bei dem die wenigstens eine Lage oder Örtlichkeit, zu der das Objekt in der Objekthierarchie zugeordnet wird, eine Heimörtlichkeit enthält, die ein Heimobjekt in der Objekthierarchie identifiziert, unter der das Objekt anfänglich als ein Kindobjekt zugeordnet wurde, um dadurch einen Heimkontext für das Objekt festzulegen; und
bei dem der Schritt der Zuordnung des Objektidentifizierers auch die Zuordnung des Heimes des Objektes als die Heimörtlichkeit umfaßt, welche das Heimobjekt für dieses Objekt in der Objekthierarchie identifiziert.

3. Computersystem nach Anspruch 2, bei dem das Objekt aus einem Gruppenobjekt in dem Speichersystem besteht, welches zu dem Zweck erzeugt wird, um eine Vielzahl der in Beziehung gesetzten Ressourcen in der Computersystemumgebung zu repräsentieren, derart, daß Objekte in der Objekthierarchie unterhalb des Gruppenobjektes eine gemeinsame Beziehung zueinander teilen, die durch das Gruppenobjekt identifiziert wird.

4. Cornputersystem nach Anspruch 3, bei dem:
das Gruppenobjekt aus einem transparenten Gruppenobjekt besteht, welches ein Heim besitzt, das durch die Heimörtlichkeit eines ersten nichttransparenten Ahnen-Heimobjektes in der Objekthierarchie identifiziert wird, unter welcher das transparente Gruppenobjekt zu Beginn als ein absteigendes Kindobjekt zugeordnet wurde; und
bei dem die Objekte, die nachfolgend als Kindobjekte des transparenten Gruppenobjektes erzeugt werden, je ein jeweiliges Heim besitzen, welches durch die Heimörtlichkeit des ersten nichttransparenten Ahnen-Heimobjektes in der Objekthierarchie identifiziert wird, unter welcher das transparente Gruppenobjekt zu Beginn als ein absteigendes Kindobjekt zugeordnet wurde.

5. Computersystem nach Anspruch 3, bei dem:
das Gruppenobjekt aus einem Terminalgruppenobjekt mit einem Heim besteht, welches durch die Heimörtlichkeit eines Heimobjektes in der Objekthierarchie definiert ist, unter welcher das Terminalgruppenobjekt zu Beginn als ein Kindobjekt zugeordnet wurde; und
bei dem Objekte, die nachfolgend als Kindobjekte des Terminalgruppenobjektes erzeugt werden, je ein jeweiliges Heim aufweisen, welches durch die Heimörtlichkeit des Heimobjektes in der Objekthierarchie identifiziert wird, unter welchem das transparente Gruppenobjekt zu Beginn als ein Kindobjekt zugeordnet wurde.

6. Computersystem nach Anspruch 2, bei dem eine Vielzahl von Objekten in der Objekthierarchie dargestellt werden und bei dem die Beziehungen zwischen den Objekten, die in der Objekthierarchie repräsentiert werden, funktionelle Beziehungen und organisatorische Beziehungen zwischen bestimmten Objekten der Objekte enthalten, die in der Objekthierarchie dargestellt werden; und
bei dem dann, wenn der Ressourcenmanagementprozeß das Computersystem veranlaßt, die Operation der Darstellung von wenigstens einer Repräsentation des Objektes an einem graphischen Anwenderinterface vorzunehmen, der Ressourcenmanagementprozeß das Computersystem veranlaßt, die Operation der Darstellung der Objekthierarchie an dem graphischen Anwenderinterface vorzunehmen, um die funktionellen und organisatorischen Beziehungen zwischen den Ressourcen in der Computersystemumgebung darzubieten.

7. Computersystem nach Anspruch 6, bei dem:
die Vielzahl der Objekte, die in der Objekthierarchie dargestellt werden, Ressourcen in der Computersystemumgebung repräsentieren, inklusive Speichersystemressourcen, Computersystemressourcen und Speicherbereichsnetzwerkressourcen, die an das Computersystem gekoppelt sind und auf der Grundlage einer Kommunikation mit dem Ressourcenmanagementprozeß über ein Netzwerkinterface arbeiten;
bei dem ein Anwender des graphischen Anwenderinterfaces die Ressourcen managen kann, die dem Objekt in der Objekthierarchie zugeordnet werden, und zwar vermittels einer Auswahl von Repräsentationen des Objektes in der Objekthierarchie, die an dem graphischen Anwenderinterface dargestellt wird; und
bei dem alle Objekte, die eine Repräsentation in dem graphischen Anwenderinterface enthalten, einen einfachen Namen und ein Heim aufweisen, die kombiniert einen einzelnen Namensraum für alle Objekte in der Computersystemumgebung definieren, und zwar ungeachtet davon, was diese Objekte repräsentieren.

8. Computersystem nach Anspruch 2, bei dem der Ressourcenmanagementprozeß ferner das Computersystem veranlaßt, die folgenden Operationen durchzuführen:
Bewegen des Objektes zu einer neuen Heimlage in der Objekthierarchie in solcher Weise, daß das Objekt einen neuen Heimkontext erhält; und
Bestimmen, ob der einfache Name für das Objekt in einzigartiger Weise das Objekt in dem neuen Heimkontext für das Objekt in bezug auf ein anderes Objekt identifiziert, welches den gleichen Heimkontext aufweist, und, wenn der einfache Name für das Objekt nicht in einzigartiger Weise das Objekt in dem neuen Heimkontext für das Objekt identifiziert, der einfache Name geändert wird, um einen einzigartigen einfachen Namen für das Objekt in dem neuen Heimkontext vorzusehen.

9. Computersystem nach Anspruch 8, bei dem dann, wenn der Ressourcenmanagementprozeß das Computersystem veranlaßt, die Operation gemäß einer Änderung vorzunehmen, der Ressourcenmanagementprozeß das Computersystem veranlaßt, eine Operation gemäß einem Anhängen einer Suffix an das Ende des einfachen Namens des Objektes vorzunehmen, derart, daß dann der einfache Name in einzigartiger Weise das Objekt in dem neuen Heimkontext identifiziert.

10. Computersystem nach Anspruch 1, bei dem das Objekt an dem graphischen Anwenderinterface in einer voll qualifizierten Weise darstellbar ist, um einen spezifischen Fall der Ressource anzuzeigen, der diesem Objekt zugeordnet ist, indem das Objekt mit dem einfachen Namen des Objektes, gefolgt von dem Heim des Objektes, dargestellt wird.