Softwareanforderungsanalyse Modellierung des Verhaltens des Systems Burkhardt Renz

(1)

Softwareanforderungsanalyse

Modellierung des Verhaltens des Systems

Burkhardt Renz

THM, Fachbereich MNI

Wintersemester 2018/19

(2)

Das Modell des Verhaltens im Kontext der Modellierung

SafeTransportation

SpeedLimited NoCollision DoorsClosed WhileMoving Goal model

Train On Block 0..1

Platform At

Object model Concern

Obstacle model NoStopAtSignal

Obstruction

Tracking

System Train

Controller Speed, Position Agent model Responsibility

Operation model Compute Acceleration

Send Acceleration

TrainController Tracking

System Operationalization

Behavior model Movement State

Closed Open

opening

[TimeOut] [AtPlatform]

Stopped Moving

start [doorsClosed]

Doors State Train

Controller Passenger

Opening entrance Closing

Start Stop

...

Coverage

Quelle: Lamsweerde, S. 291

(3)

Übersicht

Modellierung des Verhaltens von Instanzen Szenarien mit Sequenzdiagrammen der UML Verfeinerung von Szenarien

Modellierung des Verhaltens von Klassen Vorgehen bei der Modellierung des Verhaltens

(4)

Das Modell des Verhaltens des Systems

Dynamik des Systems

Verlangtes Verhalten von Akteuren in Form von zeitlichen Folgen von Zustandsübergängen für die Variablen, die sie steuern.

dargestellt durch Sequenzdiagramme und Zustandsdiagramme der UML.

Verwendung des Modells

Untersuchung des Verhaltens von Instanzen: Szenarienfür Ermittlung, Validierung und Erläuterung von Anforderungen, zum Herausfinden von Testdaten

Untersuchung der Zustandsübergange eines Typs von Akteur:

Zustandsautomatenfür Animation, Model Checking und Generierung von Code

(5)

Szenarien

Szenario = zeitliche Folge von Interaktionen zwischen Instanzen von Akteuren

Positive Szenarien:

demonstrieren in einem Beispiel, wie Ziele durch das Zusammenwirken von Akteuren erreicht wird

können auch Ausnahmefälle darstellen NegativeSzenarien:

demonstrieren in einem Beispiel, wie ungewünschte

Situationen entstehen, zeigen als beispielhafte Abläufe, die zu Hindernissen führen

Darstellungsmittel: Sequenzdiagramme der UML

(6)

Beispiel eines Sequenzdiagramms (Zugsteuerung)

: Train

Actuator/Sensor : OnBoard

Controller

doorsOpening

exit doorsClosing

p1: Passenger

entrance p2: Passenger

software agent instance

environment agent

time interaction

event name

! trainStopped

startAcceler

Quelle: Lamsweerde S. 451

(7)

Beispiel eines Sequenzdiagramms (Bibliothek)

: LoanManager

BookRequest (PatrID, BookID) : Staff

self-interaction event attributes

instance disappears : CopyManager

LoanQtyOK? (PatrID) CpyAvailable? (BookID)

Reserved? (BookID) OK-Available (CopyID)

OK-Book (PatrID, CopyID) checkOut (PatrID, CopyID) Registered? (PatrID)

Quelle: Lamsweerde S.452

(8)

Verfeinerung von Szenarien

Episoden

Teile von Interaktionsfolgen, die Subziele erreichen, werden in Episoden zusammengefasst und können in anderen Szenarien referenziert werden

Verfeinerung von Akteuren

Verfeinerung von Akteuren führt auch dazu, dass die Szenarien, in denen sie beteiligt sind verfeinert werden

(9)

Einführung einer Episode

:Scheduler

meetingRequest (dateRange, withWhom) : Initiator

reference to another diagram : Participant

schedule Determination ConstraintsAcquired

notification (date, location)

:Scheduler

? constraints (dateRange)

: Participant

OK-constr

! constraints sd ConstraintsAcquired episode

OK-request

(10)

Verfeinerung von Akteuren

: LibraryManager BookRequest

(PatrID, BookID) : Staff

RequestOK?

(PatrID, BookID) OK -Book

(PatrID, CopyID)

: LoanManager : Staff

: CopyManager

CpyAvailable? (BookID)

Reserved?

(BookID) OK-Available (CopyID)

checkOut (PatrID,CopyID) BookRequest

(PatrID, BookID)

OK-Book (PatrIDCopyID)

LoanQtyOK? (PatrID) Registered? (PatrID)

(11)

Übersicht

Modellierung des Verhaltens von Instanzen Modellierung des Verhaltens von Klassen

Zustandsautomaten mit Zustandsdiagrammen der UML Verfeinerung des Zustandsdiagramms

Vorgehen bei der Modellierung des Verhaltens

(12)

Zustandsautomaten

In Szenarien war der Zustand implizit, im Zustandsautomaten wird er explizit

Erfasst das Verhalten eines Typsvon Akteueren, nicht nur Beispiele

Erfasst alle möglichen Zustandsübergänge – deshalb systematischer als Szenarien

