DE69402540T2

DE69402540T2 - Rahmen-system für dokumente

Info

Publication number: DE69402540T2
Application number: DE69402540T
Authority: DE
Inventors: David Anderson; Jack Palevich; Larry Rosenstein; Arnold Schaeffer
Original assignee: Taligent Inc
Current assignee: Object Technology Licensing Corp
Priority date: 1993-06-04
Filing date: 1994-01-03
Publication date: 1997-11-13
Anticipated expiration: 2014-01-04
Also published as: CA2141932A1; US5524190A; EP0693197A1; DE69402540D1; EP0693197B1; CN1110065A; AU6391094A; WO1994029801A1; JPH08511116A

Description

Copyrighthinweis

Diese Patentanmeldung enthält urheberrechtlich geschütztes Material, dessen Reproduktion nur als Teil der Patentanmeldung zu informativen Zwecken gestattet ist. Alle anderen Rechte, insbesondere das Recht zur kommerziellen Verwertung derartigen Materials, sind vorbehalten.

Gebiet der Erfindung

Die vorliegende Erfindung betrifft im allgemeinen Verbesserungen bei Computersystemen und insbesondere ein System und ein Verfahren für ein Dokumentenverarbeitungssystem mit hoher Verfügbarkeit.

Hintergrund der Erfindung

