Lecture 08: Scenarios and Use Cases

Transcription

1 Introduction evelopment Process, Metrics Requirements ngineering rchitecture & esign onstructive Models Testing, Formal Verification Invited Talks Wrap-Up L 1: 20.4., Mo T 1: 23.4., o L 2: 27.4., Mo L 3: 30.4., o L 4: 4.5., Mo T 2: 7.5., o L 5: 11.5., Mo , o L 6: 18.5., Mo L 7: 21.5., o , Mo , o T 3: 1.6., Mo , o L 8: 8.6., Mo L 9: 11.6., o L10: 15.6., Mo T 4: 18.6., o L11: 22.6., Mo L12: 25.6., o L13: 29.6., Mo T 5: 2.7., o L14: 6.7., Mo L15: 9.7., o L16: 13.7., Mo L17: 16.7., o T 6: 20.7., Mo L18: 23.7., o lbert-ludwigs-universität Freiburg, Germany Prof. r. ndreas Podelski, r. ernd Westphal Lecture 08: Scenarios and Use ases Softwaretechnik / Software-ngineering 4/ Sprelim ontents & Goals Last Lecture: onsistency, ompleteness, etc. for ecision Tables. This Lecture: ducational Objectives: apabilities for following tasks/questions. What is a scenario/an anti-scenario? What is included in a use case? In a use case diagram? What is the abstract syntax of this Live Sequence hart (LS)? Which are the cuts and firedsets of this LS? onstruct the T of a given LS body. Given a set of LSs, which scenario/anti-scenario/requirement is formalised by them? Formalise this positive scenario/anti-scenario/requirement using LSs. ontent: Scenarios in Requirements ngineering User Stories; Use ases and iagrams Live Sequence harts Scenarios 2/78 5/78 You re Here 3/78

2 Suserstories 10/78 back side of file card: (acceptance) test case(s) how to tell whether the user story has been realised. effort, estimated by developers, priority (from 1 (highest) to 10 (lowest)) assigned by customer, unique identifier (e.g. unique number), and in addition: s a [role] I want [something] so that [benefit]. Per user story, one file card with the user story, e.g. following the pattern: User Story is a concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software. User Stories (eck, 1999) Sscen 7/78 (i) fter switching on, insert no money. (ii) Press the tea button. (iii) Get a tea. (iv) Get 100e change. Negative scenario: (iv) Get 50 cent change. (iii) Get a softdrink. (ii) Press the softdrink button. (i) Insert one 1 euro and one 50 cent coin. Positive scenario: xample: Vending Machine Suserstories Sscen Notations for Scenarios The idea of scenarios (sometimes without negative or anti-scenarios) (re-)occurs in many process models or software development approaches. First prominent recognition: OOS (Jacobson, 1992) In the following, we will discuss two and a half notations (in increasing formality): User Stories (part of xtreme Programming) Use ases and Use ase iagrams (OOS) Sequence iagrams (here: Live Sequence harts (amm and Harel, 2001)) 8/78 User Stories: iscussion Proposed card layout (front side): priority unique identifier, name estimation s a [role] I want [something] so that [benefit]. risk real effort easy to create close contact to customer customers are usually not trained in writing requirements may get difficult to keep overview over whole system to be developed strong dependency on competent developers estimation of effort may be difficult not easy to cover non-functional requirements and restrictions (alzert, 2009) 11/ Suserstories Sspeclang Recall: User Stories Natural Language Patterns Natural language requirements can be written using,,,,, F where clarifies when and under what conditions the activity takes place is MUST (obligation), SHOUL (wish), or WILL (intention); also: MUST NOT (forbidden) is either the system or the concrete name of a (sub-)system one of three possibilities: does, description of a system activity, offers, description of a function offered by the system to somebody, is able if, usage of a function offered by a third party, under certain conditions extensions, in particular an object F the actual process word (what happens) (Rupp and die SOPHISTen, 2009) xample: fter office hours (= ), the system (= ) should (= ) offer to the operator (= ) a backup (= F) of all new registrations to an external medium (= ). 37/90 9/78 12/78

