Systemanalyse

Quellenverweis

BRL99, You92, Mor99

Sinn und Zweck

Das Ziel der Systemanalyse ist die Identifikation, Modellierung und Bewertung von Systemen. Es können folgende Methoden verwendet werden:

Objektorientierte Analyse (OOA)

Die OOA kann mit den Mitteln der UML Methodenfamilie durchgeführt werden:

1. Use-Case-Modellierung

Zielsetzung der Methode ist die Erfassung und Darstellung der aus Sicht von externen Bedienungseinheiten ("Aktoren") an ein System gestellten funktionalen Anforderungen. Die Anforderungen sind in Form von Anwendungsfällen, den "Use Cases", zu beschreiben. Ein "Use Case" kann in einer Reihe von Szenarios konkretisiert werden. Externe Bedienungseinheiten (z.B. Mitarbeiter, Projektleiter oder Administrator) repräsentieren Rollen, die von konkreten Personen, Maschinen, Computer-"Tasks" oder anderen Systemen eingenommen werden können.

2. Klassen-/Objekt-Modellierung

Die Methode dient zur objektorientierten Systementwicklung. Diese erfordert die Modellierung von Klassen, von zugehörigen Attributen und Operationen sowie der Beziehungen zwischen den Klassen. Es ist die Aufgabe der Klassenmodellierung, die statische Klassenstruktur in Klassenmodellen festzulegen. Eine Klasse ist in Bezug auf die Ausführung eines Systems statisch und definiert die Struktur und das Verhalten ähnlicher Objekte. Objekte sind als Instanzen von Klassen zu modellieren.

Die Klassen-/Objektmodellierung kann in der objektorientierten Entwicklung sowohl während der Analyse- als auch während der Entwurfsphase eingesetzt werden. Während der Analyse sind die Klassenstruktur beziehungsweise die Objektstrukturen aus Nutzersicht zu modellieren, um auszudrücken, was ein System tut. Im Entwurf sind diese Strukturen zu verfeinern, und es ist festzulegen, wie das System etwas tut.

Bei der Klassenmodellierung sind Attribute zu verwenden, um identifizierende, beschreibende oder auch referenzierende Informationen in einer Klasse zu modellieren. Durch zusätzliche Modellierungsmöglichkeiten, wie beispielsweise die Festlegung von Sichtbarkeiten, die Vergabe von Rollennamen, die Zuordnung von Einschränkungen ("constraints"), die Beschreibung abgeleiteter Attribute und die Verwendung von Beziehungen höherer Ordnung, können die Entwicklungsergebnisse verfeinert werden.

Die Konzepte der Klassenmodellierung können auch eingesetzt werden, um die statischen Aspekte von Schnittstellen von Klassen und Subsystemen und ihre Anwendung zu definieren. Die Teile von Klassen (Attribute, Operationen) beziehungsweise Subsystemen (Klassen, Beziehungen), die als Schnittstellen definiert werden sollen, können nochmals in eigenen Schnittstellenmodellen gekennzeichnet werden.

3. Interaktionsmodellierung

Die Methode dient zur objektorientierten Systementwicklung. Zielsetzung ist es, Interaktionen zwischen Objekten und ihre Reihenfolge in Interaktionsmodellen zu beschreiben. Durch Interaktionen kann das Auftreten von Ereignissen beziehungsweise der Austausch von Nachrichten ausgedrückt werden. Die Methode kann zur Formalisierung von Szenarios (Folgen von Ereignissen und das damit verbundene Systemverhalten) und zur Modellierung des dynamischen Ablaufs von Operationen eingesetzt werden. Mit Zeitliniendiagrammen ("Sequence Diagrams") wird dabei das Ziel verfolgt, schwerpunktmäßig die ablauforientierte Reihenfolge der Interaktionen zwischen den Objekten zu modellieren und zu visualisieren. Um die Interaktionsbeziehungen detaillierter zu modellieren und um die Softwarestruktur zu betonen, werden vorwiegend Interaktionsgraphen ("Collaboration Diagrams") eingesetzt. Der für die Kommunikation benötigte Zeitaufwand wird in der Interaktionsmodellierung nicht direkt betrachtet, jedoch können Zeitbeschränkungen modelliert werden. Nebenläufigkeiten sind abbildbar. Durch die Modellierung von Signaturen, synchronen und asynchronen Abläufen, Zeit-, Ablauf- und Synchronisationsbedingungen, Verzweigungen, Iterationen, Rekursionen sowie des Erzeugens und Löschens von Objekten können Entwicklungsergebnissse verfeinert werden.

4. Aktivitätsdiagramme

Aktivitätsdiagramme können als Konkretisierung der Use-Cases durch Anlegen von Aktivitätsdiagrammen in Use-Cases angewendet werden. Damit können Abhängigkeiten, nebenläufige Prozesse, Entscheidungs-/Verzweigungspunkte dargestellt werden. Des Weiteren können Aktivitätsdiagramme als eine spezielle Art des Zustandsdiagramms, das ausschließlich Aktivitäten und Übergänge zwischen diesen zeigt, eingesetzt werden. Eine Aktivität ist einem Zustand zugeordnet und repräsentiert eine andauernde interne Aktion.

