Universität HamburgFakultät für Mathematik, Informatik und NaturwissenschaftenDepartment Informatik, Arbeitsbereich SWT

Die Metaphern "Konsumieren" und

"Produzieren" in BlueJ

Bachelorarbeit

Chris StahlhutMatrikelnummer: 5872867

E-Mail: chriss@cstahlhut.de

3. September 2010

Erstgutachter: Dr. Axel SchmolitzkyZweitgutachter: Prof. Dr. Horst Oberquelle

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 BlueJ 32.1 Zielsetzung von BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Geschichte von BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Architektur von BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Archiv-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.2 Teilsysteme des bluejcore-Archivs . . . . . . . . . . . . . . . . . . . . 7

3 Konsumieren und Produzieren 113.1 Herkunft der Metaphern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Konsumieren und Produzieren in der objektorientierten Programmierung . . . . 13

4 Konsumieren und Produzieren in BlueJ 174.1 Derzeitiger Stand in BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Fortführung der bereits bestehenden Unterstützung . . . . . . . . . . . . . . . 18

4.2.1 Zwei Sichten auf eine Klasse in einem Klassendiagramm . . . . . . . . 194.2.2 Ausblenden nicht benötigter Klassen . . . . . . . . . . . . . . . . . . . 204.2.3 Festlegen des Einstiegspunkts in das Klassendiagramm . . . . . . . . . 214.2.4 Implementationsansicht eines Interfaces . . . . . . . . . . . . . . . . . 214.2.5 „Falten“ von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.6 Schnittstellen- und Implementationsansicht in BlueJ . . . . . . . . . . 224.2.7 Kriterien nach denen Klassen in BlueJ angezeigt werden . . . . . . . . 23

4.3 Entwurf der Benutzungsschnittstelle . . . . . . . . . . . . . . . . . . . . . . . 244.3.1 Kriterien für interaktive Systeme . . . . . . . . . . . . . . . . . . . . . 244.3.2 Interaktion in BlueJ-CP . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.4 Ansätze zur Darstellung der Schnittstellen- und Implementationsansicht . . . . 264.4.1 Bereits bestehende Darstellung der Schnittstellen- und Implementati-

onsansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.2 Schnittstellenansicht in UML . . . . . . . . . . . . . . . . . . . . . . 274.4.3 Erster Entwurf der Schnittstellen- und Implementationsansicht . . . . . 28

4.5 Fixieren von Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.5.2 Darstellung einer fixierten Klasse . . . . . . . . . . . . . . . . . . . . 31

i

4.6 Ausnahmen bei den Kriterien zum Anzeigen von Klassen . . . . . . . . . . . . 314.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 BlueJ-CP 355.1 Anforderungen an den Quelltext . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Umsetzung im Quelltext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2.1 Bestimmen der Schnittstellenabhängigkeiten . . . . . . . . . . . . . . 365.2.2 Bestimmen der angezeigten Klassen . . . . . . . . . . . . . . . . . . . 375.2.3 Implementation der Interaktion um die Ansicht zu wechseln . . . . . . 385.2.4 Refactoring der Konfiguration des Benutzers . . . . . . . . . . . . . . 39

5.3 Mergen von BlueJ-CP mit BlueJ 3 . . . . . . . . . . . . . . . . . . . . . . . . 415.3.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.2 Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Nicht verfolgte Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6 Evaluation anhand einer Benutzerstudie 456.1 Rahmen der Studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.3 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.4 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.5 Bewertung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Zusammenfassung und Ausblick 557.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Literaturverzeichnis 59

A Architektur von BlueJ 61A.1 Betrachtung der Teilsysteme des bluejcore-Archivs . . . . . . . . . . . . . . . 61A.2 Beziehungen zwischen den Teilsystemen . . . . . . . . . . . . . . . . . . . . . 64A.3 Verbesserungsvorschläge und Kritik an der Architektur und dem Quelltext von

BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66A.3.1 Allgemeine Kritik am Quelltext . . . . . . . . . . . . . . . . . . . . . 66A.3.2 Verbesserungsvorschläge . . . . . . . . . . . . . . . . . . . . . . . . . 67

B Evaluation anhand einer Benutzerstudie 71B.1 Leitfaden für das Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71B.2 Aufgabe der Benutzerstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

C Probleme und Feature-Requests 73C.1 Fehler in BlueJ/-CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73C.2 Feature-Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

D Inhalt der beigefügten CD-ROM 77

ii

Abbildungsverzeichnis

2.1 Vergleich der Projektansicht in BlueJ und der Netbeans Projekt-Ansicht. . . . . 42.2 Abhängigkeiten der Jar-Archive von BlueJ sowie der verwendeten Bibliotheken 72.3 Die einzelnen Komponenten von des bluejcore Archivs, sowie ihre Beziehungen

zueinander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1 Konzept-Diagramm einer Liste mit zwei konkreten Implementationen und ei-nem Klienten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Darstellung der Abhängigkeiten der LinkedTitelListe . . . . . . . . . . . . 14

4.1 Vergleich der Dokumentationsansicht (links) und Quelltextansicht (rechts) desEditors in BlueJ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Darstellung der Abhängigkeiten der LinkedTitelListe . . . . . . . . . . . . 184.3 Darstellung der Schnittstellenabhängigkeiten der LinkedTitelListe . . . . . 194.4 Darstellung der Schnittstellenabhängigkeiten der LinkedTitelListe mit der

verborgenen Klasse DoppellinkKnoten . . . . . . . . . . . . . . . . . . . . . 204.5 Ein Dienstleister mit mehreren Klienten . . . . . . . . . . . . . . . . . . . . . 214.6 Schnittstellen- (links) und Implementationsansicht (rechts) in jMango . . . . . 274.7 Ein Objekt in der BlueJ Objektleiste . . . . . . . . . . . . . . . . . . . . . . . 274.8 Schnittstellen- (links) und Implementationsansicht (rechts) mit Quelltextschnip-

sel in der Implementationsansicht . . . . . . . . . . . . . . . . . . . . . . . . 284.9 Verbergen der Implementation in der Schnittstellenansicht (links) . . . . . . . . 294.10 Die zu betrachtende Klasse ist nur sichtbar, wenn auch mehrere, nicht zu be-

trachtende Klassen sichtbar sind . . . . . . . . . . . . . . . . . . . . . . . . . 304.11 Die nicht benötigten Klassen werden nicht angezeigt. . . . . . . . . . . . . . . 304.12 Eine an der oberen linken Ecke fixierte Klasse . . . . . . . . . . . . . . . . . . 31

5.1 Darstellung der Beziehungen zwischen den Teilsystemen dependencygraph

und pkgmgr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Darstellung der Entkopplung des PkgMgrFrame und PackageEditor von den

Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 Die Benutzungsschnittstelle von BlueJ für Einstellungen. . . . . . . . . . . . . 405.4 Entwicklung von BlueJ-CP in einer Versionsverwaltung . . . . . . . . . . . . . 415.5 Gewähltes Vorgehen BlueJ-CP mit BlueJ 3 zu vereinen . . . . . . . . . . . . . 42

6.1 Vollständiges Projekt JMicroTracker . . . . . . . . . . . . . . . . . . . . . . . 476.2 Antworten auf die Frage: Unterstützt der Wechsel der Ansichten das Verständnis

des Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

iii

6.3 Antworten auf die Frage: Hilft BlueJ-CP beim Lösen der Aufgabe . . . . . . . 506.4 Aussagen der Probanden ob BlueJ-CP in SE 1 verwendet werden sollte . . . . 506.5 Implementationsansicht des ExitActionListeners . . . . . . . . . . . . . . . . . 526.6 Schnittstellenansicht des ExitActionListeners . . . . . . . . . . . . . . . . . . 52

7.1 Die Schnittstellen- (links) und Implementationsansicht (rechts) in BlueJ-CP. . . 557.2 Ein Projekt in BlueJ mit einem Paket . . . . . . . . . . . . . . . . . . . . . . . 56

A.1 Die einzelnen Komponenten von des bluejcore Archivs, sowie ihre Beziehungenzueinander . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

iv

1 Einleitung

Dieses Kapitel leitet die Bachelorarbeit mit ihrer zugrunde liegenden Motivation und einer kur-zen Beschreibung des Aufbaus der Arbeit ein.

1.1 Motivation

Die Java Entwicklungsumgebung BlueJ bietet mit ihrer auf die Lehre des objektorientiertenProgrammierparadigmas ausgelegten Oberfläche einen hilfreichen Ansatz, um einen Teil derKomplexität von Programmiersprachen zu verbergen. Es ist beispielsweise nicht notwendig, be-reits von Anfang an die Bedeutung von Schlüsselwörtern, wie public oder static zu kennen,um das Verhältnis von Klassen zu Objekten und Methoden zu verstehen. Die Bedeutung dieserSchlüsselwörter können zu einem späteren Zeitpunkt betrachtet werden, wodurch es möglichwird, zunächst die Prinzipien von Objektorientierung zu lehren, ehe die konkrete Umsetzung inJava erfolgt.

„Konsumieren“ und „Produzieren“ stellen zwei unterschiedliche Sichten auf Objekte dar. Es gibtvielfach eine benutzende (konsumierend) und erstellende (produzierend) Sicht. In Java stellt dieSchnittstellendokumentation einer Klasse die benutzende Sicht auf diese Klasse bereit. Um eineKlasse zu verwenden, ist es nicht notwendig zu wissen, wie diese Klasse intern funktioniert.

Wird ein Java Projekt in BlueJ betrachtet, stellt das vereinfachte UML-Klassendiagramm nichtnur eine Sammlung von Klassen, sondern auch ihrer Beziehungen zueinander dar. In diesemKlassendiagramm werden jedoch alle angezeigten Benutztbeziehungen gleich behandelt unddargestellt. Nur in der Schnittstelle einer Klasse definierte Abhängigkeiten werde nicht separatbetrachtet. Jedoch sind gerade diese Beziehungen von Bedeutung, wenn eine Klasse nur ver-wendet (konsumiert) wird. Unnötig dargestellte Abhängigkeiten können ein Klassendiagrammkomplexer darstellen, als es für einen bestimmten Fokus der Betrachtung sein muss.

Ziel dieser Bachelorarbeit ist es, BlueJ dahingehend zu erweitern, dass nicht in der Schnittstelleeiner Klasse definierte Abhängigkeiten verborgen werden können.

1.2 Aufbau der Arbeit

Das 2. Kapitel erläutert die Zielsetzung und Geschichte sowie die Architektur der integriertenEntwicklungsumgebung BlueJ.

1

Kapitel 3 beschäftigt sich mit den Metaphern „Konsumieren“ und „Produzieren“, ihrer Herkunftund Bedeutung in der Objektorientierung.

In Kapitel 4 wird zunächst die bereits vorhandene Unterstützung der Metaphern in BlueJ erläu-tert. Dieser Ansatz wird daraufhin fortgeführt und auf das Klassendiagramm übertragen.

Die Umsetzung der fortgeführten Unterstützung der Metaphern wird in Kapitel 5 behandelt.

Kapitel 6 erläutert die Evaluation des modifizierten BlueJs. Hierbei wird zunächst der Rahmeneiner Benutzerstudie dargelegt, gefolgt von dem gewählten Vorgehen, den Ergebnissen sowieeiner Bewertung der Ergebnisse.

Nach der Zusammenfassung dieser Arbeit wird in dem Ausblick auf noch mögliche Verbesse-rungen und weitere Fortführungen der Unterstützung der Metaphern innerhalb von BlueJ einge-gangen.

2

2 BlueJ

In diesem Kapitel wird zunächst die Zielsetzung und Geschichte von BlueJ erläutert. Daraufhinwird ein Überblick über die Architektur von BlueJ gegeben.

2.1 Zielsetzung von BlueJ

BlueJ ist eine auf die Lehre des objektorientierten Programmierparadigmas ausgerichtete Ent-wicklungsumgebung (IDE) für Java. In [KÖLLING et al. 2003] werden drei grundlegende Pro-bleme mit den üblichen Entwicklungsumgebungen, wie z.B. Netbeans oder Eclipse, dargelegt,welche in BlueJ vermieden werden. Im folgenden werden diese Kritikpunkte erwähnt und er-läutert, wie diese Kritikpunkte in BlueJ behoben werden.

Keine objektorientierte Umgebung Im Gegensatz zu vielen anderen Entwicklungsumge-bungen setzt BlueJ bereits bei der Darstellung eines Projektes auf einen objektorientierten An-satz. Klasse und Objekte werden direkt in der Oberfläche angezeigt und es ist nicht notwendigzu wissen, wie die Elemente im Dateisystem angeordnet sind.Die Abbildung 2.1 stellt den Unterschied zwischen BlueJ und einer in heutigen Entwicklungs-umgebungen übliche Ansicht eines Projektes dar. In BlueJ werden Klassen inklusive ihrer Ab-hängigkeiten dargestellt, und nicht nur als Liste von Klassen und Paketen.

Zu komplexe Umgebung Heutige Entwicklungsumgebungen sind eher auf erfahrene undbereits ausgebildete Entwicklerinnen und Entwickler ausgelegt, als auf Personen, die erst amAnfang des Lernvorgangs stehen. Eine ungeübte Person kann von den Möglichkeiten einer sol-chen Umgebung, wie die Projekt-Ansicht, Refactorings oder die Unterstützung für Source CodeManagement (SCM), irritiert und im Lernvorgang gehemmt werden. BlueJ besitzt eine einfachgestaltete Oberfläche und reduziert die Funktionsvielfalt auf ein Minimum. Es gibt in BlueJweder eine Unterstützung für Refactorings, noch für einen Code-Generator. Auch wenn dieseMöglichkeiten heutzutage täglich verwendet werden, sind sie für unerfahrene Personen unnötig,da sie kein Unterstützung bieten um die Konzepte der Objektorientierung zu erlernen.

3

(a) Objektorienter Ansatz in der BlueJ Benutzungsschnittstelle (b) Projekt-Ansicht in Netbeans6.7

Abbildung 2.1: Vergleich der Projektansicht in BlueJ und der Netbeans Projekt-Ansicht.

Fokus auf die Benutzungsschnittstellen Heutzutage bieten viele Entwicklungsumgebun-gen eine Unterstützung zum einfachen Erstellen von Benutzungsschnittstellen. Dennoch erfor-dert es viel Zeit, eine Benutzungsschnittstelle mit einem Werkzeug zusammen zu klicken, wel-che in der Anwendungsentwicklung fehlen. Zudem wird Wissen vorausgesetzt, welches einePerson ohne Erfahrungen in der Programmierung nicht besitzt. In BlueJ können Methoden undKlassen interaktiv, also ohne Oberflächen-Klassen, verwendet und getestet werden. Dieser in-teraktive Umgang ermöglicht es, sich auf einzelne Klassen zu konzentrieren und nicht auf einevollständige Anwendung.

BlueJ wurde für die Lehre der objektorientierten Programmierung entwickelt und nicht für dieEntwicklung von größeren Anwendungen mit mehreren Paketen und diversen Klassen in jedemPaket. BlueJ sollte einfach zu bedienen sein und die lernende Person beim Lernen unterstüt-zen. Hierfür wurden in [KÖLLING und ROSENBERG 2001] acht Richtlinien für die Lehre derObjektorientierung in Java aufgestellt. Diese Richtlinien lauten:

• Objects first: Es sollen von Anfang an Objekte erzeugt und verwendet werden.

• Don’t start with a blank screen: Es soll mit kleinen Änderungen an bestehenden Syste-men angefangen werden.

• Read code: Es soll qualitativ hochwertiger Quelltext gelesen werden.

• Use “large“ projects: Die Projekte sollen nicht unnötig klein gehalten werden.

• Don’t start with “main“: Die main-Methode sollte erst eingebracht werden, wenn dienötigen Konzepte bekannt sind.

4

• Don’t use “Hello World“: Mit „Hello World“ zu beginnen widerspricht den vorangegan-gen Richtlinien und sollte vermieden werden.

• Show program structure: Die Beziehungen der einzelnen Elemente (z.B. Klassen) soll-ten dargestellt werden.

• Be careful with the user interface: Grafische und textbasierte Benutzungsschnittstellenzu implementieren erfordert ein Maß an Verständnis, über welches die Lernenden anfangsnoch nicht verfügen. Somit sollte nicht gefordert werden, frühzeitig eine Benutzungs-schnittstelle zu implementieren.

Diese Richtlinien beziehen sich nicht nur auf BlueJ als Entwicklungsumgebung, sondern auchauf den Kontext, für den BlueJ gedacht ist. In diesem Kontext werden bereits vorhandene Klas-sen zunächst benutzt, ehe die lernende Person selber eine Klasse in einem Editor erstellt. Einegenauere Betrachtung dieses Konzeptes erfolgt in Kapitel 3.

2.2 Geschichte von BlueJ

BlueJ wurde als Nachfolger für die integrierte Entwicklungsumgebung und objektorientierteProgrammiersprache Blue entwickelt. Die Blue Entwicklungsumgebung wurde 1996 für dieLehre an Universitäten vorgestellt [KÖLLING und ROSENBERG 1996]. Nachdem abzusehen war,dass Java in weiten Teilen der universitären Ausbildung Einzug halten wird, wurde Blue für dieLehre von Java in Java neu implementiert (BlueJ). Wie auch in der Blue-IDE war von Anfangan ein interaktiver Umgang mit Klassen und Objekten geplant.

In Blue und BlueJ ist es möglich, Beziehungen zwischen einzelnen Klassen direkt in der graphi-schen Darstellung zu bearbeiten. Es können sowohl Benutzt- als auch Verergungsbeziehungeninteraktiv zu dem Klassendiagramm hinzugefügt werden. Seit Version 1.0 wird der Quelltexteiner Klasse modifiziert, wenn in der Oberfläche eine Vererbungsbeziehung hinzugefügt wird.Das Klassendiagramm ist somit aktiv an der Modellierung des Diagramms beteiligt und stelltdieses nicht nur passiv dar.

„Objects First with Java:A Practical Introduction Using BlueJ“ [BARNES und KÖLLING 2006](erstmalig erschienen, 2003) ist das erste Lehrbuch, in dem erstmalig konsequent der Ansatz„Objects First“ verfolgt wird. Dieser Ansatz lässt sich Java erst dank BlueJ konsequent umset-zen.

Im August 2003 wurde die Erweiterungs-API hinzugefügt. Mit dieser API können Erweiterun-gen für BlueJ geschrieben werden, welche mit Objekten und Klassen interagieren können. Ex-emplare von Klassen können erzeugt und Methoden an Objekten in der Objektleiste aufgerufenwerden. Zudem kann mit dem Editor interagiert werden, z.B. ist eine Erweiterung entwickeltworden, welche den Quelltext innerhalb des Editors mit einem Quelltextformatierer formatiert.Eine weitere Erweiterung ermöglicht es, die öffentlichen Operationen einer Klasse in dem Klas-sendiagramm anzuzeigen.

5

Der Funktionsumfang von BlueJ wuchs im Laufe der Entwicklungszeit weiter an. Mit Version2.0 (16 September 2004) wurde die Direkteingabe hinzugefügt. Die Direkteingabe ermöglichteinen schnelles und probeweises Ausführen von Quelltextfragmenten, wie dies bereits aus Pro-grammiersprachen, die interpretiert oder zur Laufzeit kompiliert werden, bekannt ist. Die Dar-stellung des Klassendiagramms wurde in Richtung UML überarbeitet, wodurch sich BlueJ inder Oberfläche nun stärker von Blue unterscheidet.

Version 2.2.0 (6. Juli 2007) fügte einen Zugriff auf CVS basierte Repositories hinzu, welchesmit Version 2.5.0 um SVN erweitert wurde. Somit war BlueJ für größere Gruppen von Softwa-reentwicklerinnen und Softwareentwicklern nutzbar, da für den Austausch des Quelltextes nichtauf E-Mail oder andere Werkzeuge zurückgegriffen werden musste.

Inzwischen wird BlueJ an mehr als 900 Universitäten, Schulen und weiteren Einrichtungen welt-weit verwendet [BLUEJ PROJECT].

Am 04. März 2009 wurde BlueJ unter der freien [FREE SOFTWARE FOUNDATION] GPL mitClasspath Exception [GNU PROJECT] veröffentlicht, wodurch die Durchführung dieser Bache-lorarbeit stark vereinfacht wurde, da seit diesem Zeitpunkt Zugriff auf den Quelltext von BlueJbesteht.

2.3 Architektur von BlueJ

Die Beschreibung der Architektur von BlueJ wird hier nach einem Top-Down Ansatz vorge-nommen. Zunächst werden die Archive betrachtet, aus denen BlueJ, in binärer Form, besteht.Daraufhin wird ein Archiv genauer analysiert und die einzelnen Teilsysteme dargestellt. DieAnalyse wurde an BlueJ-2.5.1 vorgenommen, veröffentlicht am 30. April 2009.

