Software Engineering Modern Approaches Eric Braude and Michael Bernstein 1

© 2010 John Wiley & Sons Ltd. Chapter 14: Formal and Emerging Methods in Requirements Analysis 2

Learning Goals of This Chapter What does it mean for requirements to be formal? When is it advisable to use formal methods? What are examples of formal systems? Requirements analysis Design Implementation Testing Maintenance Planning The Software Development Lifecycle Phase most relevant to this chapter is shown in bold 3

Formal vs. Agile Approaches to Requirements Agile response Make running code and tests the effective requirements because the customer is part of this process Formal response Based on belief that mathematical precision is appropriate basis Allows automation of requirements-to-code The Problem: Natural language can be  ambiguous  clumsy when expressing some details and nuances  hard to trace to code © 2010 John Wiley & Sons Ltd. 4

Benefits of Formal Methods for Specifying Requirements Precision Provability with mathematical certainty Power – Leverage mathematics to form new requirements from existing ones Possibility for automated code generation – Precision may allow this 5

© 2010 John Wiley & Sons Ltd. Formal Modeling and Analysis Notation * Common: Z, B, OCL Alloy, VDM Can capture software abstractions more succinctly than programming language Use classical mathematics for states Sets and relations Describe behavior declaratively, using constraints Lightweight tools available to evaluate against constraints New tool projects will enhance greatly * From "Software Abstractions : Logic, Language, and Analysis" by Daniel Jackson; MIT Press (2006) ISBN:

© 2010 John Wiley & Sons Ltd Augmenting t with input (2, 4) yields: Augmenting t with input (3, 6) yields: Update Example Hayes et al If t is the table: 7

© 2010 John Wiley & Sons Ltd. Z-specification for Augmenting a Table 1 t, t’ : N  N l?, r? : N Augment Function between integers x ’ denotes value of x after application Declaration of variables and types Procedure name The set of natural numbers ? denotes input Hayes et al 8

© 2010 John Wiley & Sons Ltd. Z-specification for Augmenting a Table Completed t, t’ : N  N l?, r? : N Lookup [l?  dom( t )  t’ = t  { (l?, r?) }] V [l?  dom( t )  t’ = (t \ { (l?, t(l?)}  { (l?, r?) }] … is not an element of... Elements that t acts on. and... Remove existing element from t or... Adapted from Hayes et al Effect of application t augmented by mapping l? to r? 9

© 2010 John Wiley & Sons Ltd. Z-Specification for Lookup t, t’ : N  N l?, r! : N Lookup [ l?  dom( t )  r! = 0  t’ = t ] V [ l?  dom( t )  r! = t( l? )  t’ = t ] The table t is unchanged Hayes et al Name of an output 10

Array Function A Domain element x Range element A(x) © 2010 John Wiley & Sons Ltd. 11

© 2010 John Wiley & Sons Ltd. Z-specification for Sorting Example t, t´ : N N dom(t´) = dom(t)  rng(t´) = rng(t)   x, y  dom(t), x  y  t´(x)  t´(y)   x  rng(t´), card[ t´ -1 (x) ] = card[ t -1 (x) ] Sort Partial function (see above)Range of t Number of elements in the set... Set of elements mapped onto x by t “implies” 12

The CM State Schema checkedOut : CI ↛ ENGINEERS _____________________________ checkedOut  permitted CM © 2010 John Wiley & Sons Ltd. 13

Using a Schema in a New Schema CM privileged  CI  ENGINEER _____________________________ privileged  permitted SuperCM checkedOut : CI ↛ ENGINEER privileged  CI  ENGINEER _____________________________ checkedOut  permitted privileged  permitted SuperCM Is equivalent to: © 2010 John Wiley & Sons Ltd. 14

© 2010 John Wiley & Sons Ltd. Operation Schemas Based on Existing Schemas Operations permitted on a system result only in states permitted by the state schema Performed with operation schemas. For a state schema X – ΔX denotes state of X changes – ΞX denotes state of X unchanged 15

The CheckOut Operation Schema ∆CMCM holds; may change state e? : ENGINEERe? is an engineer (element) c? : CIc? is a configuration item _____________________________ c?  dom checkedOutc? not currently checked out ( c?, e?)  permittede? allowed to check out c? checkedOut’ = checkedOut  ( c?, e?) save transaction CheckOut Comments © 2010 John Wiley & Sons Ltd. 16

The CheckIn Operation Schema ∆CMCM holds; may change state e? : ENGINEERe? is an engineer (element) c? : CIc? is a configuration item _____________________________ ( c?, e?)  checkedOute? has checked out c? checkedOut’ = checkedOut \ ( c?, e?) save transaction CheckIn © 2010 John Wiley & Sons Ltd. 17

The DisallowedCheckin Operation Schema  CMCM holds; doesn’t change state e? : ENGINEERe? is an engineer (element) c? : CIc? is a configuration item _____________________________ ( c?, e?)  permittede? not allowed to check out c? nothing changes DisallowedCheckIn © 2010 John Wiley & Sons Ltd. 18

© 2010 John Wiley & Sons Ltd. Using a System for Formal Specification: Tradeoffs Benefits of Formal Specification Reduces ambiguity Promotes traceability from requirements to implementation Costs of Formal Specification  Requires training to apply  Doubt they can specify all needs  Customers can’t understand 19