Brauchbarkeit von Freeware und unentgeltlichen Community –Versionen kommerzieller UML – Werkzeuge

Hochschule Bremen – University of Applied SciencesAndrzej Sonnek [asonnek@stud.hs-bremen.de]

Prof. Dr.–Ing. Andreas Spillner [spillner@informatik.hs-bremen.de]

1 ZusammenfassungIn diesem Bericht werden die Ergebnisse der Studienar-beit mit dem Thema: ”Evaluation von UML – Werkzeu-gen“ prasentiert, die an der Hochschule Bremen im Som-mersemester 2006 durchgefuhrt wurde. Die Arbeit hattedie Evaluation von kostenlos verfugbaren UML – Werk-zeugen im Hinblick auf die Brauchbarkeit in hochschulin-ternen studentischen Ausbildungsprojekten zum Ziel. Eswurden Werkzeuge untersucht, die unter der Freeware –Lizenz vertrieben werden sowie Community – Editionenkommerzieller Produkte.

Die Autoren betonen ausdrucklich, dass die Grundla-gen, auf die sich die Bewertung stutzte sowie die Resulta-te der Evaluation von subjektiven Gesichtspunkten gepragtsind. Aufgrund des begrenzten Umfangs dieses Berichtswerden die Kriterienkataloge, die fur den Evaluierungspro-zess erarbeitet wurden und die tabellarischen Auswertun-gen der untersuchten Werkzeugmerkmale nicht dargestellt.10 Werkzeuge wurden naher untersucht, von denen hier dievorgestellt werden, die im gegebenen Rahmen den bestenEindruck hinterlassen haben.

2 VorwortSeit den 90 –er Jahren setzten sich die objektorientierteSoftwareentwicklung und die OO – Hochsprachen durch.In diesem Zeitraum wurden fur den Prozess der Losungs-modellierung in der Entwurfsphase graphische Beschrei-bungssprachen entwickelt. Das Design von Software wirdwie alle weiteren Entwicklungsschritte von CASE1 –Werkzeugen unterstutzt (siehe z.B.[Bre05]).

Eine universelle Beschreibungssprache fur den Bereichder allgemeinen Modellbildung und des Softwaredesignsist die Unified Modelling Language (siehe Spezifikati-onsdokumente: [UMLOCL], [UMLSuper], [UMLInfra],[UMLDiag], bzw.: [Jec04], [Oes05]), die in der Version2.0 mit 13 verschiedenen standardisierten Diagrammtypenaufwartet, von denen jeder die Betonung auf bestimmteDesignaspekte legt.

Ohne den Einsatz eines UML – Werkzeugs, das dievordefinierten graphische Elemente fur die verschiedenenDiagrammtypen bereithalt und die Einhaltung der Syntaxund teilweise der Semantik dieser Modellierungssprache

1Computer Aided Software Engineering

wahrend der Diagrammerstellung uberwacht, ist der Ent-wurfsprozess mit der UML kaum vorstellbar.

Fur die Studierenden der Informatik, Werkzeugverant-wortliche in Softwareentwicklungsteams und andere Per-sonen, die sich mit der Erstellung von Software befassen,stellt sich die Frage nach der Wahl eines geeigneten UML– Werkzeugs, das die Softwareentwicklung unterstutzt.

Die Studienarbeit war keine vollstandige Marktanalyseder verfugbaren UML – Werkzeuge, diese hatte aufgrunddes notigen Umfangs die zur Verfugung stehenden Res-sourcen und den begrenzten Zeitrahmen (3 Monate, dievorgesehene wochentliche Bearbeitungszeit ist in der Stu-dienordnung festgelegt) muhelos gesprengt.

3 Einsatz von CASE - Werkzeugen

Wie bei anderen Werkzeugen, die bei der Erstellung vonSoftware eingesetzt werden, erfordert die Integration vonUML – Werkzeugen in den Entwicklungszyklus vorerstdie Auswahl eines Werkzeugs aus einer Menge geeigneterKandidaten. Anschließend erfolgt eine Einfuhrungspha-se, die normalerweise durch eine Wirtschaftlichkeitanalysebegleitet wird (siehe: [Spi06], S. 214 ).

