 |
|
SESAM - Simulationssystem
Einführung
Eine Trainingsumgebung für zukünftige Projektmanager (z.B. Studenten) zur Verfügung zu stellen, ist einer der wichtigsten Aspekte des SESAM Projektes: Ein Student wird gebeten, ein simuliertes Projekt entsprechend seinen Fähigkeiten durchzuführen. Infolgedessen war ein flexibler Simulationsmechanismus, der vom Systembenutzer gesteuert werden kann, eine primäre Systemanforderung. Bevor die Modellbeschreibungssprache und die Modellausführung ausführlicher besprochen werden, werden wichtige Grundideen des SESAM Simulationssystems vorgestellt.
Softwareprojekte werden häufig modelliert, indem man den (geplanten oder realen) Verlauf eines Projektes beschreibt. In SESAM jedoch werden Softwareprojekte durch eine Kollektion von Effekten beschrieben, die in den Softwareprojekten geschehen können. Jeder dieser Effekte, z.B. Tätigkeiten, wie ein Review durchführen, nimmt einen bestimmten Einfluss auf das Projekt. Ein SESAM Modell ist im Wesentlichen eine Ansammlung von Regeln, die mögliche Effekte in einem Softwareprojekten beschreiben.
Diese Regeln operieren auf einer globalen Datenstruktur. Die globale Datenstruktur wird als Graph organisiert, der aus Entitäten und Relationen zwischen den Entitäten besteht. Der Graph stellt den Ist-Zustand des simulierten Projektes dar. Regelmäßig überprüft der Simulator, ob Regeln angewendet werden können. Diese Regeln können den Simulationszustand ändern und vielleicht weitere Regeln zum Einsatz bringen. Spezielle Regeln, die Kommandos, erlauben es dem Benutzer, die Simulation zu steuern. Andererseits erhält der Benutzer Informationen vom System (oder kann sie anfordern). Diese Meldungen ermöglichen es ihm, zu verfolgen, wie sich das Projekt entwickelt und abhängig von dem aktuellen Zustand zu reagieren.
Architektur
Das SESAM Simulationssystem ist in der Lage, Modelle auszuführen, die in einer spezifischen Modellsprache formuliert wurden. Das System ist so entworfen, dass die unterschiedlichen Komponenten soweit wie möglich getrennt wurden. Das SESAM System besteht aus drei unterschiedlichen Ebenen. Die erste Ebene unterstützt hauptsächlich den Modellbauer (Model Builder in der Abbildung). Der Modellbauer schreibt ein Modell mit Hilfe der Modellsprache. Dieser Prozess wird durch die Modell-Werkzeuge, die durch das System bereitgestellt werden (z.B. ein Texteditor), unterstützt. Der Modellcompiler übersetzt dieses Modell in eine einfachere, weniger abstrakte Darstellung.
Der Simulator verarbeitet diese vereinfachte Darstellung. Der Ist-Zustand der Simulation wird in einer Datenstruktur dargestellt, die als Zustand bezeichnet wird. Technisch wird der Zustand als annotierten Graph dargestellt, und der Regelteil ist eine erweiterte Graphgrammatik (siehe Melchisedech, 1996). Der Simulator identifiziert alle Subgraphen, die mit irgendeiner der linken Seiten der Grammatik übereinstimmen, und ersetzt sie durch die entsprechenden rechten Seiten und/oder ändert die Attributwerte. Interaktionen sind einfach Regeln, die angewendet werden müssen, wenn die Kommandos wirklich erteilt worden sind. Die Simulationszeit wird in Modell-definierten diskreten Zeitschritten fortgeschalten, z.B. ein Tag oder eine Stunde.
Die Interpreter-Komponente bietet schließlich eine (eingeschränkte) natürlich-sprachliche Kommunikation zwischen dem Kursteilnehmer und dem System an. So wird der Kursteilnehmer nicht auf eine vorbestimmte Kommandosyntax eingeschränkt. Der Interpreter bildet Benutzereingaben auf den Kommandos ab und gibt Meldungen an den Benutzer aus.
Zusätzlich notiert der Simulator den Verlauf des simulierten Projektes und schreibt ein Projektlogbuch mit. Dieses Projektlogbuch wird analysiert, nachdem die Simulation beendet worden ist. Ein Lehrer (oder Tutor) hilft, die Simulationsresultate zu interpretieren und auszuwerten.
Simulator - Modellinterpreter
Der SESAM Simulator besteht hauptsächlich aus einem diskreten Ereignissimulator und einem Automaten zum Vergleichen und Verändern von Graphen. Der interne Zustand des Spiels wird als typisierte und attributierte Graphstruktur implementiert, die aus Knoten und Kanten besteht, die SESAM-Entitäten und SESAM-Relationen darstellen. Die Struktur des Graphen wird durch das SESAM Schema eingeschränkt.
Am Anfang der Simulation wird das Situationsmodell in ein Ausgangsgraphen umgewandelt. Während die Simulation fortfährt, werden Benutzerkommandos und Regeln angewendet. Eine Regel ist anwendbar, wenn (1) mindestens ein Subgraph, der zum Strukturteil der Regel isomorph ist, in dem Graph gefunden werden kann, und (2) die Attributwerte des Subgraphen mit dem Bedingungteil der Regel übereinstimmen.
Wenn eine Regel anwendbar ist, können Instanzen der Regel erstellt und ausgeführt werden. Eine Regelinstanz erstellen bedeutet, dass die formalen Entitäten der Regel an die entsprechenden Entitäten des Subgraphen gebunden werden. Wenn mehr als ein isomorpher Subgraph existiert, kann mehr als eine Regelinstanz der selben Regel gebildet werden. Die Entitäten, die an die Regelinstanz gebunden sind, identifizieren eindeutig die Regelinstanz. Eine Regel auszuführen bedeutet, dass die Aktionen, die im Aktionseil der Regel beschrieben werden, an den gebundenen Entitäten durchgeführt werden. Mögliche Aktionen sind: Erstellen und Löschen von Entitäten, Erstellen und Löschen von Relationen und Ändern von Attributwerte. Dasselbe gilt für Benutzerkommandos.
Beim Anwenden von Regeln und Benutzerkommandos, wird Simulationszeit verbraucht (d.h. die Simulationszeit erhöht sich). Benutzerkommandos werden vom Spieler, Regeln werden von der Simulationszeit ausgelöst. In jedem Simulationszeitschritt wird ein Regel-Anwendungszyklus durchgeführt. Regeln mit hoher Priorität werden vor Regeln mit niedrigerer Priorität angewendet. In jedem Anwendungszyklus kann jede Regel höchstens einmal ausgeführt werden. Der Zeitschritt (z.B. 1 Stunde, 1 Tag) kann vom Modellbauer gewählt werden.
Die folgende Abbildung beschreibt den Simulationsalgorithmus. 
Simulator - Benutzungsschnittstelle
Simulieren eines Modells
Bis jetzt ist ein Prototyp der Simulatorbenutzerschnittstelle, der in Tcl/Tk geschrieben ist, vorhanden. Diese Komponente ist ein Front End zum Interpreter und zum Simulator. Menüs erlauben dem Spieler, den Simulator zu konfigurieren, indem sie Modelle laden, Simulationszustände laden und speichern und Optionen setzen. Kommandos können eingegeben werden und werden vom Interpreter interpretiert. Die Modell-Simulationsausgabe wird in dem Hauptfenster dargestellt.
Die folgende Abbildung zeigt den "Load Model" Dialog. Der Spieler hat qs_mittel_400_a.b2 selektiert und auf "Open" geklickt. Das Modell wird geladen und das Anfangsdatum der Simulation wird in dem Hauptfenster ausgegeben. Per Konvention haben die Modelldateien, die vom Simulator ausgeführt werden können, die Extension .b2 (steht für Base-2 Modell).
Dem Spieler wird eine Einleitung zum Projekt, das er führen soll, gegeben und und anschließend kann er Kommandos eingeben. Kommandos sind in die untere linke Box an der Unterseite des Fensters mit der Beschriftung "Enter User Command:" einzugeben. Wenn der Interpreter in der Lage ist, ein zugelassenes Kommando im Simulationsmodell zu finden, das zur Benutzereingabe passt, wird das Kommando ausgeführt. Ausgaben der ausgeführten Kommandos werden in dem Hauptfenster dargestellt. Z.B. möchte der Spieler, dass ein Entwickler namens Axel zu spezifizieren begint. Er trägt "ask Axel to specify" in das Kommandoeingabefeld (wie in der folgenden Abbildung gezeigt) ein und drückt Return. Der Interpreter wiederholt die Eingabe (Großbuchstaben) im Hauptfenster, findet zu diesem Kommando das passende Modell-Kommando und lässt es durch den Simulator ausführen. Die Ausgabe der vorhergehenden Kommandos wird in der folgenden Abbildung gezeigt. Der Spieler hat Axel angestellt und ließ ihn mit dem Kunden sprechen. Dem Spieler wird sowohl mitgeteilt, dass er sich zur Sitzung begibt, als auch dass er von der Sitzung zurückkommt, in beiden Fällen mit der genauen Zeitangabe , in denen die Ereignisse eintraten. Im Beispielmodell wird der Zeitschritt auf einen Tag eingestellt, also sind die Stunden und die Minuten der gegebenen Daten immer dieselben. Offensichtlich dauerte die Sitzung mit dem Kunden einen Tag.
Der untere rechte Button "Proceed one step" und das Eingabefeld namens "Proceed ... steps" können verwendet werden, wenn der Spieler wünscht, dass die Zeit vergeht ohne Kommandos einzugeben. Dies ist nützlich, wenn alle Entwickler Anweisungen bekommen haben, die eine längere Zeit dauern und das Einzige, was der Manager zu tun hat, zu warten ist. Weil das Fortfahren einen Simulationsschritt auslöst, werden Regeln angewendet, die den Simulationszustand ändern, was zu zusätzlicher Ausgabe führen kann.
Den Modellzustand browsen
Normalerweise wird der aktuelle Modellzustand vor dem Spieler versteckt, während er/sie spielt (d.h. einkommende Kommandos). Für Analysezwecke ist eine Browser-Komponente für den aktuellen Modellzustand (genannt ZARMS = Zustandsanalyse und Regel-Monitor für SESAM) vorhanden. Der Zustand besteht aus Entitäten und Relationen, deren entsprechende Typen das erste Level eines klassischen Baum-Bildes zeigen (links). Wenn Entitäten oder Relationen vorhanden sind, werden sie als Kindknoten ihres entsprechenden Typs dargestellt. Eine Entität oder eine Relation kann selektiert werden. Dann werden seine Eigenschaften (Attribute/Rollen) in der rechten Spalte angezeigt.
Im Beispiel, das in der folgenden Abbildung gezeigt wird, wird der Entwickler Axel selektiert. Seine Attribute werden angezeigt, z.B. die täglichen Kosten von DM 80,0 oder die Tatsache, dass er angestellt wurde.
ZARMS enthält auch einen Regel-Monitor, der alle Regelinstanzen anzeigt, die bis jetzt ausgeführt worden sind. Dieser Monitor hilft, zu erklären, warum sich das Modell in einer bestimmten Weise verhält und ist für die Fehlersuche und -behebung im Modell extrem wertvoll. Der Regel-Monitor wird durch das Klicken der "Rules" Schaltfläche aktiviert.
Entwicklungsaufwand für den Simulator
| Projektaufgabe |
Personal |
Zeitabschnitt |
Aufwand |
Ergebnisse |
|
|
|
|
|
| 76 Seiten | Spezifikation-Dokument |
| 6231 LOC | Prototyp |
|
| Definition des Projektwörterbuches |
|
|
|
|
| 14 Seiten | Begriffsglossar |
| 128 Begriffe | |
|
|
|
|
|
|
| 40 Seiten | Designgrundprinzip |
| 717 LOC | Spezifikation von 8 Subsysteme |
| 2063 Zeilen | Ergänzende Kommentare |
|
| Definition der Arbeitsumgebung |
|
|
|
|
|
|
|
|
|
|
| 78 Seiten | 5 Feinentwurf-Dokumente |
| (Spezifikationen von 62 Ada Packages) |
|
|
|
|
|
|
| Koordination der Änderungen zwischen Subsysteme |
|
|
|
|
|
|
| 18320 LOC | 74 Ada Packages |
| 4374 LOC | Ada Code generiert mit |
| 2060 LOC | AYacc/AFlex-Code |
|
|
|
|
|
|
| 9149 LOC | Zusätzlicher Testcode |
|
|
|
|
|
|
|
|
|
|
|
|
| 31 | Fehler |
| 9 | Änderungsanforderungen |
|
| Fehlersuche und Korrektur |
|
|
|
|
| Erste Version des Simulators |
|
|
|
|
|
|
| 306 Seiten | Dokumentation |
| 36477 LOC | Programm Code |
|
| CT: | core team member |
| MS: | student working on master thesis |
| RS: | research assistant |
| PR: | programmer |
| MD: | man day (1 MD = 8 working hours) |
| LOC: | lines of non-blank, non-comment lines of code |
|
|