DE102004051956A1 - Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten - Google Patents

Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten Download PDF

Info

Publication number
DE102004051956A1
DE102004051956A1 DE102004051956A DE102004051956A DE102004051956A1 DE 102004051956 A1 DE102004051956 A1 DE 102004051956A1 DE 102004051956 A DE102004051956 A DE 102004051956A DE 102004051956 A DE102004051956 A DE 102004051956A DE 102004051956 A1 DE102004051956 A1 DE 102004051956A1
Authority
DE
Germany
Prior art keywords
window
file
files
presentation
search
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102004051956A
Other languages
English (en)
Inventor
Ute Bevier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Priority to DE102004051956A priority Critical patent/DE102004051956A1/de
Publication of DE102004051956A1 publication Critical patent/DE102004051956A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Vorrichtung und Verfahren zur generalisierten Darstellung von in Dateien gespeicherten Inhalten, wobei als Vorrichtung ein objektorientiertes Fenster (Windows) dient. DOLLAR A Die in Sofwaresystemen eingesetzten Fenster (Bestandteil der graphischen Oberfläche von Software) zur Darstellung von Datensätzen besitzen abhängig vom Aufbau des Dateisystems unterschiedliche Anordnungen. Für jede Datei muss also ein eigenes Fenster programmiert/aus Komponenten erstellt, getestet, gewartet und im Falle verteilter Anwendungen auch über das Netzwerk verschickt werden. DOLLAR A Durch eine strenge Zerlegung der vom Fenster durchzuführenden Aktionen in system/kommunikations-, anwender-, datei- und fensterspezifische Arbeiten, die Verlegung fensterfremder Tätigkeiten in die jeweiligen Systeme sowie die strikte Beschränkung auf Schnittstellen bei Verwendung solcher Funktionalität wird erreicht, dass das Fenster nur noch Verhalten ausübt, das unabhängig von den Dateien ist, und genügt damit modernen Ansprüchen einer abgekapselten, selbstständig ausführbaren Funktionalität ("Service"). DOLLAR A Das Universalfenster eignet sich für alle Standard-Aufgaben in Software-Systemen, die der Suche, Anzeige und Verwaltung von Datei-Inhalten dienen.

