topics covered
play

Topics covered Formal specif ication in the sof tware process I - PDF document

Formal Specif ication Techniques f or the unambiguous specif ication of sof tware Objectives To explain why f ormal specif ication techniques help discover problems in system requirements To describe the use of algebraic


  1. Formal Specif ication • Techniques f or the unambiguous specif ication of sof tware Objectives • To explain why f ormal specif ication techniques help discover problems in system requirements • To describe the use of algebraic techniques f or interf ace specif ication • To describe the use of model- based techniques f or behavioural specif ication 1

  2. Topics covered • Formal specif ication in the sof tware process • I nterf ace specif ication • Behavioural specif ication Formal methods • Formal specif ication is part of a more general collection of techniques that are known as ‘f ormal methods’ • These are all based on mathematical representation and analysis of sof tware • Formal methods include – Formal specif ication – Specif ication analysis and proof – Transf ormational development – Program verif ication 2

  3. Acceptance of f ormal methods • Formal methods have not become mainstream sof tware development techniques as was once predicted – Other sof tware engineering techniques have been successf ul at increasing system quality. – Market changes have made time- to- market rather than sof tware with a low error count the key f actor. Formal methods do not reduce time to market – Formal methods are hard to scale up to large systems Use of f ormal methods • Their principal benef its are in reducing the number of errors in systems so their main area of applicability is critical systems • I n this area, the use of f ormal methods is most likely to be cost- ef f ective 3

  4. Specif ication in the sof tware process • Specif ication and design are intermingled. • Architectural design is essential to structure a specif ication. • Formal specif ications are expressed in a mathematical notation with precisely def ined vocabulary, syntax and semantics. Specif ication and design Requirements Requirements Def inition Def inition Requirements Requirements Specif ication Specif ication I n creasin Architectural Decreasin Architectural g C Design o n Design tracto g C lien r I n t I n vo Sof tware lvem vo Sof tware lvem en Specif ication t Specif ication en Specif ication t High- level High- level Design Design Design 4

  5. Specif ication in the sof tware process Requirements Formal Requirements Formal Specif ication Specif ication Specif ication Specif ication Requirements Requirements High- level High- level Def inition Def inition Design Design System Architectural System Architectural Modeling Design Modeling Design Specif ication techniques • Algebraic approach – The system is specif ied in terms of its operations and their relationships • Model- based approach – The system is specif ied in terms of a state model that is constructed using mathematical constructs such as sets and sequences. Operations are def ined by modif ications to the system’s state 5

  6. Formal specif ication languages Sequential Concurrent Algebraic Larch Lotos Model- based 1. Z 1. CSP 2. VDM 2. Petri Nets 3. B Use of f ormal specif ication • Formal specif ication involves investing more ef f ort in the early phases of sof tware development • This reduces requirements errors as it f orces a detailed analysis of the requirements • I ncompleteness and inconsistencies can be discovered and resolved • Hence, savings as made as the amount of rework due to requirements problems is reduced 6

  7. Development costs with f ormal specif ication Validation Validation Design & I mplementation Design & I mplementation Cost Specif ication Specif ication Without f ormal specif ication With f ormal specif ication I nterf ace specif ication • Large systems are decomposed into subsystems with well- def ined interf aces between these subsystems • Specif ication of subsystem interf aces allows independent development of the dif f erent subsystems • I nterf aces may be def ined as abstract data types or object classes • The algebraic approach to f ormal specif ication is particularly well- suited to interf ace specif ication 7

  8. Sub- system interf aces I nterf ace objects Sub- system Sub- system Sub- system Sub- system A B A B The structure of an algebraic specif ication <Specif ication Name> (Generic Parameter) Sort <name> Sort <name> I mports <list of specif ication names> I mports <list of specif ication names> I nf ormal description of the sort and its operations I nf ormal description of the sort and its operations 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 8

  9. Specif ication components • I ntroduction – Def ines the sort (the type name) and declares other specif ications that are used • Description – I nf ormally describes the operations on the type • Signature – Def ines the syntax of the operations in the interf ace and their parameters • Axioms – Def ines the operation semantics by def ining axioms which characterise behaviour Systematic algebraic specif ication • Algebraic specif ications of a system may be developed in a systematic way – Specif ication structuring. – Specif ication naming. – Operation selection. – I nf ormal operation specif ication – Syntax def inition – Axiom def inition 9

  10. Specif ication operations • Constructor operations. Operations which create entities of the type being specif ied • I nspection operations. Operations which evaluate entities of the type being specif ied • To specif y behaviour, def ine the inspector operations f or each constructor operation I nterf ace specif ication in critical systems • Consider an air traf f ic control system where aircraf t f ly through managed sectors of airspace • Each sector may include a number of aircraf t but, f or saf ety reasons, these must be separated • I n this example, a simple vertical separation of 300m is proposed • The system should warn the controller if aircraf t are instructed to move so that the separation rule is breached 10

  11. A sector object • Critical operations on an object representing a controlled sector are – Enter. Add an aircraf t to the controlled airspace – Leave. Remove an aircraf t f rom the controlled airspace – Move. Move an aircraf t f rom one height to another – Lookup. Given an aircraf t identif ier, return its current height Primitive operations • I t is sometimes necessary to introduce additional operations to simplif y the specif ication • The other operations can then be def ined using these more primitive operations • Primitive operations – Create. Bring an instance of a sector into existence – Put. Add an aircraf t without saf ety checks – 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 11

  12. SECT OR Sector sort Se ctor imports INTEGER , BOOLE AN specif ication Enter - a dds a n airc raft to the se ctor if s afety conditions a re s atis f e d Leave - re move s an aircraft from the se ctor Move - moves a n a ircraft from one he ight to another if safe to do so Lookup - Finds the height of an aircra ft in the s ector Cre a te - creates an e mpty sec tor Put - a dds a n airc ra f t to a se ctor with no constraint c hecks In-space - che cks if a n aircra ft is already in a sector Occupied - checks if a spe cifie d height is available Enter (Se ctor, Call-sign, He ight) ? Se ctor Le ave (Sec tor, Call-sign) ? Sector Move (Se ctor, Call-s ign, He ight) ? Se ctor Lookup (Se ctor, Call-sign) ? Height Cre ate ? Sector Put (S ector, Call-sign, Height) ? Se ctor In-spa ce (Sector, Ca ll-sign) ? Boolea n Occupied (Sector, Height) ? Boolea n E nte r (S, CS, H) = if In-space (S, CS ) the n S exc eption (Aircra ft alre ady in se ctor) elsif Occupie d (S , H) the n S exc eption (Height conflict) else Put (S , CS, H) Leave (Create, CS) = Create exception ( Aircraft not in sector) Leave (Put (S, CS1, H1), CS) = if CS = CS1 the n S else Put (Leave (S, CS), CS1, H1) Mo ve (S , CS, H) = if S = Create the n Create e xce ption (No aircra ft in s ector) elsif not In-spa ce (S , CS) the n S exception ( Aircraft not in sector) elsif Occupie d (S , H) the n S exception ( He ight c onflict) else P ut (Lea ve (S, CS), CS, H) -- NO-HEIGHT is a consta nt indicating that a valid height cannot be re turne d Lookup (C rea te , CS) = NO-HEIGHT e xce ption (Air c raft not in se ctor) Lookup (P ut (S, CS 1, H1), C S) = if CS = CS 1 the n H1 else Lookup (S, CS) Oc cupie d (Crea te, H) = false Oc cupie d (Put (S, CS1, H1), H) = if (H1 > H and H1 - H Š 300) or ( H > H1 and H - H1 Š 300) the n true els e Oc cupie d (S, H) In-space (Cre ate, CS ) = f a ls e In-space (Put (S, CS1, H1), CS ) = if CS = CS 1 the n true else In-spa ce (S, CS) Specif ication commentary • Use the basic constructors Create and Put to specif y other operations • Def ine Occupied and I n- space using Create and Put and use them to make checks in other operation def initions • All operations that result in changes to the sector must check that the saf ety criterion holds 12

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend