Inhalte dieser Lerneinheit

• Modellbegriff

• Zielmodelle

• UseCase Modelle

• Perspektiven Auf Anforderungen

• Anforderungsmodellierung in der Strukturperspektive

• Anforderungsmodellierung in der Verhaltensperspektive

Modellbegriff

Open

Eigenschaften von Modellen

• Abbild der Realität

• Verkürzung (Vereinfachung) der Realität

• Pragmatisierung der Realität

Konzeptuelle Modellierungssprachen

Modellierungssprachen zeichnen sich durch ihren Syntax und die Semantik aus.

Die Syntax einer Modellierungssprache legt die zu verwendenden Modellelemente fest und definiert die gültigen Kombinationen dieser Sprachkonstrukte.

Die Semantik definiert die Bedeutung der einzelnen Modellelemente und bildet damit die Basis für die Interpretation von konzeptuellen Modellen der jeweiligen Modellierungssprache.

Open

- UseCase Diagramm

Anforderungsmodelle

Die modellbasierte Anforderungsdokumentation basiert heute oft auf Basis der "Unified Modeling Language"Diese Modellsprache ermöglicht eine strukturierte Beschreibung von Anforderungen in jeder geforderten Perspektive.

Eine detailliertere Erklärung der UML hier auf Wikipedia:

https://de.wikipedia.org/wiki/Unified_Modeling_Language

- Übersicht der UML Diagramme

Vorteile von Anforderungsmodellen

In der Kognitionsforschung wurde nachgewiesen, dass bildhaft dargestellte Informationen schnellererfasst und besser memorisiert werden als Informationen, die in natürlicher Sprache dokumentiert sind (z.B. [Glass und Holyoak 1986]; [Kosslyn 1988] und [Mietzel 1998]). Diese Erkenntnisse lassen sich im Speziellen auch auf die Verwendung von Anforderungsmodellen übertragen.

Ein weiterer Vorteil der Verwendung von Anforderungsmodellen gegenüber natürlichsprachig formulierten Anforderungen liegt darin begründet, dass die den Anforderungsmodellen zugrunde liegenden Modellierungssprachen jeweils einen definierten Fokus haben.

Kombinierter Einsatz von Anforderungsmodellen und natürlicher Sprache

Die kombinierte Dokumentation von Anforderungen in natürlicher Sprache und durch Anforderungsmodelle ermöglicht es, die Vorteile beider Dokumentationsformen zu nutzen und gleichzeitig die spezifischen Nachteile des Einsatzes einer der beiden Dokumentationsformen abzuschwächen.

Zielmodelle

Ziele sind die Basis für die Definition von Anforderungen.

"Wer nicht weiss wohin er will, wird nie ankommen!"

Ziele beschreiben wo die Reise hingehen soll, Anforderungen konkretisieren die Ziele und ermöglichen diese in messbarer Weise zu dokumentieren.

- Zielfindungsprozess

Ziele sollen SMART formuliert werden:

• Spezifisch

• Messbar

• Erreichbar

• Realistisch

• Terminiert

8 Gebote der Zielformulierung

• Ziele sind lösungsneutral

• Ziele sind vollständig formuliert und wirtschaftlich begründet

• Ziele sind nachvollziehbar strukturiert

• Ziele sind operationalisiert

• Ziele sind priorisiert

• Ziele sind erweiterbar

• Ziele sind dokumentiert

• Ziele sind frei von Konflikten

Und- beziehungsweise Oder-Dekomposition von Zielen

Hinsichtlich der Dekompositionsbeziehungen zwischen Zielen in Und- Oder-Bäumen wird zwischen der Und-Dekomposition eines Zieles in Teilziele und der Oder-Dekomposition unterschieden. Bei der Und- Dekomposition muss jedes der Teilziele erfüllt werden, um das übergeordnete Ziel zu erfüllen. Im Gegensatz dazu muss bei der Oder- Dekomposition nur mindestens eines der Teilziele erfüllt werden, um das übergeordnete Ziel zu erfüllen.