BlueJ besteht aus mehreren Jar-Archiven. So liegen die Erweiterungs-API, der Editor und dieBoot-Klassen von BlueJ jeweils in einem eigenen Archiv. Die Archive werden im folgendenkurz vorgestellt, ehe das bluejcore.jar-Archiv genauer betrachtet wird.

2.3.1 Archiv-Struktur

bluejext Dieses Archiv verbindet BlueJ mit Erweiterungen, wie z.B. den „CNU BlueJ CodeFormatter “ 1. Über die Erweiterungs-API ist es möglich mit Klassen, Exemplaren und demEditor zu interagieren. Erweiterungen können Exemplare von Klassen erzeugen und Methodenan ihnen aufrufen.

bluejeditor Hierbei handelt es sich um den Editor von BlueJ. Dieser Editor basiert auf demunter einer MIT-Lizenz stehende jEdit-Syntax Paket 2.

1http://bluej.org/extensions/extensions.html2http://sourceforge.net/projects/jedit-syntax/

6

bluej Dieses Archiv enthält das Manifest und den Einstiegspunkt um BlueJ zu starten. BlueJkann über dieses Archiv gestartet werden, da in der Manifest-Datei dieses Archivs die die main-Methode enthaltende Klasse angegeben ist.

bluejcore In diesem Archiv sind die zentralen Komponenten von BlueJ zusammengefasst.Hier befinden sich die Benutzungsschnittstelle und der gesamte für die Interaktion mit BlueJverantwortliche Teil. Die in diesem Archiv vorhandenen Teilsysteme werden in dem nächstenAbschnitt der Architektur-Analyse betrachtet.

Die von BlueJ verwendeten Bibliotheken werden nicht weiter betrachtet. Die Abbildung 2.2stellt die Abhängigkeiten der einzelnen Archive von BlueJ sowie der verwendeten Bibliothekengrafisch dar. Die Analyse wurde mit dem JarAnalyzer 3 vorgenommen. Die Pfeile entsprechen indieser und den folgenden Abbildungen den ausgehenden Beziehungen (Benutzt- und Vererbung-Beziehungen). Da die Analyse anhand des Bytecodes vorgenommen wurde, werden Abhängig-keiten durch Reflection nicht aufgeführt. Somit fehlt eine Beziehung von dem bluej-Archiv zudem bluejcore-Archiv.

Abbildung 2.2: Abhängigkeiten der Jar-Archive von BlueJ sowie der verwendeten Bibliotheken

2.3.2 Teilsysteme des bluejcore-Archivs

Die Teilsysteme des bluejcore-Archivs befinden sich unterhalb des Wurzelpakets bluej in demPaket bluej.*. Die einzige Ausnahme dieses Musters stellt das eingebettete jEdit-Syntax-Package dar.

Das BlueJ-Wurzelpaket enthält alle benötigten Klassen, um BlueJ zu starten. Lediglich der Boot-Vorgang wurde in das bluej-Archiv unter einem separaten Quelltext-Verzeichnis ausgegliedert.Die für den Bootvorgang verantwortlichen Klassen befinden sich ebenfalls in dem Wurzelpaket,jedoch nicht unter src sondern boot/src. Somit befindet sich die main-Methode, sowie dieSplash-Screens innerhalb des bluej-Archivs. Die sonstige Funktionaltität von BlueJ wurde in dieentsprechenden Teilsystem unterteilt und unterhalb des bluej-Pakets angeordnet und befindetsich im bluejcore.jar-Archiv.

3http://www.kirkk.com/main/Main/JarAnalyzer

7

Das bluejcore-Archiv gliedert sich in folgende Teilsysteme:

bluej.utility

bluej.parser

bluej.extmgr

bluej.groupmgr

bluej.classmgr

bluej.compiler

bluej.terminal

bluej.prefmgr

bluej.testmgr

bluej.debugmgr

bluej.debugger

bluej.runtime (Startet eine separate Java-VM in der die interaktiv ausführten Aktionen aus-geführt werden)

bluej.views (Stellt eine Repräsentation von Java-Klassen für die Objektleiste und Erweiterungs-Klassen bereit.)

bluej.graph

8

bluej.pkgmgr (Verwaltet ein Projekt in BlueJ)

Eine ausführlichere Betrachtung der Teilsystem des bluejcore-Archivs befindet sich im AnhangA.1.

Die Architektur von BlueJ ähnelt einer Subsystemearchitektur [LILIENTHAL 2008]. Jedoch wer-den die Schnittstellen der Teilsysteme nicht konsequent genug festlegt.

Ein Subsystem bietet ein Schnittstelle für Klienten an. In BlueJ hingegen bietet nicht das Teil-system eine Schnittstelle an, sondern die jeweiligen Pakete des Teilsystems. Das Teilsystempkgmgr z.B. unterteilt sich in mehrere Pakete, welche jeweils eine eigenen Schnittstellen nachaußen anbieten.

Zudem sind keine Beschränkungen der Beziehungen zwischen den Teilsystemen erkennbar. Diesführte zu mehreren zyklischen Abhängigkeiten (z.B. zwischen den Teilsystemen pkgmgr undgraph) und zu einer starken Vermaschung der Teilsysteme untereinander (zu sehen in Abbildung2.3).

9

Abbildung 2.3: Die einzelnen Komponenten von des bluejcore Archivs, sowie ihre Beziehungenzueinander

10

3 Konsumieren und Produzieren

Die Metaphern „Konsumieren“ und „Produzieren“ stehen für einen Ansatz, Objekte im Sinneder Objektorientierung, aber auch Konzepte im Allgemeinen aus zwei unterschiedlichen Per-spektiven zu betrachten.

Beispiel 1 Ein Objekt, wie z.B. Kraftfahrzeug (KFZ) wird im Sinne der Metaphern kon-sumiert, indem es benutzt wird. Es bietet eine Schnittstelle, bestehend aus Pedalen, Lenk-rad, Signalleuchten etc, welche benötigt wird, damit eine Person das Objekt benutzenkann.Ein KFZ zu produzieren erfordert eine andere Betrachtung, als es zu benutzen. Es müssenz.B. die einzelnen Bauteile in der richtigen Reihenfolge zusammengesetzt werden.Wartungsarbeiten fallen ebenfalls in die Produzieren-Perspektive, da diese TätigkeitenKenntnisse über die Zusammensetzung des Objektes erfordern. Eine Fahrzeugführerinoder ein Fahrzeugführer, ohne weitere Kenntnisse über die technischen Zusammenhängedes Fahrzeugs, ist nicht im Stande Wartungsarbeiten daran vorzunehmen. Ein Fahrzeugzu fahren erfordert weniger Kenntnisse über die Beschaffenheit des Fahrzeuges, als dieseszu warten.Es ist einfacher, ein KFZ zu konsumieren, als zu produzieren.

Wie in dem gegebenen Beispiel , lassen sich Objekte einfacher konsumieren, als produzieren.Dies gilt nicht nur für physikalische Objekte, sondern auch für Konzepte, wie z.B. Listen.

3.1 Herkunft der Metaphern

Die Metaphern „Konsumieren“ und „Produzieren“ wurden am Arbeitsbereich Softwaretechnikam Department Informatik der Universität Hamburg geprägt. Sie wurden in [SCHMOLITZKY 2005,SCHMOLITZKY 2006] im Rahmen des Lehrkonzeptes „Konsumieren vor Produzieren“ vorge-stellt.

„Konsumieren vor Produzieren“ stellt die teilweise Betrachtung (benutzend/konsumierend) vordie vollständige Betrachtung (umsetzend/produzierend) von Konzepten.

11

Beispiel 2 Lernende Personen sollen zunächst ein Konzept, wie z.B. eine Liste, benutzen,ehe sie selber eine Liste implementieren. Eine Liste kann als eine geordnete Sammlungbenutzt werden, die eine lernende Person als Blackbox betrachtet. Es können Elemente zuder Liste hinzugefügt und entfernt werden. Zudem kann abgefragt werden, welche Ele-mente sich in der Liste befinden oder ob ein bestimmtes Element in der Liste vorhandenist. Ob es sich bei einer Liste um eine verkettete Liste handelt, oder diese als ein wachsen-des Array implementiert ist, ist zu dem Zeitpunkt, in dem eine Liste erstmals verwendetwird, nicht von Bedeutung und kann ignoriert werden.Eine Liste wird erst implementiert, wenn eine lernende Person die hierfür benötigtenGrundlagen kennt. Wenn eine verkettete Liste implementiert werden soll, muss der Ent-wicklerin oder dem Entwickler bekannt sein, wie Objekte untereinander referenziert wer-den. Ein wachsendes Array erfordert zudem, dass das Konzept eines Arrays bekannt istund dass Arrays eine konstante Größe besitzen, also nur eine begrenzte Anzahl an Ele-menten aufnehmen können.

Abbildung 3.1: Konzept-Diagramm einer Liste mit zwei konkreten Implementationen und einemKlienten

Die Metapher erlaubt es, zyklische Abhängigkeiten zwischen Konzepten aufzubrechen. So kannin der Lehre der Objektorientierung bereits mit Objekten gearbeitet werden, ehe die LernendenPersonen eine Klasse schreiben müssen, da die bereits vorhandenen Klassen nur konsumiertwerden.

Diese Metapher bietet sich gerade für die Lehre der objektorientierten Programmierung in Ein-führungsveranstaltungen an, da zyklische Abhängigkeiten, wie z.B. zwischen Klassen und Quell-text, aufgebrochen werden können.

In dem Positionspaper [SPÄH und SCHMOLITZKY 2007] wird die Metapher ausführlicher erläu-tert.

Die bis dahin zusammenhängende Metapher wurde in [SPÄH 2008] in die unterschiedlichenMetaphern „Konsumieren“ und „Produzieren“ zerlegt. Die dabei entwickelte Software (jMango)ist in der Lage die unterschiedlichen Sichtweisen zu visualisieren.

Ein Konzept besitzt in jMango zwei Ansichten, eine konsumierende und eine produzierendeAnsicht. Diese Ansichten können interaktiv gewechselt werden, wodurch die Visualisierung der

12

Abhängigkeiten ebenfalls angepasst wird.

3.2 Konsumieren und Produzieren in der objektorientiertenProgrammierung

In der objektorientierten Programmierung können Klassen konsumiert und produziert werden.Eine Klasse zu produzieren bedeutet, den Quelltext einer Klasse z.B. mit einem Editor zu erstel-len oder zu bearbeiten. Bei Wartungsarbeiten an einer Klasse wird ihr Quelltext verändert. Umeine Klasse zu produzieren ist es meist notwendig die gesamte Klasse zu verstehen.

Um eine Klasse zu konsumieren, muss die Schnittstelle der Klasse benutzt werden. Die Schnitt-stelle bietet die einzige Möglichkeit, eine Klasse zu benutzen. Hierfür müssen Abhängigkeiten(Definition 1) mit betrachtet werden, damit die Schnittstelle verwendet werden kann.

Definition 1 (Schnittstellenabhängigkeiten einer Klasse). Die Menge aller in der Schnittstelleeiner Klasse genannten Typen bilden die Schnittstellenabhängigkeiten. Sie setzt sich aus derSumme aller öffentlichen Felder, sowie der Schnittstellenabhängigkeiten der Super-Klasse undder Schnittstellenabhängigkeiten aller öffentlichen Operationen zusammen (siehe Definition 2).

Die Schnittstellenabhängigkeiten einer Klasse bieten Hinweise auf möglicherweise von einemKlienten zu benutzende Klassen. Die in dem fachlichen Beispiel 3 gegebene Schnittstellenab-hängigkeit von der Klasse LinkedTitelListe zu der Klasse Titel weist lediglich darauf hin,dass ein Klient der Liste möglicherweise die Klasse Titel benutzen muss. Wenn bei einer Listenur die Anzahl der gespeicherten Titel abgefragt werden muss, muss die Abhängigkeit zu derTitel-Klasse nicht betrachtet werden.

Beispiel 3 Ein Projekt mit verkettete Liste von Titeln besteht aus den drei KlassenLinkedTitelListe, Titel und DoppellinkKnoten. Es gibt zwei Schnittstellenabhän-gigkeiten zu der Klasse Titel. Diese Schnittstellenabhängigkeiten gehen von den Klas-sen LinkedTitelListe und DoppellinkKnoten aus. Es besteht eine weitere Abhän-gigkeit von der Klasse LinkedTitelListe zu dem DoppellinkKnoten. Eine graphi-sche Darstellung dieses Beispiels findet sich in Abbildung 3.2.

Wenn eine Operation der Liste benutzt wird, die eine Schnittstellenabhängigkeit (Definition 2)zu der Klasse Titel besitzt, dann muss diese Abhängigkeit mit benutzt werden. Wenn der ab-hängige Typ nicht benutzt wird, ist es nicht möglich, diese Operation zu benutzen. Wenn bei derListe eine Operation fuegeElementHinzu(Titel) aufgerufen werden soll, ist es notwendigein Exemplar der Klasse Titel als Parameter zu übergeben 1. Somit bieten Schnittstellenabhän-gigkeiten einer Klasse nur Hinweise auf womöglich von einem Klienten zu benutzende Klassen,während die Schnittstellenabhängigkeiten einer Operation immer mit betrachtet werden müs-sen.

1Auch wenn in Java null an Stelle jedes Referenztypen übergeben werden kann, wird dieses in diesem Kontextnicht weiter betrachtet.

13

Abbildung 3.2: Darstellung der Abhängigkeiten der LinkedTitelListe

Definition 2 (Schnittstellenabhängigkeiten einer Operation). Die Schnittstellenabhängigkeiteneiner Operation sind alle Typen, welche ein Klient kennen muss, um diese Operation zu benutzen.

Nicht alle Abhängigkeiten einer Klasse lassen sich auf die Schnittstelle zurückführen. Die inBeispiel 3 vorhandene Abhängigkeit der LinkedTitelListe zu dem Doppellinkknoten istkeine Schnittstellenabhängigkeit. Die Abhängigkeit ist Teil der Implementation der Linked-TitelListe und ist somit eine Implementationsabhängigkeit (Definition 3). Die Implemen-tationsabhängigkeiten einer Klasse wiesen auf Implementationsdetails hin und sind für einenKlienten nicht von Bedeutung2.

Definition 3 (Implementationsabhängigkeiten einer Klasse). Alle Typen, die in der Implemen-tation einer Klasse genannt werden, sind die Implementationsabhängigkeiten. Sie setzt sich ausallen verwendeten Klassen (Exemplar-Variablen, Parameter und Ergebnistypen von Hilfsmetho-den, Klassen lokaler Variablen, Schnittstellenabhängigkeiten) zusammen.

In der Implementation einer Klasse werden häufig mehr Klassen benutzt, als in der Dokumen-tation erscheinen. Wenn alle Abhängigkeiten in der Schnittstellendokumentation zu sehen sind,werden unnötig viele Informationen angezeigt, welche einen Klienten verwirren können. Zu-dem widerspricht es dem Geheimnisprinzip, da Teile des inneren Aufbaus nach außen gegebenwerden.

Da alle Schnittstellenabhängigkeiten auch Implementationsabhängigkeiten sind, ist die Mengeder Schnittstellenabhängigkeiten eine Teilmenge (jedoch keine echte Teilmenge) der Implemen-tationsabhängigkeiten.

2Implementationsdetails, wie z.B. die Aufwandsklasse, oder ob eine Überprüfung anhand von Gleichheit oder Iden-tität vorgenommen wird, müssen an der Schnittstelle dokumentiert werden. Die konkrete Umsetzung muss einemKlienten nicht sichtbar gemacht werden.

14

Datentypen ohne eigene Implementation Da Datentypen ohne eigene Implementation(z.B. ein Interface) keine Implementation bereitstellen, gibt es keine Implementationsabhän-gigkeiten. Die Implementation eines solchen Datentypen erfolgt grundsätzlich in einer anderenKlassen, welche diese Typen implementiert.

15

16

4 Konsumieren und Produzieren in BlueJ

In diesem Kapitel wird zunächst dargestellt, inwieweit die Metaphern „Konsumieren“ und „Pro-duzieren“ in BlueJ bereits unterstützt wird. Daraufhin werden Vorschläge unterbreitet, wie dieseUnterstützung fortgeführt werden kann. Die daraus entstehende Funktionalität wird entworfenund es wird auf speziell zu behandelnde Klassen eingegangen.

4.1 Derzeitiger Stand in BlueJ

Der Editor in BlueJ bietet zwei Sichtweisen auf eine Klassendefinition. Es kann zwischen derSchnittstellen-Dokumentation und dem Quelltext einer Klasse unterschieden werden. Die Do-kumentationsansicht zeigt die mit dem Werkzeug Javadoc generierte Dokumentation der Klasse(Abbildung 4.1 links).

Abbildung 4.1: Vergleich der Dokumentationsansicht (links) und Quelltextansicht (rechts) desEditors in BlueJ.

17

Die Dokumentationsansicht bietet einem Klienten eine aufgeräumte und einfach zu verstehen-de Darstellung der Schnittstelle einer Klasse. Es werden lediglich Informationen über Ope-rationen angezeigt, auf die ein Klient zugreifen kann. Alle nicht öffentlichen Hilfsmethodenund Exemplar-Variablen werden nicht dargestellt. Die konkrete Implementation wird verbor-gen. Diese Ansicht bietet somit keine Informationen über Operationen, die nicht von außerhalbbenutzt werden können.

Ein Klient benötigt die Quelltextansicht nicht, um die dargestellte Klasse zu konsumieren. Wer-den hingegen Wartungsarbeiten an der Klasse vorgenommen, ist es notwendig die konkrete Im-plementation zu verstehen. Um einen Fehler zu beheben muss nicht nur die Ursache des Fehlersverstanden werden, sondern, um Seiteneffekte zu vermeiden, die gesamte Klasse.

Mit diesen beiden Ansichten unterstützt BlueJ bereits eine Unterscheidung zwischen Konsu-mieren und Produzieren einer Klasse. Konsumenten müssen den Quelltext nicht betrachten undkönnen die Dokumentationsansicht wählen, während Produzenten den Quelltext betrachten undverändern können.

Der interaktive Umgang mit Klassen in BlueJ ermöglicht es einer lernenden Person, diese zu-nächst zu benutzen, ehe die Person in der Lage sein muss, diese Klasse selber zu implementieren(produzieren). Es können bereits implementierte Klassen zunächst konsumiert werden, ehe dieQuelltextansicht der Klassendefinition geöffnet wird und die Umsetzung betrachtet und verän-dert werden kann. Klassen können somit zunächst konsumiert werden, ehe sie produziert wer-den. Dies ist ein Beispiel für die Anwendung der Metapher „Konsumieren vor Produzieren“.

4.2 Fortführung der bereits bestehenden Unterstützung

Den Unterschied zwischen der konsumierenden und produzierenden Sicht auf eine Klassedefi-nition unterstützt der Editor bereits. Das Klassendiagramm hingegen stellt statisch die produzie-rende Sicht auf die Klassen dar, denn es werden grundsätzlich alle Abhängigkeiten zu anderenKlassen dargestellt. Die Abbildung 4.2 zeigt solch eine Klassendiagramm mit einer verkettetenListe von Titeln (Beispiel 3 mit Abbildung 3.2 aus dem vorherigen Kapitel).

Abbildung 4.2: Darstellung der Abhängigkeiten der LinkedTitelListe

18

4.2.1 Zwei Sichten auf eine Klasse in einem Klassendiagramm

Die LinkedTitelListe benutzt sowohl die Klasse Titel, als auch die Klasse Doppellink-

Knoten. Da es sich um eine Liste von Titeln handelt, muss die Abhängigkeit von der KlasseTitel zu den Schnittstellenabhängigkeiten gehören. Gäbe es keine Schnittstellenabhängigkeitzu der Klasse Titel, wäre es nicht möglich, einen Titel zu der Liste hinzuzufügen.

Die Abhängigkeit zu der Klasse DoppellinkKnoten ist nicht Teil der Schnittstellenabhängig-keiten und stellt ein Implementationsdetail dar. Dieses Implementationsdetail ist für einen Kli-enten nicht relevant und wird für die konsumierende Sicht auf die Klasse LinkedTitelListe

nicht benötigt.

Eine Darstellung der konsumierenden Sicht auf die LinkedTitelListe zeigt lediglich die Ab-hängigkeiten, die auf die Schnittstelle der Klasse LinkedTitelListe zurückzuführen sind. DieListe besitzt nur die Schnittstellenabhängigkeit zu der Titel-Klasse. Diese eine Schnittstellen-abhängigkeit muss in der konsumierenden Sicht dargestellt werden. Diese Sicht auf die KlasseLinkedTitelListe ist in Abbildung 4.3 zu sehen.

Abbildung 4.3: Darstellung der Schnittstellenabhängigkeiten der LinkedTitelListe

Da die konsumierende Sicht auf eine Klasse nur ihre Schnittstellenabhängigkeiten beinhaltet,wird diese Darstellung Schnittstellenansicht einer Klasse genannt.

