Übung 02

Anforderungsanalyse

Software
Engineering

 Anforderungsspezi kation: Szenarien

Notationen
Natürliche Sprache

Use Case

Verhalten

Logik

User Story EX(EF p)

2
fi

 Use Cases
(Anwendungsfälle)

• Repräsentieren Anforderungen des Kunden

• Ausgangspunkt vieler objekt-orientierter Entwicklungsmethoden

• Verwendung während Analyse und Entwurf

 Use Cases

• UML:

• System

• Akteure

• Verhalten Akteuere und System

4
 “A use case is all the ways of using a system to achieve a
particular goal for a particular user.
Taken together the set of all the use cases gives you all of the
useful ways to use the system, and illustrates the value that it will
provide.”
-Ivar Jacobson

 Use Cases

• Reihe von Möglichkeiten für Akteure, mit dem System zu interagieren

• Sichtbare, quanti zierbare oder quali zierbare Auswirkungen auf jene

Dinge, die außerhalb des Systems liegen, im speziellen auf die Akteure

• Abgeschlossene, zusammenhängende Einheit als Teil der Funktionalität

des Systems

6
fi
fi
 Use-Case-Diagramm:
Elemente
• System
 Beispiel

• Akteur


• Use Case


• Assoziation Akteur-UC

Keine Ablaufbeschreibung

 Throwback: UML

• Formale (!!!) Technik

• Metamodell

8
 Akteur
• Rolle, die jemand (Person) oder etwas (System) einnimmt

• Durchaus mehrere Rollen einer Person / eines Objekts möglich

• Nicht Teil des Systems, sondern der -umgebung

• Interagieren mit System über Use-Cases

• Indem sie System benutzen (Ausführung initiieren)

• Indem sie vom System benutzt werden (Bereitstellen von Funktionalität)

9
 Akteur
• Werden durch Assoziationen mit UC
verbunden, d.h. sie interagieren mit dem
System

• Jeder Akteur muss mit mindestens einem

UC verbunden sein 

(sonst sinnlos)

• Assoziation ist binär, kann Multiplizitäten

aufweisen (nachrangig)

• Default: 0:1

10
 Use Case (Anwendungsfall)
• Beschreiben Verhalten das vom zu entwickelnden System erwartet wird

• Kundenwünsche und Analyse der textuellen Problemstellung

Ein Termin kann für einen oder mehrere

Teilnehmer von berechtigten Benutzern erfasst
werden. Alle Teilnehmer müssen über diesen
neuen Termin verständigt werden. Neue
Termine müssen sofort in allen geö neten, die
jeweiligen Teilnehmer betre enden, Kalendern
nachgezogen werden.

11
ff
ff
 Use Cases: <<include>>

• UC A (base) bindet UC (included) B

zwingend ein

• Keine explizite Reihenfolge

• B kann i.d.R. eigenständig

ausgeführt werden

12
Use Cases: <<include>>

13
 Use Cases: <<extend>>

• UC A (base) kann UC B (extending)

einbinden

• A entscheidet, ob B ausgeführt wird

• A und B können auch allein ausgeführt

werden

• Optional: Extension Points, Conditions

14
 Use Cases: <<extend>>

• Extension points im base

UC de niert

• Mehrere extension points

möglich (eindeutige
Namen)

15
fi
 Use Cases: Generalisierung

• B (sub) erbt Verhalten von A (base) und kann es

überschreiben

• B erbt alle Beziehungen

• B benötigt A (wegen Grundfunktionalität)

• B entscheidet, was von A ausgeführt und geändert

wird

16
 Use Cases: Generalisierung

• Optional: A ist abstrakt

• A kann nicht direkt

ausgeführt werden, nur B

17
 Akteure: Generalisierung

• B (sub) erbt von A (super)

• B kann mit allen UC von A in der Rolle

von A interagieren

• Mehrfachvererbung erlaubt

18
Akteure: Vererbung

19
 Hinweise zur Modellierung
• Nur relevante UC und Akteure
• Keine Zerlegung von UCs in
Teilschritte

• Eine Abstraktionsebene