- Und-/Oder-Dekomposition von Zielen

Use Cases

Wozu sind Use Case Diagramme geeignet?

Use-Case-Diagramme der UML [OMG 2007] (vgl.  Abschnitt  4.2.3)  sind leicht verständliche Modelle, die dazu dienen, aus einer Nutzungssicht die Funktionalitäten des betrachteten Systems, deren Beziehungen untereinander und die Beziehungen des Systems zu dessen Umgebung überblicksartig zu dokumentieren.

- Notationsübersicht Use Case Modell

Elemente des Use Case Diagramms

• Use Cases

• Akteure

• Systemgrenze

• Extend-Beziehung

• Include-Beziehung

Use Case

Ein Anwendungsfall (engl. use case) bündelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes fachliches Ziel (engl. business goal) zu erreichen. Er beschreibt, was inhaltlich beim Versuch der Zielerreichung passieren kann und abstrahiert von konkreten technischen Lösungen. Das Ergebnis des Anwendungsfalls kann ein Erfolg oder Fehlschlag/Abbruch sein.

Akteur

Ein Akteur bezeichnet in der UML ein Element, das mit dem modellierten System interagiert. Meistens steht er in Beziehung zu einem Anwendungsfall: es ist der Akteur, der einen Anwendungsfall anstößt oder der die erwarteten Resultate eines Anwendungsfalls entgegennimmt. Akteure sollten nicht mit konkreten handelnden Personen oder Systemen verwechselt, sondern eher als eine Art Rolle betrachtet werden. Kundenberater ist zum Beispiel als Name für einen Akteur besser geeignet als Herr Meier vom Verkauf.

Systemgrenze

Die Systemgrenzen innerhalb eines Use-Case-Diagramms separie- ren die Teile des Use Case, die zum System gehören, von den Teilen (Personen und Systemen), die außerhalb der Systemgrenze liegen. Optional kann der Name des Systems an den Systemgrenzen ange- geben werden.

Extend-Beziehung

Eine Extend-Beziehung («extend») von einem »Use Case A« zu einem »Use Case B« besagt, dass die in »Use Case A« enthaltene Interaktionsfolge die in »Use Case B« definierte Interaktionsfolge an einem definierten Punkt (Extension Point) erweitert. Diese Erweiterung ist abhängig vom Eintreten einer definierten Bedingung.

Include-Beziehung

Eine Include-Beziehung («include») von einem »Use Case A« zu einem »Use Case B« drückt aus, dass »Use Case A« in jedem Fall  die in »Use Case B« definierte Interaktionsfolge inkludiert.

- Beispiel Use Case Diagramm

Use Case Spezifikationen

Use-Case-Diagramme zeigen die aus einer externen Nutzungssicht wesentlichen Funktionalitäten des betrachteten Systems sowie spezifische Beziehungen der einzelnen Funktionalitäten untereinander bzw. zu Aspekten in der Umgebung des Systems. Abgesehen vom Namen eines Use Case und dessen Beziehungen dokumentieren Use-Case-Dia- gramme allerdings keinerlei weitere Informationen über die einzelnen Use Cases, wie z.B. die Systematik der Interaktion eines Use Case mit Akteuren in der Umgebung. Diese Informationen werden unter Ver- wendung einer geeigneten Schablone zusätzlich zum Use-Case-Dia- gramm textuell dokumentiert.

Attribute einer Use Case Spezifikation

• Bezeichnung

• Name

• Autoren

• Priorität

• Kritikalität

• Quelle

• Verantwortlicher

• Beschreibung

• Auslösendes Ereigniss

• Akteure

• Vorbedingung

• Nachbedingung

• Ergebnniss

• Hauptszenario

• Alternativszenario

• Qualiäten

