Modelle
Allgemeines
Bevor ein Softwaresystem gebaut wird, werden Modelle erstellt, mit welchen das System aus unterschiedlichen Blickwinkeln beleuchtet wird. Ein Modell ist ein Abbild einer konkreten Sache in vereinfachter Form, mit dem Ziel etwas zu veranschaulichen und zu einem besseren Verständnis beizutragen. Modelle oder einzelne Ausschnitte davon können mit einzelnen Diagrammen grafisch repräsentiert werden.
Diagramme
Diagramme haben gegenüber von reinem Text den Vorteil, dass sie den Konzepter zu einer gewissen Systematik zwingen. Das nachfolgende Beispiel zeigt ein vereinfachtes Beispiel eines kostenpflichtigen Internet-Downloads. Die Downloadseite wird nur angeboten, wenn der Benutzer gültige Kreditkartenangaben eingegeben hat, andernfalls kann der Benutzer die Angaben korrigieren. Mit Hilfe des Diagramms stellt man rasch fest, dass hier eine Abbruchmöglichkeit in der Aktivität "Kreditartenangaben erfassen" notwendig ist.
Die im vorliegenden Vorgehensmodell verwendeten Modelle stammen aus RUP, ebenso die Diagramme, welche ihrerseits auf UML basieren.
Siehe auch: Diagramme (Übersicht).
Modelle
RUP basiert vollständig auf sog. Modellen. Diese beleuchten jeweils einen Aspekt des Systems. Die nachstehende Abbildung zeigt auf, welche Modelle in welchen Phasen entwickelt werden müssen.
Auslöser jedes Projekts ist ein Bedürfnis. Im Rahmen der Voranalyse wird versucht, dieses Bedürfnis im Rahmen einer Vision zu erfassen. Dabei werden Ziele formuliert und ein möglichst reales, u.U. exemplarisches Bild einer möglichen Endlösung formuliert. Um das Kundenproblem besser verstehen zu können wird zudem ein grobes Prozessmodell modelliert.
Das Schwergewicht der Phase Konzept ist die strukturierte Ermittlung der Systemanforderungen, deren wichtigster Teil das sog. "Use-Case-Modell" sowie Dialog- und Report-Design sind. Use-Cases (Anwendungsfälle) beschreiben aus Sicht eines jeden Benutzertyps, was das System tun muss, um einen bestimmten Anwendungsfall zu erledigen. Anschliessend wird ein Analyse-Modell erstellt, welches einerseits eine Beschreibung der notwendigen Fachklassen (objektorientierte Weiterführung von Entitätstypen) und anderseits aus sog. "Use-Case-Realisierungen" besteht. Letztere zeigen auf, welcher Use-Case mit Hilfe welcher Fachklassen realisiert werden können[1]. Für kritische Teilsysteme[2] wird nun nach Möglichkeit eine erste Programmversion realisiert. Dafür müssen vorgängig ein Design-Modell, ein (physisches) Datenmodell sowie ein Deployment-Modell erarbeitet werden. Die wichtigsten Sichten dieser Modelle werden anschliessend in der Systemarchitektur zusammengefasst.
In der Phase Realisierung wird nun das sog. Systemdesign entwickelt. Es ist der technische Bauplan für die nachfolgende Realisierung. In dieser Phase werden die bereits in der Phase Konzept begonnen Modelle (Design-Modell, Datenmodell, Deployment-Modell) fertig gestellt. Die wichtigsten Ergebnisse werden anschliessend in der Systemarchitektur nachgeführt. Ebenso werden Funktionen zum Test des Systems realisiert und im Test-Modell zusammengefasst. Basierend auf dem Systemdesign wird in der Folge das System programmiert und getestet.
Beachte:
1) Die obige Grafik zeigt nur den Zusammenhang der einzelnen Modelle und ignoriert alle anderen Aspekte (wie z.B. Einführung, Schulung etc). Sie beschränkt sich daher auch auf die 3 Phasen Voranalyse, Konzept und Realisierung.
2) Das Prozessmodell sowie das Use-Case-Modell müssen sprachlich vollständig in der Sprache abgefasst sein. Erst die nachfolgenden Modelle sind "Baupläne" für Informatiker.
3) Was man aus obiger Grafik ablesen kann, ist das Use-Case-Modell der Ausgangspunkt sämtlicher Modelle. Diese Abhängigkeit ist ein wesentliches Merkmal des vorliegenden Vorgehensmodells. Siehe auch: Grundsatz "Use-Case Zentrierung"
4) Die Systemarchitektur hat eine ähnliche Aufgabe wie das Use-Case-Modell, von welchem sie primär abgeleitet ist. Aus Kosten/Nutzen-Gründen beeinflusst die Systemarchitektur aber auch das Use-Case-Modell. Siehe auch Grundsatz „Architektur Zentrierung“.