GEH MIR AUS DEM WEG!

WAS MODELLIERUNGS-

WERKZEUGE VON WHITE-

BOARDS LERNEN KÖNNEN

reinen Abzeichnen nicht so dramatisch.Viel dramatischer ist die Lernkurve: Je häu-figer die Kandidaten ein und dasselbeDiagramm gezeichnet haben, desto schnel-ler wurden sie. Irgendwann kannten sie dasDiagramm auswendig und sparten die Zeit,die Details auf der Vorlage nachzuschauen.Dieser Effekt war praktisch unabhängigdavon, welches Werkzeug die Kandidatenin welcher Reihenfolge verwendeten. Beider Anzahl der Maus- und Tastaturaktionwar dagegen kaum eine Lernkurve zubeobachten – diese Zahlen sind eher werk-zeugspezifisch.

Allgemeine Zeichenwerkzeuge

„Ich hab das eben mit PowerPoint ge -macht.” Nicht nur Heimwerker erfindenneue Anwendungen für ihr Werkzeug.Auch junge Studenten missbrauchen Tools– wie „MS PowerPoint” oder „LibreOfficeDraw” – für das Erstellen von Klassen -

Viele grafische Editoren unterbrechen den Benutzer bei seiner Arbeit. Insbesondere UML-Modellierungswerkzeuge stören den Arbeitsfluss des Entwicklers mit Pop-Ups und derNotwendigkeit, in Werkzeugleisten herumzusuchen. Gleichwohl werden Softwarearchitektennicht in Mausmetern bezahlt. Um die Bedienbarkeit von grafischen Benutzungsoberflächen zuverbessern, muss man die Menschen dabei beobachten, wie sie arbeiten. Die daraus resultie-renden Erkenntnisse können den Arbeitsablauf dann aber auch erheblich beschleunigen.

m e h r z u m t h e m a :http://www.hessen-it.de/mm/Hessen-IT_NEWS_0310.pdf

52 53

Unabhängig davon benötigen mancheKollegen oder Kolleginnen für dasselbeDiagramm viel länger als andere. Das kannnatürlich an der jeweiligen Person liegen.Oder liegt es am verwendeten Werkzeug?Um diese Frage zu klären, haben wir eine(leider nicht öffentliche) Untersuchung ver-schiedener Modellierungswerkzeuge durch-geführt, deren Ergebnisse von der Hessen-IT, der Aktionslinie des HessischenWirt schaftsministeriums für den gesamtenInformations- und Telekommunikations -markt in Hessen, veröffentlicht wurde (vgl.[Hes10]). Dabei haben wir sowohl diejeweils benötigte Zeit, die Anzahl derMausklicks und Tastaturanschläge, diezurück gelegten Mausmeter als auch dieHäufigkeit der Wechsel zwischen Tastaturund Maus gemessen.

Vielleicht schon einmal einige Beobach -tungen vorweg: Es gibt Unterschiede zwi-schen den Personen, aber diese sind beim

„Und wer soll das lesen können?”, ist derhäufigste Kommentar, nachdem wir einKlassendiagramm am Whiteboard entwor-fen haben. Trotzdem ist das Arbeiten amWhiteboard angenehmer als die Ver wen -dung eines Modellierungswerkzeugs: Manhat zwar viel Platz und kann dasEndergebnis fotografieren und an alle ver-schicken oder einchecken – aber das machtdie Diagramme nicht unbedingt leserlicher(siehe Abbildung 1).

Wenn die Diagramme in irgendeinerDokumentation verwendet werden sollen,lassen wir sie von jemandem nachzeichnen,frei nach dem Motto: „Make it fancy!”„Wie heißt denn die Kante da?” „WelcheKardinalität soll die Assoziation da untenhaben?”

Bei einer Whiteboard-Skizze fehlen häu-fig auch einige Details. Der Kollege, der dasGanze „rein zeichnen” oder später umset-zen soll, muss dann häufig noch einmalnachfragen, was Zeit kostet, oder erergänzt selbstständig, was nicht immerrichtig sein muss. Da wünscht man sichgelegentlich doch ein Werkzeug, das einenauf fehlende Details hinweist.

f achar t i ke l

Prof. Albert Zündorf

(E-Mail: zuendorf@cs.uni-kassel.de)

leitet das Fachgebiet Softwaretechnik der

Universität Kassel. Ausgehend vom Forschungs -

projekt Fujaba unternimmt er seit über 15 Jahren

Ausflüge in verschiedenste Bereiche der Software -

technik, immer basierend auf modellgetriebener