5. Zustandsmodellierung

Zielsetzung der Zustandsmodellierung im objektorientierten Bereich ist die Modellierung des dynamischen Verhaltens eines Systems. Wichtigstes Anwendungsgebiet ist die Modellierung des dynamischen Verhaltens von Objekten signifikanter ereignisgesteuerter Klassen. Solche Klassen spezifizieren im Allgemeinen "aktive" Objekte.

Das Verhalten von Objekten einer Klasse ist als Lebenszyklus zu abstrahieren und wird in einem Zustandsmodell modelliert. Das Zustandsmodell soll alle Zustände, die ein Objekt annehmen kann, die möglichen Zustandsübergänge, die Ereignisse, die Zustandsübergänge bewirken können, die Bedingungen, die neben den Ereignissen für einen Zustandswechsel erfüllt sein müssen, und die Aktionen, die infolge von Zustandsübergängen auszuführen sind, definieren.

Mit den Zuständen werden Datenwerte, die die Attribute eines Objekts einer Klasse annehmen können, und mögliche Verknüpfungen mit anderen Objekten festgelegt. Der Zustandsübergang, der für ein Objekt einer Klasse in einer konkreten Situation eintritt, ist eindeutig durch den Zustand, in dem sich das Objekt aktuell befindet, das eingetroffene Ereignis sowie spezifizierte Bedingungen bestimmt.

Ein Pfad in einem Zustandsmodell repräsentiert eine Folge von Ereignissen. Szenarios, die häufig während der Analyse zur Formulierung gewünschter Ereignisfolgen verwendet werden, müssen auf die Pfade der spezifizierten Zustandsmodelle abbildbar sein.

Strukturierte Analyse (SA)

Die strukturierte Analyse besteht aus der Kombination der Methoden:

1. Datenflussmodellierung

Ziel der "Datenflussmodellierung" ist es, die Funktionsstruktur eines Systems durch die kombinierte Betrachtung von Funktionen und Daten zu präzisieren. Die Datenflüsse bilden hierbei die Schnittstellen zwischen den Funktionen. Die Datenflussmodellierung abstrahiert von den physikalischen Gegebenheiten eines geplanten Systems.

In einem top-down-orientierten Vorgehen werden immer detailliertere Schichten des zukünftigen Systems spezifiziert. Ausgangspunkt ist ein Übersichtsdiagramm („Kontextdiagramm“), das lediglich die Datenflüsse des Systems von und zu seiner Umgebung wiedergibt. Bei der Verfeinerung des Datenflussmodells werden die in der Funktionshierarchie identifizierten Funktionen durch ein Datenflussdiagramm der entsprechenden Ebene verfeinert.

Ein Datenflussdiagramm einer bestimmten Hierarchie-Schicht lässt sich als ein Zusammenspiel von Prozessen darstellen, die über Datenflüsse in Verbindung stehen. Eine Verfeinerung auf der Daten-Seite wird stets in Abstimmung mit der entsprechenden Verfeinerung der Funktionshierarchie durchgeführt. Bei der Modellierung der Datenflüsse kommt es darauf an, eine logische innere Struktur des geplanten Systems zu finden, die stabil und unabhängig von Entwurfsentscheidungen und Hardware-Gegebenheiten ist.

2. Funktionsmodellierung

Die Funktionsmodellierung hat zum Ziel, schrittweise ein System zu zerlegen, beginnend bei der Sicht auf die Hauptfunktion eines Systems über die Zwischenebenen bis zur Ebene elementarer Funktionen. Auf einer Ebene wird jeweils von Details der darunter liegenden Ebene abstrahiert. Die Teilfunktionen zusammengenommen ergeben vollständig die aufgegliederte Funktion (Funktionshierarchie).

Formale Spezifikation

Die Formale Spezifikation ist eine Spezifikation nach strengen Regeln. Man unterscheidet zwei Klassen von formaler Spezifikation: die abstrakte Spezifikation (implementierungsneutral, Blackbox-Sicht, algebraische Spezifikation) und die modellbasierte Spezifikation, in der die Zustandsänderung des Systems aufgrund einer oder mehrer Operationen beschrieben wird (Beispiel ist die Z-Spezifikation). Ziel einer formalen Spezifikation ist eine knappe und präzise Darstellung mit der Möglichkeit, diese direkt in Code umzuwandeln. Eine Verifikationsmöglichkeit zur Fehlererkennung sowie ein Korrektheitsbeweis des Programms aufgrund der Spezifikation sind wünschenswert. Der Nachteil einer formalen Spezifikation ist die schwere und aufwändige Erstellung, die nur wenige Entwickler/Projektleiter überhaupt beherrschen, die Unverständlichkeit für den Kunden (d.h. sie kann nicht als Kommunikationsgrundlage verwendet werden) sowie die Begrenzung auf einige funktionale Anforderungen (z.B. mathematische Berechnungen). Da eine rein formale Spezifikation kaum realisierbar erscheint, ist eine Mischung aus formaler und halb- oder informaler Spezifikation das Optimum. Was formal spezifizierbar ist, soll damit beschrieben werden, der Rest wird über eine andere Spezifikationsvariante behandelt.