Lecture 10: Requirements Engineering. Wrap-Up. Softwaretechnik / Software-Engineering. Pre-Charts (Again)

Transcription

1 Softwaretechnik / Software-Engineering Lecture 10: Requirements Engineering Wrap-Up Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany Pre-Charts (Again) 4/ Sblockcontent Topic Area Requirements Engineering: Content VL 6 Introduction Requirements Specification Desired Properties Kinds of Requirements Analysis Techniques Documents Dictionary, Specification Specification Languages Natural Language VL 7 Decision Tables Syntax, Semantics Completeness, Consistency,... VL 8 VL 9 VL 10 Scenarios User Stories, Use Cases Live Sequence Charts Syntax, Semantics Definition: Software & SW Specification Wrap-Up Example: Vending Machine Positive scenario: Buy a Softdrink (i) Insert one 1 euro coin. (ii) Press the softdrink button. (iii) Get a softdrink. LSC: buy softdrink Positive scenario: Get Change (i) Insert one 50 cent and one 1 euro coin. (ii) Press the softdrink button. (iii) Get a softdrink. (iv) Get 50 cent change. LSC: get change chg- Negative scenario: A Drink for Free (i) Insert one 1 euro coin. (ii) Press the softdrink button. (iii) Do not insert any more money. (iv) Get two softdrinks.!! 2/34 5/ Scontent Content Pre-Charts Semantics, once again Requirements Engineering with scenarios Strengthening scenarions into requirements Software, formally Software specification Requirements Engineering, formally Software implements specification LSCs vs. Software Software implements LSCs Scenarios and tests Play In/Play Out Requirements Engineering Wrap-Up Pre-Charts A fulllscl = (PC,MC,ac,am,ΘL) actually consists of pre-chartpc = ((LP, P, P),IP,Msg P,CondP,LocInvP,ΘP) (poss. empty), main-chartmc = ((LM, M, M),IM,Msg M,CondM,LocInvM,ΘM), activation conditionac Φ(C), and mode am {initial, invariant}, strictness flagstrict, chart mode existential (ΘL = cold) or universal (ΘL = hot). Concrete syntax:!! 3/34 6/34

2 Requirements Engineering with Scenarios wherec P 0 andcm 0 are the minimal (or instance heads) cuts of pre- and main-chart. ΘL = hot w W m N0 w 0 = ac ψexit(c P 0 ) ψprog(,cp 0 ) w/1,...,w/m Lang(B(PC)) w m+1 = ψexit(c 0 M ) = w m+1 = ψprog(,c 0 M ) w/m + 2 Lang(B(MC)) w W k m N0 w k = ac ψexit(c P 0 ) ψprog(,cp 0 ) w/k + 1,...,w/m Lang(B(PC)) w m+1 = ψexit(c 0 M ) = w m+1 = ψprog(,c 0 M ) w/m + 2 Lang(B(MC)) ΘL = cold w W m N0 w 0 = ac ψexit(c 0 P ) ψprog(,cp 0 ) w/1,...,w/m Lang(B(PC)) w m+1 = ψexit(c 0 M ) w m+1 = ψprog(,c 0 M ) w/m + 2 Lang(B(MC)) w W k < m N0 w k = ac ψexit(c 0 P ) ψprog(,cp 0 ) w/k + 1,...,w/m Lang(B(PC)) w m+1 = ψexit(c 0 M ) w m+1 = ψprog(,c 0 M ) w/m + 2 Lang(B(MC)) am = initial am = invariant A set of wordsw (C B) ω is accepted by L, denoted byw = L, if and only if activation conditionac Φ(C), and mode am {initial, invariant}, strictness flagstrict, chart mode existential (ΘL = cold) or universal (ΘL = hot). pre-chartpc = ((LP, P, P),IP,Msg P,CondP,LocInvP,ΘP) (poss. empty), main-chartmc = ((LM, M, M),IM,Msg M,CondM,LocInvM,ΘM), A fulllscl = (PC,MC,ac,am,ΘL) actually consists of Pre-Charts!! 6/34 8/34 OK dwater pwater Universal LSC: Example LSC: buy water AM: invariant I: strict User CoinValidator ChoicePanel Dispenser water_in_stock 7/34 OK dwater pwater Universal LSC: Example LSC: buy water AM: invariant I: strict User CoinValidator ChoicePanel Dispenser water_in_stock (!!! ptea! pfillup!) (dsoft! dtea!) 7/34

3 Sre Scontent Content Pre-Charts Semantics, once again Requirements Engineering with scenarios Strengthening scenarions into requirements Software, formally Software specification Requirements Engineering, formally Software implements specification LSCs vs. Software Software implements LSCs Scenarios and tests Play In/Play Out Requirements Engineering Wrap-Up 12/34 Software and Software Specification, formally 13/ Sstrengthen Analysing LSC Requiremnts Requirements on Requirements Specifications A requirements specification should be correct it correctly represents the wishes/needs of the customer, complete all requirements (existing in somebody s head, or a document, or...) should be present, relevant things which are not relevant to the project should not be constrained, consistent, free of contradictions each requirement is compatible with all other requirements; otherwise the requirements are not realisable, neutral, abstract a requirements specification does not constrain the realisation more than necessary, traceable, comprehensible the sources of requirements are documented, requirements are uniquely identifiable, testable, objective the final product can objectively be checked for satisfying a requirement. Correctness and completeness are defined relative to something which is usually only in the customer s head. is is difficult to be sure of correctness and completeness. Dear customer, please tell me what is in your head! is in almost all cases not a solution! It s not unusual that even the customer does not precisely know...! For example, the customer may not be aware of contradictions due to technical limitations. Definition. [LSC Consistency] A set of LSCs{L1,...,Ln} is called consistent if and only if there exists a set of wordsw such that n i=1 W = Lang(Li). Software, formally Definition. Software is a finite descriptions of a (possibly infinite) set S of (finite or infinite) computation paths of the form σ 0 α 1 σ 1 α 2 σ 2 where σi Σ, i N0, is called state (or configuration), and αi A, i N0, is called action (or event). The (possibly partial) function : S S is called interpretation ofs. 12/37 11/34 14/34

4 (CC-by-sa 4.0, Dirk Ingo Franke) Example: Software, formally Software is a finite descriptions of a (possibly infinite) set S of (finite or infinite) computation paths α of the formσ 1 α 0 σ 2 1 σ 2. σi: state/configuration;αi: action/event. 1: public int f( int x, int y ) { 2: x = x + y; 3: y = x / 2; 4: return y; 5:} 15/34 Example: Software, formally Software is a finite descriptions of a (possibly infinite) set S of (finite or infinite) computation paths α of the formσ 1 α 0 σ 2 1 σ 2. σi: state/configuration;αi: action/event. HTML. 1: <html> 2: <head> 3: <title>swt 2016</title> 4: </head> 5: <body/> 6: </html> Example: Software Specification Alphabet: M dispense cash only, C return card only, M C dispense cash and return card. Customer 1: don t care ( ) C.M M ω S1 = M.C C Customer 2: you choose, but be consistent S2 = (M.C) ω or(c.m) ω Customer 3: consider human errors S3 = (C.M) ω 15/34 17/34 Example: Software, formally Software is a finite descriptions of a (possibly infinite) set S of (finite or infinite) computation paths α of the formσ 1 α 0 σ 2 1 σ 2. σi: state/configuration;αi: action/event. HTML. User s Manual. etc. etc. T : room ventilation r1 r2 r3 b button pressed? off ventilation off? on ventilation on? go start ventilation stop stop ventilation 15/34

5 LSC: get change!! chg- Global Invariants. State Machines. 1: public int f( int x, int y ) { 2: x = x + y; 3: y = x / 2; 4: return y; 5:} Global Invariants. x 0 Global Invariants. State Machines. User s Manual. etc. etc. Global Invariants. State Machines. later The Requirements Engineering Problem Formally (Σ A) ω all computation paths overσanda, aka. chaos requirements, all these computation paths are allowed (maybe including refinements) one software which does not satisfy the requirements one software (= set of computation paths) which satisfies the requirements Requirements engineering: Describe/specify the set of the allowed softwares as S. Note: what is not constrained is allowed, usually! Software development: Create one softwares whose computation paths S are all allowed, i.e. S S. Note: different programs in different programming languages may describe the same S. Often allowed: any refinement of ( in a minute; e.g. allow intermediate transitions). 19/34

6 OK I Stestplay Software Specification vs. Software S = {(S0, 0)} σ 0 0 α 0 1 σ 1 0 α 0 2 σ 2 0 M I M σ 1 0 α 1 1 σ 1 1 α 1 2 σ 2 1 σ 2 0 α 2 1 σ 1 2 α 2 2 σ 2 2 (S1, 1)} S1 implements S viai andm S2 implements S viai andm How to Prove that a Software Satisfies an LSC? LSC: buy softdrink LSC: get change chg- SoftwareS satisfies existential LSC L if there existsπ S such that L acceptsw(π). ProveS = L by demonstratingπ. Note: Existential LSCs may hint at test-cases for the acceptance test! ( : as well as (positive) scenarios in general, like use-cases) requirements fixed verification & validation acceptance specified delivered architecture designed integrated modules designed realised (S2, 2)} 20/34 23/ Stestplay LSCs vs. Software How to Prove that a Software Satisfies an LSC? LSC: buy softdrink LSC: get change chg- SoftwareS satisfies existential LSC L if there existsπ S such that L acceptsw(π). ProveS = L by demonstratingπ. Note: Existential LSCs may hint at test-cases for the acceptance test! ( : as well as (positive) scenarios in general, like use-cases) requirements fixed specified architecture designed verification & validation modules designed acceptance delivered integrated realised!! pwater LSC: buy water AM: invariant I: strict User CoinValidator ChoicePanel Dispenser (!!! ptea! pfillup!) water_in_stock (dsoft! dtea!) Universal LSCs (and negative/anti-scenarios!) in general need an exhaustive analysis! (Because they require that the software never ever exhibits the unwanted behaviour.) ProveS = L by demonstrating oneπ such thatw(π) is not accepted by L. dwater 21/34 23/ Stestplay Stestplay (Harel and Marelly, 2003) Pushing It Even Further Software S satisfiesaset of LSCsL1,...,Ln ifandonlyifs = Li forall1 i n. hot w WS w 0 = ac ψexit(c0) = w 0 = ψprog(,c0) w/1 Lang(B(L)) w WS k N0 w k = ac ψexit(c0) = w k = ψhot Cond (,C0) w/k+1 Lang(B(L)) cold w WS w 0 = ac ψexit(c0) w 0 = ψprog(,c0) w/1 Lang(B(L)) w WS k N0 w k = ac ψexit(c0) w k = ψprog(,c0) w/k +1 Lang(B(L)) ΘL am = initial am = invariant Wesaysoftware S satisfies LSCL (withoutpre-chart), denotedbys = L, ifandonlyif we usews to denote the set of words induced by S. w(π) = (σ0 α1),(σ1 α2),(σ2 α3),..., A computation pathπ = σ 0 α 1 σ 1 α 2 σ 2 S of softwares induces the word Σ = (C B), i.e. the states are valuations of the conditions inc, A E!?, i.e. the events are of the forme!,e? (viewed as a valuation ofe!,e?). A softwares is called compatible with LSC L overc ande is if and only if LSCs as Software Specification 22/34 24/34

7 (CC-by-sa 4.0, Dirk Ingo Franke) Swrapup Sttwytt Tell Them What You ve Told Them... Live Sequence Charts (if well-formed) have an abstract syntax: instance lines, messages, conditions, local invariants; mode: hot or cold. From an abstract syntax, mechanically construct its TBA. Pre-charts allow us to specify anti-scenarios ( this must not happen ), contrain activation. AnLSC issatisfied byasoftware S ifandonlyif existential (cold): there is a word induced by a computation path ofs which is accepted by the LSC s pre/main-chart TBA. universal (hot): all words induced by the computation paths ofs are accepted by the LSC s pre/main-chart TBA. Method: discuss (anti-)scenarios with customer, generalise into universal LSCs and re-validate. Example: Software Specification Alphabet: M dispense cash only, C return card only, M C dispense cash and return card. Customer 1: don t care ( ) C.M M ω S1 = M.C C Customer 2: you choose, but be consistent S2 = (M.C) ω or(c.m) ω Customer 3: consider human errors S3 = (C.M) ω 25/34 28/34 Requirements Engineering Wrap-Up 26/ Swrapup Sblockcontent Topic Area Requirements Engineering: Content VL 6 Introduction Requirements Specification Desired Properties Kinds of Requirements Analysis Techniques Documents Dictionary, Specification Specification Languages Natural Language VL 7 Decision Tables Syntax, Semantics Completeness, Consistency,... VL 8 VL 9 VL 10 Scenarios User Stories, Use Cases Live Sequence Charts Syntax, Semantics Definition: Software & SW Specification Wrap-Up Tell Them What You ve Told Them... A Requirements Specification should be correct, complete, relevant, consistent, neutral, traceable, objective. Requirements Representations should be easily understandable, precise, easily maintainable, easily usable. Languages / Notations for Requirements Representations: Natural Language Patterns Decision Tables User Stories Use Cases Live Sequence Charts Formal representations can be very precise, objective, testable, can be analysed for, e.g., completeness, consistency can be verified against a formal design description. (Formal) inconsistency of, e.g., a decision table hints at inconsistencies in the requirements. 27/34 30/34

8 Swrapup Requirements Analysis in a Nutshell Customers may not know what they want. That s in general not their fault! Care for tacit requirements. Care for non-functional requirements / constraints. For requirements elicitation, consider starting with scenarios ( positive use case ) and anti-scenarios ( negative use case ) and elaborate corner cases. Thus, use cases can be very useful use case diagrams not so much. Maintain a dictionary and high-quality descriptions. Care for objectiveness / testability early on. Ask for each requirements: what is the acceptance test? Use formal notations to fully understand requirements (precision), for requirements analysis (completeness, etc.), to communicate with your developers. If in doubt, complement (formal) diagrams with text (as safety precaution, e.g., in lawsuits). 31/34 References Harel, D. and Marelly, R. (2003). Come, Let s Play: Scenario-Based Programming Using LSCs and the Play-Engine. Springer-Verlag. Ludewig, J. and Lichter, H. (2013). Software Engineering. dpunkt.verlag, 3. edition. Rupp, C. and die SOPHISTen (2014). Requirements-Engineering und -Management. Hanser, 6th edition. 34/ Swrapup Literature Recommendation (Rupp and die SOPHISTen, 2014) 32/34 References 33/34