Dynamische Klassendiagramme - Nutzung der Metapher vom „Konsumieren und Produzieren“ in BlueJ Axel Schmolitzky und Chris Stahlhut, Universität Hamburg {schmolit, 6stahlhu}@informatik.uni-hamburg.de Zusammenfassung ren Zeitpunkt ausführlich zu behandeln (sie so damit Konsumieren und Produzieren sind zwei Seiten der- vertraut zu machen, dass sie es produktiv einsetzen selben Medaille. Wir untersuchen seit einigen Jah- können). Dieser simple Kniff ermöglicht es an etlichen ren die Metapher vom Konsumieren und Produzieren Stellen, die gerade bei der Objektorientierung häu- (kurz: K&P-Metapher) im Umfeld der Lehre objekt- fig zirkulären Abhängigkeiten von Grundkonzepten orientierter Programmierung. etwas aufzubrechen. In diesem Artikel stellen wir eine Erweiterung der In (Schmolitzky u. Züllighoven, 2007) haben wir für die Lehre der objektorientierten Programmierung dazu bereits einige Beispiele aus dem Bereich der Pro- entwickelten Entwicklungsumgebung BlueJ vor. Diese grammierung angeführt. Unter anderem haben wir Erweiterung führt die bereits in BlueJ implizit vorhan- Generizität in Java als ein Konzept aufgeführt, das für dene Unterstützung der K&P-Metapher konsequent den Umgang mit generischen Sammlungen in Java fort, indem sie auch im BlueJ-Klassendiagramm dyna- anfänglich nur konsumiert zu werden braucht (sprich: misch die Unterscheidung zwischen dem Konsumieren wie gibt man bei der Deklaration einer Sammlung und dem Produzieren einer Klasse ermöglicht. den Typ ihrer Elemente an), und können so in einer Erstsemesterveranstaltung die sehr nützlichen Samm- Einleitung lungen des Java Collections Framework (JCF) relativ früh thematisieren. Erst deutlich später (im darauf Konsumieren und Produzieren sind zwei Seiten der- folgenden Semester) thematisieren wir Generizität selben Medaille. Ein Buch kann gelesen (konsumiert) so, dass die Studierenden selbst generische Klassen und geschrieben (produziert) werden, ein Tisch be- produzieren können. nutzt oder gebaut, eine Software genutzt oder entwi- ckelt werden. Zur Verdeutlichung kann im Kontrast dazu eine an- Damit ein Artefakt (ein Gegenstand, ein Text, ein dere Sicht dargestellt werden, wie sie beispielsweise Konzept) konsumiert werden kann, muss es zuerst in einem Lehrbuch von Liang umgesetzt ist (Liang, produziert werden. Bevor ein Buch gelesen werden 2010). Hier wird das JCF sehr spät (in Kapitel 22) kann, muss es geschrieben werden. Bevor ein Tisch für angesprochen; vermutlich deshalb, weil die Autoren eine Mahlzeit genutzt werden kann, muss er gebaut der Meinung sind, dass vor dem Umgang mit generi- werden. Bevor Software benutzt werden kann, muss schen Sammlungen grundsätzlich geklärt sein muss, sie programmiert werden. Im Allgemeinen gilt dabei, was Generizität ist (Kap. 21). Ein weiteres Beispiel dass das Produzieren deutlich anspruchsvoller ist als für dieses Denken findet sich in (Ashok u. a., 2008). das Konsumieren; eine für sich genommen triviale Auf diese Weise wird ein zentrales und nützliches Kon- Erkenntnis. zept (Sammlungen) aufgrund einer vermeintlichen Wir untersuchen seit einigen Jahren die Meta- formalen Abhängigkeit von einem anderen Konzept pher vom Konsumieren und Produzieren (kurz: K&P- (Generizität) aus unserer Sicht unnötig „nach hinten Metapher) im Umfeld der Lehre der objektorientierten geschoben“. Programmierung (Späh u. Schmolitzky, 2007). Bei un- In diesem Artikel liegt der Fokus nicht auf dem serer Didaktik machen wir uns dabei zunutze, dass Konsumieren und Produzieren von Konzepten in der Konsumieren leichter als Produzieren ist: Häufig ver- Lehre, sondern auf dem Konsumieren und Produzie- mitteln wir unseren Studierenden ein zu verstehendes ren von Klassen in der objektorientierten Programmie- Konzept nur in einer „abgespeckten“ Version (lassen rung (OOP). Während ein Dozent die Entscheidung, sie es nur konsumieren), um es erst zu einem späte- welcher Anteil eines Konzeptes konsumierend und Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 21 von 44 welcher produzierend betrachtet werden soll, mehr K&P in BlueJ bisher oder weniger willkürlich treffen kann, gibt es bei den BlueJ ist eine für die Lehre des objektorientierten Klassen der OOP klar definierte Eigenschaften, die für Programmierparadigmas entworfene Entwicklungs- Klienten einer Klasse einerseits und für die Entwickler umgebung (engl. abgekürzt: IDE) für Java. Sie ist einer Klasse andererseits relevant sind. Dies macht sie wie Eclipse frei verfügbar, hat aber im Gegensatz einer automatisierten Darstellung zugänglich. zu Eclipse nicht den Anspruch, eine vollwertige IDE Im nächsten Abschnitt werden wir zuerst einige Be- für die professionelle Softwareentwicklung darzustel- griffe benennen, die für die nachfolgende Diskussion len; BlueJ ist gezielt minimalistisch ausgelegt, um grundlegend sind. Abschnitt 3 stellt dar, auf welche Programmieranfängern die Kernkonzepte der objekt- Weise die K&P-Metapher bisher in der Lehrumgebung orientierten Programmierung zu vermitteln und diese BlueJ umgesetzt ist. Abschnitt 4 zeigt, wie dies kon- nicht mit umfangreicher Funktionalität zu überwälti- sequent fortgeführt werden kann, und stellt eine pro- gen (Kölling u. a., 2003). BlueJ wird weltweit inzwi- totypische Implementation vor. Abschnitt 5 diskutiert, schen von fast 1000 Hochschulen eingesetzt (BlueJ, wie die bisherigen Erkenntnisse gewinnbringend ein- 2010). gesetzt werden könnten. Abschnitt 6 fasst die Arbeit zusammen. K&P in der Objektorientierung Ein zentraler Gedanke der Objektorientierung ist, dass die Zuständigkeiten für die Aufgaben eines Systems auf verschiedene Objekte verteilt werden und diese Objekte sich gegenseitig benutzen. Ein Objekt, das ein anderes benutzt, bezeichnen wir als einen Klienten; ein Objekt, das benutzt wird, als einen Dienstleister. Jedes Objekt kann sowohl Klient als auch Dienstleister sein. Ein weiterer zentraler Gedanke der Objekt- orientierung (und der Softwaretechnik) ist, dass bei einem Objekt zwischen seiner Schnittstelle und sei- ner Implementation unterschieden werden kann. Über Abbildung 1: Das Hauptfenster von BlueJ seine Schnittstelle bietet ein Objekt seine Dienstleis- tungen an; in der Implementation wird dieses Ange- BlueJ stellt die Klassen eines Java-Projektes, anders bot umgesetzt. Diese Unterscheidung wird deutlicher, als übliche IDEs, nicht in Listenform dar, sondern in wenn der Fokus von den Objekten auf die sie defi- Form eines einfachen UML-Klassendiagramms (Ab- nierenden Klassen gerichtet wird: In Java wird syste- bildung 1). BlueJ visualisiert mit diesem Diagramm matisch zwischen der Schnittstelle einer Klasse und nicht nur die Struktur des Projektes, sondern bietet ihrer Implementation unterschieden, indem die mit auch direkte Interaktionsmöglichkeiten mit den dar- dem Werkzeug javadoc erzeugte Dokumentation ei- gestellten Klassen und ihren Exemplaren: Es können ner Klasse üblicherweise ihre Schnittstelle darstellt, interaktiv Exemplare dieser Klassen erzeugt und an während der Quelltext der Klasse ihre vollständige diesen Exemplaren dann alle Methoden aufgerufen Implementation wiedergibt. werden. Ein Programmierer eines Klienten, der Exemplare Aufgrund der Möglichkeit, Klassen und Objekte in- einer anderen Klasse ausschließlich benutzen will, kon- teraktiv zu benutzen, ohne Quelltext schreiben zu sumiert die andere Klasse lediglich. Er muss idealer- müssen, kann bei der Benutzung von BlueJ bereits weise nur ihre Schnittstelle kennen (die auch explizit zwischen konsumierenden und produzierenden Per- in Form eines Java-Interfaces beschrieben sein kann), sonen unterschieden werden. Eine konsumierende um qualifiziert als Klient auftreten zu können. Erst Person kann Klassen und Objekte benutzen, ohne wis- wenn ein Programmierer die andere Klasse warten sen zu müssen, wie diese mit Java erstellt werden. muss (Fehler beheben muss, ihre Funktionalität erwei- Nur eine produzierende Person, also jemand, der Klas- tern muss, etc.), muss er ihren Quelltext bearbeiten sen in ihrem Quelltext verfasst, muss mehr über Java und kann in Bezug auf ihre Dienstleistungen produ- wissen (Syntax, Bibliotheksklassen, etc.). Der Object- zierend aktiv werden. First-Ansatz von Barnes und Kölling (Barnes u. Kölling, Die Essenz lautet: eine Klasse konsumieren erfor- 2009) basiert sehr stark auf diesen Möglichkeiten. dert nur die Kenntnis ihrer Schnittstelle; eine Klasse Der in BlueJ integrierte Editor zum Bearbeiten von produzieren erfordert zwingend Einblick in ihre Im- Klassendefinitionen bietet zwei Sichten: eine konsu- plementation. Beide Sichten auf eine Klasse finden mierende, die die von javadoc für die Klasse erstell- sich auch in der Entwicklungsumgebung BlueJ wieder, te (und nicht interaktiv änderbare) Schnittstellen- allerdings nur unvollständig. beschreibung darstellt (Schnittstellensicht); und eine Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 22 von 44 produzierende Sicht, die den vollständigen Quelltext Wenn ein Klient der Klasse TitelListe geschrieben der Klasse darstellt und bearbeitbar macht (Quelltext- werden soll (etwa eine Komponente, die Wiederga- sicht). belisten auf dem Bildschirm darstellt), kann der Pro- grammierer diese Klasse im BlueJ-Editor betrachten, um die aufrufbaren Operationen vor sich zu haben. Da den Programmierer somit nur die Schnittstelle in- teressieren muss, kann dazu die Schnittstellensicht des Editors gewählt werden (Abbildung 3). Diese Sicht verbirgt alle Implementationsdetails, unter anderem auch die Abhängigkeit zu der Klasse ListenKnoten; ein Effekt, der im Sinne des Geheim- nisprinzips nur erwünscht sein kann. Abbildung 2: Ein Klassendiagramm in BlueJ Für die nachfolgende Diskussion soll ein Beispiel das Verständnis erleichtern: In einem Lehrprojekt, das fachlich einen MP3-Player modellieren soll, werden neben den abzuspielenden Musiktiteln auch Wieder- gabelisten benötigt. Das BlueJ-Projekt dazu enthält deshalb neben der Klasse Titel auch eine Klasse TitelListe. Objekte der Klasse TitelListe sollen alle Eigenschaften aufweisen, die eine Liste üblicher- weise anbietet: Die Reihenfolge der Elemente ist frei manipulierbar und es können beliebig Duplikate ein- gefügt werden (eine Semantik, die offensichtlich gut zu einer Wiedergabeliste von Musiktiteln passt). Ent- sprechend bietet ihre Schnittstelle Operationen wie einfuegenAnPosition, entferneAnPosition etc. an. Die Klasse TitelListe sei intern als doppelt verkettete Abbildung 4: Die Quelltextsicht im BlueJ-Editor Liste von Knotenelementen umgesetzt, die neben den Verkettungsreferenzen jeweils eine Referenz auf einen Erst wenn die Implementation der Klasse Titel halten sollen (in dem Lehrprojekt geht es um TitelListe selbst betrachtet oder bei Wartungsarbei- verschiedene Implementationsformen für Listen). Die- ten verändert werden soll, muss in die Quelltextsicht se Knotenelemente seien in der Klasse ListenKnoten des Editors gewechselt werden. Diese Sicht unter- realisiert. Abbildung 2 zeigt diese Zusammenhänge in scheidet sich nur geringfügig (primär durch die einem BlueJ-Klassendiagramm. Blockhervorhebung, Abbildung 4) von der anderer Editoren. BlueJ unterstützt somit mit den beiden Sichten im Editor direkt die K&P-Metapher: Klienten können eine Klasse nur konsumieren (müssen nur die Informatio- nen sehen, die für eine Benutzung notwendig sind: die Schnittstellensicht), während Wartungsprogram- mierer den Zugriff auf den vollen Quelltext benötigen, um produzierend tätig werden zu können. K&P in BlueJ fortgeführt Die Klasse TitelListe hat eine in ihrer Schnitt- stelle definierte Benutzt-Beziehung zu der Klas- se Titel, während die Beziehung zu der Klasse ListenKnoten nicht zu ihrer Schnittstelle gehört. Die Klasse ListenKnoten benutzt ebenfalls die Klasse Titel. Alle drei Abhängigkeiten werden im BlueJ- Klassendiagramm durch Pfeile dargestellt, siehe Ab- bildung 2. Da es sich bei der Klasse Titel um den Element- Abbildung 3: Die Schnittstellensicht im BlueJ-Editor typen der Liste handelt, ist die Abhängigkeit in der Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 23 von 44 Schnittstelle der Klasse TitelListe unumgänglich; Ausblenden von Klassen erwartungsgemäß muss ein Klient einer TitelListe Da im Kontext unseres Beispiels allein die Klasse damit rechnen, Titel als Parameter zu übergeben TitelListe die Klasse ListenKnoten benutzt, kann (obwohl nicht alle Operationen der Klasse explizit mit letztere als ein ausgelagertes Implementationsdetail Titeln umgehen müssen, siehe oben). betrachtet werden. Aus Sicht eines Klienten der Es ist hingegen für einen Klienten eher nachrangig, TitelListe ist nicht nur die Benutzt-Beziehung zwi- wie die Klasse TitelListe implementiert ist. Der Um- schen den beiden Klassen irrelevant, sondern die kom- stand, dass dies in einer verketteten Liste passiert, ist plette Klasse ListenKnoten; sie muss in der Konsu- für die Benutzung üblicherweise irrelevant. Dies wird mentensicht der Klasse TitelListe nicht angezeigt auch in den beiden Editor-Darstellungen der Klasse werden. Abbildung 6 zeigt eine in dieser Hinsicht deutlich: In der Schnittstellensicht ist lediglich die konsequente Darstellung des Projekts mit der Konsu- Klasse Titel aufgeführt, während im Quelltext der mentensicht der TitelListe. Dieses Diagramm ist Klasse auch die Klasse ListenKnoten auftaucht. deutlich einfacher, ein von uns erwünschter Effekt; durch das Umschalten von Klassen in ihre Klienten- sicht soll die Komplexität des Diagramms reduziert werden können. Abbildung 5: Klientensicht der TitelListe Abbildung 6: Die konsequente Klientensicht Diesen Unterschied könnten wir auch im Klassen- diagramm darstellen, indem wir eine Klientensicht auf Für unsere Erweiterung ergibt sich somit ein rein die Klasse TitelListe postulieren: in dieser Sicht be- formales Kriterium, nach dem Klassen verborgen wer- steht lediglich eine Abhängigkeit zur Klasse Titel den können: Zeigt das momentane Klassendiagramm (Abbildung 5). Die Darstellung der TitelListe in eine Abhängigkeit zu einer Klasse A, so ist diese Klasse Abbildung 2, in der alle Abhängigkeiten der Klasse ge- anzuzeigen. Dies ist von der Art der Abhängigkeit (ba- zeigt werden, nennen wir hingegen ihre Produzenten- sierend auf der Schnittstelle oder nicht) unabhängig. sicht. Da Produzenten einer Klasse ihren Quelltext er- Benutzen zwei Klassen B und C dieselbe Klasse A, so stellen/bearbeiten, sollten für sie alle Abhängigkeiten ist A anzuzeigen, wenn min. eine eingehende Abhän- sichtbar sein. gigkeit angezeigt wird. Eine Klasse wird also nur ver- Die Darstellung in Abbildung 5 stammt aus einer borgen, wenn sie im momentanen Klassendiagramm von uns entwickelten Erweiterung von BlueJ, die ein keine eingehenden Abhängigkeiten besitzt. interaktives Umschalten zwischen den beiden Sichten Wird ein Projekt erstmalig in BlueJ-CP geöffnet, auf jede Klasse im Klassendiagramm ermöglicht. Wir könnte für alle Klassen die Klientensicht gewählt wer- nennen diese Erweiterung im Folgenden kurz BlueJ- den, in der Hoffnung, dass dies einen ersten „high- CP. level“ Überblick vermittelt, weil transitiv alle Imple- Die grundsätzliche Möglichkeit zweier Sichten auf mentationsdetails ausgeblendet sind. Bei der Wahl jede Klasse führt in BlueJ-CP dazu, dass es nicht nur der anfangs anzuzeigenden Klassen sind jedoch einige ein statisches, sondern eine Vielzahl von möglichen Dinge zu beachten. Klassendiagrammen für dasselbe Projekt gibt. Durch die interaktive Möglichkeit des Wechsels der Sichten Einstiegspunkte für Java klassisch wird das statische Klassendiagramm zu einem dy- Einen offensichtlichen Einstiegspunkt in eine allgemei- namischen Klassendiagramm. Bei einem Projekt mit ne Java-Anwendung bietet die main-Methode. Klas- n Klassen ergeben sich bis zu 2n mögliche Klassen- sen, die eine Methode mit einer speziellen Signatur diagramme. Das zu einem bestimmten Zeitpunkt an- anbieten (es kann mehrere in einem Projekt geben), gezeigte Klassendiagramm bezeichnen wir als das mo- bilden somit einen guten Ausgangspunkt. Im Idealfall mentane Klassendiagramm. verfügt genau eine Klasse über eine main-Methode. Um die Unterscheidung visuell stärker zu verdeutli- Diese Klasse wird in der Klientensicht angezeigt und chen, haben wir für die Darstellung der Klientensicht ist somit möglicherweise sogar die einzige Klasse, die auch das Klassensymbol leicht verändert: der untere im momentanen Klassendiagramm angezeigt werden Teil erscheint weiß. Für die Produzentensicht haben muss. Erst durch das Umschalten bei dieser Klasse wir nichts am Symbol verändert, weil dies der bisheri- auf die Produzentensicht werden die Klassen sichtbar, gen Darstellung in BlueJ entspricht. die im Rumpf der main-Methode benutzt werden. Auf Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 24 von 44 diese Weise kann ein Klassendiagramm nach und nach In der Programmierausbildung „entfaltet“ werden. Idealerweise würden die Teilnehmer an einer einfüh- Java-Pakete verfügen ebenfalls über eine Schnitt- renden Programmierveranstaltung gar nicht merken, stelle, sie besteht aus allen öffentlichen (mit dem Modi- dass sie mit einem veränderten BlueJ arbeiten, und fikator public deklarierten) Klassen. Nur die auf diese an passender Stelle würden die zusätzlichen Möglich- Weise „exportierten“ Klassen können aus anderen Pa- keiten von BlueJ-CP zum Einsatz kommen. Wir haben keten benutzt werden, alle anderen Klassen gehören in dieser Hinsicht bisher noch keine belastbaren Er- zur Implementation eines Paketes. fahrungen sammeln können. Die öffentlichen Klassen eines Pakets (insbesondere Immerhin haben wir mit 23 freiwilligen Teilneh- der Pakete, die keine main-Methode enthalten) stellen mern einer Erstsemesterveranstaltung eine kleine Stu- somit weitere sinnvolle Einstiegspunkte dar, die initial die durchgeführt, in der sie eine Vorversion von BlueJ- bei der Darstellung eines Paketes sichtbar sein sollten. CP alternativ zu BlueJ bei der Lösung einer Übungs- Auch sie sollten anfangs in der Klientensicht darge- aufgabe einsetzen konnten (Stahlhut, 2010). Ein Er- stellt werden (inklusiv ihre transitiven Schnittstellen- gebnis dieser Studie war, dass 21 der 23 Probanden Beziehungen) und können bei Bedarf aufgefaltet wer- der Meinung waren, dass BlueJ-CP beim Verständnis den. der Konzepte Schnittstelle und Implementation unter- Eine Ausnahme stellen JUnit-Testklassen dar. Die- stützt, während 2 Probanden es nicht als unterstüt- se Klassen müssen nur deshalb öffentlich sein, damit zend empfunden haben. 18 von 23 empfanden es als sie vom JUnit-Rahmenwerk gefunden und ausgeführt angemessen, Klassen benutzungsabhängig verbergen werden können, und gehören somit nicht zur Schnitt- zu können (bei 5 Enthaltungen). stelle eines Pakets. Zur Reduktion der Diagramm- Die Erkenntnisse aus dieser Studie sind primär Komplexität können sie gesondert ausgeblendet wer- in die Weiterentwicklung von BlueJ-CP eingeflossen; den. aber das Feedback aus den geführten Interviews lässt deutlich darauf schließen, dass die interaktive Mög- Einstiegspunkte für BlueJ lichkeit zweier Sichten auf eine Klasse, intelligent ein- Das Problem mit beiden Einstiegsheuristiken (main- gesetzt, beim Verständnis von Kapselung und Schnitt- und öffentliche Klassen) ist, dass sie nicht gut für ech- stellen hilfreich sein kann. te BlueJ-Projekte funktionieren: Da in BlueJ Objekte In der Visualisierung von Software interaktiv erzeugt werden und die Benutzer direkt an diesen Objekten Methoden aufrufen können, wer- Seit wir BlueJ-CP zur Visualisierung von Java- den main-Methoden nur in Ausnahmefällen implemen- Projekten zur Verfügung haben, erscheinen uns die tiert; siehe dazu unter anderem (Kölling u. Rosenberg, aus Quelltexten generierten Klassendiagramme ande- 2001). Und die Lehre-Projekte in BlueJ bestehen auch rer UML-Werkzeuge merkwürdig „flach“: Sie zeigen nur sehr selten aus mehreren Paketen (obwohl BlueJ immer alle Abhängigkeiten, unabhängig von ihrer Ein- diese auch darstellen kann), sondern meist nur aus ordnung als Schnittstellen- oder als Implementations- einem, typischerweise dem unbenannten Paket. Abhängigkeit. Die Kriterien für diese Einordnung sind rein formal und können ohne weiteres auch in ande- Für echte BlueJ-Projekte ergibt sich deshalb die auf ren Werkzeugen als in BlueJ dafür genutzt werden, den ersten Blick paradoxe Schlussfolgerung, dass ge- automatisiert verschiedene Abstraktionen desselben nau die Klassen initial dargestellt werden sollten, die Quelltextes anzubieten. nicht von anderen Klassen benutzt werden. Denn bei diesen liegt die Vermutung nahe, dass sie für den Ein interessantes Vorhaben könnte somit sein, die interaktiven Gebrauch entwickelt wurden und somit mit BlueJ-CP gesammelten Erkenntnisse auch in an- gute Einstiegspunkte sind. Auf diese Weise ist auch si- deren Werkzeugen umzusetzen; zumindest in solchen, chergestellt, dass eine gerade neu erstellte, aber noch die quelloffen zur Verfügung stehen. Wir sehen dabei unbenutzte Klasse angezeigt wird. insbesondere die Möglichkeit im Vordergrund, ein be- stehendes System mit Hilfe der beschriebenen Mittel nach und nach interaktiv aufzufalten und somit einen Einsatzmöglichkeiten objektorientierten Entwurf zu explorieren. Inwieweit Die Erkenntnisse aus unserem anfänglich rein gedank- dies wirklich beim Einlesen und Verstehen hilfreich lichen Experiment mit BlueJ und der realen Umset- ist, gälte es zu untersuchen. zung in BlueJ-CP weisen uns zwei interessante We- Ein Werkzeug, das explizit zur Untersuchung der ge: Zum einen sollte untersucht werden, inwieweit K&P-Metapher entwickelt wurde, ist jMango (Späh, BlueJ-CP sinnvoll in der Programmierausbildung ein- 2008). Es bietet neben einer filtergestützten Visualisie- gesetzt werden kann, um die Konzepte Schnittstel- rung von Java-Systemen auch eine Unterstützung für le und Implementation anschaulicher zu vermitteln. die Modellierung von Konzept-Abhängigkeiten. Die in Zum anderen scheint uns das Konzept der verschiede- einer Erstsemesterveranstaltung vermittelten Konzep- nen Sichten auf Klassendiagramme übertragbar auf te wurden mit Hilfe von jMango systematisch model- andere Werkzeuge. liert (Albers, 2009). Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 25 von 44 Da jMango als eine Eclipse-RCP-Anwendung kon- with Java. In: Information Technology in Computer struiert ist, wäre es denkbar, gezielt die Visualisie- Science Education (ITiCSE 2001), 2001 rungsmöglichkeiten für allgemeine Java-Projekte als Plugin für Eclipse anzubieten. Auf diese Weise könn- [Liang 2010] L IANG, Y. D.: Introduction to Java Pro- te das dynamische Falten von Klassendiagrammen gramming. Harlow, United Kingdom : Prentice Hall auf breiter Ebene für Java-Eclipse-Projekte zur Ver- / Pearson Education, 2010. – 8. Auflage fügung gestellt werden. Bisher fehlt in jMango aller- [Schmolitzky u. Züllighoven 2007] S CHMOLITZKY, A. dings noch ein guter Algorithmus für das automati- ; Z ÜLLIGHOVEN, H.: Einführung in die Software- sche Layouten von Klassendiagrammen (zumindest entwicklung - Softwaretechnik trotz Objektorien- als Ausgangspunkt), so dass ein gebrauchsfertiges Plu- tierung? In: A. Zeller and M. Deininger (Hrsg.), gin noch Forschungs- und Entwicklungsaufwand er- Software Engineering im Unterricht der Hochschu- fordert. len (SEUH), 2007 Zusammenfassung [Späh 2008] S PÄH, C.: Konsumieren und Produzieren Das Konsumieren einer Klasse von ihrem Produzieren als nützliche Metaphern in der Softwaretechnikaus- zu unterscheiden ist ein Kernkonzept der Objektorien- bildung und der Exploration von Klassenstrukturen, tierung, dem – softwaretechnisch breiter betrachtet – Universität Hamburg, Diplomarbeit, 2008 die Trennung von Schnittstelle und Implementation [Späh u. Schmolitzky 2007] S PÄH, C. ; S CHMOLITZKY, zugrunde liegt. Die IDE BlueJ macht diese Unterschei- A.: „Consuming before Producing“ as a Helpful dung in ihrem Editor deutlich, indem sie zwei Sichten Metaphor in Teaching Object-Oriented Concepts. In: auf eine Klasse anbietet. Eleventh Workshop on Pedagogies and Tools for the In diesem Artikel haben wir dargestellt, wie BlueJ Teaching and Learning of Object Oriented Concepts, erweitert werden kann, um diesen Unterschied auch 2007 im BlueJ-Klassendiagramm zu visualisieren. Konzeptu- ell ergab sich daraus, dass es für ein Klassendiagramm [Stahlhut 2010] S TAHLHUT, C.: Die Metapher „Konsu- mit n Klassen 2n verschiedene Darstellungen geben mieren und Produzieren“ in BlueJ, Universität Ham- kann, die ein System auf mehreren Abstraktions- burg, Bachelorarbeit, 2010 ebenen darstellen können. Diesen Umstand gilt es wei- ter zu untersuchen, sowohl in seinen Einsatzmöglich- keiten in der Lehre als auch in der Visualisierung von Softwaresystemen. Literatur [Albers 2009] A LBERS, T.: Evaluation eines prototy- pischen Werkzeuges zur Visualisierung von Konzept- abhängigkeiten unter Berücksichtigung der Metapher „Konsumieren vor Produzieren“, Universität Ham- burg, Bachelorarbeit, 2009 [Ashok u. a. 2008] A SHOK, S ; K IONG, D ; P OO, D: Object-Oriented Programming and Jav. Springer Ver- lag, 2008. – 2. Auflage [Barnes u. Kölling 2009] B ARNES, D. J. ; KÖLLING, M.: Objects First with Java — A Practical Introduction using BlueJ. Harlow, United Kingdom : Prentice Hall / Pearson Education, 2009. – 4. Auflage [BlueJ 2010] B LUE J: BlueJ — The interactive Java en- vironment. Version: 2010. http://www.bluej.org. – zuletzt besucht: 2010-12-16 [Kölling u. a. 2003] KÖLLING, M. ; Q UIG, B. ; PATTER - SON , A. ; R OSENBERG , J.: The BlueJ system and its pedagogy. In: Journal of Computer Science Educa- tion, Special issue on Learning and Teaching Object Technology (2003) [Kölling u. Rosenberg 2001] KÖLLING, M. ; R OSEN - BERG, J.: Guidelines for Teaching Object Orientation Ludewig, Böttcher (Hrsg.): SEUH 2011 Seite 26 von 44