en fr ger es

Tutorial - Requirements Model (German)

Die Modellierung der Anforderungen in UWE besteht aus zwei Teilen:

  • Anwendungsfälle der Anwendung und deren Beziehungen darstellen
  • Aktivitäten, welche die Anwendungsfälle detailliert beschreiben

Anwendungsfälle

Obwohl es wegen der Einfachheit dieses Beispiels nicht zwingend notwendig wäre, ist es dennoch in den meisten Fällen empfehlenswert zunächst einmal mit einem Anwendungsfälle zu beginnen. Dadurch lassen sich auf einfache Weise die wesentlichen Funktionalitäten unserers online Adressbuchs beschreiben: Der Benutzer soll Kontakte suchen und löschen können, er soll Kontakte erstellen oder ändern. Natürlich ermutigen wir Sie in Ihren Diagrammen weitere Funktionalitäten zu modellieren, dieses Tutorium beschränkt sich jedoch - der Übersichtlichkeit halber - auf die eben genannten.

In UWE unterscheidet man bei den Anwendungsfällen zwischen den Stereotypen «browsing» und «processing» um darzustellen, ob ein Anwendungsfall die persistente Datenbasis der Anwendung ändert oder nicht. So bekommt "SearchContacts", welcher das Suchen von Kontakten modelliert, den Stereotyp «browsing», da beim Suchen nur Daten gelesen bzw. dem Benutzer präsentiert werden. Die anderen Anwendungsfälle hingegen modellieren Datenänderungen und sind daher vom Stereotyp «processing».

Namen und Symbole der Stereotypen
browsingbrowsing processingprocessing
webUseCasewebUseCase
UWE solution modelled with MagicDraw

Aktivitäten

Da mit Anwendungsfällen alleine sehr wenig Informationen festgehalten werden können, kann jeder Anwendungsfall durch ein Prozessablauf genauer beschrieben werden. Damit lassen sich die Vorgänge innerhalb eines Anwendungsfalls sowie die dabei dem Benutzer präsentierten Daten und von ihm verlangte Eingaben modellieren.

Namen und Symbole der Stereotypen
userActionuserAction systemActionsystemAction
displayActiondisplayAction navigationActionnavigationAction
displayPindisplayPin interactionPininteractionPin

Zunächst können analog zu Prozessaktivitäten die beiden Stereotypen «userAction» und «systemAction» verwendet werden, wodurch Informationen zu Prozessen bereits während der Anforderungsanalyse festgehalten werden können. Der Stereotyp «userAction» wird für Benutzeraktionen auf der Webseite benutzt, die einen Prozessablauf anstoßen oder eine Antwort auf eine konkrete Informationsanforderung abfragen. Im Gegensatz dazu beschreibt «systemAction» die Aktionen, die das System ausführt. Beide Aktionstypen können über die Toolbar eingefügt werden.

Informationen über die verwendeten Datenstrukturen können durch Objektknoten und Aktionspins dargestellt werden, wobei die Objektknoten zur Darstellung der späteren Inhaltsklassen und die Pins zur Modellierung ihrer Attribute dienen.

Meist ist es außerdem sinnvoll bereits während der Anforderungsanalyse festzulegen, welche Daten in welcher Form und zu welchem Zeitpunkt präsentiert werden. Zur Darstellung von Präsentationsgruppen dient in UWE der Aktionsstereotyp «displayAction», während für die Ausgabe- und Eingabeelemente die beiden Stereotypen für Aktionspins «displayPin» und «interactionPin» definiert worden sind. Schließlich gibt es noch den Stereotyp «navigationAction», welcher dazu verwendet werden kann die Navigationsmöglichkeiten und die damit verbundenen Präsentationselemente zu modellieren.

Da diese Stereotypen immer dazu dienen während der Anforderungsanalyse die Elemente der Präsentation festzuhalten, können für sie außerdem RIA-Eigenschaften festgelegt werden und für alle Stereotypen können über die Eigenschaft "type" noch die Art des Elements spezifiziert werden.

Als Beispiel modellieren wir auf diese Weise zwei Prozessabläufe unserer Webanwendung Adressbuch. Zuerst betrachten wir die Aktivität zum Anwendungsfall "CreateContact". Hier sollte zunächst ein Formular dargestellt werden, welcher die Eingabe eines Namen, einer Emailadresse, jeweils zwei Adressen und Telefonnummern und das Hochladen einer Bilddatei ermöglicht. Dabei soll die Emailadresse während der Eingabe validiert werden und bei der Eingabe der Adressen sollen diese automatisch ergänzt werden. Dieses Formular soll dann vom Benutzer ausgefüllt und schließlich im System abgespeichert werden.

content diagram

Als zweiter Anwendungsfall wird "SearchContacts" verfeinert. Für diesen sind vor allem die Elemente der Darstellung von Interesse, weshalb wir uns auch auf diese beschränken. Hierbei besteht die Präsentation zunächst aus einem einfachen Formular zur Eingabe von Suchbegriffen und einem Knopf, welcher die Anzeige an die Suchbegriffe anpasst.

Der Hauptteil der Anzeige besteht jedoch aus einer Liste von Kontakten, welche durch die Aktion "Contacts" modelliert wird. Wie bei den Adressen und Telefonnummern gezeigt wurde, können darin präsentierte Elemente zusätzlich gruppiert werden, indem man für die Übergeordneten Aktionen eine Unterstruktur erstellt.

Die beiden durch die Aktionen des Stereotyps «navigationAction» modellierten Übergänge führen zu anderen Anwendungsfällen. Dies modellieren wir, indem die Aktionen als Verhalten die entsprechende Aktivität zugeordnet bekommt.

content diagram

Transformationen

Hat man ein Modell der Anforderungen erstellt, so ergeben sich zwei Möglichkeiten, wie diese Modellierung verwendet werden kann um die Entwicklung der weiteren Modelle (Content, Navigation, Presentation und Process) zu vereinfachen. Diese können zusätzlich zum auf den nächsten Seiten beschriebenen Vorgehensweisen angewandt werden:

  • Statt ein Modell mit dem dazugehörigen Diagramm manuell zu erzeugen, kann man es auch durch eine Transformation aus den Daten des Anforderungsmodells generieren lassen.
  • Ein bereits erzeugtes Modell kann außerdem erweitert werden, indem man neue Klassen aus dem Anforderungsmodell transformiert oder bestimmte modellabhängige Daten zu einer vorhandenen Klasse durch eine Transformation erzeugen lässt.

Weiter  page