Die Dokumentenverarbeitung ist gegenwärtig die vorherrschende Anwendung der Computertechnologie. Beispiele für die Textverarbeitungstechnologie des Standes der Technik umfassen die Wordperfect Textverarbeitung und die Word Textverarbeitung der Microsoft Corporation. Diese Produkte sind so konstruiert, daß sie auf verschiedenen Betriebssystemen und unterschiedlichen Hardwareplattformen lauffähig sind. Einige der Hardwareplattformen und Betriebssysteme sind weniger zuverlässig als andere. Um einen Verlust von Daten oder anderen Informationen zu vermeiden, besitzen diese Produkte eine Sicherungseigenschaft, welche bei der Einstellung des Systems aktiviert werden kann. Die Sicherung erfolgt, wenn eine vom Anwender festgelegte Zeit verstrichen ist, sofern ein Anwender die Eigenschaft aktiviert. Wenn im System zwischen den Sicherungen ein Defekt auftritt, kommt es zu einem Verlust jener Informationen, die seit der letzten Sicherung neu eingegeben wurden. Auf ähnliche Weise steht diese Sicherungseigenschaft für Datenbank-, Grafik- und Bildanwendungen oder andere Computeranwendungen zur Verfügung. Somit kann jeder zwischen zwei Sicherungen auftretende Defekt für Computeranwendungen kostspielige Folgen haben.
Das Technische Offenbarungsbulletin von IBM, Vol 33, Nr. 12, Seiten 304-305 (Mai 1991), offenbart ein Werkzeug, mit dessen Hilfe ein Smalltalk-Programmierer rasch und einfach einen Bildabsturz reparieren kann. Smalltalk/V verwendet eine als "Änderungsaufzeichnungsdatei" bezeichnete Datei, welche den Quellcode der Methoden enthält, die der Anwender im Laufe seiner Arbeit erstellt oder modifiziert hat. Diese Datei wird als Bestandteil des Umgebungsbildes betrachtet, welche insbesondere all das enthält, was der Anwender eingetippt hat. Diese Änderungen umfassen die Erstellung oder Modifizierung eines Verfahrens, das Löschen eines Verfahrens, die Erstellung oder Modifizierung einer Klasse und das Löschen einer Klasse sowie einer Historie des gesamten Smalltalk-Codes, den der Anwender explizit beim Testen seiner Anwendung ausgeführt hat.
Während der Anwender die Umgebung modifiziert, werden die Änderungsaufzeichnungsdatei und der Klassenhierarchiedurchsucher dynamisch mit den Änderungen, die der Anwender durchgeführt hat, aktualisiert. Jede Änderung wird an das Ende der Änderungsaufzeichnungsdatei angehängt. Bei einem Systemabsturz muß der Anwender die Umgebung neu starten, die Änderungsaufzeichnungsdatei bearbeiten und manuell alle Änderungen extrahieren, die durchgeführt wurden, seit das Bild das letzte Mal gespeichert wurde. Dies ist sowohl mühsam als auch zeitaufwendig, und oft sind auch viele redundante Daten in den Änderungen enthalten, wie zum Beispiel ein Verfahren, das der Anwender mehrmals geändert hat, bis er mit den Änderungen zufrieden war. Die Änderungsaufzeichnungsdatei kann im Laufe der Entwicklung sehr groß werden.
Die in der Referenz dargebotene Lösung ist ein Zusatz zur objektorientierten Umgebung eines neuen, als "ungesicherte Änderungen" bezeichneten, Verfahrens, welches jene Stelle in der Änderungsaufzeichnungsdatei speichert, wo das "Bild speichern" zuletzt durchgeführt wurde. Alle nach dem letzten Sichern durchgeführten Änderungen in der Umgebung werden wie zuvor immer noch an die Aufzeichnungsdatei angehängt. Wenn es jedoch zu einem Absturz kommt, werden nur die Änderungen von der gespeicherten Position bis zum Zustand unmittelbar vor dem Absturz durch Ausführung dieses Verfahrens rasch in die Umgebung gebracht, und danach wird der Inhalt des darüberliegenden Fensters eingefügt. Da nur die letzten Änderungen geladen werden, erhöht sich die Ladegeschwindigkeit wesentlich. Das Einfügen dieser Änderungen stellt die objektorientierte Umgebung rasch wieder in jenen Zustand her, der unmittelbar vor dem Absturz vorhanden war, und ermöglicht es dem Smalltalk-Anwender, mit der Fehlerbeseitigung und anderen Programmierarbeiten fortzusetzen.
Software Practice & Experience, Vol 17, Nr. 11, Seite 813-845 (November 1987), offenbart einen interaktiven Texteditor für mehrere Dateien, der für Bitmap-Darstellungen gedacht ist. Eine textliche Befehlssprache ergänzt die mausgesteuerte Ausschneiden-und-Einfügen-Schnittstelle, um komplexe oder sich wiederholende Bearbeitungsaufgaben leichter durchführbar zu machen. Die Sprache ist gekennzeichnet durch die Zusammensetzung regulärer Ausdrücke zur Beschreibung der Struktur des zu modifizierenden Textes. Die Behandlung von Dateien als Datenbank mit Änderungen, die als atomare Transaktionen aufgezeichnet werden, leitet die Implementierung und erzeugt geradewegs einen allgemeinen "Rückgängigmachen"-Mechanismus. Sam wird als zwei Prozesse implementiert, die durch einen Strom mit geringer Bandbreite verbunden sind, wobei ein Prozeß für die Anzeige verantwortlich ist und der andere für die Bearbeitungsalgorithmen. Daher kann es mit dem Anzeigeprozeß in einem Bitmap-Terminal laufen und der Editor auf einem lokalen Host, mit beiden Prozessen auf einem Bitmap-Terminal und dem Editor auf einem lokalen Host, mit beiden Prozessen auf einem mit Bitmap ausgestatteten Host, oder mit dem Anzeigeprozeß im Terminal und dem Editor in einem Remote Host. Durch Unterdrückung des Anzeigeprozesses kann es sogar ohne Bitmap-Terminal laufen. Das System verwendet einen Cache, der sich im Speicher des Computers befindet.
Sam verwaltet Dateiänderungen für Dateien mit variabler Länge, wobei es einen Algorithmus mit zwei Durchläufen für die Durchführung von Änderungen verwendet und jede Datei als eine Datenbank behandelt, für welche Transaktionen registriert werden. Änderungen werden nicht am Inhalt direkt vorgenommen. Stattdessen wird, wenn ein Befehl gestartet wird, eine "Markierung", welche eine Folgenummer enthält, in den Transkriptpuffer gestellt, und jede an der Datei durchgeführte Änderung, sei es eine Einfügung oder eine Löschung oder eine Änderung am Dateinamen, wird an das Ende des Transkripts angehängt. Wenn der Befehl fertig ausgeführt ist, wird der Transkript zur Markierung zurückgespult und am Inhalt angewandt. Sam bietet keine Möglichkeit, eine Rückgängigmachung rückgängig zu machen. Jede Markierung im Transkript enthält eine Folgenummer und einen Relativzeiger in das Transkript der vorhergehenden Markierung, um das Abspulen des Transkripts zu unterstützen.
Das VIERTE JÄHRLICHE SYMPOSIUM ÜBER ANWENDERSCHNITT- STELLENSOFTWARE UND TECHNOLOGIE, 11. November 1991, US, Seite 107-115, H. Wang & M. Green, "Ein Ereignisobjekt- Wiederherstellungsmodell für objektorientierte Anwenderschnittstellen", diskutiert ein Ereigniswiederherstellungsmodell für eine objektorientierte Anwendung. Der in diesem Dokument befürwortete Ansatz trennt traditionelle Historien- und Befehlslisten in Pro-Objekt-Listen auf, welche gut in die objektorientierte Struktur passen. Einzigartige Merkmale dieses Rahmenwerks sind die hierarchische Struktur der lokalen Wiederherstellungsobjekte, welche die Anwendungsstruktur reflektieren, seine einfache Semantik und seine einfache Implementierung, welche es dem Schnittstellenersteller wesentlich erleichtern, es in bestehende objektorientierte Anwenderschnittstellenstrukturen zu integrieren. Keines der Bezugsdokumente lehrt ein Befehlsobjektaufzeichnungssystem zur Wiederherstellung von Dokumenten oder anderen Einheiten in einer objektorientierten Umgebung.

Zusammenfassung der Erfindung