3 Suc Use ases Use ase xample name uthentication goal the client wants access to the TM pre-condition the TM is operational, the welcome screen is displayed, card and PIN of client are available post-condition client accepted, services of TM are offered post-cond. in exceptional case access denied, card returned or withheld, welcome screen displayed actors client (main actor), bank system open questions none normal case 1. client inserts card 2. TM read card, sends data to bank system 3. bank system checks validity 4. TM shows PIN screen 5. client enters PIN 6. TM reads PIN, sends to bank system 7. bank system checks PIN 8. TM accepts and shows main menu exception case 2a card not readable 2a.1 TM displays card not readable 2a.2 TM returns card 2a.3 TM shows welcome screen 13/78 16/78 (-by-sa 4.0, irk Ingo Franke) Suc Suc open questions none normal case 1. client inserts card 2. TM read card, sends data to bank system 3. bank system checks validity 4. TM shows PIN screen 5. client enters PIN 6. TM reads PIN, sends to bank system 7. bank system checks PIN 8. TM accepts and shows main menu exception case 2a card not readable 2a.1 TM displays card not readable 2a.2 TM returns card 2a.3 TM shows welcome screen exception case 2b card readable, but not TM card exception case 2c no connection to bank system exception case 3a card not valid or disabled exception case 5a client cancels exception case 5b client doesn t react within 5s exception case 6a no connection to bank system exception case 7a first or second PIN wrong exception case 7b third PIN wrong (Ludewig and Lichter, 2013; V-Modell XT, 2006) 14/78 17/78 (-by-sa 4.0, irk Ingo Franke) Suc Use ase: efinition use case sequence of interactions between an actor (or actors) and a system triggered by a specific actor, which produces a result for an actor. (Jacobson, 1992) participants: the system and at least one actor, actor: an actor represents what interacts with the system. n actor is a role, which a user or an external system may assume when interacting with the system under design. ctors are not part of the system, thus they are not described in detail. ctions of actors are non-deterministic (possibly constrained by domain model). use case is triggered by a stimulus as input by the main actor. use case is goal oriented, i.e. the main actor wants to reach a particular goal. use case describes all interactions between the system and the participating actors that are needed to achieve the goal (or fail to achieve the goal for reasons). use case ends when the desired goal is achieved, or when it is clear that the desired goal cannot be achieved. 15/78 Use ase iagrams 18/78

4 Sequence iagrams Sucd use case use case extends uses or include use case use case More notation: client bank system uthenticate Use ase iagrams 19/78 22/ Ssd Sucd Use ase iagram: igger xamples TM info services extend print statement [not auth.] query balance [print statement] include transactions get cash include basic services extend define standing order include authentication (Ludewig and Lichter, 2013) Recall: Vending Machine xample Positive scenario: (i) Insert one 1 euro and one 50 cent coin. (ii) Press the softdrink button. (iii) Get a softdrink. (iv) Get 50 cent change. Negative scenario: (i) fter switching on, insert no money. (ii) Press the tea button. (iii) Get a tea. (iv) Get 100e change. notation understandable by customer precision complexity of definition natural language feels like visual formalism (temporal) logic /78 23/ Ssd Sucd Use ase iagram: igger xamples (V-Modell XT, 2006) 21/78 History Most Prominent: Sequence iagrams with long history: Message Sequence harts, standardized by the ITU in different versions (ITU Z.120, 1st edition: 1993), often accused to lack a formal semantics. Sequence iagrams of UML 1.x (one of three main authors: I. Jacobson) Most severe drawbacks of these formalisms: unclear interpretation: example scenario or invariant? unclear activation: what triggers the requirement? unclear progress requirement: must all messages be observed? conditions merely comments no means (in language) to express forbidden scenarios msc (ITU-T, 2011) 24/78

5 Msg L L is a set of messages with (l,,l ) Msg only if (l,l ) ; message (l,,l ) is called instantaneous iff l l and asynchronous otherwise, ond (2 L \ ) Φ() is a set of conditions with (L,φ) ond only if l l for all l l L, LocInv L {, } Φ() L {, } is a set of local invariants with (l,ι,φ,l,ι ) LocInv only if l l, : exclusive, : inclusive, Θ : L Msg ond LocInv {hot,cold} assigns to each location and each element a temperature. I = {I1,...,In} is a partitioning of L; elements of I are called instance line, a partial order L L, a symmetric simultaneity relation L L disjoint with, i.e. =, L is a finite, non-empty of locations with where ((L,, ),I,Msg,ond,LocInv,Θ) efinition. [LS ody] Let be a set of events and a set of atomic propositions. n LS body over and is a tuple LS ody: bstract Syntax Ssd ation aint servation nstraint :User :System ode d=duration {d..3*d} ardout {0..13} t=now OK {t..t+3} Unlock (OMG, 2007) sd Userccepted LS: L M: invariant I: strict Ss of UML 2.x address some issues, yet the standard exhibits unclarities and even contradictions (Harel and Maoz, 2007; Störrle, 2003) For the lecture, we consider Live Sequence harts (LSs) (amm and Harel, 2001; Klose, 2003; Harel and Marelly, 2003), who have a common fragment with UML 2.x Ss (Harel and Maoz, 2007) Modelling guideline: stick to that fragment. Thus: Live Sequence harts 25/78 28/ Ssd The Plan LSs as another formal software specification: LS body abstract and concrete syntax, xcursion: üchi automata (T), T construction: uts, Firedsets, Transitions, Language of an LS body, Putting it all together: ctivation modes, Pre-charts, xistential and universal LSs, Some bigger LS examples, iscussion of MS issues named on previous slide. Some concluding notes on the block Requirements ngineering. Next block: design, architecture... LS ody xample L : l1,0 l1,1 l1,2 l1,3, l1,2 l1,4, l2,0 l2,1 l2,2 l2,3, l3,0 l3,1 l3,2, l1,1 l2,1, l2,2 l1,2, l2,3 l1,3, l3,2 l1,4, l2,2 l3,1, I = {{l1,0,l1,1,l1,2,l1,3,l1,4},{l2,0,l2,1,l2,2,l2,3},{l3,0,l3,1,l3,2}}, Msg = {(l1,1,,l2,1),(l2,2,,l1,2),(l2,2,,l3,1),(l2,3,,l1,3),(l3,2,,l1,4)} ond = {({l2,2},)}, LocInv = {(l1,1,,,l1,2, )} 26/78 29/78 Live Sequence harts: Syntax (ody) LS ody xample L : l1,0 l1,1 l1,2 l1,3, l1,2 l1,4, l2,0 l2,1 l2,2 l2,3, l3,0 l3,1 l3,2, l1,1 l2,1, l2,2 l1,2, l2,3 l1,3, l3,2 l1,4, l2,2 l3,1, I = {{l1,0,l1,1,l1,2,l1,3,l1,4},{l2,0,l2,1,l2,2,l2,3},{l3,0,l3,1,l3,2}}, Msg = {(l1,1,,l2,1),(l2,2,,l1,2),(l2,2,,l3,1),(l2,3,,l1,3),(l3,2,,l1,4)} ond = {({l2,2},)}, LocInv = {(l1,1,,,l1,2, )} l1,0 l2,0 l3,0 l1,1 l2,1 l1,2 l2,2 l3,1 l1,3 l1,4 l2,3 l3,2 27/78 29/78

