© 2010- 2011 GooBiz.com Agile System Modeling using UML and SysML How to assure MRD - PSD traceability and deal with changes using a Goal-Driven Modeling

© 2010- 2011 GooBiz.com

Agile System Modeling using UML and SysML

How to assure MRD - PSD traceability and deal with changes using a Goal-Driven Modeling ?

An ‘MP3 Player’ Case Study…

To visualize presentation slides, please use the full screen mode and click to progress

©2010 – 2014 Birol Berkem - GooBiz.com

(*) MRD : Marketing Requirement Document

PSD : Product Specification Document

http://creativecommons.org/licenses/by-sa/3.0/us/

© 2010- 2011 GooBiz.com

Main Steps of the System Development Life Cycle(Exemple : using Harmony from IBM / Telelogic)

…or using RUP or Scrum Methods to Gather Requirements

Example of Scrum’s User Story : « As a Listener of an MP3 Audio-Player System, I would like to Listen Audio and Record Audio with satisfaction »

uc V1- Operate Audio Player

MP3-Audio PlayerOperations

Listener

Listen Audio

Record Audio

The underlying system requirements for the MP3 Player are :

How to apply these methods to gather and structure requirements in order to deal with changes ? 3

Step 1. Compose hierarchically business requirements (1) and system

requirements (2) that refine them

Step 2. Derive system functions (3) that satisfy these requirements and use cases that invoke system functions

Step 3. Model how system functions are triggered in the Product Life Cycle ?

Step 4. Establish Test Cases on the basis of Use Case Scenarios that realize System Functions

• (1) Business Requirement : A needed achievement and the quality measures expressed in terms of broad outcomes the business requires.

• (2) System Requirement : A condition or capacity required by a user from the system in order to fulfill the business requirements (the goal).

• (3) System Function : Action requested from a product or realized by itself to partially satisfy a requirement

4

Main Steps to « Smartly Gathering Requirements »

Let’s look at each step on the same case study…

Requirements and

SystemAnalysis

4

custom Audio Player Initial System Requirements

«Functional»The audio player must allow user to adjust the volume as well as to set the « surround » function along with "play"

or "pause" functions.

tagsid = REQ022

(from Functional Requirements)

The Surrounding function must be available while the Audio Player is set to Player, to Pause or to Adjust volume

tagsid = REQ022.2


The Adjust Volume function must be available while the Audio Player is set to Play, to Pause or to Surrounding

tagsid = REQ022.1


The Surrounding User Interface must support categories like : karaoké, disco, live, studio, matrice, echo

tagsid = REQ445


The Play User Interface must support categories like : recently played, by author, by type, by year

tagsid = REQ443


«business requirement»V1- Satisfy the customer by offering a very

operational product with a user friendly interface

(from Business Requirements)

«refine» «refine»

«refine»«refine»

«deriveReqt»

Step 1 - Compose hierarchically business and system requirements to better manage impact analysis when requirements evolve

Business Requirement : A need and the quality measures

expressed in terms of broad outcomes the business requires

System Requirement : A condition or capacity required from the system in order to fulfill the business requirements

Functional Boundary of the System under discussion

5How to assign these requirements to system functions ? (cf. next)

req Initial System Requirements assigned to Functions

Player Functions

The Surrounding function must be available while the Audio Player is set to Player, to Pause or to Adjust volume

tagsid = REQ022.2


The Adjust Volume function must be available while the Audio Player is set to Play, to Pause or to Surrounding

tagsid = REQ022.1


The Play User Interface must support categories like : recently played, by author, by type, by year

tagsid = REQ443


«service»Surround«service»

Play

«service»Record

«service»Player

Controler

«service»Adjust Volume

The Surrounding User Interface must support categories like : karaoké, disco, live, studio, matrice, echo

tagsid = REQ445


Before Recording Audio is started, the Play function must be disabled


Whenever Recording Audio is stopped, the Play function must be enabled


