ICS 52 Introduction to Software Engineering Lecture Notes

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 Topic 5 Summer 2003 1

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

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 Topic 5 Ethnographic studies can help Summer 2003 3

Domain Requirements n n Derived from the application domain and describe system characterisics and features that reflect the domain Example : Library System – There shall be a standard user interface to all databases which shall be based on the Z 39. 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. Topic 5 Summer 2003 4

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 Topic 5 Summer 2003 5

Requirements change management n n Should apply to all proposed changes to the requirements 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 Topic 5 Summer 2003 6

Enduring and volatile requirements n n Topic 5 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 Volatile requirements. Requirements which change during development or when the system is in use. In a hospital, requirements derived from health-care policy Summer 2003 7

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 Topic 5 Difficult to Prove Correctness Summer 2003 8

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

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

Alternatives to NL specification Topic 5 Summer 2003 11

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

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

Form-based node specification Topic 5 Summer 2003 14

PDL-based requirements definition n Topic 5 Requirements may be defined operationally using a language like a programming language but with more flexibility of expression 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 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 Summer 2003 15

Part of an ATM specification Topic 5 Summer 2003 16

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

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

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

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

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

Goals and Objectives n n n Topic 5 Requirements Specification – clarify customer's requirements – reveal ambiguity, inconsistency, incompleteness 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 Verification – proving an implementation satisfies its specification Validation – testing and debugging Documentation – communication between specifier, implementor, customer, clients Summer 2003 22

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

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 Topic 5 Summer 2003 24

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

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

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

Basic Types of Behavioral Specification Topic 5 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 Summer 2003 28

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. Topic 5 Summer 2003 29

Abstract Model Specifications n 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 Specification includes – type definition: syntax of object being specified – model: underlying structure – invariants: properties of modeled object – pre/post conditions: semantics of operations Pros and Cons – may suggest an implementation – widely applicable because of modeling orientation Various notations: VDM, Z, RAISE Topic 5 Summer 2003 30

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 Topic 5 Summer 2003 31

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

Abstract Model Specifications: Z Clock Bell. Status: {quiet, ringing}, Alarm. Status: {disabled, enabled} Clock time, alarm_time: N bell: Bell. Status alarm: Alarm. Status Init. 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) Topic 5 Summer 2003 33

Set. Alarm. Time 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) Enable. Alarm Clock (alarm = disabled) => (alarm = enabled) ( (alarm_time = time ) => (bell = ringing) (~(alarm_time = time )) => (bell = bell) ) (time = time) (alarm_time = alarm_time) Disable. Alarm Clock (alarm = enabled) => (alarm = disabled) (bell = quiet) (time = time) (alarm = alarm) (alarm_time = alarm_time) Topic 5 Summer 2003 34

State Transition Specifications n n Topic 5 Explicitly describes system behavior by a set of states and defines operations as transitions between states or observations on state Specification includes – states: possible values – transitions: semantics by state transformations and observations 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 Graphical as well as textual notations: State. Charts, ASLAN, Paisley, Ina. Jo, Special Summer 2003 35

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

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

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 Topic 5 Summer 2003 38