Softwareentwicklung.

der au tor

Abb. 1: Klassendiagramm amWhiteboard.

Abb. 2: PowerPoint-„Klassendiagramm” ohne Kardinalitäten.

1/2012

Bei der Auswahl von Klassen als Typmüssen sich die Studenten leider mit einereinfachen Liste zufrieden geben. Je größerdas Modell wird, desto länger dauert dasHeraussuchen. Und wer sich unglücklichdurch die Eigenschaften der Elemente klickt,hat schnell drei Dialoge gleichzeitig geöff-net (siehe Abbildung 5). „Ich sehe dasDiagramm vor lauter Dialogen nicht.”

Der Mehrwert von Modellen

„Müsst ihr immer so lange Namen neh-men, ich tippe mir ja die Finger blutig.” –„Versuch es doch einmal mit 'SparxSystems Enterprise Architect', da kriegtman mit <Strg>+<Space> Completion.”Die meisten Softwareentwickler kennendiese Tastenkombination aus ihrer Ent -wicklungsumgebung. Bei EnterpriseArchitect kann man damit in Dialogennach Klassen suchen. Noch gewohnter istdie Kombination, wenn man eine Methodeoder ein Attribut im Diagramm mit <F2>bearbeitet und den Typ aus einer Liste mitVervollständigungen aussuchen kann (sie-he Abbildung 6). Auf diese Art lassen sichganze Methodensignaturen überarbeiten.

Studenten, die diese magischen Tastenkennen, kommen so fast um jeden Dialogherum. „Wau, das geht ja wie Brezeln ba -cken.” Unsere kleine Werkzeug-Vergleichs -studie ergab, dass Completion die Zahl derbenötigten Tastatureingaben dramatisch –d. h. um bis zu 30 % – verringern kann.Studenten, die die Tastenkürzel nicht nutz-ten, konnten zwar noch von der Ver -vollständigung profitieren, mussten aberähnlich wie bei Visio mit Dialogen arbei-ten.

Das Diagramm wieder im

Vordergrund

„Rational hat sämtliche Dialoge wegopti-miert!” Wer mit den älteren Versionen vonRational Rose bereits in Kontakt gekom-men ist, wird sich kaum vorstellen können,dass IBM den jüngeren Produkten einenkomplett überarbeiteten Editor spendierthat. Auf Dialoge wird konsequent verzich-tet.

f achar t i ke l

Abb. 3: Dia verdeckt das Diagramm mit Dialogen.

Abb. 4: Von yuml.me generiertes Klassendiagramm.

diagrammen (oder sogar Excel). In der Tatlassen sich Klassen durch einfachesGruppieren von drei Kästchen darstellenund Assoziationen durch Verbindungenabbilden (siehe Abbildung 2).

Assoziations- und Rollennamen sowieKardinalitäten fügen sie als Textfelder ein.Leider müssen sie sich dann auch selbst umdas Layout und die korrekte Syntax vonAttributen, Methoden und Parameternkümmern. „Hm, ich glaub 'Magazin' obenlinks und 'Autor' unten rechts sieht besseraus.” – „Wie lange brauchst du denn fürdas ganze Layouten?” – „Ist 'erstellt'eigentlich eine Zu-Eins- oder eine Zu-N-Assoziation?” Den Studenten in unseremBeispiel wird langsam deutlich, dass allge-meine Zeichenwerkzeuge zwar einfach zubedienen sind, ihnen aber keine inhaltlicheArbeit abnehmen können: Die Bedeutungvon Formen, Linien, und Text bleibt denProgrammen wie einem Whiteboard ver-schlossen.

UML-Zeichenwerkzeuge

„Nimm Dia oder yuml.me, mit denen kannman Klassendiagramme zeichnen!” Beidessind völlig unterschiedliche Werkzeuge,deren Diagramme uns aber regelmäßig wie-der unterkommen. Dia kennt die einzelnenArtefakte eines Klassen diagramms, aberzum Bearbeiten der Elemente müssen dieStudenten sich durch Dialoge kämpfen, diedas Klassendiagramm verdecken. Das fühltsich ungefähr so an, als müsse man einFormular ausfüllen, das das Whiteboardverdeckt, bloß weil man eine Klasse umbe-nennen möchte (siehe Abbildung 3).

Der Web-Dienst yuml.me geht einen völ-lig anderen Weg. Klassendiagramme wer-