«satisfy»

«satisfy»

«satisfy»

«include»

«include»

«include» «include»

«satisfy»

«satisfy» «satisfy»

Step 2 – Formalize the System Boundary by assigning requirements to system functions

System Functions : Actions requested from a product or realized by itself to satisfy partially a user requirement

6How to capture the internal behaviors of the ‘Player Controler’ function ?

7

stm StateMachine

TURNED ON

+ on userinput/send ecouteur.beep

SURROUNDING

RECORDING

PLAYING

WAITING FOR UI_EVENT

+ do / wait

Initial_StateMachine_MP3

PAUSE

+ do / wait

refPLAY

refSurround

TURNED OFF

Synchjoin_surrounding

Initial_surround

surr_and_wait surround_and_play

Initial_play_record

DELAYING

turn on/sendtscr.lightOn

record/sendbutton.disable(play)

pause

play/sendbutton.disable(record)

after (15s)/sendtscr.lightOff

surround

stop/sendrecorder.save(voice),sendbutton.enable(play)

end_surround

stop/sendbutton.enable(record)

play

surround

after(0.5s)

turn off/sendtscr.lightOff

pause

Step 3 – Model states and transitions of the ‘Player Controler’ function to better understand its internal behaviors

by clicking on the « Surrounding » state we

will specify how the « Surrounding function »

is used (slide 9)

In each state a system function is

triggered by the Player Controler

Now …how to specify usage of these functions by the Actors of the system ?

uc V1-Operate Audio Player (Solution)

Player Functions

MP3-Audio Player Operations

Listener

Listen Audio

Record Audio

«service»Power On

«service»Record

«service»Play

«service»Pause

«service»Adjust Volume

«service»Surround

Scenarios : Surround Scenario

Scenarios : Listen Audio Scenarios

«include»«include»

«extend»

«include»

«include»

«extend»

«include» «extend»«extend»

«extend»

«extend»

Step 4.1 – Determine first how Use Cases invoke System Functions

The Audio Player Functions are based on the previous

system requirements

A base Use Case that processes the actor’s

interactions with the system functions

8How are these functions invoked within Use Case Scenarios ? (see next slide)

9

Step 4.2 – …then elaborate UC Scenarios that invoke System Functionssd Listen Audio Scenarios

listener :Listener

mp3device:Portable Audio

Player

refIdle

par

refPause

refIdle

alt

[Idle]

[Playing]

[Pause]

refOptions (Surround)

alt

[AdjustVolume]

[Idle]

alt surr. and idle

[Surround]

[Idle]

refIdle

loop for selection

[while mp3device is not turned_off]

refTurn off

refTurn On

Use Cases :V1-OperateAudio Player (Solution Proposée)

UML Sequence Diagram that illustrates Scenarios within the Use Case " Listen Audio "

refAdjust Volume

refPlay

Actor / System Interactions formalize invocation scenarios of system functions in the UC

« Listen Audio »

This Surround scenario will be available just by a simple click

on this (see next slide)

Actor / System interactions for the ‘Surrounding’ Scenario (cf.next)

sd Surround Selection

l istener :Listener


Player

«Enumeration»{karaoké, disco, live, studio, matrice, echo}

«Enumeration»{surrounding, parameters, equalizer}

Use Case : LISTEN AUDIO

parallel tasks

THE " SURROUND " SCENARIO : ACTOR / SYSTEM INTERACTIONS

par resound and display_ok

press(options)

display(options menu)

selectsurround()

display(list of surrounds)

selectsurround_type()

activate(selected_surround_type)

display(ok)

provide(selected_surround_type)

sd Surround Selection

l istener :Listener


Player

«Enumeration»{karaoké, disco, live, studio, matrice, echo}

«Enumeration»{surrounding, parameters, equalizer}

Use Case : LISTEN AUDIO

parallel tasks

THE " SURROUND " SCENARIO : ACTOR / SYSTEM INTERACTIONS

