From Use Cases to Post Conditions Martin Giese and Rogardt Heldal Chalmers Tekniska Högskola, Göteborg, Sweden KeY Workshop, June 7, 2004 – p.1/26
Motivation . . . for the crowd: Until now, the KeY method starts at the design phase: • add OCL pre/post conditions to methods • instantiate design patterns • Constraints like argument ranges, objects being non-null What is missing is the analysis phase: • Specifications that correspond to customer requirements • Done before the first class diagram • Textual descriptions KeY Workshop, June 7, 2004 – p.2/26
Informal Specification in UML • UML use cases are a means for informal specification • Describe the system’s behaviour • Suitable for communication with customers • Parts of use case: • name • main flow • alternative flows • pre and post conditions • . . . KeY Workshop, June 7, 2004 – p.3/26
Example: Automated Teller Machine • In this case study, look only at withdrawal: • Main flow: insert card, enter PIN, request cash amount, get money, return card • Alternative flows: wrong PIN, cash amount exceeds balance, etc. • In this work: put a more precise informal description in the post condition of the use case. . . KeY Workshop, June 7, 2004 – p.4/26
Post Condition of Withdraw • If the customer entered the PIN on the Card, and the customer’s balance was greater or equal to the requested amount, then the customer got the requested amount and the amount was deducted from the balance. • If the customer entered the wrong PIN three times, the card was retained. • If the customer requested too much money, the card was returned to the customer. KeY Workshop, June 7, 2004 – p.5/26
Main Scenario: Sequence Diagram KeY Workshop, June 7, 2004 – p.6/26
Main Scenario: Sequence Diagram ➠ Last Operation (giveAmount) must ensure post condition of use case KeY Workshop, June 7, 2004 – p.6/26
Informal to Formal Specification • Want to give the formal post-condition for the final operation in the scenario, for example operation giveAmount • Guarantee that the formal post-condition of the operation satisfy the informal post-condition of the use case • Problem: • There might be several scenarios of the use case • The final operation can vary for different scenarios ➠ Gather possible scenarios in state chart KeY Workshop, June 7, 2004 – p.7/26
State Chart for ATM Example KeY Workshop, June 7, 2004 – p.8/26
State Chart for ATM Example • A: givePin(userPin1)[userPin1 = cardPin1] KeY Workshop, June 7, 2004 – p.8/26
State Chart for ATM Example • A: givePin(userPin1)[userPin1 = cardPin1] • B: givePin(userPin1)[userPin1 <> cardPin1] KeY Workshop, June 7, 2004 – p.8/26
State Chart for ATM Example • A: givePin(userPin1)[userPin1 = cardPin1] • B: givePin(userPin1)[userPin1 <> cardPin1] • C: [balance >= amount] KeY Workshop, June 7, 2004 – p.8/26
State Chart for ATM Example • A: givePin(userPin1)[userPin1 = cardPin1] • B: givePin(userPin1)[userPin1 <> cardPin1] • C: [balance >= amount] • D: [balance < amount] KeY Workshop, June 7, 2004 – p.8/26
Condition to Satisfy: First Attempt Given a path π : op 1 ( args 1 ) op 2 ( args 2 ) op k ( args k ) s 0 s 1 s 2 s k . . . • Last operation for path: final ( π ) : = op k • Post cond. of last method should ensure post cond. of use case: Post final ( π ) → Post UC KeY Workshop, June 7, 2004 – p.9/26
Condition to Satisfy: First Attempt Given a path π : op 1 ( args 1 ) op 2 ( args 2 ) op k ( args k ) s 0 s 1 s 2 s k . . . • Last operation for path: final ( π ) : = op k • Post cond. of last method should ensure post cond. of use case: wrong! Post final ( π ) → Post UC • Problem: Holds only if we add information about the path taken KeY Workshop, June 7, 2004 – p.9/26
Information about a Path Let Cond ( π ) gather information about the path taken. op 1 a ( args 1 a )[ cond 1 a ] op 2 ( args 2 )[ cond 2 ] s 0 s 1 a s 2 . . . op 1 b ( args 1 b )[ cond 1 b ] s 1 b . . . KeY Workshop, June 7, 2004 – p.10/26
Information about a Path Let Cond ( π ) gather information about the path taken. op 1 a ( args 1 a )[ cond 1 a ] op 2 ( args 2 )[ cond 2 ] s 0 s 1 a s 2 . . . op 1 b ( args 1 b )[ cond 1 b ] s 1 b . . . • For simplicity, take conjunction of guards: Cond ( π ) = cond 1 a ∧ cond 2 KeY Workshop, June 7, 2004 – p.10/26
Information about a Path Let Cond ( π ) gather information about the path taken. op 1 a ( args 1 a )[ cond 1 a ] op 2 ( args 2 )[ cond 2 ] s 0 s 1 a s 2 . . . op 1 b ( args 1 b )[ cond 1 b ] s 1 b . . . • For simplicity, take conjunction of guards: Cond ( π ) = cond 1 a ∧ cond 2 ➠ Restriction: • Guards in state chart do not refer to attribute values • Distinct names for event arguments KeY Workshop, June 7, 2004 – p.10/26
Condition to Satisfy • If we are on this path, the post cond. of the final method ensures that of the use case: Cond ( π ) → ( Post final ( π ) → Post UC ) KeY Workshop, June 7, 2004 – p.11/26
Condition to Satisfy • If we are on this path, the post cond. of the final method ensures that of the use case: Cond ( π ) → ( Post final ( π ) → Post UC ) • or equvialently: ( Cond ( π ) ∧ Post final ( π ) ) → Post UC KeY Workshop, June 7, 2004 – p.11/26
Condition to Satisfy • If we are on this path, the post cond. of the final method ensures that of the use case: Cond ( π ) → ( Post final ( π ) → Post UC ) • or equvialently: ( Cond ( π ) ∧ Post final ( π ) ) → Post UC • Finally, this should be the case for all possible paths π : � � � ( Cond ( π ) ∧ Post final ( π ) ) → Post UC π ∈ Σ KeY Workshop, June 7, 2004 – p.11/26
OCL Post-Condition for giveAmount Context ATMController::giveAmount(amount:long) post: if ( amount <= bank.getBalance(card.getID()) ) then cashDispenser^giveOutCash(amount) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) - amount and card^returnCard() else not cashDispenser^giveOutCash(?) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) and card^returnCard() KeY Workshop, June 7, 2004 – p.12/26
Case Study: Normal Flow • Consider: The “normal flow” with no wrong PIN entered and a sufficient balance • Call this path π 1 . • Combined conditions from guards: Cond ( π 1 ) = ( userPin1 = cardPin ∧ balance >= amount ) • Final operation on π 1 : final ( π 1 ) = giveAmount KeY Workshop, June 7, 2004 – p.13/26
Case Study: Relationship between specifications Need to show: ( Cond ( π 1 ) ∧ Post final ( π 1 ) ) → Post UC KeY Workshop, June 7, 2004 – p.14/26
Case Study: Relationship between specifications Need to show: userPin1 = cardPin and balance >= amount and if ( amount <= bank.getBalance(card.getID()) ) then cashDispenser^giveOutCash(amount) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) - amount and card^returnCard() else not cashDispenser^giveOutCash(?) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) and card^returnCard() implies Post UC . KeY Workshop, June 7, 2004 – p.15/26
Case Study: Relationship between specifications Need to show: userPin1 = cardPin and balance >= amount and cashDispenser^giveOutCash(amount) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) - amount and card^returnCard() implies Post UC . KeY Workshop, June 7, 2004 – p.16/26
Informal Proof 1 userPin1 = cardPin and balance >= amount and cashDispenser^giveOutCash(amount) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) - amount and card^returnCard() ⇓ If the customer entered the PIN on the Card, and the customer’s balance was greater or equal to the requested amount, then the customer got the requested amount and the amount was deducted from the balance. KeY Workshop, June 7, 2004 – p.17/26
Informal Proof 2 userPin1 = cardPin and balance >= amount and cashDispenser^giveOutCash(amount) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) - amount and card^returnCard() ⇓ If the customer entered the wrong PIN three times, the card was retained. KeY Workshop, June 7, 2004 – p.18/26
Informal Proof 3 userPin1 = cardPin and balance >= amount and cashDispenser^giveOutCash(amount) and bank.getBalance(card.getID()) = bank.getBalance@pre(card.getID()) - amount and card^returnCard() ⇓ If the customer requested too much money, the card was returned to the customer. KeY Workshop, June 7, 2004 – p.19/26
Reflection We have considered whether • every behavior allowed by the formal specification is also allowed according to the informal one We have not yet considered whether • every behavior the informal specification allows is still allowed by the formal one, stated as: � � � ( Cond ( π ) ∧ Post UC ) → Post final ( π ) π ∈ Σ KeY Workshop, June 7, 2004 – p.20/26
Recommend
More recommend
