Specif ication in the sof tware Specif ication and design process - PDF document

Formal Specif ication Objectives • To explain why f ormal specif ication techniques help discover problems in • Techniques f or the system requirements unambiguous • To describe the use of algebraic techniques f or interf ace specif ication of specif ication sof tware • To describe the use of model- based techniques f or behavioural specif ication Formal methods Topics covered • Formal specif ication is part of a more • Formal specif ication in the sof tware general collection of t echniques t hat are process known as ‘f ormal met hods’ • I nterf ace specif ication • These are all based on mathematical • Behavioural specif ication representation and analysis of sof tware • Formal methods include – Formal specif ication – Specif ication analysis and proof – Transf ormational development – Program verif ication Acceptance of f ormal methods Use of f ormal methods • Formal methods have not become • Their principal benef its are in mainstream sof tware development reducing the number of errors in techniques as was once predicted systems so their main area of – Other sof tware engineering techniques have applicability is critical systems been successf ul at increasing system quality. • I n this area, the use of f ormal – Market changes have made time- to- market rather than sof tware with a low error count methods is most likely to be cost- the key f actor. Formal methods do not ef f ective reduce time to market – Formal methods are hard to scale up to large systems 1

Specif ication in the sof tware Specif ication and design process • Specif ication and design are Requirements Requirements intermingled. Def inition Def inition • Architectural design is essential to Requirements Requirements structure a specif ication. Specif ication Specif ication I ncreasing Contractor I nvolvement • Formal specif ications are expressed Architectural Decreasing Client I nvolvement Architectural in a mathematical notation with Design Design precisely def ined vocabulary, synt ax Sof tware Sof tware and semantics. Specif ication Specif ication Specif ication High- level High- level Design Design Design Specif ication in the sof tware Specif ication techniques process • Algebraic approach – The system is specif ied in terms of it s Requirements Formal Requirements Formal operations and t heir relationships Specif ication Specif ication Specif ication Specif ication • Model- based approach Requirements Requirements High- level High- level – The system is specif ied in terms of a Def inition Def inition Design Design state model t hat is construct ed using System Architectural mathemat ical constructs such as sets System Architectural Modeling Design Modeling Design and sequences. Operations are def ined by modif icat ions to the system’s state Formal specif ication languages Use of f ormal specif ication • Formal specif ication involves investing Sequential Concurrent more ef f ort in the early phases of sof tware development • This reduces requirements errors as it f orces a detailed analysis of t he Algebraic Larch Lotos requirements • I ncompleteness and inconsist encies can be discovered and resolved Model- based 1. Z 1. CSP • Hence, savings as made as t he amount of 2. VDM 2. Petri Nets rework due to requirement s problems is 3. B reduced 2

I nterf ace specif ication Development costs with f ormal specif ication • Large systems are decomposed into Validation subsystems with well- def ined interf aces Validat ion between t hese subsystems Design & I mplementation • Specif ication of subsystem int erf aces Design & allows independent development of the I mplementation Cost Specif ication dif f erent subsystems • I nterf aces may be def ined as abstract Specif ication data types or object classes • The algebraic approach to f ormal specif ication is particularly well- suited to interf ace specif icat ion Without f ormal specif ication With f ormal specif ication The structure of an algebraic Sub- system interf aces specif ication I nterf ace <Specif ication Name> (Generic Parameter) objects Sort <name> Sort <name> I mports <list of specif ication names> I mports <list of specif ication names> Sub- system Sub- system I nf ormal description of the sort and its operations Sub- system Sub- system I nf ormal description of the sort and its operations A B A B Operation signatures setting out the names and the Operation signatures setting out the names and the types of the parameters to the operations def ined types of the parameters to the operations def ined over the sort over the sort Axioms def ining the operations over the sort Axioms def ining the operations over the sort Systematic algebraic Specif ication components specif ication • I ntroduction • Algebraic specif ications of a system – Def ines the sort (the type name) and may be developed in a systematic declares other specif ications that are used way • Descript ion – Specif ication struct uring. – I nf ormally describes the operations on the type – Specif ication naming. • Signature – Operation select ion. – Def ines the syntax of the operations in the – I nf ormal operat ion specif ication interf ace and their parameters • Axioms – Syntax def inition – Def ines the operation semantics by def ining – Axiom def inition axioms which characterise behaviour 3

