Vergleich von CASE-Werkzeugen zur Modellierung von Softwaresystemen mittels UML für KMU

Inhaltsverzeichnis

1 Einleitung

2 Einführung in UML
2.1 Anwendungsfalldiagramm
2.2 Aktivitätsdiagramm
2.3 Klassendiagramm
2.4 Sequenzdiagramm
2.5 Kollaborationsdiagramm
2.6 Zustandsdiagramm

3 CASE-Werkzeuge
3.1 Definition und Ziele
3.2 Allgemeine Anforderungen an CASE-Werkzeuge
3.3 Vorgehensweise bei der Auswahl eines CASE-Werkzeugs
3.4 Modifizierte Vorgehensweise

4 Kriterienkatalog
4.1 Ausschlusskriterien
4.2 Allgemeine Kriterien für CASE-Werkzeuge
4.3 Spezielle Kriterien für CASE-Werkzeuge
4.4 Spezielle Kriterien bzgl. der Modellierung mit der UML

5 Referenzmodell
5.1 Anwendungsfälle
5.2 Aktivitätsdiagramme
5.3 Beschreibung des Klassenmodells
5.4 Beschreibung des Änderungskatalogs
5.4.1 Änderungen am Klassendiagramm (Abb. 5.6)
5.4.2 Änderungen am Sequenzdiagramm (Abb. 5.7)
5.4.3 Änderungen am Kollaborationsdiagramm (Abb. 5.8)
5.4.4 Änderungen am Zustandsdiagramm (Abb. 5.9)

6 Evaluierung der Werkzeuge
6.1 Vorauswahl
6.2 Bewertungsnotation
6.3 INNOVATOR 8
6.3.1 Einführung und Beschreibung
6.3.2 Bewertung gegenüber dem Kriterienkatalog
6.3.3 Bewertung gegenüber dem Änderungskatalog
6.4 Together Control Center 6.1
6.4.1 Einführung und Beschreibung
6.4.2 Bewertung gegenüber dem Kriterienkatalog
6.4.3 Bewertung gegenüber dem Änderungskatalog
6.5 Rational Rose Enterprise Edition
6.5.1 Einführung und Beschreibung
6.5.2 Bewertung gegenüber dem Kriterienkatalog
6.5.3 Bewertung gegenüber dem Änderungskatalog
6.6 Poseidon for UML Professional Edition 2.0
6.6.1 Einführung und Beschreibung
6.6.2 Bewertung gegenüber dem Kriterienkatalog
6.6.3 Bewertung gegenüber dem Änderungskatalog

7 Auswertung
7.1 Ausschlusskriterien
7.2 Allgemeine Kriterien für CASE-Werkzeuge
7.3 Spezielle Kriterien für CASE-Werkzeuge
7.4 Spezielle Kriterien bzgl. der Modellierung mit der UML
7.5 Modellierung des Referenzmodells
7.6 Zusammenfassung

8 Zusammenfassung und Ausblick

Literaturverzeichnis

Abbildungsverzeichnis

Anhang

Zusammenfassung

In der vorliegenden Arbeit wird die Leistungsfähigkeit von CASE-Werkzeugen für den Einsatz in Klein- und mittelständischen Unternehmen untersucht. Besonderes Augen-merk liegt dabei auf der Modellierung mit der UML. Zu diesem Zweck wird ein Kriterien-katalog erstellt, welcher die verschiedenen Aspekte von CASE-Werkzeugen beleuch-tet. Anhand dieses Kataloges werden alle zu bewertenden Werkzeuge auf die Erfüllung der enthaltenen Kriterien untersucht. Außerdem wird ein Beispielprojekt entwickelt, an-hand dessen die Modellierungsmöglichkeiten überprüft werden. Den organisatorischen Rahmen bildet eine in dieser Arbeit entwickelte Vorgehensweise zur Evaluierung von CASE-Werkzeugen.

Danksagung

An dieser Stelle möchte ich allen danken, die mich bei der Anfertigung dieser Arbeit unterstützt haben. Mein besonderer Dank gilt dabei Herrn Prof. Dr. Wilhelm Rossak und Herrn Dipl. Inf. Christian Erfurth für ihre freundliche Betreuung.

1 Einleitung

Die stetig zunehmende Komplexität von Softwareprojekten hat zur Entwicklung von Werkzeugen geführt, die den Software-Entwicklungsprozess unterstützen. Sogenannte CASE¹ -Werkzeuge helfen dabei, die Arbeit in sämtlichen Phasen des Entwicklungspro-zesses zu erleichtern. Als CASE-Werkzeuge bezeichnet man alle Software-Produkte, die Funktionen zur Entwicklung von Software bereitstellen. Durch sie können Rou-tineabläufe automatisiert und das Software-Management erleichtert werden. Außer-dem 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. Beson-derer 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 aufge-führt ist. Im fünften Kapitel erfolgt die Beschreibung eines Referenzmodells und eines zugehörigen Kataloges von Änderungen, welche mit jedem der untersuchten Werk-zeuge in Kapitel sechs modelliert werden. Hier erfolgt außerdem die Evaluierung der Werkzeuge anhand des in Kapitel vier aufgestellten Kriterienkatalogs. Schließlich wer-den im siebten Kapitel die Bewertungsergebnisse gegenübergestellt. Kapitel acht fasst die Arbeit zusammen und gibt einen Ausblick.

2 Einführung in UML 1.4

Die UML ist eine Sprache und Notation zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme. Sie deckt ein breites Spektrum von Anwendungsgebieten ab und eignet sich u.a. für konkurrierende, verteilte, zeitkritische und sozial eingebettete Systeme.

Im Folgenden werden die wichtigsten Modellierungselemente der UML vorgestellt. Dabei wird von der Version 1.4 ausgegangen. Eine ausführliche Beschreibung der UML findet man in [Oestereich01], [Stevens00], [Rumbaugh99] sowie unter [OMG]. Für Be-griffe aus der Objektorientierung sei auf die einschlägige Literatur verwiesen.