Obwohl der Trend zunehmend zu einer Integration vonDesign-, Implementierungs- und Testwerkzeugen unter ei-ner einheitlichen Oberflache fuhrt (IDE & RAD2), wurdenvorwiegend die aktuell am Markt erhaltlichen stand alone– UML – Werkzeuge evaluiert.

Die Einfuhrung eines UML – Werkzeugs soll einenbereits existierenden, reifen Entwicklungsprozess un-terstutzen. Bei der Tatigkeit eines Designers und Software-entwicklers ist die Kenntnis der Grundlagen der objektori-entierten Softwareentwicklung und der UML – Beschrei-bungssprache allein noch nicht ausreichend, um sie bei derErstellung eines Architekturdesigns fur eine gegebene Pro-blemstellung einzusetzen. Es wird Wissen uber das zu ent-wickelnde System benotigt und ein Vorgehenskonzept, dieAnforderungen systematisch zu ermitteln und eine Losungzu konzipieren, die diese erfullt. Alsbald ein Losungs-konzept und Vorgehensplan existieren, kann einfuhrend,z.B. in einem Pilotprojekt, das Werkzeug eingesetzt wer-den.

2Integrated Development Environment – integrierte Entwicklungsum-gebung.

Die UML – Werkzeughersteller bieten teilweise sehrgute Tutorien und Benutzerdokumentationen, die sich anAnfanger richten und den Einstieg in die UML – Model-lierungssprache mit dem Erlernen der Werkzeugbedienungverbinden.

4 Pro und Contra fur den Einsatzder UML – Werkzeuge

Die UML – Modellierungswerkzeuge sind viel mehr alseinfache graphische Editoren fur die UML – Diagramm-erstellung. Sie erfordern ein tief greifendes Verstandnisfur die Details der UML – Beschreibungssprache, derOOA und des OOD3. Nur die Benutzer, die uber fundierteKenntnisse auf diesen Gebieten verfugen, konnen die Leis-tungsfahigkeit der Werkzeuge ausnutzen und von ihrer In-tegration in die IDE – Werkzeuge profitieren.

Als Ergebnis der Modellierung in UML entsteht eineSammlung an graphischen Diagrammen, die das Designund die Architektur eines Systems darstellen und die Im-plementierung der Losung in einer Programmierspracheaufzeigen. Durch die Modellierung, also die Abstraktionvon den Details und die Betonung der essentiellen Aspekteeines zu losenden Problems, wird die Kommunikation un-ter den an der Entwicklung beteiligten Personen unterstutztund gefordert.

Leider wird die werkzeuggestutzte Modellierung in derAnfangsphase durch eine steile Lernkurve behindert. DieAnwender verlieren sich in den Details, die die Benutz-ung der Werkzeugfunktionen und der dahinter stehendenKonzepte (Modellreprasentation im Rechner, Elemente derUML – Sprache in ihrer Bedeutung und Syntax) betreffen.Die eigentliche Aufgabe wird aus den Augen verloren. DieWerkzeuge erfordern von den Benutzern die Bereitschaft,sich in ihre Konzepte zu vertiefen.

Bei den Benutzern kann sich infolgedessen ein Gefuhlder Unzufriedenheit einstellen. Daraus folgt, dass vor demWerkzeugeinsatz eine grundliche Einarbeitungsphase er-folgen muss, fur die Zeit eingeplant und Beispiel– oderLeitprojekte gewahlt werden sollen.

Durch den Einsatz von UML wird automatisch eine de-taillierte Dokumentation erzeugt, anhand derer die Einar-beitung in die Interna des Losungskonzeptes fur externeEntwickler oder die nachfolgenden Generationen moglichist. Eventuelle Modifikationen der Software im Rahmender Wartung, nachtragliche Anderungen im Design undder Architektur konnen automatisch und durchgangig indie Klassen und die Dokumentation ubernommen werden.Das Vorgehen ist auf jedem Fall vorzuziehen, um zu ver-hindern, dass das Design und die Architektur eines Soft-waresystems nur in den Kopfen der Entwickler existieren.

Als ernuchternd ist anzusehen, dass unter den Freewa-re UML – Werkzeugen auf dem Markt keine große Aus-wahl herrscht4, und dass sich die meisten der Fortschritte

