Kooperative Objektinteraktionsdiagramme in Eclipse

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

2 Anforderungsanalyse 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

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

•

•

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,

2 Anforderungsanalyse

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,

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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-

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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)

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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

2 Anforderungsanalyse •

•

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).

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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. 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 UMLObjekt 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 ggf. als gemeinsame Grundlage für die rückblickende Diskussion getroffener Entscheidungen verwenden können.

2 Anforderungsanalyse

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 Flexible Reaktion auf neue Erkenntnisse 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

2 Anforderungsanalyse

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.

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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

2 Anforderungsanalyse

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 Kommunikationsmedium für den Wissenstransfer 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 a) Graphische Visualisierung als Kommunikationsunterstützung 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

2 Anforderungsanalyse

31

Diagrams, s. [Bör04]) b) Protokolle der Interaktion als Kommunikationsunterstützung. 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

2 Anforderungsanalyse

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

2 Anforderungsanalyse

33

Internet) mit dem System arbeiten können, unabhängig vom Online-Status anderer Gruppenmitglieder und einzelner Clients.

3 Stand der Forschung

34

3 Stand der Forschung 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.

3 Stand der Forschung

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])

3 Stand der Forschung

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]).

3 Stand der Forschung

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.

3 Stand der Forschung

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.

3 Stand der Forschung

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-

3 Stand der Forschung

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.

3 Stand der Forschung

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

3 Stand der Forschung

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-

3 Stand der Forschung

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

3 Stand der Forschung

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

3 Stand der Forschung

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 Kommunikationsmedium für den Wissenstransfer TA2 a) Graphische Visualisierung als Kommunikationsunterstützung

3 Stand der Forschung

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. b) Protokolle der Interaktion als Kommunikationsunterstützung. 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 Flexible Reaktion auf neue Erkenntnisse 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

3 Stand der Forschung

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: Flexible Reaktion auf neue Erkenntnisse 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

3 Stand der Forschung

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. TA10: Usermanagement 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 a) Graphische Visualisierung als Kommunikationsunterstützung 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 a) Graphische Visualisierung als Kommunikationsunterstützung 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.

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 In COINED werden Nachrichtenfluss und Objektinteraktion in Diagrammen visualisiert. Diese Diagramme können später als Kommunikationsgrundlage dienen und zu Dokumentationszwecken eingesetzt werden

4 Lösungsansatz

68

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. 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. TA10: Usermanagement 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 “) 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

5 Details zur Lösung 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

5 Details zur Lösung

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.

5 Details zur Lösung

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

5 Details zur Lösung

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

5 Details zur Lösung

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