I nterf ace specif ication in critical Specif ication operations systems • Consider an air traf f ic control system • Constructor operations. Operations where aircraf t f ly through managed which create entities of the type sectors of airspace being specif ied • Each sector may include a number of • I nspection operations. Operations aircraf t but , f or saf ety reasons, these must be separated which evaluate entities of the type • I n this example, a simple vert ical being specif ied separat ion of 300m is proposed • To specif y behaviour, def ine the • The system should warn the controller if inspector operations f or each aircraf t are instruct ed to move so t hat constructor operation the separation rule is breached A sector object Primitive operations • Critical operations on an object • I t is sometimes necessary to introduce additional operations to simplif y the representing a controlled sector are specif ication – Enter. Add an aircraf t t o the • The ot her operations can then be controlled airspace def ined using these more primitive – Leave. Remove an aircraf t f rom t he operations controlled airspace • Primit ive operations – Move. Move an aircraf t f rom one – Create. Bring an instance of a sector into height to another existence – Lookup. Given an aircraf t identif ier, – Put. Add an aircraf t without saf ety checks return its current height – I n- space. Determine if a given aircraf t is in the sector – Occupied. Given a height, determine if there is an aircraf t within 300m of that height SECTOR Sector sort Sector Specif ication commentary imports INTEGER, BOOLEAN specif ication Enter - adds an aircraft to the sector if safety conditions are satisfed Leave - removes an aircraft from the sector Move - moves an aircraft from one height to another if safe to do so Lookup - Finds the height of an aircraft in the sector Create - creates an empty sector • Use the basic const ructors Create Put - adds an aircraft to a sector with no constraint checks In-space - checks if an aircraft is already in a sector Occupied - checks if a specified height is available and Put to specif y other operations Enter (Sector, Call-sign, Height) → Sector Leave (Sector, Call-sign) → Sector Move (Sector, Call-sign, Height) → Sector Lookup (Sector, Call-sign) → Height • Def ine Occupied and I n- space using Create → Sector Put (Sector, Call-sign, Height) → Sector In-space (Sector, Call-sign) → Boolean Occupied (Sector, Height) → Boolean Create and Put and use them to Enter (S, CS, H) = if In-space (S, CS ) then S exception (Aircraft already in sector) elsif Occupied (S, H) then S exception (Height conflict) make checks in other operation else Put (S, CS, H) Leave (Create, CS) = Create exception (Aircraft not in sector) Leave (Put (S, CS1, H1), CS) = def initions if CS = CS1 then S else Put (Leave (S, CS), CS1, H1) Move (S, CS, H) = if S = Create then Create exception (No aircraft in sector) elsif not In-space (S, CS) then S exception (Aircraft not in sector) • All operations that result in changes elsif Occupied (S, H) then S exception (Height conflict) else Put (Leave (S, CS), CS, H) -- NO-HEIGHT is a constant indicating that a valid height cannot be returned to the sector must check that the Lookup (Create, CS) = NO-HEIGHT exception (Aircraft not in sector) Lookup (Put (S, CS1, H1), CS) = if CS = CS1 then H1 else Lookup (S, CS) saf ety criterion holds Occupied (Create, H) = false Occupied (Put (S, CS1, H1), H) = (H1 > H and H1 - H ≤ 300) or (H > H1 and H - H1 ≤ 300) then true if else Occupied (S, H) In-space (Create, CS) = false In-space (Put (S, CS1, H1), CS ) = if CS = CS1 then true else In-space (S, CS) 4