den in einer DSL auf einer Web-Seite for-muliert und lassen sich anschließend übereine URL im PNG-, SVG- oder PDF-Format abrufen oder direkt in eine Web-Seite einbinden. Auf das Layout hat man sogut wie keinen Einfluss, aber die Dia -gramme sind optisch relativ ansprechendund ohne das Starten eines Extra-Toolsschnell zu erstellen (siehe Abbildung 4).

Die gemeinsame Schwäche der beidenTools wird den Studenten bewusst, wennsie anfangen, Klassen umzubenennen.Dann müssen sie jedes Vorkommen vonHand ändern. „Bei der Klasse, die duumbenannt hast, hast du vergessen, dieVerwendungen als Parametertyp auchumzubenennen!” Punktabzug für Inkonsis -tenz.

Mit Dialogen zum Modell

„Bei Visio kann mir das nicht passieren:Das baut ein Modell zum Diagramm auf.”Das ist ein großer Schritt nach vorne, dennVisio stellt die Diagrammelemente in einemModell-Explorer als Baum dar. Diagrammesind Sichten, die Teile des Modells visuali-sieren. Benennt man Elemente um, werdenalle Vorkommnisse in Diagrammen ent-sprechend aktualisiert. Mit Ausnahme desKlassennamens lassen sie sich allerdingsnur mit Dialogen bearbeiten.

kann. Verbindungen zwischen den Klassenwerden mit der rechten Maustaste vonKlasse zu Klasse gezogen.

Diagrammelemente können überarbeitetwerden, indem man sie selektiert und ein-fach anfängt zu tippen (siehe Abbildung 8).„Beim Aufziehen von Klassen hat man wie-der das Gefühl, selbst ein Diagramm zuzeichnen, aber warum muss ich das nochselbst machen, wenn die Informationendoch schon im Quellcode vorliegen?”

Agiles Reverse-Engineering

„Hast du einmal versucht, Code wiederein zu lesen?” Hier beginnt eine weitere Lei -densgeschichte unserer Studenten. SobaldQuellcode vorliegt, will niemand mehr die

54 55

Ein Whiteboard mit Modell

„Mit UML Lab kannst du wirklich wie aneinem Whiteboard arbeiten.” Bei YattaSolutions wurde ein Klassendiagramm-Editor entwickelt, mit dem man seineKlassen wie auf einem Whiteboard zeich-net und dabei mit Vervollständigung ausdem Modell unterstützt wird. Das Anlegenvon Klassen geschieht durch das Aufzieheneines Rechtecks auf dem Diagramm.Danach ist die Klasse selektiert und mankann damit beginnen, Klassenname sowieAttribut- und Methodensignaturen einzu-tippen. Ähnlich wie bei Rational SoftwareArchitect wird eine Vervollständigungangeboten, die aber zwischen Klassen imDiagramm und Modell unterscheiden

Klassen, Attribute und Methoden wer-den direkt im Diagramm editiert (sieheAbbildung 7). „Wow, die sind weit gekom-men!” – „Naja, nach der dritten Klasse binich ziemlich genervt. Ich muss jedes Malzwei Sekunden warten, wenn ich auf dieDiagrammfläche klicke, um eine neueKlasse anzulegen.” Wie bereits einleitenderwähnt, ist die Lernkurve bei den einzel-nen Werkzeugen relativ konstant. Dafürbaut sich eine Erwartungshaltung auf: Mitder Zeit gewöhnt sich der Benutzer anMauswege und Abläufe. Er lernt, wo erhinklicken muss. Im schlimmsten Fall musser dadurch auf das Tool warten, stattanders herum.

f achar t i ke l

Abb. 5: Visio legt sogar mehrere Dialoge übereinander.

Abb. 6: Enterprise Architect blendet passende Modellelemente ein.

1/2012

Klassendiagramme dafür selbst zeichnen. Alle professionellenModellierungswerk zeuge bieten das Einlesen von Quellcode an,aber von den Ergebnissen sind die Studenten mehr als enttäuscht.„Warum hat er die Assoziation jetzt nicht erkannt?” – „Warumhat er die Getter und Setter für den Namen ausgeblendet, aber fürdie Adresse nicht?” –„Na toll, die Klasse passt ja nicht mal auf denBildschirm!”

Technisch arbeiten die meisten Tools mit einer Heuristik, die ver-sucht, zusammengehörige Artefakte wieder zusammenzufassen. BeiZugriffsmethoden für JavaBean-Properties funktioniert das nochrelativ gut. Heuristiken versagen allerdings bei angepasstenZugriffsmethoden oder Asso ziationsimplementierungen.