Um Wartungsarbeiten vornehmen zu können, bietet es sich an, die Implementationsabhängig-keiten zu betrachten. Diese werden in der Implementationsansicht dargestellt.

Es gibt zwei Darstellungen einer Klasse, die Schnittstellenansicht und die Implementationsan-sicht. Daraus folgt, dass es nicht nur ein Klassendiagramm gibt, sondern eine von der Anzahlder vorhandenen Klassen abhängige Vielzahl von Klassendiagrammen. Da jede Klasse auf zweiArten dargestellt werden kann, gibt es potentiell 2n (mit n = Anzahl der Klassen) Klassendia-gramme. Das gerade angezeigte Klassendiagramm wird das momentane Klassendiagramm ge-nannt.

19

4.2.2 Ausblenden nicht benötigter Klassen

In der Schnittstellenansicht der Klasse LinkedTitelListe besteht keine Abhängigkeit zu derKlasse DoppellinkKnoten, da diese Abhängigkeit auf der Implementation und nicht der Schnitt-stelle der Klasse LinkedTitelListe basiert. Die Klasse DoppellinkKnoten ist für einen Kli-enten der LinkedTitelListe nicht relevant und stellt ein Implementationsdetail dar.

Implementationsdetails zu verbergen ist eines der grundlegenden Ziele des Geheimnisprinzips.Nicht alle Implementationsdetails einer Klasse sind auch direkt ein Teil dieser Klasse. Wie indem Beispiel mit der Klasse LinkedTitelListe sind die verketteten Knoten aus dieser Klasseausgelagert worden. Dennoch stellt die Klasse DoppellinkKnoten nur ein Implementationsde-tail dar und ist für einen Klienten der Klasse LinkedTitelListe nicht relevant. Da die KlasseDoppellinkKnoten nur für die Implementation der Klasse LinkedTitelListe benötigt wird,kann diese Klasse in der Schnittstellenansicht der Klasse LinkedTitelListe verborgen wer-den. Dies ist in Abbildung 4.4 zu sehen.

Abbildung 4.4: Darstellung der Schnittstellenabhängigkeiten der LinkedTitelListe mit derverborgenen Klasse DoppellinkKnoten

Wenn nicht benötigte Klassen verborgen werden sollen, stellt sich die Frage, nach welchen Kri-terien entschieden wird, welche Klassen anzuzeigen und welche Klasse zu verbergen sind.

Eine Klasse kann nur dann verborgen werden, wenn in dem momentanen Klassendiagrammkeine eingehende Beziehung zu dieser Klasse zu sehen ist. Wird eine Klasse von mehr als einemKlienten benutzt, so muss sie angezeigt werden, wenn mindestens eine eingehende Beziehungzu sehen ist. Die Abbildung 4.5 zeigt ein Projekt mit zwei Klienten und einem Dienstleister.

Wenn also zwei Klienten (K1 und K2) einer Klasse D diese Klasse nur in ihrer Implementation be-nutzten und sowohl K1 als auch K2 in der Schnittstellenansicht sind, werden keine Beziehungenzu der Klasse D angezeigt. Also kann die Klasse D verborgen werden.

Ist die Klasse K1 in der Implementationsansicht und die Klasse K2 in der Schnittstellenansicht,so ist in dem momentanen Klassendiagramm eine eingehende Benutzt-Beziehung zu der KlasseD zu sehen. Die Klasse D muss somit angezeigt werden.

20

Abbildung 4.5: Ein Dienstleister mit mehreren Klienten

Die ausgehenden Beziehungen von der Klasse D wirken sich nicht bezüglich der Nicht-Sichtbar-keit der Klasse D aus. Auch wenn die Klasse D ausgehende Beziehung zu einer weiteren Klasse Ehat, wird die Klasse D verborgen. Die Klassen, zu denen die Klasse D eine ausgehende Beziehunghat, werden separat betrachtet. Wenn also eine Klasse E nur von der Klasse D benutzt wird, kanndiese mit der Klasse D zusammen verborgen werden.

4.2.3 Festlegen des Einstiegspunkts in das Klassendiagramm

Es muss bestimmt werden, von welchen Klassen aus die ausgehenden Abhängigkeiten die sicht-baren und nicht sichtbaren Klassen bestimmen. Versetzt die Benutzerin oder der Benutzer einebereits sichtbare Klasse in die Implementationsansicht, werden zusätzliche Implementationsab-hängigkeiten sichtbar. Wird eine sichtbare Klasse in die Implementationsansicht versetzt, wer-den weitere Klassen sichtbar. Das Klassendiagramm lässt sich wie eine Straßenkarte „auffal-ten“.

Um das Klassendiagramm nach und nach auffalten zu können, müssen vorher die Einstiegspunk-te in das Diagramm bestimmt werden. In Java ließen sich alle Klassen mit einer main-Methodeals Einstiegspunkte festlegen, da diese Methode der Einstiegspunkt der VM ist und eine Java-Anwendung über diese Methode gestartet wird.

Ein Paket bietet ebenfalls eine Schnittstelle. Diese Schnittstelle besteht aus allen öffentlichenKlassen eines Pakets. Nur die öffentlichen (in Java anhand des Schlüsselwortes public zu er-kennen) Klassen können außerhalb eines Pakets benutzt werden, womit diese einen Einstiegs-punkt in das Paket darstellen.

Somit stellen alle öffentlichen Klassen eines Paket ebenfalls einen Einstiegspunkt dar und kön-nen grundsätzlich angezeigt werden.

4.2.4 Implementationsansicht eines Interfaces

Interfaces bieten selber keine Implementation an, wodurch sie über keine Implementationsab-hängigkeiten verfügen. Die Implementation eines Interfaces erfolgt in Subtypen, welche das

21

Interfaces implementieren. In der Implementationsansicht eines Interfaces werden somit die im-plementierenden Klassen angezeigt.

Wird ein Interface in die Implementationsansicht versetzt, ist es für Klienten dieses Interfaceswichtig zu wissen, welche konkreten Klassen dieses Interface implementieren. Da nur die kon-krete Implementation eines Interfaces von Bedeutung ist, können sowohl die Implementationender implementierenden Klassen, als auch ihre Schnittstellen verborgen werden. Die implemen-tierten Klassen können als „zusammengefaltet“ verstanden werden.

4.2.5 �Falten� von Klassen

Um das Klassendiagramm weiter zu verkleinern, können Klassen „gefaltet“ werden. Eine ge-faltete Klasse besäße in dem Klassendiagramm keine ausgehenden Beziehungen zu anderenKlassen. Hiermit ließe sich die Komplexität des Diagramms weiter reduzieren.

Das Falten von Klassen stellt eine dritte Perspektive auf Klassen dar. Eine gefaltete Klasse zeigtnur ihren Namen und nicht ihre Schnittstelle oder Implementation.

4.2.6 Schnittstellen- und Implementationsansicht in BlueJ

Die bisher vorgestellte Fortführung der Unterstützung für die Unterschiede zwischen der konsu-mierenden und produzierenden Ansicht lässt sich grundsätzlich auf Klassendiagramme übertra-gen. In BlueJ gelten hingegen Einschränkungen, die nicht auf alle Klassendiagramme übertragenwerden können. Diese Einschränkungen und daraus folgende Schlussfolgerungen für die unter-schiedlichen Ansichten werden im Folgenden betrachtet.

Momentanes Klassendiagramm in BlueJ

In BlueJ werden Klassendiagramm nicht nur betrachtet, sondern, es wird auch mit ihnen inter-agiert. Es kann ein Exemplar von einer Klasse erzeugt werden, indem der Konstruktor dieserKlasse aufgerufen wird.

Da eine Klasse im Laufe der Entwicklung sowohl benutzt, als auch verändert werden kann, ist esnotwendig, die Ansicht einer Klasse dynamisch wechseln zu können. Das Klassendiagramm istnicht statisch, sondern kann durch Wechseln der Ansichten auf eine Klasse dynamisch verändertwerden.

Dies erzwingt eine Möglichkeit, mit der die Ansicht einer Klasse im laufenden Betrieb vonBlueJ verändert werden kann. Es muss also möglich sein, die Ansicht einer Klasse von derSchnittstellen- in die Implementationsansicht zu versetzen (und wieder zurück), woraufhin alleAbhängigkeiten dieser Klasse angezeigt werden müssen.

22

Einstiegspunkte in BlueJ

In BlueJ ist es nicht nötig, eine main-Methode zu definieren. Die meisten Projekte für BlueJenthalten keine main-Methode und werden interaktiv von der Benutzerin oder dem Benutzerausgeführt.

Viele Projekte besitzen eine Klasse, von der aus die Benutzerinnen und Benutzer das Projektstarten können. Diese Klassen besitzen für gewöhnlich keine eingehenden Abhängigkeiten, dasie von keiner anderen Klasse, sondern den interaktiv benutzt werden sollen. Genau diese Klassestellt einen Einstiegspunkt in das Projekte dar. Wenn das Projekt verstanden werden soll, bietetes sich an, bei dieser Klasse zu beginnen. Wenn diese Klasse keine Schnittstellenabhängigkeitenbesitzt und sie nach Öffnen des Projektes in der Schnittstellenansicht ist, besteht das momen-tane Klassendiagramm nur aus dieser Klasse. Von dieser Klasse aus kann das Projekt weiteraufgefaltet werden und so werden alle Klassen des Projektes nach und nach sichtbar.

Wenn gar nicht benutzte Klassen immer angezeigt werden, kann nicht nur der Einstiegspunktin das Projekt erkannt werden. Es ist zudem möglich eine noch nicht benutzte Klasse in demKlassendiagramm zu sehen.

Eine neu erstellte Klasse wäre mit ihren Abhängigkeiten sichtbar und kann zu einem späterenZeitpunkt betrachtet werden. Erst wenn diese Klasse von einer anderen Klasse benutzt wird,kann sie in dem Klassendiagramm verborgen werden.

4.2.7 Kriterien nach denen Klassen in BlueJ angezeigt werden

Insgesamt wurden folgende Kriterien festgelegt, nach denen eine Klasse in dem momentanenKlassendiagramm angezeigt wird:

Die Klasse

1. wird gar nicht benutzt

2. besitzt in dem momentanen Klassendiagramm eingehende Abhängigkeiten

3. ist public

4. enhält eine main-Methode

Es werden somit nur Klassen verborgen, die (1) benutzt werden und (2) keine eingehende Ab-hängigkeiten in dem momentanen Klassendiagramm besitzen.

Die Umsetzung der hier vorgestellten Fortführung der Unterstützung der Metaphern führte zuder Implementation von BlueJ Consuming/Producing (CP).

Wenn in dem Klassendiagramm zwischen den einzelnen Ansichten unterschieden werden kann,muss die momentane Ansicht einer Klasse am Symbol dieser Klasse direkt erkennbar sein. Inden folgenden Abschnitten werden die für den Wechsel notwendig Interaktionen, sowie ver-schiedene Ansätze, die Schnittstellen- und Implementationsansicht darzustellen, diskutiert.

23

4.3 Entwurf der Benutzungsschnittstelle

BlueJ bietet bereits eine Vielfalt an Interaktionsmöglichkeiten für die Benutzerinner und Benut-zer. Es können interaktiv Exemplare von Klassen erzeugt und Methoden an ihnen aufgerufenwerden.

Zwischen der Schnittstellen- und Implementationsansicht zu wechseln, erfordert weitere Inter-aktionsmöglichkeiten, die zu den bereits bestehenden Möglichkeiten hinzugefügt werden müs-sen. Diese zusätzlichen Möglichkeiten dürfen jedoch nicht den in BlueJ vorhandenen Interak-tionen widersprechen, oder einschränken. z.B. ist BlueJ auf jeder Plattform auf der ein JavaDevelopment Kit (JDK) vorhanden ist, lauffähig und dies muss auch für BlueJ-CP gelten.

Zu diesen die Möglichkeiten für zusätzliche Interaktionen einschränkenden Kriterien geltennoch weitere Kriterien, nach denen eine Software betrachtet und bewertet werden kann.

4.3.1 Kriterien für interaktive Systeme

Es gibt verschiedene Kriteriensysteme, nach denen ein interaktives System bewertet werdenkann. Ein solches System bietet das IFIP-Modell [HERCZEG 2009]. In diesem Modell wird dieBenutzungsschnittstelle einer Software in drei Schnittstellen unterteilt. Diese lauten:

• Werkzeugschnittstelle

• Dialogschnittstelle

• Ein-/Ausgabeschnittstelle

Jeder dieser Schnittstellen werden weitere Kriterien zugeordnet. Das daraus entstehende Krite-riensystem ermöglicht eine Untersuchung und Bewertung einzelner Aspekte einer Software.

Im Folgenden werden einzelne Kriterien der im IFIP-Modell beschriebenen Dialog- und Ein-/Ausgabeschnittstelle in Bezug auf die in BlueJ-CP neu hinzukommenden Schnittstellen- undImplementationsansicht betrachtet und erläutert.

Dialogkriterien

Es werden ausschließlich die Dialogkriterien, Selbstbeschreibungsfähigkeit, Erwartungskonfor-mität und Steuerbarkeit erläutert.

Selbstbeschreibungsfähigkeit Die Ansichten und auch die Interaktion mit den Klassen soll-ten so weit möglich, keine oder nur eine kurze Einführungsphase benötigen. Es kann nicht davonausgegangen werden, dass eine Benutzerin oder ein Benutzer zunächst eine mehrtägige Schu-lung besuchen muss, ehe diese Person mit BlueJ-CP arbeiten kann

24

Erwartungskonformität Die hinzugefügten Ansichten der Klassen dürfen nicht im Wider-spruch zu bereits bestehende Darstellungen in BlueJ stehen.

Steuerbarkeit Die Benutzerin oder der Benutzer steuert den Wechsel der Ansichten und nichtBlueJ-CP.

Ein-/Ausgabekriterien

Aus den Ein-/Ausgabekriterien werden die folgenden Kriterien für den Entwurf der Schnittstellen-und Implementationsansicht, sowie der Interaktion zum Wechseln der Ansicht erläutert.

Wahrnehmbarkeit Es muss möglich sein, innerhalb kurzer Zeit zu erkennen, welche Klas-se in welcher Ansicht dargestellt wird. Ebenso dürfen neu erschienene Klasse nicht übersehenwerden.

Unterscheidbarkeit Die Schnittstellen- und Implementationsabhängigkeiten müssen leichtzu Unterscheiden sein. Es darf zu keinen Verwechselungen zwischen den einzelnen Ansichtenkommen.

Handhabbarkeit BlueJ-CP darf den Benutzerinnen und Benutzern nicht im „Weg stehen“.Es darf nicht zugelassen werden, dass drei Menüebenen durchgearbeitet werden müssen, um dieAnsicht einer Klasse zu wechseln.

4.3.2 Interaktion in BlueJ-CP

Im Laufe der Entwicklung in einem Projekt muss die Ansicht einer Klasse mehrfach gewech-selt werden. Hierfür ist es notwendig, die Interaktion dahin gehend handhabbar zu gestalten,dass nicht zu viele Schritte notwendig sind. Es kann nicht als handhabbar angesehen werden,wenn zum Wechseln der Ansicht einer Klasse jedes mal auf die Menüleiste zugegriffen werdenmuss.

Das Kontextmenü einer Klasse in dem Klassendiagramm bietet hierfür eine bessere Position.Das Kontextmenü bietet nicht nur die Operationen, die die Klasse selber implementiert, son-dern auch auch Operationen, die für die Klasse in dem Diagramm gelten. So kann eine Klassegelöscht, bearbeitet oder übersetzt (kompiliert) werden.

Die Ansicht einer Klasse über das Kontextmenü zu wechseln erfordert einen weitaus geringerenAufwand, als über die Menüleiste. Eine noch weniger Aufwand erfordernde Möglichkeit, lässtsich ohne das Kontextmenü umsetzen.

25

Es kann eine kombinierte Eingabe von Tastatur und Maus eingeführt werden, in der der Maus-zeiger nur über der Klasse zu „schweben“ braucht, um dann die Ansicht mit dieser Kombinationzu wechseln. Hierbei ist jedoch zu bedenken, das BlueJ bereits solche Kombinationen verwendet(z.B. wird Strg+Klick benutzt um mehrere Klassen zu markieren).

Das Mausrad heutiger Computermäuse bietet nicht nur die Möglichkeit, auf und ab bewegt zuwerden, sondern fungiert häufig auch zweite als Maustaste. Auch wenn diese Funktionalitätnicht auf allen Plattformen verfügbar ist, bietet sie dennoch einen einfachen Weg, um die Ansichteiner Klasse zu wechseln.

Alle Klassen in einem Klassendiagramm über das Kontextmenü, oder die zweite Maustaste indie Schnittstellen- oder Implementationsansicht zu versetzen benötigt, abhängig von der Anzahlder Klassen in dem Diagramm einen linearen Aufwand.

Um diese Aktion einfacher zu gestalten, wurde das Kontextmenü des Projektes erweitert, damitalle in dem Diagramm vorhandenen Klassen in die Schnittstellen- oder Implementationsansichtzu versetzen. Wenn nur der Einstiegspunkt des Projekts zu sehen ist und alle Klassen in dieImplementationsansicht versetzt werden, werden alle Klassen und alle Abhängigkeiten in demDiagramm angezeigt. Es gibt in Bezug auf die Abhängigkeiten oder angezeigten Klassen keinenUnterschied zwischen dem momentanen und dem im unveränderten BlueJ angezeigten Klassen-diagramm.

Alle Klassen in die Schnittstellenansicht zu versetzen, hat den Effekt, dass daraufhin nur nochder Einstiegspunkt zu sehen ist 1.

4.4 Ansätze zur Darstellung der Schnittstellen- undImplementationsansicht

Es soll bereits anhand des Symbols einer Klasse erkannt werden, welche Ansicht auf diese Klas-se gerade in dem momentanen Klassendiagramm gewählt ist. Hierfür stehen unterschiedlicheAnsätze zur Verfügung. Diese Ansätze werden im Folgenden diskutiert.

4.4.1 Bereits bestehende Darstellung der Schnittstellen- undImplementationsansicht

Die Unterscheidung zwischen Schnittstellenansicht und Implementationsansicht wurde bereitsin jMango [SPÄH 2008] umgesetzt. Die Schnittstellenansicht einer Klasse wird als Rechteck mitabgerundeten Ecken und einer anderen Farbe als die Implementationsansicht dargestellt. DieImplementationsansicht besteht aus einem normalen Rechteck. Die unterschiedlichen Ansichtensind in Abbildung 4.6 zu sehen.

1Wenn das Projekt nach den vorher vorgestellten Kriterien mehrere Einstiegspunkte hat, werden auch diese ange-zeigt.

26

Abbildung 4.6: Schnittstellen- (links) und Implementationsansicht (rechts) in jMango

Im Gegensatz zu BlueJ ist jMango nicht UML-konform. Ein Rechteck mit abgerundeten Eckenstellt in UML ein Objekt dar.

Da BlueJ UML konform ist und einen interaktiven Umgang mit Klassen und Objekten bietet,werden Objekte in BlueJ entsprechend der UML Spezifikation dargestellt (Abbildung 4.7).

Abbildung 4.7: Ein Objekt in der BlueJ Objektleiste

Die Schnittstellenansicht einer Klasse darf nicht mit einem Objekt in der Objektleiste verwech-selt werden dürfen. Dies widerspräche der Erwartungskonformität, da ein Rechteck mit abge-rundeten Ecken ein Objekt darstellt.

Die unterschiedlichen Farben für die Schnittstellen- und Implementationsansicht können eben-falls mit einer Darstellung in dem Klassendiagramm in BlueJ verwechselt werden. BlueJ bietetdie Möglichkeit, für jeden Stereotypen (z.B. enum, Interface, Test) eine separate Farbe zu defi-nieren. Somit müsste darauf geachtet werden, dass die Farbe der Schnittstellenansicht nicht imKonflikt mit der Farbe eines Stereotypen liegt.

Zudem muss bedacht werden, dass nicht jede Person das gesamte Farbspektrum wahrnehmenkann. Insbesondere eine Rot-Grün-Schwäche, aber auch eine Gelb-Blau-Schwäche darf nichtdazu führen, dass es nicht möglich ist, zwischen der Schnittstellen- und Implementationsansichtzu unterscheiden.

Somit kann der in jMango gewählte Ansatz, die Schnittstellen- und Implementationsansicht dar-zustellen nicht auf BlueJ-CP übertragen werden.

4.4.2 Schnittstellenansicht in UML

UML bietet bereits eine Darstellung von Interfaces. In dieser Darstellung wird der Name desInterfaces kursiv (z.B. LinkedTitelListe) dargestellt [FOWLER und SCOTT 2000].