Demgemäß ist es eine Hauptaufgabe der vorliegenden Erfindung gemäß den Ansprüchen, ein System und ein Verfahren zur automatischen Sicherung eines Dokumentes durch Anwendung objektorientierter Technologie an die Dokumentenverarbeitung zu schaffen. Das System sichert Änderungen eines Dokumentes automatisch als Befehlsobjekte, die in einem nichtflüchtigen Speicher aufgezeichnet werden. Danach wendet das System im Falle eines Stromausfalles oder eines anderen Problems die Änderungsobjekte in der Reihenfolge an, in denen sie in der Aufzeichnung gesichert wurden, um das Dokument oder ein anderes Anwendungsbild wiederherzustellen.

Kurze Beschreibung der Zeichnungen

Figur 1 ist ein Blockdiagramm eines Personalcomputersystems gemäß einer bevorzugten Ausführungsform;
Figur 2A & 2B sind Flußdiagramme, welche die Verarbeitung darstellen, die gemäß einer bevorzugten Ausführungsform durchgeführt wird;
Figur 3 ist ein Flußdiagramm, welches die Verarbeitung gemäß einer bevorzugten Ausführungsform darstellt, welche durchgeführt wird, wenn ein Dokument wiederhergestellt wird;
Figur 4 ist ein Flußdiagramm, welches die Logik zeigt, die mit dem Sichern eines Dokumentes gemäß einer bevorzugten Ausführungsform in Zusammenhang steht.

Genaue Beschreibung der Erfindung