Description

  • 1. Technisches Gebiet
  • Die vorliegende Erfindung bezieht sich auf die grundlegende Architektur von moderner Software in Form von objektorientierten Dialogsystemen, insbesondere auf die wesentliche Schnittstelle zwischen Benutzer und gespeicherten Daten: das so genannte Fenster (Window).
  • Im Zuge der Verbreitung des Internet und daraus folgend der über das Internet angebotenen eigenständigen Software-Module (Webservices) folgt die Software-Entwicklung immer stärker dem aktuellen Trend der Hardware-Entwicklung hin zur Grid-Technologie: eigenständige, „intelligente" Einheiten werden über Steuerelemente verschiedener Hierarchieebenen zu großen Netzwerken zusammengekoppelt. Damit ein solches Geflecht für die jeweiligen Benutzer, ob Mensch oder Maschine, als einheitliches System erscheint, müssen die jeweiligen Steuerungsebenen die darunter liegenden Einzelkomponenten „virtualisieren": Sie müssen sie in ihren wesentlichen Funktionalitäten und Daten abbilden können. Dies verlangt notwendig, dass diese Einheiten Standards erfüllen, die für diese Abbildung und die dadurch ermöglichte Automatisierung als Repräsentationselement dienen können. Solche Grid-Systeme haben nicht nur den Vorteil, flexibel hinsichtlich ihrer Größe da sein, da einzelne Elemente hinzugefügt oder entfernt werden können (Stichwort: On Demand), sie sind zumeist auch kostengünstiger, da standardisierte Komponenten typischerweise preisgünstiger sind als individuelle. Im Software-Bereich werden Grid-Systeme durch die moderne Architektur der SOA (service oriented architecture) realisiert, bei der üblicherweise, aber nicht notwendigerweise die zugrunde liegenden Einzelkomponenten Webservices sind, deren hohe Standardisierung durch die Vielfalt des Internet an Hard- und Software- sowie Betriebssystemen in den unterschiedlichsten Versionen erzwungen wurde.
  • Wie bereits erwähnt, funktioniert Virtualisierung über Standards und Standards ihrerseits sind die Typisierung von Problemen („Verwertete Information: Wissen und Intelligenz – Virtualisierung und Automatisierung", Schriftenreihe „Definition der Information, Länge der Information, Metrik", bussole IV): Die zu programmierenden (automatisierenden) Elemente, ob Chips, Server, Daten-Transaktionen, zu kompilierender Programmcode, Geschäftsprozesse oder sogar Hochöfen, werden nach wesentlichen Merkmalen gruppiert und können deshalb hinsichtlich dieser Merkmale einheitlich behandelt werden. Dadurch erreicht das System zweierlei: Erstens wird die Komplexität gesenkt, da nicht jeder Einzelfall in allen maßgeblichen Details einzeln behandelt werden muss und zweitens wird es möglich, neue Einzelfälle desselben Typs auch dann zu berücksichtigen, wenn seine individuellen Elemente, also diejenigen Merkmale, die nicht vom Typ erfasst sind und in denen er sich von anderen Einzelfällen desselben Typs unterscheidet, noch nicht vollständig bekannt sind.
  • Die standardisierten Merkmale sind dabei nicht nur bestimmte Werte, die diese Typen aufweisen, sondern auch ihr einheitliches Verhalten. In der Programmierung werden diese Standards oft auch Metadaten, Modell, Profil/Richtlinien, Struktur/Prinzip oder Schnittstelle genannt, wobei das daraus resultierende „Abbildungsnetz", das „über relevante Untersuchungsbereiche geworfen" wird (Patent DE 19831651 C1 , S. 7), als Trennschicht dient, um die ausführende Logik von der spezifischen Behandlung des Einzelfalls zu separieren. Das ist die grundlegende Technik von Java (JVM Java Virtual Machine), so arbeitet ein kürzlich in den Medien vorgestelltes Produkt zur Software-Konvertierung von einer Plattform auf eine andere („QuickTransit" von Alasdair Rawsthorne, CW 38/2004, S. 4, "Start-up erklärt Softwareportierung für überflüssig") und es ist letztendlich der Grundsatz des „Verbergens" der Objektorientierung selbst, die Objekte nur über ihre Schnittstellen zugänglich macht, während die internen Einzelheiten ohne Belang sind. Diese Typisierung kann jedoch auf verschiedenen Abstraktionsebenen erfolgen und geht in letzter Zeit auch in der Software-Konstruktion immer stärker vom einzelnen Objekt hin zum gesamten zu modellierenden System. Dies erhöht die Automatisierbarkeit, was die gesamte Programmierung flexibler und fehlerfreier macht, und wird deshalb auf allen Ebenen verstärkt realisiert: Patent DE 69404439 T2 , S. 7, Patent DE 69530252 T2 , S. 3 ([0012]], Patent DE 69627522 T2 , S. 17 ([0151]-[0153]), Patentanmeldung DE 10206903 A1 / DE 10206902 A1 , 3.
  • Virtualisierung als Strategie von Informationsverarbeitungen betrifft jedoch nicht nur die Abbildung von informationstechnologischen Systemen wie Hard- und Software, sondern auch Systeme, die betriebswirtschaftliche Probleme modellieren (Patentanmeldung DE 10307544 A1 ) oder maschinelle Anlagen verwalten wie die Patentanmeldung DE 10306273 A1 . In letzterem wird für die Modellierung einer hüttentechnischen Anlage mit ihren Hochöfen und den so genannten Medienströmen wie Eisenerz oder Energie dasselbe Verfahren verwendet wie in der Softwarekonstruktion: die typisierte Abbildung der beteiligten Elemente in Art und Verhalten durch Metadaten, die hier „Strukturparameter" genannt werden. Diese Ähnlichkeit liegt in der Natur der Information begründet, physikalische Wirkung mit der speziellen Eigenschaft der Identifizierbarkeit und Wiederholbarkeit zu sein, sodass jeder regelmäßige Prozess diese Anforderung erfüllt, ob dies nun ein Material- oder Energiestrom ist. Solange aus eindeutigen Anfangszuständen immer wieder dieselben eindeutigen Endzustände folgen, liegt deshalb Information vor, unabhängig von der Art der Zustände oder Wirkung, die diese Zustände verändert ( DE 10306273 A1 , S. 2, [0001]).
  • Information schafft somit die Verbindung zwischen Naturkräften und „geordneten Zuständen", da Ordnung ein Ausschlussprinzip ist und insofern immer einen „Auswahlmechanismus" voraussetzt: Dieser Mechanismus ist das Prinzip der geringsten Wirkung („Physik der Information", Bevier F.F., bussole Verlag, ISBN 3-935031-03-3, S. 87,199). Geordnete Zustände lassen sich dann umgekehrt immer als Schnittstellen zwischen den einzelnen Stadien des regelmäßigen Prozesses behandeln, wodurch Kontrolle über Wirkungsketten und damit über Verhalten ermöglicht wird. Schnittstellen sind deshalb eine Form von „Checkpoints" für ein dynamisches System.
  • 2.1. Stand der Technik hinsichtlich der verwendeten Methodik
  • Da die ML-Methode (http://www.dixi.bussole.de/ML.pdf) zwar recht unbekannt, als Konstruktions- und Vermessungsmittel für die Beschreibung der Erfindung jedoch von zentraler Bedeutung ist, wird die gewerbliche Nutzbarkeit ihres Kernelements, einen „wegeoptimierten Baumgraphen aus verbalen Vorgaben" zu erzeugen, durch Praxisbeispiele demonstriert.
  • Information ist als Menge der wiederholbaren, zusammenhängenden Wertveränderungen einer einfachen oder mehrdimensionalen Eigenschaft nichts anderes als geordnete, durch Zustände und ihre wohldefinierte Anordnung abbildbare Prozesse: identifizierbare, regelmäßige Wirkung (Regelwerk). Zustände werden in der Praxis der Informationstechnologie deshalb immer in irgendeiner Darstellungsform modelliert, die eine genau festgelegte Reihenfolge von Zustandsänderungen ermöglichen wie die Zustandsautomaten der Modellierungssprache UML (Unified Modeling Language), die in Patentanmeldung DE 19712946 A1 beschriebene Darstellung von Arbeitsprozessen (Workflow) über Aktivitätsnetze oder die bekannten Petri-Netze. Letztere sind als gerichtete Graphen von Zuständen und Ereignissen (Transitionen) faktisch eine Realisierung der Definition der Information als Wertveränderung, da jeder Zustand durch mindestens ein Ereignis aufgehoben (beendet) und/oder durch mindestens ein Ereignis eingeleitet (realisiert) wird („Petri-Netze", Bernd Rosenstengel, Udo Winand, Vieweg Verlag, ISBN 3-528-33582-3, S. 8).
  • Auch die von den Patent(anmeldung)en DE 69404439 T2 und DE 10206903 A1 / DE 10206902 A1 demonstrierte Priorität der Verknüpfung vor dem einzelnen Objekt weist auf die Akzeptanz der Praxis gegenüber der physikalischen Natur der Information als Wirkung hin, die sich nicht über den einzelnen Zustand (Knoten, Objekt) abbilden lässt, sondern nur über die wohlstrukturierte Anordnung von Zuständen.
  • Da jede Problemlösung eine Abbildung des jeweiligen Problembereiches darstellt, bilden effiziente Lösungsverfahren für das gesamte System diesen Problembereich häufig über strukturierte Netze (Graphen) gegenseitiger Wechselwirkungen ab, die aus Wiederverwendungs- und Wartbarkeitsgründen die Verknüpfungen zwischen den Netzknoten (Kopplung, Kommunikation) zu minimieren suchen: Dies erfolgt in der Modellierung von Teilsystemen oft über ein steuerndes Verbindungselement, das die Wirkungsketten zwischen den zu verbindenden Teilsystemen sammelt und dadurch an einer Stelle (Schnittstelle) bündelt. Beispiele dafür sind in der Modellierung das Entwicklungsmuster (Design Pattern) Facade, in derjüngeren Java-Programmierung die SDOs (Service Data Objects), in Patent DE 69627522 T2 das Konstrukt des „Datenobjektes" oder in Patentanmeldung DE 10205793 A1 dasjenige des „Kommunikationsobjektes".
  • Die von diesen Patenten demonstrierte Minimierung von Verknüpfungen (Grundsatz der losen Kopplung) entspricht der Minimierung von Längen in der ML-Methode, die die optimale Struktur eines solchen Wirkungsnetzes gemäß dem Prinzip der geringsten Wirkung dadurch zu bestimmen sucht, dass der durchschnittliche Abstand der Netzknoten minimiert wird durch geeignete Strukturierung der Arbeitsteilung von Objekten, die zur Ausführung der gewünschten Funktionen fähig sind. Dabei verwendet sie die wesentliche Eigenschaft der Arbeitsteilung in informationsverarbeitenden Systemen, dass an Systemgrenzen die Kommunikationsdichte (Informationsaustausch) stark absinkt und deshalb die Zahl von Wirkungsketten gegenüber dem internen (Sub)Systembereich erheblich geringer ist. Eine geschickte Wahl der Objektgestaltung unter Berücksichtigung der Häufigkeit von Wechselwirkungen (Messages) kann deshalb das Systemaufkommen an Aufwand, das für die Informationsverarbeitung erforderlich ist, deutlich absenken, wie die oben angeführten Beispiele eines steuernden Verbindungselementes nahe legen. (Patent DE 69627522 T2 „Auswirkungen der Kopplung..", S. 9 ff und „Objektspaghetti", S. 17 ([0151]) sowie der bereits früh angeführte Zusammenhang von Steigerung der Effizienz mit Absenkung von Querverbindungen in Patent DE 69404439 T2 , S. 8) Die von der ML-Methode geforderte Dreiecksanordnung, die sich in Baumstrukturen niederschlägt, findet sich besonders deutlich dargestellt in Patentanmeldung DE 10206903 A1 / DE 10206902 A1 , die das dort beschriebene konfigurierbare Softwaresystem über eine Ablauflogik handhabt, die als Baumstrukturen ausgearbeitet sind (S. 2). Der Unterschied der ML zu dem in dieser Anmeldung beschriebenen System liegt in der größeren Strenge der ML, da beliebige Referenzen und Verzweigungen bei der ML nicht erlaubt sind, um das Minimum der erforderlichen Verknüpfungen zu erhalten. Diese Beliebigkeit ist insoweit auch nicht erforderlich, da das Minimum immer noch zusammenhängend ist, das heißt, dass jedes Element des Systems mit jedem anderen in Verbindung treten kann, um seine Funktionalität zu nutzen.
  • Die Praktikabilität der Baumstruktur für die Softwarearchitektur wird neben der oben erwähnten Patentanmeldung ebenso durch die älteren Patente DE 69404439 T2 zur Programmmodellierung, DE 69530252 T2 zur Transaktionssteuerung auf Betriebssystemebene und DE 69622078 T2 über die Gestaltung des Problembereichs als Szenario demonstriert.
  • Auch die analytische Verwendung von Worten für die Systemkonstruktion ist nicht neu: in Patent DE 19831651 C1 wird die Bedeutung von so genannten Themenworten für den Systementwurf betont (S. 3, mit Literaturverweis) und in der Patentanmeldung DE 10330054 A1 sind Thesauri sogar die zentrale Einrichtung, um aus Dokumenten und Beschreibungen eine Sammlung von Informationen aus Worten (Hinweisworte, Schlüsselworte) und deren Verknüpfungen (S. 3) zu erzeugen, die zur Modellierung der betriebswirtschaftlichen Prozesse dient.
  • 2.2. Stand der Technik hinsichtlich der Voraussetzungen für ein Universalfenster
  • Das in dieser Erfindung vorgestellte Universalfenster betrachtet den Prozess der Präsentation von Dateninhalten über eine graphische Benutzerschnittstelle (GUI) nicht primär als abhängig von den Dateninhalten selbst, sondern als einen Typ von Aufgaben zur Darstellung, der weitaus stärker von den Bedingungen des ausführenden Systems sowie den Forderungen der Anwender abhängt als von den Individualitäten einer spezifischen Dateistruktur. Ein solches Fenster stellt somit die konsequente Anwendung der Virtualisierungsstrategie für einen Typ von Präsentationsfunktionen dar und benötigt deshalb als Voraussetzung ein System, das die Bedingungen der Virtualisierung von umfassender Metadaten-Verfügbarkeit und hoher Prozesspräzision liefert. Letzteres bedeutet, dass Funktionalitäten von Subsystemen (Komponenten) nicht direkt von angebundenen Programmen verwendet werden, sondern nur über die von dem jeweiligen Subsystem angebotene Schnittstelle (Stichwort „Facade"). Schnittstellenorientierung bedeutet weiterhin, dass vielfach benötigte Funktionen einfach aufzufinden sein sollen, also immer vom oder über das System und seine Subsysteme angeboten werden müssen. Nur innerhalb eines Subsystems können verfügbare Methoden direkt benutzt werden.
  • Der Grund für diese strenge Vorgehensweise liegt darin, dass die Verwendung von Funktionen immer eine Kopplung bedeutet (Information: die Endzustände werden durch die Anfangzustände sowie die ausgeführten Regeln determiniert). Da in der Realisierung eines Programms eine Schnittstelle eine wohldefinierte Menge von Variablen und Methoden ist, muss jedes verwendende Programm diese Menge oder eine Teilmenge davon exakt kennen, um sie nutzen zu können. Erfolgen Änderungen, die nicht nur Ergänzungen sind, muss jedes verwendende Programm diese Änderungen berücksichtigen, um selbst wieder korrekt zu funktionieren.
  • Um hier Einheitlichkeit zu gewährleisten, dürfen diese Änderungen deshalb nur von einer einzigen Stelle ausgehen und diese Stelle muss zentral zugänglich sein. Nur dies ermöglicht eine flexible Anbindung von Komponenten, die sich in diesem Fall jeweils nur an einer einzigen Stelle über die zur Verfügung stehenden Funktionalitäten und deren Umfang orientieren müssen. Im anderen Fall wären alle angebundenen Komponenten gezwungen, immer alle übrigen angebundenen Komponenten nach deren Schnittstellenverzeichnissen zu durchforsten und sie auf Änderungen zu überprüfen („Spaghetti").
  • Im Detail ist Voraussetzung für ein Universalfenster eine serviceorientierte Architektur (SOA) mit sicherem Kommunikationssystem, soll heißen dass Ereignissteuerung, dynamisches Routing (flexibles Auffinden der maßgeblichen Objekte eines Befehls) und die Gewährleistung der Befehlsausführung (transactional guaranteed delivery) vorhanden sind sowie geeignete Sicherheitsfunktionen (wie Fehleraufspürung, Firewall, Virenprüfung, Verschlüsselung). Des Weiteren müssen die Benutzertunktionalitäten abgekapselt in der Architektur angeboten werden wie einerseits Lokalisierung (Sprache und Text, Datumsaufbereitung und Kalenderfunktionen etc.) und andererseits Berechtigung (Rollenabhängigkeit, Zugangskontrolle). Darüber hinaus stellt eine solche Architektur Dienste zur Verfügung, mit denen auf Ressourcen (wie Peripheriegeräte) zugegriffen werden kann (Drucken, Suchen in Dateien aller Art, Export/Import, Änderungsdienste wie Protokollierung, Archivierung, Beschlagwortung, Wiedervorlage, Terminierungen/Kalenderfunktionen und die jeweiligen Plausibilitäten), deren Benutzung ebenfalls mit Berechtigungen verknüpft werden kann.
  • Diese Architektur bietet somit wohldefinierte Schnittstellen (inklusive globaler Variablen) für Kommunikation, Benutzer (Layout, Berechtigung), Ressourcen (Zugriff, Berechtigungssystem, individuelle Methoden) und übergreifende Funktionen (System-Bibliotheken), deren Ausführung sie unter den gegebenen Sicherheitsbedingungen selbständig gewährleistet.
  • Damit sichert sie die Möglichkeit zu, Dienste (Services) und Ressourcen beliebig an die Architektur ankoppeln zu lassen, soweit sie die angebotenen Schnittstellen verarbeiten können.
  • Eine solche modulare Infrastruktur wurde bereits 1999 in einem experimentellen Kernel für allgemeine Datenbankaufgaben realisiert (Basis des Realisierungsbeispiels), der bereits Programm-Aktualisierungen über Datei-Import durchführen konnte („Nicht für Jedermann", Bevier F.F., bussole Verlag, ISBN 3-935031-01-7, S. 82): ein Vorteil, der später in Patentanmeldung DE 10206903 A1 / DE 10206902 A1 besonders betont wird (S. 2, [0010] bzw. [0009]).
  • Noch früher wird eine ähnlich strukturierte Kommunikationsinfrastruktur in Patent DE 19617381 C2 beschrieben, obwohl die dort angesprochene Realisierung aus dem Bereich der Netzwerktechnologie stammt, während der für das Universalfenster vorausgesetzte Aufbau der Systemumgebung über die ML-Methode ermittelt wurde. Auch die moderne Entwicklung des ESB-Java-Frameworks (Enterprise Service Bus) verwendet eine solche modulare Interaktionsbasis und offeriert dadurch ein geeignetes fundamentales System für serviceorientierte Architekturen, das dynamisches Routing, Ereignissteuerung und die Gewährleistung der Ausführung von Befehlen zur Verfügung stellt sowie ein Dateisystem (intelligent data fabric), das Daten über ein Puffersystem (Cache) handhabt mit der Fähigkeit, sie auch auf dem Datenspeicher zu pflegen. Letztendlich dient ein solches Basissystem dann Geschäftsprozessen (ebenfalls Services), die mehr oder weniger unabhängig voneinander die serviceorientierte Architektur vervollständigen. Als weiteres Beispiel ähnlicher Modularisierung einer zentralen Infrastruktur kann diejenige der Patentanmeldungen DE 10206902 A1 / DE 10206903 A1 dienen, doch die bekannteste Anwendung dürfte die Entwicklungsumgebung „Eclipse" sein, deren Funktionalität ausschließlich über so genannte Plug-Ins (Komponenten, Services, Subsysteme) gestellt wird.
  • 2.3. Stand der Technik in Fensterprogrammierung
  • Auch in der Fensterprogrammierung ist der Trend zur Virtualisierung, das heißt zu schnittstellengeprägter Programmierung, zu erkennen. Besonders die Modellierungsstrategie des MVC (Model-View-Controller) zerlegt Präsentationsaufgaben längst in anwenderabhängige und anwenderunabhängige Aufgabenbereiche, die durch Steuerungselemente gekoppelt werden. Weiterhin werden in Entwicklungsumgebungen oder Generatorsystemen, die aus abstrakten Modellen sowie vorgefertigten Mustern für Detaillösungen Software erstellen können (wie MDA: model driven architecture), häufig bereits komplexe Fensterelemente als Bausteine der Programmierung angeboten, sodass durch einfache Auswahl, zumeist per Mausklick (Drag & Drop), und Spezifizierung von Parametern ein individuelles Fenster erstellt werden kann. In Patent DE 19831651 C1 und Patentanmeldung DE 10205793 A1 werden solche Software-Erstellungssysteme beschrieben, die anhand von Mustern, Agenten/Kommunikationsobjekten und Metadaten hinsichtlich der Zusammenarbeit derselben in einer Mehrschichten-Architektur funktionieren und deshalb auch Fenster-Mustervorlagen bearbeiten können.
  • Bisher werden Verarbeitungsfenster für Datensätze jedoch immer nur als Einzelfälle programmiert, abhängig von den Datenstrukturen und den individuellen Prüfungen und Präsentationen, die für die spezifischen Dateien gültig sind. Die Standardisierung der Präsentationsaufgaben findet nur auf der Ebene von Fensterkomponenten statt wie Kontrollknöpfe (Buttons), Listenfelder oder Optionsfenster (verändern das Aussehen des Fensters je nach ausgewählter Option: Registerkarten, „Reiterfenster", „Tabpanes"). Über diese Verwendung von Komponenten hinaus wird eine Vereinheitlichung von Fensterprogrammierung durch Templates (Muster) oder Vererbung erreicht, wobei die dem Typ der Präsentationsaufgaben entsprechenden Eigenschaften und Verhaltensweisen in diversen Hierarchien der Abhängigkeit abgebildet werden.
  • Die auf Systemebene erreichte Automatisierung der gesamten Verarbeitung, die als Grid-, serviceorientierte oder Virtualisierungs-Architektur inzwischen technisch nutzbar zur Verfügung steht, wird dagegen noch nicht für die jeweilige Ausgestaltung von vollständigen Fenstern (Windows) verwendet, um den dadurch ermöglichten Grad an Flexibilisierung, Wartungs- und Fehlerfreiheit zu erreichen.
  • 3. Probleme
  • Die Probleme einer individuellen Fensterprogrammierung sind dieselben wie die jeglicher Individualprogrammierung: „die Neuerfindung des Rades". Statt die Gleichartigkeit eines Prozesses auszunutzen, müssen ähnliche Fälle immer wieder neu in Angriff genommen werden, entweder von Grund auf neu programmiert mit all den unvermeidlichen Fehlerquellen oder von vergleichbaren Fällen kopiert, wobei Kopierfehler ebenfalls nicht verhindert werden können. Der beste Fall (Muster, Templates, Vererbung) ist dabei nichts anderes als die Veredelung des Kopiervorganges, da die individuellen Elemente, die eingefügt oder geändert werden müssen, klar gekennzeichnet sind.
  • Für jeden der Einzelfälle wird jedoch immer noch ein eigener Präsentationsprozess kodiert, der nicht nur erstellt und getestet, sondern auch bei Veränderungen berücksichtigt werden muss, was erneut eine Fehlerquelle darstellt, da bei der Vielzahl der gleichartigen Fälle leicht eine durchzuführende Aktualisierung übersehen werden kann. Zusammen mit dem Problem des „Aufschaukelns" kann dies zu Störungen führen, die absolut vermeidbar wären, wobei „Aufschaukeln" das Phänomen ist, dass Fehler in Hierarchien besonders schädlich sind, wenn sie auf einer niedrigen Ebene der Hierarchie stattfinden und sich somit durch die Folgeebenen hindurch „vererben". Dies ist im Zuge der Kopiervorgänge von Templates/Mustern/Vererbung umso ungünstiger, in je mehr Stufen diese Kopiervorgänge erfolgen, bis das gewünschte Endergebnis erreicht ist. Da Fenster durch die Kombination von System-, Anwender- und Dateiaufgaben häufig besonders komplex sind, werden sie freilich oft in vielen Kopierhierarchien erstellt, um die Wiederverwendbarkeit bereits programmierter Elemente zu sichern. Damit sind Fenster besonders anfällig für dieses Problem des „Aufschaukelns".
  • Fenster sind als zentrale Schnittstelle zu den Anwendern darüber hinaus ein besonders auffälliges Merkmal jeglicher Software. Ihre Funktionalität in Umfang und Komfort einerseits, sowie Fehleranfälligkeit andererseits bestimmt in hohem Maße den Eindruck, den Anwender von einer Software haben. Somit können kleine Mängel bereits viel Schaden anrichten in einem Bereich von Software, der oft unterschätzt wird: der Kommunikation der Anwender mit den Software-Erstellern.
  • 4. Aufgabe der Erfindung
  • Liegen tatsächlich Einzelfälle vor, so ist die Individualprogrammierung die einzig mögliche Vorgehensweise. Doch gerade die Virtualisierungstendenz in der gesamten Automatisierung und Programmierung zeigt deutlich, dass die Masse der Fälle in jedem Aufgabengebiet (80:20-Regel) typisierbar sind und dass überall dort, wo Typisierbarkeit vorliegt, dadurch wesentliche Verbesserungen sowohl in der Qualitätssicherung des Produkts als auch in seiner Kostenstruktur erreicht werden konnten.
    •
  • Aufgabe der Erfindung ist es deshalb, die Virtualisierung, die bereits auf der Ebene der Infrastruktur erfolgte, durch die Konstruktion eines Fensters zu unterstützen, dass die Gleichartigkeit der Präsentationsaufgaben bei der Darstellung von Inhalten (Dateien) ausnutzt, sodass statt einer Vielzahl ähnlicher Programmobjekte nur noch ein einziges Programmobjekt berücksichtigt werden muss. Dies ist nicht nur für die serviceorientierte Architektur von Vorteil, weil sie nicht mehr viele einzelne Präsentationsobjekte für Dateien verwalten muss, sondern nur noch eines, das über den Parameter „Datei" für die Aufgabe individualisiert werden kann. Es hat auch Vorteile bei der Entwicklung, beispielsweise einer MDA, weil statt einer Vielzahl von Komponenten für die Fenstergestaltung im Falle von Präsentationen von Dateien nur noch das eine Fenster mit den erforderlichen Schnittstellen zur Umsetzung der Modellierung erforderlich ist.
  • Besonders für Web-Applikationen ist dies interessant, da es bedeutet, dass die Darstellung von Fenstern (hier Browsern) weniger Kommunikation erfordert, die über das Internet zu erfolgen hat.
  • Zuletzt ist ein solches Universalfenster bedienerfreundlich, da es sich nicht nur ähnlich den vergleichbaren Fenstern verhält, sondern tatsächlich identisch ist. Anwender brauchen die jeweilige Problematik der Datei nicht mehr zu kennen, um mit einem solchen Fenster trotzdem umgehen zu können, da alle dateiunabhängigen Elemente identisch sind und die dateiabhängigen Elemente immer über dieselben Schnittstellen zur Verfügung gestellt werden, die somit nicht nur die Funktionalität offerieren, sondern diese darüber hinaus deutlich dokumentieren.
    •
  • 5. Beschreibung der Erfindung
  • Ein Universalfenster für die Repräsentation von in Dateien gespeicherten Inhalten bietet zuerst die Möglichkeit, diese Inhalte zu suchen und das Ergebnis benutzer- und inhaltgerecht unter Berücksichtigung von Systemvorgaben zu repräsentieren und bei Bedarf weiterzuleiten (an die Datenbank, an Drucker, an Exporteinheiten oder andere Services). Weiterhin sind die Ergebnisse nach Berechtigungsvorgabe verwaltbar, wobei die durchgeführten Änderungen auf Plausibilität geprüft werden. Inhalts-individuelle Verfahrensweisen werden ebenfalls angeboten und erforderlichenfalls zur Ausführung gebracht. Im Gegensatz zu bisherigen Fenstern, die diese Anforderungen ebenfalls erfüllen, kann dieses Fenster jedoch nicht nur einen spezifischen Fall von Inhalten bewältigen, sondern beliebig viele.
  • Und im Gegensatz zur Browsertechnologie, die (ohne Ergänzungen wie Javascript oder Plug-Ins) ebenfalls beliebig viele verschiedene Inhalte präsentieren kann, ist es bereits mit problemspezifischem Verhalten ausgerüstet, mit dem es einen ganzen Typ von Aufgaben verwalten kann, ohne zusätzliche Ergänzungen zu erfordern.
  • 5.1. Beschreibung der Erfindung aus Aufgabensicht
    • 1) Das Universalfenster für in Dateien gespeicherte Inhalte, kurz Fenster genannt, muss als Erstes aufrufbar sein, d.h. es muss leicht und einfach zu finden und zu aktivieren sein. Dies erfolgt üblicherweise durch einen Eintrag in ein Menü, oft auch eine Toolbar (externes Kontrollpaneel, zumeist über Icons verwendbar), von dem aus die Anwender das Fenster aufrufen können.
  • Fensterrelevanz: Menüs und Toolbars, die das Fenster aufrufen können, müssen vom System gestellt werden, da dieses das Fenster zur Aktivierung anbieten und kennen muss. Das bedeutet, dass diese Menüs und Toolbars nicht zu denen gehören, die umgekehrt das Fenster kennen und bearbeiten muss.
    • 2) Danach muss es sich in das System einbinden (Aktivierung): Es muss die Kommunikation zum und vom System starten, sich die möglichen Steuerparameter (Vorlaufparameter) besorgen, falls sie noch nicht im Speicher vorliegen, es muss die Anbindung an verwendbare Ressourcen wie Dateien oder Drucker und SystemBefehle (frei verfügbare Systemmethoden) – wie Änderungsdienste, Fehlermeldungen, Eingabe-Aufforderungen, Popup-, Rechte-Maus- und Fenster-API-Präsentation oder das Angebot an sonstigen ausführbaren Befehlen – kennen lernen und sich beim System als aktiv melden, um in übergeordnete Prozesse, an denen es beteiligt ist, eingebunden zu werden: wie bspw. die erneute Text-Bestimmung bei Sprachen-Änderung oder das Beendigen des Systems.
  • Vorlaufparameter des Systems können sich beispielsweise auf die Meldungen beziehen (welche Fehlerpriorität sie im Allgemeinen haben, ob die Verarbeitung abgebrochen oder ob der Fehler protokolliert/archiviert/beschlagwortet werden soll). Wichtig bei der Kommunikation mit dem System ist, dass nur diejenigen Systemmethoden in Frage kommen, die das Fenster selbst verarbeiten kann.
  • Fensterrelevanz: Vorlaufparameter des Systems müssen – falls das System dazu die Methoden inkl. Berechtigungsprüfung stellt und diese dem Fenster bekannt sind – nur hinsichtlich der Änderung der Werte im Fenster oder dessen Toolbar bzw. Menü (FensterAPI) angeboten werden. Der systemspezifische Teil von Toolbars bzw. Menüs sowie die Berücksichtigung einer eventuellen Verarbeitungssteuerung durch diese Vorlaufparameter hat jedoch innerhalb derjenigen Verarbeitung zu erfolgen, für die sie vorgesehen ist, sodass das Fenster sich nicht darum zu kümmern hat.
    • 3) Wenn es aufgerufen wird, muss es die Anwender identifizieren können, um nicht nur ihre Rechte für den Zugriff auf Ressourcen und Methoden (System-, Fenster-, Datei-, Individualmethoden) zu erfahren, sondern auch ihre Sprache.
  • Die länderspezifischen Besonderheiten (Lokalisierung) wie Datumsaufbereitung, Zahlenaufbereitung (Dezimalpunkt), Währungen oder Kalenderfunktionen (Feiertage, Arbeitstage und Wochenbeginn) können als Teil der Feldaufbereitungen und Checks dagegen nicht Aufgabe eines Universalfensters sein, sondern der Methoden der jeweiligen Datei (Datei-, Individualmethoden).
  • Außerdem ist es häufig geläufig, Anwendern die Möglichkeit zu geben, sich bestimmte Möglichkeiten, die vom System oder vom Fenster zur Verfügung gestellt werden, auszuwählen und diese zu speichern, sodass sie bei einer nächsten Verwendung des Fensters ohne weitere Auswahl aktiviert werden. Bei Vorlaufparametern sind jedoch nur diejenigen des Fensters von Bedeutung, da alle anderen außerhalb des Einflussbereiches des Fensters liegen und somit auch an anderen Stellen verändert werden dürfen.
  • Das bedeutet, dass das Fenster eine eigene Ressource benötigt, um die eigenen Angaben, die dauerhaft zu hinterlegen sind, abzulegen wie zum Beispiel die Lokalisierung der Fenster-Texte und Fehlermeldungen, falls das System hier keine eigene Methode zur Verfügung stellt, oder die von den Anwendern für die allgemeine Verarbeitung des Fensters oder seiner jeweiligen Instanzen ausgewählten Einstellungen (Vorlaufparameter oder die letzte Selektion = Spezifizierung von Suchkriterien).
  • Vorlaufparameter des Fensters können sich auf die Behandlung von Änderungen beziehen (ob sie sofort gespeichert werden sollen oder eine Bestätigung verlangen müssen, ob bei Datenfreigabe der nächste Satz angesprungen werden soll oder in den Suchmodus zurück verzweigt wird), Vorlaufparameter von Anwendern können sich auf die Sprache, die bevorzugte Datei oder das bevorzugte Layout beziehen, je nachdem, welche Variabilitäten in Optik und Verarbeitung das Fenster anbietet.
  • Fensterrelevanz: Üblicherweise wird jedoch die Optik und wegen der Lokalisierungsproblematik Textbearbeitung und das Meldungswesen vom System gesteuert und sollte deshalb vom Fenster nicht manipuliert werden, um das Aussehen (Look&Feel) der gesamten Applikation (Gesamt-System) nicht zu stören (Stichwort CSS: Layoutsteuerung für XML-Formate oder Einheitlichkeit von Zahlenformaten).
  • Vorlaufparameter des Fensters gelten immer für alle Instanzen (erkennbar an den zuständigen Dateien).
    • 4) Des Weiteren muss bereits an dieser Stelle die wesentliche Ressource, für die das Fenster in dieser Instanz zuständig ist – die Datei der darzustellenden Inhalte – bekannt sein. Dies kann entweder durch ein Menü oder Toolbar des Systems oder eine sofortige Anwender-Entscheidung im Fenster selbst stattfinden, wenn die bearbeitbaren Dateien nicht bereits in der Fenster-Ressource vorhanden sind.
  • Fensterrelevanz: Üblicherweise wird die gesamte Auswahl von bearbeitbaren Dateien in einem System-Menü (oder einer Menüstruktur) angeboten, worauf die aktive Instanz des Fenster sowie seines Menüs und seiner Toolbar auf die ausgewählte Datei fixiert werden. Dies hat den einfachen Grund, dass eine Applikation (Gesamt-System) sich in der Regel nicht auf ein Fenster beschränkt, sondern sich aus mehreren Prozessen zusammensetzt, bei denen Dateien und ihre Standardverwaltung nur ein Teil davon sind. Ein Universalfenster sollte deshalb hinsichtlich der Datei-Bestimmung als reiner Befehlsempfänger fungieren, da die gesamte Prozesssteuerung sich auf einer anderen Ebene befindet.
  • Zu beachten ist, dass üblicherweise mehrere Fenster-Instanzen parallel zur Verfügung stehen können, während Toolbars in der Menüleiste des Systems nur einmal vorhanden sind. Dies bedeutet, dass die jeweils aktive Fenster-Instanz bestimmt, welche der Fenster-Toolbar-Instanzen zu sehen ist, sie muss also die Möglichkeit haben, bei Aktivierung eine Rückmeldung an die eigene Toolbar zu geben. Auch das eigene Menü wird in der Regel nicht angezeigt, wenn das Fenster nicht aktiv ist.
  • Nachdem die Datei, für die diese Instanz zuständig ist, bekannt ist, muss das Fenster sich an die Datei anbinden (Initialisierung), um sich die Datei-Metadaten zu beschaffen über den Feldaufbau, die Feld-Aufbereitung, Darstellung in Rechte-Maus- Präsentation und Plausibilitätsprüfungen (Check), die generellen und die individuellen Methoden der Datei, die grundlegenden Steuerungsparameter (Vorlaufparameter), die zugehörigen Texte und Fehlermeldungen (Meldung), die Such-Kriterien und Such-Verfahren, Such-Ergebnisse und Such-Aufbereitungen sowie die Nutzung von System-Diensten für Import und Export von gleichartigen Inhalten oder von Änderungsdiensten (Meldung an das System für andere Services oder Protokollierung, Archivierung, Beschlagwortung, Wiedervorlage, Terminierungen/Kalenderfunktionen).
  • Ein Berechtigungssystem für die Bearbeitung von Dateien oder Datensätzen (Inhalten) wird üblicherweise über die Anwender-Verwaltung des Systems geregelt, was den Vorteil hat, dass die Prüfung von Rechten nur an einer einzigen Stelle (Stichwort Single-Sign-On, PKI Public Key Infrastructure) durchgeführt werden muss, wenn sie nicht gar vollständig in der Hand des Systems liegt.
  • Vorlaufparameter der Datei können sich auf Mandanten beziehen (ob sie zu berücksichtigen sind und welcher aktiv ist) sowie auf die Änderungsdienste oder die Berücksichtigung von Sprachen in Texten, soweit sie das Fenster selbst verarbeiten kann/muss.
  • Fensterrelevanz: Wie bei den Vorlaufparametern für das System muss das Fenster bzw. seine Toolbar und sein Menü nur-falls die Datei die passenden Methoden inkl. Berechtigungsprüfung dazu stellt und das Fenster diese kennt- eine Änderungsmöglichkeit anbieten, da der dateispezifische Teil von Menüs und Toolbars sowie die Berücksichtigung einer eventuellen Verarbeitungssteuerung durch diese Vorlaufparameter innerhalb derjenigen Verarbeitung zu erfolgen hat, für die sie vorgesehen sind (die allgemeinen oder individuellen Dateimethoden).
    • 5) Initialisierung: Mit diesen Daten kann das Fenster nun seine generellen Fähigkeiten zur Suche und Verarbeitung individualisieren – auf die aktuelle System-Umgebung, die bearbeitete Datei und die individuelle Person „Anwender". Es muss sich seine Texte in der jeweiligen Sprache beschaffen und die Darstellung der Datei gemäß den Vorlaufparametern und den Datei-Metadaten aufbereiten, soweit sie die Darstellung berühren wie z.B. die anzuzeigenden Felder.
  • Und es muss dem System mitteilen, welche Fenstermethoden es selbst anbietet, die von anderer Seite genutzt werden können: Es muss sein Fenster-API starten.
  • Falls eine Berücksichtigung von fensterfremden Vorlaufparametern in Frage kommt, werden sie nicht in die Fenster-Instanz aufgenommen, sondern aus Aktualitätsgründen direkt beim System, der Datei oder aus der Fenster-Ressource abgefragt (Vorlaufparameter des Fensters gelten für alle Instanzen). Die Datei-Metadaten werden analog dazu direkt aus der jeweiligen Ressource ermittelt, in der sie abgespeichert sind, da auch diese unter Umständen von anderer Stelle aus geändert werden können.
  • Falls das Fenster bereits eine Selektion gespeichert hat, kann es die Suche sofort durchführen und die Such-Ergebnisse dieser Selektion in der erforderlichen Such-Aufbereitung zur Verarbeitung anbieten. Der erste Datensatz (Inhalt) – oder, falls die Selektion die Information über einen ausgewählten Datensatz beinhaltet, diesen speziellen Datensatz – wird dann mit Hilfe der Dateimethoden der Feldaufbereitung (gemäß den Datei-Metadaten der Präsentation und gemäß den Zugriffs-Rechten der Anwender) dargestellt, soweit sie das Fenster selbst verarbeiten kann.
    • 6) Nachdem das Fenster Suche und Verarbeitung anbieten kann und diese Suche auch gemäß den eingegebenen Werten der Such-Kriterien (Selektion) über die entsprechenden Dateimethoden gezielt durchführt und aufbereitet, wird es nun einen speziellen Datensatz zur Verarbeitung anbieten.
  • Dabei wurden die Rechte der Anwender an Datensätzen und Verarbeitungsformen von den entsprechenden Dateimethoden überprüft.
  • Sind die Inhalte normiert, können also nur bestimmte Werte für die jeweiligen Datensätze bzw. Datenfelder zugelassen werden, müssen diese Normierungen (Listen) ebenfalls eingelesen werden, um bei Bedarf die Beschreibungen des jeweiligen zutreffenden Listenwertes zu ermitteln (Text) oder die gesamte Liste (beispielsweise per Popup) zur Ansicht zu bringen. Auch solche Aufbereitungen und Prüfungen werden von den Dateimethoden zur Verfügung gestellt, da sie sowohl von der Datei als auch vom jeweiligen Dateifeld abhängig sind.
    • 7) Für die Verarbeitung müssen die Datei-Metadaten hinsichtlich des Feldaufbaus und die Dateimethoden zur Feldaufbereitung berücksichtigt werden, um den Datensatz korrekt aufzubereiten.
  • Während der Verarbeitung muss ständig die Möglichkeit gegeben sein, über die Such-Ergebnisse auf weitere spezielle Datensätzen zur Verarbeitung (Pkt 6) zuzugreifen.
  • Zur Übersicht über die jeweiligen Inhalte und Verarbeitungsformen ist die Rechte-Maus-Präsentation für Listen, Texte, Änderungsdienst-Angaben oder ähnliches anzubieten. Für häufig genutzte Angaben wie Listen kann auch die Darstellung des jeweiligen Datenfeldes mit einem besonderen Element ergänzt werden, mit dem diese Listen direkt angezeigt werden können (Popup als internes Menü mit vom Fenster steuerbaren Elementen).
  • Die Besonderheiten bei neuen Datensätzen (Vorbelegung von Inhalten) sind zu gewährleisten, auch müssen Löschungen (je nach Rechten) oder Kopien oder auch die Möglichkeit, Standardsätze zu benennen, angeboten werden Sind Änderungen durchgeführt worden, sind diese zu prüfen und bei Bedarf entweder eine Fehlermeldung auszugeben oder durchzuführen.
  • Dabei muss die Verarbeitung ständig von den Möglichkeiten der Darstellung wie Buttons, Maus oder Tastatur (Controls) sowie Popups, Rechte-Maus und Fenster-API (Menü, Toolbar) gesteuert werden können, wobei das Fenster-API bei Bedarf entsprechend aktualisiert werden muss.
    • 8) Zusätzlich muss die Verarbeitung auch die vom System oder den Datei-Metadaten angebotenen Funktionalitäten (s. Punkt 2) anbieten und bei Bedarf ausführen wie beispielsweise über das Universalfenster hinausgehende Angaben über die System-Befehle zu erlangen oder Hinweise (Fehlermeldungen mit geringer Priorität) auszugeben, die Kommunikation zu anderen Ressourcen wie Dateien oder Drucker zu erreichen oder Änderungsdienste je nach Berechtigung zur Verfügung stellen. Liegen Unklarheiten vor, muss darüber hinaus über eine Eingabe-Aufforderung eine Entscheidung über System- bzw. Datei-Angaben (Auswahl) von den Anwendern gefordert werden können.
    • 9) Bei der Verarbeitung der jeweiligen Inhalte müssen gelegentlich andere Inhalte – von derselben oder anderen Dateien – überprüft werden. Aus dem Grund muss das Fenster in der Lage, eine weitere Instanz des Universalfensters zu öffnen und dessen Steuerparameter wie beispielsweise verändertes Layout zu manipulieren (falls implementiert). Wird von einem solchen Sub-Fenster (Client) ein Inhal/Datensatz auswählt, muss es das rufende Fenster über diese Entscheidung benachrichtigen können. (Client-Transfer) Die Kommunikation über das System braucht nicht in Anspruch genommen zu werden, da beide Fenster Instanzen derselben Klasse sind.
  • Die eigene Toolbar bzw. das Menü muss zu der Zeit der Aktivität des Sub-Fensters (Clients) auf dieses verweisen (s. Pkt. 4)
    • 10) Während der gesamten Verarbeitung muss das Fenster für die übergeordneten Prozesse (Pkt. 2) zur Verfügung stehen wie die erneute Text-Bestimmung bei Sprachen-Änderung oder das Beendigen des Systems. Auch auf das Fenster-API muss es reagieren können
    • 11) Verlassen: Bei der Beendigung des Fensters müssen die Vorlaufparameter des Fensters und die Selektion hinterlegt werden, außerdem muss es Ressourcen freigeben (wie die Fenster-APIs) und sich beim System abmelden.
  • Anmerkung: Für die Realisierung des Universalfensters werden die üblichen Verhaltensregeln berücksichtigt, da dies am ehesten mit dem Stand der Technik in der Kommunikationsinfrastruktur übereinstimmt, der als Grundlage des Universalfensters erforderlich ist.
  • Anmerkung: Für die Realisierung des Universalfensters wird eine Kopplung von Dateien nicht berücksichtigt, da diese Kopplung in die individuellen Methoden der Dateien oder die Applikationsübersichten des Systems verlagert und so aus der Repräsentationsebene herausgehalten werden kann, zumal in jüngerer Zeit die Tendenz besteht, solche Kopplungen zu separieren, um sie flexibler zu machen (Kommunikationsobjekte, conceptual objects). Auch kann das Client-Konzept im Universalfenster dazu dienen, solche separierten Kopplungen konstruktionsgemäß auszuführen, ohne die Optimierung der Struktur/Verarbeitung zu zerstören.
  • 5.2. Beschreibung der Erfindung aus Funktionssicht
  • Aus der Beschreibung der Erfindung aus Aufgabensicht ergibt sich eine Terminologie von 37 Begriffen, deren Definition mithilfe der ML-Methode präzisiert wurde, bis das Ergebnis der automatischen Lösungssuche ein verwertbares Resultat erzielte. Das heißt, dass die „wichtigen" Begriffe korrekt als „Objekte" ausgewiesen werden, während die übrigen nur „externe Variable/Methoden" sind, was darauf hindeutet, dass die verbalen Zusammenhänge den Problembereich adäquat abbilden.
  • Da die ML-Methode nur strukturelle, jedoch keine inhaltlichen Aspekte verwertet, wurde dieses Resultat in den einzelnen Zweier-Beziehungen von Begriffen überprüft, bis die Lösung sowohl den strukturellen Anforderungen als auch den inhaltlichen entsprach.
  • 5.3. Beschreibung der Voraussetzungen aus Funktionssicht
  • Jedes Modul von Software muss in die gesamte Anwendung integriert werden und erfordert deshalb selbst bei loser Kopplung Gegebenheiten, ohne die es nicht funktionieren kann und für die es letztendlich ausgelegt ist. Oder mit anderen Worten: Der Einsatz von Zündkerzen ist in einem Dieselmotor nicht erforderlich.
  • Die Gestaltung eines datenanonymen Universalfensters führt dabei zu den folgenden Anforderungen an die serviceorientierte Architektur, wobei den geforderten Funktionalitäten die Verwaltung der für sie maßgeblichen Bedingungen hinsichtlich erforderlicher Plausibilitäten wie Berechtigung selbst obliegt.
  • 0) System = Basis für Ressourcen und Verarbeitung
  • Das System stellt die Grundlage der gesamten Architektur dar. Von der Anbindung an das Stromnetz zur Hardware (Computer, Monitor, Tastatur, Akku etc.), den Netzwerkverbindungen und den jeweiligen Betriebssystemen bis hin zu den Software-Produkten, die zur Interaktion aller beteiligten Einheiten erforderlich sind, wird die gesamte Infrastruktur als „System" benötigt, um die Realisierung von Software zu ermöglichen. Diese Funktionen sind jedoch in aller Regel vor den ausführenden Subsystemen einer Software-Applikation verborgen.
  • Folgende Dienste des Systems müssen dagegen den Subsystemen offen zugänglich gemacht werden:
  • 1) ImExport = Übertragung von „Inhalten" an Ressourcen außerhalb des „Systems"
  • Diese Funktionalität ist für die Anbindung an externe Systeme mit den entsprechenden Sicherheitskontrollen beim Austausch von Inhalten zuständig. Die Anbindung hat dabei nicht nur als technische Schnittstelle zu funktionieren, sondern muss auch einen gezielten methodischen Zugriff für die jeweils erforderlichen Aufgaben zur Verfügung stellen wie beispielsweise bei einem Drucker die Schachtauswahl.
  • Externe Systeme können dabei neben Peripheriegeräten wie Drucker, Disketten oder CD/DVDs auch mobile Endgeräte am lokalen Netzwerk, virtuelle Netzwerke, die das Internet zur Kommunikation verwenden (VPN Virtual private networks), das Internet selbst oder angebundene Fremdsysteme sein.
  • Sicherheitsfunktionen drehen sich dabei um Firewall, Virenprüfung, Verschlüsselung, aber auch um Fehleraufspürung in übermittelten Daten.
  • 2) Änderungsdienste = „SystemBefehle" im Zusammenhang mit der „Fortschreibung"
  • Änderungsdienste beschäftigen sich insbesondere mit Überwachungsaufgaben für die Datenhaltung, deren Aufgabe die Aufbereitung, Prüfung und Speicherung von Inhalten in Dateien zur späteren Wiederverwendung ist. Änderungsdienste verfolgen diese Vorgänge, um sie nachvollziehbar und leichter auffindbar zu machen. So werden wichtige Veränderungen in den Dateien protokolliert, die Daten werden prioritätsgemäß archiviert, zur Kategorisierung und firmenweiten Navigation beschlagwortet und sie lassen sich über Kalenderfunktionen zu späteren Zeiten wieder zur Bearbeitung vorschlagen.
  • 3) SystemBefehl = zur Verfügung gestellte „System"methoden
  • Da jegliche offen gelegte Schnittstelle des Systems letztendlich ein SystemBefehl ist, sind hier insbesondere solche Funktionalitäten angesprochen, die je nach Kontext und Berechtigung den angebundenen Komponentenprogrammen zur Verfügung stehen wie beispielsweise Kalenderfunktionen. Oft werden sie als Systembibliotheken oder-module bezeichnet.
  • 4) Subsystem Kommunikation = Austausch von „Inhalten" zur Verarbeitung innerhalb des „Systems"
  • Die Kommunikation dient der Gewährleistung der sicheren Interaktion der verschiedenen Komponenten im System. Interaktion bedeutet den ereignisgesteuerten Austausch von Nachrichten zwischen den verschiedenen Subsystemen und muss deshalb sowohl die Subsysteme als auch deren Schnittstellen kennen, um diese Nachrichten nicht nur korrekt weiterleiten zu können (dynamisches Routing), sondern auch sicherzustellen, dass diese Nachrichten tatsächlich ausgeführt werden (transactional guaranteed delivery).
  • Neben der Sicherung der Befehlsausführung ist es darüber hinaus in modernen Softwaresystemen üblich, proaktive Sicherungsstrategien anzubieten, um mögliche Fehlerquellen oder vorsätzliche Schäden frühzeitig zu erkennen und zu beheben.
  • Die oben genannten Systemfunktionen liegen als interne Basis jedem der Kommunikationsdienste zugrunde, die den Anwendungskomponenten wie dem Fenster zur Verfügung gestellt werden, sind aber für die Aufgabenstellung der Anforderer nicht von eigenständigem Interesse. Sie werden deshalb nach dem objektorientierten Prinzip vom „Verbergen von Ausführungsdetails" als Blackbox gehandhabt. Folgende Dienste der Kommunikation müssen dagegen den Subsystemen offen zugänglich gemacht werden:
  • 4,1) Liste = Normierung von „Inhalten", vorgegeben von der jeweiligen Verarbeitung
  • Normierte Inhalte sind nicht frei wählbar, hängen deshalb immer von dem Subsystem ab, das sie verwendet. So stellt ein modernes System nicht nur verschiedene Sprachen, sondern immer auch Kalenderfunktionen zur Verfügung, die lokale und religiöse Vorgaben enthalten können, die das System dann beispielsweise Datei-Subsystemen für Plausibilitätsprüfungen (wie Feiertage) anbietet. Dateien dagegen können für die von ihnen bearbeiteten Inhalte ebenfalls Normierungen verlangen wie Ja/Nein-Felder, oder Felder, deren Werte von anderen abhängen.
  • Solche Abhängigkeiten können berechenbar sein, sie können jedoch auch auf anderen, dem System bekannten Dateien beruhen.
  • Listen sind, ähnlich wie Texte, ein Angebot des Systems, solche Normierungen in einfachen Standard-Dateien unterzubringen, da viele Programme Steuer- und Arbeitsdaten benötigen, die mehrfach verwendet werden müssen wie beispielsweise Länderkennzeichen. Doch nicht nur der Inhalt muss konsistent für alle Nutzerprogramme sein, auch die Darstellung von solchen Normierungen, um für die Anwender einen einheitlichen Eindruck (Look&Feel) zu gewährleisten.
  • Die Speicherung dieser Inhalte kann dabei im selben Datei-Subsystem erfolgen wie die Arbeitsdaten, muss es aber, ebenso wie bei den Texten, nicht notwendig tun.
  • 4,2) Inhalt = für „Anwender" und „System" bedeutsamer Gegenstand der Verarbeitung
  • Inhalte sind alles, was sich speichern und dadurch auch transportieren lässt und was irgendeinen Nutzen bringt. Einfache normierte Inhalte werden über Listen abgearbeitet, sprachenabhängige über Texte, strukturierte Inhalte über Dateien, Inhalte, die auf Papier oder an sonstige Verwendungsstellen außerhalb des Systems gelangen müssen, werden über die ImExport-Funktionalität des Systems (Druck) behandelt und die Veränderung von Inhalten wird durch die Änderungsdienste beaufsichtigt.
  • Inhalte müssen deshalb vom Kommunikationssystem nicht nur ihrem Typ gemäß eingeordnet werden können, sie müssen auch unabhängig vom Typ übertragbar und abrufbar sein, um individuelle Interaktion zwischen Komponenten zu erlauben und somit übergreifende Prozesse zwischen einzelnen Subsystemen zu ermöglichen.
  • Auch die Änderungsdienste müssen bei Bedarf Inhalt ungeachtet seiner spezifischen Verarbeitung verfolgen und Sicherheitsfunktionen müssen erforderlichenfalls auf Inhalte ungeachtet ihrer späteren Verwendung zugreifen können, um Fehler oder vorsätzliche (interne) Schäden aufspüren zu können, die von Anwendern oder angebundenen Komponenten in das Gesamtsystem einfließen könnten.
  • 4,3) Subsystem FensterAPI = Präsentation der bekannten Funktionen durch das „Fenster"
  • Das FensterAPI stellt den Zugang zum Fenster als Schnittstelle zwischen System und Anwendern dar (siehe „Realisierung Fenster").
  • 4,4) Subsystem Anwender = Person mit „Rechten" zur Steuerung des „Systems"
  • Das Anwender-Subsystem bindet Anforderer wie Menschen oder Fremdsysteme an das System und regelt die spezifischen Aufgaben des flexiblen, kontrollierten Zugriffs (siehe unten).
  • 4,5) Text = „SystemBefehle", die Abhängigkeiten von „Sprache" regeln
  • Die Textfunktionen dienen somit der Koordination, Verwaltung und Speicherung von Inhalten, die von Anwendern abhängen. Solche Abhängigkeiten (Lokalisierung) sind durch die Sprache oder Formatierungen von Zahlen oder Datumsangaben gegeben und müssen bei jeder Form von Präsentation gegenüber Anwendern berücksichtigt werden.
  • Texte werden in sehr vielen Komponenten genutzt und sind deshalb vom System anzubieten. Die Speicherung dieser Inhalte kann dabei im selben Datei-Subsystem erfolgen wie die Arbeitsdaten, muss es aber nicht.
  • 4,6) Subsystem Suche = Zugriff auf „Inhalte" durch die „Datei" für das „Fenster"
  • Das Suche-Subsystem bindet Dateien an das System und regelt die spezifischen Aufgaben des flexiblen, kontrollierten Zugriffs (siehe unten).
  • Für ein Fenster als Schnittstelle zu den Anwendern sind dabei folgende Aufgabengebiete der Kommunikation von speziellem Interesse:
  • 4,4) Subsystem Anwender = Person mit „Rechten" zur Steuerung des „Systems"
  • Das Anwender-Subsystem gewährleistet eine flexible Zugangsmöglichkeit für Menschen oder Fremdsysteme, die letztendlich wieder Zugänge für Menschen offerieren.
  • Ein solcher Zugang zeigt deutlich die zwei grundsätzlichen Problembereiche jeder Informationsverarbeitung, die auf der Natur der Information, gerichtete Wirkung zu sein, basieren: einerseits muss Information von Anwendern in das System integriert werden, andererseits muss Information an die Anwender geliefert werden.
  • Im ersten Fall muss der Informationsaustausch kontrolliert werden hinsichtlich der Anwender. Die von den Systemfunktionen ImExport bzw. Kommunikation geleisteten Dienste sind dabei hierarchisch vorgeschaltet, sodass die dem Subsystem Anwender überlassenen eingegangenen Information bereits korrekt aufbereitet und unter Sicherheitsaspekten unbedenklich sind.
  • Im zweiten Fall werden den Anwendern Informationen angeboten, die den Anforderungen der jeweiligen Anwender gemäß präsentiert werden müssen.
  • 4,4,1) Auswahl = Ressource des „Systems" zur Entscheidungsfindung durch die „Anwender"
  • Das System benötigt im Lauf seiner Verarbeitung Klarstellungen, für die es Informationen seitens der Anwender in einheitlicher Form anfordert. Auch die Präsentation der Auswahl hinsichtlich Lokalisierung und Text obliegt dieser Funktionalität, die anfordernden Subsysteme müssen deshalb nur die jeweiligen formalen Aspekte für die spezifische Auswahl zur Verfügung stellen. Die von den Anwendern empfangenen Informationen sind hinsichtlich Korrektheit der mitgegebenen formalen Aspekte zu berücksichtigen und im positiven Fall an die Verarbeitung weiterzureichen. Im negativen Fall erfolgt eine Meldung.
  • Plausibilitätsprüfungen der Inhalte müssen dagegen von den die Auswahl-Funktionalität anfordernden Subsystemen selbst durchgeführt werden.
  • 4,4,2) Meldung = Übergabe von „Inhalten" an die „Anwender"
  • Meldungen sind standardisierte Informationen des Systems an die Anwender, die für diese von Interesse sind, sie können Hinweise sein oder sich als Fehler bemerkbar machen. Die Präsentation der Meldung hinsichtlich Lokalisierung und Text obliegt dabei ebenfalls dieser Funktionalität, die anfordernden Subsysteme müssen deshalb nur die jeweiligen Schlüsselwerte für die spezifische Meldung zur Verfügung stellen.
  • 4,4,3) Rechte = Umfang der „Kommunikation"
  • Anwender können zwar das System steuern, jedoch nicht in unbeschränktem Maß. Rechte regeln dabei nicht nur die Zugänge zu Funktionen, sondern auch zu Daten und sind deshalb Filter, die über jede Interaktion von Anwendern mit dem System gelegt werden. Bei modernen Systemen geschieht dies nicht nur bei der Prüfung der eingehenden Signale seitens der Anwenders, sondern bereits bei Angeboten an Anwender, da es psychologisch positiver ist, eine Verbot nicht offen zu legen, sodass Anwender nur das auswählen dürfen, was sie auch berechtigungsgemäß tatsächlich ausführen dürfen.
  • 4,4,4) Sprache = „Kommunikations"mittel für „Anwender"
  • Das Aufgabengebiet „Sprache" umfasst die Koordination, Verwaltung und Speicherung von denjenigen Steuerungselementen hinsichtlich der Präsentation von Inhalten für die Anwender (Lokalisierung), die dem System zur Verfügung stehen. Insbesondere regelt es die Umstellung aller zu präsentierenden Elemente auf die neuen Lokalisierungsgegebenheiten bei Sprach- oder Länderwechsel.
  • Seine Aufgabe ist letztendlich, das System für die Anwender nutzbar zu machen, denn Inhalte, die Anwendern angeboten werden, müssen von diesen verstanden werden können. Ihre Bedeutung (ihre Menge an Information) muss von ihnen aus den angebotenen Daten (Zuständen) korrekt reproduziert (interpretiert) werden, um Missverständnisse und damit Fehler zu vermeiden.
  • Sie sind also nicht nur aus der für das technische System nützlichen Struktur in eine Form zu bringen, die für die Gehirne menschlicher Anwender verarbeitbar ist wie Worte oder Bilder, sie sollten es auch in einer Weise tun, die diese Interpretationsarbeit möglichst einfach hält. Jede zusätzliche Arbeit, die Anwendern durch fehlende Übersetzung oder falsche Formatierung aufgebürdet wird, ist zusätzlicher Aufwand für ihre Gehirne und damit auch eine zusätzliche Fehlerquelle, ohne dass diese zusätzlich aufgebrachte Wirkung einen Nutzen hätte.
  • Die eigene Sprache (und Schrift) der Anwender ist dabei die bequemste Art, Worte verständlich zu machen, die eigenen Formatierungen von Tausendertrennungen lassen Zahlen leichter zugänglich werden und die korrekte Anordnung von Monat, Jahr und Tag hilft dabei, die richtige und rasche Erfassung der Zeitangabe zu fördern.
  • 4,4,5) Selektion = Spezifizierung von „Suchkriterien" durch die „Anwender"
  • Dieses Aufgabengebiet umfasst die Konservierung und Wiederauffindung des vom Anwender-Subsystem zu bearbeitenden Anteils an Selektionen (siehe Suche) zur späteren Verwendung durch dieselben Anwender, dieselbe Präsentationsumgebung (Fenster) und dieselben Daten.
  • 4,4,6) Vorlaufparameter = Steuerparameter für die Verarbeitung (hier: des „Fensters")
  • Der vom Anwender-Subsystem zu bearbeitende Anteil an den Vorlaufparametern ist die Speicherung und Wiederherstellung dieser Auswahl hinsichtlich der Einstellungen für globale Steuerungen der Verarbeitung (Customizing) im Falle, dass dieselben Anwender das System wieder benutzen. Dann ist eine erneute Anfrage nicht mehr erforderlich.
  • Für ein Fenster als Schnittstelle zu den Anwendern ist dabei nur der fensterspezifische Satz an Vorlaufparametern von Interesse wie beispielsweise (falls vom System angeboten) die Oberflächengestaltung.
  • 4,6) Subsystem Suche = Zugriff auf „Inhalte" durch die „Datei" für das „Fenster"
  • Das Suche-Subsystem bindet Dateien an das System und regelt die spezifischen Aufgaben des flexiblen, kontrollierten Zugriffs.
  • Gespeicherte Inhalte sind ohne Wert, solange sie nicht wieder aufgefunden werden können, um weiterer Verarbeitung zur Verfügung zu stehen. Das Subsystem Suche zeigt wieder deutlich die zwei grundsätzlichen Problembereiche jeder Informationsverarbeitung, die auf der Natur der Information, gerichtete Wirkung zu sein, basieren: einerseits muss Information abgegeben werden, andererseits muss Information in das System integriert werden. Im ersten Fall muss der Informationsaustausch kontrolliert werden hinsichtlich der Schnittstellen-Passgenauigkeit zum Datenträger-System, im zweiten Fall, muss der eingehende Datenstrom korrekt aufbereitet werden, um vom verarbeitenden System, ob Mensch oder Maschine, „verstanden" zu werden, wobei Technik und Sicherheit wieder dem Kommunikationssubsystem und bei Bedarf dem ImExport-Dienst des Systems obliegen, die Berechtigung dagegen dem Anwender-Subsystem.
  • Auch hier gilt wie bei der Funktionalität „Fortschreibung" der Datei, dass die Suche als Blackbox sowohl den Ort des Dateisystems als auch dessen Aufbau verbirgt.
  • 4,6,1) SuchAufbereitung = Präsentation der „Suche"
  • Die vom Datenträger eingegangenen Ergebnisse einer Suche werden gemäß den Aufbereitungsvorschriften („Feldaufbereitung") für die auf Fenstern, Drucken oder Ähnlichem benötigte Darstellung unter Berücksichtigung von „Sprache"-Diensten des Anwender-Subsystems aufgearbeitet. Auch Klartexte und normierte Werte („Listen") für die anzuzeigenden Feldern werden über „Feldaufbau" und „Feldaufbereitung" der Datei sowie „Sprache" inklusive „Text" ermittelt und mitgeführt.
  • Dies erfolgt jedoch nicht nur für die reine Darstellung der Suchliste, sondern vorzugsweise auch so umfassend, dass das Fenster die vollständige Information über alle gefundenen Datensätze vorfindet, sodass keine weiteren Zugriffe des Fensters auf Datensätze und ihre Metadaten erforderlich sind.
  • 4,6,2) SuchErgebnisse = Resultat der „Suche"
  • Diese Funktionalität nimmt die vom Datenträger-System übermittelten Ergebnisse über die Dateifunktion „Feldaufbau" auf. Dies bedeutet, dass die den Suchkriterien entsprechenden Datensätze technisch insoweit überarbeitet sind, dass sie vom Kommunikationssystem übertragen werden können und die Form haben, die die Fortschreibungs-Funktionalität des Datei-Subsystems erfordert, um bei Bedarf eine korrekte Anpassung der gespeicherten Daten an die aktuellen Werte zu erzielen.
  • 4,6,3) Suchkriterien = Einschränkung der „Suche"
  • Suchkriterien erlauben es, je nach Datenbanksystem und individueller Datei, Inhalte gezielt nach den Werten einzelner Bestandteile (Feldern) einzukreisen. Die erforderlichen Beschreibungen werden gemäß den Aufbereitungsvorschriften („Feldaufbereitung") für die auf Fenstern, Drucken oder Ähnlichem benötigte Darstellung auch unter Berücksichtigung von „Sprache"-Diensten des Anwender-Subsystems aufgearbeitet. Klartexte und normierte Werte („Listen") für die anzuzeigenden Feldern werden ebenfalls über „Feldaufbau" und „Feldaufbereitung" sowie „Sprache" und „Text" ermittelt und mitgeführt, sodass verwendende Subsysteme keinen weiteren Ermittlungsbedarf mehr im Zusammenhang mit diesen Daten haben.
  • 4,6,4) Suchverfahren = verschiedene Formen der „Suche"
  • Je nach Datenbanksystem sind die Möglichkeiten, Suche durchzuführen, verschieden vielfältig, wobei es sich bei der angebotenen Funktionalität nicht um die technische Realisierung der Suche handelt, sondern um den Zugang für die anwendenden Subsysteme, um die Ausführung der technisch möglichen Datenbeschaffungsvorgänge mit den gewünschten Vorgaben zu initiieren.
  • 4,6,5) Subsystem Datei = Ressource des „Systems" zur Ansammlung von gleichartigen „Inhalten"
  • Eine Datei ist die koordinierte Konservierung von dauerhaften Inhalten zur späteren Wiederverwendung (Persistenz). Sie ist jedoch nicht nur der reine Datenspeicher, sondern auch das Managementsystem zu seiner Verwaltung. In modernen Systemen wird diese Funktion immer stärker von den Anwendungsprogrammen isoliert, um diese unabhängig von den Datenformaten und den technischen Ausführungen zu machen (Grundsatz der losen Kopplung). Die Basis-Architektur des Realisierungsbeispiels verwirklicht diesen Grundsatz durch metadatengesteuerte Objekte für den generalisierten Dateizugriff, wobei die dateispezifischen Elemente in eigenen ausführbaren Komponentenobjekten abgearbeitet werden. Als Teil der Metadaten versieht diese Kombination von dateitypspezifischen und dateiindividuellen Methoden den Gesamtkomplex einerseits mit einer einheitlichen Schnittstelle für den Datenzugriff und die -fortschreibung, andererseits mit den geforderten individuellen Charakteristik für Prüfung und Aufbereitung. Patent DE 69627522 T2 realisiert die isolierte Dateifunktionalität durch Schnittstellen (Front-End-Klassen), die die generalisierten Funktionalitäten analog dem Entwurfsmuster Facade sammeln und zu den jeweiligen tatsächlich betroffenen Objekten weiterleiten, und auch die diversen Java-Frameworks zur Datenhandhabung kapseln Datenzugriff und -fortschreibung in immer umfangreicherem Maße, wie die jüngste Entwicklung der SDO (Service Data Objects) demonstriert.
  • Die Funktionen einer Datei betreffen dabei die Strukturierung der Inhalte und deren Abhängigkeiten sowie die Speicherung und Wiederauffindung in zeitüberdauernden Medien. Wie beim Anwender-Subsystem gilt, dass die vorgeschalteten Systemfunktionen für die korrekte technische und unter Sicherheitsaspekten unbedenkliche Aufbereitung des Datenflusses gesorgt haben.
  • 4,6,5,1) Fortschreibung = Änderung von „Inhalten" in der „Datei"
  • Diese Funktionalität sorgt je nach Art und Mächtigkeit des dahinter stehenden Datenbank-Managementsystems für die Konsistenz der gespeicherten Daten mit ihrem Abbild im Anwendungssystem, das von den Anwendern manipuliert wurde.
  • Als Blackbox verbirgt sie sowohl den Ort des Dateisystems als auch dessen Aufbau. Ob die Datei also physikalisch im selben Rechnersystem vorhanden ist, im Netzwerk oder im Internet, ob sie kompakt oder verteilt ist, ob sie flach, relational oder objektorientiert ist, spielt für das Anwendungssystem keine Rolle, weil das Subsystem Datei dies über die Funktionalität „Fortschreibung" abkapselt. Wie viele Arbeitsschritte dahinter stehen, ob Leitungen aufgebaut oder Filter benutzt werden müssen, ist interne Sache dieser Aufgabe und für die Handhabung durch anwendende Systeme ohne Belang. Auch die bei Bedarf von dieser Funktion aufgerufene Kennwortbestimmung durch den „Rechte"-Dienst des Anwendersystems sowie die Versendung von Daten, die durch die Exportfunktion und/oder die Kommunikation technisch und sicherheitsbezogen nachgearbeitet werden, liegen im Zuständigkeitsbereich dieser Funktion „Fortschreibung" verborgen.
  • 4,6,5,2) Vorbelegung = Unterlassungswerte für neue „Inhalte"
  • Neue Inhalte sind nicht immer vollständig bestimmt. Um fehlende Werte zu definieren, werden für jeden Typus von Inhalt Unterlassungswerte angegeben, die einen klaren Zustand des Inhalts gewährleisten. Dies können einfache Werte sein, aber auch ausgewählte Datensätze, die als besonders typisch gekennzeichnet wurden oder Berechnungsmethoden, mit denen die neuen Inhalte aus der aktuellen Situation bestimmt werden.
  • 4,6,5,3) Check = Prüfung von „Inhalten" durch die „Datei"
  • Die Inhalte werden dabei nicht nur auf Korrektheit hinsichtlich der eingegebenen Datenformate, sondern auch hinsichtlich der vorhandenen Abhängigkeiten wie Normierungen oder Berechnungen aus anderen Dateifeldern kontrolliert.
  • 4,6,5,4) Feldaufbau = Struktur der „Datei" in Felder
  • Da eine Datei gleichartige Inhalte verwaltet, kann sie diese nach deren Gleichartigkeit (Typ) katalogisieren. Lässt sich ein Inhalt zergliedern, so dienen Felder als diejenigen Dateielemente, die die einzelnen Bestandteile des Inhaltes aufnehmen.
  • Die Beschreibung dieser Bestandteile über Metadaten wie Feldtyp, Feldanordnung, Bereich der Feldwerte, Priorität der Feldwerte (Muss/Kannfelder), Normierung der Feldinhalte oder spezielle Prüfungsmethoden mit ihren Meldungen sind dabei erforderlich, um die gespeicherten Werte wieder zu den Inhalten mit Bedeutung zu machen, die der Datei übergeben wurden. Inhalt mit Bedeutung heißt dabei nichts anderes als Information (Zustände, verbunden durch regelmäßiges Verhalten), weshalb die gespeicherten Daten erneut in ihren Kontext von Abhängigkeiten und Methoden gestellt werden müssen, damit aus Daten Information wird (Interpretation).
  • Um Sprachenabhängigkeit zu gewährleisten, sind die Meldungen der Prüfungsmethoden gemäß der Meldungsschnittstelle des Anwender-Subsystems als Schlüsselwerte im Textsystem zu hinterlegen.
  • 4,6,5,5) Feldaufbereitung = Präsentation von Feldern durch die „Datei"
  • Dieses Aufgabengebiet der Datei umfasst alle Funktionalitäten, die sich um die Präsentation der Felder dreht, wie die Anzeige/Verwaltbarkeit in Fenstern, Drucken, Editoren (Browsern), Export-Dateien oder Ähnlichem. Die Anzeige bzw. Verwaltbarkeit kann dabei noch in verschiedene Unterarten der jeweiligen Präsentationsobjekte gegliedert sein, die auch für das Anwender-Subsystem hinsichtlich der Berechtigungen maßgeblich sein können. Auch die Frage, ob die Werte von Sprache (Lokalisierung) abhängen, ist Bestandteil der Feldaufbereitung, da in solch einem Fall der endgültige Wert über die Anwenderschnittstelle „Sprache" aufbereitet werden muss. Im Falle von Texten sind deshalb die Schlüsselwerte des Textsystems zu verwenden, die auf die jeweiligen Sprachausgaben und Versionen wie „de/Kurztext" oder „de/Langtext" verweisen.
  • Die dem Fenster vom System angebotenen Schnittstellen sind deshalb ImExport (1), Änderungsdienste (2), SystemBefehle (3) und Kommunikation (4). Kommunikation bietet weiterhin die Schnittstellen zu Anwendern (4,4), Suche (4,6) und dem Fenster-API (4,3) sowie zu Texten (4,5), Listen (4,1) und Inhalten (4,2). Die Anwenderschnittstelle (4,4) regelt Auswahlen (4,4,1), Meldungen (4,4,2), Rechte (4,4,3) und Sprache (4,4,4) sowie die Informationen über die Selektionen (4,4,5) und Vorlaufparameter (4,5,6), die Suche (4,6) bietet den flexiblen und kontrollierten Zugang zu den Dateien (4,6,5) mit der Prüfung von Inhalten (4,6,5,3), ihrem Aufbau (4,6,5,4), Unterlassungswerten (4,6,5,2) und der Präsentation (4,6,5,5) an sowie deren Speicherung (4,6,5,1). Die Suche (4,6) gliedert sich für das Fenster noch weiter auf in Suchkriterien (4,6,3), Suchverfahren (4,6,4), Suchergebnis (4,6,2) und Suchpräsentation (4,6,1).
  • Die Anordnung, die Suche vor die Datei zu schalten, begründet sich in der Tatsache, dass Suchen meist über mehrere Datenquellen hinweg erfolgen können.
  • 5.4. Detaillierte Beschreibung der Erfindung aus Funktionssicht
  • Das Fenster selbst strukturiert sich dann in zwei Subsysteme (Komponenten, komplexe Objekte):
  • 4,3) Subsystem FensterAPI = Präsentation der bekannten Funktionen durch das „Fenster"
  • Das API stellt den Zugang zum Fenster als Schnittstelle für System und Anwender dar. Es empfängt die Befehle der Anwender und die Nachrichten des Systems, koordiniert sie und sendet erforderliche Befehle und Nachrichten an das System ab.
  • Dabei muss es nicht vollständig im Fenster selbst integriert sein, auch Menüs, Toolbars oder sonstige Kontrollpaneele, die Funktionalitäten des Fensters verwenden, werden von diesem Subsystem gesteuert.
  • 4,3,1) RechteMaus = Darstellung des „FensterAPIs"
  • Die RechteMaus-Funktion wird in modernen Dialogsystemen angeboten, um den Anwendern die genau für einen ausgewählten Punkt zutreffenden Verarbeitungen anzubieten. Gelegentlich werden auch spezielle Informationen hinzugefügt, um einen umfassenden Überblick zu gewähren.
  • Diese Funktion bestimmt nicht nur die für ein ausgewähltes Objekt des Fensters zutreffenden, berechtigungskonformen Verarbeitungen des Fensters oder der Datei („Feldaufbau"), sondern bei Bedarf auch die anzuzeigenden Informationen („Feldaufbau", „Feldaufbereitung") aus den Metadaten für die gesamte Datei. Für die Anzeige dieser Auflistungen wird in der Regel ein Popup-Menü verwendet, das für die Weiterleitung der gewünschten Aufgabenstellung sorgt.
  • 4,3,2) Initialisierung = Vorbereitung der „Darstellung", erste „Suche"
  • Diese Funktion steht am Anfang jeder Fensterverarbeitung. Sie wird vom Kommunikations-Subsystem oder im Falle der Client-Verarbeitung vom rufenden Fenster desselben Typs gestartet, und sorgt für die notwendige Anbindung an das System, im Speziellen an die Datei, deren Inhalte es aufzubereiten hat.
  • Auch eventuelle externe API-Elemente wie Menüs oder Toolbars werden von dieser Funktion installiert und ihre Kontrollelemente in die Verarbeitung eingebunden.
  • Das dateispezifische Layout des Fensters wird über das Datei-Subsystem („Feldaufbereitung") ermittelt und realisiert und die erste Suche durchgeführt, falls das Anwender-Subsystem für diese spezielle Person bereits eine Selektion zur Verfügung stellt. Die gefundenen Datensätze werden dann in der gewünschten SuchAufbereitung zur Verarbeitung angeboten.
  • 4,3,3) Verlassen = Entfernung der Instanz des „Fensters" mit Kontrollabgabe
  • Wird das Fenster geschlossen, so schließt es seine externen API-Elemente und meldet sich beim System ab, speziell bei seiner Datei.
  • 4,3,4) Subsystem Fenster = Ressource des „Systems" zur „Darstellung" und „Fortschreibung" für und durch „Anwender"
  • Das Fenster stellt die eigentliche Oberfläche dar, die als Schnittstelle zu den Anwendern dient (s.u.)
  • 4,3,5) Controls = Elemente des „Fensters" für die „Anwender"
  • Fenster (Windows) gestatten Anwendern in der Regel auf vielfältige Art, ihre Anforderungen zu übertragen: per Klick, Doppelklick, per Schalter (Buttons diverser Art) oder Auswahlen, die auf vom System gestellte Ereignisse reagieren (Events).
  • Die Funktionalität „Controls" sammelt alle Ereignisse, ordnet sie und leitet sie regelkonform an eine ausführende Stelle im Fenster oder über das Kommunikationssystem weiter.
  • Diese Konzentration der Ereignissteuerung auf einen Punkt hat den Vorteil, dass bei Anpassungen des Fensters an die serviceorientierte Architektur die jeweils nötigen Adaptionen nur an einer einzigen Stelle berücksichtigt werden müssen. Weiterhin ist es bei einer Fehlersuche hilfreich, einen Checkpoint zu haben, an dem die fehlerhafte Verarbeitung aufgespürt werden kann.
  • 4,3,6) Popup = Darstellung von „Listen"
  • Listen sind normierte Inhalte seitens des Systems, der Datei oder des Fensters selbst. Die Funktion Popup ermittelt nicht nur diese Listen beliebiger Herkunft, sondern bringt sie unter Verwendung der „Sprache"- und „Text"-Schnittstellen auch in eine anwendergemäße Form und stellt sie als temporäre Menüs oder Listenfelder dar. Weiterhin erlaubt sie je nach Bedarf und Berechtigung die Auswahl einzelner oder mehrerer Listenelemente und bestimmt ein eventuell auszuführendes Ereignis („Controls").
  • 4,3,4) Subsystem Fenster = Ressource des „Systems" zur „Darstellung" und „Fortschreibung" für und durch „Anwender"
  • Das Fenster stellt die Oberfläche dar, auf denen die Elemente positioniert werden können, die für Anwender von Bedeutung sind, weil sie entweder Inhalte anzeigen oder Befehle empfangen können. Deshalb gehört zu seinem Aufgabenbereich auch der Aufruf eines untergeordneten Fensters gleichen Typs, da es sich im einfachsten Fall zwar um ein eigenständiges, identisches Fenster handelt, moderne Entwicklungsumgebungen jedoch auch die Möglichkeit von Fenster-Komponenten bieten, die als integrierter Bestandteil eines übergeordneten Fensters erscheinen können.
  • 4,3,4,1) Klartext = „Texte" des „Fensters"
  • Für die einzelfallunabhängigen Fensterfelder, also solche, die nicht von der bearbeiteten Datei abhängen, sondern für die korrekte Funktion des Fensters selbst erforderlich sind wie beispielsweise die Möglichkeit, einen Druck zu starten, müssen ebenfalls Informationen hinterlegt werden. Es werden erklärende Texte in jeder gewünschten Form (Hilfetext, Statuszeilentext, Tooltip) und in anwendergerechter Aufbereitung für jedes Feld und jeden eigenständigen Feldbereich benötigt, praktischerweise legt diese Funktionalität jedoch auch noch die Funktionen fest, die von den betreffenden Feldern/Buttons ausgeführt werden müssen und welche Fehler dabei möglich sind, da in modernen Umgebungen auch Methodenaufrufe als Metadaten (sogar in einfacher Textform) hinterlegt werden können.
  • 4,3,4,2) Client = untergeordnete Instanz desselben „Fensters"
  • Ein Client wird vom Fenster aktiviert, wenn Anwender oder der Stand der aktuellen Verarbeitung die Inhalte einer anderen Datei verlangen wie beispielsweise bei der Normierung von Feldinhalten, die sich nur auf Feldwerte einer anderen Datei beziehen dürfen und somit eine Aufbereitung erfordern, die über die Standard-Datei der „Listen" des Systems hinausgeht.
  • 4,3,4,3) ClientTransfer = Übertragung von „Inhalten" zwischen „Client" und „Fenster"
  • Die Kommunikation zwischen Client und Fenster muss nicht über das Subsystem „Kommunikation" erfolgen, da es sich typgemäß um dasselbe Fenster handelt. Somit sind beiden Partizipanten die Variablen und Methoden des anderen bekannt und können direkt verwendet werden.
  • 4,3,4,4) Darstellung = Präsentation der „Inhalte" durch das „Fenster"
  • Diese Funktionalität des Fensters setzt die Vorgaben des Dateisubsystems hinsichtlich der Feldaufbereitung um. Im Gegensatz zur Funktion „Initialisierung" des FensterAPIs dreht es sich hier nicht um Layoutfragen wie beispielsweise Positionierung und Beschriftung des Feldes auf der Oberfläche, sondern um die Aufbereitung der Felder und Feldwerte selbst. Falls implementiert, kann diese Funktion auf die gepufferte Information der „SuchAufbereitung" zugreifen, ansonsten muss sie die jeweiligen Schnittstellen der Anwender- und Dateisysteme selbst ansprechen: Erklärende Feldtexte wie Hilfetexte, Tooltips oder Meldungen müssen bestimmt und bei Bedarf angezeigt werden sowie die Feldwerte gemäß ihres Typs und der Lokalisierungsangaben („Sprache") aufbereitet und zur Verfügung gestellt. Zahlen werden formatiert, Texte gemäß ihrer Vorgaben („Feldaufbereitung") mit oder ohne Schlüsselwert angezeigt, sonstige Objekte nach ihren spezifischen Darstellungsformen verbalisiert oder präsentiert.
  • Diese Funktion liefert dabei nicht nur die visuelle Präsentation des Feldes je nach Typ als Zeichenkette, Zahl, Liste oder sonstigem Objekt, sondern auch die dazugehörigen Verarbeitungsmöglichkeiten (für „Controls"), da die erforderlichen Methodenaufrufe als Metadaten hinterlegt sein müssen („Feldaufbau"). Zeichen und Zahlen können nach Bedarf und Berechtigung editierbar sein, Listen können sortiert, selektiert und verändert werden und für die sonstigen Objekte die hinterlegten Verarbeitungsprogramme (Editoren) aufgerufen werden, um die Ergebnisse vollständig anzuzeigen oder zu manipulieren.
  • Zur Darstellung gehören jedoch nicht nur die einzelnen Dateifelder, sondern auch die gesamte Datei. Darunter fallen den Kontext erklärende Beschreibungen wie Hilfetexte, Tooltips oder Meldungen, aber auch die Präsentation von individuellen Methoden, die für eine spezifische Datei erforderlich sind, soweit sie den Anwendern zur Verarbeitung angeboten werden müssen.
  • 5.5. Konstruktionsmerkmale der Erfindung
  • Aus der Beschreibung der Erfindung aus Aufgabensicht ergab sich eine Terminologie von 37 Begriffen (systemrelevanten Prozessbausteinen) für ein System inklusive der Erfindung, das zum optimalen Funktionieren der Erfindung aus sieben komplexen Objekten mit dem folgenden Aufbau und Zusammenhang in Baumstruktur besteht, wobei der Fokus bei der Bestimmung der Systemfunktionen darauf lag, die Anforderungen für die Erfindung zu liefern. Weitere vom System und seinen sonstigen Subsystemen angebotene Funktionalitäten blieben deshalb außer Acht.
  • Die oberste Ebene der Hierarchie, der Wurzelknoten, ist das System:
  • Figure 00250001
  • Figure 00260001
  • Ein solches System hat ein Szenariengewicht (die Summe aller Längen = der kürzeste Abstand zwischen zwei einzelnen Begriffen) von 4680 und nähert sich damit dem rein strukturell berechneten Idealgewicht von 4662 bis auf 0,4% an. Die maximale Länge zwischen zwei Begriffen beträgt bei dieser Struktur aus 7 Objekten 6, da die Länge 1 zwei (systemrelevante) Funktionalitäten desselben Objekts verbindet. Wegen der hohen Prozesspräzision sind deshalb im Fehlerfall maximal 6 Funktionsbereiche/Prozessabschnitte zu prüfen, ein unkontrollierter Wirkungsverlauf („Objektspaghetti") wird dadurch vermieden.
  • Das Fenster selbst besteht aus zwei hierarchisch angeordneten Objekten mit insgesamt 11 Begriffen (systemrelevanten Aufgabengebiete, externen Methoden).
  • 6. Gewerblicher Nutzen der Erfindung
  • Mit den geforderten Voraussetzungen und den angebotenen Fenster-Funktionalitäten ist es möglich, ein einziges Subsystem Fenster inklusive Fenster-API für alle Inhalte zu verwenden, die die geforderten Dateimethoden aufweisen.
  • Die Präsentation von Inhalten kann damit zu einem Service gemacht werden, der den modernen Anforderungen an serviceorientierte Architekturen entspricht, völlig unabhängig davon, wie die interne Ausarbeitung der jeweiligen Schnittstellen tatsächlich gestaltet ist.
  • So kann eine erste Version des Universalfensters vielleicht nur Texte, Zahlen und Listen verarbeiten, weil die zugrunde liegende Infrastruktur keine externen Programme aufzurufen vermag, eine zweite Version jedoch präsentiert sonstige Objekte gemäß deren spezifischer Verarbeitungsprogramme (Editoren), sobald das Dateisystem die erforderlichen Metadaten für die vom System gestellte Anbindung von Fremdprogrammen (siehe „SystemBefehl") aufweist. Die vorausgesetzte strenge Schnittstellenorientierung macht es nämlich möglich, problemlos die eine gegen die andere Version auszutauschen, je nach Entwicklungsumgebung möglicherweise sogar ohne manuelle Eingriffe, was eine bequeme Fortentwicklung von Software gestattet. Dies ist gerade in der letzten Zeit rapider Verbesserungen auf dem Internet-Sektor ein wesentlicher Vorteil, um konkurrenzfähig zu bleiben, zumal ein solches Fenster Plattformunabhängigkeit dadurch fördert, dass es sich auf die Präsentationsaufgaben konzentriert (siehe „unkonventionelles Ausführungsbeispiel").
  • Der gewerbliche Nutzen von Visualisierung ist, wie bereits angeführt, in vielen Patenten und praktischen Anwendungen bewiesen und zwar hinsichtlich Zuverlässigkeit der Produkte sowie ihrer kostengünstigen Erstellung und Wartung. Auch der durch diesen gewerblichen Nutzen hervorgerufene Trend, die Visualisierung in einer Weise durchzuführen, dass ganze Problembereiche zu Services („intelligente Einheiten" wie diejenigen der Grid-Technologie) gestaltet werden, wird besonders deutlich an zwei großen Firmen dieser Branche sichtbar: IBM mit seinem Produkt „Websphere Product Center", das alle IT-Aufgaben rund um ein Produkt sammelt sowie SAPs „Master Data Management", das alle IT-Aufgaben rund um Stammdaten-Objekte sammelt, dienen beide dem Zweck, diese Funktionen nicht nur einem Software-System, sondern vielen verschiedenen anzubieten und zwar immer mit demselben Inhalt und immer mit demselben Verhalten, unabhängig davon, wie Anwender sich ihre Produkte oder Stammdaten anzusehen oder zu verarbeiten wünschen.
  • Das Besondere gegenüber den bisherigen Komponenten und/oder Webservices ist genau der Unterschied zwischen der bisherigen Fenstergestaltung und dem Universalfenster: Es ist die Abstraktionsebene der Funktionalität, die isoliert wird. Beide erwähnten Produkte stellen nicht nur einen geringen Umfang an Funktionen und Daten zur Verfügung, die erst zu einem größeren Verbund zusammengepuzzelt werden müssen, um eine problembezogene Aufgabe lösen zu können, sondern orientieren sich an zentralen Objekten einer ERP-Umgebung, die vielfältig strukturiert sind und noch vielfältiger verwendet werden. In solchen Fällen alle diese Objekte betreffenden Funktionalitäten zu sammeln, nimmt den verwendenden Applikationen nicht nur das Problem ab, die Komplexität der Objekte zu beachten, es sichert daneben auch den oben erwähnten „Gleichklang" – es sichert die Information der Objekte dadurch, dass es aus denselben Anfangszuständen immer wieder dieselben Endzustände erzeugt, was bei redundanter Funktionsausführung in unterschiedlichen Applikationen nicht immer gewährleistet werden kann.
  • Gerade SAPs Produkt ist dem für das Universalfenster vorausgesetzten Subsystem „Datei" vergleichbar. Soweit solche zentralen Prozesse ihre Repräsentation beinhalten, ist eine derartige Umgebung bereits imstande, auch die Präsentationsaufgaben zu isolieren, um die volle Flexibilität der serviceorientierten Architektur auszunutzen. Das MVC-Modell kann damit für ein ganzes System und nicht nur für einzelne Bausteine als Grundstruktur dienen.
  • Das Universalfenster weist als Visualisierung von Präsentationsaufgaben einer bestimmten Art (graphisches Dialogsystem zwischen Anwendern und Datei) alle Vorteile der Visualisierung auf. Da alle von dem Fenster benutzten Objekte (Variable und Methoden) unabhängig vom Einzelfall der Datei gestaltet sind, weil alle dateispezifischen Elemente in das Dateisystem ausgelagert wurden, ist es tatsächlich nicht mehr erforderlich, für jede neue Dateiverwaltung ein eigenes Programmobjekt zu erzeugen. Es kann immer wieder dasselbe Objekt verwendet werden.
  • Dies ist besonders nützlich für verteilte Umgebungen, denn das Fenster kann überall komplexe Präsentationen liefern, solange es in die Kommunikationsstruktur der Applikation integriert ist. Es kann in einfachen Ausführungen auf mobilen Endgeräten installiert werden und erspart gegenüber der bisherigen Praxis, nur Fensterkomponenten zur flexiblen Komposition eines Fensters zu verwenden, Bandbreite, da alle fenster- und system-spezifischen Daten und Funktionen in der gewünschten Kombination permanent auf dem Endgerät vorgehalten werden können, ohne ständig neu berechnet werden zu müssen. Auch die Metadaten der Datei oder der Anwender werden nur einmal beim Initialisieren der jeweiligen Fensterinstanz benötigt. Durch die Tatsache, dass die serviceorientierte Architektur nur ein einziges Präsentationsobjekt für diese Fälle verwalten muss, werden aber auch Web-Anwendungen vereinfacht, da sie die einfachen Präsentationsaufgaben reduzieren können auf die Interaktion des Fensters mit den jeweiligen Subsystemen Anwender, Kommunikation und Datei der jeweiligen Anwendung.
  • Das Universalfenster repräsentiert somit einen so genannten „Rich Client", denn es stellt mehr Funktionen als ein einfacher Browser zur Verfügung, ohne die gesamte Applikation enthalten zu müssen. Rich Client-Architekturen werden im Moment gewerblich von der IBM genutzt in ihrem Produkt „Workplace" (s. "IBM Workplace Client Technology: Delivering the Rich Client Experience", White Paper). Durch seine Fokussierung auf die Präsentationsaufgaben von Dateien gibt das Fenster zwar die Vielseitigkeit auf, die Rich Client-Systeme durch das Herunterbrechen von Fenstergestaltung auf Komponentenebene bietet, es offeriert jedoch im Ausgleich für einen Großteil der benötigten Aufgaben eine fertige Lösung, die nicht mehr in jedem einzelnen Fall dynamisch bestimmt werden muss mit all den Vorzügen einer zentralen Verwaltung, die durch IBM's „Product Center" und SAPs ,MDM" angezeigt werden.
  • Ein weiterer gewerblicher Nutzen liegt in der Arbeitsersparnis für bestehende, nichtserviceorientierte Architekturen darin, dass der Umstieg auf diese moderne Infrastruktur erleichtert wird. Ein Vorzug der SOA ist es schließlich, über Services die Anbindung von so genannten Legacy-Systemen (Software älterer Bauweise) integrieren zu können, was besonders bei betriebswirtschaftlicher Software von hoher Bedeutung ist. Eine solche Anbindung erlaubt eine schrittweise Umstellung der einzelnen, als Services verfügbaren Legacy-Systemen auf moderne Entwicklungsumgebungen, was in der Regel eine Vielfalt an einfachen Fenstern erfordert. Diese können zum großen Teil durch das einmalige Erstellen des Universalfensters zur Verfügung gestellt werden, das dann geradezu „Ersatzteil"-Charakter erhält.
  • Nicht zuletzt ist die Berücksichtigung und Zertifizierung der DIN EN ISO 9421 (Software-Ergonomie) einfacher, wenn für einen ganzen Fensterkomplex nur ein einziges Objekt zu beachten ist.
  • 7. Vorteilhafte Wirkungen der Erfindung
  • Die völlige Wiederverwendbarkeit des Universalfensters spart erheblich Arbeit gegenüber der bisherigen Vorgehensweise, denn selbst bei der umfassenden Verwendung von Templates oder Vererbung stellt das Endergebnis doch immer einen Einzelfall dar, der in seiner gesamten Konstruktion erstellt, getestet und bei notwendigen Anpassungen korrigiert (und wieder getestet) werden musste. Erfolgt diese Arbeit über Generatoren, weil beispielsweise Metadaten für Browseroberflächen verarbeitet werden müssen, so muss dieser Generator selbst nicht nur für jede Kombination an Einzelfällen ausgiebig getestet werden, sondern erfordert daneben bei jeder automatischen Erstellung Übertragungsvorgänge, die auch heute noch auf dem Internet zum Problem werden können.
  • Menschliche Arbeit kostet darüber hinaus Geld und deshalb heutzutage sogar Arbeitsplätze. Benutzt eine moderne serviceorientierte Architektur dagegen ein Universalfenster, so entfällt die Massenarbeit des „Hackens" von Programmcode für die vielen, ständig wiederkehrenden Fensteraufgaben, die billiger im Ausland erledigt werden kann. Was dagegen den Software-Entwicklern hierzulande verbleibt, ist eine flexible Umgebung, die den Kundenbedürfnissen leichter, günstiger und zuverlässiger angepasst werden kann, sodass sie ihren Unternehmen die Möglichkeit bieten, nicht nur konkurrenzfähig zu bleiben, sondern durch den direkten Kontakt mit Kunden und ihren Wünschen auch die Missverständnisse zu vermeiden, die durch die Auslagerung an externe Programmierer zu befürchten sind und die selbst nur kostenträchtig vermieden werden können. Weil eine serviceorientierte Architektur immer auch flexibel ist, stellt der direkte Kontakt zum Kunden darüber hinaus nicht nur die Möglichkeit dar, dessen Wünsche und Anforderungen sehr präzise zu erfahren, sondern sie auch rasch und qualitätsbewusst umzusetzen und damit einen deutlichen Wettbewerbsvorteil vor den Konkurrenten zu erzielen, die noch nach der üblichen Weise Software gestalten.
  • Die völlige Wiederverwendbarkeit des Universalfensters sichert neben der Kostenersparnis eine hohe Fehlerresistenz, da das Fenster nicht nur für einen einzigen Einzelfall einer Datei ausgeführt und damit „getestet" wird. Die Erfahrung zeigte, dass nach einigen Dateien, deren verschiedene Individualcharakteristika von dem Fenster aufbereitet wurden, die möglichen Wirkungsketten (intern und extern) umfassend durchgespielt wurden, sodass Fehler, die in vielen Softwaresystemen einfach nur dadurch verbleiben, weil sie weder im Test noch in der üblichen Verarbeitung auftauchen, sehr eingeschränkt werden können.
  • Auch die Benutzerfreundlichkeit ist ein Vorteil, der neben der gebotenen Zuverlässigkeit aus der Wiederverwendbarkeit stammt: Kennen die Anwender ein Fenster, so kennen sie alle. Zwar mögen sie die spezifischen Einzelheiten der bearbeiteten Datei noch nicht entdeckt haben, sie wissen aber, wie das Fenster ihnen Fehler oder Hinweise mitteilt oder Zugänge zu Funktionen offeriert, die für diese Inhalte spezifisch sind und deshalb in serviceorientierten Architekturen von den Dateien selbst angeboten werden. Letzteres erfolgt wieder unter dem Gesichtspunkt eines zentralen Zugangs zu Informationen, der von der strengen Schnittstellenorientierung gefordert wird, weil die dateispezifischen Funktionen damit jeder Form von Verarbeitung in exakt derselben Version zur Verfügung stehen wie dem Universalfenster. Die früher häufig aufgetretene Erscheinung, dass ein Fenster einen anderen Fehlertext ausgibt als das andere oder dass auf dem Druck ein anderer Wert erscheint als auf dem Bildschirm, ist dadurch schlicht unmöglich gemacht worden.
  • 8. Ausführungsbeispiel
  • 8.1. Bevorzugtes Ausführungsbeispiel
  • Die vorliegende Erfindung wird an Hand eines bevorzugten Ausführungsbeispieles näher erläutert.
  • Wie in betriebswirtschaftlicher Software zumeist verwendet, soll ein relationales Datenbank-Managementsystem für die Speicherung und Verwaltung der Daten zuständig sein, neben der graphischen Oberfläche stehen Menüs und Toolbars zur Verfügung, auch temporäre, aufklappbare Menüs (Popups) und umfassende Tabellenfunktionen können vom Fenster genutzt werden, sodass Listen optisch wie eine Aufreihung einzelner Felder aussehen können, wobei sie zellenweise unterschiedlich bestimmbar bleiben.
  • Dann enthält das Fenster fünf Teilbereiche, die im Realisierungsbeispiel (1-9) in unterschiedlichen Versionen dargestellt werden: Der erste Teilbereich dreht sich um die Suchkriterien, die über die Suchfunktion „Suchkriterien" der Datei bestimmt und falls vorhanden, vom Anwender-Subsystem „Selektion" mit ihren letzten Vorgaben versehen werden können.
  • Diese Suchkriterien werden in diesem Ausführungsbeispiel als eine Liste angelegt, deren einzelne Zeilen den Namen des jeweiligen Suchfeldes in der gewünschten Sprache angeben, den Typ des Feldes bestimmen, korrekt ausgeben und zur Eingabe durch die Anwender anbieten sowie gegebenenfalls seine Normierung, also sein Wertevorrat (Suchfunktion „Suchkriterien"). Dabei werden Normierungen über einen eigenen Druckknopf (Schalter, Button) angezeigt, um den Anwendern zu signalisieren, dass hier eine Suche über definierte Werte möglich ist (in 3 als Buch dargestellt). Auch die möglichen Suchverfahren werden über solch eine optisch deutlich erkennbare Schaltstelle zur Übersicht und Auswahl angeboten (Suchfunktion „Suchverfahren"). Diese Schaltstelle kann als Button oder Klartext der selektierten Suchoption ausgearbeitet sein (in 3 als „im Text" ersichtlich).
  • Die Suche selbst wird bei Bedarf über die Funktion „Controls" ausgelöst, die von dem Such-Button (siehe Teilbereich 5, 1) aktiviert wird.
  • Der zweite Teilbereich, der Übersicht halber unter dem ersten angeordnet, listet die gefundenen Datensätze gemäß der Suchfunktion „SuchAufbereitung" auf, zusammen mit den normierten Werten derjenigen Felder, die auf einen Wertevorrat zurückgreifen. Über die verschiedenen Funktionsmöglichkeiten (Mausaktionen wie Klick, Doppelklick oder Rechte Maus, Buttons oder Ereignisse, die von Tastaturaktionen ausgelöst werden) bestimmt die Feld-API-Funktion „Controls" dann, was auszuführen ist wie zum Beispiel das Anzeigen normierter Werte, die auf Anforderung der Anwender (wie einen Klick auf die entsprechende Zelle) als Popup-Menü zur Ansicht angeboten werden(Fenster-API „Popup", 8). Auswahl wird ermöglicht, falls die Zeile editierbar ist, falls also Werte verändert werden dürfen. Werden Feldwerte verändert, ruft das Fenster die Prüfroutinen der jeweiligen Datei auf („Check") und meldet gegebenenfalls Fehler.
  • Der dritte Teilbereich stellt einen einzelnen ausgewählten Datensatz gemäß der Feldaufbereitung dar (Dateifunktion „Feldaufbereitung"), wobei die Beschreibungen sprach- und feldabhängige Texte sind. Normierte Felder werden je nach Vorgabe als Schlüsselwerte und/oder als sprachenabhängige Texte gezeigt und sonstige Objekte gemäß den Vorgaben in verbalisierter oder miniaturisierter Form präsentiert (4). Dieser dritte Teil wird in diesem Ausführungsbeispiel auf einem zweiten Optionsfenster realisiert, da Datensätze gelegentlich sehr umfangreich werden können, wobei die Variabilität der Datenfelder erneut über eine flexible Listengestaltung ermöglicht wird. Bietet die Systemumgebung darüber hinaus Methoden für eine sehr flexible Oberflächengestaltung an, so ist auch denkbar, die fünf Teilbereiche in veränderlicher Größe variabel zu positionieren, sodass jeder gleichzeitig zu sehen ist. Auch hier gilt, dass die Felder gemäß den verschiedenen Funktionsmöglichkeiten überwacht und über „Controls" verwaltet werden.
  • Der vierte Teilbereich ermöglicht dann eine detaillierte Feldbehandlung gemäß den Vorgaben der „Feldaufbereitung" (falls implementiert, via gepufferter Information aus der „Suchaufbereitung"). Dazu sind Fenster-Objekte geeignet, die analog den Optionsfenstern eine „Schichtenstruktur" aufweisen, bei der jede Schicht eine unterschiedliche Bauweise hat, jedoch nur die ausgewählte Schicht angezeigt wird. So kann das Fenster sich auf die verschiedenen, vom System zur Verfügung gestellten Feldtypen einrichten, indem es für jeden möglichen Datentyp eine standardisierte Verarbeitung anbietet (2, 4). Wird ein Feld für diese Detailsicht dann ausgewählt, bestimmt das Fenster über interne Funktionen anhand des Feldtyps den korrespondieren Fensterfeld-Typ, bereitet die anzuzeigenden Inhalte gemäß „Feldaufbau" und „Feldaufbereitung" auf, falls die Darstellung im gesamten Datensatz von der Detailsicht abweicht (ansonsten kann sie übernommen werden), und bietet sie den Anwendern bei Bedarf zur Verarbeitung an. Über die verschiedenen Funktionsmöglichkeiten bestimmt die Feld-API-Funktion „Controls" dann, was auszuführen ist (7). Werden Feldwerte verändert, erfolgt erneut eine Prüfung (Dateimethode „Check").
  • Der fünfte und letzte Teilbereich ist ein eher „logischer" Bereich, da er in jedem Fall sichtbar/aktiv sein muss: Es ist der Bereich der verfügbaren Funktionen, die nicht direkt von Feldern abhängen (wie Klicks, Doppelklicks, Rechte-Maus, Tastatur oder auch Buttons für normierte Werte). Dabei sind graphisch symbolisierte Funktionen, die auf Teilbereiche beschränkt sind, deutlich kenntlich zu machen. Im Falle des beschriebenen Ausführungsbeispiels, das zwei Optionsfenster benutzt, wird dies einfach dadurch erreicht, dass solche Funktionen nur auf dem Optionsfenster präsentiert werden, auf dem sie benötigt werden (1, 2). Es sind aber auch Lösungen mit Popups (temporären Menüs) oder Toolbars denkbar, bei denen die Ansammlung der Funktionen als Auflistung oder Buttonleiste offeriert wird, wobei letztere sogar als eigenes Fenster realisiert werden könnte.
  • Ein typischer Fall einer auf Teilbereiche beschränkten Funktion ist der Button „Suche", da er nur im Zusammenhang mit den „Suchkriterien" Sinn macht, während Funktionen, die sich mit der Prüfung, dem Bestätigen oder Abbruch der Arbeiten beschäftigen, auf jedem Teilbereich erforderlich sind, auf dem Werte geändert werden können.
  • 8.2. Unkonventionelles Ausführungsbeispiel
  • Um zu demonstrieren, dass die Erfindung tatsächlich ein Wirkungsgefüge beschreibt, wird ein zweites, unkonventionelles Ausführungsbeispiel vorgestellt, dessen physikalische Wirkungen zwar völlig verschieden sind und mit chipgesteuerten elektrischen Strömen oder Tastaturanschlägen wenig zu tun haben, dessen Anforderungen an Zustände jedoch wie bei allen Informationen identifizierbar und wiederholbar sind und das demnach bei vorhandener Möglichkeit, die steuernden Metadaten zu adaptieren, das Modell der Erfindung unverändert übernehmen kann.
  • Dieses zweite Ausführungsbeispiel mag aus dem Bereich Kunst oder kreatives Marketing stammen. Die Systemumgebung wird dabei über Personen und geeignetes Material gestellt und kann entweder ein Theater oder Museum (im Falle der Kunst) oder eine große Fensterscheibe eines Warenhauses mit dahinter liegenden Räumlichkeiten sein (im Falle des Marketing).
  • Das System (Theaterleiter oder Abteilungsleiter des Warenhauses) entscheidet dann über den Start des Fensters (Fenster-API „Initialisierung"), indem es die verantwortliche Person beauftragt zu beginnen.
  • Diese Person wird dann entweder den Vorhang im Theater öffnen oder den Sichtschutz vor der Fensterscheibe entfernen. Die Scheiben können dabei hinsichtlich der fensterspezifischen Funktionen bereits vorgefertigt sein (vgl. 1 und 2, wenn auch künstlerisch ansprechender), das heißt, dass Zonen für die Suchkriterien und die Suchliste sowie den gesamten Datensatz und die Felddetails bereits optisch erkennbar voneinander getrennt sind. Die Möglichkeiten der Anwender, ihre Wünsche kundzutun (Events), werden über Glocken verschiedener Klangfarbe realisiert.
  • Diese verantwortliche Person („Initialisierung) kennt nun das „Motto" des Tages bereits, also die Spezifizierung des Angebots an die Kunden/Zuschauer. Für ein Theater mag dies das Thema „Schauspielstücke des William Shakespeare" sein, für eine Marketing-Abteilung „was brauche ich für den Sommerurlaub". Das Motto des Tages wird dabei realisiert durch einige Körbe voller Schildchen und Utensilien, die verborgen im Hintergrund der Scheibe zur Verfügung stehen.
  • Gemäß dem Motto des Tages versieht die verantwortliche Person die Suchkriterien mit Texten, die den Zuschauern sagen, wie und was sie aus dem vorhandenen Angebot auswählen können. Liegen dabei nur bestimmte Varianten vor („Listen"), so wird dies durch eine (diesmal nicht temporäre) Auflistung gekennzeichnet, die neben dem entsprechenden Feld aufgezeichnet wird und die es ermöglicht, die einzelnen Zeilen durch Häkchen oder Durchstreichen mithilfe der den Zuschauern angebotenen Zeichenstifte auszuwählen.
  • Auch die Such- und Feldliste wird gemäß dem „heutigen Motto" mit Texten versehen, um den Zuschauern die Einzelheiten offen zu legen. Damit ist diese Person mit ihrer Arbeit fertig und kann gehen..
  • Spielen die Zuschauer mit, werden sie mit den Zeichenstiften entweder in den dafür vorgesehenen Feldern der Suchkriterienzone Wünsche eingeben wie „Rollenname = Julia" oder „Urlaubswunsch = Baden". Ein Glockenzeichen gibt das Ende der Aktion an und eine Person („Controls") mit gutem Gehör, die diese Glockenklänge deutlich unterscheiden kann, gibt den entsprechenden Befehl mit den spezifizierten Anforderungen an die Leute im Hintergrund weiter, die vor den Körben sitzen und nun das Theaterstück „Romeo und Julia" suchen müssen oder die vom Kaufhaus angebotenen Badeorte. Alle passenden Schildchen und Utensilien werden dann an eine weitere Person übergeben, die den Namen des Theaterstücks oder der Badeorte in die Suchlistenzone der Glasscheibe heftet und beim Theaterstück die verschiedenen Rollen, den Abstrakt und die Beschreibung bzw. bei den Badeorten deren Länder, Fotos und Hotels den dafür vorbereiteten Feldern der Datensatzzone zuordnet, wenn die Zuschauer durch Durchstreichen oder Häkchen an der Suchliste anzeigen, dass sie Interesse an diesem speziellen Theaterstück oder Badeort haben.
  • Wenden sich die Zuschauer daraufhin den Details zu, so wird ihnen als „individuelle Dateimethode" bei der Auswahl der „Beschreibung" des Theaterstücks das gewünschte Drama vorgespielt oder bei der Auswahl „Land und Leute" ein exotischer Vertreter der Einheimischen des Badeortes vorgestellt.
  • Dieses unkonventionelle Ausführungsbeispiel zeigt, dass die Schnittstellenorientierung der modernen Virtualisierung tatsächlich die Möglichkeit bietet, dieselben Automatismen auf verschiedenen Plattformen anzubieten, solange eine Korrespondenz der Plattformen mit den erforderlichen Metadaten erreicht werden kann.
  • 8.3. Beschreibung der Zeichnungen
  • Die Zeichnungen stellen die Erfindung anhand eines einfachen Realisierungsbeispiels vor, das mit der Entwicklungsumgebung Omnis Studio© und einer SQL-verarbeitbaren Datenbank innerhalb einer Architektur umgesetzt wurde, die die zentralen Prozesse (wie System/Kommunikation oder Datei) anhand von metadatengesteuerten komplexen Objekte umsetzte und so demonstrierte, dass lauffähige Applikationen nicht viele Klassen benötigen, wenn die Metadatensteuerung auch Verhalten beinhalten kann.
  • 1: Suchkriterien und Suchfenster mit Funktionen in Button-Form (inklusive Tooltip) ohne Anbindung an eine Datei
  • 2: detaillierter Datensatz sowie Details eines Datenfeldes mit Funktionen (inklusive Tooltip) ohne Anbindung an eine Datei
  • 3: Suchkriterien und Suchfenster mit Funktionen (inklusive Tooltip) bei Anbindung an die Datei der Metadaten
  • 4: detaillierter Datensatz sowie Details eines Datenfeldes mit Fenster-Funktionen (inklusive Tooltip) bei Anbindung an die Datei der Metadaten. Zum Feldformat (hier eine Liste) gehörige Funktionen (Buttons) sind in die Details des Datenfeldes integriert
  • 5: Suchkriterien und Suchfenster mit Funktionen bei Anbindung an die Datei der Metadaten: individuelle Dateimethoden der Metadaten-Datei
  • 6: Suchkriterien und Suchfenster mit Funktionen bei Anbindung an die Datei der Metadaten: Methoden, die vom System, der Kommunikation oder Datei gestellt werden und dabei keine individuellen Methoden sind
  • 7: detaillierter Datensatz sowie Details eines Datenfeldes mit Funktionen bei Anbindung an die Datei der Metadaten: feldspezifische Methoden auf der Ebene der Felddetails
  • 8: Suchkriterien und Suchfenster mit Verarbeitung bei Anbindung an eine beliebige Datei: feldspezifische Methoden auf der Ebene der Suchliste
  • 9: verschiedene Instanzen des Universalfensters, Toolbar und Menü sind dem obersten Fenster zugeordnet

Claims (1)

  1. Das Universalfenster für die Präsentation von in Dateien gespeicherten Inhalten ist als Fenster (Window) Bestandteil von Computerprogrammen, speziell objektorientierten Dialogsystemen, die auf serviceorientierter Architektur basieren, wobei das Fenster als graphische Schnittstelle zwischen Programm und Anwender (GUI) Inhalte aus Dateien präsentiert und deren korrekte Verarbeitung erlaubt, wobei verschiedene Instanzen möglich sein können, gekennzeichnet dadurch: • dass das Fenster alle Aktivitäten des Systems und der Kommunikation sowie der Anwender und der Dateien ausgelagert hat, • dass das Fenster deshalb beliebig viele Dateien in seinen diversen Instanzen handhaben kann, wobei es Instanzen seiner selbst verwenden kann, • dass die ausgelagerten, systemrelevanten Aufgabenbereiche (Begriffe) unbeachtlich ihrer Implementierung über Schnittstellen seitens des Systems, der Kommunikation, der Anwender- und Dateiobjekte zur Verfügung stehen müssen, um die 11 systemrelevanten Aufgabengebiete des Fensters in der Form zu unterstützen, dass die Wirkungsketten zur Bewältigung der Fensteraufgaben minimiert werden, ohne dass der Zusammenhang aufgegeben wird, das heißt, dass jeder systemrelevante Baustein (Begriff) mit jedem anderen in Verbindung treten kann, sodass die gesamte (öffentliche) Funktionalität des Systems gewährleistet bleibt • dass diese 11 Aufgabengebiete des Fensters in zwei Gruppen eingeteilt werden können, deren eine vorwiegend der Interaktion des Fensters mit den Systembausteinen und den Anwendern dient, während die andere sich um die Präsentationsaufgaben kümmert • dass diese zwei Gruppen in einer kompakten Weise konstruiert sind, sodass ein für die benutzte Programmierumgebung nur wenig umfangreicher Programmiercode für die Lösung erforderlich ist (Vermeidung von „Spaghetti"-Code)
DE102004051956A 2004-10-26 2004-10-26 Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten Withdrawn DE102004051956A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102004051956A DE102004051956A1 (de) 2004-10-26 2004-10-26 Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102004051956A DE102004051956A1 (de) 2004-10-26 2004-10-26 Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten

Publications (1)

Publication Number Publication Date
DE102004051956A1 true DE102004051956A1 (de) 2006-04-27

Family

ID=36129011

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102004051956A Withdrawn DE102004051956A1 (de) 2004-10-26 2004-10-26 Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten

Country Status (1)

Country Link
DE (1) DE102004051956A1 (de)

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Cover Pages, Microsoft Extensible Apllication Markup Language (XAML), 06.10.2004,S.1-5 *
http://www.devx.com/webdev/Article/20834 In web.archive.org am 24.10.04 *
http://xml.coverpages.org/ms-saml.html In web.archive.org am 10.10.04 *
NIGEL,McFarlane:A Standards-based Look at XAML s Features, DevX, 20.04.04,S.1-5 *

Similar Documents

Publication Publication Date Title
DE10051645B4 (de) Prozesssteuersystem und Verfahren zum Kontrollieren eines Prozesses
DE102013207608B4 (de) Instrumentieren von Software-Anwendungen für die Konfiguration derselben
DE10121790B4 (de) Softwarekonfigurationsverfahren zur Verwendung in einem Computersystem
DE60319229T2 (de) Verfahren und system zur erweiterung der api eines dateisystems
DE69915661T2 (de) Prozesssteuerung
DE19940210B4 (de) Verfahren zum Herstellen eines Computersystems und zum Modifizieren einer grafischen Benutzeroberfläche, die von einem Betriebssystem kontrolliert wird
US7739292B2 (en) System and method for modeling and managing enterprise architecture data and content models and their relationships
EP3049920A1 (de) Verfahren und einrichtung zur automatisierten erzeugung und bereitstellung wenigstens einer softwareanwendung
DE19963673A1 (de) Verfahren, Systeme und Computerprogrammprodukte zur Dokumentenverwaltung für Software-Entwicklungssysteme
DE102010037750A1 (de) Dynamische Hyperlinks für Prozessregelsysteme
WO2003071455A2 (de) Engineeringverfahren und engineeringsystem für industrielle automatisierungssysteme
DE19628168A1 (de) Vernetztes multimediales Netz
DE102010007967A1 (de) Verfahren, Computerprogramm-Produkt sowie computerlesbares Speichermedium zur generischen Erstellung eines Strukturbaums zur Beschreibung eines IT-Verfahrens
WO2007022874A1 (de) System, verfahren und computerprogrammprodukt zur arbeitsflussbasierten datenverarbeitung
DE10119876A1 (de) Verfahren, System und Computerprorammprodukt zur Bereitstellung einer Jobüberwachung
DE10206903A1 (de) Softwareapplikation, Softwarearchitektur und Verfahren zur Erstellung von Softwareapplikationen, insbesondere für MES-Systeme
DE60019996T2 (de) System zum Koordinieren von Dokumenten und Aufgaben für einen Rechner
DE69709918T2 (de) Relationelle datenbank die in einer speicherstruktur compiliert und gespeichert ist
DE112008003861T5 (de) Systeme und Verfahren, um Software zum Herunterladen zur Verfügung zu stellen
DE102004051956A1 (de) Universalfenster (Window) für die Präsentation von in Dateien gespeicherten Inhalten
DE69925108T2 (de) Ableitung einer objektklasse durch vererbung, instanzierung oder klonierung
Burleson Oracle internals: tips, tricks, and techniques for DBAs
EP1490762B1 (de) Verfahren, software-produkt und system zur universellen computergestuetzten informationsverarbeitung
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
DE10247533A1 (de) Graphisches Entwerfen und automatisches Erzeugen für ein Verstehen der Semantik von Versorgungsketten geeigneter Kooperationsdienste für Versorgungsketten

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8139 Disposal/non-payment of the annual fee