par resound and display_ok

press(options)

display(options menu)

selectsurround()

display(list of surrounds)

selectsurround_type()


display(ok)


Steps 4.3/4.4 – Describe each Scenario and deduce behaviors of the related System Function

Actor / system interactions describe

the black box test case for the « Surround »

function.

These Messages become operations to

test this function(click to visualize)

10

class TestCase for the Surrounding Component

PLAYER ::PLAYER[SURROUNDING]

- status: Boolean

# ctrl_surround() : boolean+ select_surround() : Surrounds[]+ select_surr_type(Surround) : void# activate(String) : boolean# display() : void# provide(Surround) : void

ObjectFunctional

State

More accurately (see next slide)…

11

Step 4.4 – Specify a Test Case Component for each System Function

Transform each system function into an object in the desired functional state

Map actor/system interactions that realizes this system function as its contextual operations

class TestCase for the Surrounding Component


- status: Boolean


11

How to design the Architecture Backbone using system functions ? (see next slide)…

Object State

An ‘Operation Contract’ is to be built up for the ‘black box testing’ of each

operation

class V1-Playing-Surrounding-Functions

«block»PLAYER


- status: Boolean

# ctrl_surround() : boolean+ select_surround() : Surrounds[]+ select_surr_type(Surround) : void- activate(String) : boolean

PLAYER ::PLAYER[RECORDING]

- status: Boolean

# ctrl_record() : boolean

PLAYER ::PLAYER_CONTROLER

- status: Boolean

# ctrl_player() : boolean+ cmd_play() : void+ cmd_pause() : void+ req_options(String) : Options[]+ cmd_surround() : void+ cmd_record() : void+ cmd_stop() : void# enable_button(Button) : void# disable_button(Button) : void+ turn_off() : void# setstate(String) : void# wait() : void

PLAYER ::PLAYER[PLAYING]

- status: Boolean

# ctrl_play() : boolean+ play() : Selection_types[]+ press(String) : String+ select_track(String) : String- activate(String) : boolean

I_PLAY

I_SURROUND

«block»Buttons

«block»Buttons::

Record Audio

«block»Buttons::Play

Audio

+ enable() : void+ disable() : void

I_RECORD

«block»Touch-screen

# ctrl_display() : boolean- set_activated_object() : void+ light_on() : void+ light_off() : void+ display() : void

I_TSCR

I_BUTTONS

DATA LAYER

«import»

«import»

«import»

«import»

«import»

«import»

The controler of the Player orchestrates execution of these

functions

External components participate to the realization

of functions via required and provided interfaces

Step 4.5 – Design a draft ‘Architectural Backbone’ of the whole system before designing its system functions

The Surrounding function is expressed by the [Surrounding] state of the Player object.

The actor / system interactions (scenario) that realize this function become its operations

Recording function of the

Player …

12

Step 5. Elaborate a High-Level Block Diagram of the System using Parts, Ports and Interfaces

Step 6. Refine and Optimize the initial architecture design to better deal with changes

Step 7.1 Model white box interactions by use case scenario (user story)

Step 7.2 Map corresponding Operations on the Components (Parts) of Blocks

13

Steps for the « System Design »

Click to visualise these steps on the ‘MP3 Player’ Case Study…13

SystemDesign

14

ibd Design_UI_Processor_Subsystem

p1_proc_cpup2_proc_cpu

«block»Portable Audio Player::Processing Subsys.


«BlockPro...codec

p1_proc_cpu

p_mem

p2_proc_cpu

«BlockPrope...cpu

p1_proc_cpu

p_mem

p2_proc_cpu

p_ui_buttonp_ui_tscr

«block»Portable Audio Player::User Interface


p_ui_button

«BlockPrope...btn :Buttons


«BlockProperty»tscr

p_ui_tscr

Internal Block Diagram for the User Interface and Processing Subsystems Communication Structure

p_cpu

«BlockProper...mem

p_cpu