Die Erfindung wird vorzugsweise in Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel einem IBM PS/2 oder einem Apple Macintosh Computer, befindet. Eine repräsentative Hardwareumgebung wird in Figur 1 dargestellt, welche eine typische Hardwarekonfiguration einer Workstation gemäß der vorliegenden Erfindung darstellt und eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, mit einem eingebauten nicht-flüchtigen Speicher 11 und eine Anzahl anderer Einheiten umfaßt, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1 dargestellte Workstation umfaßt einen Direktzugriffsspeicher (RAM) 14, einen Nur-Lese-Speicher (ROM) 16, einen E/A- Adapter 18 zum Anschluß von Peripheriegeräten, wie zum Beispiel einer Festplatteneinheit 20, und einer Disketteneinheit 21 am Bus, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 20, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus, einen Kommunikationsadapter 34 zum Anschluß der Workstation an einem datenverarbeitenden Netzwerk und einen Anzeigenadapter 36 für den Anschluß eines Anzeigegerätes 30 am Bus. Typischerweise befindet sich auf der Workstation ein Betriebssystems, wie zum Beispiel das Betriebssystem IBM OS/2 Betriebssystem oder das Apple System/7 -Betriebssystem.
In einer bevorzugten Ausführungsform wird die Erfindung in der Programmiersprache C++ mit Hilfe von objektorientierten Programmiertechniken implementiert. Ein Fachmann wird verstehen, daß es sich bei objektorientierten Programmierobjekten (OOP-Objekte) um Softwareeinheiten handelt, welche Datenstrukturen umfassen, sowie Operationen, die auf die Daten wirken. Gemeinsam werden Objekte durch die Elemente dazu befähigt, nahezu jede Echtwelteinheit bezüglich deren Eigenschaften, welche durch deren Datenelemente dargestellt werden, zu modellieren, und deren Verhalten wird durch deren Datenmanipulationsfunktionen dargestellt. Auf diese Weise können Objekte konkrete Dinge, wie zum Beispiel Personen und Computer, modellieren, und sie können abstrakte Konzepte, wie zum Beispiel Zahlen oder geometrische Konzepte, modellieren. Die Vorteile der Objekttechnologie ergeben sich aus drei Grundprinzipien: Einkapselung, Polymorphismus und Vererbung.
Objekte verstecken die internen Strukturen ihrer Daten und die Algorithmen, nach denen ihre Funktionen arbeiten, bzw. kapseln diese ein. Anstatt diese Implementierungsdetails offenzulegen, präsentieren Objekte Schnittstellen, welche deren Abstraktionen säuberlich ohne unwesentliche Informationen darstellen. Polymorphismus ist eine weitere Stufe der Einkapselung. Der Gedanke, der dahintersteckt, ist: viele Formen, eine Schnittstelle. Eine Softwarekomponente kann eine Anforderung an eine andere Komponente stellen, ohne genau zu wissen, worum es sich bei dieser Komponente handelt. Die Komponente, welche die Anforderung erhält, interpretiert diese und berechnet aufgrund ihrer Variablen und Daten, wie die Anforderung auszuführen sei. Das dritte Prinzip ist die Vererbung, welche es Entwicklern ermöglicht, bereits bestehende Konstruktionen und Codes wieder zu verwenden. Durch diese Fähigkeit müssen Entwickler eine Software nicht immer von Grund auf neu erstellen. Stattdessen können Entwickler durch die Vererbung Subklassen ableiten, welche die Verhaltensweisen erben, die dann vom Entwickler den jeweiligen besonderen Anforderungen angepaßt werden.
Ein Ansatz des Standes der Technik besteht darin, Objekte und Klassenbibliotheken in einer Prozedurumgebung zu schichten. Viele am Markt befindliche Anwendungsrahmenwerke verwenden diesen Konstruktionsansatz. In dieser Konstruktion befinden sich ein oder mehrere Objektschichten an der Spitze eines monolithischen Betriebssystems. Wenngleich dieser Ansatz alle Prinzipien der Einkapselung, des Polymorphismus und der Vererbung in der Objektschicht verwendet und eine wesentliche Verbesserung gegenüber den Prozedurprogrammiertechniken darstellt, weist dieser Ansatz auch gewisse Einschränkungen auf. Diese Probleme ergeben sich aus der Tatsache, daß es für einen Entwickler zwar einfach ist, seine eigenen Objekte wiederzuverwenden, aber schwierig ist, Objekte aus anderen Systemen zu verwenden, und der Entwickler daher immer noch gezwungen ist, mit prozeduralen Betriebssystemaufrufen (OS-Aufrufe) in tiefere Nichtobjekt-Schichten einzugreifen.
Ein weiterer Aspekt des objektorientierten Programmierens ist ein Rahmenwerkansatz für die Anwendungsentwicklung. Eine der besten Definitionen für Rahmenwerke stammt von Ralph E. Johnson von der Universität von Illinois und Vincent F. Russo von Purdue. In ihrem 1991 veröffentlichten Papier mit dem Titel Wiederverwendung von objektorientierten Designs, technischer Bericht UIUCDCS91- 1696 von der Universität in Illinois, bieten sie folgende Definition an: "Eine abstrakte Klasse ist eine Konstruktion einer Reihe von Objekten, welche zusammenarbeiten, um eine Reihe von Pflichten auszuüben. Somit stellt ein Rahmenwerk eine Reihe von Objektklassen dar, welche zusammenarbeiten, um festgelegte Gruppen von Berechnungspflichten auszuführen." Vom Standpunkt des Programmierens her betrachtet handelt es sich bei Rahmenwerken im wesentlichen um Gruppen miteinander verbundener Objektklassen, welche eine vorgefertigte Struktur einer Arbeitsanwendung bieten. So könnte zum Beispiel ein Anwenderschnittstellenrahmenwerk die Unterstützung und das "Standard"-Verhalten zum Zeichnen von Fenstern, Rollbalken, Menüs usw. bieten. Da Rahmenwerke auf Objekttechnologie basieren, kann dieses Verhalten vererbt und außer Kraft gesetzt werden, damit Entwickler das Rahmenwerk erweitern und maßgeschneiderte Lösungen auf einem speziellen Wissensgebiet erstellen können. Dies ist ein wichtiger Vorteil gegenüber der herkömmlichen Programmierung, da der Programmierer nicht den ursprünglichen Code verändert, sondern stattdessen die Software erweitert. Darüberhinaus arbeiten sich Entwickler nicht blind durch Schichten von Codes hindurch, weil das Rahmenwerk eine strukturelle Führung und Modellierung bietet, zur selben Zeit aber auch den Entwickler befreit, um dann die spezifischen Maßnahmen, die für den jeweiligen Problembereich einzigartig sind, treffen zu können.
Von einer geschäftlichen Perspektive aus betrachtet können Rahmenwerke als eine Möglichkeit angesehen werden, Expertenwissen in einem bestimmten Wissensbereich einzukapseln oder aufzunehmen. Firmeneigene Entwicklungsorganisationen, Unabhängige Softwareverkäufer (ISV) und Systemintegratoren haben Fachwissen in bestimmten Bereichen erworben, wie zum Beispiel bei der Herstellung, Buchhaltung oder bei Währungsumwandlungen. Dieses Fachwissen wird in ihren Code aufgenommen. Rahmenwerke ermöglichen es diesen Entwicklungsorganisationen, die allgemeinen Merkmale dieses Fachwissens durch Aufnahme in den Code der Organisation festzulegen und zu verpacken. Zum ersten erhalten Entwickler dadurch die Möglichkeit, eine Anwendung, welche das Fachwissen verwendet, zu erstellen oder zu erweitern, wodurch das Problem einmal gelöst wird und die Geschäftsregeln und die Konstruktion verstärkt und auf konsistente Weise angewendet werden. Ebenso sind Rahmenwerke und das in den Rahmenwerken steckende Fachwissen auch von strategischem Wert für jene Organisationen, die sich Fachwissen in vertikalen Märkten erarbeitet haben, wie zum Beispiel in der Fertigung, der Buchhaltung oder der Biotechnologie, und somit einen Verteilungsmechanismus für die Verpackung, den Wiederverkauf und die Ausnutzung ihres Fachwissens und den weiteren Fortschritt und die Ausbreitung der Technologie gefunden haben.
Historisch gesehen haben sich die Rahmenwerke erst in jüngster Zeit als ein Hauptströmungskonzept auf Computerplattformen entwickelt. Diese Migration wurde durch die Verfügbarkeit objektorientierter Sprachen wie zum Beispiel C++ unterstützt. Traditionellerweise wurde C++ am häufigsten auf UNIX-Systemen und den Workstations von Forschern verwendet, und kaum auf Computern in kommerziellen Umgebungen. Sprachen wie C++ und andere objektorientierte Sprachen, wie zum Beispiel Smalltalk und andere, haben einer Reihe von Universitäts- und Forschungsprojekten geholfen, die Vorläufer der heutigen kommerziellen Rahmenwerke und Klassenbibliotheken zu schaffen. Einige Beispiele dafür wären Interviews von der Stanford-Universität, der Andrew- Befehlssatz von der Carnegie-Mellon Universität und das ET++-Rahmenwerk von der Zürich-Universität.
Es gibt, je nach Niveau des Systems und der Art des Problems, viele Arten von Rahmenwerken. Die Arten der Rahmenwerke reichen von Anwendungsrahmenwerken, die bei der Entwicklung von Anwenderschnittstellen helfen, bis hin zu Rahmenwerken niedrigerer Ebene, welche grundlegende Systemsoftwaredienste wie zum Beispiel Kommunikation, Drukken, Ablagesystemunterstützung, Graphik usw. bieten. Kommerzielle Beispiele von Anwendungsrahmenwerken sind MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTStep App Kit (NEXT), und Smalltalk-80 MVC (ParcPlace)
Das Programmieren mit Rahmenwerken erfordert von den Entwicklern, die an andere Systemarten gewöhnt sind, eine neue Art des Denkens. Tatsächlich handelt es sich hierbei nicht mehr um das "Programmieren" im herkömmlichen Sinn. In älteren Betriebssystemen, wie zum Beispiel in DOS oder UNIX, schafft das eigene Programm des Entwicklers die gesamte Struktur. Das Betriebssystem bietet Dienstleistungen durch Systemaufrufe - das Programm des Entwicklers führt diese Aufrufe durch, wenn es die Dienstleistung benötigt, und die Kontrolle kehrt wieder zurück, nachdem die Dienstleistung zur Verfügung gestellt wurde. Die Programmstruktur basiert auf der Flußkontrolle, welche im Code enthalten ist, den der Entwickler schreibt.
Wenn Rahmenwerke verwendet werden, ist dies genau umgekehrt. Der Entwickler ist nicht mehr für die Flußkontrolle verantwortlich. Der Entwickler muß auf die Tendenz verzichten, die Programmieraufgaben in bezug auf den Fluß der Ausführung verstehen zu wollen. Stattdessen muß sich das Denken auf die Verantwortlichkeiten der Objekte richten, welche sich auf das Rahmenwerk verlassen müssen, um zu bestimmen, wann die Tasks ausgeführt werden sollten. Vom Entwickler geschriebene Routinen werden von einem Code aktiviert, den der Entwickler nicht geschrieben hat, und den der Entwickler niemals sieht. Dieser Flipflop-Vorgang im Kontrollfluß kann eine wesentliche psychologische Barriere für Entwickler darstellen, die nur über Erfahrungen im prozeduralen Programmieren verfügen. Wenn dies jedoch einmal begriffen wird, erfordert das Rahmenwerk-Programmieren wesentlich weniger Aufwand als andere Arten des Programmierens.
Ähnlich wie ein Anwendungsrahmenwerk dem Entwickler vorgefertigte Funktionalität bietet, übertragen Systemrahmenwerke, wie zum Beispiel jenes, das in einer bevorzugten Ausführungsform enthalten ist, dasselbe Konzept, indem sie Dienstleistungen auf Systemebene bieten, welche Entwickler, wie zum Beispiel Systemprogrammierer, verwenden, um Unterklassen zu bilden bzw. außer Kraft zu setzen, um maßgeschneiderte Lösungen zu schaffen. Man stelle sich zum Beispiel ein Multimedia-Rahmenwerk vor, welches die Grundlage für die Unterstützung von neuen und unterschiedlichen Geräten, wie zum Beispiel Audio, Video, MIDI, Animationen usw., bieten sollte. Der Entwickler, der eine neue Art von Gerät unterstützen soll, müßte einen Gerätetreiber schreiben. Um dies mit einem Rahmenwerk durchzuführen, muß der Entwickler nur die Eigenschaften und das Verhalten unterstützen, welches dem neuen Gerät eigentümlich ist.
Der Entwickler bietet in diesem Fall eine Implementierung für bestimmte Mitgliederfunktionen, die vom Multimedia-Rahmenwerk aufgerufen werden. Ein unmittelbarer Vorteil für den Entwickler ist die Tatsache, daß der generische Code, der für die einzelnen Gerätekategorien benötigt wird, bereits vom Multimedia-Rahmenwerk zur Verfügung gestellt wird. Dies bedeutet, daß der Entwickler des Gerätetreibers weniger Code schreiben, testen und weniger Fehler beseitigen muß. Ein weiteres Beispiel für die Anwendung des Systemrahmenwerkes wären getrennte E/A-Rahmenwerke für SCSI- Geräte, NuBus-Karten und graphische Geräte. Weil es in diesem Zusammenhang eine vererbte Funktionalität gibt, bietet jedes einzelne Rahmenwerk Unterstützung für allgemeine Funktionalitäten, die in seiner Gerätekategone enthalten sind. Andere Entwickler könnten dann von diesen konsistenten Schnittstellen zu allen Arten von Geräten Gebrauch machen.
Eine bevorzugte Ausführungsform übernimmt das Konzept der Rahmenwerke und wendet dieses im gesamten System an. Für den kommerziellen oder firmeninternen Entwickler, den Systemintegrator oder OEM bedeutet dies, daß all die Vorteile, die für ein Rahmenwerk, wie zum Beispiel MacApp, dargestellt wurden, nicht nur auf die Anwendungsebene für solche Dinge wie Text und Anwenderschnittstellen übertragen werden können, sondern auch auf die Systemebene, für Dienstleistungen wie zum Beispiel Graphiken, Multimedia, Dateisysteme, E/A, Testdurchführung usw.
Die Anwendungserstellung in der Architektur einer bevorzugten Ausführungsform ist im wesentlichen gleich wie das Schreiben bereichsspezifischer Puzzleteilchen, die dem Rahmenwerkprotokoll unterstellt sind. Auf diese Weise ändert sich das gesamte Konzept des Programmierens. Anstelle des Schreibens einer Codezeile nach der anderen, welche mehrfache API-Hierarchien aufrufen, wird Software nunmehr entwickelt, indem Klassen von bereits bestehenden Rahmenwerken innerhalb dieser Umgebung abgeleitet werden, und indem danach je nach Bedarf neues Verhalten hinzugefügt und/oder vererbtes Verhalten außer Kraft gesetzt wird.
Somit wird die Anwendung des Entwicklers zu einer Sammlung von Code, der geschrieben und von allen anderen Rahmenwerkanwendungen gleichermaßen benutzt wird. Dies stellt ein sehr mächtiges Konzept dar, weil Entwickler dadurch in der Lage sind, auf der Arbeit anderer aufzubauen. Dies gibt dem Entwickler auch die Flexibilität, ein Programm je nach Bedarf mehr oder weniger maßzuschneidern. Manche Rahmenwerke werden genau so verwendet werden, wie sie sind. In manchen Fällen wird das Ausmaß der maßgeschneiderten Anpassung minimal sein, so daß das Puzzleteilchen, das der Entwickler einfügt, ein kleines ist. In anderen Fällen kann der Entwickler sehr großzügige Veränderungen durchführen und etwas völlig neues schaffen. In einer bevorzugten Ausführungsform, wie sie in Figur 1 dargestellt ist, ist ein Programm, das sich im RAM 14 befindet und der Kontrolle der CPU 10 unterliegt, für die Verwaltung verschiedener Tasks unter Verwendung eines objektorientierten Dokumentenrahmenwerks verantwortlich.
Andere Systeme, wie zum Beispiel das Apple Macintosh System 7, verwenden ein Modell, welches vom Anwender verlangt, daß er ein Dokument explizit sichert. Bei diesen Systemen öffnet der Anwender ein Dokument, führt einige Änderungen durch, und sichert das Dokument. Für gewöhnlich ersetzt die neue Version des Dokumentes die ältere, wenngleich manche Anwendungen eine oder mehrere zuvor gesicherte Versionen behalten.
Bis der Anwender die Sicherung durchführen läßt, existieren die Änderungen nur innerhalb der Anwendung. Wenn die Anwendung oder das System abstürzt, gehen diese Änderungen verloren. Manche Anwendungen sichern Teile ihrer Daten auf Festplatte, und der Anwender mag in der Lage sein, einiges aus diesen Festplattendateien wiederherzustellen. Manche Anwendungen (z.B. Quicken und HyperCard am Macintosh) führen jedesmal auf wirksame Weise eine automatische Sicherung durch, wenn der Anwender etwas ändert. Dieses Verarbeitungsverfahren verhindert, daß der Anwender seine Arbeit aufgrund eines Absturzes verliert, aber der Anwender kann seine Arbeit aufgrund einer ungewollten Änderung verlieren. Andere Anwendungen zeichnen Prüfpunktdaten eines Dokumentes in einer separaten Datei auf, wenn der Anwender Seiten wechselt. Dies verhindert, daß der Anwender seine Arbeit auf anderen Seiten verliert, aber es verhindert nicht, daß er seine Arbeit auf der aktiven Seite verliert.