2.1 Anwendungsfalldiagramm

In einem Anwendungsfalldiagramm werden die Beziehungen zwischen einer Menge von Anwendungsfällen und den daran beteiligten Akteuren gezeigt. Ein Anwendungs-falldiagramm bildet somit einen Kontext und eine Gliederung für die Beschreibung von Geschäftsvorfällen.

Ein Beispiel für einen Geschäftsvorfall ist die schriftliche Schadensmeldung eines Hausratversicherten. Der gesamte Ablauf für die Verarbeitung dieses Ereignisses wird durch einen Geschäftsprozess (z.B. ’Hausratschaden melden’) beschrieben. Dabei ist zu beachten, dass auch Aktivitäten dargestellt werden können, die nicht durch die zu entwickelnde Anwendung unterstützt werden.

Anwendungsfalldiagramme sind in erster Linie ein Hilfsmittel zur Anforderungsermitt-lung und kein Designansatz oder eine Beschreibung des internen Verhaltens eines zu entwickelnden Systems. Primär werden Anwendungsfälle dazu verwendet die Kommu-nikation mit Anwendern und Auftraggebern zu unterstützen. Sie beschreiben das exter-ne Systemverhalten, also die Leistungsmerkmale eines Systems. Darüber wie dieses Systemverhalten realisiert wird, treffen Anwendungsfälle keine Aussage.

Abbildung 2.1 zeigt die verschiedenen Notationselemente eines Anwendungsfalldia-gramms.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Notationselemente des Anwendungsfalldiagramms.

2.2 Aktivitätsdiagramm

Aktivitätsdiagramme beschreiben die Ablaufmöglichkeiten eines Systems mit Hilfe von Aktivitäten. Eine Aktivität ist ein Zustand mit einer internen Aktion und einer oder mehreren ausgehenden Transitionen (Zustandsübergängen), die automatisch dem Abschluss der internen Aktion folgen. Sie stellt somit einen einzelnen Schritt in einem Verarbeitungsablauf dar. Im Falle von mehreren ausgehenden Transitionen müssen diese durch Bedingungen unterscheidbar sein.

Aktivitätsdiagramme unterstützen die Beschreibung nebenläufiger Aktivitäten. Dabei ist die Reihenfolge von parallel laufenden Aktivitätspfaden irrelevant, d.h. sie können nacheinander, gleichzeitig oder abwechselnd laufen.

Aktivitäten und Aktivitätsdiagramme sind entweder einer Klasse, einer Operation oder einem Anwendungsfall zugeordnet und beschreiben die internen Ablaufmöglichkeiten dieser Modellelemente.

In einem Aktivitätsdiagramm kann man Aktivitäten hierarchisch schachteln, so dass eine einzelne Aktivität aus mehreren Detailaktivitäten besteht. Dabei müssen die eingehenden und ausgehenden Transitionen der zusammengesetzten Aktivität und des Detailmodells übereinstimmen.

Aktivitätsdiagramme lassen sich in Verantwortungsbereiche unterteilen. Dadurch kön-nen die Aktivitäten anderen Elementen oder Strukturen zugeordnet werden. Man kann damit z.B. ausdrücken, zu welcher Klasse oder Komponente die Aktivitäten gehören.

Multiple Transitionen bzw. Auslöser bieten eine weitere Möglichkeit parallele Abläufe darzustellen.

Aufgrund der genannten Darstellungselemente sind Aktivitätsdiagramme geeignet die unterschiedlichsten Arten von Abläufen darzustellen. Fachliche Zusammenhänge und Abhängigkeiten, die sich hinter einem Anwendungsfall verbergen, lassen sich mit ihnen vollständig beschreiben. Ein Aktivitätsdiagramm kann außerdem Sachverhalte aus mehreren Anwendungsfällen beschreiben sowie Geschäftsregeln und Entschei-dungslogik abbilden.

Die Darstellung einer Aktivität (Abb. 2.2) erfolgt durch ein benanntes Rechteck mit gerader Ober- und Unterseite und runden Seitenlinien. Es enthält eine Aktivitätsbeschreibung, die aus einem Namen, einer frei formulierten Beschreibung, Pseudocode oder Programmiersprachencode bestehen kann. Transitionen werden wie in einem Zustandsdiagramm als Pfeile dargestellt. Eine Ereignisbeschriftung entfällt, da die Transitionen implizit durch den Abschluss der Aktivität ausgelöst werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Aktivitäten und Transition.

Bedingungen und Verzweigungen

Ausgehende Transitionen können mit in eckigen Klammern stehenden Bedingungen (boolsche Ausdrücke) versehen werden. Als Alternative können Verzweigungen, dargestellt durch Rauten (Abb. 2.3), verwendet werden. Eine solche Raute stellt ebenfalls eine Entscheidungsaktivität dar.

Und- und Oder-Synchronisation

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Entscheidung/Verzweigung.

Transitionen können synchronisiert, zusammengeführt und aufgeteilt werden (Abb. 2.4). Bei einer Zusammenführung von mehreren Transitionen setzt sich der Aktionsfluss fort, sobald eine Transition eingeht. Die Synchronisation setzt dagegen voraus, dass alle eingehenden Transitionen vorliegen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Zusammengesetzte Aktivität.

Schleifen

Für eine Schleife ist lediglich eine Abbruchbedingung und eine zurückführende Transiti-on notwendig (Abb. 2.6). Innerhalb der Schleife sind beliebig viele Aktivitäten zulässig.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Wiederholung/Schleife.

Optionale Aktivitäten

Vor einer optionalen Aktivität (Abb. 2.7) wird eine bedingte Verzweigung notiert. Die Zweige werden anschließend wieder zusammengeführt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Optionale Aktivität.

Signale senden und empfangen

Signale können beim Übergang zwischen zwei Aktivitäten an ein Objekt gesendet werden. Ebenso kann der Start einer Aktivität das Eintreffen eines Signals voraussetzen. Abbildung 2.8 zeigt die zugehörigen Notationselemente. Mit ihrer Hilfe lassen sich z.B. nebenläufige Prozesse synchronisieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: Interprozesskommunikation.