- Beispiel aus Dokument "Systemanforderungen" Hermes 5

- Beispiel aus Buch Basiswissen Requirements Engineering

Perspektiven auf Anforderungen

In der modellbasierten Dokumentation von Anforderungen werden typischerweise die drei Perspektiven Struktur, Funktion und Verhalten unterschieden (vgl. Abschnitt 4.2.1). Jede Perspektive wird getrennt voneinander unter Verwendung geeigneter konzeptueller Modellierungssprachen dokumentiert [Davis 1993] und [Pohl et al. 2005]:

■     Strukturperspektive:

In dieser Perspektive werden z.B. die Struktur von Ein- und Ausgabedaten sowie die statisch-strukturellen Aspekte von Nutzungs- und Abhängigkeitsbeziehungen des Systems im Systemkontext dokumentiert.

■     Funktionsperspektive:

In dieser Perspektive wird dokumentiert, welche  Informationen aus dem Systemkontext durch das zu entwickelnde System bzw. dessen Funktionen manipuliert werden und welche Daten vom Sys- tem in den Systemkontext fließen.

■     Verhaltensperspektive:

In dieser Perspektive wird das System und dessen Einbettung in den Systemkontext zustandsorientiert dokumentiert, indem z.B. die Reaktion des Systems auf Ereignisse im Systemkontext, Bedingungen eines Zustandswechsels sowie Effekte dokumentiert werden, die das System in der Umgebung erbringen soll.

- Die drei Perspektiven und mögliche Diagrammformen

Klassendiagramm

Wozu sind Klassendiagramme geeignet?

Klassendiagramme der UML dienen zur Modellierung der Struktur- perspektive der Anforderungen eines geplanten Systems. Ein Klassendiagramm besteht aus einer Menge von Klassen und Assoziationen zwischen diesen Klassen. Klassen und Assoziationen in UML-Klassendiagrammen sind ähnlich den Entitätstypen und Beziehungstypen von Entity-Relationship-Diagrammen. Klassenmodelle besitzen aber im Ver- gleich zu Entity-Relationship-Diagrammen durch zusätzliche Modellelemente (z.B. solche, die es erlauben, die Operationen auf den Objekten dieser Klasse zu spezifizieren) eine größere Beschreibungsmächtigkeit.

- Notationsübersicht Klassendiagramm

- Modellierungsbeispiele aus Basiswissen Requirements Engineering

Übung Altersrente

https://www.ahv-iv.ch/Portals/0/Documents/Formulare/E-Formulare/318.370_d.pdf

Datenflussdiagramm

Wozu sind Datenflussdiagramme geeignet?

Im Mittelpunkt der Ansätze zur Anforderungsmodellierung in der Funktionsperspektive stehen Funktionsmodelle, die die Funktionalität des betrachteten Systems durch Funktionen, Datenspeicher, Daten-/ Informationsflüsse sowie Quellen und Senken in der Umgebung des Systems modellieren. Eine verbreitete Ausprägungsform von Funktionsmodellen sind Datenflussmodelle, wie sie z.B. in der strukturierten Analyse nach [DeMarco 1978] vorgeschlagen werden. Datenflussmodelle unterstützen zudem, das System in verschiedenen Abstraktions- ebenen zu modellieren.

- Notationselemente Datenflussdiagramm

Prozesse stellen notwendige Funktionen des betrachteten Systems dar, die die im System fließenden Daten4 (Informationsflüsse) transformieren. Ein Prozess konsumiert die Eingabedaten, verarbeitet diese Daten und gibt das Ergebnis der Verarbeitung in Form von Ausgabedaten weiter. Die Systematik, in der ein Prozess Daten transformiert, wird in Datenflussdiagrammen nicht betrachtet.

Datenspeicher sind abstrakte Konzepte, die dazu dienen, Daten im System persistent zu machen. Die Prozesse des Systems können dabei sowohl lesend als auch schreibend auf die Daten im Datenspeicher zugreifen, um die notwendigen Eingabedaten zu erhalten und wenn notwendig die erzeugten Ausgabedaten persistent abzulegen.