Sicherungsloses Modell

Eine bevorzugte Ausführungsform zeichnet Prüfpunktdaten bei jeder Änderung des Dokumentes auf und zeichnet diese auf Festplatte auf. Im Falle eines Absturzes startet das System mit der zuletzt "gesicherten" Version und wiederholt alle Änderungen, die der Anwender durchgeführt hat, im Abgleich mit der Kopie. Das sich daraus ergebende Dokument ist identisch mit jenem Dokument, welches der Anwender zum Zeitpunkt des Absturzes hatte. Tatsächlich sichert das System automatisch ein gespeichertes Bild und eine Befehlsaufzeichnung. Das gespeicherte Bild zeichnet den Zustand des gesamten Dokumentes zu einem bestimmten Zeitpunkt auf, und die Befehlsaufzeichnung zeichnet alle Änderungen auf, die am Dokument seit diesem Zeitpunkt durchgeführt wurden.
Wenn der Anwender das Dokument bearbeitet, ist der allgemeine Programmablauf wie folgt:
Jedesmal, wenn ein Anwender eine Änderung am Dokument durchführt, wird eine Kopie des Befehlsobjektes, welches die Änderung darstellt, an das Ende einer Schlange gestellt.
Ein separater Hintergrundtask nimmt die Befehlsobjekte aus der Schlange und sichert diese in der Befehlsaufzeichnung. Dieser Task wird mit niedrigerer Priorität ausgeführt, um die Ausführung dieser Maßnahme zu ermöglichen, wenn der Anwender nicht mit dem System interagiert, um die Auswirkungen auf die Produktivität des Anwenders so gering wie möglich zu halten.
Das Befehlsobjekt wird normal verarbeitet, um das Dokument zu ändern.
Figur 2 ist ein Flußdiagramm, welches die Verarbeitung darstellt, die in Übereinstimmung mit einer bevorzugten Ausführungsform ausgeführt wird. Die Verarbeitung beginnt am Punkt 200 und geht sofort zum Funktionsblock 210 weiter, um ein Dokument durch Laden des Dokumentes von einer Festplatte oder einem anderen Speichergerät zu öffnen. Ein Dokument könnte Text-, Grafik-, Bild-, Audio- oder andere Informationen enthalten. Der Entscheidungsblock 220 erkennt Änderungen, wenn sie am Dokument durchgeführt werden. Danach wird für jede am Dokument durchgeführte Änderung ein Befehlsobjekt erstellt und an das Ende einer Schlange im Speicher gestellt, wie dies im Funktionsblock 230 dargestellt ist. Schließlich ist ein Hintergrund-Task, der im Funktionsblock 230 dargestellt ist, dafür verantwortlich, die Aufzeichnung in einem nichtflüchtigen Speicher basierend auf den in der Schlange stehenden Objekten zu erstellen.
Wenn ein Anwender ein Dokument öffnet, kommt es zu folgender Verarbeitung:
Das gespeicherte Bild des Dokuments wird von einer Festplatte, einem Cache oder einem anderen Speicher geladen.
Wenn die Befehlsaufzeichnung nicht leer ist, werden die in der Aufzeichnung enthaltenen Befehle wiederum abgespielt.
Figur 3 ist ein Flußdiagramm, welches die Verarbeitung darstellt, die ausgeführt wird, wenn ein Dokument in Übereinstimmung mit einer bevorzugten Ausführungsform wiederhergestellt wird. Die Verarbeitung beginnt am Punkt 300 und geht sofort zum Funktionsblock 310 weiter, um ein gesichertes Dokument von einer Festplatte, einem Festplattencache oder einem anderen Speicher zu laden. Am Entscheidungsblock wird danach eine Entscheidung durchgeführt, um zu bestimmen, ob die Befehlsaufzeichnung leer ist. Wenn dies der Fall ist, ist das Dokument vollständig, und die Kontrolle wird zum Punkt 350 zurückgegeben. Wenn dies nicht der Fall ist, werden die in der Aufzeichnung gesicherten Befehle der Reihe nach wiederum abgespielt und am Dokument angewandt, wie dies im Funktionsblock 330 dargestellt ist, die Befehlsaufzeichnung wird beim Funktionsblock 340 gelöscht und die Kontrolle wird zum Punkt 350 zurückgegeben.
Zu bestimmten Zeitpunkten wird das Dokument gesichert:
Gesamtes Dokument im gesicherten Bild sichern.
Befehlsaufzeichnung löschen.
Figur 4 ist ein Flußdiagramm, welches die Logik darstellt, die mit dem Sichern eines Dokumentes in Übereinstimmung mit einer bevorzugten Ausführungsform in Zusammenhang steht. Die Verarbeitung beginnt am Punkt 400 und geht sofort zum Funktionsblock 410 weiter, um das Dokument zu sichern. Danach wird die Befehlsaufzeichnung am Funktionsblock 420 gelöscht, und die Kontrolle kehrt zum Punkt 430 zurück. Diese Verarbeitung kann auf Anforderung eines Anwenders, zu einer vom Anwender vorherbestimmten Zeit oder automatisch ausgeführt werden, wenn ein Dokument geschlossen wird.
Die Ablagearchitektur definiert eine abstrakte Modellsicherung, welche sowohl das gesicherte Bild als auch eine Befehlsaufzeichnung enthält. Ein Dokument besteht aus einer Gruppe von separaten Modellobjekten, auf welche die Modellsicherung Zugriff bietet. Die Modellobjekte umfassen ein Dokumentenbild auf der Ebene der einzelnen Modelle. Typischerweise wird die Modellsicherung auf Festplatte gespeichert, aber ein Fachmann kann leicht erkennen, daß sich die Modellsicherung auch im Speicher, im Cache oder auf anderen Speichermedien befinden kann.

