Agile and Smart Modeling With UML and SysML on a Case Study
Transcript of Agile and Smart Modeling With UML and SysML on a Case Study
© 2009 – 2010 GooBiz.com
Agile and Smart Modeling with UML and SysML on the basis of your Project Vision
Goal-Driven Modeling to assist Agile Methods (*) on a short Case Study
To visualize presentation slides, please use the full screen mode and click to progress
©2010 Birol Berkem - GooBiz.com
(*) Agile Methods : SCRUM, AUP (S.W. Ambler), Lean & Agile Development (C.Larman), XP,...
Agile Requirements Writing using UP and Scrum
Case Study : « As a Listener of an MP3 Audio-Player System, I would like to Listen and Record Audio with satisfaction »
uc V1- Operate Audio Player
MP3-Audio PlayerOperations
Listener
Listen Audio
Record Audio
Acceptance Checking : The system must verify the following requirements :
How to smartly gather these requirements in order to deal with changes ?2
Step 1. Compose hierarchically business requirements (1) and system
requirements (2) that refine them
Step 2. Derive and formalize system functions (3) that satisfy these requirements and use cases that invoke system functions
Step 3. Model the System Life Cycle that control transitions between states where functions are triggered
Step 4. Model Use Cases and System Functions to establish Test Cases on the basis of 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 requirement3
Main Steps for « Smartly Gathering Requirements »
Let’s look at each step on the same case study…
Requirements and
SystemAnalysis
3
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
(from Functional Requirements)
The Adjust Volume function must be available while the Audio Player is set to Play, to Pause or to Surrounding
tagsid = REQ022.1
(from Functional Requirements)
The Surrounding User Interface must support categories like : karaoké, disco, live, studio, matrice, echo
tagsid = REQ445
(from Functional Requirements)
The Play User Interface must support categories like : recently played, by author, by type, by year
tagsid = REQ443
(from Functional Requirements)
«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 by a user from the system in order to fulfill the business requirements
Functional Boundary of the System under Discussion
4
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
(from Functional Requirements)
The Adjust Volume function must be available while the Audio Player is set to Play, to Pause or to Surrounding
tagsid = REQ022.1
(from Functional Requirements)
The Play User Interface must support categories like : recently played, by author, by type, by year
tagsid = REQ443
(from Functional Requirements)
«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
(from Functional Requirements)
Before Recording Audio is started, the Play function must be disabled
(from Functional Requirements)
Whenever Recording Audio is stopped, the Play function must be enabled
(from Functional Requirements)
«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
5When these system functions are triggered ? (see next slide)…
6
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 rigorously states and transitions of the system where system functions are triggered
Example : The GOAL of the « Surrounding » state is to support realization
of the « Surrounding function » scenario as
described next (slide 9)
Each state in which a system function is
triggered corresponds to a
particular GOAL for the system
How these functions are USED by the Actors of the system ? (see next slide)…
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 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
7How these functions are precisely invoked in Use Case Scenarios ? (see next slide)
8
Step 4.2 – 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 described just by a simple click
on it (see next slide)
Actor / System interactions for the Surround scenario is described next
sd Surround Selection
l istener :Listener
mp3device:Portable Audio
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)
Step 4.3- Describe each scenario to prepare the Test Case for the Function
These actor / system interactions describe BLACK BOX test case
realization Ffor the « Surround » function.
They will become at the design time operations to
test this function(see next slide)
9How to go toward testing black box system functions before architecture design ?
(see next slide)
10
Step 4.4 – Specify a Test Component for each System Function to deploy later into the System Architecture
Transform each system function into a Goal-Oriented Object (1)
Map actor/system interactions that realize each function as contextual operations of this object
(1) Goal-Oriented Object : An object in a state in which a system function scenario can be completely tested on the basis of its actor/system interactions
• Example : All of the interactions that realize the Surrounding function (see previous slide) can be tested in the [Surrounding] state of the Player object
How to prototype Orchestration of these system functions ? (see next slide)…
SystemAnalysis
A Goal-Oriented Objectwhose goal is to support
The « Surrounding Function »within the Player System
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
10
class V1-Playing-Surrounding-Functions
«block»PLAYER
PLAYER ::PLAYER[SURROUNDING]
- 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 – Prototype Orchestration of System Components before designing and deploying them into the System Architecture
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 …
11
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
12
Steps for « System Design »
Click to visualise these steps on our Case Study… 12
SystemDesign
13
ibd Design_UI_Processor_Subsystem
p1_proc_cpup2_proc_cpu
«block»Portable Audio Player::Processing Subsys.
p1_proc_cpup2_proc_cpu
«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_buttonp_ui_tscr
p_ui_button
«BlockPrope...btn :Buttons
p_ui_buttonp_ui_tscr
«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 Player are shown below
An Application Controler block must 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
p1_proc_cpup2_proc_cpu
«block»Portable Audio Player::Processing Subsys.
p1_proc_cpup2_proc_cpu
p_cpu
«BlockProperty»
mem
p_cpu
p1_proc_cpup2_proc_cpu
p_mem
«BlockProperty»
cpu
p1_proc_cpup2_proc_cpu
p_mem
«BlockPr...
surround«BlockPro...
play
p_ui_buttonp_ui_tscr
«block»Portable Audio Player::User Interface
p_ui_buttonp_ui_tscr
p_ui_button
«BlockP...
btn :Buttons
p_ui_buttonp_ui_tscr
«Block...
tscr
p_ui_tscr
«BlockPr...
record
«BlockProperty»
ctrl-MP3
I_Play
I_RecorderI_SurroundI_Surround
«delegate»
surround-I_surround
«delegate»
play-I_Play
«delegate» «delegate»
rec-I_Recorder
14
Etape 6 –An optimized 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 determine precisely operations of these components ? (see next slide)
15
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)
activate(selected_surround_type)
display(ok)
provide(selected_surround_type)
These interactions describe WHITE BOX test case
realization for the « Surround » function.
They will become operations to test this function
(see next slide)
Operations of system components will be updated on the basis of these interactions (see next slide)
16
ibd Internal Blocks of the CPU-V1
p1_proc_cpup2_proc_cpu
«block»Portable Audio Player::Processing Subsys.
p1_proc_cpup2_proc_cpu
«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
p1_proc_cpup2_proc_cpu
p_mem
«BlockProperty»
cpu
p1_proc_cpup2_proc_cpu
p_mem
«BlockPr...
surround«BlockPro...
play
p_ui_buttonp_ui_tscr
«block»Portable Audio Player::User Interface
p_ui_buttonp_ui_tscr
p_ui_button
«BlockP...
btn :Buttons
p_ui_buttonp_ui_tscr
«Block...
tscr
p_ui_tscr
«BlockPr...
record
«BlockProperty»
ctrl-MP3
«block»Components::PLAYER ::PLAYER[SURROUNDING]
- status: Boolean
# ctrl_surround() : boolean+ select_surround() : Surrounds[]+ select_surr_type(Surround) : void# activate(String) : boolean# display() : void# provide(Surround) : void
I_Play
I_RecorderI_SurroundI_Surround
«delegate»
surround-I_surround
«delegate»
play-I_Play
«delegate» «delegate»
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
Notice that black box system components were already succesfully specified with these expected behaviours before design time Using the same «Goal-Oriented Objects » (see slide 10 and 11)
17
How to deal with changes ?
Model hierachically changed business and system requirements
Impact changes on system functions (services) to satisfy these requirements
Transform system functions into Goal-Oriented Objects to map them to the system architecture using associations or specialization relationships
Let’s look at each step on our case study…
SystemAnalysis
and Design
Requirements and
SystemAnalysis
17
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
(from V2-Complete usage life cycle)
Caracteristics of the Resounding Signal for Acknowledgement
(from V2-Complete usage life cycle)
«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
(from V2-Complete usage life cycle)
Some attractive player requirements for the travelling mode...
(from V2-Complete usage life cycle)
«Functional»The sound level must be synchronized with the envrironment noise
(from V2-Complete usage life cycle)
«refine»«refine»
«refine»«refine»
«refine»
Changing Business Requirements that cause extension to previous functions
Additional Requirements that must be supported by system functions to
satisfy Business Requirements
18
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
(from V2-Complete usage life cycle)
The sound level must be synchronized with the envrironmental noise as described below
(from V2-Complete usage life cycle)
«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
19
class V2-Full life Cycle
«block»PLAYER
PLAYER ::PLAYER[SURROUNDING]
- status: Boolean
# ctrl_surround() : boolean+ select_surround() : Surrounds[]+ select_surr_type(Surround) : void# activate(String) : boolean# display() : void# provide(Surround) : void
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»
Transform and Map these functions with corresponding requirements to the existing system architecture for tests
New complex functions are mapped into the existing architecture using association or specialization relationships
SystemAnalysis
and Design
20Notice how «Goal-Driven Modeling » brings agility in developping systems particularly to better deal with the changes
More complete Agile Modeling and SOA Trainings with BMM, BPMN, UML, SysML and SoaML…
© 2010 – GooBiz.com
•Increasing Business Agility with the Goal-Driven SOA using EA(1 day on your site)
• Goal-Driven SOA Specification et Realization using BPMN, UML and SoaML (3 days on your site)
•Goal-Driven Agile Business Modeling with BMM, BPMN and SOAML using EA(3 days on your site)
•Efficient Requirement Analysis with UML 2 using EA (3 days on your site)
•Component Based System Design with UML 2 using EA (2 days on your site)
•Agile Embedded System Design with UML 2 and SysML using EA (3 days on your site)
e-Mail to : [email protected]
21