3Objektorientierte Analyse und das objektorientierte Design.4Bezogen auf die angegebenen Quellen, die fur die Recherche der

Werkzeuge gedient haben.

auf diesem Gebiet in kommerziellen Entwicklungshausernereignen.

Im Bezug auf die zukunftige Entwicklung der UMList festzustellen, dass Konzepte wie Model Driven Archi-tecture – MDA oder Executable UML – xUML5 (siehe:[Zep06]) diese starker in den Mittelpunkt setzen. MDAoder xUML haben zum Ziel, auf der Grundlage eines sehrdetaillierten UML – Modells eine automatische Generie-rung ausfuhrbaren Codes zu ermoglichen.

5 Beschreibung der Kriterien fur dieEvaluierung

In der Studienarbeit wurden die allgemeinen Qualitats-merkmale, wie sie fur Softwareprodukte definiert werden,auf das Konzept der Evaluierung von UML – Werkzeu-gen angewandt. Die Qualitat der durch die Werkzeuge er-stellten Modelle (Diagramme) hangt von den theoretischenKenntnissen uber die UML und von der Berufserfahrungder Softwareingenieure ab, die mit der Modellierung ei-ner konkreten Problemstellung befasst sind. Die Qualitatder UML – Diagramme an sich erfordert eine getrennteBetrachtung (z.B. in [Unh05]), die nicht der Gegenstanddieser Studienarbeit war.

Fur den Zweck der Evaluierung wurden die Werkzeug-kandidaten einem Abnahmetest aus der Sicht des Anwen-ders unterzogen. Der Abnahmetest gliederte sich in einvorher festgelegtes Evaluierungskonzept ein. Das Evaluie-rungskonzept umfasste die Definition der zu untersuchen-den Merkmale und die Beschreibung einer Strategie, dieauf einem systematischen Weg die definierten Kriterienuntersucht und dokumentiert.

Es wurden hauptsachlich externe Qualitatsmerkmaleberucksichtigt, wie sie in der ISO 9126 fur Softwaresys-teme definiert sind. Wahrend einer Subsumierung wurdenden einzelnen Qualitatsmerkmalen entsprechende, im Be-zug auf UML – Werkzeuge konkretisierte Kriterien defi-niert. Die internen Qualitatsmerkmale wurden bei der Eva-luierung nicht berucksichtigt6.

6 Phasen der EvaluierungDie eigentliche Evaluierung war in zwei Phasen unterteilt.In der ersten Phase fand die Einarbeitung in die UML –Werkzeuge anhand eines Beispielprojekts statt. Dabei wur-de die Funktionalitat der Werkzeuge untersucht und einUberblick uber ihre Bedienung und die Ergonomie der Be-nutzungsoberflache gewonnen.

5Aus den formellen, in der Action Semantic Languages - ASL ver-fassten, individuell definierten Sprachelementen in UML – Diagrammenwird ein ausfuhrbarer Code erzeugt, der in einer UML – Virtual Machinezum Ablauf gebracht werden kann.

6Eine Software kann in ihrer Kernfunktionalitat aus der Sicht des Be-nutzers zum Zeitpunkt der Anwendung nicht mehr verandert werden. Diezu evaluierenden UML – Werkzeuge wurden als Fertigprodukte betrach-tet und somit konnten die meisten der internen Qualitatsmerkmale nichtexplizit untersucht werden.

Dieser Ansatz lieferte einen nicht zu unterschatzenden

”ersten Eindruck“, der Sympathie oder Antipathie fur einbestimmtes Werkzeug weckte. Wenn verfugbar, wurdenwahrend der Einarbeitungsphase integrierte Hilfen und Tu-torien benutzt. Auch das Angebot an Einfuhrungsmateria-lien zu Softwaredesign mit der UML auf der Internetseiteder Hersteller wurde bewertet.

Im Verlauf der Kennenlernphase wurden die mit demgegebenen Kandidaten erzeugten Diagramme mit denendes Referenzprojekts verglichen. Wahrend dieser Phasegemachten Erfahrungen wurden fortlaufend in einer kon-textbezogener Fachsprache in eine vorbereitete Rahmen-struktur eingetragen. Die handschriftliche, knappe Doku-mentation betraf die Installierbarkeit, den Funktionsum-fang des Werkzeugs, die Gestaltung der Benutzungsober-flache und die Benutzerfuhrung. Ferner wurde das Ange-bot an den in die Werkzeuge integrierten Hilfen, Tutorienund Wizzards bewertet und der Umfang und Qualitat derOnline – Dokumentation untersucht.

