1. Topic 5Summer 2003 1 ICS 52: Introduction to Software Engineering Lecture Notes for Summer Quarter, 2003 Michele Rousseau Topic 5 Partially based on lecture notes written by Sommerville, Richard N. Taylor, André van der Hoek, Dan Frost and Doris Tonne. Duplication of course material for any commercial purpose without the written permission of the lecturers is prohibited

2. Topic 5Summer 2003 2 Today’s Lecture n Problems in RE n Formal Methods

3. Topic 5Summer 2003 3 Some Problems with RE n Social and organisational factors –Can dominate the system reqs –Not 1 viewpoint, but many –No systematic way to tackle these factors n Example –Consider a system which allows senior management to access information without going through middle managers Managerial responsibilities. Managers may have no uninterrupted time where they can learn to use the system Organisational resistance. Middle managers who will be made redundant may deliberately provide misleading or incomplete information so that the system will fail n Ethnographic studies can help

4. Topic 5Summer 2003 4 Domain Requirements n Derived from the application domain and describe system characterisics and features that reflect the domain n Example :Library System –There shall be a standard user interface to all databases which shall be based on the Z39.50 standard. –Because of copyright restrictions, some documents must be deleted immediately on arrival. Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer.

5. Topic 5Summer 2003 5 Domain requirements problems n Understandability –Requirements are expressed in the language of the application domain –This is often not understood by software engineers developing the system n Implicitness –Domain specialists understand the area so well that they do not think of making the domain requirements explicit

6. Topic 5Summer 2003 6 Requirements change management n Should apply to all proposed changes to the requirements n Principal stages –Problem analysis. Discuss requirements problem and propose change –Change analysis and costing. Assess effects of change on other requirements –Change implementation. Modify requirements document and other documents to reflect change

7. Topic 5Summer 2003 7 Enduring and volatile requirements n Enduring requirements. Stable requirements derived from the core activity of the customer organisation. E.g. a hospital will always have doctors, nurses, etc. May be derived from domain models n Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy

8. Topic 5Summer 2003 8 Problems with NL Specification n Ambiguity –The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult –Lack of rigor n Over-flexibility –The same thing may be said in a number of different ways in the specification n Lack of modularisation –NL structures are inadequate to structure system requirements n Difficult to Prove Correctness

9. Topic 5Summer 2003 9 How Can We Ensure Completeness? n Traceability is concerned with the relationships between requirements, their sources and the system design n Source traceability –Links from requirements to stakeholders n Requirements traceability –Links between dependent requirements n Design traceability –Links from the requirements to the design

10. Topic 5Summer 2003 10 Example: Traceability Matrix U=> Uses, R=>Relates

11. Topic 5Summer 2003 11 Alternatives to NL specification

12. Topic 5Summer 2003 12 Structured language specifications n A limited form of natural language may be used to express requirements n Removes Ambiguity and Flexibility n Imposes Uniformity n Often bast supported using a forms- based approach

13. Topic 5Summer 2003 13 Form-based specifications n Definition of the function or entity n Description of inputs and where they come from n Description of outputs and where they go to n Indication of other entities required n Pre and post conditions (if appropriate) n The side effects (if any)

14. Topic 5Summer 2003 14 Form-based node specification

15. Topic 5Summer 2003 15 PDL-based requirements definition n Requirements may be defined operationally using a language like a programming language but with more flexibility of expression n Most appropriate in two situations –Where an operation is specified as a sequence of actions and the order is important –When hardware and software interfaces have to be specified n Disadvantages are –The PDL may not be sufficiently expressive to define domain concepts –The specification will be taken as a design rather than a specification

16. Topic 5Summer 2003 16 Part of an ATM specification

17. Topic 5Summer 2003 17 PDL disadvantages n PDL may not be sufficiently expressive to express the system functionality in an understandable way n Notation is only understandable to people with programming language knowledge n The requirement may be taken as a design specification rather than a model to help understand the system