Objektzustand

Aktivitäten rufen häufig Änderungen am Objektzustand hervor. Ein Objektzustand wird durch ein Rechteck mit dem Objektnamen und dem Objektzustand in eckigen Klam-mern notiert. Eine gestrichelte Transitionslinie von einem Objektzustand zu einer Akti-vität bedeutet, dass die Aktivität einen Ausgangszustand verlangt. Umgekehrt zeigt der Objektzustand den aus einer Aktivität resultierenden Zustand. Die Notation von Objekt-zuständen (Abb. 2.9) ist optional und dient der Hervorhebung besonderer Sachverhalte.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Resultierende bzw. vorausgesetzte Objektzustände.

2.3 Klassendiagramm

Klassendiagramme werden verwendet, um die statische Struktur eines Systems zu dokumentieren. Dazu gehört zu ermitteln, welche Klassen es gibt und in welcher Beziehung sie zueinander stehen. Im Folgenden werden die einzelnen Elemente von Klassendiagrammen erläutert.

Klasse

Eine Klasse beschreibt die Struktur und das Verhalten von Objekten, die aus ihr erzeugt werden können. Sie beinhaltet die Definition von Attributen und Operationen sowie der Semantik für eine Menge von Objekten. Die Objekte werden aus Klassen erzeugt und stellen die in einer Anwendung zur Programmlaufzeit agierenden Einheiten dar. Opera-tionen werden in der Objektorientierung sehr häufig auch als Methoden bezeichnet. Das Verhalten eines Objektes wird durch die möglichen Nachrichten, die es versteht, beschrieben. Ein Objekt benötigt dabei zu jeder Nachricht eine entsprechende Opera-tion.

Eine Klasse wird, wie in Abbildung 2.10 gezeigt, durch ein Rechteck mit einem Klassennamen und ggf. Attributen und Operationen dargestellt. Klassenname, Attribute und Operationen werden dabei jeweils durch eine horizontale Linie getrennt. Ein Klassenname ist ein Substantiv und beginnt mit einem Großbuchstaben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: Notationsmöglichkeiten für Klassen.

Metaklasse

In der UML können Klassenoperationen und Klassenattribute in einer Metaklasse oder in der Klasse selbst notiert werden. Innerhalb der Klasse müssen sie allerdings unterstrichen werden, um sie von normalen Operationen und Attributen unterscheiden zu können. Abbildung 2.11 zeigt die Notation einer Metaklasse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.11: Metaklasse.

Parametrisierbare Klasse

Eine parametrisierbare Klasse definiert eine Schablone zur Erzeugung von Klassen. In statisch typisierten Sprachen sind parametrisierbare Klassen ein wichtiges Hilfsmit-tel um wiederverwendbaren Code zu erzeugen. Die graphische Notation (Abb. 2.12) ist ähnlich der von Klassen. Zusätzlich können noch Parameter in einem gestrichelten Rechteck notiert werden. Zu den Klassen, die aus parametrisierbaren Klassen entste-hen, existiert eine Verfeinerungsbeziehung mit dem Stereotyp «bind» (s. S.16).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.12: Schablonenklasse mit Verfeinerungsbeziehung.

Abstrakte Klasse

Eine abstrakte Klasse ist eine allgemeine Oberklasse für eine Menge von konkreten Un-terklassen. Abstrakt bedeutet, dass für mindestens eine ihrer Operationen keine Imple-mentierung existiert. Darum ist es auch nicht möglich eine abstrakte Klasse zu instanti-ieren. Die Darstellung (Abb. 2.13) ist gleich der von normalen Klassen mit dem Zusatz abstrakt in geschweiften Klammern unter dem Klassennamen. Eine andere Möglichkeit ist den Klassennamen kursiv zu schreiben. Für die Operationen gilt das gleiche.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.13: Verschiedene Notationsmöglichkeiten für abstrakte Klassen.

Hilfsmittelklasse

In Hilfsmittelklassen werden globale Variablen und Funktionen zusammengefasst, die als Klassenattribute und Klassenoperationen definiert werden. Sie werden mit dem Stereotyp «utility» gekennzeichnet. Abbildung 2.14 zeigt die graphische Notation einer Hilfsmittelklasse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.14: Hilfsmittelklasse.

Objekt

Ein Objekt ist eine Instanz einer Klasse. Es besitzt Attribute und kann die in seiner Klasse definierten Nachrichten mit Hilfe von entsprechenden Operationen empfangen. Die Nachrichten definieren das Verhalten eines Objektes. Dieses Verhalten ist für alle Objekte einer Klasse gleich, ebenso die Struktur der Attribute.

Dargestellt werden Objekte (Abb. 2.15) durch Rechtecke. Diese beinhalten entweder nur den Objektnamen, zusätzlich auch den Klassennamen oder auch die Attributwerte. Die Attributwerte werden durch eine horizontale Linie vom Objektnamen getrennt. Der Objektname wird zusätzlich unterstrichen und beginnt mit einem Kleinbuchstaben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.15: Notationsmöglichkeiten für Objekte.

Klassen-Objekt-Beziehungen werden durch einen gestrichelten Pfeil (Abb. 2.16) dargestellt. Dabei zeigt das Objekt auf seine Klasse.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.16: Instantiierungsbeziehung.

Schnittstelle, Schnittstellenklasse

Mit einer Schnittstelle wird das externe Verhalten von Klassen spezifiziert. Sie beinhaltet eine Menge von Signaturen für Operationen, welche durch eine Klasse implementiert werden muss, die diese bestimmte Schnittstelle bereitstellen will.

Schnittstellen werden mit dem Stereotyp «interface» gekennzeichnet (Abb. 2.17). Ei-ne Schnittstellen-Klasse ist abstrakt und definiert ausschließlich abstrakte Operationen. Eine Kennzeichnung der Operationen mit abstrakt ist deshalb nicht erforderlich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.17: String realisiert die Schnittstelle Sortierbar.