• Keine Abläufe oder Prozesse!

20
 Use Cases: Textuelle Beschreibung

Für jeden UC:

• Beschreibung des Ablaufs

• Titel
• Nachbedingung Erfolg

• Kurzbeschreibung
• Nachbedingung Fehlschlag

• Akteure
• Anmerkungen

• Vorbedingungen
• Erweiterungen (optional)

• Auslösendes Ereignis
• Alternativen (optional)

21
 Included UC

Alternative für Teilschritt 3

Beschreibung Alternativablauf

https://docs.google.com/document/d/1d80apvdFutO1Ze6piDChy13H3jRMjKR1QDEy9N0m81I/edit
Die Verwaltung von Abgaben zu Übungsaufgaben soll durch ein System unterstützt werden. Zur Entwicklung des
Systems soll dessen Funktion erfasst werden. Folgende Anforderungen werden an das System gestellt:

Das System soll mehrere Kurse unterstützen. Die Administration eines Kurses, bspw. die Zuweisung von Lehrenden
zu einem Kurs, erfolgt durch einen Kursleiter. Lehrende erstellen die Aufgaben in einem Kurs und beurteilen die
Abgaben der Studierenden. Da mehrere Lehrende einem Kurs zugewiesen sein können, legt der Kursleiter fest,
welcher Lehrende welche Abgabe beurteilt. Der Leiter eines Kurses kann auch als Lehrender in dem Kurs tätig sein.
Studierende können Kurse belegen und Abgaben in das System hochladen. Beim Hochladen einer Abgabe muss
der Name und Matrikelnummer angegeben werden, andernfalls wird die Abgabe vom System nicht akzeptiert. Eine
erfolgreiche Abgabe wird vom System durch eine Meldung bestätigt. Eine Abgabe kann maximal einmal erfolgen.

Die Benutzer des Systems, d.h. die Kursleiter, Lehrenden und Studenten, können ihre Benutzerdaten verwalten
(z.B. die E-Mail-Adresse ändern), sich die Kurse und die dort gestellten Aufgaben als auch die Abgaben und
Bewertungen ansehen.

Das Anlegen eines Kurses am Beginn des Semesters und das Löschen eines Kurses am Ende des Semester
erfolgen durch einen Administrator. Beim Anlegen eines Kurses muss der Administrator dem Kurs einen Kursleiter
zuweisen. Nach dem Anlegen eines Kurses ist jedoch für den Administrator möglich, einen weiteren Kursleiter
hinzuzufügen oder einen bereits zugewiesenen Kursleiter zu entfernen. Am Ende des Semesters stellt der Kursleiter
die Zeugnisse aus.

Die Funktionalität zur Registrierung und Anmeldung (Login) eines Benutzers muss nicht vom System unterstützt
werden. 23
Die Verwaltung von Abgaben zu Übungsaufgaben soll durch ein System unterstützt werden. Zur Entwicklung des
Systems soll dessen Funktion erfasst werden. Folgende Anforderungen werden an das System gestellt:

Das System soll mehrere Kurse unterstützen. Die Administration eines Kurses, bspw. die Zuweisung von Lehrenden
zu einem Kurs, erfolgt durch einen Kursleiter. Lehrende erstellen die Aufgaben in einem Kurs und beurteilen die
Abgaben der Studierenden. Da mehrere Lehrende einem Kurs zugewiesen sein können, legt der Kursleiter fest,
welcher Lehrende welche Abgabe beurteilt. Der Leiter eines Kurses kann auch als Lehrender in dem Kurs tätig sein.
Studierende können Kurse belegen und Abgaben in das System hochladen. Beim Hochladen einer Abgabe muss
der Name und Matrikelnummer angegeben werden, andernfalls wird die Abgabe vom System nicht akzeptiert. Eine
erfolgreiche Abgabe wird vom System durch eine Meldung bestätigt. Eine Abgabe kann maximal einmal erfolgen.

Die Benutzer des Systems, d.h. die Kursleiter, Lehrenden und Studenten, können ihre Benutzerdaten verwalten
(z.B. die E-Mail-Adresse ändern), sich die Kurse und die dort gestellten Aufgaben als auch die Abgaben und
Bewertungen ansehen.

