Objektorientierte Systemanalyse

Gert Heinrich, geb. 1960 in Stuttgart, Studium der Mathematik mit Nebenfach Physik an der Universität Stuttgart, 1985 Diplom-Mathematiker,,Promotion zum Dr. rer. nat. bei Prof. Dr. Uwe Jensen am Institut für Angewandte Mathematik und Statistik an der Universität Hohenheim 1993-95 Tätigkeit am Institut für Angewandte Mathematik und Statistik der Universität Hohenheim als wissenschaftlicher Mitarbeiter bzw. wissenschaftlicher Angestellter, 1996-2001 Tätigkeit bei der Staatl. Lotterie-Einnahme Glöckle in Stuttgart als Leiter Belegdatenerfassung und Kartenservice und bei der Allianz Lebensversicherungs AG in Stuttgart in der Abteilung Informationssysteme als Projektleiter im E-Business Bereich seit Dezember 2001 Leiter des Studiengangs Wirtschaftsinformatik an der Berufsakademie Villingen-Schwenningen

Klaus Mairon; geb. 1967 in Freiburg i.Br.; Studium der Wirtschaftsinformatik an der Hochschule Furtwangen (1989-1994), zusätzliches Master-Studium Application Architectures an der Hochschule Furtwangen (2005-2006). Klaus Mairon verfügt über langjährige Erfahrung im Bereich objektorientierter Softwareentwicklung. Er ist als Executive IT-Consultant im Bereich Claims Management der Firma Metris GmbH verantwortlich für die Architektur, Methodik und Technologie der erstellten Software. In seinem Verantwortungsbereich liegen zusätzlich die Themen Grundlagenforschung, Know-how-Transfer und Hochschulkontakte sowie Schulungen zu den Themen Java, EJB und OOA/OOD mit UML. Seit 1997 ist Klaus Mairon nebenberuflich als Lehrbeauftragter an den Fakultäten Allgemeine Informatik und Wirtschaftsinformatik der Hochschule Furtwangen tätig.

1;Vorwort;6
2;Inhalt;8
3;Abbildungsverzeichnis;12
4;1 Einführung in die Objektorientierung;18
4.1;1.1 Entstehungsgeschichte der Objektorientierung;18
4.2;1.2 Historie der Objektorientierung;24
4.3;1.3 Objektorientierte Vorgehensmodelle;26
4.4;1.4 Grundkonzepte der Objektorientierung;26
4.5;1.5 UML;28
4.6;1.6 Aufgaben;31
5;2 Objektmodellierung;32
5.1;2.1 Einführung;32
5.2;2.2 Strukturmodellierung;34
5.3;2.3 Verhaltensmodellierung;57
5.4;2.4 Aufgaben;69
6;3 Objektorientierte Analyse;74
6.1;3.1 Anwendungsfälle;75
6.2;3.2 Aktivitätsdiagramme;86
6.3;3.3 Klassen- und Objektdiagramme;97
6.4;3.4 Zustandsautomaten;112
6.5;3.5 User Interface Design;115
6.6;3.6 CRC-Karten;123
7;4 Objektorientiertes Design;126
7.1;4.1 Verfeinerung des Klassendiagramms;127
7.2;4.2 Szenarios mit Sequenzdiagrammen;137
7.3;4.3 Beschreibung von Zustandsänderungen;138
7.4;4.4 Wege zu einem guten Design;140
8;5 Lösungen;146
8.1;5.1 Lösungen zu Kapitel 1;146
8.2;5.2 Lösungen zu Kapitel 2;147
8.3;5.3 Lösungen zu Kapitel 3;166
8.4;5.4 Lösungen zu Kapitel 4;185
9;6 Literatur- und Quellenverzeichnis;188
10;7 Index;190

3 Objektorientierte Analyse (S. 57-58)