Von einer Klasse können mehrere Schnittstellen implementiert werden. Des weiteren kann die Klasse natürlich noch zusätzliche Eigenschaften enthalten. Eine Schnittstelle beschreibt somit in der Regel eine Untermenge der Operationen einer Klasse. Zwi-schen der implementierenden Klasse und der Schnittstellenklasse besteht eine Rea-lisierungsbeziehung, die durch einen gestrichelten Pfeil mit dem Stereotyp «realize» dargestellt wird.

Alternativ kann eine Schnittstelle auch durch das ’Lolli’-Symbol (Abb. 2.18) oder als einzelner Kreis dargestellt werden.

Zwischen Schnittstellenklassen können Vererbungsbeziehungen bestehen. Diese werden durch das Stereotyp «extend» ausgedrückt. Zu beachten ist dabei, dass nur abstrakte Operationen hinzugefügt werden können.

Eine Schnittstellenklasse kann mehrere verschiedene Schnittstellen erweitern und somit mehrere Oberklassen haben. In bezug auf Mehrfachvererbung bei normalen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.18: Schnittstellen als Lolli-Symbol und alleinstehend.

Klassen stellt dies jedoch kein Problem dar, da hier lediglich Mengen von Signaturen zusammengefasst werden.

Man kann dem Schnittstellenkonzept eine größere Mächtigkeit verleihen, indem man für die in den Schnittstellen definierten Signaturen Zusicherungen, wie z.B. Vorbedingungen, Nachbedingungen, Invarianten oder Ausnahmen, spezifiziert.

Zusicherung, Object Constraint Language (OCL)

Eine Zusicherung ist ein Ausdruck, der eine Bedingung oder Integritätsregel beschreibt. mit ihr lassen sich die zulässigen Wertemengen von Attributen beschreiben, Vor- oder Nachbedingungen für Nachrichten bzw. Operationen angeben, strukturelle Eigenschaf-ten zusichern u.v.m.

Zusicherungen können frei formuliert oder als Eigenschaftswert, Stereotyp oder Ab-hängigkeit notiert werden. Es besteht die Möglichkeit, sie an andere Notationselemente wie Attribute, Operationen, Klassen und jede Form von Klassenbeziehungen anzuhän-gen.

Die Notation von Zusicherungen erfolgt innerhalb geschweifter Klammern, wenn sie mit einem Modellelement verbunden sind oder mit Hilfe der Object Constraint Language über das Schlüsselwort context.

Beispiel:

{ Zusicherung }

context VerantwortlichesModellelement inv: Zusicherung

Die Object Constraint Language ist eine formale Sprache. Mit ihrer Hilfe kann UMLModellen zusätzliche Semantik angefügt werden, die mit gewöhnlichen UML-Elementen nicht oder nur unzureichend ausgedrückt werden kann.

Eingeleitet werden OCL-Ausdrücke durch einen Kontext für eine spezifische Instanz:

context Gegenstand inv:

self.eigenschaft

Self ist eine spezifische Instanz von Kontext und inv: steht für Invariante. Eine ausführliche Beschreibung der OCL findet man in [Warmer99].

Eigenschaftswert

Eigenschaftswerte sind benutzerdefinierte, sprach- und werkzeugspezifische Schlüsselwort-Wert-Paare, die der Semantik einzelner Modellelemente spezielle charakteristische Eigenschaften hinzufügen können.

So wie Attribute die Eigenschaften von Klassen näher bestimmen, können Eigen-schaftswerte die Eigenschaften von beliebigen Modellelementen genauer beschreiben. Eigenschaftswerte können beliebig und willkürlich vergeben werden. Es ist jedoch sinn-voll, sie innerhalb eines Projektes auf eine wohldefinierte Menge zu beschränken.

Eigenschaftswerte bestehen aus einem Schlüsselwort und einem Wert. Sie werden einzeln oder als Aufzählung in geschweiften Klammern notiert.

Beispiele:

Abbildung in dieser Leseprobe nicht enthalten

Stereotyp

Mit Hilfe von Stereotypen werden die Verwendungsmöglichkeiten von Modellelementen klassifiziert. Dabei werden einer oder mehreren Klassen bestimmte, gemeinsame Eigenschaften zugeordnet.

Stereotypen haben keine Typsemantik, wie Typen oder Klassen. Sie ermöglichen eine semantisch-konzeptionelle und visuelle Unterscheidung und geben Hinweise auf die Verwendung von Modellelementen.

Im Gegensatz zu Eigenschaftswerten wird durch Stereotypen das Metamodell um neue Modellelemente erweitert. Dagegen werden mit Eigenschaftswerten einzelne Aus-prägungen bestehender Modellelemente um bestimmte Eigenschaften erweitert.

Ein Stereotyp wird vor bzw. über dem Elementnamen in doppelte spitze Klammern notiert oder durch spezielle Symbole dargestellt.

Beispiele:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.19: Stereotypen.

Generalisierung, Spezialisierung

Generalisierung und Spezialisierung sind Abstraktionsprinzipien zur hierarchischen Struk-turierung der Semantik eines Modells. Hierbei werden allgemeine Eigenschaften in Oberklassen und speziellere Eigenschaften in Unterklassen zusammengefasst. Die Oberklassen vererben ihre Eigenschaften an die entsprechenden Unterklassen. Diese verfügen somit über die in ihnen spezifizierten Eigenschaften sowie denen ihrer Oberklassen. Die geerbten Eigenschaften können überschrieben und erweitert, jedoch nicht eliminiert bzw. unterdrückt werden.

Die Einteilung in Ober- und Unterklassen geschieht mit Hilfe eines Unterscheidungs-merkmals, genannt Diskriminator (Abb. 2.20). Dieser stellt den entscheidenden Ge-sichtspunkt dar, unter dem die Strukturierung erfolgen soll und ist das Ergebnis einer Modellierungsentscheidung. Die Menge der Unterklassen mit gleichem Diskriminator wird Partition genannt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.20: Direkte und baumartige Notation von Vererbungsbeziehungen.

