Die Theorie hinter den Modellen

OpenSAGA verfolgt eine Reihe von Zielen, die sich auch in der Art und Weise widerspiegeln, in der die Modelle entworfen sind. Primäre Ziele für die Gestaltung der Modelle war

• diese zum zentralen Arbeitsartefakt zu machen, d.h. dass Entwickler ausschließlich Modelle und Strategie-Interfaces implementieren, aber keinen Zugriff auf generierten Code haben. Die Arbeit erfolgt also rein modellgetrieben.
• eine möglichst technologie-unabhängige Beschreibungsform für die integralen Bestandteile von Webanwendungen und Portalen zu finden,
• eine möglichst hohe Abstraktionsebene zur Beschreibung anzubieten,
• eine Top-Down-Entwurfssystematik zur schrittweisen Beschreibung komplexer Zusammenhänge zu ermöglichen und
• die Modelle so zu gestalten, dass eine Technologie-Evolution möglich wird, ohne dass Anwendungen neu geschrieben oder weitreichend geändert werden müssen.

Der Idealzustand, den wir mit den Modellen anstreben, sieht wie folgt aus:

• Technologische Details werden in den Modellen nicht beschrieben. Der Generator liefert die notwendigen und sinnvollen Implementierungsdetails “hinter den Kulissen”.
• Die Modelle sind rein deklarativ – es wird soweit irgend möglich das “Was?” beschrieben, nicht aber das “Wie?”
• Die Modelle beschränken sich darauf, Probleme einer Domäne möglichst gut zu beschreiben. OpenSAGA fokussiert sich daher auf webbasierte Anwendungen.
• Die Modelle sollen sich auf einer Abstraktionsebene bewegen, die auch für Fachexperten ohne IT-Kenntnisse anwendbar sind.

Die OpenSAGA-Modelle folgen aber auch einer Reihe von “agilen Entwurfsprinzipien” (frei nach Scott Ambler und Agile Modeling), um möglichst einfach und schnell Ergebnisse zu liefern:

• Wir streben nicht an, die Welt in jedem Detail beschreiben zu können. Ist ein Sachverhalt äußerst komplex, ist es besser, ihn in einem abstrakten Modell zu kapseln als ihn in umfangreichen und schwer verständlichen Detailmodellierungen zu beschreiben. Beispiel: Man könnte eine komplexe Auswahlhilfe für Eingabefelder mit Eingabe- und Recherchemöglichkeiten detailliert über Zustandsübergänge, jedes einzelne Steuerelement, usw. beschreiben – es reicht aber auch, ein Modell für “Eingabefelder mit Auswahlhilfen” anzubieten, das die wesentlichen Zusammenhänge beschreibt (Auswahl worauf? Welche Auswahlmöglichkeiten? Usw.)
• Wir modellieren jeweils in der geeignetsten Form. Beispiel: Es macht keinen Sinn, komplexe SQL-Statements noch einmal in einer XML-basierten abstrakten Sprache zu verbergen – wenn SQL die richtige Modellierungsebene ist, muss sie nutzbar sein.
• Wir bemühen uns um eine leichte Abbildung von/auf UML. UML lässt Vieles missen, was für den Entwurf von benutzergesteuerten Anwendungen essentiell ist (Navigationen, Masken, usw.) – daher haben wir uns für eine eigene Modellsprache entschieden.
• Wenn eine individuelle Ausprägung von bestimmten Sachverhalten sinnvoll ist, bieten wir an geeigneter Stelle ein minimales Strategie-Interface an, über das eine Individualprogrammierung in das generierte System injiziert werden kann.

Zusammenfassend liefert OpenSAGA eine modellbasierte und technologie-abstrahierende domänenspezifische Sprache für webbasierte Anwendungen und Portale.