6

7 I1 nd The Other Way Round L : I = Msg = ond = LocInv = 30/78 oncrete vs. bstract Syntax L : l1,0 l1,1 l1,2 l1,3, l1,2 l1,4, l2,0 l2,1 l2,2 l2,3, l3,0 l3,1 l3,2, l1,1 l2,1, l2,2 l1,2, l2,3 l1,3, l3,2 l1,4, l2,2 l3,1, I = {{l1,0,l1,1,l1,2,l1,3,l1,4},{l2,0,l2,1,l2,2,l2,3},{l3,0,l3,1,l3,2}}, Msg = {(l1,1,,l2,1),(l2,2,,l1,2),(l2,2,,l3,1),(l2,3,,l1,3),(l3,2,,l1,4)} ond = {({l2,2},)}, LocInv = {(l1,1,,,l1,2, )} I2 31/78 Note: if messages in a chart are cyclic, then there doesn t exist a partial order (so such charts don t even have an abstract syntax). (l1,,l2) Msg : l {l1,l2}. an instance head, i.e. l is minimal wrt., or a message, i.e. then there is a location l simultaneous to l, i.e. l l, which is the location of a local invariant, i.e. (l1,ι1,φ,l2,ι2) LocInv : l {l1,l2}, or a condition, i.e. (L,φ) ond : l L, or For each location l L, if l is the location of ondedness/no floating conditions: (could be relaxed a little if we wanted to) Well-Formedness LocInv = {(l1,1,,,l1,2, )} ond = {({l2,2},)}, Msg = {(l1,1,,l2,1),(l2,2,,l1,2),(l2,2,,l3,1),(l2,3,,l1,3),(l3,2,,l1,4)} L : l1,0 l1,1 l1,2 l1,3, l1,2 l1,4, l2,0 l2,1 l2,2 l2,3, l3,0 l3,1 l3,2, l1,1 l2,1, l2,2 l1,2, l2,3 l1,3, l3,2 l1,4, l2,2 l3,1, I = {{l1,0,l1,1,l1,2,l1,3,l1,4},{l2,0,l2,1,l2,2,l2,3},{l3,0,l3,1,l3,2}}, LS ody xample 29/78 32/78

8 References 77/78 References alzert, H. (2009). Lehrbuch der Softwaretechnik: asiskonzepte und Requirements ngineering. Spektrum, 3rd edition. eck, K. (1999). xtreme Programming xplained mbrace hange. ddison-wesley. amm, W. and Harel,. (2001). LSs: reathing life into Message Sequence harts. Formal Methods in System esign, 19(1): Harel,. and Maoz, S. (2007). ssert and negate revisited: Modal semantics for UML sequence diagrams. Software and System Modeling (SoSyM). To appear. (arly version in SSM 06, 2006, pp ). Harel,. and Marelly, R. (2003). ome, Let s Play: Scenario-ased Programming Using LSs and the Play-ngine. Springer-Verlag. ITU-T (2011). ITU-T Recommendation Z.120: Message Sequence hart (MS), 5 edition. Jacobson, I. (1992). Object Oriented Software ngineering Use ase riven pproach. M Press. Klose, J. (2003). LSs: Graphical Formalism for the Specification of ommunication ehavior. Ph thesis, arl von Ossietzky Universität Oldenburg. Ludewig, J. and Lichter, H. (2013). Software ngineering. dpunkt.verlag, 3. edition. OMG (2007). Unified modeling language: Superstructure, version Technical Report formal/ Rupp,. and die SOPHISTen (2014). Requirements-ngineering und -Management. Hanser, 6th edition. Störrle, H. (2003). ssert, negate and refinement in UML-2 interactions. Technical Report TUM-I0323, Technische Universität München. V-Modell XT (2006). V-Modell XT. Version /78