Man unterscheidet drei Arten von Vererbung: Spezialisierungsvererbung, Spezifikationsvererbung und Implementierungsvererbung.

Die Spezialisierungsvererbung, auch ist-ein-Vererbung oder is-a-Inheritance genannt, ist die häufigste Form der Vererbung. Hierbei werden die Definitions- und Werteberei-che sowie die Vor- und Nachbedingungen von Operationen in der Regel eingeschränkt bzw. verschärft.

Bei der Spezifikationsvererbung gilt für Operationen, die in Unterklassen überschrie-ben werden, dass sie keine strengeren Vorbedingungen haben dürfen als die der Ober-klasse. Außerdem müssen die Nachbedingungen wenigstens so streng sein wie die der Oberklasse.

Die Implementierungsvererbung dient lediglich der Wiederverwendung von Eigenschaften der Oberklassen und ist durch rein technische Gesichtspunkte begründet. Konzeptionelle Argumente spielen dabei keine Rolle.

Mehrfachvererbung

Wenn eine Klasse mehr als eine Oberklasse besitzt, so spricht man von Mehrfachvererbung. Sie wird nicht von allen Programmiersprachen unterstützt, da durch sie verschiedene Probleme auftreten können. So z.B., wenn verschiedene Oberklassen Eigenschaften mit gleichen Namen haben. In diesem Fall muss die Eigenschaft mit der Oberklassenbezeichnung angesprochen werden. In Abbildung 2.21 werden Mehrfachvererbungsbeziehungen dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.21: Mehrfachvererbung.

Assoziation

Assoziationen ermöglichen die Kommunikation zwischen Objekten und beschreiben Verbindungen zwischen Klassen. Eine konkrete Beziehung zwischen zwei Objekten, also die Instanz einer Assoziation, wird Objektverbindung genannt.

In der Regel besteht eine Assoziation zwischen zwei verschiedenen Klassen. Jedoch sind auch rekursive Assoziationen zwischen mehreren Klassen möglich. Mit Hilfe des Stereotyps «temporär» kann angezeigt werden, dass die Assoziation nur zeitweilig gültig ist. Dies ist der Fall, wenn ein Objekt als Argument in einer Nachricht nur lokal innerhalb der entsprechenden Operation bekannt ist.

Durch die Angabe von Kardinalitäten wird ausgedrückt mit wie vielen Objekten ein Objekt assoziiert sein kann. Eine Assoziation kann mit einem Namen gekennzeichnet werden, der diese näher beschreibt. Durch Rollennamen auf jeder Seite der Beziehung kann die Rolle, die die jeweiligen Objekte einnehmen, erläutert werden. Zusicherungen dienen dazu die Beziehung speziell einzuschränken.

Neben den Rollennamen können auch Sichtbarkeitsangaben auf beiden Seiten der Assoziation notiert werden. Die Assoziation selbst wird durch eine Linie zwischen den beteiligten Klassen dargestellt (Abb. 2.22).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.22: Beispiel einer Assoziation.

Gerichtete Assoziation

Eine gerichtete Assoziation erlaubt es, von der einen Assoziationsrolle zur anderen zu navigieren, nicht jedoch umgekehrt. Sie wird wie eine normale Assoziation notiert und hat eine geöffnete Pfeilspitze (Abb. 2.23) an der Seite der Klasse, zu der navigiert werden kann.

Die Notation einer normalen Assoziation stellt eine vereinfachte Schreibweise zweier gerichteter Assoziationen dar. Diese sind voneinander unabhängig und werden jeweils von einer Klasse verantwortet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.23: Gerichtete Assoziation.

Attributierte Assoziation

Eine attributierte Assoziation kann verwendet werden, wenn Attribute und Operationen keiner der beiden beteiligten Klassen zugeordnet werden können, da sie Eigenschaften der Beziehung sind. Die Eigenschaften der Beziehung werden daher als Klasse modelliert, die der Assoziation zugeordnet ist. Dabei haben Assoziation und Assoziationsklasse die gleiche Bedeutung.

Eine Besonderheit der attributierten Assoziation ist die Einschränkung, dass zwei beteiligte Objekte höchstens eine Beziehung zueinander haben dürfen. Notiert werden attributierte Assoziationen (Abb. 2.24) wie gewöhnliche Assoziationen, denen über eine gestrichelte Linie die Assoziationsklasse zugeordnet ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.24: Attributierte Assoziation.

Von der Verwendung der attributierten Assoziation wird abgeraten, da sie nicht objektorientiert ist.

Qualifizierte Assoziation

Bei einer qualifizierten Assoziation wird eine referenzierte Menge von Objekten durch qualifizierte Attribute in Partitionen unterteilt. Das qualifizierende Attribut wird in einem Rechteck (Abb. 2.25) an der Seite der Klasse notiert, die über diesen Qualifizierer auf das Zielobjekt zugreift. Die Angabe von mehreren Attributen ist möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.25: Beispiel einer qualifizierten Assoziation.

Abgeleitete Assoziation

Die Objektbeziehungen einer abgeleiteten Assoziation können aus den Werten ande-rer Objektbeziehungen und ihrer Objekte bestimmt werden. Sie wird wie eine normale Assoziation notiert, mit dem Unterschied, dass ihr Name mit einem Schrägstrich ein-geleitet wird. Außerdem kann die Ableitungsvorschrift als Zusicherung notiert werden (Abb. 2.26).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.26: Abgeleitete Assoziation als Untermengen-Spezifikation.

Mehrgliedrige Assoziation

Eine Assoziation, an der mehr als zwei Assoziationsrollen beteiligt sind, nennt man mehrgliedrige Assoziation. Eine Assoziationsrolle wird durch eine Klasse repräsentiert. Dabei kann die Klasse auch mehrfach an der mehrgliedrigen Assoziation beteiligt sein. In Abbildung 2.27 ist eine solche mehrgliedrige Assoziation dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.27: Mehrgliedrige Assoziation.