18. Topic 5Summer 2003 18 Formal Specification n Techniques for the unambiguous specification of software

19. Topic 5Summer 2003 19 Formal methods n Formal specification is part of a more general collection of techniques that are known as ‘formal methods’ n Formal Method (FM) = –specification language + formal reasoning n Body of techniques supported by –precise mathematics –powerful analysis tools

20. Topic 5Summer 2003 20 Formal Specifications: what and why? n Use of formalisms –e.g., logic, discrete mathematics, formal languages n To describe systems –e.g., system models, constraints, requirements, designs n For broad range of effects –e.g., highly reliable, secure, safe systems and more effective production n With varying levels of use –guidance: structuring what to say –documentation: unambiguous communication –rigor: formal specification and proofs –mechanisms: proof assistance, testing

21. Topic 5Summer 2003 21 Formal Specification in Software Development n Formal specifications ground the software development process in the well-defined basis of computer science n Orientation goes from customer to developer n Formal specification expressed in language whose syntax and semantics are formally defined –hierarchical decomposition –mathematical foundation –graphical presentation –accompanied by informal description

22. Topic 5Summer 2003 22 Goals and Objectives n Requirements Specification –clarify customer's requirements –reveal ambiguity, inconsistency, incompleteness n System/Software Design –module identification and decomposition from structural specifications of component relations and behavioral specification of components –refinement demonstrating that next level of abstraction satisfies higher level n Verification –proving an implementation satisfies its specification n Validation –testing and debugging n Documentation –communication between specifier, implementor, customer, clients

23. Topic 5Summer 2003 23 Benefits of Using Formal Specifications and Methods n higher quality software n verifiability of implementation n insight and understanding n minimized maintenance and cost n automated assistance n formal analysis n guidance for testing n transformation technology n reduced liability and risks n promotes reusability

24. Topic 5Summer 2003 24 Formal Methods are not yet widely used n Reasons –emerging technology with unclear payoff –little experience –lack of automated support –not especially user friendly –too many in-place techniques and tools n Excuses –high learning curve –mathematical sophistication required –techniques not widely applicable –ignorance of advances

25. Topic 5Summer 2003 25 Desirable Properties of Formal Specifications n Consistency –an implementation exists that satisfies a specification n Complete (incrementally) –all required aspects are specified n Unambiguous –all implementations that satisfy the specification are satisfactory (tradeoffs with completeness) n Inference –the ability to prove properties about implementations that satisfy a specification –the ability to prove that an implementation satisfies a specification

26. Topic 5Summer 2003 26 Types of Formal Specifications n Behavioral specifications describe constraints on behavior of implementation – e.g., –functionality –safety –security –performance n Structural specifications describe constraints on internal composition of implementation –module interconnection –uses and is-composed-of –dependence relations

27. Topic 5Summer 2003 27 Characteristics of Specification & Support n Model-oriented specifications –specify system behavior by constructing a model in terms of well-defined mathematical constructs n Property-oriented specifications –specify system behavior in terms of properties that must be satisfied n Visual specifications –specify system behavior and structure by graphical depictions n Executable specifications –specify system behavior completely enough that specifications can run on a computer n Tool support –syntactic checking –model checking –proof checking

28. Topic 5Summer 2003 28 Basic Types of Behavioral Specification n Abstract Model Specifications –defines operations in terms of well-defined mathematical model n Algebraic Specifications –defines a system using a heterogeneous algebra n State Transition Specifications –defines operations in terms of states and transitions n Axiomatic Specifications –defines operations by logical assertions

29. Topic 5Summer 2003 29 Formal Specification Languages: Clock Example + Initially, the time is midnight, the bell is off, and the alarm is disabled. + Whenever the current time is the same as the alarm time and the alarm is enabled, the bell starts ringing. This is the only condition under which the bell begins to ring. + The alarm time can be set at any time. + Only when the alarm is enabled can it be disabled. + If the alarm is disabled while the bell is ringing, the bell stops ringing. + Resetting the clock and enabling or disabling the alarm are considered to be done instantaneously.

