Abkürzungsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
1. Einführung
2. Begrifflichkeiten
2.1 Objektorientierung
2.2 UML
2.3 System
2.4 Diagramm vs. Modell
2.5 Objekt vs. Klasse
3. Modell- und Diagrammtypen der UML
3.1 Anwendungsfalldiagramm
3.1.1 Akteur und Anwendungsfall
3.1.2 Beziehung
3.2 Klassendiagramm
3.2.1 Klasse
3.2.2 Attribut
3.2.3 Operation
3.2.4 Beziehung
3.3 Zustandsdiagramm
3.3.1 Zustand
3.3.2 Beziehung
3.3.3 Weitere Elemente
3.3.4 Praxisbeispiel „Computer GmbH“
3.4 Aktivitätsdiagramm
3.4.1 Aktivität
3.4.2 Beziehung
3.4.3 Objekt
3.4.4 Weitere Elemente
3.4.5 Praxisbeispiel „Computer GmbH“
3.5 Sequenzdiagramm
4. Fallstudie „Textil GmbH“
4.1 Einführung in die Fallstudie „Textil GmbH“
4.2 Systemanforderungen des Pflichtenheftes
4.3 Gesamtmodell
4.4 Modell der Systemnutzung in Rational Rose
4.4.1 Anwendungsfalldiagramm „Konfiguriere System“
4.4.2 Anwendungsfalldiagramm „Bearbeite Stammdaten“
4.4.3 Anwendungsfall „Erfasse Kollektionsartikel“
4.4.4 Anwendungsfall „Vervollständige Kollektionsartikel“
4.4.5 Anwendungsfall „Erhöhe Status“
4.4.6 Anwendungsfall „Bearbeite Werbeartikel“
4.4.7 Anwendungsfall „Verknüpfe Lieferant“
4.5 Logisches Modell in Rational Rose
4.5.1 Paket „Bearbeite Stammdaten“
4.5.2 Paket „Konfiguriere System“
4.5.3 Zustandsänderung von Kollektionsartikeln
5. Benutzerberechtigung im Anwendungssystem „Ready 2004“
6. Ausblick auf die Programmierung des Anwendungssystems
7. Fazit
Literaturverzeichnis
Anhangverzeichnis
Anhang
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Beispiel für ein Anwendungsfalldiagramm
Abbildung 2: Beispiel für eine Include-Beziehung
Abbildung 3: Beispiel für eine Extend-Beziehung
Abbildung 4: Beispiel für eine Generalisierung
Abbildung 5: Beispiel für ein Klassendiagramm
Abbildung 6: Instanziierung von Objekten aus der Klasse „Software“
Abbildung 7: Beispiel für eine abstrakte Klasse
Abbildung 8: Beispiel für Vererbungsstrukturen zwischen Klassen
Abbildung 9: Beispiel für ein Zustandsdiagramm
Abbildung 10: Zustandsdiagramm „Freigabeprozess von Einkaufsbestellungen“
Abbildung 11: Aktivitätsdiagramm „Mahnbriefe der Computer GmbH“
Abbildung 12: Beispiel für ein Sequenzdiagramm
Abbildung 13: Gesamtmodell der Anwendung „Ready 2004“
Abbildung 14: Browseransicht in Rational Rose
Abbildung 15: Anwendungsfalldiagramm „Konfiguriere System“
Abbildung 16: Sequenzdiagramm „Definiere Mussfelder“
Abbildung 17: Anwendungsfalldiagramm „Bearbeite Stammdaten“
Abbildung 18: Aktivitätsdiagramm „Erfasse Kollektionsartikel“
Abbildung 19: Sequenzdiagramm „Erfasse Kollektionsartikel“
Abbildung 20: Aktivitätsdiagramm „Vervollständige Kollektionsartikel“
Abbildung 21: Sequenzdiagramm „Vervollständige Kollektionsartikel“
Abbildung 22: Sequenzdiagramm „Erhöhe Status“ (Hauptszenario)
Abbildung 23: Sequenzdiagramm „Bearbeite Werbeartikel“
Abbildung 24: Sequenzdiagramm „Verknüpfe Lieferant“
Abbildung 25: Logisches Modell in Rational Rose
Abbildung 26: Klassendiagramm „Bearbeite Stammdaten::Anwendungsklassen“
Abbildung 27: Klassendiagramm „Konfiguriere System::Anwendungsklassen“
Abbildung 28: Einrichtung der Mussfelder je Status und Artikelklasse
Abbildung 29: Zustandsdiagramm der Klasse „KollektionsArtikel“
Tabelle 1: Abstraktion von Objekten der realen Welt
Tabelle 2: Modelle der UML
Tabelle 3: UML-Notation von Klassen
Tabelle 4: UML-Notation von Klassen am Beispiel der Klasse „Hardware“
Tabelle 5: UML-Notation von Attributen am Beispiel der Klasse „Software“
Tabelle 6: Überblick über Multiplizitäten
Tabelle 7: Sichtbarkeit für Attribute und Operationen
Tabelle 8: Aktivitätsdiagramm – Elemente
Tabelle 9: Meilensteine zur Umsetzung der Anforderungen
Tabelle 10: Kernanforderungen an das Anwendungssystem „Ready 2004“
Tabelle 11: Übersicht über die Artikelstatusänderung
Tabelle 12: Szenarios des Anwendungsfalls „Erhöhe Status“
Tabelle 13: Hauptszenario des Anwendungsfalls „Erhöhe Status“
Tabelle 14: Nebenszenarios 1, 2 und 3 zum Anwendungsfall „Erhöhe Status“
Tabelle 15: Übersicht über ausgewählte, identifizierte Modellelemente
Tabelle 16: Anwendungsklassen des Paketes „Bearbeite Stammdaten“
Tabelle 17: Aufzählungsklassen des Paketes „Bearbeite Stammdaten“
Tabelle 18: Strukturklassen des Paketes „Bearbeite Stammdaten“
Tabelle 19: Anwendungsklassen des Paketes „Konfiguriere System“
Tabelle 20: Aufzählungsklassen des Paketes „Konfiguriere System“
Tabelle 21: Mögliche Zustände von Kollektionsartikeln
Tabelle 22: Übersicht der erforderlichen Rollen in „Ready 2004“
Tabelle 23: Zugriffsrechte „Creation“, „Vertrieb Inland“ und „Vertrieb Ausland“
Tabelle 24: Zugriffsrechte „Einkauf“
Tabelle 25: Zugriffsrechte „Administration“
Die Erfolgschance auf neue ertragreiche Softwareprojekte ist in den vergangenen Jahren gesunken. Dennoch scheitern, insbesondere durch das Nichteinhalten festgelegter Budgets und/oder Zeitrahmen, nach wie vor ein Großteil der beauftragten Projekte.(Vgl. Norris, 1995, zitiert bei: Thaller, 2002, S. 17)
Die Literatur sieht die Ursachen hierfür vor allem im schlechten Projektmanagement, im Fehlen zukunftsorientierter Gesamtkonzepte und im mangelnden methodischen Vorgehen. Der Programmcode entsteht oftmals zu früh, so dass die wahren Anforderungen der Anwender keine Berücksichtigung finden.(Vgl. Seidel, 2004, S. 1; vgl. o.V., 2004, S. 1)
Ein weiteres Problem stellt häufig die unterschiedliche Spezialisierung der Projektbeteiligten dar. Je spezialisierter Auftraggeber, Anwender, Analytiker und Entwickler in ihren Fachbereichen sind, umso schwieriger ist es die Grundlage für eine erfolgreiche Entwicklungsarbeit herzustellen bzw. eine gemeinsame Basis der Verständigung zu schaffen.(Vgl. Oestereich, 2001, S. 18).
Die objektorientierte Softwareentwicklung begegnet dieser Herausforderung, indem sie die Projekte von der Anforderungsanalyse bis zur Implementierung des Systems, durch eine einheitliche Notation begleitet. In der Praxis hat sich die Unified Modeling Language (UML) als standardisierte Modellierungssprache bewährt. Die Symbole und Diagramme der UML gelten als leicht verständlich und fördern damit den Informationsaustausch zwischen den Beteiligten.
Ziel dieser Diplomarbeit ist es, dem Leser nicht nur einen ausgewählten Extrakt der UML-Modellelemente vorzustellen, sondern vor allem deren Verwendbarkeit an praxisorientierten Beispielen aufzuzeigen. Dazu vermittelt der erste Teil dieser Arbeit die theoretischen Grundlagen, die für das Verständnis der fiktiven Fallstudie im zweiten Teil erforderlich sind.
Da in der Literatur einige Begriffe nicht eindeutig definiert oder in der Praxis synonym verwendet werden, erläutert das folgende Kapitel die notwendigen Begrifflichkeiten und grenzt sie voneinander ab.
Das dritte Kapitel beschreibt die wesentlichen Modell- und Diagrammtypen der UML sowie deren standardisierte Elemente. Die Auswahl beschränkt sich dabei, auf die in der Fallstudie modellierten Diagramme und Konzepte.
Der Leser erhält nicht nur grundlegende Informationen zur Verwendung der Modellelemente, sondern lernt gleichzeitig deren Notation, in der UML[1], kennen. Einige Elemente und Diagramme werden anhand einfacher Unternehmensprozesse des erfundenen Unternehmens „Computer GmbH“[2] beschrieben und grafisch dargestellt.
Im vierten Kapitel wurde die Fallstudie „Textil GmbH“ entwickelt, die zeigt, wie die UML in den Kontext eines komplexen Softwareprojektes integriert werden kann. Die Fallstudie setzt sich
- aus dem Pflichtenheft „Stammdatenverwaltung I“ der Textil GmbH (s. Anhang II),
- dem in Rational Rose angefertigten UML-Modell „Diplomarbeit 800410“ sowie
- dem generierbaren Pilotsystem „Ready 2004“
zusammen.
Das fünfte Kapitel zeigt ein Berechtigungskonzept für das neue Anwendungssystem auf.
Im sechsten Abschnitt der Arbeit gibt die Verfasserin einen Ausblick auf die Programmierung des Anwendungssystems „Ready 2004“ und komplettiert damit die Fallstudie „Textil GmbH“.
Neben dem Pflichtenheft umfasst der Anhang dieser Arbeit ein Glossar, das die im Dokument kursiv geschriebenen Begriffe erläutert (s. Anhang I). Ferner wurden die in Rational Rose verwendeten UML-Notationen in einer Übersicht zusammengestellt (s. Anhang III).
Die objektorientierte Systementwicklung stellt eine Alternative zur klassischen (strukturierten) Systementwicklung dar. Ein wesentlicher Unterschied besteht
darin, dass die Daten und Funktionen nicht mehr voneinander getrennt, sondern vielmehr ganzheitlich betrachtet werden.
Dadurch lassen sich nun auch Beziehungen und Abhängigkeiten modellieren, die zwischen den Objekten der realen Welt bestehen.
Die Objektorientierung basiert auf den folgenden Grundprinzipien: (Vgl. Stahlknecht; Hasenkamp, 2002, S. 279)
- Kapselung von Daten,
- Klassenbildung und Vererbung (s. Kapitel 3.2 ) sowie
- Nachrichtenkommunikation (s. Kapitel 3.5 ) und Polymorphismus.
Eine weitere Neuerung besteht darin, dass die Entwicklungsphasen Analyse (OOA), Entwurf (OOD) und Realisierung (OOP) dieselben Konzepte (Klassen, Objekte, Beziehungen, etc.) verwenden. Diese methodische Durchgängigkeit legt den Grundstein für eine schnellere und bessere Verständigung zwischen allen Projektbeteiligten.(Vgl. Balzert, 1999, S. 2)
Die UML hat sich als Standardnotation für die objektorientierte Modellierung durchgesetzt. Sie ermöglicht, objektorientierte Konzepte in Bildern und Worten darzustellen.(Vgl. Grässle; Baumann; Baumann, 2000, S. 13)
Mit geeigneten UML-Modellierungswerkzeugen, wie z.B. Rational Rose, können die Modelle zudem spezifiziert, konstruiert und dokumentiert werden, vollkommen unabhängig von einer Programmiersprache[3].(Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 12). Da es sich bei der UML um eine standardisierte Modellierungssprache handelt, lässt sich aus einigen Diagrammtypen Quellcode generieren[4].(Vgl. Oestereich, 2001, S. 22) Die erstellten Codeskelette können als Grundlage für die weitere Systemprogrammierung verwendet werden.
Der Systembegriff hat in der Literatur keine einheitliche Definition. In dieser Arbeit ist ein System als eine Kombination aus Hard- und Software[5] zu verstehen, die Probleme lösen und/oder Geschäftsprozesse optimieren soll. Der bereitgestellte Leistungsumfang von Systemen ist individuell. Er hängt maßgeblich von den spezifischen Anforderungen des Auftraggebers ab.
Die verschiedenen Beteiligten an einem System verfolgen meist voneinander abweichende Interessen. Demzufolge unterscheiden sich auch ihre Sichtweisen auf das System. So betrachtet beispielsweise ein Anwender, ein Computersystem aus einem anderen Blickwinkel als ein Komponentenhersteller oder ein Designer, der den PC entworfen hat.(Vgl. Schmuller, 2003, S. 34)
Nach Schmuller und Boggs repräsentieren UML-Diagramme diese unterschiedlichen Sichten auf das System (Vgl. Schmuller, 2003, S. 26; vgl. Boggs; Boggs, 2003, S. 76). Ausgewählte Aspekte eines Systems, insbesondere komplexe Problembereiche, können durch Diagramme visualisiert und grafisch dargestellt werden. Sie bilden damit für alle Beteiligten, die Grundlage für ein gemeinsames Verständnis der Anforderungen.
Da komplexe Systeme selten in einem Diagramm darstellbar sind, werden mehrere Diagramme modelliert, die zusammen das Modell des Systems bilden.
Vergleichbar mit den Bauplänen eines Hauses stellen Modelle die Baupläne der Softwareentwicklung dar. Sie zeigen auf, was ein System leisten soll und fördern die frühe Auseinandersetzung mit den Anforderungen, bevor die Programmierarbeit beginnt.(Vgl. Schmuller, 2003, S. 26) Fehler und konzeptionelle Lücken können auf diese Weise noch zu einem frühen Zeitpunkt aufgedeckt und meist mit geringerem Aufwand beseitigt werden als in nachfolgenden Projektschritten (Vgl. Boggs; Boggs, 2003, S. 49).
Objekte beschreiben die Eigenschaften von Personen, Gegenständen und Ereignissen der realen Welt. Im System repräsentieren sie die konkreten Daten, die später von der Anwendung verwaltet werden (Vgl. Balzert, 2001a, S. 15). Alle Objekte mit gemeinsamen Eigenschaften, werden in Einheiten zusammengefasst. Diese gruppierten Einheiten bezeichnet die Objektorientierung als Klassen (s. Kapitel 3.2) und deren zugehörige Objekte als Instanzen der Klasse.(Vgl. Erler, 2000, S. 17)
Die realen Objekte der Computer GmbH, wie z.B. Computer, Monitor oder Drucker, können in der Objektorientierung wie folgt abstrahiert werden.
Tabelle 1: Abstraktion von Objekten der realen Welt
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle in Anlehnung an Grässle; Baumann; Baumann, 2000, S. 29
An einer Systemerstellung sind meist mehrere Personen mit unterschiedlichen Zuständigkeiten beteiligt, die unterschiedliche Informationen beanspruchen.
Beispielsweise benötigen Auftraggeber und Projektmanagement eine abstrakte Sicht auf das System, um den Projektumfang festzulegen. Entwickler brauchen zunächst einen Überblick über die Bestandteile des Systems, um daraus die Klassen abzuleiten. Die für die Installation des Systems verantwortlichen Mitarbeiter, sind auf Informationen über die Netzwerkkonfiguration und die, durch die Systementwicklung erzeugten Dateien angewiesen.(Vgl. Boggs; Boggs, 2003, S. 50 f.)
Diese unterschiedlichen Sichten der Projektbeteiligten auf das System erfordern adäquate Darstellungsweisen. Um den Ansprüchen aller Projektbeteiligten gerecht zu werden, unterscheidet die UML drei Modelle:
1. Das Modell der Systemnutzung beschreibt das geschäftliche Umfeld des Systems und dessen allgemeine Funktionalität aus der Sicht der Anwender (Vgl. Grässle; Baumann; Baumann, 2000, S. 30). In diesem Modell wird auf die Darstellung von Implementierungsdetails verzichtet. Ziel ist es, allen Beteiligten eine implementierungsunabhängige Sicht auf das System zu geben.
2. Im Logischen Modell wird das zu erstellende Softwaresystem auf hoher Abstraktionsebene dargestellt. Zum einen werden die Elemente des Systems, deren Struktur und gegenseitigen Beziehungen zueinander, veranschaulicht (Statisches Modell). Zum anderen zeigt es die Funktionsabläufe auf und beschreibt das Verhalten des Systems im Verlauf der Zeit (Dynamisches Modell).(Vgl. Stevens; Pooley, 2000, S. 75)
Das Logische Modell wird auf Basis des Modells der Systemnutzung erstellt.
3. Das Physikalische Modell beschreibt die physische Struktur des Systems und seine Komponenten. Zudem legt es die Art der Datenspeicherung und die Zugriffsmechanismen fest. Die Darstellung des Physikalischen Modells ist optional (Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 109).[8]
Tabelle 2: Modelle der UML
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle in Anlehnung an Boggs; Boggs, 2003, S. 50 f., 60 ff., Neumann,
2002, S. 154 ff., S. 170 ff., Stevens; Pooley, 2000, S. 75 f.
Die in der Tabelle aufgeführten Diagrammtypen, dienen lediglich der Orientierung. Es ist ebenso möglich, Sequenz- und Aktivitätsdiagramme im Use Case View von Rational Rose zu erstellen, um beispielsweise Anwendungsfälle hinsichtlich ihres Ablaufes zu spezifizieren.
In den folgenden Abschnitten werden die verschiedenen Diagrammtypen beschrieben, die im Fallbeispiel (s. Kapitel 4.) Anwendung finden.
Anwendungsfalldiagramme[9] stellen die Anforderungen an das System, aus der Perspektive der Benutzer, dar. In Abgrenzung zum Geschäftsprozessdiagramm, fokussiert das Anwendungsfalldiagramm automatisierte Prozesse.(Vgl. Boggs; Boggs, 2003, S. 33)
Anwendungsfalldiagramme geben einen guten Überblick über die Grundfunktionalität und den Kontext des zu erstellenden Systems (Vgl. Grässle; Baumann; Baumann, 2000, S. 51). Daher eignen sie sich optimal zur Kommunikation mit dem Auftraggeber, der nicht zwingend über UML-Kenntnisse verfügen muss.(Vgl. Stevens; Pooley, 2000, S. 119)
Wie Abbildung 1 zeigt, visualisieren Anwendungsfalldiagramme die Interaktionen zwischen Akteuren und Anwendungsfällen.
Abbildung 1: Beispiel für ein Anwendungsfalldiagramm
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Anwendungsfalldiagramm in Rational Rose
Akteure stellen die Benutzer des Systems dar. Benutzer sind entweder Personen oder externe Systeme, die Anwendungsfälle initiieren oder aus ihnen Wert schöpfen.
Ein Akteur repräsentiert dabei kein konkretes Individuum, sondern verkörpert eine Rolle (Vgl. Stevens; Pooley, 2000, S. 121). In der Praxis kann eine Person verschiedene Rollen ausüben. Beispielsweise könnte der Geschäftsführer der Computer GmbH zugleich Einkaufsleiter des Unternehmens sein. Ebenso können mehrere Personen die gleiche Rolle ausüben. Wenn für die spätere Systemnutzung keine Unterscheidung, z.B. nach Einkaufsleiter (Inland) und Einkaufsleiter (Ausland) erforderlich ist, können diese Verantwortlichkeiten zu einer Rolle Einkaufsleiter zusammengefasst werden.
Aus diesen Darstellungen lassen sich somit die Rollen - respektive Akteure - Geschäftsführer und Einkaufsleiter ableiten.
Durch diese Abstraktion lassen sich redundante Beschreibungen von Abläufen und Tätigkeiten vermeiden, sofern durch die Zusammenführung kein Informationsverlust entsteht.
Ein Anwendungsfall stellt eine Anforderung an das System dar, die aus der Sicht der Benutzer beschrieben wird (Vgl. Boggs; Boggs, 2003, S. 33 f.). Er umfasst mehrere aufeinander folgende Aktivitäten, einschließlich deren Varianten, die das zu erstellende System ausführen soll. Anwendungsfälle spezifizieren das Systemverhalten, folglich das, was vom System zu leisten ist, ohne vorzugeben, wie die Implementierung erfolgt.(Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 247)
Die Aktionsfolgen eines Anwendungsfalles werden nicht im Anwendungsfalldiagramm, sondern besser in Aktivitäts- und Interaktionsdiagrammen dargestellt. Die Diagramme lassen sich in Rational Rose mit dem Anwendungsfall verknüpfen. In der Praxis hat sich darüber hinaus die zusätzliche Dokumentation der Ereignisabläufe bewährt.
In der UML-Notation werden Akteure als Strichmännchen und Anwendungsfälle als Ellipsen dargestellt.
Abbildung in dieser Leseprobe nicht enthalten Szenario
Anwendungsfälle weisen häufig unterschiedliche Variationen von Arbeitsabläufen auf. Um diese darzustellen, ist es sinnvoll eine Unterscheidung in primäre und sekundäre Ereignisabläufe vorzunehmen. Primäre Folgen stellen das Hauptszenario des Anwendungsfalles dar. Sekundäre Szenarios zeigen eventuelle Abweichungen vom Hauptablauf, wie z.B. Fehlerbehandlungen.(Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 254) Folglich stellen Szenarios alle oder eine Auswahl der möglichen Ablaufpfade eines Anwendungsfalles dar (Vgl. Oestereich, 2001, S. 335). Im Allgemeinen werden sie in Textform beschrieben und durch Sequenz- und/oder Aktivitätsdiagramme visualisiert (Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 666).
Objekte der realen Welt können unterschiedliche Beziehungen zueinander haben. Um diese Informationen auch in der objektorientierten Modellierung darzustellen, werden die Modellelemente - des jeweiligen Diagramms - durch Linien miteinander verbunden. Die wichtigsten Beziehungsarten sind Assoziationen, Abhängigkeiten und Generalisierungen (Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 154). Darüber hinaus können Realisierungsbeziehungen und Aggregationen abgebildet werden.
Abbildung in dieser Leseprobe nicht enthalten Assoziation
Eine Assoziation wird als einfache Linie dargestellt. Sie zeigt in Anwendungsfalldiagrammen die Beziehung zwischen einem Akteur und einem Anwendungsfall (Vgl. Grässle; Baumann; Baumann, 2000, S. 54).
Die UML unterscheidet uni- und bidirektionale Assoziationen (Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 644). Eine einseitig gerichtete Assoziation zeigt, dass der Akteur ausschließlich Daten in das System eingibt, beispielsweise eine Datenimportschnittstelle. Unidirektionale Assoziationen werden als Pfeillinie dargestellt. Die Pfeilspitze zeigt auf den Anwendungsfall.
Verläuft die Kommunikation in beide Richtungen, ist die Beziehung bidirektional. Die Bedienung eines Geldautomaten stellt eine solche Dialogbeziehung dar. Der Akteur gibt Informationen in das System ein, in der Regel seine PIN und den gewünschten Betrag. Gleichzeitig erhält er Informationen aus dem System, etwa die Anzeige des aktuellen Kontostandes oder Hinweismeldungen bei Fehleingaben.
Abbildung in dieser Leseprobe nicht enthalten Abhängigkeit
Beziehungen zwischen Anwendungsfällen bezeichnet die UML als Abhängigkeiten. Gelegentlich werden in unterschiedlichen Situationen, die gleichen Aktivitäten ausgeführt, beispielsweise die Prüfung von Benutzerberechtigungen bei Stammdatenneuanlagen oder -löschvorgängen. Um die redundante Beschreibung der Berechtigungsprüfung zu vermeiden, kann für diesen Ablauf ein eigener Anwendungsfall modelliert werden (Vgl. Balzert, 1999, S. 67).
Nimmt ein Anwendungsfall die Funktionalität eines anderen in Anspruch, werden die beiden Anwendungsfälle über eine Abhängigkeitsbeziehung miteinander verbunden. Die UML unterscheidet die Stereotypen «include» und «extend».
- Include-Beziehung[10]
Die Include-Beziehung zeigt, dass ein Anwendungsfall einen anderen enthält. Diese Abhängigkeit darf nur dann modelliert werden, wenn ein Anwendungsfall immer die bereitgestellte Funktionalität des anderen Anwendungsfalles verwendet (Vgl. Boggs; Boggs, 2003, S. 131).
Der Abhängigkeitspfeil zeigt auf den enthaltenen Anwendungsfall.
Abbildung 2: Beispiel für eine Include-Beziehung
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Anwendungsfalldiagramm in Rational Rose
- Extend-Beziehung[11]
Die Extend-Beziehung eignet sich insbesondere, für die Darstellung von optionalen Tätigkeiten. Der Basis-Anwendungsfall wird nur unter bestimmten Umständen, durch einen anderen Anwendungsfall, erweitert, beispielsweise, wenn eine zuvor definierte Bedingung erfüllt wird. Die Extend-Beziehung wird dargestellt, indem der Pfeil vom optionalen Anwendungsfall zu dem Erweiterten verläuft (Vgl. Boggs; Boggs, 2003, S. 131).
Abbildung 3: Beispiel für eine Extend-Beziehung
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Anwendungsfalldiagramm in Rational Rose
Rational Rose bietet zusätzlich den Stereotyp «refine» an. Dieser kann verwendet werden, um zu zeigen, dass ein Anwendungsfall aus einem anderen entsteht (Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 142).
Abbildung in dieser Leseprobe nicht enthalten Generalisierung
Ein weiteres wichtiges Modellelement der Objektorientierung stellt die Generalisierung (auch Vererbung) dar (Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 405). Sie wird in Anwendungsfalldiagrammen genutzt, um zu zeigen, dass mehrere Akteure oder Anwendungsfälle eine Gemeinsamkeit haben (Vgl. Boggs; Boggs, 2003, S. 132). Spezielle Akteure können beispielsweise die gesamte Struktur und das Verhalten von einem allgemeinen Akteur erben. Das Beispiel in Abbildung 4 zeigt, dass ein Vertriebsmitarbeiter entweder für den inländischen Markt zuständig ist oder den ausländischen Markt betreut.
Der Generalisierungspfeil führt immer vom Speziellen zum Allgemeinen (Vgl. Stevens; Pooley, 2000, S. 137).
Abbildung 4: Beispiel für eine Generalisierung
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Anwendungsfalldiagramm in Rational Rose
Bevor Programmierer mit der Codeerstellung beginnen, sollten sie die Struktur des Systems kennen. Dafür benötigen sie zunächst ein statisches Bild über die Bestandteile des Systems und deren Beziehungen zueinander. Um diese Informationen bereitzustellen, sollte ein Klassendiagramm modelliert werden, das sich vorerst auf die fachlich relevanten Klassen beschränkt. Im weiteren Verlauf können zusätzliche Klassendiagramme erstellt werden, um z.B. komplexe Zusammenhänge zu separieren.
Abbildung 5: Beispiel für ein Klassendiagramm
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Klassendiagramm in Rational Rose
Klassendiagramme zeigen nicht nur die Zusammenhänge zwischen den Klassen im System auf, sondern sie bieten Programmierern außerdem die Möglichkeit, die
modellierten Klassen für die Implementierung zu verwenden. Verschiedene Werkzeuge, wie z.B. JANUS/Access[12] sind in der Lage, aus Klassendiagrammen
automatisiert Codeskelette zu generieren, die als Basis für die Detailprogrammierung verwendet werden können.(Vgl. Boggs; Boggs, 2003, S. 51)
Klassen stellen die Hauptelemente in Klassendiagrammen dar. Sie beschreiben die statischen und dynamischen Objekteigenschaften (Vgl. Erler, 2000, S. 69). Klassen repräsentieren nicht nur die Struktur (Attribute), das Verhalten (Operationen) und die Beziehungen (Assoziationen, Vererbungsstrukturen) von Objekten, sondern besitzen zudem einen Mechanismus um neue Objekte zu erzeugen (Vgl. Oestereich, 2001, S. 209). Auf Grund dieser Funktionalität werden sie auch als Objektfabriken oder Objektschablonen bezeichnet.(Vgl. Balzert, 1999, S. 21) Der Vorgang der Objektgenerierung wird Instanziierung genannt.
Abbildung 6: Instanziierung von Objekten aus der Klasse „Software“
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle in Anlehnung an Oestereich, 2001, S. 210
Das obere Segment enthält den Namen der Klasse im Singular, z.B. Hardware. Der Klassenname beginnt mit einem Großbuchstaben und ist im Fettdruck darzustellen. Optional kann der Paketname mit zwei Doppelpunkten vorangestellt werden, um die Zugehörigkeit der Klasse zu einem bestimmten Paket zu zeigen.
Der mittlere Bereich zeigt die Attribute einer Klasse. Attribute werden kleingeschrieben. Setzt sich der Attributname aus mehreren Wörtern zusammen, werden die Wörter zu einem zusammengefasst und jeweils der erste Buchstabe der folgenden Wörter großgeschrieben. Zusätzlich zu ihrem Namen können Attribute ihren Datentyp anzeigen. Um die Datenpflege zu erleichtern, ist es möglich einen Vorbelegungswert (Initialwert) für das Attribut zu definieren.(Vgl. Oestereich, 2001, S. 210)
Der untere Abschnitt zeigt die Operationen einer Klasse. Neben dem Operationsnamen, der ebenfalls kleingeschrieben wird, kann die Operationssignatur zur Anzeige gebracht werden. Die Signatur setzt sich aus Parametern, die in Klammern eingeschlossen werden und gegebenenfalls einem Rückgabetyp zusammen.(Vgl. Boggs; Boggs, 2003, S. 258)
Die Sichtbarkeit gibt an, ob die Attribute und Operationen, außerhalb der Klasse, lesbar bzw. modifizierbar sind (s. hierzu auch S. 20 f.).
Neben den Attributen und Operationen kann eine Klasse die Definitionen eventueller Zusicherungen, Eigenschaftswerte und Stereotypen enthalten (Vgl. Oestereich, 2001, S. 209). In der Praxis werden diese, zugunsten der Lesbarkeit von Diagrammen, selten zur Anzeige gebracht. Ebenso können die Attribute und Operationen der Klassen vollständig ausgeblendet werden.
Tabelle 4: UML-Notation von Klassen am Beispiel der Klasse „Hardware“
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle
Abbildung in dieser Leseprobe nicht enthalten Abstrakte Klasse
Eine besondere Form von Klassen stellen abstrakte Klassen dar. Die Besonderheit liegt darin, dass abstrakte Klassen keine Objekte erzeugen.
Dieses Modellelement findet bei Vererbungsstrukturen Anwendung (Vgl. Boggs; Boggs, 2003, S. 234). Dabei stellt eine abstrakte Klasse eine Oberklasse dar, die gemeinsame Attribute und Operationen von ihren Unterklassen einschließt und an die Unterklassen vererbt. Die Unterklassen selbst repräsentieren normale Klassen, die Objekte instanziieren können.
Abstrakte Klassen werden wie normale Klassen in der UML notiert. Zur Kennzeichnung steht unter dem Klassenname der Eigenschaftswert {abstrakt}. Alternativ kann der Klassenname kursiv geschrieben werden. (Vgl. Oestereich, 2001, S. 214) Rational Rose verwendet die Kursivschrift.
Abbildung 7: Beispiel für eine abstrakte Klasse
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Klassendiagramm in Rational Rose
Die Computer GmbH verkauft EDV-Zubehör. Die Produkte des Unternehmens lassen sich entweder der Gruppe Hardware oder Software zuordnen. Da es keine Produkte „Zubehör“ gibt, entfällt die Notwendigkeit, dass die Klasse „Zubehör“ Objekte erzeugt. Sie kann somit als abstrakte Klasse modelliert werden. Demzufolge handelt es sich bei den Objekten der Anwendung immer um Objekte der Klasse „Hardware“ oder „Software“.
Objekte der realen Welt unterscheiden sich durch ihre Eigenschaften und/oder durch ihr Verhalten. Jede Objekteigenschaft kann als eigenständiges Attribut einer Klasse abgebildet werden. Um beispielsweise die Einkaufspreise von Softwareprodukten in der Anwendung zu verwalten, wird diese Information als Attribut „epreis“ definiert. Durch die Festlegung des Datentyps, wie z.B. Currency (Währung), String (Zeichenkette), Integer (Ganzzahl) oder Float (Gleitkommazahl), wird der Wertebereich für die Attributwerte bestimmt (Vgl. Schmuller, 2003, S. 55).
Nach der Definition der Objektstruktur können nun die individuellen Objektmerkmale, wie z.B.: „Der Artikel Microsoft Word 2000 kostet im Einkauf 200,00 Euro und wird für 250,00 Euro verkauft.“, in der Anwendung erfasst und gespeichert werden.
Es ist wichtig die Begriffe Attribut und Attributwert voneinander abzugrenzen. Alle Objekte einer Klasse besitzen identische Attribute, da diese durch die Klassendefinition vorgegeben sind. Im oben genannten Exempel werden jedoch die Attributwerte im Allgemeinen differieren, beispielsweise durch ihre verschiedenen Produktnamen oder durch unterschiedliche Verkaufspreise.
Abbildung in dieser Leseprobe nicht enthalten Klassenattribut
Diese Attributform dient in erster Linie der Vereinfachung der Datenpflege. Wird ein Attribut als Klassenattribut gekennzeichnet, haben alle Objekte der Klasse den gleichen Attributwert. Verkauft ein Unternehmen beispielsweise alle Artikel mit dem vollen Steuersatz, kann der Prozentsatz als Klassenattribut definiert werden. Dadurch müssen nicht alle Objekte einzeln mit dieser Information gepflegt werden.
Ein weiterer Vorteil liegt in der Wartung des Attributwertes. Bei einer Änderung des aktuellen Steuersatzes um ein Prozent, wird der Attributwert an einer zentralen Stelle geändert und gilt anschließend für alle Objekte dieser Klasse.
Klassenattribute werden in der UML-Notation unterstrichen.[16] (Vgl. Oestereich, 2001, S. 221)
Abbildung in dieser Leseprobe nicht enthalten Abgeleitetes Attribut
Eine weitere Sonderform stellen abgeleitete Attribute dar.
Der Attributwert leitet sich aus einem oder mehreren anderen Attributen ab und berechnet sich automatisch (Vgl. Boggs; Boggs, 2003, S. 257).
Der Kalkulationsalgorithmus ist als Zusicherung des Attributes anzugeben. Auf diese Weise können beispielsweise Deckungsbeiträge systemautomatisch berechnet werden.
Zur Kennzeichnung wird dem Attributnamen ein Schrägstrich „/“ vorangestellt. (Vgl. Oestereich, 2001, S. 221)
Tabelle 5: UML-Notation von Attributen am Beispiel der Klasse „Software“
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle
Objekte der realen Welt kommunizieren miteinander, indem sie sich Nachrichten senden (Vgl. Schmuller, 2003, S. 44 f.). Beispielsweise übermittelt der Computer ein Signal an den Drucker, wenn ein Dokument gedruckt werden soll.
Um ein vollständiges Bild der Realität zu erhalten, ist es daher wichtig sowohl die Struktur von Objekten als auch deren Verhalten zu modellieren.
Die dynamischen Eigenschaften eines Objektes werden in der UML durch Operationen abgebildet. Diese sind als Funktionen zu verstehen, die Algorithmen ausführen (Vgl. Balzert, 2001b, S. 180). Sendet ein Objekt eine Nachricht an ein anderes Objekt, wird das empfangende Objekt zur Ausführung einer Operation aufgefordert.(Vgl. Schmuller, 2003, S. 44 f.)
Alle Objekte einer Klasse verwenden dieselben Operationen (Vgl. Balzert, 1999, S. 548).
Die UML unterscheidet die drei folgenden Operationsarten:
1. Manageroperationen verwalten die Neuanlage (Konstruktoren) und Löschung (Destruktoren) von Objekten (Vgl. Boggs; Boggs, 2003, S. 259). Außerdem können sie Verbindungen zwischen Objekten herstellen (connect) und lösen (release) (Vgl. Neumann, 2002, S. 13).
2. Mit Hilfe von Zugriffsoperationen können die Attributwerte von Objekten gelesen und/oder geändert werden. Eine direkte Änderung der Attributwerte ist auf Grund des Prinzips der Datenkapselung nicht möglich.
3. Des Weiteren können Hilfsoperationen definiert werden. Diese erscheinen häufig in Interaktionsdiagrammen als reflexive Nachrichten (s. S. 30).(Vgl. Boggs; Boggs, 2003, S. 259)
Zur Kennzeichnung der Operationsvarianten im Modell, können entsprechende Stereotypen definiert werden.
Analog zu Anwendungsfalldiagrammen können auch Klassendiagramme Beziehungen zwischen den Modellelementen abbilden. Am häufigsten werden Assoziationen und Generalisierungen zwischen Klassen modelliert.
Abbildung in dieser Leseprobe nicht enthalten Assoziation
Assoziationen, zwischen ein oder mehreren Klassen, werden als einfache Linie dargestellt und können durch die Angabe von Assoziations- und/oder Rollennamen spezifiziert werden. Außerdem besteht die Option, an den Linienenden die Multiplizitäten (s. S. 20) anzugeben.(Vgl. Balzert, 1999, S. 535) Reflexive Assoziationen stellen Beziehungen zwischen Objekten derselben Klasse dar (Vgl. Balzert, 1999, S. 40). Assoziationen werden bei der Erzeugung von Objekten als konkrete Objektbeziehungen instanziiert (Vgl. Oestereich, 2001, S. 330).
Abbildung in dieser Leseprobe nicht enthalten Generalisierung
Die Generalisierung stellt die Beziehung zwischen zwei Klassen dar, einer generellen Oberklasse und einer speziellen Unterklasse (Vgl. Grässle; Baumann; Baumann, 2000, S. 150).
Der Generalisierungspfeil verläuft immer von der Unter- zur Oberklasse.
Diese Beziehung wird häufig in Verbindung mit abstrakten Klassen modelliert. Daher soll das Beispiel aus Abbildung 7 erneut aufgegriffen und erweitert werden.
Abbildung 8: Beispiel für Vererbungsstrukturen zwischen Klassen
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Klassendiagramm in Rational Rose
Gemeinsame Eigenschaften von Hard- und Softwareprodukten können in der
Oberklasse definiert und an die Unterklassen vererbt werden. Zusätzlich besteht die Möglichkeit weitere Attribute und Operationen individuell für die Unterklassen festzulegen.
Die wesentlichen Vorteile dieses Konstruktes sind, dass identische Attribute und Operationen von Klassen nicht redundant in der Datenbank vorzuhalten sind. Ferner erleichtert dies die Wartung und Pflege des Systems, da eventuelle Änderungen lediglich an der Oberklasse vorzunehmen sind.
Abbildung in dieser Leseprobe nicht enthalten Multiplizität
Die Multiplizität erlaubt Aussagen darüber wie viele Objekte an einer Assoziation beteiligt sind (Vgl. Grässle; Baumann; Baumann, 2000, S. 150). Genau genommen spezifiziert sie die Anzahl der Objekte, die ein bestimmtes Objekt kennen kann (Vgl. Balzert, 1999, S. 41).
Tabelle 6: Überblick über Multiplizitäten
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle in Anlehnung an Balzert, 1999, S. 41; Boggs; Boggs, 2003, S. 109
Abbildung in dieser Leseprobe nicht enthalten Sichtbarkeit
Das Konzept der Kapselung kann durch die Sichtbarkeitsdefinition eingeschränkt werden. Die Sichtbarkeit ist eine Eigenschaft, die für Attribute und Operationen steuert, ob diese Elemente von außen, d.h. außerhalb der Klasse sichtbar sind.
Abhängig von der Konfiguration können damit Lese- und Schreibrechte auf die Elemente, durch andere Modellelemente, festgelegt werden.(Vgl. Boggs; Boggs, 2003, S. 252)
Tabelle 7: Sichtbarkeit für Attribute und Operationen
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle in Anlehnung an Erler, 2000, S. 73; Boggs; Boggs, 2003, S. 252,
S. 276
Objekte der realen Welt befinden sich zu jedem Zeitpunkt in einem bestimmten Zustand (Vgl. Schmuller, 2003, S. 29). Beispielsweise befindet sich ein Computer-monitor im Zustand „Betriebsbereit“, wenn er eingeschaltet ist. Finden keine Aktivitäten am PC statt, wechselt der Zustand in den Modus „Bildschirmschoner an“.
Folglich können Objekte diverse Zustände im Verlauf ihres Lebens annehmen, die sich entweder als Reaktion auf bestimmte Ereignisse (z.B. Einschalten des Monitors) oder auf Grund von Zeitablauf (z.B. nach fünf Minuten) ändern.
Zustandsdiagramme halten diese Ausschnitte der Realität fest und modellieren auf diese Weise das Verhalten von Objekten.(Vgl. Schmuller, 2003, S. 29) Zustandsdiagramme werden in der Regel dann erstellt, wenn Objekte einer Klasse unterschiedliche Zustände annehmen können oder komplexe Operationen, hinsichtlich ihrer Wirkung, zu spezifizieren sind (Vgl. Boggs; Boggs, 2003, S. 40).
Grundsätzlich dienen Zustandsdiagramme Informationszwecken. Durch die dynamische Sicht auf das System, werden insbesondere Analytiker und Entwickler in die Lage versetzt, das Verhalten von Objekten im System zu verstehen und
Zusammenhänge zu erkennen (Vgl. Schmuller, 2003, S. 129). Darüber hinaus wird der Entwicklungsprozess unterstützt, da beispielsweise durch den Einsatz von Wächterbedingungen, bereits Geschäftslogik abgebildet und in die Implementierung einfließen kann.
Abbildung 9: Beispiel für ein Zustandsdiagramm
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Zustandsdiagramm in Rational Rose in Anlehnung an Erler, 2000, S. 118
Zustände sind die Hauptelemente von Zustandsdiagrammen. Sie stellen eine Zeitspanne dar, in der ein Objekt eine bestimmte Bedingung erfüllt, auf ein Ereignis wartet oder in der Aktivitäten ausgeführt werden (Vgl. Oestereich, 2001, S. 337). Objekte bleiben immer für eine endliche Dauer in einem bestimmten Zustand (Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 330).
In der UML-Notation werden Zustände als Rechteck mit abgerundeten Ecken dargestellt. Sie können - ebenso wie Klassen - in drei Bereiche untergliedert werden. Der obere Abschnitt beinhaltet den Namen des Zustandes, der mittlere Abschnitt eventuelle Zustandsvariablen wie Timer oder Zähler. Das untere Segment zeigt die Aktionen und Aktivitäten an, die dieser Zustand durchführt.(Vgl. Schmuller, 2003, S. 121)
Aktionen sind Operationen, die beim Eintritt in den Zustand (entry) oder beim Verlassen des Zustandes (exit) ausgeführt werden. Ebenso kann das Objekt während des Zustandes Aktivitäten durchführen (do).(Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 196)
Um zu zeigen, dass ein Objekt seinen Zustand ändert, werden Ausgangs- und Zielzustand mittels einer durchgezogenen Pfeillinie verbunden. Dabei ist der Pfeil auf den Zielzustand gerichtet.(Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 333) Diese Beziehung wird Zustandsübergang oder Transition genannt (Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 297).
Sind Ausgangs- und Folgezustand identisch, spricht man von einer Transition to Self (Vgl. Balzert, 1999, S. 81).
Am Zustandsübergang kann das Ereignis angegeben werden, das den Zustandsübergang auslöst. Um zu verdeutlichen, dass sich ein Zustand ändert, weil eine bestimmte Bedingung erfüllt ist, kann eine Wächterbedingung angezeigt werden. Diese muss immer wahr sein, damit eine Zustandsänderung erfolgt.(Vgl. Schmuller, 2003, S. 122 f.)
Ein Zustandsdiagramm beginnt immer mit einem Startzustand und kann mit Endzuständen enden. Diese beiden Zustände stellen so genannte Pseudozustände dar, da Objekte diese Zustände niemals annehmen können (Vgl. Erler, 2000, S. 116).
Abbildung in dieser Leseprobe nicht enthalten Startzustand
In der UML wird der Startzustand durch einen ausgefüllten Kreis symbolisiert (Vgl. Neumann, 2002, S. 276). Der Startzustand fordert einen umgehenden Übergang in den folgenden Zustand, da dieser den erstmöglichen Zustand für neu erzeugte Objekte darstellt (Vgl. Neumann, 2002, S. 55; vgl. Erler, 2000, S. 116).
Abbildung in dieser Leseprobe nicht enthalten Endzustand
Ein Endzustand wird als Kreis notiert, der einen kleineren ausgefüllten Kreis enthält (Vgl. Neumann, 2002, S. 276). Der Einsatz von Endzuständen im Zustandsdiagramm ist optional und quantitativ unbegrenzt.(Vgl. Boggs; Boggs, 2003, S. 327) Der Endzustand stellt dar, dass das Objekt nicht mehr existiert. Daher führen aus diesem Zustand keine Transitionen heraus.(Vgl. Balzert, 1999, S. 80)
Die Computer GmbH möchte ihren Freigabeprozess von Einkaufsbestellungen optimieren. Dazu soll der Genehmigungsweg systemseitig abgebildet werden. Jeder, für die Materialbestellung zuständige Mitarbeiter, verfügt über ein Budget von 400 Euro je Bestellung. Bestellungen mit höheren Gesamtbeträgen müssen vom Einkaufsleiter genehmigt werden. Die Kommunikation der Prozessbeteiligten erfolgt ausschließlich via E-Mail-Korrespondenz.
Um die Anforderungen für die Systementwickler aufzubereiten, sind die Informationen zunächst zu abstrahieren. Zum besseren Verständnis können die Abläufe zusätzlich durch Diagramme veranschaulicht werden. Das folgende Zustandsdiagramm bildet die zu implementierende Geschäftslogik ab. Durch die leicht nachvollziehbare Darstellung, ist der Prozess sowohl für den Auftraggeber als auch für die Systementwickler verständlich.
Abbildung 10: Zustandsdiagramm „Freigabeprozess von Einkaufsbestellungen“
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Zustandsdiagramm in Rational Rose
Das Zustandsdiagramm, in Abbildung 10, wurde für die Klasse „Bestellung“ modelliert und ist wie folgt zu lesen.
Ein Objekt der Klasse „Bestellung“, kann entweder den Zustand „Erstellt“, „Zu genehmigen“, „Abgewiesen“ oder „Freigegeben“ annehmen.
Der erste Zustand wird ausgelöst, sobald der Anwender eine Bestellung im System erfasst. Übersteigt der Bestellbetrag die Freigabegrenze von 400 Euro, so löst dieses Ereignis ein Genehmigungsverfahren und den neuen Zustand „Zu genehmigen“ aus.
Der Einkaufsleiter (genehmigende Person) erhält durch den Eintritt in diesen Zustand eine Nachricht per E-Mail. Diese informiert ihn darüber, dass eine Bestellung zur Freigabe ansteht. Der Einkaufsleiter muss nun die übermittelten Bestelldaten prüfen und über eine Genehmigung bzw. Ablehnung entscheiden.
Durch die Eingabe des Beschlusses in das System, wechselt der Zustand der Bestellung entweder in „Freigegeben“ oder „Abgewiesen“. Der zuständige Bearbeiter wird immer per E-Mail über den Entschluss des Einkaufsleiters benachrichtigt („Freigabe“ oder „Abgewiesen“) und kann somit die Bearbeitung fortsetzen.
Einkaufsbestellungen unter 400 Euro erhalten automatisch den Status „Freigegeben“ und umgehen das Freigabeverfahren.
Eine Sonderform des Zustandsdiagramms stellen Aktivitätsdiagramme dar, die gleichermaßen dynamische Aspekte des Systems zeigen. Sie können zur Beschreibung von Anwendungsfällen, Arbeitsabläufen oder komplexen Operationen erstellt werden.(Vgl. Balzert, 1999, S. 87)
Aktivitätsdiagramme zeigen die Reihenfolge der einzelnen Arbeitsschritte auf. Ferner können die organisatorischen Verantwortlichkeitsbereiche (Akteure), durch so genannte Schwimmbahnen dargestellt werden sowie die vom Arbeitsablauf betroffenen Objekte.(Vgl. Boggs; Boggs, 2003, S. 89) Darüber hinaus besteht die Möglichkeit parallel verlaufende Aktivitäten zu modellieren. Die Visualisierung von alternativen Abläufen erfolgt durch den Einsatz von Entscheidungspunkten.
Tabelle 8: Aktivitätsdiagramm – Elemente
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstellte Tabelle
In Abhängigkeit davon welchen Sachverhalt das jeweilige Aktivitätsdiagramm beschreibt, kann eine Aktivität die Durchführung einer Aufgabe, ein Schritt eines Arbeitsablaufes oder die Ausführung einer Anweisung in einer Prozedur sein.
Aktivitäten ähneln Zuständen, unterscheiden sich jedoch darin, dass sie nicht auf Ereignisse warten.(Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 143)
Aktivitäten können sowohl nacheinander als auch parallel ablaufen. Ebenso können sie organisatorisch verteilt sein.(Vgl. Grässle; Baumann; Baumann, 2000, S. 39) Werden die Zuständigkeiten durch Schwimmbahnen dargestellt, wie in Abbildung 11, ist jede Aktivität genau einem Verantwortlichkeitsbereich zuzuordnen (Vgl. Erler, 2000, S. 131).
In der UML werden Aktivitäten als Rechteck, mit abgerundeten Seitenlinien, symbolisiert. Sind Aktionen und/oder Unteraktivitäten definiert, können diese im unteren Bereich des Aktivitätssymbols zur Anzeige gebracht werden.(Vgl. Borrmann; Komnick; Landgrebe; Matèrne; Rätzmann; Sauer, 2001, S. 144) Für umfangreiche Unteraktivitäten empfiehlt sich die Darstellung in separaten Aktivitätsdiagrammen, die sich in Rational Rose mit dem Hauptdiagramm verknüpfen lassen.
Die Beziehung zwischen Aktivitäten wird in der UML als Übergang bezeichnet und als Pfeil dargestellt. Ein eingehender Übergang löst eine Aktivität aus. Nachdem die Aktivität ausgeführt wurde, löst sie einen Übergang aus und wechselt in die nächste Aktivität.(Vgl. Grässle; Baumann; Baumann, 2000, S. 71)
Ist die Folgeaktivität von der Erfüllung einer Bedingung abhängig, so können mehrere Übergänge aus einer Aktivität führen, die sich allerdings gegenseitig ausschließen müssen. In der Praxis werden diese Fälle mittels Entscheidungspunkten modelliert.
Objekte sind Instanzen von Klassen, d.h. Objektstruktur und -verhalten sind durch die Klassendefinition vorgegeben. Die Attributwerte hingegen sind für jedes Objekt individuell, ebenso wie die nicht veränderbare Objektidentität.(Vgl. Oestereich, 2001, S. 329) Die Gesamtheit der Attributwerte definiert den aktuellen Objektzustand (Vgl. Neumann, 2002, S. 458). Das Objektsymbol in der UML entspricht der Darstellung von Klassen. Um Objekte von Klassen abzugrenzen, wird der Objektname unterstrichen. Zusätzlich kann der Klassenname angegeben werden.(Vgl. Schmuller, 2003, S. 28) Objekte können in Aktivitätsdiagrammen verwendet werden, um zu zeigen, dass eine Aktivität ein neues Objekt erzeugt oder ein bestehendes Objekt ändert. Ebenso können Aktivitäten, die zwischen Objekten stattfinden, dargestellt werden (Vgl. Booch; Rumbaugh; Jacobson, 1999, S. 292).
Abbildung in dieser Leseprobe nicht enthalten Startzustand
Der Beginn der ersten Aktivität wird mit einem Startzustand symbolisiert.
Grafisch wird der Startzustand durch einen ausgefüllten Kreis dargestellt (Vgl. Neumann, 2002, S. 276).
Abbildung in dieser Leseprobe nicht enthalten Endzustand
Endet ein Arbeitsablauf, so kann dies durch einen Endzustand angezeigt werden (Vgl. Boggs; Boggs, 2003, S. 114). Die Verwendung von Endzuständen im Diagramm ist optional (Vgl. Boggs; Boggs, 2003, S. 327).
Endzustände werden in der UML durch einen Kreis dargestellt, der einen kleineren ausgefüllten Kreis enthält (Vgl. Neumann, 2002, S. 276).
Abbildung in dieser Leseprobe nicht enthalten Entscheidung
Entscheidungspunkte dienen der Definition von Regeln und somit zur Fallunterscheidung (Vgl. Erler, 2000, S. 128). Sie werden durch eine Raute dargestellt.
Eine Entscheidung kann einen Eingang und zwei oder mehr Ausgänge haben (Vgl. Grässle; Baumann; Baumann, 2000, S. 71). Die ausgehenden Übergänge schließen sich gegenseitig aus und sind daher mit Wächterbedingungen zu spezifizieren, die in eckigen Klammern angezeigt werden (Vgl. Schmuller, 2003, S. 165).
Die Buchhaltung der Computer GmbH schreibt regelmäßig Kunden und Lieferanten mit einem Mahnbrief an, die sich im Zahlungs- bzw. Lieferverzug befinden.
Die folgende Abbildung zeigt einen Ausschnitt der Aktivitäten, um diese MS Word-Dokumente zu erstellen, zu sichern und zu drucken.
Abbildung 11: Aktivitätsdiagramm „Mahnbriefe der Computer GmbH“
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Selbsterstelltes Aktivitätsdiagramm in Rational Rose
Zuerst öffnet der Anwender das Textverarbeitungsprogramm. Das System erzeugt automatisch ein neues MS Word-Dokument und speichert es als Datei. Das Dokument wird geöffnet und der Anwender kann den Mahntext eingeben. Die Änderungen werden automatisch gespeichert. Das Objekt „Dokument1“ nimmt den Zustand „Gespeichert “ an.
Sofern sich der Drucker im betriebsbereiten Zustand befindet, erfolgt der Ausdruck des Briefes. Anderenfalls erhält der Anwender eine Hinweismeldung, wie z.B. „Bitte schalten Sie den Drucker ein.“
Nach erfolgreichem Drucken des Dokumentes befindet sich das Objekt „Dokument1“ im Zustand „Gedruckt“. Dieses Aktivitätsdiagramm zeigt somit zugleich die Aktivitäten, die zwischen den Zuständsänderungen des Objektes stattfinden. Dadurch kann gegebenenfalls auf die Modellierung eines zusätzlichen Zustandsdiagramms verzichtet werden.
Die zahlreichen Darstellungsmöglichkeiten der UML verleiten schnell, alle Aspekte visualisieren zu wollen. Damit die Modellierungsarbeiten nicht vergebens getätigt werden, ist der Detaillierungsgrad bei allen Diagrammen, auf die Zielgruppe und den verfolgten Zweck abzustimmen.(Vgl. Grässle; Baumann; Baumann, 2000, S. 79)
Kollaborations - und Sequenzdiagramme sind Diagramme, die den Nachrichtenaustausch zwischen ausgewählten Objekten abbilden (Interaktionsdiagramme) (Vgl. Grässle; Baumann; Baumann, 2000, S. 83).
Sie werden erstellt, um die Funktionalitäten von Anwendungsfällen zu beschreiben und den zeitlichen Verlauf der Interaktionen darzustellen (Vgl. Boggs; Boggs, 2003, S. 36). Folglich zeigen Sequenzdiagramme, in abstrahierter Form, wie das System arbeitet. Durch seinen übersichtlichen und relativ leicht verständlichen Aufbau, eignet sich dieser Diagrammtyp insbesondere zum Informationsaustausch mit dem Auftraggeber (Vgl. Grässle; Baumann; Baumann, 2000, S. 52).
Jedes Sequenzdiagramm stellt in der Regel ein Szenario eines Anwendungsfalls dar (Vgl. Grässle; Baumann; Baumann, 2000, S. 84). Alternativ- oder Parallelszenarios können in weiteren Sequenzdiagrammen modelliert und in Rational Rose mit dem Hauptszenario verknüpft werden. Auf diese Weise entsteht ein vollständiges Bild, über die zu implementierenden Funktionalitäten eines Anwendungsfalls.
[...]
[1] In dieser Arbeit werden die Modellelemente in der UML-Version 1.3 notiert, da die aktuelle Version 2.0 nicht vom eingesetzten UML-Modellierungswerkzeug Rational Rose 2000e unterstützt wird.
[2] Die Computer GmbH verkauft EDV-Zubehör (Hard- und Software) an Endkunden.
[3] Die Version Rose Enterprise unterstützt die folgenden Sprachen: C++, Java, Ada, CORBA, Visual Basic, COM, Oracle8 und XML (Vgl. Boggs; Boggs, 2003, S. 51).
[4] Die automatisierte Codegenerierung erfolgt hauptsächlich aus statischen Diagrammen heraus, z.B. aus Klassendiagrammen. Durch Reverse Engineering können auch Änderungen im Programmcode automatisch in das Modell zurück übernommen werden.
[5] Der Schwerpunkt dieser Arbeit, liegt auf der Betrachtung von Softwaresystemen.
[6] Der Datentyp „String“ ermöglicht die Eingabe von Buchstaben, Zahlen und Sonderzeichen als Freitext. Zusätzlich kann, in spitzen Klammern, die maximal zulässige Zeichenanzahl definiert werden, z.B. <30>.
[7] Der Datentyp „Float“ lässt ausschließlich die Eingabe von Gleitkommazahlen zu.
[8] Diese Arbeit legt seinen Schwerpunkt auf das Modell der Systemnutzung und das Logische Modell.
[9] Heide und Helmut Balzert verwenden in ihren Publikationen, anstelle des Begriffes „Anwendungsfall“ den
Begriff „Geschäftsprozess“. Um Verwechslungen mit Geschäftsprozessdiagrammen zu vermeiden, wird in dieser Arbeit der Begriff „Anwendungsfall“ verwendet.
[10] Die „Include-Beziehung“ wird in der Literatur auch als „Enthält-Beziehung“ bezeichnet.
Heide Balzert verwendet den Begriff „Uses-Beziehung“.
[11] In der Literatur ist statt „Extend-Beziehung“ auch der Begriff „Erweitert-Beziehung“ zu finden.
[12] JANUS/Access ist ein Produkt der Firma OTRIs AG.
[13] Der Datentyp „Integer“ lässt ausschließlich die Eingabe von Ganzzahlen zu. Im Beispiel wird der
Attributwert mit „Null“ vorbelegt, um die Datenpflege zu vereinfachen.
[14] Attribute mit dem Datentyp „Currency“ zeigen die eingegebenen Werte als Währungsbetrag an.
[15] Der Datentyp „short“ ähnelt dem „Integer“-Typ, mit dem Unterschied, dass der zulässige Wertebereich
kleiner ist. Er beschränkt sich auf ganze Zahlen zwischen –32.768 und 32.768.
[16] In Rational Rose wird dem Klassenattribut ein Dollarzeichen „$“ zur Kennzeichnung vorangestellt.
[17] In Rational Rose wird statt dem Stern „*“ der Buchstabe „n“ dargestellt.
[18] Dieser Sichtbarkeitstyp ist abhängig von der Programmiersprache. Er wird von Rational Rose unterstützt.
In anderen UML-Werkzeugen, wie zum Beispiel MS Visio und Objecteering steht die Auswahl dieses Typs
zur Zeit nicht zur Verfügung.
