Grundlagen des Software Engineering Fundamentals of Software Engineering

Transcription

1 Software Engineering Research Group: Processes and Measurement Fachbereich Informatik TU Kaiserslautern Grundlagen des Software Engineering Fundamentals of Software Engineering Winter Term 2011/12 Prof. Dr. Dr. h. c. Dieter Rombach Chapter 4.2: Software Application Engineering Requirements Engineering for Last update: 21/11/2011

2 Goals (ES) for ES The goals of this chapter are to be able to characterize embedded systems (ES) identify and define issues relevant for engineering ES identify requirements categories for ES Use a simple model for documenting functional ES requirements Literature David Parnas and Jan Madey. Functional Documents for Computer Science. Science of Computer Programming, Elsevier, 1995 Stacy J. Prowell, Carmen J. Trammell, Richard C. Linger, and Jesse H. Poore Cleanroom Software Engineering: Technology and Process. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 1

3 Characteristics (ES) Interaction With User always? With environment always! for ES Complex functionality Specific tasks (does not imply trivial!!) Limited memory Application specific control logic Special hardware (ASIC/ FPGA/ Microcontroller) Low power Often battery operated (autonomous) Power issues (heat management) Low manufacturing cost (mass products) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 3

4 Requirements categories (ES) Functional Domain-dependent User-dependent for ES Non-functional Performance Resource consumption (e.g., power) Dependability Safety Reliability Availability Maintainability? Integrity? Inverse All safety critical issues (Design Constraints) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 4

5 Some example properties of interest in software for ES (ES) for ES Functional Real-time (soft hard!): Button X is pressed do task in deadline s. Response to external events (event-driven/reactive): Button X is pressed do task Temporal: safety and liveness Safety: Something bad will never happen Liveness: Something good will eventually happen. Communication and concurrency Heterogeneity Non-functional Performance: Component X processes Y requests / hour Resources: Available memory is 128 KB Dependability: Failure rate of the component 10-4 failures / month E.g., Fault tolerance? Is this really a property / requirement? A means for achieving higher dependability Other means include prevention, removal and forecasting However, fault tolerance is often needed e.g., networked ES Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 5

6 Requirement for ES - A closer look at an ES (ES) for ES Microcontroller / Microprocessor ASIC / FPGA Memory (Software) CMOS Light (Sensor) Electronic shutter (Actuator) A/D (D/A) conversion Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 6

7 Requirement for ES - A closer look to an ES: Block diagram (ES) for ES System input Control Logic (Hardware + Software) D/A System output Actuators Sensor A/D Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 7

8 Requirement for ES - A closer look to an ES: Block diagram (ES) for ES How do we begin? Identify system boundary Interfaces Input Output Define what is true at system boundary Relation between input and output Define constraints on the system Also a relation between input and output Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 8

9 Requirement for ES - Logical model (ES) for ES Monitored value m(t) i(t) Control Logic (Hardware + Software) O(t) D/A Controlled value c(t) Actuators Sensor A/D Output device Input device Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 9

10 (ES) for ES System requirements document Black-box view of the system Description of the environment Constraints from the environment e.g., physical laws Constraints relevant for the system to be built Assumptions Document whose content is defined by mathematical relations Before we continue, Elementary set-theoretic concepts: Relation AH: Set of {Age, Height}: {{20, 170}, {25,170}, {30,180}, {35,185}} Function NA: Set of {Name, Age}: {{A, 20}, {B, 25}, {C, 30}, {D, 35}} A well-behaved relation Domain Range For a function f or a relation r domain Dom (f) or Dom (r) : X-values Dom(AH): {20, 25, 30, 35} For a function f or a relation r range Ran (f) or Ran (r) : Y-values Ran(NA): {20, 25, 30, 35} Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 10

11 4 Variables model (ES) for ES Monitored value m i (t) SOF Controlled value c i (t) O i (t) Actuators Sensor i i (t) Output device Input device Logical System boundary REQ Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 11

12 4 Variables model - Monitored and Controlled variables (ES) for ES Monitored variables: (Sensor) Variables whose values influence output of the machine / system Controlled variables: (Actuator) Variables whose values are determined by the system Exist (are visible) outside the system boundary Often physical quantities Values often vary with time Mathematically Monitored variables m i (t) m(t): R Value m : function assigning a time dependent real value. M(t) : {m 1 (t), m 2 (t),, m n (t)} : Vector of monitored variables Controlled variables c i (t) c(t): R Value c : function assigning a time dependent real value. C(t) : {c 1 (t), c 2 (t),, c n (t)} : Vector of controlled variables Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 12

13 4 Variables model - Input and Output variables (ES) for ES Input variables Input variables i i (t) Variables whose values are the result of measurement of m i (t) Output variables o i (t) Variables whose values are the result of computation by the machine For all ( ) m i (t) there exists ( ) a corresponding i i (t) c i (t) o i (t) Vice-versa need not be true Often i i (t) and o i (t) will be discrete and digital If the machine is HW/SW control logic Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 13

14 4 Variables model - Relations (ES) NATural constraints expressed as a relation between the vectors of monitored variables M(t) and controlled variables C(t) Dom (NAT): values of M(t) Ran (NAT): values of C(t) {M(t), C(t)} NAT if and only if (iff) environment (nature) permits the behavior for ES REQuirements specified as a relation between the vectors of monitored variables M(t) and controlled variables C(t) Dom (REQ): values of M(t) Ran (REQ): values of C(t) {M(t), C(t)} REQ iff system should permit the behavior INput device description is a relation between monitored variables M(t) and Input variables I(t) OUTput device description is a relation between output variables O(t) and controlled variables C(t) SOFtware requirements specified as a relation between Input variables I(t) and output variables O(t) Dom (SOF): values of I(t) Ran (SOF): values of O(t) {I(t), O(t)} SOF iff software should permit the behavior Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 14

15 4 Variables model - Properties (ES) This should ALWAYS be true Dom (REQ) (is a subset of) Dom (NAT) or document is incomplete If (Dom (NAT REQ) = Dom (NAT) Dom (REQ)) also holds then REQ is considered feasible with respect to NAT Else system breaks laws of nature for ES Software behavior is acceptable if M(t), C(t), I(t), O(t) [IN(M(t), I(t)) & SOF(I(t),O(t)) & OUT(O(t), C(t)) & NAT(M(t), C(t))] REQ(M(t), C(t)) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 15

16 4 Variables model - Summary (ES) NAT for ES MON REQ CON IN OUT INPUT SOF OUTPUT Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 16

17 4 Variables models (ES) for ES We now know: What to document in an system requirement specification of embedded systems What properties it must satisfy Completeness, feasibility, acceptability (of software) Abstraction How do we go about documenting this? Natural language Common practice Can be imprecise and ambiguous Critical systems demand usage of formalized notation where syntax and semantics are precisely defined Known example SBS Software cost reduction Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 17

18 Sequence Based (ES) for ES Tag requirements Define system boundary Identify stimuli Identify responses Choice of appropriate abstraction Stimuli and responses could change depending on the level of abstraction Systematic enumeration of Stimuli Sequence Response and Stimuli Sequence equivalence Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 18

19 Sequence Based (ES) for ES Tag requirements Tag 1 Requirements The security alarm has a detector that sends a trip signal when motion is detected 2 The security alarm is activated by pressing the SET button 3 The SET button is illuminated when the security alarm is set 4 If a trip signal occurs while the security alarm is set, a tone (alarm) is emitted 5 A three-digit code must be entered to silence the alarm tone 6 Correct entry of the code deactivates the security alarm 7 If a mistake is made when entering the code, the user must press the CLEAR button before the code can be reentered Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 19

20 Sequence Based (ES) for ES Define system boundary Identify stimuli Stimulus Description Symbol Trace Set Device activator S 2 Trip Signal from detector T 1 BadDigit Incorrect entry of a digit in the code B 7 Clear Clear entry C 7 GoodDigit A digit that is part of the correct entry of the 3-digit code that deactivates the alarm and the device G 5,6 Identify responses Response Description Trace Light On Set button illuminated 3 Light Off Set button not illuminated 6 Alarm On Alarm tone activated 4 Alarm Off Alarm tone deactivated 5 Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 20

21 Sequence Based (ES) for ES Systematic enumeration of Stimuli Sequence Response and Stimuli Sequence equivalence Rule: Do not extend the sequence IF the response is illegal OR IF the sequence is declared equivalent to a previous sequence ELSE extend Sequences of length 0 and 1 Sequence Response Equivalence Trace λ (empty) null D1 S Light On 2, 3 T Illegal D1 B Illegal D1 C Illegal D1 G Illegal D1 D1 The security alarm is initially deactivated Derived requirements Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 21

22 Sequence Based (ES) for ES Systematic enumeration of Stimuli Sequence Response and Stimuli Sequence equivalence Sequences of length 2 Sequence Response Equivalence Trace SS null S D2 ST Alarm On 4 SB null D3 SC null S D4 SG null D5 D2 D3 D4 D5 After the device has been set, the Set button has no further effect until the device has been deactivated The device produces no external response to an erroneous entry The device produces no external response to a Clear entry The device produces no external response to correct entry of a GoodDigit until all three digits of the code have been entered Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 22

23 Sequence Based (ES) Systematic enumeration of Stimuli Sequence Response and Stimuli Sequence equivalence Rule: The enumeration is complete if there are no more sequences to extend for ES Sequences of length 5 Sequence Response Equivalence Trace STGGS null STGG D2 STGGT null STGG D6 STGGB null STB D3 STGGC null ST D4 STGGG Alarm Off Light Off λ 3, 5, 6 Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 23

24 Software cost reduction (SCR) (ES) for ES Developed at the US Naval Research Labs during the development of the A-7 aircraft Tabular representation of state changes Uses 2 of the relations from the 4 variable model (NAT, REQ) Synchronous model One set of inputs processed in a state before processing the inputs at next state One input assumption Only one input changes at a time SCR mainly deals with this part NAT MON REQ MON IN OUT INPUT SOF OUTPUT Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 24

25 Elements of the SCR model (ES) for ES System is a state machine (S, S 0, E m,t) consisting of States S, initial state S 0 E m : set of monitored events T : allowable transitions Function mapping monitored event (e E m ) and the current state (s S) to the next state (s S) System mode class: An equivalence class of system states (a set of states) Values of a mode class are called modes Condition: Predicate defined on a single system state Predicate is often a Boolean-valued function Event: Predicates on two system states Occurrence: An event occurs if a condition changes Conditioned WHEN TRUE: c WHEN FALSE: c becomes False Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 25

26 Types of SCR tables (ES) Variable Tables: Definition of monitored & controlled variable values Mode Condition Table: Definition of modes based on monitored variables for ES Mode Transition Table: Mode transitions described as a function of current mode and monitored variables i.e. (conditioned) monitored events Event Table: Definition of values of a controlled variable given (conditioned) monitored events and modes Functions should be total i.e. defined for all possible inputs Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 26

27 Software Cost (ES) for ES System mvar mset mtrip mnumber[1,2,3] mclear Req Clight calarm cvar I Sof O SW-System Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 27

28 Variable tables monitored variables (ES) mset Event / Condition Values mtrip Event / Condition Values for ES Initial correct digits entered!) when pushes setbutton!) $off$ mtrip = $off$ Initial correct digits entered!) when mtrip = $on$ $on$ $off$ mnumber[i=1..3] mclear Event / Condition Values Event / Condition Values Initial pushes the right digit number pushes the right digit number i!) $F$ pushes clear button!) when mset = $on$ Initial entered a digit!) $on$ $off$ Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 28

29 Variable tables controlled variables (ES) for ES clight Event / Condition Initial = Values $off$ $on$ calarm Event / Condition Initial OR i=1,2,3: mnumber[i] = when $mset$ = $on$ Values $off$ $on$ Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 29

30 Contition table (ES) Describe Modes (= externally visible states) Informal Mode condition table for ES Example of a mode condition table: mode *off* *on* condition mset = $off$ mset = $on$ AND - *passive* mtrip = $off$ AND - *pas_0* - *pas_1* mnumber[1] = $T$ - *pas_2* mnumber[2] = $T$ - *active* mtrip = $on$ AND - *act_0* - *act_1* mnumber[1] = $T$ - *act_2* mnumber[2] = $T$ Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 30

31 Mode transition table (ES) Describe Mode transitions Informal Mode transition matrix for ES Example of mode transition matrix (automobile): input mode * off * * inactive * output mode * off * * inactive nvar = nvar = $on ) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 31

32 Mode transition table (ES) I / O *off* * act_0 * *act_1* *act_2* *pas_0* *pas_1* *pas_2* *off* Req. Categories *act_0* *act_1* for ES r[2] = r[1] = $F$) r[2] = $F$) $on$) = $on$) = $on$) r[3] = = r[1] = r[2] = = r[1] = r[2] = $T$) Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 32

33 Event table (ES) Give time-independent specification of the sw function Mode Conditions *X* Cond 1 Cond 2 Cond 3 for ES mode *off* *pas_0* *pas_1* *pas_2* *act_0* *act_1* *act_2* --- T T T T T T *automatic on* caccelerat e T Conditions!too slow!.!increase speed! T T T T T T T clight $on$ $off$ calarm $on$ $off$ Prof. Dr. Dr. h. c. Dieter Rombach, Fundamentals of Software Engineering, Winter Term 2011/12 33