Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering, COMP201 Slide 1 Lectures 9,10 Formal Specifications.

Similar presentations


Presentation on theme: "Software Engineering, COMP201 Slide 1 Lectures 9,10 Formal Specifications."— Presentation transcript:

1 Software Engineering, COMP201 Slide 1 Lectures 9,10 Formal Specifications

2 Software Engineering, COMP201 Slide 2 Formal Specification - Techniques for the unambiguous specification of software Objectives: l To explain why formal specification techniques help discover problems in system requirements l To describe the use of algebraic techniques (for interface specification) and model-based techniques(for behavioural specification) l To introduce Abstract State Machine Model

3 Software Engineering, COMP201 Slide 3 Formal methods l Formal specification is part of a more general collection of techniques that are known as ‘formal methods’ COMP313 “Formal Methods” These are all based on mathematical representation and analysis of software l Formal methods include Formal specification Specification analysis and proof Transformational development Program verification

4 Software Engineering, COMP201 Slide 4 Acceptance of formal methods l Formal methods have not become mainstream software development techniques as was once predicted Other software engineering techniques have been successful at increasing system quality. Hence the need for formal methods has been reduced Market changes have made time-to-market rather than software with a low error count the key factor. Formal methods do not reduce time to market The scope of formal methods is limited. They are not well-suited to specifying and analysing user interfaces and user interaction Formal methods are hard to scale up to large systems

5 Software Engineering, COMP201 Slide 5 Use of formal methods l Their principal benefits are in reducing the number of errors in systems so their main area of applicability is critical systems: Air traffic control information systems, Railway signalling systems Spacecraft systems Medical control systems l In this area, the use of formal methods is most likely to be cost-effective l Formal methods have limited practical applicability

6 Software Engineering, COMP201 Slide 6 Specification in the software process l Specification and design are inextricably mixed. l Architectural design is essential to structure a specification. l Formal specifications are expressed in a mathematical notation with precisely defined vocabulary, syntax and semantics.

7 Software Engineering, COMP201 Slide 7 Specification and design

8 Software Engineering, COMP201 Slide 8 Specification in the software process

9 Software Engineering, COMP201 Slide 9 Specification techniques l Algebraic approach The system is specified in terms of its operations and their relationships l Model-based approach The system is specified in terms of a state model that is constructed using mathematical constructs such as sets and sequences. Operations are defined by modifications to the system’s state

10 Software Engineering, COMP201 Slide 10 Formal specification languages ASML - Abstract State Machine Language Yuri. Gurevich, Microsoft Research, 2001

11 Software Engineering, COMP201 Slide 11 Use of formal specification l Formal specification involves investing more effort in the early phases of software development This reduces requirements errors as it forces a detailed analysis of the requirements l Incompleteness and inconsistencies can be discovered and resolved !!! Hence, savings as made as the amount of rework due to requirements problems is reduced

12 Software Engineering, COMP201 Slide 12 Development costs with formal specification

13 Software Engineering, COMP201 Slide 13 1. Interface specification l Large systems are decomposed into subsystems with well-defined interfaces between these subsystems l Specification of subsystem interfaces allows independent development of the different subsystems l Interfaces may be defined as abstract data types or object classes The algebraic approach to formal specification is particularly well-suited to interface specification

14 Software Engineering, COMP201 Slide 14 Sub-system interfaces

15 Software Engineering, COMP201 Slide 15 The structure of an algebraic specification sort imports < LIST OF SPECIFICATION NAMES > Informal description of the sort and its operations Operation signatures setting out the names and the types of the parameters to the operations defined over the sort Axioms defining the operations over the sort < SPECIFICATION NAME > (Generic Parameter) introduction description signature axioms

16 Software Engineering, COMP201 Slide 16 Behavioural specification l Algebraic specification can be cumbersome when the object operations are not independent of the object state l Model-based specification exposes the system state and defines the operations in terms of changes to that state

17 Software Engineering, COMP201 Slide 17 OSI reference model Application Model-based specification Algebraic specification

18 Software Engineering, COMP201 Slide 18 Abstract State Machine Language (AsmL) l AsmL is a language for modelling the structure and behaviour of digital systems l AsmL can be used to faithfully capture the abstract structure and step-wise behaviour of any discrete systems, including very complex ones such as: Integrated circuits, software components, and devices that combine both hardware and software

19 Software Engineering, COMP201 Slide 19 Abstract State l An AsmL model is said to be abstract because it encodes only those aspects of the system’s structure that affect the behaviour being modelled The goal is to use the minimum amount of detail that accurately reproduces (or predicts) the behaviour of the system l Abstraction helps us reduce complex problems into manageable units and prevents us from getting lost in a sea of details AsmL provides a variety of features that allow you to describe the relevant state of a system in a very economical, high-level way

20 Software Engineering, COMP201 Slide 20 Abstract State Machine and Turing Machine l An abstract state machine is a particular kind of mathematical machine, like the Turing machine (TM) l But unlike a TM, ASMs may be defined a very high level of abstraction l An easy way to understand ASMs is to see them as defining a succession of states that may follow an initial state

21 Software Engineering, COMP201 Slide 21 State transitions l The behaviour of a machine (its run) can always be depicted as a sequence of states linked by state transitions Moving from state A to state B is a state transition paint in green paint in red A B

22 Software Engineering, COMP201 Slide 22 Configurations l Each state is a particular “configuration” of the machine l The state may be simple or it may be very large, with complex structure l But no matter how complex the state might be, each step of the machine’s operation can be seen as a well-defined transition from one particular state to another

23 Software Engineering, COMP201 Slide 23 Evolution of state variables paint in green paint in red A B We can view any machine’s state as a dictionary of (Name, Value) pairs, called state variables (Colour, Red) is a variable, where “Colour” is the name of variable, “Red” is the value

24 Software Engineering, COMP201 Slide 24 Evolution of state variables l Names are given by the machine’s symbolic vocabulary l Values are fixed elements, like numbers and strings of characters The run of a machine is a series of states and state transitions that results form applying operations to each state in succession

25 Software Engineering, COMP201 Slide 25 Example Diagram shows the run of a machine that models how orders might be processed S 1 Mode = “Initial” Orders = 0 Balance = £0 InitialiseProcess All Orders S 3 Mode = “Final” Orders = 0 Balance = £500 S 2 Mode = “Active” Orders = 2 Balance = £200 Each transition operation: can be seen as the result of invoking the machine’s control logic on the current state calculates the subsequence state as output

26 Software Engineering, COMP201 Slide 26 Control Logic The machine’s control logic behaves like a fix set of transition rules that say how state may evolve We can think of the control logic as a text that precisely specifies, for any given state, what the values of the machine’s variables will be in the following step Typical form of the operational text is: “ if condition then update ”

27 Software Engineering, COMP201 Slide 27 Control Logic as a Black Box l The two dictionaries S 1 and S 2 have the same set of keys, but the values associated with each variable name may differ between S 1 and S 2 The Machine’s Control Logic … if mode = “Initial” then mode := “Active” mode“Initial” orders0 balance£0 Mode“Active” orders2 balance£200 input output The machine control logic is a black box that takes as input a state dictionary S 1 and gives as output a new dictionary S 2

28 Software Engineering, COMP201 Slide 28 Run of the Machine l The run of the machine can be seen as what happens when the control logic is applied to each state in turn l The run starts form initial state S 1  S 2  S 3  … S 1 is given to the black box yielding S 2, processing S 2 results in S 3, and so on … l When no more changes to state are possible, the run is complete

29 Software Engineering, COMP201 Slide 29 Update operations l We use the symbol “: =” (reads as “gets”) to indicate the value that a name will have in the resulting state For example: mode:=“Active” l Update can be seen only during the following step (this is in contrast to Java, C, Pascal, …) l All changes happen simultaneously, when you moving from one step to another. Then, all updates happen at once.(atomic transaction)

30 Software Engineering, COMP201 Slide 30 Programs Example 1. Hello, world Main() step WriteLine(“hello, world!”) ASML uses indentations to denote block structure, and blocks can be places inside other blocks Statement block affect the scope of variables Whitespace includes blanks and new-line character, ASML does not recognize tab character for indentation !!!!!!! An operation names Main() gives the top-level operational definition of the model (Main() is like main() in Java and C )

31 Software Engineering, COMP201 Slide 31 The Executable Specification Language - ASML Compiler asmlc [name of the program] !!! Use D drive at the University Laboratories !!! Example D:\>asmlc test.asml D:\> test.exe D:\> test.exe >output_file.txt

32 Software Engineering, COMP201 Slide 32 I. Steps The general syntax for steps is Step [label] [stopping-condition] statement block l a statement block consists of indented statement that follow l a label is an optional string, number of identifier followed by a colon (“:”) l stopping condition is any these forms: until fixpoint until expression while expression A step can be introduced independently or as part of sequence of steps in the form: step …

33 Software Engineering, COMP201 Slide 33 Stopping for fixed point “until fixed point” enum EnumMode Initial Started Finished var mode = Initial var count = 0 Main() step until fixpoint if mode = Initial then mode :=Started count:=1 if mode = Started and count < 10 then count:= count+1 if mode = Started and count >=10 then mode:= Finished Initial Started Finished if count < 10 then count:= count+1 count  10 count:= 1

34 Software Engineering, COMP201 Slide 34 Stopping for conditions “while” & “until” while expression until expression var x as Integer = 1 Main() step while x < 10 WriteLine(x) x:= x + 1 var x as Integer = 1 Main() step until x > 9 WriteLine(x) x:= x + 1 Running each of these examples produces nine steps. It will print numbers: 1,2,3,4,5,6,7,8 and 9 as output Either while or until may be used to give an explicit stopping condition for iterated sequential steps of the machine.

35 Software Engineering, COMP201 Slide 35 Conditions eq= ne  lt < gt > in  notin  subset  superset  subseteq  superseteq 

36 Software Engineering, COMP201 Slide 36 Sequences of steps l The syntax step … step … indicates a sequence of steps that will be performed in order Labels after the “step” keyword are optional but helpful as documentation.

37 Software Engineering, COMP201 Slide 37 Be wary ! l Be wary of introducing unnecessary steps l This can occur if two operations are really not order-dependent but are given as two sequential steps, regardless l It is very easy to fall into this trap, since most people are used to the sequential structures used by other programming languages

38 Software Engineering, COMP201 Slide 38 Iteration over collections Another common idiom for iteration is to do one step per element in some finite collection such as a set or sequence step foreach ident 1 in expr 1, ident 2 in expr 2 … statement-block myList = [1,2,3] Main() step foreach i in myList WriteLine (i) Sequential, step-based iteration is available for sets as well as sequences, but in the case of sets, the order is not specified

39 Software Engineering, COMP201 Slide 39 Guidelines for using steps SituationYou choose … operations occur in a fixed order sequence of steps each operation must be done in order iterated steps with stopping condition “while”,“until” operations must be done in sequence, one after another iteration over collection “foreach” operations can be done without order iteration over collection “forall” Repeat an operation until no more changes occur fixed-point stopping condition “until fixed point”

40 Software Engineering, COMP201 Slide 40 II. Updates “How are variables updated?” l A program defines state variables and operations l The most important concept is that state is a dictionary of (name,value) pairs l Each name identifies an occurrence for state variables Operations may propose new values for state variables But effect of these changes is only visible in subsequent step

41 Software Engineering, COMP201 Slide 41 The update statement Update symbol “: =” (reads as “gets”) var x = 0 var y = 1 Main() step WriteLine(“In the first step, x =” + x) // x is 0 WriteLine (“In the first step, y =” + y) // y is 1 x:=2 step // updates occur here WriteLine(“In the second step, x =” + x)//x is 2 WriteLine(“In the second step, y =” + y)//y is 1

42 Software Engineering, COMP201 Slide 42 Delayed effect of updates Updates don’t actually occur until the step following the one in which they are written var x = 0 var y = 1 Main() step WriteLine(“In the first step, x =” + x) // x is 0 WriteLine(“In the first step, y =” + y) // y is 1 step x:=2 WriteLine (“In the second step, x =” + x) // x is 0 step WriteLine (“In the third step, x =” + x) // x is 2

43 Software Engineering, COMP201 Slide 43 When updates occur in C, Javain ASML temp = x x = y y = temp step x:= y y:=x Swapping values l All updates given within a single step occur simultaneously at the end of the step. l Conceptually, the updates are applied “in between” the steps.

44 Software Engineering, COMP201 Slide 44 Consistency of updates The order within a step does not matter, but all of updates in the step must be consistent None of the updates given within a step may contradict each other If updates do contradict, then they are called “inconsistent updates” and an error occur Inconsistent updateError: CLASH in the update set step x:=1 x:=2 we don’t know which of the two should take effect

45 Software Engineering, COMP201 Slide 45 Total and partial updates l An update of the variable can either be total or partial l Total update is a simple replacement of variable’s value with a new value l Partial updates apply to variables that have structure l The left hand side of the update operation “ X : = val ” indicates whether the update is total or partial

46 Software Engineering, COMP201 Slide 46 Total update of a set-valued variable 1. The variable Students was, initially, an empty set 2. It was then updated to contain the names of the four students 3. Update became visible in the second step as the finial roster var Students as Set of String = {} Main() step WriteLine (“The initial roster is = ” + Students) Students := {“Bill”, “Carol”, “Ted”, “Alice”} step WriteLine (“The final roster is = ” + Students)

47 Software Engineering, COMP201 Slide 47 Partial update of a set-valued variable l “ X : = val ” is update operation l If X ends with an index form, then the update is partial l If X ends with a variable name, then the update is total var Students as Set of String = {} Main() step WriteLine (“The initial roster is = ” + Students) Students(“Bill”) := true Students(“Carol”) := true Students(“Ted”) := true Students(“Alice”) := true step WriteLine (“The final roster is = ” + Students)

48 Software Engineering, COMP201 Slide 48 Updating a set-valued variable l Updating the set Students with updating statement (*) removes “Bill ” from the set l The update is partial in the sense that other students may be added to the set Students in the same step without contradiction var Students as Set of String = {} Main() step WriteLine (“The initial roster is = ” + Students) Students := {“Bill”, “Carol”, “Ted”, “Alice”} step WriteLine (“The current roster is = ” + Students) Students ( “Bill”) := false // ( * ) step WriteLine (“The final roster is = ” + Students)


Download ppt "Software Engineering, COMP201 Slide 1 Lectures 9,10 Formal Specifications."

Similar presentations


Ads by Google