Da mehrgliedrige Assoziationen nicht von Programmiersprachen unterstützt werden, sollte man sie nicht verwenden und die entsprechenden Sachverhalte stattdessen durch normale Assoziationen beschreiben.

Spezialisierte Assoziation

Eine spezialisierte Assoziation (Abb. 2.28) ist eine normale Assoziation, die eine Spezialisierungsbeziehung zu einer anderen Assoziation unterhält. So wie bei Klassen erbt die spezialisierte Assoziation (Unterassoziation) von der allgemeineren Assoziation (Oberassoziation).

Durch Spezialisierungsbeziehungen entstehen keine neuen Objektbeziehungen. Zwi-schen Instanzen von Klassen mit Ober- und Unterassoziationen besteht daher jeweils eine einzige Objektverbindung. Dabei besteht die Unterassoziation meistens zwischen zwei Klassen, die von den Klassen abgeleitet sind zwischen denen die Oberassoziation besteht.

Es empfiehlt sich jedoch auf spezialisierte Assoziationen bei der Modellierung zu verzichten, da sie problematisch in Hinsicht auf andere Modellierungselemente sind. Stattdessen kann man auch OCL-Zusicherungen verwenden, die die beabsichtigten Einschränkungen ebenfalls ausdrücken können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.28: Spezialisierte Assoziation.

Assoziationszusicherung

Bedingungen, die eine Assoziation erfüllen muss, werden in geschweiften Klammern neben der Assoziationslinie notiert. Diese Zusicherungen können frei, formelhaft oder als OCL-Ausdruck formuliert werden und beliebigen Inhalt haben. Die in Abbildung 2.29 angegebene Zusicherung soll ausdrücken, dass jedem Mitarbeiter eine Fähigkeit nur einmal zugeordnet werden darf. Dabei wird ausgenutzt, dass in einem Set ¹ jedes Element nur einmal enthalten sein darf (im Gegensatz zum Bag ² ). Falls die beiden Mengen dennoch gleich sind, ist keine Fähigkeit mehrfach vorhanden.

Ein anderes Beispiel für eine Zusicherung ist {geordnet}. Es gibt an, dass die Objekte innerhalb der Beziehung geordnet sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.29: Zusicherung über die Eindeutigkeit von Kompetenzgraden.

Aggregation

Eine Aggregation ist eine Zusammensetzung eines Objektes aus einer Menge von Ein-zelteilen. Sie ist eine Assoziation mit der zusätzlichen Information, dass die beteiligten Klassen eine Ganzes-Teile-Hierarchie darstellen und keine gleichwertige Beziehung führen.

Ein Merkmal der Aggregation ist, dass die Aggregatklasse Aufgaben stellvertretend für seine Teile übernimmt. So kann die Aggregatklasse bspw. Operationen enthalten, die keine unmittelbare Veränderung im Aggregat selbst zur Folge haben, sondern Nach-richten an seine Einzelteile weiterleiten. Dies wird Propagieren von Operationen ge-nannt.

Bei einer Aggregationsbeziehung muss genau festgelegt sein, welche Klasse das Aggregat ist und welche die Rolle der Einzelteile übernimmt. Das Aggregat übernimmt somit stellvertretend die Verantwortung und Führung.

Der Unterschied zu einer Assoziation besteht ausschließlich aus der Information, welche Rollen die beteiligten Klassen einnehmen. Streng genommen gibt es keinen Unterschied. Jedoch ist die Verwendung der Aggregation sinnvoll, da sie einen wichtigen Hinweis auf die höhere Bindung zwischen den beteiligten Klassen liefert und so zum besseren Verständnis von Klassenmodellen beiträgt.

Eine Aggregation (Abb. 2.30) wird wie eine Assoziation dargestellt und hat auf der Seite der Aggregatklasse eine Raute.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.30: Aggregation.

Teil

Aggregationen können wie Vererbungsbeziehungen auch baumartig (Abb. 2.31) notiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.31: Baumartige Aggregationen.

Komposition

Die Komposition ist eine spezielle Variante der Aggregation, bei der die Teile vom Ganzen existenzabhängig sind. Beschrieben wird, wie sich etwas Ganzes aus Einzelteilen zusammensetzt und diese kapselt.

Im Unterschied zur Aggregation muss die Kardinalität auf der Seite des Aggregats immer 1 sein. Dabei ist jedes Teil genau einem Kompositionsobjekt zugeordnet. Die Existenz der Teile ist abhängig von der Existenz des Ganzen.

Eine Komposition (Abb. 2.32) wird dargestellt wie eine Aggregation, wobei die Raute ausgefüllt gezeichnet wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.32: Aggregation und Komposition.

Abhängigkeitsbeziehung

Eine Abhängigkeitsbeziehung zwischen zwei Modellelementen zeigt an, dass die Än-derung in dem unabhängigen Element eine Änderung in dem abhängigen Element zur Folge hat.

Dargestellt wird eine Abhängigkeitsbeziehung (Abb. 2.33) durch einen gestrichelten Pfeil vom abhängigen Element auf das unabhängige Element.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.33: Abhängigkeitsbeziehung.

Verfeinerungsbeziehung / Realisierungsbeziehung

Verfeinerungsbeziehungen werden dazu verwendet den unterschiedlichen Detaillierungs-grad zwischen gleichartigen Elementen darzustellen. Eine Realisierungsbeziehung be-schreibt die Beziehung zwischen einer Schnittstelle und ihrer Implementierung. Verfeinerungsbeziehungen helfen dabei wichtige Entwurfsentscheidungen besser zu dokumentieren. Die beiden genannten Beziehungen werden in den Abbildungen 2.34 und 2.35 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.35: Verfeinerungsbeziehung.

2.4 Sequenzdiagramm

Ein Sequenzdiagramm (Abb. 2.36) zeigt eine Reihe von Nachrichten, die eine Menge von Objekten in einer zeitlich begrenzten Situation austauschen. Hierbei steht der zeitliche Verlauf der Nachrichten im Vordergrund.