Die Phase I der Evaluierung lieferte die Auswahlgrund-lage fur die Ubername von 4 der Werkzeuge in die Pha-se II. In der zweiten Phase der Evaluierung wurden dieausgewahlten Werkzeuge systematisch anhand detaillier-ter Kriterienkataloge Punkt fur Punkt untersucht und durchNotenvergabe bewertet. Die Ergebnisse wurden in vorbe-reitete Bewertungs- und Ubersichtstabellen eingetragen.Wahrend der Berichterstellung flossen die Ergebnisse dersystematischen und der informellen Evaluierung in einsubjektives Gesamturteil ein.

Der Stichtag fur den Download der Werkzeuge (undder an diesem Tag aktuellen Versionen) war der 28. April2006. Die nach diesem Tag veroffentlichten Versionen derSoftware bzw. der UML – Spezifikationsdokumente fan-den keine Berucksichtigung mehr.

Mit Sicherheit empfiehlt es sich, das Angebot an CASE– Werkzeugen, die Neuerscheinungen auf dem Markt, dieallgemeinen Entwicklungsrichtungen7 und Innovationenlaufend zu verfolgen. Es soll fur den Werkzeugverantwort-lichen und die Softwareentwickler zu einer Pflichtubungwerden, sich regelmaßig die Zeit zu nehmen, die neues-ten Entwicklungen oder die Folgeversionen der hier vorge-stellten und vorgeschlagenen UML – Werkzeuge zu evalu-ieren.

7 Phase I: Kennenlernphase

Der Schwerpunkt der Evaluation richtete sich auf die Er-stellung von Diagrammen (Benutzung der UML – Werk-zeuge als Zeichenwerkzeuge), die vorwiegend in ihrer Ei-genschaft als Kommunikationsmittel unter den Entwick-lern eingesetzt werden. Modelldetails, die in der weiterenEntwicklung den Diagrammen hinzugefugt werden, spiel-ten bei der Bewertung keine große Rolle. Diese Herange-hensweise ist vertretbar, weil wahrend des Modellierens inder Praxis erst eine grobe Struktur der Losung fur einen

7ExecutableUML – xUML, MDA, Agile MDA sollen hier als Stich-worte genannt werden.

Teilaspekt des zu entwickelnden Systems geschaffen underst spater um die Details verfeinert wird (top – down Vor-gehen).

Wahrend der Diagrammerstellung unter Einsatz einesUML – Werkzeugs beschranken sich die Entwickler oft aufein aus dem Zusammenhang gerissenes Modell, das ad hocgezeichnet wird, damit die Elemente, mit denen hantiertwird, sofort allen Teammitgliedern vor Augen liegen.

Leider wird bei diesem Ansatz die Leistungsfahigkeitder UML – Werkzeuge, wie automatische Codegenerie-rung z.B. aus Klassen– oder Sequenzdiagrammen und ihrEinsatzzweck als die Drehscheibe der darauf aufsetzendeniterativen Softwareentwicklung sowie der Basis fur die Im-plementierung, nicht oder in den meisten Fallen nur unzu-reichend ausgenutzt.

Fur die Evaluation der meisten der Werkzeuge in derersten Phase wurden jeweils ca. 6 – 8 Stunden Zeit ver-wandt. In dieser Periode wurden die verfugbaren Beispieleund Tutorien nachvollzogen sowie das Beispielprojekt um-gesetzt. Zum Teil evaluationsbegleitend, zum Teil im Vor-aus wurde die verfugbare Dokumentation gesichtet. Eini-ge der Werkzeuge (hier nicht aufgefuhrt) wurden aufgrundverschiedener Schwierigkeiten nicht evaluiert.

7.1 Liste der evaluierten WerkzeugeHier werden alle Werkzeuge in alphabetischer Reihenfolgeaufgelistet, die bei der Recherche den Eingangsvorausset-zungen8 entsprochen haben (Tabelle 1). Die Einstiegseitefur die Recherche der Werkzeuge im Internet war die Ho-mepage der Object Management Group:

[URL: www.omg.org/uml]

Auf dem Markt ist eine unuberschaubare Anzahl anUML – Werkzeugen erhaltlich. Auf themenbezogenen In-ternetseiten gibt es Ubersichten von mehr als 100 Werk-zeugen unterschiedlicher Hersteller. Aus diesen Ubersich-ten, die stichpunktartige Aussagen zum Funktionsum-fang liefern, ist es schwierig, ein fur einen beabsichtigtenZweck geeignetes UML – Werkzeug zu finden.

Die Hersteller und Entwickler der UML – Produkte ha-ben seit Neuem die Moglichkeit diese von der OMG imProgramm ”UML 2.0 Tools Certification“ auf die Konfor-mitat mit dem Standard zertifizieren zu lassen.

Nr. Werkzeug Version Hersteller URL1 Argo

UML0.20 http://argouml.tigris.org/

2 BorlandTogetherDesigner2005

5595.0 www.borland.com/us/products/together/

3 BOUML 2.14.1 http://bouml.free.fr4 DOME 5.3 www.htc.honeywell.com/

dome

8Freeware, Community Edition, vom Hersteller kostenlos zurVerfugung gestellt.

Nr. Werkzeug Version Hersteller URL5 FUJABA 4.3.2 http://wwwcs.uni-

paderborn.de/cs/fujaba6 OMONDO

EclipseUML

2.1.02006-0320

www.eclipsedownload.com

7 OracleJ2EEJDevel-oper

10g Re-lease 310.1.3.-36.73

www.oracle.com/tools/jdev home.html

8 Poseidonfor UMLCE

4.1 www.gentleware.com

9 StarUML

5.0.2 http://staruml.sourceforge.net/en/

10 VisualParadigmfor UMLCE

5.2 CEBuild sp120060419

www.visual-paradigm.com

Tabelle 1: Ubersicht ausgewahlter UML – Werkzeuge.

8 Phase II: Evaluation

Die in die zweite Phase der Evaluation aufgenommenenUML – Werkzeuge gehorten lizenzrechtlich zwei unter-schiedlichen Gruppen an. Die frei vertriebenen, gebuhren-freien BOUML ([BOUML]) und StarUML ([StarUML])sowie zwei Community Editionen von kommerziellen Pro-dukten: Poseidon for UML CE ([Poseidon])] sowie Vi-sual Paradigm for UML CE ([VP]). Die beiden letztge-nannten Werkzeuge unterliegen Benutzungseinschrankun-gen des Herstellers.

In Hinsicht auf ihre Verwendbarkeit muss festgestelltwerden, dass die Beschrankungen bei Visual Paradigmfor UML CE (Abb. 1) so gravierend sind, dass bis auf klei-ne Projekte die Brauchbarkeit des Werkzeugs in Zweifelgezogen werden kann.

Abbildung 1: Visual Paradigm for UML CE

StarUML (Abb. 2) bot ebenfalls alle Funktionen an,die von einem UML – Werkzeug erwartet werden. Diegraphische Benutzungsoberflache war ausreichend schnell,zeigte aber kleine Schwachen bei der Darstellung der Dia-gramme und ihrem Ausdruck. Hier konnten aus dem Klas-sendiagramm wie bei BOUML, Quellcodegeruste erzeugtwerden.

Abbildung 2: StarUML

BOUML (Abb. 3) war das schnellste9 der Werkzeu-ge. Die Schnelligkeit wurde mit einer sehr schlichten Be-nutzungsoberflache und der Beschrankung der unterstutz-ten UML – Spezifikation auf die Version 1.5 erkauft. DerFunktionsumfang des Werkzeugs kann fur viele Projekt-vorhaben als ausreichend angesehen werden. Die Benut-zungsanleitung des Werkzeugs gehort nicht zu den Bestenim Testfeld.

Abbildung 3: BOUML

Poseidon for UML CE (Abb. 4) unterstutzte nur eineAuswahl der moglichen UML 2.0 Standard – Diagrammar-ten, die fur die meisten Projekte als ausreichend angesehen

9Daten der Evaluationsumgebung: Athlon 2000 CPU mit WindowsXP, 512 MB RAM, 1024x768 Bildschirmauflosung.