Das Anlegen eines Kurses am Beginn des Semesters und das Löschen eines Kurses am Ende des Semester
erfolgen durch einen Administrator. Beim Anlegen eines Kurses muss der Administrator dem Kurs einen Kursleiter
zuweisen. Nach dem Anlegen eines Kurses ist jedoch für den Administrator möglich, einen weiteren Kursleiter
hinzuzufügen oder einen bereits zugewiesenen Kursleiter zu entfernen. Am Ende des Semesters stellt der Kursleiter
die Zeugnisse aus.

Die Funktionalität zur Registrierung und Anmeldung (Login) eines Benutzers muss nicht vom System unterstützt
werden. 24
Die Verwaltung von Abgaben zu Übungsaufgaben soll durch ein System unterstützt werden. Zur Entwicklung des
Systems soll dessen Funktion erfasst werden. Folgende Anforderungen werden an das System gestellt:

Das System soll mehrere Kurse unterstützen. Die Administration eines Kurses, bspw. die Zuweisung von Lehrenden
zu einem Kurs, erfolgt durch einen Kursleiter. Lehrende erstellen die Aufgaben in einem Kurs und beurteilen die
Abgaben der Studierenden. Da mehrere Lehrende einem Kurs zugewiesen sein können, legt der Kursleiter fest,
welcher Lehrende welche Abgabe beurteilt. Der Leiter eines Kurses kann auch als Lehrender in dem Kurs tätig sein.
Studierende können Kurse belegen und Abgaben in das System hochladen. Beim Hochladen einer Abgabe muss
der Name und Matrikelnummer angegeben werden, andernfalls wird die Abgabe vom System nicht akzeptiert. Eine
erfolgreiche Abgabe wird vom System durch eine Meldung bestätigt. Eine Abgabe kann maximal einmal erfolgen.

Die Benutzer des Systems, d.h. die Kursleiter, Lehrenden und Studenten, können ihre Benutzerdaten verwalten
(z.B. die E-Mail-Adresse ändern), sich die Kurse und die dort gestellten Aufgaben als auch die Abgaben und
Bewertungen ansehen.

Das Anlegen eines Kurses am Beginn des Semesters und das Löschen eines Kurses am Ende des Semester
erfolgen durch einen Administrator. Beim Anlegen eines Kurses muss der Administrator dem Kurs einen Kursleiter
zuweisen. Nach dem Anlegen eines Kurses ist jedoch für den Administrator möglich, einen weiteren Kursleiter
hinzuzufügen oder einen bereits zugewiesenen Kursleiter zu entfernen. Am Ende des Semesters stellt der Kursleiter
die Zeugnisse aus.

Die Funktionalität zur Registrierung und Anmeldung (Login) eines Benutzers muss nicht vom System unterstützt
werden. 25
Die Verwaltung von Abgaben zu Übungsaufgaben soll durch ein System unterstützt
werden. Zur Entwicklung des Systems soll dessen Funktion erfasst werden. Folgende
Anforderungen werden an das System gestellt:

Das System soll mehrere Kurse unterstützen. Die Administration eines Kurses, bspw. die
Zuweisung von Lehrenden zu einem Kurs, erfolgt durch einen Kursleiter. Lehrende
erstellen die Aufgaben in einem Kurs und beurteilen die Abgaben der Studierenden. Da
mehrere Lehrende einem Kurs zugewiesen sein können, legt der Kursleiter fest, welcher
Lehrende welche Abgabe beurteilt. Der Leiter eines Kurses kann auch als Lehrender in
dem Kurs tätig sein. Studierende können Kurse belegen und Abgaben in das System
hochladen. Beim Hochladen einer Abgabe muss der Name und Matrikelnummer
angegeben werden, andernfalls wird die Abgabe vom System nicht akzeptiert. Eine
erfolgreiche Abgabe wird vom System durch eine Meldung bestätigt. Eine Abgabe kann
maximal einmal erfolgen.