Terminatoren beschreiben Objekte (Personen, Personengruppen, Abteilungen, Organisationen oder Systeme) in der Umgebung des Sys- tems, die mit dem betrachteten System Informationen austauschen. Terminatoren sind Aspekte der Umgebung des Systems und können daher durch den Entwicklungsprozess nicht verändert werden (vgl. Abschnitt 2.1). Terminatoren werden als Quelle bezeichnet, wenn sie Daten an das System übergeben, und als Senke, wenn sie Daten vom System erhalten.

Ein Datenfluss beschreibt den Transport von Daten zwischen Prozessen, Datenspeichern und Terminatoren [Yourdon 1989]. In Anforderungsmodellen kann ein Datenfluss dabei den Transport sowohl von materiellen wie auch immateriellen Objekten modellieren, z.B. Informationsflüsse oder Materialflüsse. In Datenflussdiagrammen werden typischerweise nur die wesentlichen Datenflüsse modelliert und solche, die für die Anforderungen des Systems nicht relevant sind, vernachlässigt.

- Beispiel eines Datenflussdiagramms

Statecharts

Wozu eignen sich Statecharts?

Das Zustandsdiagramm (englisch state diagram) ist eine der 14 Diagrammarten der Sprache UML für Software und andere Systeme. Es stellt einen endlichen Automaten in einer UML-Sonderform grafisch dar und wird benutzt, um entweder das Verhalten eines Systems oder die zulässige Nutzung der Schnittstelle eines Systems zu spezifizieren.

Aktivitätsdiagramme

Wozu eignen sich Aktivitätsdiagramme?

Das UML-Aktivitätsdiagramm eignet sich zur Modellierung von Abläufen [OMG 2007]. Neben Aktivitätsdiagrammen der UML sind ereignisgesteuerte Prozessketten (EPK) [Keller et al. 1992] ein weitverbreiteter Ansatz zur Ablaufmodellierung – insbesondere für die Entwicklung von Informationssystemen. UML-Aktivitätsdiagramme betrachten den Kontrollfluss zwischen Aktivitäten bzw. Aktionen des Systems. Bei einer sequenziellen Abfolge von Aktivitäten/Aktionen wird eine Folgeaktivität dann ausgeführt, wenn die vorangegangene Aktivität/Aktion terminiert. Abbildung 6–12 zeigt wichtige Modellelemente von Aktivitätsdiagrammen der UML [OMG 2007].

- Notationselemente Aktivitätsdiagramm

- Beispiel eines Aktivitätsdiagramms

Aufgrund von Problemen, die bei der Verwendung endlicher Automaten in der Praxis auftraten (wie z.B. fehlende Möglichkeiten zur Abstraktion), wurden die Automatenkonzepte zur Modellierung des re- aktiven Verhaltens weiterentwickelt. Eine in der Praxis verbreitete Technik zur Modellierung des Verhaltens eines Systems stellen Statecharts [Harel 1987] dar. Bei Statecharts handelt es sich um ein Automatenkonzept, das auf endlichen Automaten beruht, diese allerdings um Möglichkeiten zur Hierarchisierung von Zuständen zur  Angabe von Bedingungen für Zustandsübergänge und um die Modellierung von Nebenläufigkeit erweitert. Abbildung 6–15 zeigt die Modellelemente von Statecharts in der von Harel vorgeschlagenen Notation [Harel 1987].

- Notationsübersicht

- Beispiel

Die in der UML verwendete Diagrammform ist eine Variante des Zustandsübergangsdiagramms. Neben dieser Diagrammform gibt es in der Informatik und der Telekommunikation weitere Formen, die sich nicht grundsätzlich, wohl aber in der Ausdrucksmächtigkeit unterscheiden.