30. Topic 5Summer 2003 30 Abstract Model Specifications n Explicitly describes behavior in terms of a model using well-defined types (sets, sequences, relations, functions) and defines behavior by showing effects on model –State is explicit in the model –Objects can be built hierarchically n Specification includes –type definition: syntax of object being specified –model: underlying structure –invariants: properties of modeled object –pre/post conditions: semantics of operations n Pros and Cons –may suggest an implementation –widely applicable because of modeling orientation n Various notations: VDM, Z, RAISE

31. Topic 5Summer 2003 31 Abstract Model Specifications: Process using Z n Specification using Z abstract model specifications –1. Given sets, data types, and constants –2. State definitions and invariants –3. Initial state –4. Operations

32. Topic 5Summer 2003 32 Abstract Model Specifications: the Z Notation specification name [generic parameters] declaration predicate n a Z specification is a collection of schemas n a schema introduces some sets, data types, constants, and invariant properties n the schema declaration defines each variable's name and type (syntax) n the predicate defines the relationships between the entities that must always hold (semantics)

33. Topic 5Summer 2003 33 Abstract Model Specifications:Z Clock BellStatus: {quiet, ringing}, AlarmStatus: {disabled, enabled} Clock time, alarm_time: N bell: BellStatus alarm: AlarmStatus InitClock  Clock (time = midnight)  (bell = quiet)  (alarm = disabled) Tick  Clock ( time = succ(time)) (alarm_time = time)  (alarm = enabled) => (bell = ringing) (~((alarm_time = time)  (alarm = enabled)) => (bell = bell) (alarm = alarm)  (alarm_time = alarm_time)

34. Topic 5Summer 2003 34 SetAlarmTime  Clock new_time   alarm_time  new_time?) ((alarm_time = time)  (alarm = enabled) => (bell = ringing) (~((alarm_time = time)  (alarm = enabled)) => (bell = bell) (time = time)  (alarm = alarm) EnableAlarm  Clock (alarm = disabled) => (alarm = enabled)  ( (alarm_time= time) => (bell = ringing)  (~(alarm_time = time)) => (bell  = bell) )  (time  = time)  (alarm_time  = alarm_time) DisableAlarm  Clock (alarm = enabled) => (alarm = disabled)  (bell = quiet)  (time = time)  (alarm  = alarm)  (alarm_time  = alarm_time)

35. Topic 5Summer 2003 35 State Transition Specifications n Explicitly describes system behavior by a set of states and defines operations as transitions between states or observations on state n Specification includes –states: possible values –transitions: semantics by state transformations and observations n Pros and Cons –free of representational details (except augmentations) –state explosion is common –extensions to minimize states and modularize –particularly applicable to control systems, languages, hardware n Graphical as well as textual notations: StateCharts, ASLAN, Paisley,InaJo, Special

36. Topic 5Summer 2003 36 State Transition Specifications: State Charts Clock off ringing CLOCK tickalarm up quiet on [alarm_time = time] enabled disabled time' := succ(time) time' := midnight gettime disabled

37. Topic 5Summer 2003 37 Algebraic Specification n Objects specified as algebraic sorts in terms of axiomatic relations between associated operations –State is concealed in objects –Objects can be built hierarchically n Specification includes –sets and functions: syntax and legal constructions –relations between functions n Pros and Cons –only pure functions described (no side effects) –supports extensibility of data abstractions –often hard to comprehend and construct n Various notations: OBJ, Larch, Clear, Anna

38. Topic 5Summer 2003 38 Algebraic Specifications: Process n Specification using heterogeneous algebras –1. establish the sorts (sets) (objects and attributes) –2. establish the necessary operations along with their domains and ranges constructor operations access operations –3. establish the axiomatic relations