Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU
- Art: Diplomarbeit
- Autor: Stefan Krause
- Abgabedatum: Dezember 2003
- Umfang: 123 Seiten
- Dateigröße: 1,5 MB
- Note: 1,0
- Institution / Hochschule: Friedrich-Schiller-Universität Jena Deutschland
- ISBN (eBook): 978-3-8324-7637-3
-
ISBN (Paperback) :
978-3-8324-7637-3 P - ISBN (CD) :978-3-8324-7637-3 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Krause, Stefan Dezember 2003: Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU, Hamburg: Diplomica Verlag
- Schlagworte: Kriterienkatalog, Together, Diagramm, Rational Rose, Poseidon
In den Warenkorb
74,00 €
Diplomarbeit von Stefan Krause
Einleitung:
Die stetig zunehmende Komplexität von Softwareprojekten hat zur Entwicklung von Werkzeugen geführt, die den Software-Entwicklungsprozess unterstützen. Sogenannte CASE1-Werkzeuge helfen dabei, die Arbeit in sämtlichen Phasen des Entwicklungsprozesses zu erleichtern. Als CASE-Werkzeuge bezeichnet man alle Software-Produkte, die Funktionen zur Entwicklung von Software bereitstellen. Durch sie können Routineabläufe automatisiert und das Software-Management erleichtert werden. Außerdem tragen CASE-Werkzeuge dazu bei, die Software-Produktivität zu erhöhen und die Software-Qualität zu verbessern.
Um aus der Vielzahl der am Markt verfügbaren CASE-Werkzeuge dasjenige auswählen zu können, das den gestellten Anforderungen am nächsten kommt, ist eine genaue Betrachtung der Leistungsmerkmale eines Werkzeuges erforderlich. Dabei können Vergleichsstudien von CASE-Werkzeugen den Entscheidungsprozess vereinfachen und beschleunigen. Aus Aufwandsgründen können Vergleichsstudien meistens nur eine geringe Anzahl aus der Vielzahl von Werkzeugen einbeziehen.
In der vorliegenden Arbeit werden vier CASE-Werkzeuge unter dem Gesichtspunkt des Einsatzes in Klein- und mittelständischen Unternehmen (KMU) verglichen. Besonderer Wert wird außerdem auf die Modellierungsmöglichkeiten mit der UML gelegt. Dazu wird im zweiten Kapitel zunächst eine Einführung in UML 1.4 gegeben. In Kapitel drei werden Anforderungen beschrieben, die an CASE-Werkzeuge gestellt werden und es wird eine Vorgehensweise zur Bewertung von CASE-Werkzeugen entwickelt. Die Bewertung wird anhand eines Kriterienkatalogs durchgeführt, der in Kapitel vier aufgeführt ist. Im fünften Kapitel erfolgt die Beschreibung eines Referenzmodells und eines zugehörigen Kataloges von Änderungen, welche mit jedem der untersuchten Werkzeuge in Kapitel sechs modelliert werden. Hier erfolgt außerdem die Evaluierung der Werkzeuge anhand des in Kapitel vier aufgestellten Kriterienkatalogs. Schließlich werden im siebten Kapitel die Bewertungsergebnisse gegenübergestellt. Kapitel acht fasst die Arbeit zusammen und gibt einen Ausblick.
Inhaltsverzeichnis:
| 1. | Einleitung | 5 |
| 2. | Einführung in UML 1.4 | 6 |
| 2.1 | Anwendungsfalldiagramm | 6 |
| 2.2 | Aktivitätsdiagramm | 7 |
| 2.3 | Klassendiagramm | 10 |
| 2.4 | Sequenzdiagramm | 23 |
| 2.5 | Kollaborationsdiagramm | 24 |
| 2.6 | Zustandsdiagramm | 26 |
| 3. | CASE-Werkzeuge | 31 |
| 3.1 | Definition und Ziele | 31 |
| 3.2 | Allgemeine Anforderungen an CASE-Werkzeuge | 32 |
| 3.3 | Vorgehensweise bei der Auswahl eines CASE-Werkzeugs | 33 |
| 3.4 | Modifizierte Vorgehensweise | 33 |
| 4. | Kriterienkatalog | 35 |
| 4.1 | Ausschlusskriterien | 35 |
| 4.2 | Allgemeine Kriterien für CASE-Werkzeuge | 36 |
| 4.3 | Spezielle Kriterien für CASE-Werkzeuge | 39 |
| 4.4 | Spezielle Kriterien bzgl. der Modellierung mit der UML | 41 |
| 5. | Referenzmodell | 44 |
| 5.1 | Anwendungsfälle | 44 |
| 5.2 | Aktivitätsdiagramme | 44 |
| 5.3 | Beschreibung des Klassenmodells | 47 |
| 5.4 | Beschreibung des Änderungskatalogs | 50 |
| 5.4.1 | Änderungen am Klassendiagramm (Abb. 5.6) | 50 |
| 5.4.2 | Änderungen am Sequenzdiagramm (Abb. 5.7) | 50 |
| 5.4.3 | Änderungen am Kollaborationsdiagramm (Abb. 5.8) | 51 |
| 5.4.4 | Änderungen am Zustandsdiagramm (Abb. 5.9) | 51 |
| 6. | Evaluierung der Werkzeuge | 52 |
| 6.1 | Vorauswahl | 52 |
| 6.2 | Bewertungsnotation | 52 |
| 6.3 | INNOVATOR 8.0 | 53 |
| 6.3.1 | Einführung und Beschreibung | 53 |
| 6.3.2 | Bewertung gegenüber dem Kriterienkatalog | 54 |
| 6.3.3 | Bewertung gegenüber dem Änderungskatalog | 65 |
| 6.4 | Together Control Center 6.1 | 68 |
| 6.4.1 | Einführung und Beschreibung | 68 |
| 6.4.2 | Bewertung gegenüber dem Kriterienkatalog | 69 |
| 6.4.3 | Bewertung gegenüber dem Änderungskatalog | 78 |
| 6.5 | Rational Rose Enterprise Edition | 83 |
| 6.5.1 | Einführung und Beschreibung | 83 |
| 6.5.2 | Bewertung gegenüber dem Kriterienkatalog | 83 |
| 6.5.3 | Bewertung gegenüber dem Änderungskatalog | 92 |
| 6.6 | Poseidon for UML Professional Edition 2.0.2 | 97 |
| 6.6.1 | Einführung und Beschreibung | 97 |
| 6.6.2 | Bewertung gegenüber dem Kriterienkatalog | 97 |
| 6.6.3 | Bewertung gegenüber dem Änderungskatalog | 105 |
| 7. | Auswertung | 110 |
| 7.1 | Ausschlusskriterien | 110 |
| 7.2 | Allgemeine Kriterien für CASE-Werkzeuge | 110 |
| 7.3 | Spezielle Kriterien für CASE-Werkzeuge | 111 |
| 7.4 | Spezielle Kriterien bzgl. der Modellierung mit der UML | 112 |
| 7.5 | Modellierung des Referenzmodells | 112 |
| 7.6 | Zusammenfassung | 112 |
| 8. | Zusammenfassung und Ausblick | 113 |
| Literaturverzeichnis | 114 | |
| Abbildungsverzeichnis | 114 | |
| Anhang | 117 |
Abbildung 2.44: Parallele Zustände. Ereignis und Transition Ein Ereignis ist ein in einem bestimmten Kontext bedeutsames Vorkommnis, das sich räumlich und zeitlich lokalisieren lässt und einen Zustandsübergang (Transition) auslöst. Es kann folgende Ursachen haben: - Eine Bedingung für einen Zustandsübergang wird erfüllt. - Das Objekt erhält eine Nachricht. Zustandsdiagramme beschreiben Situationen in denen ein Objekt bestimmte Ereignisse erhalten darf und wie sich diese auf den Status des Objektes auswirken. Voraussetzung für die Verarbeitung bestimmter Ereignisse ist, dass sich das Objekt in einem dafür geeigneten Zustand befindet. Dass ein Ereignis zu unterschiedlichen Aktionen führen kann, abhängig vom Zustand in dem sich das Objekt befindet und welche Bedingungen an das Ereignis geknüpft sind, kann ebenfalls im Diagramm ausgedrückt werden. Ereignisse werden auf Pfeilen (Abb. 2.45) zwischen den Zuständen notiert und lösen Zustandsübergänge aus. Bei fehlender Beschriftung der Übergänge erfolgt die Auslösung automatisch nachdem die mit einem Zustand verbundenen Aktionen abgeschlossen sind. Eine Transitionsbeschreibung hat folgende Notation: ereignis(argumente) [...]
Zustandsübergänge werden durch Ereignisse ausgelöst, welche aus einem Namen und einer Liste von möglichen Argumenten bestehen. An diese Ereignisse können von einem Zustand Bedingungen geknüpft werden, die erfüllt sein müssen, damit ein Zustand eingenommen werden kann. Dabei ist die Definition einer Bedingung unabhängig von einem speziellen Ereignis. Durch Ereignisse können Aktionen innerhalb eines Zustandes ausgelöst werden, die durch entsprechende Operationen realisiert werden. Als spezielle Auslöser sind vordefiniert: → entry - löst automatisch beim Eintritt in einen Zustand aus → exit - löst automatisch beim Verlassen eines Zustandes aus → do - wird solange ausgelöst wie der Zustand aktiv ist Die Darstellung von Zuständen (Abb. 2.42) erfolgt mittels abgerundeter Rechtecke. Diese können einen Namen enthalten und in bis zu drei Bereiche eingeteilt werden. Neben dem Namen des Zustandes kann das Diagramm Zustandsvariablen sowie eine Liste möglicher interner Ereignisse, Bedingungen und daraus resultierender Operationen beinhalten. [...]
Der Zustand eines Objektes innerhalb des dargestellten Szenarios wird mit «new», «destroyed» oder «transient» gekennzeichnet. Die Beziehung zwischen zwei Objekten kann in einem Kollaborationsdiagramm speziell gekennzeichnet werden. Dabei kann einer der folgenden Stereotypen vor das nachrichtenempfangende Objekt auf die Verbindungslinie notiert werden. - «association» Die Grundlage der Objektbeziehung ist eine Assoziation, Aggregation oder Komposition. Diese Angabe kann entfallen, da sie der Standardfall ist. - «global» Das empfangende Objekt ist global. - «local» Das empfangende Objekt ist lokal in der sendenden Operation. - «parameter» Das empfangende Objekt ist ein Parameter in der sendenden Operation. - «self» Das empfangende Objekt ist das sendende Objekt. Es existieren spezielle Synchronisationsmerkmale, die in folgender Form ausgedrückt werden: [...]
In den Warenkorb
74,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832476373
Arbeit zitieren:
Krause, Stefan Dezember 2003: Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU, Hamburg: Diplomica Verlag
Schlagworte:
Kriterienkatalog, Together, Diagramm, Rational Rose, Poseidon



