Brauchbare UML-Werkzeuge - Institut für Softwaretechnologie

Transcription

Institut für Softwaretechnologie
Abteilung Software Engineering
Universität Stuttgart
Universitätsstraße 38
70569 Stuttgart
Fachstudie Nr. 74
Brauchbare UML-Werkzeuge
Martin Albiez, Frederik Nothelfer, Wolfgang Scherer
Studiengang:
Softwaretechnik
Prüfer:
Prof. Dr. rer. nat. Jochen Ludewig
Betreuer:
Dipl.-Inf. Matthias Wetzel
begonnen am:
18. Februar 2007
beendet am:
30. Oktober 2007
Fachstudie > UML-Tools
Seite 2 / 62
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation für diese Fachstudie .
1.2 Zielsetzung dieser Fachstudie . .
1.3 Auswahl der Werkzeuge . . . .
1.4 Aufbau des Dokuments . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Ablauf der Fachstudie
2.1 Rahmenbedingungen . . . . . . . . . . . . . . . . .
2.1.1 Zeitrahmen . . . . . . . . . . . . . . . . . .
2.1.2 Beteiligte Personen . . . . . . . . . . . . . .
2.2 Projektablauf . . . . . . . . . . . . . . . . . . . . .
2.2.1 Beginn der Fachstudie . . . . . . . . . . . .
2.2.2 Erarbeitung der Bewertungskriterien . . . . .
2.2.3 Auswertung . . . . . . . . . . . . . . . . . .
2.2.4 Überlagern der Auswertung mit den Profilen
2.2.5 Abschluss und Präsentation . . . . . . . . .
3 Vorstellung der Werkzeuge
3.1 ArgoUML . . . . . . . . . . . . . .
3.2 BOUML . . . . . . . . . . . . . . .
3.3 OMONDO EclipseUML . . . . . .
3.4 Borland Together . . . . . . . . . .
3.5 Gentleware Poseidon . . . . . . . .
3.6 IBM Rational Software Modeler . .
3.7 Microsoft Visio . . . . . . . . . . .
3.8 Sparx Systems Enterprise Architect
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
7
7
.
.
.
.
.
.
.
.
.
8
8
8
8
9
9
9
9
9
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
12
13
13
15
16
16
17
4 Vorstellung der Bewertungskriterien
4.1 Nichtfunktionale Bewertungskriterien . . .
4.1.1 Unterstützung durch den Hersteller
4.1.2 Stabilität und Fehler . . . . . . . .
4.1.3 Bedienbarkeit . . . . . . . . . . . .
4.1.4 Performance . . . . . . . . . . . .
4.2 Funktionale Bewertungskriterien . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
21
22
25
27
5 Bewertung der Tools
5.1 ArgoUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 BOUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 OMONDO EclipseUML . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
32
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
5.4
5.5
5.6
5.7
5.8
Inhaltsverzeichnis
Borland Together . . . . . . . . . .
Gentleware Poseidon . . . . . . . .
IBM Rational Software Modeler . .
Microsoft Visio . . . . . . . . . . .
Sparx Systems Enterprise Architect
6 Nutzerprofile
6.1 Das SoPra-Profil . . . .
6.2 Das StuPro-Profil . . . .
6.3 Das Diplomarbeit-Profil .
6.4 Das Unternehmen-Profil
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
38
40
42
44
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
48
50
52
7 Gesamtbewertung
7.1 Gesamtvergleich der Tools . . . . . .
7.2 Auswertung des SoPra-Profils . . . .
7.3 Auswertung des StuPro-Profils . . . .
7.4 Auswertung des Diplomarbeit-Profils
7.5 Auswertung des Unternehmen-Profils
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
56
57
58
59
60
8 Fazit
8.1 SoPra . . . .
8.2 StuPro . . . .
8.3 Diplomarbeit
8.4 Unternehmen
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
61
61
62
Seite 4 / 62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abbildungsverzeichnis
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Die Oberfläche von ArgoUML . . . . . . . . . . . . .
Die Oberfläche von BOUML . . . . . . . . . . . . . .
Die Oberfläche von OMONDO EclipseUML . . . . .
Die Oberfläche von Borland Together . . . . . . . . .
Die Oberfläche von Gentleware Poseidon . . . . . . .
Die Oberfläche des IBM Rational Software Modeler . .
Die Oberfläche von Microsoft Visio . . . . . . . . . .
Die Oberfläche von Sparx Systems Enterprise Architect
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
12
13
14
15
16
17
18
4.1
4.2
4.3
UML-Klassendiagramm des Einsteigerfreundlichkeitstests . . . . . . . . . . .
UML-Use-Case-Diagramm des Einsteigerfreundlichkeitstests . . . . . . . . . .
UML-Sequenzdiagramm des Einsteigerfreundlichkeitstests . . . . . . . . . . .
22
23
23
5
1 Einleitung
1.1 Motivation für diese Fachstudie
Die in diesem Bericht dokumentierte Fachstudie wurde von drei Studenten der Universität Stuttgart von Februar bis Oktober 2007 an der Abteilung Software Engineering des Instituts für
Softwaretechnologie durchgeführt.
Für studentische Arbeiten am Institut, insbesondere Softwarepraktikas, Studienprojekte und
Diplomarbeiten, werden häufig zur Modellierung UML-Werkzeuge eingesetzt. Die Wahl, welches Werkzeug in einem Projekt zum Einsatz kommt, war meist auf persönlicher Erfahrung der
Projektbeteiligten oder des Aufgabenstellers basiert. Diese Fachstudie soll daher eine fundierte
Entscheidungsgrundlage für die Wahl von UML-Werkzeugen von zukünftigen Projekten bieten.
Hierzu wurden acht UML-Werkzeuge auf ihren Funktionsumfang und Brauchbarkeit untersucht. Anhand von Profilen wurde dann verglichen, ob eine Software für einen bestimmten
Projekttyp verwendet werden kann. Hierbei werden die einzelnen Anforderungen der Profile
berücksichtigt. Bei einem Softwarepraktikum mit 70 Teilnehmern sollte so ein Werkzeug möglichst günstig oder gar umsonst sein, für eine Diplomarbeit, bei der ein Tool über sechs Monate
von wenigen Personen verwendet wird, spielt der Preis so etwa eine kleinere Rolle, hier ist
vielmehr der Funktionsumfang wichtig.
1.2 Zielsetzung dieser Fachstudie
Zur fundierten Entscheidungsfindung werden daher UML-Werkzeuge gesucht, die
1. eine hohe Bedienbarkeit und Funktionalität aufweisen,
2. preislich in einem für Universitätsprojekte passenden Spektrum liegen oder durch Partnerprogramme kostengünstig vom Hersteller bezogen werden können,
3. möglichst den aktuellen UML-Standard, UML 2.1, unterstützen,
4. auch über Versionsgrenzen hinweg die Wiederverwendbarkeit und den Austausch von
Daten sicherstellen. Hier gab es in der Vergangenheit immer wieder große Probleme, etwa
beim Versionswechsel einer Software.
Die in Frage kommenden Werkzeuge sollen in dieser Fachstudie anhand ihrer nicht-funktionalen
und funktionalen Eigenschaften untersucht werden. Hierauf aufbauend werden Empfehlungen
für die einzelnen Projekttypen, hier Profile genannt, gegeben.
6
1.3. Auswahl der Werkzeuge
1.3 Auswahl der Werkzeuge
Die auszuwertenden Tools wurden teilweise vom Betreuer der Fachstudie vorgegeben. Zusätzlich wurde von den Autoren eine Marktanalyse der verfügbaren Produkte durchgeführt und die
passendsten ausgewählt. Hierbei spielten Aspekte wie Funktionsumfang und Bedienbarkeit, aber
auch Anschaffungskosten sowie Einarbeitungszeit eine große Rolle. Da viele Projekte an der
Universität weniger als sechs Monate umfassen, bleibt wenig Zeit, sich in ein UML-Werkzeug
länglich einzuarbeiten.
1.4 Aufbau des Dokuments
In Kapitel 2 wird ein Überblick über den Ablauf der Fachstudie und die beteiligten Personen
gegeben. Kapitel 3 stellt die ausgewählten Werkzeuge kurz mit Screenshot vor. In Kaptitel 4
werden der von den Autoren ausgearbeitete Kriterienkatalog und die darin verwendeten Skalen
erläutert. Kapitel 5 stellt die Ergebnisse der Evaluation der Tools anhand des Kriterienkatalogs
dar und beschreibt Alleinstellungsmerkmale, die die Produkte auszeichnen. Kapitel 6 verknüpft
schließlich die Bewertungsergebnisse mit den Profilen für die einzelnen Projekttypen und gibt
Empfehlungen für jedes Profil ab. Kapitel 7 schließt die Fachstudie mit einem generellen Fazit
ab.
Seite 7 / 62
2 Ablauf der Fachstudie
2.1 Rahmenbedingungen
2.1.1 Zeitrahmen
Die Fachstudie wurde vom 18. Februar 2007 bis zum 30. Oktober 2007 durchgeführt.
2.1.2 Beteiligte Personen
Prüfer
Prof. Dr. rer. nat. Jochen Ludewig
Betreuer
Dipl.-Inf. Matthias Wetzel
Bearbeiter
Die Fachstudie wurde durchgeführt von Martin Albiez, Frederik Nothelfer und Wolfgang Scherer.
8
2.2. Projektablauf
2.2 Projektablauf
2.2.1 Beginn der Fachstudie
Zu Beginn der Fachstudie wurde in einem Treffen zwischen dem Betreuer und den Bearbeitern
das generelle Thema und die erhofften Ergebnisse diskutiert. Ziel war es, brauchbare UMLWerkzeuge für Projekte an der Universität zu finden. Ferner wurde der grobe Zeitplan festgelegt. Hier erfolgte die Vorauswahl der zu evaluierenden UML-Tools durch no-can-do-Kriterien
zusammen mit den Betreuern. Es verblieben acht UML-Werkzeuge zur Evaluation.
2.2.2 Erarbeitung der Bewertungskriterien
Der Kriterienkatalog zur Bewertung der Kandidaten wurde mit Hilfe von Checklisten und der
eigenen Erfahrung der Betreuer und der Autoren im Umgang mit UML-Werkzeugen erarbeitet.
In einem ersten Treffen wurden die gesammelten Kriterien verfeinert und in Gruppen wie
etwa Bedienbarkeit, Performance, usw. eingeteilt. Es wurde besonderes Augenmerk auf die verwendeten Skalen gelegt. Wo immer es möglich war kam die Absolutskala zum Einsatz, bei
vergleichenden Bewertungen die Ordinalskala mit Hilfe von Werten wie , , ⊕, etc. Ebenso
wurde die Normierung der Werte auf ein Intervall zwischen 0,0 und 1,0 beschlossen, um für die
Profile eine bessere Vergleichbarkeit zu erhalten.
Zeitgleich erarbeiteten wir die grundlegenden Anforderungen der Profile für die einzelnen
Nutzungsszenarien. Diese wurden in weiteren Gesprächen dann noch vertieft.
2.2.3 Auswertung
Nachdem der Kriterienkatalog aufgestellt war, begann die Auswertung der gewählten UMLWerkzeuge. Jedes Tool wurde von zwei Autoren gemeinsam geprüft. Gemessene Zeiten, wie
etwa das Erstellen von Diagrammen wurde von zwei Testern unabhängig durchgeführt und die
Ergebnisse dann gemittelt. Für jedes getestete Programm wurden ferner textuell die beim Evaluieren gemachten Erfahrungen festgehalten, um etwa besonders gute oder schlechte Eigenschaften darzustellen.
2.2.4 Überlagern der Auswertung mit den Profilen
Zum Schluss der Auswertung wurden die Ergebnisse jedes Tools mit den Anforderungen der
einzelnen Nutzungsprofile verglichen. Hierbei entstand eine Nutzwertanalyse, die die Tauglichkeit der Tools in Zahlen ausdrückt. Zusätzlich wird für jedes Profil eine textuelle Empfehlung
gegeben, welches Werkzeug wohl am Besten geeignet ist.
2.2.5 Abschluss und Präsentation
Im Zeitraum zwischen dem 02.08.07 und dem 30.10.07 erstellten wir den Abschlussbericht und
präsentierten die Ergebnisse bei der Abteilung für Software Engineering.
Seite 9 / 62
3 Vorstellung der Werkzeuge
Im Folgenden werden die Werkzeuge vorgestellt, die im Rahmen der Fachstudie evaluiert wurden. Es wurde sowohl kostenlose als auch kommerzielle Software in die Auswahl mit aufgenommen, da in der späteren Nutzwertanalyse mit Hilfe der Nutzungsprofile die Kosten als Kriterium
eine Rolle spielen. Ein weiterer Grund für die gemischte Auswahl von kommerzieller und freier
Software ist ein prinzipieller Qualitätsvergleich der beiden Rubriken in der Hoffnung, ein kostenloses UML-Werkzeug empfehlen zu können, das mit den kommerziellen mithalten kann.
Die frei erhältlichen Werkzeuge sind:
• ArgoUML
• BOUML
• OMONDO EclipseUML
Die kommerziellen Werkzeuge sind:
• Borland Together
• Gentleware Poseidon
• IBM Rational Software Modeler
• Microsoft Visio
• Sparx Systems Enterprise Achitect
Für jedes Werkzeug folgt nun ein Screenshot mit einer kurzen Beschreibung. Diese enthält
jeweils Informationen über den Hersteller, mögliche verschiedene Ausprägungen von Version,
Lizenz und Preis der Software, sowie Gründe für die Auswahl des Werkzeugs.
3.1 ArgoUML
ArgoUML wurde anfangs von Jason Robbins entwickelt und ist seit 2002 als Open-SourceProjekt auf der Webseite http://argouml.tigris.org zum freien Download inklusive des Quellcodes verfügbar. Das Projekt selbst läuft unter der BSD-Lizenz. Die Software basiert auf Java und
ist somit komplett plattformunabhängig.
ArgoUML unterstützt die Diagramme des UML 1.4-Standards und bietet Export, bzw. Import
in offene Formate wie XMI sowie SVG durch eine moderne Oberfläche. Ferner ist ein komplettes round-cycle-engineering möglich, d.h. das Konvertieren von Klassen in UML und das
Generieren von Code aus UML-Diagrammen.
10
3.1. ArgoUML
Abbildung 3.1: Die Oberfläche von ArgoUML
Seite 11 / 62
Kapitel 3. Vorstellung der Werkzeuge
Für das hier getestete Release der Version 0.24 schreiben die Autoren auf der Homepage, dass
das Werkzeug in dieser Version selbst noch nicht für den produktiven Einsatz verwendet werden
sollte. Interessanterweise gab es bei der Evaluierung aber keine Bugs oder Stabilitätsprobleme,
im Gegensatz zu manchen anderen kostenlosen UML-Werkzeugen.
3.2 BOUML
Abbildung 3.2: Die Oberfläche von BOUML
BOUML wird privat von Bruno Pagès entwickelt und kann unter der Homepage
http://bouml.free.fr kostenlos als Freeware heruntergeladen werden. Die aktuelle Version 2.30
bietet UML 2.0-Unterstützung und läuft unter Linux/Unix, MacOSX und Windows über das
QT-Framework.
Das UML-Werkzeug rühmt sich, besonders schnell und effizient zu arbeiten, auf der Homepage des Autors werden allerlei Vergleiche mit anderen (kommerziellen) Konkurrenten gezogen.
Speziell bei der Lade-, Speicher- und Startzeit ist BOUML allen anderen Tools deutlich überlegen.
Das Programm ist völlig umsonst und läuft unter so ziemlich jeder Umgebung, daher ist es
ein idealer Kandidat für diese Fachstudie. Leider zeigte sich im Verlauf der Evaluation, dass die
Bedienung sehr unkonventionell und unübersichtlich ausgefallen ist.
Seite 12 / 62
3.3. OMONDO EclipseUML
3.3 OMONDO EclipseUML
Abbildung 3.3: Die Oberfläche von OMONDO EclipseUML
EclipseUML von OMONDO ist ein Plugin für das bekannte Eclipse Framework und gliedert
sich in dessen Java Entwicklungsumgebung ein. Es steht derzeit in zwei Varianten zur Verfügung. Die „Free Edition“ ist kostenlos, während die „Studio Edition“ für 2400 e (einmalige
Zahlung für eine Einzel-Benutzer-Lizenz) erworben werden kann. Beide Varianten gibt es sowohl für „Eclipse 3.3“ als auch für „Eclipse 3.2“. Die im Folgenden durchgeführte Evaluation
bezieht sich auf die „Free Edition“ für „Eclipse 3.2“, da die „Free Edition“ in Zusammenhang
mit „Eclipse 3.3“ aufgrund eines Softwarefehlers kaum sinnvoll zu benutzen war (näheres hierzu siehe Evaluationsabschnitt). Da EclipseUML auf der Eclipse-Plattform aufsetzt, ist es sowohl
unter Windows als auch unter Linux lauffähig.
3.4 Borland Together
Together ist eine grafische Modellierungs-Plattform von Borland. Sie ist als Plugin für das
Eclipse Framework oder Visual Studio erhältlich. Im Rahmen dieser Studie wurde die auf der
Herstellerhomepage (http://www.borland.com/de/products/together/) zum Download verfügbare Trialversion von Borland Together 2006 Release 2 for Eclipse getestet. Da die Software auf
Eclipse basiert, ist sie unter Windows, Linux und Mac OS lauffähig und kostet ca. 1100 e.
Seite 13 / 62
Abbildung 3.4: Die Oberfläche von Borland Together
Seite 14 / 62
3.5. Gentleware Poseidon
Laut Hersteller kann die Together Architekten, Entwickler, UML-Designer, Geschäftsprozessanalytiker und Datenmodellierer dabei unterstützen, die Entwicklung qualitativ hochwertiger Softwareanwendungen zu beschleunigen. Der Funktionsumfang beschränkt sich also nicht
auf die Modellierung mit UML, sondern bietet zum Beispiel auch Möglichkeiten zur Geschäftsprozess- und Datenmodellierung, die hier jedoch nicht berücksichtigt und getestet wurden.
3.5 Gentleware Poseidon
Abbildung 3.5: Die Oberfläche von Gentleware Poseidon
Poseidon for UML von Gentleware steht in den vier Varianten „Community Edition“, „Standard Edition“,„Professional Edition“ und „Embedded Edition“ zur Verfügung. Die Varianten
unterscheiden sich in ihrem Funktionsumfang voneinander, jedoch ist keine von ihnen kostenlos. Die im Folgenden durchgeführte Evaluation des Tools basiert auf der „Community Edition“,
welche für monatlich 5 e (oder jährlich 48 e) erhältlich ist. Poseidon ist unter Windows, MacOS
X und Linux lauffähig.
Seite 15 / 62
3.6 IBM Rational Software Modeler
Abbildung 3.6: Die Oberfläche des IBM Rational Software Modeler
Der Rational Software Modeler wird von IBM in vielen verschiedenen Versionen und Varianten vertrieben. Die hier getestete Version 7.0 des IBM Rational Software Modelers fügt sich
nahtlos in Eclipse 3.2 ein und bietet volle Unterstützung des UML 2.1 Standards. Lauffähig ist
die Software nicht nur unter Windows, sondern auch unter Linux mit KDE oder GNOME.
Der Rational Software Modeler ist Teil der IBM Rational-Familie und verfügt somit über eine
gute Anbindung an andere Tools des Herstellers mit dem Ziel, ein vollständiges RoundcyleEngineering zu bieten, von der Modellierung über die Entwicklung bis hin zum Softwaretest.
Preislich liegt der Software Modeler, welcher die günstigste Variante der IBM Rational Software darstellt, bei 2232 e. Da Universitäten die Software im Rahmen von Partnerprogrammen
mit IBM oft kostenlos beziehen können, wird das Tool hier im Rahmen der Fachstudie trotzdem
evaluiert.
3.7 Microsoft Visio
Visio ist die Visualisierungssoftware des Microsoft-Office-Systems. Die hier getestete Version
Microsoft Office Visio Professional 2007 ist nur unter Windows XP und Windows Vista lauffähig.
Seite 16 / 62
3.8. Sparx Systems Enterprise Architect
Abbildung 3.7: Die Oberfläche von Microsoft Visio
Da die Software nicht primär für die Softwareentwicklung sondern zur Visualisierung der
verschiedensten Diagramme entwickelt wurde, ist das Erstellen von UML-Diagrammen nur ein
kleiner Bereich von Visios Fähigkeiten. Daher beschränken sich auch die Möglichkeiten im
UML-Modellierungsbereich auf die grafische Darstellung der UML-Diagramme.
MS Visio wurde in die Werkzeugauswahl aufgenommen, da die Lizenz für Studenten der
Universität Stuttgart kostenlos ist. Die Software ist nicht Teil des Office-Pakets und kostet 699 e
als Professional und 329 e als Standard Edition.
Der Enterprise Architect von Sparx Systems ist ein UML-Werkzeug, das laut Hersteller den
kompletten Softwareentwicklungszyklus einschließlich Test und Wartung umfasst. Es ist in einer Version für Windows und für Linux erhältlich und wurde hier unter Windows in der Version
Enterprise Architect Professional 6.5 getestet. Die aktuelle Version ist allerdings der Enterprise
Architect 7.0, der sich jedoch bei den getesteten Funktionen nicht wesentlich von seinem Vorgänger unterscheidet. Lediglich die übersichtlicher gestaltete Toolbox (in ihr sind die Werkzeuge zum Erstellen von Klassen enthalten) hätte sich positiv auf den Einsteigerfreundlichkeitstest
ausgewirkt, die anderen Verbesserungen machten sich in den Ergebnissen der Evaluierung nicht
bemerkbar. Dies bestätigte sich, nachdem die auf der Homepage des Herstellers erhältliche Trial
Version von EA 7.0 Build 815 installiert und im Hinblick auf Verbesserungen untersucht wurde.
Es gibt verschiedene Versionen der Software: Corporate-, Professional und Desktop Edition.
Seite 17 / 62
Abbildung 3.8: Die Oberfläche von Sparx Systems Enterprise Architect
Bei den Lizenzen der Versionen gibt es jeweils Mengenrabatte sowie eine akademische Lizenz.
Die normale Professional Edition kostet umgerechnet 149 e, die Akademische 79 e. Ein vollständiger Überblick über den Funktionsumfang der einzelnen Versionen sowie die Preise und
Lizenzen befindet sich auf der Homepage http://www.sparxsystems.com. Laut den Angaben des
Herstellers war das Ziel der Entwicklung des Tool „ein zuverlässiges, funktionsreiches, flexibles
und umfassendes UML Modellierungswerkzeug (...) zu einem vernünftigen Preis“ auf den Markt
zu bringen.
Seite 18 / 62
4 Vorstellung der Bewertungskriterien
Hier werden die Bewertungskriterien der UML-Werkzeuge vorgestellt. Es wird jeweils die verwendete Skala und deren Wertebereich angegeben. Zusätzlich wird angegeben, wie die Werte
ermittelt wurden.
Um die Vergleichbarkeit sicherzustellen und in den Profilen eine Nutzwertanalyse durchführen zu können, werden alle gemessenen Werte auf eine Intervallskala mit dem Wertebereich
[0, 0; 1, 0] normiert. Die dazu notwendige Transformation wird ebenfalls hier beschrieben.
4.1 Nichtfunktionale Bewertungskriterien
Hier werden die Kriterien zu nichtfunktionalen Eigenschaften der UML-Werkzeuge vorgestellt.
4.1.1 Unterstützung durch den Hersteller
Kosten
Skala:
Anschaffungskosten in Euro
Skalentyp:
Absolutskala
normierte Skala:
[0,0; 0,25; 0,50; 0,75; 1,0]
Skalentransformation: umsonst → 1,0
1 e bis 100 e → 0,75
101 e bis 500 e → 0,50
501 e bis 2000 e → 0,25
ab 2001 e → 0,0
Beschreibung:
Gibt den Kaufpreis der Software in der getesteten Version an.
Ermittlungsart:
Herstellerinformationen einholen.
Kommentar:
Sollte ein vergünstigter Studenten- oder Universitätspreis angeboten werden, so wird der reguläre Preis angegeben und in Klammern der vergünstigte Preis. Bei der Einbeziehung des Preises zur Bewertung der
Werkzeuge im Rahmen der Profile wird dann der passende Preis als
Bewertungsgrundlage verwendet. D.h. für das SoPra-, StuPro- und Diplomarbeitsprofil die ermäßigten Preise, für das Unternehmensprofil der
reguläre Preis.
19
Kapitel 4. Vorstellung der Bewertungskriterien
Support
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
Skalentransformation: nein → 0
ja → 1
Beschreibung:
Gibt an, ob und welchen Support der Hersteller für ein Werkzeug anbietet.
Ermittlungsart:
Herstellerinformationen zum Support einholen.
Kommentar:
Bei Freeware und Open-Source-Software gilt als Support ein Forum
oder eine Mailing-Liste.
Weiterentwicklung
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
ja → 1
Beschreibung:
Gibt an ob ein Tool noch weiterentwickelt wird oder ob die Arbeit an
dem Tool offensichtlich eingestellt wurde.
Ermittlungsart:
Das letzte Releasedatum wird erfasst und die Webseite wird nach Informationen über den Entwicklungsstand und die Weiterentwicklung des
Tools durchsucht.
Kommentar:
–
Seite 20 / 62
4.1. Nichtfunktionale Bewertungskriterien
4.1.2 Stabilität und Fehler
Abstürze
Skala:
///⊕/⊕⊕
Skalentyp:
Ordinalskala
normierte Skala:
[0,0; 0,25; 0,5; 0,75; 1,0]
Skalentransformation: → 0, 0
→ 0, 25
→ 0, 5
⊕ → 0, 75
⊕⊕ → 1, 0
Beschreibung:
mehrere reproduzierbare Abstürze = mehrere nichtreproduzierbare Abstürze = Ein reproduzierbarer Absturz = Ein nichtreproduzierbarer Absturz = ⊕
Kein Absturz = ⊕⊕
Ermittlungsart:
Stürzt das Tool während der Evaluation ab, wird dies erfasst und aufsummiert. Zusätzlich wird versucht die Fehlersituation zu rekonstruieren um die Reproduzierbarkeit des Fehlers festzustellen.
Kommentar:
Reproduzierbare Fehler bei wichtigen Funktionen des Werkzeugs machen dies Kriterium zu einem KO-Kriterium und das Werkzeug wird
nicht weiter evaluiert. Gibt es nach einem Absturz eine Recovery-Funktion,
so wird dies textuell erwähnt.
Fehler und Bedienschwächen
Skala:
///⊕/⊕⊕
Skalentyp:
Nominalskala
normierte Skala:
[0,0; 0,25; 0,5; 0,75; 1,0]
→ 0, 25
→ 0, 5
⊕ → 0, 75
⊕⊕ → 1, 0
Seite 21 / 62
Beschreibung:
Gibt an, ob das Werkzeug signifikante Bedienschwächen oder reproduzierbare Fehler zeigt.
Ermittlungsart:
Dokumentation während der Evaluation.
Kommentar:
Textuell wird die Art der Fehler beschrieben.
4.1.3 Bedienbarkeit
Einsteigerfreundlichkeitstest
Um die Einarbeitungszeit und Einsteigerfreundlichkeit zu messen wurde ein Referenzmodell
entworfen. Dieses wurde in einer hier nicht getesteten UML-Software von allen drei Teilnehmern zusammen erstellt, so dass es jedem bekannt war. Danach bauten jeweils zwei Autoren
dieselben Diagramme mit dem zu evaluierenden UML-Werkzeug nach und stoppten die benötigte Zeit. Diese wurde dann gemittelt, woraus sich der jeweilige Zeitwert für die einzelnen
Diagrammtypen ergab.
Das Referenzmodell umfasste ein Klassendiagramm, ein Use-Case-Diagramm und ein Sequenzdiagramm. Diese waren wie folgt aufgebaut:
Abbildung 4.1: UML-Klassendiagramm des Einsteigerfreundlichkeitstests
Seite 22 / 62
Abbildung 4.2: UML-Use-Case-Diagramm des Einsteigerfreundlichkeitstests
Abbildung 4.3: UML-Sequenzdiagramm des Einsteigerfreundlichkeitstests
Seite 23 / 62
Die drei verwendeten Skalen und Skalentransformationen für die einzelnen Diagrammtypen
lauten wie folgt:
Diagramm-Typ
Use-Case-Diagramm
Klassendiagramm
Skala
Zeit in Minuten
Skalentyp
Absolutskala
normierte Skala
[0,0; 0,25; 0,5; 0,75; 1.0]
Skalentransformation
0,0-2,0 min → 1,0
2,1-4,0 min → 0,75
4,1-6,0 min → 0,5
6,1-8,0 min → 0,25
8,1-∞ min → 0,0
0,0-11,0 min → 1,0
11,1-14,0 min → 0,75
14,1-17,0 min → 0,5
17,1-20,0 min → 0,25
20,1-∞ min → 0,0
Sequenzdiagramm
0,0-4,0 min → 1,0
4,1-6,0 min → 0,75
6,1-8,0 min → 0,5
8,1-10,0 min → 0,25
10,1-∞ min → 0,0
Die so ermittelten drei Einzelwerte für die drei Diagramme werden im Verhältnis 1:2:1 zu
einer Gesamtbewertung gemittelt. Da das Klassendiagramm als das Wichtigste angesehen wird,
erhält es einen höheren Gewichtungsfaktor als die anderen beiden Diagramme.
Benutzerfreundlichkeit
Skala:
1-5
Skalentyp:
Ordinalskala
normierte Skala:
[0,2; 0,4; 0,6; 0,8; 1,0]
Skalentransformation: für jeden erfüllten Punkt der Checkliste steigt der Wert um
Beschreibung:
1
5
Es gibt eine Checkliste, für jeden erfüllten Punkt gibt es einen Punkt
mehr in der Endbewertung. Die Checkliste besteht aus:
• Übersichtliche Gestaltung der Software (Symbolleisten, Menus,
Tooltips...)
• Wenn API vorhanden: Dokumentation
• Einfache Installation
• Guter Diagrammdruck mit Skalierung
• Auto-Layouter
Ermittlungsart:
Programm auf die Features absuchen und eventuelle Dokumentation
sichten.
Kommentar:
–
Seite 24 / 62
Werkzeug-Hilfen
Skala:
1-3
Skalentyp:
Ordinalskala
normierte Skala:
[0,33; 0,67; 1,0]
Skalentransformation: für jeden erfüllten Punkt der Checkliste steigt der Wert um
Beschreibung:
1
3
Es gibt eine Checkliste, für jeden erfüllten Punkt gibt es einen Punkt
mehr in der Endbewertung. Die Checkliste besteht aus:
• (Einstiegs) Tutorials vorhanden
• Hilfe oder Handbuch vorhanden
• UML-Hilfe beim Erstellen von Diagrammen
Ermittlungsart:
Programm auf die Features absuchen und eventuelle Dokumentation
sichten.
Kommentar:
Die hier genannten Features dienen dem schnellen Arbeiten mit dem
Werkzeug gerade für UML-Neulinge (z.B. für das Softwarepraktikum).
4.1.4 Performance
Die Performance wurde jeweils an demselben Rechner gemessen. Das hierfür benutzte Gerät,
ein Intel Core Duo T2300E 1,66 GHz mit 1GB RAM, wurde für die Rechenzeitenmessungen in
eine langsamere Konfiguration versetzt, in der es nur noch mit 365MHz läuft. Dadurch liegen die
gemessenen Zeiten weiter auseinander und Unterschiede werden deutlicher. Bei der normalen
Konfiguration lagen die Zeiten zwischen der Hälfte und einem Drittel der angegebenen Zeiten.
Auch die Bedienzeit wurde in dieser Rechnerkonfiguration gemessen, was bedeutet, dass
leichte Verzögerungen bei schnelleren Maschinen nicht auftreten. Jedoch wurde auf diese Weise festgestellt, ob es beim Arbeiten mit dem Werkzeug prinzipiell zu längeren Antwortzeiten
kommen kann. Diese können auftreten, wenn zum Beispiel extrem große UML-Diagramme bearbeitet werden oder nicht die volle Rechenleistung zur Verfügung steht, da andere Programme
parallel ausgeführt werden.
Startzeit
Skala:
Zeit in Sekunden
Skalentyp:
Absolutskala
Seite 25 / 62
normierte Skala:
[0,0; 0,5; 1,0]
Skalentransformation: 0-30 s → 1,0
31-120 s → 0,5
120-∞ s → 0,0
Beschreibung:
Die Startzeit ist die Zeit in Sekunden, die das Tool nach seinem Aufruf
benötigt, um arbeitsbereit zu sein.
Ermittlungsart:
Die Startzeit wird im Anschluss an einen Neustart des Rechners gemessen.
Kommentar:
Die Startzeit aller Tools wurde auf demselben Rechner mit derselben
Konfiguration gemessen. Die Transformation der Zeitwerte auf die normierte Skala erfolgte anhand der subjektiven Betrachtung der gemessenen Werte.
Ladezeit
Skala:
Zeit in Sekunden
Skalentyp:
Absolutskala
normierte Skala:
[0,0; 0,5; 1,0]
6-10 s → 0,5
11-∞ s → 0,0
Beschreibung:
Die Ladezeit ist die Zeit in Sekunden, die das Tool zum Laden eines
Modells benötigt.
Ermittlungsart:
Es wird das Referenzmodell geladen.
Kommentar:
Die Ladezeit aller Tools wurde auf demselben Rechner mit derselben
Konfiguration gemessen.
Speicherzeit
Skala:
Zeit in Sekunden
Skalentyp:
Absolutskala
normierte Skala:
[0,0; 0,5; 1,0]
Seite 26 / 62
4.2. Funktionale Bewertungskriterien
6-10 s → 0,5
11-∞ s → 0,0
Beschreibung:
Die Speicherzeit ist die Zeit in Sekunden, die das Tool zum Speichern
eines Modells benötigt.
Ermittlungsart:
Es wird das Referenzmodell gespeichert.
Kommentar:
Die Speicherzeit aller Tools wurde auf demselben Rechner mit derselben Konfiguration gemessen.
Bedienzeit
Skala:
//⊕⊕
Skalentyp:
Ordinalskala
normierte Skala:
[0,0; 0,5; 1,0]
→ 0, 5
⊕⊕ → 1, 0
Beschreibung:
Die Bedienzeit ist ein Wert zwischen und ⊕⊕, mit dem die mittlere
Antwortzeit des Tools charakterisiert wird. Hierbei bedeutet der Wert
⊕⊕, dass das Werkzeug auf die Benutzereingaben stets prompt reagiert
und für den Benutzer nur kleine Wartezeiten zwischen den einzelnen
Aktionen entstehen. Die tolerierten Wartezeiten hängen dabei von dem
jeweiligen Umfang der auszuführenden Aktionen ab, wodurch die Bewertungen einem subjektiven Einfluss der Tester unterliegen. Eine Bedienzeit vom Wert drückt aus, dass das Tool nicht flüssig und nur
mit ständig auftretenden Wartezeiten bedient werden kann.
Ermittlungsart:
Die Art und Stärke der beim Bedienen des Tools auftretenden Verzögerungen werden textuell erfasst. Daraus und aus der Empfindung, wie
störend dies bei der Arbeit mit dem Werkzeug ist, entsteht der Messwert.
Kommentar:
–
4.2 Funktionale Bewertungskriterien
Hier werden die Kriterien zu funktionalen Features der UML-Werkzeuge vorgestellt.
Seite 27 / 62
UML-Generierung
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
ja → 1
Beschreibung:
Gibt an ob ein Tool in der Lage ist aus bestehendem Code UML-Diagramme zu generieren. Falls ja, wird zusätzlich angegeben, aus welchen
Programmiersprachen dies möglich ist.
Ermittlungsart:
Die Funktion wird während der Evaluation gesucht und anhand eines
Referenzquellcodes getestet.
Kommentar:
-
Code-Generierung
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
ja → 1
Beschreibung:
Gibt an ob ein Tool in der Lage ist aus einem modellierten UML-Diagramm heraus Code zu generieren. Falls ja, wird zusätzlich angegeben,
für welche Programmiersprachen dies möglich ist.
Ermittlungsart:
Die Funktion wird während der Evaluation gesucht und anhand des Referenzmodells getestet.
Kommentar:
-
Diagramm-Aktualisierung
Seite 28 / 62
4.2. Funktionale Bewertungskriterien
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
ja → 1
Beschreibung:
Gibt an ob ein Tool in der Lage ist ehemals generierten Code nach dessen Veränderung wieder zu importieren, um die getätigten Änderungen
im UML-Diagramm nachzutragen.
Ermittlungsart:
Die Funktion wird während der Evaluation gesucht und anhand des Referenzmodells getestet.
Kommentar:
-
Kollaboration
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
ja → 1
Beschreibung:
Gibt an ob ein Tool Funktionen besitzt, die es mehreren Benutzern ermöglichen, an demselben Projekt zu arbeiten. Dazu kann zum Beispiel
eine Versionskontrolle oder eine Aufteilung des Projekts in einzelne Pakete gehören. Eine Liste dieser Funktionen wird textuell festgehalten.
Ermittlungsart:
-
Kommentar:
-
Integration mit anderen Tools
Skala:
Ja / Nein
Skalentyp:
Nominalskala
normierte Skala:
[0, 1]
Seite 29 / 62
ja → 1
Beschreibung:
Gibt an ob ein Tool Standardformate importieren und exportieren kann
und über welche Import- und Exportformate es verfügt.
Ermittlungsart:
Das Referenzmodell wird im Standardformat importiert und exportiert.
Zusätzlich wird eine Liste der Importformate und eine Liste der Exportformate erstellt.
Kommentar:
-
UML-Unterstützung
Skala:
Klassen-, Use-Case-, oder Sequenzdiagramm nicht komplett
weniger als UML 1.4
komplett UML 1.4
komplett UML 1.4, aber weniger als UML 2.1
komplett UML 2.1
Skalentyp:
Ordinalskala
normierte Skala:
[0,0; 0,25; 0,5; 0,75; 1,0]
Skalentransformation: Wenn das Werkzeug nicht vollen Funktionsumfang zumindest bei Klassen, Use-Case- und Sequenzdiagrammen bietet erfolgt die Bewertung
mit → 0,0.
Falls die Software nicht den kompletten UML-Standard 1.4 unterstützt
→ 0,25.
Falls das Werkzeug nur den kompletten UML-Standard 1.4 unterstützt
→ 0,50.
Falls das Tool zwar den kompletten UML-Standard 1.4 unterstützt, aber
nur einige Diagramme aus dem 2.1 Standard → 0,75.
Falls alle UML-Diagramme des 2.1 Standards implementiert sind →
1,0.
Beschreibung:
Gibt die Anzahl der unterstützten UML-Diagrammtypen an.
Ermittlungsart:
Zuerst wird die Vollständigkeit der drei kritischen Diagramme getestet.
Danach wird geprüft, welcher UML-Standard tatsächlich unterstützt anhand der verfügbaren Diagrammen und der Herstellerangaben.
Kommentar:
-
Seite 30 / 62
5 Bewertung der Tools
5.1 ArgoUML
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
Open Source
1,0
GPL
Support
Nein
0,0
Kein offizielles Forum
Weiterentwicklung
ja
1,0
Letztes Release 0.24 vom 21. Februar 2007.
Abstürze
⊕⊕
1,0
Während der Evaluation kam es zu keinen Abstürzen.
⊕
0,75
Die Oberfläche ist eher auf dem Stand von vor
einigen Jahren, aber dennoch funktional.
Σ 27 min
0,625 Use-Case-Diagramm: 4 min (0,75)
Klassendiagramm: 13 min (0,75)
Sequenzdiagramm: 10 min (0,25)
4
0,8
– übersichtlich gestaltet
– dokumentierte API
– Diagrammdruck und -export ohne Skalierung
– Autolayout-Funktionen
Werkzeug-Hilfen
3
1,0
– Hilfe
– Tutorials
– Hilfe zu UML
Startzeit
45 sek
0,5
–
Ladezeit
<1 sek
1,0
–
Speicherzeit
5 sek
1,0
–
Bedienzeit
0,5
Bei Klassendiagrammen etwas träge wenn viele Attribute vorhanden sind. Manchmal hängt die
Oberfläche kurzzeitig (java-typisch).
Fortsetzung auf der nächsten Seite
31
Kapitel 5. Bewertung der Tools
Kriterium
Wert
norm. Bemerkung
Wert
UML-Generierung
ja
1,0
Es werden Java und C++-Klassen unterstützt, sowie IDL-Dateien.
Code-Generierung
ja
1,0
Es werden die Zielformate C#, C++, Java und
PHP unterstützt.
DiagrammAktualisierung
nein
0,0
–
Kollaboration
nein
0,0
–
ja
1,0
Import/Export: XMI, Quellcode
UMLUnterstützung
UML 1.4
0,25
Kritische UML-Diagramme vollständig vorhanden. Das Komponentendiagramm aus dem 1.4
Standard fehlt jedoch.
Anmerkungen zur Software
Die Software benötigt unbedingt ein aktuelles Java Runtime Environment (getestet mit JRE 1.6)
um flüssig bedienbar zu sein. Die gestartete JAR wirft in der Kommandozeile zur Laufzeit einige Fehler, die jedoch im Programm selbst keine Auswirkungen zu haben scheinen; das Tool ist
während der Evaluierung nie abgestürzt.
5.2 BOUML
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
kostenlos
1,0
Freeware (Closed Source)
Support
Ja
1,0
Yahoo Bouml Group
Weiterentwicklung
ja
1,0
Letztes Release 2.3 vom 29. Juli 2007.
Abstürze
⊕⊕
1,0
Seite 32 / 62
5.2. BOUML
Kriterium
Wert
norm. Bemerkung
Wert
0,5
Σ 19,5 min
Sequenzdiagramm: 3,5 min (1,0)
3
0,6
– einfache Installation
Werkzeug-Hilfen
2
0,7
– Hilfe
– Online-Tutorials
Startzeit
3 sek
1,0
–
Ladezeit
3 sek
1,0
–
Speicherzeit
1 sek
1,0
–
Bedienzeit
⊕⊕
1,0
Das Programm reagiert stets flott und ohne Verzögerung.
UML-Generierung
ja
1,0
Es werden Java und C++-Klassen unterstützt.
XMI nur durch Plug-In.
Code-Generierung
ja
1,0
Es werden die Zielformate Java, C++ und IDL
unterstützt. XMI nur durch Plug-In.
nein
0,0
–
Kollaboration
nein
0,0
–
ja
1,0
Es gibt ein Rational Rose Import Plug-In.
UMLUnterstützung
UML 1.4
0,5
Es ist der komplette 1.4 Standard implementiert.
Die Oberfläche ist sehr unkonventionell gestaltet
und lehnt sich leider nicht an andere StandardSoftware an. Es gibt wenig Hilfen für den Benutzer, die Einarbeitung ist mühsam.
In der evaluierten Version ist die gesamte Oberfläche etwas unübersichtlich gestaltet. Die Bedienung ist am Anfang sehr kryptisch, so muss vor der Erstellung eines UML-Diagramms etwa erst
ein sogenannter UML-Diagramm-Container erstellt werden, in dem dann das eigentliche Diagramm erstellt werden kann. Insgesamt lässt sich BOUML nach kurzer Einarbeitung erfreulich
Seite 33 / 62
schnell bedienen und erlaubt schnelle Resultate. Auch die Möglichkeit, einzelne Diagrammelemente in Farbe, Form und Schrift beliebig zu formatieren ist bei diesem UML-Werkzeug
vorhanden. Ferner ist der Export und Import in das offene XMI-Format möglich. Die Software
ist durch Plug-Ins erweiterbar, die von einer wachsenden Fan-Gemeinde erstellt und angeboten
werden auf der Autoren-Website.
5.3 OMONDO EclipseUML
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
Open Source
1,0
In der Free Edition kostenlos
Support
Ja
1,0
Support vorhanden
Forum / Usergroup vorhanden
Weiterentwicklung
Ja
1,0
Releasedatum: März 2007
Abstürze
⊕⊕
1,0
0,0
Wenn im Diagramm gescrollt wird, können die
Quick-Toolbars der Klassen nicht mehr verwendet werden und das Erstellen von Methoden und
Feldern wird umständlicher.
Die selbst erstellten Stereotypes werden nicht gespeichert und können daher nicht verwendet werden.
Nach manuellen Änderungen im Code (welche Teil der Produktphilosophie sind) verschwinden Elemente wie Assoziationskanten aus dem
UML-Diagramm.
Werden beim Bearbeiten des Sequenzdiagramms
mehrere Nachrichten markiert und verschoben,
so entstehen gravierende Anzeigefehler und das
Sequenzdiagramm ist nicht mehr zu benutzen.
Σ 25,5 min
0,5
Use-Case-Diagramm: 2,5 min (0,75)
Klassendiagramm: 17,5 min (0,25)
Seite 34 / 62
5.3. OMONDO EclipseUML
Kriterium
Wert
norm. Bemerkung
Wert
4
0,8
– übersichtlich gestaltet (wer Eclipse kennt hat
aber große Vorteile)
– API vorhanden und dokumentiert (teilweise
aber spärlich)
– Installation umständlich und stark davon abhängig welches Paket man sich heruntergeladen
hat (für Einsteiger undurchsichtig)
– Diagrammdruck
– Auto-Layouter
Werkzeug-Hilfen
2
0,67
– Handbuch im Eclipseformat, daher komfortable Suchfunktion innerhalb der Hilfe
– UML-Hilfe
Startzeit
41
0,5
–
Ladezeit
4
1,0
–
Speicherzeit
<1
1,0
–
Bedienzeit
0,5
Es treten allgemein Wartezeiten auf.
UML-Generierung
Ja
1,0
Der Import ist auf Java Quellcodedateien beschränkt. Es können nur Klassendiagramme generiert werden.
Code-Generierung
Ja
1,0
Das
UML-Klassendiagramm
wird
von
OMONDO EclipseUML direkt in Java Quellcode umgesetzt.
Ja
1,0
Der generierte Java-Quellcode kann auch verändert werden kann.
Kollaboration
Nein
0,0
Dieses Feature steht nur in der Studio Edition zur
Verfügung.
Ja
1,0
Import / Export: xmi, Code
UMLUnterstüzung
komplett
UML 2.1
0,75
Laut Hersteller werden zwar alle Bestandteile
von UML 2.1 unterstützt jedoch sind beim Testen folgende Mängel aufgefallen, die zu Punktabzug geführt haben: Keine Assoziationsklassen
möglich; Kommentare nur außerhalb von Paketen zulässig
Seite 35 / 62
Wie bereits erwähnt gliedert sich Omondo EclipseUML als Plugin in die Java Entwicklungsumgebung von Eclipse ein. Leider sind damit auch einige Nachteile verbunden. In Zusammenhang hiermit ist zunächst die undurchsichtige Installation des Tools zu nennen. Für den in diesem Dokument beschriebenen Test des Tools wurden drei Versuche benötigt um das Werkzeug
funktionsfähig zu installieren. Dies liegt zum einen daran, dass die Eingliederung in ein bereits bestehendes vorinstalliertes Eclipse aus ungeklärten Gründen nicht funktionierte und zum
anderen daran, dass auch die manuelle Zusammenstellung der benötigten Plugins umständlich
ist und gewisse Vorkenntnisse verlangt. So bleibt dem mit Eclipse unerfahrenen Benutzer nur
die Möglichkeit das angebotene Komplettpaket zu verwenden, für welches man sich auf der
Downloadseite des Herstellers jedoch nicht intuitiv entscheiden würde. Zusätzlich sind die Beschreibungen des Herstellers für die einzelnen Softwarepakete auf der Downloadseite des Tools
und im Installer der Software selbst irreführend und teilweise fehlerhaft.
Ein weiterer großer Mangel bei der Verwendung von Omondo EclipseUML stellte sich nach
der Installation der aktuellen Version für Eclipse 3.3 heraus. Diese Version war auf Grund eines
gravierenden Softwarefehlers nicht einsetzbar. Das Konzept von Omondo EclipseUML basiert
darauf, dass es eine Art UML-Editor gibt, der lediglich eine weitere Möglichkeit bietet, das interne UML-Modell zu verändern. Es ist also beispielsweise egal, ob man eine Klasse wie gewohnt
über ihren Quelltext ändert, oder ob man die Veränderungen im Klassendiagramm selbst vornimmt. Die getätigten Änderungen werden gegenseitig übernommen. Das heißt die Umsetzung
(das Übernehmen) der im Klassendiagramm vorgenommenen Veränderungen in den Quelltext
der Klasse ist zentraler Bestandteil der Software. In der oben genannten Version der Software
ist jedoch genau dieser Schritt fehlerhaft. So erzeugt beispielsweise das Ziehen einer Assoziationskante zwischen zwei Klassen Java-Code, der semantisch eine ganz andere Bedeutung hat.
Zusätzlich wird diese falsche Bedeutung beim weiteren Arbeiten mit dem Tool wieder interpretiert und veranlasst dadurch eine ungewollte Veränerung des Klassendiagramms. Aus diesem
Grund konnte das Tool in der aktuellen Version für Eclipse 3.3 nicht getestet werden und es
wurde stattdessen die Vorgängerversion für Eclipse 3.2 verwendet.
5.4 Borland Together
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
1100 e
0,25
Borland Together 2006 Release 2 for Eclipse
Support
Ja
1,0
Es gibt ein Forum, Telefon-, Web-, Emailsupport
kostenlos. Je nach Lizenz erhält man noch weiterer Support.
Weiterentwicklung
Ja
1,0
Releasedatum von Together Release 2: 8.9.2006
Seite 36 / 62
5.4. Borland Together
Kriterium
Wert
norm. Bemerkung
Wert
Abstürze
⊕⊕
1,0
⊕
0,75
Die Assoziationsklasse konnte nicht wie in der
Vorgabe erstellt werden (siehe Anmerkungen).
Σ 34,5 min
0,5
Use-Case-Diagramm: 3 min (0,75)
5
1,0
– Diagrammdruck und -export mit Skalierung
Werkzeug-Hilfen
3
1,0
– Eclipse-Hilfesystem
– Startseite mit Tutorials
– Hilfe zu UML
Startzeit
212s
0,0
–
Ladezeit
3,5s
1,0
Da in Eclipse immer alle geöffneten Projekte
geladen sind, ist hier die Zeit zum Öffnen des
Referenz-Klassendiagramms angegeben.
Speicherzeit
0s
1,0
Man muss bzw. kann die Diagramme nicht explizit speichern. Alle Änderungen werden unmittelbar gespeichert.
Bedienzeit
0,0
Beim Verschieben und Bearbeiten von Diagrammelementen kommt es zu Verzögerungen, was
beispielsweise das Layouten erschwert.
UML-Generierung
Ja
1,0
C++, IDL, Java
Code-Generierung
Ja
1,0
C++, IDL, Java
Ja
1,0
Es ist die sofortige Synchronisierung von Diagramm und Code möglich.
Kollaboration
Ja
1,0
Da Together auf Eclipse basiert ist eine Versionsverwaltung durch CVS und SVN möglich.
Ja
1,0
Import / Export: ecore, XMI, Code
Seite 37 / 62
Kriterium
Wert
norm. Bemerkung
Wert
UMLUnterstüzung
< UML 2.1
0,75
Paketdiagramm, Objektdiagramm, Interaktionsübersichtsdiagramm und Timingdiagramm fehlen.
Die Assoziationsklasse konnte nicht wie in UML 2.1 üblich erstellt werden. Nach dem Versuch,
die gestrichelte Line direkt an die Assoziation zu heften, konnten die zu der Assoziationsklasse
gehörenden Elemente nicht mehr bewegt werden. Diese Veränderung des Diagramms war also
nicht vorgesehen. Allerdings konnte alles problemlos rückgängig gemacht werden.
Die per Default eingestellte Ansicht der Diagramme hat zu wenig Details und die Einstellmöglichkeit ist für Eclipse-Neuling schwer zu finden.
Ansonsten hat Together alles, was man von einem professionellen und vor allem kommerziellen Werkzeug erwartet. Durch die Integration in Eclipse und den großen Funktionsumfang der
Software, sind manche Dinge schwer zu finden oder erscheinen auf den ersten Blick umständlich. Wenn man jedoch richtig mit dem Werkzeug arbeitet kommen die Vorteile wie die direkte
Verknüpfung von Modell und Code zum Tragen.
5.5 Gentleware Poseidon
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
144 e
0,5
5 e monatlich, 13.50 e im Quartal oder 48 e
jährlich. Bei einer angenommenen durchschnittlichen Laufzeit von drei Jahren, in denen ein einmalig bezahltes Tool in derselben Version verwendet werden kann, ergeben sich daraus 144 e.
Support
Ja
1,0
Kostenloser Support vorhanden
Forum / Usergroup vorhanden
Weiterentwicklung
Ja
1,0
Releasedatum: Juni 2007
Abstürze
⊕⊕
1,0
Seite 38 / 62
5.5. Gentleware Poseidon
Kriterium
Wert
norm. Bemerkung
Wert
0,5
Wird beim Bearbeiten eines Sequenzdiagramms
eine Lebenslinie gelöscht, können keinerlei weitere Nachrichten mehr erstellt werden und das
Sequenzdiagramm ist somit wertlos.
Σ 23,5 min
0,75
4
0,8
– API vorhanden und dokumentiert
– Diagrammdruck
Werkzeug-Hilfen
3
1,0
– Tutorial auf der Homepage vorhanden, in der
Software integriert ist ein Standardbeispiel und
ein Abschnitt „Erste Schritte“ in der Hilfe
– Handbuch in Form einer offline Webseite vorhanden, daher aber leider keine komfortable
Suchfunktion innerhalb der Hilfe
– UML-Hilfe
Startzeit
138s
0,0
–
Ladezeit
13s
0,0
–
Speicherzeit
9s
0,5
–
Bedienzeit
0,5
Es treten allgemein Wartezeiten auf, im Speziellen jedoch beim Verschieben von Objekten.
UML-Generierung
Ja
1,0
Der Import ist allerdings auf Java 1.4 Quellcodedateien beschränkt. Es können nur Klassendiagramme generiert werden.
Code-Generierung
Ja
1,0
Es können Java-Klassen erzeugt werden.
Ja
1,0
Wenn die Java Dateien erneut importiert werden,
wird das Poseidon Modell entsprechend angepasst. Das Layout der Diagramme bleibt dabei
erhalten. Allerdings gehen Änderungen, die zuvor am Modell in Poseidon gemacht wurden, verloren.
Kollaboration
Nein
0,0
Es gibt keine integrierte Versionsverwaltung.
Seite 39 / 62
Kriterium
Wert
norm. Bemerkung
Wert
Ja
1,0
UMLUnterstüzung
UML 1.4
0,5
Unterstützt werden alle Diagramme aus UML
1.4, wobei das Objektdiagramm in das Komponentendiagramm und das Verteilungsdiagramm
integriert ist.
Poseidon von Gentleware ist ein einsteigerfreundliches UML-Modellierungstool, das von Beginn an intuitiv zu bedienen ist. Leider versteckt sich in der Software noch der ein oder andere
Fehler, wie beispielsweise der oben beschriebene Fehler beim Bearbeiten von Sequenzdiagrammen.
Wie bereits erwähnt existieren neben der hier getesteten „Community Edition“ noch drei
weitere Varianten in denen die Software vertrieben wird. Diese unterscheiden sich in ihrem
Funktionsumfang teilweise deutlich von der „Community Edition“. So erlaubt die „Professional Edition“ beispielsweise nicht nur die Codegenerierung für Java, sondern auch für weitere
Programmiersprachen, wie C++, C#, VB.net, Delphi und weitere mehr. Weiterhin ist es dem
Benutzer in der „Professional Edition“ möglich für Java Projekte ein Reverse Engineering oder
ein Roundtrip Engineering durchzuführen.
Die genaue Gegenüberstellung der Features der einzelnen Softwarevarianten kann unter http://
www.gentleware.com/edcompare.html eingesehen werden.
5.6 IBM Rational Software Modeler
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
2232 e
(0 e)
0,0
(1,0)
Universitäten erhalten die Software kostenlos
falls ein entsprechendes Programm mit IBM
existiert.
Support
Ja
1,0
Im Kaufpreis enthalten (6 Monate).
Weiterentwicklung
ja
1,0
Releasedatum: März 2007
Seite 40 / 62
5.6. IBM Rational Software Modeler
Kriterium
Wert
norm. Bemerkung
Wert
Abstürze
⊕⊕
1,0
⊕
0,75
Die Oberfläche ist sehr komplex, da sie sich in
die Entwicklungsumgebung (Eclipse) integriert
und diese stellenweise erweitert.
Σ 26 min
0,5
Use-Case-Diagramm: 5 min (0,5)
5
1,0
Werkzeug-Hilfen
3
1,0
– Hilfe
– Tutorials
– Hilfe zu UML
Startzeit
90 sek
0,5
–
Ladezeit
6 sek
0,5
–
Speicherzeit
5 sek
1,0
–
Bedienzeit
⊕⊕
1,0
Die Anwendung arbeitet schnell und ohne Verzögerungen.
UML-Generierung
ja
1,0
Es werden Java, C# und C++-Klassen unterstützt.
Code-Generierung
ja
1,0
Es werden die Zielformate C#, C++, Java unterstützt.
ja
1,0
Durch vollständige Einbindung in die Entwicklungsumgebung ist ein round-cycle-Engineering
möglich.
Kollaboration
ja
1,0
Möglich durch weitere Tools der IBM RationalReihe.
ja
1,0
Import/Export: XMI, Quellcode
UMLUnterstützung
UML 2.0
1,0
Kritische UML-Diagramme vollständig vorhanden.
Seite 41 / 62
Um den Modeler zu installieren, ist der Download eines 1,3 GB großen "Download Managers"von der IBM-Webseite notwendig, der dann wiederum Installationsdateien aus dem Internet nachlädt. Das installierte Produkt kommt dann aber seltsamerweise nur auf ca. 600 MB. Das
Besondere an diesem Werkzeug ist, dass es sich komplett in die Eclipse-Entwicklungsplattform
einklinkt und dort sehr gut mit geöffneten Projekten zusammenarbeitet. Auch ist die Oberfläche
auffallend modern und intuitiv gestaltet, es werden sehr sinnvolle und viele Hilfen in Form von
Auto-Complete-Feldern und Popups angeboten.
5.7 Microsoft Visio
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
699 e
(0 e)
0,25
(1,0)
Studenten der Universität Stuttgart erhalten Visio
kostenlos.
Support
Ja
1,0
Es gibt ein Support-Portal und weiterer kostenpflichtiger Support.
Weiterentwicklung
Ja
1,0
Es gibt Updates für das Office-Paket. Letztes Update 14.6.2007
Abstürze
⊕⊕
1,0
0,5
Bei den Use-Case-Diagrammen gibt es den Stereotyp „include“ nicht, er kann jedoch selbst definiert werden. Im Sequenz-Diagramm können nur
Nachrichten von im Klassendiagramm existierenden Methoden geschickt werden. Die Fehlenden können jedoch direkt angelegt werden. Die
Assoziationskante der Assoziationsklasse verläuft immer horizontal und die Beschriftung kann
nicht verschoben werden.
Σ 30,5 min
0,5
Seite 42 / 62
5.7. Microsoft Visio
Kriterium
Wert
norm. Bemerkung
Wert
5
1,0
Werkzeug-Hilfen
3
1,0
– Hilfe
– Tutorials
– Hilfe zu UML
Startzeit
9s
1,0
–
Ladezeit
13
0,0
–
Speicherzeit
3,5
1,0
–
Bedienzeit
⊕⊕
1,0
–
UML-Generierung
Nein
0,0
Mit Visual Studio können jedoch Daten exportiert werden, die mit Visio als UML importiert
werden können.
Code-Generierung
Nein
0,0
–
Nein
0,0
–
Kollaboration
Nein
0,0
Es gibt keine integrierte Versionsverwaltung.
Nein
0,0
–
UMLUnterstüzung
UML 1.4
0,5
–
Bis auf die bei Fehler und Bedienschwächen erwähnten Dinge eignet sich Visio gut zum Visualisieren der UML-Diagramme, obwohl es nicht primär zur Softwaremodellierung entwickelt
wurde. Wenn man also auf Codegenerierung und Roundcycle-Engineering Features verzichten
kann und einfach UML-Diagramme zeichnen möchte, reicht Visio als Modellierungswerkzeug
aus.
Seite 43 / 62
Kriterium
Wert
norm. Bemerkung
Wert
Kosten
149 e
(79 e)
0,75
Akademische Lizenz der Professional Version
Support
Ja
1,0
Es gibt ein Forum und 12 Monate freien Support
beim Kauf.
Weiterentwicklung
Ja
1,0
Neuestes Releasedatum: EA 7.0 Build 815 vom
03.08.2007
Abstürze
⊕⊕
1,0
0,75
Die Undo-Funktion bezieht sich nur auf das Layout im Diagramm (siehe Anmerkungen). Der
Dialog zum Bearbeiten der Klassen ist gewöhnungsbedürftig.
Σ 26 min
5
1,0
– Diagrammdruck und -export ohne Skalierung
Werkzeug-Hilfen
3
1,0
– Hilfe
– Integrierte Online-Tutorial
– Hilfe zu UML
Startzeit
23,5s
1,0
–
Ladezeit
3s
1,0
–
Speicherzeit
< 1s
1,0
–
Bedienzeit
⊕⊕
1,0
–
UML-Generierung
Ja
1,0
ActionScript, C, C++, C#, Delphi, Java, PHP, Python, VBNet, Visual Basic
Code-Generierung
Ja
1,0
ActionScript, C, C++, C#, Delphi, Java, PHP, Python, VBNet, Visual Basic
Seite 44 / 62
5.8. Sparx Systems Enterprise Architect
Kriterium
Wert
norm. Bemerkung
Wert
Ja
1,0
Der Quellcode und die Diagramme können synchronisiert werden.
Kollaboration
Ja
1,0
EA hat eine integrierte Versionsverwaltung. Projekte können in Pakete aufgeteilt werden, die getrennt bearbeitet und versioniert werden können.
Ja
1,0
UMLUnterstüzung
UML 2.1
1,0
–
In der evaluierten Version EA 6.5 ist die Toolbar etwas unübersichtlich gestaltet. Es passen
wegen der vielen Kategorien nicht alle Werkzeuge in die Ansicht und die Scrollfunktion kann
leicht übersehen werden. Dies wurde jedoch in der neuen Version EA 7.0 verbessert.
Die Undo-Funktion bezieht sich leider nur auf das Layout im Diagramm. So können zum
Beispiel Änderungen von Attributen und Methoden in Klassen nicht rückgängig gemacht werden. In den Diagrammansichten sieht man immer nur eine Repräsentation der Klassen usw.),
so kann dies nicht einmal durch Neuladen rückgängig gemacht werden, da die Änderung sofort
gespeichert wird.
Der Enterprise Architect zeichnet sich dadurch aus, dass man nach einer kurzen Einarbeitungsphase schnell und effektiv UML-Diagramme erstellen kann und auch die RoundcycleEngineering Funktionen einfach zu bedienen sind.
Seite 45 / 62
6 Nutzerprofile
Die Auswahl des richtigen UML-Werkzeugs kann nicht nur an Hand von Bewertungskriterien geschehen. Je nach Einsatzgebiet spielen die einzelnen Kriterien eine unterschiedlich große
Rolle. Beispielsweise können hohe Anschaffungskosten ein KO-Kriterium sein, wenn das Werkzeug im Rahmen eines Praktikums mit 70 Teilnehmern eingesetzt werden soll.
Es wurden die folgenden vier Nutzungsprofile ausgearbeitet, die anschließend genau beschrieben werden:
SoPra – das Softwarepraktikum des Studiengangs Softwaretechnik der Universität Stuttgart
StuPro – ein Studienprojekt im Softwaretechnikstudiengang an der Universität Stuttgart
Diplomarbeit – Einsatz des Werkzeugs im Rahmen einer Diplomarbeit
Unternehmen – ein größeres Unternehmen benötigt ein UML-Werkzeug
Die Summer aller Gewichte beträgt in jedem Profil 100 Punkte, so dass am Ende vergleichbare
Werte entstehen.
6.1 Das SoPra-Profil
Das Profil orientiert sich am Softwarepraktikum des Studiengangs Softwaretechnik der Universität Stuttgart. Jeder Softwaretechnikstudent absolviert im vierten Semester dieses Praktikum.
Die Merkmale des SoPra sind:
Kein Geld: Die Anschaffung des Werkzeugs darf nichts kosten, da das Praktikum ca. 75 Teilnehmer hat und einmal im Jahr stattfindet. Die Kosten sind deshalb in diesem Profil ein
KO-Kriterium.
Viele Personen: Wie erwähnt nehmen ca. 75 Studenten an dem Praktikum teil.
Kleine Arbeitsgruppen: Die Studenten finden sich in Dreiergruppen zusammen. Sie werden voraussichtlich zusammen mit dem UML-Werkzeug arbeiten, darum ist es nicht so
wichtig, dass es Teamarbeit unterstützt.
Wenig Erfahrung: Da die Studenten sich erst im vierten Semester befinden und dies das erste
Praktikum im Rahmen des Studiums ist, ist anzunehmen, dass sie im Entwerfen und mit
UML-Werkzeugen wenig Erfahrung haben. Das Tool muss also einsteigerfreundlich und
leicht zu handhaben sein und beim Erstellen der UML-Diagramme Hilfe anbieten.
Entwicklungssprache Java: Im SoPra wird in Java implementiert, das Werkzeug muss also
nur die Sprache Java unterstützen (z.B.: bei der Codegenerierung).
46
6.1. Das SoPra-Profil
Laufzeit: Nach der Laufzeit des SoPras von einem Semester werden die UML-Diagramme
meist nicht mehr benötigt.
Geringer Projektumfang: Der Projektumfang bestimmt auch die Größe und Anzahl der Diagramme. Die Studenten müssen Use Case-, Klassen- und Sequenzdiagramme erstellen.
Auch die Benutzung von Diagrammelementen wird sich auf die wichtigsten beschränken,
zum Beispiel beim Klassendiagrammen auf Interfaces, Klassen, Vererbung, Assoziation
und Aggregation.
Kriterium
Gewicht
Begründung
Kosten
10
Im SoPra kann für das UML-Werkzeug kein Geld ausgegeben werden, da sehr viele Teilnehmer und kein Budget.
Support
1
Durch kurze Projektdauer und -umfang ist ein Support
nicht notwendig.
Weiterentwicklung
4
Weiterentwicklung garantiert eine gewisse Fehlerfreiheit
der Software.
Abstürze
10
Abstürze der Software sind gerade für kurze Verwendung
eines im gewissen Maße unbekannten Tools sehr ungünstig.
8
Da es sich im SoPra meist um UML-Neulinge handelt führen Inkonsistenzen oder Bugs im Werkzeug zu einer Abwertung der Software.
10
Aufgrund der kurzen Projektdauer ist keine Zeit, sich länglich in ein Werkzeug einzuarbeiten, daher hier sehr hohe
Gewichtung dieses Punktes.
8
Eine hohe Benutzerfreundlichkeit garantiert eine kürzere
Einarbeitungszeit und schnellere Erfolge mit dem Werkzeug.
Werkzeug-Hilfen
8
Für UML-Neulinge sind eine gute Hilfe und passende
UML-Tutorials unerlässlich.
Startzeit
3
Eine lange Startzeit ist für dieses Profil unerheblich.
Ladezeit
4
Eine schnelle Ladezeit ist wünschenswert, langes Laden
stellt aber wohl kein Problem dar.
Speicherzeit
5
Da ein UML-Diagramm öfters gespeichert denn geladen
wird ist die Speicherzeit höher gewichtet als die Ladezeit.
Bedienzeit
8
Flüssige Bedienung wünschenswert, unabhängig vom Anwendungszweck.
Seite 47 / 62
Kapitel 6. Nutzerprofile
Kriterium
Gewicht
Begründung
UML-Generierung
3
In einem SoPra werden die UML-Diagramme von Grund
auf erstellt und nicht aus Code generiert.
Code-Generierung
7
Wahrscheinlicher Einsatzzweck der erstellten UMLDiagramme im SoPra ist die Code-Generierung.
5
Solch eine Funktion kann dazu genutzt werden, die Dokumentation nach der Implementierungsphase aktuell zu halten. Dies ist in den meisten Projekten nützlich und wichtig.
Kollaboration
1
Für das kleine SoPra-Team ist keine Kollaboration notwendig.
2
Nicht notwendig
UMLUnterstützung
3
Für das SoPra sind die Klassendiagramme, Use-CaseDiagramme und Sequenzdiagramme sehr wichtig, die von
allen Werkzeugen beherrscht werden.
6.2 Das StuPro-Profil
Das StuPro ist ein Profil für das Studienprojekt A, das Softwaretechnikstudenten der Universität
Stuttgart im Hauptstudium durchführen. Jedes Semester starten ca. 2-3 Studienprojekte, deren
Ausschreibung sich auf alle Abteilungen der Informatikfakultät bezieht, so dass eine Abteilung
ca. alle zwei Jahre ein StuPro besitzt. Dieses Profil bezieht sich auf die Abteilung Software
Engineering, da diese Studie für sie durchgeführt wurde. Die Merkmale des StuPros sind:
Sehr wenig Geld: Der Abteilung stehen maximal 100 e im Jahr für das Studienprojekt zur
Verfügung, die sie jedoch nicht unbedingt ausgeben will.
Große Gruppe: Das StuPro umfasst eine Gruppe von 6-12 Studenten. Daher kommt es vor,
dass die Arbeiten, die das UML-Werkzeug betreffen, aufgeteilt werden, um die Studenten
im Hinblick auf ihre Arbeitsstunden gleichmäßig auszulasten und den Projektanfang zu
beschleunigen.
Durchschnittliche Erfahrung: Die Teilnehmer des Projekts sind mit dem Entwerfen mit
Hilfe von UML vertraut und benötigen verschiedene Sichten auf den Entwurf durch verschiedene Diagrammtypen.
Entwicklungssprache Java: Im StuPro kann theoretisch in jeder Programmiersprache entwickelt werden. Die Abteilung SE schreibt jedoch meist eine Entwicklung mit Java vor.
Das Werkzeug muss also nur diese Sprache unterstützen (z.B.: bei der Codegenerierung).
Laufzeit: Ein Studienprojekt läuft über den Zeitraum von zwei Semestern und mit bis zu 12
Teilnehmern kann der Umfang des Projekts recht groß werden.
Seite 48 / 62
6.2. Das StuPro-Profil
Mittelgroßes Projekt: Das Studienprojekt kann die Entwicklung einer Software sein oder auf
einer bestehenden Software aufbauen. Deshalb kann der Umfang der UML-Diagramme
groß werden und es kann nötig sein, bestehende Diagramme wiederzuverwenden.
Kriterium
Gewicht
Begründung
Kosten
7
Für die Studienprojekte steht jährlich nur ein kleines Budget zur Verfügung, daher sollte das UML-Werkzeug möglichst wenig kosten oder gar umsonst sein.
Support
2
Als Support ist ein kostenloses Forum sinnvoll aber nicht
unbedingt notwendig.
Weiterentwicklung
5
der Software. Da die Ergebnisse eines Studienprojekts
eventuell in einer Diplomarbeit weitergeführt werden sollen ist die Weiterentwicklung des Tools relativ wichtig.
Abstürze
10
Abstürze der Software sind gerade für die Verwendung eines eher unbekannten Tools sehr ungünstig.
9
In einem StuPro werden die erstellten UML-Modelle oft
angefasst und verändert. Bedienschwächen und Fehler wirken sich dabei sehr nervig und negativ aus und sollten bei
einem UML-Werkzeug hier nicht auftreten.
6
StuPro-Teilnehmer haben schon durch das SoPra Erfahrung in der Modellierung mittels UML, trotzdem ist aufgrund der Gruppengröße für jedes Mitglied eine schnelle
Einarbeitung notwendig.
3
Da ein Studienprojekt relativ lange läuft ist eine hohe Benutzerfreundlichkeit des Werkzeugs nicht unbedingt notwendig aber dennoch wünschenswert. Dennoch stellt z.B.
eine veraltete Oberfläche nach einiger Benutzungszeit kein
Problem mehr dar. Daher ist dieser Punkt geringer gewichtet als etwa beim SoPra.
Werkzeug-Hilfen
7
Da in einem Studienprojekt oft bis dato unbekannte UMLDiagramme zum Einsatz kommen ist eine umfassende Hilfe hierzu unerlässlich.
Startzeit
2
Ladezeit
2
Eine lange Ladezeit ist nicht kritisch, da die UML-Modelle
typischerweise genau einmal pro Sitzung geladen werden.
Seite 49 / 62
Kriterium
Gewicht
Begründung
Speicherzeit
6
Bedienzeit
8
Flüssige Bedienung ist wünschenswert, unabhängig vom
Anwendungszweck.
UML-Generierung
6
Für ein Studienprojekt ist es öfters sinnvoll, aus bestehendem Code UML-Diagramme zu generieren, etwa wenn ein
alter Programmcode ohne aktuelle UML-Diagramme (Dokumentation) vom Kunden vorgegeben werden.
Code-Generierung
7
Die Erstellung von Programmcode aus den UMLModellen ist einer der Haupteinsatzzwecke des UMLWerkzeugs, daher hohe Gewichtung.
7
Solch eine Funktion kann dazu genutzt werden, die Dokumentation nach der Implementierungsphase aktuell zu halten. Dies ist für ein umfangreiches Projekt wie das StuPro
wichtig.
Kollaboration
6
Kollaboration ist bei einer Gruppengröße von 6-12 Mitgliedern wünschenswert.
2
Nicht notwendig
UMLUnterstützung
5
Für das Studienprojekt sind die Klassendiagramme, UseCase-Diagramme und Sequenzdiagramm sehr wichtig.
Aber auch erweiterte Diagramme sollten unterstützt werden.
6.3 Das Diplomarbeit-Profil
Dieses Profil ist für Diplomarbeiten, bei denen ein UML-Werkzeug benötigt wird. Auch hier
wird als Beispiel eine Diplomarbeit in der Abteilung Software Engineering herangezogen. Die
Diplomarbeit wird von einem Studenten durchgeführt und besteht zu einem gewissen Teil aus
der Implementierung einer Software oder Softwarekomponente. Die Merkmale der Diplomarbeit sind:
Wenig Geld: Die Abteilung SE könnte ca. 100 e für Diplomarbeiten pro Semester zur Verfügung stellen.
Einpersonen-Projekt: Die Diplomarbeit wird von einem Studenten durchgeführt, weshalb
das UML-Werkzeug in der Regel keine Teamentwicklung unterstützen muss.
Seite 50 / 62
6.3. Das Diplomarbeit-Profil
Viel Erfahrung: Der Diplomand ist mit UML und Entwerfen vertraut und hat eventuell sehr
spezielle Anforderungen an das Werkzeug. Dies kann ich sich beispielsweise auf besondere UML-Konstrukte, UML- oder Code-Generierung beziehen.
Entwicklungssprache Java: Prinzipiell kann in jeder Sprache entwickelt werden, aber in
der SE-Abteilung ist die Entwicklungssprache meist Java.
Laufzeit: Die Diplomarbeit dauert ein Semester.
Mittelgroßes Projekt: Da die Diplomarbeit auch auf einer bestehenden Software aufbauen
kann, kann die Größe des Gesamtsystems recht groß sein.
Kriterium
Gewicht
Begründung
Kosten
5
Für Diplomarbeiten steht jährlich nur ein kleines Budget
zur Verfügung, daher sollte das UML-Werkzeug möglichst
wenig kosten, auch wenn wenige Lizenzen tatsächliche
notwendig sind (maximal 2-3 Diplomarbeiten in einer Abteilung gleichzeitig).
Support
5
Ein vorhandener Support durch den Hersteller ist wichtig,
vor allem auch da, Software, die im Rahmen einer Diplomarbeit entstanden ist, oft auch nach Beendigung der
Diplomarbeit noch weiterentwickelt wird.
Weiterentwicklung
7
der Software.
Abstürze
10
Abstürze der Software sind sehr ungünstig zumal möglicherweise große Projekte bearbeitet werden.
8
In einer Diplomarbeit werden die erstellten UML-Modelle
oft angefasst und verändert. Bedienschwächen und Fehler
wirken sich dabei sehr nervig und negativ aus und sollten
bei einem UML-Werkzeug nicht auftreten.
3
Bearbeiter einer Diplomarbeit haben umfangreiche Kenntnisse in UML, was ohnehin ein schnelles Einarbeiten garantiert.
3
Durch die mittlere Projektlaufzeit kann auch eine benutzerunfreundliche Oberfläche verwendet werden, diese
stellt nach einmaliger Einarbeitung kein Problem mehr dar.
Werkzeug-Hilfen
5
Da in einer Diplomarbeit oft viele verschiedene UMLDiagramme zum Einsatz kommen ist eine umfassende Hilfe hierzu wünschenswert.
Seite 51 / 62
Kriterium
Gewicht
Begründung
Startzeit
2
Ladezeit
2
Speicherzeit
5
Bedienzeit
8
Anwendungszweck.
UML-Generierung
8
Oft ist es bei Diplomarbeiten notwendig, UMLDiagramme aus nicht korrekt dokumentiertem Programmcode zu generieren.
Code-Generierung
10
Die Erstellung von Programmcode aus den UMLModellen ist einer der Haupteinsatzzwecke des UMLWerkzeugs, daher hohe Gewichtung.
9
Solch eine Funktion kann dazu genutzt werden, die Dokumentation nach der Implementierungsphase aktuell zu
halten. Dies ist für ein umfangreiches Projekt wie eine Diplomarbeit wichtig.
Kollaboration
1
Eine Diplomarbeit wird typischerweise von einem einzelnen Bearbeiter angefertigt, daher ist eine Kollaboration
nicht notwendig.
3
Meist nicht notwendig.
UMLUnterstützung
6
Es werden viele verschiedene UML-Diagramme benötigt.
6.4 Das Unternehmen-Profil
Das Unternehmensprofil steht für das Szenario, in dem ein mittelgroßes bis großes Unternehmen
ein UML-Entwicklungswerkzeug benötigt. Da die Kosten der kommerziellen Werkzeuge oft
sehr hoch sind, soll dieses Profil verhindern, dass daraus immer ein KO-Kriterium wird.
Genügend Geld: Hier wird davon ausgegangen, dass das Unternehmen über die nötigen finanziellen Mittel verfügt, um sich jedes Werkzeug leisten zu können.
Unterschiedliche Projektgruppen: Das Werkzeug wird in den unterschiedlichsten Projekten verwendet, so dass die Anzahl der Beteiligten stark variieren kann.
Seite 52 / 62
6.4. Das Unternehmen-Profil
Viel Erfahrung: Es wird davon ausgegangen, dass es sich bei den Benutzern im Unternehmen
um Experten handelt, die eine Vielzahl an Funktionalität von dem Werkzeug erwarten.
Entwicklungssprache beliebig: Das Unternehmen verwendet die gängigen Programmiersprachen und will sich von dem Werkzeug nicht einschränken lassen.
Laufzeit: Die Laufzeit der einzelnen Projekte kann stark variieren. Es wird davon ausgegangen, dass das Werkzeug nach der Anschaffung in ständiger Benutzung ist.
Unterschiedliche Projekte: Die Größe der Projekte kann von klein über mittel bis groß sein.
Das Werkzeug muss mit jeder Projektgröße zurecht kommen.
Kriterium
Gewicht
Begründung
Kosten
1
Auch wenn kein Unternehmen mehr für ein UMLWerkzeug zahlen will als nötig, spielt in diesem Profil das
Kostenkriterium keine Rolle.
Support
9
Für ein Unternehmen ist ein Hersteller-Support extrem
wichtig, da ein Ausfall der Software meist sehr schnell sehr
viel Geld kosten kann.
Weiterentwicklung
5
der Software und die Verwendung neuer Technologien.
Abstürze
10
Abstürze der Software und der damit verbundene Datenverlust sind unvertretbar wenn kritische Projekte damit
modelliert werden.
8
In einem Unternehmen werden die erstellten UMLModelle oft angefasst und verändert. Bedienschwächen
und Fehler wirken sich dabei extrem auf die Bearbeitungszeit und damit auf die Kosten aus.
5
Die Einsteigerfreundlichkeit stellt oft den entscheidenden
Erfolgsfaktor bei der Einführung dar.
5
Eine benutzerfreundliche Oberfläche ist in jedem Fall
wünschenswert für das effiziente Arbeiten mit einem
Werkzeug.
Werkzeug-Hilfen
5
Gute Werkzeughilfen sind sinnvoll, da Projekte in Unternehmen typischerweise sehr viele UML-Diagrammtypen
verwenden.
Startzeit
1
Das Tool wird sehr selten neu gestartet.
Seite 53 / 62
Kriterium
Gewicht
Begründung
Ladezeit
3
Speicherzeit
3
Bedienzeit
8
Anwendungszweck.
UML-Generierung
3
Meist liegt der Quellcode schon als UML-Diagramme vor
und die Generierung von UML-Diagrammen ist nicht notwendig..
Code-Generierung
7
Die Generierung von Quellcode aus bestehenden Diagrammen ist sehr wichtig für Unternehmensprojekte.
7
Für die Aktualisierung der Dokumentation ist diese Funktion unerlässlich.
Kollaboration
7
Für die typischerweise verteilten und großen Projekte in
einem Unternehmen ist eine Unterstützung für Kollaboration sehr interessant.
5
Komplettes Round-Cycle-Engineering mit integriertem
Test wünschenswert.
UMLUnterstützung
5
Es werden viele verschiedene UML-Diagramme benötigt,
insbesondere auch aus dem UML 2.1 Standard.
Seite 54 / 62
7 Gesamtbewertung
Dieses Kapitel enthält die Auswertung der Evaluation der Werkzeuge. Für jedes Nutzungsprofil
ist eine Tabelle mit der Nutzwertanalyse vorhanden, sowie eine Tabelle, in der die Bewertungen
der Werkzeuge ungewichtet aufsummiert sind.
55
Seite 56 / 62
Kosten
Support
Weiterentwicklung
Abstürze
Werkzeug-Hilfen
Startzeit
Ladezeit
Speicherzeit
Bedienzeit
UML-Generierung
Code-Generierung
Kollaboration
UML-Unterstützung
Gesamt
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
18
Gew.
1,0
0,0
1,0
1,0
0,75
0,625
0,8
1,0
0,5
1,0
1,0
0,5
1,0
1,0
0,0
0,0
1,0
0,25
12,4
ArgoUML
7.1 Gesamtvergleich der Tools
1,0
1,0
1,0
1,0
0,5
0,875
0,6
0,7
1,0
1,0
1,0
1,0
1,0
1,0
0,0
0,0
1,0
0,5
14,2
BOUML
1,0
1,0
1,0
1,0
0,0
0,5
0,8
0,33
0,5
1,0
1,0
0,5
1,0
1,0
1,0
0,0
1,0
0,75
13,4
OMONDO
0,25
1,0
1,0
1,0
0,75
0,5
1,0
1,0
0,0
1,0
1,0
0,0
1,0
1,0
1,0
1,0
1,0
0,75
14,3
Together
0,5
1,0
1,0
1,0
0,5
0,75
0,8
1,0
0,0
0,0
0,5
0,5
1,0
1,0
1,0
0,0
1,0
0,5
12,0
Poseidon
0,0 (1,0)
1,0
1,0
1,0
0,75
0,5
1,0
1,0
0,5
0,5
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
15,3
Rational
0,25 (1,0)
1,0
1,0
1,0
0,5
0,5
1,0
1,0
1,0
0,0
1,0
1,0
0,0
0,0
0,0
0,0
0,0
0,5
10,5
Visio
0,75
1,0
1,0
1,0
0,75
0,625
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
1,0
17,1
EA
Kapitel 7. Gesamtbewertung
Kosten
Support
Weiterentwicklung
Abstürze
Werkzeug-Hilfen
Startzeit
Ladezeit
Speicherzeit
Bedienzeit
UML-Generierung
Code-Generierung
Kollaboration
UML-Unterstützung
Gesamt
10
1
4
10
8
10
8
8
3
4
5
8
3
7
5
1
2
3
100
Gew.
10,0
0,0
4,0
10,0
6,0
6,25
6,4
8,0
1,5
4,0
5,0
4,0
3,0
7,0
0,0
0,0
2,0
0,75
77,9
ArgoUML
10,0
1,0
4,0
10,0
4,0
8,75
4,8
5,6
3,0
4,0
5,0
8,0
3,0
7,0
0,0
0,0
2,0
1,5
81,65
BOUML
7.2 Auswertung des SoPra-Profils
10,0
1,0
4,0
10,0
0,0
5,0
6,4
2,64
1,5
4,0
5,0
4,0
3,0
7,0
5,0
0,0
2,0
2,25
72,79
OMONDO
2,5
1,0
3,0
10,0
6,0
5,0
8,0
8,0
0,0
4,0
5,0
0,0
3,0
7,0
5,0
1,0
2,0
2,25
72,75
Together
5,0
1,0
4,0
10,0
4,0
7,5
6,4
8,0
0,0
0,0
2,5
4,0
3,0
7,0
5,0
0,0
2,0
1,5
70,9
Poseidon
10,0
1,0
3,0
10,0
6,0
5,0
8,0
8,0
1,5
2,0
5,0
8,0
3,0
7,0
5,0
1,0
2,0
3,0
88,5
Rational
10,0
1,0
2,0
10,0
4,0
5,0
8,0
8,0
3,0
0,0
5,0
8,0
0,0
7,0
0,0
0,0
0,0
1,5
72,5
Visio
7,5
1,0
3,0
10,0
6,0
6,25
8,0
8,0
3,0
4,0
5,0
8,0
3,0
7,0
5,0
1,0
2,0
3,0
90,75
EA
7.2. Auswertung des SoPra-Profils
Seite 57 / 62
Seite 58 / 62
Kosten
Support
Weiterentwicklung
Abstürze
Werkzeug-Hilfen
Startzeit
Ladezeit
Speicherzeit
Bedienzeit
UML-Generierung
Code-Generierung
Kollaboration
UML-Unterstützung
Gesamt
7
2
5
10
9
6
3
7
2
2
6
8
6
7
7
6
2
5
100
Gew.
7,0
0,0
5,0
10,0
6,75
3,75
2,4
7,0
1,0
2,0
6,0
4,0
6,0
7,0
0,0
0,0
2,0
1,25
71,15
ArgoUML
7,0
2,0
5,0
10,0
4,5
5,25
1,8
5,6
2,0
2,0
6,0
8,0
6,0
7,0
0,0
0,0
2,0
2,5
76,65
BOUML
7.3 Auswertung des StuPro-Profils
7,0
2,0
5,0
10,0
0,0
3,0
2,4
2,31
1,0
2,0
6,0
4,0
6,0
7,0
7,0
0,0
2,0
3,75
70,46
OMONDO
1,75
2,0
5,0
10,0
6,75
3,0
3,0
7,0
0,0
2,0
6,0
0,0
6,0
7,0
7,0
6,0
2,0
3,75
78,25
Together
3,5
2,0
5,0
10,0
4,5
4,5
2,4
7,0
0,0
0,0
3,0
4,0
6,0
7,0
7,0
0,0
2,0
2,5
70,4
Poseidon
7,0
2,0
5,0
10,0
6,75
3,0
3,0
7,0
1,0
1,0
6,0
8,0
6,0
7,0
7,0
6,0
2,0
5,0
92,75
Rational
7,0
2,0
5,0
10,0
4,5
3,0
3,0
7,0
2,0
0,0
6,0
8,0
0,0
0,0
0,0
0,0
0,0
2,5
60,0
Visio
5,25
2,0
5,0
10,0
6,75
3,75
3,0
7,0
2,0
2,0
6,0
8,0
6,0
7,0
7,0
6,0
2,0
5,0
93,75
EA
Kosten
Support
Weiterentwicklung
Abstürze
Werkzeug-Hilfen
Startzeit
Ladezeit
Speicherzeit
Bedienzeit
UML-Generierung
Code-Generierung
Kollaboration
UML-Unterstützung
Gesamt
5
5
7
10
8
3
3
5
2
2
5
8
8
10
9
1
3
6
100
Gew.
5,0
0,0
7,0
10,0
6,0
1,875
2,4
5,0
1,0
2,0
5,0
4,0
8,0
10,0
0,0
0,0
3,0
1,5
71,775
ArgoUML
5,0
5,0
7,0
10,0
4,0
2,625
1,8
3,5
2,0
2,0
5,0
8,0
8,0
10,0
0,0
0,0
3,0
3,0
79,925
BOUML
5,0
5,0
7,0
10,0
0,0
1,5
2,4
1,65
1,0
2,0
5,0
4,0
8,0
10,0
9,0
0,0
3,0
4,5
79,05
OMONDO
7.4 Auswertung des Diplomarbeit-Profils
1,25
5,0
7,0
10,0
6,0
1,5
3,0
5,0
0,0
2,0
5,0
0,0
8,0
10,0
9,0
1,0
3,0
4,5
81,25
Together
2,5
5,0
7,0
10,0
4,0
2,25
2,4
5,0
0,0
0,0
2,5
4,0
8,0
10,0
9,0
0,0
3,0
3,0
77,65
Poseidon
5,0
5,0
7,0
10,0
6,0
1,5
3,0
5,0
1,0
1,0
5,0
8,0
8,0
10,0
9,0
1,0
3,0
6,0
94,5
Rational
5,0
5,0
7,0
10,0
4,0
1,5
3,0
5,0
2,0
0,0
5,0
8,0
0,0
0,0
0,0
0,0
0,0
3,0
58,5
Visio
3,75
5,0
7,0
10,0
6,0
1,875
3,0
5,0
2,0
1,0
5,0
8,0
8,0
10,0
9,0
1,0
3,0
6,0
94,625
EA
7.4. Auswertung des Diplomarbeit-Profils
Seite 59 / 62
Seite 60 / 62
Kosten
Support
Weiterentwicklung
Abstürze
Werkzeug-Hilfen
Startzeit
Ladezeit
Speicherzeit
Bedienzeit
UML-Generierung
Code-Generierung
Kollaboration
UML-Unterstützung
Gesamt
1
9
5
10
8
5
5
5
1
3
3
8
3
7
7
7
5
5
100
Gew.
1,0
0,0
5,0
10,0
6,0
3,125
4,0
5,0
0,5
3,0
3,0
4,0
3,0
7,0
0,0
0,0
5,0
1,25
59,75
ArgoUML
1,0
9,0
5,0
10,0
4,0
4,375
3,0
3,5
1,0
3,0
3,0
8,0
3,0
7,0
0,0
0,0
5,0
2,5
72,38
BOUML
1,0
9,0
5,0
10,0
0,0
4,0
4,0
1,6
0,5
3,0
3,0
4,0
3,0
7,0
7,0
0,0
5,0
3,75
70,85
OMONDO
7.5 Auswertung des Unternehmen-Profils
0,25
9,0
5,0
10,0
6,0
2,5
5,0
5,0
0,0
3,0
3,0
0,0
3,0
7,0
7,0
7,0
5,0
3,75
81,5
Together
0,5
9,0
5,0
10,0
4,0
6,0
4,0
5,0
0,0
0,0
1,5
4,0
3,0
7,0
7,0
0,0
5,0
2,5
73,5
Poseidon
0,0
9,0
5,0
10,0
6,0
2,5
5,0
5,0
0,5
1,5
3,0
8,0
3,0
7,0
7,0
7,0
5,0
5,0
89,5
Rational
0,25
9,0
5,0
10,0
4,0
2,5
5,0
5,0
1,0
0,0
3,0
8,0
3,0
0,0
0,0
0,0
0,0
2,5
58,25
Visio
0,75
9,0
5,0
10,0
6,0
3,125
5,0
5,0
1,0
3,0
3,0
8,0
3,0
7,0
7,0
7,0
5,0
5,0
92,88
EA
8 Fazit
8.1 SoPra
Die Platzierung der UML-Werkzeuge für das SoPra-Profil ist wie folgt:
1. IBM Rational Software Modeler: 88,5
2. BOUML: 81,65
3. ArgoUML: 77,9
Der Sparx Enterprise Architect würde mit 90,75 Punkten eigentlich den ersten Platz belegen.
Da im SoPra die Kosten jedoch ein KO-Kriterium darstellen, scheidet die Software aus da in der
Auswertung nur Werkzeuge berücksichtigt werden, die für Studenten der Universität Stuttgart
kostenlos sind.
8.2 StuPro
Die Platzierung der UML-Werkzeuge für das StuPro-Profil ist wie folgt:
1. Sparx Enterprise Architect: 93,75 Punkte
2. IBM Rational Software Modeler: 92,75 Punkte
3. Borland Together: 78,25 Punkte
Der Enterprise Architect liegt hier sehr knapp vor dem Modeler von IBM. Da die Evaluationsgenauigkeit nicht hier nicht extrem exakt ist, sind diese Werkzeuge als gleichwertig anzusehen.
Bei der Entscheidung, welches Werkzeug für die SE-Abteilung das geeignetere ist, könnte die
Wahl zu Gunsten des Modelers ausfallen, da der Anschaffungsaufwand gleich null ist. Die Studenten können die Software selbst und kostenlos beziehen.
8.3 Diplomarbeit
Die Platzierung der UML-Werkzeuge für das Diplomarbeit-Profil ist wie folgt:
Auch hier liegen das erst- und das zweitplatzierte Werkzeug zu dicht beieinander, um von
einem Sieger sprechen zu können. Die Wahl des richtigen Werkzeugs sollte also vom genauen
Einsatzzweck abhängen.
61
Kapitel 8. Fazit
8.4 Unternehmen
Die Platzierung der UML-Werkzeuge für das Unternehmen-Profil ist wie folgt:
Für Unternehmen scheinen die kostenlosen Werkzeuge nicht geeignet zu sein. Auch hier sind
die ersten beiden Plätze so dicht beisammen, dass die Wahl des Tools von anderen Faktoren
bestimmt werden sollte. Beispielsweise kann der Preis die Entscheidung beeinflussen oder die
Tatsache, dass ein Unternehmen plant, noch weitere Werkzeuge eines Anbieters anzuschaffen,
so dass eine gute Integration wichtig ist.
Seite 62 / 62

Brauchbare UML-Werkzeuge - Institut für Softwaretechnologie

Transcription

Similar documents

Zitieren von Gesetzesvorschriften - Juristische Fakultät

Vergleich CODESYS V2 zu CODESYS V3

8. Security Engineering

Corel Ventura - DENKMAL2.CHP

Mastertest 2011

PHP und MySQL, OO-PHP, Seitenklassen

Sechs H.264-fähige HD-Multimedia- Streaming - HDTV