Topic 5Summer 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 5Summer Today’s Lecture n Problems in RE n Formal Methods

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

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

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

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

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

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

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

Topic 5Summer Alternatives to NL specification

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

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

Topic 5Summer Form-based node specification

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

Topic 5Summer Part of an ATM specification

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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