Claims

1. Eine Einrichtung zur Änderung von Dokument-Daten, die ein Originaldokument darstellen, in Abhängigkeit von Öffnungs-, Änderungs- und Sicherungskommandos eines Benutzers, und worin die in einem Speicher residenten Dokument-Daten auch Objekte umfassen, die Änderungen im Zustand der Dokument-Daten während ihrer Verarbeitung wiedergeben, gekennzeichnet durch:

(a) Mittel (210) für ein Öffnungskommando eines Benutzers zum Kopieren der Daten aus dem Originaldokument in einen Arbeitsbereich;

(b) Mittel (220, 230), die auf jedes Änderungskommando eines Benutzers ansprechen zur Erzeugung eines Kommandoobjekts, das Kommandodaten zur Identifizierung eines Datenteils des Originaldokuments und Kommandomethoden zur Änderung des Datenteils des Originaldokuments enthält;

(c) Mittel (240), die auf jedes Kommandoobjekt ansprechen für die Ausführung von Kommandomethoden in jedem Kommandoobjekt zur Änderung Datenteils des Originaldokuments im Arbeitsbereich, um einen modifizierten Datenteil des Dokuments im Arbeitsbereich zu erzeugen;

(d) Mittel (270), die auf jedes Änderungskommando ansprechen zur Speicherung des erzeugten Kommandoobjekts im Speicher;