Das Ziel der Analyse ist es, die Anforderungen eines Auftraggebers an ein neues Softwaresystem zu ermitteln und zu beschreiben. Hierzu muss ein Modell des Fachkonzepts erstellt werden, das vollständig, eindeutig, konsistent und realisierbar ist. Bei der (System-)Analyse werden bewusst alle Aspekte der Implementierung ausgeklammert. Erst der Entwurf der Benutzungsschnittstelle (GUI-Entwurf) stellt einen ersten Übergang in das objektorientierte Design dar, weil hier Implementierungsdetails eine gewisse Rolle spielen. Trotzdem kann der Entwurf der Benutzungsschnittstelle bereits in der Analyse durchgeführt werden, weil für viele Anwender erst hierüber ein vollständiges Bild der zukünftigen Anwendung entsteht. Die objektorientierte Analyse geht von Objekten aus, die sich in der realen Welt befinden. Das sind nicht nur Gegenstände oder Personen, sondern häufig auch Begriffe oder Ereignisse aus dem Anwendungsbereich.

Ziel der objektorientierten Analyse ist es, das zu realisierende Problem zu verstehen und in einem OOA-Modell zu beschreiben. Dieses Modell soll die essentielle Struktur und Semantik des Problems, aber noch keine technische Lösung beschreiben. Das OOA-Modell (Analysemodell) bildet die fachliche Lösung des zu realisierenden Systems. Man spricht hierbei auch vom Fachkonzept, welches aus einem statischen und einem dynamischen Modell besteht.

Das statische Modell beschreibt insbesondere die Klassen des Systems, die Beziehungen zwischen den Klassen und die Vererbungsstrukturen. Pakete dienen dazu, Teilsysteme zu bilden, um bei großen Systemen einen besseren Überblick zu ermöglichen. Das dynamische Modell zeigt die Funktionsabläufe. Anwendungsfälle beschreiben die durchzuführenden Aufgaben auf einem hohen Abstraktionsniveau. Sie werden durch Aktivitätsdiagramme und/oder Zustandsautomaten verfeinert. Das OOA-Modell muss alle Informationen enthalten, um daraus einen Prototyp der Benutzungsoberfläche abzuleiten.

3.1 Anwendungsfälle

Der Begriff des Anwendungsfalls (engl. Use Case) wurde von Dr. Ivar Jacobson erstmals 1987 in Zusammenhang mit einer objektorientierten Methode auf einer Konferenz vorgestellt. Über sein Buch Software Engineering: Use Case Driven Approach [8] wurde der Anwendungsfall zum allgemeinen Begriff in der Objektmodellierung. In den folgenden Jahren wurde die Idee von Jacobson weiterentwickelt. Obwohl das Konzept der Anwendungsfälle prinzipiell vollkommen unabhängig von der objektorientierten Modellierung ist, besitzt es einen festen Platz in den meisten Vorgehensmodellen für die objektorientierten Softwareentwicklung und auch in der UML.

In vielen aktuellen Vorgehensmodellen schließt sich die Modellierung von Anwendungsfällen an die Geschäftsprozessmodellierung an und basiert auf den darin erstellten Ergebnissen (z.B. Soll-Prozessen). Anwendungsfälle werden hierbei für die systemseitig zu unterstützenden Arbeitsschritte im modellierten Prozess erstellt. Auf einer höheren Abstraktionsebene können Anwendungsfälle auch zur Beschreibung von Geschäftsprozessen eingesetzt werden. In diesem Buch werden Anwendungsfälle jedoch als erste Schritte in der Analyse behandelt und dienen der Beschreibung der Aufgaben eines neuen Softwaresystems. Somit befinden sich die hier beschriebenen Anwendungsfälle auf einem niedrigeren Abstraktionsniveau als die o.g. Geschäftsprozesse.

3.1.1 Anwendungsfälle und Akteure

Ein Anwendungsfall innerhalb eines Informationssystems wird definiert "als eine Sequenz von zusammengehörenden Transaktionen, die von einem Akteur im Dialog mit einem System ausgeführt werden, um für den