Da Interfaces in BlueJ über ihren Stereotypen als solche kenntlich gemacht werden, kann dieseDarstellung für die Schnittstellenansicht einer Klasse verwendet werden, ohne dabei im Konfliktmit der bereits bestehenden Darstellung für Interfaces zu stehen.

27

Der Unterschied zwischen normaler und kursiver Schrift ist für eine Klasse in einem Klassendia-gramm zu gering, um zwischen der Schnittstellen- und Implementationsansicht zu unterschei-den.

Da sich die Darstellung eines Interfaces in UML nur gering von der Darstellung einer Klasseunterscheidet, ist auch dieser Ansatz für die Schnittstellen- und Implementationsansicht unge-eignet.

4.4.3 Erster Entwurf der Schnittstellen- und Implementationsansicht

In der Implementationsansicht werden alle Abhängigkeiten einer Klasse angezeigt. Da dieseAbhängigkeit nicht aus der Schnittstelle, sondern aus der Implementation einer Klasse hervor-gehen, könnte die Implementationsansicht diese Betrachtung der Implementation einer Klassevisuell darstellen.

Hierfür ließe sich die Implementationsansicht dahingehend verändern, dass in dieser ein Quell-textschnipsel in dem unteren Bereich des Symbols einer Klasse angezeigt wird. Wenn der Quell-textschnipsel zusätzlich in einer anderen Farbe als das restliche Symbol für die Schnittstellenan-sicht hinterlegt ist, unterscheidet sich die Implementationsansicht noch stärker von der Schnitt-stellenansicht, als wenn der Quelltextschnipsel der einzige Unterschied wäre.

Die Schnittstelle einer Klasse bietet keinen direkten Zugriff auf die Implementation und könntewie eine verschlossene Box, die ihren Inhalt verbirgt, verstanden werden. Dies könnte mit der inBlueJ bereits verwendeten Darstellung visualisiert werden.

Die Abbildung 4.8 zeigt die Implementationsansicht (rechts) mit einem Quelltextschnipsel unddie aus BlueJ übernommene Darstellung als Schnittstellenansicht.

Abbildung 4.8: Schnittstellen- (links) und Implementationsansicht (rechts) mit Quelltextschnip-sel in der Implementationsansicht

In der durchgeführte Benutzerstudie wurde mehrfach angemerkt, dass sich die Schnittstellen-ansicht von der Implementationsansicht unterscheiden solle. BlueJ-CP verhielt sich somit nichterwartungskonform, da von den Probanden erwartet wurde, dass sich die Schnittstellenansichtvon der aus BlueJ bekannten Ansicht unterscheide. Zudem wurde von den Probanden angemerkt,dass sie sich einen umfangreicheren Quelltextschnipsel wünschten.

Aufgrund der negativen Rückmeldungen in der Benutzerstudie wurde dieser Ansatz verworfenund die Darstellung der Schnittstellen- und Implementationsansicht erneut überarbeitet.

28

Finaler Entwurf der Schnittstellen- und Implementationsansicht

In der Schnittstellenansicht werden die ausschließlich auf die Implementation zurückzuführen-den Abhängigkeiten verborgen. Dies ließe sich in der Darstellung der Schnittstellenansicht vi-sualisieren, indem der untere Teil der Klasse in dem Diagramm wie mit einem Blatt Papier„verdeckt“ wird.

Die Implementationsansicht würde unverändert von BlueJ übernommen. Die unterschiedlichenAnsichten sind in Abbildung 4.9 zu sehen.

Abbildung 4.9: Verbergen der Implementation in der Schnittstellenansicht (links)

Diese Darstellungen sind die finale Schnittstellen- und Implementationsansicht in BlueJ-CP.

4.5 Fixieren von Klassen

Kleine Projekte können durch Klassendiagramme verständlich dargestellt werden. Wenn dasKlassendiagramm jedoch zu groß wird, wird es unübersichtlich und es ist nicht länger einfach,den Beziehungen zwischen einzelnen Klassen zu folgen. Eine mögliche Lösung, das Problemder Unübersichtlichkeit von größeren Klassendiagrammen zu umgehen stellt das „fixieren“ vonKlassen dar.

4.5.1 Motivation

Wenn die Ansicht einer Klasse von der Schnittstellen- in die Implementationsansicht versetztwird, können mehrere, vorher nicht sichtbare Klassen erscheinen. Wenn von diesen neu erschie-nen Klassen nur eine einzige Klasse näher betrachtet werden soll, wirken sich die weiteren,vorher nicht sichtbaren Klassen möglicherweise störend aus. Diese Klassen verbergen zu kön-nen um nur die zu betrachtende Klasse zu sehen, reduziert die Größe des Klassendiagrammsund damit auch den Aufwand um das Klassendiagramm zu verstehen. Die Abbildung 4.10 zeigtein solches Klassendiagramm, in dem eine Klasse betrachtet werden soll (ZuBetrachtende-Klasse) und alle anderen Klassen bei der Betrachtung stören.

Wenn nur der Einstiegspunkt und die zu betrachtende Klasse zu sehen sind, ist das Klassendia-gramm kleiner und übersichtlicher (Abbildung 4.11). Es sind keine Klassen zu sehen, die dieÜbersichtlichkeit des Klassendiagramms verringern.

29

Abbildung 4.10: Die zu betrachtende Klasse ist nur sichtbar, wenn auch mehrere, nicht zu be-trachtende Klassen sichtbar sind

Abbildung 4.11: Die nicht benötigten Klassen werden nicht angezeigt.

Angenommen, es wäre möglich eine Klasse als verborgen zu markieren, damit diese nicht längerin dem Klassendiagramm zu sehen ist. Dann entstünde jedoch das Problem, dass diese Klasseu.U. wieder sichtbar gemacht werden muss. Es sind zudem mehrere Interaktionen mit dem Klas-sendiagramm notwendig wenn mehrere Klassen verborgen werden sollen.

Einfacher wäre ein Ansatz, der unabhängig von der Anzahl der zu verbergenden Klassen funk-tioniert. Ein Ansatz nach dem Motto „Du bleibst, der Rest kann weg“ wäre es, die zu betrach-tende Klasse zu „fixieren“ und alle Klassen in dem Diagramm in die Schnittstellenansicht zuversetzen.

In dem Beispiel (Abbildung 4.10 und 4.11) ist dieser Effekt zu sehen, da nur die Klasse ZuBe-

trachtendeKlasse, sowie die Klasse Einstiegspunkt und die Klasse BenutzendeKlasse

zu sehen sind.

30

Eine fixierte Klasse muss immer angezeigt werden, auch sie nach den zuvor festgelegten Krite-rien (Abschnitt 4.2) verborgen werden sollte. Damit eine fixierte Klasse nicht länger angezeigtwird, wenn sie nicht länger betrachtet wird, muss die Fixierung entfernt werden können.

Dies gibt den Benutzerinnen und Benutzern ein größeres Maß an Kontrolle über die Darstellungdes momentanen Klassendiagramms. Sie werden nicht von BlueJ-CP gezwungen ein unnötiggroßes Diagramm zu betrachten, sondern können es sich zusätzlich verkleinern. Es erhöht somitdie Steuerbarkeit von BlueJ-CP.

4.5.2 Darstellung einer �xierten Klasse

Eine fixierte Klasse kann durch einen „Magneten“ als fixiert kenntlich gemacht werden. DieserMagnet ließe sich an einer Kante oder Ecke der Klasse darstellen, jedoch ist dabei zu beachten,dass dieser Magnet nicht den Namen der Klasse verdeckt.

Somit bieten sich die Ecken einer Klasse innerhalb des Klassendiagramms an, auf eine fixiertenKlasse hinzuweisen. Der Magnet könnte an der oberen linken Ecke angebracht werden, womitdarauf hingewiesen wird, dass diese Klasse fixiert ist (Abbildung 4.12).

Abbildung 4.12: Eine an der oberen linken Ecke fixierte Klasse

Die unteren Ecken eignen sich nicht, um den Magneten anzubringen, da die untere rechte Eckebereits benutzt wird, um die Größe einer Klasse innerhalb des Klassendiagramms zu verän-dern.

Würde der Magnet an der oberen Kante angebracht werden, kann dieser den Stereotypen derfixierte Klasse verdecken, wodurch Informationen über den zu betrachtenden Klasse verlorengingen.

Somit ist eine der beiden oberen Ecken die beste Position, diesen Magneten darzustellen.

4.6 Ausnahmen bei den Kriterien zum Anzeigen vonKlassen

Die in Unterabschnitt 4.2.7 festgelegten Kriterien lassen sich nicht auf alle Klassen in einemDiagramm anwenden. Ein paar dieser Ausnahmen werden in den folgenden Unterabschnittenbetrachtet.

31

Test-Klassen

Jede public-Klasse wird in BlueJ-CP als Teil der Schnittstelle des Pakets betrachtet und grund-sätzlich angezeigt. Jedoch gibt es Klassen, welche öffentlich sind, dabei jedoch nicht über dieGrenzen des selben Pakets hinaus benutzt werden.

JUnit Test-Klassen z.B. müssen public sein, damit diese als Test-Klasse erkannt und die Testsdurchgeführt werden können. Da BlueJ JUnit unterstützt und Tests als ein Bestandteil des Klas-sendiagramms betrachtet werden, müssen Test-Klassen in BlueJ-CP separat betrachtet wer-den.

Die Test-Klassen werden in dem Klassendiagramm hinter der zu testenden Klasse angeordnetund in BlueJ-CP nur angezeigt, wenn die zu testende Klasse sichtbar ist. Wenn eine Test-Klassevon der zu testenden Klasse unabhängig ist, also nicht den Namen „[ZuTestendeKlasse]Test“hat, wird die Test-Klasse immer angezeigt. Somit ist es möglich, eine Test-Klasse als Einstiegs-punkt zu definieren und immer anzuzeigen, auch wenn die zu testende Klasse nicht sichtbarist.

Jede Test-Klasse benutzt die zu testenden Klasse, wodurch keine getestete Klasse unbenutzt istund somit nicht nach dem „gar nicht benutzt“ Kriterium (Kriterium 1 in Unterabschnitt 4.2.7)angezeigt werden müsste. Diese Benutzt-Beziehung darf nicht betrachtet werden, wenn eineKlasse aufgrund der sonstigen Nicht-Benutzung angezeigt würde. Sonst kann es passieren, dasseine interaktiv zu erzeugende und sonst unbenutzte Klassen nie angezeigt wird.

Gleichbehandlung von ö�entlichen und nicht ö�entlichen Klassen

Nach den zuvor vorgestellten Kriterien werden öffentliche Klassen immer angezeigt (Unterab-schnitt 4.2.7). Dieses Kriterium stößt z.B. in den Beispiel-Projekten aus „Objects First with Java“[BARNES und KÖLLING 2006] auf Probleme. Alle Top-Level-Klassen in diesen Projekten sindals public deklariert. Diese Klassen würden nach den bisherigen Kriterien immer angezeigtwerden.

Um zu verhindern, dass jede öffentliche Klasse angepasst werden muss, wenn BlueJ-CP aus-probiert wird, ist es möglich, das entsprechende Kriterium zu inaktivieren. Es bleibt den Benut-zerinnen und Benutzern überlassen, ob sie öffentliche Klassen immer angezeigt haben möchtenoder nicht. Wenn öffentliche Klassen nicht immer angezeigt werden sollen, werden sie genausobehandelt, wie nicht öffentliche Klassen. Eine öffentliche, und nur in der Implementation eineroder mehrere Klassen benutzte Klasse, wird nicht angezeigt, wenn alle Klassen in der Schnitt-stellenansicht sind.

32

4.7 Zusammenfassung

In diesem Kapitel wurde zunächst aus der Fortführung der in BlueJ bestehenden Unterscheidungzwischen der konsumierenden und produzierenden Sicht auf eine Klassendefinition erwachsendeFunktionalität entworfen.

Kriterien wurden festgelegt, nach denen eine Klasse in dem Diagramm sichtbar und nicht sicht-bar sein soll.

Unterschiedliche Darstellungsmöglichkeiten wurden diskutiert und die zum Wechseln benötigteFunktionalität wurde festgelegt.

Klassen in dem Diagramm zu fixieren unterstützt die Benutzerinnen und Benutzer dabei, denÜberblick in dem Klassendiagramm zu behalten, da unnötig angezeigte Klasse verborgen wer-den können.

Zuletzt wurden Spezialfälle betrachtet, bei denen die anfangs zum Anzeigen von Klassen fest-gelegten Kriterien nicht gelten, wie z.B. Testklassen, die immer öffentlich sein müssen.

Die Umsetzung des hier vorgenommenen Entwurfs der Funktionalität und Benutzungsschnitt-stelle beschreibt das folgende Kapitel.

33

34

5 BlueJ-CP

Der Anspruch dieses Kapitels ist, ein konzeptuellen Überblick zu verschaffen, mit denen dieEntwicklung von BlueJ-CP weitergeführt werden kann.

In der Entwicklung von BlueJ-CP wurden insgesamt 25 bereits in BlueJ existierende Klassenverändert und 26 hinzugefügt.

Die vorgenommenen Änderungen beschränken sich auf die folgenden Teilsysteme:

• editor

• extensions

• graph

• pkgmgr

• prefmgr

Bevor diese Änderungen vorgenommen wurden, mussten die entsprechenden Teilsysteme, Pake-te und Klassen bestimmt und verstanden werden, damit die vorgestellten Änderungen überhauptumgesetzt werden konnten.

Zudem wurden über Qualitätsanforderungen hinausgehende Anforderungen an den Quelltextgestellt. Die Modifikation musste nicht nur qualitativ hochwertig sein, sondern auch noch wei-teren Anforderungen gerecht werden.

5.1 Anforderungen an den Quelltext

Ein während der Entwicklung von BlueJ-CP angestrebtes Ziel war die Integration von BlueJ-CPin den Hauptentwicklungszweig von BlueJ. Da kein direkter Zugriff auf die Versionsverwaltungvon BlueJ besteht, wurde BlueJ-CP unabhängig von BlueJ entwickelt.

Da auch BlueJ während dieser Arbeit weiter entwickelt wurde und BlueJ-CP nicht von einerälteren Version von BlueJ abhängig sein soll, musste die Möglichkeit bestehen, die beiden Pro-jekte (BlueJ und BlueJ-CP) zu synchronisieren. Die Synchronisation von BlueJ-CP mit einerneueren Version von BlueJ wird in Abschnitt 5.3 beschrieben.

Um die Synchronisation der Projekte einfach zu gestalten, müssen die in BlueJ-CP vorgenom-menen Änderungen an dem Quelltext von BlueJ „minimal invasiv“ 1 gehalten werden.

1In diesem Fall lässt es als: „So gering wie möglich, so viel wie nötig“ interpretieren.

35

Jedes potentielle Refactoring muss genau überprüft werden, um die Anzahl an Konflikten zwi-schen den Änderungen zu BlueJ-CP und der neuen Version von BlueJ gering zu halten.

Ein weiteres Kriterium ist eine einfache Verbreitung von BlueJ-CP. Nicht jede Person bevorzugtdie Installation von binärer Software, sondern zieht es vor, die Software selber zu kompilieren.Zudem wäre eine Verbreitung in ausschließlich binärer Form ein Verstoß gegen die GPL mitClassPath Exception. Der vollständige Quelltext von BlueJ-CP muss demnach mit angebotenwerden.

Die Integration von BlueJ-CP in BlueJ war kein vorrangiges Ziel in der Entwicklung von BlueJ-CP. Es weist lediglich auf eine Einschränkung der Methodik hin, mit der der Quelltext von BlueJmodifiziert werden kann.

5.2 Umsetzung im Quelltext

Wie in 5.1 beschrieben, wurde in BlueJ-CP eine geringe Anzahl an Modifikationen in BlueJangestrebt.

In den folgenden Abschnitten wird die Umsetzung im Quelltextes beschrieben. Hierbei werdenlediglich größere Änderungen dargestellt. Kleine Änderungen, wie z.B. die Modifikation desQuelltextes, um die Abhängigkeiten einer Klasse erneut zu analysieren, oder ein Neuzeichnender Oberfläche nach einer Benutzerinteraktion, werden nicht weiter beschrieben.

5.2.1 Bestimmen der Schnittstellenabhängigkeiten

Um die Schnittstellenabhängigkeiten von den Implementationsabhängigkeiten zu unterschei-den, müssen die Schnittstellenabhängigkeiten zunächst bestimmt werden. Hierfür wurde dieErweiterungs-API benutzt, welche Zugriff auf alle Methoden, Klassen- und Exemplar-Variablensowie aller Konstruktoren bietet. Da die Exemplar-Variablen und Methoden Zugriff auf die ver-wendeten Zugriffsmodifikatoren bieten, ließ sich die Zugreifbarkeit bestimmen. Konstruktorenbieten in der Erweiterungs-API keinen Zugriff auf die Modifikatoren, was im Rahmen der Ent-wicklung von BlueJ-CP zu der entsprechenden Klasse (BConstructor) hinzugefügt wurde.

Die Klasse DependencyExtractor übernimmt eine Klasse (BClass aus der Erweiterungs-API)und extrahiert daraus die Schnittstellenabhängigkeiten.

Die Schnittstellenabhängigkeiten werden daraufhin in die in BlueJ übliche Repräsentation über-führt und an dem Exemplar der Klasse ClassTarget in einer von den Implementationsabhän-gigkeiten separaten Menge gespeichert. Schnittstellenabhängigkeiten werden nicht als Subtypmodelliert, da dann eine Anpassung der Vererbung-Beziehungen in BlueJ notwendig gewordenwäre, denn Supertypen sind ebenfalls Teil der Schnittstellenabhängigkeit.

36

5.2.2 Bestimmen der angezeigten Klassen

Zwischen der Repräsentation eines Pakets in BlueJ und der Darstellung an der Oberfläche wurdeein weiteres Teilsystem eingefügt, das Teilsystem dependencygraph.

Dieses Teilsystem übernimmt die in einem Paket vorhandenen Knoten und Kanten des Klas-sendiagramms und überträgt diese in eine eigene, interne Repräsentation. Mit dieser internenRepräsentation ist es möglich, das Klassendiagramm als Graphen zu behandeln und über einemodifizierte 2 „Copying Garbage Collection“ [JONES und LINS 1996] zu bestimmen, welcheKlassen und Abhängigkeiten in dem Diagramm angezeigt werden sollen. Zusätzlich reduziertdie in dem Teilsystem dependencygraph gewählte interne Repräsentation von Knoten und Kan-ten die Kopplung zu dem Teilsystem pkgmgr und ermöglicht einfach zu testende Einheiten. DieAnbindung des Teilsystems dependencygraph an das Teilsystem pkgmgr ist in der Abbildung5.1 zu sehen.

Abbildung 5.1: Darstellung der Beziehungen zwischen den Teilsystemen dependencygraph

und pkgmgr

Die separate Modellierung des Graphen dient sowohl der Entkopplung des Teilsystems depen-dencygraph, als auch einfacheren Implementation der Garbage Collection. In BlueJ wird einGraph nach der mathematischen Sichtweise als Menge von Kanten und Knoten repräsentiert.Diese Modellierung eignet sich zwar, für die Darstellung des Klassendiagramms, bietet jedochkeinen einfachen Zugriff auf in BlueJ-CP benötigte Informationen.

2Es werden hierbei nicht zwei Speicherbereiche reserviert, sondern zwei unterschiedliche Abbildungen von Knotenauf Kanten.

37

In einer Garbage Collection, welche für jeden Knoten die ein- und ausgehenden Kanten be-trachtet, ist eine andere Modellierung von Vorteil. Somit wurde eine Graphen-Repräsentationgewählt, welche diese Assoziation speichern kann, damit diese nicht für jeden Knoten erneutbestimmt werden muss. Ein Graph ist in der in dem Teilsystem dependencygraph gewähltenRepräsentation eine Abbildung von Knoten auf Kanten.

Die Entkopplung des Graphen von der Repräsentation in BlueJ ermöglicht zudem eine einfachesTesten der Klassen.

Der Typ GarbageCollectionDependency repräsentiert sowohl Schnittstellen- als auch Imple-mentationsabhängigkeiten. Um die einzelnen Arten von Abhängigkeiten voneinander zu unter-scheiden, wurde ein Aufzählungstyp übergeben. Dieser Aufzählungstyp unterscheidet Schnitt-stellen- von Implementationsabhängigkeiten. Es wäre möglich gewesen, eine Schnittstellenab-hängigkeit als Subtyp einer Abhängigkeit zu definieren, wie es bereits für Vererbungsbezie-hungen (GarbageCollectionInheritanceDependency) der Fall ist. Hierbei wäre jedoch zubeachten, dass die Methoden equals und hashCode für eine Schnittstellenabhängigkeit nichtüberschrieben werden dürfen. Eine Schnittstellenabhängigkeit von der Klasse A zu B unterschei-det sich in Bezug auf ein Gleichheitskriterium nicht von einer Implementationsabhängigkeit vonA zu B.