Die Benutzer des Systems, d.h. die Kursleiter, Lehrenden und Studenten, können ihre
Benutzerdaten verwalten (z.B. die E-Mail-Adresse ändern), sich die Kurse und die dort
gestellten Aufgaben als auch die Abgaben und Bewertungen ansehen.

Das Anlegen eines Kurses am Beginn des Semesters und das Löschen eines Kurses am
Ende des Semester erfolgen durch einen Administrator. Beim Anlegen eines Kurses muss
der Administrator dem Kurs einen Kursleiter zuweisen. Nach dem Anlegen eines Kurses
ist jedoch für den Administrator möglich, einen weiteren Kursleiter hinzuzufügen oder
einen bereits zugewiesenen Kursleiter zu entfernen. Am Ende des Semesters stellt der
Kursleiter die Zeugnisse aus.

Die Funktionalität zur Registrierung und Anmeldung (Login) eines Benutzers muss nicht
vom System unterstützt werden. 26
 Textuelle Beschreibung
UC: Abgabe hochladen

Studierende können Kurse belegen und Abgaben

in das System hochladen.

Beim Hochladen einer Abgabe muss der Name

und Matrikelnummer angegeben werden,
andernfalls wird die Abgabe vom System nicht
akzeptiert.

Eine erfolgreiche Abgabe wird vom System durch

eine Meldung bestätigt.

Eine Abgabe kann maximal einmal erfolgen.

Bemerkung: Für eine vollständige Spezi kation ist

eine textuelle Beschreibung aller UC erforderlich!

27
fi
 Anforderungsspezi kation: Szenarien
Notationen
Natürliche Sprache

Use Case

Verhalten

Logik

User Story EX(EF p)

28
fi

 Computation Tree Logic

Transitionssystem, Zustände mit atomaren Propositionen. zo=1st

29
 Computation Tree Logic

• Aufklappen als Baum

• Unendlicher, gerichteter Baum

• (Zustand, Tiefe im Baum)

30
 Computation Tree Logic
• NeXt, in the next state

• Future, eventually in the

Sei p eine atomare Aussage und ϕ, ψ CTL Formeln,
future

Y ∈ {A, E}, Z ∈ {G, F, X}. Dann ist auch


• Globally, always
ϕ′ := ⊥ | ⊤ | p | ( ¬ϕ) | (ϕ ∧ ψ) | (ϕ ∨ ψ) | (ϕ → ψ)

• Until
| YZϕ | Y[ϕUψ] 



• Alle Pfade
eine CTL Formel.

• Ein Pfad

31
 Computation Tree Logic

Auswertung einer Formel (auch Query, Property) ausgehend von der Wurzel
des Baumes (also Anfangszustand des Transitionssystems)

32
Computation Tree Logic
EX p

There Exists a path

where p holds in the
neXt state

33 Bäume sind unendlich groß

Computation Tree Logic
AX p

Along All paths, p

holds in the neXt state

34 Bäume sind unendlich groß

Computation Tree Logic
EF p

There Exists a path

where p holds at some
state in the Future

35 Bäume sind unendlich groß

Computation Tree Logic
AF p

Along All paths, p

holds at some state in
the Future

36 Bäume sind unendlich groß

Computation Tree Logic
EG p

There Exists a path

where p holds Globally

37 Bäume sind unendlich groß

Computation Tree Logic
AG p

Along All paths, p

holds Globally

38 Bäume sind unendlich groß

Computation Tree Logic
E[pUq]

There Exists a path

where p holds Until q
holds

39 Bäume sind unendlich groß

Computation Tree Logic
A[pUq]

Along All paths, p

holds Until q holds

40 Bäume sind unendlich groß

 Computation Tree Logic
• It is always the case that the airbag is deployed after a crash

• AG(c → AXa)

• Whenever a message is sent, it will eventually be acknowledged

• AG(m → AFr)

• It is possible to get to a state where started holds, but ready does not hold

• EF(started ∧ ¬ready)
41
 Computation Tree Logic

Weitere Infos:

• Forschung (Safe.Spec)

• Lehre (Softwareveri kation, Prof. Schlinglo )

42
fi
ff
Bitte begründet eure Lösungen

43