Lecture 8: Use Cases and Scenarios 2017-06-01 Prof. Dr. Andreas - - PowerPoint PPT Presentation
Softwaretechnik / Software-Engineering Lecture 8: Use Cases and Scenarios 2017-06-01 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universitt Freiburg, Germany 8 2017-06-01 main Topic Area Requirements
– 8 – 2017-06-01 – main –
2017-06-01
Albert-Ludwigs-Universität Freiburg, Germany
– 8 – 2017-06-01 – Sblockcontent –
2/45
VL 6 . . . VL 7 . . . VL 8 . . . VL 9 . . .
– 8 – 2017-06-01 – Scontent –
3/45
– 8 – 2017-06-01 – main –
4/45
– 8 – 2017-06-01 – Sscen –
5/45
Needs!
need 1 need 2 need 3 ...Solution! Customer Developer
announcement
(Lastenheft)
→
...e
Customer Developer
(Pflichtenheft)
→
spec 1 spec 2a spec 2b ...§
...e
Customer Developer
software contract
(incl. Pflichtenheft)
→
Needs! Developer Customer
software delivery
– 8 – 2017-06-01 – Sscen –
5/45
Needs!
need 1 need 2 need 3 ...Solution! Customer Developer
announcement
(Lastenheft)
→
...e
Customer Developer
(Pflichtenheft)
→
spec 1 spec 2a spec 2b ...§
...e
Customer Developer
software contract
(incl. Pflichtenheft)
→
Needs! Developer Customer
software delivery
One quite effective approach: try to approximate the requirements with positive and negative scenarios.
– 8 – 2017-06-01 – Sscen –
5/45
Needs!
need 1 need 2 need 3 ...Solution! Customer Developer
announcement
(Lastenheft)
→
...e
Customer Developer
(Pflichtenheft)
→
spec 1 spec 2a spec 2b ...§
...e
Customer Developer
software contract
(incl. Pflichtenheft)
→
Needs! Developer Customer
software delivery
One quite effective approach: try to approximate the requirements with positive and negative scenarios.
Customer intuition: “If the system is not at all able to do this, then it’s not what I want.”
Customer intuition: “If the system does this, then it’s not what I want.”
– 8 – 2017-06-01 – Sscen –
5/45
Needs!
need 1 need 2 need 3 ...Solution! Customer Developer
announcement
(Lastenheft)
→
...e
Customer Developer
(Pflichtenheft)
→
spec 1 spec 2a spec 2b ...§
...e
Customer Developer
software contract
(incl. Pflichtenheft)
→
Needs! Developer Customer
software delivery
One quite effective approach: try to approximate the requirements with positive and negative scenarios.
Customer intuition: “If the system is not at all able to do this, then it’s not what I want.”
Customer intuition: “If the system does this, then it’s not what I want.”
what about exceptional cases? what about corner-cases? etc.
– 8 – 2017-06-01 – Sscen –
6/45
(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink.
(i) Insert one 50 cent and one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink. (iv) Get 50 cent change.
– 8 – 2017-06-01 – Sscen –
6/45
(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink.
(i) Insert one 50 cent and one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Get a softdrink. (iv) Get 50 cent change.
(i) Insert one 1 euro coin. (ii) Press the ‘softdrink’ button. (iii) Do not insert any more money. (iv) Get two softdrinks.
– 8 – 2017-06-01 – Sscen –
7/45
(re-)occurs in many process models or software development approaches.
(in increasing formality):
– 8 – 2017-06-01 – main –
8/45
– 8 – 2017-06-01 – Suserstories –
9/45
“A User Story is a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.”
– 8 – 2017-06-01 – Suserstories –
9/45
“A User Story is a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.” Per user story, use one file card with the user story, e.g. following the pattern: As a [role] I want [something] so that [benefit].
– 8 – 2017-06-01 – Suserstories –
9/45
“A User Story is a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.” Per user story, use one file card with the user story, e.g. following the pattern: As a [role] I want [something] so that [benefit]. and in addition:
assigned by customer,
(acceptance) test case(s), i.e., how to tell whether the user story has been realised.
– 8 – 2017-06-01 – Suserstories –
9/45
“A User Story is a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.” Per user story, use one file card with the user story, e.g. following the pattern: As a [role] I want [something] so that [benefit]. and in addition:
assigned by customer,
(acceptance) test case(s), i.e., how to tell whether the user story has been realised.
Proposed card layout (front side):
priority unique identifier, name estimation As a [role] I want [something] so that [benefit]. risk real effort
– 8 – 2017-06-01 – Suserstories –
9/45
“A User Story is a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.” Per user story, use one file card with the user story, e.g. following the pattern: As a [role] I want [something] so that [benefit]. and in addition:
assigned by customer,
(acceptance) test case(s), i.e., how to tell whether the user story has been realised.
Proposed card layout (front side):
priority unique identifier, name estimation As a [role] I want [something] so that [benefit]. risk real effort
– 6 – 2016-05-12 – Sspeclang –
33/37
Natural language requirements can be (tried to be) written as an instance of the pattern “A B C D E F.” (German grammar) where
A clarifies when and under what conditions the activity takes place B is MUST (obligation), SHOULD (wish), or WILL (intention); also: MUST NOT (forbidden) C is either “the system” or the concrete name of a (sub-)system D
usage of a function offered by a third party, under certain conditions E extensions, in particular an object F the actual process word (what happens)
(Rupp and die SOPHISTen, 2009)
Example:
After office hours (= A), the system (= C) should (= B) offer to the operator (= D) a backup (= F) of all new registrations to an external medium (= E).
– 8 – 2017-06-01 – Suserstories –
10/45
✔ easy to create, small units ✔ close contact to customer ✔ objective / testable: by fixing test cases early ✘ may get difficult to keep overview over whole system to be developed → maybe best suited for changes / extensions (after first iteration). ✘ not designed to cover non-functional requirements and restrictions ✘ agile spirit: strong dependency on competent developers ✘ estimation of effort may be difficult
(Balzert, 2009)
– 8 – 2017-06-01 – main –
11/45
– 8 – 2017-06-01 – Suc –
12/45
– 8 – 2017-06-01 – Suc –
13/45 use case — A sequence of interactions between an actor (or actors) and a system trig- gered by a specific actor, which produces a result for an actor.
(Jacobson, 1992)
– 8 – 2017-06-01 – Suc –
13/45 use case — A sequence of interactions between an actor (or actors) and a system trig- gered by a specific actor, which produces a result for an actor.
(Jacobson, 1992)
More precisely:
the system and at least one actor.
what interacts with the system.
system may assume when interacting with the system under design.
thus they are not described in detail.
(possibly constrained by domain model).
as input by the main actor.
wants to reach a particular goal.
the system and the participating actors that are needed to achieve the goal (or fail to achieve the goal for reasons).
achieved, or when it is clear that the desired goal cannot be achieved.
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal pre-condition post-condition post-cond. in exceptional case actors
normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition post-condition post-cond. in exceptional case actors
normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition post-cond. in exceptional case actors
normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case actors
normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors
normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
– 8 – 2017-06-01 – Suc –
14/45
h t t p : / / c
m
s . w i k i m e d i a .
g ( C C
y
a 4 . , D i r k I n g
r a n k e )
name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
card readable, but not ATM card
no connection to bank system
card not valid or disabled
client cancels
client doesn’t react within 5 s
no connection to bank system
first or second PIN wrong
third PIN wrong (Ludewig and Lichter, 2013)
– 8 – 2017-06-01 – main –
15/45
– 8 – 2017-06-01 – Sucd –
16/45
actor name use case name
use case name
– 8 – 2017-06-01 – Sucd –
17/45
Use Case Example: ATM Authentication
– 8 – 2017-06-01 – Suc –14/27
http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke)name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
card readable, but not ATM card
no connection to bank system
card not valid or disabled
client cancels
client doesn’t react within 5 s
no connection to bank system
first or second PIN wrong
third PIN wrong (Ludewig and Lichter, 2013)
– 8 – 2017-06-01 – Sucd –
17/45
Use Case Example: ATM Authentication
– 8 – 2017-06-01 – Suc –14/27
http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke)name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
card readable, but not ATM card
no connection to bank system
card not valid or disabled
client cancels
client doesn’t react within 5 s
no connection to bank system
first or second PIN wrong
third PIN wrong (Ludewig and Lichter, 2013)
client (main actor) Authentication bank system
– 8 – 2017-06-01 – Sucd –
18/45
actor name use case name
use case name
– 8 – 2017-06-01 – Sucd –
18/45
actor name use case name
use case name
More notation:
use case A use case B
use case B
include
– 8 – 2017-06-01 – Sucd –
19/45 ATM info services
print statement [not auth.] query balance [print statement]
transactions
get cash define stan- ding order
basic services
authentication
– 8 – 2017-06-01 – Shappy –
20/45
Use Case Example: ATM Authentication
– 8 – 2017-06-01 – Suc –14/27
http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke)name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
card readable, but not ATM card
no connection to bank system
card not valid or disabled
client cancels
client doesn’t react within 5 s
no connection to bank system
first or second PIN wrong
third PIN wrong (Ludewig and Lichter, 2013)
– 8 – 2017-06-01 – Shappy –
20/45
Use Case Example: ATM Authentication
– 8 – 2017-06-01 – Suc –14/27
http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke)name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
card readable, but not ATM card
no connection to bank system
card not valid or disabled
client cancels
client doesn’t react within 5 s
no connection to bank system
first or second PIN wrong
third PIN wrong (Ludewig and Lichter, 2013)
(1.) Observables:
– 8 – 2017-06-01 – Shappy –
20/45
Use Case Example: ATM Authentication
– 8 – 2017-06-01 – Suc –14/27
http://commons.wikimedia.org (CC-by-sa 4.0, Dirk Ingo Franke)name Authentication goal the client wants access to the ATM pre-condition the ATM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of ATM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system
none normal case
sends data to bank system
sends to bank system
exception case 2a card not readable 2a.1 ATM displays “card not readable” 2a.2 ATM returns card 2a.3 ATM shows welcome screen
card readable, but not ATM card
no connection to bank system
card not valid or disabled
client cancels
client doesn’t react within 5 s
no connection to bank system
first or second PIN wrong
third PIN wrong (Ludewig and Lichter, 2013)
(1.) Observables:
(2.) Finite Automaton: q1 q2 q3 q4 q5
insert_card ∧ card_rdbl q insert_card ∧¬ card_rdbl send_data data_valid pin_screen
– 8 – 2017-06-01 – Shappy –
21/45
– 8 – 2017-06-01 – Scontent –
22/45
– 8 – 2017-06-01 – main –
23/45
– 8 – 2017-06-01 – Ssd –
24/45
ITU standardized in different versions (ITU Z.120, 1st edition: 1993); often accused of lacking a formal semantics.
msc event_ordering
proc_a proc_b proc_c m1
m2 m3 m4
(a) (ITU-T, 2011)
– 8 – 2017-06-01 – Ssd –
24/45
ITU standardized in different versions (ITU Z.120, 1st edition: 1993); often accused of lacking a formal semantics.
(one of three main authors: I. Jacobson)
exhibits unclarities and even contradictions (Harel and Maoz, 2007; Störrle, 2003)
msc event_ordering
proc_a proc_b proc_c m1
m2 m3 m4
(a) (ITU-T, 2011)
sd UserAccepted
:User :ACSystem Code d=duration CardOut {0..13} OK Unlock {d..3*d} t=now {t..t+3}
DurationConstraint TimeObservation TimeConstraint DurationObservation
(OMG, 2007)
– 8 – 2017-06-01 – Ssd –
24/45
ITU standardized in different versions (ITU Z.120, 1st edition: 1993); often accused of lacking a formal semantics.
(one of three main authors: I. Jacobson)
exhibits unclarities and even contradictions (Harel and Maoz, 2007; Störrle, 2003)
Live Sequence Charts (LSCs) (Damm and Harel, 2001; Klose, 2003; Harel and Marelly, 2003), LSCs have a common fragment with UML 2.x SDs: (Harel and Maoz, 2007).
msc event_ordering
proc_a proc_b proc_c m1
m2 m3 m4
(a) (ITU-T, 2011)
sd UserAccepted
:User :ACSystem Code d=duration CardOut {0..13} OK Unlock {d..3*d} t=now {t..t+3}
DurationConstraint TimeObservation TimeConstraint DurationObservation
(OMG, 2007)
LSC: L AM: invariant I: strict I1 I2 c1 I3 A B C D E c2 ∧ c3
– 8 – 2017-06-01 – main –
25/45
– 8 – 2017-06-01 – Slscsyn –
26/45
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 I3
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 I3
instance line head (hot) line segment (cold) line segment instance line/ life line
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 I3 A B C D E
instance line head (hot) line segment (cold) line segment instance line/ life line
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 I3 A B C D E
instance line head (hot) line segment (cold) line segment instance line/ life line (hot) instantaneous message (hot) asynchronous message simultaneous region
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4
instance line head (hot) line segment (cold) line segment instance line/ life line (hot) instantaneous message (hot) asynchronous message simultaneous region
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4
instance line head (hot) line segment (cold) line segment instance line/ life line (hot) instantaneous message (hot) asynchronous message simultaneous region (cold) local invariant (hot) condition exclusive inclusive
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4
instance line head (hot) line segment (cold) line segment instance line/ life line (hot) instantaneous message (hot) asynchronous message simultaneous region (cold) local invariant (hot) condition exclusive inclusive
– 8 – 2017-06-01 – Slscsyn –
26/45
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4
instance line head (hot) line segment (cold) line segment instance line/ life line (hot) instantaneous message (hot) asynchronous message simultaneous region (cold) local invariant (hot) condition exclusive inclusive coregion
– 8 – 2017-06-01 – Slscsyn –
27/45
I1 I2
φ
I3
E F G
concrete syntax
(diagram)
((L, , ∼), I, Msg, Cond, LocInv, Θ) abstract syntax
q1 q2 q3 q4 q5 q6 q7 true
semantics
(Büchi automaton)
– 8 – 2017-06-01 – Slscsyn –
28/45
Let E be a set of events and C a set of atomic propositions, E ∩ C = ∅. An LSC body over E and C is a tuple ((L, , ∼), I, Msg, Cond, LocInv, Θ) where
message (l, E, l′) is called instantaneous iff l ∼ l′ and asynchronous otherwise,
with (L, φ) ∈ Cond only if l ∼ l′ for all l = l′ ∈ L,
with (l, ι, φ, l′, ι′) ∈ LocInv only if l ≺ l′, ◦: exclusive, •: inclusive,
assigns to each location and each element a temperature.
– 8 – 2017-06-01 – Slscsyn –
29/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4
– 8 – 2017-06-01 – Slscsyn –
29/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
– 8 – 2017-06-01 – Slscsyn –
30/45
Let E be a set of events and C a set of atomic propositions, E ∩ C = ∅. An LSC body over E and C is a tuple ((L, , ∼), I, Msg, Cond, LocInv, Θ) where
message (l, E, l′) is called instantaneous iff l ∼ l′ and asynchronous otherwise,
with (L, φ) ∈ Cond only if l ∼ l′ for all l = l′ ∈ L,
with (l, ι, φ, l′, ι′) ∈ LocInv only if l ≺ l′, ◦: exclusive, •: inclusive,
assigns to each location and each element a temperature.
– 8 – 2017-06-01 – Slscsyn –
31/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
– 8 – 2017-06-01 – Slscsyn –
31/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
l1,2 ≺ l1,4, l2,0 ≺ l2,1 ≺ l2,2 ≺ l2,3, l3,0 ≺ l3,1 ≺ l3,2 ≺ l3,3, l1,1 ≺ l2,1, l2,2 ≺ l1,2, l2,3 ≺ l1,3, l3,2 ≺ l1,4, l2,1 ∼ l3,1, l2,2 ∼ l3,2,
– 8 – 2017-06-01 – Slscsyn –
31/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
l1,2 ≺ l1,4, l2,0 ≺ l2,1 ≺ l2,2 ≺ l2,3, l3,0 ≺ l3,1 ≺ l3,2 ≺ l3,3, l1,1 ≺ l2,1, l2,2 ≺ l1,2, l2,3 ≺ l1,3, l3,2 ≺ l1,4, l2,1 ∼ l3,1, l2,2 ∼ l3,2,
– 8 – 2017-06-01 – Slscsyn –
31/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
l1,2 ≺ l1,4, l2,0 ≺ l2,1 ≺ l2,2 ≺ l2,3, l3,0 ≺ l3,1 ≺ l3,2 ≺ l3,3, l1,1 ≺ l2,1, l2,2 ≺ l1,2, l2,3 ≺ l1,3, l3,2 ≺ l1,4, l2,1 ∼ l3,1, l2,2 ∼ l3,2,
– 8 – 2017-06-01 – Slscsyn –
31/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
l1,2 ≺ l1,4, l2,0 ≺ l2,1 ≺ l2,2 ≺ l2,3, l3,0 ≺ l3,1 ≺ l3,2 ≺ l3,3, l1,1 ≺ l2,1, l2,2 ≺ l1,2, l2,3 ≺ l1,3, l3,2 ≺ l1,4, l2,1 ∼ l3,1, l2,2 ∼ l3,2,
– 8 – 2017-06-01 – Slscsyn –
31/45
∼ ⊆ L × L
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 l1,0 l1,1 l1,2 l1,3 l1,4 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1 l3,2 l3,3
l1,2 ≺ l1,4, l2,0 ≺ l2,1 ≺ l2,2 ≺ l2,3, l3,0 ≺ l3,1 ≺ l3,2 ≺ l3,3, l1,1 ≺ l2,1, l2,2 ≺ l1,2, l2,3 ≺ l1,3, l3,2 ≺ l1,4, l2,1 ∼ l3,1, l2,2 ∼ l3,2,
– 8 – 2017-06-01 – Slscsyn –
32/45
Bondedness/no floating conditions: (could be relaxed a little if we wanted to)
then there is a location l′ simultaneous to l, i.e. l ∼ l′, which is the location of
∃ (l1, E, l2) ∈ Msg : l ∈ {l1, l2}. Note: if messages in a chart are cyclic, then there doesn’t exist a partial order (so such diagrams don’t even have an abstract syntax).
– 8 – 2017-06-01 – Slscsyn –
33/45
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 I3 I2 c1 I1 A B C D E c2 ∧ c3 c4
– 8 – 2017-06-01 – Slscsyn –
33/45
I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 I1 I2 c1 I3 A B C D E c2 ∧ c3 c4 I3 I2 c1 I1 A B C D E c2 ∧ c3 c4
l1,2 ≺ l1,4, l2,0 ≺ l2,1 ≺ l2,2 ≺ l2,3, l3,0 ≺ l3,1 ≺ l3,2 ≺ l3,3, l1,1 ≺ l2,1, l2,2 ≺ l1,2, l2,3 ≺ l1,3, l3,2 ≺ l1,4, l2,1 ∼ l3,1, l2,2 ∼ l3,2,
– 8 – 2017-06-01 – Scontent –
34/45
– 8 – 2017-06-01 – main –
35/45
– 8 – 2017-06-01 – Scutfire –
36/45
I1 I2
φ
I3
E F G
concrete syntax
(diagram)
((L, , ∼), I, Msg, Cond, LocInv, Θ) abstract syntax
q1 q2 q3 q4 q5 q6 q7 true
semantics
(Büchi automaton)
– 8 – 2017-06-01 – Scutfire –
37/45
– 8 – 2017-06-01 – Scutfire –
37/45
A non-empty set ∅ = C ⊆ L is called a cut of the LSC body iff C
∀ l, l′ ∈ L • l′ ∈ C ∧ l l′ = ⇒ l ∈ C,
∀ l, l′ ∈ L • l′ ∈ C ∧ l ∼ l′ = ⇒ l ∈ C, and
∀ I ∈ I • C ∩ I = ∅.
– 8 – 2017-06-01 – Scutfire –
37/45
A non-empty set ∅ = C ⊆ L is called a cut of the LSC body iff C
∀ l, l′ ∈ L • l′ ∈ C ∧ l l′ = ⇒ l ∈ C,
∀ l, l′ ∈ L • l′ ∈ C ∧ l ∼ l′ = ⇒ l ∈ C, and
∀ I ∈ I • C ∩ I = ∅.
The temperature function is extended to cuts as follows: Θ(C) =
, if ∃ l ∈ C • (∄ l′ ∈ C • l ≺ l′) ∧ Θ(l) = hot cold , otherwise that is, C is hot if and only if at least one of its maximal elements is hot.
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
38/45 ∅ = C ⊆ L — downward closed — simultaneity closed — at least one loc. per instance line
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
39/45
The partial order “” and the simultaneity relation “∼” of locations induce a direct successor relation on cuts of an LSC body as follows: Definition. Let C ⊆ L bet a cut of LSC body ((L, , ∼), I, Msg, Cond, LocInv, Θ). A set ∅ = F ⊆ L of locations is called fired-set F of cut C if and only if
∀ l ∈ F ∃ l′ ∈ C • l′ ≺ l ∧ (∄ l′′ ∈ C • l′ ≺ l′′ ≺ l),
∀ l = l′ ∈ F • (∃ I ∈ I • {l, l′} ⊆ I) = ⇒ l l′ ∧ l′ l,
the corresponding sending is already in C, ∀ (l, E, l′) ∈ Msg • l′ ∈ F = ⇒ l ∈ C. The cut C′ = C ∪ F is called direct successor of C via F, denoted by C F C′.
– 8 – 2017-06-01 – Scutfire –
40/45
C ∩ F = ∅ — C ∪ F is a cut — only direct ≺-successors — same instance line on front pairwise unordered — sending of asynchronous reception already in
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
40/45
C ∩ F = ∅ — C ∪ F is a cut — only direct ≺-successors — same instance line on front pairwise unordered — sending of asynchronous reception already in
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
– 8 – 2017-06-01 – Scutfire –
41/45
I1 I2
φ
I3
E F G
l1,0 l1,1 l1,2 l2,0 l2,1 l2,2 l2,3 l3,0 l3,1
q1 q2 q3 q4 q5 q6 q7
¬E! E! ¬E? E? ∧ φ F! F! ¬(F? ∨ G! ∨ G?) G! ∧ G? ∧ ¬F? F? ∧ ¬(G! ∧ G?) ¬F? F? ¬(G! ∧ G?) G! ∧ G? G! ∧ G? ∧ F? true E? ∧ ¬φ
The TBA B(L ) of LSC L over C and E is (CB, Q, qini, →, QF ) with
∪ E!?, where E!? = {E!, E? | E ∈ E},
– 8 – 2017-06-01 – Scutfire –
42/45 Recall: The TBA B(L ) of LSC L is (C, Q, qini, →, QF ) with
∪ E!?,
– 8 – 2017-06-01 – Scutfire –
42/45 Recall: The TBA B(L ) of LSC L is (C, Q, qini, →, QF ) with
∪ E!?,
So in the following, we “only” need to construct the transitions’ labels:
→= {(q, , q) | q ∈ Q} ∪ {(q, , q′) | q F q′} ∪ {(q, , L) | q ∈ Q}
– 8 – 2017-06-01 – Scutfire –
42/45 Recall: The TBA B(L ) of LSC L is (C, Q, qini, →, QF ) with
∪ E!?,
So in the following, we “only” need to construct the transitions’ labels:
→= {(q, ψloop(q), q) | q ∈ Q} ∪ {(q, ψprog(q, q′), q′) | q F q′} ∪ {(q, ψexit(q), L) | q ∈ Q}
– 8 – 2017-06-01 – Scutfire –
42/45 Recall: The TBA B(L ) of LSC L is (C, Q, qini, →, QF ) with
∪ E!?,
So in the following, we “only” need to construct the transitions’ labels:
→= {(q, ψloop(q), q) | q ∈ Q} ∪ {(q, ψprog(q, q′), q′) | q F q′} ∪ {(q, ψexit(q), L) | q ∈ Q}
q ...
ψloop(q): “what allows us to stay at cut q” “. . . F1” ψprog(q, q′): “characterisation of firedset Fn” ψexit(q): “what allows us to legally exit” true
I1 I2 c1 I3 A B C D E c2 ∧ c3
– 8 – 2017-06-01 – Sttwytt –
43/45
– 8 – 2017-06-01 – main –
44/45
– 8 – 2017-06-01 – main –
45/45 Balzert, H. (2009). Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering. Spektrum, 3rd edition. Beck, K. (1999). Extreme Programming Explained – Embrace Change. Addison-Wesley. Damm, W. and Harel, D. (2001). LSCs: Breathing life into Message Sequence Charts. Formal Methods in System Design, 19(1):45–80. Harel, D. and Maoz, S. (2007). Assert and negate revisited: Modal semantics for UML sequence diagrams. Software and System Modeling (SoSyM). To appear. (Early version in SCESM’06, 2006, pp. 13-20). Harel, D. and Marelly, R. (2003). Come, Let’s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag. ITU-T (2011). ITU-T Recommendation Z.120: Message Sequence Chart (MSC), 5 edition. Jacobson, I. (1992). Object Oriented Software Engineering – A Use Case Driven Approach. ACM Press. Klose, J. (2003). LSCs: A Graphical Formalism for the Specification of Communication Behavior. PhD thesis, Carl von Ossietzky Universität Oldenburg. Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. OMG (2007). Unified modeling language: Superstructure, version 2.1.2. Technical Report formal/07-11-02. Störrle, H. (2003). Assert, negate and refinement in UML-2 interactions. Technical Report TUM-I0323, Technische Universität München.