Somit müssten die equals- und hashCode-Methoden aus dem Supertypen übernommen wer-den, und dürften nicht überschrieben werden. Der Subtyp GarbageCollectionInterfaceDe-

pendency besäße weder einen Zustand, noch ein von dem Supertyp unterscheidbares Verhal-ten.

Eine Vererbungsbeziehung wird durch die Klasse GarbageCollectionInheritanceDepen-

dency dargestellt. Da eine Vererbungsbeziehung immer eine Schnittstellenabhängigkeit ist, wirdder entsprechende Aufzählungstyp automatisch gesetzt. Zudem kann eine Klasse eine Benutzt-Beziehung zu dem eigenen Supertypen besitzen. Diese Beziehung muss ebenfalls innerhalb desKlassendiagramms dargestellt werden können, wodurch eine Benutzt- und Vererbungsbeziehungnicht gleich sein dürfen.

5.2.3 Implementation der Interaktion um die Ansicht zu wechseln

Die Wechsel aller Klassen innerhalb eines Pakets ist sowohl mit dem Kontext-Menü, als auchdem „Ansicht“-Eintrag in der Menü-Leiste möglich. Da in beiden Fällen die selbe Aktion er-folgen soll, wurde für jeden Sichtwechsel eine einzige Klasse implementiert. Die Klassen Set-

ImplementationViewForAllTargetsAction- und SetInterfaceViewForAllTargetsAct-ion befinden sich im Paket bluej.pkgmgr.actions. Da diese Klassen von unterschiedlichenKlassen und zu unterschiedlichen Zeitpunkten (Kontext-Menü und Menüleiste werden zu unter-schiedlichen Zeitpunkten erzeugt) erzeugt werden, konnte das Exemplar der Klasse Package,in welchem alle Klassen in eine bestimme Ansicht gesetzt werden sollten, nicht direkt referen-ziert werden. Es wäre eine größere Modifikation des Quelltextes von BlueJ nötig gewesen, wasjedoch den in Abschnitt 5.1 beschriebenen Anforderungen an den Quelltext widerspricht.

38

Die unterschiedlichen Zeitpunkte, in denen die SetImplementationViewForAllTargetsAc-

tion- und SetInterfaceViewForAllTargetsAction-Klassen erzeugt werden, ist darin be-gründet, dass das Kontext-Menü für ein Paket generiert wird, wenn es angezeigt werden soll,während die Menü-Leiste einmal während des Startvorgangs der Anwendung erzeugt wird. Zu-dem kann die Konfiguration im laufenden Betrieb verändert werden, wodurch die Einträge inder Menü-Leiste nicht immer sichtbar sein dürfen. Da die Menü-Leiste angezeigt wird, ohnedass ein Paket geladen wurde, kann zu diesem Zeitpunkt nicht entschieden werden, in welchemPaket die Ansichten verändert werden sollen.

Um dieses Problem zu beheben wurde zunächst eine Behälter-Klasse hinzugefügt, welche dasPaket enthält, woraufhin es das enthaltene Paket an eine benutzende Klasse geben kann. Zusätz-lich wurden die bereits in BlueJ vorhandenen Klassen durch das Interface Repaintable vonden Action Klassen entkoppelt. Die Beziehungen dieser Typen sind im Klassendiagramm 5.2 zusehen.

Abbildung 5.2: Darstellung der Entkopplung des PkgMgrFrame und PackageEditor von denActions

5.2.4 Refactoring der Kon�guration des Benutzers

Die Klasse PrefMgr verwaltet in BlueJ die Einstellungen der Anwendung. Die Einstellungenkönnen über die Benutzungsschnittstelle eingerichtet werden. Die Abbildung 5.3 zeigt einenReiter dieser Oberfläche.

Der Zustand der Konfiguration wird in der Datei bluej.properties gespeichert. Hierfür mussein Label definiert werden, woran der Zustand dieser Option in der .properties-Datei gebun-

39

Abbildung 5.3: Die Benutzungsschnittstelle von BlueJ für Einstellungen.

den wird. Die zu den Checkboxen gehörenden Label werden in BlueJ als öffentliche Konstan-ten (public static final) in dem PrefMgr gehalten. Der PrefMgr bot mit den Operationenboolean getFlag(String) und setFlag(String, boolean) zudem die Möglichkeit, denZustand der entsprechenden Option zu setzen und zu erfragen. Die Operationen werden nur be-nötigt, um die Werte hinter den Checkboxen abzufragen, oder zu setzen. Entsprechend ist nichtjeder String ein sinnvoller aktueller Parameter, sondern nur die Strings, die ein Label für die.properties-Datei sind.

Um dieses stärker deutlich zu machen, wurde ein neues enum erstellt (BooleanUserPreferen-ces), welches diese Label darstellt und die entsprechenden Operationen angepasst. Zudem be-sitzt jede dieser Einstellungsmöglichkeiten einen Standardwert, welcher gesetzt wird, wenn dieBenutzerin, oder der Benutzer keine Einstellung vorgenommen hat. Diese Werte wurden in ei-nem static-Block gesetzt. Hierfür muss bei Konstanten für jedes Label der Wert von den Ent-wicklerinnen und Entwicklern eingetragen werden. Um die Fehleranfälligkeit zu reduzieren,wurde der Aufzählungstyp BooleanUserPreferences dahin gehend erweitert, dass der Stan-dardwert an diesem abgefragt werden kann.

Da über alle Werte eines enums iteriert werden kann, muss nicht länger jeder Standardwert ein-zeln gesetzt werden, sondern kann für alle Werte innerhalb einer Schleife gesetzt werden.

40

5.3 Mergen von BlueJ-CP mit BlueJ 3

Am 30. Mai 2010 wurde BlueJ 3 veröffentlicht. Es wurde die Darstellung von Objekten imInspektor verändert, und der Editor um mehrere Features erweitert. Darin enthalten sind Code-Completion, die Navigationsansicht (eine Darstellung des Quelltextes mit sehr kleiner Schrift,sowie den gerade im Editor betrachteten Ausschnitt) und Scope Highlighting.

5.3.1 Vorgehen

Der Weg von BlueJ zu BlueJ-CP in der Versionsverwaltung, wird in Abbildung 5.4 schematischdargestellt. Es wurden Änderungen an verschiedensten Klassen vorgenommen, welche daraufhinauch in der Weiterentwicklung von BlueJ zu BlueJ 3 verändert wurden. Diese sowohl in BlueJ-CP, als auch in BlueJ 3 veränderten Klassen führten zu Konflikten, welche eine Vereinigung vonBlueJ-CP mit BlueJ erschwerten.

Abbildung 5.4: Entwicklung von BlueJ-CP in einer Versionsverwaltung

Die Konflikte zwischen BlueJ-CP und BlueJ mussten behoben werden, ohne dabei Änderun-gen von BlueJ 3 oder BlueJ-CP zu verlieren. Das hierbei gewählte Vorgehen wird durch eineVersionsverwaltung unterstützt und in Abbildung 5.5 visualisiert.

Das Vorgehen lässt sich fünf Schritte unterteilen:

1. Zurücksetzen des Arbeitsordners auf die Ursprungsversion von BlueJ

2. Austauschen des Arbeitsordners mit BlueJ 3

3. Hinzufügen der neuen Version von BlueJ in die Versionsverwaltung

4. Den Arbeitsordner auf den letzten Stand von BlueJ-CP setzen

5. Vereinen von BlueJ-CP mit der in der Versionsverwaltung vorhandenen neuen Versionvon BlueJ

41

Abbildung 5.5: Gewähltes Vorgehen BlueJ-CP mit BlueJ 3 zu vereinen

Diese Vorgehensweise bietet den Vorteil, dass Dateien, die nur in der neuen Version von BlueJ,jedoch nicht in BlueJ-CP verändert wurden, keinen Konflikt in der Versionsverwaltung verursa-chen. Da diese Dateien nur in BlueJ geändert wurden, gibt es bei diesen Dateien keine Konfliktein der Versionsverwaltung und sie konnten problemlos aktualisiert werden.

5.3.2 Herausforderungen

In der Weiterentwicklung von BlueJ zu BlueJ 3 wurden nicht nur neue Features implementiert,sondern auch der Quelltext ein wenig auf den aktuellen Stand der Programmiersprache Javagebracht. So werden Generics bei Sammlungen häufiger als vor BlueJ 3 benutzt. Zudem wurdedie Anzahl an Tests von 20 auf 150 erhöht.

Insbesondere der Gebrauch von Generics erwies sich für den Merge-Vorgang von BlueJ-CP mitBlueJ 3 als häufige Ursache von Konflikten mit den Änderungen zu BlueJ-CP. Eine weitere,häufige Ursache von Konflikten war das in Abschnitt 5.2.4 beschriebene Refactoring. Da dieüber die PrefMgr-Klasse erreichbaren Einstellungen zentral verwaltet werden, wird diese Klassein nahezu allen Teilsystem und vielen Klassen benutzt.

42

5.4 Nicht verfolgte Aspekte

Exceptions werden in BlueJ-CP nicht als Schnittstellenabhängigkeiten erkannt, wenn diese indem Methodenkopf angegeben sind (checked Exceptions). Der derzeit gewählte Ansatz (Unter-abschnitt 5.2.1), um Schnittstellenabhängigkeiten zu extrahieren bietet keinen Zugriff auf etwai-ge Exceptions, die ein Klient behandeln muss.

Der in BlueJ verwendete Parser, unterstützt derzeit keine generischen Parameter. Wird eineVariable als Collection<Titel> deklariert, erkennt der Parser, dass hierbei eine Benutzt-Beziehung zu der Collection besteht, jedoch nicht, dass eine Beziehung zu der Klasse Titelvorhanden ist. In BlueJ-CP wäre es möglich gewesen, diese Beziehungen für Parameter vonOperationen oder Exemplar- und Klassen-Variablen zu extrahieren und anzuzeigen. Diese Be-ziehungen wurden jedoch in BlueJ-CP ignoriert, um das aus BlueJ bekannte Verhalten nicht zuverändern. Zudem wären ohne Modifikationen am Parser nur die in der Schnittstelle bekanntengenerischen Parameter angezeigt worden und kein aus z.B. lokalen Variablen.

Innere Klassen stellt BlueJ nicht im Klassendiagramm dar, und werden somit in BlueJ-CP nichtbetrachtet. Eine Klasse „entfalten“ zu können und somit die inneren Klassen anzuzeigen wurdenicht implementiert.

43

44

6 Evaluation anhand einer

Benutzerstudie

Während der Entwicklung von BlueJ-CP wurde folgende These aufgestellt:

These 1. Die eingeführte Schnittstellen- und Implementationsansicht einer Klasse unterstützendie Lernenden im Verständnis der Konzepte Schnittstelle und Implementation einer Klasse.

Um diese These zu belegen, wurde eine Benutzerstudie durchgeführt. Die Studie bestand nachdem Vorbild des Übungsbetriebs einer Lehrveranstaltung aus einer Aufgabe mit darauf folgenderBesprechung mit dem Versuchsleiter.

6.1 Rahmen der Studie

Die Benutzerstudie wurde innerhalb der Veranstaltung Softwareentwicklung 1 (SE 1) durch-geführt. Diese Veranstaltung wird in der Regel im ersten Semester der Informatik Studiengängeder Universität Hamburg besucht. Zudem wird diese Veranstaltung von Nebenfach-Studierendenbesucht. Insgesamt nahmen im WS 2009/2010 ca. 400 Studierende an dieser Lehrveranstaltungteil.

Die in SE 1 gestellten Aufgaben werden während der Laborübung abgearbeitet und von denBetreuern im laufenden Übungsbetrieb „abgenommen“, also überprüft, dass die Lösung denAnsprüchen der Lehrveranstaltung genügt. Zusätzlich können sich die Teilnehmerinnen undTeilnehmer bei Problemen an die Betreuer wenden. Die Betreuer können dann die Fragen be-antworten und weitere Hinweise geben, wie z.B. auf bessere Implementations-Ansätze.

Die Veranstaltung besteht formal aus einer Vorlesung à zwei SWS und einer Übung mit zweiSWS. Die Übung ist als Laborübung auf 180 Minuten ausgelegt, da der Anteil der Heimarbeitaufgrund des Charakters als Laborübung geringer als in klassischen Übungen ist. Dafür wer-den die Teilnehmerinnen und Teilnehmer angehalten, die Aufgaben während der Übungszeit inGruppen zu zwei Personen zu lösen und nicht alleine. In der Übung wird überwiegend im Paarprogrammiert.

SE 1 umfasst Grundlagen der imperativen und objektorientierten Programmierung, den Unter-schied zwischen Klassen und ihren Exemplaren. Das Java Collection Framework sowie Typenmit Interfaces sind ebenfalls Teil von SE 1. Vererbung, sowie die Entwicklung von Oberflächenmit Swing und Ansätze zur Modellierung von Software werden in einer Folgeveranstaltung (SE

45

2) behandelt. In SE 2 wird nicht mit BlueJ gearbeitet, sondern mit der integrierten Entwicklungs-umgebung Eclipse 1.

In SE 1 wird versucht, nach dem Prinzip „Konsumieren vor Produzieren“ die Inhalte an dieTeilnehmerinnen und Teilnehmer zu vermitteln. Zunächst wird z.B. eine Klasse oder das JavaCollection Framework benutzt, ehe selber Klassen oder Sammlungen implementiert werden.

Da BlueJ bereits in dieser Lehrveranstaltung verwendet wird und BlueJ-CP sich auch an dieseGruppe von Studierenden richtet, bot sich diese Veranstaltung für eine Benutzerstudie an.

Hierfür wurde den Teilnehmerinnen und Teilnehmern von SE 1 angeboten, eine vom Versuchs-leiter gestellte Aufgabe alternativ zu einer Aufgabe der Lehrveranstaltung zu bearbeiten.

Es wurde sowohl in der Vorlesung, als auch zu Beginn jeder Übung auf die Studie hingewie-sen. Zusätzlich wurde deutlich gemacht, dass die Aufgabe der Studie aufwändiger als die desÜbungsbetriebes ist.

Es meldeten sich 23 Personen in 12 Gruppen als freiwillige Teilnehmerinnen und Teilnehmerfür die Benutzerstudie (im folgenden Probanden).

6.2 Aufgabenstellung

Analog zu dem Übungsbetrieb wurde den Probanden eine Aufgabe gestellt. Zunächst sollten dieProbanden den Wechsel der Ansicht einer Klasse und die daraus resultierenden Auswirkungenauf das Klassendiagramm anhand eines ihnen bekannten Projekts kennenlernen. Diese Aufgabediente der Einarbeitung in BlueJ-CP und bot die Möglichkeit, frühzeitig auf Fragen und Ver-ständnisprobleme eingehen zu können.

Im zweiten Teil der Aufgabe wurde den Probanden das Projekt „JMicroTracker“ mit 10 Klassen,und drei Interfaces zur Verfügung gestellt. Der JMicroTracker verfolgt die seit dem Start derAnwendung verstrichene Zeit und unterteilt diese in Arbeits- und Pausenzeit. Die Interaktionerfolgt über ein Tray-Icon und es wird eine Oberfläche angeboten, welche die bisher verfolgteArbeits- und Pausenzeit anzeigt. Zunächst sollten sich die Probanden einen Überblick über dasProjekt verschaffen und die einzelnen Klassen und Interfaces betrachten. Sie sollten ebenfallsdie Komplexität des Projektes wahrnehmen. Dieses Projekt war größer und komplexer (in seinenBeziehungen) als alle anderen in SE 1 verwendeten Projekte.

Die zentrale Aufgabe bestand im Hinzufügen der Funktionalität zweier Schaltflächen. DieseSchaltflächen waren bereits in der Benutzungsschnittstelle des Projekts vorhanden, und die um-fassende Klasse bot Methoden an, um AktionListener zu einer Schaltfläche hinzuzufügen. Dadas Konzept eines Listeners nicht Teil der Lehrveranstaltung ist, wurde den Probanden einleitenderklärt, wie sie einen AktionListener zu einer Schaltfläche hinzufügen können.

Zunächst musste ein bereits bestehender AktionListener zu einer Schaltfläche hinzugefügt wer-den, ehe ein eigener AktionListener implementiert wurde.

1http://www.eclipse.org

46

Die Abbildung 6.1 zeigt das vollständige Klassendiagramm des Projekts JMicroTracker in BlueJ-CP.

Abbildung 6.1: Vollständiges Projekt JMicroTracker

Die Aufgabe war aufwändiger als alle bisherigen Aufgaben der Lehrveranstaltung. Somit wur-de von den Probanden nicht verlangt, die Aufgabe vollständig zu lösen. Ziel der Aufgabe wares, die Probanden dazu zu bringen sich mit BlueJ-CP in einer ihnen bekannten Situation zubeschäftigen.

Die vollständige Aufgabenbeschreibung findet sich im Anhang B.2.

47

6.3 Vorgehen

Die Aufgaben wurden von den Studierenden mit Hilfestellungen des Versuchsleiters bearbei-tet.

Die Probanden starteten zunächst BlueJ-CP aus dem Heimatordner des Versuchsleiters. Dar-aufhin öffneten sie ein ihnen bereits bekanntest Projekt, um die unterschiedlichen Ansichtenkennenzulernen.

Erst nachdem sie sich mit den unterschiedlichen Ansichten vertraut gemacht hatten, öffneten siedas Projekt JMicroTracker.

Anfangs war nur der Einstiegspunkt des Projekts sichtbar. Nachdem die Probanden die Ansichtdieser einzigen zu sehenden Klasse wechselten, wurden sechs weitere Klassen sichtbar und dieProbanden konnten sich, nach und nach, das gesamte Projekt erschließen.

Die Probanden wurden auf weitere, verborgene Klassen hingewiesen und als eine weitere Funk-tionalität zum Beenden der Anwendung implementiert werden sollte, wurde auf den ExitAk-

tionListener hingewiesen. Somit konnten sich die Probanden direkt mit der Schnittstelle derKlasse befassen, anstatt diese zu suchen.

Nachdem die Probanden die Aufgabe gelöst oder dieses zumindest intensiv genug versucht hat-ten, wurden sie mit einem Fragebogen als Leitfaden interviewt. Der Fragebogen findet sich imAnhang unter B.1.

Der Fragebogen war in vier Teile unterteilt. Zunächst wurden allgemeine Fragen gestellt, wiedem Empfinden des Schwierigkeitsgrades, oder zum vorherigen Verständnis von Schnittstelleund Implementation einer Klasse.

Der zweite Teil des Fragebogens bezog sich auf die BlueJ-CP zugrunde liegenden Konzepte, wiedie Unterstützung für das Verständnis von Schnittstelle und Implementation oder des Aufbauseines Projekts. Ebenfalls wurde nach der bewussten Verwendung der unterschiedlichen Ansich-ten einer Klasse gefragt.

Im vierte Teil wurde nach der Benutzungsschnittstelle gefragt. Hierbei wurde sowohl nach derDarstellung der einzelnen Klasse, als auch nach dem Ansatz um Klasse verbergen zu könnengefragt.

Zuletzt wurde nach dem Aufwand der Aufgabe für die Benutzerstudie gefragt.

6.4 Ergebnisse

Die Ergebnisse werden in folgende drei Bereiche unterteilt dargestellt.

1. Wechsel zwischen Schnittstellen-/Implementationsansicht und Verbergen von Klassen

2. Benutzungsschnittstelle von BlueJ-CP

48

Abbildung 6.2: Antworten auf die Frage: Unterstützt der Wechsel der Ansichten das Verständnisdes Projekts

3. Aufwand der Aufgabe

Wechsel zwischen Schnittstellen/Implementationsansicht und Verbergen vonKlassen

11 der 12 Gruppen gaben an, dass BlueJ-CP sie im Verständnis von Schnittstelle und Imple-mentation einer Klasse unterstützt. Die sich gegen die Unterstützung aussprechende Gruppe gabzudem an, dass die Ansichten nur teilweise klar gewesen sei.

16 der 23 Probanden empfanden den Wechsel der Ansichten als hilfreich, um die Struktur einesProjekts zu verstehen. Da bei dieser Frage die Meinungen der Mitglieder der Gruppen mehrmalsvoneinander abwichen, wurde nicht die Gruppe, sondern die einzelnen Probanden betrachtet.Mehrere Gruppen gaben an, dass die Möglichkeit Klassen zu verbergen erst bei größeren Pro-jekten hilfreich sei. Eine graphische Gegenüberstellung der Ergebnisse findet sich in Abbildung6.2.

Die Meinungen zur Unterstützung des Wechsels zwischen Schnittstelle und Implementation wa-ren fast ausgewogen. 10 von 23 Probanden sahen keinen Vorteil in BlueJ-CP um Aufgaben zulösen. Auch hier gaben mehrere Probanden an, dass die bisher in SE 1 verwendeten Projektezu klein gewesen seien, oder die Unterstützung erst bei größeren Projekten zum Tragen käme.Die Abbildung 6.3 stellt hier die Rückmeldungen der Probanden bzgl. der Unterstützung vonBlueJ-CP beim Lösen von Aufgaben dar.