«delegate»

«delegate» «delegate»

«delegate»

cpu-codec

Step 5 – Elaborate the Internal Blocks and Ports of the System : The « User Interface » and « Processing » Subsytems of the ‘MP3 Player’ are shown below

An Application Controler block may be designed inside the CPU block to Orchestrate execution

of the above functions (see next slide)

Functional Blocks will be deployed there to better deal

with evolutions of these functions (see next slide)

Click to visualize detailed parts and interfaces on the next slide…

ibd Internal Blocks of the CPU-V1




p_cpu

«BlockProperty»

mem

p_cpu


p_mem

«BlockProperty»

cpu


p_mem

«BlockPr...

surround«BlockPro...

play




p_ui_button

«BlockP...

btn :Buttons


«Block...

tscr

p_ui_tscr

«BlockPr...

record

«BlockProperty»

ctrl-MP3

I_Play

I_RecorderI_SurroundI_Surround

«delegate»

surround-I_surround

«delegate»

play-I_Play


rec-I_Recorder

15

Etape 6 –A more detailed architecture to better deal with changes

An Application Controler designed for the cpu block to Orchestrate execution of the

above functions (MVC pattern)

Surround, Record and Play « Components » designed for the memory (mem) block to better

deal with evolutions of these functions (OCP pattern)

Provided and required interfaces

between the CPU and Mem components

How to accurately determine operations of these components ? (see next slide)

16

Step 7.1 - Describe each white box scenario to prepare the Integration Test for the corresponding software component

sd SURROUNDING

«block»

Portable Audio Player::ProcessingSubsys.

mem

surround

cpu

ctrl-MP3

«block»

Portable Audio Player::UserInterface

btn :Buttons tscr

listener :Listener

(from Scenarios)

karaoké, disco, l ive, studio, matrice, echo

surrounding, parameters, equalizer, ...

SURROUNDING SCENARIO INTERACTIONS (White Box)

press(options)

req(options)

display(options_menu)

options_menu()

select(surround)

cmd(surround)

select(surround)

display(list_of_surrounds)

list_of_surrounds()

select(surround_type)

select(surround_type)


display(ok)


These interactions describe WHITE BOX test case

realization for the « Surround » function.

Messages will give up operations to test this

function(see next slide)

Operations of system components will be updated on the basis of these interactions (cf. next slide)

17

ibd Internal Blocks of the CPU-V1




«block»Components::

Processor-TMS320V::MP3PLayer-Controler

+ reqTurnOn() : void- setState() : void+ reqPlay() : void+ reqSurround() : void+ cmdSurround() : void+ reqPause() : void- wait() : void

p_cpu

«BlockProperty»

mem

p_cpu


p_mem

«BlockProperty»

cpu


p_mem

«BlockPr...

surround«BlockPro...

play




p_ui_button

«BlockP...

btn :Buttons


«Block...

tscr

p_ui_tscr

«BlockPr...

record

«BlockProperty»

ctrl-MP3

«block»Components::PLAYER ::PLAYER[SURROUNDING]

- status: Boolean


I_Play

I_RecorderI_SurroundI_Surround

«delegate»

surround-I_surround

«delegate»

play-I_Play


rec-I_Recorder

«trace»

«trace»

Etape 7.2 – Update components with operations on the basis of white box interactions

The White box interactions (previous slide) that realize the

‘Surrounding’ function become operations of

the corresponding block

18

How to deal with changes ?

Model hierachically changed business and system requirements grouping them by goals

Impact changes on system functions (services) to satisfy these requirements

Transform system functions to map them into the system architecture

Let’s look at each step on our case study…

SystemAnalysis

and Design

Requirements and

SystemAnalysis

18

Model changed business and system requirementscustom Audio Player Extended System Functions

Player [Moving Mode]

«Functional»[Usage in the Moving mode] : In the

walking and jogging modes, all user inputs must be acknowledged

using a resounding signal and displaying "ok" on the screen

