Objektorientierte Systemanalyse

Das Buch Objektorientierte Systemanalyse begleitet den Leser anhand einiger durchgängiger Beispiele durch Analyse und Design der objektorientierten Modellierung. Die wesentlichen und praktikabelsten Diagramme der UML werden kurz und knapp beschrieben und sind mit Übungsaufgaben und Lösungen hinterlegt. Der optimale Einstieg für Einsteiger, welche die objektorientierte Theorie auch umsetzen wollen.

Das kompakte Lehrbuch richtet sich an Studierender der Bachelorstudiengänge der Wirtschaftsinformatik und angrenzenden Studiengängen.

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 Akteur ein Ergebnis von messbarem Wert zu erstellen" (siehe Balzert [1]).

Der „messbare Wert" bedeutet in diesem Kontext, dass das Ergebnis einen sichtbaren, quantifizierbaren und/oder qualifizierbaren Einfluss auf die Systemumgebung hat. Eine Transaktion ist eine Menge von Verarbeitungsschritten, von denen entweder alle oder keiner ausgeführt werden.