Auf die Frage, ob BlueJ-CP innerhalb der Lehrveranstaltung eingesetzt werden sollte und wennja, alternativ oder zusätzlich zu BlueJ, entschieden sich 2 Gruppen gegen eine Verwendung vonBlueJ-CP. 2 Gruppen gaben an, BlueJ durch BlueJ-CP zu ersetzen und die Hälfte der Gruppen inder Stichproben wünschten eine zusätzliche Verwendung von BlueJ-CP. Dieser könnte sowohlfür Projekte, in denen der Fokus auf Schnittstelle und Implementation einer Klasse gelegt wurde,als auch für Projekte mit mehr als drei oder vier Klassen verwendet werden. Eine Gruppe gabzu dieser Frage keine Rückmeldung (zu sehen in Abbildung 6.4).

49

Abbildung 6.3: Antworten auf die Frage: Hilft BlueJ-CP beim Lösen der Aufgabe

Abbildung 6.4: Aussagen der Probanden ob BlueJ-CP in SE 1 verwendet werden sollte

Die beiden Gruppen, die sich gegen eine Verwendung von BlueJ-CP in SE 1 aussprachen, gabenan, dass eine mögliche Benutzerin oder ein möglicher Benutzer von den zusätzlichen Möglich-keiten in BlueJ-CP „übermannt“ werden könnte.

Benutzungsschnittstelle von BlueJ-CP

Drei Gruppen gaben an, dass sie den in BlueJ-CP verwendeten Ansatz zum Anzeigen und Ver-bergen von Klassen nicht beurteilen könnten. Alle anderen Gruppen empfanden diesen Ansatzals angemessen. Eine Gruppe gab noch an, dass eine sichtbare und aus einer verborgenen Klassebenutzte Klasse auf diese verborgenen Benutztbeziehungen bei Bedarf hinweisen könnte.

Die Darstellung der Schnittstellen- und Implementationsansicht war nach Aussagen von 15 Per-sonen verständlich. Acht Personen gaben an, dass die Darstellung nicht oder nicht sofort ver-ständlich war.

Die Interaktion mit BlueJ-CP stellte keine Probleme dar. Ein großer Teil der Probanden wünschtesich jedoch weitere Hinweise auf verborgene Klassen, oder gaben Hinweise auf noch bestehendeProbleme wie z.B. dass der Code-Schnipsel in der Implementationsansicht bei unkompiliertenKlassen nur schwer zu erkennen sei, weil der untere Teil des Typen mit diagonalen Strichendarauf hinweist, dass dieser nicht kompiliert wurde.

Alle Fehler sowie alle zusätzlichen Funktionalitäten, die von mehr als einer Gruppe gefordertwurden, finden sich im Anhang C.

50

Aufwand der Aufgabe

Der größte Teil der Probanden empfand den Aufwand zum Lösen der Aufgabe als zu groß.Wenige Gruppen gaben jedoch an, dass ihrer Meinung nach ein solcher Aufwand nötig sei, umdie Vor- und Nachteile der einzelnen Ansichten einer Klasse darstellen zu können.

6.5 Bewertung der Ergebnisse

Da die Probanden bereits Erfahrungen mit BlueJ gesammelt hatten, musste nicht auf die Grund-lagen der Bedienung eingegangen werden. Jedoch stellte dieses Vorwissen auch ein Hinder-nis dar. Da die Schnittstellenansicht der üblichen Klassen-Ansicht in BlueJ entsprach, musstedarauf geachtet werden, dass die Schnittstellenansicht nicht fälschlicherweise als Implemen-tationsansicht interpretiert wird. Eine Gruppe war der Meinung, dass die Schnittstellenansicht„ungewöhnlich“ aussehen sollte und nicht die Implementationsansicht. Diese Meinung könnteauf den Erfahrungen mit BlueJ beruhen, da es dort nur eine Implementationsansicht im Klassen-diagramm gibt und sie dieses mit der bekannten Darstellung der Klasse in Verbindung bringen.Somit birgt die Weiterverwendung der Ansicht einer Klasse für die Schnittstellenansicht das Ri-siko, diese beiden Ansichten zu verwechseln. Aufgrund dieser Verwechselungsgefahr wurde dieDarstellung der einzelnen Ansichten noch einmal überarbeitet.

Viele Gruppen verstanden den Unterschied zwischen den Sichten, jedoch nicht, dass das Klas-sendiagramm Hinweise auf möglicherweise benutzte Typen bietet. Wenn die Klasse Titellistedie Klasse Titel verwendet, kann es für Benutzer der Titelliste notwendig sein, ebenfallsdie Titel zu verwenden. Wird nur die Größe der Titelliste erfragt, ist es nicht notwendigeinen Titel zu benutzen. Es wurde auch nur durch Hinweise erkannt, dass das Klassendia-gramm kleiner wird, wenn die Schnittstellenansicht einer zu benutzenden Klasse ausgewählt ist.Beispielhaft zu sehen in den Abbildungen 6.5 und 6.6.

Zu beobachten war ebenfalls, dass nur selten auf die Dokumentation einer Klasse geachtet wur-de. Statt die Javadoc-Sicht auf die Klassendefinition zu wählen, wurde der Quelltext betrachtet.Jedoch zeigten viele Gruppen Probleme mit dem Verständnis des Quelltextes. Dies kann sowohlan dem betrachteten Quelltext, als auch der mangelnden Erfahrung vieler Probanden liegen.

Da dies die erste Benutzerstudie des Versuchsleiters war, können die Ergebnisse durch nichtvorhergesehene Faktoren, wie z.B. eine nicht ausreichende Erläuterung im Aufgabentext, ver-fälscht worden sein. Ebenfalls fand eine engere Betreuung der Probanden statt, als es in derLehrveranstaltung möglich gewesen wäre.

Die hier durchgeführte Benutzerstudie war nicht repräsentativ, da eher Studierende mit wenigProblemen in der Lehrveranstaltung an dieser Studie teilgenommen haben. Dies zeigt auch einVergleich mit der eine Woche zuvor durchgeführten Lehrevaluation.

Die Probanden bewerteten den Schwierigkeitsgrad der Lehrveranstaltung zu gut 33% als zu ein-fach und knapp 17% als zu schwer. Die Hälfte der Gruppen in der Stichprobe betrachteten denSchwierigkeitsgrad als angemessen. Dieses stellt eine Verschiebung in Richtung „zu einfach“

51

Abbildung 6.5: Implementationsansicht des ExitActionListeners

Abbildung 6.6: Schnittstellenansicht des ExitActionListeners

gegenüber den Ergebnissen der Lehrevaluation eine Woche vorher. Jedoch gaben sowohl in derLehrevaluation, als auch dieser Stichprobe 50% der Teilnehmerinnen und Teilnehmer an, dassdie Lehrveranstaltung einen angemessenen Aufwand erfordert. Die Tabelle 6.1 stellt diese An-gaben noch einmal gegenüber.

52

Zu einfach Angemessen Zu schwerProbanden 33.34 50 16.67

Alle Studierenden in SE 1 6 56.7 31.3

Tabelle 6.1: Vergleich des von den Probanden angegebenen Aufwands für die Lehrveranstaltungin %

Entgegen den Erwartungen nahmen nicht überwiegend, oder ausschließlich Probanden an dieserStudie teil, welchen die Lehrveranstaltung eher zu einfach war. Die Stichprobe war verschoben,aber dennoch stimmte der größte Teil der Einschätzungen aus der Stichprobe mit denen derLehrevaluation überein.

53

54

7 Zusammenfassung und Ausblick

Dieses Kapitel fasst die Arbeit noch einmal zusammen. Zusätzlich wird noch auf mögliche Wei-terentwicklungen der Unterstützung der Metaphern „Konsumieren“ und „Produzieren“ in BlueJeingegangen.

7.1 Zusammenfassung

BlueJ-CP wurde mit dem Gedanken entwickelt, die aus dem Editor von BlueJ bekannten unter-schiedlichen Sichten auf eine Klassendefinition in das Klassendiagramm zu übertragen.

Hierfür wurden unterschiedliche Ansätze die Darstellung der Schnittstelle einer Klasse von derDarstellung der Implementation zu unterscheiden betrachtet, getestet und bewertet. Es wurdeeine Visualisierung gewählt (Abbildung 7.1), die sowohl einfach zu erkennen ist, als auch einenleichten Übergang von BlueJ nach BlueJ-CP ermöglicht, da sie nicht im Widerspruch zu der inBlueJ gewählten Darstellung von Klasse steht.

Abbildung 7.1: Die Schnittstellen- (links) und Implementationsansicht (rechts) in BlueJ-CP.

BlueJ-CP ermöglicht es, die für einen Klienten unwichtigen Implementationsdetails innerhalbdes Klassendiagramms zu verbergen.

Es wurden Kriterien festgelegt, nach denen ein Einstiegspunkt in das Klassendiagramm be-stimmt werden kann. Diese geschah sowohl für Klassendiagramme in Java, als auch für dieSpezialfälle von Diagrammen in BlueJ.

Die im Rahmen einer Erstsemesterveranstaltung durchgeführte Evaluation belegte die aufge-stellte These, wonach die eingeführte Schnittstellen und Implementationsansicht das Verständnisvon Schnittstelle und Implementation unterstützt.

Dennoch bleiben mehrere Fragen offen, welche aufgrund ihrer Komplexität und ihres Umfangsnicht in dieser Bachelorarbeit behandelt werden konnten.

55

7.2 Ausblick

In dieser Arbeit wurde das Klassendiagramm von BlueJ dahingehend erweitert, dass es nicht nurstarr die Beziehungen der Klassen darstellt, sondern die Lernenden im Verständnis der KonzepteSchnittstelle und Implementation unterstützt. Dennoch war es nicht möglich, alle möglichenAnsätze für eine bessere Unterstützung dieser Konzepte zu betrachten. Ein paar diese Ansätzewerden im Folgenden kurz erläutert.

Integration von Paketen in das Klassendiagramm

Für gewöhnlich sind mit BlueJ bearbeitete Projekte auf ein Paket beschränkt, so dass nur dieKlassen dieses Pakets angezeigt werden müssen. BlueJ bietet zusätzlich auch eine Darstellungvon Paketen, jedoch sind diese nicht stark in das Klassendiagramm integriert. Subpakete werdenausschließlich als Symbol (Abbildung 7.2) dargestellt und es gibt keine Darstellung der Schnitt-stelle eines Paketes. Die ein- und ausgehenden Beziehungen eines Paketes werden ebenfallsnicht dargestellt.

Mehrere Ansätze wären denkbar, wie ein Paket stärker in das Klassendiagramm integriertenwerden kann. Es wäre z.B. denkbar, dass ein Paket in der Schnittstellenansicht in ein Klas-sendiagramm integriert werden kann. Hierbei könnten alle aus der Schnittstelle entstehendeneingehenden und ausgehenden Beziehungen dargestellt werden.

Abbildung 7.2: Ein Projekt in BlueJ mit einem Paket

Repräsentative Benutzerstudie

Die Benutzerstudie wurde mit insgesamt 23 Probanden durchgeführt. Mit dieser Anzahl an Pro-banden ist es möglich, Implikationen auf Vor- und Nachteile von BlueJ-CP zu extrahieren. DieEignung von BlueJ-CP für den Lehrbetrieb zu evaluieren, war nicht Teil dieser Arbeit und stehtsomit noch aus. Hierfür müssen noch weitere Evaluationen durchgeführt werden, damit Stör-effekte vermieden werden. Insbesondere die engere Betreuung während der Studie kann dasErgebnis ungewollt beeinflusst haben. Zudem wurde die Darstellung der Ansichten aufgrundder Evaluation verändert und die neuen Ansichten waren nicht Teil der Studie.

56

Weitere Funktionalität

Zudem wurden in der Benutzerstudie nach zusätzlichen Fähigkeiten von BlueJ-CP gefragt. EineAuswahl dieser Feature-Requests wird in Anhang C.2 dargestellt. Insbesondere eine Anzeigevon eigentlich nicht dargestellten Klassen kann hilfreich sein, wenn eine Klasse in dem Dia-gramm verschoben wird. So kann verhindert werden, dass eine angezeigt und eine nicht ange-zeigte Klasse „übereinander“ liegen. Zudem können nicht dargestellte, eingehenden Benutztbe-ziehungen auf Wunsch der Benutzerin, oder des Benutzers dargestellt werden.

57

58

Literaturverzeichnis

[ALBERS 2009] ALBERS, TIM (2009). Evaluation eines prototypischen Werkzeuges zur Visua-lisierung von Konzeptabhängigkeiten unter Berücksichtigung der Metapher „Konsumierenvor Produzieren“. Diplomarbeit, Universität Hamburg.

[BARNES und KÖLLING 2006] BARNES, DAVID J. und M. KÖLLING (2006). Objects Firstwith Java - A Practical Introduction using BlueJ. Prentice Hall / Pearson Education, Harlow,United Kingdom. 3. Auflage.

[BAXTER et al. 2006] BAXTER, GARETH, M. FREAN, J. NOBLE, M. RICKERBY, H. SMITH,M. VISSER, H. MELTON und E. TEMPERO (2006). Understanding the shape of Java softwa-re. In: OOPSLA ’06: Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, S. 397–412, New York, NY,USA. ACM.

[BENYON 2010] BENYON, DAVID (2010). Designing Interactive Systems - A comprehensiveguide to HCI and interaction design. Pearson Education, Essex, United Kingdom. 2. Auflage.

[BLUEJ-GEMEINSCHAFTa] BLUEJ-GEMEINSCHAFT. BlueJ Extensions. http://bluej.

org/extensions/extensions.html. Zuletzt besucht: 2010-02-12.

[BLUEJ-GEMEINSCHAFTb] BLUEJ-GEMEINSCHAFT. BlueJ-Project. zuletzt besucht: 2010-10-02.

[BLUEJ PROJECT] BLUEJ PROJECT. BlueJ Users. http://bluej.org/about/users.html.Zuletzt besucht: 2010-04-23.

[FOWLER und SCOTT 2000] FOWLER, MARTIN und K. SCOTT (2000). UML kontzentriert -Eine strukturierte Einführung in die Standard-Objetktmodellierungssprache. Addison Wes-ley, München. 2. Auflage.

[FREE SOFTWARE FOUNDATION] FREE SOFTWARE FOUNDATION. FSF Philosophy. http://www.gnu.org/philosophy/. Zuletzt besucht: 2010-02-25.

[GAMMA et al. 1995] GAMMA, ERICH, R. HELM, R. JOHNSON und J. VLISSIDES (1995).Design Patterns. Addison-Wesley, Boston, MA.

[GNU PROJECT] GNU PROJECT. GNU. http://www.gnu.org/software/classpath/

license.html. Zuletzt besucht: 2010-02-25.

[HENRIKSEN 2004] HENRIKSEN, POUL (2004). A Direct Interaction Tool for Object-OrientedProgramming Education. Diplomarbeit, University of Southern Denmark.

[HERCZEG 2009] HERCZEG, MICHAEL (2009). Sofware-Ergonomie - Theorien, Modelle undKriterien für gebrauchstaugliche interaktive Systeme. Oldenbourg Wissenschaftsverlag,München. 3. Auflage.

59

[JONES und LINS 1996] JONES, RICHARD und R. LINS (1996). Garbage Collection - Algo-rithms for Automatic Dynamic Memory Management. John Wiley & Sons, Chichester, UnitedKingdom. 3. Auflage.

[KÖLLING 2009] KÖLLING, MICHAEL (2009). Mics-Blog: BlueJ is 10. http://blogs.

kent.ac.uk/mik/2009/08/24/bluej-is-10/. Zuletzt besucht: 2010-02-12.

[KÖLLING et al. 2003] KÖLLING, MICHAEL, B. QUIG, A. PATTERSON und J. ROSENBERG

(2003). The BlueJ system and its pedagogy. Journal of Computer Science Education, Specialissue on Learning and Teaching Object Technology.

[KÖLLING und ROSENBERG 1996] KÖLLING, MICHAEL und J. ROSENBERG (1996). AnObject-Oriented Program Development Environment for the First Programming Course. In:SIGCSE Technical Symposium on Computer Science Education, Bd. 27, S. 83–87.

[KÖLLING. und ROSENBERG 1996] KÖLLING., MICHAEL und J. ROSENBERG (1996). Blue -A Language for Teaching Object-Oriented Programming. In: SIGCSE Technical Symposiumon Computer Science Education, Bd. 27, S. 190–194.

[KÖLLING und ROSENBERG 2001] KÖLLING, MICHAEL und J. ROSENBERG (2001). Guide-lines for Teaching Object Orientation with Java. In: Information Technology in ComputerScience Education (ITiCSE 2001).

[LILIENTHAL 2008] LILIENTHAL, CAROLA (2008). Komplexität von Softwarearchitekturen.Doktorarbeit, Universität Hamburg.

[LINSTEAD et al. 2009] LINSTEAD, ERIK, L. HUGHES, C. LOPES und P. BALDI (2009). Ex-ploring Java software vocabulary: A search and mining perspective. In: SUITE ’09: Pro-ceedings of the 2009 ICSE Workshop on Search-Driven Development-Users, Infrastructure,Tools and Evaluation, S. 29–32, Washington, DC, USA. IEEE Computer Society.

[PARNAS 1972] PARNAS, D. L. (1972). On the criteria to be used in decomposing systems intomodules. Commun. ACM, 15(12):1053–1058.

[SCHMOLITZKY 2005] SCHMOLITZKY, AXEL (2005). Position Paper: Towards ComplexityLevels of Object Systems Used in Software Engineering Education. In: 19th European Con-ference on Object-Oriented Programming (ECOOP).

[SCHMOLITZKY 2006] SCHMOLITZKY, AXEL (2006). Teaching inheritance concepts with Ja-va. In: PPPJ ’06: Proceedings of the 4th international symposium on Principles and practiceof programming in Java, S. 203–207, New York, NY, USA. ACM.

[SPÄH 2008] SPÄH, CHRISTIAN (2008). Konsumieren und Produzieren als nützliche Meta-phern in der Softwaretechnikausbildung und der Exploration von Klassenstrukturen. Di-plomarbeit, Universtiät Hamburg.

[SPÄH und SCHMOLITZKY 2007] SPÄH, CHRISTIAN und A. SCHMOLITZKY (2007). “Con-suming before Producing” as a Helpful Metaphor in Teaching Object-Oriented Concepts.In: Eleventh Workshop on Pedagogies and Tools for the Teaching and Learning of ObjectOriented Concepts, Berlin.

60

A Architektur von BlueJ

A.1 Betrachtung der Teilsysteme des bluejcore-Archivs

bluej.utility Hier werden viele Hilfsklassen untergebracht, welche an unterschiedlichen Stel-len in BlueJ benötigt werden. Dies erstreckt sich von der Verwaltung der aus der Oberflächekonfigurierbaren Einstellungen bis hin zu einer synchronized Queue.

bluej.parser Der Parser wurde mit Hilfe des Parsergenerators ANTLR 1 generiert und teil-weise von Hand erweitert.

bluej.extmgr Verwaltet die Erweiterungen in BlueJ. Die Erweiterungen werden durch denExtensionsManager geladen und verwaltet. Die API für eine Erweiterung wird in dem bluejext-Archiv bereitgestellt.

bluej.groupmgr Dieses Teilsystem bindet BlueJ an ein Source Code Management System(SCM) an. Derzeit werden das „Concurrent Versions System“ (CVS) 2 und „Subversion“ (SVN)3 unterstützt.

bluej.classmgr Jedes Projekt in BlueJ verwendet seinen eigenen ClassLoader (BPClass-Loader). Zusätzlich ist es möglich, Bibliotheken in BlueJ, über eine grafische Benutzungs-schnittstelle, zur Verfügung zu stellen. Dies können innerhalb der Konfigurationsoberfläche vonBlueJ verwaltet werden. Die für die Konfiguration von Bibliotheken für BlueJ-Projekte benötigteOberfläche ist ebenfalls in diesem Teilsystem angesiedelt.

bluej.compiler BlueJ kompiliert Projekte und Klassen mit einer eigenen CompilerThread-Klasse. Diese Thread-Klasse befindet sich zusammen mit dem Compiler und der dazu gehören-den Queue in diesem Teilsystem.

1http://www.antlr.org/2http://www.nongnu.org/cvs/3http://subversion.apache.org/

61

bluej.terminal Wird in einem BlueJ-Projekt eine Ausgabe auf der Konsole, z.B. mit printlnvorgenommen, wird dies von dem terminal-Teilsystem in einem eigenen Fenster dargestellt.