(from V2-Complete usage life cycle)

Form and Duration of the visual acknowledgement on the screen


Caracteristics of the Resounding Signal for Acknowledgement


«business requirement»V2 - Maximize satisfaction of the user while he/she is

jogging, walking, travelling or using the player at the office or at home

(from Business Requirements)

Player [Travelling Mode]Player [At Home]

The player should interact with the Hi-Fi and Computer equipment to import or export tracks


Some attractive player requirements for the travelling mode...


«Functional»The sound level must be synchronized with the envrironment noise




«refine»

Changing Business Requirements that cause extension to previous functions

Additional Requirements that must be supported by

the system functions to satisfy Business

Requirements

19

req V2- Extended System Functions with Requirements

Player Functions

«service»Surround«service»

Play

«service»Record

«service»Play [Moving

Mode]

«service»Player

Controler

«service»Player [Moving

Mode]

«service»Player [At

Home]The player should interact with the Hi-Fi and Computer equipment to import or export tracks

(from V2-Complete usage life cycle)[Usage in the Moving mode] : In the walking and jogging modes, all user inputs must be acknowledged using a resounding signal and displaying "ok" on the screen


The sound level must be synchronized with the envrironmental noise as described below


«include»

«include»«include»

«satisfy»

«satisfy»

«satisfy»

Impact changes on the system functions to satisy new requirements

New Complex Functions are added to the functional architecture to satisfy changes on requirements

Requirements and

SystemAnalysis

20

class V2-Full life Cycle

«block»PLAYER


- status: Boolean


PLAYER ::PLAYER[RECORDING]

- status: Boolean

# ctrl_record() : boolean

PLAYER ::PLAYER_CONTROLER

- status: Boolean

# ctrl_player() : boolean+ cmd_play() : void+ cmd_pause() : void+ req_options(String) : Options[]+ cmd_surround() : void+ cmd_record() : void+ cmd_stop() : void# enable_button(Button) : void# disable_button(Button) : void+ turn_off() : void# setstate(String) : void# wait() : void

PLAYER ::PLAYER[PLAYING]

- status: Boolean

# ctrl_play() : boolean+ play() : Selection_types[]+ press(String) : String+ select_track(String) : String- activate(String) : boolean

I_PLAY

I_SURROUND

«block»Buttons

«block»Buttons::

Record Audio

«block»Buttons::Play

Audio

+ enable() : void+ disable() : void

I_RECORD

PLAYER ::PLAYER [MOVING_MODE]

# ctrl_player() : boolean+ acknowledgts() : void

«block»Touch-screen

# ctrl_display() : boolean- set_activated_object() : void+ light_on() : void+ light_off() : void+ display() : void

I_TSCR

PLAYER ::PLAYER [AT_HOME]

# ctrl_player() : boolean+ media_interactions() : void+ connect_media() : void

Touch-screen [Mov ing_Mode]

# ctrl_display() : boolean+ disp_ack_ok() : void+ buzzer_ack() : void+ disp_medias() : void

PLAYER ::PLAYER [PLAYING_IN_MOVING_MODE]

# ctrl_play() : boolean+ auto_sound_level() : void# regulate_sound() : void

I_BUTTONS

DATA LAYER

«import»

«import»

«import»

«import»

«import»

«import»

Map these functions with corresponding requirements to the existing system architecture for tests

New complex functions are mapped into the existing architecture using association and specialization relationships

SystemAnalysis

and Design

21Notice how the «Goal-Driven Modeling » approach brings agility

particularly to better deal with changes

More complete Agile System Development Training Courses using standards…

© 2011 / 2014– GooBiz.com

e-Mail to : [email protected]

22

mailto:[email protected]?subject=Demande%20info

http://goobiz.com/Services.htm

Documents

© 2010- 2011 GooBiz.com Agile System Modeling using UML and SysML How to assure MRD - PSD traceability and deal with changes using a Goal-Driven Modeling