Die Objekte werden lediglich durch senkrechte Lebenslinien dargestellt. Dadurch wird der zeitliche Verlauf der Nachrichten hervorgehoben. Oberhalb dieser Linien steht der Name bzw. das Objektsymbol. Nachrichten werden als waagerechte Pfeile zwi-schen den Objekt-Linien gezeichnet. Eine Nachricht wird in der Form nachricht(argumente) auf die Pfeile notiert. Die Antwort wird ähnlich wie beim Kollabo-rationsdiagramm in Textform (antwort:=nachricht) oder als eigener, gestrichelter Pfeil mit offener Pfeilspitze dargestellt.

Um zu verdeutlichen, welches Objekt gerade aktiv ist, werden die gestrichelten Lebenslinien durch breite, nicht ausgefüllte oder graue, senkrechte Balken überlagert. Ein solcher Balken wird als Steuerungsfokus bezeichnet. Links bzw. rechts davon können frei formulierte Erläuterungen und Zeitanforderungen notiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.36: Standard-Notationselemente des Sequenzdiagramms.

Das Erzeugen eines neuen Objektes wird dargestellt durch eine Nachricht, die auf ein Objektsymbol trifft. Ein Kreuz am Ende des Steuerungsfokus zeigt die Zerstörung des Objektes an. Iterationen (Abb. 2.37) werden durch einen Stern vor der Nachricht mar-kiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.37: Iteration in UML.

2.5 Kollaborationsdiagramm

Ein Kollaborationsdiagramm beschreibt eine Menge von Interaktionen zwischen ausgewählten Objekten in einer bestimmten Situation. Dabei steht die Zusammenarbeit der Objekte im Vordergrund. Im Kollaborationsdiagramm werden ausgewählte Nachrichten zwischen den Objekten gezeigt, wobei der zeitliche Verlauf der Kommunikation durch Nummerierung der Nachrichten verdeutlicht wird.

Voraussetzung für die Kommunikation zweier Objekte ist das Vorhandensein einer Assoziation zwischen ihnen. Die Objektverbindung kann permanent bestehen oder temporär bzw. lokal, z.B. als Argument einer Nachricht. Für Nachrichten, die ein Objekt an sich selbst schickt ist keine Assoziation notwendig.

Neben der zeitlichen Abfolge, den Namen, Antworten und den möglichen Argumenten der Nachrichten, können ebenso Iterationen bzw. Nachrichten-Schleifen in Kollaborationsdiagrammen dargestellt werden. Sie sind ein Hilfsmittel, um spezielle Ablaufsituationen zu erläutern oder zu dokumentieren.

Objekte werden durch Assoziationslinien miteinander verbunden. Pfeile markieren dabei die Richtung der Nachricht vom Sender zum Empfänger. Ebenso aufgeführt werden ggf. Argumente oder mögliche Antworten. Sequenznummern, beginnend bei eins, verdeutlichen die zeitliche Abfolge der Nachrichten. Die von außen kommende Nach-richt (Startnachricht) wird ohne Nummer dargestellt. Sie kann optional auch von ei-nem Akteursymbol ausgehen. Abbildung 2.38 zeigt ein Beispiel eines Kollaborations-diagramms.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.38: Notation des Nachrichtenaustausches als Kollaborationsdiagramm.

Die Syntax der Nachrichtenbezeichnung lautet wie folgt:

Vorgänger-Bedingung Sequenzausdruck Antwort := Nachrichtenname(Parameterliste)

Die Vorgänger-Bedingung ist eine Aufzählung der Sequenznummern anderer Nachrich-ten, die bereits gesendet sein müssen, bevor diese Nachricht gesendet werden darf. Sie dient also zum Synchronisieren und ist optional. Die Sequenznummern werden durch Komma getrennt aufgelistet und mit einem Schrägstrich abgeschlossen. Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Der Sequenzausdruck zeigt die Reihenfolge der Nachrichten durch eine aufsteigen-de Nummerierung. Die Schachtelung einer Nachricht innerhalb anderer Nachrichten erfolgt durch die Angabe von, durch einen Punkt getrennten, Unter-Sequenznummern. Solche Schachtelungen treten auf, wenn innerhalb einer Operation, die eine empfan-gene Nachricht interpretiert, wiederum neue Nachrichten gesendet werden.

Das wiederholte Senden einer Nachricht wird durch einen Stern gekennzeichnet. Dabei kann die Anzahl der Iterationen in eckigen Klammern durch Pseudocode oder in der verwendeten Programmiersprache angegeben werden. Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Falls die Nachrichten parallel gesendet werden sollen, so wird das durch zwei vertikale Linien hinter dem Stern angezeigt. Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Außerdem kann eine Bedingung notiert sein, die erfüllt sein muss, damit die Nachricht ausgeführt werden darf. Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Die Antwort auf eine Nachricht kann mit einem Namen versehen werden, der als Argument in anderen Nachrichten verwendet werden kann. Der Name ist, ähnlich wie eine lokale Variable, innerhalb der sendenden Nachricht gültig.

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:

[Abbildung in dieser Leseprobe nicht enthalten] unspezifisch

Die sequentielle Nachricht wird vom Empfänger angenommen und vollständig verarbeitet. Erst dann darf der Absender weitermachen.

[Abbildung in dieser Leseprobe nicht enthalten] synchron

Bei der synchronen Nachricht wartet der Sender, bis der Empfänger die Nachricht angenommen hat.

[Abbildung in dieser Leseprobe nicht enthalten] asynchron

Die asynchrone Nachricht fügt sich in die Warteschlange des Empfängers ein. Der Absender muss nicht wissen, wann der Empfänger die Nachricht annimmt.

2.6 Zustandsdiagramm

In einem Zustandsdiagramm (Abb. 2.39) wird eine Folge von Zuständen dargestellt, die ein Objekt im Laufe seiner Existenz einnehmen kann. Außerdem zeigt es die Aktionen, die zu Zustandsübergängen führen.

Ein Zustandsdiagramm stellt eine hypothetische Maschine dar, die sich zu jedem Zeitpunkt in einer Menge endlicher Zustände befindet.

