DE102005025644A1

DE102005025644A1 - Verfahren und Vorrichtung zum visuellen Applikationenentwurf

Info

Publication number: DE102005025644A1
Application number: DE102005025644A
Authority: DE
Inventors: Michael San Leandro Travers; Dominic San Leandro John; John San Leandro Olson; Wilhelm San Leandro Thomas
Original assignee: MDL Information Systems Inc
Current assignee: Symyx Solutions Inc
Priority date: 2004-06-03
Filing date: 2005-06-03
Publication date: 2006-01-26
Also published as: GB2414834A; EP1603035A2; NL1029182C2; GB2414834A8; NL1029182A1; US20060064674A1; GB0511407D0; EP1603035A3

Abstract

Ein bevorzugtes Ausführungsbeispiel umfasst eine visuelle Sprache, die konfiguriert ist, um die Infrastruktur einer Mainstream-Plattform einzusetzen und um Nutzen von den Effekten zu ziehen, die mit einem großen Benutzernetzwerk und Anbietern von Komponenten zusammenhängen. In verschiedenen Aspekten ermöglichen die Systeme und Verfahren der vorliegenden Erfindung die Übersetzung von Stammfunktionen einer modernen objektorientierten Sprache in eine visuelle Form und bieten über eine grafische Schnittstelle Einrichtungen zur Zusammenstellung von Komponenten an. DOLLAR A Eine bevorzugte Sprache basiert auf der .NET-Plattform von Microsoft, lässt den Datenfluss und die Ereignisverbindungen zwischen .NET-Objekten zu und ermöglicht die Integration einer Vielzahl von ungleichartigen Komponenten, wie Abfragesystemen, Browsern und Webdiensten. Verschiedene Aspekte beinhalten die Verwendung von Reflektion zur Entdeckung und Aufdeckung von Objektmitgliedern, die Verwendung des .NET-Systems zur Einschränkung und Leitung der Auswahl des Benutzers, und Ausbreitungsalgorithmen, die Heuristiken verwenden, damit das System den Erwartungen des Benutzers entspricht.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Diese Anmeldung beansprucht die Unterstützung der vorläufigen US-Anmeldungsnummer 60/576,882, eingereicht am 3. Juni 2004 und vorläufige US-Anmeldungsnummer 60/676,086, eingereicht am 28. April 2005. Der gesamte Inhalt der oben genannten Anwendungen wird durch Referenznahme hierin beinhaltet.
BEREICH
Diese Erfindung bezieht sich auf die Bereiche der Formularbildung und Programmierung sowie der Abfrage und dem Durchsehen von Datenbanken.

Programmiersprachen benötigen, wenn sie über die Phase des Forschungsprototypen hinaus gehen sollen, eine große Anzahl an Entwicklern, um das Wachstum aufrecht erhalten zu können. Sprachen mit kleiner Anzahl an Entwicklern haben die Tendenz zum allmählichen Verschwinden. Dies ist besonders heute zutreffend, wo Sprachen sich mit schnell ändernden, anderen Technologien verbinden müssen.

Visuelle Sprachen, die auf kleine gebietsspezifische Kreise abzielen, haben es schwer, die kritische Masse zu erreichen, die notwendig ist, um Mainstream-Werkzeuge zu werden. Falls sie keine ausreichend große Nische finden, bleiben sie eine Einzelerscheinung. Außerdem sind derzeit verfügbare Client-Anwendungen gewöhnlich nicht für einfache Daten und Arbeitsflüsse als auch für komplexe Arbeitsflüsse und/oder einzigartige Datentypen verwendbar.

ZUSAMMENFASSUNG

Ein Aspekt der vorliegenden Erfindung richtet sich auf die Lösung des oben genannten Einsatzproblems. Außerdem besteht ein weiterer Aspekt der vorliegenden Erfindung in der Fähigkeit, eine laufende Anwendung anzupassen, indem eine beliebige Komponente oder Klasse abgelegt wird und im Verbinden der Methoden, Eigenschaften und Ereignisse dieser Komponente in die laufende Anwendung mit Hilfe von visueller Verbindung. Außerdem richtet sich die vorliegende Erfindung auf das Anbieten von XML-Definitionen für die Benutzerschnittstellen und die zugrunde liegende Logik. Außerdem richtet sich die vorliegende Erfindung auf das Anbieten eines Mechanismus' damit Formulare innerhalb einer Anwendung sowohl das Aussehen als auch das Verhalten der Hosting-Anwendung verändern, wann immer sie eingesehen werden. Außerdem richtet sich die vorliegende Erfindung auf das Anbieten eines neuen Denkmusters zur Interaktion mit Abfragehistorien und den Ergebnissen dieser Abfragen.

Ein bevorzugtes Ausführungsbeispiel umfasst eine visuelle Sprache, die konfiguriert ist, um die Infrastruktur einer Mainstream-Plattform einzusetzen und um Nutzen von den wirtschaftlichen Effekten zu ziehen, die mit einem großen Benutzernetzwerk und Anbietern von Komponenten zusammenhängen. In verschiedenen Aspekten ermöglichen die Systeme und Verfahren der vorliegenden Erfindung die Übersetzung von Stammfunktionen einer modernen objektorientierten Sprache in eine visuelle Form und bieten über eine grafische Schnittstelle Einrichtungen zur Zusammenstellung von Komponenten an.

Eine bevorzugte Sprache basiert auf der .NET-Plattform von Microsoft, lässt den Datenfluss und die Ereignisverbindungen zwischen .NET-Objekten zu und ermöglicht die Integration einer Vielzahl von ungleichartigen Komponenten, wie Abfragesysteme, Browser und Webdienste. Verschiedene Aspekte beinhalten die Verwendung der Reflektion zur Entdeckung und Aufdeckung von Objektmitgliedern, die Verwendung des .NET-Systems zur Einschränkung und die Leitung der Auswahl des Benutzers und Ausbreitungsalgorithmus, der Heuristik verwendet, damit das System den Erwartungen des Benutzers entspricht. Eine bevorzugte visuelle Sprache ist Teil der Visual Dataflow Language Base ("VDL-Basis" oder "Basis"). VDL-Basis kann durchgeführt werden, um bei der Entdeckung von Pharmamedikamenten behilflich zu sein.

In einem Ausführungsbeispiel bietet die vorliegende Erfindung eine visuelle Verbindungssprache an, die die kundenspezifische Anpassung von Formularen und Anwendungen bei der Ausführung zulässt. In einem anderen Ausführungsbeispiel können die vorliegenden Systeme und Methoden automatisch "Referenzen" zu einem beliebigen "Teil" (Komponente) in der Komponentenhierarchie erstellen, das die laufende Anwendung darstellt. Diese Referenzen können zu einem Formular hinzugefügt werden, um einen Nutzwert für die Verbindung des "Teils" anzubieten, auf das im Rest des Formulars Bezug genommen wird. Wie erkennbar ist, kann ein Nutzwert ein Objekt sein, das eine bestimmte Handlung vorschlägt und zulässt. Zum Beispiel kann der Netzwert eines Türgriffs sein, dass er die Handlung des Drehens und Ziehens vorschlägt und zulässt; der Nutzwert einer Taste auf einem Bildschirm kann das Anklicken vorschlagen und zulassen.

In einem Ausführungsbeispiel operiert Basis als eine Integration des visuellen Datenfluss-Paradigmas mit den Techniken der heutigen IDEs, Sprachplattformen und XML-basierten Seitenbeschreibungssprachen.

In einem Aspekt richtet sich die vorliegende Erfindung auf ein Computersystem, das aus einer Anzeigekomponente zur Anzeige eines visuellen Anwendungsdesigns besteht; einer ersten visuellen Programmierungskomponente mit einem exponierten ersten Programmierungsattribut; einer zweiten visuellen Programmierungskomponente mit einem exponierten zweiten Programmierungsattribut; und einer Verbindungskomponente, fähig um automatisch einen ersten visuellen Konnektor zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente zu erzeugen, basierend auf einer oder mehreren Beziehungen zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente.

In verschiedenen Ausführungsbeispielen ist der erste visuelle Konnektor eine Verbindung; der erste visuelle Konnektor wird des weiteren generiert, basierend auf den vom Benutzer eingegebenen Daten; der erste visuelle Konnektor wird zwischen dem exponierten ersten Programmierungsattribut und dem exponierten zweiten Programmierungsattribut erzeugt; der erste visuelle Konnektor wird als Reaktion auf Daten erzeugt, die angeben, dass ein Benutzer die erste visuelle Programmierungskomponente zur zweiten visuellen Programmierungskomponente gezogen hat; der erste visuelle Konnektor verbindet das exponierte erste Programmierungsattribut und das zweite exponierte Programmierungsattribut; der erste visuelle Konnektor wird als Reaktion auf Daten erzeugt, die angeben, dass ein Benutzer einen Mauszeiger von der ersten visuellen Programmierungskomponente zur zweiten visuellen Programmierungskomponente gezogen hat; der erste visuelle Konnektor verbindet das exponierte erste Programmierungsattribut mit dem exponierten zweiten Programmierungsattribut; die zweite visuelle Programmierungskomponente wurde zum visuellen Anwendungsdesign als Reaktion auf die Benutzereingabe hinzugefügt; das exponierte erste Programmierungsattribut umfasst einen ersten Komponenten-Pin, der erste Komponenten-Pin wird einem Benutzer angezeigt; der zweite Komponenten-Pin wird einem Benutzer angezeigt; der zweite Komponenten-Pin wird einem Benutzer nicht angezeigt; mindestens eines der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente ist eine Standardkomponente; die Standardkomponente ist kein Mitglied einer bestimmten Klasse; die Standard-Komponente wird während der Laufzeit hinzugefügt; mindestens eines der: (a) ersten visuellen Programmierungskomponente, (b) zweiten visuellen Programmierungskomponente und (c) des ersten visuellen Konnektors wird während der Laufzeit hinzugefügt; ein zweiter visueller Konnektor verbindet eine erste Benutzerschnittstelle mindestens mit einer der ersten oder zweiten visuellen Programmierungskomponente; jede der exponierten ersten und exponierten zweiten Programmierungsattribute sind Mitglieder einer bestehenden Plattform; die Plattform ist .NET; der erste visuelle Konnektor ist mindestens einer eines Datenkonnektors und ein Ereignis-Konnektor; das visuelle Anwendungsdesign ist mindestens eine: (a) Anwendung, (b) Formular und (c) Arbeitsfluss, der mehrere Formulare umfasst, mindestens eine der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente wurde durch Drag-and-Drop einer entsprechenden Komponente aus einer Komponenten-Bibliothek in das visuelle Anwendungsdesign hinzugefügt; das erste Programmierungsattribut umfasst mindestens: eine Klasse, System, Element, Steuerung, Funktion und Objekt; das System umfasst außerdem eine Teile-Manager-Komponente; die Teile-Manager-Komponente ist fähig, das visuelle Anwendungsdesign auf die Benutzerwartungen abzustimmen; das visuelle Anwendungsdesign wurde erstellt, damit es mit den Erwartungen des Benutzers, basierend auf Heuristik, übereinstimmt; die Teile-Manager-Komponente ist fähig, Ereignisaktivierungen zuzulassen, nachdem ein Datenschwellwert bei einer Komponente eingetroffen ist; die Teile-Manager-Komponente ist fähig, Ereignisse folgerichtig zu bestellen; der Teile-Manager ist fähig, die Datenübertragung zwischen den Komponenten zu managen; die Übertragung umfasst erste Tiefenausbreitung; die Übertragung umfasst erste Breitenausbreitung; mindestens eine der ersten visuellen und zweiten visuellen Programmierungskomponente ist eine Flasche; die Flasche speichert einen Datenwert und bietet Zugriff auf den Datenwert.

In einem anderen Aspekt richtet sich die vorliegende Erfindung auf ein System für die Modifikation eines visuellen Anwendungsdesigns, das eine erste visuelle Programmierungskomponente mit einem exponierten ersten Programmierungselement umfasst, wobei die erste visuelle Programmierungskomponente mit einem Mitglied der ersten Klasse übereinstimmt; eine zweite visuelle Programmierungskomponente ist mit der ersten visuellen Programmierungskomponente verbunden, wobei die zweite visuelle Programmierungskomponente mit einem Mitglied der zweiten Klasse übereinstimmt, das mit der ersten Klasse verbunden ist; eine modifizierende Komponente fähig zur Modifikation der ersten visuellen Programmierungskomponente als Reaktion auf Daten, die angeben, dass die zweite visuelle Programmierungskomponente modifiziert wurde.

In verschiedenen Ausführungsbeispielen wurde die erste visuelle Programmierungskomponente als Reaktion auf Daten modifiziert, die angeben, dass die zweite visuelle Programmierungskomponente nur modifiziert wurde, während sich die erste visuelle Programmierungskomponente im zulässigen Bereich befand; die erste visuelle Programmierungskomponente kehrt zu einem unmodifizierten Status zurück, wenn sich die erste visuelle Programmierungskomponente nicht länger im zulässigen Bereich befindet; die zweite visuelle Programmierungskomponente wurde dem virtuellen Anwendungsdesign hinzugefügt als Reaktion auf Daten, die angeben, dass der Benutzer die zweite visuellen Programmierungskomponente on das visuelle Anwendungsdesign gezogen und abgelegt hat; die erste visuelle Programmierungskomponente wurde als Reaktion auf Daten modifiziert, die angeben, dass ein Benutzer Komponenten aus einer Komponenten-Bibliothek in die zweite visuelle Programmierungskomponente gezogen und abgelegt hat; die modifizierende Komponente ist fähig, die erste visuelle Programmierungskomponente während der Laufzeit als Reaktion auf Daten zu modifizieren, die angeben, dass die zweite visuelle Programmierungskomponente modifiziert wurde, dass das visuelle Anwendungsdesign eines ist: (a) eine Anwendung, (b) ein Formular und (c) ein Arbeitsfluss, der mehrere Formulare umfasst.

In einem anderen Aspekt richtet sich die vorliegende Erfindung auf ein System für die Anzeige von Datenbankabfragen und Ergebnisse, das eine Anzeigekomponente umfasst, fähig zur Anzeige einer historischen Suchstruktur, die einen oder mehrere Knoten und einen oder mehrere Pfeile umfasst; und eine Abfragekomponente fähig zum Hinzufügen eines ersten Pfeils, der auf den ersten Knoten in der historischen Suchstruktur zeigt, der erste Pfeil stellt die erste Suchabfrage dar und der erste Knoten stellt die Ergebnisse der ersten Suchabfrage dar, wobei der erste Pfeil und der erste Knoten zur historischen Suchstruktur als Reaktion auf Daten hinzugefügt werden, die anzeigen, dass ein Benutzer ein Suchelement auf einen zweiten Knoten gezogen hat, der die Ergebnisse einer zweiten Suchabfrage darstellt und wo die Ergebnisse der ersten Suchabfrage teilweise auf (a) dem Suchelement und (b) die Ergebnisse der zweiten Suchabfrage basieren.

In verschiedenen Ausführungsbeispielen umfassen die Daten, die angeben, dass ein Benutzer ein Suchelement auf einen zweiten Knoten gezogen hat, Daten, die angeben, dass ein Benutzer einen dritten Knoten, der Ergebnisse einer dritten Suchabfrage darstellen, auf einen zweiten Knoten gezogen hat; die Ergebnisse der zweiten Suchabfrage und die Ergebnisse der dritten Suchabfrage werden logisch kombiniert, um die Ergebnisse der ersten Suchabfrage herzustellen; die Ergebnisse der zweiten Suchabfrage und die Ergebnisse der dritten Suchabfrage werden basierend auf den Daten logisch kombiniert, die angeben, dass ein Benutzer mindestens eines des Folgendem auswählte: ein logisches ODER, ein logisches UNT, ein logisches NICHT, ein logisches WEDER und ein logisches NAND; die Daten geben an, dass ein Benutzer ein Suchelement auf einen zweiten Knoten gezogen hat, der Daten umfasst, die angeben, dass ein Benutzer einen zweiten Pfeil, der eine zweite Suchabfrage darstellt, auf den zweiten Knoten gezogen hat; die Ergebnisse der zweiten Suchabfrage werden modifiziert, basierend teilweise auf die zweite Suchabfrage zur Herstellung der Ergebnisse der ersten Suchabfrage; das Suchelement stammt aus einer Bibliothek an Suchelementen; das Suchelement ist mindestens ein: Filter, Abfrage und Suchergebnis.

In einem anderen Aspekt richtet sich die vorliegende Erfindung auf ein System, das Mittel für die Anzeige des visuellen Anwendungsdesigns umfasst; Mittel für die Anzeige einer ersten visuellen Programmierungskomponente mit einem exponierten ersten Programmierungsattribut; Mittel für die Anzeige einer zweiten visuellen Programmierungskomponente mit einem exponierten zweiten Programmierungsattribut; und Mittel für die automatische Erzeugung eines ersten visuellen Konnektors zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente, basierend auf einer oder mehreren Beziehungen zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente.

In einem anderen Aspekt richtet sich die vorliegende Erfindung auf ein System für die Modifikation eines visuellen Anwendungsdesigns, das Mittel für die Anzeige einer ersten visuellen Programmierungskomponente mit einem exponierten ersten Programmierungselement umfasst, wobei die erste visuelle Programmierungskomponente mit einem Mitglied der ersten Klasse übereinstimmt; Mittel für die Anzeige einer zweiten visuellen Programmierungskomponente ist mit der ersten visuellen Programmierungskomponente verbunden, wobei die zweite visuelle Programmierungskomponente mit einem Mitglied der zweiten Klasse übereinstimmt, das mit der ersten Klasse verbunden ist; Mittel für die Modifikation der ersten visuellen Programmierungskomponente als Reaktion auf Daten, die angeben, dass die zweite visuelle Programmierungskomponente modifiziert wurde.

In einem anderen Aspekt richtet sich die vorliegende Erfindung auf ein System für die Anzeige von Datenbankabfragen und Ergebnisse, die ein Mittel zur Anzeige einer einer historischen Suchstruktur umfassen, die einen oder mehrere Knoten und einen oder mehrere Pfeile umfasst; und Mittel zum Hinzufügen eines ersten Pfeils, der auf den ersten Knoten in der historischen Suchstruktur zeigt, der erste Pfeil stellt die erste Suchabfrage dar und der erste Knoten stellt die Ergebnisse der ersten Suchabfrage dar, wobei der erste Pfeil und der erste Knoten zur historischen Suchstruktur als Reaktion auf Daten hinzugefügt werden, die anzeigen, dass ein Benutzer ein Suchelement auf einen zweiten Knoten gezogen hat, der die Ergebnisse einer zweiten Suchabfrage darstellt und wo die Ergebnisse der ersten Suchabfrage teilweise auf dem Suchelement und die Ergebnisse der zweiten Suchabfrage basieren.

ABBILDUNGEN
1 ist ein Screenshot, der darstellt, wie ein Benutzer die Ergebnisse einer Abfrage auf einer Datenbank mit Molekülen durchsieht;
2 stellt eine Fallbeschreibung der Benutzung der Komponente dar
3 ist ein Diagramm, dass eine Ausbreitungssequenz beschreibt;
4 stellt die Ausführung verschiedener Teile dar;
5 stellt ein Gate-Teil dar;
6 stellt die Ausführung verschiedener Pins dar;
7 stellt die Verbindung eines Webdienstes für Währungsumtausch dar;
8 stellt dar, wie eine Datenbank in einem Ausführungsbeispiel verbunden ist;
9 ist ein Blockdiagramm, das die Komponenten eines vorliegenden Systems und Verfahren darstellt;
10 stellt eine erste Tiefenausbreitung dar;
11 stellt Referenzteile dar;
12 stellt Gates dar, wie sie entsprechend der vorliegenden Systeme und Verfahren verwendet werden;
13 stellt eine typische historische Suchstruktur dar;
14–21 stellen ein typisches Benutzschnittstellenfenster während des Formulardesigns dar; und
22 beschreibt einen illustrativen VDL-Basis Arbeitsfluss.
DETAILLIERTE BESCHREIBUNG
Die folgenden Definitionen werden in dieser Beschreibung verwendet, sollten jedoch nicht als Einschränkung auf den Umfang der beschriebenen Erfindung ausgelegt werden.
Ein Child bezieht sich auf einen Parameter oder Daten, die mit Parametern oder Daten auf einer höheren Ebene verbunden sind. Außerdem kann ein Child auch auf die hierarchische Beziehungen eines Teils oder eines Bereichs in einem hierarchischen Datensatz Bezug nehmen. Ein Parent bezieht sich auf einen Parameter oder Daten, die mit Parametern oder Daten auf einer niedrigeren Ebene verbunden sind.
Datenmapping bezieht sich auf den Prozess der Definition, wie eine Datenquelle mit einer anderen für den Zweck verbunden ist, dass beide Daten zur und von der Datenquelle importiert und exportiert werden.
Datennormalisierung ist die Umwandlung von Daten zu konsistenten Maßeinheiten. Dies ist notwendig, weil das gleiche Feld in verschiedenen Datenbanken unter Verwendung unterschiedlicher Einheiten gespeichert sein kann. Zum Beispiel verwendet eine Datenbank Milliliter, eine andere Mikroliter und die Anzeige kann Nanoliter verlangen. Die Umwandlungen der Maßeinheiten ist erforderlich, wenn Daten abgefragt, abgerufen oder angezeigt werden. Manchmal bedeutet die Datennormalisierung "Umwandlung des Datenspektrums zu [0:1]." Manchmal bedeutet es "Zeigen der Dateien in einer Gauß'schen Normalverteilung." Manchmal bedeutet es die Verwendung der Konsistenz in den Maßeinheiten. In allen diesen Fällen werden Datenwerte umgewandelt, um den Vergleich mit ungleichartigen Daten zu ermöglichen.
Eine Datenquelle bietet Zugriff auf eine Datenbank. Beispiele von Datenbanken sind: Repository der Unternehmensstruktur, ACD (VDL Content Datenbank), Dokument-Repository, Formular-Repository und XDFILE. (Eine Zieldatenquelle ist die Datenquelle, die für eine bestimmte Operation, zu einem bestimmten Zeitpunkt verwendet wird.)
Ein Dokument kann auf dem Bildschirm, auf Papier oder im Dokument-Repository bestehen. Ein Dokument erscheint auf dem Bildschirm, wenn VDL-Basis einen Datensatz in einem Formular anzeigt. Benutzer können Dokumente drucken, speichern und abrufen.
Dokumentnavigation ist das Bewegen durch ein Dokument auf dem Bildschirm, um grafische Objekte und Text einzusehen, die über ein Formular angezeigt werden. (Siehe Formular und Formularnavigation.)
Das Dokument-Repository speichert Dokumente, die vom Benutzer gespeichert werden.
Ein Filter ist ein Set an Suchkriterien, die verwendet werden können, um einen Datensatz zu filtern, der nur die von Ihnen gewünschten Daten beinhalten soll. Das Filtern ist der Prozess der Verfeinerung der Suchergebnisse, indem weitere Suchkriterien angewendet werden. Das Filtern kann durch eine der beiden Möglichkeiten erfolgen: (1) Modifizierung der Originalabfrage, um die zusätzlichen Kriterien zu beinhalten (zum Beispiel, indem Querylets hinzugefügt werden) und dann die Wiederausführung der Abfrage; (2) Anwenden eines zuvor gespeicherten Filterobjektes auf die Suchergebnisse. Beide Verfahren erstellen einen neuen Knoten in der Historie.
Ein Formular ist eine Definition, wie Daten dem Benutzer visuell präsentiert werden. Ein Formular kann zum Beispiel in einer Abfrage, einer Ansicht und in einem Datensatz Informationen zusammenbringen, sodass diese vom Benutzer auf dem Bildschirm oder auf Papier angesehen werden können.
Formularnavigation ist das Untersuchen einer Liste verfügbarer Formulare und die Auswahl eines für den Gebrauch.
Formularobjekt ist ein Element, das ein Endbenutzer einem Formular hinzufügen kann, um die Eigenschaften zu beeinflussen. Objekte beinhalten das Zeichnen von Objekten, Text, Feldern von einer Datenquelle und Tabellen von einer Datenquelle.
Homepage ist eine VDL-Basisform, erstellt von einem Administrator oder einem hochentwickelten Formulardesigner, der Ansichten auf hoher Ebene des Arbeitsflusses des Benutzers anbietet, die es dem Benutzer ermöglichen, schnell innerhalb der VDL-Basis zu den für ihn interessanten Gebieten zu navigieren.
Eine Liste ist ein Objekt, das die Zeilen (aber nicht die Daten) darstellt, die Ergebnis einer Suche sind. Diese Zeilen umfassen entweder eine Liste primärer Suchschlüssel (eine statische Liste) oder das Abfrageobjekt und die Datenquelle (dynamische Liste, zum Gebrauch in einer nachfolgenden Suche).
Normalisierung – siehe Datennormalisierung; Schemennormalisierung und Strukturnormalisierung.
Ein Parent bezieht sich auf einen Parameter oder Daten, die mit Parametern oder Daten auf einer niedrigeren Ebene verbunden sind. Ein Child bezieht sich auf einen Parameter oder Daten, die mit Parametern oder Daten auf einer höheren Ebene verbunden sind.
Ein Pin bezieht sich auf ein exponiertes Attribut eines Teiles oder auf ein gekapseltes Objekt. Ein exponiertes Attribut kann zum Beispiel visuell als ein Pin dargestellt werden, der eine exponierte Eigenschaft, Ereignis, Verfahren, Funktion, Verschlüsselungselement, Datenelement oder ein ähnliches Objektmitglied darstellt. Wie erkennbar ist, können Pins sichtbar oder unsichtbar sein.
Bevorzugt wird hierin verwendet mit der Bedeutung "bevorzugt, aber nicht notwendigerweise".
Eine Abfrage ist ein Objekt, das den Wo-Satz eines SQL Suchbefehls definiert. Sie kann mehrere Male angewendet werden, kann mit anderen Abfrageobjekten kombiniert werden und kann in einer Abfragebibliothek gespeichert und abgerufen werden.
Ein Querylet ist ein Fragment einer Abfrage. Es beinhaltet die Suchkriterien für ein einzelnes Feld in der Datenbank. (Es bietet Benutzern eine schnelle Möglichkeit zu suchen, ohne ein Formular zu erstellen.)
Ein Datensatz enthält die Daten, die das Ergebnis der Suche sind, sowie Metadaten, die die Ansicht beschreiben, die zur Anzeige der Daten verwendet werden.
R-Gruppen-Dekomposition ist die Identifikation von R-Gruppen-Strukturen (auch generische Strukturen und Markush-Strukturen genannt) in einem Molekül durch das "Auflösen" oder Zerfallen eines Sets von realen Strukturen in eine einzelne generische Struktur. Beim Zeichnen eines Moleküls werden R-Gruppen durch ein "R" dargestellt.
R-Gruppen-Dekomposition ist das Gegenteil von R-Gruppen-Enumeration, wo Sie eine generische Struktur nehmen und alle seine möglichen realen Werte enumerieren.
Eine SAR-Tabelle (Struktur-Aktivitäts-Beziehungs-Tabelle) zeigt die Ergebnisse des Messens einer Serie verbundener Verbindungen in Bezug auf bestimmte Eigenschaften an, die von Interesse sind. Eine SAR-Tabelle kann zum Beispiel eine Serie verbundener Verbindungen zeigen, die in Bezug auf ihre Effektivität als Inhibitor gemessen wurden. Verbindungen in einer SAR-Tabelle sind dadurch verbunden, dass sie die gleiche Kernstruktur miteinander teilen, aber über unterschiedliche R-Gruppen-Werte verfügen.
Schemennormalisierung ist die Änderung eines Datenbankschemas, um es brauchbarer zu machen. Dies kann auf verschiedene Weise erfolgen, entsprechend einem Regelset, das in der Literatur benannt wird. Ein Schema kann beim Speichern effizienter sein als ein anderes. Ein Schema kann beim Suchen effizienter sein als ein anderes. Die Umwandlung von einem Schema in ein anderes ist manchmal notwendig, um die Leistung zu optimieren.
Die Suchen ist das Ausführen einer systematischen Suche der Datenbank unter Verwendung von Suchkriterien, die der Benutzer angibt.
Strukturnormalisierung ist die Umwandlung chemischer Darstellungen in einem standardisierten Formular. Strukturnormalisierung macht es möglich, Strukturen konsistent abzufragen, abzurufen und anzuzeigen.
Eine Zieldatenquelle ist die Datenquelle, die für eine bestimmte Operation, zu einem bestimmten Zeitpunkt verwendet wird. Eine Datenquelle kann Zugriff auf eine Datenbank anbieten. Beispiele von Datenbanken sind: Repository der Unternehmensstruktur, ACD (VDL Content Datenbank), Dokument-Repository, Formular-Repository und XDFILE.
Das Vorlagen-Repository enthält Vorlagen für diese Objekte: Formulare, Abfragen, Berichte, Ansicht.. Benutzer können Vorlagen aus diesem Repository auswählen und sie modifizieren, um kundenspezifische Formulare, Abfragen, Berichte und Ansichten zu erstellen. Benutzer können ihre kundenspezifischen Vorlagen im Vorlagen-Repository speichern.
Eine Ansicht definiert, wie Daten abgerufen werden. Eine Ansicht beschreibt den Auswahl -Satz eines SQL-Suchbefehls.
Eine visuelle Programmnierungskomponente ist ein beliebiges Teil oder Komponente, die visuell auf einem Formular, Anwendung, Arbeitsfluss oder verwandtes angezeigtes Element sichtbar ist (hierin auch als ein Teil oder eine Komponente benannt).
Ein Vokabular ist eine Liste mit Text oder numerischen Werten, die für die Abfrage einer vorgegebenen Datenquelle gelten (oder darauf registriert sind). Benutzer wählen aus einer Vokabularliste aus, wenn sie eine Suche zusammenstellen oder wenn sie Informationen registrieren.
Trickfenster ist ein Element, das ein Administrator oder ein hochentwickelter Formulardesigner zu einem Formular hinzufügen kann, das über spezielle Eigenschaften und zugehörige Ereignisse verfügt. Ein Trickfenster kann kundenspezifische Tasten, hochentwickelte Formularoptionen und Vorlagen, Zeitstempel, hochentwickelte Tabellen beinhalten.
Arbeitsfluss ist, wie der Prozess durch ein System oder eine Komponente fließt.
In einem Ausführungsbeispiel umfasst ein System, das eine VDL-Basis zur Anwendung bringt, eine Client-seitige Schnittstelle, damit Benutzer eine Datenbank von Verbindungen nach molekularer Struktur und andere Charakteristiken abfragen, die Ergebnisse einsehen und das ausgewählte Unterset der Ergebnisse für die zukünftige Verarbeitung sendet (zum Beispiel durch eine andere Anwendung, die Verbindungen bestellt, die von einem katalogisierten Bestand geliefert werden). Andere Arbeitsflüsse können ebenfalls in VDL-Basis umgesetzt werden. Zum Beispiel kann ein Formulardesigner oder Endbenutzer die visuelle Verbindungssprache von VDL-Basis verwenden, um Formularserien für den Benutzer zu erstellen, die zur Bestückung der Datenbank ausgefüllt werden.
Ein bevorzugtes Ausführungsbeispiel ermöglicht die kundenspezifische Anpassung von Formularen und Anwendungen, während sie noch ausgeführt werden. Zum Beispiel können Benutzer die Benutzerschnittstelle und Logik einer bestehenden VDL-Basisanwendung modifizieren, indem sie visuelle Verbindungen verwenden. Sie können auch neue Komponenten hinzufügen (z.B. eine .NET-Klasse oder Steuerung) bei einem Formular oder Anwendung und deren Verfahren, Eigenschaften und Ereignisse mit dem Rest der Anwendung zu "verbinden". Wie erkennbar ist, muss eine .NET-Komponente keine bestimmte Schnittstelle zur Anwendung bringen oder eine bestimmte Klasse erweitern, um integriert zu werden. Dies ermöglicht den Benutzern, die Systeme mit Standardklassen zu erweitern, die kommerziell oder auch kundenspezifisch geschrieben erhältlich sind. Wie weiter erkennbar ist, obwohl viele der Beschreibungen unten den Betrieb mit der .NET-Plattform von Microsoft^® beinhalten, kann jede geeignete Plattform verwendet werden.
Ein bevorzugtes Ausführungsbeispiel kann automatisch "Referenzen" zu einem beliebigen "Teil" in der Teilehierarchie erstellen, welches das laufende Framework und die Anwendung darstellt. Diese Referenzen können zu einem Formular hinzugefügt werden, um einen Nutzwert für die Verbindung des "Teils" anzubieten, auf das im Rest des Formulars Bezug genommen wird. Benutzer können zum Beispiel ein Menüelement "Teil" auf einer Referenz zu einem Menü ablegen und das Menüelement wird automatisch zum Menü hinzugefügt, auf das referenziert wird. Ähnlich kann ein Benutzer eine Eigenschaft auf einer Referenz ändern und die Eigenschaft wird auf dem Objekt dieser Referenz geändert. Verbindung zu den Verfahren, Eigenschaften und Ereignissen einer Referenz ist wie die Verbindung zu den Methoden, Eigenschaften und Ereignissen des Objektes, das referenziert wird. Bevorzugt bleiben Änderungen, die an einem Objekt durch den Gebrauch einer Referenz vorgenommen werden nur so lange in Kraft, wie sich die Referenz im zulässigen Bereich befindet (d.h. der derzeitige Formularlevel hat sich nicht geändert, das derzeitige Parent-Fenster ist noch aktiv oder die hierarchischen Ebenen haben sich nicht geändert, etc.) Wenn zum Beispiel ein Benutzer eine Referenz zum Dateimenü einer Anwendung zum derzeitigen Formular hinzufügen wollte und dann die "sichtbare" Eigenschaft der Referenz auf "falsch" einstellen würde, dann würde das "Datei"-Menü der Anwendung verschwinden. Nachdem der Benutzer vom aktiven Formular weg navigiert (z.B. durch das Aufrufen eines anderen Formulars) verschwindet das "Datei"-Menü, da die Referenz nicht "angewendet" wird, wenn sein Parent sich nicht mehr im zulässigen Bereich befindet.
In einem bevorzugten Ausführungsbeispiel können Referenzen auf Teile über Formulare oder Fenster hinweg auf die gleiche hierarchische Ebene wie die Formulare und Fenster angewendet werden, die diese Teile benutzen. Ein Beispiel wären Teilfenster im Registerformat, wo jede eine Referenz zu einem Teil verwendet. In diesen Fällen ist es einfach, das erste Fenster, welches das Teil anzeigt, den "Parent" zu nennen und jedes nachfolgende Fenster, das die Referenz anzeigt, ein "Child" zu nennen. Referenzen auf Teile können in Formularen oder Fenstern angewendet werden, die in der Hierarchie der Formulare oder Fenster niedriger sind und diese Teile verwenden. Ein Beispiel würde ein Child-Fenster oder Formular sein, das ein Teil in einem Parent-Fenster oder Formular referenziert. Wie erkennbar ist, kann ein Child-Fenster ein unabhängiges Fenster oder ein Frame innerhalb eines Parent-Fensters sein. Wie weiter erkennbar ist, wo ein Arbeitsfluss aus mehreren Formularen besteht, kann ein referenziertes Teil ein Teil sein, das aus vorherigen Formularen stammt (d.h. eines, das höher in der Arbeitsfluss-Hierarchie ist) oder ein Formular, das zuerst auf einem Anzeigefenster erscheint.
Ein referenziertes Teil kann ein Teil darstellen, das angezeigt wird oder in einem Parent-Formular oder einem Parent-Fenster erstellt wurde. In einem Ausführungsbeispiel kann ein Child-Formular oder Fenster das Teil vom Parent-Fenster referenzieren, z.B. das Teil kann zum Child-Fenster oder Formular hinzugefügt werden, ohne dass man ein neues Teil erstellen muss. Weitere Modifikationen des referenzierten Teils können umgesetzt werden, indem Elemente zum referenzierten Teil hinzugefügt werden. Solche Modifikationen werden auf dem Child-Formular (Fenster) erscheinen. Bevorzugt werden Modifikationen, die am referenzierten Teil vorgenommen werden, auch am Parent-Teil reflektiert. Diese reflektierten Änderungen am Parent-Teil können temporär sein (d.h. bis sich das Parent-Teil nicht mehr im zulässigen Bereich befindet). Wie erkennbar ist, können Referenzen auf Teile automatisch innerhalb der Hierarchie erzeugt werden oder können manuell erstellt werden, wenn eine Referenz gewünscht wird. Eine weitere Diskussion zu Referenzen wird unten in Verbindung mit den Abbildungen geboten. 11.
1 ist ein Screenshot, der darstellt, wie ein Benutzer die Ergebnisse einer Abfrage (102) auf einer Datenbank mit Molekülen durchsieht. Wenn ein Benutzer ein Formular im Design-Modus durchsieht, signalisieren verschiedene Indikatoren bevorzugterweise, dass der Design-Modus aktiv ist. Zum Beispiel geben Grafiken den Aufbau (110) an oder Warnsignale können vorhanden sein. Außerdem kann in einem Ausführungsbeispiel im Design-Modus die Verbindung exponiert sein (120). In einem Ausführungsbeispiel verwendet eine VDL-Basis eine visuelle Box-und-Verbindung Metapher. Ein Vorteil ist die Art und Weise, wie ein visuelles Datenfluss-Paradigma mit einer nicht visuellen zugrunde liegenden Plattform integriert ist.
Eine bevorzugte VDL-Basisanwendung umfasst ein Set von Formularen oder Bildschirmen, wo jedes eine hierarchische Struktur an Komponenten umfasst. Formulare können durch XML-Dokumente beschrieben werden. Komponenten können durch Verbindungen verbunden werden, die Daten- und Ereignisflüsse bereitstellen. Eine "Verbindungskomponente" ist eine Software fähig zur Erstellung von einen oder mehreren visuellen Konnektoren ("Verbindungen") zwischen Komponenten. Wie erkennbar ist, kann jedes Programmierungsobjekt (wie ein .NET-Objekt) zu einem Formular hinzugefügt werden, das sowohl Benutzerschnittstellenkomponenten als auch interne Objekte enthält, die gewöhnlich unsichtbar sind. Die Mitglieder eines Objektes können in visuelle Nutzwerte umgewandelt und mit Verbindungen verbunden werden.
In einem Ausführungsbeispiel beabsichtigt die Verbindungssprache die Verbindung der Komponenten auf einem einzelnen Formular und zwischen Formularen ("Arbeitsfluss"). Typische Anwendungen werden Benutzerschnittstellen managen und Datenflüsse zwischen Teilen eines komplexen Formulars herstellen.
2 stellt eine Fallbeschreibung der Benutzung der Komponente dar. In einem bevorzugten Ausführungsbeispiel baut ein Komponentenbauer eine Komponente, die in die Verbindungssprache integriert werden kann (Schritt 200). Komponenten, Pins, Verbindungen usw. werden detailliert unten beschrieben. Im Schritt 202 baut ein Formulardesigner ein Formular einschließlich der Komponenten auf und verbindet sie mit Verbindungen. Wird mehr als ein Formular verwendet, wird ein Arbeitsfluss erstellt (Schritt 204). In den Schritten 206 und 208 verwendet ein Benutzer ein erstelltes Formular und kann neue Trickfenster in das Formular platzieren, um die gewünschten Ergebnisse zu erzeugen. Andere Komponenten können beinhaltet werden und können durch die Verwendung von ausgeblendeten Verbindungen auf dem Formular einbezogen werden. Details des Elements werden dargestellt in Verbindung mit 2 unten.
Wie erkennbar ist, können Komponenten in Komponenten-Bibliotheken gespeichert und durch einen Benutzer zu einem Formular durch "Ziehen und Ablegen" hinzugefügt werden.
Teile, Pins und Verbindungen
Die Verbindungssprache einer bevorzugten Ausführung kann verwendet werden, um Komponenten-basiertes visuelles Programmieren bereitzustellen. Teile (Komponenten) exponieren einige ihrer Werte, Ereignisse oder Verfahren über Pins. Die Pins sind über Verbindungen verbunden. Dies bietet ein einfaches visuelles Verfahren für das Spezifizieren von Beziehungen zwischen den Komponenten, aus denen sich ein Formular zusammensetzt. Teile können sowohl sichtbare Trickfenster (Steuerungen) und unsichtbare Komponenten enthalten, die Rechen- und andere Dienste bereitstellen.
Das Teile-System arbeitet bevorzugt durch das Formen einer hierarchischen Struktur, die die bestehende grafische Einschränkungshierarchie parallelisiert und erweitert (wie zum Beispiel vom Benutzerschnittstellenpaket von .NET angeboten wird, z.B. Windows-Formulare). Ein typisches Teil kann sein, ein anderes Objekt zu kapseln. Teile können benannt werden, so dass sie durch andere Teile in XML- Definitionsdateien und anderweitig referenziert werden können und sie können ein Framework bereitstellen, um Pins, Anordnung und andere notwendigen Informationen zur Erweiterung eines Objektes nachzuverfolgen, damit es im visuellen Framework, wie offen gelegt, arbeiten kann.
Ein Fragment einer XML-Formulardefinition wird unten bereitgestellt (geometrische Informationen wurden der Kürze wegen ausgelassen):
Wie erkennbar ist, ähnelt dieses XML-Format denen, die durch Sprachen wie XAML bereitgestellt werden. Die <form>, <textbox>, <button> und <object> Tags können alle Teile definieren, die eine Hierarchie formen. Verschiedene Ausführungsbeispiele stellen jedoch klare Vorteile über Sprachen des früheren Standes der Technik bereit. Solche Ausführungsbeispiele können zum Beispiel die Möglichkeit bereitstellen, ein beliebiges Objekt zu verschlüsseln (über den <object> Tag) und es mit herkömmlichen Steuerungen zu vermischen; die Fähigkeit, Eigenschaft, Ereignisse, Verfahren, Funktionen, Verschlüsselungselemente usw. der Objekte über den <expose> Tag (diese exponierten Eigenschaften, Ereignisse, Verfahren, Funktionen, Verschlüsselungselemente usw. können visuell als Pin dargestellt werden); und die Fähigkeit, exponierte Pins mit Verbindungen zu verbinden (über den <wire> Tag).
Es sollte erkennbar sein, dass die XML-Verschlüsselung vor Benutzern ausgeblendet werden kann, die sie bevorzugt mit Hilfe einer Designer-Benutzerschnittstelle (UI), die unten besprochen wird, aufbauen.
Wie oben beschrieben, formen in verschiedenen Ausführungsbeispielen Teile eine Hierarchie, die die Formular- und Anwendungsstruktur definiert, Teile haben Namen, so dass sie in der XML und anderswo referenziert werden können, Teile kapseln Steuerungen und andere .NET-Objekte und Teile können Objektmitglieder als Pins exponieren. Wie erkennbar ist, kann jedes Verfahren, Klasse, Element usw., das in einer Plattform verfügbar ist, in den vorliegenden Systemen und Verfahren gekapselt und eingesetzt werden.
Pins exponieren bevorzugt Attribute (hierin auch Programmierungsattribute genannt) eines Teiles oder seines gekapselten Objektes. Zum Beispiel kann ein exponiertes Attribut visuell als ein Pin dargestellt werden, der eine exponierte Eigenschaft, Ereignis, Verfahren, Funktion, Verschlüsselungselement usw. darstellt. Als ein weiteren Beispiel können Pins exponierte Attribute von .NET-Objekten darstellen.
In einem Ausführungsbeispiel wird ein exponiertes Attribut visuell auf einem Bildschirm als ein Pin dargestellt, um einen visuellen Ort zum Anbringen einer Verbindung bereitzustellen. In einem anderen Ausführungsbeispiel sind Pins auf einem Bildschirm nicht visuell dargestellt; exponierte Mitglieder können jedoch trotzdem über Verbindungen verbunden werden. In einem weiteren Ausführungsbeispiel können Attribute ohne die Erzeugung eines entsprechenden Pins exponiert werden. In einem Ausführungsbeispiel, wo Pins nicht auf einem Bildschirm dargestellt werden (d.h. unsichtbare Pins oder exponierte Attribute ohne entsprechenden Pin) können Verbindungen automatisch zwischen Teilen durch Ziehen und Ablegen von einem Teil auf einem anderen Teil erzeugt werden. In einem anderen Ausführungsbeispiel, wo Pins nicht auf einem Bildschirm dargestellt werden, kann ein Benutzer mit einer Maus eine Handbewegung machen und eine Verbindung kann automatisch erzeugt werden. Wie detailliert oben beschrieben ermöglicht dieses Verbindungsmodell (auch ein intelligentes Verbindungsmodell genannt), dass Verbindungen automatisch mit den entsprechenden exponierten Verfahren, Steuerungen, Objekten, Mitgliedern, Datenelementen usw. verbunden werden. In einem Ausführungsbeispiel, wo mehr als ein Verbindungspunkt verfügbar ist, fordert ein Dialogfenster den Benutzer auf, die gewünschte Verbindung anzugeben. In einem anderen Ausführungsbeispiel ist nur ein Verbindungspunkt verfügbar und die Verbindung wird automatisch hergestellt.
Pins können weiter klassifiziert werden, je nachdem, ob sie hauptsächlich mit Daten (Werte) oder Ereignissen umgehen. Eine bevorzugte Pin-Hierarchie ist:

• Input Pins – Daten – Input-Eigenschaften-Pins – Inputverfahren-Argument-Pins – Inputlisten-Pins (kombiniert mehrere Inputs in eine Liste) – Ereignis – Inputverfahren-Pins
• Output Pins – Daten – Output-Eigenschaften-Pins – Outputverfahren-Ergebnis-Pins – Ereignis – Output-Ereignis-Pins

In einem Ausführungsbeispiel übertragen Daten-Pins Werte in Abhängigkeit von Typbeschränkungen. Wie oben beschrieben, können diese Werte .NET-Objekte sein. Sie können den Datentyp von ihren zugrunde liegenden Objekt-Mitgliedern (wie ein String, Nummer, Datensatz oder Molekül) übernehmen.
Wie oben beschrieben, werden Pins bevorzugt erstellt durch das Exponieren ausgewählter Mitglieder des zugrunde liegenden Objektes. Gewöhnlich erstellt dies einen einzelnen Pin, aber im Fall eines Verfahrens mit Argumenten oder eines Ergebniswertes kann es mehrere Pins erstellen. Da ein typisches Objekt Dutzende verfügbare Mitglieder hat, reduziert ein expliziter Exponierungsschritt das visuelle Durcheinander, indem nur die Eigenschaften visualisiert werden, die für den Benutzer wirklich interessant sind.
Bevorzugt verbinden Verbindungen einen Output-Pin mit einem Input-Pin eines kompatiblen Typs. Eine Datenverbindung, d.h. eine Verbindung zwischen zwei Daten-Pins, bedeutet bevorzugt, dass der Wert am Input-Pin den Wert am Output-Pin reflektieren sollte. Die Details der Beibehaltung dieser Übereinstimmung gehören gewöhnlich zum Job des Teile-Managers (wie oben beschrieben); bevorzugt werden sie gegenstandslos und befinden sich nicht direkt unter der Kontrolle eines Formularbauers.
Ereignisverbindung stellt bevorzugt etwas mehr als einen traditionellen Ereignisanwender oder einen Verfahrensaufruf dar. Zum Beispiel stellt ein Ereignis-Output-Pin bevorzugt ein Ereignis dar, wie einen Tastenklick (ein Ereignis, das rechtzeitig stattfindet), während ein Ereignis-Input-Pin bevorzugt ein Verfahren oder eine andere Handlung darstellt. Eine Ereignisverbindung (Ereignisverbindung) verbindet bevorzugt Verfahren mit Ereignissen, sodass die Verfahren zur gleichen Zeit des Geschehens des Ereignisses ausgelöst werden. In einem Ausführungsbeispiel stellen die Ereignisverbindungen die Ereignisanwender oder Verfahrensaufrufe innerhalb einer bestimmten Plattform dar, z.B. .NET.
In einem bevorzugten Ausführungsbeispiel reagiert das Verbindungssystem auf Änderungen in der Verbindungskonfiguration oder auf ein beliebiges zugrunde liegendes Ereignis, selbst im Design-Modus. Somit operiert es auf der höchsten Ebene von "Live" und Änderungen, die auf einem Formular im Design-Modus vorgenommen wurden, werden sofort auf dem Bildschirm reflektiert. Wo zum Beispiel ein Benutzer eine Komponente hinzufügt, um einen Wert auf einem Formular anzuzeigen, wird die Komponente umgehend den Wert anzeigen.
Wie oben beschrieben ist das Ziel einer Verbindungssprache ein Verfahren für das einfache Komponenten-basierte visuelle Programmieren bereitzustellen. Teile (Komponenten) können einige ihrer Werte, Ereignisse oder Verfahren über Pins exponieren. Die Pins sind über Verbindungen verbunden. Dies bietet ein visuelles Verfahren für das Spezifizieren von Beziehungen zwischen den Komponenten, aus denen sich ein VDL-Basisformular zusammensetzt, sowohl Trickfenster als auch unsichtbare Komponenten, die Back-End Dienste anbieten. In einem bevorzugten Ausführungsbeispiel legen Formulardesigner Trickfenster im System ab und verbinden es.
Teile sind Basiskomponenten eines bevorzugten Systems. Gewöhnlich wird ein Teil eine .NET-Steuerung kapseln (wie eine Taste) oder ein Nicht-Steuer UI-Element (wie ein Menüelement). Wie erkennbar ist, können alle Verfahren, Komponenten, Klassen, Elemente usw. einer beliebigen Plattform in vorliegenden Systemen und Verfahren gekapselt werden. Kapseln biete eine grafische Darstellung der zugrunde liegenden Verschlüsselungselemente der gekapselten Elemente.
Wie oben beschrieben, können Pins und Verbindungen in zwei Klassen aufgeteilt werden: die, die mit Daten (Objekten) umgehen und die, die mit Ereignissen umgehen. Wie erkennbar ist, verfügen diese über unterschiedliche Semantik und sollten separat in Betracht gezogen werden.
Pins und Verbindungen können auch verwendet werden, um Ereignisse zu signalisieren. Das Verbinden eines Ereignis-Pins zu einem Verfahrens-Pin kann ein Verhalten verwirklichen.
Viele Plattformen haben ein grundsätzlich typisiertes Objektmodell. Damit können alle Objekte zu einer Klasse gehören und alle Variablen können einen Typ haben, der sie auf das Halten von Objekten eines bestimmten Typs beschränkt. In einem bevorzugten Verbindungssystem entsprechen Pins Varianten, so dass sie auch typisiert werden können. Der Pintyp kann eine nützliche Anleitung für die Verbindung sein und kann den Benutzer anleiten, andere bedeutungsvolle Verbindungen herzustellen und in einigen Fällen die Verbindung ganz automatisieren. Wie erkennbar ist, müssen die Pins nicht sichtbar sein, damit Verbindungen etabliert werden können. Entsprechend können die Pins in einem Ausführungsbeispiel sichtbar sein. In einem anderen Ausführungsbeispiel können die Pins nicht sichtbar sein.
In einem Ausführungsbeispiel, wo rigorose Objektorientierte Programmierungstypen statt die mehr interaktive und informelle Aktivität des Formularaufbaus zum Einsatz kommen, kann es von Vorteil sein, die durchgeführte Typüberprüfung zu lockern. Es kann zum Beispiel nützlich sein, wenn ein Benutzer direkt einen numerischen Output verbinden kann (zum Beispiel von einem Zähler) zu einem Textfeld zur Anzeige, statt ihn explizit durch eine Typ-Umwandlungs-Komponente zu verbinden, wie es durch strenge Typüberprüfung erforderlich wäre. Typzwang kann durch ein Modul definiert werden, das alles Wissen über Typzwänge kapselt und kann sowohl Werte zu Typen zwingen und über die Kompatibilität von Typen berichten (zur Fehlerüberprüfung und Rückmeldung während der Verbindung).
Wenn sich ein Wert eines Output-Daten-Pins ändert, muss sich der neue Wert auf die Input-Pins der verbundenen Pins ausbreiten. Dies kann verursachen, dass andere Komponenten ihre Output-Pins ändern und zu einer Ausbreitungskette führen. 3 ist ein Diagramm, dass eine Ausbreitungssequenz beschreibt. Wie gezeigt, gibt der Benutzer einen Text in eine Textbox ein, verursacht, dass der String in eine Ganzzahl umgesetzt wird, die zur Bestimmung der Breite einer anderen Komponente verwendet wird.
In einem Ausführungsbeispiel können Verbindungen automatisch als Reaktion auf eine Benutzerhandlung erstellt werden. Zum Beispiel kann das einfache Ablegen in das Textbox eines Trickfensters in einem Daten-Kenntnis-Formular (DAF) automatisch Verbindungen zwischen dem Formular und der Box herstellen. Dies ist eine Funktion der DAF, das Verbindungsmodell muss diesen Gebrauchsmodus unterstützen. In einem Ausführungsbeispiel ist die Teile-Fabrik fähig zur automatischen Verbindung.
4 stellt eine bevorzugte Teile-Hierarchie dar. Wie oben beschrieben sind Teile die Objekte, die durch das Verbindungssystem verbunden sind. Teile beinhalten Pins, die die Schnittstelle bereit stellen. In einem Ausführungsbeispiel kann ein Teil ein anderes Objekt kapseln und seine Eigenschaften als Pins exponieren, z.B. das Class EncapsulatingPart.
In einem Ausführungsbeispiel übernehmen Teile von der GeneralizedNode Class, sodass sie eine Eingrenzungshierarchie für Anordnungs- und Navigationszwecke unterhalten. Das Folgende ist eine Beschreibung verschiedener Funktionsaufrufe, Verfahren, Komponenten und Prototypen, die in verschiedenen Ausführungsbeispielen vorhanden sind. Der Fachmann wird ihre Umsetzung und Anwendung in den vorliegenden Systemen und Verfahren erkennen.
ARRAYLIST PINS()
VOID ADDPIN (PIN)
PIN GETPINNAMED (STRING)
VOID ACTIVATE()
Aktivieren Sie das Teil. Das Standardverfahren fordert einfach zur Aktivierung aller Output-Pins auf.
PROPERTYPIN EXPOSEINPUTPROPERTY (STRING, ZIEL)
PROPERTYPIN EXPOSEINPUTPROPERTY (STRING)
PROPERTYPIN EXPOSEOUTPUTPROPERTY (STRING, ZIEL)
Erstellt einen Pin, der die benannte Eigenschaft darstellt und fügt ihn zum Zielobjekt hinzu.
PROPERTYPIN EXPOSEOUTPUTPROPERTY (STRING)
Erstellt einen Pin, der die benannte Eigenschaft eines Standardobjektes darstellt und fügt ihn zum Zielobjekt hinzu. Dies wird gewöhnlich das gekapselte Objekt sein. Wenn dem Eigenschaftenname ein Unterstrich vorangeht (z.B. "_Name"), dann ist das Standardobjekt das Teil selbst, statt das gekapselte Objekt.
Andere Exponierungsverfahren können ähnliche Signaturen und Dateikürzel haben wie oben. In diesen Fällen können sie einen Pin erstellen, der die benannte Eigenschaft darstellt und sie hinzufügt.
OUTPUTEVENTPIN EXPOSEEVENT (STRING)
Exponieren des benannten Ereignisses als einen Output- Ereignis-Pin
INPUTEVENTPIN EXPOSEMETHOD (STRING)
Exponieren des Null-Argument-Verfahrens, durch einen Input-Ereignis-Pin als String benannt
ArrayList ExposeMethod (MethodSpec)
Exponieren des Verfahrens als einen Input-Ereignis-Pin und seine Argumente als Input-Daten-Pins.
ARRAYLIST EXPOSEEVERYTHING()
Exponieren aller öffentlichen Eigenschaften, Ereignisse und Verfahren des Teils.
PUBLIC STATIC VOID PROPERTYWIRE (OBJEKT O1, STRING P1, OBJEKT O2, STRING P2)
Dies kann zur Verbindung zweier beliebiger Objekte über die Eigenschaften verwendet werden. P1 und P2 sind Eigenschaftennamen. O1 und o2 sind Objekte, die mit den entsprechenden Teilen gekapselt werden.
PUBLIC STATIC VOID EVENTWIRE (OBJEKT O1, STRING-EREIGNIS1, OBJEKT O2, STRING-VERFAHREN2)
Dies kann zur Verbindung zweier beliebiger Objekte über die Ereignisse und Verfahren verwendet werden. O1 und o2 sind Objekte, die mit den entsprechenden Teilen gekapselt werden. Ereignisl ist ein Ereignisname (für o1) und Verfahren2 ist ein Verfahrensname (für o2).
class EncapsulatingPart : Teil
ENCAPSULATINGPART STATIC ENCAPSULATE (OBJEKT)
Erstellen eines Teils zum Kapseln eines Objektes.
EXPONIEREN
Die Exponierungsverfahren haben eine identische Schnittstelle aber per Standard exponieren Sie Eigenschaften usw. am gekapselten Objekt, statt auf dem Teil selbst.
class WidgetPart : Gekapseltes Teil
Ein WidgetPart kapselt ein Trickfenster (Steuerung). Diese Klasse weiß, wie das Trickfenster zu verwenden ist, sodass Benutzerereignisse verursachen, dass ein Objekt aktiviert wird.
class CompositePart : Teil
CompositeParts kapseln ein Netzwerk anderer Teile ein, exponieren einige der Pins der inneren Teile als eigene.
class ScriptPart : Teil
Script-Teile haben ein Script, z.B. Jscript, VB.Net oder eine andere Script-Sprache. Der Script selbst kann als ein Pin exponiert werden. Script-Objekte können beliebige Pins haben, die als Variablen für die Scripts exponiert sind.
class JScriptPart : ScriptPart
class VBScriptPart : ScriptPart
class BottlePart : Teil
Ein Flaschen-Teil akzeptiert ein Objekt auf einem Input-Pin und exponiert einige seiner Eigenschaften. In einem Ausführungsbeispiel kann dies unterschiedlich vom EncapsulatingPart sein, das Eigenschaften der gekapselten Komponente exponieren kann. Dies exponiert Eigenschaften des Datenobjekts.
class GatePart : Teil
Ein GatePart dient zur Verzögerung der Übertragung eines Wertes zusammen mit einer Verbindung, bis ein Ereignis stattfindet. 5 stellt ein Gate-Teil dar. Wie in 5 gezeigt, sind die Textboxen 502, Gate 504 und Auslöser 506. Auch gezeigt (aber nicht gekennzeichnet) werden die Verbindungen, die die verschiedenen Textkomponenten verbinden. Nur als nicht einschränkendes Beispiel, wo ein Input-Feld automatisch ein Folgefeld aktualisiert, kann es von Vorteil sein, das Folgefeld unaktualisiert zu lassen, bis ein Auslöser aktiviert wird. GateParts können die folgenden Pins haben:
In (Typ-Objekt)
Out (Typ-Objekt)
Auslöser (EventInput)
class MergePart
In einem Ausführungsbeispiel kann ein normaler Input- Pin nur eine Verbindung haben. Es kann nützlich sein, über ein spezielles Teil (oder Pin) zu verfügen, das Werte von verschiedenen Quellen verschmelzen kann. Wo zum Beispiel ein Teil über mehrere Input-Pins aber nur über einen Output-Pin verfügt, kann der Output der Wert sein, der der neueste von einem beliebigen der Input-Pins ist. In einem Ausführungsbeispiel schließen die vorliegenden Systeme und Verfahren einen Multiplex-Input-Pin ein.
6 stellt die Ausführung verschiedener Pins dar. Pins sind exponierte Schnittstellen von Teilen, die die Verbindung zu anderen Teilen zulassen. Pins gehören zu einem Teil und haben ein Ziel, d.h. das Objekt, mit dem sie tatsächlich kommunizieren. Dieses Ziel kann entweder das Teil selbst, das gekapselte Objekt oder für zusammengesetzte Teile kann es ein eingegrenztes Teil sein. Im Allgemeinen sollten Pins nicht durch direkte Aufrufe an deren Erbauer erstellt werden. Statt dessen sollten die Exponierungsverfahren der Teile verwendet werden. Wie erkennbar ist, kann ein InputEventPin verwendet werden, um ein Verfahren zu exponieren.
Erstellt eine Verbindung. Wenn es bereits eine Verbindung zu diesem Input-Pin gibt, kann sie gelöscht werden.
Verbindungen sind Verbindungen zwischen zwei Pins. In einem Ausführungsbeispiel kann es nur eine Klasse, Verbindung, geben.
Erbauer
Öffentliche Verbindung (OutputPin output, InputPin input)
Verbindung löschen()
Verbindungen können in Formularen durch XML-Elemente definiert werden. Der exakte Syntax kann in der Spezifizierungssprache des XML-Formulars definiert werden. Einschließlich nur als Beispiel, kann ein Beispiel eines Syntaxes sein:
<wire outwidget="mdbfile" outpin="Text" inwidget="localDB" inpin="File"/>
FEHLER IN DER HANDHABUNG
Wie erkennbar ist, kann jeder Fehler im Handhabungsverfahren beinhaltet werden.
SCHNITTSTELLE WEBDIENSTE
Webdienste werden mehr und mehr für viele Anwendungen wichtig und es wurden Anstrengungen unternommen, Zugriff auf sie durch visuelle Sprachen zu ermöglichen. Die vorliegenden Systeme und Verfahren können dies in Verbindung mit bestehenden Plattformen, z.B. .NET-Tools unterstützen.
7 stellt dar, wie in einem Ausführungsbeispiel ein Webdienst für Währungstausch verbunden ist. Wie gezeigt, gibt es zwei unsichtbare Teile auf diesem Formular, eines stellt den Webdienst 702 und ein Teil dar, das die arithmetische Multiplikation 704 ausführt. Das Teil des Webdienstes kann automatisch von einer veröffentlichten Datei erstellt werden, z.B. durch ein .NET-Dienstprogramm, das den Dienst in eine Klasse mit Verfahren, entsprechend der Dienst-APIs, umwandelt. In einem Ausführungsbeispiel werden diese Verfahren in verbindungsfähige Pins umgewandelt. In diesem Fall nimmt der Webdienst als Input die Namen von zwei unterschiedlichen Ländern und gibt als Output den Umtauschkurs zwischen deren Währungen aus; diese Zahl wird dann als ein Koeffizient zu einem Multiplikator verwendet. Wie gezeigt, stellen die Pins und Verbindungen die Konnektivität der Komponenten in 7 dar. 7. Wenn der Input-Text für die bestimmten Länder der Input (706 und 708) ist und die Umwandlungstaste betätigt wird (710), wird der Umtauschkurs der unsichtbaren Komponente 702 an den unsichtbaren Multiplizier-Block 704 weitergegeben. Der zuvor im Block 712 eingegebene Wert wird dann mit dem weitergegebenen Kurs multipliziert und der Output (auf dem Output-Pin des Blocks 704) wird an den Input-Pin der Textbox 714 weitergegeben, wo das Ergebnis angezeigt wird. In einem Ausführungsbeispiel kann der Umtauschkurs an den Output-Pin des Blocks 702 an einen Input-Pin eines separaten Anzeige-Blocks (716) weitergeleitet werden. Wie erkennbar ist, werden die Verbindungen, die die Blöcke verbinden, über die Pins, wie oben beschrieben, hergestellt.
8 stellt dar, wie eine Datenbank in einem Ausführungsbeispiel verkabelt ist. Wie gezeigt erscheinen die Ergebnisse einer Datenbankabfrage in Box 802 (hier Diphenylfulven anzeigend). In einem Ausführungsbeispiel kann diese Box ein einzelnes Datenbankfeld sein. In einem Ausführungsbeispiel erscheint der Wert dieses Felds auf DataItem Pin 804 und ändert sich, wenn der Benutzer durch den Ergebnissatz blättert. Damit wird der Wert auf dem Pin automatisch geändert, wo ein neues Ergebnis in Box 802 angezeigt wird. Wie dargestellt kann dieser Pin auch mit dem Param0 Pin 806 eines StringMaker-Objekts 808 verbunden werden, der auch als einen Input eine URL-Vorlage 810 hat. Der StringMaker ersetzt den Abfragewert in der Vorlage, leitet ihn durch seinen Output-Pin 812, wo er entlang einer Verbindung 814 zum URL-Input-Pin 816 eines Webbrowser-Teils 818 gesendet wird. In einem Ausführungsbeispiel ist der Effekt dieser Verbindung, automatisch eine neue Webabfrage auszuführen, wenn der Benutzer durch einen Ergebnissatz blättert. Zusätzliche Pins für StringMaker 808 und Abfragebox 802 werden gezeigt und können in verschiedenen Ausführungsbeispielen zum Einsatz kommen. Wie erkennbar ist, können zusätzliche Komponenten, Input-Pins und Output-Pins auch verwendet werden.
9 ist ein Blockdiagramm, das die Komponenten eines vorliegenden Systems und Verfahren darstellt. Wie gezeigt, stellen Blöcke einen Formulardesigner 902, ObjectStore 904, Teile-Fabrik 906, Navigator 908, Teile-Pins-Verbindungen (910, und auch wie oben beschrieben), Teile-Manager 912 und Komponenten 914 dar. In einem Ausführungsbeispiel ist der Formulardesigner die Benutzerschnittstelle zum Teil und zum Verbindungssystem. Die Teile-Fabrik kann das Modul des Systems sein, dass zwischen einem XML-Format und der Teile-Hierarchien übersetzt. Der Navigator kann Änderungen an der Teile-Hierarchie beaufsichtigen (zum Beispiel, wenn ein Benutzer eine Umwandlung in ein neues Formular auslöst). Der Teile-Manager kann die Ausbreitung von Werten durch das Verbindungssystem beaufsichtigen. Der Formulardesigner kann die "Meta-Benutzer-Schnittstelle" sein, die es einem Benutzer erlaubt, Formulare durch eine Designer-UI aufzubauen und zu beeinflussen. Die Komponenten-Bibliothek kann Definitionen von Teilen beinhalten.
Wie erkennbar ist, kann sich das System im "Laufmodus" befinden, in diesem Fall arbeitet das UI-Trickfenster normal, oder im Designmodus, wo Mausklicke und andere Befehle die Form der Komponenten beeinflussen und erlauben, dass Pins und Verbindungen erstellt und beeinflusst werden. Der Formulardesigner verwendet Zeichnungs-Pins und Verbindungen und da Formulare auch nicht visuelle Teile als auch Steuerungen enthalten können, verwendet der Formulardesigner auch das Erstellen von Visualisierungen für solche Teile, wenn er sich im Designmodus befindet. In einem Ausführungsbeispiel wird der Formulardesigner als ein transparentes Overlay über ein Standard .NET-Fenster zur Ausführung gebracht. Selbst im Designmodus, wie oben beschrieben, können die Änderungen an einem Formular sofort reflektiert werden.
In einem Ausführungsbeispiel wird ein Formular entworfen, indem Komponenten aus der Komponenten-Bibliothek hineingezogen werden, was als ein Satz kleiner XML-Schnipsel umgesetzt wird, die eine Komponente definieren. Solche Komponenten können auf eine zugrunde liegende .NET-Klasse mit einigen Eigenschaften basieren, die als Pins exponiert werden. Wie erkennbar ist, kann dem Formular ein beliebiges Objekt hinzugefügt werden, das die notwendigen Verbindungs-Pins bereitstellt.
In einem Ausführungsbeispiel kann die VDL-Basis aus einer hierarchischen Struktur von Teilen oder Komponenten bestehen, spezifiziert durch eine Sammlung an XML-Dateien, z.B. in einem Format, das XUL oder XAML ähnelt. In einem Ausführungsbeispiel kann ein Teil eine Benutzerschnittstellensteuerung, wie eine Taste, Tabelle oder Textbox, ein Container für andere UI-Teile oder ein Nicht-UI-Teil sein, das Berechnungen im Hintergrund ausführt. In bestimmten Ausführungsbeispielen werden andere Module des Systems zentriert, um die Teilhierarchie auf gewisse Weise zu beeinflussen.
Wo das Verbindungssystem die Reflektionsfähigkeiten von .NET verwendet, ist es möglich, Objekte auf verfügbare Eigenschaften und Operationen zu untersuchen und sie während der Laufzeit aufzurufen. Reflektion kann verwendet werden, um dynamische Sprachen auf statischen zu schreiben. Die Rechenleistung ist im Allgemeinen kein Faktor in der UI-Ereignishandhabung, wie oben beschrieben.
Dynamischer Zugriff auf Ereignishandhabung während der Laufzeit kann auch durch Reflektion erfolgen, erfordert aber zusätzliche Komponenten. Zum Beispiel haben, .NET-Ereignisanwender starke Überprüfungstypen in ihren Argumenten, was es erschwert, einen universellen energischen Ereignisanwender zu haben, der mit Ereignissen aller Art arbeiten kann. Entsprechend kann ein kundenspezifischer Ereignisanwender kundenspezifische Ereignisanwenderklassen auf Anfrage erstellen, zur Laufzeit, unter Verwendung der eingebauten Verschlüsselungserzeugungsvorrichtung von .NET.
Wie beim Stand der Technik bekannt ist, verfügt .NET über ein grundsätzlich typisiertes Objektmodell. Alle Objekte gehören zu einer Klasse und alle Variablen, Argumente und Eigenschaften verfügen über einen Typ, der sie auf ein Objekt einer bestimmten Klasse beschränkt. In einem Verbindungssystem entsprechen Pins Variablen und sind somit typisiert. Der Pintyp kann eine nützliche Anleitung für die Verbindung sein und kann den Benutzer anleiten, andere bedeutungsvolle Verbindungen herzustellen und in einigen Fällen die Verbindung ganz automatisieren.
Es kann jedoch gewünscht werden, den Typ der Überprüfung zu lockern, der von .NET auferlegt ist und für die rigorose Objekt-orientierte Programmierung statt die mehr interaktive und informelle Aktivität des Formularaufbaus erstellt wurde. Es würde zum Beispiel nützlich sein, wenn ein Benutzer direkt einen numerischen Output verbinden kann (zum Beispiel von einem Zähler) zu einem Textfeld zur Anzeige, statt ihn explizit durch eine Typ-Umwandlungs-Komponente zu verbinden, wie es durch strenge Typüberprüfung erforderlich wäre.
Typzwang wird durch ein Modul definiert, das alles Wissen über Typzwänge kapselt und kann sowohl Werte zu Typen zwingen und über die Kompatibilität von Typen berichten (zur Fehlerüberprüfung und Rückmeldung während der Verbindung).
In einem Ausführungsbeispiel kann die starke Typisierung in Verbindung mit dem intelligenten Verbinden zum Einsatz kommen. Es kann oft lästig sein, Verbindungen mit der Maus herzustellen, aufgrund der kleinen Größe der Bildschirmpräsentation der Pins (was wiederum durch den Bedarf des Schonens des Bildschirms notwendig ist). Die alternative Verbindungstechnik ist die Verwendung einer Handbewegung mit der Maus, die von einem Teil zum nächsten reicht. Das System berechnet dann alle die möglichen Verbindungen, die vom ersten Teil zum zweiten erstellt werden könnten und verwendet das Typ-System als eine Beschränkung. Öfters wird es nur eine mögliche Verbindung geben, die dann erstellt wird. Wenn es mehr als eine gibt, kann der Benutzer die entsprechende Verbindung aus einem Dialog auswählen.
Ausbreitung ist der Prozess der Übertragung von Werten und Ereignissen von einem Teil zum anderen. In einem Ausführungsbeispiel muss der neue Wert auf die Input-Pins der verbundenen Teile ausgebreitet werden, wenn sich der Wert eines Output-Daten-Pins ändert. Dies kann wiederum verursachen, dass andere Komponenten ihre Output-Pins ändern und kann zu einer Ausbreitungskette führen. Eine visuelle Datenfluss-Sprache kann bestimmte Erwartungen durch seinen Gebrauch von Fluss-Metapheren erwecken.
Relevante Analogien sind der Elektrizitätsfluss durch einen Schaltkreis, Wasserfluss durch Rohre oder Verkehrsfluss durch ein Straßennetz. Diese Paradigmen zeigen, dass sich Ereignisse durch das Netzwerk parallel ausbreiten, wenn es mehrere Pfade gibt, die sich vom Originalknoten aus ausbreiten.
In einem Ausführungsbeispiel ist jedes Teil verantwortlich zur Ausbreitung aller Output-Pins, die sich verändert haben. Wie erkennbar ist, ist dies aus der Durchführungsperspektive natürlich und kann in Änderungen resultieren, die sich in einem ersten Tiefentraversal der verbindenden Grafik ausbreiten. In einem Ausführungsbeispiel kann eine erste Breiten-Grafik-Traversal verwendet werden, um die Verbindungen zwischen Topologie und Kausalität zu erhalten.
In einem Ausführungsbeispiel setzt der Teile-Manager die erste Breiten-Ausbreitung ein. Insbesondere kann dieses Modul alle Teile-Aktivierung und Ausbreitung überwachen und die Anordnung von Ereignissen steuern.
Damit die Ausbreitung stattfinden kann, muss das Verbindungssystem benachrichtigt werden, wenn eine Möglichkeit besteht, dass sich der Wert eines Output-Pins geändert hat. In einem Ausführungsbeispiel erfolgt dies durch das Erstellen von Ereignisanwendern für alle (oder einem Unterset von allen) Ereignissen auf einer gekapselten Steuerung. Diese Anwender können das Aktivierungs-() Verfahren aufrufen, die die Ausbreitung, wie oben beschrieben, initiieren können. In verschiedenen Ausführungsbeispielen können nicht endende Schleifen verhindert werden, indem die Ausbreitung nur bei Wertänderungen erfolgt und jeder Pin auf ein einziges Ausbreitungsereignis beschränkt wird.
10 stellt eine erste Tiefenausbreitung dar. Wie in 10 gezeigt, kann die Anzeigebox 1002 ein Moleküleditor sein, der einen Wert am Pin MolFileString 1004 und ein Ereignis am StructureChanged 1006 abgibt, wann immer der Benutzer die molekulare Struktur 1008 ändert. Das Ziel des Verbindungsnetzwerks ist, dass diese Handlung eine neue Abfrage auslöst. Wie erkennbar ist, hängt das Abfrage-Objektteil 1010, das die Abfrage ausführt, von zwei unterschiedlichen Pfaden ab, die den Molekül-Editor zurück verbinden. Für eine ordnungsgemäß arbeitende Verbindung muss die aktualisierte Anfrage vom QueryBuilder 1016 (über den QueryString Pin 1012) zur Verfügung stehen, bevor der Input der Displaybox 1002 (über den DoSearch Pin 1014) erhalten und die Abfrage ausgelöst wird. Um sicherzustellen, dass sich die Präsenz des QueryBuilder und QueryString in der ordnungsgemäßen Reihenfolge befinden, kann eine modifizierte Ausbreitungsheuristik eingesetzt werden.
In einem Ausführungsbeispiel verfolgt ein erster Breiten-Grafik-Traversal-Algorithmus Knoten, die gehandhabt werden müssen. In einem Ausführungsbeispiel ist der Teile-Manager (wie oben beschrieben) fähig, dies zu tun und ist außerdem fähig, eine Anzahl an Warteschlangen mit unterschiedlichen Prioritäten zu unterhalten. Allgemein ausgedrückt, ist es in diesem Zusammenhang das Ziel des Teile-Managers, Ereignisaktivierungen zuzulassen, nachdem alle Werte eingetroffen sind und zu versuchen Ereignisse zu ordnen, sodass alle Abhängigkeiten in der ordnungsgemäßen Reihenfolge berechnet werden. In einem Ausführungsbeispiel wird erste Tiefenausbreitung verwendet. In einem anderen Ausführungsbeispiel wird erste Breitenausbreitung verwendet.
Wie erkennbar ist, können die Warteschlangen Output-Pins enthalten, die ihre Werte noch über die angebrachten Verbindungen übertragen müssen. In einem anderen Ausführungsbeispiel werden zwei Warteschlangen verwendet, eine für Wert-Output-Pins und die andere für Ereignis-Output-Pins.
Ein Zyklus des Teile-Managers kann wie folgt beschrieben werden, obwohl dies nur eine repräsentative Beschreibung ist.

1) einen Pin aus der Warteschlange entfernen (siehe unten);
2) Senden des Werts entlang der angebrachten Verbindungen;
3) Input-Pins akzeptieren den Wert;
4) das zugehörige Teile-Verfahren wird abgerufen und führt möglicherweise in weiteren Output-Pins, die in die Warteschlange gestellt werden;
5) Wiederholen, bis Warteschlangen leer sind Wie erkennbar ist, kann die Auswahl des nächsten Pins zur Ausbreitung ein wichtiger Unterschied sein. Entsprechend ist der Teile-Manager fähig, die folgenden Schritte auszuführen:

Wenn es Pins auf der Wert-Pin-Warteschlange gibt, wählen Sie einen davon aus, ansonsten,
wenn es genau einen Pin auf der Ereignis-Pin-Warteschlange gibt, wählen Sie diesen aus, ansonsten,
wählen Sie einen aus den Ereignis-Pins in der Warteschlange, basierend auf deinen Abhängigkeiten, aus:
Sehen Sie bei jedem Pin, ob Abhängigkeiten zu einem anderen Pin vorliegen (z.B. ein Rückwärts-Treecrawl)
Wenn ein Pin ohne Abhängigkeiten gefunden wurde, wählen Sie ihn aus.
Wenn kein solcher Pin gefunden wurde, gibt es zirkuläre Abhängigkeiten und es ist nicht möglich, eine gute Anordnung auszuwählen. Geben Sie deshalb auf und wählen Sie den ersten Pin in der Warteschlange aus.
Dieser Abschnitt beschreibt einige Teile mit Sonderzweck, die den Grundmechanismus, der oben beschrieben wurde, erweitern, als auch einige Teile, die die Bibliothek der eingebauten Teile darstellen. Außerdem beschreiben verschiedene Begriffe unten viele Begriffe, die mit den vorliegenden Systemen und Verfahren zusammenhängen. Diese Teile können unabhängig oder zusammen in verschiedenen Ausführungsbeispielen, wie beschrieben, verwendet werden.
Zusammengesetzte Teile
Jede Programmierungssprache benötigt eine Art Abstraktionsmechanismus. In einem visuellen Verbindungssystem bedeutet dies im Allgemeinen die Fähigkeit, dass ein Netzwerk an Teilen und Verbindungen in eine einzelne Komponente zusammenfällt, sodass es leicht wiederverwendet werden kann. Diese können als zusammengesetzte Teile bezeichnet werden. Zusammensetzungen werden in separaten XML-Dateien definiert, die den gleichen Syntax wie Formulare verwenden, mit einem zusätzlichen Syntax, der ermöglicht, dass Pins der beinhalteten Teile auf die Oberfläche der Zusammensetzung befördert werden. Eine Zusammensetzung kann zum Beispiel eine Textbox, eine Kennzeichnung und einige ausgeblendete Mechanismen beinhalten.
Referenzteile
Referenzteile sind ein Teil der besonderen Art, das einem Formular ermöglicht, Kreuzreferenzen auf ein Teil zu beinhalten, das sich in seinem hierarchischen Bereich befindet oder anderweitig nicht direkt zugreifbar sind (zum Beispiel können sie verwendet werden, um Referenzen zwischen Teilen auf unterschiedlichen Teilfenstern eines Teilfenster-Containers im Registerformat zu erstellen). Referenzen können verwendet werden, um Eigenschaften der referenzierten Teile zu ändern, Pins zu exponieren oder zusätzliche Unterteile hinzuzufügen. Eine Referenz kann auch verwendet werden, um das Verhalten, Eigenschaften oder Children einer Klasse in einer Anwendungshierarchie von Klassen zu ändern.
11 stellt Referenzteile dar. Wie gezeigt, beinhaltet 11 zwei Referenzen: eine zum existierenden Hilfe-Menü 1102 sowie eine Referenz zu einem hinzugefügten Unterteil namens Rat-Element 1104. Dieses Element wird dann über eine Ereignisverbindung 1106 zu einem Dialog-Start-Teil 1108 verbunden, das einen Dialog öffnet, der durch eine separate XML-Datei definiert wird.
Wie oben und in Anlage D beschrieben, können verschiedene Dateien Referenzen haben, z.B. Application.xml, Workflow.xml und Form.xml können einige Referenzen haben.
Eine Referenz kann eine Verbindung sein (durch Name) zu einem Objekt in der Hierarchie. Die Hierarchie kann bevorzugt zusammengesetzt sein aus der VDL-Basis->Anwendung->Arbeitsfluss->Formular. In diesem Beispiel kann ein Objekt nur eine Referenz durch ein Objekt einer niedrigeren Ebene sein. Nachdem ein Objekt von einer dieser Ebene durch eine niedrigere Ebene referenziert wird, werden die Referenzattribute (der unteren Ebene) die Attribute des Objektes ändern. Nachdem sich die Ebene ändert, kehren die Attribute in ihren initialen Status zurück.
Zum Beispiel kann ein Formular eine Werkzeugleiste von der Basis während des Zeitraums, indem das Formular angezeigt werden kann, deaktivieren.
Die Base.xml kann sein:
Die FormCompLoc.xml kann sein:
Nachdem sich das Formular der Anwendung ändert, kann die Basis\Hauptwerkzeugleiste automatisch in ihren initialen Status zurückkehren (aktivieren = "wahr" sichtbar = "wahr"). Wenn ein Benutzer die Deaktivierung der Leiste während der gesamten Anwendung benötigt, dann kann die Referenz auf der Ebene der Application.xml statt auf der Ebene der Form.xml erfolgen.
Die ApplicationCompLoc.xml kann sein:
Gates
12 stellt Gates dar, wie sie entsprechend der vorliegenden Systeme und Verfahren verwendet werden. In einem Ausführungsbeispiel sind Gates reguläre Teile, die feingranuliertere Steuerung zulassen, wenn Werte entlang der Verbindungen übertragen werden. Zum Beispiel: Wenn der Text-Output-Pin 1202 einer Textbox 1204 direkt mit einer anderen Textbox oder einem Abfragegenerator verbunden ist, wird jedes Zeichen, das der Benutzer schreibt, den Wert des Pins ändern und dazu führen, dass Ereignisse nach vorn ausgebreitet werden. Dies schafft ein sehr "lebendiges" Gefühl einer Anwendung, kann aber Leistungsprobleme verursachen, wenn die Erhaltoperation teuer ist und kann auch für einen Benutzer verwirrend sein. Um dies zu ändern, wird ein Gate-Teil 1206 in die Verbindung eingebracht und durch das EnterKeyEvent (gesendet über Verbindung 1208) ausgelöst. Nun wird der Out-Pin des Gates 1210 den Textwert nicht übertragen, bis zum ordnungsgemäßen Punkt.
Flaschen
Flaschen lösen ein semantisches Problem, das bei visuellen Komponentensprachen geläufig ist. Das Problem ist die Dichotomie zwischen Objekten, die relativ statisch sind (die Komponenten) und die, die sich entlang der Verbindungen in virtueller Bewegung befinden (Datenwerte). Eine Flasche nimmt im Wesentlichen ein Datenobjekt auf und hält es, sodass dessen Eigenschaften durch die Verbindungen bewertet werden können.
In einem bevorzugten Ausführungsbeispiel akzeptieren Flaschen ein Objekt als Input und einen String, der die Eigenschaft, die von Interesse ist, angibt. Solcher Input kann gespeichert werden ("abfüllen"). Flaschen können zwei Pins, Out und In, bereitstellen, die den Wert der benannten Eigenschaften verfügbar und jeweils einstellbar machen. Erweiterungen zu den Durchführungen würde in Laufzeit die Erstellung von multiplen Pins zulassen, die mehrere Eigenschaften exponieren, als auch andere Mitglieder des abgefüllten Objektes, wie Ereignisse und Methoden.
Funktionelle Rechenteile
Das Komponentenset beinhaltet ein Teileset, das funktionelle Berechnungen ausführt, einschließlich Arithmetik, Boolean-Logik, Ungleichungen und dergleichen. Diese Teile exponieren im Allgemeinen einen oder mehrere Daten-Pins und einen einzelnen Output-Daten-Pin und sind vom Konzept her ziemlich einfach, da sie keinen Status oder Ereignis beinhalten. Andere Teile dieses Typs beinhalten den StringMaker, Wenn/dann/sonst schaltet und Teile zum Extrahieren von Datensätzen.
Abfragebezogene Teile
In verschiedenen Ausführungsbeispielen werden derzeitige Anwendungen verwendet, um Datenbanken abzufragen und sie zu durchblättern. Entsprechend besteht eine Anzahl an Teilen, die in diesem Prozess zur Hilfe stehen. Diese beinhalten das Abfrageobjekt, das als Input eine Abfragespezifikation akzeptiert in UQL, eine Variante von SQL) und gibt einen Datensatz an einen Output-Pin aus. Andere Teile können diese Datensätze anzeigen, speichern oder beeinflussen.
Außerdem ist ein weiteres wichtiges Teil das Data Aware Form (Daten-Kenntnis-Formular) (DAF): ein Formular, das einen Datensatz als Input akzeptieren und es über das Verbindungssystem zu internen Teilen verteilen, das extrahieren und individuelle Felder anzeigen kann. Das DAF kann auch einen ähnlichen Prozess für Abfrageformulare ausführen, wo es Abfrage-Sätze von verschiedenen Feldern sammelt, sendet sie durch logische Abfrage-Teile, um sie zu kombinieren und erzeugt eine vollständige UQL-Aussage.
Asynchrone Teile
Wie beschrieben führen die meisten Teile entweder UI-TAsks oder einfache Berechnungen aus, die eine geringfügige Zeitmenge in Anspruch nehmen. Teile, die zeitraubende Tasks durchführen, müssen sie in einem separaten Thread durchführen, um lange benutzersichtbare Verzögerungen zu vermeiden. Das oben beschriebene Abfrageobjekt funktioniert auf diese Weise, da Abfragen eine signifikante Zeitmenge in Anspruch nehmen können. Im Allgemeinen wird ein Teil einen Thread starten, wenn es durch ein Ankunfts-Ereignis ausgelöst wird und wenn der Thread abgeschlossen ist, werden einige Werte auf die Output-Pins gelegt. In einem Ausführungsbeispiel erfolgt die gesamte Ausbreitung innerhalb eines einzelnen Threads.
Wie erkennbar ist, können andere Ausführungsbeispiele durchgeführt werden, wie als ein Teil, das mit einem Barcode-Leser verbunden ist und es als Input für einen normalen Abfrageprozess verwenden; ein Teil, das die Text-zu-Sprache Übersetzung durchführt; numerische Anzeigeteile, die ihre Werte je nach Spektrum farbcodieren; und ein Teil, das eine Excel-Tabellenkalkulation umwickelt und zulässt, dass Abfrageergebnisse darin verbunden sind. Diese Teile können dann über die Verbindungssprache verbunden werden, um bestehende Funktionalitäten zu verwenden (zum Beispiel, die Inputs oder Outputs der Datenbankabfragen).
In einem Ausführungsbeispiel kann, um den Bildschirm zu bewahren, eine separate logische Ansicht für das Ausführen der Verbindung, in der das Layout der Komponenten von deren "physikalischem" Ort in der Schnittstelle des Endbenutzers entkoppelt werden. In einem Ausführungsbeispiel können spezielle Anordnungskomponenten oder die Hinzufügung der Anordnungsvermerke an die Verbindungen durchgeführt werden, um den oben genannten Vorgang weiter zu ermöglichen.
Wie erkennbar ist, kann das Erstellen langer Formulare vereinfacht werden, indem die Erstellung von vielen Verbindungen in einer einzigen Operation zugelassen werden. Debugging kann außerdem Debugging-Tools durchführen, die Spuren der Verbindungsaktivität drucken; als auch kompliziertere Tools, die Steppers und intelligente Tracer beinhalten, die Ereignisse kurz fassen, damit sie besser verständlich sind.
Suchhistorie
13 stellt eine typische historische Suchstruktur dar. Eine Beschreibung der Suchhistorie ist unten beinhaltet und eine detaillierte Erläuterung ist in der Anlage C beinhaltet. In einem Ausführungsbeispiel verwendet VDL-Basis ein Baum-Paradigma zum Darstellen der Anfragen (Pfeile) und Ergebnisse (Knoten), die der Benutzer vervollständigt hat. In einem Ausführungsbeispiel ist die VDL-Basis hoch-interaktiv. Benutzer können zum Beispiel auf Pfeile in der Struktur klicken, um zu den Abfrageformularen zu navigieren, die zum Spezifizieren für diese Abfragen verwendet werden. Modifizieren des Abfrageformulars verursacht, dass ein neuer Pfeil entsteht, der eine neue Abfrage darstellt. Das Klicken auf einen Knoten (z.B. die gefüllten Kreise in der Struktur) bringt den Benutzer zu den Ergebnisformularen, die durch diesen Knoten repräsentiert werden. Das Ziehen einer Abfrage von einem Knoten zu einem anderen Knoten wendet diese Abfrage beim neuen Knoten an (verwendet das Ergebnis-Set, das durch den neuen Knoten repräsentiert wird, als die Suchdomäne für diese Abfrage). Das Ziehen eines Knotens zu einem anderen Knoten ermöglicht dem Benutzer, die "logische Liste" zu verwenden, um ein neues Ergebnis-Set von den beiden Original-Ergebnis-Sets zu erstellen. Zum Beispiel kann ein Popup-Fenster den Typ der Handlung erfordern, den ein Benutzer wünscht. In einem Ausführungsbeispiel kann ein Benutzer einen Rechtsklick auf Knoten oder Pfeile durchführen, um auf den Abfragen oder Ergebnis-Sets zu operieren, die sie darstellen (z.B. Speichern des Formulars, Exportieren des Ergebnis-Sets, Speichern eines Teilgebietes, Umbenennen, Ändern der Beschreibung usw.)
In einem Ausführungsbeispiel ist die Suchhistorie-Grafik-Einträge und Strukturabfragen und andere produzierende Operationen für Datensätze, die Ergebnisse dieser Operationen und die Beziehung zwischen ihnen beinhaltet. Es zeigt sie in grafischer Form an und erlaubt dem Benutzer, sie einzusehen und zu verwalten. Es ist gewöhnlich mit einem Anzeige-Teilfenster verbunden, das es zur Anzeige der ausgewählten Datensätze und Abfragen verwendet. In einem Ausführungsbeispiel stehen mehrere Suchteilfenster zur Verfügung, die jeweils eine Suchstruktur (oder Suchelemente) beinhalten, die für einen Benutzer zur Anwendung eines bestehenden Knotens (Ergebnisse) oder Ecke (Abfrage) auf einem angezeigten Knoten zur Verfügung stehen. Zum Beispiel kann ein Knoten auf einem Suchbildschirm auf einen Knoten in einem separaten Suchbildschirm gezogen und abgelegt werden. Auf diese Weise können Benutzer Elemente innerhalb und auch zwischen Fenstern, Teilfenstern oder Suchbildschirmen ziehen und ablegen. Suchelemente können Filter, Abfragen, angezeigt als ein Pfeil oder Elemente in der Bibliothek, Ergebnisse von vorherigen Abfragen, angezeigt als Knoten oder als ein Element in der Bücherei usw., beinhalten.
In einem Ausführungsbeispiel ist die visuelle Anzeige der Suchhistorie eine Grafik, die aus Knoten, verbunden durch Ecken, besteht. Knoten können Suchergebnisse darstellen (Liste von Datensätzen) und Ecken können Operationen darstellen, die neue Listen erzeugen (fragt andere Operationen ab). Sowohl Knoten als auch Ecken können aktive UI-Objekte sein. Knoten stellen Nutzwerte für Datensatz-Operationen dar, wie das Wiederaufsuchen eines Ergebnissets und das Starten einer neuen Suche. Ecken stellen Nutzwerte für Abfrage-Operationen dar.
Die Suchhistorien-Grafik kann aus einer Kontrollleiste oben und einem Anzeigegebiet unten bestehen. Sie kann ein zugehöriges Anzeige-Teilfenster haben, gewöhnlich zur rechten, das verwendet wird, um ausgewählte Elemente anzuzeigen. Die Anzeige zeigt das Netzwerk der Knoten und Ecken an. Ein Knoten oder Ecke kann ausgewählt werden, in diesem Fall werden sie grafisch hervorgehoben. Multiple Auswahlen werden nicht unterstützt.
Außerdem kann die Suchhistorie ein Menü mit Menüelementen, wie Speichern, Speichern als, Ausschneiden/Kopieren/Einfügen ausführen und sollte auf das ausgewählte Objekt angewendet werden, wenn zutreffend.
Wie erkennbar ist, gibt es mehr als einen Wurzelknoten. Gewöhnlich wird die Suchhistorie mit einem einzelnen Wurzelknoten starten, der eine Datenquelle darstellt. Der einzelne Knoten kann jedoch auch ein Ergebnisset von einer Suchabfrage darstellen. Die Anzeige wird automatisch ausgelegt und rekonfiguriert sich selbst, wenn Knoten und Ecken hinzugefügt oder gelöscht werden. In einem Ausführungsbeispiel werden auch manuelle Layout-Mechanismen bereitgestellt.
14–21 stellen eine typische Benutzschnittstellenfenster während des Formulardesigns dar. Wie während des visuellen Formulardesigns gezeigt, kann ein Benutzer verschiedene Komponenten, Teile, Pins, Verbindungen usw. (wie oben beschrieben) auf ein Formular ziehen und ablegen. Die entsprechenden Verfahren und Funktionen werden angewendet, indem die beschriebenen Systeme und Verfahren verwendet werden.
Wie in 14 gezeigt ist, wird ein Formular angezeigt, wobei dem Benutzer eine Suchstruktur in Fenster 1402 zur Verfügung steht. Die im Fenster 1402 angezeigten Ergebnisse stammen von einer vorherigen Benutzersuche. Ein Benutzer kann ein Suchelement von einer Bibliothek an Suchelementen auf einen Knoten oder einen Pfeil in einer Suchstruktur ziehen, um eine neue Suche auszuführen. Solche Suchelemente können Filter, Abfragen (angezeigt als ein Pfeil oder ein Element in der Bibliothek), Ergebnisse von vorherigen Abfragen (angezeigt als ein Knoten oder ein Element in der Bibliothek) usw. beinhalten. Zum Beispiel kann ein Benutzer einen molekularen Gewichtfilter (Box 1410) auf das Element 1408 ziehen, um die Ergebnisse weiter zu filtern. Einschließlich als ein anderes Beispiel, kann der Benutzer eine vordefinierte Benutzerabfrage von der Bibliothek auf einen Knoten ziehen, um die Ergebnisse weiter zu filtern. Einschließlich als ein noch weiteres Beispiel, kann der Benutzer ein Ergebnis von der Bibliothek auf einen Pfeil ziehen, der eine Suchabfrage darstellt. Wie erkennbar ist, kann ein neuer Ergebnisknoten oder eine neue Suchabfrage zur Bibliothek der Suchelemente hinzugefügt werden, damit ein Benutzer darauf zugreifen kann.
Wie in Verbindung mit 19 beschrieben, können die Suchelemente auch Knoten beinhalten, die Suchergebnisse darstellen und Pfeile, die Suchabfragen darstellen, die bereits auf der Suchstruktur angezeigt werden. In einem Ausführungsbeispiel kann ein Benutzer eine Suchstruktur aktiv modifizieren, indem Suchelemente, die auf dem Bildschirm angezeigt werden, gezogen und abgelegt werden. In einem anderen Ausführungsbeispiel kann ein Benutzer aktiv eine Suchstruktur modifizieren, indem Elemente von einer Bibliothek von Suchelementen gezogen und abgelegt werden.
15 zeigt, dass ein neuer Pfeil 1502 geformt wurde, der den Such-Modifizierer darstellt und ein neuer Ergebnisknoten wurde erzeugt 1504.
Wie in 16 gezeigt, kann ein Benutzer auf eine Aktion (Pfeil) klicken, um die Suchkriterien zu modifizieren. Der Benutzer kann zum Beispiel den molekularen Gewicht-Filter (1602) auf < 200 modifizieren und die Taste Filter ausführen 1603 klicken.
17 stellt das Ergebnis der Modifikation des Filters dar. Wie gezeigt, stellt Pfeil 1702 eine neue Handlung und Knoten 1704 neue Ergebnisse dar, die erzeugt wurden. Die Ergebnisse können wie gezeigt gespeichert werden, indem Sie einen Name (1720), Beschreibung (1730) angeben und dann auf die Taste "OK" klicken (1740). 18 zeigt die Ergebnisse des Anwendens des neuen Filters, wie in der 17 beschrieben. 17.
19 zeigt den Effekt des Ziehens und Ablegens von einem Knoten zu einem anderen Knoten. Wie gezeigt, wird der Ergebnis-Knoten 1902 auf den Ergebnis-Knoten 1904 gezogen. Wie oben beschrieben, erkennt das System, dass der Benutzer die Kombination der Ergebnisse der beiden Knoten wünscht und fragt entsprechend nach dem Typ der Kombination, den der Benutzer in der 20 wünscht. 20. Wie in 21 gezeigt, hat der Benutzer ausgewählt, die Ergebnisse zu OR, was einen neuen Ergebnis-Knoten 2102 ergibt. Wie erkennbar ist, geben die Zahlen bei den Ergebnis-Knoten die Anzahl der Einträge an, die mit diesem Knoten übereinstimmen. Damit liegen für Knoten 1902 432 Ergebniselemente vor und für Knoten 1904 gibt es 588 Elemente. Wenn diese Ergebnisse OR werden, gibt es 1020 Ergebniselemente, wie in 21 angegeben. 21.
22 zeigt einen typischen VDL Arbeitsfluss. Wie gezeigt, kann ein Arbeitsfluss eine Vielzahl an Arbeitsfluss-Elemente umfassen, einschließlich das Erstellen von Datenquellen, Erstellen von Datenbanken, Erstellen von Formularen, Registrieren, Output, UI-Navigation, Suchhistorie, Listenlogik, Grafiken, Tasks, Suchen und Durchsehen. Außerdem kann der Fluss über Elemente springen, um effizientere Ergebnisse zu erreichen.
In einem Ausführungsbeispiel werden die Klassen-Elemente, Verfahren, Funktionen usw. wie in Anhang A gezeigt, durchgeführt. In einem Ausführungsbeispiel werden die vorliegenden Systeme und Verfahren in Übereinstimmung mit den funktionellen Spezifikationen erstellt, die in Anhang B beinhaltet sind.
Eine weitere Beschreibung verschiedener Ausführungsbeispiele wird in Anhang D bereitgestellt. Andere Ausführungsbeispiele sind für Fachmänner offensichtlich.
Zur Erleichterung der Diskussion werden Funktionen der Komponenten unabhängig beschrieben. Obwohl Komponenten und deren Funktionen unabhängig beschrieben werden können, wird ein Fachmann erkennen, dass eine Komponente fähig sein kann, die Funktionen einer beliebigen Anzahl an Komponenten auszuführen. Wo es zum Beispiel beschrieben ist, dass eine Komponente zu einem exponierten ersten Attribut und eine zweite Komponente zu einem exponierten zweiten Attribut gehört, sollte erkannt werden, dass eine Komponente fähig sein kann, sowohl das erste und das zweite Attribut zu exponieren.
Während die vorliegende Erfindung in Bezug auf verschiedene Ausführungsbeispiele dargestellt und erläutert wurde, besteht nicht die Absicht, sie auf die gezeigten Details zu beschränken, da verschiedene Modifikationen und Strukturänderungen vorgenommen werden können, ohne vom Sinn der vorliegenden Erfindung abzuweichen. Außerdem, obwohl die oben genannten Beschreibungen hauptsächlich auf Ausführungsbeispiele bezogen ist, wo .NET verwendet wird, kann ein Fachmall erkennen, dass die Erfindung nicht auf diese Ausführungsbeispiele beschränkt ist und auf einer beliebigen Anzahl Plattformen verwendet werden kann. Ohne weitere Analyse wird das Vorbenannte den Inhalt der vorliegenden Erfindung offen legen, den Andere, durch das Anwenden von heutigen Kenntnissen, leicht aus verschiedenen Anwendungen anpassen können, ohne Merkmale auszulassen, die vom Standpunkt der früheren Technik wesentliche Charakteristiken der generischen oder spezifischen Aspekte dieser Erfindung darstellen.
ANHANG A
VDL.Basis.

Beschreibung: Beinhaltet die VDL Basis-Hauptklasse, welches das Programm startet.

VDL-Klasse

Beschreibung: Hauptklasse, die das Programm startet.

IVDLBasis-Schnittstelle

Beschreibung: Hauptklasse, die das Programm startet.

VDL.Basis.Steuerungen.

Beschreibung: Basis-UI-Komponente, die auf ein .NET-Formular platziert und für Basisfunktionalitäten zusammen verbunden werden kann.

VDL.Basis.Steuerungen.Datenkenntnis

Beschreibung: Datenkenntnissteuerungen können zusammen zu anderen Steuerungen verbunden werden, damit Änderungen in einer beliebigen Steuerungseigenschaft andere Steuerungen auf diese Änderung aufmerksam machen.

VDL.Basis.Steuerungen.Suchhistorie
VDL.Basis.Framework.

Beschreibung: Beinhaltet Klassen, die mit dem zugrunde liegenden Basis-Framework umgehen

VDL.Basis.Framework.Verbinden.

Beschreibung: Beinhaltet Klassen, die mit der Verbindung des zugrunde liegenden Basis-Frameworks umgehen.

VDLInterne.Basis.

Beschreibung: Nur für den internen Gebrauch.

VDLBasis_Imp-Klasse

Beschreibung: Hauptklasse, die das Programm startet.

VDLInterne.Basis.Steuerung.

Beschreibung: Nur für den internen Gebrauch.

Feldauswahl_Imp-Klasse

Beschreibung: Anzeige der Strukturansicht der Felder in der derzeitigen Datenbank. Ermöglicht dem Benutzer, Felder auszuwählen.
Erlaubt dem Benutzer, Felder zu ziehen oder einen Doppelklick darauf auszuführen, eine Handlung zu initiieren (z.B. zu einer Abfrage ein Feld hinzuzufügen)
Ermöglicht dem Benutzer, innerhalb der Struktur zu suchen.

Beschreibung:

• Instanziieren den Feldselektor. Der Feldselektor kann instanziiert werden, indem ein Standardkonstruktor verwendet wird und referenziert werden, indem eine Variable der Typsteuerung verwendet wird, wie bei jeder beliebigen .NET-Steuerung.:
• Laden des Feldselektors mit Feldern einer Datenquelle. Die Wurzeleigenschaft muss bei einem Wurzel-Felddeskriptor-Objekt eingestellt sein. Die Felddeskriptor-Strnktur wird von den Metadaten für die Datenquelle erstellt.
Der Einfachheit halber wurde eine write-only Datenquell-Eigenschaft hinzugefügt. Dies führt dazu, dass der Feldselektor die Felddeskriptoren erzeugt und die Wurzeleigenschaften festlegt. Es kann jedoch angebrachter sein, dem Objekt der Datenquelle zu gestatten, die Felddeskriptor-Hierarchie zu erzeugen.
• Suchen nach einem Knoten. Suche nach einem bestimmten Feldnamen und dessen Auswahl.
Um den nächsten Fall dieses Feldnamens zu finden, beginnend bei der Auswahl:
• Reagieren auf Auswahl und andere Handlungen. Der Feldselektor wird ein NachAuswahl-Ereignis generieren, wann immer ein Knoten als Ergebnis eines Mausklicks, eines Tastaturereignisses oder eines Programmierereignisses ausgewählt wird. Ein Standardereignisanwender kann darauf reagieren.
• Reagieren auf Auswahl und andere Handlungen. Der Feldselektor wird ein NachAuswahl-Ereignis generieren, wann immer ein Knoten als Ergebnis eines Mausklicks, eines Tastaturereignisses oder eines Programmierereignisses ausgewählt wird. Ein Standardereignisanwender kann darauf reagieren.

Es gibt auch spezielle NachErweiterungs- und NachZusammenfall-Ereignisse, die sich spezifisch auf den Feldselektor beziehen.
Andere Ereignisse werden den Standardereignis-Handhabungsmechanismus von der Steuerung übernehmen, einschließlich den Doppelklick.
Verwendung der Schnittstelle der zugrunde liegenden Struktursteuerung
Wir müssen annehmen, dass die zugrunde liegende Struktursteuerung über eine nützliche Funktionalität verfügt, die wir nicht in der AbstraktFeldSelektor-Schnittstelle duplizieren müssen. Ein Entwickler sollte in der Lage sein, dies zu tun.
Es liegt in der Verantwortung des Entwicklers, die Steuerung in einem Status zu belassen, der für den Feldselektor noch einen Sinn ergibt. Eine Anwendung sollte zum Beispiel Datenobjekte, die an Strukturknoten angebracht sind, nicht löschen, da diese durch den Feldselektor verwendet werden können.
Eigenschaften

ausgewähltesFeld als Objekt Beschreibung: Das ausgewählte Feld
Wurzel als String Beschreibung: String, der den Wurzelfeldpfad enthält.

Verfahren

finden (Feldname als String) als Boolean Beschreibung: Findet und wählt das Feld nach seinem Namen aus.. Parameter: Feldname als String Beschreibung: String, der den Namen des Feldes enthält. Sendet zurück: Boolean, wahr wenn erfolgreich gefunden.

DateiOrduerStruktur_Imp

Beschreibung: Dies ist eine UI-Steuerung, die als Teil in das Formular verwendet werden kann. Alle Operationen kommen als ungültig zurück und nehmen keine Argumente an. Der Rückkehrwert und die Argumente sind durch die Steuerungseigenschaften zugreifbar.

Ablegobjekt (Historienliste/Datensatz/Molekülentwurf/...) in die Betriebssystemhierarchie zum speichern. Ziehen Sie das Objekt zum Lesen und zum Verwenden. Browsen Sie das Betriebssystem. Umbenennen/Löschen/Erstellen eines Dokuments. Verschieben/Kopieren eines Dokuments. Suchen des Dokuments nach Eigenschaften (Attribut)-Wert.
Endbenutzer-Interaktion beinhaltet ein Unterset des Systemdateimanagements.

Beschreibung: Erlaubt dem Entwickler, die meisten Aspekte des Dateisystemmanagements auszuführen.
- • Anzeigen von Dateien und Ordnern, die auf der lokalen Maschine als auch auf dem Objektaufbewahrer im ICS-Server verfügbar sind.
- • Lese- und Schreibfähigkeit bei Dateien erlauben.
- • Stellt Suchfähigkeiten bereit.

Eigenschaften
Kontexte als String[] (nur zum Holen)

Syntax: Verfügbarer Objektaufbewahrungs-Wurzelnamen als String[]
Beschreibung: Abrufen aller Objektaufbewahrungs-IOddner-Wurzelnamen, die in der Client-Objektaufbewahrung verfügbar sind. Listen Sie die oberen Knotennamen der Verzeichnisansicht auf. Sie stellen alle Wurzelordner dar, die vom ICS-Objektaufbewahrungsdienst und der lokalen Objektaufbewahrung verfügbar sind.

Dokumentname() als String

Beschreibung: Dokumentname mit dem das Dokument gelesen oder gespeichert werden sollte. Dokumentname, durch den Benutzer nach dem Entsorgen des Öffnen/Speichern Dialogs festgelegt wurde. DokumentName wird auch direkt durch den Benutzer festgelegt, wenn er/sie durch die Struktur der Ordner und Dokumente navigiert. Der Dokumentname stimmt mit dem vollständigen Pfad des derzeitig ausgewählten Elements in der Strukturansicht überein. Zum Beispiel: "MyComputer\C:\\temp" oder "MyComputer\C:\\VDL\isentris1.1\Readme.txt".

Dokumentinhalt() als String

Beschreibung: Dokumentinhalt zum Speichern oder Dokumentinhalt zum Lesen.

Suchattribute MethodeExponieren(String)

Beschreibung: Attributname, der im Suchvorgang verwendet wird. Dies ist eines der Attributnamen, die vom Isentris-Objektaufbewahrungsdienst verfügbar sind.

Suchwert() als String

Beschreibung: Attributwert, der im Suchvorgang verwendet wird. Die Art, wie der Attributwert verwendet wird, hängt vom Attribut ab. Bitte nehmen Sie auf die ICS-Entwicklerdokumentation Bezug.

DialogZeigen() als Boolean

Beschreibung: Flagge zum Spezifizieren, ob der Endbenutzer mit den Speicher- und Leseoperationen interagieren sollte.

Dialogtitel() als String

Beschreibung: Dialogtitel, der für den Öffnen/Speichern Dialog verwendet werden sollte.

LetztesSuchergebnis() als String

Syntax: () als String
Beschreibung: Liste der Dokumentnamen (Verzeichnis und Dokumentnamen), die mit dem Suchkriterium übereinstimmen.

Verfahren
Lesen() ungültig

Beschreibung: Dies ist die Umkehr des Speicherverfahrens. Dokumentnamen wird als Input-Argument verwendet und Dokumentinhalt hält das Ergebnis dieses Vorgangs.
Parameter: keiner
Rückkehr: ungültig.

Speichern() ungültig

Beschreibung: Diese Operation nimmt den Wert des Dokumentinhalts und speichert ihn in einem Dokument. Wenn DialogAnzeigen falsch ist, wird Dokumentname direkt den Ort des zu speichernden Dokuments angeben. Sonst wird der Wert DocumentName als vorgeschlagener Wert verwendet, wenn der Öffnen/Speichern Dialog erscheint. Wenn der Dialog entsorgt wurde, halten die Eigenschaften von Dokumentname den vom Endbenutzer eingegebenen Wert.
Parameter: keiner
Rückkehr: ungültig.

Suchen() ungültig

Beschreibung: Dies folgt dem isentris-Suchkonzept beim Objektaufbewahrdienst. Suchattribut und Suchwert werden als Input verwendet, um ein Suchkriterium zu erstellen. LetzteSuchergebnisse hält die Liste der Dateien, die mit diesem Kriterium übereinstimmen, vom Verzeichnis, das dem Dokumentnamen entspricht. Wenn es mehr als ein Suchergebnis gibt, wird der Navigationspfeil (vorherig/nächster) aktiviert.
Parameter: keiner
Rückkehr: ungültig.

Hilfe_Imp-Klasse

Beschreibung: Der Benutzer bittet um Hilfe, "F2" und Anwendungsformular und die Hilfe wird entsprechend in Bezug auf Sprache konfiguriert, die Datei wird gefunden und angezeigt. Der Benutzer klickt auf einen Hyperlink eines Hilfeabschnitts und die Hyperlinkseite wird angezeigt.

Verfahren
getHelpForID (ID als String) als Hilfe

Beschreibung: Parameter: ID als String Beschreibung: Sendet zurück: Das Hilfeobjekt

getHelp() als String

Beschreibung: Parameter: Beschreibung: Sendet zurück: String, der den Hilfetext enthält.

MSOfficeControl_Imp-Klasse

Beschreibung: Manipulation von MS Office und anderen OLE-Anwendungen. Bearbeiten und Speichern der Dokumente. Ziehen von Office-Dokumenten zur Anzeige. Mehrere Möglichkeiten, um Dateien zu öffnen (API und Dialog)
Beschreibung: Dies ermöglicht dem Entwickler, die UI-Funktion des Einbettens eines Nicht-VDL Basisdokuments in ein .NET-Formular auszuführen. Diese Funktion ahmt die Fähigkeit des Benutzers nach, die gleiche Task in der UI auszuführen. Kann in ein Formular platziert werden und gestattet dem Benutzer, ein beliebiges Dokument einzubetten, das mir dem IE eingesehen werden kann. Dialogfenster können hinzugefügt werden
- • Hinzufügen einer OfficeSteuerung zu einem Formular, sodass der Benutzer Dokumente in das Formular einbetten kann.
- • Laden, Speichern und Schließen des Dokuments in der Steuerung.
- • Präsentiert dem Benutzer ein Microsoft Dialogfenster, sodass sie die zu ladende Datei auswählen können und der Entwickler kann auch die Auswahl auf einer Liste mit Dateitypen einschränken.

Verfahren
LadenDatei (Dateiname als String) als int

Beschreibung: Erlaubt dem Entwickler, eine beliebige Dokumentdatei in die Steuerung zu laden, die in einem Formular eingebettet ist.
Parameter: Dateiname als String
Beschreibung: Dateiname mit Pfad (relativ oder absolut)
Sendet zurück: eine Ganzzahl 0 wenn erfolgreich oder die Nicht-Null für die Anmerkung verschiedener Fehler.

DateiSpeichern() als int

Beschreibung: Erlaubt dem Entwickler, eine beliebige Dokumentdatei zu speichern, die in der Steuerung geöffnet ist.
Sendet zurück: eine Ganzzahl 0 wenn erfolgreich oder die Nicht-Null für die Anmerkung verschiedener Fehler.

DateiSchließen() ungültig

Beschreibung: Schließt die Datei.
Sendet zurück:

LadenVonDialog() als Int

Beschreibung: Erlaubt dem Entwickler, ein Dialogfenster für den Benutzer zu öffnen, der die Dokumente beschränkt, die in die Steuerung geladen werden. Die derzeitige Liste beinhaltet: Word, Excel, PowerPoint und HTML. Die Liste kann vom Entwickler erweitert oder verkleinert werden. Sendet zurück: eine Ganzzahl 0 wenn erfolgreich oder die Nicht-Null für die Anmerkung verschiedener Fehler wenn der Benutzer abbricht.

DefinierenDialogLadeliste(DokumentTypen als String) ungültig

Beschreibung: Definiert den Dokumenttyp, der durch den Pop-up Dialog geöffnet werden kann.
Parameter: DokumentTypen als String
Beschreibung: Ein String, der alle die Dokumenttypen enthält, die durch den Pop-up Dialog geöffnet werden können. (Hinweis, der String muss nach MS Dialogformat formatiert sein. Beispiel:

TaskLeiste_Imp
Beschreibung: Leiste links in der Anwendung, startet verschiedene Anwendungen. Benutzer klickt auf ein Anwendungssymbol und die Anwendung startet. Der Benutzer führt einen Rechtsklick auf das Anwendungssymbol aus und die Anwendung wird ausgeblendet, ist aber noch vorhanden.
Verfahren
getListOfApplications as Applications[]

Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Eine Reihe von Anwendungen

getListeDerLaufendenAnwendungen() als Anwendungen[]

AnwendungÖffnen(Anwendung) ungültig

Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

AnwendungSchließen(Anwendung) ungültig

Strukturerbringer_Imp-Klasse

Beschreibung: Erbringt eine einzelne Struktur für einen beliebigen Grafikkontext. Zeigt eine einzelne Struktur in einer Benutzersteuerung an. Bearbeitet eine einzelne Struktur einer Benutzersteuerung und sendet die bearbeitete Struktur zurück.

Werkzeugleiste_Imp-Klasse

Beschreibung: Verfugt über übernommene Standardsteuerungsmitglieder (Aktivieren, sichtbar, Hintergrundfarbe etc.). Werkzeugleisten-Tasten sind in einer Werkzeugleiste beinhaltet. Die Tasten können eine Dropdown-Liste mit weiteren Tasten beinhalten.

Eigenschaften
Tasten

Beschreibung:

Tastengröße

Beschreibung:

Verfahren
Werkzeugleiste()

Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

Ereignisse
aufTastenklick()

Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

aufTastenDropDown()

Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

VDLIntern.Basis.Steuerung.Datenkenntnis
Beschreibung: Nur für den internen Gebrauch.
Formular_Imp

Beschreibung: Hinzufügen/Entfernen von Steuerungen. Erhalten/Festlegen von Verhalten (Modus). Akzeptieren und Anzeigen von Datensätzen. Anzeigen/Ausblenden von Verbindungen. Steuerungen von Beschreibungen über Fabrik aufbauen. Kopiert an Clipboard (Bild, Daten und UQL). Erzeugt UQL. Fortbestehen/Nicht fortbestehen

Eigenschaften Verfahren
Raster_Imp-Klasse

Beschreibung: Hinzufügen/Entfernen von Feldern. Feldformat festlegen. Layout festlegen. Feld ausblenden zeigen. Kopieren ausgewählt. Sortieren. Drehen. Tabellenkalkulation erstellen.

Eigenschaften
Feldkopfleisten() als String

Layout als String

Beschreibung:
Parameter: Tabellenkalkulation/Platine
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

ToolTipText als String

Beschreibung: Nützlich für Mol und Roen
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

Verfahren
Abfrage_Imp-Klasse

Beschreibung: Bindet an einen Felddeskriptor. Binden einstellen/ändern. Kopiert an Clipboard (Bild, Daten und UQL). Fortbestehen/Nicht fortbestehen. Erzeugt UQL. Benutzer modifiziert (d.h. Ändern von Abfragewerten, Bearbeiten von Strukturen usw.). Größe abpassen und neu positionieren

FormularBox_Imp-Klasse
Habe dies mit 70 besprochen. Sollte ziemlich vollständig sein. [kw]
Eine Box, die auf ein Formular platziert wird, um Werte eines Datenbankfeldes anzuzeigen oder abzufragen. Es gibt verschiedene Boxtypen zum Abdecken verschiedener Datentypen. Jeder Typ wird über einen DISPLAY-Modus, der nur die Datenbankwerte anzeigt und einen QUERYLET-Modus mit Suchoptionen verfügen, die exponiert oder ausgeblendet werden können. Formular

Beschreibung: Bindet an einen Felddeskriptor. Binden einstellen ändern. Kopiert an Clipboard (Bild, Daten und UQL). Fortbestehen /Nicht fortbestehen. Erzeugt UQL. Benutzer modifiziert (d.h. Ändern von Abfragewerten, Bearbeiten von Strukturen usw.). Größe abpassen und neu positionieren Verfahren

GetType() als Int

Beschreibung: Sendet eine Ganzzahl zurück, die den Formular-Boxtyp angibt. VDLStruktur = 1 VDLReaktion BeilsteinStruktur BeilsteinReaktion Text Ganzzahl Float Bild
Sendet zurück: Eine Ganzzahl, die die verschiedenen Typen der Formularboxen definiert

TypFestlegen(Typ als Int) ungültig

Beschreibung: Legt den Typ der Formularbox fest.
Parameter: Typ als Int
Beschreibung: Eine Ganzzahl, die den Typ einer Formularbox definiert. VDLStruktur = 1 VDLReaktion BeilsteinStruktur BeilsteinReaktion Text Ganzzahl Float Bild

GetliModus() als Int

Beschreibung: Erhält den Display-/Abfragemodus der Formularbox.
Sendet zurück: Eine Ganzzahl, die den Modus der Formularbox definiert. Display = 1 {Standard} Querylet = 2

ModusFestlegen(Modus als int) ungültig

Syntax: ModusFestlegen(Modus als int) ungültig
Beschreibung: Legt den Modus der Formularbox fest.
Parameter: Modus als int
Beschreibung: Eine Ganzzahl, die den Modus der Formularbox definiert. Display = 1 {Standard} Querylet = 2

GetDatenbankfeld() Feldobjekt

Beschreibung: Erhält das Datenbankfeld, dessen Wert durch die Formularbox angezeigt oder abgefragt wird.
Sendet zurück: Das Datenbankfeld ist mit der Formularbox verbunden.

DatenbankfeldFestlegen(Feld als String) ungültig

Beschreibung: Legt das Datenbankfeld fest, dessen Wert durch die Formularbox angezeigt oder abgefragt wird.
Parameter: Feld als String
Beschreibung: Das Datenbankfeld ist mit der Formularbox verbunden

SuchoptionenAnzeigen(Opt1 als Boolean, [Opt2 als Boolean], [Opt3 als Boolean]) ungültig

Beschreibung: Erlaubt dem Entwickler, die verschiedenen Suchoptionen im Querylet-Modus auszublenden oder zu exponieren.
Parameter: Opt1 als Boolean
Beschreibung: Wahr {Standard} zur Anzeige der Option, Falsch zum Ausblenden.

Ergebnis_Imp-Klasse

Beschreibung: Eine Steuerung, die ein Container zum Aufbewahren eines Datensatzes ist. Kann im Designmodus sichtbar, aber für den Benutzer unsichtbar werden.

Verfahren
getDatensatz(ID als String) als Datensatz

Beschreibung: Erhält den Datensatz.
Parameter: ID als String
Beschreibung:
Sendet zurück: ein Datensatz-Objekt.

Tabellen_Imp-Klasse

Beschreibung: Gleiche Datentypinformationen pro Spalte. Benutzer wählt eine Datenquelle aus und zieht sie zur Tabelle und legt sie ab, dann erstellt das System neue Spalten. Der Benutzer klickt auf den Titel einer Tabellenspalte und das Programm sortiert die Anordnung der Daten. Der Benutzer zieht die Eigenschaften vom Eigenschaftenfeld zur Tabelle und legt sie dort ab und das Programm fügt die Eigenschaft als eine neue Spalte in der Tabelle ein. Der Benutzer wählt eine Spalte aus und zieht sie zum Papierkorb und die Programmspalte wird aus der Tabelle entfernt. Der Benutzer zieht ein Bild zur Tabelle und die Tabelle findet heraus, wie das Bild anzuzeigen ist.

Verfahren
VDLInterne.BasisSteuerungen.Suchhistorie
Beschreibung:
Die Suchhistorie ist aus Knoten zusammengesetzt.
Knoten (in der Benutzersteuerung als kreisförmige Punkte dargestellt) stellen entweder Suchergebnis + Formular oder eine Liste logischer Operatoren dar Transitionen (in der Benutzersteuerung als Linien zwischen den Knoten dargestellt) stellen das UQL (SQL) + das zugehörige Formular dar
Der Entwickler kann dieses API verwenden zum:

– Hinzufügen eines Knotens/Transition
– Entfernen eines Knotens/Transition
– Bearbeiten/Aktualisieren des Inhalts des Knotens oder der Transition

Beschreibung: Abfragen/Durchsuchen Benutzer – jedes Abfrageergebnis wird als neuer Knoten in Diagrammen gespeichert. In Historie zurückgehen – Benutzer wählt gespeicherte Ergebnisse aus. Speichern RS oder Unterdiagramm. Besuche Logik – Importieren der SD-Datei als PS. Kombinieren – Operationstypen zwischen DS. Benutzer wählt gespeicherte Abfrage aus (Diagrammecke).

Verfahren
SpeichernNeueAbfrage()

Beschreibung: /RS
Parameter:
Beschreibung:
Sendet zurück:

NeueAbfrageAuswählen()

Beschreibung: /RS
Parameter:
Beschreibung:
Sendet zurück:

ISeachHistoryListener Rückruf-Schnittstelle

Beschreibung: Abfragen/Durchsuchen Benutzer – jedes Abfrageergebnis wird als neuer Knoten in Diagrammen gespeichert. In Historie zurückgehen – Benutzer wählt gespeicherte Ergebnisse aus. RS oder Unterdiagramm speichern. Logik besuchen. SD-Datei als PS importieren. Kombinieren – Operationstypen zwischen DS. Benutzer wählt gespeicherte Abfrage aus (Diagrammecke).

Verfahren
AusgewählterKnoten (SuchhistorieKnoten ausgewählterKnoten,

SuchhistorieKnoten[] Parents) ungültig
Beschreibung: /RS
Parameter:
Beschreibung:
Sendet zurück:

AusgewählteTransition (SuchhistorieTransition ausgewählteTr, SuchhistorieKnoten[] Parents) ungültig

Beschreibung: /RS
Parameter:
Beschreibung:
Sendet zurück:

SuchhistorieKnoten-Klasse

Beschreibung: Stellt den tatsächlichen Knoten dar (UQL + sein Formular) Das API

Verfahren
DropTransition(SuchhistorieKnoten Parent, SuchhistorieTransition ausgewählteTr)ungültig

Beschreibung: /RS
Parameter:
Beschreibung:
Sendet zurück:

KnotenAblegen (SuchhistorieKnoten Knoten1, SuchhistorieKnoten Knoten2) ungültig

Beschreibung: /RS
Parameter:
Beschreibung:
Sendet zurück:

SuchhistorieWurzelKnoten-Klasse

Beschreibung: Stellt eine Datenbank dar

Verfahren
SuchhistorieTransition-Klasse

Beschreibung: Stellt das tatsächliche SQL + sein Formular dar

Verfahren
SuchhistorieBinäreTransition-Klasse

Beschreibung: Stellt eine binäre Operation dar, die 2 Knoten als Inputs akzeptiert, zum Beispiel eine Liste logischer Operationen, wie AND wird zwei Knoten (Ergebnisset + Formulare) als Inputs und als Output einen einzelnen SuchhistorieKnoten (UQL + Formular) nehmen

Verfahren
VDLIntern.Basis.Framework.

Beschreibung: Nur für den internen Gebrauch.

ClientFramework_Imp-Klasse
Beschreibung:
Die Haupt-Framework-Klasse. Alle Verfahren in dieser Klasse sind statisch. Alle vom Framework hervorgebrachten Anwendungen werden in der Lage sein, eines seiner Verfahren aufzurufen, um eine ICS-Verbindung oder eine ICS-Datenquellverbindung herzustellen
Beschreibung:

• Herstellen der Verbindung zu ICS-Diensten (Datenquelle, Objektaufbewahrung usw.).
• Login; verfolgt die Verbindung nach, sodass der Benutzer sich einmal einloggen und diese Verbindung nutzen kann, selbst wenn verschiedene Anwendungen verwendet werden.
• Wechseln zwischen Anwendungen nach "Hop into" Stil. Starten einer neuen Anwendung und übertragen der jetzigen Daten zu ihr.

Eigensshaften
AktiveAnwendungen als Anwendungsliste (nur holen)

Beschreibung: Ruft eine Anwendungsliste ab, die derzeit auf dem VDL-Basis-Framework läuft.

Verfahren
verbinden([HostName] als String |[Verbindungsprofil] ISCVerbindungsattribute) als ICSVerbindung

Beschreibung: Erstellt eine neue Verbindung zum ICS-Server.
Hinweis: Das Verfahren akzeptiert nur einen oder keinen Parameter. Wenn kein Parameter vorliegt, wird das Framework die bestehende Verbindung verwenden, falls vorhanden, oder den Endbenutzer um Verbindungsinformationen bitten.
Parameter: Hostname (optional)
Beschreibung: Der Hostname, wo der ICS-Server läuft. In diesem Fall wird das Framework versuchen, eine bestehende Verbindung zum gleichen Host zu finden und diese zu verwenden. Wenn keine Verbindung zum gleichen Hostnamen gefunden werden kann, wird der Endbenutzer gebeten, die Verbindungsinformationen einzutragen. ODER
Parameter: Verbindungsprofil (optional)
Beschreibung: Die ICS-Server Verbindungsattribute. Dies kann durch eine Anwendung erstellt werden, wenn die Anwendung alle Informationen für die Verbindung kennt. Wenn für dieses Verbindungsprofil einige Werte ungültig sind, wird der Endbenutzer gebeten, Verbindungsinformationen zur Verfügung zu stellen.
Sendet zurück: Eine ICS-Verbindung stellt die hergestellte Verbindung zum ICS-Server dar. Ausnahmen: Eine Ausnahme wird gewährt, wenn die Verbindung fehlschlägt. Die Anwendung sollte diese Ausnahme einschließen und eine entsprechende Fehlermeldung an den Endbenutzer senden.

getDatenquellliste(Verbindungsprofil als IcsVerbindungsattribute) als String[]

Beschreibung: Ruft die Liste der Datenquelleinträge für eine ICS-Verbindung ab.
Parameter: Verbindungsprofil als IcsVerbindungsattribute
Beschreibung: die ICS-Verbindungsattribute, für die die Datenquellliste abgerufen wird. Das Verbindungsprofil wird verwendet, um die verwandte ICS-Verbindung abzurufen. Wenn für dieses Verbindungsprofil keine Verbindung besteht, wird das Framework eine neue erstellen.
Sendet zurück: Eine Reihe von Strings, Datenquellnamen.

getDatenquelle(Verbindungsprofil als IcsVerbindungsattribute, Verbindungsname als String) als ICSVerbindung

Beschreibung: Herstellen einer neuen Datenquellverbindung für eine ICS-Verbindung und eines Datenquellnamens.
Parameter: Verbindungsprofil als IcsVerbindungsattribute
Beschreibung: die ICS-Verbindungsattribute, für die das Datenquellobjekt gebaut werden wird. Das Verbindungsprofil wird verwendet, um die verwandte ICS-Verbindung abzurufen. Wenn für dieses Verbindungsprofil keine Verbindung besteht, wird das Framework eine neue erstellen.
Parameter: Verbindungsname als String
Beschreibung: Einer der Strings, erhalten durch den getDatenquellliste-Ruf.
Sendet zurück: Ein ICS-Datenquellobjekt

Anwendungsliste_Imp-Klasse

Beschreibung: Liste der Anwendungen, die im VDL Framework laufen

Verfahren
Element()

Beschreibung: Sendet die Anwendung zurück, die genannt ist.
Parameter:
Beschreibung:
Sendet zurück: Anwendungsschnittstelle.

Datenquelle_Imp-Klasse

Beschreibung: Der Benutzer kann eine Liste mit Feldern für die Datenquelle erhalten. Sie können auch eine Suche ausführen, die das Ergebnisset zurücksendet.

Verfahren
GetFeldliste(Datenquelle als Objekt) als String[FieldNames] oder Feldwurzel

Beschreibung: Erhält eine Liste mit Feldern, die in der Datenquelle sind.
Parameter: Datenquelle als Objekt
Beschreibung: Das Datenquellobjekt
Sendet zurück: Eine String-Reihe mit Feldnamen.

AbfrageAusführen(AbfrageString als String oder UQL) als Ergebnisset

FrameworkTeile_Imp-Klasse

Beschreibung: Der Benutzer kann diese Klasse zur Verbindung zum ICS, zum Erhalten einer Liste mit Datenquellen und zum Erhalt einer Datenquelle verwenden.

Verfahren
GetDatenquellliste(Host als String, Benutzername als String, Passwort als String,) als String[]

Beschreibung: Erhält eine Liste von zugreifbaren Datenquellnamen von einem Host.
Parameter: Host als Strings
Beschreibung: Ein String, der den Datenbank-Hostnamen enthält.
Parameter: Benutzername als String
Beschreibung: Ein String, der den Benutzernamen oder ID erhält.
Parameter: Passwort als String
Beschreibung: Ein String, der das Passwort enthält.
Sendet zurück: Eine String-Reihe mit Datenquellnamen.

GetDatenquelle(Datenquellname als String,) als Datenquelle

Beschreibung: Erhält das Datenquellobjekt, das namentlich angefordert wurde.
Parameter: Datenquellname als String
Beschreibung: Ein String, der den Datenquellnamen enthält.
Sendet zurück: Das Datenquellobjekt

IAnwendung_Imp-Schnittstelle

Beschreibung: Anwendungsschnittstelle, die auf Informationen über die Schnittstelle zugreift und zulässt, dass Daten zwischen den Anwendungen übertragen werden.

Verfahren
getName()

Beschreibung: Sendet die benannte Anwendung zurück.
Sendet zurück: Name der Anwendung.

Aktivieren()

Beschreibung: Aktiviert oder konzentriert die Anwendung.

getInfo()

Beschreibung: Sendet die Anwendungsdaten zurück. {mol-Datei, Abfrage-String, Suchhistorie, etc}
Parameter:
Beschreibung:
Sendet zurück: Anwendungsdatenobjekt.

InfoFestlegen()

Beschreibung: Anwendungsdaten festlegen. {mol-Datei, Abfage-String, Suchhistorie, etc}
Parameter: Anwendungsdaten
Beschreibung:

IcsVerbindungsattribute_Imp-Klasse

Beschreibung: Dieses Objekt stellt ein ICS-Verbindungsprofil dar. Es beinhaltet alle benötigten Informationsteile, um eine Verbindung herzustellen.

Eigenschaften
Hostname (erhalten und festlegen)

Syntax: Serverhostname als String
Beschreibung: Abrufen oder Festlegen des Werts des ICS-Servernamens, wo die Verbindung hergestellt werden wird.

IcsPort (erhalten und festlegen)

Syntax: Server-ICS-Portnummer als int
Beschreibung: Abrufen oder Festlegen des Werts des ICS-Server-Ports.

Benutzername (erhalten und festlegen)

Syntax: ICS-Benutzername als String
Beschreibung: Abrufen des Werts des Benutzernamens, der zur Herstellung der Verbindung verwendet wurde.

DsServiceName (erhalten und festlegen)

Syntax: Datenquell-Servicename als String
Beschreibung: Abrufen des Werts des Datenquell-Servicenamens, der auf dem ICS-Server läuft.

IcsVerbindungs-Klasse

Beschreibung: Dieses Objekt stellt eine ICS-Verbindung für eine spezifische Anwendung dar. Verfahren in dieser Klasse stimmen mit den gleichen Verfahrensnamen in der ClientFramework-Klasse überein. Beispiele dieser Klassen werden im ClientFramework durch die IcsVerbindungsattribute abgebildet.

Eigenschaften
IcsVerbindungsprofil als IcsVerbindungattribute (nur holen)

Beschreibung: Abrufen der Werte der Parameter, die für die Herstellung dieser Verbindung verwendet werden.

Anwendungsname als String (nur zum Holen)

Beschreibung: Abrufen des Anwendungsnamens, für die diese ICS-Verbindung hergestellt wird.

Verfahren
getDatenquellliste() als String[]

Beschreibung: Ruft die Liste der Datenquelleinträge für diese ICS-Verbindung ab.
Parameter: keiner
Sendet zurück: Eine Reihe von Strings, Datenquellnamen.

Beschreibung: Herstellen einer neuen Datenquellverbindung für diese ICS-Verbindung und eines Datenquellnamens.
Parameter: keiner
Sendet zurück: Ein ICS-Datenquellobjekt

getServiceBeispiel(Servicename als String) als Objekt

Beschreibung: Herstellen einer neuen Serviceverbindung für diese ICS-Verbindung und einen Servicenamen.
Parameter: Servicename als String
Beschreibung: der Name des Services, der beim ICS-Server registriert ist.
Sendet zurück: Ein Objekt, dass eine Service-Session darstellt. Dies sollte für die entsprechenden Klasse vorgesehen sein, die mit der Servicedurchführung übereinstimmt.

ImportExport_Imp-Klasse

Beschreibung: Der Benutzer möchte eine SD-Datei, RD-Datei, CSV, mol-Datei und XD-Datei imporieren. Sie verwenden eine IOKomponente zum Laden der Datei. Der Benutzer möchte eine SD-Datei, RD-Datei, CSV, mol-Datei und XD-Datei exportieren. Sie verwenden die IOKomponente zum Speichern der Datei. Der Endbenutzer möchte eine große Datei vom Client zum Server importieren. Sie verwenden IOUpload zum Erstellen einer temporären Tabelle mit Daten.

Eigenschaften
Datensatz Eigenschaft

Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

Verfahren
DateiLaden(Format, Lokal/Remote) ungültig

Beschreibung:
Parameter:
Beschreibung:

DateiSpeichern(Format, Lokal/Remote, Datensatz ) ungültig

Beschreibung:
Parameter: Format
Beschreibung: CSV, Liste, SD-Datei, RD-Datei, XD-Datei
Parameter: LokalRemote
Beschreibung: Client oder Server
Parameter: Datensatz
Beschreibung: Ein zusätzliches Argument kann hinzugefügt werden. "config" in Bezug auf Feld- Mapping oder Memory versus Datenbank.
Sendet zurück: Boolean, wahr wenn erfolgreich.

Navigationsmaschine_Imp-Klasse

Beschreibung: Der Benutzer trägt eine URL ein und der Navigator lädt die Seite, überprüft die Sicherheit und zeigt die Seite an. Der Benutzer klickt auf Home und Basis kehrt zur Homepage zurück. Der Benutzer klickt auf Weiter und Basis gelangt zum nächsten Status der Anwendung. Der Benutzer klickt auf Zurück und Basis gelangt zum vorherigen Status der Anwendung. Der Benutzer klickt auf Favoriten und Basis zeigt die Seite an.

Verfahren
setHome(URL als String) ungültig

Beschreibung:
Parameter:
Beschreibung:

geheZuHome() ungültig

Beschreibung:
Parameter:
Beschreibung:

geheZuZurück() ungültig

Beschreibung:
Parameter:
Beschreibung:

geheZuVorherig() ungültig

Beschreibung:
Parameter:
Beschreibung:

geheZuNächstes() ungültig

Beschreibung:
Parameter:
Beschreibung:

geheZuFavoriten() ungültig

Beschreibung:
Parameter:
Beschreibung:

entfernenFavoriten(Name als String) ungültig

Beschreibung:
Parameter:
Beschreibung:

FavoritenHinzufügen(Name als String, iURL als URL) ungültig

Beschreibung:
Parameter:
Beschreibung:

TeileFabrik_Imp-Klasse

Beschreibung: Vorgegebene XML stellt bestehende Formulare, Arbeitsflüsse usw. dar. Dies erstellt die Laufzeit-Objekte, die notwendig sind, um sie wiederzugeben und zu manipulieren. Vorgegebenes Formular, Arbeitsfluss usw. bestehen auf XML. Konfigurierbar, sodass neue Komponententypen durch VDL oder Kunden hinzugefügt werden können.

Verfahren
TeilMachen(XMLKomponentenKonfig als String) als Objekt

Beschreibung: Erstellt ein beliebiges Teil, das für die VDL-Basis verwendet wird
Parameter: XMLKomponentenKonfig
Beschreibung: Ein String, der die XML-Konfiguration für ein neues Teil beinhaltet
Sendet zurück:

AnhängTeil(ParentTeil als Objekt, ChildTeil als Objekt) ungültig

Beschreibung: Hängt ein Teil zu einem bestehenden Teil mit einer Child/Parent-Beziehung an.
Parameter: ParentTeil als Objekt
Beschreibung: Der Parent-Teil, den Sie verknüpfen wollen.
Parameter: ChildPart als Objekt
Beschreibung: Der Child-Teil, den Sie verknüpfen wollen.

Druck_Imp-Klasse

Beschreibung: Verwendet Standard-Betriebssystem-Schnittstelle, die Standarddruckoptionen verwendet, einschließlich Druckvorschau, Seitengröße, Ränder, Portrait-/Quer-Modus. 'Druck' kann auf 'Alle Einträge' oder einem ausgewählten Unterset angewendet werden.

Verfahren
Druck() Verfahren

Syntax: Druck()
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

ObjektDrucken() Verfahren

Syntax: Drucken(myObjekt als Objekt)
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

EigenschaftenDrucken() Verfahren

Syntax: Drucken(myEigenschaften als Eigenschaften, myObjekt als Objekt)
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

BenutzerPräf_Imp-Klasse

Beschreibung: Fast ein Eintrag pro Präf oder Präf-Objekt mit vielen Eigenschaften (eine pro Präf). (global wird seine Einstellungen auf jedes Programm anwenden, das im Basis-Framework läuft.)
Beschreibung: Entwickler wird in der Lage sein, alle VDL-Basis-Präferenzen mit den Klassen in diesem Paket festzulegen.
- • Hauptklasse ist BenutzerPräf und wird den Zugriff auf alle Unter-Präferenzklassen ermöglichen.
- • Mol/Reak Rendering Präf (Global) {Bond-Länge, Atom zeigen, etc}
- • AddIns Liste der zu ladenden Addins. Installieren, Aktualisieren, Entfernen von Addins. (nicht sicher, ob das global benötigt wird)
- • Druck-Präf (Basis) {Seitengröße, Ränder, etc}
- • Skin Präf (Gobal) {Fensterfarbe, Schriftarten, Hintergrundmuster}
- • Abfrage Präf (Global) {Reaktion Automap, automatisches Erzeugen von Listen, Filtern von Datensätzen, etc.}
- • Verbindungs-Präf (global) {ICS Host, ICS Port #, Benutzername, Datenquell-Servicename, etc}
- • Registrations-Präf (Basis) {Auto Reg-Generation, Regeln überprüfen, etc.}

Eigenschaften
MolRemLayoutPräf() Eigenschaft

Syntax: MolRemLayoutPräf()
Beschreibung:
Parameter: BondLänge
Beschreibung:
Parameter: Ketteneinstellung
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

DruckPräf() Eigenschaft

Syntax: FestlegenMolRemLayoutPräf() als Boolean
Beschreibung:
Parameter: als Formular
Beschreibung:
Parameter: BerichtMgr
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

FormularPräf() Eigenschaft

Syntax: FestlegenFormularPräf() als Boolean
Beschreibung:
Parameter: COS Vorlage
Beschreibung:
Parameter: FestlegenOrt
Beschreibung:
Parameter: StandardFormular
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

SkinPräf() Eigenschaft

Syntax: FestlegenSkinPräf(SkinTyp) als Boolean
Beschreibung:
Parameter: SkinTyp
Beschreibung: mögliche Werte: AFGzurVerwendung, Wurzelebene, AutoMap,
AutoVorlagenListenErzeugung
Parameter: HintergrundBild
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

AbfragePräf() Eigenschaft

Syntax: FestlegenAbfrage(Abfragetyp) als Boolean
Beschreibung:
Parameter: Abfragetyp
Beschreibung: mögliche Werte: AFGzurVerwendung, Wurzelebene, AutoMap,
AutoVorlagenListenErzeugung
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

AddInPräf() Eigenschaft

Syntax: FestlegenAddInPräf() als Boolean
Beschreibung:
Parameter: InstallierteListe
Beschreibung:
Parameter: HinzufügenEntfernen
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück: Boolean, wahr wenn erfolgreich.

RenderingDispIayMolReaktRendPräf_Imp-Klasse

Beschreibung: Mol/Reak Rendering Präf (Global) {Bond-Länge, Atom zeigen, etc}

AddInPräf-Klasse

Beschreibung: AddIns Liste der zu ladenden Addins. Installieren, Aktualisieren, Entfernen von Addins. (nicht sicher, ob das global benötigt wird)

DruckPräf-Klasse

Beschreibung: (VDL-Basis) {Seitengröße, Ränder, etc}

SkinPräf-Klasse

Beschreibung: (Gobal) {Fensterfarben, Schriftarten, Hintergrundmuster

AbfragePräf-Klasse

Beschreibung: (Global) {Reaktion Automap, automatisches Erzeugen von Listen, Filtern von Datensätzen, etc.}

VerbindungsPräf-Klasse

Beschreibung: (global) {ICS Host, ICS Port #, Benutzername, Datenquell-Servicename, etc}

RegistrationPräf-Klasse

Beschreibung: (VDL-Basis) {Auto Reg-Generation, Regeln überprüfen, etc.}

VDLIntern.Basis.Framework.Verbindung

Beschreibung: Nur für den internen Gebrauch.

UnsichtbarVerbundeneKomponente_Imp-Basisklasse

Beschreibung: Wie eine verbundeneKomponente, wird aber verwendet, wenn die Funktion im Formular benötigt wird, aber der Endbenutzer sollte sie nicht in der Steuerung sehen {z.B. Datenzugang}

VerbundeneKomponente_Imp-Basisklasse

Beschreibung: Eine Steuerung kann ein Teil übernehmen und Aktivieren() von dieser Klassen und sie verwenden, um eine integnerte Steuerung zu werden, die zu anderen Steuerungen im Formular verbunden ist.

Eigenschaften
Teil() Eigenschaft

Syntax: Teil als Objekt
Beschreibung:

Verfahren
Aktivieren() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

Teil_Imp-Abstraktklasse

Teile übernehmen von der GeneralizedNode Class [NYI], sodass sie eine Eingrenzungshierarchie für Anordnungs- und Navigationszwecke unterhalten können.

Eigenschaften
ReiheListePins[] Eigenschaften

Syntax:
Beschreibung:

Verfahren
PinHinzufügen() Verfahren

Syntax: ungültig PinHinzufügen(Pin)
Beschreibung: Fügt einen Pin zur ReiheListePins des Teils hinzu[]
Parameter: Ein Pin-Objekt
Beschreibung:
Rückkehr: ungültig.

GetPinBenannt() Verfahren

Syntax: Pin GetPinBenannt(Name als String)
Beschreibung: Holt einen Pin von der ReiheListePins des Teils[]
Parameter: String, der den Namen des Pins enthält
Beschreibung:
Rückkehr: ungültig.

Ungültig Aktivierungs-() Verfahren

Syntax: ungültig Aktivieren()
Beschreibung: Aktivieren Sie das Teil. Das Standardverfahren fordert einfach zur Aktivierung aller Output-Pins auf.
Rückkehr: ungültig.

PropertyPin ExposeInputProperty(String, Ziel)
PropertyPin ExposeInputProperty(String)
PropertyPin ExposeOutputProperty(String, Ziel)
PropertyPin ExposeOutputProperty(String)

Beschreibung: Erstellt einen Pin, der die benannte Eigenschaft eines Standardobjektes darstellt und fügt ihn zum Zielobjekt hinzu.
Sendet zurück: EigenschaftPin

OutputEventPin ExposeEvent(String)

Beschreibung: Exponieren des benannten Ereignisses als einen Output-Ereignis-Pin

InputEventPin ExposeMethod(String)
Beschreibung: Exponieren des Null-Argument-Verfahrens, durch einen Input-Ereignis-Pin als String benannt
ReiheListe Exponierungsverfahren(VerfahrenSpez) [NYI]

Beschreibung: Exponieren des Verfahrens als einen Input-Ereignis-Pin und seine Argumente als Input-Daten-Pins.
Wie erkennbar ist, können die Pins umbenannt werden, wenn ein Konflikt besteht.

öffentlich statisch ungültig EigenschaftVerbindung(Objekt o1, String p1, Objekt o2, String p2)

Beschreibung: Bequemes Verfahren zur Verbindung zweier beliebiger Objekte über die Eigenschaften. P1 und P2 sind Eigenschaftennamen. O1 und o2 sind Objekte, die mit den entsprechenden Teilen gekapselt werden.

öffentlich statisch ungültig EreignisVerbindung(Objekt o1, String-Ereignisl, Objekt o2, String-Verfahren2)

Beschreibung: Bequemes Verfahren zur Verbindung zweier beliebiger Objekte über die Eigenschaften und Verfahren. O1 und o2 sind Objekte, die mit den entsprechenden Teilen gekapselt werden. Ereignisl ist ein Ereignisname (für o1) und Verfahren2 ist ein Verfahrensname (für o2).

Pin-Klasse

Beschreibung: Pins sind exponierte Schnittstellen von Teilen, die die Verbindung zu anderen Teilen zulassen

Eigenschaften
Name Eigenschaft

Syntax:
Beschreibung: Name des Pin.

PinEigenschaft Eigenschaft

Syntax:
Beschreibung: Name des Pin.

Verbindung_imp-Klasse

Syntax: Öffentliche Verbindung(OutputPin output, InputPin input)
Beschreibung: Verbindungen sind Verbindungen zwischen zwei Pins. Es gibt nur eine Klasse,
Verbindung

VerbindungLöschen() [NYI] Verfahren

Syntax: ungültig VerbindungLöschen(Pin)
Beschreibung: Entfernt die Verbindung vom Formular.
Rückkehr: ungültig.

Verbindungssystem_Imp-Klasse

Beschreibung: Aufbau eines Formulars – bietet die Fähigkeit, Komponenten miteinander zu verbinden. Ausbau eines DAF-Formulars – erlaubt, dass Daten-Kenntnis-Komponenten automatisch verbunden werden. Aufbau einer Komponente – erlaubt das Speichern verbundener Komponentenstrukturen und deren Verwendung als Einheiten (Zusammensetzungen). Verwenden eines Formulars – Endbenutzer eines Formulars verwenden das Verbindungssystem, ohne sich dessen bewusst zu sein. Arbeitsfluss aufbauen – benutzt Verbindungen zum Verbinden von Formularen in einem Arbeitsfluss.
Beschreibung: Verbindung erlaubt einer Steuerung, andere Steuerungen auf einem Formular zu alarmieren, wenn eine seiner Eigenschaftenwerte verändert wurden. Andere Steuerungen können auf diese Änderungen reagieren und Alarme selbst versenden.
- • Der Entwickler kann ein Formular erstellen, dass über eine Textboxsteuerung verfügt, die ihr Display ständig aktualisiert, um den geänderten Wert einer komplett separaten Slider-Steuerung zu reflektieren.

Eigenschaften
ExponierenInput Eigenschaft

Syntax: ExponierenInput als Boolean
Beschreibung:

ExponierenOutput Eigenschaft

Syntax: ExponierenOutput als Boolean
Beschreibung:

ExponierenEreignis() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

ExponierenVerfahren() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

Verbinden() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

ZusammensetzungDefinieren() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

Aktivieren() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

NeuerWert() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

GatePort() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

FlaschenPort() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

ScriptPort() Verfahren

Syntax:
Beschreibung:
Parameter:
Beschreibung:
Sendet zurück:

VDLIntern.Basis.Dienstprogramme.

Beschreibung: Nur für den internen Gebrauch.

CheshireSchnittstelle-Klasse

Beschreibung: Cheshire-Regeln auf Moleküle oder Reaktionen und Rückergebnisse anwenden (jeweils ein mol/rxn pro Schritt oder als Charge)

Verfahren
ScriptAnwenden(CheshireScript als String, MolRxnDatei als String) als String

Beschreibung: Anwenden der Cheshire-Regeln auf Moleküle oder Reaktionen und Rückergebnisse
Parameter: CheshireScript als String
Beschreibung: Ein String, der den Cheshire Script enthält.
Parameter: MolRxnDatei als String
Beschreibung: Optionaler String, der den Namen der Vorlage enthält.
Sendet zurück: Einen String, der das resultierende Mol oder die Reaktionsdatei enthält.

PipelinePilotSchnittstelle-Klasse

Beschreibung: Weiterleiten des Informationssets (Ergebnisset) an Pipeline Pilot und zurück durch XML, Sdfile, Rdfile oder durch eine Datenquelle.

Verfahren
Exportieren(XML als String) ungültig

Beschreibung: Weiterleiten des Informationssets (Ergebnisset) an Pipeline Pilot
Parameter: XML als String
Beschreibung:

Importieren() als String

Beschreibung: Weiterleiten des Informationssets zurück von PP durch XML, Sdfile, Rdfile oder durch eine Datenquelle.
Sendet zurück: Einen String, der die XML enthält.

Arbeitsfluss-Klasse

Beschreibung: Der Benutzer klickt auf einen Arbeitsfluss-Knoten (Formular) in der Arbeitsfluss-Ansicht und der Navigator zeigt die folgende Seite an. Der Entwickler doppelklickt auf einen Knoten (Formular) und Basis geht in den Design-Modus und zeigt das Formular zum Bearbeiten an. Entwickler erstellt einen neuen Arbeitsfluss, zusammengesetzt aus neuen Modi und bestehenden Arbeitsflüssen.

ChartingEditor-Klasse

Beschreibung: Diagramm mit Assistenten aufbauen. Achsenfeld festlegen. Feldkategorie festlegen. Feldmarkierer festlegen (für Serie). Diagrammtyp festlegen. Kurvenanpassung. Farbe, Füllung und Linienmuster festlegen. Kennzeichnungen und Anmerkungen festlegen. Diagramm kopieren. Flagge auf Anzeigen der Fehlermarge setzen. Binden und Clustern einiger Werte. Aktive ToolTip Informationen (expl: struct field und regno)

Registration-Klasse

Beschreibung: Registriert Daten auf 3 Arten: Hinzufügen einzelner Daten, Hinzufügen mehrerer Daten, Aktualisieren einzelner Daten/Löschen.

BerichtModul-Klasse

Beschreibung: Erstellt und Druckt Berichte als PDF, RTF, Word, Html, Excel und PowerPoint-Dateien.

ANHANG B
1. ÜBERSICHT
Die funktionelle Spezifikation einer Komponente beschreibt detailliert das externe Design einer Komponente. In einem bevorzugten Ausführungsbeispiel folgt die funktionelle Spezifikation einer Komponente dem Endarchitekturplan.
Dieses Dokument beinhaltet die folgenden Abschnitte

• Verwendung der Komponente – eine Beschreibung der Verwendungsfälle und Diagramme, die zeigen, wie die Aktoren mit der Komponente interagieren.
• Experimente – beschreibt die Experimente, die verwendet werden, um risikoreiche Gebiete auf Komponentenebene zu untersuchen
• GUI – zeigt, wie Menschen mit der Komponente interagieren werden
• APIs – beschreibt die Dienste, die durch die Komponente bereitgestellt werden
• Dateiformate – eine Beschreibung von allen Dateiformaten durch die Komponente
• Datenbankschema – ERD (Diagramm über die Dateneinheitsbeziehungen) für alle Datenbanken, die von der Komponente verwendet werden
• Fehlerbehandlung – eine Beschreibung von beliebigen Fehlern, die von der Komponente verwendet werden
• Leistungsmodelle

2. VERWENDUNG DER KOMPONENTE

<Beschreiben von Verwendungsfällen mit einer Sammlung von UML-Diagrammen, die Aktoren zeigen (Menschen und Dinge), die mit der Komponente interagieren. Illustrieren jedes Anwendungsfalles mit UML-Diagrammen wie: Aktivität; Arbeitsfluss, Objekte (und deren Beziehungen), Zusammenarbeit, Status. Diese Diagramme sollten direkt auf die Endanforderungen und zur System-UI abgebildet werden.>

Die Client-Objektaufbewahrung wird hauptsächlich durch den Endbenutzer verwendet. Der Endbenutzer sollte die Ordner und Dokumente managen, die auf dem lokalen Computer und auf einem Remote-Server aufbewahrt werden. Die Client-Objektaufbewahrung sollte auch zu Teilen verbunden sein. Teile sollten auslösen, wenn ein Dokument gespeichert oder gelesen werden kann und sollten den Dokumentinhalt anbieten und interpretieren. Außerdem sollte das Durchsuchen des Aufbewahrungssystems oder das Suchen der darin befindlichen Dokumente durch Taste oder Menüteil ausgelöst werden.
2.1. Endbenutzer-Interaktion.
Endbenutzer-Interaktion beinhaltet ein Unterset des Systemdateimanagements.
2.1.1. Dokumente und Ordner zeigen.
Dies ist die Fähigkeit, dem Endbenutzer die Namen und Symbole der Dokument- und Ordnernamen als Strukturansicht anzuzeigen. Aus dieser Strukturansicht kann der Endbenutzer ein Element (Dokument oder Ordner) auswählen, um einen der unten genannten Verwendungsfälle auszuführen.
2.1.2. Dokumenteigenschaften ansehen.
Für ein spezifisches (ausgewähltes) Dokument kann der Endbenutzer die Liste der ihm zugewiesenen Attribute abrufen. Die Attributliste gleicht die Attributliste ab, die von einem Objektaufbewahrdienst verfügbar ist.
2.1.3. Erstellen, Löschen, Verschieben, Kopieren und Umbenennen.
Innerhalb der Sicherheitsbeschränkungen, die entweder durch das systemeigene Dateisystem oder den Objektaufbewahrungsdienst eingestellt wurden, sollte der Endbenutzer in der Lage sein, neue Dokumente und Ordner zu erstellen. Er/sie sollte auch in der Lage sein, Dokumente und Ordner zu löschen, zu kopieren oder zu verschieben. Für diese Ausgabe wird nur die Dokumentumbenennung möglich sein, da der Objektaufbewahrungsdienst verhindert, dass ein Ordner umbenannt wird.
2.1.4. Suchen und Einsehen von Suchergebnissen.
Mit dem Objektaufbewahrungsdienst können API Benutzer nach Dokumenten entsprechend deren Attributwerte suchen. Die Client-Objektaufbewahrung wird den gleichen Mechanismus unterstützen und wird diese Funktionalität auf das systemeigene Dateisystem für Dokumentattribute transponieren, bei denen eine Gleichheit in den Dateieigenschaften vorliegt.
Wenn eine Suche abgeschlossen wird, hat der Endbenutzer Zugriff auf eine Liste mit Dokumenten, die mit den Suchkriterien übereinstimmen. Der Endbenutzer wird auch in der Lage sein, durch die Suchergebnisliste zu navigieren (vorheriges/nächstes).
2.1.5. Navigieren im Ordner Hierarchie.
Der Endbenutzer wird in der Lage sein, das systemeigene Dateisystem des lokalen Computers oder einen Kontext auf dem Objektaufbewahrungsdienst (privat oder öffentlich) auszuwählen. Dies wird der Startpunkt zum Navigieren in den Unterverzeichnissen sein. Für jeden Ordner wird die Client-Objektaufbewahrung alle Ordner und Dokumente innerhalb des derzeitigen Ordners sowie den übergeordneten Ordner auflisten. Durch die Auswahl eines Ordners wird der Endbenutzer die Ordneransicht ändern.
2.1.6. Dokumentnamen angeben.
Um Operationen zu speichern und zu lesen (siehe Teile-Interaktion unten), sollte der Endbenutzer einen Dateinamen angeben. Die Client-Objektaufbewahrung wird den Benutzer zum gewünschten Ordner navigieren, einen Dateinamen eingeben oder eine bestehende Datei auswählen lassen. Dieser Dateiname wird durch das Teil erreichbar, das mit der Client-Objektaufbewahrung verbunden ist.
2.2. Teile-Interaktion.
Die Client-Objektaufbewahrung kann in das VDL-Basis Verbindungssystem beinhaltet werden. Tasten-Teil, Menü-Teil oder andere Teile (zum Beispiel ein Teil, das mit Suchergebnissen umgeht) könnten eine Verbindung herstellen, um Objekte zu belassen oder abzurufen, die auf dem lokalen Dateisystem oder einem Remote Server aufbewahrt werden.
2.2.1. Suche.
Vor dem Abrufen eines Dokuments könnte ein Teil eine Suche ausführen. Das Suchergebnis wird eine Liste mit Strings sein, die den Dateipfad vom Verzeichnis darstellt, von dem die Suche ausging. Ein Element dieser Liste könnte in der Operation Speichern oder Lesen verwendet werden. Das Suchergebnis wird als ein Output-Pin verfügbar sein. Das Suchkriterium wird in einem Input-Pin spezifiziert.
2.2.2. Speichern und Lesen.
Wenn ein String ein Objekt darstellt, könnte ein Teil bitten, dass dieser String in einem Dokument gespeichert wird. Wenn ein Dokument besteht und lesbar ist, könnte ein Teil auf seinen Inhalt zugreifen und ihn verwenden, um ein Objekt seriell-parallel umzuwandeln. Die Client-Objektaufbewahrung wird Teilen erlauben anzugeben, ob der Endbenutzer den Dokumentennamen zum Lesen oder speichern spezifizieren kann. Wenn der Endbenutzer den Dokumentnamen angeben kann, wird ein Dialog erscheinen und den Endbenutzer bitten, ein Dokument auszuwählen. Die Client-Objektaufbewahrung wird sich nur mit Textdateien kümmern. Um den binären Inhalt zu speichern, kann die Link-Methode der IOrdner-Klasse verwendet werden.
3. EXPERIMENTE

<Geben Sie Experimente an und führen Sie sie aus, um risikoreiche Gebiete auf Komponentenebene zu untersuchen und wenn Sie sich zwischen alternativen Durchführungsmethoden entscheiden müssen. Entwerfen Sie Experimente, um eine oder zwei präzise Fragen zu beantworten. Produzieren Sie einfache Prototypen, um Ihre Experimente durchzuführen. Entwerfen Sie diese Prototypen nicht für den späteren Gebrauch, wenn Sie verschlüsseln. Beginnen Sie, indem Sie Ihre Experimente angeben, führen Sie die dann im Verlauf der Designiterationen aus. Die Enditeration muss die Ergebnisse aller Ihrer Experimente beinhalten>

3.1. Experiment 1, System.Formular.Dateidialog.
3.1.1. Ziel
Versuchen Sie vorhandene Steuerung zu verwenden, um die kundenspezifische Dateihierarchie wiederzuverwenden.
Verwenden Sie bestehende Eigenschaften, die von den Entwicklern verwendet werden können.
3.1.2. Experiment
Sehen Sie in der Dokumentation nach um zu sehen, ob Benutzer die Dateidialogklasse erweitern können, die vom Microsoft .NET Framework zur Verfügung gestellt wird, um das Standarddateisystem mit einer Ansicht der Objektaufbewahrung zu ersetzen. Ändern Sie die Dateidialogeigenschaften, um das Standarddateisystem mit einer Ansicht der Objektaufbewahrung zu ersetzen.
3.1.3. Ergebnis
Ich konnte das Standarddateisystem nicht mit einer anderen Objekthierarchie austauschen. Der Dialog für das Öffnen einer Datei und der Dialog zum Speichern einer Datei sind endgültige Klassen. Ich habe auch im Dialog Ordner durchsuchen und in einigen früheren Visual Basic-Komponenten nachgesehen (DriverListBox, DirListBox und FileListBox), konnte aber das Standarddateisystem nicht ersetzen.
3.1.4. Schlussfolgerung
Die vorliegenden Systeme und Verfahren stellen ihren eigenen Objektbrowser bereit.
3.2. Experiment 2, System.Formular.Strukturansicht
3.2.1. Ziel
Verwenden Sie diese Steuerung zur Verwendung bei der Client-Objektaufbewahrung.
3.2.2. Experiment
Referenz Strukturansicht-Steuerung. Arbeiten mit einigen Beispielen der MSDN-Bibliothek. Erweitern des Strukturknotens bei Bedarf. Versuchen Sie Drag-and-Drop. Versuchen Sie Tooltip.
3.2.3. Ergebnis
Die MSDN-Bibliothek bietet ein gutes Beispiel einer Windows Explorer-ähnlichen Anwendung, die die Strukturansichtssteuerung verwendet. Das Beispiel verwendet die Strukturansicht und sein Ereignis direkt. Die vorliegenden Systeme und Verfahren übernehmen die Strukturansichtsklasse und setzen einige Ereignisverfahren, wie OnBeforeExpand() außer Kraft. Das OnItemDrag-Verfahren wird verwendet, um die Drag-and-Drop Operation zu initiieren.
Ich bin jedoch zur Zeit nicht in der Lage, den Tooltip auf jedem Knoten der Strukturansicht zum Funktionieren zu bringen. Laut Standard funktioniert der Tooltip pro Steuerung, es wird nur einmal gezeigt, wenn der Mauszeiger in der Steuerung bleibt. Es müssen weitere Experimente erfolgen, um eine Lösung zu finden.
3.2.4. Schlussfolgerung
Außer der Tooltip-Funktionalität können alle benötigten UI-Funktionalitäten durch die Verwendung der Strukturansichtssteuerung durchgeführt werden.
3.3. Experiment 3, Objektaufbewahrung in .NET
3.3.1. Ziel
Testen, wie sich die Objektaufbewahrung in einer .NET-Umgebung verhält.
3.3.2. Experiment
Etablieren einer Verbindung zum Objektaufbewahrungsdienst und nachahmen der Objektaufbewahrungsprobe, die mit der Enterprise-Installation bereitgestellt wird.
3.3.3. Ergebnis
Objektaufbewahrung SOAP-Übersetzung wurde noch nicht durchgeführt und kann nicht direkt in .NET verwendet werden.
4. GUI
Des gibt eine Hauptsteuerung, die die Client-Objektaufbewahrung darstellt. Sein Design wurde durch den Ablaufplan inspiriert. Diese Steuerung erweitert die System.Windows.Formulare.Benutzersteuerungsklasse. Somit kann es im Verbindungssystem mit dem "Trickfenster" XML-Element verwendet werden. Es wird auch direkt im Dateidialog verwendet.
4.1. Client-Objektaufbewahrungssteuerung in einem verbundenen Formular
In diesem Fall ist die Objektaufbewahrungssteuerung Teil eines Formulars. Andere Teile können mit ihr interagieren, wie im Abschnitt Verwendungsfälle beschrieben. Der Endbenutzer kann auch direkt mit ihr interagieren, um Dateimanagementoperationen zu suchen oder auszuführen. Der Endbenutzer kann einen Dokumentnamen bearbeiten, indem er ihn anklickt. Der Endbenutzer kann ein Dokument zu einer anderen Steuerung im Formular ziehen. Die Taste Finden wird einen Suchvorgang, beginnend am derzeitigen Ordner starten (ausgewählter Ordner oder Ordner des ausgewählten Dokuments). Nachdem die Suche abgeschlossen ist, werden die beiden Pfeile das vorherige oder nächste Suchergebnis in der Strukturansicht auswählen. Die Operation Finden wird nach Dateinamen suchen, die dem Muster neben der Taste finden entsprechen.
Abbildung 1
Abbildung 1 stellt die Seite clientObjStore.XML innerhalb der XBrowser Demoanwendung dar.
Ein Inhaltsmenü erlaubt dem Benutzer, Dokumente oder Ordner zu kopieren, zu löschen, zu erstellen oder umzubenennen.
Abbildung 2
4.2. Client-Objektaufbewahrungssteuerung im Dialog
In diesem Fall wird die Steuerung direkt in der .NET Entwicklungsumgebung referenziert, um ein Dialogformular zu bauen. Die Funktionalitäten in der Strukturansicht bleiben die gleichen. Wenn Zeigen der Dialogflaggeneigenschaften auf der Client-Objektaufbewahrungssteuerung auf Wahr eingestellt sind, wird ein Aufruf auf seine Leseverfahren den folgenden Dialog aufrufen. Der Endbenutzer wird dann eine Datei in der Strukturansicht auswählen und auf Öffnen klicken, um die Auswahl zu validieren.
Abbildung 3
Der Dialog in 3 kann eingesehen werden, indem die Taste Lesen auf der Seite clientObjStore.XML geklickt wird, mit überprüftem "Show C.O.S. Dialog?".
5. APIs
Client-Objektaufbewahrungs-API ist an die Objektaufbewahrung API gebunden: es verwendet IOrdner- und IDokument-Schnittstellen. Außerdem exponiert es eine Benutzersteuerung als Benutzerschnittstelle und einen Öffnen/Speichern-Dialog.
5.1. Ordner- und Dokumentenstruktur
Dies ist eine Benutzersteuerung. Alle Operationen kommen als ungültig zurück und nehmen keine Argumente an. Der Rückkehrwert und die Argumente sind durch die Steuerungseigenschaften zugreifbar.
5.1.1. Speicherungsverfahren.
Diese Operation nimmt den Wert des Dokumentinhalts und speichert ihn in einem Dokument. Wenn ShowDialog falsch ist, wird DocumentName direkt den Ort des zu speichernden Dokuments angeben. Sonst wird der Wert DocumentName als vorgeschlagener Wert verwendet, wenn der Öffnen/Speichern Dialog erscheint. Wenn der Dialog entsorgt wurde, halten die Eigenschaften von DocumentName den vom Endbenutzer eingegebenen Wert.
5.1.2. Leseverfahren.
Dies ist die Umkehr des Speicherverfahrens. DocumentName wird als Input-Argument verwendet und DocumentContent hält das Ergebnis dieses Vorgangs.
5.1.3. Suchverfahren.
Dies folgt dem Suchkonzept beim Objektaufbewahrdienst. SearchAttribute und SearchValue werden als Input verwendet, um ein Suchkriterium zu erstellen. LastSearchResults hält die Liste der Dateien, die mit diesem Kriterium übereinstimmen, vom Verzeichnis, das dem DocumentName entspricht. Wenn es mehr als ein Suchergebnis gibt, wird der Navigationspfeil (vorherig/nächster) aktiviert.
5.1.4. Kontexteigenschaften
Listen Sie die oberen Knotennamen der Verzeichnisansicht auf. Sie stellen alle Wurzelordner dar, die vom Objektaufbewahrungsdienst und der lokalen Objektaufbewahrung verfügbar sind.
5.1.5. DocumentName Eigenschaft.
Dokumentname mit dem das Dokument gelesen oder gespeichert werden sollte. Dokumentname, durch den Benutzer nach dem Entsorgen des Öffnen/Speichern Dialogs festgelegt wurde. DocumentName wird auch direkt durch den Benutzer festgelegt, wenn er/sie durch die Struktur der Ordner und Dokumente navigiert.
Der Dokumentname stimmt mit dem vollständigen Pfad des derzeitig ausgewählten Elements in der Strukturansicht überein. Zum Beispiel: "MyComputer\C:\\temp".
5.1.6. DocumentContent Eigenschaft.
Dokumentinhalt zum Speichern oder Dokumentinhalt zum Lesen.
5.1.7. ShowDialog Eigenschaft.
Flagge zum Spezifizieren, ob der Endbenutzer mit den Speicher- und Leseoperationen interagieren sollte.
5.1.8. DialogTitle Eigenschaft.
Dialogtitel, der für den Öffnen/Speichern Dialog verwendet werden sollte.
5.1.9. SearchAttribute Eigenschaft.
Attributname, der im Suchvorgang verwendet wird. Dies ist eines der Attributnamen, die vom Objektaufbewahrungsdienst verfügbar sind.
5.1.10. Search Value Eigenschaft.
Attributwert, der im Suchvorgang verwendet wird. Die Art, wie der Attributwert verwendet wird, hängt vom Attribut ab.
5.1.11. LastSearchResults Eigenschaft.
Liste der Dokumentnamen (Verzeichnis und Dokumentname), die mit dem Suchkriterium übereinstimmen.
6. API INFORMATION
Das oben dargestellte API reflektiert das bevorzugte Ausführungsbeispiel. Es können jedoch andere Ausführungsbeispiele, die andere APIs verwenden, eingesetzt werden. Der Paketname wird VDL.Base.Controls sein.
6.1. FolderAndDocTree Klasse

Beschreibung: Dies ist eine UI-Steuerung, die als Teil in das Formular verwendet werden kann. Alle Operationen kommen als ungültig zurück und nehmen keine Argumente an. Der Rückkehrwert und die Argumente sind durch die Steuerungseigenschaften zugreifbar.
Ablegobjekt (Historienliste/Datensatz/Molekülentwurf/...) in die Betriebssystemhierarchie zum speichern. Ziehen Sie das Objekt zum Lesen und zum Verwenden. Browsen Sie das Betriebssystem. Umbenennen/Löschen/Erstellen eines Dokuments. Verschieben/Kopieren eines Dokuments. Suchen des Dokuments nach Eigenschaften (Attribut)-Wert.

Endbenutzer-Interaktion beinhaltet ein Unterset des Systemdateimanagements.

Beschreibung: Erlaubt dem Entwickler, die meisten Aspekte des Dateisystemmanagements auszuführen.

• Anzeigen von Dateien und Ordnern, die auf der lokalen Maschine als auch auf dem Objektaufbewahrer im Server verfügbar sind.
• Lese- und Schreibfähigkeit bei Dateien erlauben.
• Stellt Suchfähigkeiten bereit.

61.1. Kontexteigenschaft (nur zum Holen)

Syntax: Verfügbarer Objektaufbewahrungs-Wurzelnamen als String[]
Beschreibung: Abrufen aller Objektaufbewahrungs-IOrdner-Wurzelnamen, die in der Client-Objektaufbewahrung verfügbar sind. Listen Sie die oberen Knotennamen der Verzeichnisansicht auf. Sie stellen alle Wurzelordner dar, die vom Objektaufbewahrungsdienst und der lokalen Objektaufbewahrung verfügbar sind.

6.1.2. Lese-() Verfahren

Syntax: Lesend als ungültig
Beschreibung: Dies ist die Umkehr des Speicherverfahrens. DocumentName wird als Input-Argument verwendet und DocumentContent hält das Ergebnis dieses Vorgangs.
Parameter: keiner
Rückkehr: ungültig.

6.1.3. Speicheruugs-() Verfahren.

Syntax: Speichern() als ungültig
Beschreibung: Diese Operation nimmt den Wert des Dokumentinhalts und speichert ihn in einem Dokument. Wenn ShowDialog falsch ist, wird DocumentName direkt den Ort des zu speichernden Dokuments angeben. Sonst wird der Wert DocumentName als vorgeschlagener Wert verwendet, wenn der Öffnen/Speichern Dialog erscheint. Wenn der Dialog entsorgt wurde, halten die Eigenschaften von DocumentName den vom Endbenutzer eingegebenen Wert.
Parameter: keiner
Rückkehr: ungültig.

6.1.4. Such-() Verfahren.

Syntax: Suchen() als ungültig
Beschreibung: Dies folgt dem Suchkonzept beim Objektaufbewahrdienst. SearchAttribute und SearchValue werden als Input verwendet, um ein Suchkriterium zu erstellen. LastSearchResults hält die Liste der Dateien, die mit diesem Kriterium übereinstimmen, vom Verzeichnis, das dem DocumentName entspricht. Wenn es mehr als ein Suchergebnis gibt, wird der Navigationspfeil (vorherig/nächster) aktiviert.
Parameter: keiner
Rückkehr: ungültig.

6.1.5. DocumentName() Eigenschaft.

Syntax: () als String
Beschreibung: Dokumentname mit dem das Dokument gelesen oder gespeichert werden sollte. Dokumentname, durch den Benutzer nach dem Entsorgen des Öffnen/Speichern Dialogs festgelegt wurde. DocumentName wird auch direkt durch den Benutzer festgelegt, wenn er/sie durch die Struktur der Ordner und Dokumente navigiert.
Der Dokumentname stimmt mit dem vollständigen Pfad des derzeitig ausgewählten Elements in der Strukturansicht überein. Zum Beispiel: "MyComputer\C:\\temp".

6.1.6. DocumentContent() Eigenschaft.

Syntax: () als String
Beschreibung: Dokumentinhalt zum Speichern oder Dokumentinhalt zum Lesen.

6.1.7. SearchAttribute() Eigenschaft.

Syntax: () als String
Beschreibung: Attributname, der im Suchvorgang verwendet wird. Dies ist eines der Attributnamen, die vom Objektaufbewahrungsdienst verfügbar sind.

6.1.8. Search Value() Eigenschaft.

Syntax: () als String
Beschreibung: Attributwert, der im Suchvorgang verwendet wird. Die Art, wie der Attributwert verwendet wird, hängt vom Attribut ab.

6.1.9. ShowDialog() Eigenschaft.

Syntax: () als Boolean
Beschreibung: Flagge zum Spezifizieren, ob der Endbenutzer mit den Speicher- und Leseoperationen interagieren sollte.

6.1.10. DialogTitle() Eigenschaft.

Syntax: () als String
Beschreibung: Dialogtitel, der für den Öffnen/Speichern Dialog verwendet werden sollte.

6.1.11. LastSearchResults() Eigenschaft.

Syntax: () als String
Beschreibung: Liste der Dokumentnamen (Verzeichnis und Dokumentname), die mit dem Suchkriterium übereinstimmen.

7. DATEIFORMATE
Es gibt für diese Komponente kein spezifisches Dateiformat. Die Objektaufbewahrung kann jedoch nur mit Textdateien, nicht mit binären Dateien umgehen. Mit binären Dateien kann über Links umgegangen werden.
8. DATENBANKSCHEMEN
Wenn Datenbanken auf Systemebene verwendet werden, einen ERD bereitstellen. (Sie können eine URL angeben, die zum ERD verweist.)
9. FEHLER IN DER HANDHABUNG
Wie erkennbar ist, kann jeder Fehlerhandhabungsmechanismus beinhaltet werden.
10. LEISTUNGSMODELLE
Verschiedene Leistungsmodelle und Kriterien werden im Text der Anwendung beschrieben.
Anhang C
Suchhistoriendiagramm
Spezifikation der Benutzerschnittstelle
1. Theorie des Betriebs
Das Suchhistorie-Diagramm nimmt Abfragen und andere produzierende Operationen für Datensätze auf und strukturiert sie, die Ergebnisse dieser Operationen und die Beziehung zwischen ihnen. Es zeigt sie in grafischer Form an und erlaubt dem Benutzer, sie einzusehen und zu verwalten. Es ist gewöhnlich mit einem Anzeige-Teilfenster verbunden, das es zur Anzeige der ausgewählten Datensätze und Abfragen verwendet.
Die visuelle Anzeige der Suchhistorie ein Diagramm, das aus Knoten, verbunden durch Ecken, besteht. Knoten können Suchergebnisse darstellen (Liste von Datensätzen) und Ecken können Operationen darstellen, die neue Listen erzeugen (fragt andere Operationen ab).
Sowohl Knoten als auch Ecken können UI-Objekte sein. Knoten stellen Nutzwerte für Datensatz-Operationen dar, wie das Wiederaufsuchen eines Ergebnissets und das Starten einer neuen Suche. Ecken stellen Nutzwerte für Abfrage-Operationen dar.
2. Layout
Das Suchhistorien-Diagramm kann aus einer Kontrollleiste oben und einem Anzeigegebiet unten bestehen. Es kann ein zugehöriges Anzeige-Teilfenster haben, gewöhnlich zur rechten, das verwendet wird, um ausgewählte Elemente anzuzeigen.
Abbildund 1: Beispiel eines Suchhistorien-Diagramms
2.1. Steuerungsleiste
Die Steuerungsleiste beinhaltet die folgenden Steuerungstasten.
2.1.1. Eintrag (nicht für 1.0)
Dies ist eine Schalttaste. Wenn sie sich im gedrückten Zustand befindet, werden neue Suchen und Ergebnisse zum Versuch hinzugefügt. Wenn sie angehoben ist, dann jedoch nicht.
2.1.2. Stopp (nicht für 1.0)
Stoppt die Eintragung. Wenn Eintragung aus ist, hat das keine Wirkung. Wenn Eintragung an ist, wird die Eintragungstaste angehoben.
2.1.3. erste Breite/erste Tiefe
Diese sind Schalt- und sich gegenseitig ausschließende Tasten (wird eine Taste betätigt, wird die andere nicht gedrückt). Im ersten Breiten-Modus werden neue Suchen entlang* der zuletzt ausgeführten Suche hinzugefügt. Im ersten Tiefen-Modus werden neue Suchen unter der zuletzt ausgeführten Suche hinzugefügt.
2.1.4. Wurzel hinzufügen
Die Taste Hinzufügen erlaubt das Hinzufügen neuer Wurzelknoten. Diese können neue Datenquellen oder andere Datensätze sein...
2.2. Display: allgemein
Die Anzeige zeigt das Netzwerk der Knoten und Ecken an. Ein Knoten oder Ecke kann ausgewählt werden, in diesem Fall werden sie grafisch hervorgehoben. Multiple Auswahlen werden nicht unterstützt.
Während die Suchhistorie nicht über ein Menü verfügt, kann es in einem größeren Kontext eingebettet werden, der Standard-Menüelemente enthält. In diesem Fall können Menüelemente, wie Speichern, Speichern als, Ausschneiden/Kopieren/Einfügen auf das ausgewählte Objekt angewendet werden, wenn zutreffend.
Es kann mehr als einen Wurzelknoten geben. Gewöhnlich wird die Suchhistorie mit einem einzelnen Wurzelknoten starten, der eine Datenquelle darstellt.
Die Anzeige wird automatisch ausgelegt und rekonfiguriert sich selbst, wenn Knoten und Ecken hinzugefügt oder gelöscht werden. In einem Ausführungsbeispiel werden auch manuelle Layout-Mechanismen bereitgestellt.
Ein Datensatz/Liste kann zu einem unbesetzten Gebiet des Teilfensters von einer Quelle außerhalb gezogen werden (z.B. eine bestehende Objektaufbewahrung). In diesem Fall wird der Datensatz ein neuer Wurzelknoten des Diagramms.
2.3. Datensatz-Wurzel
2.3.1. Datensatz-Wurzel-Display
Eine Datensatz-Knotenanzeige beinhaltet

• einen Kreis
• Auswahlindikator (z.B. Hervorhebung des Kreises)
• eine numerische Eintragungszählung (falls vorhanden)
• Knoten, die Datenquellen darstellen werden grafisch angezeigt und beinhalten einen Namen.

Eine Datensatz-Wurzel kann eine beliebige Anzahl von ausgehenden Ecken und ein oder null eingehende Ecken haben.
2.3.2. Datensatz-Wurzeloperationen
Auf die meisten Wurzeloperationen kann man per Mausklick zugreifen. Der rechte Mausklick ruft ein Menü dieser Operationen auf. Der linke Mausklick ruft die Standardoperation auf (Datensatz einsehen).
2.3.2.1. Datensatz einsehen (LH)
Wählen Sie den Knoten aus und zeigen Sie den Datensatz im Anzeigeteilfenster an.
2.3.2.2. Einsehen in neuem Formular
Wählen Sie den Knoten aus und zeigen Sie den Datensatz in einem spezifizierten Formular an. Diese Operation verwendet ein hierarchisches Menü, um eine Liste passender Formulare anzuzeigen (basierend auf den letzten 5 durch den Benutzer verwendeten).
2.3.2.3. Exportieren/Speichern/Speichern als
Dieses hierarchische Menü erlaubt dem Benutzer, den Datensatz in vielfältigen Formaten zu exportieren (SD, MDLXML... exakte Liste ist noch zu bestimmen). Die exakte Semantik des Speichern muss auch noch bestimmt werden.
2.3.2.4. Verfeinern
Erstellen Sie eine neue Suchecke unter diesem Knoten und wählen Sie sie aus.
2.3.2.5. Ausführen der Listenlogik
Diese Operation erstellt einen neuen Listenlogik-Knoten, basierend auf den geklickten Knoten und einem anderen Knoten.
Ablauf der Operationen.

1) wählen dieser Operation
2) System trägt einen Modus mit einem speziellen Mauszeiger (Raster) ein und bitten den Benutzer, den 2. Knoten anzuklicken. Escape oder das Benutzen einer anderen Taste storniert die Operation.
3) Nachdem der 2. Knoten ausgewählt wurde, erscheint ein Dialog und der Benutzer wird gebeten, aus der Liste der logischen Operationen auszuwählen (UND, ODER oder SUBTRAHIEREN)
4) Der neue Knoten und Ecken erscheinen in der Anzeige. Der neue Knoten ist ausgewählt.

Schritt 1) und 2) können durch die Ziehen/Ablegen Operation ersetzt werden, wo ein Knoten zu einem anderen gezogen wird. Dies definiert die beiden Quellknoten; die Abfolge oben wird bei Schritt 3) gestartet.
Damit diese Operation erfolgreich ist, müssen beide Datensätze von [der gleichen] Datenquelle erstellt werden und müssen über identische Schlüsselfelder verfügen.
2.3.2.6. Pfad speichern...
Speichern Sie diesen Knoten und alle seine Parents im vorliegenden Historienobjekt.
2.3.2.7. Unterstruktur speichern...
Speichern Sie diesen Knoten und alle seine Children im vorliegenden Historienobjekt.
2.3.2.8. Wurzel erstellen
Machen Sie diesen Knoten zur Wurzel der Struktur. In einem Ausführungsbeispiel kann dies auch eine neue Struktur schaffen.
2.3.2.9. Löschen
Löschen Sie diesen Knoten und seine Children (Unterstruktur).
2.3.2.10. Anwenden bei einer Abfrage außerhalb (Ziehen/Ablegen)
Wenden Sie eine Abfrage von einer externen Quelle an (z.B. vorhandene Objektaufbewahrung) auf den Knoten an und erzeugen Sie eine neue Ecke und Knoten. Dies kann durch eine Menüoperation aufgerufen werden (die die Auswahl des Abfrageobjekts von einem Finder oder so verlangt) oder es kann aufgerufen werden, indem ein externes Objekt gezogen und auf dem Knoten abgelegt wird.
2.4. Abfrage-Ecke
2.4.1. Abfrage-Ecke-Anzeige
Eine Abfrage-Ecke ist eine Linie, die zwei Knoten verbindet. Sie stellt eine Abfrage dar, die auf Datensätze in der Struktur angewendet werden können.

• Linie mit Pfeilspitze
• Auswahlindikator
• Name (annehmend, dass wenn eine Abfrage gespeichert wird, ein Name vergeben wird)
• Abfragetext (im Popup)

Eine Ecke verbindet eine Quell- und Produkt-Wurzel. Die Produktwurzel kann null sein (fehlend), im Dall, dass die Abfrage neu erstellt und noch nicht ausgeführt wurde.
Abfragetext bedeutet die Textdarstellung der Abfrage. Dies könnte in UQL-Form sein:
wo MOLWT > 300 UND NAME WIE %dihydr%
oder, in einigen Fällen, könnte ein durch den Menschen lesbareres Formular erzeugt werden:
wo Molekulargewicht größer als 300 ist und der Molekülname "dihydr" enthält
Auf jedem Fall wird der Text gewöhnlich zu lang sein, um in die Anzeige zu passen, deshalb wird er in einem Flyover Popup angezeigt, wo der Benutzer die Maus über die Abfrageecke bewegt.
2.4.2. Abfrageecke-Operationen
Auf Eckenoperationen wird durch einen Mausklick zugegriffen. Der rechte Mausklick ruft ein Menü dieser Operationen auf. Der linke Mausklick ruft die Standardoperation auf (Abfrage einsehen).
2.4.2.1. Einsehen/Bearbeiten der Abfrage (LH)
Dies ruft im Anzeigeteilfenster einen Abfrageeditor auf.
2.4.2.2. Abfrage ausführen
Anwenden oder Wiederanwenden der Abfrage auf seinen Quell-Datensatz und Aktualisieren des Produkt-Datensets.
2.4.2.3. Anwenden auf neuen Datensatz (In einem Ausführungsbeispiel kann das durch Ziehen erreicht werden)
Diese Operation wendet die Abfrage auf einem neuen Datensatz an.
Wie das Auflisten logischer Operationen erfordert dies die Angabe eines zweiten Arguments. Es kann also entweder durch eine modale Auswahloperation erfolgen (gleiche wie bei Auflisten der Logik) oder durch das Ziehen der Abfrage-Ecke zu einem Datensatz-Knoten.
2.4.2.4. Speichern
Speichern des Abfrageobjekts. Ein Dialog wird erscheinen, die Speicheroptionen gibt eine Auflistung logischer Knoten.
Eine Auflistung logischer Knoten stellt eine Auflistung logischer Operationen dar. Grafisch gesehen, sieht es wie eine Box aus (oder eine andere Form, die leicht vom Datensatz-Knoten unterscheidbar ist). Es zeigt Text oder ein Symbol an, die angibt, welche Operation ausgeführt wird. Eine Auflistung logischer Knoten verfügt immer über zwei eingehende Ecken und eine einzelne ausgehende Ecken.
2.5. Auflisten logischer Ecke
Auflisten logischer Ecken sind Linien, die Datensatz-Knoten mit der Auflistung logischer Knoten verbinden. Diese Ecken sind inaktiv.
2.6. Knoten/Ecken umwandeln
Das Ziehen eines Symbols stellt eine Datenquelle zu einem Knoten dar, stellt einen Datensatz von einer unterschiedlichen Datenquelle dar und zeigt die Umwandlungsoperation an. (Hinweis: Dies ist ähnlich einer Kombination, aber aufgrund der Natur des DSS beschränkt).
Wenn die Informationen zur Ausführung der Umwandlung nicht durch die Metadaten des Datensatzes offensichtlich sind, wird ein Dialog erscheinen und den Benutzer bitten, die kombinierten Felder anzugeben.
Das Ergebnis dieser Operation ist ein neuer Datensatz-Knoten, zusammen mit einem Symbol, die die Umwandlungsoperation darstellen und die Ecken, die die entsprechenden Quell-Datensätze darstellen.
In einem Ausführungsbeispiel führt das Ziehen des Knotens A zu B eine logische Auflistung aus, wenn A und B von der gleichen Datenquelle stammen. In einem Ausführungsbeispiel führt das Ziehen des Knotens A zu B eine Umwandlung aus, wenn sie von unterschiedlichen Datenquellen stammen.
In einem Ausführungsbeispiel kann ein Benutzer den Knoten zum DB-Symbol ziehen. In einem Ausführungsbeispiel kann ein Benutzer von einem Menü von DBs auswählen, während er sich in einem Knoten befindet. Die Kombination erfolgt etwas automatischer.
Dies umfasst, was die Suchstruktur tun kann. In einem Ausführungsbeispiel verfügt jeder RS über die gleiche Signatur. In einem Ausführungsbeispiel bestehen > 1 Wurzeln zum Diagramm. Wie erkennbar ist, kann die Anzahl der Wurzeln bei Bedarf eingeschränkt werden.
2.6.1. Cherry-picking Ecken
3. Verwendung (als Komponente, API (siehe unten), etc)
4. Spezifikationsaktualisierung (16.09.03 – WT)
4.1. Importieren einer Datei
Importieren...
Zeigt einen Standarddialog zum Öffnen der Datei an, wo der Benutzer die zu importierende Datei angeben kann. Benutzer können die folgenden Dateitypen importieren: SD-Datei, RD-Datei, SAR-Tabelle und XD-Datei. Die importierte Datei wird in der Historie als Datenquelle angezeigt und zeigt automatisch *alle* Datensätze in der Tabelle an. (1.0)
Das Druckfenster
Zeigt einen Standard-Windows-Druckdialog an, der es Ihnen ermöglicht, die Abfrage/Ergebnisse und Historie/Eigenschaften auszudrucken. Dies ist WYSIWIG und gleicht einem Druckbildschirm – es wird nichts unsichtbares ausgedruckt. Zeigt einen Standard-Windows-Druckdialog an, der es Ihnen ermöglicht, die Abfrage/Ergebnisse und Historie/Eigenschaften auszudrucken.
4.2. Rechtsklick-Kontextmenüs
Historie – Knoten
Benennen/Umbenennen
Zeigt eine Bearbeitungsbox an, wo Sie das Ergebnisset benennen können. Befehl ist Benennen, wenn der Knoten unbenannt ist. Wenn der Knoten bereits benannt ist, lautet der Befehl Umbenennen.
Speichern Ergebnis als...
Zeigt ein Standarddialogfenster zum Speichern der Datei an, wo der Benutzer das Ergebnis benennt und speichert.
Der Benutzer kann zum lokalen Festplatte, privatem Gebiet auf dem Netzwerk oder öffentlichem Gebiet auf dem Netzwerk speichern, wenn sie über Privilegien verfügen. Diese gespeicherten Ergebnisse erscheinen im Teilfenster der gespeicherten Objekte per Standard.
Exportieren...
Zeigt einen Standarddialog zum Speichern als an, wo der Benutzer Daten als SD-Datei, RD-Datei, XD-Datei oder Tab-Delimited Format exportieren kann.
Löschen der Ergebnisse

löscht den ausgewählten Knoten von der Historie. Dies löscht alles unter dem bestimmten Knoten.

Einsehen Ergebnisse als Top-Knoten

blendet alles über dem ausgewählten Knoten aus. (Der Knoten wird keine Datenquelle.)

Berichten als... (Post 1.0)
Zeigt einen Standarddialog zum Speichern der Datei an, wo der Benutzer den Berichttyp, Namen des Berichts angeben und ihn speichern kann. Benutzer können Berichte in den folgenden Formaten speichern: PDF, RTF, HTML, Word, Excel und PowerPoint. Benutzer gibt Berichtpräferenzen an in der Registerkarte Bearbeiten > Präferenzen > Reporting. Diese beinhalten Kopfzeilen, Fußzeilen, Titel usw.
Speichern Zweig

zeigt einen Standarddialog zum Speichern der Datei an, wo Sie den Zweig benennen und speichern, von oben in der Historie zum ausgewählten Knoten als XML-Datei. Nichts unter dem ausgewählten Knoten wird gespeichert. Dies beinhaltet Ergebnisse, Abfragen und Formulare. Dieser gespeicherte Zweig erscheint im Teilfenster der gespeicherten Objekte per Standard.

Speichern der gesamten Historie

zeigt einen Standarddialog zum Speichern der Datei an, wo Sie die gesamte Historie benennen und speichern, von oben in der Historie bis zum untersten Knoten als eine XML-Datei. Beinhaltet alle Zweige, Ergebnisse, Abfragen und zugehörige Formulare. Diese gespeicherte Historie erscheint im Teilfenster der gespeicherten Objekte per Standard.

Löschen der gesamten Historie löscht alles in der Historie, aber behält den Zylinder mit der Original-Datenquelle.
Registrieren zu > <Name der offenen Datenquelle> (Post 1.0)
Registriert alles im ausgewählten Ergebnisset zur ausgewählten offenen Datenquelle. Befehl wird nur gezeigt, wenn der Benutzer über Registrierungsprivilegien verfügt.
Finden verwandter Daten (Post 1.0)
Zeigt einen Dialog an, wo der Benutzer die offene Datenquelle zeigt, wo nach verwandten Informationen gesucht werden kann. Sucht nach Datensätzen (auf der ausgewählten Datenquelle), die über verwandte Daten verfügen, wie wenn sie angeklickt worden wären.
Historie- Fester Pfeil
Benennen/Umbenennen zeigt eine Bearbeitungsbox an, wo Sie die Abfrage benennen können. Der Befehl lautet Benennen wenn die Abfrage unbenannt ist. Wenn die Abfrage bereits benannt ist, lautet der Befehl Umbenennen.
Speichern der Abfrage als...
Zeigt ein Standarddialogfenster zum Speichern der Datei an, wo der Benutzer die Abfrage benennt und speichert. Benutzer können zu ihrer lokalen Festplatte, privatem Gebiet auf dem Netzwerk oder zu einem öffentlichen Gebiet auf dem Netzwerk speichern, wenn sie über Privilegien verfügen. Diese gespeicherte Abfrage erscheint im Teilfenster gespeicherte Objekte per Standard. Man kann mehrere Abfragen (feste Pfeile) auswählen und als eine speichern. Funktioniert auf die gleiche Weise, wie wenn der Benutzer einen Filter bearbeiten und auf einen neuen Pfeil einen Rechtsklick ausführen würde. (Ein Filter ist eine Abfrage.)
Speichern der gesamten Historie

zeigt einen Standarddialog zum Speichern der Datei an, wo Sie die gesamte Historie benennen und speichern, von oben in der Historie bis zum untersten Knoten. Beinhaltet alle Zweige, Ergebnisse, Abfragen und zugehörigen Formulare. Diese gespeicherte Historie erscheint im Teilfenster gespeicherte Objekte per Standard.

Löschen gesamter Historie

löscht alles in der Historie, behält aber den Zylinder mit der Original-Datenquelle.

Historie- Zylinder (Datenbank)
Speichern der gesamten Historie

Löschen gesamter Historie löscht alles in der Historie, behält aber den Zylinder mit der Original-Datenquelle.
4.3. Andere UI-Tasten
Suche Taste:
Wechselt automatisch zur Historie-Registerkarte
Navigationsleiste
Vorherig (Linker Pfeil oder Zurück-Taste) Geht zurück zum vorherigen Formular auf dem Sie waren, in dem Status, in dem Sie das Formular verlassen haben. Wenn Sie zum Beispiel umfangreich am Formular A gearbeitet haben und dann zu Formular B gegangen sind und dann Vorherig geklickt haben, würden Sie sehen, dass sich Formular A noch in dem Status befindet, wie sie es verlassen haben. Wenn Sie zu einer Webseite gehen würden, zeigt das Anklicken von Vorherig diese Webseite an. Dies legt den entsprechenden Knoten oder Umwandlung (Ecke) auf der Suchhistorie fest.

• Wenn das letzte Formular für eine andere Datenquelle war, dann wird die Historie für diese Datenquelle aufgerufen und der DS-Selektor wird dieses DS angeben.

Nächstes (rechter Pfeil) zeigt das nächste Formular an, auf dem Sie waren, in dem Status, wie Sie das Formular verlassen haben. Wenn Sie zu einer Webseite gehen und auf Nächstes klicken, wird diese Webseite angezeigt. Dies legt den entsprechenden Knoten oder Umwandlung (Ecke) auf der Suchhistorie fest

Hauptwerkzeugleiste

• Taste Neue Abfrage: Erstellen eines neuen Pfeils in der Historie.
• Taste Abfrage löschen: Erstellen eines neuen Pfeils in der Historie.
• Taste Suchen: Wechselt automatisch zur Registerkarte Historie

Datenquell-Selektor

• Wechselt zur neuen oder derzeitig aktiven Historie für die ausgewählte Datenquelle.

Historie-Registerkarte
Erste Tiefe oder Breite Schalttasten

Breite: Legt ganze DB oder ausgewählten Datensatz als Basis für alle neue Suchen fest, bis zur Tiefe gewechselt wird
Tiefe: Verwendet jeden neuen Datensatz als Bass für die neue Suche, bis zur Breite gewechselt wird

Taste Auflisten der Logik
Ziehen und Ablegen der Knoten aufeinander: kennzeichnet Knoten und ruft den Dialog zum Auflisten der Logik auf Taste Klicken der Auflistung der Logik: Sagt dem Benutzer, Knoten auszuwählen, wenn sie nicht ausgewählt sind, kennzeichnet Knoten und ruft den Dialog zum Auflisten der Logik auf Abspielen/Stop-Schalttaste für die Aufnahme
Startet und Stoppt die Aufnahme der Daten
Datenquell-Zylinderknoten:

Stellt die Datenquelle dar und kann eine Kennzeichnung haben, um die Anzahl der Aufnahmen darzustellen

Abfragepfeil (fest):

Klicken: Navigieren zur Abfrageseite
Rechtsklick: Siehe Franks Rechtsklickmenüs
Abfrage zum Knoten ziehen: Wird die Abfrage auf neuer Domäne ausführen
Auf Arbeitsplatz ziehen: Navigiert zu diesem Formular
Ziehen in Objektdateiordner: Aufforderung zum Speichern
Ziehe Abfragepfeil auf andere Historie-Datenquelle

Datensatz-Knoten

Klicken: Navigiert zum Durchsuchen der Seite und zeigt Formular in dem Status an, in dem es verlassen wurde
Rechtsklick: Siehe Franks Rechtsklickmenüs
Auf Arbeitsplatz ziehen: Navigiert zu diesem Formular
Ziehen in Objektdateiordner: Aufforderung zum Speichern
Ziehen des Knotens auf den Knoten: Ruft Dialog zum Auflisten der Logik auf
Ziehen des Knotens auf Zylinderknoten: Ruft Auflisten der Logik auf, um eine Eindeutigkeitsüberprüfung durchzuführen
Ziehen des Knotens auf andere Historie-Datenquelle

Auflisten der Logik

Pfeile (gepunktet): Klicken zum Navigieren zu einer Beschreibung am Arbeitsplatz
Strukturindikatoren: Oder, Und, Kein: Klicken zum Navigieren zu einer Beschreibung am Arbeitsplatz
Dialog: Und (Union), Oder (Knotenpunkt), Xoder, Kein mit ISIS/Basis wie grafische Indikatoren

Objekt Dateistruktur
Formt in der Objekt Dateistruktur der Registerkarte Historie:

Doppelklick: RS von derzeitig ausgewählten Knoten zeigt das Doppelklick-Formular an. Eine gepunktete
Linie erscheint in der Historie unter dem alten Knoten und ein neuer Knoten wird erstellt.
Ziehen eines Knotens in die Historie: RS von Knoten, auf den das Formular gezogen wurde, zeigt das neue Formular an. Eine gepunktete Linie erscheint in der Historie unter dem alten Knoten und ein neuer Knoten wird erstellt.
Abfrageformular (und/oder Filter) kann auf die Historie-Knoten gezogen werden, um eine neue Abfrage zu starten.

Sortieren
Der Historie-Status bleibt der gleiche – kein neuer Knoten und behält den sortierten Status bei, wenn Sie zu einem anderen Knoten und wieder zurück wechseln.
4.4. API
Diese Komponente kann eine .Net Benutzersteuerung sein; sie kann unter dem Basis-Framework und der MSVS .Net Umgebung verwendet werden.
Öffentlicher Paketname: MDLIntern.Basis.Steuerungen.Suchhistorie
Übersicht über den Paketinhalt
Detail:

Paket: VDL.Basis.Steuerungen.Suchhistorie
Klasse: Suchhistorie
Beschreibung: Dies ist die aktuelle Suchhistorie-Benutzersteuerung. Sie kann unter MSVS .NET und Basis-Framework arbeiten Verfahren:
Druckfähigkeiten können in der Zukunft hinzugefügt werden
Klasse: SuchhistorieKnoten
Beschreibung: SuchhistorieKnoten stellt einen individuellen Knoten dar, der von der Suchhistorie gezeichnet wurde. Dies kann durch den Entwickler über die Übernahme und/oder Aggregation ausgedehnt werden
Klasse: SuchhistorieNullKnoten
Beschreibung: SuchhistorieNullKnoten stellt einen individuellen, nicht gefüllten Knoten dar, der von der Suchhistorie gezeichnet wird. Dies kann durch den Entwickler über die Übernahme und/oder Aggregation ausgedehnt werden
Klasse: SuchhistorieWurzelKnoten
Beschreibung: SuchhistorieWurzelKnoten stellt eine individuelle Datenbank oder Datei dar. Dies kann durch den Entwickler über die Übernahme und/oder Aggregation ausgedehnt werden
Klasse: SuchhistorieUmwandlung
Beschreibung: SuchhistorieUmwandlung stellt eine individuelle Umwandlung zwischen 2 Knoten dar, in anderen Worten, es stellt eine Abfrage dar (Formular +UQL). Dies kann durch den Entwickler über die Übernahme und/oder Aggregation ausgedehnt werden. Eine Umwandlung kann eine unäre oder binäre Umwandlung sein (wie sie für Auflisten der Logik verwendet wird)
Schnittstelle: ISuchhistorieAnzeige
Beschreibung: Zeigt Callback in Bezug auf Tooltip, Kennzeichnungen, Hintergrund- und Vordergrundfarben für Knoten und Umwandlungen auf Verfahren:
Schnittstelle: ISuchhistorieListener
Beschreibung: Verhaltens-Callback in Bezug auf Knoten- und Umwandlungsaktivitäten Verfahren:
Klasse: VDL.Basis.Steuerungen.Suchhistorie.KundenspezifischerDialog
Klasse: ListLogikDialog,
Beschreibung: Diese Klasse stellt das Dialogfenster für das Auflisten der Logik dar. Dies ist ausdehnbar und/oder ersetzbar.
Schnittstelle: ISuchhistorieDialogfensterDaten
Beschreibung: Daten, die zum Status des Dialogfensters zurückkehren
Hinweis: Aufgrund der c# API-Lernkurve, können einige API-Zugriffe auf volle Verwendung der Benutzersteuerungstechnologie wechseln, dies bedeutet, in der Lage zu sein, mehr Variablenkonfigurationen vom Eigenschaftendialog des IDE einzustellen.

4.5. Persistenz
Die Suchhistorie-Struktur kann fortdauern (speichern/laden). Unten ist eine Grammatik-Datei, die mit der .xsd Konvention geschrieben wurde. Elementliste

Komplextypen
Datentypdefinitionen
Original Schemenquelle
Anhang D
VDL-Basisarchitektur
1 Einleitung
Dieses Dokument stellt eine Beschreibung eines Ausführungsbeispiels der VDL-Basis dar.
Dieses Dokument beinhaltet die folgenden Abschnitte:

• Übersicht über die VDL-Basis
• Architekturübersicht (1.Iteration)
• Anwendungen
• Arbeitsfluss
• Liste der Komponenten
• Anhang
• Übersicht über die VDL-Basis

VDL-Basis kann durch Chemiker und Biologen zur Abfrage von Daten und zum Visualisieren, Berichten und Registrieren der Ergebnisse ihrer Abfragen verwendet werden. Das VDL-Basisprodukt kann einen Framework-Layer beinhalten, das standardisierte Mittel für den Zugriff auf Kern-Schnittstellen-Dienste bietet.
Das VDLBasis-Framework kann zum Bauen dicker Clients verwendet werden und kann eine Basis zum Bau zukünftiger Anwendungen darstellen (VDL-Anwendungen, VDL-Beratungsanwendungen und Kundenanwendungen)
2 VDL-Kern-Schnittstellen-Desktop
2.1 Übersicht
VDL-Kern-Schnittstellen-Desktop stellt das Framework für VDL Client-Anwendungen insgesamt dar. VDL-Kern-Schnittstellen-Desktop besteht aus zwei wichtigen Stücken, 1) die VDL Client-Anwendung, die eine Client-Anwendung darstellt (wie zum Beispiel Base oder Reagent Selector) und 2) das VDL Client-Framework, das die VDL Client-Anwendungen unterstützt, indem fundamentale horizontale und vertikale Dienste bereitgestellt werden, die die VDL Client-Anwendungen zusammen binden und Synergien erstellt.
Ein VDL-Kern-Schnittstellen-Desktop kann viele VDL Client-Anwendungen haben, die zur gleichen Zeit und auf einem einzigartigen VDL Client-Framework ablaufen
VDL-Kern-Schnittstellen-Desktop stellt bereit:

• Eine Framework-Basis für VDLBase (Abfragen, Durchsuchen, Registrieren und Berichten)
• Verbindungen zur VDL-Kern-Schnittstelle – Session(s) und Management der VDL-Kern-Schnittstellen-Dienstverbindungen (eine Anwendung kann um neue Dienstfälle bitten oder eine bestehende verwenden) – Eine leichte Möglichkeit zum Exponieren eines N+1 VDL-Kern-Schnittstellen-Dienstes bis zum UI
• Ein Nachrichtenmechanismus über die Anwendungen hinweg (auf dem gleichen Desktop und über den Desktop hinweg)
• Integration durch – Volle Kompatibilität mit Microsoft .NET Framework – Kopplung mit bestehenden Kundenanwendungen (Web und dicke UI, kann Tools bereitstellen, um Webanwendungen zu bauen, muss in der Lage sein, mit bestehenden Webanwendungen zu koppeln/zu sprechen) – Kopplung mit MS-Office (1) verwenden unserer Objekte von MS-Office wird beschränkt sein auf die .NET Akzeptanz von MS-Office, 2) Verwendung von MS-Office von unserer VDL-Basis wird auf die Möglichkeiten beschränkt sein, die durch MS-Office .NET-Strategie geboten werden) – Bereitstellen einer einfachen Möglichkeit, das Aussehen und Gefühl zu ändern (Skins)
• Ein konsistentes Verfahren des Einsatzes über zukünftige VDL-Anwendungen hinweg
• Eine einfache Möglichkeit, um den komplexen Arbeitsflusseinsatz leicht zu machen, indem die folgenden Technologien angeboten werden: – Komponenten – Intelligente Verbindungstechnologie – Ziehen und Ablegen-Programmierung – Arbeitsflussmanagement über Benutzer und Maschinen hinweg
• Anwendungs-Lebenszyklusmanagement
• Eine Multi-Level Steckarchitektur
• Benutzer-Task-Management
• Einzelnes Login
• Eine gemeinsame Framework-Basis für die zukünftigen Produkte, die VDL liefern wird
• Discovery-Framework verfügt über unterschiedliche wichtige Technologien auf dem Server und Client-seitig. Diese Technologien verfügen über signifikante Lernkurven für unsere Kunden und ein erstklassiges Beratungsteam. Es ist wichtig für VDL, so viel wie möglich zu vereinfachen) die Entwicklung neuer Anwendungen und 2) die kundenspezifische Anpassung bestehender Anwendungen über solche Technologien, wie Komponenten, Verbindungen, Nachrichten über Anwendungen und Benutzer hinweg.

2.1.1 Konzeptuelle Architektur-Layers
In diesem Bild sitzt VDLBase oben auf dem Framework. Das Framework formt die Basis, die in der Lage sein muss, nicht nur die heutigen Erfordernisse für VDLBase zu unterstützen, sondern auch die Erfordernisse von zukünftigen VDL-Produkten (5 bis 10 Jahre). Das Framework kann eine offene und flexible Basis bereitstellen, das den Bau direkt oben drauf ermöglicht, wenn das VDLBase-Paradigma nicht mit den Erfordernissen der Zukunft übereinstimmt.
1) einige Anwendungen haben oben auf die ISIS-Basis gebaut, wie ACD Finder, 2) einige Anwendungen haben oben auf den ISIS-Kern dll (oder Objektbibliothek zu seinem Kern dll gebaut), wie ISIS für Excel und 3) einige Anwendungen, die ohne ISIS gebaut wurden, wie die Oracle-Anwendungen, die mit einer Nicht-Struktur Information arbeiten.
Kernschnittstelle stellt den Hauptfokus der Datenbank und die chemische Funktionalität bereits, die exponiert werden müssen. Die Funktionalität, die durch die Kern-Schnittstelle nicht bereitgestellt wird, kann entweder bereitgestellt werden durch 1) Cheshire oder 2) Hinzufügen zu einer Kern-Schnittstelle (kann für zukünftige Freigaben von Kern-Schnittstelle oder einem extra Domänendienst sein). Einige derzeitige Funktionalitäten, die durch die ISIS-Host Bussel-Funktionen bereitgestellt werden, können zur Zeit nicht durch die Kern-Schnittstelle exponiert werden (diese können bei Bedarf hinzugefügt werden).
2.1.2 VDL Client-Framework-Übersicht
Das VDL Client-Framework ist das allgemeine Rückgrat über alle Anwendungen hinweg, unterstützt durch den VDL Kern-Schnittstellen-Desktop. Dies ist die Basis, die zum Bau der VDLBase und zukünftiger VDL-Produkte verwendet wird. VDL Client-Framework stellt bereit:

• Task Management
• Nachrichten (über Benutzer und Maschinen hinweg)
• Fähigkeit des Hop-across (Hop-into) Anwendungen
• VDL-Kern-Schnittstellen-Verbindungen)
• Authentifizierung
• Anwendungs-Lebenszyklusmanagement
• Navigation über Anwendungen hinweg
• Steckarchitektur (veröffentlicht Schnittstellen oder API)

Hinweise:

• Das VDL Client-Framework (VDLClientFramework) deckt Windows UI-Verfahren ab, das Einzeldokument-Schnittstellenverfahren (SDI) (wie Internet Explorer) und auch das Mehrfachdokument-Schnittstellenverfahren (MDI) (wie Opera oder ISIS Basis)
• Verbindungen zu mehreren VDL Kern-Schnittstellen-Servern sind über einen Fall des VDLClientFramework erlaubt, aber der Benutzer kann nicht mehrere VDLClientFrameworks auf der gleichen Maschine laufen lassen.

VDL Client Toolkit:
Das Toolkit ist ein Toolset, das alles enthält, das kein Framework ist, aber trotzdem auf alle VDL-Anwendungen zutrifft.
Zum Beispiel ist das "hop-into" eines seiner Tools ("hop-into" ermöglicht die Kommunikation über unterschiedliche Fälle der VDL Client-Anwendungen hinweg, durch das Starten einer Anwendung und das Senden von Daten zu ihr)
Das Client-Toolkit verfügt über eine Steckarchitektur, die es Entwicklern gestattet, Tools hinzuzufügen/kundenspezifisch anzupassen, die über Anwendungen hinweg gemeinsam benutzt werden sollen.

Hinweis: VDLClientFramework und VDLClientToolkit können sich konzeptionell zusammenschließen

2.1.3 VDL Client-Anwendungsübersicht
Dies ist die Basis, die zum Bau der VDLBase und zukünftiger VDL-Produkte verwendet wird. Eine VDL Client-Anwendung (VDLClientAnwendung):

• Verfügt über eine bidirektionale Kommunikationsleitung mit dem VDL Client-Framework
• Wird durch einen VDLClientFramework referenziert, hauptsächlich für Lebenszyklus-Management (ein VDLClientFramework referenziert mehrere VDLClient-Anwendungen)
• Stellt eine Anwendung dar (wie eine VDLBase oder Reagent Selector) mit seinem eigenen Thread (sein Thread wird der ArbeitsflussThread genannt).
• Verfügt über einen ArbeitsflussThread, der sequentiell durch viele verschiedene Arbeitsflüsse schreiten kann
• Kann über ein UI verfügen oder nicht (durch die VDLClientUIAnwendung)
• Ist Thread-basiert
• Kann Nachrichten von anderen Anwendungen empfangen/an sie senden – Wenn Nachricht empfangen wird, erfolgt eine spezifizierte Handlung – Nachrichten können an eine Anwendung gesendet werden, die auf der gleichen Maschine oder auf einem Remote Computer sind (durch VDLClientFramework)
• Managt Arbeitsfluss (durch die VDLClientUIAnwendung und VDLClientKonsoleAnwendung)
• Verfügt über die Maschine für die Komponenten-Verbindungstechnologie
Diagramm: VDLClientAnwendungs-Klasse-Diagramm
• Die VDLClientAnwendung ist die Basisklasse für alle VDL-Anwendungen. Eine Anwendung kann entweder sein: – UI-basiert (VDLClientUIAnwendung), – Konsolen-basiert (VDLClientKonsolenAnwendung) oder ein – .Exe Wrapper/Adapter-basiert (VDLClientExeWrappernwendung).
• VDLBase ist UI-basiert und übernimmt von der VDLClientUIAnwendung (das auch eine VDLClientAnwendung ist).
• Die heutige VDLBase wird nicht notwendigerweise für zukünftige VDL-Produkte ausreichend sein. VDLClientUIAnwendungen sind offener und erweiterbarer als VDLBase und sollte verwendet werden, wenn die VDLBase nicht den zukünftigen Anforderungen entspricht.
• VDLClientExeWrapperAnwendung ist ein Wrapper einer bestehenden Anwendung, die von einer VDLClientAnwendung verwendet werden muss.

2.2 Untersysteme und Module
2.2.1 Übersicht
2.2.1 Die Client Untersysteme
2.2.2.1 VDL Kern-Schnittstelle-Desktop, VDLClientFramework und VDLClientAnwendung
2.2.2.2 VDL Basis Komponente für .NET (Microsoft Visual Studio)
2.2.3 Die Untersysteme des Servers: Kern-Schnittstellen-Liaison und die zukünftigen N+1 Dienste
2.3 Prozessansicht
VDLClientAnwendung und VDLClientFramework laufen asynchron:

• Jede VDLClientAnwendung führt ihren eigenen Thread aus (der Leichtprozess kann eine Anwendungsdomäne von .NET sein)
• VDLClientFramework verfügt über seinen eigenen Thread (es kann der Thread 0 => Prozess sein)
• Eine Maschine kann mehr als einen Fall jeweils auf dem VDLClientFramework laufen lassen, aber aus Brauchbarkeitszwecken kann ein Benutzer nicht mehrere VDLClientFramework auf der gleichen Maschine ausführen.

Hinweis: Das Framework wird eine .NET Remoting verwenden, um eine unstabile VDLClientAnwendung in seinem eigenen Prozess zu konfigurieren [Anforderung RD23]

2.4 VDLClientFramework
2.4.1 Hochklassiges Klassendiagramm des VDLClientFramework

• _surroundingFrameworkUI stellt die VDLClientFramework-UI dar (kann SDI oder/und MDI sein)
• Eine neue Anwendung verfügt über die Auswahl, von der VDLClientUIAnwendungsklasse oder von der VDLBase-Klasse gebaut zu werden.
• VDLClientAnwendungsFabrik weiß, wie eine beliebige VDLClientAnwendung erstellt wird (aus dem Nichts und auch von einem Anordnungsfall). Es verfolgt sie auch über sein Repository nach.
• VDLClientAnwendung verfügt über die Basis-Maschine für die Komponenten-Technologie
• VDLClientUIAnwendung verfügt über die Maschine für: 1. Die Verarbeitung des Arbeitsflusses 2. Die intelligente Verbindungstechnologie
• ein Fall des VDLClientFramework kann das Management der Verbindungen zu multiplen VDL Kern-SchnittstellenServern sein, aber es könnte nicht gestatten, dass mehrere VDLClientFrameworks vom gleichen Benutzer auf dem gleichen Computer ausgeführt werden.

Framework-Inbetriebnahmeschritte:

1. Der Benutzer klickt auf ein Symbol auf seinem Desktop zum Start. Die Startup-Klasse überprüft, ob das Framework läuft, wenn nicht, wird es mit der Anwendungsreferenz gestartet.
2. Das Framework nimmt die Komponenten in Betrieb, die in seiner Konfigurationsdatei angegeben sind (einige Komponenten haben einen Link zu einigen Login-UI, zum Beispiel eine Komponente kann eine Kern-Schnittstellen Verbindungskomponente sein)
3. Das Login UI ist eine Anzeige (laut (2)) und gibt eine Aufforderung an den Endbenutzer.
4. Das Framework nimmt das surroundingFrameworkUI in Betrieb, wenn es nicht Null ist.
5. Das Framework nimmt die Anwendungen in Betrieb (fortbestehende Anwendungen, Standard-Anwendungen, Aktivieren der Anwendungs-Callbacks)

Szenario
Zum Beispiel kann das _surroundingFrameworkUI nur eine Menüleiste und eine linke Shortcut-Leiste "a la Outlook" sein. Innen, in der linken Shortcut-Leiste können Sie Symbole sehen, die unterschiedliche Anwendungen darstellen, die bereits ausgeführt werden
In diesem Beispiel stellt die Taste "Basis 1" in der "Shortcut-Leiste" die derzeitig sichtbar laufende Anwendung dar. In diesem Beispiel sind 5 weitere Anwendungen, die parallel laufen (Comp. Loc, Base1, Base3 und 2 Reagent Selector). Sie sollten über eine (oder viele) Webbrowser-Anwendungen verfügen.
2.4.2 VDLClientFramework Kommunikation: Inter und intra VDL Kern-Schnittstellen-Desktop Kommunikation
Es gibt verschiedene Zugriffe auf die Kommunikation:

A1. Code (API)
A2. Einstecken
A3. Endbenutzer

Alle diese Zugriffe unterstützen die folgenden Kommunikationsarten:

CT1. Gleiche Maschine, gleiche Anwendung
CT2. Gleiche Maschine, über Anwendungen hinweg
CT3. Über Maschinen hinweg
CT4. Über Benutzer hinweg

VDLClientAnwendungen wird in der Lage sein, miteinander über eine oder zwei der folgenden Nachrichtenmechanismen zu sprechen:

M1. Nachrichtensystem a. Ein spezifisches Nachrichten-API zum Senden von Nachrichten (Ereignis + Daten) von einer Anwendung zu anderen [.NET Remoting kann hier verwendet werden] b. Eine Durchführung kann über das VDL Kern-Schnittstellen Nachrichten-Center erfolgen (siehe Anhang\benötigte Extra-Funktionalitäten von\VDL Kern-Schnittstellen-Nachrichten- Center um diese Anforderung zu unterstützen) [Nachteil: schwerer, Gebrauch: für Sync. Tasks]
M2. Leite Anruf [P2P] an eine VDLClientAnwendung. Sehr flexibel, wenig generisch [.NET Remoting kann hier verwendet werden]
M3. Verwendung als privates Mailsystem das mit der VDLBase koppelt ("Senden an >... ") [Vorteile: Robustheit, skalierbar kein C# zu Java zu C# Translationskosten] – Kann etwas wie die IBM\MQSerie verwenden
M4. Clipboard
M5. TCP/UDP Buchsen. Einfach, hoch portabel, schnell. Vergleich:

2:

Kein Optimum

X:

Kann es tun

C/S:

Client/Server

Schlussfolgerung:
Die beste Wahl ist grün. Dies wird überprüft und auf dem Spezifikationsdokument detailliert werden. VDL KERN-SCHNITTSTELLE\Nachrichten-Center (M1.b) scheint strategisch eine gute Entscheidung zu sein, es muss aber eine Lösung für 1) CT4 (in der Lage sein, Nachrichten über Benutzer hinweg zu senden) und 2) einige angemessene Leistungen (der SOAP-Layer kann die Kommunikationsleitung verlangsamen) bieten.
Für Bewertungszwecke ist es wichtig zu verwenden 1) ein Nachrichten-Basissystem, 2) das asynchrone Nachrichten gestattet.
Inter-Prozess-Kommunikation wird nach der Vereinbarung beider Parteien möglich sein. Wenn der gleiche Benutzer in beiden Prozessen erscheint, ist die Vereinbarung nicht notwendig. Wenn das E-Mail Paradigma ausgewählt wird, dann kann der Empfänger die Nachricht frei lesen, akzeptieren oder löschen.

Hinweis: ein Ereignis (oder Nachricht) kann über zugehörige Daten verfügen.

Wenn eine Anwendung mit einer anderen Anwendung kommunizieren möchte, die auf einem anderen Framework läuft, sendet die Emitter-Anwendung eine Kontaktnachricht zum Ziel-Framework\Anwendung. Unterschiedliche Mechanismen können durchgeführt werden, um dies zu erreichen, einige Lösungen sind Domänen-basiert, Server-basiert...
Wie Frameworks miteinander maschinenübergreifend sprechen:

– Starten von n Frameworks und sie miteinander bekannt machen, sodass sie kommunizieren können. Das Problem mit dieser Methode ist, dass sie viel weiterleiten müssen – dies ist eine N-Quadrat Kommunikation – wenn Sie dies richtig tun, wird es transparent sein (dies ist wie eine Agent-Methode, wirklich robust, wenn eine der Anwendungen zertällt, wird die andere Anwendung immer noch in der Lage sein, zu kommunizieren).
– Sie können auch UDP-Buchsen für das Senden verwenden, um die Arbeit zu vereinfachen.
– Oder eine Domäne erstellen, die für die Herstellung des Relais und des Sendesignals verantwortlich ist.
– Sie können eine bereits bestehende Domäne verwenden (wie das Nachrichtensystem, MQSerie, ein Register, Benennungsdienst oder Ressource Discovery Server Methoden...)
– Das Framework selbst kann die Domäne ersetzen und einen VDL Kern-Schnittstellen-Dienst bitten, das Ziel-Framework zu kontaktieren.

2.4.3 Toolkit
Das Toolkit ist ein Toolset, das alles enthält, das kein Framework ist, aber trotzdem auf alle VDL-Anwendungen zutrifft.
2.4.3.1 VDLBase Framework-Nachrichtensysteme
Oben auf der "VDLClientFramework-Kommunikation" gebaut, gestattet das Nachrichtensystem:

1. Datenobjekte über Anwendungen, Benutzer und Maschinen hinaus zu transferieren: Senden von Nachrichten. Diese Funktionalität ist von allen Aktoren verfügbar (Chemiker, Adv. UI-Designer, dev.). Es ist wie ein verteiltes Clipboard.
2. Gemeinsames Benutzen von Objekten für den ganzen Arbeitsfluss-Umfang: Arbeitsflussstatus. Zum Beispiel kann das Objekt eine DB-Verbindung sein. Diese Funktionalität ist nur für den Adv. UI-Designer, Admin und den Dev. verfügbar)
3. Objekt gemeinsam über 2 Formular benutzen: FormularNavigator. Diese Funktionalität ist für den Adv. UI-Designer, Admin und den Dev. verfügbar)

2.4.3.2 Hop-Into (oder Hop-Across):
Die Hop-into Fähigkeit gestattet dem Benutzer, Dateninformationen zwischen Anwendungen/Arbeitsflüssen zu transferieren. Dies wird das VDLClientFramework und die Inter-Prozess-Kommunikationstechniken, basieren auf .NET für Anwendungen verwenden, die auf separaten Prozessen und Maschinen laufen.
Hop-Across ist eine Kombination von 1) Starten der Zielanwendung (oder Finden einer bereits laufenden Anwendung) über das VDLClientFramework und 2) Senden der Daten zur Anwendung über den Nachrichtenmechanismus
2.4.3.3 Benutzerpräferenzen und Anwendungseinstellungen
Benutzerpräferenzen werden global für den Benutzer gehandhabt. Präferenzen haben Unterpräferenzen und Eigenschaften. Benutzerpräferenzen werden im Benutzerprofil gespeichert auf der VDL Kern-Schnittstelle\Authentifizierung db.
Anwendungseinstellungen und Formulareinstellungen werden angeben, wie eine Anwendung oder Formular eingestellt ist.
Die Anwendung (oder Formular) Einstellungen werden innerhalb der Application.xml (oder Form.xml gespeichert auf der VDL Kern-Schnittstelle\OSS\<ein gemeinsames Gebiet> (Hinweis: VDL Kern-Schnittstelle\OSS muss auf eine DB steckbar sein)
Anwendungseinstellungen können Benutzerpräferenzen nicht überschreiben, aber Benutzerpräferenzen können Anwendungseinstellungen überschreiben.
Nachdem eine Application.xml (oder Form.xml) aktualisiert ist, wird der Benutzer aufgefordert, entweder das neue Formular wie vorliegend zu verwenden oder zu versuchen, das neue Formular automatisch mit dem alten Formular in einer kundenspezifischen Datei zu verschmelzen.
Eine Formularanpassungsdatei beinhaltet nur den Unterschied zwischen dem Originalformular und was der Benutzer hinzufügt.
2.4.3.4 Skins: Kundenspezifisch anpassbare UI (Look and Feel) [Nicht rev 1.0]
Um unser Framework in die laufende Umgebung eines Kunden zu integrieren.
Dies wird ermöglicht durch die C#-Funktionalität.
2.4.3.5 I18N – Internationalisierung
Das Framework wird einen generischen Mechanismus bereitstellen, der die unterschiedlichen Dateien für die unterstützten Sprachen handhabt.
Es gibt für die Internationalisierung 3 Hauptebenen:

1. Laufen in verschiedeneren Betriebssystemen
2. Dateien von Datenbanken in das korrekte Format verschieben (Datum, etc... ) • Entsprechend der örtlichen Einstellungen (oder Präferenz): – Sortieren sollte korrekt gehandhabt werden (einige Sprachen haben größere Zeichen als andere) – Auf Datenbankebene (sollte für Oracle OK sein, wenn Oracle und der Treiber für Oracle gut konfiguriert sind) – Datum sollte als Zahl gespeichert und als Datum rückkonvertiert werden
3. UI-Translation • Ein Fehler pro Anwendung • Ein Fehler pro Framework • Die UI-Texttranslation (Menü, Flasche, etc...) • Vereinheitlichte Feldtabellenfelder Basis kann den systemeigenen Mechanismus verwenden, der innerhalb des MFC geliefert und in .NET wiederverwendet wird. Dieser Mechanismus basiert auf einer Ressource-Datei (.resx), wo jede Translationsdatei über ein Paar verfügt <einzigartige ID, Text (in einer Sprache)>. Diese einzigartigen IDs werden dann durch die UI verwendet.

VDLBase wird unter Verwendung von Unicode-Strings geschrieben, um die 16 Bits Sprachen (wie japanisch) zu unterstützen [C# Support ist systemeigen]
2.4.3.6 Umgang mit Fehlern
Das VDLClientFramework-Toolkit wird einen Mechanismus bereitstellen, der mit Fehlern umgeht. Die Fehlerhandhabung arbeitet mit unterschiedlichen Dateien für die unterstützten Sprachen. Hauptsächlich die Anwendung fragt das Framework für ein Fehlerhandhabungs-Objekt und das VDLClientFramework sendet der Anwendung die ID des richtig initialisierten Objekts zu.
Zwei Typen von Fehlerdateien.

• Eine Fehlerdatei pro Anwendung [Fehler in dieser Datei bezieht sich nur auf die Anwendung]
• Eine Fehlerdatei für das Framework [Fehler in dieser Datei bezeiht sich auf das Basis-Client-Framework (oder VDL Kern-Schnittstelle-Desktop) und das Backend]

Der Fehleranwender muss die Internationalisierung unterstützen:
Die Standardfehlerdateien werden in englischer Sprache sein. Jede Fehlerdatei kann über sein eigenes internationales Äquivalent verfügen (Russisch, Französisch, Spanisch... )
Der Fehleranwender wird das OS-Internationalisierungs-Setup entdecken und adäquat die entsprechenden Fehlerdateien verwenden.
Ein Fehler wird über eine einzigartige ID verfügen, die verwendet wird in 1) der Fehlerdatei und 2) im Kern
Hinweise:

• Basis und BaseFramework können miteinander verschmolzen werden.
• Die Fehlerdateien können innerhalb des Anwendungsordners organisiert werden, bitte nehmen Sie auf das Kapitel Ordner und Dateien für weitere Details Bezug

2.4.3.7 Log Framework
Auf den Logger kann überall innerhalb des Codes zugegriffen werden. Es wird 5 Alarmstufen geben: FATAL, FEHLER, WARNUNG, INFO, DEBUG. Verwenden Sie zum Beispiel einen äquivalenten .NET des Log4J um mit dem Backend-Login-Mechanismus kohärent zu bleiben.
Log4J für .Net wird Log4Net genannt (http://log4net.sourceforge.net/)
log4net ist ein Logging API, das flexible und beliebige Detailsteuerung über das Logmanagement und Konfiguration bereitstellt. log4net ist ein Port exzellenter Log4j Framework zur .Net Laufzeit. Das Log4net Framework ist ähnlich wie ein möglicher Original-Log4j, während es Nutzen aus den neuen Funktionen in .Net Laufzeit zieht. Siehe http://jakarta.apache.org/log4j für weitere Informationen zu Log4j.
Log4net Framework wird durchgeführt in C# (C Sharp) unter Verwendung von Microsoft VisualStudio .NET. Es wurde entwickelt, um in der .NET Laufzeit zu laufen. In binärer Form kommt es als eine gemanagte Code-Baugruppe. Diese Baugruppe kann direkt von jeder .NET-Sprache verwendet werden, einschließlich gemanagtem C++, C#, VB.NET.
Lizenz: Apache
2.4.3.8 Authentifizierung und Lizenzierung
Das VDLClientFramework wird diese 2 Funktionalitäten vermitteln. Siehe "Sicherheit und Erlaubnis" & "Lizenzierung" für weitere Details
2.4.3.9 Hilfemechanismus
Das VDLClientFramework-Toolkit wird einen Mechanismus bereitstellen, der die Hilfe handhabt. Hilfe wird I18N unterstützen.
Wie der Umgang mit Fehlerdateien wird die Hilfe über eine Datei verfügen, die die Hilfe-IDs und deren zugehörigen Hilfetext beinhaltet. Die Hilfe-IDs werden innerhalb des Codes verwendet.
2.4.3.10 Umgang mit Bildern
Das VDLClientFramework-Toolkit wird einen Mechanismus bereitstellen, der die Bilder handhabt. Der Bilderanwender wird in der Lage sein, ein großes Bild aus der Datenbank zu entnehmen und seine Thumbnails dynamisch zu berechnen. Er wird auch Möglichkeiten zur Anzeige von Bildern haben. Aus Leistungsgründen kann es besser sein, die Multi-Auflösungsbilder vorzuberechnen und zu speichern. Bei richtiger Ausführung hat dies keine große Auswirkung auf die Bildgröße und ist viel schneller.
2.4.3.11 Task-Listenmanagement [Basis V.2.0]
Das Framework stellt einen Mechanismus bereit, der mit dem Task-Listenmanagement umgeht.
2.4.3.12 Shortcut Keys Mapper
Das Framework stellt den Basis-Standard Shortcut-Mechanismus bereit; jede Anwendung kann dann einen Shortcut-Key aktivieren/deaktivieren oder ihn über ein Referenzobjekt umdefinieren (siehe weiter für Detail). Hier können auch die Ressourcendateien von .Net verwendet werden
Vom Anforderungsdokument:
Wählen Sie alle Daten in einem Feld oder aus einer Liste aus, indem Sie Ctrl A verwenden Kopieren Sie die Daten in eine andere Anwendung, indem Sie Ctrl C, Shift Ctrl C und Ctrl V verwenden
Mit Ctrl X können Sie die ausgewählten Werte aus dem Clipboard ausschneiden
Mit CTRL B können Sie den hervorgehobenen Text fett drucken
Mit Ctrl I können Sie den hervorgehobenen Text in Schrägschrift erscheinen lassen
Mit CTRL S speichern Sie das aktive Objekt
Mit TAB- gehen Sie im Formular von Spalte zu Spalte
F2- Zum Ändern des Maßstabs der ausgewählten Struktur
F3- Um SD-DATEIEN zu lesen
F5- Zum Registrieren
F6 Widerrufen
←, → Kursortasten zum Bewegen nach vorn und zurück im Datensatz
Esc- Abwählen
Alt-S Sortieren
Alt I- Importieren
Alt E- Exportieren
ALT R- Bericht
ALT B- Formular zurück
ALT F- Formular vorwärts
ALT SHIFT TAB – Um zwischen den VDLBase-Anwendungen zu wechseln.
2.4.3.13 Drucken
Das Toolkit wird mit der Druckfabrik umgehen
2.4.3.14 Widerrufen & Wiederholen des Frameworks
Das Toolkit wird mit dem Widerrufen & Wiederholen des Frameworks umgehen. Dieses Framework wird eine Fabrik des Befehl-Design-Musters von GoF sein.
2.4.3.15 Lizenzüberprüfung
2.4.4 Persistenz
Objekt kann auf dem Client oder Server gespeichert und geladen werden.
Der Mechanismus für fortbestehende Daten muss mit zwei Objekttypen umgehen:

1) Binäre: wie Komponenten, die auf dem Server aufbewahrt werden und lokal auf dem Client gecacht werden (durch das .NET Caching)
2) Textformat: wie Arbeitsfluss, Formulare, Ergebnisset, Listen, Snapshots von Datensätzen, Suchhistorie, etc... die auf dem Server in der VDL Kern-Schnittstelle\Objekt-Aufbewahrungsdatenbank (neue Anforderung für OSS) fortbestehen

Der vollständige Status der Anwendungen und des Frameworks bestehen nicht fort, nur die spezifizierten Objekte bestehen fort.
Es gibt 3 Typen von Informationen, die zu speichern sind von (2):

• Nur Daten
• Nur Formular. Das Formular wird als nicht aufgefülltes Formular behandelt
• Daten + Formular. Das Formular wird als aufgefülltes Formular behandelt.

Hinweis: "Nur Formular" und "Daten + Formular" kann als das Gleiche betrachtet werden, z.B. kann "Nur Formular" ein nicht aufgefülltes "Daten + Formular" sein

Es gibt einige verschiedene Techniken zum Speichern der Daten: Für statische Daten

• Nach Wert: Die Daten werden im Inneren eines Dokuments gespeichert (wie eine SD-Datei). Wenn die Daten dynamisch sind, stellen die statischen Daten einen Snapshot der Daten dieses bestimmten Zeitpunkts dar.

Für dynamische Daten

• Nach Referenz: Das Dokument beinhaltet Hinweise auf Daten, die anderswo fortbestehen. Diese Daten können sich mit der Zeit ändern (wie eine Liste)
• Nach Erstellung: Das Dokument enthält die Technik zum Abrufen oder Wiedererstellen der Daten (wie ein Dokument mit dem Namen der Datenbank und des SQL)...

Hinweis: VDL Kern-Schnittstelle\OSS wird mit dem Formularmanagement umgehen. Kunden möchten, dass mit dem Formular in der Datenbank umgegangen wird, deshalb muss OSS dies bereitstellen [VDLBase Version 1.0). OSS muss einen lokalen Mechanismus bereitstellen [VDLBase Version 2.0]. Als eine neue Anforderung muss OSS auf der Datenbank ausgeführt werden.

Schlussfolgerung:
Es wurde bei der Anforderungsüberprüfung des Endbenutzers (Teil 2) entschieden, dass die Persistenz bei der Spezifikationsphase bestimmt wird, dahingehend, welcher Typ der Persistenz verwendet werden wird (nach Wert, nach Referenz, nach Erstellung (SQL)) und für welches Objekt.
2.4.5 Hochgradiges Aktivitätsdiagramm des VDLClientFramework
Nachdem die Anwendung gestartet wurde, überprüft der VDLClientFramework, ob eine seiner Anwendungen vorher fortbestanden haben. Wenn ein Fall fortbestand, wird das VDLClientFramework diesen fortbestandenen Fall wieder instanziieren. Wenn nichts fortbestanden war, wird das VDLClientFramework einen neuen Fall erstellen.
Wie zuvor gesehen, wird ein VDLClientFramework Fall über seinen eigenen Thread verfügen und wird in der Lage sein zu arbeiten, während der Benutzer auf einer laufenden VDLClientAnwendung arbeitet.
Der Benutzer wird zum Beispiel in der Lage sein, von der Anwendung eine Suche zu starten, große Berechnungen von einer anderen Anwendung durchzuführen und trotzdem noch seinen Verbindung im Reagent Selector-Arbeitsfluss zu durchsuchen.
Wenn der Benutzer eine Anwendung verlässt, wird er aufgefordert, sie zu speichern (Fortbestehen ihres Status', sodass der Benutzer darauf zurückkommen kann).

• Anfrage für Benutzer-Berechtigungsnachweis wird vom VDL Kern-Schnittstellen-Authentifizierungsmechanismus verwendet. Dies ist ein einzelner Login pro VDL Kern-Schnittstellen-Server für alle die Anwendungen, die im VDLClientFramework laufen (einschließlich Internetanwendungen), die Dienste von der gleichen VDL Kern-Schnittstelle verwenden. Um in der Zukunft einen "einzelnen Login" zu haben, kann eine der VDL Kern-Schnittstellenserver ausgewählt werden, die primäre/globale VDL Kern-Schnittstelle zu sein, die die Benutzer-Berechtigungsausweise von anderen VDL Kern-Schnittstellen kennt.
• VDL Kern-Schnittstellen-Authentifizierung wird verwendet, um mit unterschiedlichen Benutzerprivilegien umzugehen, die von der VDL Basis angeboten werden (Endbenutzer, Admin, Adv. UI-Designer und Entwickler).
• Standard- versus Enterprise-Edition der Anwendungen werden durch den VDL Kern-Schnittstellen-Lizenzmanager gehandhabt.

Hinweis: Um unverbunden mit dem Netzwerk zu arbeiten, muss VDL Kern-Schnittstellen-Login einen Caching-Mechanismus anbieten, der den letzten Berechtigungs-Cache wiederverwendet, wie es Windows tut [Basis 2.0].

2.4.6 VDLClientFramework und VDL Kern-Schnittstelle
VDL Kern-Schnittstellen-Session sitzt im VDLClientFramework; es wird von den VDLClientAnwendungen für einen vorgegebenen Benutzer und VDL Kern-Schnittstellen-Server gemeinsam benutzt. Ein VDL Kern-Schnittstellen-ServiceFall (ein N+1 Service) kann von einer Anwendung über das VDLClientFramework über die VDL Kern-Schnittstellen-Session angefragt werden.
In diesem Szenario startet der Chemiker eine VDLClientAnwendung (das VDLClientFramework kann bereits mit einigen VDLClientAnwendungen gestartet worden sein oder es kann ein neuer Fall des VDLClientFrameworks sein). Die VDLClientAnwendung bittet um die VDL Kern-SchnittstellenSession. Das VDLClientFramework fordert den Benutzer auf, Berechtigungsausweise vorzulegen und wenn diese unbekannt sind, versucht es, eine bestehende VDL Kern-SchnittstellenSession im Cache zu finden. Wenn das VDLClientFramework keine finden kann, wird er eine Verbindung zum VDL Kern-Schnittstelle und Cache für einen Fall der VDL Kern-SchnittstellenSession herstellen. Dann kehrt die VDL Kern-SchnittstellenSession zur VDLClientAnwendung zurück.

Hinweis: der gleiche Cache-Mechanismus, der auf die VDL Kern-Schnittstellen-Session angewendet wird, kann für die Service-Fälle verwendet werden. Die Basis sollte nicht verhindern, dass der Entwickler seine Servicefälle mitteilen kann. (Bei Beschränkungen muss der Kundendienst Thread-sicher sein)

2.5 VDLClientAnwendung
2.5.1 VDLClientAnwendung Lebenszyklus
Die Hauptstadien der VDLClientAnwendung sind geladen, initialisiert, geschlossen und fortbestehen.
Initialisiert stellt den Status einer VDLClientAnwendung nach ihrer Erstellung dar (oder Wiederauferstehung von einer fortbestandenen Datei). Initialisieren und Schließen haben Callbacks, wie Prelnitialize(), Postlnitialize(), PreCloseQ und PostClose(). Nach der Initialisierung wird die Anwendung in der Lage sein, Nachrichten zu senden und zu empfangen. Nachdem der Benutzer fertig ist, wird die Anwendung optional in einer Datei fortbestehen.

Hinweis: Das folgende Diagramm stellt den Status der Maschine eines ArbeitsflussThreads dar
Hinweis: Lesen Sie die XML Konfigurationsdatei, die sowohl die Erstellung eines neuen Falls oder die Wiederauferstehung eines fortbestandenen Falls aufzeigt. Das bedeutet, dass ein neuer Fall ein fortbestandener Fall mit dem Standardstatus ist.

2.5.2 VDLClientUIAnwendung und Arbeitsfluss
Eine VDLClientUIAnwendung:

• Geht mit einem einzigartigen ArbeitsflussThread um (zum Beispiel, ein Fall einer VDLClientUIAnwendung kann ein Reagent Selector Arbeitsfluss sein, ein anderer Fall kann eine Freistil-Internet URL sein und ein letzter Fall kann ein Verbindungsfinder-Arbeitsfluss sein. Diese 3 unterschiedlichen Fälle werden von 3 unterschiedlichen parallelen/konkurrenten VDLClientAnwendungsfällen behandelt. Der Benutzer kann zwischen ihnen nach Bedarf wechseln, ohne eine von ihnen zu stoppen).
• Kann auch mit 1 zu viel verbundenem Arbeitsfluss im gleichen ArbeitsflussThread/Anwendung umgehen. In diesem Fall werden diese 3 Arbeitsflüsse sequenziell ablaufen (dies formt einen großen Arbeitsfluss, bestehend aus mehreren verbundenen Arbeitsflüssen).

Es gibt 2 verschiedene Möglichkeiten der Verbindung von Arbeitsflüssen:

1. Ein Arbeitsfluss kann in einem "Meta-Status" eines größeren Arbeitsflusses sein
2. Ein Arbeitsfluss kann Transitionen zu einem anderen Arbeitsfluss haben

2.6 Arbeitsflüsse
Das folgende Konzept wurde vom Objekt-Paradigma inspiriert. Ein Objekt verfügt über Attribute, die den Status des Objekts darstellen. Der Status wird durch die Verfahren modifiziert. Die Verfahren + das Statusformular einer Statusmaschine für dieses Objekt. Die Variablen, die in einem Verfahren erstellt und verwendet werden sind außerhalb des zulässigen Bereichs, sobald Sie die Verfahren verlassen (Außer für Hinweise). Die Attribute des Objekts können von allen Verfahren des Objekts verwendet werden, sie liegen außerhalb des zulässigen Bereichs, wenn das Objekt sich selbst nicht mehr im zulässigen Bereich befindet. Das Objekt verfügt im Allgemeinen über einen Erbauer, der die Attribute initialisiert und einen Zerstörer (Vollender), der die Attribute löschen kann. Durch das Anwenden des gleichen Objektkonzepts zu einer VDLClientUIAnwendung kann der Arbeitsfluss aus mehreren Knoten zusammengesetzt werden.
2.6.1 Übersicht
Ein Arbeitsfluss setzt sich aus mehreren Knoten, Ecken, einem Startpunkt und einem Endpunkt zusammen. Jeder Knoten referenziert zu einem Formular oder zu einem anderen Arbeitsfluss. Ein Formular ist zusammengesetzt aus Teilen (oder Komponenten oder VDLClientKomponenten).
Zwei Knoten werden durch eine Ecke verbunden. Eine Ecke referenziert eine FormularNavigator-Komponente, die sichtbar im Arbeitsfluss-UI und in den Formularen ist.
Ein ArbeitsflussThread ist eine Anwendungsverarbeitungseinheit. Es gibt einen Arbeitsfluss Thread pro VDLClientAnwendung. Ein ArbeitsflussThread kann viele Arbeitsflüsse sequenziell ablaufen lassen (Die sequenziellen Arbeitsflüsse können als ein großer Arbeitsfluss angesehen werden, da 1) es jeweils eine Verarbeitungseinheit gibt und 2) Sie Regeln (oder Transitionen) haben, von einem Arbeitsfluss zu einem anderen zu wechseln).
Die Sequenzierung der Formulare wird durch die Ecken über den FormularNavigator gehandhabt. Der Datenfluss wird über die Teile-Verbindungstechnologie verbunden.
Der Arbeitsflussstatus übernimmt vom Statusobjekt. Der Status ist ein Repository der Objekte/Teile (Der Status ist eine Art Hash-Tabelle [Name, Objekt]).
Auf den zulässigen Bereich eines Objektes im ArbeitsflussStatus kann durch die anderen Objekte im gesamten ArbeitsflussThread zugegriffen werden.
Sie können zum Beispiel zwei Datenquellen im ArbeitsflussStatus ablegen und sie von einem beliebigen Knoten aus, je nach Bedarf, verwenden.
Ein FormularNavigator ist ein Formular-an-Formular Navigator, es ist ein einfaches Konzept, das dem Endbenutzer hilft, Objekte zusammen zu verbinden, die von unterschiedlichen Formularen stammen. Ein FormularNavigator hat:

• Einen FormularNavigatorStatus, der mit der Argumentenpassage über Knoten/Formulare hinweg umgehen kann. Auf den zulässigen Bereich des Objekts, das im FormularNavigatorStatus gespeichert ist, kann nur von Objekten aus zugegriffen werden, die sich in beiden Knoten (oder Formularen) befindet, die mit der Transition (oder FormularNavigator) Extremitäten zusammenhängen. (Hinweis: Ein Objekt kann entlang des Arbeitsflusses durch jeden Knoten über die unterschiedlichen FormularNavigatoren jedes Formulars weitergeleitet werden. Sicherlich wird in der Realität dieses Objekt höchstwahrscheinlich ein ArbeitsflussStatus-Objekt werden)
• Ein FormularURLNavigator, der zum nächsten Knoten zeigt.

Hinweis – Einschränkung:
Ein Advance UI-Designer kann einen Arbeitsfluss vom VDLBaseObjektRepository-Service (zum Beispiel einen Einkaufswagen-Arbeitsfluss) zu einem bestehenden Arbeitsfluss importieren. Der Advance UI-Designer muss dann die Arbeitsflüsse verbinden, durch 1) Hinzufügen von Transitionen zwischen ihnen oder 2) Hinzufügen eines "Meta-Status", der den importierten Arbeitsfluss beinhaltet. Es ist nicht möglich, zwei parallele, unverbundene Arbeitsflüsse zu haben, die gleichzeitig in der gleichen VDLClientAnwendung laufen. Es ist möglich, dies mit zwei unterschiedlichen Anwendungen auszuführen, indem die 2 Arbeitsflüsse in separaten VDLClientAnwendungen behalten werden und Daten zwischen ihnen durch den VDLClientAnwendungsKommunikationsmechanismus ausgetauscht werden.
Das folgende Diagramm stellt eine mögliche UI für den Arbeitsfluss-Designer dar (Advance UI Designer).
Szenario
Die folgenden Diagramme zeigen, wie Daten über Formulare hinweg durch den FormularNavigator übermittelt werden können. In diesem Szenario befindet sich die DB-Steuerung im ArbeitsflussStatus-Gebiet, die für den ganzen Arbeitsfluss sichtbar ist. Der Adv. UI-Designer doppelklickt auf dem Arbeitsfluss-Knoten und kommt in einem Formular an. Wenn sich der Arbeitsfluss im Laufzeit-Modus befindet, erscheint Formular A. Wenn der Benutzer auf die Suchtaste klickt, leitet die Komponentenverbindungstechnologie das Suchsignal zum DB-Teil weiter (im Inneren des ArbeitsflussStatus) und drückt das Ergebnisset in den FormularNavigator AB (der den Knoten/FormularA mit Knoten/FormularB verbindet). Der FormularNavigator aktiviert das neue Formular B und bittet um die Anzeige. Dann nimmt das Raster von Formular B das Ergebnisset, das den FormularNavigator AB enthält, und zeigt es an.
(Link: wie ist es mit der Verbindungstechnologie verbunden)
Formular B hat zwei FormularNavigatoren, die die beiden Verbindungen darstellen, die an Knoten B angeschlossen sind (ein FormularNavigator stellt die Verbindung zwischen Formular A zu Formular B dar und der zweite FormularNavigator stellt die Verbindung zwischen Formular B zu Formular C dar)
Hinweise für das nächste Diagramm

• Der violette Pfeil zeigt, dass der FormularNavigator oben (Arbeitsfluss-Ansicht) der gleiche ist, wie die beiden "FormularNavigatoren AB" (von Formular A) und "FormularNavigator BA" (von Formular Form B) unten.
• Für ein leichteres Verständnis kann die Taste "FormularNavigator AB" mit "Formular B" gekennzeichnet werden und die beiden Tasten (FormularNavigator BA und FormularNavigator BC) auf dem Formular B können mit "Formular A" und "Formular C" gekennzeichnet werden, da sie die nächsten zugreifbaren Formulare auf dem derzeitigen Formular darstellen.
• Der FormularNavigator muss nicht grafisch dargestellt werden; er kann einfach als Ecke zwischen den beiden Formularen dargestellt werden.

Diagramm: Eine UI-Darstellung des Arbeitsflusses, seiner Formulare und des FormularNavigators (an den Ecken)
Hinweis: Es besteht die Absicht, die UI nicht zu zeigen, jedoch das Konzept hinter der UI. Der FormularNavigator kann nicht in der Arbeitsfluss-UI erscheinen, oder er kann einen anderen Namen haben.
2.6.2 Arbeitsfluss-Klassen-Diagramm
Hinweis: Der Arbeitsfluss verwendet das Generische Diagramm, definiert im Anhang als ein Modell/Controller
Der Arbeitsfluss kann:

• Durch einen Advance UI Designer entworfen werden
• Vom "Basis-Objekt-Repository-Service" importiert werden [Der "Basis-Objekt-Repository-Service" beinhaltet Arbeitsflüsse und Knoten (wie Window, Window Border, Formular...)] – Oder vom ArbeitsflussService kommen

ArbeitsflussCache
Um schneller zu arbeiten, verwendet die Basis aufgefüllte Formulare eines Arbeitsflusses, ein Arbeitsfluss verfügt über einen ArbeitsflussCache, der entdeckt, ob zukünftig auf das Formular zugegriffen werden kann und wenn ja, dann wird es automatisch gecached. Ansonsten werden alle Objekte auf Null festgelegt, um dem Garbage Collector (GC) zu helfen.
Beachten Sie bitte immer, dass es bei den X vorherigen und nächsten zugreifbaren Knoten eine andere Möglichkeit gibt, um mit der Erstellung und Zerstörung eines Formulars umzugehen.
[∀f, currentForm ∊ Form, dist(f, currentForm)> X => ∀ o ∊ Objekt, o ⊂ f => o = null, f = null].
Oder [∀f, currentForm ∊ Form, dist(f, currentForm) > X => alle die Objekte von f und f sind auf Null eingestellt, um dem GC zu helfen], wo dist(f, currentForm) die absolute Zahl der Knoten definiert, die weitergeleitet werden müssen, damit man von f zur currentFrom gelangt
2.6.3 Arbeitsfluss und Benutzerrollen [Nicht für Version 1.0]
Ein Arbeitsfluss kann verschiedene Benutzertypen (Rollen) involvieren, die den Arbeitsfluss in verschiedenen Phasen verwenden. Zum Beispiel kann ein Chemiker Verbindungen eingeben, ein Prozess kann versuchen, diese zu registrieren und eine QA-Person kann die abgelehnten Verbindungen manuell korrigieren oder nach einer visuellen Überprüfung löschen. VDLBase Split-Komplex Multi-Benutzer-Arbeitsflüsse so viele wie "einfache einzelne Benutzer-Arbeitsflüsse":

Hinweis: Das gelbe Gebiet wurde Chemikern der Abt. A zugewiesen (spezifische Rolle) und das rosa Gebiet ist für die QA-Abteilung. (Eine weitere spezifische Rolle)

Einschränkungen:
Die "einfachen, einzelnen Benutzer-Arbeitsflüsse" laufen sequenziell, viele Benutzer können einen Arbeitsfluss verwenden, aber nur jeweils ein Benutzer kann einen bestimmten ArbeitsflussThread verwenden. Wenn ein Unternehmen komplexere Arbeitsflüsse hat, die sie nicht in einen Arbeitsfluss vereinigen möchten (zum Beispiel, weil sie parallel arbeiten müssen), dann muss der Benutzer mehrere Anwendungen verwenden.
Abhängige Arbeitsflüsse werden über externe Vorbedingungen synchronisiert, die in einem "Tupel-Raum" fortbestanden. Hochgradiges Benutzerfalldiagramm für Arbeitsfluss
Basis zieht HTML als eine einzelne Seite zur Wiedergabe in Betracht. Der Mechanismus zum Weiterleiten von Objekten von/zu einer HTML-Seite wird in den Spezifikationen bereitgestellt. Hochgradiges Benutzerfalldiagramm für Arbeitsflussauswahl
2.6.4 Abeitsfluss-Persistenz
VDLClientAnwendung muss in der Lage sein, das Folgende fortzubestehen

• Nicht aufgefüllter Arbeitsfluss
• Ein aufgefüllter Arbeitsfluss (schneller Exit)

Ein XML-Format kann verwendet werden.
2.7 On Demand-Status: Formularstatus, Anwendungsstatus und Frameworkstatus
Discovery Desktop stellt mehrere Statusschichten zum Austausch von Daten bereit, die dem zulässigen Bereich folgen.
Auf Code-Ebene wird die Verbindung verwendet, um Daten über Komponenten hinweg auszutauschen. Dies funktioniert gut, gestattet aber nicht den automatischen und asynchronen Datenaustausch (zum Beispiel eine Komponente speichert Daten irgendwo, damit eine andere Komponente diese Daten bei Bedarf wiederverwenden kann, dieser Mechanismus kann im Inneren der Teile-Technologie über einen Puffermechanismus ausgeführt werden, scheint aber flexibler zu sein, wenn der Puffer von einem Detach-Objekt vom Teile-Mechanismus gehandhabt wird, dieses Detach-Objekt wird sein eigenes Puffer-Teil oder Statusteil sein) Somit benötigt die Basis eine höheren Abstraktebene, um die Daten am Leben zu halten für den Austausch zwischen Formularen, Anwendungen und Frameworks (Zum Beispiel eine Anwendung X\Formular Y möchte einige Objekte zu einer Anwendung Z weiterleiten, die von einem Benutzer ausgewählt wurde) Es gibt 3 verschiedene Statusobjekte für den Austausch von Daten im Inneren des Frameworks, die Wahl des Statusobjekts hängt vom zulässigen Bereich der Komponenten ab, die die Daten gemeinsam benutzen werden. Für den Austausch von Daten, übergreifend:

• Zwei Formulare: der FormularNavigatorStatus
• Alle die Formulare einer Anwendung: der ArbeitsflussStatus
• Alle die Anwendungen: der FrameworkStatus (Eine Anwendung kann auf einer lokalen oder Remote-Maschine sein)

Hinweise:

• Diese 3 Statusobjekte werden die gleiche Schnittstellen verwenden.
• Der Austausch von Daten über Benutzer hinweg erfolgt über den Nachrichtenmechanismus, der vorher beschrieben wurde.
• Der FormularNavigatorStatus und der ArbeitsflussStatus werden einfache Hash-Tabellen sein, während der FrameworkStatus ein intelligenter "Tupel-Raum" sein wird, der lokale/versus Server-Tupel-Verwendung optimiert (es gibt viele verfügbare Durchführungen von "Tupel-Raum": Ruple ist zum Beispiel eine XML-Raum-Implementation)

Zum Beispiel weiß der "ACD Arbeitsfluss über "DB" DB2 und RS in diesem Beispiel. "DB2" und "RS" sind bei allen Anwendungen bekannt. In diesem Beispiel kann der Reagent Selector auf DB2 und RS zugreifen, er kennt aber nicht DB (Reagent Selector befindet sich nicht unbedingt auf dem gleichen Computer).
Das rote Rechteck stellt den FrameworkStatus dar, das grüne Rechteck stellt den ArbeitsflussStatus dar.

Hinweis: In der Zukunft kann der FrameworkStatus erweitert werden, um den Datenaustausch der Benutzer zu unterstützen.

2.8 VDLClientUIAnwendung
Lassen Sie uns zu einem bestimmten Typ der VDLClientAnwendung zurückgehen, die sich auf die UI spezialisiert, die VDLClientUIAnwendung. Dies ist wahrscheinlich die interessanteste, dahingehend, dass es die VDLClientAnwendung ist, die als Rückgrat für VDLBase verwendet wird.
Wie gesehen, kennt das VDLClientFramework über viele VDLClientAnwendung und einige von ihnen sind VDLClientUIAnwendungen. Die VDLClientUIAnwendung verfügt auch über einen ArbeitsflussThread, der mit mehreren Formularen umgeht, die von VDLClientKomponenten zusammengestellt sind.

Definition: Ein Formular kann ein großes Trickfenster sein, erstellt in einem Formularaufbauer und angezeigt in der UI. Ein Formular kann fortbestehen.

2.8.1 Wysiwyg-Klassen-Diagram: Formulare, Menüs, Toolbars, etc...
Die Objektstruktur stellt dar:

• Das WYSIWYG (What You See Is What You Get = Was Sie sehen, ist was Sie bekommen)
• Die Objektabhängigkeiten
• Eine kohärente Teilung des Anwendungsbildschirms in kleinere handhabbare Gebiete (Zonen).

Die Objektstruktur wird gestatten:

• Eine schnelle Umgestaltung der Zone, die von Interesse ist
• Eine leichte Möglichkeit der Referenzierung von Objekten vom Memory, aber auch von den Konfigurationsdateien.

2.8.2 Objektdiagramm von Basis-Wysiwyg
2.8.3 Die Grammatik der Konfigurationsdateien
Aus Wiederverwendungszwecken gibt es vier Hauptkonfigurationsdateien, die eine komplette Ausführungsanwendung beschreibt.

• Base.xml (Beschreibung des Frameworks)
• Application.xml (Beschreibung einer bestimmten Anwendung)
• Workflow.xml (Beschreibung eines Arbeitsflusses für eine oder mehrere Anwendungen)
• Form.xml (Beschreibung eines Formulars eines oder mehrerer Arbeitsflüsse)

Hinweis:

• Application.xml und Workflow.xml können vereinigt werden. Falls der Zusammenschluss erfolgt, wird der negative Punkt die Wiederverwendbarkeit des Arbeitsflusses im Inneren der Application.xml sein.
• Diese 4 Dateien sind Konfigurationsdateien; es ist angemessen, einen automatischen XML←→Objektdatenbinder zu verwenden, um diese Objekte als XML-Dateien fortbestehen zu lassen. Datenbindungswerkzeuge (Objekt, XML) vereinfachen den Entwicklungs- und Wartungszyklus wesentlich, im Vergleich des direkten Zugriffs auf den DOM.

2.8.3.1 Base.xml-Datei

• Schema
• DTD (Hinweis: DTD ist nicht leistungsstark genug, um klar alles zum Ausdruck zu bringen)

Hinweis:

• Basis\Startup\Komponenten-Referenz\Name: Ein Benutzer wird immer die gleiche VDL Kern-Schnittstelle für sein VDLBase Framework konfigurieren, die auf verschiedenen Maschinen läuft.

Hinweis:

• Wenn es keine Anordnungsfälle (XML) von Anwendungen gibt, wird die Standard-Anwendungs-Inbetriebnahme in dieser Datei angegeben und in einer Anwendungsdatei definiert (Zum Beispiel, zwei Standard-Inbetriebnahmeanwendungen können eine Login-Seite sein, gefolgt von der Basisanwendung. Inbetriebnahme-Komponenten können zur Kern-Schnittstelle QA, Kern-Schnittstelle Dev und Kern-Schnittstellen-Produktionsfällen verbunden werden). (Es besteht der Bedarf, über das gleiche Login/Passwort oder eine Master-Kern-Schnittstelle zu verfügen, die in ihrer Wallet das unterschiedliche Login/Passwort für den transparenten Zugriff auf die unterschiedlichen Kern-Schnittstellen haben)
• Hinzufügen eines Shortcut-Elements mit den folgenden Attributen: aktiv (z.B. Aktivieren/Deaktivieren), Tastatur Shortcut (z.B. Ctrl+V), System Aktions-ID (z.B. SYSTEM.COPY_ID). Der Tooltip befindet sich im Inneren des Shortcut-Mechanismus', wo .COPY_ID definiert wird.
• Die Standard-KernSchnittstellen-Lokalisierung kann im Inneren einer der Komponenten definiert und im Inbetriebnahme-Element referenziert werden.
• Ein Name-Wert-Paar Eigenschaftenelement wird der Base.xml hinzugefügt, um zu beantworten, wie viele Eigenschaften vom Admin gefordert werden, wie: – "Inaktivitätszeit vor Logout" – "Standard Homepage" – "Standard lokale Einstellungen" – "Standardbrowserformular pro Datenquelle" {dies kann auch innerhalb des Komponentenelements der XML-Datei definiert werden} – Objekt/Anwendungsname zugehörig zu Hop Across – Serverort – Lokale Verzeichnisse – Kundenunterstützungs-Link.

2.8.3.2 Application.xml-Datei

• Schema
• DTD

Hinweis: Es gibt andere Wege, um mit Referenzen mit mehr Grammatik umzugehen:

1. Eine Möglichkeit besteht darin, ein generisches Referenzobjekt in Betracht zu ziehen, das über alle Attribute verfugen kann
2. Eine andere Möglichkeit besteht im Ersetzen der Referenz mit allen seinen Attributen (Dock, Aktivieren, Titel, sichtbar, etc...) durch eine spezialisiertere Referenz (zum Beispiel ToolbarReferenz, MenüleistenReferenz, etc... in diesem Fall werden die Attribute mehr spezialisiert)
3. Eine weitere Möglichkeit kann durch die Wiederverwendung des gleichen XML-Elements bestehen, wie das, welches das Objekt erstellte und die Festlegung des gleichen Namens. In diesem Fall gibt es nur eine Grammatik zu warten (zum Beispiel kann es von einer base.xml haben: <Toolbar name = "Base\MainToolbar" visible = "true" enable = "true" .../> und von einer application.xml kann es haben: <Toolbar name = "Base\MainToolbar" enable = "false" .../>. Das bedeutet, wenn das Basis-Framework diese Anwendung anzeigt, wird die Werkzeugleiste mit dem Namen "Base/MainToolbar" deaktiviert (grau), wenn der Benutzer diese Anwendung für eine andere verlässt, wird die Werkzeugleiste mit dem Namen "Base\MainToolbar" sichtbar)
4. Eine andere Möglichkeit besteht darin, ein Verfahren und ein Wertattribut in der Referenz zu haben, sodass Sie Dinge haben können, wie <Reference name ="Base\MainToolbar" method = "visible" value = "true" .../>

2.8.3.3 Workflow.xml-Datei

• Schema
• DTD

Ein Arbeitsfluss kann andere Arbeitsflüsse beinhalten; sie formen im Prinzip einen größeren Arbeitsfluss.
Ein Arbeitsfluss verfügt über viele Knoten, die entweder 1) ein Formular oder 2) ein Arbeitsfluss (innerer Arbeitsfluss) sein können. Dies wird über das URL-Attribut des Knotens erreicht. Ein Knoten hat einen Typ, der entweder START, ENDE oder NORMAL (Standard) sein kann. START und ENDE stellen den typischen Grundstatus eines Arbeitsflusses dar und NORMAL stellt dar, was immer der Benutzer möchte. Das bedeutet, dass wenn eine Knote eine Transition zum inneren Arbeitsfluss hat, der Arbeitsfluss mit dem START des inneren Arbeitsflusses verknüpft ist.
Transition verfügt über einige Attribute, wie von, zu, Bedingung und Handlung. Alle Bedingungs- und Handlungsattribute sind Callback, entweder .NET-Klasse oder Scripting.

Hinweis: In dieser Grammatik erfolgt die Referenzierung auf verschiedene Weise und in der Application.xml. In Wirklichkeit wird es über Dateien hinweg konsistent sein, dies wird hier getan, um zu zeigen, dass es verschiedene Möglichkeiten gibt, das Gleiche zu tun.

Beispiel des Arbeitsflusses:
Das Ziel dieser einfachen Anwendung ist, zwei Hauptformulare, Abfrage- und Durchsuch- und eine Einkaufswagen-Fähigkeit zu haben. Dieser Arbeitsfluss integriert einen bestehenden Einkaufswagen-Arbeitsfluss.
2.8.3.4 Form.xml-Datei
Schema

• DTD

Hinweis: Folgendes muss hinzugefügt werden:

• FormularPrivileg-Attribute zu FormXML (Domain: NO_MODIFICATION_ALLOWED, ADD_OBJECTS-AND_CHANGE_PROPERTIES, FULL_MODIFICATION)

Es wird eine weitere Konfigurationsdatei benötigt. Die, die spezifiziert, wie Tags in der Form.xml-Datei auf tatsächliche Objekte/Attribute abgebildet werden. Die DAF nimmt eine Art von konfigurierbarer Objektfabrik an, die Beschreibungen von Form.xml anhängt und Objekte (Steuerungen) baut. Wenn dies konfigurierbar ist (über eine Konfigurationsdatei), dann können die Endbenutzer kundenspezifisches Mapping erstellen. Sie können sagen, dass zum Beispiel, StructureQuerylet meine kundenspezifische MyCorpStructureQuerylet und nicht die Standard-VDLStructureQuerylet sein soll.
Eine andere Lösung kann sein, ein automatisches Datenbindungswerkzeug zu verwenden
2.8.3.5 Referenzen
Wie Sie in den Grammatikdateien sahen, können Application.xml, Workflow.xml und Form.xml einige Referenzen haben.
Eine Referenz kann ein Link (durch Namen) zu einem Objekt in der Hierarchie sein. Die Hierarchie setzt sich zusammen aus Basis/Anwendung/Arbeitsfluss/Formular.
Objekt kann nur eine Referenz durch eine niedrigere Ebene sein.
Nachdem ein Objekt von einer Ebene durch eine niedrigere Ebene referenziert wird, werden die Referenzattribute (der unteren Ebene) die Attribute des Objektes ändern. Nachdem sich die Ebene ändert, kehren die Attribute in ihren initialen Status zurück.
Zum Beispiel kann ich ein Formular haben, das eine Werkzeugleiste von der Basis während des Zeitraums deaktiviert, indem das Formular angezeigt wird.
Die Base.xml sieht so aus
Die FormCompLoc.xml kann so aussehen
Nachdem sich das Formular der Anwendung ändert, kann die Basis\Hauptwerkzeugleiste automatisch in ihren initialen Status zurückkehren (aktivieren = "wahr" sichtbar = "wahr").
Wenn Sie während der gesamten Anwendung eine Deaktivierung der Leiste möchten, dann muss die Referenz bei der Application.xml, statt bei der Form.xml erfolgen.
Die ApplicationCompLoc.xml kann so aussehen
Referenzobjekt regelt:

• Sie können nur ein benanntes Objekt referenzieren
• Sie können Objekte zu referenzierten Objekten hinzufügen, können aber ein Child eines referenzierten Objektes nicht entfernen. Aber Sie können die Eigenschaft eines Objektes modifizieren (Zum Beispiel toolbar.enable = false, toolbar.visible = false)
• Wenn ein Formular oder eine Anwendung ein Objekt referenziert, das nicht besteht (falscher Name), dann wird eine Fehlermeldung erzeugt und die Children der Referenz werden nicht hinzugefügt.
• Es wird vorgeschlagen, eine Minimum-Benennungs-Konvention für Basisobjekte und alle VDL Anwendungen zu verwenden, die die Minimum-Basisdatei verwenden (und der Erweiterung widerstehen) Eine Basis Konfigurationsdatei (XML-Datei) wird bei der Instanziierung von VDLBase geladen und kann während der Session nicht geändert werden.

2.8.4 VDLBase URL-Format
VDLBase verfügt über eine Adressleiste, die zwei unterschiedliche Arten von URLs akzeptiert:

1. Klassisches Format, das vom Browser verwendet wird (Datei:// oder http://...)
2. Spezialisierte, wie "VDLbase://<base>/<application>/<form>" oder "VDLbasea://<VDL Core Interface servername>/<base>/<application>/<form>"

In diesem zweiten Format gibt <base> die Verwendung von base.xml an, die <application> spezifiziert, welche application.xml zu verwenden ist und die <form> gibt ab, welche form.xml zu verwenden ist.
Zum Beispiel:

• VDLbase://LorealBase/RegeantSelector/query_sfruct
• VDLbase://BaseY/CompoundLocator/report
• VDLbase://VDL Core InterfaceQA/CompLoc/home

2.9 Teile und Verbindungen
2.9.1 Hintergrund zu Teilen
Ein Teil (VDLClientKomponente) ist eine schwarze Box, die Funktionalitäten über seine Input- und Output-Pins
exponiert. Es gibt 2 Arten von Teilen, a) der primitive Teiltyp, b) das zusammengesetzte Teil ( das
zusammengesetzte Teil besteht aus Teilen (primitiv und/oder zusammengesetzt)).
Teile lösen das Problem des Abstrahierens der Komplexität im Inneren der Komponenten durch Exponieren eines Untersets von internen Pins. Teile können zusammengesteckt und wieder und wieder verwendet werden.
Teile haben unterschiedliche Rollen und Namen. VDLBase nennt sie:

• Steuerung auf der UI-Ebene (oder Ansichts-/Präsentationsebene)
• Teil auf der Modell-/Controller-Ebene (manchmal sind sie nur Modell/Controller Wrapper)
• Trickfenster stellt eine Kupplung der Steuerung und des Teils dar

Hinweis: TechCom nannte das Teil durch VDLClientKomponente um.

Verbindung: Unter der Haube
Das folgende Diagramm gibt ein Gefühl der Beziehung zwischen der UI-Verbindung und den BL-Komponenten (Business Logik). Der Pfeil zeigt, wo die Objekte in beiden Welten sind. Das Ziel ist, beide Welten zu trennen, sodass das UI umgeschrieben oder modifiziert werden kann, ohne die Business-Logik-Welt zu brechen. Die Verbindung wird das Objekt auf der Business-Logik-Welt entsprechend der UI-Verbindung verbinden. Aus Gründen der Vereinfachung sind nicht alle Objekte hier präsent (Status, Navigator...). (Die Farben des großen Pfeils haben keine besondere Bedeutung).
2.9.2 Unterschiedliche Verbindungsgrammatiken
Dieses Kapitel ist eine Diskussion über verschiedene Arten der Darstellung von Komponenten, Verbindungen und wie sich Komponenten aufeinander beziehen. Szenario:
1. Erster Schritt, der Benutzer erstellt die UI:
2.a. Zweiter Schritt, der Benutzer verbindet die UI:
2.b. Als Alternative für den 2. Schritt, der Benutzer verbindet die UI:
In dieser Alternative wird das DAF das Hauptobjekt und die Datenquelle wird einfach eine Verbindung. Diese Methode erscheint günstiger zu sein, da sie es gestattet, dass viele Abfragen und Ergebnissets von der gleichen Verbindung gebaut werden.
2.c. Als eine weitere Alternative für den 2. Schritt verbindet der Benutzer die UI:
In dieser Alternative wird das RS das Hauptobjekt und die Datenquelle wird einfach eine Verbindung. Diese Methode ermöglicht auch, dass so viele Abfragen und Ergebnissets von der gleichen Verbindung leicht gebaut werden können. Diese Methode ermöglicht dem Benutzer, eine Abfrage mit einer unterschiedlichen Datenquellverbindung wieder zu verwenden. In anderen Worten gestattet diese Verbindungsmethode dem Benutzer klar anzugeben, wie ein RS erzeugt wurde. Der Benutzer kann leicht ein anderes RS hinzufügen und es in eine beliebige Datenquellverbindung und/oder Abfrage stecken (der Benutzer kann die bestehende Datenquellverbindung und/oder Abfrage wieder verwenden).
Hinweis:
Die Suchtaste Ereignis kann entweder zum DAF oder zum RS gehen, jedoch nicht zum DS zum Aktivieren vieler DS und unterschiedlicher RS pro DS. Eine feinere Steuerung kann durch das Mapping der Suchtaste zum RS, statt zur Abfrage DAF erreicht werden.
1. Im dritten Schritt navigiert der Benutzer von der Abfrage zum Browse-Formular und baut es

Hinweis: Es wird ein Symbol erscheinen, das besagt "Gehe zurück zum Arbeitsfluss" (wie ein negatives Vergrößerungsglas
] dann können Sie auf den Arbeitsfluss-Knoten "Browsen-Formular" doppelklicken.

Wenn der Benutzer im Browsen-Formulars ankommt, werden beide FormularNavigatoren bei dem Objekt vorhanden sein, das Sie im Inneren abgelegt haben. Der ArbeitsflussStatus ist auch bei dem Objekt vorhanden, das Sie im Inneren abgelegt haben (RS in unserem Beispiel) und ist während des gesamten Arbeitsflussbereichs (DB-Verbindung in unserem Beispiel) sichtbar.
2. Vierter Schritt, der Benutzer verbindet das Browsen-Formular
Natürlich sind alle diese Schritte nicht festgeschrieben und können über unterschiedliche logische Wege erfolgen (wie, 2 Komponenten hinzufügen, sie verbinden, eine weitere Komponente hinzufügen, sie verbinden, hinzufügen, Feld auf Tabelle konfigurieren, hinzufügen... zum Beispiel)

Hinweis: Es wird ein Schaltsymbol geben, um das Formular mit und ohne Verbindungen zu sehen. Das Symbol kann 4 Schalt-Stadien haben (keine Verbindung, nur Ereignisverbindungen, nur Datenverbindungen, alle Verbindungen)

3.a. Ein alternativer Schritt kann sein:
Alles vom Datensatz-Navigator Eine andere Alternative kann etwas sein wie dies (a la Obiekt-Bibliothek)
Hinweise:

• Das Wichtige ist nicht, wie die Verbindung besteht, aber die Logik dahinter durch die Respektierung des Verbindungstyps (gleich, nächster, Parent von). Die intelligente Verbindungstechnologie (BENUTZER SCHNITTSTELLEN-VERBINDUNG) wird die Arbeit beim korrekten Verbinden der nicht-UI Komponentenwelt ausführen.
• "nächstes" kann auch als "gleiches" mit einer "1" ausgeführt werden. "nächstes -> nächstes" als ein "gleiches 2" (gleiches mit einer 2 Zahl auf dem blauen Rohr)
• "gleich" kann auch als "nächstes" mit einer "0" ausgeführt werden.
• Es ist wichtig, die vielen wichtigen Informationen zu sehen, ohne dass 3 Mausklicks ausgeführt werden müssen, um auf eine Eigenschaft zuzugreifen

Hintergrund zu Rohren und Verbindungen
Die Industrie tendiert in die Richtung zu gehen, wo mehr Arbeit durch den Chemiker/Biologen und weniger durch die IT-Abteilung durchzuführen ist. Dies bedeutet, dass "Visuelle Programmierung" einen guten und schrittweisen Weg bereitstellen kann, wo Chemiker/Biologen mehr Dinge selbstständig ausführen können, die früher die Involvierung der IT-Abteilung forderten.
Dynamische Konfiguration ermöglicht dem Endbenutzer, die GUI leicht zu entwickeln und anzupassen.
Verbinden befreit den Endbenutzer von der Aufgabe, einen Code für Ereignisnachrichten zu schreiben, was früher die IT-Unterstützung benötigte.
Eine Verbindung kann Ereignisse und/oder Daten über Teile hinweg übertragen. Unsere Kunden kennen sich nicht mit dem Verbindungskonzept aus, es ist aber ein kritisches Konzept für den Umgang mit Ereignissen in einer "visuellen Programmierungsmethode". Verbindungen können Rohre darstellen, da sie eine Obermenge von Rohren sind.
Ein Rohr ist ein Unterset einer Verbindung, wo die Inputs eines Teils Datensets der gleichen Natur sind (wie ein Ergebnisset) und wo die Outputs Untersets oder transformierte Inputs sind. Rohre sind ein Stecker in einer Kette und zeigen den Datenfluss durch unterschiedliche Operatoren (Strukturanzeiger, Textfeldanzeiger (MW)) Rohre scheinen Schwierigkeiten zu haben, Ereignisse darzustellen, deshalb ist es wichtig, das Verbindungskonzept beizubehalten. Rohre werden häufig verwendet und sind unseren Kunden über Produkte wie ObjektBibliothek und Rohrleistungs-Pilot bekannt. Rohre können Farben und Eigenschaften, wie in der ObjektBibliothek haben (Gleich, ParentVon, Nächstes, Ausgewählt...)
Kurzum, ein Rohr ist ein Unterset einer Verbindung. Eine Verbindung kann alles übertragen, während ein Rohr eine spezialisierte Verbindung ist, die sich auf das Übertragen von mehreren Objekten der gleichen Natur konzentriert.
Auf UI-Ebene wird MDL-Basis die Begriffe verwenden:

3. Verbindun gen zum Ausdrücken der Einrichtung, die Ereignisse überträgt (wie Taste drücken oder die meisten der Datenquell-Inputs...)
4. Rohre zum Ausdrücken der Einrichtung, die einen Objektfluss der gleichen Natur überträgt (wie das DAF, das sein ausgewähltes Ergebnisset zu einem anderen DAF überträgt).

Hinweis: eine Komponente kann sowohl über Rohre (die ein Datenset der gleichen Natur übertragen) und Verbindungen (die 0 bis n unterschiedliche Objekte übertragen) für seine Inputs und Outputs verfügen (wie zum Beispiel eine Datenquelle)

2.9.3 Benutzerschnittstelle, Teile und Verbindungen stellen dar: ein Immobilienproblem
Die UI-Repräsentation der Teile (sichtbar oder nicht) und der Verbindungen kann auf verschiedene Möglichkeiten erfolgen:

• "Alle Immobilien zusammen", die Verbindungen und Teile, die im Design-Modus in der gleichen UI-Ansicht sichtbar sind.
• "Getrennte Immobilien", die UI befindet sich in seiner eigenen Ansicht, ohne nicht sichtbare Teile oder Verbindungen. Die Verbindungen und eine schematische Darstellung eines jeden Teils (für sichtbare und nicht sichtbare Teile befinden sich in einer einzigartigen getrennten Ansicht.

Unterschiedliche UI-Architektur und Konzepte:
2.9.3.1 Alle Immobilien zusammen
Die Hauptidee ist dass sich die nicht sichtbaren Komponenten und Verbindungen auf der gleichen Ansicht wie die Benutzerschnittstelle befinden. Das UI stellt den "Verbindungen anzeigen" Schalter bereit, um zwischen AN/AUS der nicht sichtbaren UI-Teile und Verbindungen zu schalten.
2.9.3.2 Getrennte Immobilien
2.9.3.2.1 Getrennte Immobilien – durch eine Schiebeleiste
In dieser Lösung trennt eine Schiebeleiste beide Ansichten, das UI und die Komponenten (mit Verbindungen) benutzen nicht die gleichen Immobilien zusammen.

• Oben auf der Blätterleiste befindet sich eine sichtbare Endbenutzer-UI, dies ist die UI, die der Chemiker sieht und verwendet.
• Unten auf der Schiebeleiste befindet sich die "Komponentenansicht", die die Komponenten und ihre Verbindungen über die gesamte Anwendung hinweg darstellt, dies ist die Ansicht, die der "Adv. UI-Designer" und der Entwickler verwenden wird.

Hinweise:

• Die Komponenten von der "Komponentenansicht" stammen von unterschiedlichen Formularen (in unserem Beispiel stammen die Komponenten vom Browsen-Formular und dem Abfrageformular).
• Nur der Admin, Adv UI-Designer und der Entwickler werden in der Lage sein, die Blätterleiste zu verwenden, der Endbenutzer wird sie gar nicht sehen können.
• Das MVC-Modell ist kritisch für diese Lösung, wenn ein Entwickler ein Objekt wie das DAF von der UI löscht (oben auf der Blätterleiste), sollte die DAF-Komponente (unten auf der Blätterleiste) auch verschwinden und umgekehrt. Wenn eine Komponente ausgewählt wird, muss sein UI-Äquivalent (falls vorhanden) ausgewählt werden und umgekehrt.

Hinweise:

• Jedes Teil der UI (obere Ansicht der Blätterleiste) verfügt über eine Komponentendarstellung in der Komponentenansicht (die untere Ansicht der Bläterleiste). Der Reziproke ist nicht wahr, da manche Komponente nicht über eine UI-Darstellung verfügen.
• Die Blätterleiste kann DnD (Drag and Drop) zum Unteren der Seite sein, so ist nur das UI sichtbar.
• Jede Komponente von der Komponentenansicht verfügt über den gleichen Namen wie sein Spiegel-Trickfenster von der UI-Ansicht. Der Benutzer kann ein beliebiges Trickfenster oder Komponente auswählen und wird die Objekteigenschaften im Eigenschaften-Editor sehen. Das Objekt wird über ein bestimmtes Objekt verfügen, welches es darstellt.
• Wenn ein Objekt aus einer der Ansichten ausgewählt wurde (UI oder Komponentenansicht), wenn sein äquivalentes Objekt in einer anderen Ansicht besteht, wird das Objekt auch in den nicht ausgewählten Ansichten hervorgehoben (MVC).
• Jede UI-Komponente in der Komponentenansicht verfügt über eine Formular-Zubehör-Kennzeichnung, die daran angebracht ist <from name> das ist das Formular, welches das UI-Teil besitzt und anzeigt. (Dies wird in den vorherigen Bildern nicht dargestellt)

2.9.3.2.2 Getrennte Immobilien – durch 2 unterschiedliche Formulare
Im nächsten folgenden Abschnitt verwenden das UI und die Komponenten (mit Verbindungen) nicht die gleiche Immobilie und sie verwenden nicht das gleiche Formular. Ein Ereignis (ein Tasten-Ereignis zum Beispiel) schaltet für den Benutzer zwischen der UI-Ansicht zur Komponenten-Ansicht und umgekehrt um.
In diesem Fall verfügt das MVC-Modell über zwei Ansichten, die am Modell angebracht sind
2.9.4 Verbindungstechnologie
Potentielle Verbindungslösung:

1. "Tiefe Verbindung": Schließt die Verbindung eng zum Kern-Code, der Kern-Cide selbst verwendete Verbindungen
2. "Entkopplungsverbindung": Entkoppelt die Verbindung zwischen dem UI und den Business Logik-Schichten. Wenn eine Verbindung geändert werden muss, bleibt die darunterliegende Verbindung die gleiche.
3. "Lose miteinander verbundene Verbindungen": Entkoppeln der Verbindung zwischen Ui und BL.
Verwenden der Verbindung und des Teils nur auf UI-Ebene, nicht in der BL-Schicht.
4. "Vermittler (mit Verbindungen)": entkoppeln das UI vom BL. Es kann mit n-aire Beziehungen der Komponentenverbindungen umgehen.

Auf API-Ebene der Komponenten wird nur die Verbindungstechnologie verfügbar sein. Die Rohr-Methode erfolgt automatisch durch die intelligente Verbindung, die eine leichteren und überzeugenden Grund für den Entwickler liefert, das MDL-Basis Framework, statt Microsoft Visual Studio und die MDL-Komponenten direkt ohne das Framework zu verwenden.
Zum Beispiel wird auf der API-Ebene die Strukturanzeige die Struktur festlegen, außer bei der UI-Ebene, dort wird möglicherweise Rohr Ein, Rohr Aus vorliegen, das durch das Ergebnisset von 1 oder n Strukturen übertragen kann.
Indem die Rohrtechnologie nur auf UI-Ebene über die intelligente automatische Verbindung bereitgestellt wird, scheint die UI-Verbindungskomplexität zu fallen, wenn der Benutzer Rohre mit unterschiedlichem Verhalten auswählt (ParentVon, Gleich, Nächstes, Ausgewählt)
Unterschiedliche Verbindungsarchitektur:
Dies wird detaillierter die "Tiefe Verbindung", "Entkopplungsverbindung", "Lose miteinander verbundene Verbindung" und "Vermittle" Architektur abdecken
2.9.4.1 Tiefe Verbindung – Ein Teilemodell
In dieser ersten Idee befinden sich die Teile und Verbindungen tief im Kern-Code. Es gibt eine Eins-zu-Eins Beziehung zwischen einer Verbindung auf dem Bildschirm und einer Verbindung auf der Business-Logik-Ebene.
2.9.4.1.1 Teile (Modell/Controller)
2.9.4.2 Entkopplungsverbindung
Das Verbinden auf die gleiche Weise wie im Code ist zu komplex und umfangreich, um in der Benutzerschnittstelle des Endbenutzers dargestellt zu wenden; es kann produktiver sein, die Codekomplexität dem Endbenutzer zu abstrahieren. Es ist auch immer eine gute Übung für die Evolution (sogar noch mehr für ein Framework), die Benutzerschnittstellenebene von der logischen Ebene zu trennen.
In dieser zweiten Idee befinden sich die Teile und Verbindungen immer noch tief im Kern-Code. Es gibt eine Eins-zu-Eins Beziehung zwischen einer Verbindung auf dem Bildschirm und einer Verbindung, die für eine VDLClientUIAnwendung ausgeführt wird. Dies kann theoretisch zu einer N zu 1 Beziehung zwischen den Benutzerschnittstellen-Verbindungen zur Business-Logik-Verbindung werden, die es der UI-Verbindungsgrammatik gestattet, für die Evolution und Versionierung geändert zu werden.
2.9.4.3 Lose miteinander verbundene Verbindungen
In dieser dritten Idee verfügt die UI über Verbindungen und die Business-Logik verfügt nur über typische Hinweise. Es ist auch als Verbindung # und Intelligente Verbindungstechnologie bekannt.
Das Verbinden auf die gleiche Weise, wie es auf Code-Ebene erfolgt ist zu komplex; diese Komplexität kann dem Endbenutzer gut abstrahiert werden. Es ist auch immer eine gute Übung für die Evolution (sogar noch mehr für ein Framework), die Benutzerschnittstellenebene von der logischen Ebene zu trennen.
Die Art, wie die Teile auf der logischen Ebene verbunden sind, macht auf der Schnittstellenebene nicht viel Sinn, hauptsächlich weil das Zielpublikum für diese beiden Ebenen unterschiedliche Zwecke verfolgt. Der Verbindungszweck der Benutzerschnittstelle ist, den leichtesten Weg zu finden, Dinge zu tun und sie so generisch wie möglich zu halten. Das Ziel der logischen Teil-Ebene ist so flexibel wie möglich aus der Sicht der Komponenten zu sein (auch für MS Visual Studio .NET) und so leistungsfähig wie möglich zu sein. Eine Verbindung der Benutzerschnittstelle kann eine oder mehrere Handlungen bei der logischen Teile-Ebene beinhalten.
Die heutige Verbindung auf Benutzerschnittstellen-Ebene ist separat von der Business-Logik-Verbindung involviert. Die Verbindung bei der Benutzerschnittstelle wird schnell involviert, wenn der Benutzer beginnt, mit der Benutzerschnittstelle zu interagieren.
Die Verbindung beim logischen Layer kann erfolgen, ist jedoch überhaupt nicht notwendig. Die Verbindung kann ohne Verbindung und Teile auf dem Business-Logik-Layer hergestellt werden, sondern nur mit Hinweisen. In anderen Worten, die Komponenten können über eine 1:1 oder 1:n Mapping zwischen den UI- und BL-Layers verfügen. Diese Verbindung kann 1) leicht durch die Zeit und Versionen involviert werden (Version 1, Version 2...) , 2) leicht konfiguriert werden, je nach Anwendung, die im Vordergrund läuft, 3) es ist kein Code vom Endbenutzer erforderlich und 4) kann sehr leicht erweitert werden.
Die automatische intelligente Verbindungstechnologie nimmt die Benutzer-UI-Input-Verbindungsereignisse und, einem Regelset folgend, sieht voraus, was die Absicht des Benutzers ist, indem Teile auf die wahrscheinlichste Weise verbunden werden, dem derzeitigen Status der beiden involvierten Teile folgend.

• Die UI-Verbindung geht auch mit implizierten Verbindungen um, die durch die Position des Objekts vorgegeben sind. Zum Beispiel, ein Trickfenster, das auf dem ArbeitsflussStatus sitzt (oder dem FormularNavigator) bedeutet eine Umkonfiguration der Objektstruktur der Abhängigkeiten.
• Die UI-Verbindung stellt die Trennung zwischen der UI-Welt und der zugrunde liegenden Business-Logik dar. Wie Sie sehen können (bei der Business-Logik) kann die zugrunde liegende Verbindung bestehen oder nicht (mit dieser UI-Verbindung [die einfachste Business-Logik-Verbindungsform können einfach nur reelle Hinweise sein, die Komponenten referenzieren, eine andere Durchführung kann eine 1:1 Mapping der UI-Verbindung oder von etwas anderem sein...]. Der Einfachheit halber sollte es nur über eine Verbindungstechnologie verfügen und es sollte nur auf UI-Ebene erfolgen. Die UI-Verbindung wird dort sein und unabhängig den zugrunde liegenden Weg involvieren, wie die Teile miteinander sprechen. Wenn die UI-Verbindung einfach genug ist (und dies kann erfolgen, wenn die BENUTZERSCHNITTSTELLEN-VERBINDUNG verwendet wird), am bevorzugtesten erhalten Endbenutzer (Chemiker, etc...) mit Computerinteresse die Aufgabe des "Adv. UI-Designers".
• In anderen Worten, die UI-Verbindung ist ein Laufzeit visueller Programmierungsübersetzer (oder Dolmetscher). Die UI-Verbindung löst das Komplexitäts- und Detailproblem dahingehend, dass die UI-Verbindung den logischen Layer für den Endbenutzer abstrahiert. [Als Analogie werden Java and C# von C++ inspiriert, das von C inspiriert wurde, das wahrscheinlich von FORTRAN stammt, aber jede dieser Sprachen verfügt über seine eigenen Komplexitätsgrad aber alle können die gleiche Anwendung mit mehr oder weniger der gleichen Codemaschine erzeugen].

Klassendiagramm – Lösung 1
Im folgenden Diagramm verfügt jede Regel über seine eigene Funktion, die ausgeführt wird. Die Funktion activateRule(...) nimmt 2 Komponenten als Argumente, die von Komponente und die zu Komponente. Die von/zu stammen von der Richtung des DnD (Drag and Drop).
Die erste Durchführung der Maschine wird ziemlich rudimentär sein.
Klassendiagramm – Lösung 2
In dieser Lösung wird ein Regelset definiert und ist erweiterbar.
2.9.4.4 Vermittler (statt Verbindungen)
Sowohl Verbindungen als auch Vermittler fördern die lose Kupplung von Komponententypen.
Eine Verbindung stellt einen Datenfluss zwischen zwei Objektfällen dar (eine "Ereignisverbindung" ist tatsächlich eine Art Datenfluss). Eine Verbindungstransaktion wird binär übernommen, mit zwei involvierten Parteien. Zwischen jedem der beiden Fälle kann es mehrere Verbindungen geben.
Ein Vermittler ist zwischen zwei oder mehreren Objektfällen zwischengeschaltet. Transaktionen können binär, trinär oder n-när sein. Zwischen einem vorgegebenen Objektset sollte es nur einen Vermittler geben, der mit mehreren Datenflüssen umgehen kann.
Eine Verbindung hat wenig oder keine "Kenntnis" über die Objekte, die es verbindet. Aber ein Vermittler hat semantisch "Kenntnis" darüber, wie seine Zusammenarbeitsklassen interagieren. Die Person, die den Vermittler schrieb, wusste wahrscheinlich etwas über diese Klassen und deren potentiellen Interaktionen.
Zum Beispiel kann ein Vermittler einige Umwandlungen von den Daten bewirken, wie die Umwandlungen von Einheiten. Ein Vermittler kann auch eine Transaktion über drei oder mehrere Objekte hinweg koordinieren. Diese sind schwer mit Verbindungen zu erreichen, es sei denn, man fügt auch Vermittlungsobjekte zwischen dem Input und dem Output hinzu.
Vermittler bedürfen der Erstellung der Arbeit. Jede vermittelte Interaktion erfordert, dass ein Programmierer versteht, wie die Komponente interagiert, schreibt einen spezifischen Code zu dieser Interaktion und testet den Code. Diese Arbeit schlägt sich jedoch in Vorteile für den Endbenutzer oder für den gelegentlichen wissenschaftlichen Entwickler nieder. Diese Benutzer müssen sich nicht mit den Details der Komponenten-Schnittstellen befassen.
Es sollte angemerkt werden: In dem Umfang, dass Verbindungen automatisch für Interaktionen bestimmter Klassen erzeugt werden, was einen ähnlichen Grad der Anstrengungen der Entwickler in Anspruch nimmt und ähnliche Vorteile für den Benutzer hat.
Vermittler sind wiederverwendbar. Wenn eine Unterklasse erstellt wird, sollte ein Vermittler zu seiner Superklasse ohne Modifikationen arbeiten. Ähnlich, wenn der Vermittler mit einer Schnittstelle, statt mit einer Klasse gekoppelt ist, dann kann jede Klasse, die diese Schnittstelle durchführt, mit diesem Vermittler arbeiten. Vermittler selbst können eine Unterklasse sein, um Funktionalitäten hinzuzufügen oder außer Kraft zu setzen.
Vermittler werden vom Designer-UI entkoppelt. Sie können für die UI unsichtbar sein. Oder sie sind in der UI als Steuerung dargestellt. Oder es kann eine Art vereinfachter "Verbindungs-" Darstellung vorliegen, die die tatsächlichen Interaktionen maskiert. Aber bei den wahren Verbindungen ist das Verbindungsmuster sehr mit dem UI gekoppelt.
Aus diesem Grund sind die Vermittler mehr an die Endbenutzer "angeschlossen", funktionieren als Black Box; Verbindungen sind "offener" für Benutzermodifikationen durch das GUI. Wenn Vermittler jedoch in Skript geschrieben werden, können sie für Benutzer offener sein. Außerdem können die Benutzer die Option haben, einen Vermittler auszuschalten und ihr eigenes Ad Hoc Scripting statt dessen zu verwenden.
2.9.5 Automatische Verbindung
Die meisten Objekte werden automatisch verbunden, wenn der Endbenutzer mit der Benutzer-Schnittstelle interagiert. Der Advanced UI-Designer wird in der Lage sein, die Standardverbindung, erstellt von der VDLBase, zu modifizieren.
2.9.6 Schlussfolgerungen zu Verbindungen, Teilen und Immobilien
Beide Lösungen "Alle Immobilien zusammen" und "Getrennte Immobilien" scheinen zu funktionieren und sind attraktiv.
"Getrennte Immobilien" können verbesserte Immobilien bereitstellen.
Auf der einen Seite erhält der Benutzer bei "Alle Immobilien zusammen" ein besseres Gefühl über die Korrelation zwischen der UI, den Verbindungen und den nicht sichtbaren Teilen. Auf der anderen Seite behält man durch "Getrennte Immobilien" eine Ansicht der vollständigen Verbindung, die leichter zu verstehen und zu handhaben sein kann.
Die Szenarien der "Verbindungsgrammatiken" hängen von den "Immobilien" und der "Verbindungs-" Lösung ab.
Die Trennung der Benutzerschnittstellen-Verbindung und der logischen Komponenten wird unser Leben für die Wiederverwendung unserer Komponenten von .NET vereinfachen.
Steck- oder steckbare Module werden immer noch für die komplexe Entwicklung verwendet.
Wenn die Benutzerschnittstellen-Verbindung gut erfolgte (leistungsstark und einfach), wird sie durch mehr Endbenutzer verwendet werden. Dies wird ein wichtiger Schritt für das Unternehmen und für die Benutzer sein, da die Benutzer nicht länger von den IT-Mitarbeitern abhängig sind, um einfache UI-Verbindungsaufgaben auszuführen (gewisses Training wird zur Verfügung gestellt). Wenn die UI-Verbindung eng zum logischen Layer ist, verschließen Sie die Verbindung für die Evolution und exponieren Sie dem Endbenutzer die Business-Logik-Komponentenkomplexität.
2.10 Vereinheitlichte Feldtabelle
2.10.1 Übersicht
Szenarien:
Ein Admin beginnt, das Discovery Framework zu installieren, das sein Unternehmen gerade gekauft hat. Der Admin konfiguriert seine neuen VDL Kern-Schnittstellen-Datenquellen und importiert auch seine eigene bestehende Datenquelle. Die durch die VDL Kern-Schnittstelle gelieferte Datenquellen kommen mit einer Standard "vereinheitlichten Feldtabelle" (wird für Beilstein nützlich sein). Der Admin kann dies entweder modifizieren oder wie vorgefunden beibehalten.
Nachdem der Admin die bestehenden Datenquellen importiert, um sie zu veröffentlichen, wird er von der Konfigurations-UI aufgefordert anzugeben, was die Feld-Mapping-Beziehungen zwischen der "vereinheitlichten Feldtabelle" und den Datenquellen sind.
Es ist kritisch, dass dieses Werkzeug über die Fähigkeit der Manipulation, Hinzufügens, Entfernen und Verschiebens der "vereinheitlichten Feldtabelle" auf wirklich einfache Weise verfügt. Die UI-Werkzeuge wird per Standard abbilden, was abgebildet werden kann; dies ist durch den Admin modifizierbar.
Nachdem dies erfolgte, können Chemiker, Biologen, fortgeschrittene Formulardesigner und Entwickler die vereinheitlichte Feldtabelle als ein Strukturfeld mit zugreifbaren Eigenschaften für deren Abfrage nach Formular, Querylet und UQL-Aussage verwenden.
Vereinheitlichte Feldtabelle
Die "vereinheitlichte Feldtabelle" wird verwendet, um die Struktur der Felder im Inneren der "Feld" Registerkartensteuerung des Formular-Designs UI zu erzeugen. Die "vereinheitlichte Feldtabelle ist hierarchisch und das einzige, das von 90% der Benutzern verwendet wird. Es wird möglich sein, die direkten Tabellennamen und Spalten statt einer "vereinheitlichten Feldtabelle" zu verwenden, jedoch werden nur Personen mit fortgeschrittenem Datenquellwissen dies für spezifische Felder tun.
Durch das Durchsetzen der "vereinheitlichten Feldtabelle" gelten vereinheitlichte Grundtabellen für alle Chemiker und Biologen der Abteilungen und Teams des Unternehmens. In anderen Worten, es synergiert die Arbeit durch das Auferlegen einer einzigartigen vereinheitlichten Unternehmensfeldtabelle. Die "vereinheitlichte Feldtabelle" kann über Synonyme verfügen. Die "vereinheitlichte Feldtabelle" ist lebendig und wächst, wenn das Unternehmen neue Begriffe aufnimmt. Eines der größten hinzugefügten Werte der "vereinheitlichten Feldtabelle" ist, dass die Formulare geschrieben werden unter Verwendung dieser "vereinheitlichten Feldtabelle", sodass die Formulare von verschiedenen Datenquellen wiederverwendet werden können, da sie die gleiche "vereinheitlichte Feldtabelle" verwenden. Neue Chemiker werden in der Lage sein, die "vereinheitlichten Feldtabelle" anzusehen und zu lernen, wie Dinge in diesem Unternehmen standardisiert werden und wofür die vereinheitlichte Feldtabelle verwendet wird.
Dieses Verzeichnis muss durch einen Admin kundenspezifisch anpassbar sein, damit es dem Gebrauch des kulturellen Chemie- und Biologievokabulars im Unternehmen angepasst werden kann. Es muss auch in der Lage sein, multiple Auswahlen für einen mehrdeutigen Fall vorzuschlagen.
2.10.2 Wie man die "vereinheitlichte Feldtabelle" aktualisiert
Der Admin kann eine neue Datenquelle importieren oder einfach Felder hinzufügen, modifizieren und verschieben. Der Endbenutzer wird auch in der Lage sein, indirekt neue Begriffe dem Admin über den Importmechanismus vorzuschlagen (SD-Datei, RD-Datei...). Wenn ein Benutzer eine Datei importiert und wenn er die Verbindungen registrieren möchte, muss er die "vereinheitlichte Feldtabelle" zu den Feldern registrieren, die in seiner Datei angegeben sind (die gleiche Konfigurations-UI, die der Admin verwendete, um eine neue Datenbank zu veröffentlichen). Das neue Vokabular kann in eine lokale Datei gehen und zu gegebener Zeit wird der Benutzer in der Lage sein, sich auf einige Begriffe festzulegen um sie zu veröffentlichen. Diese gehen zum Admin zur Überprüfung und dann, bei Akzeptierung, gehen sie zur "vereinheitlichten Feldtabelle" (vielleicht wird eine einfache E-Mail in der Version 1.0 ausreichend sein)
2.10.3 Konzeptuelles Klassendiagramm
In der Wirklichkeit ist dies in einer XML-Datei oder in Datenbanktabellen durchführbar. Außerdem können Hinweise etwas unterschiedlich angeordnet werden. Dies kann in ein oder zwei Dateien verteilt werden (eine für die Serverseite der VDL-Basis und die andere kann eine Metadatei für die Datenquelle sein)
Erklärung der Klassen
Die "vereinheitlichte Feldtabelle"

• Sie beinhaltet viele "vereinheitlichte Feldtabellen-Begriffe"

Der "vereinheitlichte Feldtabellen-Begriff" enthält:

1 Einen Vokabular-Feldnamen (zum Beispiel: MW)
2 Einen Human-lesbaren Namen (zum Beispiel: Molekulares Gewicht)
3 Viele Synonyme (zum Beispiel: mweigtht, mw, mol weight, etc...)
4 Viele Datenbank Mapping Begriffe/Felder" (zum Beispiel: Bis.x.y.z.mw, ACD.b.d.f.mwt, etc...), dies können Verknüpfungen zu mehreren DB-Mapping-Dateien sein.
5 Ein Typ: int, float, string, etc... [Sollte auch integrieren – Kardinalität (Skalar versus Reihe), – Einheiten (Standardeinheit, die im Unternehmen verwendet wird) und eine – "Domäne-ID" Referenz (siehe unten)]
6 Viele Handlungen (steckbare Handlungen/Callbacks, zum Beispiel zur Umwandlung von Einheiten von Celsius in Fahrenheit)
7 Muss in der Lage sein, "wissenschaftlich lokal" auszuwählen (wie Metrik, MSI,)
8 Eine einzigartige Begriffsdefinition (lesbarer String)
9 1 Tooltips/Hilfe (lesbarer String)
10 Eine einzigartige ID, die unveränderlich ist und durch die Formulare verwendet wird, um den Begriff zu referenzieren (Die einzigartige ID kann (2) der "Human lesbare Name" + sein hierarchischer Pfad, oder eine Zahl sein. Diese IDs werden für I18N sehr nützlich sein, sie werden gestatten, dass das Verzeichnis in verschiedene Sprachen übersetzt wird. Für internationale Unternehmen wird der Benutzer in der Lage sein, die französische Bürodatenbank durch ein englisches Formular abzufragen (gleiche Verzeichnis-IDs).

Ein "vereinheitliche Feldtabellen-Datenbank-Mapper"
Es beinhaltet viele "vereinheitliche Feldtabellen-Datenbank-Mapper-Begriffe
Der "vereinheitliche Feldtabellen-Datenbank-Mapper-Begriff" beinhaltet:

• Eine Einheit (welche die Einheit ist, in der das reelle Datenbankfeld ausgedrückt wird) + eine Einheits-Funktion (oder Callback) zur Umwandlung zwischen Einheiten.
• Der reelle Datenbankfeldpfad (Beispiel: Bis.x.c.v.b.mweight)
• Eine Referenz zum "vereinheitlichten Feldtabellen-Begriff', den es referenziert

Hinweis:

A Beim "vereinheitlichten Feldtabellen-Begriff können (1) und (2) gleich sein.
B – Das Synonym beinhaltet einige DB-Feldnamen, die als Synonyme hinzugefügt wurden
C kann eine Standard-Mapping-Datei für unsere Datenbanken und Beilstein liefern
D Auf dem Klassendiagramm soll ein vereinheitlichter Feldtabellen-Datenbank-Mapping-Begriff nur einen "vereinheitlichten Feldtabellen-Begriff" abbilden (dies erfolgt, wenn der Admin die neue Datenbank importiert)
E Wenn ein Formular, das über ein vereinheitlichtes Feldtabellenformular verfügt, nicht seinen "vereinheitlichten Feldtabellen-Datenbank-Mapping-Begriff" findet, dann wird das Feld mit einer unterschiedlichen Farbe markiert oder mit grau ausgefüllt.
F Der Begriff von Aliasnamen kann hinzugefügt werden, um dem Benutzer eine Alternative vorzuschlagen, wenn die "vereinheitlichte Feldtabelle" nicht in der Datenbank existiert. Wenn zum Beispiel eine Struktur in der Verbindung\Struktur und in der Katalyse\Struktur und auch in der Reaktion\Struktur durch die "vereinheitlichte Feldtabelle" bekannt ist, dann referenziert der Benutzer auf seinem Formular Verbindung\Struktur von der "vereinheitlichten Feldtabelle", dann kann er einen Rechtsklick auf Alias ausführen und andere Arten von Strukturen sehen, über die die vereinheitlichte Feldtabelle Kenntnis hat (wie Katalyse\Struktur und Reaktion\Struktur als Beispiel)

2.10.4 Beispiel eines Formularinhalts unter Verwendung der "vereinheitlichten Feldtabelle"

<Widget class = structureDisplay.class field = "Structure">...
<Widget class = SingleValue.class field = "Comgound\Molecular Weight">...

2.10.5 Potentielle Durchführung
VDLBase kann eine beliebige Datenquelle konsumieren, die durch die VDL Kern-Schnittstelle exponiert ist. Sie muss jedoch ihr eigenes Set von gebräuchlichen Feldnamen auf die tatsächlichen Datenverzeichnisse überziehen. Aus diesem Grund wird ein spezieller VDLBase Datenquellservice für den Client als Webservice exponiert. Da alle VDLBase Datenbankverbindungen durch diesen Service laufen muss kein anderer VDL Kern-Schnittstellen-Datenquellservice als Webservice exponiert werden.
Die gebräuchlichen Feldnamen selbst und die Informationen, die sie in den Datenbank-Metadaten abbilden, werden durch einen Administrator definiert. Diese Informationen werden in einer Datei oder in einer Datenbank im mittleren Bereich sitzen. Diese Informationen werden während der Laufzeit zu den Metadaten jeder Datenbank hinzugefügt. Der Client wird Metadaten erhalten, wo die gebräuchlichen Namen eingefügt wurden. Es sollte keine spezielle Programmierung für den Client notwendig sein, um mit den gebräuchlichen Namen umzugehen.
Beim Erhalt von Abfragen vom Client, muss der VDLBase Datenquellservice die gebräuchlichen Namen zurück zu den tatsächlichen Datenbankfeldnamen abbilden. Dann, beim Abrufen eines Datensatzes für den Client, werden die gebräuchlichen Namen in den Datensatz eingefügt. Somit sollte der Gebrauch von gebräuchlichen Namen für den Client komplett transparent sein.
Kunden sollten die Option haben, die gebräuchlichen Feldnamen nicht zu verwenden, wenn es für sie eine zu hohe administrative Last darstellt. In diesem Fall handelt der VDLBase Datenquellservice lediglich als "Durchreiche" zu anderen VDL Kern-Schnittstellen-Datenquelldiensten.
Sorgfalt muss gewaltet werden, um die Name-Mapping Operationen effizient durchzuführen. Zum Beispiel kann der Service die manipulierten Metdadaten cachen, um sie wieder zu verwenden.
Abbildung 1 Datenfluss gebräuchlicher Feldnamen-Service
2.10.6 Verzeichnis: Vokabular für Feld-Wert
Die Metadaten verfügen über

• Domäne-ID: es wird Bezug nehmen auf ein Objekt, welches kennt: – Den potentiellen Wert, der für diesen Begriff genommen werden kann – Deren Beschränkungen – Ob es ein Wipe out-Feld ist – Ob es fest/frei oder fest ist, aber erweitert werden kann (Zum Beispiel wird molekulares Gewicht das Doppelte nehmen, Wert > 0. Ein weiteres Beispiel: Toxität könnte nur mild toxisch und karzinogen nehmen und kann nicht fest sein, sodass der Benutzer neue Begriffe anhängen kann oder es kann fest sein und dann muss der Benutzer den Admin bitten, einen neuen Begriff hinzuzufügen)

2.10.8 Aggregation der Datenquelle (Version 2.0)Admin-Tools zum Erzeugen des Konnektors für füs (Version 1.0)

• Für Aggregierung DS (Version 2.0)
• Planen erweiterter Kurse für IDS und aggregiertes DS für das Team (John)

2.11 VDLBase Framework und Microsoft Visual Studio .NET

1. Microsoft Visual Studio ist mehr eine Entwicklungsumgebung für den Bau der Anwendung als ein interaktives Laufzeit-Framework, wie VDLBase
2. VDLBase bietet genügend attraktive Funktionalitäten durch das VDLBase Framework (wie eine leichte Integration, Nachrichten senden Hop-Across... ) welches die Arbeit erleichtert, statt diese Fähigkeiten von Beginn an unter dem Microsoft Visual Studio umzuschreiben
3. VDLBase bietet ein begrenztes Set an gut definierten Komponenten beim Microsoft Visual Studio .NET IDE (wie die Objekt-Bibliothek), diese Komponenten sind ein Struktureditor (Neues Zeichnen), Ein Formularabbilder, ein Datenbankzugriff.
4. VDLBase funktionieren auf beiden Seiten gut, indem die Entwicklung unter dem Microsoft Visual Studio gestattet und unter VDLBase Laufzeit-Framework ausgeführt wird
5. VDLBase wird einige seiner Funktionalitäten auf attraktivere Weise für das VDLBase Framework, statt für das Microsoft Visual Studio .NET IDE anbieten. Zum Beispiel wird VDLBase die Teile-Technologie beiden Lösungen, VDLBase und MVS anbieten. Beide werden die gleiche exponierte Teile-API verwenden, aber die UI-Verbindung wird nur durch das VDLBase Framework zugreifbar sein. Die gleichen Funktionalitäten werden durch das MVS angeboten, aber in einer primitiveren Form, wo der Benutzer mit dem Code umgehen muss oder wo eine indirekte Verbindungs-ID erforderlich ist, wie es von der Objekt-Bibliothek vorgenommen wird.
6. VDLBase ist von einer MVS-Anwendung aus aufrufbar.

3 VDLBase
3.1 VDLBase Aktivitätsdiagramm
3.1 VDLBase Konfigurationsdateien
VDLBase ist VDLClientUIAnwendung WYSIWYG konfiguriert auf bestimmte Weise Base Application XML:
Application XML:
Form XML:
3.3 VDLBase Kommunikationsprotokoll
3.4 Registrierung [Version 2.0]
3.4.1 Übersichts
Der VDLBase Registrierungsservice wird für alle neuen Registrierungen von Verbindungen, Reaktionsregistrierungen und Aktualisierungen von bestehenden Einträgen verwendet. Immer wenn Daten in einer Datenbank geändert werden, muss dies durch den Registrierungsservice erfolgen.
Im Grunde erfolgt die Registrierung in einigen wenigen Schritten, 1) lesen Sie die Datei und erhalten Sie ein Ergebnisset davon (die Datensätze können sich auf einer temporären Tabelle auf dem Server befinden), 2) Registrieren Sie die Daten des Ergebnissets auf der Zieldatenbank. Schritt zwei verfügt über 3 Optionen: 2.a) Eintrag für Eintrag, 2.b) der komplette Datensatz, 2.c) Unterset des Datensatzes.
3.4.1.1 Gebräuchliche Operationen während der Registrierung:

– Einfügen (neue Einträge) • Batch (SD-Datei, etc... ) • Interaktiv • Hybrid
– Aktualisieren (Eintrag ändern) und erweitern
– Löschen (Entfernen eines bestehenden Eintrags)
– Einträge archivieren

Alle diese Operationen treffen auf Einträge und Untereinträge zu, zum Beispiel, wenn eine Datenbank dafür ausgelegt ist, kann ich eine neue Maßeinheit für das molekulare Gewicht zu einem bestehenden Untereintrag zum molekularen Gewicht hinzufügen.
3.4.1.2 Registrierungsart

1. Jeweils eine Verbindung
2. Reihe von Verbindungen

Die meisten Registrierungsformulare scheinen mit 'jeweils einer Verbindung' umzugehen, außer auf spezialisierten Gebieten, wie CombiChem, wo Verbindungsreihen verwendet werden.
3.4.1.3 Formulare für das Bearbeiten eines Datensatzes (Datensätze)
Das Registrierungsformular für jeweils eine Verbindung' zeigt die meisten seiner Informationen auf einer Seite an (ohne Schiebeleiste, alles ist auf einem Bildschirm sichtbar). Die Daten werden im Allgemeinen auf verschiedene Registerkarten-Steuerungen verteilt, wenn es zu viele Informationen gibt, die auf einer Seite angezeigt werden sollen.
Die erste Methode verwendet einen Formularerzeuger. Dieser Formularerzeuger wird optional als Input verwenden: ein Vorlageformular und/oder eine Abfrage. Ein heuristischer Algorithmus wird sein Bestes tun, um das Formular zu definieren. Dann kann das Formular wie vorliegend verwendet werden oder kann durch die Benutzer (oder einen Admin) modifiziert werden, damit es deren spezifische Bedürfnisse erfüllt.
Eine zweite Methode besteht in der Wiederverwendung eines Durchsuchungsformulars als ein Registrierungsformular. Die Idee stammt von dem Fakt, dass ein Benutzer gewöhnlich nach einer bestimmten Verbindung sucht, um das Formular für die Registrierung wiederzuverwenden.
In dieser Sekunde des "Registrierungsmodus", wird dem Formular hinzugefügt:

– Eine Register-Taste (oder Update)
– Eine Widerruf-Fähigkeit (einmal geklickt, versetzt es die Verbindung in ihren Originalzustand, diese Fähigkeit besteht von dem Moment an, wo der Benutzer beginnt, die Verbindung zu modifizieren bis zu dem Moment, wenn der Benutzer auf die Register-Taste klickt. Sie steht nicht zur Verfügung, nachdem die Register-Taste betätigt wurde (Version 1.0). Diese Widerruf-Taste ist die Hauptsächliche, die außerhalb des Frameworks angeboten wird)
– Neue bearbeitbare modale Trickfenster statt der Daten

Das bedeutet, dass es möglich sein muss, die vereinheitlichte Feldtabelle zu fragen (oder einen Unterservice der vereinheitlichten Feldtabelle), was die entsprechenden Trickfenster sind für die Verwendung 1) Anzeige eines Wertes mit seinen Einheiten im Browse-Modus, 2) Abfrage eines Wertes in einem QbF oder QbQ und 3) Registrierung eines Wertes. In anderen Wirten werden Daten durch unterschiedliche Trickfenster nach ihrem Modus (Browse, Abfrage, Registrierung) angezeigt. [Regelbasierend].
Zum Beispiel kann die "Toxität" dargestellt werden durch 1) ein Textfeld im Browse-Modus, 2) eine Kombi-Box im Abfrage-Modus und 3) einen Drop-Down im Registrierungs-Modus.
Der Schalt-Modus in Browsen (mit dem Browse-Trickfenster) zum Registrierungs-Modus (mit dem Registrierungs-Trickfenster) erscheint, sobald der Benutzer auf ein Feld doppelklickt. Nach der Bearbeitung verbleibt das Feld in rot, bis die Taste 'Update' (oder Registrieren) gedrückt wird, dann wird das Feld wieder schwarz.
Von der Architektur her sind die Feldanzeigen des Formulars Referenzen (IDs) zu den vereinheitlichten Feldtabellen-Feldern, diese Referenzen werden höchstwahrscheinlich der Strukturpfadname, gefolgt von einem einzigartigen Namen für diesen Zweig der Struktur sein, wie .\compound\molecular weight Bei der Registrierung werden die Regeln für die Aktualisierung der VEREINHEITLICHTEN FELDTABELLE mit neuen Informationen immer noch an der gleichen Stelle sitzen.
3.4.1.4 Datenscripts (oder Datenhandlungen)
Ein Benutzer muss in der Lage sein, den Wert eines Feldes zu einem Skript oder zu einem Callback zu verknüpfen, womit unterschiedliche Daten erhalten und neue Daten erzeugt werden, die Teil des Verbindungsformulars sein und mit ihnen registriert werden.
3.4.1.5 Registrierung: Jeweils eine Verbindung
Die vereinheitliche Feldtabelle muss eine Möglichkeit haben anzugeben, was die Felder sind, die nicht benötigt werden (oder nicht verwendet werden) bei der Registrierung der nächsten Verbindung.
Anforderungen an die vereinheitlichte Feldtabelle:

– Welches Feld wird nicht benötigt
– Welches Trickfenster wird für das Browsen, Abfragen, Registrieren, Aktualisieren verwendet
– Welche Person oder Gruppe kann ein bestimmtes Feld registrieren
– Registrierungsgruppe definieren lassen

3.4.1.6 UI-Regeln für Registrierung

1. Globale Widerrufstaste kann zum Widerrufen verwenden werden
2. Nachdem ein Wert eines Browse-Formulars modifiziert wurde, wird es nach der Bearbeitung rot. Nach der Registrierung kehrt es zur Farbe schwarz zurück (oder den Originalzustand).
3. Nachdem der Wert bearbeitet wurde, wird eine "Aktualisierungs-" Taste zur Werkzeugleiste hinzugefügt. Nachdem der Benutzer auf "Aktualisieren" klickt, erscheint ein Dialogfenster mit allen Modifikationen und bittet um Bestätigung.
4. Von Formular zu Formular zum Registrieren von jeweils einer Verbindung können einige e er mit vorherigen Daten vorausgefüllt und einige können leer sein. Der vorherige Eintrag kann als Vorlage für den nächsten Eintrag dienen.

3.4.1.7 Combi.Chem
Dies ist die Kombination des n Ergebnissets (R1, ...Rn). Die Lösungsgröße beträgt R1.size*R2.size*..*Rn.size Das Ergebnisset kann von einer Datei, einer Abfrage usw. stammen
Der Benutzer kann die Daten visualisieren
Der Benutzer sollte die Möglichkeit haben, eine Verbindung von jedem R1, ..., Rn auszusuchen und die Kombinierungsergebnisse zu visualisieren. Die UI wird über zwei Haupttasten verfügen "Calcul" und "Register".

– "Calcul" wird die Reaktion berechnen von entweder 1) die ausgewählte Verbindung (von R1 bis Rn) oder 2) alle R1, ..., Rn Kombinationen.
– "Register" wird alles was berechnet wurde zur Datenbank drücken Hier werden auch Felder die Kombination anderer Felder sein. Deshalb besteht der Bedarf, Handlungen in Felder einzustecken.

3.4.2 Übersicht Registrierungs-Arbeitsfluss
Daten können von einer Datei, einer bestehenden Datenbank stammen. Der Validierungsprozess der Daten wird die Datenintegrität überprüfen
3.4.2.1 Ausfallsicherheit:
Wenn der Client abstürzt, muss der Benutzer wissen, was zum Server gelangte und was nicht. Was durchging, ist vom Benutzer zugreifbar, indem um die Liste zum Server gebeten wird.
3.4.3 Registrierungsservice
4 VDL Client-Komponenten (Trickfenster, Steuerungen und Teile)
Eine Komponente ist ein Codestück (UI und/oder Business-Logik) , die Funktionalitäten umschließt/kapselt und einen Kohärent und eine prägnante API exponiert, die anderen Komponenten (und Code, Skripts) gestattet, zu interagieren.
Ein Komponentenfall kann sein:

• Im VDLClientFramework, in diesem Fall, kann auf die Komponente von unterschiedlichen VDLClientAnwendungen zugegriffen werden,
• In einer VDLCLientAnwendung, in diesem Fall, ist die Komponente nur sichtbar von dieser Anwendung.
• Außerhalb des VDLBase Frameworks, in einer Microsoft .NET Umgebung.

Die meisten Komponenten sitzen in zwei Layern, einige Komponenten sitzen nur in einem Layer.
Die Layer sind:

• Der Benutzer-Schnittstellen-Layer (UI, dies stellt die Ansicht vom MVC-Modell dar)
• Der Business-Logik-Layer (BL, dies stellt das Modell vom MVC-Modell dar)

Je nachdem, wo die Komponente sitzt, stellen die Spezifikationen der Komponente bereit:

• Modell, Ansicht und Controller (Ansicht/Controller für die UI und/oder Modell/Controller für die BusinessLogik)
• Verwenden von Fall, Aktivität, Sequenz und KlassenDiagramm.

Klassendiagramm eines MVC, das mit einer n:n Beziehung zwischen Ansichten und Modellen umgehen kann.
Alle Komponenten werden auf der VDLClientFramework-Ebene verfügbar sein; ein Unterset ist auch von der .NET Microsoft Visual Studio Umgebung zugreifbar sein.
Dieses Unterset wird das Äquivalent der Objekt-Bibliothek beinhalten.
Zum Beispiel: Raster, DbConnection, Strukturabbilder und Feldtext werden bei der MS-Visual Studio- und der VDLClientFramework-Ebene verfügbar sein. Komponenten wie Suchhistorie, Nachrichten senden und BaseObjektRepository-Struktur werden nur auf der VDLClientFramework-Ebene verfügbar sein.
Hinweis:

• Einige Komponenten müssen von einer UI gehandhabt werden, aber auch von einer Batch-Verarbeitung (VDLClientKonsoleAnwendung)
• Details werden in den Spezifikationsdokumenten für jede Komponente erfolgen.
• Komponente werden über eine Versionsnummer verfügen.

4.1 VDL Client-Komponentenliste
4.1.1 Design der Komponenten
4.1.1.1 Feld-Selektor-Struktur
Beschreibung:
Anzeige von Objekten, die in einem Formular verwendet werden können (über DnD, Doppelklick). Diese Objekte stellen dar:

1 Datenbankfelder
2 Windows primitive Trickfenster (Taste, Kalender, etc.)
3 Komplexe Trickfenster (Arbeitsfluss, Formular, etc.) [kann kontextabhängig sein]
4 Benutzerspezifische Trickfenster

Der Feld-Selektor wird die vereinheitlichte Feldtabelle in der Feld-Registerkartensteuerung anzeigen
Der Feld-Selektor wird mit der Umwurzelung der Datenbank-Wurzel umgehen
Schnittstelle:

+In: DS
+Out: Ausgewähltes Feld

Benutzer-Input:

1. Objekt/Feld und Dnd auswählen
2. Auf Objekt/Feld doppelklicken
3. Muss in der Lage sein, zu suchen
4. Nach Feldern: Gebräuchliche Verzeichnisbegriffe

Ansicht-Controller:
Verwenden des generischen Struktur-Trickfensters
UI-Klassen (Klassendiagramm)
UI-Verhalten (Statusdiagramm)
Modell-Controller
Beziehung zu anderen Komponenten:

• Eigenschaften-Editor, beide Komponenten können zu einer verschmolzen werden

Offen:
Abhängigkeit:

DatenquellKonnektor, DSSelektor, Querylets, DAF

4.1.1.2 Eigenschaften-Editor
Beschreibung:
Anzeigen der Eigenschaften einer aktiven Komponente (die aktive Komponente ist die Komponente, auf die der Fokus liegt). Eigenschaften-Editor wird einen Selbstprüfungsmechanismus verwenden. Die Eigenschaften werden in der Eigenschaften-Editor-UI angezeigt und sind bearbeitbar.
Schnittstelle:

+In: eine Komponente oder Objekt

4.1.2 Datenquell-Konfigurationskomponenten
4.1.2.1 DSSelektor
Beschreibung:
Diese Komponente gibt alle Datenquellen an, die von der Kern-Schnittstelle zur Verfügung stehen, mit der VDLBase verbunden ist. Der Benutzer wählt sich eine davon aus.
Schnittstelle:

+in: Verbindung/DS
+out: Ausgewählte DS (String)
#DS*

Abhängigkeit:

DatenquellKonnektorTrickfenster

4.1.2.2 DatenquellKonnektorTrickfenster
Beschreibung.
Nicht visuelles Trickfenster, das die Datenquell-Verbindung darstellt
Schnittstelle:

#VDL Kern-Schnittstellen-Verbindung
+in: UQL Formular
+in: UQL Wo
+in: UQL Auswählen
+in: Suche (gehe)
+out: RS

Abhängigkeit:
Login-Komponente, DSSelektor, Feld-Selektor
4.1.3 Komponenten durchsuchen und abfragen
Hinweis:
Die folgenden Komponenten können im DAF sitzen (Data Aware Form): QueryPan, QueryLet, RecordSetNavigator, SingleValueWidget, DataGrid, StructureGrid...
Das "können sitzen" wird in den Spezifikationen geklärt... Der Komponentenname kann in den Spezifikationen anders sein...
4.1.3.1 QueryPanel
Beschreibung:
Eine Tafel, die eine grafische Darstellung einer Abfrage darstellt. Diese Steuerung produziert eine Abfrageaussage, oder einfach nur den "Wo" Satz, basierend auf dem Benutzer-Input. Dies könnte einfach die DAF sein. Die Spezifikationen werden das Design klären.
Schnittstelle:

+out SQL Wo

4.1.3.2 Abfrageobjekt
Beschreibung
Die Abfrageobjekte wissen, wie eine UQL-Aussage und eine Datenquellreferenz zu nehmen sind und geben einen Datensatz wieder.
Schnittstelle:

+in: UQL-Aussage
+in: Datenquellreferenz
+out: Datensatz

4.1.3.3 Querylet
Beschreibung
Querylet wird im Inneren des QueryPanel arbeiten, dies stimmt mit dem klassischen VDL Querylet (oder Affrent-Stil) überein. Querylet ist die Komponente, die es dem Benutzer ermöglicht, eine Suche durch Querylet durchzuführen. Die Querylet-Komponente wird das Querylet in eine Abfrage umsetzen und sie über den VDL Kern-Schnittstellen-Daten-Wrapper ausführen.
Schnittstelle:

+in: Feld
+in: DS
+out SQL Wo

Dies ist der Abfrage-Editor
Abhängigkeit:

DSSelektor, Feld-Selektor, DAF, AFG

4.1.3.4 Automatischer Formulargenerator (AFG, Transform, Jabberwock)
Beschreibung

AFG: Automatischer Formulargenerator erstellt ein neues Formular unter Verwendung derzeitig verfügbarer Informationen, wie ein Vorlagenformular oder Abfrage oder bestehendes Formular oder einen Moduswechsel (Wie Berichterstatten, Browsen, Raster, Tabelle, Diagramm, Formular).

Schnittstelle:

+in: Start
+out: ein Formular (ein Browsen-DAF oder eine Berichtvorlage, etc.)
+in: Präferenzen
+in: Ein beliebiges Formular
+in: Vorlage
+in: Vereinheitlichte Feldtabelle
+in: Modus (Berichterstatten, Browsen, Raster, Tabelle, Diagramm, etc.)) (Formularbauer ist der manuelle)
+in: Steckbar oder Modul.

Was in diesem Formular erstellt werden muss ist definiert durch:

– Browsen der Präferenzen
– Raster, umgebende Daten, Formular, Tabelle

Zwei Arten von Vorlagen

1. durch Scripting (XML, beschreibt das Layout...)
2. durch Form (vordefiniertes Layout zum Wiederanwenden)

Der AFG-Output eines DAF-Formulars.
Das DAF-Browse-Formular erzeugt durch das AFG kann in ein Formular eingebettet werden, das Teil eines Arbeitsflusses ist.
Abhängigkeit: DAF, Querylets, Import/Export
4.1.3.5 Formularbauer
Beschreibung:
Dies ist keine wirkliche Komponente, aber eine Anwendung, die über dem VDLClientUIFramework läuft, das XML produziert, Formulare, Arbeitsflüsse und Zusammensetzungen beschreibt
Schnittstelle:

+in: Modus
+in: Eintrag
+out: SQL Auswahl
+out SQL Wo

4.1.3.6 Datensatz-Navigator
Beschreibung:
Komponente, die den derzeitigen Hinweis für einen Datensatz definiert. Sie definiert, welcher Eintrag derzeit der zuerst sichtbare ist. Sie können mit einem Schritt von +/– 1 oder +/– n navigieren.
Schnittstelle:

+in : Ergebnisset
+in: inc 1
+in: dec 1
+in: inc n
+in: dec n
+in: Gehe zu erstem Eintrag
+in: Gehe zu letztem Eintrag
+in: Gehe zu Eintrag #
+out: Ergebnisset

4.1.3.7 DataAwareForm – DAF (DataForm, SQLForm, ActiveForm, BaseForm...)
Beschreibung:
Ein Teilfenster, das zur Abfrage oder Anzeige einer RS verwendet werden kann. Es beinhaltet Trickfenster, die zu einem bestimmten Feld eines RS gebunden sind.
DAF kann Raster, Tabellen, "Formulare" anzeigen (bedeutet, die Layouts der Textboxen und Strukturboxen), Navigationsteilfenster und Multi-Level Kombinationen von Rastern, Tabellen, etc. Sie bringen es auf eine Seite und fügen einen Datensatz ein. Das DAF gestattet auch das freihändige Zeichnen – Vielleicht von einem generischen Formular oder Tafel und andere nicht-Abfrage bezogenen Elemente übernommen (Bilder, etc.)
Das DAF wird gewöhnlich für Abfragen durch Formulare verwendet.
Hinweis:
Das DAF wird eine Trickfenster-ID verwenden (Die Trickfenster-ID wird sich auf ein Objekt beziehen, das ausdrückt, welches Trickfenster verwendet werden muss, um seine Felder in unterschiedlichem "Modus" anzuzeigen (Registrierunp, Browsen, Abfrage) – Zum Beispiel kann "Toxität" dargestellt werden durch 1) ein Textfeld im Browsen-Modus, 2) eine Kombibox in Abfragemodus und 3) ein Drop-Down in Registrierungsmodus)
Verwende Fall:
Benutzer trägt Abfrage ein

1. Benutzer spezifiziert Ansicht
2. Benutzer browst

Schnittstelle:

+In: Datensatz (impliziert DS)
+in: Modus
+out SQL Wo
+Out: Datensatz
+Out: SQL Auswahl (muss einen inneren und äußeren Abfragebauer erschaffen, der Metadaten als Input nimmt und eine SQL ausgibt)
+In: Child hinzufügen
+Out: Parent von [Typ: Ergebnisset, von Objekt-Bibliothek]
+Out: Gleicher Eintrag [Typ: Ergebnisset, von Objekt-Bibliothek]
+Out: Nächster Eintrag [Typ: Ergebnisset, von Objekt-Bibliothek]

Abhängigkeit: Querylets, Strukturabbilder, AFG, Feld-Selektor
4.1.3.8 EinzelWertTrickfenster
Beschreibung:

Stellt ein Feld eines Eintrags im DS dar

Schnittstelle:

+In: Feld
+Out: SQL Auswahl
#In: Modus
#In: Datensatz (sollte es von seinem Container bekommen)
+Out SQL Wo

4.1.3.9 DatenRaster (DataAwareGrid, Tabelle...)

Beschreibung: Msft Word-Tabelle

Schnittstelle:

+in: Datensatz
+out: Ausgewählter Datensatz

4.1.3.10 StrukturRaster (ObjektRaster, Raster)
Beschreibung:

Regeant Selector

Schnittstelle:

+in: Datensatz
+out: Ausgewählter Datensatz

4.1.4 Systemkomponenten
4.1.4.1 Systemtrickfenster
Beschreibung:

Vom System angebotene Funktionalitäten

Schnittstelle:

+In: Schließt Anwendung
+In: Handlung Speichern zu Datei
+In: Dateiname (String)
+In: Exit
+In: Gehe zu Home...

4.1.4.2 Navigator

Beschreibung: Diese Komponente kann Teil des Systems sein, Sie bieten eine URL an und das System ruft sie auf und bittet darum, dass das Formular den URL-Inhalt anzeigt +In: URL

4.1.4.3 Login
Beschreibung:

Diese Komponente nimmt den Input des Benutzer-Berechtigungsausweises und validiert ihn gegen einen VDL Kern-Schnittstellen-Server.

Abhängigkeit:

VDL Kern-Schnittstellen-Verbindung.

4.1.4.4 Anwendungs-Nachrichten-Anwender
Beschreibung:

1) Sendet Ereignis über die VDLClientAnwendung hinweg, 2) Löst Handlungen aus, wenn die Nachricht empfangen wird Sollte ein VDLClientFramework-Tool sein, das Informationen zur Zielanwendungs- "Message Handler" propagiert
Siehe VDLBase Framework-Messaging-System innerhalb des Toolkits für weitere Details.

4.1.4.5 Die 3 Statusobjekte (FrameworkStatus, Arbeitsfluss/AnwendungsStatus und der FormularNavigatorStatus)
Die 3 Statusobjekte werden wirklich vom gleichen Statusobjekt übernommen. Sie verfügen über einen unterschiedlichen Namen, um ihre Rollen und ihren zulässigen Gereicht zu differenzieren.
4.1.5 Andere Komponenten
4.1.5.1 VDL Zeichnen
Beschreibung:

Struktur-Editor/Anzeiger. Die neue Zeichnung wird sich befinden in C# Schnittstelle:

+In/out: Struktur

4.1.5.2 DateiOrdnerStruktur
Beschreibung:
Schnittstelle:

+In [Dnd]: fortbestehendes Objekt (Formulare, Trickfenster, Formular+Daten, Listenhistorie)
+Out [DnD]: fortbestehendes Objekt (Formulare, Trickfenster, Formular+Daten, Listenhistorie)

Ansicht-Controller:
Verwenden des generischen Struktur-Trickfensters siehe auch "BasisObjektRepository" von "Neuer Service"
4.1.5.3 Berichterstattungskomponente
Beschreibung:
Interne Lösung
Dieses Klassen-Diagramm gestattet Plug-ins in den 3 Hauptgebieten der Berichterstattungskomponente zu haben: Inhalt, Vorlage und Format.
Es gestattet das dynamische Umschalten der Plug-in Konfiguration.
4.1.5.4 Importieren/Exportieren der Komponente
Beschreibung:

Dateiformat: SD-Datei, RD-Datei, Mol-Datei, CSV, XD-Datei, Liste....

Schnittstelle:
4.1.5.5 Kern-Schnittstellen-Dienste
Die KernSchnittstellen-Dienste-Wrapper für VDLBase werden die vollständige KernSchnittstellen-API exponieren.
Dies bedeutet, dass Fortschrittsberichte, Fehler, Ausnahmen durch die Wrapper berichtet werden.
4.1.5.5.1 Session
Beschreibung:
Eine Session ist eine "Mitbenutzbare Inbetriebnahme-Komponente" (es ist notwendig, sich einzuloggen). VDLBase kann potentiell mit mehreren KernSchnittstellen verbunden werden.
Diese Komponente kann verwendet werden von 1) dem Framework (und ist für die Anwendungen mitbenutzbar, die es möchten), 2) von einer VDLClientAnwendung.
All die anderen VDL Kern-Schnittstellen-Dienste sind auch vom Framework und der VDLClientAnwendung aus zugreifbar. Die anderen VDL Kern-Schnittstellen-Dienste sind keine "Mitbenutzbare Inbetriebnahme-Komponente", aber eine "Mitbenutzbare Komponente", da es nicht erforderlich ist, sie zu starten, um das Framework in Betrieb zu nehmen.
Schnittsfelle:
4.1.5.5.2 Message-Center
Beschreibung:

Siehe VDL Kern-Schnittstelle

Schnittstelle:

Wrapper-Schnittstelle

4.1.5.5.3 Objektaufbewahrung
Beschreibung:

Siehe VDL Kern-Schnittstelle (neue Anforderung für OSS oben auf der Datenbank)

Schnittstelle:

Wrapper-Schnittstelle

Die UI wird durch die DateiOrdnerStruktur von der "AndereKomponenten\Datei-Ordner-Struktur" behandelt.
4.1.5.5.4 Datenquelle
Beschreibung:
Schnittstelle:
Wird durch die Datenquell-Konfigurationskomponenten und die Browse- und Abfragekomponenten umschlossen und verwendet.
Basis muss in der Lage sein, alle Datenquellen zu suchen, die von der Kern-Schnittstelle 2.0 bereitgestellt werden (siehe Listenanforderung ER11.1).
Listen-Logik muss exponiert werden.
Es muss dem Wrapper-API gestattet sein, mit mehreren Datenquellen gleichzeitig verbunden zu werden.
Der Wrapper wird eine "automatische" Struktur-Suchfähigkeit bereitstellen, wie es der Datenbank-Browser tut.
VDLBase wird Dateien in den folgenden Formaten importieren/exportieren:Mo-Datei, SD-Datei, RD-Datei, CSV, XD-Datei
4.1.5.6 Suchhistorie
Beschreibung:
Die Auflistungshistorie verwendet das Generische Diagramm, definiert im Anhang als ein Modell/Controller
Schnittstelle:
In/Out

+in: DS
+in: RS
+in: Abfrage
+in: Historie
+out: Ausgewählte RS
+out: Ausgewählte Abfrage
+out: Historie

Benutzerinteraktionen:
Interaktionen der Komponenten:

• Dateistruktur: DnD wird für Knoten, Ecken, Diagramme und Unterdiagramme verwendet, um Objekte in der Suchhistorie zu speichern oder zu laden.
• Datenquelle:

4.1.5.6.1 Suchhistorie (Ansicht/Controller)

Hinweis: CompoundLocator verfügt über die Möglichkeit der automatischen Suche. Dies bedeutet, dass das Suchergebnis von anderen Suchtypen getrennt werden kann (wie, exakt, SS, ...). Das volle Ergebnisset kann immer noch als ein Knoten dargestellt werden und kann verschiedene Children-Knoten haben, die Unterergebnissets verschiedener Suchtypen darstellen, die Transition wird angeben, ob es sich um SS, Exact... handelte. Damit eröffnet sich die Möglichkeit der Anwendung der Auflistungs-Logik auf die volle Liste oder einem Unterset der Liste, die von einem Suchtyp gefunden wurde.

4.1.5.6.2 Listenhistorie (Controller/Modell)
Die grünen Klassen stellen die Klasse dar, die vom "Generischen Diagramm" unten übernommen wurde.

• Die Ecke stellt entweder ein AbfrageFormular, einen SQL/UQL-Abfrage-String oder eine Listen-Logik-Operation dar
• Der Knoten stellt entweder ein Ergebnisset, ein BrowseFormular mit seinem Ergebnisset oder ein Nichts dar (in diesem Fall wird der Knoten den Inhalt seiner Ecke wiederbringen) Das BrowseFormular und das AbfrageFormular werden einen Caching-Mechanismus verwenden, wenn der Speicher niedrig wird.

4.1.5.6.2.1 Hinweis: Suchhistorie, die im generischen Diagramm verwendet wird, ist im Anhang als Modell/Controller definiert
5 Server-seitige Komponenten und deren Dienste
VDLBase wird mit dem VDL Kern-Schnittstellen-Server unter Verwendung von SOAP (Simple Object Access Protocol = Einfaches Objekt-Zugriffs-Protokoll) kommunizieren. Alle Serverkomponenten werden für den Client als Webdienste exponiert. Serverkomponenten sind gewöhnlich in Java geschrieben und werden als VDL Kern-Schnittstellen-Dienste mit einem Web-Dienste-Wrapper ausgeführt. Das Weiterleiten von "Objekten nach Wert" passt nicht einfach in ein Web-Dienste-Paradigma und wird einige Anordnungsklassen verwenden, die von Java zu .NET und umgekehrt exponieren.
Das Folgende sind die Dienste, die vom VDL Kern-Schnittstellen-Server erforderlich sind, um die VDLBase zu unterstützen. Einige sind "Wrappers" um VDL Kern-Schnittstellen-Basisdienste. Andere müssen besonders für VDLBase geschrieben werden.
5.1 Authentifizierung & Lizenzierung
5.2 Datenquelle und gebräuchliche Feldnamen
VDLBase kann eine beliebige Datenquelle konsumieren, die durch die VDL Kern-Schnittstelle exponiert ist. VDLBase wird Dateien in den folgenden Formaten importierenlexportieren:Mo-Datei, SD-Datei, RD-Datei, CSV, XD-Datei
Sie muss jedoch ihr eigenes Set von gebräuchlichen Feldnamen auf die tatsächlichen Datenverzeichnisse überziehen. Aus diesem Grund wird ein spezieller VDLBase Datenquellservice für den Client als Webservice exponiert. Da alle VDLBase Datenbankverbindungen durch diesen Service laufen, muss kein anderer VDL Kern-Schnittstellen-Datenquellservice als Webservice exponiert werden.
Die gebräuchlichen Feldnamen selbst und die Informationen, die sie in den Datenbank-Metadaten abbilden, werden durch einen Administrator definiert. Diese Informationen werden in einer Datei oder in einer Datenbank im mittleren Bereich sitzen. Diese Informationen werden während der Laufzeit zu den Metadaten jeder Datenbank hinzugefügt. Der Client wird Metadaten erhalten, wo die gebräuchlichen Namen eingefügt wurden. Es sollte keine spezielle Programmierung für den Client notwendig sein, um mit den gebräuchlichen Namen umzugehen.
Beim Erhalt von Abfragen vom Client, muss der VDLBase Datenquellservice die gebräuchlichen Namen zurück zu den tatsächlichen Datenbankfeldnamen abbilden. Dann, beim Abrufen eines Datensatzes für den Client, werden die gebräuchlichen Namen in den Datensatz eingefügt. Somit sollte der Gebrauch von gebräuchlichen Namen für den Client komplett transparent sein.
Kunden sollten die Option haben, die gebräuchlichen Feldnamen nicht zu verwenden, wenn es für sie eine zu hohe administrative Last darstellt. In diesem Fall handelt der VDLBase Datenquellservice lediglich als "Durchreiche" zu anderen VDL Kern-Schnittstellen-Datenquelldiensten.
Sorgfalt muss gewaltet werden, um die Name-Mapping Operationen effizient durchzuführen. Zum Beispiel kann der Service die manipulierten Metdadaten cachen, um sie wieder zu verwenden.
Abbildung 1 Datenfluss gebräuchlicher Feldnamen-Service
5.3 Arbeitsfluss-Service [LIMS-Unfertige Erzeugnisse] [Version 2.0]
Es gibt verschiedene Möglichkeiten, um den Arbeitsfluss-Service durchzuführen.
6.1.1)
Der ArbeitsflussService wird die Rollen-Kooperation gestatten, indem mit unterschiedlichen Benutzertypen (Rollen) umgegangen wird, die mit ihm zu unterschiedlichen Phasen des Arbeitsflusses interagieren. Nachdem ein Benutzer mit seinem Teil in Bezug auf einen bestimmten Arbeitsfluss fertig ist, wird der Arbeitsfluss zum ArbeitsflussService gedrückt, der auf dem Server sitzt. Sobald sich der nächste abzeichnet, verbindet sich der Benutzer zur VDLBase und der Arbeitsfluss wird auf seiner Liste des Arbeitsflusses hinzugefügt.
6.1.2)
Der ArbeitsflussService geht konkurrent mit Benutzern auf dem gleichen Arbeitsfluss um, in diesem Fall verfügt der Arbeitsfluss-Service über die Arbeitsfluss-Maschine. Der ArbeitsflussService wird zu einem Server von XML-Seiten für Benutzer (wie ein Webserver für HTML-Seiten). Knoten verfügen über Rollen, die zugehörig zu ihnen sind. Die Arbeitsfluss-Service-Maschine ist intelligent genug, um alle Formulare, die vom Benutzer des Arbeitsflusses verwendet werden, auf einmal zu senden.
Wie im Kapitel "Arbeitsfluss und Benutzerrollen" gesehen, wird ein komplexer Multi.Benutzer-Arbeitsfluss in mehrere einzelne Benutzer-Arbeitsflüsse aufgeteilt, dieser Arbeitsfluss wird durch Vorbedingungen "verknüpft". Zum Beispiel verfügt im nächsten Diagramm der Arbeitsfluss 3 über eine Vorbedingung, mit dem Start zu warten, bis Arbeitsfluss 1 und Arbeitsfluss 2 beendet sind.
Lösung: 6.1.2 würde für die Version 2.0 ausgewählt
Der ArbeitsflussService kann zusätzlich zur "VDL Kern-Schnittstellen-ObjektAufbewahrung" ausgeführt werden oder es kann ein neuer Service sein, der Daten zu einer Datenbank speichert.
5.4 VDL Basis-Objekt-Repository
Beschreibung:
VDLBaseObjektRepository ist ein Objekt-Repository, welches das Speichern, Abrufen und Laden einiger Objekte gestattet, wie Sortieren der Anordnung, Abfrage, Abfragehistorie, Listen, Vokabulare, Berichtvorlagen, Arbeitsflüsse, Formulare.... So kann der Benutzer sie gemeinsam benutzen und wiederverwenden. VDL Kern-Schnittstellen-ObjektAufbewahrung muss in der Lage sein, in einer Datenbank, statt in einem Dateisystem fortzubestehen.
Hochgradiges Benutzerfall-Diagramm.
Alle diese Funktionalitäten werden durch VDL Kern-Schnittstellen ObjektAufbewahrungs-Dienst angeboten.
So wird BaseObjektRepository das VDL Kern-Schnittstellen-OSS auf der Serverseite oder ein Fall einer Klasse sein, der vom VDL Kern-Schnittstellen-OSS übernimmt.
5.4.1.1.1 Modell-Controller-Wrapper
Die Serverfähigkeiten (zumindest die in Bezug auf den privaten Ordner des VDL Kern-Schnittstellen-OSS) werden für den Client benötigt. BaseObjektRepository-Client wird ein Wrapper für die Client-Version als auch die Server-Version des OSS sein [Version 2.0].
5.4.1.1.2 Ansicht-Controller
Verwenden Sie ein generisches Struktur-Trickfensters. Es gibt 2 unterschiedliche Hauptknoten: lokal und Remote
5.5 Registrierungsservice
Der Registrierungsservice, der von VDLBase verwendet wird, wurde von Consulting entwickelt. Entweder 1) der Consulting Registrierungsservice wird als Standard mit der VDLBase geliefert, einige Funktionalitäten werden durch die VDLBase-Lizenz verschlossen sein und geöffnet, nachdem der volle Service gekauft wurde (durch Marketing, Entwicklung und Consulting zu definieren) oder 2) eine Minimum ersetzbare Durchreich-Light-Version des Registrierungsservices wird vom VDLBase-Team implementiert und geliefert, diese Light-Version wird ersetzt, nachdem der Kunde die volle Version von Consulting kauft (gleiche API).
6 Lieferung und Einsatz
6.1 Lieferung
VDL Basis wird über ein Netzwerk entwickelt, von einer Installation beim Server. Die Installation beim Client sollte automatisch und für den Endbenutzer unsichtbar sein und keine Eingriffe vom IT-Admin-Support bedürfen. Updates zur Software erfolgen auf dem Server und verbreiten sich auf die Clients nach Anforderung, wiederum mit wenigen oder keinen erforderlichen Eingriffen.
Das gleiche gilt für Anwendungen, die auf der Basisarchitektur gebaut sind. Basis- und andere Anwendungen können Server-seitige und Client-seitige Komponenten beinhalten. Diese können in eine einzelne Installation kombiniert werden, die auf dem VDL Kern-Schnittstellen-Server erfolgt.
Client Installationsschritte
Die erstmalige Installation der Basis auf einer Client-Maschine erfolgt in mehreren Schritten. Der Benutzer:

• Geht zu einer Webseite
• Downloadet und installiert .NET bei Bedarf
• Downloadet und führt den Basis-Shell Installer aus
• Führt die Basis aus
• Konfiguriert sie
• Loggt sich in die VDL Kern-Schnittstelle ein
• Anwendungen werden heruntergeladen

Bitte nehmen Sie Bezug auf VDL Base Deployment Specification.doc für weitere Details
Bitte nehmen Sie auf die VDLBase Installer-Spezifikationen für weitere Details Bezug Basis wird die Signatur von Baugruppen erfordern, um Baugruppen herunterzuladen. Dies impliziert, dass Basis zuvor das adäquate Zertifikat erhält, nachdem das Produkt erworben wurde.
In anderen Worten wird jeder Provider einer "herunterladbaren Baugruppe" ein Zertifikat anbieten. Ein Zertifikat ist einzigartig und eng and den Besitzer des Unternehmens gebunden, wo die Baugruppe ausgeführt werden soll.
3 Arten von Installer werden die Basis 1.0 liefern:

• Client .EXE Installer (über Internet und optionale CD)
• Server-Installer (N+1) von der Kern-Schnittstelle
• .Net Pull-Typ-Installer

6.2 Einsatz
6.2.1 Betriebssystem
VDLBase wird unterstützt von:

• Für den Client: – Windows 2000 – Windows XP – Citrix Metaframe XP (muss funktionieren, wird aber nicht unterstützt)
• Für den Server: – Alle Kern-Schnittstellen unterstützten Plattformen (Microsoft/Windows und SUN/Solaris)

6.2.2 VDLBase Einsatz (< 100 konkurrente Benutzer)
Ein Unternehmen kann viele Fälle der folgenden Konfiguration haben, die gleichzeitig laufen.
Hinweis:
Basisprozessor stellt entweder dar:

• VDLBase (dicker Client),
• Eine Internetanwendung, in die Basis oder einige Basis-Komponenten eingebettet sind (dünner Client) oder
• Eine dicke Kundenanwendung, in die Basis oder einige Basis-Komponenten eingebettet sind oder
• Ein Entwickler sitzt bei MSVS und einige Basis-Komponenten.

6.2.3 Skalierbarkeit: Großer VDLBase-Einsatz (> 100 konkurrente Benutzer)
Das folgende Einsatz-Diagramm ist für eine große Benutzeranzahl nützlich. Es ist auch eine Lösung für den Umgang mit der Ausfallsicherheit.
6.2.4 Kompatibilität/Koexistenz
VDLBase muss in der Lage sein, parallel zu den folgenden Werkzeugen zu laufen:

• IE6
• MS Office (XP und 11)
• ISIS Basis

6.3 Ordner und Dateien

• bin: habe die ablauffähige Datei (base.exe)
• bin\cache: habe die fortbestehenden Fälle (dies kann zum Server gelangen) und alle die heruntergeladenen Anwendungen
• bin\dlls: habe die dlls, die für das Ausführen erforderlich sind (Framework, ...)
• doc: beinhaltet die Dokumentation der Treiberanwendung
• Lokale Arbeit: stellt den Arbeitsordner des Benutzers dar; dies kann durch "C:\Documents and Settings\user\My Documents\VDL Core Interface Desktop" ersetzt werden
• Logs: habe die Logs der Anwendung erhalten, die laufen oder gerade abgestürzt sind
• Support: beinhaltet die Werkzeuge Dritter zusammen mit deren Lizenzvereinbarung
• System: beinhaltet die Systemdateien und Konfigurationsdateien. Vielleicht wird ein unterschiedlicher Ordner benötigt, um im Inneren von System, wie Admin, Log hinzugefügt zu werden

Base.exe

ist eine Bootstrap-Anwendung. Alle anderen DLLs werden heruntergeladen vom Server und Live im Cache.

Doc beinhaltet die Dokumentation.
System beinhaltet Konfigurationsdinge und beliebige Dateien für das System, einschließlich den Cache. Der Cache sollte flach sein, obwohl er alle möglichen verschiedenen Dinge enthalten wird.
Dies ist alles, was vom technischen Standpunkt aus notwendig ist. Marketing könnte einige Vorstellungen darüber haben, wie Basis-abhängige Anwendungen präsentiert werden sollten (d.h., vielleicht möchten sie, dass sie ihr eigenes Verzeichnis haben).
Lokale Benutzerdateien sollten gespeichert werden, wo immer der Benutzer sie möchte, möglicherweise
in My Documents/VDL Desktop
7 Programmierung und kundenspezifische Anpassung

1. Scripting
2. Microsoft Visual Studio
3. Plug-in Architektur
4. Tasks erfordern die Umschließung eines N+1 Services zu einer UI-Komponente
5. Konnektivität mit Dritten

7.1 Scripting
7.2 Microsoft Visual Studio
.NET
Satz der VDLBase
Komponenten werden exponiert zum Microsoft Visual Studio:
• Strukturanzeiger
• DAF (Querylet...)
• DB Access
• Frame
• Äußeres Framework, eingebettet in einem .NET Client
Diese Komponenten wurden im Abschnitt "VDL Client-Komponenten" beschrieben 7.3 Plug-in Architektur
Basis ist hauptsächlich über seine XML-Konfigurationsdateien konfigurierbar. Komponenten exponieren Plug-ins.
(Diese werden bei den Spezifikationen geklärt)
Aus Evolutionsgründen ist es wichtig, die öffentliche API von der Engine zu trennen.
Es ist auch wichtig, ein separates öffentliches Paket zu verwenden, das sich von der privaten Maschine unterscheidet um dem Endbenutzer das Lernen und den Gebrauch zu erleichtern.
Potentielles Plug-in Gebiet:
• VDLClientFramework

1. VDLClientFramework (BL – UI Business-Logik) • Systemsignal-Callback • Lebenszyklus: geladen, gestartet, fortbestanden, beendet (Inbetriebnahme, Außerbetriebnahme) – => Sie können Ihre eigene Klasse zu den vorhandenen in der XML-Datei hinzufügen. • Ereignis (Senden, Empfangen des Ereignisses-> Handlung) • Login (Benutzer, Passwort) [Benutzer muss in der Lage sein, das Login zu verbessern] • Login Timeout Callback, Entwickler kann die Zeit angeben. • Längerer und Ausnahmenumgang • Hop Across • NetzwerkTimeOut Callback (Fehlermanagement) • Toolkit-Erweiterung • Mitbenutzbare Inbetriebnahme-Komponente (wie VDL Kern-Schnittstelle) – => Sie werden in der Framework XML-Datei definiert • Mitbenutzbare Komponente (gemeinsame Benutzung über VDLAnwendungen hinweg)
2. VDLClientFramework (UI) • Skin ändern • Systemsignal-Callback • Login UI • Popup-Menü aktivieren/deaktivieren • DnD

• VDLAnwendung

1. VDLAnwendung (BL) • Längerer und Ausnahmenumgang • Objekt Callback löschen • Akzeptierbares Objekt für das Clipboard
2. VDLAnwendung (UI) • Skin ändern • Popup-Menü aktivieren/deaktivieren • Application gain focus, application lost focus • DnD

• Arbeitsfluss

1. Benutzer Callback für • Transition • Formular (Eingang, Ausgang) • Starten und Beenden eines Arbeitsflusses • DnD

• Formulare

1. Benutzer Callback für • Formular (Eingang, Ausgang) [Argumente: Formularname • DnD • Geöffnet • Schließen
2. Konfigurationsflaggen • Akzeptiert Kopieren/Einfügen innerhalb eines Formulars

• Komponente

1. Die Komponente muss den Logger empfangen
2. Wie man eine neue Komponente schreibt
3. Wie man eine neue Komponente hinzufügt
4. Plug-in erklären (MVC)
5. Komponente (BL) • Lebenszyklus der Komponente • Spezifisches Plug-in: Dokument Berichterstattung Inhalt: Voll versus Basis-Berichterstattung Format: Doc, txt, HTML oder PDF Vorlage: – Kopfzeile, Inhalt, Fußzeile – Kopfzeile Bericht erstellt Callback • Datenquell-Verbindung (Verbindung nicht vorhanden, vorhanden, etc...) Callbacks – Callback, der die Abfrage fängt (von UI zu UQL) – Callback öffnen/schließen – Suche beendetes Callback – Suchereignis unterbrechen API sollte gestatten: – Temporäre Datenquellen zu erstellen (temporäre Tabelle) • Raster • Tabelle • Registrierung Registrierter Daten-Callback Aktualisierter Daten-Callback • Suchhistorie Geändert(Objekt o) Callback • Strukturanzeiger Geänderter Callback Festlegen/Erhalten der Zeichnungspräferenzen • Importieren/Exportieren Start Ende Plug-in Konversionsklassen (Standard wird für RD-Datei, XD-Datei und SD-Datei bereit gestellt) Mapping Callback Fortschritts-Callback N+1 Komponente Festlegen/Erhalten des Datensatzes Erstellt/geschlossen Hilfereferenz Log-Referenz
6. Komponente (UI) • Skin ändern • Dialog Trigger (erfordert DR28.1) • Fokus am Callback verlieren und gewinnen • Mausklick-Callbacks (links, rechts, Doppelklick) • Intelligente Verbindungstechnologie

7.4 Tasks erfordern die Umschließung eines N+1 Services zu einer UI-Komponente

1. Schreiben Sie den N+1 Service mit dem VDL KERN-SCHNITTSTELLEN-Server API
2. Umschließen Sie die API über SOAP (dies wird die API für den Client auf dem .NET-Layer exponieren)
3. Passen Sie die Business-Logik-Wrapper API auf dem generierten SOAP-Stub an (das Standardverhalten wird die volle API exponieren)
4. Schreiben Sie die UI-Komponente, die – Eine Verbindungs-/Rohr-API exponiert – Mit dem Benutzer interagiert

7.5 Konnektivität mit Dritten
7.5.1 Kern-Schnittstelle
7.5.2 Discovery Gate
VDLBase kann auf das Discovery Gate über drei Möglichkeiten zugreifen:

1. Direkt über die Discovery Gate SOAP-Schnittstelle
2. Indirekt über die Kern-Schnittstelle
3. DG 2.0 wird als Datenquelle exponiert, Basis wird Zugriff auf diese Datenquellen haben

Letztlich wird das Discovery Gate von der alten GCS-Technologie zur neuen Kern-Schnittstellen-Technologie getragen.
8 Sicherheit, Erlaubnisse und Lizenzen
8.1 Benutzerrollen und Gruppen
Gewöhnlich wird die VDL Kern-Schnittstellen-Authentifizierung verwendet. Die Wallet wird jedoch Tickets enthalten, die besonders für VDLBase erstellt wurden. Zum Beispiel wird ein Ticket die Rolle des Benutzers identifizieren (Wissenschaftler, Entwickler, Administrator), die Privilegien bestimmt. VDL KERN-SCHNITTSTELLEN-Authentifizierung gestattet uns, Gruppen zu erstellen, Benutzer und Tickets pro Gruppe zu definieren. Das Gruppenmitglied wird von den Tickets übernehmen. Gruppen verfügen auch über Eigenschaften.
Dies sollte keine Code-Änderungen in der VDL Kern-Schnittstellen-Authentifizierung erfordern. Die kundenspezifische Anpassung erfolgt durch die Werte in der Authentifizierungs-Datenbank.
Für den Fall, dass VDLBase verwendet wird, um zu zwei unterschiedlichen VDL Kern-Schnittstellen-Servern verbunden zu werden, soll eine davon als der primäre oder Master-Fall bestimmt werden. VDLBase-spezifische Autorisierungsinformationen werden nur von diesem primären Fall stammen. Damit werden alle Situationen vermieden, wo VDLBase widersprüchliche Autorisierungsinformationen von zwei oder mehreren Quellen erhält.
8.2 Authentifizierung und Lizenzen
VDLBase unterstützt Lizenzen nach Anwendung. Der VDL Kern-Schnittstellen Lizenzierungsmechanismus wird für den Umgang mit zukünftigen Anwendungen verwendet, die zusätzlich zum VDLBase Framework gebaut werden.
VDL Kern-Schnittstellen-Lizenzierungsmechanismus gestattet dem VDLClientFramework einen Kontext für jede Anwendung zu haben (Format: Application\VDL\Base, Application\VDL\RegeantSelector, ...). Auf gleiche Weise muss ein Produkt-Kontext für jedes Produkt erstellt werden.
Von diesen Kontexten werden Lizenzen erzeugt und zur VDL Kern-Schnittstelle importiert. Diese Lizenzen werden durch IPP erzeugt und an die Kunden gesendet. Kundenadministratoren nehmen die Dateien und installieren sie innerhalb der VDL Kern-Schnittstelle mit dem Admin-Tool, das mit der VDL Kern-Schnittstelle bereitgestellt wird.
Nachdem diese Lizenz auf dem Server installiert ist, kann der Anwendungsname über 5:setApplication(Anwendungsname) auf dem Client eingestellt werden. Wenn die Anwendung nicht bekannt ist, wird eine Ausnahme von der VDL Kern-Schnittstelle ausgegeben.
VDLClientFramework wird mit vielen Anwendungen (VDLClientAnwendung) gleichzeitig umgehen, jede Anwendung muss seinen eigenen Anwendungs-Kontext und Produkt-Kontext haben.
8.3 Lizenzen Eenutzerfälle
Verwendung des Falles 1:
Ich habe das VDL Discovery Framework Standard gekauft (ich erhalte VDLBase Standard + VDL Kern-Schnittstelle Standard) und ich habe auch Reagent Selector Enterprise gekauft.
Verwendung des Falles 2:
Ich habe das VDL Discovery Framework Enterprise gekauft (ich erhalte VDLBase Standard + VDL Kern-Schnittstelle Enterprise) und ich habe auch Reagent Selector Basic gekauft.
Lösung: wird beschrieben in der Lizenzspezifikation
8.4 Download
9 Annahmen
Der Architekturplan für dieses Produkt wurde unter Annahme der folgenden Annahmen erstellt:

• Das VDLClientFramework wird für zukünftige VDL-Produkte benötigt
• Lokale Datenbank ist für Base 2.0
• VDLBase Offline-Fähigkeit ist für Base V.2.0
• Zeichnen (in c#) wird rechtzeitig fertig sein
• VDL Kern-Schnittstelle 2.0 wird rechtzeitig fertig sein, zusammen mit den benötigten Funktionalitäten
• Parallele Arbeitsflüsse von konkurrenten Benutzern wird in naher Zukunft benötigt
• Das VDLClientFramework wird für Aufgaben, Arbeitsflussmanagement und das LIMS-System verwendet.

10 Leistungsmodell
Leistung ist ein großes und komplexes Problem, dessen Lösung mehrere Stufen involviert. Es kann sich lohnen, ein Produkt ohne korrekte Leistung zu verwenden.
10.1 Leistungsprobleme von früheren Erfahrungen und zukünftige potentielle Risiken

– Von MINE: • Langsames Backend + Langsame XML-Übersetzung
– Vom Discovery Gate: • Warten Sie auf die vollständige Suche, bevor Abrufen ein Killer war [Lösen in VDL KERN-SCHNITTSTELLE] • Warten auf vollständiges Abrufen vor der Anzeige • Nichtskalierbares Backend [VDL KERN-SCHNITTSTELLE Cluster + DNS]
– Von VDL KERN-SCHNITTSTELLE: • VDL KERN-SCHNITTSTELLEN-API Gesprächigkeit [Wahrscheinlich bereits in JBs Batch-Mechanismus gelöst] • SOAP Übersetzungskosten [Lee und QA kümmern sich darum] – Potentiell derzeit das höchste Risiko • Das Backend ist in Bezug auf Skalierbarkeit nicht gefolgt

10.2 Vorschau der VDLBase
Im Allgemeinen, wird dies Objekte cachen und die Gesprächigkeit des Netzwerks minimieren.
10.2.1 Nachrichtenfluss
Die Skala, die Latenz und die Anzahl der Nachrichten unterscheidet sich entsprechend der Szenarien. Unser Hauptziel wird sein, das Testen der Leistung innerhalb des Entwicklungseinheitstests hinzuzufügen und die Ergebnisse nachzuverfolgen.

1. Aus Sicht der Basisleistung ist es das Ziel, über SOAP so nahe wie möglich an der VDL Kern-Schnittstelle zu sein
2. Aus Sicht der SOAP-Leistung ist es das Ziel, so nahe wie möglich an der VDL Kern-Schnittstelle (Java API) zu sein
3. Aus Sicht der VDL Kern-Schnittstellen-Leistung ist es das Ziel, so nahe wie möglich zu JDBC und schneller als ISIS-HOST zu sein.

Ergebnisset:

• Potentielle Lösung: ein Paging-System: – Auf Diskette (oder lokaler DB) [Privat vom Benutzer] 1. Nury Extregs + Abfragen [für jede Suche] – Im Speicher: 1. Was auch immer der Benutzer ansieht (alle Daten), verbleibt im Speicher (bis veraltet). 2. Veraltet (aktualisierter Zeitstempel) und verschwinden
• Aus Leistungsgründen wird das Bestellen eines Ergebnissets wahrscheinlich auf der Server-Seite für einen großen Datensatz und auf der Client-Seite für einen kleinen, handlichen Datensatz erfolgen müssen. Der Bestellvorgang auf dem Client und dem Server muss der gleiche sein, um kohärent zu bleiben.

Suchhistorie:

1. Aktualisieren/Updaten der Struktur
2. Aktualisieren des Zweigs
3. Aktualisieren des Knotens und Bellow (Domäne nicht ändern)

Formulare:
Formulare und besonders erzeugte Formulare müssen gecacht und wenn möglich wiederverwendet werden, sodass die Erstellungszeit minimiert wird. Außerdem wird Vor- und Nach-Fetching und Alterungsmechanismen verwendet.
Zusätzlich benötigt VDLBase einen schnellen Mechanismus, um das Formular am Server abzufragen. Dies kann durch zwei Optionen erfolgen 1) über OSS durch SOAP, und 2) über eine Datenbank durch einen Webserver. Die Kern-Schnittstelle ist bereits mit dem Webserver mitgeliefert.
Importieren der Datendatei (txt, SD-Datei, VDLXml, ...)
Importieren einer kleinen Datendatei, die VDLXml Datenquelle im Speicher verwenden kann. Wenn die zu importierende Datei zu groß ist, sollte die Kern-Schnittstelle einen Mechanismus, wie eine temporäre Oracle-Tabelle verwenden. (Kern-Schnittstellen-Anforderungen_)
Datenquelle:
11 Beschreibung der wiederverwendbaren Koemponenten
Dieser Abschnitt listet wiedervenvendbare Komponenten auf, die im Produkt verwendet werden und beschreibt deren Wiederverwendungspotential.
11.1 Wiederverwendbare Komponenten
11.2 Neue Komponenten, von der VDLBase bereitgesfellt
12 Werkzeuge

• Dokumentation (so etwas wie javadoc für C#)
• Entwicklung: VS.NET 2003
• Bauen: Nunit und JPerf (oder Junit, das auch in der C# Welt populär geworden ist), Nant und ClearCase
• QA: Rational Robot von Rational Rose kann für das automatische UI-Testen verwendet werden
• Installer: InstallAnyWhere, InstallShield, MS-Intaller

13 Bauprozess
Wir werden den neuen formellen VDL Bauprozess verwenden, bereitgestellt von der VDL Kern-Schnittstelle.

• Automatischer Prozess: – Bau-Code (Code + Dok), UnitTest, Bau-Installer, UnitTest, Senden eines detaillierten Fehlerberichtes für jede Phase zu einer Zielliste mit Personen (je nach Phase). – Der Bauprozess muss vollständig automatisiert sein – Minimum von einem Bau pro Tag in der Entwicklungsphase. – Werkzeuge • Nunit (oder Junit) kann für das automatische Testen der Einheit verwendet werden (KOSTENLOS) • Jperf kann für das automatische Testen der Leistung der Einheit verwendet werden (KOSTENLOS) • Nant kann für das Scripting verwendet werden (KOSTENLOS) • Rational Robot von Rational Rose kann für das automatische UI-Testen verwendet werden. (BENÖTIGT EINE LIZENZ)

14 Anforderunge an die Rückverfolgbarkeit
Anforderungen an die Endbenutzer-Aufgaben
Anforderungen an die Admin-Tasks
System- und Lizenzanforderungen
Anforderungen an die Entwickleraufgaben
14.1 Aktoren
Endbenutzer:

0 – Keine Anpassung
1 – Anpassung (Felder, beschränkte Eigenschaften)
2- Formularbauer (volle Eigenschaften, Bau-Registerkarte (Trickfenster), gebaut für Verhalten)

Adv. Ui-Designer:

3 – Anwendungsdesigner (Verbindung) <- kann ein Wissenschaftler sein (verfügt nicht über eine Visual Studio Lizenz)

Entwickler:

4 – Entwickler (erstellt neue Komponenten, Scripting), (verfügt über eine Visual Studio Lizenz)

14.2 Generische Bibliothek der Komponenten
14.2.1 Generische Struktur
14.2.2 Generisches Diagramm
14.2.2.1.1 Generisches Diagramm (Ansicht/Controller)
14.2.2.1.2 Generisches Diagramm (Modell/Controller)
Die gelben Klassen sind in sich geschlossen. Sie stellen den inneren Mechanismus des Diagramm-Pakets dar. Die grünen Klassen stellen das öffentliche API dar. Ein Benutzer kann dieses Diagramm als Suchhistorie oder einen Arbeitsfluss wiederverwenden (Teil und Struktur kann sogar passen, muss überprüft werden)
Das Klassen-Diagramm stellt ein generisches rekursives Diagramm dar (es kann Diagramme in seinen Knoten enthalten). Die Knoten verfügen über verschiedene_Quell- und _Zielknoten über Transitionen. Ein Knoten weiß auch, welche Transition zu ihrer Aktivierung führt.
14.3 Input/Output-Formate
Alles kann als XML gespeichert/gelesen werden.
Daten

6. Strukturdaten (Teil-Schema, Auflistungshistorie, ...)
7. Inhalt (Ergebnisset, Benutzeranmerkungen, ...)

14.4 Zusätzlich benötigte Funktionalitäten von [VDL Kern-Schnittstelle V.2.0]
14.4.1 VDL Kern-Schnittstellen-Objektaufbewahrung

1) Anforderung 1 – lokaler Backup und Arbeiten Offline [wird für Basis V.2.0 benötigt] Wir benötigen einen Mechanismus, der es dem Benutzer erlaubt, Dinge schnell lokal auf seinem Laptop zu sichern, bevor es ins Flugzeug geht und die nach Wunsch wieder zurück synchronisiert werden können. Die erste Version kann diese Fähigkeit nur bei der privaten Objektaufbewahrungs-Session (privater Ordner) anbieten. Heute ist die über das OSS Import/Export möglich, Sie müssen jedoch ein Admin sein. Deshalb besteht die neue Anforderung darin, dies für einen Benutzer und sein privates Gebiet auszuführen, ohne dass man ein Admin sein muss. Der Teil Backup/Arbeiten Offline wird für VDLBase V 2.0 benötigt.
2) Anforderung 2 – MROW [benötigt für Basis V.1.0] MROW (Multiple Reader, One Writer = Mehrere Leser, ein Schreiber). Dies kann mit dem heutigen OSS erfolgen, ist jedoch nicht hundertprozentig sicher.
Heute müssen Sie: • das Dokument auf schreibgeschützt einstellen (auf Server) • das Dokument von öffentlichem/Gruppengebiet zu einem privaten Gebiet (auf dem Server) kopieren • Lesen, Schreiben einstellen • zu lokal importieren • Dokument modifizieren (von einem Flugzeug und einem Laptop) • das Dokument zurück zum Server exportieren • Schreibschutz einstellen • zu öffentlichem/Gruppengebiet kopieren
3) Anforderung 3 – Gruppenordner [benötigt für Basis V.1.0] VDLBase erfordert eine Gruppe, erstellt von einem Benutzer für eine bestimmte Benutzergruppe Benutzerfall: Ein Benutzer schrieb ein Dokument, um es mit Benutzer B, C und D gemeinsam zu benutzen. Benutzer A geht zur Objektaufbewahrung und erstellt einen Ordner unter der Gruppe. Benutzer A weist Benutzer B, C und D LESEN-SCHREIBEN (oder schreibgeschützt) für den erstellten Ordner zu. Nachdem der Benutzer A gelöscht ist, sollten alle seine erstellten Gruppen verschwinden oder zu einem anderen Besitzer zugewiesen werden [Dies ist das gleiche Paradigma, wie das gemeinsame Benutzen einer Datei mit mehreren Benutzern unter einem Windows-Dateisystem].
4) Anforderung 4 – OSS-Implementation auf einer Datenbank [wird benötigt für Basis V.1.0] Kunden möchten, dass mit dem Formular in der Datenbank umgegangen wird, deshalb muss OSS dies bereitstellen [VDLBase Version 1.0].
5) Anforderung 5 – Ein leichter Weg zum Speichern von Binärem [wird benötigt für Basis V.1.0] Im Moment bestehen im OSS String-Typ-Dokumente fort. VDLBase benötigt einen leichten Weg zum Speichern von Binärem (Bilder, ablauffähige Dateien), ohne dass die Umwandlung von ihnen selbst ausgeführt werden muss.
6) Anforderung 6 – Upload/Download vieler Dokumente auf einmal [wird benötigt für Basis V.1.0] Aus Leistungsgründen muss VDLBase in der Lage sein, mehrere Dokumente auf einmal von der Kern-Schnittstelle abzufragen. Diese Dokumente sollten in einer Sendung durch den SOAP-Server zum .NET API zurück gesendet werden.

14.4.2 VDL Kern-Schnittstellen-Authentifizierung und Lizenzierung

1. Anforderung 1 – Offline [Basisversion V.2.0] Um als nicht netzwerkverbundener Benutzer arbeiten zu können, muss VDL Kern-Schnittstellen-Login einen Caching-Mechanismus bereitstellen, der die zuletzt gecachte Benutzerberechtigung verwendet (so wie Windows dies tut)
2. Anforderung 2 – Multiple VDL Kern-Schnittstellen-Server, ein kohärentes Login [Basisversion 1.0] a. fügen Sie die Wallet, erweiterte Fähigkeit, zur Authentifizierung hinzu. Wenn sich ein Benutzer mit zwei unterschiedlichen VDL Kern-Schnittstellen-Fällen verbindet (zum Beispiel QA und Produktion, wird die Wallet automatisch verbunden. Kontextanfragen werden für die jeweilige Wallet zurückgegeben (oder VDL KERN-SCHNITTSTELLE). b. Für den Fall, dass VDLBase verwendet wird, um zu zwei unterschiedlichen VDL Kern-Schnittstellen-Servern verbunden zu werden, soll eine davon als der primäre oder Master-Fall bestimmt werden. VDLBase-spezifische Autorisierungsinformationen werden nur von diesem primären Fall stammen. Damit werden alle Situationen vermieden, wo VDLBase widersprüchliche Autorisierungsinformationen von zwei oder mehreren Quellen erhält.

14.4.3 VDL Kern-Schnittstellen-Nachrichten-Center [Basis V.1.0]
VDLBase erfordert, dass VDL Kern-Schnittstellen-Nachrichten-Center in der Lage ist, Nachrichten nicht nur an seine eigenen Benutzer, sondern auch an beliebige Gruppen oder Benutzer zu senden. Der Sender kann die Gruppe oder Benutzer definieren. VDL Kern-Schnittstellen-Nachrichten-Center unterstützt dies zur Zeit nicht.
In Bezug auf das Design (und die verfügbaren Ressourcen) ist es sauberer, dies auf der Ebene der VDL Kern-Schnittstellen-Nachrichten-Centers und nicht auf der Ebene der VDLBase zu tun.
14.4.4 VDL Kern-Schnittstellen-SOAP [Basisversion 1.0]

1) Anforderung 1 – Schnell [Basis V 1.0] Die Verbindung zwischen VDL Kern-Schnittstelle-SOAP muss wirklich schnell sein.
2) Anforderung 2 – Vollständig exponierte Kern-Schnittstellen-API [Basis V 1.0] SOAP muss den vollständigen Kern-Schnittstellen-API exponieren • Weiterleiten nach Wert wird benötigt • Ebenso das Weiterleiten nach Referenz
3) Anforderung 3 – Firewall [Basis V 1.0] SOAP-Schnittstelle muss in der Lage sein, eine Firewall zu passieren (sollte kein Problem sein).
4) Anforderung 4 – Automatisches API-Wrapper-Werkzeug [Basis V 1.0] Ein einfaches Werkzeug muss bereitgestellt werden, um einen neuen N+1 Kern-Schnittstellen-Dienst schnell zu umwickeln und auf der .NET Welt zu exponieren

14.4.5 VDL Kern-Schnittstellen-Datenquelle
Für den Import: Kern-Schnittstelle kann einen Speichermechanismus für kleine Datensätze verwenden und muss einen Mechanismus, wie eine temporäre Oracle-Tabelle für große Datensätze verwenden. Einige SD-Dateien können über 500.000 bis 1 Millionen Verbindungen verfügen.

Claims

Computersystem, umfassend: Anzeigekomponente, fähig zur Anzeige eines visuellen Anwendungsdesigns; erste visuelle Programmierungskomponente mit einem exponierten ersten Programmierungsattribut; zweite visuelle Programmierungskomponente mit einem exponierten zweiten Programmierungsattribut; Verbindungselement, fähig zum automatischen Erzeugen eines ersten visuellen Konnektors zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente, basierend auf einer oder mehreren Beziehungen zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente.
System des Anspruchs 1, wobei der erste visuelle Konnektor eine Verbindung ist.
System des Anspruchs 1, wobei der erste visuelle Konnektor weiterhin basierend auf den Input-Daten des Benutzers erzeugt wird.
System des Anspruchs 1, wobei der erste visuelle Konnektor zwischen dem exponierten ersten Programmierungsattribut und dem exponierten zweiten Programmierungsattribut erzeugt wird.
System des Anspruchs 1, wobei der erste visuelle Konnektor als Reaktion auf Daten erzeugt wird, die angeben, dass ein Benutzer die erste visuelle Programmierungskomponente auf die zweite visuelle Programmierungskomponente gezogen hat.
System des Anspruchs 5, wobei der erste visuelle Konnektor das exponierte erste Programmierungsattribut und das exponierte zweite Programmierungsattribut verbindet.
System des Anspruchs 3 wobei der erste visuelle Konnektor als Reaktion auf Daten erzeugt wird, die angeben, dass ein Benutzer einen Mauszeiger von der ersten visuellen Programmierungskomponente auf die zweite visuelle Programmierungskomponente gezogen hat.
System des Anspruchs 7, wobei der erste visuelle Konnektor das exponierte erste Programmierungsattribut und das exponierte zweite Programmierungsattribut verbindet.
System des Anspruchs 3, wobei die zweite visuelle Programmierungskomponente zum visuellen Anwendungsdesign hinzugefügt wird als Reaktion auf eine Benutzereingabe.
System des Anspruchs 1, wobei das exponierte erste Programmierungsattribut einen ersten Komponenten-Pin umfasst.
System des Anspruchs 10, wobei der erste Komponenten-Pin einem Benutzer angezeigt wird.
System des Anspruchs 10, wobei der erste Komponenten-Pin einem Benutzer nicht angezeigt wird.
System des Anspruchs 1, wobei das exponierte zweite Programmierungsattribut einen zweiten Komponenten-Pin umfasst.
System des Anspruchs 13, wobei der zweite Komponenten-Pin einem Benutzer angezeigt wird.
System des Anspruchs 13, wobei der zweite Komponenten- Pin einem Benutzer nicht angezeigt wird.
System des Anspruchs 1, wobei mindestens eine der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente eine Standardkomponente ist.
System des Anspruchs 16, wobei die Standardkomponente nicht ein Mitglied einer bestimmten Klasse ist.
System des Anspruchs 16, wobei die Standardkomponente während der Laufzeit hinzugefügt wird.
System des Anspruchs 1, wobei mindestens eines der: (a) ersten visuellen Programmierungskomponente, (b) zweiten visuellen Programmierungskomponente und (c) ersten visuellen Konnektors während der Laufzeit hinzugefügt wird.
System des Anspruchs 1, außerdem einen zweiten visuellen Konnektor umfassend, wobei der zweite visuelle Konnektor eine erste Benutzerschnittstelle mit mindestens einer einer ersten und einer zweiten visuellen Programmierungskomponente verbindet.
System des Anspruchs 1, wobei jede der exponierten ersten und exponierten zweiten Programmierungsattribute Mitglieder einer bestehenden Plattform sind.
System des Anspruchs 21, wobei die Plattform .NET ist.
System des Anspruchs 1, wobei der erste visuelle Konnektor mindestens eines eines Datenkonnektors und eines Ereigniskonnektors ist.
System des Anspruchs 1, wobei das visuelle Anwendungsdesign mindestens eines ist von: (a) einer Anwendung, (b) einem Formular und (c) eines Arbeitsflusses, der mehrere Formulare umfasst.
System des Anspruchs 1, wobei mindestens eine der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente hinzugefügt werden, indem eine entsprechende Komponente von einer Komponenten-Bibliothek gezogen und auf dem visuellen Anwendungsdesign abgelegt wird.
System des Anspruchs 1, wobei das erste Programmierungsattribut mindestens eines umfasst von: einer Klasse, einem System, einem Element, einer Steuerung, einer Funktion und einem Objekt.
System des Anspruchs 1, wobei das zweite Programmierungsattribut mindestens eines umfasst von: einer Klasse, einem System, einem Element, einer Steuerung, einer Funktion und einem Objekt.
System des Anspruchs 1, außerdem eine Teile-Manager-Komponente umfassend.
System des Anspruchs 28, wobei die Teile-Manager-Komponente fähig ist, das visuelle Anwendungsdesign den Erwartungen eines Benutzers anzupassen.
System des Anspruchs 29, wobei das visuelle Anwendungsdesign basierend auf Heuristik den Erwartungen eines Benutzers angepasst wird.
System des Anspruchs 29, wobei die Teile-Manager-Komponente fähig ist, die Ereignisaktivierung zuzulassen, nachdem ein Schwellwert von Daten bei einer Komponente angekommen ist.
System des Anspruchs 29, wobei die Teile-Manager-Komponente fähig ist, Ereignisse folgerichtig anzuordnen.
System des Anspruchs 28, wobei der Teile-Manager fähig ist, den Transfer von Daten zwischen Komponenten zu verwalten.
System des Anspruchs 33, wobei der Transfer eine "Tiefe zuerst"-Ausbreitung umfasst.
System des Anspruchs 33, wobei der Transfer eine "Breite zuerst"-Ausbreitung umfasst.
System des Anspruchs 1, wobei mindestens eine der ersten visuellen und der zweiten visuellen Programmierungskomponenten eine Flasche ist.
System des Anspruchs 36, wobei die Flasche einen Datenwert speichert und Zugriff auf den Datenwert bietet.
System zur Modifikation eines visuellen Anwendungsdesigns, umfassend: eine erste visuelle Programmierungskomponente mit einer exponierten ersten Programmierungskomponente, wobei die erste visuelle Programmierungskomponente mit einem Mitglied einer ersten Klasse übereinstimmt; einer zweiten visuellen Programmierungskomponente, verbunden mit der ersten visuellen Programmierungskomponente, wobei die zweite visuelle Programmierungskomponente mit einem Mitglied einer zweiten Klasse übereinstimmt, das mit der ersten Klasse verwandt ist; eine modifizierende Komponente, fähig zur Modifikation der ersten visuellen Programmierungskomponente als Reaktion auf Daten, die angeben, dass die zweite visuelle Programmierungskomponente modifiziert worden ist.
System des Anspruchs 38, wobei die erste visuelle Programmierungskomponente als Reaktion auf Daten modifiziert wird, die angeben, dass die zweite visuelle Programmierungskomponente nur modifiziert worden ist, während sich die erste visuelle Programmierungskomponente Anwendungsbereich befindet.
System des Anspruchs 39, wobei die erste visuelle Programmierungskomponente zu einem nicht modifizierten Status zurückkehrt, wenn sich die erste visuelle Programmierungskomponente nicht länger im Anwendungsbereich befindet.
System des Anspruchs 38, wobei die zweite visuelle Programmierungskomponente zum ersten virtuellen Anwendungsdesign als Reaktion auf Daten hinzugefügt wurde, die angeben, dass ein Benutzer die zweite visuelle Programmierungskomponente zum visuellen Anwendungsdesign gezogen und abgelegt hat.
System des Anspruchs 38, wobei die erste visuelle Programmierungskomponente als Reaktion auf Daten modifiziert wird, die angeben, dass ein Benutzer Komponenten von einer Komponenten-Bibliothek gezogen und auf die zweite visuelle Programmierungskomponente abgelegt hat.
System des Anspruchs 38, wobei die modifizierende Komponente fähig ist, die erste visuelle Programmierungskomponente während der Laufzeit als Reaktion auf Daten zu modifizieren, die die zweite visuelle Programmierungskomponente angeben.
System des Anspruchs 38, wobei das visuelle Anwendungsdesign eines ist: (a) eine Anwendung, (b) ein Formular und (c) ein Arbeitsfluss, der mehrere Formulare umfasst.
System zur Anzeige von Datenbankabfragen und Ergebnissen, umfassend: eine Anzeigekomponente, fähig zur Anzeige einer Suchhistorienstruktur die einen oder mehrere Knoten und einen oder mehrere Pfeile umfasst; und eine Abfragekomponente, fähig zum Hinzufügen eines ersten Pfeiles, auf einen ersten Knoten der Suchhistorienstruktur zeigend, wobei der erste Pfeil eine erste Suchabfrage und der erste Knoten Ergebnisse der ersten Suchabfrage darstellen, wobei der erste Pfeil und der erste Knoten zu der Suchhistorienstruktur als Reaktion auf Daten hinzugefügt werden, die angeben, dass ein Benutzer ein Suchelement auf einen zweiten Knoten gezogen hat, der Ergebnisse einer zweiten Suchabfrage darstellt, und wobei die Ergebnisse der ersten Suchabfrage teilweise basieren auf (a) dem Suchelement und (b) den Ergebnissen der zweiten Suchabfrage.
System des Anspruchs 45, wobei die Daten, die angeben, dass ein Benutzer ein Suchelement auf den zweiten Knoten gezogen hat, Daten umfasst, die angeben, dass ein Benutzer einen dritten Knoten, der Ergebnisse einer dritten Suchabfrage darstellt, auf den zweiten Knoten gezogen hat.
System des Anspruchs 46, wobei die Ergebnisse der zweiten Suchabfrage und die Ergebnisse der dritten Suchabfrage logisch kombiniert werden, um die Ergebnisse der ersten Suchabfrage zu produzieren.
System des Anspruchs 47, wobei die Ergebnisse der zweiten Suchabfrage und der Ergebnisse der dritten Suchabfrage basierend auf Daten logisch kombiniert sind, die angeben, dass ein Benutzer mindestens eines ausgewählt hat von: einem logischen ODER, einem logischen UND, einem logischen NICHT, einem logischem NOR und einem logisches NAND.
System des Anspruchs 45, wobei die Daten, die angeben, dass ein Benutzer ein Suchelement auf den zweiten Knoten gezogen hat, Daten umfasst, die angeben, dass ein Benutzer einen zweiten Pfeil, der eine zweite Suchabfrage auf dem zweiten Knoten darstellt, auf den zweiten Knoten gezogen hat.
System des Anspruchs 49, wobei die Ergebnisse der zweiten Suchabfrage modifiziert werden basierend teilweise auf der zweite Suchabfrage, um die Ergebnisse der ersten Suchabfrage zu produzieren.
System des Anspruchs 45, wobei das Suchelement von einer Bibliothek an Suchelementen stammt.
System des Anspruchs 51, wobei das Suchelement mindestens eines ist von: einem Filter, einer Abfrage und einem Suchergebnis.
Computersystem, umfassend: Mittel zur Anzeige eines visuellen Anwendungsdesigns; Mittel zur Anzeige einer ersten visuellen Programmierungskomponente mit einem exponierten ersten Programmierungsattribut; Mittel zur Anzeige einer zweiten visuellen Programmierungskomponente mit einem exponierten zweiten Programmierungsattribut; und Mittel zum automatischen Erzeugen eines ersten visuellen Konnektors zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente, basierend auf einer oder mehreren Beziehungen zwischen der ersten visuellen Programmierungskomponente und der zweiten visuellen Programmierungskomponente.
Computersystem zur Modifikation eines visuellen Anwendungsdesigns, umfassend: Mittel zur Anzeige einer ersten visuellen Programmierungskomponente mit einer exponierten ersten Programmierungskomponente, wobei die erste visuelle Programmierungskomponente einem Mitglied einer ersten Klasse entspricht; Mittel zur Anzeige einer zweiten visuellen Programmierungskomponente, verbunden mit ersten visuellen Programmierungskomponente, wobei die zweite visuelle Programmierungskomponente einem Mitglied einer zweiten Klasse entspricht, das mit der ersten Klasse verwandt ist; Mittel zur Modifikation der ersten visuellen Programmierungskomponente als Reaktion auf Daten, die angeben, dass die zweite visuelle Programmierungskomponente modifiziert worden ist.
Computersystem zur Anzeige von Datenbankabfragen und -ergebnissen, umfassend: Mittel zur Anzeige eines Suchhistorienbaumes, der einen oder mehrere Knoten und einen oder mehrere Pfeile umfasst; und Mittel zum Hinzufügen eines ersten Pfeiles, der auf einen ersten Knoten des Suchhistorienbaumes zeigt, wobei der erste Pfeil eine erste Suchabfrage dar und der erste Knoten Ergebnisse der ersten Suchabfrage darstellen, wobei der erste Pfeil und der erste Knoten zu dem Suchhistorienbaum als Reaktion auf Daten hinzugefügt werden, die angeben, dass ein Benutzer ein Suchelement auf einen zweiten Knoten gezogen hat, der Ergebnisse einer zweiten Suchabfrage darstellt, und wobei die Ergebnisse der ersten Suchabfrage teilweise basieren auf dem Suchelement und den Ergebnissen der zweiten Suchabfrage.