bluej.prefmgr Der PrefMgr verwaltet die Einstellungen innerhalb BlueJs. Die für die Ober-fläche benötigten Klassen finden sich ebenfalls in diesem Teilsystem. Da die Einstellungen andieser zentralen Stelle erfolgen, wird der PrefMgr an mehreren Stellen innerhalb von BlueJverwendet.

bluej.testmgr Stellt die Anbindung zu JUnit bereit und bereitet die Testdurchläufe für dieOberfläche auf. Innerhalb des Subpkets record befinden sich Klassen, welche ermöglichen,Testfälle interaktiv aufzuzeichnen.

bluej.debugmgr Stellt die Benutzungsschnittstelle für den Debugger (die Inspektoren), sowieden interaktiven Umgang mit Klassen und ihren Exemplaren zur Verfügung. Die Objektleistebefindet sich in dem Subpakets debugmgr.objectbench.

bluej.debugger Der Debugger stellt über das Java Debugging Interface (JDI) eine Verbindungzu der separat laufenden Runtime-VM her.

bluej.runtime Dieses Teilsystem ist für die Durchführung der interaktiven Aufrufe der Benut-zungsschnittstelle verantwortlich. Die Klasse ExecServer wird in einer separaten VM gestartet,und führt Shell-Klassen aus. Diese Klassen werden zur Laufzeit als Quelltext erstellt erweiternden Typen Shell und werden aus BlueJ übersetzt und in die Runtime-VM geladen. Die ShellKlassen werden in der bluej.debugmgr.Invoker Klasse erstellt und in eine Datei geschrieben.Daraufhin wird die Shell-Klassen gestartet und der interaktiv auszuführende Quelltext durchge-führt. Der Debugger in BlueJ verbindet sich mit der separaten VM und holt die Ergebnisse derDurchführung der Shell Klasse über das JDI.

bluej.views Stellt eine Repräsentation von Java-Klassen für die Objektleiste und Erweiterungs-Klassen bereit.

bluej.pkgmgr Der Package-Manager (pkgmgr) ist mit 180 Typen das größte Teilsystem. Die-ses Teilsystem übernimmt die Verantwortung für verschiedene Aspekte eines Java-Pakets inBlueJ. Dies reicht von der Benutzerinteraktion (Klassen oder Pakete erstellen), über die Darstel-lung als Graphen bis hin zu der Verwaltung der Konfigurationsdatei (package.blueJ).

Der Package-Manager besteht aus mehreren Pakete. Die Pakete, action, dependency, graphPainterund target stellen jeweils eine eigenen Teil des Teilsystems pkgmgr dar.

62

Das Paket graphPainter enthält die den Graphen zeichnenden Klassen. Mit Ausnahme desPackageTargetPainter und GraphPainterStdImpl sind Exemplare dieser Klassen zustands-los (Es gibt keine Exemplar-Variablen). Der GraphPainterStdImpl zeichnet den gesamtenGraphen und benutzt alle weiteren Klassen, um die entsprechenden Elemente in das Klassendia-gramm zu zeichnen (z.B. den ClassTargetPainter für eine Klasse in dem Diagramm). Meh-rere Exemplare des GraphPainterStdImpl werden über ein Singleton [GAMMA et al. 1995]Entwurfsmuster verhindert. Die einzige Exemplar-Variable stellt hierbei lediglich eine Hilfsva-riable dar, welche auch den jeweiligen Hilfsmethoden als Parameter übergeben werden kann.

Die anderen Klassen in dem Paket graphPainter zeichnen jeweils andere Elemente des Gra-phen. Die ClassTargetPainterKlasse ist zudem die einzige Klasse, die ebenfalls eine Klassen-Variable an Stelle eine lokalen Variable als Cache verwendet. Sie wird ausschließlich in einerMethode benutzt und sichert eine Eigenschaft eines Graphics Objektes.

Das Paket target enthält die Repräsentation von Typen und dependency die Beziehungen zwi-schen den Typen in dem Klassendiagramm. Die Klasse ClassTarget stellt hierbei eine Klassein dem Diagramm dar. Gezeichnet wird ein ClassTargetmit dem bluej.pkgmgr.graphPainter-

.ClassTargetPainter. Viele andere mit einer Klasse zusammenhängende Funktionalitätenfinden sich in dem ClassTarget. In dieser Klasse werden die Beziehungen aus dem Parserin Beziehungen für den Graphen umgewandelt und verschiedene Benutzerinteraktionen werdenmit inneren Klassen implementiert (Testklasse erzeugen, compilieren, entfernen, . . . ).

Da nur eine Klasse die unterschiedlichen Arten von Typen in einem Klassendiagramm repräsen-tiert, müssen diese Arten (TestKlasse, enum, abstrakte Klasse, . . . ) voneinander unterschiedenwerden können. Hierfür hält ein ClassTarget ein Exemplar vom Typ ClassRole, woran dieunterschiedlichen Arten unterschieden werden können.

Die einzelnen Rollen einer Klasse dienen überwiegend als „Flag“ und sind fast ausschließlichzustandslos. Innerhalb das ClassTargets wird zwischen den einzelnen Rollen über instanceofunterschieden. Die einzige Klasse, deren Exemplare einen Zustand besitzen ist die AppletClassRole.Es speichert die Parameter für das Applet, sowie die Größe des Fensters.

Rollenspezifisches Verhalten der Oberfläche wird ebenfalls in den einzelnen Rollen hinzuge-fügt. z.B. kann keine Test-Klasse von einer abstrakten Klasse erzeugt werden, weswegen dieAbstractClassRole diese Menüeinträge nicht hinzufügt.

actions enthält den Großteil der Implementationen der von dem Benutzer durchgeführten Ak-tionen in dem Klassendiagramm. Wenn z.B. eine neue Klasse erstellt, oder das Projekt gesichertwerden soll, wird diese Aktion in dem Paket actions implementiert.

bluej.graph In BlueJ werden alle generisch für Graphen verwendbare Klassen in dem Pa-ket graph zusammengefasst. Hier werden Knoten, Kanten sowie die für die Benutzerinter-aktion (markieren und verschieben eines Knotens) benötigten Klassen bereitgestellt. Entgegender Implementationen im pkgmgr wird hier nicht zwischen den einzelnen Typen von Knoten desGraphen unterschieden. Es gibt keine unterschiedliche Betrachtung von ReadmeTargets oderClassTargets.

63

A.2 Beziehungen zwischen den Teilsystemen

Die Abbildung A.1 zeigt die Beziehungen zwischen den Teilsystemen des bluejcore-Archivs.Die Pakete bluej.utility und bluej.prefmgr wurden ebenso entfernt, wie alle Referenzenauf Bibliotheken.

Die einzelnen Teilsysteme können beliebig miteinander interagieren. Es bestehen keine Be-schränkungen bezüglich der Beziehungen. Die Freiheit in der Benutzung von Teilsystemen er-streckt sich ebenfalls auf die Klassen innerhalb dieses Teilsystems, sofern auf diese zugegrif-fen werden kann. Somit wurde keine zusätzliche Schnittstelle für ein Teilsystem außerhalb derSchnittstelle des oder der Pakete definiert, wie es in manchen modularen Ansätzen der Fall ist(OSGI, Netbeans Modules). Die Pakete bluej.pkgmgr.targets und bluej.pkgmgr.graphPaintersind ebenso ein Teil der Schnittstelle des pkgmgr wie das Wurzelpaket des Teilsystems.

Der Mangel an festen Regeln und Konventionen, nach denen Beziehungen zwischen einzelnenTeilsystemen erlaubt sind, führte zu einer großen Zahl an zyklischen Abhängigkeiten. Die Zy-klen umfassen mehrfach nur 2 Teilsysteme, wobei diese gegenseitigen Abhängigkeiten teilweisenur auf wenige Stellen im Quelltext zurückzuführen sind. Die Abhängigkeit des classmgr vompkgmgr ist auf 2 Klassen zurückzuführen.

Die Benutzt-Beziehung vom graph-Teilsystem zum pkgmgr widerspricht dem Abstraktions-gedanken des graph-Teilsystems. Um einen Graphen zu modellieren und zu zeichnen ist esnicht notwendig auf Eigenschaften eines Pakets zuzugreifen. Diese widersprüchliche Benutzt-Beziehung, sowie einen Lösungsansatz wird in A.3.2 diskutiert.

Der pkgmgr übernimmt in BlueJ eine zentrale Rolle. Das Teilsystem ist nicht nur für das Klas-sendiagramm, sondern für das gesamte Hauptfenster von BlueJ verantwortlich.

Fast alle Beziehungen zu dem bluej Teilsystem gehen auf eine einzige Klasse zurück. DieKlasse Config ist eine Utility-Klasse, welche für die Konfiguration verantwortlich ist. Es wer-den globale verwendete Zustände gesichert, z.B. auf welchem Betriebsystem die Anwendungläuft, oder ob es sich hierbei um BlueJ oder Greenfoot handelt. Zudem übernimmt die KlasseConfig ebenfalls die Sicherung der Einstellungen auf der Festplatte. Alle von der Oberflächeaus einstellbaren Konfigurationen befinden sich im bluej.utility.PrefMgr.

Das utility-Paket wurde aus dem Graphen entfernt, da es aufgrund seiner Sammlung vonUtility-Klassen an verschiedenen Stellen in BlueJ verwendet wird und der Graph sonst nochunübersichtlicher würde.

Insgesamt ist BlueJ im Laufe der 10 jährigen Entwicklung gewachsen und dies merkt man demQuelltext auch an. Dennoch ist die Qualität der Architektur und des Quelltextes nicht schlecht.Es gibt viele Möglichkeiten die Qualität zu verbessern. Ein paar dieser Möglichkeiten werdenim Anhang unter A.3 erläutert.

64

Abbildung A.1: Die einzelnen Komponenten von des bluejcore Archivs, sowie ihre Beziehungenzueinander

65

A.3 Verbesserungsvorschläge und Kritik an der Architekturund dem Quelltext von BlueJ

Eine Anwendung an der bereits mehrere Jahre entwickelt wird, sammeln sich mit der Zeit ei-ne Menge an unangenehmen Gerüchen (Code Smells) und Altlasten an. In diesem Abschnittwerden ein paar allgemeine Kritikpunkte aufgelistet, welche sich negativ auf den Quelltext vonBlueJ auswirken und mehrere mögliche Refactorings vorgestellt.

A.3.1 Allgemeine Kritik am Quelltext

Keine Quelltext-Konventionen Der Quelltext von BlueJ ist über die Jahre der Entwick-lung und Wartung gewachsen. Ebenfalls war kein festes Team von Softwareentwicklerinnen undSoftwareentwicklern, oder nur eine Universität, an der Entwicklung von BlueJ beteiligt. Dieunterschiedlichen Entwicklerinnen und Entwickler haben einen eigenen Entwicklungsstil undeigene Meinungen, wie der Quelltext, den sie gerade schreiben, aussehen soll. Es gibt teilweisein den selben Zeilen eine Mischung aus Tabulatoren und Leerzeichen, die einzelnen Bezeich-nungen innerhalb einer Methode werden teilweise durch Großbuchstaben und teilweise durchUnterstriche getrennt (getFoo und get_foo).

Geringe Kohäsion von Klassen Mehrere Klassen besitzen eine zu geringe Kohäsion. DieKlasse ClassTarget ist verantwortlich für die Modellierung eine Klasse in technischer undoberflächenbezogener Sicht. Ein ClassTarget hält die Position des repräsentierten Typen indem Klassendiagramm ebenso, wie Operationen, die auf den Quelltext (compile) oder denÜbersetzungsvorgang (analyseSource) bezogen sind.

Legacy-Code Aufgrund der langen Entwicklungszeit von BlueJ sind viele Stellen mit „altem“Quelltext versehen. Nur selten werden generische Parameter verwendet (in BlueJ 3 wurde dieAnzahl an generischen Parametern bei Sammlungen stark vergrößert) und manche Klassen sindheutzutage nicht mehr notwendig. BlueJ bietet eine eigene Queue an, in welcher jede Operationsynchronized ist. Diese Klasse ist aufgrund des Concurrency-Framworks seit Java 5 nichtlänger notwendig. Das hohe Alter mancher Abschnitte im Quelltext zeigt sich besonders anhanddes folgenden Kommentars:

„These functions from the JDK1.2 source (I’m sure Sun won’t mind)“

Viele der Kritikpunkte sind für ein Projekt diesen Alters und Entwicklungskonzepts nicht außer-gewöhnlich. Viele Softwareentwicklerinnen und Softwareentwickler verfügen über einen eige-nen Stil um Quelltext zu schreiben. Zudem geht die Auswahl der bevorzugten Entwicklungsum-gebung (IDE, Betriebssystem, Tool-Chain) auseinander.

66

A.3.2 Verbesserungsvorschläge

Subtyping an Stelle von Verzweigungen

BlueJ und Greenfoot setzen auf eine gemeinsame Quelltext-Basis auf. Hierfür wurde in BlueJan mehreren Stellen, insbesondere in der Config und MiscPrefPanel eine Verzweigung hin-zugefügt, in der geprüft wird, ob es sich bei der gerade laufenden Anwendung um BlueJ oderGreenfoot handelt. Diese Verzweigung sind zu großen Teilen unnötig und erschweren sowohldas Verständnis, als auch die Wartung des Quelltextes, da bei Änderungen geprüft werden mussob diese nur eine oder beide Entwicklungsumgebungen betrifft.

Viele dieser Verzweigungen ließen sich mit einer AbstractConfig-Oberklasse und je nachBlueJ oder Greenfoot einer BlueJConfig und GreenfootConfig Klasse vermeiden. Da dieConfig-Klasse eine Utility Klasse ist und somit keine keine Exemplare von ihr erzeugt werden,muss zwischen den beiden Typen unterschieden werden. Dieses ließe sich z.B. durch eine Fabrikwie in der PackageFileFactory druchführen. In der PackageFileFactory wird bereits zwi-schen einem BlueJPackageFile und GreenfootProjectFile unterschieden. Einen weiterenZweck erfüllt diese Klasse nicht. Analog hierzu wäre es möglich, eine ConfigFactory zu erstel-len, welche je nach laufender Anwendung Exemplare der BlueJConfig oder GreenfootConfig-Klasse zurück gibt.

Ein ähnliches Verfahren ließe sich auch auf Betriebssystem-spezifische Klassen anwenden. Mehr-fach wird innerhalb BlueJs überprüft, auf welchen Betriebssystem die Anwendung gerade aus-geführt wird, und dementsprechend unterschiedliche Aktionen durchführt.

Benutzt-Beziehung vom bluej.graph auf bluej.pkgmgr entfernen

Das Graphen-Teilsystem stellt Typen und Operationen für Graphen zur Verfügung. Es handeltsich hierbei um eine abstrakte Implementation, welche als eingebettete Bibliothek angesehenwerden kann. Der Package-Manager erweitert den Graphen um Klassendiagramm spezifischeTypen und Methoden (der Package-Manager „ist“ ein Graph).

Die vorhandene Benutzt-Beziehung vom Graphen zum Package-Manager widerspricht dem An-satz einer eingebetteten Bibliothek. Im Folgenden wird beschrieben, wie diese Benutzt-Beziehungaufgelöst werden kann.

Die Beziehungen gehen auf 2 Klassen innerhalb des Graphen-Teilsystems zurück. Ein Refac-toring des GraphEditors stellt hierfür keine große Herausforderung dar, da diese Klasse vondem PackageEditor innerhalb des bluej.pkgmgr erweitert wird. Somit kann diese Benutzt-Beziehung, z.B. durch eine abstrakte Methode, welche im PackageEditor implementiert wird,entfernt werden.

67

Der SelectionController stellt eine größere Herausforderung dar. Er implementiert mehrereListener um die Interaktion mit dem Klassendiagramm zu ermöglichen. Hierfür werden mehre-re Typprüfungen vorgenommen um ein unterschiedliches Verhalten umzusetzen. Manche Typ-prüfungen würden ebenso funktionieren, wenn ein in dem Graphen definierter Typ verwendetwürde, andere könnten z.B. in einen Subtypen des GraphEditors verschoben werden, da derselben Operation je nach Typ ein konkretes Objekt oder null übergeben wird. Der Aufruf undder Anfang der Implementation der entsprechende Methode ist den den Quelltext-SchnipselnA.1 und A.2 zu sehen. Die Typberüprüfung in diesem Fall zu dem Dienstleister zu verschiebenbietet auch den Vorteil, dass dort nicht auf null, sondern auf den Typen geprüft werden könnte.Das in Java zur Verfügung stehende Schlüsselwort instanceof überprüft nicht bloß den Ty-pen, sondern prüft ebenfalls, ob das Objekt null ist, und gibt false zurück, sofern kein Objektreferenziert wird.

p r i v a t e void n o t i f y P a c k a g e ( GraphElement e l e m e n t ){

i f ( e l e m e n t i n s t a n c e o f C l a s s T a r g e t )( ( Package ) g raph ) . t a r g e t S e l e c t e d ( ( T a r g e t ) e l e m e n t ) ;

e l s e( ( Package ) g raph ) . t a r g e t S e l e c t e d ( n u l l ) ;

}

Listing A.1: Aufruf von targetSelected im SelectionController

