Constraints

Die populärste Definition von Constraint ist:

Ein Constraint ist eine Relation, die einmal deklariert und dann automatisch vom System aufrecht erhalten wird.

Die Systemkomponente, die für die Aufrechterhaltung der Relation verantwortlich ist, wird Constraintsolver genannt. Hier drei Beispiele für Constraints:

• Wenn der Wert der Variablen 'x' kleiner als 100 ist, wird der Bildschirmhintergrund rot.
• Es gibt zwei Textfelder. Im ersten steht englischer Text, im zweiten deutscher. Ein Englisch-Deutsch-Constraint wird deklariert, so daß bei der Änderung des Textes in einem der beiden Felder das andere die entsprechende Übersetzung enthält.
• Ein Rechteck 'F' bleibt immer innerhalb eines Rechtecks 'G'. (RectInRect)

Das erste Beispiel ist ein sogenanntes gerichtetes Constraint. Der Constraintsolver muß nur die Variable 'x' beobachten. Wenn der Benutzer die Hintergrundfarbe manuell ändern kann, kann er nicht sicher sein, daß der Wert von 'x' kleiner als 100 ist. Das zweite Constraint ist ungerichtet. Es zeigt auch die mögliche Komplexität eines Constraints. Im dritten Beispiel wird ein grafisches Constraint deklariert.

Grafische Constraints

Grafische Constraints sind Relationen, die sich auf das grafische Aussehen von Objekten auf dem Bildschirm beziehen. Im Beispiel RectInRect werden die Koordinaten des linken unteren Eckpunktes des Rechtecks 'x' und 'y' sowie seine Breite 'width' und Höhe 'height' benutzt, um die Relation zu definieren. Das Constraint kann dann als Liste von Gleichungen und/oder Ungleichungen definiert werden:

F.x > G.x
F.x + F.width < G.x + G.width
F.y > G.y
F.y + F.height < G.y + G.height

Immer, wenn sich eines der Rechtecke 'F' oder 'G' bewegt oder seine Größe ändert, kontrolliert der Constraintsolver die Relationen und ändert, falls nötig, eine der anderen Variablen so, daß die grafische Relation wieder eingehalten wird.

Einige weitere Beispiele:

• PointEqual - eines der bekanntesten Constraints. Es legt fest, daß zwei Punkte den selben Platz einnehmen.
• RectOutsideRect - ein Rechteck darf ein anderes nicht überlappen.
• CircleTouchesCircle - zwei Kreise haben mindestens einen Punkt gemeinsam.

Objection benutzt den Constraintsolver Parcon von Peer Griebel.

Anwendungsspezifische Widgets

Standardisierte Widgets (= graphische Grundelemente) wie PushButtons, Scrollbars, Texte und FileSelectionBoxes sind Teil der OSF/Motif-Widget-Menge. Sie erleichtern die Entwicklung einer graphischen Benutzungsschnittstelle. Anwendungsroutinen können durch das Auslösen von Ereignissen (wie das Betätigen eines PushButtons) aufgerufen werden und Anwendungsdaten können mit Hilfe von Text-Widgets, ToggleButtons oder ListBoxes auf standardisierte Weise dargestellt und verändert werden.

Aber ... wenn der Schnittstellen-Designer eine anwendungsspezifischere Art der Darstellung und Veränderung von Anwendungsdaten bevorzugt, erhält er keine Unterstützung. Zu diesen anwendungsspezifischeren Darstellungsformen gehören alle möglichen Arten von Diagrammen: SA/SD/RT-Diagramme und Structured Charts (CASE), Petrinetze, Nassi-Shneiderman-Diagramme, Ablaufpläne und allgemeine Netzwerkdarstellungen sind nur einige Beispiele.

Objection unterstützt genau diese Art der Entwicklung von graphischen Benutzungsschnittstellen. Der Schnittstellen-Designer kann damit neue Widget-Klassen entwerfen und ihr Verhalten definieren. Zur Definition des graphischen Verhaltens der Objekte auf dem Bildschirm werden graphische Constraints verwendet.

Elemente und Editoren

Die Abbildung oben zeigt die Komponenten von Objection. Manche von ihnen helfen bei der Definition neuer applikationsspezifischer grafischer Elemente (ASGE). Für jedes ASGE wird eine neue Interaktionsklasse definiert. Mit dem OutfitEditor kann das grafische Erscheinungsbild des ASGE definiert werden. Der ClassEditor wird benutzt, um die Attribute und Methoden einer neuen Interaktionsklasse zu ändern. Im Simulator kann die neue Interaktionsklasse sofort getestet werden. Man kann grafische Constraints benutzen, um grafische Beziehungen zwischen ASGEs auf dem Bildschirm zu definieren. Der Interaktive ConstraintEditor (ICE) hilft dem Interface-Designer, das neue grafische Constraint interaktiv zu entwerfen. Wenn die Entwicklung einer neuen Interaktionsklasse abgeschlossen ist, erzeugt der CodeGenerator Source Code.

Der Constraint Solver und das GxToolkit sind Laufzeitkomponenten. Der Constraint Solver ist für die Aufrechterhaltung der Beziehungen, die durch grafische Constraints definiert wurden, verantwortlich. Das GxToolkit stellt einen allgemeinen Mechanismus für die direkte Manipulation von ASGEs zur Verfügung.