UML Lab beschreitet hier einen interessanten neuen Ansatz, beidem Imple mentierungsdetails über ein template-basiertes Reverse-Engineering vor dem Modell verborgen werden. Je mehrImplementierungsdetails man in Templates beschreibt, desto über-sichtlicher werden die Klassendiagramme. „Ich hab ein eigenesTemplate für unseren PropertyChange-Mechanismus geschrieben.Jetzt zeigt er das als Stereotyp für das Attribut an, anstatt Getterund Setter im Diagramm zu zeigen. Die sind ja ohnehin überallgleich implementiert.”

Kontextbezogene Diagramme

„Mich interessiert so einiges nicht, was ich im Klassendiagrammsehe. Kann man nicht nur die Elemente anzeigen, an denen mangearbeitet hat, wie bei Mylyn?” Wer schon einmal die Übersichtüber den eigenen Quellcode verloren hat, sollte sich mit denProdukten von Tasktop beschäftigen. Mittlerweile gehört Mylynzum Bestandteil der Eclipse-IDE und auch eine Visual-Studio-Integration ist verfügbar. Mylyn lernt, welche Methoden in einembestimmten Kontext, z. B. bei der Arbeit an einem Ticket, auseinem Bug-Tracker verwendet wurden. Alle anderen Elemente wer-den ausgeblendet: Im Project Explorer verschwinden nicht berühr-te Klassen und Packages, nicht relevante Break-Points werden aus-geblendet und lediglich der relevante Kontext bleibt übrig.

Yatta Solutions hat dieses Konzept in UML Lab auch aufKlassendiagramme übertragen. Mit der Mylyn-Integration wird esmöglich, sich ein Klassendiagramm anzeigen zu lassen, in dem nurdie für einen Task relevanten Klassen, Attribute und Methoden

sichtbar sind, ohne dass man selbst zeichnen muss. Die Übersicht-lichkeit von Klassendiagrammen wird so auch in agilen Projektenauf Knopfdruck nutzbar.

Verteiltes Arbeiten

„Super, wir haben jetzt das grobe Modell zusammen. Am bestenmacht jeder von euch die Feinmodellierung für sich und wir treffenuns morgen wieder, um das zusammenzuführen.” Eigentlich ist daseine Horrorvorstellung für jeden, der schon eimal versucht hat,Modellinformationen zu mischen. Woran liegt das?

Wenn mehrere Leute an dem gleichen Modell arbeiten wollen,gibt es im Wesentlichen zwei Möglichkeiten: Entwe der hat man einmehrbenutzer-fähiges Tool, wie zum Beispiel TeamViewer oderGoogle Docs, oder ein altes CASE-Tool, das die Modelle in einerzentralen Datenbank editiert. Das heißt: Eigentlich arbeiten alleauf dem gleichen Modell, nur mit vielen Mäusen und Tastaturen –oder jeder hat seine eigene Modellkopie. Jeweils eigene Kopien derModelle zu haben, entkoppelt die einzelnen Modellierer. Jederkann seine Änderungen in Ruhe ausprobieren, ohne von den Ände-rungen der anderen gestört zu werden. Aber wenn jeder seine eige-ne Modellkopie hat, muss man die verschiedenen Änderungennachher wieder in eine gemeinsame Version zusammenführen. BeiQuelltext macht man das mit Versions verwaltungssystemen wieSubversion oder Git, wo das auch prima klappt. Bei Modelldateienklappt das normalerweise gar nicht. Nach dem Merge sind dieModelldateien nicht mehr ladbar und man muss mühsam in denXML-Formaten herumbasteln, damit man überhaupt weiter arbei-ten kann. Abhilfe schaffen hier nur meist sehr teureModellierungswerkzeuge, die die Modelle selbst versionieren kön-nen. Oder man nimmt einen universitären Prototyp wie Fujabaoder SiDiff.

Neuerdings gibt es hier eine dritte Alternative durch Werkzeugemit guter Round-Trip-Engineering-Funktionalität. Jeder generiertaus seiner Modellkopie einfach Quelltext, der dann versioniert undgemerged wird. Nach dem Merge lädt man den Quelltext wiederins Model lierungswerkzeug – voila. Merge-Konflikte muss manzwar auf der Quelltext-Ebene behandeln, aber das ist allemal bes-ser als in den XML-Modell-Dateien. Insgesamt funktioniert das beiunseren Studenten mit UML Lab schon ganz gut. Man verliert

f achar t i ke l

Abb. 7: Rational Software Architect verzichtet vollständig aufDialoge.

