Zur Webseite der Informatik

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

ProjektaufgabePersonalZeitabschnittAufwandErgebnisse
Spezifikation
1 CT
1 MS
43/1995 - 10/1996
70 MD
76 Seiten Spezifikation-Dokument
6231 LOC Prototyp
Definition des Projektwörterbuches
1 CT
27/1996 - 39/1996
26 MD
14 Seiten Begriffsglossar
128 Begriffe
Architektur Entwurf
1 CT
32/1996 - 51/1996
39 MD
40 Seiten Designgrundprinzip
717 LOC Spezifikation von 8 Subsysteme
2063 Zeilen Ergänzende Kommentare
Definition der Arbeitsumgebung
2 CT
18/1996 - 3/1997
77 MD
98 Seiten 5 Richtlinien
Feinentwurf
5 CT
2 RS
03/1997 - 16/1997
57 MD
78 Seiten 5 Feinentwurf-Dokumente
(Spezifikationen von 62 Ada Packages)
Designkoordination
1 CT
03/1997 - 19/1997
17 MD
Koordination der Änderungen zwischen Subsysteme
Implementierung
5 CT
2 RS
07/1997 - 18/1997
86 MD
18320 LOC 74 Ada Packages
4374 LOC Ada Code generiert mit
2060 LOC AYacc/AFlex-Code
Modul Test
5 CT
2 RS
13/1997 - 23/1997
61 MD
9149 LOC Zusätzlicher Testcode
Integration
1 CT
24/1997 - 25/1997
8 MD
Integriertes System
System Test
1 CT
1 PR
40/1997 - 09/1998
21 MD
31 Fehler
9 Änderungsanforderungen
Fehlersuche und Korrektur
5 CT
40/1997 - 09/1998
21 MD
Erste Version des Simulators
Total
8 Personen
43/1995 - 09/1998
482 MD
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