Konzept: Schnappschuss – Ereignisse verändern den Zustand Ein Zustandsautomat pro Zustandsvariable oder

zustandsbehaftetem Objekt – die Ereignisse lösen

Veränderungen am Zustand durch die steuernden Akteure aus Darstellungsmittel: Zustandsdiagramm der UML

(13)

Beispiel für das Konzept des Zustandsdiagramms

Available onLoan

checkOut(PatrID, self)

return(PatrID, self)

event with attribute

loss SM state

initial state final state

transition

(14)

Beispiel mit Aktionen und Bedingungen

doorsClosed doorsOpen

doorsOpening

doorsClosing [Speed = 0 and AtPlatform]

/ Display terminalInfo

/ Activate warningRinging action

guard

(15)

Beispiel mit Aktion im Zustand

OK- request

…

ConstraintsRequested

entry / Inform Initiator Planning

Resolving

[all available]

[conflicts]

weakeningRequest

ValidatingMeetingData

…

entry action

(16)

Verfeinerung des Zustandsdiagramms durch Unterzustände

Stopped Moving

include / movingSubstates [Speed = 0]

Accelerating Decelerating

(a)

AccelerComnd [Acceler 0]

movingSubstates

[Acceler 0]

AccelerCommand AccelerComnd

[Acceler > 0]

startAcceler [Acceler > 0]

Stopped

[Speed = 0]

startAcceler [Acceler 0]

Moving Accelerating

Decelerating AccelerComnd

[Acceler " 0]

(b) reference

sequential substate initial substate

>

> >

>

≤

(17)

Verfeinerung des Zustandsdiagramms durch parallele Zustände

TrainInfoState

DoorsState MovementState

parallel composition

state name composite state

Stopped

[Speed = 0]

startAcceler [doorsState = closed]

AccelerComnd [Acceler > 0]

Moving Accelerating

Decelerating AccelerComnd [Acceler 0]

AccelerComnd [Acceler > 0]

[Speed = 0 and AtPlatform]

doorsOpening / Display terminalInfo

doorsClosing / Activate warningRinging TrainInfoState

DoorsState MovementState

sequential substate

concurrent substate

guard as synchronizing

condition + sequential

decomposition

≤

(18)

Übersicht

Modellierung des Verhaltens von Instanzen Modellierung des Verhaltens von Klassen Vorgehen bei der Modellierung des Verhaltens

Relevante Szenarien finden

Von Szenarien zu Zustandsautomaten Von Szenarien zu Zielen

Von der Operationalisierung von Zielen zu Zustandsautomaten

(19)

Ziele, Szenarien und Zustandsautomaten ergänzen sich

Ziele

deklarativ, etwas abstrakt?

funktional und nicht-funktional aber: implizites Verhalten

Szenarien

konkret, leicht nachvollziehbar, explizites Verhalten

ideal zur Diskussion mit Anwendern und Finden von Testdaten aber: partiell, beispielhaft

Zustandsautomat

explizite Zustände, Ziele aber implizit vollständig und verifizierbar

aber: schwerer zu entwickeln

(20)

Relevante Szenarien finden

Alle Paare interagierender Akteure systematisch untersuchen Wieweit ist das System durch positive Szenarien beschrieben?

Gibt es noch weitere?

Auch an Hindernisse, d.h. negative Szenarien denken

Auch an Szenarien denken, die beim Start oder beim Ende des Einsatzes stattfinden (sollen)

Gibt es denkbare Ereignisse, zu denen kein Szenario untersucht wurde?

(21)

Von Szenarien zu Zustandautomaten

Szenarien enthalten Zustand nur implizit

Durchgehen des Szenarios und Festhalten der (potenziellen) Werte von Zustandsvariabeln im Verlauf

Generalisierung zu einem Zustandsautomat durch Perspektivwechsel:

nicht mehr den zeitlichen Ablauf im Augenmerk

sondern die Pfade der Veränderung der Zustandsvariablen Zusammenführen der Pfade zu einem Zustandautomaten

(22)

Von Szenarien zu Zielen

Fragen an Szenearien stellen: Warum?,Warum nicht?

Positive Szenarien enthalten in der Regel Verhaltensziele vom TypAchieve oder Maintain

NegativeSzenarien enthalten in der Regel Ziele vom Typ Avoid

(23)

Von der Operationalisierung von Zielen zu Zustandsautomaten – Beispiel

Safe

Entry&Exit DoorsStateClosed If NonZeroMeasuredSpeed NoDelay

AtPlatform

Open Doors Close

Doors Start

Train

MovementState ReqTrig trs opening timeout has elapsed

ReqPre tr.Position is a platform position ReqPre tr.Speed = 0 ReqPre tr.doorsState = closed

DomPre tr.Speed = 0 DomPost tr.Speed ! 0

opening

[TimeOut]

[AtPlatform and Speed = 0]

Stopped Moving

startAcceler [doorsState = closed]

DoorsState

DomPre tr.doorsState = closed DomPost tr.doorsState = open

….