Diese besteht aus:

- einer endlichen, nicht-leeren Menge von Zuständen
- einer endlichen, nicht-leeren Menge von Ereignissen
- einem Anfangszustand
- einer Menge von Endzuständen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.39: Zustandsdiagramm.

Zustand

Ein Zustand ist genau einer Klasse zugeordnet. Er stellt eine Abstraktion einer Menge von möglichen Attributwerten dar, die die Objekte dieser Klasse einnehmen können. Bei der Abstraktion werden nur solche Ereignisse berücksichtigt, die das Verhalten eines Objektes entscheidend beeinflussen. Ein Zeitraum zwischen zwei Ereignissen kann somit ebenfalls als Zustand betrachtet werden.

Start und Endzustände (Abb. 2.40) sind spezielle Zustände, wobei zu einem Startzu-stand kein Übergang stattfinden und von einem Endzustand kein Ereignis wegführen kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.40: Start- und Endzustand.

Zustände haben entweder einen eindeutigen Namen oder sind anonyme Zustände (Abb 2.41). In einem Zustandsdiagramm sind namenlose Zustände grundsätzlich voneinander verschieden. Dagegen handelt es sich bei gleichnamigen Zuständen jeweils um denselben Zustand.

Ein Zustand kann eine Menge von Zustandsvariablen haben. Diese sind Attribute der zugehörigen Klasse. Dabei werden nur die Attribute ausgewählt, die für die Beschreibung bzw. Identifikation des Zustandes von Bedeutung sind.

Eine Klasse muss nicht zwingend über Zustände verfügen, jedoch über ein entsprechendes signifikantes Verhalten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.41: Anonyme Zustände.

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. Die-se 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 Ope-rationen beinhalten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.42: Notationsvarianten für Zustände.

Die Zustandsvariablen werden in folgender Form notiert:

variable : Klasse = Initialwert {Merkmal} {Zusicherung}

Ereignisse haben das Format:

Ereignis / Aktionsbeschreibung

Unterzustand

Innerhalb eines Zustandes können sequentielle oder parallele Unterzustände (Abb. 2.43) existieren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.43: Verschachtelte Zustände.

Parallele Unterzustände habe folgende Notation:

Abbildung in dieser Leseprobe nicht enthalten

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) aus-lö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 Ereignis-se erhalten darf und wie sich diese auf den Status des Objektes auswirken. Vorausset-zung 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 abgeschlos-sen sind.

Eine Transitionsbeschreibung hat folgende Notation:

ereignis(argumente)

Abbildung in dieser Leseprobe nicht enthalten

3 CASE-Werkzeuge

In diesem Kapitel wird zunächst eine Definition des Begriffs CASE vorgenommnen und erläutert, welche Ziele man mit dem Einsatz entsprechender Werkzeuge erreichen will. Anschließend werden allgemeine Anforderungen beschrieben, die an ein CASEWerkzeug gestellt werden. Außerdem wird eine allgemeine Vorgehensweise für die Auswahl eines bestimmten Werkzeugs vorgestellt. Davon ausgehend wird schließlich eine Vorgehensweise entwickelt, mit Hilfe derer in den folgenden Kapiteln eine Bewertung von CASE-Werkzeugen durchgeführt wird.

3.1 Definition und Ziele

Die zunehmende Komplexität von Softwareprojekten und der damit verbundene Wunsch nach Hilfsmitteln und Methoden zur leichteren Beherrschung von Entwicklungsprojekten hat zur Entwicklung des CASE-Verfahrens geführt.

Was ist CASE?

Die Abkürzung CASE steht für Computer Aided Software Engineering und umfasst alle computergestützten Hilfsmittel, welche die Produktivität und Qualität von Software erhöhen, sowie das Management der Softwareentwicklung erleichtern.

In diesem Zusammenhang unterscheidet man zwischen CASE-Werkzeugen und CASE-Plattformen. CASE-Werkzeuge sind Softwareprodukte, die einzelne bei der Software-entwicklung benötigte Funktionen bzw. Dienstleistungen zur Verfügung stellen. CASE-Plattformen dagegen stellen Basisdienstleistungen, wie eine allgemeine Benutzerschnitt-stelle, ein Repository für die Datenverwaltung und einen Nachrichtendienst zur Ver-fügung. Beides zusammen nennt man CASE-Umgebungen oder auch Softwareent-wicklungsumgebungen. Eine CASE-Umgebung stellt eine organisatorische und com-puterunterstützte Arbeitsumgebung dar, die möglichst viele Tätigkeiten der Software-Erstellung (Entwicklung, Qualitätssicherung, Management) unterstützt.

CASE-Werkzeugkategorien

In Bezug auf die Projektphasen kann man eine Einteilung in upper- und lower-CASE-Werkzeuge vornehmen. Upper-CASE-Werkzeuge unterstützen die frühen Phasen wie Planung, Definition und Entwurf. Lower-CASE-Werkzeuge dagegen helfen bei Imple-mentierung, Abnahme und Einführung sowie Wartung und Pflege, also den späten Pro-jektphasen. Werkzeuge, die beide Phasen unterstützen, nennt man Integrated-CASE-Werkzeuge (I-CASE). An die in dieser Arbeit untersuchten Werkzeuge wird die For-derung gestellt, beide Phasen zu unterstützen. Sie werden im Folgenden schlicht als CASE-Werkzeuge bezeichnet.

Ziele von CASE

Die globalen Ziele, die mit Hilfe von CASE verfolgt werden, sind die Erhöhung der Pro-duktivität, die Verbesserung der Qualität sowie die Erleichterung des Softwaremana-gements. Hieraus lassen sich weitere technische, wirtschaftliche und organisatorische Ziele ableiten.

[...]

---

¹ Computer Aided Software Engineering

¹ Kollektion, die das mehrfache Aufreten ein und desselben Elementes nicht gestattet

² Kollektion, die das mehrfache Aufreten ein und desselben Elementes gestattet