(e) Mittel (330), die auf jedes Sicherungskommando eines Benutzers ansprechen zum Überschreiben der Daten des Originaldokuments im Speicher mit den modifizierten Dokument-Daten im Arbeitsbereich; und

(f) Mittel (340), die auf ein Überschreiben der Daten des Originaldokuments ansprechen zum Löschen von Kommandoobjekten im Speicher.

2. Die Einrichtung nach Anspruch 1, worin das Kommandoobjekt Kommandomethoden zum Rückgängigmachen enthält, die mit dem abgeänderten Datenteil ausgeführt werden zur Rückführung des modifizierten Datenteils in den ursprünglichen Datenteil.

3. Die Einrichtung nach Anspruch 1, worin das Kommandoobjekt Kommandomethoden zur erneuten Ausführung enthält, die mit dem ursprünglichen Datenteil ausgeführt werden zur Wiederherstellung des modifizierten Datenteils.

4. Die Einrichtung nach Anspruch 1, die weiterhin ein Modellobjekt aufweist, welches das Originaldokument und einen Logbereich zur Speicherung der Kommandoobjekte enthält.

5. Die Einrichtung nach Anspruch 1, worin die Daten des Dokuments Text-, Graphik-, Bild- oder Audioinformation enthalten.

6. Ein Verfahren zur Änderung von Dokument-Daten, die ein Originaldokument darstellen, in Abhängigkeit von Öffnungs-, Änderungs- und Sicherungskommandos eines Benutzers, und worin die in einem Speicher residenten Dokument-Daten auch Objekten umfassen, die Änderungen im Zustand der Dokument-Daten während ihrer Verarbeitung wiedergeben, gekennzeichnet durch:

(a) Kopieren der Daten aus dem Originaldokument in einen Arbeitsbereich als Antwort auf ein Öffnungskommando eines Benutzers (210);

(b) Erzeugen eines Kommandoobjektes, das Kommandodaten zur Identifizierung eines Datenteils des Originaldokuments und Kommandomethoden zur Änderung des Datenteils des Originaldokuments enthält, als Antwort auf jedes Änderungskommando eines Benutzers (220, 230);

(c) Ausführen von Kommandomethoden in jedem Kommandoobjekt zur Änderung Datenteils des Originaldokuments im Arbeitsbereich, um einen modifizierten Datenteil des Dokuments im Arbeitsbereich zu erzeugen als Antwort auf jedes Kommandoobjekt (240);

(d) Speichern des erzeugten Kommandoobjekts im Speicher als Antwort auf jedes Änderungskommando (270);

(e) Überschreiben der Daten des Originaldokuments im Speicher mit den modifizierten Dokument-Daten im Arbeitsbereich als Antwort auf jedes Sicherungskommando eines Benutzers (330); und

(f) Löschen von Kommandoobjekten im Speicher als Antwort auf ein Überschreiben der Daten des Originaldokuments (340).

7. Das Verfahren nach Anspruch 6, worin Schritt (b) den Schritt enthält:

(bl) Erzeugen eines Kommandoobjekts, das Kommandomethoden zum Rückgängigmachen enthält, die mit dem abgeänderten Datenteil ausgeführt werden zur Rückführung des modifizierten Datenteils in den ursprünglichen Datenteil.

8. Das Verfahren nach Anspruch 6, worin Schritt (b) den Schritt enthält:

(b2) Erzeugen Kommandoobjekts, das Kommandomethoden zur erneuten Ausführung enthält, die mit dem ursprünglichen Datenteil ausgeführt werden zur Wiederherstellung des modifizierlen Datenteils.

9. Das Verfahren nach Anspruch 6, das weiterhin den Schritt enthält:

(g) Erzeugen eines Modellobjekts, welches das Originaldokument und einen Logbereich zur Speicherung der Kommandoobjekte enthält.