Abb. 8: Vervollständigung und Arbeiten im Diagramm bei UMLLab.

und Yatta Solutions haben für dieWerkzeuge „Papyrus” respektive „UMLLab” bereits Prototypen für einen grafi-schen Merge gezeigt, mit denen sie diesesProblem angehen wollen.

Fazit

Einfache Modellierungswerkzeuge wie Diaoder Visio stehen dem Entwickler häufig imWeg, da sie Teile des Diagramms unterDialogen begraben. Die professionellenWerkzeuge von Sparx Systems und IBMhaben dieses Stadium größtenteils hintersich gelassen. Sie bieten die Möglichkeit, imDiagramm zu arbeiten, und beschleunigendie Arbeit, indem sie eine Vervoll ständi -gung basierend auf dem Modell anbieten.

UML Lab ging aufgrund der neuenEingabemöglichkeiten im Klassendia -gramm-Editor bereits in unserer Studie alsSieger hervor. Die damals erreichten 16 %Zeitersparnis kann es mit template-basier-tem Reverse-Engineering und kontextba-sierten Klassendiagrammen noch weitersteigern. Die in diesem Artikel angespro-chenen Werkzeuge, Bewertungskriterienund Einsatzzwecke fasst Tabelle 1 zusam-men.

Viel wichtiger ist jedoch, dass Model -lierungswerkzeuge nicht mehr nur Pro -bleme am Anfang des Entwicklungs -prozesses lösen. Sie dringen in dieImplementierungsphase vor, werden selbstflexibler und helfen so, auch bei agilemVorgehen den Überblick über großeSoftware zu behalten.

Der Trend geht endlich in die richtigeRichtung. Es wird Zeit, dass Software -entwickler sich nicht mehr mit umständ-lichen Werkzeugen selbst quälen. Auf meinem Tablet kann ich jetzt Klassen -diagramme entwerfen, als wäre es ein intelli-gentes Blatt Papier. Fehlt nur noch ein sechsQuadratmeter großer Touchscreen. ■

56 57

Neben dem Merge möchte man manch-mal auch die Änderungen, also das Diff aufModellebene, angezeigt bekommen. OBEO

zwar manchmal etwas Layout, aber dielogischen Dinge kriegt man ganz gutzusammen.

f achar t i ke l

Link

[Hes10] Hessisches Ministerium für

Wirtschaft, Verkehr und Landesentwicklung,

Hessen-IT News, 2010, siehe: http://www.hes-

sen-it.de/mm/Hessen-IT_NEWS_0310.pdf

Grafischer Editor ● ● ● ○ ● ● ● ●

Layout anpassbar ● ● ● ○ ● ● ● ●

Autolayout ○ ○ ○ ● ● ● ● ●

Modell ○ ○ ○ ○ ● ● ● ●

Views ○ ○ ○ ○ ● ● ● ●

Layers/Filter ○ ○ ○ ○ ● ● ● ○

Auto-Completion ○ ○ ○ ○ ○ ● ● ●

Dialogfrei ○ ● ○ ● ○ ○ ● ●

Wartezeitfrei ○ ● ● ○ ● ● ○ ●

Gestenerkennung ○ ○ ○ ○ ○ ○ ○ ●

Anpassbare Codegenerierung ○ ○ ○ ○ ○ ● ○ ●

Templates zum

Reverse-Engineering ○ ○ ○ ○ ○ ○ ○ ●

Round-Trip-Engineering ○ ○ ○ ○ ○ ○ ○ ●

Kontextbasierte Diagramme

(Mylyn Integration) ○ ○ ○ ○ ○ ○ ○ ●

Alle 14 UML-Diagrammarten ● ○ ○ ○ ● ● ● ○

Gemeinsames Modellieren ● ○ ○ ○ ○ ○ ○ ●

Verteiltes Arbeiten ○ ○ ○ ○ ○ ○ ○ ●

Geeignet für

Whi

tebo

ard

Pow

erP

oint

/

Libr

e D

raw

Dia

yum

l.me

Vis

io

Ente

rpri

se

Arc

hite

ct

Sof

twar

e

Arc

hite

ct

UM

L La

b

Team

-

besp

rech

ung

Prä

sent

atio

nen –

Dar

stel

lung

von

Rev

erse

Engi

neer

ing

Web

seite

n

Ver

mis

chen

von

Dia

gram

mar

ten

Des

ign

Des

ign

Rou

nd T

rip,

Agi

les

Arb

eite

n

Tabelle 1: Werkzeuge, Bewertungskriterien und Einsatzzwecke.