Kooperative Objektinteraktionsdiagramme in Eclipse

Transcrição

Diplomarbeit
Kooperative Objektinteraktionsdiagramme in
Eclipse
von
Petra Kösters
Am Turnplatz 25
33098 Paderborn
Matrikelnr. 7175558
Angefertigt am
Lehrgebiet Kooperative Systeme
Prof. Dr. Jörg Haake
der FernUniversität Hagen
Betreuer:
Dr. Till Schümmer
April 2007
Selbstständigkeitserklärung
Hiermit versichere ich, dass ich diese Arbeit selbstständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate
kenntlich gemacht habe.
Paderborn, im April 2007
__________________
i
Inhaltsverzeichnis
Abbildungsverzeichnis............................................................................................ ii
1 Einleitung ............................................................................................................. 1
1.1 Motivation..................................................................................................... 1
1.2 Zielsetzung der Arbeit................................................................................... 2
1.3 Kurzer Überblick über den weiteren Aufbau ................................................ 3
2 Anforderungsanalyse............................................................................................ 4
2.1 Lehre von Objektorientierten Konzepten...................................................... 4
2.1.1 Herausforderungen in der Fachdidaktik................................................. 6
2.1.2 Anforderungen im didaktischen Kontext ............................................. 12
2.2 Entwicklung von objektorientierten Systemen ........................................... 16
2.2.1 Der Rational Unified Process............................................................... 16
2.2.2 Agile Softwareentwicklung.................................................................. 17
2.2.3 Die Unified Modeling Language ......................................................... 19
2.2.4 Anforderungen im Kontext der OO-Entwicklung ............................... 24
2.3 Kooperationsaspekte in Lehre und Entwurfsprozessen .............................. 26
2.3.1 Groupware............................................................................................ 28
2.3.2 Technische Anforderungen .................................................................. 30
3 Stand der Forschung........................................................................................... 34
3.1 Beschreibung existierender Lösungsansätze............................................... 35
3.1.1 Konzeptionelles Szenario-Rollenspiel ................................................. 35
3.1.2 Lehr-/Lernanwendungen ...................................................................... 37
3.1.3 UML-Modellierungs-Tools.................................................................. 41
3.2 Gegenüberstellung von Lösungsansätzen und Anforderungen................... 44
4 Lösungsansatz .................................................................................................... 49
4.1 OO-Lehre: Szenario und Lösungsdarstellung............................................. 50
4.2 OO-Entwicklung: Szenario und Lösungsdarstellung.................................. 57
4.3 Konzeptionelle Lösung der technischen Anforderungen............................ 64
4.3.1 Technischer Überblick und Architektur............................................... 65
4.3.2 Verwendete Patterns und ihr Zusammenspiel...................................... 70
5 Details zur Lösung ............................................................................................. 74
5.1 Signifikante Implementierungsdetails......................................................... 74
5.2 Erfahrungen / Evaluation ............................................................................ 78
6 Zusammenfassung.............................................................................................. 79
6.1 Kurzfassung des Problems und wie es gelöst wurde .................................. 79
6.2 Offene Fragen für weitere Forschungsarbeiten........................................... 79
Quellenverzeichnis................................................................................................ 81
ii
Abbildungsverzeichnis
Abbildung 2.1 Die Klasse Mietwagen und zwei ihrer Objekte .............................. 5
Abbildung 2.2 – Rollenspiel im Informatikunterricht, Gaußschule Braunschweig,
aus [C’t 10/06, S.210] ................................................................................... 12
Abbildung 2.3 Beispiel für die Klassen-Notation in UML................................... 21
Abbildung 2.4 – Beispielhaftes Klassendiagramm ............................................... 22
Abbildung 2.5 – Objektdiagramm, passend zum Klassendiagramm in Abb.
Abbildung 2.4................................................................................................ 22
Abbildung 2.6 – Kommunikationsdiagramm entsprechend des Klassendiagramms
in Abb. Abbildung 2.4................................................................................... 23
Abbildung 2.7 – Sequenzdiagramm, äquivalent zum Kommunikationsdiagramm
in Abbildung 2.6 ........................................................................................... 24
Abbildung 2.8 - Das 3K-Modell nach Teufel et al. [Teu95]................................. 28
Abbildung 2.9 – Aus [SL07]: Einordnung von Groupware-Systemen bzgl. ihrer
Unterstützung der 3Ks................................................................................... 29
Abbildung 3.1 – Hauptklassen der Marine Biology Simulation Case Study (aus
[Brady05]) ..................................................................................................... 35
Abbildung 3.2 - Aufzeichnung eines CRC-Karten- Rollenspiel in einem RPD (aus
[Bör05])......................................................................................................... 37
Abbildung 3.3 – BlueJ: Hauptfenster und Quelltext-Editor (aus[BlueJ07])......... 38
Abbildung 3.4 – Alice: User-Interface (aus [Haa04])........................................... 39
Abbildung 3.5 ViRPlay : Screenshot der Benutzeroberfläche (aus [Diaz05a]).... 41
Abbildung 3.6 – Borland Together for Eclipse: User-Interface............................ 42
Abbildung 3.7 – ArgoUML: Hauptfenster............................................................ 43
Abbildung 3.8 – Hauptfenster von Rational Rose ................................................ 44
Abbildung 4.1 – COINED Benutzeroberfläche .................................................... 49
Abbildung 4.2 - MBCS-Beispielszenario ............................................................. 51
Abbildung 4.3 – Aktivierung der COINED-Perspektive in Eclipse ..................... 51
Abbildung 4.4 – Login und Projektwechsel.......................................................... 51
Abbildung 4.5 – Die BuddyListe aus Alices Sicht: .............................................. 52
Abbildung 4.6 – Rollenzuordnungen im ClassView............................................. 52
Abbildung 4.7 – Editieren von Objektdetails im ObjectView: Alice ist im Begriff,
dem Attribut theEnv des Objekts theMBSDemo einen Wert zuzuweisen . 53
Abbildung 4.8 - Visualisierung des aktiven Objekts und der letzten Nachricht... 53
Abbildung 4.9 – MessageProcessingView unmittelbar vor dem Senden von
init(2,2) an loc .................................................................................... 54
Abbildung 4.10 Protokollierter Nachrichtenfluss am Ende des durchgespielten
Szenarios ....................................................................................................... 55
Abbildung 4.11 –Autovermietung: Use Cases und CRC-Karten ......................... 58
Abbildung 4.12 – ChatView: Joe, Jack, Jill und John besprechen die
Rollenverteilung............................................................................................ 59
Abbildung 4.13 – Autovermietung: Initialisierte Objekte .................................... 60
Abbildung 4.14 – Autovermietung: Initiierung, Bearbeitung und Darstellung der
ersten Nachricht ............................................................................................ 60
Abbildung 4.15 Nachrichtenhistorie und Diagramm am Ende des Szenarios ...... 62
Abbildung 4.16 – Codegenerierung: Assistent und Java-Perspektive mit
generierten Klassen-Stubs............................................................................. 62
Abbildung 4.17 – Schematische Darstellung von COINEDs Architektur............ 65
iii
Abbildung 4.18 – Ablauf bei einer Datenänderung .............................................. 66
Abbildung 5.1 – Exemplarisch für die Umsetzung der DB-Schnittstelle
CMessageMapper, CMessage, IMessage...................................................... 75
Abbildung 5.2 – Paketstrukturen von COINEDs Client und Server..................... 76
Abbildung 5.3 – COINEDs Activator-Klasse....................................................... 76
Abbildung 5.4 – Alle Messaging und Listener Klassen........................................ 77
Abbildung 5.5 – Die Modell-Klassen ................................................................... 77
1 Einleitung
1
1 Einleitung
1.1 Motivation
Die objektorientierte Programmierung (OOP) hat sich gegenüber der reinen
prozeduralen Vorgehensweise als der bessere Ansatz erwiesen – besonders im
Zusammenhang mit großen Software-Projekten. Die Grundidee der
objektorientierten Programmierung ist es, einen Ausschnitt der realen Welt in
einem Programm abzubilden. OOP ist ein Klassifizieren von Problemen, weniger
eine Beschreibung der Aktionen (dies ist Hauptgegenstand der prozeduralen
Programmierung). Im Resultat liefert OOP vor allem die Möglichkeit, viel Code
wieder zu verwenden und saubere Schnittstellen zu programmieren, was die
Möglichkeit von Programmierfehlern erheblich einschränkt. Dennoch bedarf es
zusätzlicher Toolunterstützung um gerade komplexe Software-Projekte zu
unterstützen. Auch für die Vermittlung des OO-Paradigmas an Anfänger sind
entsprechende Werkzeuge erforderlich.
Diese Arbeit beschäftigt sich einerseits mit der Frage, wie man sowohl lokale als
auch verteilte Teams bei der gemeinsamen OO-Modellierung technologisch
unterstützen und so den Prozess des Systementwurfs erleichtern und verbessern
kann. Andererseits geht es um die Frage, wie eine Anwendung aussehen muss, die
die verteilte und lokale Lehre von OO Paradigmen adressiert.
In der Modelling-Szene herrscht allgemeiner Konsens darüber, dass OO-Analyse
und Design idealerweise in kooperativen Gruppensitzungen mit Teilnehmern
unterschiedlicher Expertise (Entwickler, Anwender, Systemanalytiker, etc)
stattfinden sollte. Ein praktischer Ansatz, ein solches Team beim kooperativen
Entwicklungsprozess (genauer: bei der Entwicklung und Verfeinerung des
Domänenmodells) zu unterstützen ist es, mit CRC-Karten und Rollenspielen zu
arbeiten. Eine CRC (Class Responsibility Collaborator)-Karte repräsentiert eine
spätere Klasse, darauf notiert sind Name, Zuständigkeiten, und die Namen der
anderen Klassen, die sie referenzieren können soll. Das Team erstellt und
diskutiert zunächst die voraussichtlich benötigten CRC-Karten. Die Karten
werden unter den Teammitgliedern aufgeteilt. Dann wird ein kleines BeispielSzenario durchgespielt. Das Szenario beschreibt eine mögliche Anwendung des
zu entwickelnden Systems. Jedes Teammitglied übernimmt die Rolle seiner CRCKarten und handelt entsprechend der eingetragen Zuständigkeiten. Das
Rollenspiel wird von einem Schriftführer in einem Rollenspiel-Diagramm (RPD)
festgehalten. RPDs sind eine spezielle informale Diagramm-Variante, die sich aus
Elementen von UML-Objekt- und Kommunikationsdiagrammen zusammensetzt.
Das Rollenspiel hilft dem Team dabei, eine genauere Vorstellung des zu
entwickelnden Systems zu bekommen. Es kristallisiert sich Schritt für Schritt ein
in sich schlüssiges Analyse-Modell der Problem-Domäne heraus.
In der Lehre geht es auf der anderen Seite darum, Studierenden die Konzepte der
OOP möglichst anschaulich zu vermitteln. Es ist offensichtlich das, dass o.g.
Rollenspiel-Szenario auch in diesem Kontext gut eingesetzt werden kann. Dabei
nehmen die Studierenden die Rolle von Objekten ein und spielen den
Nachrichten- und Programmfluss durch. Das Rollenspiel ermöglicht ihnen auf
intuitive Weise Objektinteraktionen nachzuvollziehen und die Abläufe in
objektorientierten Programmen begreifen.
1 Einleitung
2
Bei beiden anvisierten Einsatzmöglichkeiten geht es also letztlich darum, ein OODesign zu visualisieren und die am Entwurf beteiligten Individuen auf
komfortable Weise miteinander interagieren zu lassen. Dafür gibt es bislang kaum
bzw. nur sehr unzureichende Unterstützung durch Tools, insb. was den
Kooperationsaspekt angeht.
Im Rahmen der Arbeit soll daher erstmalig ein kooperativer, synchroner
Mehrbenutzer-Editor für RPDs in Form eines Eclipse-Plugins konzipiert und
implementiert werden. Der Editor soll lokale und verteilte Teams bei der
Entwicklung von Domänenmodellen unterstützen. Gemeinsam (zur gleichen Zeit
an verschieden Orten) editieren die Teammitglieder Klassen und Objekte (kein
Java Code, sondern in einer formlose Notation) in einem gemeinsamen Projekt
und simulieren interaktiv die Objektinteraktion an einem Diagramm. So gewinnen
sie Erkenntnisse über die benötigten Objekte und Methoden. In Anlehnung an
Rollenspiele mit CRC-Karten übernehmen Benutzer die Rolle von Objekten. Sie
„spielen“ sequentiell und interaktiv verschiedene konkrete Anwendungen des
entworfenen Systems in verschiedenen Szenarien durch. Es gibt zu einem
Zeitpunkt immer genau ein aktives Objekt, das die Kontrolle hat und dessen
Besitzer agieren muss. Wenn der Kontrollfluss bei einem Objekt ankommt, muss
der Benutzer, der für dieses Objekt zuständig ist, die Arbeit des Objekts
ausführen, z.B. Zuweisungen/Berechnungen ausführen, selbst Nachrichten an
andere Objekte schicken, etc. Danach gibt er, u. U. mit einem Returnwert, die
Kontrolle an das aufrufende Objekt zurück. Der Editor stellt die benötigten
Werkzeuge zum informalen Erstellen von Klassen, Objekten und Nachrichten zur
Verfügung. Die Kommunikation wird im Diagramm und in einer
Nachrichtenhistorie protokolliert. Ein Hauptaugenmerk des Editors soll auf der
Synchronizität liegen, der aktuelle Stand muss bei allen Clients synchron
aktualisiert werden. Weiterhin werden die, in kooperativen Anwendungen
üblichen, Elemente zur Unterstützung des Gruppenbewusstsein (Buddyliste incl.
Online-Status, UserIcons zur Visualisierung von Rollen) erwartet. Des Weiteren
soll der Editor die Möglichkeit der Code-Generierung bieten. Aus den formlosen
Klassen/Objekten sollen dann per Knopfdruck Klassen-Stubs in Java generiert
werden. Es sollen die programmatischen Grundsteine gelegt werden, um in einer
späteren Ausbaustufe, aus einem durchgespielten Szenario einen JUnit-Test-Case
generieren zu können.
1.2 Zielsetzung der Arbeit
Die Zielsetzung dieser Arbeit ist die Konzeption und die Implementierung eines
synchronen Mehrbenutzereditors für die interaktive Entwicklung von Objektinteraktionsdiagrammen. Eine Gruppe von Anwendern soll kooperativ die Objektinteraktionen in einem benutzerdefinierten Domänenmodell simulieren und
explorieren können. Die Anwendung soll lokales und verteiltes Rollenspiel
unterstützen, bei dem die einzelnen Anwender jeweils das Verhalten einer Menge
von Objekten simulieren.
Es ist genauer zu untersuchen, welche Anforderungen an die Anwendung sich aus
dem Einsatz in unterschiedlichen Kontexten ergeben. Zum einen soll der Editor
als unterstützende Maßnahme zur Vermittlung objektorientierter Konzepte, insb.
der dynamische Aspekte in objektorientierten Programmen, also Objektinteraktion
mittels Message Passing, in der Lehre einsetzbar sein.
1 Einleitung
3
Zum anderen soll die Anwendung verteilte Teams in der Entwurfsphase der
objektorientierten Softwareentwicklung unterstützen. Die Anwendung soll das
Explorieren der Problemdomäne ermöglichen. So soll das Verständnis der
Anwender für das System gefördert und eine Verfeinerung des Klassenmodells
ermöglicht werden. Das Hauptaugenmerk liegt auch in diesem Kontext auf den
dynamischen Aspekten, dem Verhalten des Systems. Darüberhinaus soll das
System als konkreten Mehrwert für den Anwender die Möglichkeit bieten, aus
dem entworfenen Klassenmodell Source-Code zu generieren. Die Anwendung
soll als Eclipse-Plugin realisiert werden.
1.3 Kurzer Überblick über den weiteren Aufbau
In Kapitel 2 findet sich eine detaillierte Anforderungsanalyse für den oben
angerissenen Problembereich. Dabei untersuchen wir zunächst in 2.1 die
Anforderungen, die sich für den Einsatz einer Anwendung in der
objektorientierten Lehre ergeben. Dazu führen wir kurz in die Konzepte der
Objektorientierung ein, untersuchen gängige Lehrmethoden und ermitteln daraus
eine Menge von didaktischen Anforderungen. 2.2 beleuchtet den Einsatz in einem
anderen Kontext, hier werden die Anforderungen, die sich für den Einsatz einer
Anwendung im OO-Entwicklungsprozess.ergeben, hergeleitet. Dazu geben wir
am Beispiel des Rational Unified Process und am Beispiel des Agile Devolopment
eine Einblick in Softwareentwicklungsmethoden, insb. den Analyseprozess, und
ermitteln daraus eine Reihe von Entwicklungssanforderungen. 2.3 beschäftigt sich
mit dem Groupware-Aspekt – hier werden die technischen Anforderungen
aufgezeigt, die daraus resultieren, dass die Anwendung kooperativ von verteilten
und lokalen Benutzern genutzt werden soll. Der Begriff Groupware wird
vorgestellt und der geplante Rollenspiel-Charakter der Anwendung wird
eingeordnet.
Kapitel 3 liefert einen Überblick über den Stand der Forschung, es werden
vergleichbare Ansätze aus dem didaktischen Kontext und dem
Entwicklungskontext aufgezeigt und bzgl. der Anforderungen eingeordnet.
In Kapitel 4 wird der im Rahmen dieser Arbeit konzipierte und implementierte
Lösungsansatz COINED vorgestellt und den Anforderungen der drei Bereiche
jeweils im Detail gegenübergestellt. Beispielszenarien illustrieren den Einsatz von
COINED im didaktischen und im Entwicklungs-Kontext (4.1 und 4.2). In 4.3
gehen wir auf die Erfüllung der technischen Anforderungen ein. Wir geben einen
technischen Überblick über COINED, stellen die verwendete Architektur vor und
beschreiben die Zusammenhänge mit speziellen Groupware-Entwurfsmustern.
Kapitel 5 gibt Aufschluss über einige signifikante Implementierungsdetails und
bisherige Erfahrungen.
Kapitel 6 liefert eine abschließende Zusammenfassung und erörtert offene Fragen
für weiterführende Arbeiten.
2 Anforderungsanalyse
4
In diesem Kapitel werden die genauen Anforderungen hergeleitet. Diese sind
dann jeweils in den Unterabschnitten 2.1.2, 2.2.4 und 2.3.2 zusammengefasst.
2.1 Lehre von Objektorientierten Konzepten
Hinter dem Begriff „Objektorientierung“ steckt die Idee, die Welt als eine
Sammlung von Objekten und ihren Beziehungen zu verstehen. Objekte können
sowohl Gegenstände (Auto, Kunde, Haus), als auch nicht-gegenständliche
Konstrukte (Konto, Flug, Reise) sein. Sie können wiederum aus anderen Objekten
zusammengesetzt sein, z.B. besteht ein Auto aus Rädern, Karosserie, Motor, usw.
Ein reales Objekt, komplett in all seiner Detailtiefe betrachtet, kann sehr komplex
und unüberschaubar sein. Deshalb arbeitet man in objektorientierten
Entwurfstechniken und Programmiersprachen mit vereinfachten, abstrahierenden
Modellen von realen Objekten. Modelle bilden die Realität ausschnitthaft und aus
einem bestimmten, dem Problembereich angepassten, Betrachtungswinkel ab. Ein
modelliertes Objekt fokussiert dann die relevanten Eigenschaften des Originals,
alle uninteressanten Details werden vernachlässigt. Für die Kundenverwaltung
einer Autovermietung wäre es z.B. wichtig, das Alter und Führerscheinstatus
eines Kunden zu kennen, Anzahl und Namen seiner Kinder spielen dagegen keine
Rolle.
Die in der Software abgebildeten Objekte sind durch ihre Identität, ihren
Zustand und ihr Verhalten charakterisiert. Der Zustand beschreibt die statischen
Eigenschaften eines Objekts mit Hilfe von Attributen. Ein Attribut legt den Typ
einer Eigenschaft fest. Der Zustand bildet eine Momentaufnahme des Objekts und
wird durch die Attributwerte eines Objekts und durch seine Verbindungen zu
anderen Objekten zu einem bestimmten Zeitpunkt definiert. Ein Objekt ist per
Definition unabhängig von seine Attributwerten und Operationen identifizierbar
und eindeutig von anderen Objekten abgrenzbar. Zwei Objekte, die denselben
Zustand besitzen, deren Attribute also gleiche Werte haben, sind immer noch zwei
verschiedene, eindeutig unterscheidbare, Objekte.
Mit Verhalten bezeichnet man die Fähigkeit von Objekten, Zustandsänderungen
durchzuführen, also ausgewählte Eigenschaften zu verändern. Hierfür stellt das
Objekt Methoden zur Verfügung, deren Aufruf in Form des Sendens einer
Nachricht geschieht
Den Programmablauf in einem objektorientierten Programm kann man sich nun
folgendermaßen vorstellen: eine Menge von Objekten interagiert miteinander,
indem die Objekte sich Nachrichten senden und selbst auf empfangene
Nachrichten reagieren. Objekte kommunizieren also per Nachrichtenaustausch
und teilen sich auf diese Weise mit, was zu tun ist. Ein Objekt kann nur auf die
eigenen Daten (Attribute) direkt zugreifen. Wenn nun also ein Objekt von einem
fremden Objekt Daten benötigt, wird eine Nachricht an dieses Objekt geschickt.
Dabei bedeutet „eine Nachricht an ein Objekt schicken“, dass ein anderes Objekt
aufgefordert wird, eine seiner Methoden auszuführen.
Um eine Nachricht an ein bestimmtes Objekt senden zu können, muss ein Objekt
das andere erst „kennen“, es muss eine Beziehung zu diesem Objekt haben.
Beziehungen sind nicht unbedingt bidirektional, um eine Antwort auf eine
5
Nachricht zu senden, muss z.B. das antwortende Objekt den Aufrufer nicht
explizit kennen.
Die dynamischen Eigenschaften eines Objekts (Verhalten) werden also durch
seine Operationen beschrieben, während die statischen Eigenschaften (Zustand)
von seinen Attributen repräsentiert werden.
Eng verknüpft mit dem Objektbegriff ist das Konzept der Klasse. Eine Klasse ist
die Typbeschreibung für eine Menge von Objekten mit gleicher Struktur,
gleichem Verhalten und gleichen Beziehungen. Sie dient als Schablone oder
Bauplan aus dem zur Laufzeit die Objekte erzeugt werden können. Objekte
werden synonym auch als Instanzen oder Exemplare einer Klasse bezeichnet1. Mit
Definition von Attributen und Operationen werden die gemeinsame Struktur, die
Beziehungen zu anderen Objekten und das gemeinsame Verhalten für alle Objekte
festgelegt, die zu dieser Klasse gehören. Alle Objekte einer Klasse besitzen
dieselben Attribute, im Allgemeinen jedoch unterschiedliche Attributwerte. Ein
Objekt ist immer ein Exemplar von genau einer Klasse.
Abbildung 2.1 Die Klasse Mietwagen und zwei ihrer Objekte
In Abbildung 2.1 sind wagen1 und wagen1 Exemplare der Klasse Mietwagen und
besitzen jeweils konkrete Werte für die Attribute kennzeichen und istVermietet.
Die Attributwerte können über die Operationen mieten(), istVermietet() und
getKennzeichen() manipuliert, bzw. abgefragt werden.
Das in der objektorientierten Programmierung (OOP) verfolgte Paradigma basiert
auf mehreren fundamentalen Konzepten, wobei die Fachwelt durchaus
unterschiedliche Auffassungen über Nennung und Wichtigkeit der verschiedenen
Konzepte vertritt. In [Arm06] findet sich hierzu eine umfassende Auswertung der
entsprechenden Fachliteratur. Deborah Armstrong identifiziert und beschreibt dort
zusammenfassend die Konzepte (sie spricht von Quarks), die in fast allen OOPDefinitionen verwendet werden. Diese Quarks sind Objekt, Klasse, Vererbung,
Kapselung, Methode, Message Passing, Polymorphismus und Abstraktion.
Einiges hiervon wurde bereits oben im Text besprochen (Objekt, Klasse,
Methode, Message Passing, Abstraktion). Die restlichen Konzepte spielen im
Rahmen dieser Arbeit keine entscheidende Rolle, sie seien dennoch, der
Vollständigkeit halber, im Folgenden kurz angerissen.
•
1
Kapselung: Klassen fassen Attribute und Operationen zu einer Einheit
zusammen, die Attribute sind von außen nicht sichtbar. Manipulationen an den
Englisch instance. In der deutschen OO-Literatur früher oft ungenau mit Instanz übersetzt. Heute
findet sich häufig der adäquatere Begriff Exemplar.
•
•
6
Attributen sind nur indirekt über genau definierte Schnittstellen, die
Operationen, möglich. Man sagt, eine Klasse kapselt ihre Attribute. Das
Prinzip der Datenkapselung ermöglicht u.a. die Definition eindeutiger
Schnittstellen, ein Aspekt, der bei der Wiederverwendung von Klassen in
verschiedenen Programmen eine wichtige Rolle spielt. Darüber hinaus sorgt
die Kapselung dafür, dass Klassen leicht verändert und erweitert werden
können, ohne dass andere Klassen stark betroffen werden.
Vererbung: Objekte können Methoden und Attribute erben oder vererben.
o Generalisierung/Spezialisierung
o Super-/Subtypen
o Einfach-/Mehrfachvererbung
o Abstrakte Klassen
Polymorphismus: Methoden mit gleichem Namen können je nach Kontext
unterschiedliche Semantik besitzen. Man unterscheidet
a) dynamischen Polymorphismus (Überschreiben von Methoden,
ermöglicht durch „spätes Binden“): Unterklassen können geerbte
Methoden überschreiben und so neu definieren.
b) statischen Polymorphismus (Überladen von Methoden): eine Methode
kann innerhalb einer Klasse mehrfach definiert werden, sofern die
Signaturen eindeutig sind. Beim Aufruf wird die entsprechende
Methode dann anhand der Parameterliste identifiziert.
Das Verständnis der hier vorgestellten Prinzipien des OO Paradigmas ist essentiell
für die Entwicklung von effizienten, objektorientierten Programmen. Die
Vermittlung des Paradigmas an Anfänger erfordert spezielle Unterrichtsmethoden,
mit Methoden aus der Lehre der prozeduralen Programmierung lässt sich das
kaum erreichen. Das wird z.B in [Bru05] im Abschnitt „The object-oriented
paradigm requires a new way of thinking – and teaching“ diskutiert. Im
Folgenden werden wir die gängigen Unterrichtsmethoden für OOP genauer
betrachten und die Herausforderungen an die Fachdidaktik ermitteln.
2.1.1 Herausforderungen in der Fachdidaktik
In der Literatur finden sich viele Stimmen, die einen objects-first Ansatz für die
Lehre von OOP propagieren, siehe z.B. [Coo03]. Objects-first konfrontiert den
Lernenden von Anfang an mit den Prinzipien des objektorientierten Entwurfs. Der
Lernende setzt sich gleich zu Beginn mit Objekten, Klassen und Methoden
auseinander, traditionellere Kontrollstrukturen werden erst später eingeführt.
Cooper erwähnt in seiner Beschreibung der Herausforderungen von objects-first
den Zuwachs an Komplexität, den diese Strategie für Lehre und Lernen mit sich
bringt. Er stellt fest, dass klassische Programmiereinführungen, bei denen man mit
einfachen Beispielprogrammen startet und nach und nach zu komplexeren
Programmen kommt, eine flachere Lernkurve haben. Dass die objects-first
Methodik nach wie vor ein umstrittener Gegenstand ist, kann man z.B. [Bru05]
entnehmen, worin Kim Bruce einen Überblick über die diesbezügliche Diskussion
gibt.
Schmolitzky [Schmo07]formuliert einige kontroverse Thesen, welche die
gängigen Ansätze und Methoden der Fachwelt, Programmieranfänger in die
objektorientierte Programmierung einzuführen, kritisieren. Der Artikel
verdeutlicht, dass bzgl. der besten/richtigen Methoden auch heute noch, nachdem
OOP längst in die Programmierausbildung an den Hochschulen eingeflossen ist,
7
immer noch Diskussionsbedarf besteht. Laut Schmolitzky rühren viele Probleme
daher, dass die eng beieinander liegenden Bereiche objektorientierte
Modellierung (OOM) und OOP zu stark vermischt werden. Er sieht die OOP als
sehr mechanisch orientiert und auf programmiersprachlichen Konzepten
aufsetzend, während die OOM für ihn eine Sicht auf die Welt darstellt, die von
der Beschreibung von Anwendungsdomänen bis hin zum Entwurf von
Softwaresystemen reicht. Schmolitzky stellt im Übrigen fest, dass der Einstieg in
die OOP heutzutage überwiegend mit Hilfe von Java gelehrt wird - er selbst hält
Java nicht für die ideale Anfängersprache, aber sieht sie als „die am wenigstens
schlechte der zur Auswahl stehenden objektorientierten Sprachen“.
Im Folgenden wollen wir einige der, laut Autor bewusst überspitzt formulierten,
Thesen, die für diese Arbeit relevant sein könnten, herausgreifen:
• „Objekte haben Namen“: Die Kritik ist in der Tat angebracht, denn wie
der Autor sagt, aus Sicht der OOP sind dynamisch erzeugte Objekte
anonyme Einheiten, die keine Namen haben. Dennoch scheint es gerade
bei der Arbeit mit Rollenspielen sinnvoll, den Objekten explizite Namen
zu geben. Die Kommunikation der Akteure untereinander wird erheblich
schwieriger, wenn anonyme Objekte zugelassen werden und die Objekte
nicht über einen Namen angesprochen werden können. Auch wird die
Identifikation eines Objekts in verschiedenen Kontexten einer Anwendung
(Objekt-Repository, Interaktions-Historie, Visuelle Repräsentation)
erschwert. Hier muss also im Zweifel abgewogen werden, ob die erhöhte
Usability das Risiko der Verwirrung aufwiegt. In jedem Fall sollte die
Anwendung den Begriff „Name“ nicht nachlässig und widersprüchlich
verwenden, damit Anwender unterscheiden können, ob ein Objektname,
ein Namengebendes Attribut oder eine Instanzvariable gemeint ist.
• „Objekte enthalten Objekte“
• „Wir beginnen mit Objekten ohne Methoden (reinen Datenobjekten), da
dies einfacher ist“
• „Wir benutzen Java zu Anfang rein funktional, um Zustände möglichst
spät einzuführen“
Im Rahmen dieser Arbeit ist die Simulation von Objekt-Interaktionen in Form von
Rollenspielen und die Visualisierung in Form von RPDs geplant, die letzten drei
Punkte von Schmolitzky stellen also hier keine Gefahr dar, weil wir sie von
vorneherein ausschließen.
Es gibt eine Reihe von Lehr-/Lernanwendungen, die objects-first unterstützen. Sie
können im Unterricht in der Einführungsphase eingesetzt werden und erleichtern
Anfängern den Einstieg in die Programmierung nach dem OO-Paradigma. Wie in
[Bru05] aufgezeigt wird, lassen sich die meisten dieser Anwendungen grob in eine
der folgenden Kategorien einordnen:
•
•
•
pädagogische IDEs,
Mikrowelten
Java-Tool-Sammlungen mit pädagogischer Ausrichtung
Die, laut [Diaz05b] am häufigsten zitierte, pädagogische IDE ist BlueJ. Einen
vergleichenden Überblick über BlueJ und seine Methodik findet man z.B in
[Köl03]. BlueJ ist eine, speziell als Lehr- und Lernanwendung konzipierte,
8
integrierte Java Entwicklungsumgebung. Das User-Interface ist übersichtlich und
einfach gehalten. Der Benutzer beginnt eine Sitzung üblicherweise mit einer
Menge von vordefinierten Klassen, die in einer UML-ähnlichen, graphischen
Darstellung visualisiert werden. Der Benutzer kann direkt mit den Icons
interagieren und so aus einer Klasse Objekte erzeugen und von diesen Objekten
Methoden ausführen lassen. Diverse Evaluierungen bestätigen, dass die Arbeit mit
BlueJ den Anwendern das Erlernen der OO-Basiskonzepte Objekt, Klasse,
Methode erheblich erleichtern kann, nicht zuletzt aufgrund der Möglichkeit,
Objekte interaktiv aus Klassen zu erzeugen und interaktiv Methoden aufzurufen,
[Haa04][Rag05][Köl03]. In [Rag05] wird allerdings auch gezeigt, dass BlueJ auf
der anderen Seite Schwierigkeiten macht, wenn es darum geht, die dynamischen
Aspekte von OOP zu vermitteln. Vorteile, die die statische Visualisierung der
Klassen/Objekte für frühe Lernphasen hat, können in späteren Phasen, bei der
Transition von individuellen Objekten zu ganzen Programmen, zu Nachteilen
werden.
Weitere Beispiele für pädagogische IDEs, die ebenfalls eine direkte Interaktion
mit Objekten erlauben, sind BeanShell und DrJava. Beide Systeme sind Java
Interpreter, die die interaktive Ausführung einer Folge von Java Anweisungen
über ein Kommandozeilen-Interface ermöglichen.
Als exemplarische Vertreter für die Kategorie der Mikrowelten seien „Karel J.
Robot“ [Berg04] und Alice[Dan03, Coo03] genannt. Laut Bruce [Bru05] bedeutet
Programmieren im Kontext einer Mikrowelt üblicherweise, Anwender
manipulieren eine Menge von Objekten, bzw. interagieren mit diesen Objekten
und illustrieren so die Schlüsselkonzepte der OOP. Bei Karel J. Robot werden
z.B. Objekte durch Roboter symbolisiert, die in ihrer Welt (einem 2D Gitter)
positioniert werden. Auf den Robotern können Methoden aufgerufen werden,
welche die Roboter bewegen, drehen und den Umgang mit Artefakten steuern
(beepers können aufgenommen und herumgetragen werden).
Alice ist eine für Programmieranfänger entwickelte Programmierumgebung für
die Erstellung von interaktive 3D-Graphiken und Animationen. Für die
Repräsentation von Objekten verwendet Alice eine anthropomorphe Metapher.
Der Anwender bevölkert eine kleine virtuelle Welt mit 3D-Objekten. Jedes Objekt
kapselt seine eigenen Daten und verfügt über seine eigenen Methoden. Ein Objekt
kann per Drag&Drop in einen Editor gezogen werden. In dem Editor können
Aussehen und Verhalten geändert und über Dropdown-Menüs können primitive
Methoden ausgewählt werden, mit denen dann eine Nachricht an das Objekt
geschickt werden kann. In [Coo03] werden die konkreten Auswirkungen des
Einsatzes von Alice im Unterricht untersucht. Demnach hilft die visuelle
Umgebung von Alice den Lernenden ein sicheres Gefühl für Objekte zu
entwickeln. Die interaktiven Methodenaufrufe auf Objekten fördern das
Verständnis für Kapselung und für Methoden bzw. Message Passing.
Die dritte Kategorie von Lehranwendungen sind Java-Tool-Sammlungen, die
darauf ausgerichtet sind, Anfängern das Programmieren zu vereinfachen. Sie
bringen vereinfachte, für Anfänger leicht zu nutzende, Features, wie z.B. GUI
Komponenten, oder eine Menge fertiger Klassen in Form von Bibliotheken mit.
Hierzu zählen z.B. die Java Power Tools (JPT) oder Grafikbibliotheken, wie sie in
[Bru01] und [Rob01] vorgestellt werden. Bei den beiden letzteren arbeitet man
mit einer Art Leinwand, auf die die Objekte z.B. als 2D-Shapes gezeichnet
9
werden. Auf diesen Objekten können Methoden aufgerufen werden, worauf die
Objekte dann entsprechend reagieren müssen.
Mit den hier vorgestellten Anwendungen lassen sich einige OO-Basiskonzepte gut
vermitteln. Das bestätigen die oben im Text zu den jeweiligen Anwendungen
aufgeführten Quellen, die neben den Beschreibungen teilweise auch
Auswertungen enthalten.
Es lassen sich eine Mechanismen erkennen, die sich offensichtlich gut zur
Umsetzung der Basiskonzepte eignen. Zum Beispiel kann die Möglichkeit des
direkten, interaktiven Objektzugriffs das Verständnis für den Objektbegriff an
sich und für das Konzept der Kapselung fördern (findet sich in allen oben
genannten Anwendungen). Wenn ein Anwender Objekte direkt aus einer Klasse
erzeugen kann, kann das das Verständnis für den Zusammenhang von
Klasse/Objekt erleichtern (BlueJ). Visualisierung und Animation macht
Programmflüsse klarer (Alice). Die Möglichkeit interaktiv auf einem Objekt
Methoden aufzurufen, bzw. Nachrichten zu verschicken erleichtert das
Verständnis der Konzepte Methode und Message Passing (bei alle genannten).
Dynamik in objektorientierten Programmen
Im Rahmen dieser Arbeit steht die Unterstützung und Visualisierung von
Objektinteraktionen, also den dynamischen Aspekten objektorientierter
Programme im Vordergrund, deswegen wird in diesem Abschnitt einmal genauer
untersuchen, auf welche Weise sich diese Aspekte Anfängern am besten
vermitteln lassen. Objektinteraktionen in OOP erfolgen in Form von Message
Passing.
Laut Jimenez-Diaz et al. [Diaz05a] müssen Anfänger begreifen, dass innerhalb
von OOP Message Passing ein Synonym für die Funktionalität einer Anwendung
ist - Eine Klasse hat einen konkreten Nutzen und Nachrichten, die diese Klasse
bearbeitet, definieren das Verhalten der Klasse. Eine Aktivität in einem OOSystem wird durch eine Nachricht von einem Objekt an eine anderes initiiert. Die
Nachrichtenübermittlung transferiert den Kontrollfluss von einem Objekt zum
nächsten und die Bearbeitung der Nachricht wird aller Wahrscheinlichkeit nach
den Zustand des Objekts verändern. Deswegen stellt der Ansatz von Jimenez-Diaz
et al. [Diaz05a] die Vermittlung des Message Passing-Konzepts in den
Vordergrund und unterstreicht u.a. mit folgender Aussage noch weiter die
Wichtigkeit des Verständnisses der Lernenden für diese elementare OO-Konzept:
“Another key idea from message passing is the functional decomposition. [..] the
chained execution of several methods is the way to deal with complex
functionality. To do that, the learner should understand that the classes are
related among them not only by composition or inheritance but also by use”
In der Literatur finden sich nun viele Hinweise darauf, dass Anfänger Probleme
haben, die dynamischen Aspekte und die Interaktionen in objektorientierten
Programmen zu verstehen und ihnen demnach eben gerade das Konzept des
Message Passing Schwierigkeiten bereitet. Die Fallstudie von Ragonis und BenAri [Rag05] zeigt z.B. die konkreten Probleme, die Studenten beim Arbeiten mit
BlueJ mit dem Begreifen der Dynamik eines Programms/des Programmflusses
hatten.
10
Es lässt sich ganz allgemein sagen, dass Dynamik in der OOP eine größere
Herausforderung für Anfänger darstellt als in der prozeduralen Programmierung,
so stellen z.B. Dann et al. [Dan03] die grundsätzliche Behauptung auf „Behavior
is more complicated than method/functions in an imperative language“.
Ein wichtiges Anliegen einer pädagogischen Anwendung für die Einführung in
OOP muss also die Vermittlung von dynamischem Verhalten bzw. Message
Passing sein.
Dynamisches OO-Verhalten anhand von statischen Repräsentationen zu begreifen
ist schwierig. Es ist offensichtlich, dass sich dynamische Abläufe besser nachvollziehen lassen, wenn sie in einer entsprechenden Form visualisiert oder gar
animiert werden. Zum Thema Visualisierungstechniken lässt sich allgemein
sagen, dass der Einsatz einer Visualisierung allein üblicherweise nicht
ausreichend ist - die Visualisierung sollte vielmehr den Lernende aktiv mit in das
Geschehen einbeziehen:
„Visualization technology is of little educational value unless it engages the
learners in an active learning activity“, vgl. [Naps02]
Auch von Andrianoff und Levine [And02] wird angeführt, dass Aktivitäten, die
Studenten aktiv mit einbeziehen (im Gegensatz zum passiven Zuschauen/-hören)
im Allgemeinen zu einer besseren Vermittlung des zu lernenden Material führen.
Der Forderung nach der aktiven Beteiligung der Lernenden wird die Methode des
Rollenspiels, gerecht. Dementsprechend finden sich auch mehrere Quellen, die
Ansätze vorschlagen, in denen Rollenspiele zur Vermittlung von OO-Konzepten
im Allgemeinen und von Message Passing im Besonderen eingesetzt werden
([And02], [Diaz05a], [Bör04])
Im folgenden Abschnitt befassen wir uns genauer mit Rollenspielen als genereller,
pädagogischer Methode und wir betrachten den möglichen Einsatz im Kontext der
objektorientierten Lehre.
Rollenspiel
Außerhalb des Informatik-Kontexts werden in Rollenspielen oft reale
Lebenssituationen simuliert, Rollenspiele dienen in diesem Zusammenhang zur
Vermittlung von sozialen Fähigkeiten. Die Akteure sollen ihre sozialen
Handlungskompetenzen erweitern, indem sie eine bestimmte Rolle übernehmen
und in dieser Rolle kritische Situationen in der simulierten Realität anspielen.
Firmen nutzen Rollenspiele um Mitarbeiter zu schulen oder Bewerber zu testen,
indem
sie
Job-typische
Szenarien
wie
Verkaufsgespräche
oder
Kundenreklamationen durchspielen lassen. Auch Führungsrollenspiele in denen
komplexe Führungs- und Arbeitsprozesse simuliert werden sind üblich.
Rollenspiele stellen eine aktive Lernform dar. Die Teilnehmer werden zu
Akteuren, die miteinander agieren.. Der Freiheitsgrad, der den einzelnen Akteuren
gewährt wird, kann variieren (vgl.[And02]). So gibt es z.B. auf der einen Seite das
freie Rollenspiel ohne konkrete Vorgaben, auf der anderen Seite aber auch
geskriptetes Szenario-Rollenspiel, wobei die Rollen, ihr Verhalten und das zu
spielende Szenario klar vorgegeben sind.
11
Technische Unterstützung von sozialen Rollenspielen gibt es u.a. in Form von
kollaborativen, web-basierten Umgebungen. Ein Beispiel für eine solche Umgebung ist Fablusi [Fab], eine Online-Rollenspiel-Simulations-Plattform mit der
sich beliebige dynamische Rollenspiele erzeugen lassen
Wie sieht es nun mit dem Einsatz von Rollenspielen in der Informatik aus?
Andrianoff und Levine [And02] stellen fest, dass das Rollenspiel bereits seit
vielen Jahren (mindestens seit 1987) in der Informatik-Ausbildung vorkommt. Sie
führen verschiedene Ansätze an, in denen Rollenspiele als Unterrichtsmethode für
verschiedene Bereiche der Informatik vorgeschlagen werden, u.a. für Hardware
Design, Formale Methoden und Backtracking, aber eben auch für den OOEntwurf. Bzgl. letzterem heißt es, Rollenspiele könnten hilfreich dabei sein,
Intuition für das Verständnis von OO-Design aufzubauen. Das ist nun gerade im
Rahmen dieser Arbeit interessant.
Das Potenzial von Rollenspielen in der OOP unterstreichen auch Bergin et al. in
[Berg04] – sie haben Rollenspiele in ihre Liste der Paedagogical Pattern
eingearbeitet. Bergin et al. [Berg04] sehen, dass der Mensch sich als eine gute
Metapher für Objekte eignet,
"In teaching object systems, a good metaphor is human beings. People are
autonomous, encapsulated actors, who interact with other similar objects."
Sie führen weiter aus, dass ein Lernender, wenn er die Rollen in einem Szenario
versteht, auch entsprechend weiß, wie und mit wem er interagieren kann. Er
erkennt schnell, was er nicht verstanden hat.
Wie solche Rollenspiele nun konkret aussehen können, zeigen Andrianoff und
Levine in [And02]. Hier werden verschiedene Rollenspiel-Szenarien mit
unterschiedlicher Komplexität für die Vermittlung verschiedener OO-Konzepte
vorgestellt. Es wird jeweils aufgeführt, inwiefern die einzelnen Rollenspiele mit
bestimmten OO-Konzepten korrellieren. U.a wird für die Vermittlung von
Objektinteraktionen ein Rollenspiel aus der Marine Biology Case Study (MBCS)
vorgeschlagen, ein Beispiel, an dem sich auch eines der, im Rahmen dieser Arbeit
beschriebenen Anwendungsszenarien, orientiert (s. 4.1). Im Rahmen solcher
Rollenspiele übernehmen die Mitglieder einer Gruppe die Rolle von Objekten,
und simulieren Nachrichtenfluss und -bearbeitung durch Interaktion mit anderen
Akteuren/Objekten. So gewinnen sie Erkenntnisse über die Abläufe des
objektorientierten Systems.
Die natürliche Art des Rollenspiels ist die physische, also die face-to-face
Variante – Schüler stehen in der Gruppe zusammen, tragen jeweils Post-Its mit
ihren Objektnamen und simulieren Aktionen durch „Aussprechen“, Assoziation
durch Anfassen, Kontrollfluss z.B. durch das Werfen eines Balls. Das Foto in
Abbildung 2.2 zeigt eine solche reale Unterrichtssituation
12
Abbildung 2.2 – Rollenspiel im Informatikunterricht, Gaußschule Braunschweig, aus [C’t
10/06, S.210]
Auf der anderen Seite gibt es auch virtuelle Rollenspiele – Schüler arbeiten am
Rechner und übernehmen die Rolle von antropomorphisierten Objekten in einer
virtuellen Welt (Beispiel Alice, Karel J. Robot, ViRPlay vgl. 2.1.1).
Das virtuelle Rollenspiel bringt Vor- und Nachteile gegenüber dem physischen
Rollenspiel mit sich. Ein Softwaresystem kann die Möglichkeit bieten, die
ansonsten eher flüchtigen Informationen zu speichern. So ließen sich u.a. Objekte
speichern und Objektinteraktionen und Nachrichtenfluss persistent protokollieren,
auch Replay-Funktionen wären denkbar. Je nach Darstellungsform kann die
Repräsentation der Visualisierung zu Dokumentationszwecken wieder verwendet
werden.
2.1.2 Anforderungen im didaktischen Kontext
In diesem Abschnitt gehen wir darauf ein, was genau von den Anfängern in der
OOP falsch verstanden kann und welchen Umgang mit den Artefakten im
Rahmen einer didaktischen Anwendung das impliziert, bzw. welche
Anforderungen sich für die Anwendung ergeben.
Die Studie von Noa Ragonis [Rag05] identifiziert anhand konkreter Beispiele
einige Schwierigkeiten, die Anfänger mit objektorientierten Programmen haben.
Die Studie basiert zwar auf dem Einsatz von BlueJ, die Autoren sind allerdings
der Meinung, dass die Ergebnisse nicht notwendigerweise BlueJ-spezifisch sind
und die identifizierten Probleme auch in anderen Umgebungen auftauchen
können. Folgenden Schwierigkeiten wurden benannt:
•
•
•
•
•
•
•
Objektzustand: Anfänger haben Schwierigkeiten, zu verstehen, welchen
Einfluss der Aufruf einer Methode auf den Objektzustand hat.
Methodenaufruf: Schüler haben nicht sofort verstanden, dass eine
Methode jederzeit und mehrfach aufgerufen werden kann.
Parameter: Anfänger haben Probleme, zu verstehen, wo Parameterwerte
herkommen
Rückgabewerte: Anfänger verstehen nicht, wo der Rückgabewert einer
Methode hingeht.
Input Instructions: Anfänger verstehen die Notwendigkeit nicht.
Konstruktoren: Anfänger verstehen die Zusammenhänge zwischen
Deklaration, Aufruf, und Ausführung von Konstruktoren nicht.
„The overall picture of execution“: Anfänger haben Schwierigkeiten den
globalen Programmfluss auszumachen, die Frage „Was passiert und
wann“ tauchte immer wieder auf.
13
Es ist offensichtlich, dass sich hier viele Punkte um das Konzept des Message
Passing drehen. Eine entsprechende Anwendung muss hier also ansetzen und
Klarheit bzgl. Nachrichten, Methodenaufrufen und Programmfluss schaffen. Es
muss möglich sein, auf Objektebene zu arbeiten, Einblick in die Objektzustände
zu bekommen und Attributwerte zu manipulieren. Es muss möglich sein,
interaktiv von Objekten Nachrichten zu versenden, und Parameter zu belegen. Der
Programmfluss muss visualisiert werden. Mit einer rollenspielartigen Simulation
der Objektinteraktionen könnten einige der erwähnten Punkte geklärt werden.
Zum einen sollte in einer solchen Simulation der globale Programmfluss klar
werden, zum anderen dürften damit auch die Fragen bzgl. Rückgabewerten,
Parametern, und Auswirkungen auf Objektzustände klar werden
In Dann et al. führen in [Dan03] an, dass der Begriff des Zustands schwierig zu
vermitteln ist, nicht zuletzt wegen der Unübersichtlichkeit der
Darstellungsformen:
„State is challenging, because objects require the use of the program heap for
implementation. Drawing traditional memory maps to explain objects, variable
scope, and how methods work requires both a stack and a heap.[...] confusing
clutter of arrows and boxes on the board[…].”
Eine entsprechende didaktische Anwendung muss also Objektzustände in einer
übersichtlichen Darstellungsform präsentieren.
Die folgende Tabelle fasst die Implikationen, die sich im dem Umfeld der
Didaktik auf den Umgang mit Artefakten ergeben, zusammen.
DA11 Benutzerinteraktionen auf Objektebene
Die Lernenden sollen ein allgemeines Verständnis für die Grundidee der
Objektorientierung, das Konzept des Objekts, entwickeln. Hierfür ist es
erforderlich, dass die Anwendung Objektstrukturen visualisiert und die
Benutzerinteraktion auf Objekt-Level zulässt. Anwender müssen Klassen
definieren und aus diesen Klassen Objekte erzeugen können. Es muss möglich
sein, Einblick in Objektzustände zu verschiedenen Zeitpunkten nehmen zu
können und Objektzustände ggf. manuell, durch Manipulation von
Attributwerten, ändern zu können. Dadurch erlangt der Anwender nicht nur über
die benötigten Objekte, sondern auch über deren Struktur, also die benötigten
Attribute, Klarheit. Entsprechende Interaktionsmöglichkeiten mit Objekten, wie
bspw. die Manipulation von Attributwerten, das Initiieren neuer Nachrichten,
oder der Empfang und die Bearbeitung von Nachrichten, können Lernende dabei
unterstützen, Einblick in grundlegende OO-Konzepte wie Objekte und Message
Passing zu gewinnen.
DA2
Kapselung
Wenn das System Rollen unterstützt, sollte dafür gesorgt werden, dass jeder
Benutzer nur in die Instanzen der Klasse, deren Rolle er übernommen hat, hinein
schauen kann. Nur der Rolleninhaber darf die Attribute seiner Objekte direkt
manipulieren, andere Benutzer dürfen nur indirekt über entsprechende
1
DA steht für didaktische Anforderung
14
Nachrichten zugreifen. So kann das Kapselungs-Konzept vermittelt werden. Je
nach Anwendung kann die konsequente Umsetzung dieses Konzeptes allerdings
auch auf Kosten des allgemeinen Informationsgehalts und Nutzen der
Anwendung gehen (Visibilität vs. Zugriff). Die Anwendung sollte jedoch in
jedem Fall sicherstellen, dass ausschließlich der Rolleninhaber ein Objekt
manipulieren kann.
DA3
Interaktives Senden von Nachrichten
Vermittlung der Konzepte Message Passing und Methode. Aus Sicht des
Anwenders muss eine klare Unterscheidung von Nachricht und Methode
möglich und erkennbar sein. Hierfür ist es hilfreich, wenn Anwender interaktiv
Nachrichten initiieren können, z.B in über das das Kontextmenü eines Objekts.
Es ist für Anfänger nicht offensichtlich, woher Parameter kommen, deswegen
muss
die
Anwendung
ebenso
das
interaktive
Belegen
von
Nachrichtenparametern ermöglichen.
DA4
Interaktives Erzeugen von Objekten
Vermittlung der Konzepte Objekt und Klasse – Aus Sicht des Anwenders muss
eine klare Unterscheidung von Objekten und Klassen möglich und erkennbar
sein. Dazu gehört, dass beide jeweils in einem eigenen Bildschirmbereich, einer
eigenen Liste, verwaltet werden sollten. Objekte sollten sich interaktiv aus
Klassen generieren lassen, z.B über ein entsprechendes Kontextmenü der Klasse.
DA5
Objektbeziehungen
Anfänger müssen lernen, dass Objektbeziehungen eine notwendige
Voraussetzung für das Senden von Nachrichten sind. Die Anwendung muss
sicherstellen, dass Nachrichten nur dann gesendet werden können, wenn der
Sender den Empfänger kennt, also über die entsprechende Beziehung zu diesem
Objekt verfügt (z.B. über einen entsprechenden Attributwert). Die
Objektbeziehungen sollten visualisiert werden (z.B. über entsprechende Linien
in einer Diagrammdarstellung), damit der Anwender sich schnell Überblick
verschaffen und fehlende Assoziationen identifizieren kann.
DA6
Kommunikationsmedium für den Wissenstransfer
Die Lernenden müssen die Möglichkeit haben, im Nachhinein über Abläufe zu
diskutieren. Wie in [And02] behauptet, steigt der Nutzen der Anwendung, wenn
die Erfahrungen anschließend diskutiert und referenziert werden („The benefit of
each of these exercises is greatly enhanced if the experience is discussed
afterwards and referenced frequently as students learn more“). Daher muss die
Anwendung die Abläufe in geeigneter Form aufzeichnen und dem Anwender als
Diskussionsgrundlage zur Verfügung stellen.
a) Graphische Visualisierung als Kommunikationsunterstützung
Objektstrukturen und Nachrichtenfluss, das Zusammenspiel von Artefakten
allgemein, sollten graphisch visualisiert werden, z.B. in Form eines Diagramms.
An einem Diagramm können diesbezügliche Details leicht erklärt und
kommuniziert werden. In Frage kommen u.a. die in der Software-Entwicklung
weit verbreiteten UML-Diagramme. UML ist eine Standardnotation, die von den
Entwicklern einheitlich verwendet wird und deren Elemente allgemein bekannt
sind. Verschiedene Diagramme visualisieren verschiedene Sachverhalte. Im
Zusammenhang mit Rollenspielen ist es sinnvoll, eine spezielle, aus UML-
15
Objekt und Kooperationsdiagrammen kombinierte, Diagrammform einzusetzen
(Role-Play Diagrams, s. [Bör04])
b) Protokolle der Interaktion als Kommunikationsunterstützung.
Benutzereingaben und Objektinteraktionen sollten in nachvollziehbarer und
eindeutiger Form aufgezeichnet werden. Benutzer müssen anhand der Protokolle
Programmfluss und Wertzuweisungen eindeutig nachzuvollziehen können und
die Protokolle ggfs. als gemeinsame Grundlage für die rückblickende Diskussion
getroffener Entscheidungen verwenden können.
DA7
Unterstützung lokaler und verteilter Lehre
Die Anwendung sollte sowohl in der verteilten als auch der lokalen Lehre
eingesetzt werden können. D.h. es muss auf der einen Seite möglich sein, sie als
technologische Unterstützung im Unterricht vor Ort einzusetzen. Die
Anwendung wird dann von den Schülern von verschiedenen Arbeitsplätzen im
Mehrbenutzerbetrieb genutzt. Der Umgang mit der Anwendung kann die Schüler
zusätzlich motivieren und sie bietet darüber hinaus die Möglichkeit, Vorgänge
und Abläufe dauerhaft zu speichern. Auf der anderen Seite sollte die
Anwendung auch im Rahmen der verteilten Lehre, in Situationen, wie sie sich
z.B. an einer Fern-Universität ergeben, einsetzbar sein. Hier halten sich die
Lernenden an verschiedenen Orten auf und benötigen technologische
Unterstützung, die sie in die Lage versetzt, gemeinsam synchrones Rollespiel
durchzuführen.
DA8
Flexible Reaktion auf neue Erkenntnisse
Beim Ausführen der Anwendung treffen die Benutzer Entscheidungen - sie
erzeugen Objekte, schicken Nachrichten, reagieren auf Nachrichten – und sie
gewinnen ständig neue Erkenntnisse, die dazu führen können, dass vorherige
Entscheidungen revidiert und neue getroffen werden müssen. Die
entsprechenden Änderungen müssen direkt umsetzbar sein. Die Anwendung
muss also eine flexible Anpassung des Systems zulassen. Es muss möglich sein,
Änderungen am Modell schnell und einfach umsetzen zu können und mit relativ
wenig Aufwand geänderte Szenarien durchspielen zu können. Daraus können
dann wiederum neue Erkenntnisse gewonnen werden.
DA9
Rollenspiel
Benutzer sollen Nachrichtenfluss und Objektinteraktionen in Form von
Rollenspielen simulieren können. Eine pädagogische Anwendung muss den
Lernenden aktiv am Lernprozess beteiligen, um Motivation und Lerneffekt zu
erhöhen. Das kann mit Rollenspielen erreicht werden. Weiter tragen
Rollenspiele, in denen die Anwender die Rolle von Klassen übernehmen und
Objektinteraktionen simulieren, dazu bei, dynamische Aspekte von OOP zu
verdeutlichen. Der globale Programmfluss wird deutlich, Fragen bzgl. des
Rückgabewerts, der Parameter, und der Auswirkungen auf Objektzustände,
können klar werden. Die Rollenspiele illustrieren das Konzept des Message
Passing. Die Anwendung muss u. a. dafür sorgen, dass ein Sender immer erst
auf die Antwort einer Nachricht warten muss, bevor er selbst fortfahren kann.
16
2.2 Entwicklung von objektorientierten Systemen
In den frühen Phasen der Systementwicklung existiert normalerweise noch keine
genaue Vorstellung über das zu entwickelnde System. Der Problembereich muss
in der Regel in iterativen Prozessen erst noch genauer eingekreist werden, bevor
die Artefakte des Domänenmodells sich dann nach und nach identifizieren lassen.
Ein wichtiger Schritt bei der Softwareentwicklung ist daher zunächst die
Erfassung funktioneller Systemeigenschaften. Dabei stellt sich in der Regel dann
die Frage, wie man nun von der sprachlichen, textuellen Spezifikationen zur
eigentlichen, technischen Problemlösung kommt.
Hierfür gibt es verschiedene Lösungsansätze. Eine Möglichkeit auf die im
Rahmen dieser Arbeit nicht weiter eingegangen wird, sind die linguistischen
Requirement-Analysen, zu deren Theorie Chris Rupp [Rupp06] viele Beträge
geleistet hat. Sie hat gezeigt, wie Methoden der Computerlinguistik zur Analyse
natürlichsprachlicher Anforderungen genutzt werden können. Das Ziel ist dabei
aus umgangssprachlichen Problembeschreibungen automatisch Klassenkandidaten
zu extrahieren.
Andere Lösungsansätze finden sich in schwergewichtigen UML-konzentrierten
Softwareentwicklungsmethoden oder im Bereich der agilen Methoden. In beiden
Umfeldern ist es üblich Anforderungsanalysen in Form von Use-Cases
durchzuführen. In 2.2.1 wird der Rational Unified Process(RUP) als eine
Vorgehensweise für OO-Entwicklung vorgestellt und in 2.2.2 wird auf die agilen
Methoden, die sich als Gegenbewegung zu starren und schwergewichtigen
Entwicklungsmodellen wie dem RUP verstehen, eingegangen.
Die Unified Modelling Language (UML) spielt in vielen - u.a. auch den beiden
oben genannten - Vorgehensweisen zur OO-Softwareentwicklung eine zentrale
Rolle. Ebenso wird die im Lösungsansatz dieser Arbeit verwendete DiagrammNotation an UML angelehnt. Daher geben wir in 2.2.3 eine kurze Einführung in
UML.
2.2.1 Der Rational Unified Process
Der Rational Unified Process (RUP) ist ein iteratives, inkrementelles
Vorgehensmodell für die objektorientierte Softwareentwicklung. Dabei handelt es
sich weniger eine einzelne, spezielle Methode, als vielmehr um ein adaptierbares
Prozessframework, das an die jeweiligen Gegebenheiten wie Projektgröße,
Anwendungsbereich, Art des Unternehmens, usw. angepasst werden kann und
soll. Der RUP wurde von der Firma Rational Software (seit 2002 zum IBMKonzern gehörig) als kommerzielles Produkt entwickelt und ist speziell auf den
Einsatz mit Rational Tools abgestimmt.
Historisch gesehen ist der RUP das Ergebnis drei Jahrzehnte währender
Entwicklung und Praxiseinsätze mit vielen verschieden Einflüssen. Vom Ericsson
Approach führte der Weg über den Objectory Process 1.0-3.8 (1987-1995) zum
Rational Objectory Process 4.1 (1996/1997) bis daraus schließlich der Rational
Unified Process 5.0 wurde, der 1998 veröffentlich wurde.
Mit dem generischen Unified Process wurde ein entsprechendes, nichtproprietäres, Gegenstück zum kommerziellen RUP geschaffen. Heute gibt es
verschiedene Frameworks (Agile UP, Open UP, Essential UP, Enterprise UP, etc)
17
neben dem RUP, die letztlich alle unterschiedliche Varianten/Ausprägungen
(„Refinements“) des Unified Process darstellen.1
Der Einfachheit halber beschränken wir uns im Folgenden auf die Betrachtung
des Unified Process. Das darin propagierte Vorgehen basiert auf den folgenden
Prinzipien:
•
•
•
Use-Case gesteuert: Mithilfe von Use-Cases werden die funktionalen
Anforderungen des Systems erfasst und zur Steuerung des
Entwicklungsprozesses eingesetzt
Architektur zentriert: Die Systemarchitektur ist die Basis der
Entwicklung. Sie gibt dem System die grundlegende Form, die der
Umsetzung der Use Cases dienen soll
Iterativ und inkrementell: In vielen Iterationen wird eine Folge von
Arbeitsschritten wiederholt durchlaufen. Mit jeder Iteration wird Umfang
und Qualität des Produkts verbessert, das ganze Projekt wächst
inkrementell.
Im Unified Process erstreckt sich der Lebenszyklus eines Projekts über die Phasen
Konzeption, Entwurf, Konstruktion, Übergang (Inception, Elaboration,
Construction, Transition). Jede Phase ist in mehrere Iterationen unterteilt. In einer
Iteration werden jeweils die Entwicklungsstadien Anforderungen, Anlyse, Design,
Implementation und Test durchlaufen. Der Aufwand für die einzelnen Stadien
kann je nach Zyklusphase unterschiedlich stark gewichtet sein. Am Ende jeder
Iteration entsteht dann ein Inkrement des vorhergehenden Systems, welches sich
durch Verbesserungen oder erweiterte Funktionalitäten auszeichnet. Das
Verständnis für das zu entwickelnde System reift in den einzelnen Stufen des
iterativen Prozesses.
Bei der Notation des zu entwerfenden Softwaresystems bedient sich der Unified
Process der Unified Modeling Language (UML). Tatsächlich ist die UML ein
integraler Bestandteil des Unified Processs, beide wurden Hand in Hand
miteinander entwickelt. Abschnitt 2.2.3 gibt eine Einführung in die UML.
In einem Softwareentwicklungprojekt, das nach dem RUP organisiert wird, wird
in der Regel ein unterstützendes Modellierungswerkzeug wie Rational Rose (s.
Kapitel 3.1.3, Abschnitt Rational Rose) eingesetzt. Bei der Arbeit mit Rose ist
neben der Möglichkeit, UML-Diagramme zu zeichnen, das eigentlich Wichtigere,
dass Rose es erlaubt, alle technischen Konstrukte, die für die Erstellung der
Software erstellt werden, zu verwalten. Mithilfe einer Use-Case-gesteuerten
Arbeitsweise wird ein Modell der Applikation erstellt, von dem ausgehend sich
alle Arbeitsergebnisse, die erstellt wurden, wieder erschließen lassen (vgl.
[Borr02].
2.2.2 Agile Softwareentwicklung
Agile Softwareentwicklung ist als eine Gegenbewegung zu den oft als zu
schwergewichtigen und formal angesehenen Softwareentwicklungsprozessen wie
1
RUP und UP werden im Sprachgebrauch fast synonym verwendet. Teilweise lässt sich schwer
sagen ob ein Framework nun ein Refinement vom RUP oder vom UP ist. Manche Quellen sehen
auch den RUP als eine Ausprägung des UP.
18
dem oben beschriebenen RUP entstanden. Ziel ist es die Softwareentwicklung zu
verbessern. Agilen Methoden gehen davon aus, dass Anforderungen im
Softwareentwurf nie komplett erfasst werden und deshalb ein iteratives
Explorieren des Problemraums notwendig ist. Je nach Kontext bezieht sich der
Begriff auf Teilbereiche der Softwareentwicklung, wie im Fall von Agile
Modeling, oder auf den gesamten Softwareentwicklungsprozess, wie z.B. beim
Extreme Programming. Die Hauptprinzipien hinter den agilen Methoden sind im
Agile Manifesto [Agi01] festgehalten.
In der Agilen Analyse versuchen Teams üblicherweise durch Benennung und
Beschreibung so genannter Use-Cases ihre Vorstellung über das zu entwickelnde
System zu verfeinern. Ein Use-Case beschreibt dabei eine Serie von Interaktionen
zwischen Nutzer und System, die notwendig sind, um ein fachliches Ziel des
Nutzers zu verwirklichen. In [Bit02] gibt es folgende Definition:
"Use cases, stated simply, allow description of sequences of events that, taken
together, lead to a system doing something useful"
Use-Cases stellen Anwendungsszenarien des Systems dar. Die Schwierigkeit
besteht dabei nun darin, aus den textuellen Use-Cases das Programm zu
entwickeln. Hier gibt es nun den Ansatz mit Story-Cards zu arbeiten. Ein UseCase wird auf eine oder mehrere Story-Cards umgesetzt. Auf einer Story-Card
wird eine einzelne Funktionalität aus Anwender/Kunden-Sicht in prosaischer
Form erfasst. Diese Story-Cards werden dann wiederum auf Task-Cards
abgebildet. Task-Cards enthalten die Beschreibung der Funktionalität aus
Programmierersicht. Anhand der Task-Cards können die Entwickler die einzelnen
Funktionen dann implementieren. Die große Herausforderung dieses Ansatzes
besteht in dem Schritt der Übersetzung der Stories auf Objektinteraktion. Hier
müsste ein unterstützendes Werkzeug die Möglichkeit bieten, den Objektraum zu
explorieren.
Ein weiterer systematischer Ansatz für die OO-Entwicklung, in dem Use-Cases
auch eine Rolle spielen, wird in [Bör04] vorgestellt. Dieser Ansatz basiert auf
Responsibility-Driven-Design (RDD) [Wirf90]. Börstler schlägt SzenarioRollenspiele mit CRC-Karten kombiniert mit der Protokollierung in einer
speziellen Diagrammform vor. Wir erläutern den Ansatz von Börstler in Abschnitt
3.1.1 im Rahmen der State-of-the-Art-Untersuchung genauer.
CRC (Class Responsibility Collaborator)-Karten sind ein gebräuchliches Mittel in
der OO-Analyse. Ursprünglich waren CRC-Karten ein Hilfsmittel, mit dem
Programmierern objektorientierte Denkweisen näher gebracht werden sollten (vgl.
[Beck89]). Sie sind ein einfaches, informales Werkzeug für die kollaborative,
objekt-orientierte Modellierung. Eine CRC-Karte ist eine in verschiedene
Bereiche aufgeteilte Standard-Karteikarte (s. Abbildung 4.11). Die Karte
korrespondiert zu einer Klasse, die Responsibilities geben an, welche
Verantwortlichkeiten die Klasse haben soll und die Collaborators definieren,
welche Klassen für die Erfüllung einer Verantwortlichkeit benötigt werden. Mit
den CRC-Karten lässt sich nun ein informales Analyse-Modell der Domäne
erstellen. Die Entwicklung erfolgt idealerweise (wie alle agilen Entwurfsprozesse)
in einem kreativen, kooperativen Gruppenprozess.
19
Anhand der CRC-Karten können Rollenspiel zum Simulieren von
Objektinteraktionen und zum Explorieren des Modells durchgeführt werden. Auf
diese Weise werden Unklarheiten und Inkonsistenzen aufgedeckt, neue
Erkenntnisse werden gewonnen. Die Rollenspiel-Szenarien stellen letztlich
Testfälle für das System dar. Wie bei Testfällen generell üblich, müssen
Testsituationen und Testdaten vorbereitet werden.
Ein entsprechendes unterstützendes Tool müsste die Objektinteraktionen
visualisieren und protokollieren, es müsste interaktives Szenario-Rollenspiel
unterstützen und die Möglichkeit vorsehen, das System mit Testdaten zu
initialisieren.
2.2.3 Die Unified Modeling Language
Die Unified Modelling Language (UML, [UML07]) spielt in vielen - u.a. auch
den beiden oben genannten - Vorgehensweisen zur OO-Softwareentwicklung eine
zentrale Rolle. Ebenso wird die im Lösungsansatz dieser Arbeit verwendete
Diagramm-Notation an UML angelehnt. Dieser Abschnitt soll daher einen kurzen
Einblick in UML bieten und die Diagramme vorstellen, die im Rahmen dieser
Arbeit von Bedeutung sind.
Die UML ist eine visuelle Sprache für die Spezifikation, Konstruktion und
Dokumentation der Artefakte von Softwaresystemen und Geschäftsprozessen
(vgl. [OMG03]). Die Verantwortung für die Pflege und ständige
Weiterentwicklung des UML-Standards liegt in den Händen der Object
Management Group (OMG). Die UML erfreut sich aus verschiedenen Gründen
großer Beliebtheit. Zum einen können mit einer einheitlichen und verständlichen
Notation die verschiedensten Elemente eines Softwaresystems visuell beschrieben
werden. Zum anderen bildet sie eine einfache Grundlage für die Kommunikation
zwischen den Entwicklern.
In [Fowler03] werden drei Methoden vorgestellt, wie Entwickler die UML
anwenden (UML als Skizze (formlose, unvollständige Diagramme, Handskizzen
auf Whiteboards, um den Lösungsraum und schwierige Teile des Problems zu
analysieren, UML als Blaupause (detailliertere Entwurfsdiagramme für a) Reverse
Engineering: Tools generieren Klassen aus Code oder b) Codegenerierung, also
die andere Richtung, aus Diagrammen wird Code generiert), UML als
Programmiersprache. Agile Modellierung betont UML als Skizze.
Die UML umfasst eine Reihe von graphischen, in Diagrammen organisierten,
Notationselementen für die Spezifikation statischer und dynamischer Modelle von
Analyse, Design und Architektur. Sie definiert sich dabei selbst über ein
Metamodell. UML ist heute de facto Standard für die graphische Modellierung
von Software und stellt die dominanteste graphische Notation in der
objektorientierten Welt dar (vgl. [Fowler03]). Wie bereits erwähnt, gibt es
Vorgehensmodelle/Methoden, die auf der UML aufbauen (s. oben, UP, RUP), die
UML selbst ist aber weitgehend Methoden-neutral und gibt keine spezielle
Vorgehensweise für den Modellierungsprozess vor, sie gibt dem Anwender
lediglich eine einheitliche Notation an die Hand.
Entstehungsgeschichte
Mitte der 70er bis Mitte 90er entstanden mehr als 50 Ansätze für
Modellierungssprachen für objektorientierte Analyse und Design. Einige dieser
20
Ansätze unterschieden sich nur marginal, während andere sich bereits in ihren
Zielsetzungen unterschieden. Letztlich konnte sich aber kein Ansatz als
Universallösung durchsetzen.
1995 vereinten Grady Booch und James Rumbaugh im Rahmen der Rational
Software Corporation ihre beiden Notationen zur Unified Method(UM). Im
Oktober 1995 stieß Ivar Jacobsen dazu und brachte Elemente aus seinem Object
Oriented Software Engineering (OOSE)-Ansatz ein, dazu gehörten u.a. auch die
von ihm geprägten Use Cases. So entstand die UML 0.9. Die drei Sprachschöpfer
sind seitdem auch als die „drei Amigos“ bekannt.
Viele namhafte Firmen (IBM, Microsoft, Hewlett Packard, Oracle, etc) hatten den
Bedarf nach einer einheitlichen Sprache erkannt und schlossen sich in der
Folgezeit dem weiteren Entwicklungsprozess an. 1997 wurde die UML dann
schließlich in der Version 1.1 bei der OMG zur Standardisierung eingereicht und
akzeptiert. Es folgten schnell weitere 1.x-Versionen, die kleinere Änderungen und
Fehlerbehebungen umsetzten. Der nächste größere Evolutionsschritt kam aber erst
im Frühjahr 2005 mit der Version 2.0. Darin wurde das Metamodell allgemein
stark konsolidiert. In den Bereichen Interaktion und Aktivitäten wurde es
komplett neu erstellt. Neue Konzepte (CompositePart, Port/Connector,
Collaboration, Interaction, Activity, etc) und entsprechende Notationen kamen
hinzu. Einige alte Notationen wurden verbessert.
Die UML stellt verschieden Diagramme zur Verfügung, um das Modell einer
Problemdomäne grafisch darzustellen. Die Diagramme unterscheiden sich durch
die Blickwinkel aus dem sie die Problemstellung betrachten. UML-Diagramme
können als gemeinsame Kommunikationsbasis für beteiligte Personen aus
unterschiedlichen Kontexten mit unterschiedlichem Hintergrundwissen dienen.
Die einheitliche Notation ermöglicht dem Kunden, die „gleiche Sprache“ wie der
Programmierer zu sprechen und zu verstehen. Mit der UML werden Modelle
beschrieben – Die Modellierung kann hilfreiche Unterstützung bei der SystemEntwicklung bieten, Modelle reduzieren enorme Komplexität von Sachverhalten
auf ein überschaubares Maß.
Die Diagramme lassen sich in zwei Kategorien einteilen, Struktur- und
Verhaltensdiagramme. Strukturdiagramme beschreiben die statischen und
Verhaltensdiagramme die dynamischen Eigenschaften eines Systems. Im
Folgenden beschränken wir uns auf die Betrachtung von Klassendiagrammen,
Objektdiagrammen, Sequenz- und Kommunikationsdiagrammen. Diese
Diagramme sind im Zusammenhang mit der Aufzeichnung von Objektinteraktion
und den in [Bör04] vorgestellten RPDs relevant.
Klassendiagramm
Die Struktur eines Systems wird durch das Klassendiagramm repräsentiert. Das
Klassendiagramm beschreibt, welche Klassen existieren und in welchen
Beziehungen sie zueinander stehen
Eine Klasse ist die Definition der Attribute, Operationen und der Semantik für
eine Menge von Objekten. Alle Objekte einer Klasse entsprechen dieser
Definition. In objektorientierten Programmiersprachen repräsentieren Klassen die
verschiedenen Objekttypen.
21
Das Diagrammelement für die Darstellung einer Klasse ist ein üblicherweise aus 3
Abschnitten (Compartments) aufgebautes Rechteck (vgl. Abbildung 2.1):
-
Oberste Abschnitt: Klassenname, fett
2. Abschnitt: Attribute
3. Abschnitt: Methoden
Es kann weitere optionale Abschnitte
kommentierende Annotationen sind möglich.
geben,
wie
Responsibilities,
In UML werden die Diagrammelemente umfassend als Merkmale (Features)
bezeichnet, Attribute und Methoden sind also die Merkmale einer Klasse. Zu
jedem Merkmal können Details wie Sichtbarkeit, Multiplizität, Parameter,
Initialisierung und ggf. Einschränkungen/Zusagen (constraints) notiert werden.
Sichtbarkeit wird in Form von Symbolen vor dem Merkmal angegeben - (private),
# (protected), + (public). Klassenamen müssen per Konvention mit einem
Großbuchstaben beginnen, Merkmale dagegen mit einem Kleinbuchstaben.
Abstrakte Klassen/Methodenname werden kursiv dargestellt)
Abbildung 2.3 Beispiel für die Klassen-Notation in UML1
Beziehungen zwischen Klassen beschreiben, wie genau die beteiligten Klassen
miteinander kollaborieren dürfen. Beziehungen zwischen Klassen werden mit
Verbindungslinien dargestellt. Es gibt verschieden Arten von Beziehungen,
Beziehungen sind gerichtet.
•
•
1
Assoziation – repräsentiert strukturelle Beziehungen zwischen
verschiedenen Objekten einer oder mehrerer Klasse, kann Kardinalitäten
haben, sollte mit Verb-Phrase benannt werden. Ausgefüllte Pfeile
markieren die Leserichtung, können sofern nicht anders angegeben, in
beiden Richtungen navigiert werden
Aggregation – Spezialform der Assoziation, Zusammensetzung eines
Objekts aus einer Menge von Einzelteilen, (has oder part of –relationship)
Hat-Beziehung, Teile-Ganzes-Hierarchie, ein Auto hat Räder, ein Depot
hat Konten,
Die in diesem Abschnitt verwendeten UML-Diagramme sind aus [Bör04] entnommen
•
•
22
Komposition – Besondere Form der Aggregation, die Einzelteile sind
vom Aggregat (dem Ganzen) existenzabhängig, eine Aggregation mit
existenzabhängigen Teilen, Rechnung hat Rechnungspositionen, Konto hat
Transaktionen
Generalisierung/Spezialisierung - bezeichnet Vererbung und Subtyping.
PhStudent ist ein Subtyp von Student und Lecturer und kann an allen
Stellen eingesetzt werden, an denen die Typen Student und Lecturer
verwendet werdenl.
Abbildung 2.4 zeigt ein Klassendiagramm mit Analyse-Level-Details und einigen
Design-Level-Details.
Abbildung 2.4 – Beispielhaftes Klassendiagramm
Objektdiagramm
Ein Objektdiagramm stellt eine Momentaufnahme des Systems zu einem
bestimmten Zeitpunkt dar. Es enthält fast die gleichen Notationselemente wie das
Klassendiagramm, allerdings können hier die Attribute konkrete Werte annehmen,
und Objekte können Namen haben. Der Name wird mit Doppelpunkt vor den
Klassennamen geschrieben und zur besseren Unterscheidung von Klassen- und
Objektdiagrammen unterstrichen.
Abbildung 2.5 – Objektdiagramm, passend zum Klassendiagramm in Abb. Abbildung 2.4
Kommunikationsdiagramm
In früheren UML-Versionen (UML1.x) hießen diese Diagramme noch Kollaborationsdiagramme. Kommunikationsdiagramme sind Verhaltensdiagramme, die die
Interaktion von Kommunikationspartnern darstellen. Interaktionspartner können
dabei beliebige Classifier sein (Klassen, Objekte, Akteure, Knoten).
23
Die Beschreibung der Interaktionen fokussiert hier die strukturellen Beziehungen
zwischen den Elementen. Daher sind diese Diagramme gut geeignet, wenn wenige
Nachrichten ausgetauscht werden, aber die Beziehungen zwischen den
Interaktionspartnern unterstrichen werden sollen.
Abbildung 2.6 – Kommunikationsdiagramm entsprechend des Klassendiagramms in Abb.
Abbildung 2.4
Abbildung 2.6 zeigt ein beispielhaftes Kommunikationsdiagramm. Die Reihenfolge der Nachrichten wird durch Sequenznummern ausgedrückt, Richtung und
Typ der Nachricht als kleine Pfeile. Es gibt einen so genannten Actor, der eine
Person oder ein externes System repräsentiert, welcher mit dem System
interagieren kann.
Sequenzdiagramm
Sequenzdiagramme enthalten semantisch fast äquivalente Information wie
Kommunikationsdiagramme, bieten aber mehr Detailgenauigkeit. Sie fokussieren
auf den zeitlichen Verlauf der Nachrichten. Sie sind gut geeignet, wenn wenige
Interaktionspartner viele Nachrichten austauschen und komplexe Muster des
Nachrichtenaustauschs zu modellieren sind.
Es werden Modellierungsmöglichkeiten für feste Reihenfolgen, logische und
zeitliche Ablaufbedingungen geboten. Das Sequenzdiagramm ist das
meistverwendete und umfangreichste Interaktionsdiagramm, es bietet die höchste
Detailtiefe und enthält alle wichtigen Basiskonzepte.
Details zur Notation:
- Jeder Interaktionspartner besitzt Lebenslinie
- Nachrichten werden durch Pfeile zwischen den Lebenslinien dargestellt.
- Form des Pfeils symbolisiert den Type der Nachricht, Aufruf (gefüllte Spitze),
Antwort (gestrichelt), synchrone Nachricht)
- Aktivierungsbalken zeigt, das ein IAP die Kontrolle hat
- Resultat eines Aufrufs kann direkt als Attributzuweisung im Aufruf mit
angegeben werden (ergebnis = bearbeiten(auftragsnr1, artikel1)
- Selbstaufrufe: Aktivierungsbalken werden übereinander gelegt
Abbildung 2.7 zeigt ein beispielhaftes Sequenzdiagramm.
24
Abbildung 2.7 – Sequenzdiagramm, äquivalent zum Kommunikationsdiagramm in
Abbildung 2.6
2.2.4 Anforderungen im Kontext der OO-Entwicklung
Bei den vorgestellten Vorgehensweisen – und bei der OO-Entwicklung generell geht es darum, den Problembereich einzukreisen und die Artefakte (Objekte,
Klassen und Methoden) des Domänen-Modells zu identifizieren.
Im Einzelnen lassen sich in diesem Kontext die folgende Anforderungen
herleiten.
EA11 Identifikation der Objekte
Benutzer müssen sich explorierend durch den Problemraum bewegen können. Es
muss möglich sein, festzustellen, welche Objekte zur Lösung eines Problems
tatsächlich notwendig sind, und ob die Klassenkandidaten eines evtl. bereits
gegebenen Analysemodells korrekt gewählt sind oder evtl. angepasst werden
müssen. Hierfür ist es erforderlich, dass die Anwendung Klassen- bzw.
Objektstrukturen visualisiert und die Benutzerinteraktion auf Objekt-Level
zulässt. Anwender müssen Klassen definieren und aus diesen Klassen Objekte
erzeugen können. Es muss möglich sein, Einblick in Objektzustände zu
verschiedenen Zeitpunkten nehmen zu können und Objektzustände ggf. manuell,
durch Manipulation von Attributwerten, ändern zu können. Dadurch erlangt der
Anwender nicht nur über die benötigten Objekte sondern auch über deren
Struktur, also die benötigten Attribute, Klarheit.
EA2 Identifikation der Nachrichten
Analog zu den Objekten müssen auch die zur Umsetzung einer Funktionalität
benötigten Nachrichten identifiziert werden können. Es muss klar werden,
welche Nachrichten ein Objekt an ein anderes senden kann, bzw. welche
Methoden das andere Objekt zur Verfügung stellt. Hierfür sollte die Anwendung
es dem Anwender erlauben, interaktiv im Kontext eines Objekts das Senden
einer Nachricht zu initiieren und so den Nachrichtenfluss zu simulieren. Die
Anwendung muss auf der einen Seite sicherstellen, dass die Nachrichten und
Parameter den Signaturen der zugehörigen Methoden entsprechen. Auf der
anderen Seite sollte aber auch die Ad-Hoc-Generierung einer Methode bei
Eingabe einer neuen, unbekannten Nachricht unterstützt werden. Auf diese
Weise, können neue Erkenntnisse direkt umgesetzt werden
1
EA steht für Entwicklungs-Anforderung
25
EA3 Reaktion auf Nachrichten
Neben der Frage, welche Nachrichten bzw. Methoden benötigt werden, ist auch
die Frage nach der Nachrichtenbearbeitung, bzw. dem Aufbau der Methoden zu
klären. Was genau geschieht, wenn ein Objekt eine Nachricht erhält, wie wird
diese Nachricht bearbeitet. Dazu kann das Ändern des Objektzustandes, das
Senden weiterer Nachrichten, und Rückgabe eines Rückgabewertes gehören. Die
Anwendung sollte es also ermöglichen, die Reaktionen eines Objekts auf
Nachrichten zu examinieren und ggf. individuell zu manipulieren. Durch diese
direkte Interaktion kann der Anwender sich am besten Klarheit über die
erforderlichen Bearbeitungsschritte, bzw. den Aufbau der erforderlichen
Methoden verschaffen.
EA4 Identifikation der Objekt-Beziehungen
Die Anwendung muss die Identifikation von Objekt-Beziehungen, und damit
entsprechend die Identifikation der Assoziationen zwischen Klassen
unterstützen. Die Anwendung muss sicherstellen, dass Nachrichten nur dann an
Objekte gesendet werden können, wenn die Objekte sich kennen, also eine
Beziehung zueinander haben (z.B. über einen entsprechenden Attributwert). Die
Objektbeziehungen sollten visualisiert werden (z.B. über entsprechende Linien
in einer Diagrammdarstellung), damit der Anwender sich schnell Überblick
verschaffen und fehlende Assoziationen identifizieren kann.
EA5 Testmöglichkeiten
Die Entwicklung eines OO-Programms ist ein iterativer Prozess in dem das
Domänenmodell schrittweise verfeinert wird. Eine Anwendung, die die
Entwicklung von Domänenmodellen unterstützt, sollte immer Möglichkeiten
bieten, diese Modelle in den unterschiedlichen Entwicklungsstadien zu testen.
Erst beim Testen werden Schwachstellen und Inkonsistenzen offenbart. Die
Anwendung muss also die Möglichkeit bieten, Testfälle/-szenarien zu
konstruieren, initiale Testdaten einzugeben,
und den entsprechenden
Programmfluss zu simulieren.
EA6 Kommunikationsmedium für den Wissenstransfer
Entwickler müssen die gewonnenen Erkenntnisse untereinander kommunizieren
können. Daher ist es erforderlich, dass die Anwendung die Ergebnisse der
Entwicklung in einer geeigneten Form repräsentiert und diese Repräsentation
dann als gemeinsame Diskussionsgrundlage verwendet werden kann.
Objektstrukturen und Nachrichtenfluss, das Zusammenspiel von Artefakten
allgemein, sollten graphisch visualisiert werden, z.B. in Form eines Diagramms.
An einem Diagramm können diesbezügliche Details leicht erklärt und
kommuniziert werden. In Frage kommen u.a. die in der Software-Entwicklung
weit verbreiteten UML-Diagramme. UML ist eine Standardnotation, die von den
Entwicklern einheitlich verwendet wird und deren Elemente allgemein bekannt
sind. Verschiedene Diagramme visualisieren verschiedene Sachverhalte. Im
Zusammenhang mit Rollenspielen ist es sinnvoll, eine spezielle, aus UMLObjekt und Kooperationsdiagrammen kombinierte, Diagrammform einzusetzen
(Role-Play Diagrams, s. [Bör04])
Benutzereingaben und Objektinteraktionen sollten in nachvollziehbarer und
eindeutiger Form aufgezeichnet werden. Benutzer müssen anhand der Protokolle
Programmfluss und Wertzuweisungen eindeutig nachzuvollziehen können und
die Protokolle ggf. als gemeinsame Grundlage für die rückblickende Diskussion
getroffener Entscheidungen verwenden können.
26
EA7 Unterstützung lokaler und verteilter Teams
An der Entwicklung eines Softwaresystems sind üblicherweise ganze Teams
beteiligt. Dazu können zum einen verschiedene Entwickler mit
unterschiedlichem Expertenwissen und zum anderen der Kunde/Auftraggeber,
der aktiv mit in den Entwicklungsprozess einbezogen wird, gehören.
Dementsprechend sollte eine Entwicklungsumgebung also auch für einen
Mehrbenutzerbetrieb ausgelegt sein. Das Team muss die Möglichkeit haben, von
verschiedenen Arbeitsplätzen aus gemeinsam an Projekten zu arbeiten. Verteilte
Teams – z.B. der Kunde oder bestimmte Entwickler nicht vor Ort - müssen dabei
genauso wie lokale Teams – alle Teammitglieder am selben Ort – unterstützt
werden.
EA8
Angebot des potenziellen Mehrwerts für die Anwender
Der Einsatz einer technologischen Unterstützung muss immer auch einen
praktischen Mehrwert für den Anwender mit sich bringen. Es muss aus
Anwendersicht eine Motivation existieren, die den Aufwand rechtfertigt, sich in
die Anwendung einarbeiten und sie zu nutzen. Einen solchen Mehrwert kann
zum Beispiel die Möglichkeit der generischen Erzeugung von Sourcecode
bieten.
EA9
Während des Entwicklungsprozesses werden ständig neue Erkenntnisse
gewonnen, die direkt in den Entwurf mit einfließen sollen. Die Anwendung muss
eine flexible Anpassung des Systems zulassen. Es muss möglich sein,
Änderungen am Modell schnell und einfach umsetzen zu können und mit relativ
wenig Aufwand verschiedene Design-Alternativen testen zu können. Daraus
können dann wiederum neue Erkenntnisse gewonnen werden.
EA10 Nachvollziehbarkeit
Im Hinblick auf spätere Bewertungsmöglichkeiten eines Entwurfs ist es wichtig,
alle getroffenen Entscheidungen nachvollziehbar aufzuzeichnen. Dazu gehört die
chronologische Protokollierung des Nachrichtenflusses und aller im Zuge der
Nachrichtenbearbeitung vorgenommenen Wertzuweisungen an lokale Variablen,
Attribute oder Parameter.
2.3 Kooperationsaspekte in Lehre und Entwurfsprozessen
Die 2.1 und 2.2 ermittelten Anforderungen beziehen sich vorwiegend auf die
Sicht, die Einzelbenutzer auf das System haben. Dieser Abschnitt konzentriert
sich nun auf Kooperationsaspekte - wir betrachten, welche Anforderungen sich an
eine von mehreren Benutzern synchron genutzte Anwendung ergeben. Wir leiten
her, welche Anforderungen nötig sind, um lokale und verteilte Rollenspiele
technologisch zu unterstützen.
Wie bereits in 2.1.1 ausgeführt, eignen sich Rollenspiele besonders gut für die
Vermittlung der dynamischen Aspekte objektorientierter Systeme und es ist
durchaus üblich, sie im Rahmen des Unterrichts einzusetzen. Börstler [Bör04]
schlägt darüber hinaus in seinem Ansatz den Einsatz von Rollenspielen (in
Kombination mit CRC-Karten und Role-Play Diagrammen) in der
Softwareentwicklung vor, und zwar sowohl in der Analyse- als auch in der
Design-Phase. In Rollenspielen übernehmen die Mitglieder einer Gruppe die
Rolle von Objekten, und simulieren Nachrichtenfluss und -bearbeitung durch
27
Interaktion mit anderen Akteuren/Objekten. So gewinnen sie Erkenntnisse über
die Abläufe des objektorientierten Systems.
Man unterscheidet nun zwischen face-to-face und virtuellem Rollenspiel. Face-toface-Rollenspiele sind inhärent kooperative Prozesse, für eine sinnvolle
Durchführung sind mehrere (zumindest mehr als einer) kooperierende Akteure
nötig. Der Vorteil bei dieser Art des Rollenspiels und der Kooperation ist, dass
alle Gruppenmitglieder automatisch synchron dieselbe Information über das
simulierte System erhalten, sie sehen, welche Objekte beteiligt sind, wann und
wie ein Objekt aktiviert wird, sie hören wenn eine Nachricht gesendet wird und
sie hören das Ergebnis der Bearbeitung. Probleme können direkt diskutiert
werden. Ein weiterer natürlicher Vorteil des physischen Rollenspiels, der
ebenfalls aus der direkten Kommunikations-/ Diskussionsmöglichkeit resultiert,
ist Möglichkeit der dynamischen (on-the-fly) Adaption des simulierten Systems.
Die Akteure ändern einfach ggf. ihr Script und agieren entsprechend anders.
Auf der anderen Seite gibt es die virtuelle Rollenspiele – Schüler arbeiten am
Rechner und übernehmen die Rolle von antropomorphisierten Objekten in einer
virtuellen Welt (Beispiel Alice, Karel J. Robot, ViRPlay vgl. 2.1.1) – in diesem
Fall ist die kooperative Ausführung in einer Gruppe keine zwingende
Voraussetzung, im Gegenteil, die meisten Systeme unterstützen tatsächlich nur
den Single-User-Modus (ViRPlay ist von den hier vorgestellten das einzige
System, das den Multi-User-Betrieb unterstützt). Der Anwender übernimmt dann
nacheinander die Rolle aller verschiedenen Objekte, oder das System übernimmt
stellvertretend selbst Rollen. Ein Mehrbenutzerbetrieb, und damit ein kooperatives
Rollenspiel bei dem verschiedene Rollen eben auch von verschiedenen Benutzern
übernommen werden, ist dennoch wünschenswert und u. U. auch effizienter,
schon weil es dem natürlichen Charakter des Rollenspiels entspricht.
Das virtuelle Rollenspiel bringt Vor- und Nachteile gegenüber dem physischen
Rollenspiel mit sich. Ein Softwaresystem kann die Möglichkeit bieten, die
ansonsten eher flüchtigen Informationen zu speichern. So ließen sich u.a. Objekte
speichern und Objektinteraktionen und Nachrichtenfluss persistent protokollieren,
auch Replay-Funktionen wären denkbar. Je nach Darstellungsform kann die
Repräsentation der Visualisierung zu Dokumentationszwecken wieder verwendet
werden.
In 2.1.2 und 2.2.4 haben wir gezeigt, dass sich die Forderung nach einer verteilten
Anwendungsmöglichkeit (und damit nach verteiltem Rollenspiel) sowohl im
didaktischen (DA8) als auch im Entwicklungs-Kontext (EA7) ergibt.
Die Durchführung von Rollenspielen in einer verteilten, also räumlich getrennten,
Gruppe ist nun aber nicht so ohne weiteres möglich. Man braucht geeignete
Hilfsmittel, die den Gruppenprozess unterstützen und welche die Nachteile, die
sich aus der räumlichen Distanz der Gruppenmitglieder im Gegensatz zur face-toface Kommunikation ergeben, kompensieren. Gruppenprozess-unterstützende
Systeme bezeichnet man allgemein mit dem Begriff Groupware.
28
2.3.1 Groupware
Die Forschungsdisziplin, die sich mit Groupware befasst, nennt sich Computer
Supported Concurrent Work (CSCW). Mitunter werden die Begriffe CSCW und
Groupware auch synonym verwendet. In [Baec93, Part1 - Introduction] findet sich
ein Überblick über einige kontrovers diskutierte Definitionen und Naturen beider
Begriffe.
Es gibt verschiedene Klassifikationsmerkmale für Groupware. Ein gängiger
Klassifikationsansatz ist das 3K-Modell, erstmals vorgestellt in [Teu95], hierbei
wird Groupware hinsichtlich ihrer funktionalen Unterstützung von Gruppen
klassifiziert, und zwar bzgl.
•
•
•
Koordination: Koordinierung von Gruppenaktivitäten
Kooperation: Hinarbeiten auf das Erreichen eines gemeinsam verfolgten
Ziels
Kommunikation: Informationsaustausch innerhalb der Gruppe
Abbildung 2.8 - Das 3K-Modell nach Teufel et al. [Teu95]
Der klassische Ansatz von Teufel et al. in [Teu95] fasst Groupware-Systeme mit
ähnlichen Funktionalitäten in Systemklassen zusammen (communication systems,
workflow management systems, shared information spaces, workgroup computing
systems). Die Systemklassen sind innerhalb eines Dreiecks aus Koodination,
Kooperation, Kommunikation angeordnet, um auszudrücken zu welchem Grad ein
System den jeweiligen Aspekt unterstützt (vgl. Abbildung 2.8).
In [SL07], S.11f wird ein anderer Ansatz verfolgt - hier werden die gängigen
Groupware-Anwendungen in einer 2-dimensionalen Abhängigkeit von dem Maß,
in dem sie Koordination unterstützen und von dem Maß, in dem sie
Kommunikation/Kooperation unterstützen, gesehen (vgl. Abbildung 2.9). Diese
29
Darstellung soll den jeweiligen Anteil der individuellen Anwendungen an den
3Ks besser visualisieren. Die Autoren unterscheiden Tools für Audio/VideoKonferenzen, Chat-Tools, E-Mail, Foren, Wikis, Group Decision Support
Systems (GDSS), Community Systems, Shared Workspaces, Multi-User-Editoren,
Multi-Player Spiele, Workflow Management Systems (WfMS)
Abbildung 2.9 – Aus [SL07]: Einordnung von Groupware-Systemen bzgl. ihrer
Unterstützung der 3Ks
Der Vollständigkeit halber sei erwähnt, dass es noch weitere mögliche
Taxonomien zur Klassifizierung von Groupware gibt. Als Kriterien kommen z.B.
Zeit (synchron/asynchron) und Ort (lokal/remote) und Vorhersehbarkeit
(spontan/geplant) in Frage. Als Vertreter solcher Ansätze seien die klassische
Raum/Zeit-Matrix nach Robert Johansen und deren Erweiterung um den
Parameter Vorhersehbarkeit nach Jonathan Grudin erwähnt.
Die Herausforderung bei der Entwicklung einer kooperativen Anwendung besteht
nun gerade darin, dass zusätzlich zur eigentlichen Anwendungsfunktionalität die
Unterstützung und Umsetzung von Koordination und Kooperation/
Kommunikation betrachtet werden muss. Die Anwendung muss ein User- und
Sessionmanagement zur Verfügung stellen, um die verschiedenen Benutzer zu
verwalten, und gemeinsame Arbeitssitzungen (so genannte Sessions) zu starten
und die synchrone oder asynchrone Zusammenarbeit mehrer Benutzer zu
ermöglichen und zu koordinieren. Unter Umständen müssen synchrone
Kommunikationsmöglichkeiten (Chat o.ä.) integriert werden.
Ein weiterer, zentraler Aspekt von Groupware-Anwendungen ist die
Unterstützung des Gruppenbewusstseins (Awareness). Bei verteilten Gruppen ist
es wichtig zu verhindern, dass bei den einzelnen Gruppenmitgliedern das Gefühl
der Isolation und Anonymität entsteht und sie an Motivation verlieren. Die
Anwendung muss geeignete Maßnahmen ergreifen, die dazu führen, dass die
einzelnen Benutzer jederzeit über Anwesenheit/Online-Status und die Aktivitäten
der anderen Benutzer informiert sind.
Die Umsetzung von verteilten virtuellen Rollenspielen kann man sich mit einer
Anwendung aus der Rubrik der synchronen Mehrbenutzereditoren vorstellen.
Solche Editoren erlauben den Gruppenmitgliedern synchron innerhalb einer
gemeinsamen Arbeitsumgebung gemeinsame Artefakte zu erzeugen und zu
30
manipulieren und auf diese Weise Gruppenziele zu erreichen. Die
Gruppenmitglieder teilen die gleiche Sicht (shared view) auf den gemeinsamen
Informationsraum nach dem Prinzip WYSISIS (What you see, is what I see).
Gruppeneditoren erfordern ein hohes Maß an Kooperations- und
Koordinationsfunktionalitäten, Änderungskonflikte müssen aufgelöst, bzw.
vermieden werden. Synchrone Kommunikation ist nicht explizit gefordert und hat
daher nur einen geringen Stellenwert (vgl. [SL07]).
Schümmer et al. formulieren in [Schü00] folgende technische Anforderungen, die
sich an eine Groupware bzgl. des gemeinsamen Objektzugriffs ergeben: Die
bearbeitenden Objekte müssen für alle Benutzer erreichbar und manipulierbar
sein. Änderungen an diesen Objekten müssen an alle Benutzer propagiert werden.
In interaktiven Anwendungen muss der Zugriff schnell genug sein, um flüssiges
Arbeiten zu ermöglichen. Die gemeinsamen Objekte müssen in einem
konsistenten und für alle Benutzer gleichen Zustand gehalten werden. Die
Anwendung muss dafür sorgen, dass Zugriffskonflikte aufgelöst oder von vorne
herein vermieden werden. Die Bildschirmanzeige muss mit dem Zustand der
zugrunde liegenden gemeinsamen Objekte konsistent sein.
2.3.2 Technische Anforderungen
Wie im letzten Abschnitt erläutert, resultiert aus den geforderten
Kooperationsaspekten eine Reihe von technischen Anforderungen an die
Anwendung. Im Folgenden werden diese Anforderungen nun genauer definiert.
TA11 Gemeinsamer Informationsraum
Ein kooperativer Editor im Sinne der Aufgabenstellung Arbeit basiert naturgemäß
auf einem gemeinsamen Informationsraum, in welchem eine Gruppe von
Anwendern gemeinsame Objekte manipuliert - daher können die Anforderungen
aus [Schü00] hier einfließen. Die Anwendung muss den gemeinsamen Zugriff auf
die Artefakte des Informationsraums koordinieren. Die Artefakte müssen für alle
Benutzer erreichbar sein und im gleichen und konsistenten Zustand gehalten
werden. Zugriffskonflikte müssen aufgelöst oder von vorne herein vermieden
werden. Es muss einen Benachrichtigungsmechanismus geben, der Änderungen
an den Artefakten an alle Benutzer verteilt. Der Zugriff auf die Artefakte muss
schnell genug sein, um flüssiges Arbeiten zu ermöglichen. Die Bildschirmanzeige
muss mit dem Zustand der zugrunde liegenden Artefakte konsistent sein. Alle
Anwender sollten dieselbe Sicht auf das Interaktionsdiagramm haben.
TA2
Wissen kann durch Kommunikation transferiert werden. Eine Groupware muss
diesen Prozess unterstützen indem sie Informationen in einer Form, die den
Anwendern als Grundlage für die spätere Kommunikation und Diskussion dienen
kann. aufbereitet und repräsentiert
Wie bereits in EA6a und DA6a ausgeführt - Objektstrukturen und
Nachrichtenfluss, also das Zusammenspiel von Artefakten allgemein, sollten
graphisch visualisiert werden, z.B. in Form eines Diagramms. Im Zusammenhang
mit Rollenspielen ist es sinnvoll, eine spezielle, aus UML-Objekt und
Kooperationsdiagrammen kombinierte, Diagrammform einzusetzen (Role-Play
1
TA steht für technische Anforderung
31
Diagrams, s. [Bör04])
Wie bereits in EA6a und DA6a ausgeführt - Benutzereingaben und
Objektinteraktionen sollten in nachvollziehbarer und eindeutiger Form
aufgezeichnet werden. Benutzer müssen anhand der Protokolle Programmfluss
und Wertzuweisungen eindeutig nachzuvollziehen können und die Protokolle
ggfs. als gemeinsame Grundlage für die rückblickende Diskussion getroffener
Entscheidungen verwenden können.
TA3
Synchrone Kommunikation
Normalerweise spielt die Kommunikation in Mehrbenutzereditoren eine eher
nebensächliche Rolle. In unserem Fall (System-Analyse allgemein, Rollenspiel
speziell) ist aber die direkte Kommunikation in der Gruppe ein wesentlicher
Faktor. Es muss möglich sein schnell im direkten Dialog Details oder
Unklarheiten bzgl. des Szenarios oder des Modells klären zu können ohne dafür
auf externe Mittel wie Telefon oder Mail-Client zurückgreifen zu müssen. Die
Anwendung sollte der Gruppe also eine synchrone Kommunikationsmöglichkeit
bieten, z.B. in Form eines integrierten Chats.
TA4
Awareness
Groupawareness ist ein zentrales Element in einer kooperativen Anwendung.
Anwender dürfen sich nicht isoliert fühlen, es muss für jeden jederzeit klar
erkennbar sein, welche Mitglieder zur Gruppe gehören und ihr jeweiliger OnlineStatus muss visualisiert werden. Es muss klar sein, welche Aktivitäten von
welchem Benutzer ausgeführt werden (wer schickt welche Nachricht, wer hat die
Kontrolle). Bzgl. der Artefakte muss angezeigt werden, welches Gruppenmitglied
welche Rolle innehat und wenn diese gewechselt wird. Es muss erkennbar sein,
welches Gruppenmitglied das aktive Objekt dirigiert und damit die aktuelle
Kontrolle besitzt.
TA5
Modellierung von Rollen
Eine Groupware sollte die Modellierung von Rollen für die Ausführung
bestimmter Aktivitäten ermöglichen, Benutzer werden aufgrund bestimmter
Eigenschaften Rollen zugeordnet und sie übernehmen dementsprechend die
Aktivitäten. Die jeweiligen Rollenzuordnungen sollten im Sinne der Awareness
visualisiert werden.
In Bezug auf das Rollenspiel-Konzept sollte die Anwendung es ermöglichen, die
Rolle von Klassen zu übernehmen. Zu den Aktivitäten, die mit dieser Rolle
verbunden sind, gehören dann u.a. das Erzeugen von Objekten dieser Klasse und
das Steuern dieser Objekte. Steuern meint hier, Nachrichten empfangen,
bearbeiten (dabei ggf. Attributwerte manipulieren, weitere Nachrichten
verschicken) und beantworten. Alle Darstellungsformen von Klassen und
Objekten sollten visuelle Hinweise auf den steuernden Benutzer beinhalten.
TA6
Synchronisation des Diagramms
32
Wenn die Objektinteraktion in einem Diagramm aufgezeichnet wird, sollten wie
in TA1 gefordert, alle Benutzer dieselbe Sicht auf dieses Diagramm haben. Die
darzustellenden Informationen ändern sich dynamisch, wobei die Änderungen
von verschiedenen Benutzern (auch konkurrierend) verursacht werden können.
Die Anwendung muss nun also bei jeder Änderung für eine geeignete
Synchronisation der Darstellung sorgen. Änderungen können dabei sowohl
räumlicher Natur (alle Anwender sollen Diagrammelemente ausrichten und
positionieren können) als auch inhaltlicher Natur sein (geänderte Objektzustände,
geänderter Aktivitätsstaus, neue Nachrichten, etc.) Die Änderungen müssen an
alle Benutzer verteilt werden.
TA7
Code-Generierung
Eine mögliche Implikation aus AR8 kann die generische Erzeugung von
Sourcecode sein. Eine solche automatische Codeerzeugung stellt auf jeden Fall
eine erheblichen praktischen Nutzen und damit einen Mehrwert für den
Anwender dar. Die Anwendung sollte also ermöglichen aus den u. U. informal
notierten Artefakten generisch Java- Klassenrümpfe zu erzeugen. Die Protokolle
der Objektinteraktionen sollten hinreichend vollständig sein, so dass sich auf ihrer
Grundlage JUnit-Testcases konstruieren lassen können.
TA8: Visualisierung des Nachrichtenflusses
Die Anwendung sollte den Interaktions-/bzw. Nachrichtenfluss graphisch
visualisieren. Die Darstellung muss bei neuen Nachrichten dynamisch aktualisiert
werden. Der Benutzer muss bei Ansicht des Diagramms schnell den aktuellen
Stand der Simulation erfassen können. Dies kann z.B. durch geeignetes
Markieren bestimmter Elemente (letzte Nachricht, aktiviertes Objekt) unterstützt
werden. Die Darstellung muss die Nachvollziehbarkeit der chronologischen
Reihenfolge der Nachrichten gewährleisten. Mit geeigneten Maßnahmen sollte
das Diagramm auch in längeren Simulationen mit vielen Nachrichten
übersichtlich gehalten werden können – denkbar ist z.B. eine Benutzereinstellung,
mit der sich die Anzahl der angezeigten Nachrichten beschränken lässt.
TA9:
Historie
Aus den Anforderungen EA10 und TR6 ergibt sich die Notwendigkeit einer
Nachrichtenhistorie. Während der Simulation eines Progammablaufs müssen
sowohl die gesendeten Nachrichten als auch die, von den Benutzern im Zuge der
Nachrichtenbearbeitung vorgenommenen, Zuweisungen aufgezeichnet und
persistent abgespeichert werden. Darüber hinaus sollten die Aufzeichnungen in
geeigneter Form innerhalb der Anwendung zur Anzeige gebracht werden. Damit
ist der Nachrichtenfluss auch im Nachhinein nachvollziehbar.
TA10: Usermanagement
Die Anwendung muss Benutzer, Projekte und die Zuordnungen von Benutzern zu
Projekten verwalten. Benutzer sollten sich an zentraler Stelle authentifizieren
müssen, bevor sie an kooperativen Sitzungen teilnehmen können. Darüber hinaus
ist ein Sessionmanagement erforderlich, welches für die eindeutige Zuordnung
von User zu Clients innerhalb der kooperativen Sessions sorgt. Dies ist ein
wichtiger Baustein für die Groupawareness, so ist es später möglich einzelne
Aktivitäten bestimmten Benutzern zuzuordnen.
T11: Persistenz
Alle Informationen (Benutzer, Projekte, Artefakte, Abläufe), auch die Ergebnisse
von kooperativen Sessions, sollten zentral und persistent gespeichert werden,
damit die Anwender auch beim asynchronen Zugriff auf gemeinsame Projekte
immer den letzten aktuellen Stand der Session abrufen und damit fortfahren
können. Die Benutzer sollten zu jedem Zeitpunkt von jedem Ort (über das
33
Internet) mit dem System arbeiten können, unabhängig vom Online-Status
anderer Gruppenmitglieder und einzelner Clients.
3 Stand der Forschung
34
Dieses Kapitel gibt einen Überblick über die aktuellen Forschungsansätze, die zur
Lösung der Anforderungen in Frage kommen. Die Ansätze werden zunächst kurz
kategorisiert, dann in 3.1 im Einzelnen vorgestellt und schließlich in 3.2 den in
Kapitel 2 analysierten Anforderungen tabellarisch gegenübergestellt.
Es existieren verschieden geartete Ansätze, die jeweils für eine partielle Erfüllung
der in 2 analysierten Anforderungen in Frage kommen. Es werden Ansätze aus
folgenden Bereichen betrachtet:
•
•
•
•
Konzeptionelles Szenario-Rollenspiel – Für die hier betrachteten
Ansätze gibt es keine Toolunterstützung. Es handelt sich vielmehr rein
konzeptionelle Methoden – Rollenspiele von Andrianoff, Rollenspiele aus
dem Kontext des MBCS, Szenario-Rollenspiele mit CRC-Karten nach
Börstler
Lehr- und Lehranwendungen – Hier werden existierende Anwendungen
betrachtet, die bei Einführungen in die OOP-Lehre nach dem objects-firstPrinzip eingesetzt werden. Anwendungen dieser Art sind in der Regel
speziell darauf ausgerichtet, den Anwender beim Begreifen der elementaren OO-Konzepte zu unterstützen. Als Vertreter für pädagogische IDEs
wird BlueJ betrachtet, Alice und ViRPlay sind Beispiele für Virtuelle
Welten.
UML- Modellierungs-Tools – Es gibt eine Reihe von professionellen
Design-Werkzeugen zur visuellen Modellierung mit UML-Diagrammen.
Diese UML-Modellierungs-Tools sind alle nach ähnlichem Prinzip
aufgebaut sind und lassen sich insofern mit den Anforderungen dieser
Arbeit vergleichen, als dass sie ebenfalls die visuelle Entwicklung von
Domänen-Modellen unterstützen und Mehrwert durch Code-Generierung
bieten. In diesem Rahmen werden stellvertretend für die kommerziellen,
professionellen Tools Rational Rose und Borland Together vorgestellt und
ArgoUML als Vertreter für die Open Source Anwendungen.
kooperative Ansätze – es konnten keine kooperativen Ansätze gefunden
werden, die sich wirklich sinnvoll in den Kontext der Arbeit einordnen
ließen und deren Detailuntersuchung Sinn gemacht hätte. Die Ansätze für
synchrone UML-Editoren, deckten sich nur rudimentär mit den
Anforderungen, hier lohnte sich keine Detailbetrachtung. Erwähnt sei noch
die Kooperationsmöglichkeit mit der natürlich im Prinzip jede Anwendung
verteilt werden kann, nämlich in Form gemeinsamer VNC- oder
Netmeeting-Sitzungen. So könnte z.B. ein räumlich entfernter Entwickler
per VNC auf die Rational Rose Instanz eines anderen Entwicklers
zugreifen und gemeinsam mit diesem darin modellieren. Diese
Möglichkeit untersuchen wir nicht genauer. Es ist jeweils klar, dass eine
Anwendung - ob nun mit oder ohne VNC - die Anforderungen im
didaktischen und im Entwurfskontext gleich bleibend erfüllt. Im Hinblick
auf die technischen Anforderungen wird zwar die Verteilung mit VNC
grundsätzlich möglich, jedoch fehlen die üblichen Awareness-Features
und der Einsatz ist nicht wirklich praktikabel, Benutzerinteraktionen per
VNC sind eher träge.
35
3.1 Beschreibung existierender Lösungsansätze
Im Folgenden werden die verschiedenen Ansätze im Einzelnen vorgestellt.
3.1.1 Konzeptionelles Szenario-Rollenspiel
Es wurde bereits mehrfach erwähnt, dass die Methode des Rollenspiels sich
besonders gut für die Vermittlung von dynamischen Aspekten in OOProgrammen eignet. Die face-to-face Variante, wie in 2.1.1 im Abschnitt
Rollenspiel beschrieben, ist ein erprobtes und gebräuchliches Instrument, das in
der Praxis im Unterricht eingesetzt wird. Daher ist es sinnvoll, diese Ansätze mit
in die Betrachtung des State of the Art einzubeziehen und mit den in Kapitel 2
analysierten Anforderungen zu vergleichen.
Der potenzielle Erfolg eine Rollespiels hängt offensichtlich mit der Wahl des zu
spielenden/simulierenden Szenarios und den Rollenbeschreibungen zusammen.
Andrianoff und Levine [And02]schlagen jeweils verschiedene konkrete Szenarien
und Skripte für verschiedene OO-Konzepte vor. Darunter befindet sich auch ein
Szenario das aus dem Kontext des Marine Biology Simulation Case Study
(MBCS) extrahiert wurde. Das MBSC-Szenario wird in diesem Abschnitt noch
einmal besonders erwähnt, weil es ein Beispiel dafür ist, dass die Rollenspiele
auch im Zusammenhang mit komplexeren Systemen sinnvoll eingesetzt werden
können, nämlich indem einzelne Funktionalitäten herausgegriffen und simuliert
werden.
MBCS
Die MBCS ist eine von Alyce Bryce [Brady05] entworfene Fallstudie, die seit
2003 ein fester Bestandteil des Lehrplans des Advanced Placement Program in
Computer Science[MBSC07] zur Einführung in die OOP ist.
Abbildung 3.1 – Hauptklassen der Marine Biology Simulation Case Study (aus [Brady05])
36
In der Fallstudie geht es um ein Software-System, das Meeresbiologen darin
unterstützen soll, das Verhalten von Fischen in abgeschlossen Umgebungen wie
Seen und Meeresbuchten zu untersuchen. Die Software simuliert das Verhalten
der Fische in einer Gitter-artigen Umgebung. Fische werden einer Umgebung
hinzugefügt oder entfernt, haben eine Ausrichtung und Farbe, eine Position und
sie können sich bewegen und ihre Positionen wechseln. Das System als Ganzes ist
relativ umfangreich und komplex. Abbildung 2.1 zeigt die Hauptklassen.
Die Studenten sollen lernen sich in ein komplexes bestehendes System
einzuarbeiten, und dieses um zusätzliche Funktionalitäten zu erweitern. Die
Studie soll ihnen die Illusion einer realen Projekt-Situation in der realen Welt
geben.
Mittlerweile existieren passend zu diesem System einige Rollenspiel-Szenarien
und Skripte der Art („You Are A Fish - When asked for your color say the value of
your Color recorded on your Private Data sheet – When asked for your location,
do…“), die das Verhalten der Objekte genau beschreiben. Die Akteure übernehmen die Rollen von Objekten und spielen die Interaktionen gemäß dem vorgegebenen Skript nach. Andrianoff und Levine belegen in [And02], dass Studierende
besseren Zugang zu der gesamten Studie finden, wenn ihr vorgeschlagenes
Rollenspiel zur Verdeutlichung der Interaktionen eingesetzt wird.
Szenario-Rollenspiel mit CRC-Karten und RPDs
Der Ansatz aus [Bör04] wurde bereits mehrfach erwähnt. Börstler stellt eine neue
Diagrammform für die Aufzeichnung von Objektinteraktionen in Rollenspielen
vor, das sogenannte Role-Play Diagram (RPD). In [Bör05] zeigt Börstler, wie
diese Diagramme im Zusammenhang mit CRC-Karten-Rollenspielen verwendet
werden und die Rollenspiele damit verbessert werden können. Börstler berichtet
über den erfolgreichen Einsatz von CRC-Karten-Rollenspielen, kombiniert mit
der Aufzeichnung in RPDs, in Rahmen von in OO-Design einführenden
Lehrveranstaltungen. Daneben sieht er aber auch die Eignung des Ansatzes im
Rahmen des professionellen System-Entwurfs (vgl. [Bör04])
In Abbildung 3.2 zeigt ein Rollenspiel-Diagramm nach Börstler. Das Diagramm
ist eine Mischform aus UML-Objektdiagrammen und Kooperationsdiagrammen
(vor UML2 Kollaborationsdiagramm). Zur Aufzeichnung von Rollenspielen
werden Notationsmöglichkeiten für Nachrichten und Objektzustände benötigt. In
UML-Kooperationsdiagrammen werden Nachrichten notiert, aber es ist nicht
vorgesehen, Objektzustände (also konkrete Attributwerte) aufzuzeichnen. Die
Nachvollziehbarkeit von Rollenspielen ist aber ohne diese Informationen schlecht
möglich, deshalb werden hier die entsprechenden Elemente aus UMLObjektdiagrammen verwendet. Die in den RPDs verwendete Notation ist
einfacher und formloser als die ihrer UML-Entsprechungen, u.a. ist das
Nummerierungsschema der Nachrichten in RPDs unkomplizierter gehalten. So
sind sie besser geeignet, um parallel zu den Rollenspiel-Aktivitäten Szenarien
aufzuzeichnen (vgl. [Bör04]).
37
Abbildung 3.2 - Aufzeichnung eines CRC-Karten- Rollenspiel in einem RPD (aus [Bör05])
Rollenspiel in der OO-Entwicklung kann nach dem Vorschlag von Börstler nun
folgendermaßen aussehen: Ein Entwickler-Team sitzt gemeinsam am runden
Tisch im Konferenzraum, es wird zunächst ein Analysemodell in Form von CRCKarten ausgearbeitet und es werden konkrete Anwendungsfälle/Szenarien in
textueller Form spezifiziert. Die Teammitglieder übernehmen die Rollen von
CRC-Karten und simulieren dialogartig das Verhalten der entsprechenden Objekte
mit den jeweiligen Verantwortlichkeiten. Ein Schriftführer protokolliert den
Ablauf eines Szenarios an einem Whiteboard in einem Role-Play Diagramm. Für
das Vorgehen nach Börstler gibt es bislang keine Toolunterstützung, es wird mit
PostIts, Whiteboard und Karteikarten gearbeitet.
Defizite: Ein offensichtliches Defizit der konzeptionellen Szenario-Rollenspiele
ist natürlich die fehlende technologische Unterstützung. So ist es nicht möglich,
Rollenspiele automatisch aufzuzeichnen, die Protokollierung ist immer
Handarbeit, die von einem Schriftführer übernommen werden muss. Durch das
Fehlen von expliziter technischer Unterstützung sind verteilte Rollenspiele
allenfalls in Form von Video-Konferenzen denkbar.
3.1.2 Lehr-/Lernanwendungen
Bereits in 2.1.1 waren wir kurz auf existierende Lehranwendungen und deren
Kategorisierung eingegangen. Hier werden nun die im Rahmen dieser Arbeit
interessanten Anwendungen herausgegriffen und noch einmal genauer vorgestellt.
BlueJ
BlueJ [BlueJ07]ist wohl die bekannteste und am häufigsten eingesetzte
pädagogische Java-Entwicklungsumgebung. BlueJ wurde speziell als Lehr- und
Lernanwendung konzipiert. BlueJ unterstützt den objects-first Ansatz, die
Anwender können Programme entwickeln ohne sich vorher mit Quelltexten
auseinandersetzen zu müssen, indem sie direkt mit Objekten und Klassen
interagieren.
38
Entwickelt wurde BlueJ 1999 von Michael Kölling und John Rosenberg an der
Monash Universität im australischen Melbourne, als ein Nachfolger des BlueSystems, einem integrierten System mit einer eigenen Programmiersprache und umgebung. BlueJ implementiert den Blue-Umgebungsentwurf für die Programmiersprache Java. Aktuell wird BlueJ gemeinsam von der University of Kent in
Canterbury, England – dort lehrt Kölling heute - und der Deakin University in
Melbourne, Australien geführt und weiterentwickelt.
Einen vergleichenden Überblick über BlueJ und seine Methodik findet man z.B.
in [Köl03]. In [Haa04] ist eine ausführliche Evaluierung von praktischen Einsätzen aufgeführt.
Abbildung 3.3 – BlueJ: Hauptfenster und Quelltext-Editor (aus[BlueJ07])
Das User-Interface von BlueJ ist übersichtlich und einfach gehalten (vgl.
Abbildung 3.3), so dass sich Anfänger auch ohne lange Einarbeitungszeit schnell
zurechtfinden können. Das Hauptfenster besteht zum einen aus einem Diagrammeditor, in dem in UML-ähnlicher Notation die Klassenstruktur der zu
entwickelnden Anwendung graphisch dargestellt wird. Zum anderen gibt es einen
Objektbereich, in dem die interaktiv erzeugten Objekte angezeigt, examiniert und
getestet werden können. Darüber hinaus gibt es Fenster für den Quelltext-Editor
und den integrierten Debugger.
Der Benutzer startet bei seiner Arbeit in BlueJ mit einer Menge von vordefinierten
Klassen – Programmentwicklung from scratch ist nicht vorgesehen. Dies ist nicht
unüblich für einführende OO-Lehranwendungen, wird aber auch durchaus
kritisiert (z.B. von den Autoren des Alice-Ansatzes in [Coo03]: „[...] these
approaches will leave students feeling they have no understanding of how to write
complete programs“). Besonderes Merkmal und einer der Hauptgründe für BlueJs
Stärken in der Vermittlung von Objekt und Klassen-Konzepten, sind die diversen
direkten Interaktionsmöglichkeiten mit den Artefakten, die dem Anwender
geboten werden. Der Benutzer kann direkt mit den Icons interagieren und so aus
einer Klasse Objekte erzeugen, von diesen Objekten Methoden ausführen lassen
und so ihr Verhalten illustrieren.
39
Funktionsausrichtung und –umfang von BlueJ deckt sich nur teilweise mit der
Zielsetzung dieser Arbeit. Vergleichbar wird es insofern, als dass es für die
Vermittlung von OO-Konzepten eingesetzt wird, visuelle Entwicklung unterstützt,
Klassen- und Objektstrukturen visualisiert und Benutzerinteraktionen auf ObjektLevel ermöglicht.
Hauptdefizite von BlueJ in Bezug auf die Anforderungen dieser Arbeit sind, dass
es nicht kooperativ in der Gruppe anwendbar, also nur als EinzelbenutzerAnwendung nutzbar ist. Dynamische Aspekte lassen sich nicht gut vermitteln, es
gibt keine Visualisierung des Programmflusses. Die Arbeit in [Rag05] zeigt sogar,
dass BlueJ bei den dynamischen Aspekten den Lernprozess eher behindert als
erleichtert.
Alice
Alice[Alice07] ist eine frei verfügbare, für Anfänger entwickelte, Programmierumgebung für die Erstellung von interaktive 3D-Graphiken und Animationen.
Ursprünglich entwickelt wurde Alice 1995 an der Carnegie Melon Univerity von
einer Forschungsgruppe unter der Leitung von Randy Pausch [Pau95] wurde es in
den letzten Jahren von Grund auf neu geschrieben.
In [Coo03] werden die konkreten Auswirkungen des Einsatzes von Alice im
Unterricht diskutiert.
Abbildung 3.4 – Alice: User-Interface (aus [Haa04])
Für die Repräsentation von Objekten verwendet Alice eine anthropomorphe
Metapher. In der Alice-Umgebung kann der Benutzer 3D-Objekte
nutzen/modifizieren und Programme (per Storyboarding mit Pseudo-Code in
Alice-Lingo) schreiben. Dabei lässt Alice dem Ausbilder bzw. Anwender die
Wahl, ob er die Entwicklung der virtuellen Welt from scratch oder mit
vorgefertigten Programmteilen startet. Das Hauptfenster (s. Abbildung 3.4)
besteht aus einer baumartigen Ansicht der Objekte der aktuellen Welt, einer
initialen Szene, einer Liste mit den Events der aktuellen Welt, und dem CodeEditor. Der Anwender bevölkert in einer kleinen virtuellen Welt eine initiale
Szene mit 3D-Objekten. Jedes Objekt kapselt seine eigenen Daten und verfügt
über seine eigenen Methoden. Ein Objekt kann per Drag&Drop in den Code-
40
Editor gezogen werden. In dem Editor können Aussehen und Verhalten geändert
und über Dropdown-Menüs können primitive Methoden ausgewählt werden, mit
denen dann eine Nachricht an das Objekt geschickt werden und Verhalten getestet
werden kann.
Laut [Coo03] hilft die visuelle Umgebung von Alice den Lernenden ein sicheres
Gefühl für Objekte zu entwickeln. Die interaktiven Methodenaufrufe auf Objekten
fördern das Verständnis für Kapselung und für Methoden bzw. Message Passing.
Auch das Gefühl für Programmzustände wird gefördert. Es lässt sich beobachten,
dass die Anwender von Alice ein intuitives Gefühl für Verhalten und Ereignisgesteuerte Programmierung entwickeln.
Defizite in Bezug auf die Anforderungen dieser Arbeit: Alice ist kein
Mehrbenutzersystem und lässt sich nicht verteilt einsetzen. Es ist allerdings
möglich Objekte zwischen verschiedenen virtuellen Welten zu transferieren.
Kollaboration ist also derart möglich, dass Benutzer einzeln Charaktere
konstruieren und diese dann in einem Gruppenprojekt in einer gemeinsamen
virtuellen Welt mit anderen kombinieren. Alice eignet sich zwar gut, um
Programmabläufe zu visualisieren, „echtes“ und vor allem interaktives
Rollenspiel wird dabei allerdings nicht unterstützt.
ViRPlay
ViRPlay ist ein Tool, das Anwendern das Verstehen von Interaktionen in JavaProgrammen mithilfe von Rollenspielen in einer virtuellen 3D-Welt ermöglichen
soll. Das Tool folgt dem von Jimenez-Diaz et al. in [Diaz05a] vorgestellten
Ansatz, der Ideen aus dem Bereich der Softwarevisualisierung und dem Bereich
der aktiven Lernmethoden - dazu gehören Rollenspiele - vereint.
ViRPlay verwendet ebenso wie Alice eine anthropomorphe Metapher, jedes
Objekt wird durch einen anthropomorphen Avatar repräsentiert. Die
Nachrichtenübermittlung wird durch das Werfen eines Balls zwischen den
Avataren dargestellt. Der Ball und ein Spotlight über den Avataren repräsentieren
den Kontrollfluss. Der Ball enthält Informationen über die aufgerufene Methode,
incl. Parameter- und Rückgabewerten. Die Objekte sind die Figuren, die an dem
Rollenspiel teilnehmen, zu jeder Figur werden Objektname und zugehörige Klasse
angezeigt. Das aktive Objekt hat den Ball, und wird vom Spotlight beleuchtet.
Jedes Objekt hat ein Inventar (ähnlich wie in Adventure-Spielen), das den
Objektzustand und statische Informationen enthält. Über das Inventar lässt sich
auch der zur Klasse des Objekts gehörige Sourcecode einsehen. Wenn Objekt A
eine Methode von Objekt B aufruft, wird der Ball B zugeworfen und das Spotlight
auf B gesetzt. Wenn Objekt B die Nachricht fertig bearbeitet hat, rollt (anstatt
wirft) es den Ball zurück zu A und gibt damit auch die Kontrolle zurück.
ViRPlay lässt sich insofern mit dem Ansatz dieser Arbeit vergleichen, als dass es
virtuelles Rollenspiel umsetzt und Programmfluss interaktiv simuliert werden
kann.
Defizite: Zum Zeitpunkt der Veröffentlichung des Papers zur ViRPlay [Diaz05b]
war die Möglichkeit der kooperativen Anwendung für zukünftige Versionen zwar
angedacht, aber noch nicht umgesetzt. Komplexere Abläufe mit vielen Objekten
und Nachrichten werden schnell unübersichtlich.
41
Abbildung 3.5 ViRPlay : Screenshot der Benutzeroberfläche (aus [Diaz05a])
3.1.3 UML-Modellierungs-Tools
Es gibt eine Reihe von professionellen Design-Werkzeugen zur visuellen
Modellierung mit UML-Diagrammen, die im Kontext der Softwareentwicklung
eingesetzt werden. Diese Werkzeuge sind auf den professionellen Anwender
ausgerichtet und aufgrund ihrer Komplexität üblicherweise nicht für den
einführenden Unterricht geeignet. Interaktionen auf Objekt-Level werden von
solchen Tools im Allgemeinen nicht unterstützt (vgl. [Köl03], S.9).
Diese UML-Modellierungs-Tools basieren alle auf ähnlichen Prinzipien und
unterstützen sowohl Reverse (vom Code zum Diagramm) als auch Forward (vom
Diagramm zu Code)-Engineering. Die Oberfläche solcher UML-Tools enthält als
Hauptelemente üblicherweise einen Modell-Explorer, einen Diagramm-Editor und
einen Quellcode-Editor. Der Anwender entwirft sein Domänen-Modell im
Diagramm-Editor und kann per Knopfdruck aus dem Diagramm Code-Gerüste
generieren lassen. Die Gegenrichtung, vom Sourcecode zum Klassendiagramm
wird ebenso unterstützt. Die Anwendung synchronisiert jeweils zwischen
Diagramm- und Quellcode-Editor. Exportiert werden die Modelle üblicherweise
im XML Metadata Interchange (XMI) Format, das ist der Standard für die
Erfassung der Meta-Daten, die ein bestimmtes UML-Modell ausmachen (umfasst
aber keine Layout-Informationen).
Die Anwendungen lassen sich insofern mit den Anforderungen dieser Arbeit
vergleichen, als dass sie ebenfalls die visuelle Entwicklung von DomänenModellen unterstützen und Mehrwert durch Code-Generierung bieten. In diesem
Rahmen werden stellvertretend für die großen, kommerziellen Tools Rational
Rose und Borland Together vorgestellt und ArgoUML als Vertreter für die Open
Source Anwendungen.
Borland Together
Together [Tog07]ist eine kommerzielle Produktlinie von Borland für den Entwurf
und die visuelle Modellierung von Softwarearchitekturen. Together kann in
42
verschiedene Entwicklungsumgebungen integriert werden, es gibt Versionen für
Microsoft Visual Studio, Borland JBuilder und Eclipse. Diverse
Programmiersprachen und Plattformen werden unterstützt.
Borland Together Edition für Eclipse, eine integrierte und flexible
Designumgebung, sie hilft Teams, die Entwicklung hochwertiger Anwendungen
mit der Open-Source-Plattform Eclipse wesentlich zu beschleunigen. Die
Softwarelösung, als eine Art Brücke zwischen Endanwendern, SoftwareArchitekten und Entwicklern konzipiert, eignet sich zum visuellen Modellieren
von Software, zum Messen der Software-Qualität und zur Verbesserung der
Team-Produktivität.
Wie in Abbildung 3.6 zu sehen ist, besteht das Hauptfenster aus einem ModellExplorer, dem Diagramm-Editor, einer Palette und einem Properties-Bereich.
Modellierte Strukturen können im Quellcode-Editor betrachtet und modifiziert
werden. Das Modell kann als XMI exportiert werden.
Abbildung 3.6 – Borland Together for Eclipse: User-Interface
ArgoUML
ArgoUML ist ein an der University of California, Irvine entwickeltes OpenSource
Projekt – Ein freies UML-Modellierungs-Tool mit kognitiver Unterstützung.
ArgoUML ist unter der BSD Lizenz lizensiert. Es gibt einige kommerzialisierte
Erweiterungen, die auf ArgoUML basieren, darunter auch das etwas bekanntere
Poseidon for UML von Gentleware [Pos07]. Zu den unterstützten Diagrammen
gehören Klassen-, Zustands-, Use Case-, Aktivitäts-, Kollaborations-, Sequenzund Deploymentdiagramme. Als OpenSource-Projekt ist ArgoUML natürlich
lange nicht so ausgereift und stabil wie die großen kommerziellen
Modellierungstools. Auch vom Umfang kann es nicht mithalten. Die Sequenzdiagramme werden z.B. nicht vollständig unterstützt, es gibt keine professionellen
Features wie Qualitätsanalysen und Unterstützung für Patterns. Aber das Tool soll
hier sowieso nur im Hinblick auf die elementare, visuelle Modellierung und die
Code-Generierung betrachtet werden. Im Gegensatz zu den anderen beiden
vorgestellten Modellierungswerkzeugen ist ArgoUML eine Standalone-
43
Anwendung und kann nicht in eine IDE intergriert werden. Dafür ist das
Benutzer-Interface von ArgoUML übersichtlich und wird allgemein als intuitiv
bedienbar empfunden. Der Export als XMI wird unterstützt. Die CodeGenerierung beschränkt sich auf Java.
Abbildung 3.7 – ArgoUML: HauptfensterAbbildung 3.7 zeigt die Benutzeroberfläche von ArgoUML.
Abbildung 3.7 – ArgoUML: Hauptfenster
IBM Rational Rose
Rational Rose [Rose07] gilt als Referenztool für die UML-Modellierung. Es
richtet sich an professionelle Systementwickler. Es unterstützt die iterative
Entwicklung (einschließlich inkrementeller Quellcode-Erzeugung und RetroCode-Entwurf) in den wichtigsten Programmierumgebungen. Rational Rose
übernimmt die gesamte Modellierung, von Prozessen und Softwarearchitekturen
bis zu den Daten, IHM und Web-Besonderheiten. Es gibt eine Code-QualitätsAnalyse. Rational Rose ist als CASE-Tool speziell an den Einsatz im Rational
Unified Process angepasst.
Bei der Arbeit mit Rose ist neben der Möglichkeit, UML-Diagramme zu
zeichnen, das eigentlich Wichtigere, dass Rose es erlaubt, alle technischen
Konstrukte, die für die Erstellung der Software erstellt werden, zu verwalten.
Mithilfe eine Use-Case-gesteuerten Arbeitsweise erstellen man ein Modell der
Applikation, von dem ausgehend man sich alle Arbeitsergebnisse, die
erstellt wurden, wieder erschließen kann.
Die Arbeitsweise mit Rose kann man sich dabei folgendermaßen vorstellen (vgl.
[Borr02]: .Zunächst werden die Akteure und die für diese zu implementierenden
Use-Cases in entsprechenden Diagrammen erfasst. Damit hat man dann eine
Sammlung der Hauptfunktionen, die das Programm dem Kunden bieten soll. Als
Nächstes werden die Abläufe in den Use-Cases in Form von Szenarios
beschrieben. Rose lässt dem Anwender dabei die Wahl, ob er lieber mit Sequenzoder mit Kollaborationsdiagrammen arbeiten möchte. Szenarios können als
44
Instanzen von Anwendungsfällen betrachtet werden. Die beiden Diagrammarten
lassen sich per Kopfdruck auseinander erzeugen. Die Definition der für die
Objekte notwendigen Klassen kann direkt aus den Szenariodiagrammen heraus
erfolgen. In Abbildung 3.8 ist das Haupfenster von Rational Rose zu sehen.
Abbildung 3.8 – Hauptfenster von Rational Rose
Der Nachteil professioneller Tools wie Rational Rose und Together liegt in der
Komplexität der Benutzeroberflächen, Benutzer benötigen viel Einarbeitungszeit.
Für Anfänger sind sie in der Regel nicht geeignet.
3.2 Gegenüberstellung von Lösungsansätzen und Anforderungen
Tabelle die Anforderung aus 2.2.4 den Lösungen gegenüberstellt
DA11 Benutzerinteraktionen auf Objektebene
Pädagogische Anwendungen für die OO-Einführung unterstützen in der Regel
die Benutzerinteraktion auf Objektebene und die in 3.1 in dieser Kategorie
vorgestellten Ansätze bilden hier keine Ausnahme. Alle vorgestellten Ansätze
lassen es zu, dass Benutzer interaktiv Objektzustände zu verschiedenen
Ausführungszeitpunkten untersuchen, dabei in Objekte hineinschauen und mit
diesen interagieren zu können. Sie sind darauf ausgerichtet, den Anwender
beim Begreifen des Objekt-Konzepts zu unterstützen.
Anders sieht es bei den professionellen UML-Tools für Software-Entwicklung
aus. Hier ist es in der Regel nicht üblich, den Benutzer mit Objekten
interagieren zu lassen (vgl. [Köl03], S.9). Der Umgang mit Objekten
1
DA steht für didaktische Anforderung
45
beschränkt sich auf ihre statische Darstellung in den entsprechenden
Diagrammformen (Objektdiagramme, Sequenzdiagramme, Kommunikationsdiagramme, etc). „Echte“ Interaktionsmöglichkeiten, wie sie für die Einführung
in OOP benötigt werden, werden nicht geboten.
DA2
Kapselung
In BlueJ, Alice und ViRPlay werden Objekte als gekapselte Einheiten
wahrgenommen, dadurch dass Benutzer interaktiv in die Objekte „hinein
sehen“ können. Private Attribute können nur über den Aufruf von Methoden
manipuliert werden. Der Einblick in Objektzustände ist allerdings nicht auf
Rollen beschränkt, ein Anwender kann in jedes Objekt hineinsehen.
Die Szenario-Rollenspiele eignen sich gut zur Umsetzung des Konzepts der
Kapselung, die einzelnen Teilnehmer müssen einfach angewiesen werden, die
privaten Attribute ihrer Objekte jeweils voreinander geheim halten und
Änderungen nur auf Aufforderung - in Form einer entsprechenden Nachricht vorzunehmen.
Bei den vorgestellten UML-Tools gibt es keine besonderen Maßnahmen, die
das Konzept der Kapselung in expliziter Form verdeutlichen würden.
DA3
Interaktives Senden von Nachrichten
In allen vorgestellten didaktischen Anwendungen ist es möglich, interaktiv aus
dem Kontext eines Objekts heraus Methoden aufzurufen/Nachrichten zu
senden. In BlueJ können über das Kontextmenü eines Objekts die Methoden
dieses Objekts aufgerufen werden, Das Senden einer Nachricht von einem
Objekt zu einem anderen ist nicht möglich. In Szenario-Rollenspiele ist es
natürlich möglich, dass Akteure sich Nachrichten schicken könne.
In diesem Zusammenhang gilt für die UML-Tools dasselbe wie für DA1, sie
unterstützen diese Art der Benutzer-Interaktion nicht. In einem SequenzDiagramm können zwar Nachrichten als Diagrammelemente erzeugt werden,
aber hier geht es nur um die Darstellung, Nachrichten bzw. die entsprechenden
Methoden werden nicht im eigentlichen Sinn „ausgeführt“.
DA4
Interaktives Erzeugen von Objekten
Alle didaktischen Anwendungen unterstützen das interaktive Erzeugen von
Objekten. Die vorgestellten Ansätze zeichnen sich alle dadurch aus, dass sie
dem Anwender ein starkes Bewusstsein für Objekt und Klassen vermitteln. Es
ist jeweils möglich interaktiv Objekte zu erzeugen.
In den UML-Tools können die für die Verwendung in Sequenz- und
Objektdiagrammen benötigten Objekte aus Klassen erzeugt werden.
DA5
Objektbeziehungen
ViRPlay erfüllt diese Anforderung vollständig, Nachrichten können nur an die
im Inventar eines Objekts aufgeführten Collaborators geschickt werden.
UML-Tools bieten hier keine gezielte Unterstützung, abgesehen von der
Visualisierung der Beziehungen in den Diagrammen.
DA6
EA6
TA2
46
Die handschriftlich erstellten RPDs der Szenario-Rollenspiele eignen sich als
Kommunikationsmedium.
BlueJs Diagrammdarstellung ist UML-Diagrammen nachempfunden und sollte
sich daher als Kommunikationsmedium einsetzen lassen. Die graphischen
Visualisierungsformen (3D-Welten) von Alice und ViRPlay eignen sich nicht
als Dokumentations- und Kommunikationsmedium. Denkbar wäre es allenfalls
bestimmte Zustände mit Screenshots festzuhalten, aber deren spätere
Aussagekraft in Bezug auf das modellierte System dürfte zweifelhaft sein.
Sinn und Zweck der UML-Tools ist nun gerade der Umgang mit UMLDiagrammen, die vorgestellten Ansätze bieten also hier die ganze Palette an
Diagrammen die zur Visualisierung und Kommunikation verwendet werden
können.
Explizite Nachrichtenhistorien (zusätzlich zur Diagrammdarstellung) sind in
den vorgestellten Anwendungen nicht vorgesehen
DA7
Unterstützung lokaler und verteilter Lehre
Verteilte Szenario-Rollenspiele wären z.B. in Form von Videokonferenzen
denkbar.
BlueJ und Alice lassen sich nicht verteilt einsetzen. In Alice ist es allerdings
möglich Objekte zwischen verschiedenen virtuellen Welten zu transferieren.
Lokale Kollaboration ist also derart möglich, dass Benutzer einzeln Charaktere
konstruieren und diese dann in einem Gruppenprojekt in einer gemeinsamen
virtuellen Welt mit anderen kombinieren. Für ViRPlay ist eine
Kooperationsunterstützung geplant.
Die UML-Tools sind nicht kooperativ nutzbar.
DA8
Szenario-Rollenspiele lassen sich beliebig anpassen, neue Erkenntnisse können
direkt durch Ändern des Verhaltens von Akteuren umgesetzt werden.
Die Lehranwendungen arbeiten teilweise mit vordefinierten Klassen, hier lassen
sich Änderungen nicht immer so ohne weiteres umsetzen.
In den UML-Tools lassen sich anhand der Diagramme Modell-Änderungen
schnell und fexibel umsetzen.
DA9
Rollenspiel
BlueJ unterstützt keine Rollen. ViRplay steht ja nun gerade für Virtual Role
Play, hier wird Rollenspiel also unterstützt, Benutzer können die Rolle von
Objekten übernehmen und Programmfluss simulieren indem sie Nachrichten
von anderen Objekten empfangen und bearbeiten. Alice kann kein echtes
Rollenspiel, hier kann der Benutzer zwar interaktiv auf Objekte zugreifen und
an diesen Objekten auch Methoden aufrufen, aber die Simulation des
Nachrichtenflusses kann nicht interaktiv erfolgen.
Die UML-Tools unterstützen kein Rollenspiel
47
EA11: Identifikation der Objekte
EA2: Identifikation der Nachrichten
EA3: Reaktion auf Nachrichten
EA4: Identifikation der Objekt-Beziehungen
BlueJ ermöglicht keine interaktive Programm-Simulation, ermöglicht aber die
Exploration der Objekte und das Ausführen einzelner Methoden. Insofern sind
E1 und E3 voll erfüllt und EA2 und EA4 nur teilweise.
ViRPlay lässt interaktive Simulation zu und ermöglicht damit die volle
Explorationes des Problembereichs, erfüllt E1-E4 also vollständig.
Die UML-Tools erlauben üblicherweise kein interaktives Explorieren des
Objektraums und keine Simulation von Objektinteraktionen, insofern erfüllen sie
EA1-EA4 nicht im Sinne unserer Anforderungen.
EA5: Testmöglichkeiten
Alice und BlueJ ermöglichen den interaktiven Aufruf und Test einer Methode
eines Objekts. ViRPlay ermöglicht interaktive Simulation von ganzen Abläufen,
bietet hier also weitergehende Testmöglichkeiten.
Rational Rose und Together sind jeweils eng mit Java-IDEs verzahnt, durch die
Synchronisation von Diagrammen und Quellcode ist es möglich diesen Code
gleich innerhalb der IDE zu testen. Zudem gibt es Code-Qualitätsanalysen die
Modell-Schwächen offenbaren können. ArgoUML ist ein StandaloneModellierungs-Tool hier ist das Testen also nicht so ohne weiteres möglich.
EA8:
Angebot des potenziellen Mehrwerts für die Anwender
Die UML-Tools bieten Mehrwert durch Code-Generierung, Code-QualitätsAnalysen, Exportmöglichkeiten ins XMI-Format.
EA9:
Die Lehranwendungen arbeiten teilweise mit vordefinierten Klassen, hier lassen
sich Änderungen nicht immer so ohne weiteres umsetzen.
In den UML-Tools lassen sich anhand der Diagramme Modell-Änderungen
schnell und fexibel umsetzen
EA10: Nachvollziehbarkeit
Entwurfsentscheidungen werden weder in den didaktischen Anwendungen noch
in den UML-Tools nachvollziehbar protokolliert
Gemeinsamer Informationsraum
TA1
TA3
Synchrone Kommunikation
TA4
Awareness
TA5
Modellierung von Rollen
TA6
Synchronisation des Diagramms
Da keine der vorgestellten Anwendungen die Kooperation mehrerer Benutzer
unterstützt, kann offensichtlich auch keine der Anforderungen TA1, TA3-TA6
erfüllt werden.
TA7 Code-Generierung
BlueJ kann aus Klassendiagrammen Sourcecode erzeugen.
Die UML-Tools bieten alle die Möglichkeit aus den Diagrammen Sourcecode zu
erzeugen
TA8 Visualisierung des Nachrichtenflusses
:
In echten Rollespielen kann Nachrichtenfluss leicht durch einen Gegenstand der
1
EA steht für Entwicklungs-Anforderung
48
die Kontrolle signalisiert und weitergegeben wird visualisiert werden. In RPD
wird die Kontrolle des aktiven Elements mit einem Stern visualisiert.
ViRPlay visualisiert den Nachrichtenfluss in einer 3D-Welt durch das Werfen
eines Balls zwischen Avataren. Alice visualisiert den Nachrichtenfluss durch
Animation der 3D-Objekte. BlueJ visualisiert Nachrichtenfluss nicht.
Die UML-Tools bieten außer der statischen Darstellungen in Sequenz- und
Kooperationsdiagrammen keine besondere Visualisierung von Nachrichtenfluss
TA9:
Historie
ViRPlay ist die einzige Anwendung, die interaktive Simulationen ermöglicht
und damit eine Historie von Interaktionen aufzeichnen könnte. Tatsächlich wird
aber nur die jeweils letzte Nachricht visualisiert, eine komplette Liste der
Interaktionen wird nicht geführt.
Die Anwendungen sind alle keine Mehrbenutzeranwendungen, daher benötigen
sie in der Regel kein Usermanagement und bieten es auch nicht an.
T11: Persistenz
Die Daten der Anwendungen werden jeweils nur lokal gespeichert.
4 Lösungsansatz
49
4 Lösungsansatz
Als Lösungsansatz zur Erfüllung der in Kapitel 2 hergeleiteten Anforderungen
wurde im Rahmen dieser Arbeit die Anwendung COINED (Collaborative
Examination of Object Interaction) konzipiert und implementiert. Es handelt sich
dabei um eine Groupware mit der eine lokale oder verteilte Gruppe von Benutzern
gemeinsam Nachrichtenfluss und Objektinteraktionen eines objektorientierten
Systems simulieren und visualisieren kann
An
einem
benutzerdefinierten
Domänen-Modell
werden
konkrete
Systemfunktionalitäten
rollenspielartig
durchexerziert.
Die
Anwender
übernehmen die Rollen einzelner Klassen und simulieren die Reaktion der
Exemplare dieser Klassen auf empfangene Nachrichten. Die Reaktion eines
Objekts auf eine empfangene Nachricht kann dabei Verschiedenes beinhalten, u.a.
•
•
•
•
die Erzeugung/Manipulation lokaler Variablen
eine Zustandsänderung durch Editieren der Attributwerte
das Senden neuer Nachrichten an andere Objekte
das Senden einer Antwort an das aufrufende Objekt.
COINED wurde als verteiltes System in Form einer Client-/Server-Architektur
realisiert, wobei der Server als standardisierte Webapplikation und der Client als
Plugin für das Open-Source Entwicklungsframework Eclipse umgesetzt wurden.
.
Abbildung 4.1 – COINED Benutzeroberfläche
Der COINED-Client präsentiert sich dem Benutzer in Form einer EclipsePerspektive als eine Sammlung verschiedener Sichten (Views), vgl. Abbildung
4.1. Das Diagramm (1) ist dabei das Kernstück, hier werden Objekte,
Beziehungen und Nachrichtenfluss in Diagrammform dargestellt und dynamisch
visualisiert. Die Klassenliste (2) und die Objektliste (3) dienen als Klassen- resp.
Objekt-Repository. Im Bereich MessageProcessing (4) findet während einer
4 Lösungsansatz
50
Simulation die Bearbeitung von empfangenen Nachrichten statt und der Bereich
MessageHistory (5) liefert einen chronologischen Überblick über alle gesendeten
Nachrichten sowie über alle Benutzer-geführten Zuweisungen. Die Buddy-Liste
(6) liefert einen Überblick über die Projektteilnehmer und ihre Onlinestati. Der
Chat (7) bietet den Teilnehmern die Möglichkeit der synchronen, Simulationsbegleitenden Kommunikation
Im Folgenden werden wir anhand von Beispielszenarien erläutern, wie sich
COINED sowohl im didaktischen als auch im Entwurfs-Kontext einsetzen lässt
und inwiefern es die jeweiligen Anforderungen erfüllt. Anschließend geben wir
einen Überblick über COINEDs Architektur und technische Umsetzung, sowie
über die verwendeten Design-Patterns und zeigen auf, inwieweit den technischen
Anforderungen entsprochen wird.
4.1 OO-Lehre: Szenario und Lösungsdarstellung
Das folgende Beispielszenario soll den möglichen Einsatz von COINED im
Rahmen der Lehre verdeutlichen.
Ein Informatik-Professor an einer Fern-Universität möchte im Rahmen seiner
Vorlesung „Einführung in die objektorientierte Programmierung“ seinen
Studenten einige OO-Grundkonzepte (insb. Objektinteraktionen und den
Message-Passing-Mechanismus) mithilfe eines Rollenspiels verdeutlichen. Bei
der Wahl des Rollenspiels entscheidet er sich für ein, aus der Marine Biology
Simulation Case Study (MBCS, s. [Brady05]) extrahiertes Szenario, das in der
Fachliteratur[And02] für die Demonstration von Message-Passing vorgeschlagen
wird.
In der MBCS wird, mit Schwerpunkt auf pädagogischen Aspekten, eine
Aquarium-Simulationssoftware realisiert. Fische werden einer Umgebung
hinzugefügt oder entfernt, haben eine Ausrichtung und Farbe, eine Position und
sie können sich bewegen und ihre Positionen wechseln. Das System als Ganzes ist
relativ umfangreich und komplex, für das Rollenspiel wird daher nur ein
spezielles vereinfachtes Szenario, ähnlich zu [Diaz05a] eingesetzt. Es soll den
Benutzern klar machen, auf welche Weise die Hauptklasse Fische erzeugt und
initialisiert.
Der folgende Ablauf wird dann mit verteilten Rollen (ein Student übernimmt die
Rolle des Fisches f1, andere sind env, loc, oder theMBSDemo) durchgespielt. Für
jede Rolle wird das Verhalten vorher genau festgelegt (vgl. die
JavaRolePlayScripts aus [Brady05]).
An einer Fern-Universität kann ein solches Rollenspiel nun nicht auf klassische
Weise im Hörsaal mit anwesenden Studenten durchgespielt werden. Die
Fernstudenten sitzen vielmehr verteilt an verschiedenen Orten und nutzen u.a.
Rechner mit Internetanschluss zur Kommunikation. Deshalb beschließt der
Professor COINED für die Durchführung seines Rollenspiels einzusetzen. Der
COINED-Server soll auf einem Rechner in der Universität laufen.
4 Lösungsansatz
51
Abbildung 4.2 - MBCS-Beispielszenario
Die Studenten arbeiten in kleinen Gruppen von jeweils 4 Teilnehmern. Jedes
Gruppenmitglied startet seinen eigenen COINED-Client, indem es seine jeweilige
Eclipse-Umgebung startet und innerhalb von Eclipse in die COINED-Perspektive
wechselt (s. Abbildung 4.3).
Abbildung 4.3 – Aktivierung der COINED-Perspektive in Eclipse
Hier loggt er sich zunächst auf dem Server ein und öffnet anschließend das vom
Professor vorbereitete Projekt „Aquarium“.
Abbildung 4.4 – Login und Projektwechsel
4 Lösungsansatz
52
Das Projekt enthält bereits alle benötigten Klassen (MBSDemo, Fish,
BoundedEnv, Location), aber noch keine Objekte. Zunächst wartet die
Gruppe, bis alle Teilnehmer online sind und das Projekt geöffnet haben. Das ist
der Fall, wenn in der BuddyListe alle Status-Icons grün sind. In Abbildung 4.5
sehen wir eine Momentaufnahme aus Alices Sicht: Mary ist offline, Paul ist
online und hat das Projekt geöffnet, Peter ist online aber noch nicht im Projekt.
Abbildung 4.5 – Die BuddyListe aus Alices Sicht:
Die Rollen werden verteilt, Peter soll für Location zuständig sein, Paul für
Fish, Mary für BoundedEnv und Alice für theMBSDemo. Diese Zuordnungen
werden im ClassView über den Eintrag „Direct this class“ im Kontextmenü einer
Klasse vorgenommen (s. Abbildung 4.6). Innerhalb der COINED-Umgebung trägt
der jeweils für eine Klasse zuständige Benutzer die Bezeichnung Director. Nur
der Director hat die Befugnis, Objekte aus einer Klasse zu erzeugen und auf
Nachrichten zu reagieren.
Abbildung 4.6 – Rollenzuordnungen im ClassView
Nach erfolgter Zuordnung kann Peter als Director der Klasse Location das
Objekt loc erzeugen, Paul erzeugt f1:Fish, Mary env:BoundedEnv und Alice
theMBSDemo:MBSDemo. Das Erzeugen eines neuen Objekts geschieht ebenfalls
über das Kontextmenü einer Klasse im ClassView.
Vom theMBSDemo-Objekt soll der Nachrichtenfluss starten, deshalb legt Alice als
Director von MBSDemo initiale Beziehungen zu den vorhandenen Objekten
mithilfe von entsprechenden Attributen fest. Hierzu wechselt sie in den
ObjectView und selektiert theMBSDemo. Daraufhin werden die aktuellen
Attributwerte in der Objektdetail-Maske angezeigt, wo Alice sie direkt
manipulieren kann (s. Abbildung 4.7)
4 Lösungsansatz
53
Abbildung 4.7 – Editieren von Objektdetails im ObjectView: Alice ist im Begriff, dem
Attribut theEnv des Objekts theMBSDemo einen Wert zuzuweisen
Jetzt kann die eigentliche Simulation beginnen. Zunächst soll die main()Methode von theMBSDemo aufgerufen werden. Ein beliebiges Gruppenmitglied
ruft „Send Initial Message To“ im Kontextmenü von theMBSDemo auf. Im sich
daraufhin öffnenden MsgProcessingView wird in dem „Create New Request“Dialog theMBSDemo als Empfänger automatisch eingetragen, der Benutzer wählt
dessen einzige Methode main und verschickt die Nachricht durch Betätigen den
Send-Buttons.
Daraufhin wird der Empfänger der Nachricht (theMBSDemo) aktiviert und die
Kontrolle an den Director von theMBSDemo (Alice) übergeben. Visualisiert wird
die Aktivierung eines Objekts durch die den Wechsel seiner Hintergrundfarbe und
durch die Markierung mit dem Sternsymbol (vgl. Abbildung 4.8).
Abbildung 4.8 - Visualisierung des aktiven Objekts und der letzten Nachricht
Alice hat also nun die Kontrolle und muss die empfangene Nachricht im
MsgProcessingView verarbeiten und beantworten. Laut Script soll die init()Methode des Objekts loc aufgerufen werden. Alice muss also die entsprechende
Nachricht an das Objekt loc schicken. Loc ist in dem Attribut theLoc gespeichert,
also zieht sie dieses Attribut mit der Maus vom ObjectView in das „SendTo“-Feld
und wählt dann im Dropdown-Menü „Request Name“ die Nachricht init aus. In
der Tabelle darunter belegt sie noch die Parameter mit den gewünschten Werten
(2,2).
4 Lösungsansatz
54
Abbildung 4.9 – MessageProcessingView unmittelbar vor dem Senden von init(2,2) an
loc
Mit dem Send-Button wird die Nachricht gesendet und die Kontrolle an das
empfangende Objekt loc weitergereicht. Peter als Director von loc ist nun für
die Bearbeitung der Nachricht zuständig. Per Drag&Drop speichert er die
Argumente der Nachricht in locs Attributen und schließt die Bearbeitung mit
Betätigung des Finish-Buttons ab. Die Kontrolle geht daraufhin zurück an
theMBSDemo, Alice ist wieder am Zug. Sie konstruiert und schickt nun die
Nachricht init(env,loc) an das Fisch-Objekt f1. Paul ist Director der FischKlasse, also bekommt er als nächstes die Kontrolle. Die in den Argumenten der
empfangenen Nachricht enthaltenen Referenzen auf loc und env legt Paul für die
spätere Verwendung in den entsprechenden Feldern von f1 ab. Nachdem der Fisch
f1 jetzt das Objekt env kennt und mit ihm kommunizieren kann, sendet Paul die
Nachricht randomDirection an env um eine initiale Ausrichtung für den Fisch
zu erhalten. Das Objekt env wird aktiviert, Mary hat die Kontrolle. Sie
beantwortet die Nachricht mit der Rückgabe einer zufälligen Ausrichtung. Pauls
Fisch f1 erhält die Antwort und speichert den Wert in seinem Attribut myDir. In
den nächsten Schritten generiert Paul eine zufällige initiale Farbe indem er die
Nachricht randomColor an sich selbst sendet und selbst beantwortet. Die Farbe
wird im Attribut myColor abgelegt. Damit ist der Fisch soweit initialisiert, dass
er der Umgebung hinzugefügt werden kann, also sendet Paul die Nachricht add
mit sich selbst als Parameter an das Objekt env. Mary fügt die so erhaltene
Referenz auf f1 in die Umgebung ein und gibt die Kontrolle direkt wieder zurück.
Paul kann nun seinerseits f1s Bearbeitung der init()-Nachricht von
theMBSDemo abschließen, der Kontrollfluss landet damit wieder theMBSDemo.
Abbildung 4.10 zeigt den Stand des Diagramms und der Nachrichtenhistorie zu
diesem Zeitpunkt.
An diesem Fallbeispiel werden bereits einige der Merkmale deutlich, mit denen
COINED Lernprozesse unterstützen kann. Im Folgenden stellen wir nun genauer
gegenüber, welche Merkmale jeweils die einzelnen didaktischen Anforderungen
erfüllen.
4 Lösungsansatz
55
Abbildung 4.10 Protokollierter Nachrichtenfluss am Ende des durchgespielten Szenarios
DA1: Benutzerinteraktion auf Objektebene
In COINED: Direkter Zugriff auf Objekte ist zum einen im ObjectView und zum
anderen im DiagramView möglich. Im Diagramm werden die einzelnen Objekte
in Form von Rechtecken, ähnlich der Notation in UML-Objekt-Diagrammen,
visualiert. Der Objektname, -typ und die sowie Attributnamen und –werte zu
einem bestimmten Zeitpunkt werden angezeigt. Assoziationen zwischen Objekten
werden über gerichtete Linien visualisiert. Über das Kontextmenü eines Objekts
können die Objektdetails und Messagestack des Objekts geöffnet werden, d.h. die
Wahl des entsprechenden Menüeintrags aktualisiert den MessageProcessingView
bzw. die ObjectDetails-Maske mit den Daten des aktuellen Objekts. Eine andere
Sichtweise auf die Objekte findet sich im ObjectView. Hier werden die Objekte
eines Projekts listenartig aufgeführt. Die Auswahl der angezeigten Objekte lässt
sich über Filter beschränken, z.B. kann der Benutzer nur die von ihm dirigierten
Objekten auflisten lassen. Die Selektion eines Objekts der Liste führt zur Anzeige
der Details dieses Objekts in der Maske im unteren Teil des ObjectViews. In
dieser Maske können die Attributwerte direkt editiert werden, vorausgesetzt, der
Benutzer ist auch Director dieses Objekts, bzw der zugehörigen Klasse.
Abbildung 4.7 zeigt die beiden Objekt-Darstellungsformen: grafisch im
Diagramm und listen-artig im ObjectView.
DA2: Kapselung
In COINED: Die Objekte und ihre jeweiligen Attributwerte sind im Diagram-und
ObjectView für alle Benutzer sichtbar. Mit diesen Informationen werden die
Diagramme aussagekräftiger und können dann Programmflüsse besser
visualisieren. Bei der Manipulation von Objekten bleibt COINED dem Prinzip der
Kapselung allerdings treu, nur der Director, also der Benutzer, der ein Objekt
dirigiert, darf Attribute und -werte dieses Objekts editieren. Alle anderen Benutzer
müssen Nachrichten an das Objekt schicken, wenn sie seine Attributwerte
verändern wollen. Hier ist ein Filter denkbar, dieser ist jedoch zukünftigen
Versionen von COINED vorbehalten.
DA3:Interaktiv Nachrichten senden
In COINED: Methoden können im ClassView eingesehen, angelegt und bearbeitet
werden, also explizit auf Klassen- nicht auf Objektebene. Die Methoden einer
Klasse bestimmen die möglichen Nachrichten, die an ein Objekt dieser Klasse
geschickt werden können. Wenn ein Benutzer eine Nachricht an ein Objekt
4 Lösungsansatz
56
schicken möchte, zieht er dieses Objekt aus dem ObjectView in das entsprechende
Feld im MessageProcessingView. Das Dropdown-Menü Message bietet dann alle
Nachrichten, die sich an diese Objekt schicken lassen, zur Auswahl. Für jede
Methode, die Klasse des Objekts besitzt, wird die entsprechende Nachricht
angezeigt. Nach der Auswahl einer Nachricht werden die Parameterfelder
entsprechend der Methodensignatur aktualisiert. Der Benutzer kann den einzelnen
Parametern dann konkrete Werte zuweisen, entweder per Drag&Drop oder, im
Fall von einfachen Datentypen, durch direkte Eingabe. Gesendete Nachrichten
werden im DiagramView visualisiert. Auf der Verbindungslinie zwischen zwei
Objekten werden in einer Box alle Nachrichten gelistet die zwischen den
Objekten verschickt wurden. Jede Nachricht hat ein Pfeil-Icon, das die Richtung
des Nachrichtenflusses symbolisiert. Innerhalb einer Box werden die Nachrichten
in absteigender Reihenfolge angezeigt, die aktuellste Nachricht steht dann jeweils
oben.
Methoden tauchen also nur im Kontext von Klassen (nämlich im ClassView) und
Nachrichten im Kontext von Objekten (im MessageProcessingView arbeitet der
Benutzer auf Objektebene, im DiagramView ebenso) auf. Eine Tatsache, welche
die Differenzierung von Methode und Nachricht aus Benutzersicht unterstreichen
sollte.
DA4: Interaktiv Objekte erzeugen
In COINED: Klassen und Objekte werden jeweils in verschiedenen Views
(ClassView und ObjectView) verwaltet. Beide Views sind als Master-DetailsBlöcke konzipiert, d.h. es gibt auf der einen Seite eine Listendarstellung aller
Elemente und auf der anderen Seite eine Detailmaske (vgl. Abbildung 4.6,
Abbildung 4.7). Die Selektion eines Listenelements zeigt dann die Details dieses
Elements in dieser Detailmaske an. Im ClassView lassen sich in der Detailmaske
Attribute (Name und Typ) und Methoden einer selektierten Klasse einsehen,
erzeugen und/oder editieren. In den Details des ObjectViews werden die Attribute
(Name und Typ) und die konkreten Attributwerte von Objekten angezeigt, die
Editierbarkeit beschränkt sich an dieser Stelle aber auf die Attributwerte. Neue
Objekte werden im ClassView durch direkte Instanziierung von Klassen erzeugt.
Um ein Objekt einer bestimmten Klasse zu erzeugen, selektiert man die Klasse
und wählt im Kontextmenü den Eintrag „Create New Object“. Das Erzeugen von
Objekten ist nur dem Director der Klasse des Objekts gestattet.
Die strikte Trennung von Klassen- und Objektraum, und die Beschränkungen der
Editiermöglichkeiten im jeweiligen Kontext (Attributname/-typ und Methoden im
ClassView, Attributwerte im ObjectView) sollen den Anwender dabei
unterstützen, sauber zwischen Objekten und Klassen zu differenzieren zu können.
DA5: Beziehungen
In COINED: Ein Objekt kann Nachrichten nicht an beliebige Objekte
verschicken, sondern nur so an solche, zu denen es in einer Beziehung steht. Das
sendende Objekt muss das empfangende Objekt kennen. Diese Kenntnis kann sich
z.B. aus einem Attributwert, einem Parameter oder einer lokalen Variable des
aktuellen Messagestacks des Objekts herleiten. In COINED initiiert der Benutzer
das Senden einer Nachricht, indem er ein Objekt per Drag&Drop in den
MessageProcessingView zieht. Der Drag&Drop-Mechanismus wurde dabei so
umgesetzt, dass ausschließlich Attribute, Parameter und lokale Variablen des
aktuellen Objekts als DragSource zugelassen werden. Somit besteht also für den
4 Lösungsansatz
57
Benutzer überhaupt keine Möglichkeit, Nachrichten an unbekannte Objekte zu
senden.
DA6: Kommunikationsmedium für den Wissenstransfer
In COINED werden Nachrichtenfluss und Objektinteraktion in Diagrammen
visualisiert. Diese Diagramme können später als Kommunikationsgrundlage
dienen und zu Dokumentationszwecken eingesetzt werden
b) Protokolle der Interaktion als Kommunikationsunterstützung
Der vollständige Nachrichtenfluss und alle Benutzerinteraktionen werden
persistent in der Datenbank gespeichert und im HistoryView zur Anzeige
gebracht. Diese Informationen dokumentieren den vollständigen Ablauf der
Simulationen und bieten den Anwender eine gemeinsame Kommunikationsbasis
aufgrund der weiterführende Design-Entscheidungen getroffen werden können.
DA7: Unterstützung verteilter und lokaler Lehre
COINED wurde mit dem Schwerpunkt auf der Unterstützung von verteilter
Gruppenarbeit konzipiert. Mehrere (lokale oder verteilte) Benutzer arbeiten
gruppenweise in gemeinsamen Sessions an Projekten. Dabei muss die Arbeit
natürlich nicht zwingend als Multi-User-Session erfolgen, Single-User Betrieb ist
ebenso möglich.
COINEDs Client-/Server-Kommunikation basiert letztlich auf TCP/IP, damit
kann es sowohl im LAN (lokale Lehre, eine Gruppe arbeitet mit vernetzten
Rechnern in einem Seminarraum) als auch übers Internet (verteilte Lehre,
Lernende sitzen an verschiedenen Orten an Rechnern mit Internetanschluss)
eingesetzt werden.
DA8: Flexible Reaktion auf neue Erkenntnisse
Da Änderungen am Modell innerhalb von COINED schnell und einfach
umgesetzt werden können, ist es möglich mit relativ wenig Aufwand die neuen
Erkenntnis in alternative Modelle einfließen zu lassen und diese im SzenarioRollenspiel zu testen.
DA9: Rollenspiel
COINED unterstützt interaktives Szenario-Rollenspiel. Benutzer übernehmen die
Rolle von Objekten und senden, empfangen und bearbeiten Nachrichten. Der
Nachrichtenfluss und Objektzuständen werden in einem RPD visualisiert. Beim
Senden einer Nachricht gibt ein Objekt die Kontrolle an den Empfänger der
Nachricht ab. Erst mit dem Erhalt der Antwort bekommt der Sender die Kontrolle
zurück. Objekte, die auf Antworten warten, also Teil des aktuellen Execution
Stacks sind, signalisieren diesen Zustand über das farbige Director-Icon. Bei allen
anderen Objekten ist das Icon leicht transparent.
4.2 OO-Entwicklung: Szenario und Lösungsdarstellung
Neben dem Einsatz in der Lehre bietet sich im Bereich der Softwareentwicklung
eine weitere Einsatzmöglichkeit von COINED. Das folgende Szenario soll
exemplarisch verdeutlichen, wie COINED als unterstützendes Werkzeug in der
Entwurfsphase eines Softwareprojekts eingesetzt werden kann.
4 Lösungsansatz
58
Eine
Autovermietung
gibt
bei
einer
auswärts
ansässigen
Softwareentwicklungsfirma die Entwicklung eines neuen Verwaltungssystems in
Auftrag. Das System soll die für Autovermietungen üblichen Funktionalitäten
erfüllen, dazu gehört u.a. die Verwaltung des Fahrzeug- und Kundenbestands, das
Reservieren oder Ein- und Auschecken von Fahrzeugen, etc. Die Entwicklung soll
in einem heterogenen Team aus Mitarbeitern der Softwarefirma und Mitarbeitern
der Autovermietung erfolgen. Letztere sollen in den gesamten
Entwicklungsprozess (insb. auch in der Entwurfsphase) aktiv einbezogen werden.
Im Vorfeld, in einer ersten Analysephase hat das Team bereits Use Cases
identifiziert und, z.B. unter zu Hilfenahme von CRC-Karten, ein elementares,
informales Modell entwickelt, das jetzt in einer Designphase konkretisiert und
verfeinert werden soll.
Abbildung 4.11 –Autovermietung: Use Cases und CRC-Karten
Es gibt noch Unklarheiten bzgl. des genauen Modells, die beteiligten Klassen und
Objekte sowie ihr Verhalten und ihre Interaktion müssen noch genauer
identifiziert werden. Die Entwurfsphase beinhaltet unter anderem auch, dass
bestimmte Implementierungsfragen geklärt werden. Es müssen Entscheidungen zu
den tatsächlichen Klassen getroffen werden, ihre Eigenschaften müssen auf
konkrete Attribute und Methoden abgebildet werden, für das Zustandekommen
von Beziehungen müssen geeignete Umsetzungsformen (durch Konstruktion,
Senden von Argumenten, Empfang von Antworten), gefunden werden. Das
Modell wird in der Designphase immer wieder geändert, verschiedene
Designalternativen werden durchgetestet. Am Ende sollen aus dem Modell JavaKlassenrümpfe generiert werden.
Nicht alle Teammitglieder können bei den nun anstehenden Sitzungen vor Ort
sein, um face-to-face miteinander zu kommunizieren und Entwurfsentscheidungen
wie sonst üblich auf Papier oder Whiteboards zu diskutieren. Deshalb sucht man
nach Möglichkeiten einen verteilten Entwurfsprozess zu unterstützen und den
Teilnehmern Remote-Zugriff bzw. -Einstieg in gemeinsame Entwurfssitzungen zu
bieten. Man entscheidet sich für den Einsatz von COINED. Der COINED-Server
wird in der Software-Firma aufgesetzt und so in die Netz-Infrastruktur integriert,
dass die Teammitglieder sich über das Internet von verschiedenen Orten mit den,
auf ihren Laptops und Desktop-PCs installierten, Clients einloggen können.
Im ersten Schritt versuchen die Anwender die Artefakte des Analysemodells auf
eine möglichst einfache Art innerhalb von COINED abzubilden, so dass ein erstes
Designmodell in Form eins Projekts mit Klassen und Objekten entsteht. In diesem
Projekt werden dann die verschiedene Use Cases „durchgespielt“.
4 Lösungsansatz
59
Zur Illustration des konkreten Einsatzes von COINED schauen wir uns den Use
Case „Kfz mieten“ genauer an.
Unser Team besteht aus John, Jack, Jill und Joe. Alle halten sich an verschiedenen
Orten auf. Joe hatte sich bereit erklärt ein initiales Projekt mit einer ersten
Umsetzung der CRC-Karten anzulegen. Dieses Projekt soll nun als Ausgangsbasis
für die weitere, gemeinsame Entwicklung dienen. Die Teammitglieder loggen sich
zu einem verabredeten Zeitpunkt aus der COINED-Perspektive ihrer EclipseUmgebungen am Server ein und öffnen das Projekt „Autovermietung“. Folgende
Klassen hat Joe bereits angelegt:
•
•
•
•
Kfz - Die Fahrzeuge, die vermietet werden können (ID, Typ, istVerfügbar,
miete())
Vermietung– Verwaltet den Fahrzeug- und Kundenbestand (kfzListe,
sucheKfz(), kundenListe, sucheKunde())
Mitarbeiter - Nimmt Kundenaufträge entgegen, wie Fahrzeuganfragen,
Vermietungen und Rückgaben (ID, Name, mieten(), zurückgeben(),
kollaboriert mit Vermietung).
Kunde(ID, Name, gemietete Fahrzeuge, ausstehende Gebühren
Den etwas konkreteren Ablauf eines „Kfz mieten“-Szenarios hat das Team schon
während der Analyse vorher besprochen, Joe hatte eine textuelle Beschreibung
per Email verteilt.
Max Muster mietet bei einem Mitarbeiter das Kfz mit der ID “PB-PK 123“. Max
Mustermann ist registrierter Kunde mit der ID 321. Das Kfz ist verfügbar. Nach
dem Mieten hat das Kfz den Status „nicht verfügbar“ und es ist beim Kunden Max
Muster als gemietetes Kfz eingetragen.
Nachdem das Team komplett angemeldet ist und das Projekt geöffnet hat
(erkennbar an den Status-Icons in der BuddyListe), vergewissert sich Joe über den
integrierten Chat als erstes, dass auch alle die entsprechende SzenarioBeschreibung erhalten und vor sich liegen haben. Bei der Gelegenheit wird gleich
die Rollenverteilung geklärt, Jack übernimmt die Rolle der Vermietung, Joe spielt
die Kunden, Jill ist für die Kfz und John für die Mitarbeiter zuständig. Alle führen
die jeweilige Zuordnung gleich in COINED durch (über das Kontextmenü im
ClassView, vgl. Abbildung 4.6)
Abbildung 4.12 – ChatView: Joe, Jack, Jill und John besprechen die Rollenverteilung
Ähnlich wie Testdaten für TestCases in einer JUnit-Testumgebung innerhalb der
setUp()-Methode initialisiert werden, müssen auch für die Szenarien in COINED
initiale Daten vorbereitet werden. Das Erzeugen von Testdaten kann z.B. das
Anlegen bestimmter Objekte und das Vorbelegen von Attributwerten umfassen. In
unserem Beispiel muss das Team also zunächst entsprechend initiale Objekte
4 Lösungsansatz
60
anlegen, bevor die Simulation starten kann. Jeder erzeugt die erforderlichen
Objekte der Klasse für die er als Director zuständig ist und weist gegebenenfalls
initiale Attributwerte zu (John: derMitarbeiter, Jack: dieVermietung, Jill:
kfz1 und Joe: kunde1). Neue Objekte werden über das Kontextmenü einer
Klasse im ClassView erzeugt.
Abbildung 4.13 – Autovermietung: Initialisierte Objekte
Das
Szenario
soll
mit
dem
initialen
Senden
der
Nachricht
mieten(kundenID=“321“, kfzID=“PB-PK 123“) starten. Stellvertretend für die
Systemkomponente (z.B. Systemeingaben über das GUI), von der die
Bearbeitungsabläufe später tatsächlich ausgelöst werden sollen, gibt es in
COINED das theActor-Objekt. Jedes Objekt hat in seinem Kontextmenü den
Eintrag „Send Initial Message To“ über den sich eine initiale Nachricht von
theActor an dieses Objekt schicken lässt. Diesen Weg nutzt Joe nun um das
Rollenspiel und den Mietvorgang anzustoßen (vgl. Abbildung 4.14)
Abbildung 4.14 – Autovermietung: Initiierung, Bearbeitung und Darstellung der ersten
Nachricht
John (derMitarbeiter) muss für die Bearbeitung der Anfrage das
entsprechende Kunden- und Kfz-Objekt ermitteln. Er stellt fest, dass er selbst
nicht über die entsprechenden Informationen verfügt, und auch keine Assoziation
zu einem Objekt besitzt, von dem er diese Information bekommen könnte. Ein
Blick auf das Diagramm offenbart schnell, dass das Objekt dieVermietung als
Verwalter der Kfz und Kundenlisten der richtige Ansprechpartner wäre. Im Chat
bespricht John kurz mit dem Team, dass er seinem Objekt gerne eine initiale
Referenz auf dieVermietung in Form eines Attributwertes anlegen würde. Da
für die Klasse Mitarbeiter sowieso die Responsibilities sucheKfz und
sucheKunde vorgesehen sind und spätestens bei deren Umsetzung die
Vermietung als Collaborator erforderlich sein wird, stimmen alle sofort zu. John
4 Lösungsansatz
61
erzeugt also für seine Mitarbeiter-Klasse im ClassView das neue Attribut
vermietung vom Typ Vermietung. Er wechselt wieder zurück in den ObjectView und weist dem Attribut den konkreten Wert dieVermietung zu. Im
Diagramm erscheint eine blaue gerichtete Verbindungslinie, die symbolisiert, dass
das Objekt derMitarbeiter das Objekt dieVermietung nun kennt und mit
ihm interagieren kann. John kann nun also die Suchanfragen stellen, er schickt die
Nachricht sucheKfz(„PB-PK123“) an dieVermietung. Damit geht die
Kontrolle an Jack, dieser beantwortet die Nachricht indem er das entsprechende
Objekt kfz1 per Drag&Drop aus seinen privaten Attributen auf das Anwortfeld
zieht und durch Klicken des Finish-Buttons die Kontrolle zurückgibt.
John speichert das erhaltene Fahrzeug kfz1 in einer lokalen Variablen um ihm im
nächsten Schritt eine Verfügbarkeitsanfrage senden zu können. Er initiiert die
Nachricht diesmal nicht per Drag&Drop sondern über das Kontextmenü der
Variable („Send Message To“). Beide Wege sind gleichwertig und führen zum
Formular („Create a New Outgoing Request“), in dem das adressierte Objekt, hier
jetzt also kfz1, vorgepromptet ist. Bei der Sichtung des Dropdown-Menüs mit
den für die Klasse Kfz definierten Nachrichten stellt John fest, das es die
Nachricht istVerfügbar() noch nicht gibt. Also gibt er den Namen der
Nachricht manuell ein. Er könnte noch Parameter angeben, aber er benötigt keine
und schickt die neue Nachricht ab. Jill erhält die Kontrolle und muss nun auf die
neue Nachricht reagieren. Sie könnte die Nachricht mit Do-Not-Understand
beantworten und so verwerfen. Aber sie sieht sofort, dass es noch keine andere
Methode zur Abfrage des privaten verfügbar-Attributs von Kfz gibt. Also
akzeptiert sie die Nachricht, indem sie sie erwartungsgemäß beantwortet. Sie zieht
den Wert von verfügbar in das Antwortfeld und beendet die Bearbeitung. Im
Hintergrund wird damit automatisch eine neue der Nachricht entsprechende
Methode in die Klasse Kfz eingefügt.
Der weitere Ablauf des Szenarios geht ohne weitere Besonderheiten über die
Bühne. John schickt die Nachricht mieten() an kfz1, woraufhin Jill den
Verfügbarkeits-Status von kfz1 auf false setzt. John lässt sich das KundenObjekt kunde1 mittels der Nachricht sucheKunde(„321“) von
dieVermietung zurückgeben. Mit Senden der Nachricht mieteKfz (kfz1)
aktiviert er das Objekt kunde1 von Joe. Joe trägt das übergebene Argument kfz1
in die Liste der gemieteten Fahrzeuge ein und gibt die Kontrolle zurück. Damit
kann John nun die Bearbeitung der initialen mieten() Nachricht vom ActorObjekt abschließen.
4 Lösungsansatz
62
Abbildung 4.15 Nachrichtenhistorie und Diagramm am Ende des Szenarios
Nach dem Abschluss des Rollenspiels kann sich das Team die genaue
Chronologie des Nachrichtenflusses und alle getätigten Zuweisungen im
MessageHistoryView noch einmal vor Augen führen. Dort ist auch die
hierarchische Struktur des Nachrichtenstacks gut erkennbar.
Jack merkt an, dass die Objektinteraktion ingesamt sehr „Mitarbeiter-lastig“ ist ein Sachverhalt, den man am Diagramm schnell nachvollziehen kann. Man
diskutiert kurz alternative Möglichkeiten, z.B. könnte der Mitarbeiter seine
Kommunikation mit dem Kfz-Objekt an das Kunden-Objekt delegieren, bleibt
dann aber bei der ursprünglichen Version.
Abbildung 4.16 – Codegenerierung: Assistent und Java-Perspektive mit generierten KlassenStubs
Das Team spielt nun noch verschiedene andere Szenarien wie„Kfz zurückgeben“
durch, testet so das Modell und bessert es gegebenenfalls nach. Von der finalen
Version ist Joe so begeistert, dass er gerne direkt dem Implementieren loslegen
möchte. Dafür lässt er sich von COINED Java-Klassenrümpfe mit Methoden und
4 Lösungsansatz
63
Attributen aus dem Modell generieren (s. Abbildung 4.16). Sein Eclipse wechselt
dabei automatisch in die Java-Perspektive in der Joe gleich auf die generierten
Klassen zugreifen und diese ausprogrammieren kann.
Das vorgestellte Nutzungsszenario illustriert bereits wie COINED einige der
Anforderungen aus 2.2.4 erfüllt und unterstützt. Während der Simulation
offenbaren sich die Unzulänglichkeiten des Modells auf relativ natürliche Art und
Weise, notwendige Artefakte werden identifiziert. So werden beispielsweise
intuitiv die fehlende Beziehung zwischen Mitarbeiter und Vermietung (EA4), und
die benötigte Nachricht istVerfügbar() (EA3) aufgedeckt.
Im Folgenden betrachten wir noch einmal genauer, wie COINED die einzelnen
Anforderungen umsetzt.
EA1: Identifikation der Objekte
EA2: Identifikation der Nachrichten
EA3: Reaktion auf Nachrichten
EA4: Identifikation der Objektbeziehungen
Bei der Simulation der Szenario-Rollenspiele arbeiten die Benutzer direkt auf
Objektebene und bewegen sich eben gerade explorierend durch den Objekt-Raum.
Die zur Umsetzung einer bestimmten Systemfunktionalität benötigten Objekte
werden schnell identifiziert (EA1). Auch die benötigten Nachrichten(EA2), die
Reaktionen der Empfänger (EA3) und die erforderlichen Beziehungen zu anderen
Objekten um Nachrichten senden können (EA4), können während der Simulation
aufgedeckt werden. Im AU
Ein besonderes, EA2 unterstützendes, Merkmal von COINED ist die Möglichkeit
der Ad-Hoc-Methodengenerierung. Damit ist es möglich, unbekannte Nachrichten
an Objekte zu verschicken. Der Sender generiert eine benutzerdefinierte Nachricht
mit neuem Namen und Parametern. Der Empfänger hat die Möglichkeit mit DoNot-Understand zu antworten, dann geht die Kontrolle zum Sender zurück und
die neue Nachricht/Methode wird verworfen. Der Empfänger kann die Nachricht
aber auch akzeptieren, indem er sie auf die im MsgProcessingView übliche Weise
bearbeitet und beantwortet. In der Klasse des Empfängers wird dann automatisch
eine der Nachricht entsprechenden Methode angelegt.
EA5: Testmöglichkeiten
Mit COINED lassen sich verschieden Systemfunktionalitäten rollenspielartig
simulieren. Diese Simulationen können auch als Tests betrachtet werden. Sie
dienen dazu Inkonsistenzen und Fehler im Modell aufzudecken.
EA6: Kommunikationsmedium für den Wissenstransfer
b) Protokolle der Interaktion als Kommunikationsunterstützung
4 Lösungsansatz
64
EA7: Unterstützung lokaler und verteilter Teams
Analog zu DA7 - COINED wurde mit dem Schwerpunkt auf der Unterstützung
von verteilter Gruppenarbeit konzipiert. Mehrere (lokale oder verteilte) Benutzer
arbeiten gruppenweise in gemeinsamen Sessions an Projekten. Dabei muss die
Arbeit natürlich nicht zwingend als Multi-User-Session erfolgen, Single-User
Betrieb ist ebenso möglich. COINEDs Client-/Server-Kommunikation basiert
letztlich auf TCP/IP, damit kann es sowohl im LAN (lokale Lehre, eine Gruppe
arbeitet mit vernetzten Rechnern in einem Seminarraum) als auch übers Internet
(verteilte Lehre, Lernende sitzen an verschiedenen Orten an Rechnern mit
Internetanschluss) eingesetzt werden.
EA8: Potenzieller Mehrwert
Ein konkreter Mehrwert, den die Nutzung von COINED bietet, liegt in der
Möglichkeit der Code-Generierung. Aus dem entworfenen Modell können
Klassenrümpfe erzeugt werden, die dann als Grundlage für die spätere
Implementierung dienen.
Ein indirekterer Mehrwert kann sich bzgl. der Qualität des Designs ergeben.
Wenn die Möglichkeit, verschiedene Design-Alternativen zu testen, intensiv
genutzt wird, führt das dazu, dass der resultierende Entwurf später weniger
anfällig auf Änderungen reagiert. Auch die Wahrscheinlichkeit während der
späteren
Implementierung
in
Probleme,
die
auf
schlechten
Entwurfsentscheidungen basieren, zu geraten, verringert sich.
EA9: Flexible Reaktion auf neue Erkenntnisse
Da Änderungen am Modell innerhalb von COINED schnell und einfach
umgesetzt werden können, ist es möglich mit relativ wenig Aufwand verschiedene
Design-Alternativen zu testen. So können neue Erkenntnisse gewonnen und das
Design flexibel angepasst werden.
EA10: Nachvollziehbarkeit
In COINED: Der HistoryView listet alle gesendeten Nachrichten und alle
Zuweisungen chronologisch in einer Baumdarstellung auf. Die einzelnen Eben
des Baum lassen sich je nach gewünschtem Detailgrad auf oder zu klappen. Über
Filter kann die Anzeige auf Zuweisungen oder Nachrichten beschränkt werden.
Die Nachrichten sind aufsteigend durchnummeriert. Zu jeder Nachricht lassen
sich über ein Kontextmenü Details wie Quell- und Zielobjekt, Parameter, und
Zeitstempel anzeigen. Über den HistoryView ist der Nachrichtenfluss also
vollständig nachvollziehbar.
Die durchgehende Nummerierung der Nachrichten findet sich auch in ihrer
Repräsentation im Diagramm. Diese Ansicht ist allerdings eher für eine
ausschnittartige Betrachtung des Programmflusses geeignet, aus Gründen der
Übersichtlichkeit wird nur eine benutzerdefinierte Anzahl von
aktuellen
Nachrichten zwischen zwei Objekten angezeigt.
4.3 Konzeptionelle Lösung der technischen Anforderungen
In diesem Abschnitt betrachten wir die technische Umsetzung der Lösung. In
4.3.1 stellen wir kurz die Architektur von COINED vor und erläutern im
Einzelnen den Bezug zu den in 2.3.2 hergeleiteten technischen Anforderungen. In
4.3.2 gehen wir auf die, in der Lösung verwendeten, Entwurfsmuster aus dem
Bereich der, in [SL07] vorgestellten, Computer Mediated Interaction Pattern ein.
4 Lösungsansatz
65
4.3.1 Technischer Überblick und Architektur
Wie anfangs bereits erwähnt, wurde COINED als verteiltes Mehrbenutzer-System
in Form einer Client-/ Server-Architektur realisiert, wobei der Server die zentrale
Instanz ist, welche die Zusammenarbeit der Clients untereinander koordiniert.
Der COINED-Server ist eine, der Java-Servlet-Spezifikation entsprechende,
Webapplikation, die in einem beliebigen Standard-ServletContainer eingesetzt
werden kann. Die Client-/Server-Kommunikation erfolgt zum einen über eine
WebService-Schnittstelle (Update- und Datenrequests) und zum anderen über eine
JMS-Schnittstelle (Update-Notifications). Der WebService basiert auf der SOAPImplementation Axis und als JMS-konformer Messaging-Dienst wird ActiveMQ
eingesetzt. Zur persistenten Datenhaltung wird eine MySQL-Datenbank
verwendet.
Der
COINED-Client
wurde
als
Plugin
für
das
Open-Source
Entwicklungsframework Eclipse in der Version 3.2 umgesetzt. Eclipse und
Eclipse-Plugins (und damit auch COINED) sind in Java implementiert und somit
weitestgehend plattformunabhängig. Für die grafische Diagrammdarstellung wird
das Zeichnungs- und Layout-Plugin Draw2D (ein Teil des GEF-Frameworks)
verwendet.
In Abbildung 4.17 findet sich eine vereinfachte schematische Darstellung der
Architektur.
Abbildung 4.17 – Schematische Darstellung von COINEDs Architektur
Die Identifizierung der Clients und die Authorisierung der Zugriffe auf den
WebService werden über ein Sessionmanagement geregelt. Den entsprechenden
Ablauf beim Start eines Clients kann man sich folgendermaßen vorstellen.
Zunächst muss sich der Benutzer am System authentifzieren indem er sich mit
seinen Account-Daten (Nickname, Passwort) über einen Login-Dialog am Server
anmeldet. Kann der Server die Anmeldedaten validieren, generiert er für den
4 Lösungsansatz
66
Client eine neue Session und gibt die SessionID zurück. Der Client muss danach
alle weiterführenden Server-Requests mit dieser SessionID versehen, damit der
Server eindeutige Zuordnungen von Requests und Clients machen und die
Gültigkeit prüfen kann.
Die eigentliche kollaborative Umgebung betritt der Benutzer erst mit dem
Öffnen/Erzeugen eines COINED-Projekts. Beim erstmaligen Betreten eines
Projekts, wird ein Request an den Server abgesetzt, der dafür sorgt, dass der
Benutzer automatisch als Projektmitglied eingetragen wird. Der Server sendet
Update-Notifications über das neue Mitglied an alle Clients, die zurzeit im
gleichen Projekt registriert sind, diese Clients fordern daraufhin die Daten des
neuen Mitglieds vom Server an und aktualisieren die graphische Darstellung in
den Benutzerlisten im BuddyListView.
Bei dieser Beschreibung erkennt man bereits wie COINED mit Update-Requests
und Update-Notifications arbeitet. Ein Mechanismus, der immer verwendet wird,
wenn ein Client eine Datenänderung vornimmt. Zur genaueren Illustration der
Kommunikationsstrukturen skizzieren wir nun das generelle Muster, nach dem
das System auf Benutzerinteraktionen mit Artefakten reagiert und entsprechende
Datenmanipulationen umsetzt.
Abbildung 4.18 – Ablauf bei einer Datenänderung
1. Über das GUI eines Clients wird ein Artefakt manipuliert. Das kann z.B. das
Verändern einen Attributwerts oder das Senden einer neuen Nachricht sein.
2. Ein entsprechender Update-Request mit den zu ändernden Daten wird an den
Server durchgereicht
a. View stellt Anfrage beim Model
b. Model delegiert an Cache
c. Cache stellt Request an WebService
3. Auf Server-Seite gibt der für den Request zuständige Businesshandler die im
Request übermittelte SessionID zur Prüfung an den SessionManager weiter.
4 Lösungsansatz
67
Der SessionManager validiert die Session und liefert die mit der Session
assoziierten Client-Informationen, wie User- und ProjektID, zurück.
4. Bei positiver Validierung delegiert der Businesshandler die zu ändernden
Daten an den entsprechenden DB-Mapper.
5. Die DB-Mapper überträgt die gewünschte Änderung persistent in den
Datenbestand der Datenbank.
6. War der DB-Eintrag erfolgreich, informiert der Businesshandler den
serverseitigen ChannelManager.
7. Der ChannelManager informiert alle Clients, die am gleichen Projekt
interessiert sind (auch den Client, von dem die Änderung ausging), über die
erfolgte Änderung, indem er eine Update-Notification im entsprechenden
Topic veröffentlicht. Auf Clientseite lauscht ein ChannelManager auf
Nachrichten in den Topics des aktuellen Projekts und nimmt diese UpdateNotification in Empfang.
8. Verteilung der Update-Nachicht innerhalb der Clients
a. ChannelManager informiert MessageController
b. MessageController informiert alle an der Nachricht interessierten
Listener
9. Der Cache entfernt ggf. eine alte ungültige Version des Artefakts
10. Anforderung der neuen, geänderten Daten vom Server
a. Views fragen beim Model an.
b. Model delegiert an Cache
c. Cache holt die Daten über den WebService vom Server
11. Der Server holt die Daten aus der DB
a. Der Businesshandler delegiert die Anfrage an die entsprechende DBFinder-Klasse
b. Der Finder liest die Daten aus der DB
12. Nachdem die ausgelesenen Daten an den Client zurückgegeben und an Model
und Views verteilt worden sind, wird die Darstellung der Daten im GUI
aktualisiert
Abbildung 4.18 stellt das Zusammenspiel von grafisch dar.
Es folgt eine detailliertere Zuordnung von COINEDs Merkmalen und den
technischen Anforderungen aus 2.3.2
TR1: Gemeinsame Sicht auf ein Diagramm
In COINED: Alle Benutzer, die gemeinsam ein Projekt bearbeiten, haben die
gleiche Sicht auf das zugehörige Diagramm. Änderungen am Diagramm werden
vom Server an die Clients mittels entsprechender Update-Notifcations propagiert.
Änderungen können dabei sowohl räumlicher Natur (Objekte sind per
Drag&Drop verschieb-/positionierbar) als auch inhaltlicher Natur sein (geänderte
Objektzustände, geänderter Aktivitätsstaus, neue Nachrichten, etc.) Die Clients
werten die Notifications aus, holen sich die neuen Daten vom Server und updaten
ihre Diagrammdarstellung entsprechend.
TA2: Kommunikationsmedium für den Wissenstransfer
a: Graphische Visualisierung als Kommunikationsunterstützung
4 Lösungsansatz
68
b: Protokolle der Interaktion als Kommunikationsunterstützung
TA3: Synchrone Kommunikation
COINED besitzt einen integrierten Chat. Chatnachrichten werden persistent und
mit Bezug zum jeweils aktiven Objekt abgespeichert. Die Chatnachrichten werden
in einer eigenen Ansicht jeweils mit Nickname, User-Icon und Zeitstempel
angezeigt.
TA4: Awareness
In COINED: (a) In der Buddyliste wird rechts neben dem Benutzerbild jedes
Benutzers sein Onlinestatus mit einem roten, grünen oder gelben Icon dargestellt.
Rot bedeutet: Benutzer ist nicht eingeloggt – Gelb: Benutzer ist eingeloggt,
befindet sich aber zurzeit in einem anderen Projekt – Grün: Benutzer ist
eingeloggt und hat das gleiche Projekt geöffnet.
(b) Während einer Simulation kann man im Diagramm erkennen welches Objekt
aktiv ist (Hintergrundfarbe wechselt von Gelb zu Orange, Stern erscheint vor dem
Objektnamen). Da in der Repäsentation eines Objekts immer auch das Icon seines
Directors angezeigt wird, kann jeder Benutzer jederzeit sehen, wer die aktuelle
Kontrolle hat.
TA5: Modellierung von Rollen
In COINED: Ein Benutzer kann sich über das Kontextmenü im ClassView zum
Director einer Klasse erklären. Damit übernimmt er die Kontrolle über die Klasse
sowie alle zugehörigen Objekte, und er kann neue Objekte der Klasse erzeugen.
Der Director ist für das Verhalten der Objekte einer Klasse verantwortlich. Wenn
eins seiner Objekte eine Nachricht erhält, übernimmt er die Rolle des Objekts und
bearbeitet und beantwortet die Nachricht. Die Director-Rollen werden durch die
Anzeige der entsprechenden Benutzer-Icons visualisiert, sowohl in den
Klassenrepräsentationen im ClassView, als auch in den Objektrepräsentationen im
ObjectView und im DiagramView.
TA6: Synchronisation des Diagramms
Wie in TR1 beschrieben, werden Änderungen am Diagramm per UpdateNotifications vom Server an die Clients propagiert. Wenn nun ein Benutzer an
einem Client in einem Simulationschritt eine neue Nachricht abschickt, teilt der
Client dem Server dieses Vorhaben über einen entsprechenden Request mit, die
Nachricht wird als Parameter übergeben. Der Server speichert die Nachricht
persistent in der DB ab und schickt anschließend Update-Notifications an alle
betroffenen Clients. Die Clients werten die empfangene Notifcation aus und
stellen einen Request an den Server um die Daten der neuen Nachricht abzurufen.
Erst dann wird das GUI aktualisiert. JMS sorgt dafür das Notifications in der
richtigen Reihenfolge ausgewertet werden
TA6: Code-Generierung
Im ClassView lässt sich auf Knopfdruck aus den, in der COINED-eigenen
informalen Notation definierten, Klassen Java-Quellcode generieren. Es wird,
4 Lösungsansatz
69
sofern noch nicht existent, ein Eclipse-Projekt mit Java-Klassenrümpfe, Attribute
und Methoden eingeschlossen, erzeugt. Die Integration von COINED in Eclipse
ermöglicht es der Umgebung, mit der Generierung automatisch von der COINEDPerspektive in die Java-Perspektive zu wechseln. Der Anwender hat dort dann die
Möglichkeit Eclipse in seiner klassischen Funktion als Java-IDE zu nutzen und er
kann direkt mit der Auszuprogrammierung der Klassen beginnen.
Während der Simulation eines Progammablaufs werden sowohl die gesendeten
Nachrichten, als auch die, von den Benutzern im Zuge der Nachrichtenbearbeitung vorgenommen, Zuweisungen aufgezeichnet, im HistoryView
visualisiert und in der Datenbank persistent gespeichert. Diese Informationen
können z. B als Grundlage für die Generierung von JUnit-Testcase dienen.
TA7: Visualisierung des Interaktionsflusses
Im Diagramm wird der Interaktions-/bzw. Nachrichtenfluss graphisch visualisiert.
Die dynamische Hervorhebung (Hintergrundfarbe, Stern-Icon) des jeweils aktiven
Objekts und der letzten Nachricht fokussiert den Blick des Anwenders auf den
aktuellen Stand der Simulation. Nachrichten sind in absteigender Reihenfolge mit
ihren Nummern an den Verbindungslinien zwischen Objekten aufgelistet. Um die
Übersichtlichkeit des Diagramms im Falle vieler Nachrichten nicht
einzuschränken, kann die Anzahl der angezeigten Nachrichten pro Verbindung
über eine Benutzereinstellung individuell eingestellt werden. Anhand der
Nachrichtennummern kann der Fluss schnell nachvollzogen werden.
TA9: History
Wie bereits in TA6 erwähnt, werden während der Simulation eines
Progammablaufs sowohl die gesendeten Nachrichten als auch die, von den
Benutzern im Zuge der Nachrichtenbearbeitung vorgenommenen, Zuweisungen
aufgezeichnet und im HistoryView chronologisch aufgelistet. Der
Nachrichtenfluss kann hier also vollständig nachvollzogen werden.
In COINED müssen Benutzer sich über einen Login-Dialog mit ihren
Accountinformationen (Nickname und Passwort) am COINED-Server
authentifizieren, bevor sie den kooperativen Arbeitsbereich betreten dürfen. Vor
der ersten Benutzung muss jeder Benutzer einen eigenen Account anlegen. Nach
der erfolgreichen Authentifizierung kann der Benutzer ein Projekt öffnen, er
nimmt damit automatisch an der aktuellen kooperativen Session der
Projektmitglieder teil. Beim erstmaligen Betreten eines Projekts wird der Benutzer
automatisch als Projektmitglied eingetragen und er wird entsprechend in der
Buddyliste des Projekts aufgeführt. Benutzerinformationen, Projekte und die
entsprechenden Zuordnungen werden vom Server verwaltet und persistent in der
Datenbank gespeichert.
T11: Persistenz
COINED wurde als Client-/Server-Architektur umgesetzt. Alle Informationen
(Benutzer, Projekte, Artefakte, Zuordnungen) werden immer zentral und
persistent vom Server in einer SQL-Datenbank gespeichert. Dabei müssen
Datenbank und COINED-Server nicht notwendigerweise auf demselben System
laufen. Durch die zentrale, persistente Speicherung kann der asynchrone Zugriff
unterstützt werden. So können die Anwender auch beim asynchronen Zugriff auf
4 Lösungsansatz
70
gemeinsame Projekte immer den letzten aktuellen Stand abrufen. Die Benutzer
können zu jedem Zeitpunkt von jedem Ort (über das Internet) mit dem System
arbeiten, unabhängig vom Online-Status anderer Gruppenmitglieder und einzelner
Clients.
4.3.2 Verwendete Patterns und ihr Zusammenspiel
Groupwaresysteme unterstützen Gruppenprozesse, sie koordinieren die
Kommunikation und die Kollaboration innerhalb von Gruppen. In [SL07] werden
spezielle Entwurfsmuster (Patterns) für die Entwicklung von Groupwaresystem
definiert. Im Folgenden geben wir eine Übersicht darüber, welche dieser Pattern
in COINED verwendet wurden.
Login
In COINED müssen Benutzer sich über einen Login-Dialog mit ihren Accountinformationen (Nickname und Passwort) am COINED-Server authentifizieren,
bevor sie den gemeinsamen Arbeitsbereich betreten dürfen. So ist das System in
der Lage, innerhalb der kooperativen Sessions jede Aktion einem bestimmten
Benutzer zuzuordnen. Das ist eine der Grundvoraussetzungen, um Benutzer
identifizierbar werden zu lassen.
Der angemeldeten Benutzer wird zum einen durch den Fettdruck seines Namens
in der Repräsentation im BuddylistView und zum anderen durch die Anzeige in
der Titelzeile des Eclipse-Fensters („logged in as <username>“) kenntlich
gemacht.
Virtual Me
Jeder Anwender kann zur Beschreibung seiner virtuellen Identität ein Profil
bearbeiten. In dem Profil hat er die Möglichkeit persönliche Informationen wie
Email-Adresse, vollen Namen, sowie ein Bild zu hinterlegen. Dieses Bild wird
dann überall zur visuellen Repräsentation des Benutzers verwendet, sowohl in der
Buddyliste also auch in den Darstellungen seiner Klassen und Objekte. Wenn ein
Benutzer kein eigenes Bild hinterlegt, wird ein Default-Bild angezeigt.
Shared Editor
Anwender können gleichzeitig Objekt-Positionen manipulieren. per Mediated
Upates wird die Darstellung an allen Clients synchronisiert. Objekt-Positionen
werden persistent in der Datenbank gespeichert.
Semantische Objekt-Manipulationen finden nicht konkurrierend statt, da
ausschließlich der Director schreibenden Zugriff auf ein Objekt hat.
Floor Control
Der in COINED verwendete Kontrollflussmechanismus (nur der Director des
gerade aktiven Objekts darf editieren) kann als Variante dieses Patterns ausgeleget
werden.
Room
COINED-Projekte können als eine Ausprägung des Room-Patterns angesehen
werden. Ein Projekt enthält Artefakte und Benutzer. Artefakte und Zustände
werden persistent in der DB gespeichert, Projekte können sowohl synchron als
4 Lösungsansatz
71
auch asynchron bearbeitet werden. Zwischen den Benutzern eines Projekts
existiert ein synchroner Kommunikationskanal, der integrierte Chat.
Embedded Chat
Mit dem Chat im ChatView bietet COINED den Anwendern die Möglichkeit der
synchronen Kommunikation. Das Chatten erfolgt Projekt-bezogen, d.h. es werden
nur Nachrichten von Projektteilnehmern verschickt und angezeigt. Die
Nachrichten werden persistent in der Datenbank gespeichert.
User List
Wenn ein Benutzer ein COINED-Projekt öffnet, wird der BuddyListView mit den
visuellen Repräsentationen aller Projektteilnehmer aktualisiert. Jeder Teilnehmer
wird mit Namen und Benutzerbild aufgeführt. Ein Icon signalisiert jeweils den
aktuellen Online-/Projekt-Status eines Benutzers. (Offline, Online und nicht das
gleiche Projekt geöffnet, Online und gleiches Projekt geöffnet). Spezielle
ClientListener überwachen die Zustände der Clients und sorgen für die
dynamische Aktualisierung der Status-Icons, sowohl in Fällen in denen Benutzer
sich ordnungsgemäß am Server an-/abmelden und Projekte betreten, als auch bei
unerwarteten Fällen wie Verlust von Netzwerkverbindungen oder
Systemabstürzen.
Über die BuddyListe ist also für jedes Projektmitglied klar erkennbar, wer sich
aktuell mit im Projekt befindet und damit an der gemeinsamen Session teilnimmt.
Dieses Bewusstsein fördert den freieren Umgang der Benutzer mit den
gemeinsamen Artefakten.
Wir verwenden hier letztendlich eine Variante des User List Patterns, da die
Benutzerrepäsentation nicht komplett aus der Liste entfernt wird, wenn ein
Benutzer die Session, bzw. das Projekt verlässt, sondern stattdessen das StatusIcon entsprechend aktualisiert wird.
Interactive User Info
Über das Kontextmenü der Benutzerrepräsentationen im BuddyListView können
die Benutzerprofile eingesehen werden.
Activity Log
In COINED wird eine sehr eingeschränkte Version des Patterns verwendet.
Bestimmte modifizierende Benutzer-Aktivitäten (Zuweisungen, Nachrichten)
werden im HistoryView protokolliert.
Persistent Session
In COINED arbeiten die Benutzer in kooperativen Sessions an Projekten. Die
Ergebnisse (Artefakte, Zustandsänderungen, Abläufe) werden persistent auf dem
Server in der Datenbank gespeichert. Dadurch wird es möglich die kooperativen
Aktivitäten der letzten Session später zu reviewen oder fortzuführen. Es werden
nur die Daten der jeweils letzten Session eines Projekts verwaltet, der Zugriff auf
ältere Sessions wird nicht unterstützt.
State Transfer (aka “What’s up”)
Wenn ein Benutzer ein Projekt öffnet, wird der aktuelle Projektzustand vom
Server geladen und zur Anzeige gebracht. Dass der Server immer über die
4 Lösungsansatz
72
aktuellste Version der gemeinsamen Daten verfügt, wird dadurch sichergestellt,
dass Änderungen grundsätzlich erst wirksam werden, wenn sie erfolgreich in die
DB weggeschrieben konnten. So können Benutzer problemlos zu einer laufenden
kooperativen Sitzung dazustoßen, sie starten immer mit dem aktuellen Stand und
konsistenten Daten.
Centralized Objects
Alle Artefakte (Klassen, Objekte, Nachrichten,…) werden zentral in einer
Datenbank verwaltet. Der Server koordiniert die konkurrierenden Zugriffe und
stellt die Artefakte auf Anfrage über eine Webservice-Schnittstelle bereit.
Änderungen an gemeinsamen Artefakten kommuniziert der Server mithilfe von
Update-Notifications über eine JMS-Schnittstelle an die interessierten Clients
Remote Subscription
Zur Verteilung von Nachrichten, die Änderungen am gemeinsamen Datenbestand
betreffen, verwendet COINED Publish/Subscribe-Messaging, realisiert mit JMS
(Java Messaging Service). Wenn ein Benutzer ein Projekt betritt, registriert sich
der Client beim Server als Konsument für alle projekt-spezifischen Nachrichten.
Die Nachrichten sind in Topics (ClassInfo, ObjectInfo, MessageInfo, UserInfo,
usw) organisiert, die der Client jeweils abonniert. Wenn nun eine Änderung am
Datenbestand ausgeführt wird, veröffentlicht der Server eine UpdateBenachrichtung im entsprechenden Topic und das System sorgt dafür, dass alle
Clients, die dieses Topic abonniert haben, die Nachricht erhalten.
Replicated Objects (aka “Replicate for Speed”)
Jeder Client verfügt über einen lokalen Cache, der die Artefakte aus den
Ergebnissen der Serveranfragen zwischenspeichert. Klassen, die Daten benötigen,
stellen Anfragen an den Cache, der diese wiederum an den Server weiterleitet,
wenn er sie aktuell nicht bedienen kann. Der Cache erhält Update-Notifications
vor allen anderen Message-Listenern, so dass er betroffene Artefakte entfernen
kann und keine ungültigen Daten enthält. Wenn der nächste Zugriff auf ein nicht
(oder nicht mehr) vorhandenes Artefakt erfolgt, wird es neu vom Server geladen.
Auf die gecacheten Daten gibt es nur lesenden Zugriff. Modifikationen erfolgen
immer erst nach Serverkommunikation.
Mediated Updates
Der Server ist die zentrale Instanz an der Clients sich anmelden und für den
Empfang von Update-Nachrichten registrieren. Wenn ein Client lokale Daten
manipuliert, schickt er einen Update-Request an den Server. Nach erfolgreicher
Umsetzung des Requests verteilt der Server Update-Notifications an alle
betroffenen Clients, genauer gesagt, er veröffentlicht die Nachricht in dem
relevanten Topic und per JMS wird die Nachricht dann an alle Subscriber des
Topics verteilt.
Der Server übernimmt hier also die Rolle des Mediators, der dafür sorgt, dass
Update-Notfications zwischen Clients propagiert werden. Die Clients müssen sich
untereinander nicht kennen.
Distributed Command
In COINED werden die Server-Requests zum Ändern und Abrufen der
gemeinsamen Daten mithilfe eines WebServices realisiert. Ein Client ruft eine
entfernte Service-Methode auf und der Server führt diese dann aus.
4 Lösungsansatz
73
Commands werden allerdings nicht an Clients weitergeleitet, insofern handelt es
sich nur um eine eingeschränkte Variante des Patterns.
Zusammenspiel der Patterns
Die verwendeten Patterns machen deutlich, dass COINEDs Hauptaugenmerk auf
der zielgerichteten Unterstützung von synchroner verteilter Gruppenarbeit liegt.
Eine verteilte Gruppe von Benutzern arbeitet in Projekten gemeinsam an zentral
verwalteten Artefakten. Das Zusammenspiel der Patterns soll für die Umsetzung
wichtiger Groupware-Konzepte sorgen, gerade auch im Umgang mit verteilten
Gruppen. In verteilten Gruppen ist es z.B besonders wichtig, den
Gruppenmitgliedern die Anwesenheit der anderen bewusst zu machen.
Motivationsförderndes Gruppengefühl verliert sich leicht, wenn die Mitglieder
alleine an verschiedenen Orten vor ihren Rechnern sitzen. Deshalb verwendet
COINED bewusst einige Patterns, die auf die Förderung und den Erhalt des
Gruppenbewusstseins abzielen (Virtual Me, User List, Interactive User Info,
Sender Recognition,…).
Weitere Effekte, die im Zusammenspiel der Patterns angestrebt werden, sind die
Anregung und Unterstützung weiterer Gruppenprozesse, wie Diskussion,
Entscheidungsfindung und Kommunikation zwischen Gruppenmitgliedern.
5 Details zur Lösung
74
In 4.3.1 wurde bereits ein kurzer technischer Überblick über COINED und seine
Architektur gegeben. Der folgende Abschnitt geht nun bezüglich der verwendeten
Technologien und der Implementierung etwas mehr ins Detail.
5.1 Signifikante Implementierungsdetails
Der COINED-Server ist in Java implementiert. Er hat die Form einer
Webapplikation nach Servlet-Spezifikation und sollte daher in jedem Standardkonformen Servlet Container lauffähig sein. Im Zuge der Entwicklung wurde die
Applikation allerdings ausschließlich innerhalb eines Apache Tomcat eingesetzt.
Clients stellen Daten- und Änderungsanfragen an den Server. Der COINEDServer muss also u.a. als Datenprovider für die Clients dienen. Diese
Funktionalität wird über einen WebService realisiert, der die entsprechenden
Methoden zur Abfrage und Änderung von Daten zur Verfügung stellt.
WebServices sind plattform- und insbesondere implementations-unabhängig, die
Schnittstellen-Beschreibung der bereitgestellten Methoden erfolgt in XMLDateien in WSDL (Web Service Description Language), einer eigenen
Spezifikationssprache. Der in COINED umgesetzte WebService stützt sich auf
SOAP als Kommunikationsprotokoll. Als Basis für die Konstruktion dieses
WebServices dient die SOAP-Engine Apache Axis. Zu diesem Zweck ist Axis als
Servlet mit in die COINED-Webapplikation integriert. Die Entwicklung der
Webapplikation erfolgte innerhalb der Eclipse Web Tools Platform (WTP1.5).
Das umfasst sowohl die Generierung der Transport-Klassen für den Client-Proxy,
die den Client Zugriff auf den Server implementieren, als auch die WSDLBeschreibung des WebService. Wobei WTP in diesen Fällen letztlich nur als ein
Wrapper für die von Axis-mitgelieferten Tools wsdl2java und java2wsdl dient.
Mit der automatischen Erzeugung der Transport-Klassen erhält der Entwickler
eine robuste Schnittstelle, ohne sich mit auf elementarer Ebene mit SOAPFunktionsweisen befassen zu müssen. In COINED werden bei der Generierung
des Client-Proxys auch die Basis-Model-Klassen, die eine Abbildung der DBTabellen darstellen, vom Server zum Client transferiert.
Der in COINED verwendete Benachrichtigungsmechanismus, mit dem
Änderungsnachrichten an Clients propagiert werden, basiert auf JMS (Java
Messaging Service) - als JMS-konformer Messaging-Dienst wird ActiveMQ
eingesetzt.
COINED nutzt asynchrones Topic-basiertes Publish/Subscribe-Messaging.
Clients registrieren sich (subscribe) beim Server als Konsumenten bestimmter
Topics. Topics sind logische Kanäle, mit denen sich Nachrichten filtern lassen. So
gibt es in COINED z.B. relativ feingranulierte Topics, welche die jeweiligen
Änderungen von Klassendetails betreffen, wie ClassInfo, FieldInfo, MethodInfo
und MethodParamInfo. Wenn nun eine Änderung am Datenbestand ausgeführt
wird, veröffentlicht (publish) der Server eine Änderungsnachricht im
entsprechenden Topic und das JMS-System, also ActiveMQ, sorgt dafür, dass alle
Clients, die dieses Topic abonniert haben, die Nachricht erhalten.
Zur persistenten Speicherung der Daten wurde während der Entwicklung das
freie, unter der GPL stehende, relationale Datenbankmanagementsystem MySQL
eingesetzt. Der Umsetzung der Zugriffe von COINED auf die Datenbank erfolgt
mittels JDBC über den offiziellen JDBC-Treiber Connector/J von MySQL. Die
75
Zugriffe sind in SQL formuliert und in einer eigenen Datenbankschicht der
Serverarchitektur innerhalb von Mapperklassen organisiert und implementiert. Es
ist prinzipiell möglich andere Datenbanken und Treiber als MySQL und
Connector/J für COINEDs Datenhaltung einzusetzen - alle SQL-Abfragen in
COINED sind ANSI SQL-92 konform formuliert. In solchen Fällen muss die
XML-Konfigurationsdatei des Servers entsprechend angepasst werden und die
entsprechenden Treiber-Bibliotheken in die Webapplikation eingebunden werden.
Die Mapperklassen der Datenbankschicht bilden die DB-Tabellen in etwa 1-zu-1
auf Basisklassen in ein elementares Klassenmodell ab. Die Bezeichnungen der
Datenbanktabellen wird in jeweils in einem Interface zur entsprechenden ModellKlasse definiert und muss dort bei Schema-Änderung ggfs. angepasst werden.
coined::server::model::CObject
coined::server::database::CObjectMapper
classID: long
database: Database
description: String
logger: Logger
name: String
CObjectMapper(in database: Database)
CObject()
delete(in id: long)
equals(in o: Object): boolean
findByID(in id: long): CObject
getClassID(): long
findByIDs(in cObjectIDs: long[]): List
getDescription(): String
findByRoleID(in roleID: long): List
getName(): String
findByUserID(in userID: long): List
setClassID(in roleID: long)
getCObjectsByProject(in projectID: long): List
setDescription(in description: String)
insert(in cObject: CObject)
setName(in name: String)
update(in cObject: CObject)
«interface»
coined::server::database::IObject
COL_DESCRIPTION: String
COL_ID: String
COL_ID_CLASS: String
COL_NAME: String
SQL_TABLE: String
Abbildung 5.1 – Exemplarisch für die Umsetzung der DB-Schnittstelle CMessageMapper,
CMessage, IMessage
Session-Management: Client erhalten bei der Anmeldung am Server eine
SessionID. Die ID verliert nach 30 Sekunden ihre Gültigkeit, sofern sie nicht
durch weitere Requests erneuert wird. Bei Request an den Webservice wird die
Gültigkeitsdauer
automatisch
verlängert.
Am
Client
läuft
ein
KeepSessionAliveThread der sich regelmäßig beim Server meldet. Der Server
räumt seinen SessionID-Pool entsprechend regelmäßig auf, wenn er auf ungültige
IDs stößt, korrigiert er ggf. den entsprechenden Client-Status und loggt den
Benutzer aus. So werden Inkonsistenzen bzgl. User- und ClientStati vermieden wenn ein Client aufgrund unvorhergesehener Umstände (Absturz, Netzverlust)
unvermittelt, also ohne ordentliche Abmeldung, ausscheidet, wird seine SessionID
ungültig, damit ist der Server informiert und kann den Statuswechsel an die
anderen Clients propagieren.
76
Abbildung 5.2 – Paketstrukturen von COINEDs Client und Server
Der Client ist als Eclipse Plugin realisiert. Plugins werden mit einer ActivatorKlasse gestartet. Der Activator für COINED ist CoinedPlugin.java, siehe
Abbildung 5.3.
.
Abbildung 5.3 – COINEDs Activator-Klasse
In Abbildung 5.2 findet sich ein Überblick über die Paketstrukturen des COINED
Clients und des Servers. In Abbildung 5.4 bietet einen Überblick über alle
Messaging und Listener-Klassen. Es gibt einen ChannelManager, der die externen
JMS-Nachrichten managt und einen MessageController der die Client-Internen
Listener-Strukturen verwaltet. Abbildung 5.5 zeigt die Model-Klassen.
coined.server.model wird sowohl vom Client als auch vom Server verwendet, die
77
Objekte dieser Klassen werden auch über die WebService-Schnittstelle
transferiert.
Abbildung 5.4 – Alle Messaging und Listener Klassen
Abbildung 5.5 – Die Modell-Klassen
78
5.2 Erfahrungen / Evaluation
COINED wurde noch nicht evaluiert. Anhand der Reaktionen auf erste
Demonstrationen - u.a. erfolgte eine Demo vor Fachpublikum im Rahmen des
Educator’s Symposium der OOPSLA 2006 - lässt sich aber bereits feststellen, dass
es bezüglich der Benutzerführung noch einige Verbesserungsmöglichkeiten gibt.
Das bestehende User-Interface wird schnell als zu komplex und die
Benutzerführung als kompliziert empfunden. Hier könnte man eventuell mit
einigen Vereinfachungen und einer strengeren Benutzerführung Abhilfe schaffen.
Zudem hängt das Gefühl der Unübersichtlichkeit auch stark von der Auflösung
des verwendeten Monitors ab - um alle Views der COINED Perspektive
vollständig darstellen zu können, muss mit einer Auflösung von mehr als
1024x768 Pixeln gearbeitet werden.
Die Visualisierungsform des Nachrichtenflusses in der Diagrammdarstellung wird
dagegen erfahrungsgemäß akzeptiert und als sinnvoll empfunden. Angebracht
wäre eventuell noch ein weiteres unterstützendes Element, welches signalisiert,
wenn ein Benutzer „an der Reihe ist“, also wenn eins seiner Objekte durch den
Erhalt einer Nachricht aktiviert wurde und die Kontrolle erhalten hat. Denkbar
wären zum Beispiel ein akustisches Signal, ein Popup-Fenster, das automatische
Holen des MessageProcessingViews in den Vordergrund oder einfach die
Veränderung der Hintergrundfarbe des MsgProcessingViews.
6 Zusammenfassung
79
6 Zusammenfassung
6.1 Kurzfassung des Problems und wie es gelöst wurde
In Rahmen dieser Arbeit wurde der synchroner Mehrbenutzer-Diagrammeditor
COINED zur Simulation von Objektinteraktionen konzipiert und implementiert.
COINED ist sowohl für den Einsatz im didaktischen Umfeld der OOP-Lehre als
auch für den Einsatz im Entwicklungprozess von OO-Systemen geeignet. In
Kapitel 4 wurde gezeigt, dass COINED die Anforderungen vollständig erfüllt,
sowohl im didaktischen als auch im Entwicklungskontext, sowie technischer
Hinsicht. Die vollständige Erfüllung der Anforderungen konnte keiner der für
einen Vergleich in Frage kommenden Forschungsansätze leisten. In der Regel
unterstützen diese Ansätze den Kooperationsaspekt nicht. COINED dagegen
wurde gerade mit dem Schwerpunkt auf Kooperation konzipiert. Es lässt sich
sowohl lokal als auch verteilt einsetzen, mehrere Benutzer können gleichzeitig
synchron an einem gemeinsamen Projekt arbeiten.
Auch war keiner der untersuchten Ansätze gleichermaßen für den Einsatz in der
Lehre zur Vermittlung von OO-Konzepten wie für den Einsatz im Kontext der
OO-Systementwicklung geeignet. COINED dagegen kann die Anforderungen in
beiden Kontexten erfüllen. Die Integration des Editors in die Eclipse-Umgebung
ermöglicht eine ganzheitliche Entwicklung. Dabei wird zunächst von einem
Entwicklungsteam innerhalb von COINED in einem iterativen Prozess, der u.a.
interaktiven Tests in Form von Szenario-Rollenspielen umfasst, das Modell
erarbeitet. Aus diesem Modell werden dann per Knopfdruck Java-Klassengerüste
in einem Eclipse-Projekt generiert. Der Anwender wechselt innerhalb von Eclipse
in die Java-Perspektive und kann direkt mit der Implementierung beginnen.
6.2 Offene Fragen für weitere Forschungsarbeiten
Ein offensichtlicher Punkt für eine sinnvolle Erweiterung ist die weitergehende
Generierung von Quell-Code. Ein rudimentärer Ansatz ist mit der Möglichkeit der
Generierung von Klassengerüsten mit Attributen und Methoden schon vorhanden.
Hier kann man nun beliebig aufbauen. Es ist denkbar aus den während einer
Simulation gesammelten Informationen JUnit-Testcases zu erzeugen. Das System
protokolliert sämtliche Zuweisungen, die die Benutzer durchführen und sämtliche
Nachrichten, die verschickt werden. Diese Abläufe stellen letztlich Testcases dar,
die einfach nur auf entsprechenden Java-Code abgebildet werden müssen. Zum
Definieren und Auslösen der Generierung eines Testcases könnte man den
Benutzer zum Beispiel eine Sequenz von Nachrichten im HistoryView markieren
lassen und den entsprechenden Punkt im Kontextmenü anbieten. Die Integration
von COINED in Eclipse ermöglicht nicht nur das Generieren, sondern auch das
direkte Ausführen der generierten JUnit-Tests in der JUnit-Umgebung von
Eclipse.
Es wäre denkbar, COINED um Replay-Funktionalitäten zu erweitern. Eine
Ablaufsteuerung mit der man auf Knopfdruck eine gespeicherte Simulation vorund zurückspulen und gegebenenfalls noch einmal ganz von vorne betrachten
kann. Der Ablauf würde dann am Diagramm animiert und visualisiert. Mit dieser
Erweiterung wäre es dann natürlich auch sinnvoll, mehrere Simulationen und
Szenarien zu einem Projekt speichern zu können und diese dann eben bei Bedarf
abrufen und wiedergeben zu können. Es sollte eine Stackanalyse und History-
6 Zusammenfassung
80
Analyse möglich sein, die aufzeigt, welche Auswirkungen geändertes Verhalten
auf frühere Interaktionen hätte.
Man könnte COINED um grafische Editiermöglichkeiten erweitern. Der
DiagrammView würde dann zum DiagrammEditor mit den entsprechen
Möglichkeiten, per Mausklick Objekte und Klassen zu erzeugen und zu
manipulieren. Die technische Umsetzung mit dem GEF würde sich anbieten, da
COINED ohnehin schon Teile davon (Draw2D) verwendet. Bei Verwendung des
GEF wären auch solche Funktionalitäten wie Overview-Fenster zum schnellen
Navigieren in großen unübersichtlichen Diagrammen leicht umsetzbar. Auch eine
ZoomIn/Out-Funktion ließe sich mit dem GEF sehr einfach realisieren und
integrieren.
Die Diagrammansicht kann noch beliebig erweitert und in Details verbessert
werden. Es wäre praktisch, wenn man in großen Projekten Bereiche des
Diagramms aus- und bei Bedarf wieder einblenden könnte. Die Interaktivität
könnte mit zusätzlichen Drag&Drop-Möglichkeiten erhöht werden. Objekte
sollten sich vom und in den DiagrammView ziehen lassen. Neue Objekte könnten
durch das Ziehen von Klassen in den DiagrammView erzeugt werden.
Die Generierung formaler UML-Diagramme wäre auch eine denkbare
Erweiterungsmöglichkeit. Aus den Klassenbeschreibungen können sich
Klassendiagramme erzeugen lassen. Aus den Role-Play-Diagrammen können
Objekt-Diagramme und Interaktionsdiagramme wie Kooperations- und
Sequenzdiagramme abgeleitet werden.
Im Rahmen dieser Arbeit konnten nicht alle Sprachkonzepte von Java
verwirklicht werden. In dieser Hinsicht sollten sich noch einige
Erweiterungsmöglichkeiten finden lassen. So könnte ein nächster wichtiger
Schritt die Umsetzung des Vererbungskonzepts sein. Ebenso sollte sich die
Umsetzung des Begriffs der Interfaces einbauen lassen.
Eine stärke Verzahnung des COINED-Clients mit dem Projektmanagement von
Eclipse wäre ebenfalls eine sinnvolle Erweiterung. In der aktuellen Version
arbeitet COINED mit einem eigenen, selbst-definierten Projekt-Begriff - es wäre
denkbar, COINED-Projekte in klassische Eclipse-Projekte zu integrieren. Ein
Schritt hierbei wäre die Erzeugung einer speziellen project nature für COINED;
die dann die Verbindungen zwischen dem Projekt und dem COINED-Plugin
definiert und managt.
Ein weiteres Thema könnte die lokale Replikation der Daten sein, man könnte
COINED dahingehend erweitern, dass es möglich wird auch offline, also ohne
Serveranbindung zu arbeiten.
Es könnte die Visualisierung beliebiger Java-Programme eingebaut werden, also
quasi die entgegengesetzte Richtung zur Code-Generierung bei der am Ende JavaKlassen stehen. Java-Klassen dann dienen als Ausgangsbasis für die Erzeugung
eines COINED-Projekts (Reverse-Engineering).
Im Zusammenhang mit den Rollespielen sollte die Erfassung von Szenarien in
den COINED-Kontext einarbeiten werden.
81
Quellenverzeichnis
[Agi01]
[Alice07]
[And02]
[Argo07]
[Arm06]
[Baec93]
[Beck89]
[Berg01]
[Berg04]
[Bit02]
[BlueJ07]
[Bör04]
[Bör05]
[Borr02]
[Bra04]
[Brady05]
[Bru01]
[Bru05]
[Coo00]
Agile Manifesto, http://www.agilemanifesto.org/principles.html
http://www.alice.org/
S.K. Andrianoff, D.B. Levine, Role Playing in an Object-Oriented
World, Computer Science Department, St. Bonaventure University
ArgoUML, http://argouml.tigris.org/
Deborah J. Armstrong, "The Quarks of Object-Oriented
Development." COMMUNICATIONS OF THE ACM February
2006, 49(2)
Baecker, R. M. (1993). Readings in groupware and computersupported cooperative work: assisting human-human collaboration.
San Mateo, Calif: Morgan Kaufmann Publishers.
Beck, K., Cunningham, W. (1989). A Laboratory for Teaching
Object-Oriented Thinking. Proceedings OOPSLA’89. 1-6.
Bergin, J., Eckstein, J., Wallingford, E., Manns, M.L. (2001) Patterns
for Gaining Different Perspectives. In Proceedings of the 8th
Conference on Pattern Languages of Programs (Monticello, Illinois,
USA, September 11-15, 2001)
Joseph Bergin, Mark Stehlik, Jim Roberts, and Richard Pattis. Karel
J. Robot: A gentle introduction to the art of object-oriented
programming in Java.
Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison
Wesley Professional, 2-3.
http://www.bluej.org/
Jürgen Börstler (2004). Object-Oriented Analysis and Design
Through Scenario Role-Play. In: UMINF 04.04, ISSN-0348-0542.
UMEÅ UNIVERSITY, Department of Computing Science: SE-901
87 UMEÅ, SWEDEN, (Online at: )
Börstler, J. (2005), Improving CRC-Card Role with Role-Play
Diagrams, OOPSLA’05, San Diego, USA, 356-364, ACM Press
Alf Borrmann, Manfred Rätzmann, Jörg Sauer, Jan Matèrne, Gunnar
Landgrebe (2002), UML und Rational Rose – Anleitung zum
Praxiseinsatz, Galileo Computing
A. Brady (2004), Marine Biology Simulation Case Study. Teaching
resources, Febuary 2004. Online at: http://max.cs.kzoo.edu/AP/MBS/
A. Brady (2005), Marine Biology Simulation Case Study, Teaching
Resources, Online at http://max.cs.kzoo.edu/AP/MBS/index.html,
Kim B. Bruce, Andrea Danyluk, and Thomas Murtagh. A library to
support a graphics-based object-first approach to CS 1. In
Proceedings of the thirty-second SIGCSE technical symposium on
Computer Science Education, pages 6–10. ACM Press, 2001.
Kim B. Bruce (2005), Controversy on How to Teach CS 1:A
Discussion on the SIGCSE-members Mailing List, Reprint, SIGCSE
Bulletin inroads, 37(2):11-117
Stephen Cooper, Wanda Dann, Randy Pausch (2000) Alice: a 3-D
tool for introductory programming concepts
82
[Coo03]
Stephen Cooper, Wanda Dann, and Randy Pausch. Teaching objectsfirst in introductory computer science. In Proceedings of the 34th
SIGCSE technical symposium on Computer science education, pages
191–195. ACM Press, 2003.
[Dan03]
Wanda Dann, Stephen Cooper, Randy Pausch (2003). Objects:
Visualization of Behavior and State. ITiCSE ’03, S.84-88
[Diaz05a] Guillermo Jiménez-Díaz, Mercedes Gómez-Albarrán,Marco A.
Gómez-Martín and Pedro A. González-Calero (2005). Software
Behaviour Understanding Supported by Dynamic Visualization.... In:
ITiCSE’05 ?. : , 54-58. (Online at: )
[Diaz05b] Guillermo Jiménez-Díaz, Mercedes Gómez-Albarrán,Marco A.
Gómez-Martín and Pedro A. González-Calero (2005): ViRPlay:
Playing Roles to Understand Dynamic Behvior
[Diaz05c] Guillermo Jiménez-Díaz, Mercedes Gómez-Albarrán,Marco A.
Gómez-Martín and Pedro A. González-Calero (2005). Understanding
Object-Oriented Software through Virtual Role-play. In: IACLT’05
[Fab]
Fablusi, The online Role-Play Simulation Platform, Online at
http://www.fablusi.com
[Gero04]
Gerosa, M., H. Fuks, A. Raposo, and C. Lucena (2004, February).
Awareness support in the AulaNet learning environment. In
Proceedings of the IASTED International Conference on Web-Based
Education - WBE 2004, Innsbruck,Austria, pp. 490{495. ACTA
Press.
[Grud88]
Grudin, Jonathan (1988). Why CSCW applications fail: problems in
the design and evaluation o.... In: Proceedings of the 1988 ACM
conference on Computer-supported cooperative work. ACM Press:
Portland, Oregon, United States, 85 - 93. (Online at:
http://research.microsoft.com/research/coet/Grudin/papers/CSCW198
8.pdf)
[Haa04]
Kelsey Van Haaster, Diane Hagan (). Teaching and Learning with
BlueJ:an Evaluation of a Pedagogical Tool.
[Köl03]
M. Kölling , J. Rosenberg. The BlueJ System and its pedagogy.
Journal of Computer Science Education, Special issue on Learning
and Teaching Object Technology, 13(4):249-268
[MBSC07] http://www.collegeboard.com/student/testing/ap/compsci_a/case.html
[Naps02]
Naps, T.L., Rößling, G., Almstrum, V., Dann, W., Fleischer, R.,
Hundhausen, C., Korhonen, A., Malmi, L., McNally, M., Rodger, S.,
Velázquez-Iturbide (2002), J.A. Exploring the Role of Visualization
and Engagement in Computer Science Education. In: M.E.
Caspersen, D. Joyce, D. Goelman, I. Utting (eds.): Working group
reports from ITiCSE on Innovation and Technology in computer
science education, ACM Press, Århus, Denmark, (2002) 131-152
[OMG03] Object Management Group, UML 2.0 Infrastructure Specification.
www.omg.org, 2003
[Pau95]
Pausch, R. et al. (1995), Alice: Rapid Prototyping system for virtual
reality, IEEE Computer Graphics and Applications, 15(3), 8-11
[Pos07]
Poseidon for UML, http://www.gentleware.com/products.html
[Rag05]
N. Ragonis, M. Ben-Ari (2005). On understanding the Statics and
83
Dynamics of Object-Oriented Programs.
[Rob01]
Roberts, E. & Picard, A. Designing a Java graphicslibrary for CS1. In
Proceedings of the 3rd annual conference on Innovation and
Technology in Computer Science Education (Dublin, Ireland, July,
1998), 213-218.
[Rose07]
http://www-06.ibm.com/software/awdtools/developer/rose/enterprise/
[Rupp06]
Chris Rupp, Sophist Group: Requirements-Engineering und Management. Carl Hanser Verlag, München 2006,
[Schmo07] Schmolitzky, A. (2007), Sieben Thesen zur Verwirrung von
Anfängern der objektorientierten Programmierung
[Schü00]
Schümmer, J., Schümmer, T., Schuckmann, C., (2000). COAST––
Ein Anwendungsframework für synchrone Groupware. In:
Conference Proceedings for the “Net.ObjectDays 2000”
[Sharf99]
Sharf, J., Hsu, T., Ryan, E. (1999). TimeScope: an Educational 3D
Multi-User Role-Playing Environment. In Proceedings of the 9th
Annual Conference of the Internet Society (San Jose,CA, USA, June
22-25, 1999),.
[SL07]
Schümmer & Lukosch (2007), Patterns for Computer-Mediated
Interaction"
[Teu95]
Teufel, S., C. Sauter, T. Mühlherr, and K. Bauknecht (1995).
Computerunterstützung für die Gruppenarbeit. Addison-Wesley.
[Tog07]
Borland Together (2007),
http://www.borland.com/us/products/together/index.html
[UML07] Unified Modeling Language – UML Resource Page,
http://www.uml.org/
[Wirf90]
Wirfs-Brokc, R., Wilkerson, B., Wiener, L. (1990), Designing
Object-Oriented Software. Upper Saddle River, NJ: Prentice Hall
84
Die im Rahmen dieser Arbeit entwickelte kooperative Anwendung COINED
(Collaborative Examination of Object Interaction) wird als OpenSource-Projekt
weiterentwickelt.
Projektinformationen und die aktuelle Executables und Sourcen sind auf den
Web-Seiten des Fachbereichs Kooperative Systeme, Praktische Informatik VI, der
FernUni Hagen unter folgender URL hinterlegt:
http://www.pi6.fernuni-hagen.de/de/projekte/coined.html

Kooperative Objektinteraktionsdiagramme in Eclipse

Transcrição

Documentos relacionados

Knigge-Tipps rund um die Kommunikation Wussten Sie, dass

WIN-911®

¨Ubungsblatt 6 Aufgabe 1: Codebreaker (6 Punkte, B)

Dax - Multi-Asset-Strategie - Trust-Wi

AGB herunterladen als PDF-Datei

Phishing und Pharming: Diebstahl im Netz

Benutzerordnung - Albertus Magnus Gymnasium Friesoythe

Office 365 Admin Center – First Steps - RZ

Wochenblatt, Oktober 2005 - Evangelische Kirche der Pfalz

ALLGEMEINE GESCHÄFTSBEDINGUNGEN