werden kann. Die Bedienung und Erlernbarkeit war Dankeiner sehr guten und fur Anfanger zugeschnittenen Doku-mentation, die in die Benutzung der Diagramme und derUML einfuhrt, als gut zu bewerten. Fur Java – Entwicklerbietet das Werkzeug automatische Codegenerierung.

Abbildung 4: Poseidon for UML CE

Die 4 Werkzeuge bieten unter den 10 der Evaluationunterzogenen, abgesehen von Borland Together Designer2005, das aufgrund der trial – Version nicht weiter betrach-tet wurde, den großten Funktionsumfang fur die Erfullungder allgemeinen Aufgaben der Modellierung mit der UML.

In der Zusammenfassung wurden die durch die Werk-zeuge wahrend der systematischen Evaluierung erreichtenPunktzahlen summiert (Abb. 5) und als Balkendiagramme(Abb. 6) dargestellt. Aus dieser Darstellung sind die Ein-schrankungen in der Benutzung der Community – Versio-nen nicht ersichtlich.

8.1 Grundlagen der Bewertung durch Punk-tevergabe

Die in der Studienarbeit verwendeten Evaluationstabellenenthalten Kriterien, die entweder informativer Natur waren(ja/nein – Bewertung) oder nach dem Schulnotensystemmit einer Punktezahl (1–4) bewertet wurden. Fur jedes po-sitiv erfullte boolsche Kriterium wurde der ”Punktezahler“des untersuchten Werkzeugs inkrementiert. Diese Punktewurden mit dem durch die Notenvergabe erreichten Kom-plement der Punktezahl (eine 1 ergab 4 Wertepunkte, eine4 ergab 1 Wertepunkt) fur jedes der 5 Qualitatsmerkmalesummiert.

Fur jede verfugbare Diagrammart gab es einen Punkt.Fur jedes vorhandene graphische Diagrammausgabefor-mat wurde ebenfalls ein Punkt hinzu addiert. Je mehr Wer-tepunkte das Werkzeug insgesamt erreichte, desto besser.

Abbildung 5: Wertetabelle erreichter Punktezahlen derWerkzeuge

Im Ubersichtbalkendiagramm (Abb. 6) werden die vierUML – Werkzeuge miteinander verglichen. In der erstenReihe von links sind die Balken fur Summen der erreichtenPunkte dargestellt.

Abbildung 6: Zusammenstellung Bewertung der Qualitats-merkmale

9 Zusammenfassung der UML –Werkzeug Evaluation

Die untersuchten UML – Werkzeuge differenzierten sichnach reinen Freeware und Community Edition – Versio-nen kommerzieller Produkte. Von der Seite der Benutzererfordert es eine große Portion Idealismus, um zu Guns-ten der Erstgenannten auf den Komfort zu verzichten, dendie kommerziellen UML – Werkzeuge bereits in den CE– Versionen bieten. Fur die Hersteller steht hinter der Ideeder CE – Versionen vordergrundlich die Platzierung ihrerProdukte am Markt. Um die Vorteile zu entfalten, die derEinsatz der UML – Werkzeuge in der Softwareentwick-lung bietet, ist eine grundliche Einarbeitung in das Werk-zeug wahrend einer vorzusehenden Einfuhrungsphase not-wendig.

Aus den vier in der II Phase evaluierten Werkzeugenkann Poseidon for UML CE als ein Kompromiss zwi-schen Funktionalitat einerseits und den Einschrankungen

einer CE – Version andererseits bei einem Minimum ander benotigten Einarbeitungszeit angesehen werden.

In Hinsicht auf den zukunftigen Einsatz eines kommer-ziellen Produktes nach der Studienzeit bietet Visual Para-digm for UML CE das großte Potenzial.

Fur Idealisten und Freunde der Open Source Bewegung,die bereits uber fundierte UML – Kenntnisse verfugen,kann BOUML empfohlen werden.

StarUML bietet als ein frei verfugbares Werkzeug um-fangreiche Funktionalitat bei einer modernen Benutzungs-oberflache. Es ist unklar, ob dieses Werkzeug zukunftigimmer noch unter dieser Lizenzart vertrieben werden wirdund vor allem, ob es die Lucken zum Funktionalitatsum-fang der am Markt verfugbaren kommerziellen Werkzeugeschließt.