p u b l i c vo id t a r g e t S e l e c t e d ( T a r g e t t ){

i f ( t == n u l l ) {i f ( g e t S t a t e ( ) != S_IDLE ) {

s e t S t a t e ( S_IDLE ) ;s e t S t a t u s ( " " ) ;

}re turn ;

}[ . . . ]

Listing A.2: Auschnitt aus der Implementation von targetSelected in der Klasse Package

Dieses Refactoring würde unter Anderem die derzeit bestehenden Widerspruch zu einem ab-strakten Graphen beheben und die beiden Teilsysteme stärker entkoppeln.

Laden von Bibliotheken zur Laufzeit und Starten von BlueJ durch Re�ection

BlueJ wird zu mehreren Jar-Archiven kompiliert, und jedes dieser Archive stellt einen Teil desGesamtsystems zur Verfügung. Entgegen der üblichen Vorgehensweise, jede benötigte Biblio-thek in der „MANIFEST.MF“ Datei des zu startenden Archivs anzugeben, werden die Biblio-theken und BlueJ-Archive zur Laufzeit in der bluej.Boot-Klasse geladen. Diese Klasse durch-

68

sucht zunächst den ClassPath nach der bluej.Main-Klasse und erzeugt ein Exemplar über Re-flection.

Dieses Vorgehen ist nicht notwendig und verhindert ein einfaches Verständnis des Quelltextes.Ein direkter Aufruf der Main-Klasse erhöht die Les- und Wartbarkeit. Dies ließe sich wie folgtUmsetzen.

Der derzeitige Vorgang zum Kompilieren und Zusammensetzen von BlueJ stellt hierfür das zen-trale Problem dar. Derzeit befindet sich der größte Teil des BlueJ-Quelltextes unter src und derQuelltext des Boot-Archivs unter boot/src. Da der Quelltext des Boot-Archivs während desKompilierens keine Zugriff auf den src-Ordner hat, kann der Compiler die Abhängigkeit zu derMain-Klasse nicht auflösen. Damit die Boot-Klasse die Main-Klasse direkt verwenden kann,muss der Compiler auf die Main-Klasse im Quelltext oder Objektcode zugreifen können. Hättedas bluejcore-Archiv keine Abhängigkeit zu dem bluej-Archiv, könnte zunächst der Kern vonBlueJ kompiliert werden und darauf hin das Boot-Archiv. Apache Ant 4 ist im Stande mehrereQuelltext-Ordner gleichzeitig zu kompilieren, wodurch es nicht notwendig wäre die Ordner-Struktur zu verändern, wenn der gesamte Quelltext gleichzeitig kompiliert werden soll.

Die durch das Ant-Buildscript erzeugten Archive müssen ebenfalls in der MANIFEST angege-ben werden, damit diese automatisch geladen werden.

Damit wäre es nicht länger notwendig, die Main-Klasse über Reflection zu laden und könntedirekt im Quelltext referenziert werden.

GraphPainter

Die Painter für Elemente des Klassendiagramms sind derzeit zu großen Teilen zustandslos undes wird genau ein Exemplar von ihnen erzeugt. Abgesehen vom GraphPainterStdImpl wirdin keiner anderen Klasse ein Exemplar eines Painters erzeugt. Der GraphPainterStdImpl er-laubt unter normalen Umständen (kein Serialisieren, kein Erzeugen durch Reflection), durchein Singleton, ein einziges Exemplar von sich. Diese Klasse zeichnet den gesamten Graphenund reicht das übergebene Graphics-Objekt an die entsprechenden Exemplare der Zeichner-Klassen (ClassTargetPainter, ReadmeTargetPainter, . . . ) weiter, um z.B. eine Klasse, einPaket oder die Readme zeichnen zu lassen.

Das Graphics-Objekt wird dann von den jeweiligen Methoden modifiziert, um nach und nachdas Klassendiagramm zu zeichnen. Um sicher zu stellen, dass das Graphics-Objekt nach durch-führen der Methode wieder im Ursprungszustand ist, wird der alte Zustand in Hilfsvariablengesichert und am Ende der Methode wieder an dem Objekt gesetzt. Somit wird ein Graphics-Objekt verwendet um das gesamte Klassendiagramm zu zeichnen.

Immer das selbe Objekt zu verwenden, um das Klassendiagramm zu zeichnen, birgt mehrereRisiken:

1. Unverständlicher Quelltext durch Zwischenspeichern alter Zustände

4http://ant.apache.org/

69

2. Unbekannter Zustand nachdem eine Methode ausgeführt wurde

3. Nicht-deterministisches Verhalten bei Nebenläufigkeit

Diese Probleme ließen sich beheben, wenn nicht das selbe, sondern eine Kopie des Graphics-Objektes verwendet würde. Eine solche Kopie ließe sich mit der Methode Graphics.create

erstellen, welche eine Kopie des ursprünglichen Objektes zurück liefert. Eine Kopie zu verwen-den reduziert den Aufwand um den alten Zustand wieder herzustellen, da in dem originalenObjekt keine Änderungen vorgenommen wurden. Somit wäre der Zustand des originalen Ob-jektes unverändert und könnte ohne weitere Überprüfungen weiter verwendet werden.

Zusätzlich wäre es möglich, das Klassendiagramm nebenläufig zu zeichnen. Derzeit wird dasDiagramm in BlueJ im „Event-Dispatching-Thread“ (EDT) gezeichnet. Wenn jedoch ein Aufrufaus einem anderen Thread als dem EDT getätigt wird, kann es zu Race-Conditions kommenwodurch sich das Graphics-Objekt in keinem vorhersehbaren Zustand befindet.

Jedoch ist zu bedenken, dass in BlueJ überwiegend nicht mit Graphics sondern Graphics2D

gearbeitet wird. Die create-Methode gibt jedoch auch bei Graphics2D lediglich ein Graphics-Objekt zurück. Diese Implementation kann zu mehreren Typzusicherungen führen, welche dieLesbarkeit des Quelltextes weiter reduzieren. Wäre die create mit einem koviaranten Ergebni-styps implementiert worden, wären die Typzusicherungen nicht notwendig.

70

B Evaluation anhand einer

Benutzerstudie

B.1 Leitfaden für das Interview

Konzepte

Schwierigkeitsgrad von SE 1

Schnittstelle Implemenation vorher klar

Warum gibt es bei einerm Interface nur eine Sicht

Unterstützt eurer Meinung nach der Sichtenwechsel die Umsetzung der Aufgaben

Unterstützt eurer Meinung nach der Sichtenwechsel das Verständnis von Schn/Imp

Unterstützt eurer Meinung nach der Sichtenwechsel das Verständnis einer Projektes

Hattet ihr den Wechsel der Sichten bewusst verwendet, um die Aufgabe zu lösen

Hattet ihr das Klassendiagramm vorher bereits bewusst verwendet und wenn ja, wofür

Benutzer Schnittstelle

Die Darstellung der Ansichten war verständlich

Gab es Probleme mit der Interaktion

Wenn nicht, worin liegt das Problem

Wie fandet ihr den Ansatz in BlueJ-CP (Klassen verbergen/ Interaktion)

Sollten Klassen „angepinnt“ werden werden können

Aufgabe

War die Aufgabe

Vorschläge für Verbesserungen

Zu einfach

Zu einfach

kam zurecht zu schwervertretbar

vertretbar kam zurecht zu schwer

ja sonst nein

ja sonst nein

ja sonst nein

ja sonst nein

ja sonst nein

angemessen kompletter Müllunverständlich

zu schwerangemessenzu leicht

ja sonst nein

ja sonst nein

ja sonst nein

71

B.2

AufgabederBenutzerstudie

Blu

eJ-C

P:

Stu

die

nau

fgab

e

Bis

her

wur

den

im R

ahm

en d

iese

r L

ehrv

eran

stal

tung

nur

„kl

eine

“ P

roje

kte

verw

ende

t. Je

doch

ble

iben

S

oftw

arep

roje

kte

nich

t im

mer

so

klei

n, d

ass

es m

ögli

ch is

t, di

eses

Pro

jekt

vol

lstä

ndig

zu

über

blic

ken.

Som

it m

uss

eine

Mög

lich

keit

gef

unde

n w

erde

n, u

m P

roje

kte

in v

erst

ändl

iche

Tei

le z

u ze

rleg

en u

nd

som

it e

inen

Tei

l der

Kom

plex

ität z

u ve

rber

gen.

Blu

eJ-C

P (

Con

sum

ing

Pro

duci

ng)

ist e

ine

mod

ifiz

iert

e V

ersi

on v

on B

lueJ

, um

Stu

dier

ende

im

Ver

stän

dnis

von

Obj

ekto

rien

tier

ung

zu u

nter

stüt

zen.

Blu

eJ u

nter

sche

idet

nur

im E

dito

r zw

isch

en d

er

Sch

nitt

stel

le u

nd I

mpl

emen

tati

on e

iner

Kla

sse.

Es

kann

zw

isch

en e

iner

dir

ekte

n, b

earb

eitb

aren

Sic

ht

auf

den

Que

lltex

t und

ein

er n

icht

edi

tier

bare

n ja

vado

c-S

icht

gew

echs

elt w

erde

n. D

as K

lass

endi

agra

mm

ei

nes

Blu

eJ-P

roje

ktes

zei

gt h

inge

gen

alle

Bez

iehu

ngen

zw

isch

en d

en K

lass

en, a

uch

wen

n di

ese

nur

auf

die

Impl

emen

tatio

n ei

ner

Kla

sse

zurü

ck z

u fü

hren

sin

d. M

it B

lueJ

-CP

wir

d ve

rsuc

ht, d

ie U

nter

schi

ede

zwis

chen

der

Sch

nitts

tell

e un

d Im

plem

enta

tion

eine

r K

lass

e au

ch im

Kla

ssen

diag

ram

m d

eutl

ich

zu

mac

hen

und

Stu

dier

ende

som

it z

u un

ters

tütz

en.

In B

lueJ

-CP

ist i

m K

lass

endi

agra

mm

die

Sch

nitt

stel

len-

Ans

icht

ein

er K

lass

e vo

rein

gest

ellt.

Die

se

Ans

icht

sch

eint

sic

h au

f de

n er

sten

Blic

k ni

cht v

on d

er a

us B

lueJ

bek

annt

en A

nsic

ht e

iner

Kla

sse

im

Kla

ssen

diag

ram

m z

u un

ters

chei

den.

Blu

eJ-C

P z

eigt

in d

iese

r A

nsic

ht je

doch

nur

Abh

ängi

gkei

ten,

die

in

der

Sch

nitts

tell

e de

fini

ert s

ind.

Aus

schl

ießl

ich

in d

er I

mpl

emen

tatio

n ve

rwen

dete

Abh

ängi

gkei

ten

wer

den

hing

egen

ver

borg

en.

Mit

ein

em K

lick

auf

die

mit

tler

e M

aust

aste

ode

r de

m M

ausr

ad k

ann

von

der

Sch

nitts

tell

en-A

nsic

ht in

di

e Im

plem

enta

tions

-Ans

icht

gew

echs

elt w

erde

n.

In d

er I

mpl

emen

tati

ons-

Ans

icht

wir

d ei

n T

eil d

es K

lass

ensy

mbo

ls w

eiß

darg

este

llt. I

n di

eser

Ans

icht

w

erde

n au

ch a

lle

Abh

ängi

gkei

ten

der

Kla

sse

im K

lass

endi

agra

mm

ang

ezei

gt. V

erw

ende

t ein

e K

lass

e ei

ne a

nder

e K

lass

e nu

r in

ihre

r Im

plem

enta

tion,

ist d

ie B

enut

zt-B

ezie

hung

nur

in d

er I

mpl

emen

tatio

ns-

Ans

icht

sic

htba

r un

d ni

cht i

n de

r S

chni

ttste

llen

-Ans

icht

. Ihr

kön

nt e

uch

die

Impl

emen

tatio

ns-A

nsic

ht

wie

ein

e ge

öffn

ete

Mot

orha

ube

vors

tell

en.

Ein

wei

tere

Klic

k m

it d

er m

ittle

ren

Mau

stas

te w

echs

elt d

ie S

icht

auf

die

se K

lass

e zu

rück

in d

ie

Sch

nitt

stel

len-

Ans

icht

. Die

Sic

ht k

ann

eben

fall

s du

rch

das

Kon

text

men

ü de

r K

lass

e ge

wec

hsel

t w

erde

n.

Wen

n ih

r da

s K

onte

xtm

enü

in d

er f

reie

n F

läch

e (z

wis

chen

den

Kla

ssen

) au

fruf

t, kö

nnt i

hr a

lle

Kla

ssen

in

die

Sch

nitt

stel

len-

und

Im

plem

enta

tion

s-A

nsic

ht v

erse

tzen

. Tes

ts s

ind

hier

von

nich

t bet

roff

en.

Schn

itts

tell

en S

icht

Impl

emen

tatio

ns

Sich

t

Mac

ht e

uch

ein

wen

ig m

it B

lueJ

-CP

ver

trau

t. V

ersu

cht h

ierb

ei z

u ve

rste

hen,

wel

che

Ben

utzt

-B

ezie

hung

en in

wel

cher

Ans

icht

(S

chni

ttste

lle

oder

Im

plem

etat

ion)

ein

er K

lass

e zu

seh

en s

ind.

1.S

tart

et B

luej

-CP

. Die

ses

ist z

u fi

nden

unt

er

/home/j2006/6stahlhu/bluej-cp/bluej

.2.

Öff

net d

as v

on e

uch

bear

beite

te S

E1T

unes

Pro

jekt

und

wec

hsel

t die

Ans

icht

des

LinkedTitelListenTest.

Dar

auf

hin

soll

te d

ie LinkedTitelListe

und

TitelBibliothek

ers

chei

nen.

Die

Tes

ts w

erde

n an

geze

igt,

wei

l sie

aus

kei

ner

Kla

sse

in

dem

Pro

jekt

ver

wen

det w

erde

n.3.

War

um is

t der

DoppellinkKnoten

nur

sic

htba

r, w

enn

auch

die

Sic

ht a

uf d

ie

LinkedTitelListe

gew

echs

elt w

ird?

Mir

erk

läre

n.

4.W

arum

ist d

ie T

itel

Bil

biot

hek

nur

dann

sic

htba

r, w

enn

sich

min

. ein

en T

est o

der

der

Effizienzvergleicher

in d

er I

mpl

emen

tatio

ns-A

nsic

ht b

efin

den?

Mir

erk

läre

n

JMicroTracker

Der

JM

icro

Tra

cker

wur

de e

ntw

icke

lt u

m d

en A

ufw

and

zum

mer

ken

von

Pau

senz

eite

n w

ähre

nd d

er

Arb

eits

zeit

zu

redu

zier

en. H

ierf

ür w

ird

ein

wei

tere

s T

rayI

con

hinz

ugef

ügt,

wel

ches

die

B

enut

zers

chni

ttst

elle

ist.

Wen

n 2

mal

auf

die

ses

Tra

yIco

n ge

klic

kt w

ird,

wec

hsel

t die

Zei

terf

assu

ng

zwis

chen

Arb

eits

zeit

und

Pau

senz

eit.

Um

die

Zei

terf

assu

ng z

u be

ende

n is

t es

mög

lich

, übe

r da

s T

rayI

con

ein

PopU

p-M

enü

zu ö

ffne

n. N

achd

em d

ie Z

eite

rfas

sung

bee

ndet

wur

de, w

ird

dies

e in

dem

O

rdne

r ~/tracks

in e

iner

Tex

tdat

ei a

ngef

ügt.

~ st

eht h

ierb

ei f

ür e

uren

Hei

mat

-Ord

ner

(/ho

me/

j200

X/x

nach

nam

e). T

rayI

con

? F

ragt

mic

h e

infa

ch.

So

ist e

s z.

B. n

icht

meh

r no

twen

dig,

sic

h di

e U

hrze

it z

u m

erke

n od

er a

uf z

u sc

hrei

ben,

wen

n m

an z

.B.

esse

n ge

ht. L

edig

lich

2 K

licks

auf

das

Tra

yIco

n vo

r un

d na

ch d

em E

ssen

und

man

kan

n si

ch s

ehen

, wie

la

nge

die

Pau

se w

ar.

1.K

opie

rt u

nd e

ntpa

ckt e

uch

das

Proj

ekt J

Mic

roT

rack

er in

eur

en H

eim

at-O

rdne

r. D

as P

roje

kt

befi

ndet

sic

h un

ter /home/j2006/6stahlhu/JMikoTracker

2.

Sta

rtet

die

Anw

endu

ng u

nd v

ersc

haff

t euc

h ei

nen

Übe

rblic

k üb

er d

as g

esam

te P

roje

kt.

3.D

erze

it si

nd 2

But

tons

noc

h oh

ne F

uktio

nalit

ät. F

inde

t zun

ächs

t die

But

tons

und

ver

such

t he

raus

zu

find

en, o

b fü

r di

e B

utto

ns T

eile

des

Que

llte

xtes

wie

derv

erw

ende

t wer

den

kann

.4.

Ver

volls

tänd

igt d

ie n

och

nich

t vor

hand

ene

Impl

emen

tati

on.

Blu

eJ-C

P:

Rü

ckm

eld

unge

n

Nac

hdem

ihr

jetz

t ein

en k

lein

en E

inbl

ick

in B

lueJ

-CP

bek

omm

en h

abt,

hätte

ich

natü

rlic

h ge

rne

Rüc

kmel

dung

en v

on e

uch.

Sch

ließ

lich

bes

teht

noc

h di

e Fr

age,

ob

dies

er A

nsat

z fü

r di

e L

ehre

von

O

bjek

tori

enti

erun

g hi

lfre

ich

ist,

oder

nic

ht. S

omit

sch

reib

t ein

e M

ail a

n m

ich:

6stahlhu@informatik.uni-hamburg.de

und

vers

ucht

fol

gend

e Fr

agen

zu

bean

twor

ten:

H

ier

gibt

es

nich

t ric

htig

ode

r fa

lsch

, ich

bin

ledi

glic

h an

eue

r M

einu

ng in

tere

ssie

rt.

1.E

mpf

ande

t ihr

die

Wec

hsel

der

Ans

icht

ein

er K

lass

e al

s hi

lfre

ich

um d

ie A

ufga

ben

zu lö

sen,

od

er e

her

verw

irre

nd?

2.H

atte

t ihr

Pro

blem

e, d

ie u

nter

schi

edli

chen

Sic

hten

zu

vers

tehe

n od

er d

iese

r vo

nein

ande

r zu

un

ters

chei

den?

3.S

ollt

e B

lueJ

-CP

ber

eits

frü

her,

alt

erna

tiv, o

der

ergä

nzen

d zu

Blu

eJ v

erw

ende

t wer

den?

4.W

arum

wer

den

Kla

ssen

man

chm

al v

erbo

rgen

?5.

Son

stig

e A

nmer

kung

en, F

eatu

re-R

eque

st o

der

Bug

-Rep

orts

72

C Probleme und Feature-Requests

C.1 Fehler in BlueJ/-CP

Im Rahmen dieser Benutzerstudie wurden von den Probanden mehrere Fehler benannt, welcheihnen in BlueJ-CP aufgefallen waren.

Beschreibung Die Pfeile sollten an den Klassen enden und nicht inder leeren Fläche dazwischen

Anzahl der Gruppen 1Mögliche Ursache In BlueJ wird für jede erzeugte Benutzt-Beziehung

Platz an der Oberfläche alloziert. BlueJ-CP ana-lysiert eine Klasse nach jedem Kompilier-Vorgangund erzeugt eine neue Benutztbeziehungen für dieOberfläche. Die Positionen der Benutz-Beziehungenwerden darauf hin neue berechnet. Hierdurchkann es passieren, dass nach mehreren Kompilier-Vorgängen die Pfeile für die Benutztbeziehungenvon der Klasse in den freien Raum abwandern.Pfeile wandern nicht mehr

Tabelle C.1: Pfeile sollen nicht in der leeren Fläche enden

Beschreibung Editor erscheint nicht im Vordergrund, wenn derEditor einer Klasse geöffnet wird.

Anzahl der Gruppen 1Mögliche Ursache Dieses Verhalten könnte auf die Konfiguration der

Desktop-Umgebung, oder aber auch auf das in derBenutzerstudie verwendeten Betriebssystem zurückzuführen sein.

Tabelle C.2: Editor erscheint nicht im Vordergrund

73

C.2 Feature-Requests

Mehrere Gruppen äußerten Wünsche bezüglich weiterer Möglichkeiten innerhalb von BlueJ-CP.

Dies sind nicht alle gewünschten Verbesserungen der Probanden, sondern nur diejenigen, dievon mehr als einer Gruppe erbeten wurden.

Beschreibung Klassen anpinnen könnenAnzahl der Gruppen 9Kommentar Wenn Klassen „angepinnt“ werden können, ist es

möglich alle Klassen, auf die die Sicht gewechseltwerden musste, um die angepinnte Klasse betrach-ten zu können wieder in die Schnittstellenansichtzu versetzen. Ebenfalls könnten diese nicht weiterbenötigte Klasse verborgen werden. Dies hätte zurFolge, dass bei größeren Projekten das Klassendia-gramm nicht mit unwichtigen Klassen und Benutzt-beziehungen „verdreckt“ wird.

Wurde nach der Studie implementiert

Tabelle C.3: Klassen anpinnen

Beschreibung Schnittstellenabhängigkeiten optisch hervorhebenAnzahl der Gruppen 3Kommentar Wenn Schnittstellenabhängigkeiten optisch von Ab-

hängigkeiten auf der Implementation unterschiedenwerden können, hebt dies auch in der Implementati-onsansicht die Unterschiede zwischen Schnittstelleund Implementation einer Klasse hervor.

Tabelle C.4: Schnittstellenabhängigkeiten hervorheben

74

Beschreibung Auf verborgene Klassen hinweisenAnzahl der Gruppen 2Kommentar Dies könnte unterstützend sein, wenn ein kompletter

Überblick über das Projekt gewünscht wird. Hierbeikönnte ein kleines Icon ö.ä. darauf hinweisen, dassdurch einen Wechsel der Ansicht einer spezifischenKlasse weitere Klassen sichtbar werden.

Tabelle C.5: Auf verborgene Klassen hinweisen

Beschreibung Vollständiges UML-Diagramm in der Klassenan-sicht

Anzahl der Gruppen 2Kommentar Diese Funktionalität wurde bereits in

mehreren Erweiterungen umgesetzt[BLUEJ-GEMEINSCHAFTa]. Wird eine einzel-ne Klasse benutzt, müsste nicht mehr auf dieDokumentation zurück gegriffen werden um alleangebotenen Operationen zu sehen. Die ange-botenen Operationen für jede Klasse in demKlassendiagramm anzuzeigen könnte das Dia-gramm unnötig „aufblähen“ und dies könnte vonden Benutzern als unangenehm empfunden werden.

Tabelle C.6: Vollständiges UML-Diagramm anzeigen

Beschreibung Implementationen eines Interfaces anzeigenAnzahl der Gruppen 2Kommentar Wenn in einer Operation ein Exemplar eines Inter-

faces erwartet wird, ist es für den Benutzer dieserOperation nicht zwangsläufig von Interesse, welcheAbhängigkeiten dieses Interface besitzt. Es wird le-diglich eine Implementation dieses Interfaces ge-wünscht.

Tabelle C.7: Implementationen von Interfaces anzeigen

75

76

D Inhalt der beigefügten CD-ROM

In der dieser Arbeit begefügten CD-ROM befinden sich das in dieser Arbeit entwickelte BlueJ-CP sowohl in installierbarer Binärform, als auch im Quelltext. Zudem befindet sich diese Ba-chelorarbeit als PDF auf der CD-ROM.

Konsumieren und Produzieren in BlueJ.pdf Diese BachelorarbeitBlueJ-CP Der Quelltext von BlueJ-CPBlueJ-CP-generic.jar Der generische Installer von BlueJ-CPDatenStudie.ods Die Rohdaten der Benutzerstudie

77

Eidesstattliche ErklärungIch versichere, dass ich die vorstehende Arbeit selbständig und ohne fremde Hilfe angefertigtund mich anderer als der im beigefügten Verzeichnis angegebenen Hilfsmittel nicht bedienthabe. Alle Stellen, die wörtlich oder sinngemäß aus Veröffentlichungen entnommen wurden,sind als solche kenntlich gemacht. Alle Quellen, die dem World Wide Web entnommen oder ineiner sonstigen digitalen Form verwendet wurden, sind der Arbeit beigefügt.

Ich bin mit einer Einstellung in den Bestand der Bibliothek des Departments Informatik einver-standen.

Hamburg, den Unterschrift: