Lecture 8

1. Lecture 8 OCL, Formal Specification Techniques Pi-Method

2. Review Lecture 7 Constraints and Invariants, OCL • asSet (operation): programs.participants->asSet()->size() • isSent (operator): target obj ^ message • Used in post condition • return boolean • context Subject::hasChanged() post: observer^update(12, 14) Update has been sent to observer (observer has invoked update) post: observer^update(?: Integer, ?: Integer) Actual value does not matter • message (operator): target obj ^^ message • return a set of messages (calls) • context Subject::hasChanged() post: observer^^update(12, 14) Observer can have multiple instances, all the calls match update(12,14) for all the intances during hasChaned() operations are returned

3. Clarification Continue • Flightsiterate (f : Flight; answer : Set(Flight) = Set{ } | • Collection constants • Set {1, 2, 5, 88 } • Bag {1, 3, 4, 5, 3} • Collection Type Expressions • Set (Customer) • Sequence(Set(ProgramPartners))

4. Roadmap for Today • OCL examples • Formal specification techniques (FST) • Break • Pi-Method

5. OCL • Formal Specification Language, Precise • Easy to read • Part of the UML standard, use with class diagram, state diagram

6. OCL examples A vehicle owner must be at least 18 years old context Vehicle inv: self. owner. age >= 18 context Person inv: self.age>= 18

7. OCL examples A car owner must be at least 18 years old context Car inv: self.owner.age>= 18

8. OCL examples Nobody has more than 3 vehicles context Person inv: self.fleet->size() <= 3 or change multiplicity

9. OCL examples All cars of a person are black context Person inv: self.fleet->forAll (v | v.colour = Colour::black)

10. OCL examples Nobody has more than 3 black vehicles context Person inv: self.fleet->select(v | v.colour = colour::black)->size() <= 3

11. OCL examples context Person inv: self.fleet->iterate(v; acc:Integer=0 | if (v.colour=colour::black) then acc + 1 else accendif) <=3 Nobody has more than 3 black vehicles

12. OCL examples context Car inv: Car.allInstances()->exists(c | c.colour=Colour::red) There is a red car.

13. OCL examples If setAge(. . . ) is called with a non-negative argument then the argument becomes the new value of the attribute age context Person::setAge(newAge:int) pre: newAge>= 0 post: self.age = newAge

14. OCL examples Calling birthday() increments the age of a person by 1 context Person::birthday() post: self.age = self.age@pre + 1

15. OCL examples Calling getName() delivers the value of the attribute name context Person::getName() post: result = name

16. The role of FSTs in Software Engineering A Formal Specification Technique (FST) consists of a formal specification language and mechanisms for deriving consequences from statements in the language FSTs can be used to: • Prove that a specification is implementable • Prove that an implementation satisfies its specification • Prove properties of system without executing them

17. Using FSTs to support requirements specification Benefits at the requirements phase • Precision and lack of ambiguity enable effective communication • FSTs assist in the early discovery of incomplete and ambiguous specifications • FSTs enable rigorous analysis • verification • validation via challenges • enhance reviews

18. Using FSTs to support design and implementation Benefits at the design phase • Supports effective decomposition of systems and precise specification of interfaces • Supports delaying design decisions through data and behavior refinement FSTs and validation • Specifications can be used to generate effective black box test cases • At requirements and design level, specifications can be animated/executed or statically analyzed FSTs and documentation • Precise, abstract, and analyzable statements of behavior

19. Types of properties that can be investigated with FSTs • Correctness: desired functionality; a refinement is consistent with its specification • Safety: a model/specification does not allow undesired behavior • Liveness: a model/specification will eventually do certain desired things • Security: unauthorized access to sensitive data and programs are not permitted by model • Timeliness: timing constraints

20. Limitations of Formal modeling of software • Formal specifications: • Can say too little or too much; • Can be wrong! • Proofs can be wrong • A formal model is at best an approximation of the real world; mathematical models cannot account for real-world behavior with perfect accuracy • Formal models make assumptions about reality; if these are violated then behavior cannot be predicted using the model • Formal proofs do not correspond to evidence needed to convince human reviewers

21. Formal specification myths • FSTs eliminate the need for testing • FSTs eliminate the need for natural language descriptions • You need a PhD in mathematics to understand FSTs • FSTs guarantee correctness • Only highly critical systems benefit from FSTs • FSTs increase cost of development • FSTs are time-consuming • FSTs lack tools

22. Levels of Rigor • Level 0: No Use of FSTs • Level 1: Use of concepts and notation from discrete math. • Level 2: Use of formalized specification languages with some supporting tools • Level 3: Use of formal specification languages with supporting environments, including theorem proving and proof checking tools.

23. Example of Level 0 specification Calculate the mean average of a set of employee salaries • Read in the List, L, of employee salaries from the Employee file • Sum the values in L in Total • Divide Total by the number of elements in L and output the result

24. Example of a level 1 specification Calculate the mean average of a set of employee salaries inputempsals: list of N(N is the set of natural numbers) outputavg: R (R is the set of real numbers) Pre-condition empsals ≠ emptylist Post-condition avg = ( ∑ i=1 empsals(i))div #empsals #empsals

25. Example of a level 2 specification Calculate the mean average of a set of employee salaries Z specification (in this case avg is formed by carrying out an integer division) sum: seqN→ R sum (Ø) = 0 ∀l : seqΝ● sum (l) = head(l) + sum (tail (l) ) Average empsals?:seqΝ avg! : R avg! = sum (empsals?)div#empsals

26. Choosing appropriate levels of rigor • Justifying designs of critical systems – level 3 • Gain insight into a problem and/or solution – level 2 • Documentation - level 1 • Well-understood problem – level 0

27. Specification qualities • incompleteif it does not provide any information to determine behavior under particular circumstances • impreciseif it does not provide enough information to determine behavior under particular circumstances • ambiguousif behavior under particular circumstances is open to different interpretations • inconsistentif two statements in the specification contradict each other

28. Types of FSTs • Specification approach: model-oriented, property-oriented • Specification perspective: process-oriented, state-oriented, object-oriented, … • Semantic basis: operational semantics, denotational semantics, formal logic,… • Analysis approach: model checking, theorem proving, animation/simulation,... • Types of applicable systems: transformational, reactive,…

29. FST notations FSTs ease the discharge of proof obligations by providing: • Mechanisms for deriving consequences from statements • Calculi for composing and transforming specifications • Abstraction mechanisms

30. Formal Reasoning - Why and What? • Once some properties are specified, many others can be inferred • Reasoning enabled usage of formal models as non-executable prototypes • Provides a systematic way to check certain kinds of oversights • Can show that a detailed design is a correct refinement of a more abstract specification • Formal reasoning is sometimes called a proof.

31. Calculation A train moves at a constant velocity of 60 miles/hr. How far does the train travel in 4 hrs? Distance = velocity * time (definition) = 60 * time (velocity = 60) = 60 * 4 (time = 4) = 240 (Arithmetic) Applies a transitive rule: if a = b and b = c, we can conclude a = c

32. Calculation and Proof • Calculations need not be arithmetic

33. Proof and Laws • Proof is valid only if every step is justified • Laws: predicate describe operators, for simplifying expressions and computing values Example: • Predicate: 2 * n = 6 --- constraining values for variables Law: 0 * n = 0 • ( p  q )  p  q • ( p  q )  (p  r)  p  (q  r)

34. Model-based FSTs • State model, states and their transitions – use set and functions • e.g: Z; VDM (Vienna development method); OO languages • Proof Obligations: • Consistency of state and invariants • Applicability of operations w.r.t. pre-conditions • Effectiveness of operation post-conditions w.r.t. pre-conditions and state invariants. • Discharged by: Logical Deduction

35. Example of a model-based specification

36. Algebraic FSTs Behavior specified solely in terms of desired properties Examples: Larch (http://nms.lcs.mit.edu/Larch/); Declarative programming languages Proof Obligations: • Consistency • Completeness • Conservative extension • Implementation satisfaction Discharge by: • Equational reasoning • Structural induction (e.g., mathematical induction)

37. Example of an algebraic specification ADT STACK sort: intstack uses: elem operations emptystack: intstack push : instackelem  intstack pop : intstack  intstack top : intstack  elem laws for all i : intstack; e : elem pop(push(i, e)) = i top(push(i,e)) = e

38. Logic • Logic is concerned with mechanizing reasoning • Logic is used to determine whether the truth of the conclusion follows necessarily from truth of preceding statements • Logic is used to analyze the form of arguments, not to determine the merits of the argument’s content

39. Propositional logic • A proposition is a statement that is true or false but not both Examples: • The Linus room cooling system in GCCIS is in shut-down mode • The GCCIS SE department Employee file has been created. The following are not propositions: • You will be an expert at the end of this course

40. Model-based semantics for propositional logic • A state is an assignment of truth values (true, false) to boolean variables. • The value of a boolean expression in a state is determined by truth tables. • A boolean expression is satisfied in a state if its value is true in that state. • A boolean expression is satisfiable if there is a state in which it is satisfied. • A boolean expression is valid if it is satisfied in every state. A valid expression is called tautology.

41. Identifying problems in specifications • Formalizing helps identify ambiguities If the inlet valve is open, then the system is switched to OPEN and the outlet valve is closed if the monitoring system is functioning Form 1:invalveopen => (sysfunct => open ⋀ outletclosed) Form 2:invalveopen => (open ⋀ (sysfunct => outletclosed) • Specifications can help frame questions: AlertState => NormalAlert ⋁ practice NormalAlert ⋀ Monitortyped => error1 practice ⋀ MonitorTyped => error1 Q. If the system is in alert state and the operator typed in MONITOR command, would an error1 occur? Q. What events cause an error1?

42. Identifying problems in specifications • Identifying inconsistencies The system is in alert state only when it is waiting for an intruder and is on practice alert alert <=> waiting ⋀ practice If the system is in teaching mode and is on practice alert, then it is in alert state. The system will be in teaching mode and on practice alert and not waiting for an intruder teaching ⋀ practice => alert teaching ⋀ practice ⋀~waiting

43. Predicate logic Terms + Predicate : IsHome(a) • Predicate logic assumes that the world consists of individual objects which may have certain properties and between which certain relations may hold Propositional logic cannot be used to reason about classes of objects For example, from the statements, All monitoring computers are ready. X12 is a monitoring computer. One cannot infer that X12 is ready. using propositional logic

44. Predicates, functions, and formulas • A function maps objects to other objects Example:N x N →N • A predicate is a function that returns a true or false value Example: N x N →boolean • Predicate logic formulas include boolean expressions, and formulas of the form: • ∀a: A● P (unrestricted universal quantifier) • ∀a: A | R● P (restricted universal quantifier) • ∃a: A● P (unrestricted existential quantifier) • ∃a: A | R ● P (restricted existential quantifier)

48. Wild and Crazy Ideas • Why software errors occur? • Do you believe programs can contain no errors ever? • What are the solutions?

49. To Do • Homework 3 Due Friday 9/30 7:00pm • Reading assignment Due Monday 10/3 in class • Aspect Oriented Programming • The way of Z: Chapters 1-3, 8-9