Die Autoren mochten hier nochmals darauf hinwei-sen, dass es Ziel der Studienarbeit war, ein Werkzeug furdie studentische Ausbildung auszuwahlen und deshalb nurkostenlos zur Verfugung gestellte Werkzeuge untersuchtwurden. Auch wurde aus der Vielzahl der im Netz freiverfugbaren UML – Werkzeuge eine erste Auswahl rela-tiv willkurlich gewahlt. Die Ergebnisse sind nicht mit ei-ner reprasentativen Untersuchung gleichzusetzen. Fur denkommerziellen Einsatz von UML – Werkzeugen sind si-cherlich weitere Kriterien anzuwenden und eine genauereUntersuchung vorzunehmen.

9.1 Begleitende ErkenntnisseWahrend der Studienarbeit wurden auch weitere, beglei-tende Erkenntnisse gewonnen, die uber das Studienarbeits-thema hinausgehen:

Eine weitere wichtige Erkenntnis fur den bearbeitendenStudenten war, dass jedes der untersuchten Werkzeuge sei-ne eigenen sehr individuellen Starken und Schwachen auf-wies. Keins der Werkzeuge schaffte es, nur die guten Ei-genschaften in sich zu vereinigen.

Ubertragen auf die Tatigkeit eines Entwicklers in derAnforderungsdefinitionsphase von neuen Produktentwick-lungen lohnt es sich immer eine eigenverantwortliche undsorgfaltige Evaluation vergleichbarer, auf dem Markt be-reits angebotener Produkte durchzufuhren. Das hilft dasPotential zu erkennen, welche Verbesserungen bei derNeuentwicklung des eigenen Produkts implementiert wer-den sollen.

Literatur[BOUML] BOUML User Manual, http://bouml.free.fr/

doc A4.pdf

[Bre05] Breu R./Matzner Th./Nickl F./Wiegert O.,Software – Engineering, Oldenbourg Verlag2005

[Jec04] Jeckle M., UML 2.0 Die neue Versionder Standardmodellierungssprache,Fachhochschule Furtwangen 2004,http://www.jeckle.de

[Oes05] Oestereich B., Analyse und Design mit UML2.0 Objektorientierte Softwareentwicklung,Oldenbourg 2005, http://www.oose.de/uml

[Poseidon] Poseidon User Guide, http://gentleware.com/fileadmin/media/pdfs/userguides/PoseidonUsersGuide.pdf

[Spi06] Spillner A. / Linz T., Basiswissen Soft-waretest Aus- und Weiterbildung zumCertified Tester Foundation Level nachISTQB - Standard, dpunkt Verlag 2006,http://www.dpunkt.de/certified-tester

[StarUML] StarUML 5.0 User Guide, StarUML.chm(aus dem Programm uber Help – Menu ab-rufbar)

[UMLDiag] Unified Modeling Language: DiagramInterchange version 2.0 ptc/05-06-04,http://www.omg.org/technology/documents/formal/uml.htm

[UMLInfra] Unified Modeling Language (UML) Speci-fication: Infrastructure version 2.0 ptc/04-10-14, http://www.omg.org/technology/documents/formal/uml.htm

[UMLOCL] OCL 2.0 Specification Version 2.0 ptc/2005-06-06, http://www.omg.org/technology/documents/formal/uml.htm

[UMLSuper] Unified Modeling Language: Super-structure version 2.0 formal/05-07-04,http://www.omg.org/technology/documents/formal/uml.htm

[Unh05] Unhelkar B., Verification and Validation forQuality of UML 2.0 Models, Wiley&Sons2005

[VP] Visual Paradigm for the Unified Mo-deling Language, http://www.visual-paradigm.com/documentation/ → VP-UML5.2 User’s Guide Teil 1

[Zep06] Zeppenfeld K. / Wolters R., Generati-ve Softwareentwicklung mit der MDA,Spektrum Akademischer Verlag 2006,http://www.mda-buch.de

Zuletzt wurden die URL – Angaben wahrend der Vorbe-reitung dieses Beitrages (29. September 2006) aktualisiert.Eine Garantie fur deren Gultigkeit uber dieses Datum hin-aus kann nicht ubernommen werden.