Download Hints to Speci ers and more Lecture notes Discrete Mathematics in PDF only on Docsity!
Hints to Sp eci ers
Jeannette M Wing May CMU CS r
Scho ol of Computer Science Carnegie Mellon University Pittsburgh PA
This pap er is derived from the pap er Teaching Mathematics to Software Engineers which will app ear in the Proceedings of the Fourth International Conference on Algebraic Methodology and Software Technology The AMAST pap er is the basis of an invited talk for AMASTs Education Day July in Montreal Canada
Abstract
I present a list of hints for writing sp ecications I address highlev el issues like learning to abstract and lowlevel issues like getting the details of logical expressions right This pap er should b e of interest not only to students of formal metho ds but also to their teachers
This research is sp onsored by the Wright Lab oratory Aeronautical Systems Center Air Force Materiel Com mand USAF and the Advanced Research Pro jects Agency ARPA under grant numb er F Views and conclusions contained in this do cument are those of the authors and should not b e interpreted as necessarily representing o cial p olicies or endorsements either expressed or implied of Wrigh t Lab oratory or the United States Government
Keywords formal metho ds formal sp ecication software engineering education discrete mathematics mathematical logic algebraic sp ecications Z Larch
I want to sp ecify the right thing happ ens if an error o ccurs I want to make sure this error never o ccurs
Completeness
I want to make sure that Ive covered all the cases including error cases for this proto col Id like to know that this language Ive designed is computationally complete
Sp ecifying interfaces
Id like to dene a hierarchy of C classes Id like a more formal description of this systems user interface
Getting a handle on complexity
The design is getting too complicated I cant t it all in my head I need a way to think ab out it in smaller pieces
Change control
Every time I change one piece of co de I need to know what other pieces are a ected Id like to know where else to lo ok without lo oking at all modules without lo oking at all the source co de
Judicious use of formalism can help address all these problems to varying levels of detail and rigor
What to Sp ecify
Formal metho ds are not to the p oint where an entire large software system can b e completely sp ecied You may b e able to sp ecify one asp ect of it eg its functionality or its realtime b ehavior you may b e able to sp ecify many asp ects of a part of it eg sp ecifying b oth functionality and realtime b ehavior of its safetycritical part In practice you may only care to sp ecify one asp ect of a part of a system anyway
In writing a sp ecication you should decide whether it is describing required or permitted b e havior Must or may Since a sp ecication can b e viewed as an abstraction of many p ossible legitimate implemen tations you might most naturally asso ciate a sp ecication with describing p ermitted b ehavior An implementation may have any of the b ehaviors p ermitted by the sp eci cation but the implementor is not required to realize all For example a nondeterministic choose op eration sp ecied for sets will have a deterministic implemen tation However the expression software system requirements suggests that a customer may in fact require certain b ehavior For example in sp ecifying an abstract data typ es interface the assumption is that all not some prop er subset of the op erations listed must b e implemen ted
Once it is clear what you want from the sp ecication pro cess you can turn to determining exactly what should b e formalized
In increasing order of level of detail you might want to formalize a global correctness condition for the system one or more system invariants the observable behavior of a system or properties of entities in a system
Correctness Conditions
You usually have some informal notion of a global correctness condition that you exp ect your system to maintain It might b e something as standard as serializabili t y cache coherence or deadlo ck freedom Or it might b e very sp ecic to the proto col or system at hand If it is standard then very likely someone else has develop ed a formal mo del for characterizing a system and a logic within which the correctness condition can b e formally stated and proved Eg serializabili t y has b een thoroughly studied by the database community from all angles theoretical to practical If your correctness condition can b e cast in terms of a wellkno wn theory it pays to reuse that work and not invent from scratch
If it is not standard then an informal statement of the correctness condition should drive the formalization of the system mo del and expression of the correctness condition For example in work by Mummert et al the authors started with this informal statement of cache coherence for a distributed le system
If a clien t b elieves that a cached le is valid then the server that is the authority on that le had b etter b elieve that the le is valid
They develop ed a system mo del a state machine mo del and logic based on the logic of authentication that enabled them to turn the informal statement into the following formal statement
For all clien ts C servers S and ob jects d for which S is the rep ository if C b elieves valid dC then S b elieves valid dC
where clients servers ob jects rep ository b elieves and valid are formally dened concepts The p oint is that the formal statement do es not read too di erently from the informal one
Keep in mind this ruleofthumb when formalizing from an informal statement Let the things you want to describ e formally drive the description of the formal mo del There is a tendency to let the formal metho d drive the description of the formal mo del you end up sp ecifying what you can easily sp ecify using that metho d That is ne as far as it goes but if there are things you cannot say or that are awkward to express using that metho d you should not feel b ound by the metho d Invent your own syntax to b e dened later add auxiliary denitions or search for a complementary metho d
The pro cess of constructing a formal mo del of a system and formally characterizing the intended correctness condition can lead to surprises More than once I have seen PhD students start formalizing the systems that they were building and then have to back o from their exp ected and desired correctness condition They end up realizing that it was to o strong not always guaranteed eg not guaranteed for some failure case or for a fastpath case or only lo cally true holds for a system comp onent but not the entire system Correctness conditions for distributed systems are likely to b e weaker than exp ected or desired b ecause of the presence of failures nodes or
Identify the level of abstraction see Section at which you are sp ecifying the system This level determines the interface b oundary that you are sp ecifying it determines what is or is not observable For example a bus error at the hardware level is not exp ected to b e an observable event in the execution of an text formatter like Word but core dumped is certainly an observable event when using a text editor like emacs
Characterize the observable entities in a state at that given level of abstraction These entities are sometimes called a systems state variables or objects This step forces you to identify the relevant abstract types of your system See the section on Properties of State Entities b elow
Characterize a set of initial states and if appropriate a set of nal states
Identify the op erations that can access or mo dify the observable entities These dene your state transitions
For each op eration characterize its observable e ect on the observable state entities For example use Z schemas Larch interfaces or VDM prep ostconditions
Observable b ehavior should include any change in state that is observable to the user If you are sp ecifying an op eration then the kinds of observable state changes include changes in value to state entities observable changes in the store new entities that app ear and old entities that disapp ear results returned by the op eration and signaled exceptions or errors
Another way to think ab out observable b ehavior is to think ab out observable equivalence Ask Can I distinguish b etween these two things where things might b e states individual entities in a state traces of a pro cess or b ehavior sets of a pro cess dep ending on what you are sp ecifying If the answer is yes then there must b e way to tell them apart p erhaps by using unique names or p erhaps by dening an equal op eration if no then there must not b e any way for the observer to tell them apart
Properties of State Entities
The most imp ortant prop erty to express of any entity in a system is its type This statement is true regardless of the ne distinctions b etween the di erent typ e systems that di erent formal metho ds and sp ecication and programming languages have Since for a sp ecication we are not concerned ab out compiletime or runtime costs of checking typ es there is never a cost incurred in do cumenting in a sp ecication an entitys typ e
Since a typ e can b e viewed as an abbreviation for a little theory declaring an entitys typ e is a succinct way of asso ciating a p ossibly innite set of prop erties with the entity in one or two words A truly p owerful abstraction device
For entities that are structured ob jects eg an ob ject that is a collection of other ob jects when determining its typ e the kinds of distinguishing prop erties include
Ordering Are elements ordered or unordered If ordering matters is the order partial or total Are elements removed FIFO LIFO or by priority
Duplicates Are duplicates allowed
Boundedness Is the ob ject b ounded in size or unb ounded Can the b ound change or it is xed at creation time Asso ciative access Are elements retrieved by an index or key Is the typ e of the index builtin eg as for sequences and arrays or userdenable eg as for symb ol tables and hash tables
Shap e Is the structure of the ob ject linear hierarchical acyclic ndimensional or arbitrarily complex eg graphs forests
For entities that are relations the kinds of distinguishing prop erties include whether the relation is a function manytoone partial nite dened for only a nite domain surjective injective bijective and any meaningful combination of these
Finally algebraic prop erties help characterize any relational entity or any function or relation dened on a structured entity The standard algebraic prop erties include idemp otency reexivity symmetry transitivity commutativity associativity distributivit y existence of an identity elemen t and existence of an inverse relation or function Algebras are wellkno wn mathematical mo dels for abstract data typ es and for pro cesses For example this algebraic equation characterizes the idemp otency of inserting the same element into a set multiple times
insert insert s e e insert s e
and this characterizes inserts commutativity prop erty
insert insert s e e insert insert s e e
It also makes sense to ask ab out whether algebraic prop erties hold for op erations on pro cesses For example for CSP pro cesses parallel comp osition is b oth commutative and asso ciative
P k Q Q k P P k Q k R P k Q k R
How to Sp ecify
Given that you understand why you are sp ecifying and what it is you want to sp ecify in what ways should you try to think ab out the system so that you can b egin to sp ecify and then make progress in writing your sp ecication The fundamental techniques are abstraction and decomposition In sp ecifying large complex systems abstraction is useful for fo cusing your attention to one level of detail at a time decomp osition for one small piece of the system at a given abstraction level at a time Both enable lo cal reasoning
Learn to Abstract Try Not to Think Like a Programmer
The skill that p eople nd the most dicult to acquire is the ability to abstract One asp ect of learning to abstract is b eing able to think at a level higher than programmers are used to
poppushse s toppushse e
Sequences or any other data structure do not enter the picture at all
Like many you may nd metho ds like Z and VDM app ealing b ecause they encourage a mo del based rather than theorybased approach to sp ecication You can build up go o d intuition ab out your system if you have a mo del in hand However to practice learning how to abstract try writing algebraic or axiomatic assertions ab out the mo del
How To Pro ceed Incrementally
At any given level of abstraction we ignore some detail ab out the system b elow You might feel anxious to sp ecify everything for fear of b eing incomplete Learning to abstract means learning when it is okay to leave something unsp ecied This asp ect of the abstraction pro cess also allows incremental sp ecication In general it is b etter to sp ecify something partially than not at all
Here are four common and imp ortant examples of incremen tal abstraction techniques rst assume something is true of the input argument and capture this assumption in a precondition then weaken the precondition rst handle the normal case then the failure case rst ignore the fact that ordering or no duplicates etc matters then strengthen the p ostcondition rst assume the op eration is atomic then break it into smaller atomic steps Lets lo ok in turn at each of these examples in their generality and in more detail
Use pre conditions
Putting your programmers cap on think of preconditions in the context of pro cedure call A precondition serves two purp oses an obligation on the caller to establish b efore calling the pro cedure and an assumption the implemen tor can make when co ding the pro cedure
More generally preconditions are a way of sp ecifying assumptions ab out the environment of a system comp onent Such assumptions can and should b e sp elled out and written down explicitly By doing so you can sp ecify and reason ab out a piece of the system without having to think ab out the entire system all at once Thus preconditions assist in partial sp ecication incremental design and lo cal reasoning all attractive means of dealing with the complexity of large software systems
One technical diculty that trips some p eople is what a sp ecication means if a precondition is not met In many sp ecication techniques like Z and Larch when an op erations precondition is not met the interpretation is all b ets are o The interpretation is that the precondition is a disclaimer^ In other words the op eration is free to do anything including not terminate if the precondition do es not hold The technical justication is that when an op eration is sp ecied using pre and p ostconditions the logical interpretation of the sp ecication is an implication
pre post
Thanks to Daniel Jackson for this term
When the precondition is false then the implication is vacuously true so any b ehavior should b e allowed
Some formal metho ds like InaJo and IO automata use the term precondition but mean something entirely di erent The precondition is interpreted as a guard no state transition should o ccur if the guard is not met Here the interpretation is conjunction
pre post
The di erence is that under the disclaimer interpretation for any state s in which the precondition do es not hold the state pair hs s i for any state s would b e in the state transition relation under the guard interpretation no such state pair would b e in the relation
There are other p ossible interpretations For example if the precondition is not met it could mean that the state transition always go es to a sp ecial error state and termination is guaranteed or it could mean the state transition leads to either an error state or nontermination The p oint is that you must understand in the notation you are using what it means when a precondition is met or not met
Finally in the presence of concurrency you need to sp ecify b oth kinds of conditions for an op eration a precondition as a disclaimer and a guard The precondition is evaluated in the state in which the op eration is called the guard in the state in which the op eration b egins executing Because of concurrency a scheduler may delay the start of the execution of an op eration to some time after the call of the op eration since there is time b etween the state in which the op eration is called and the state in which it starts executing an intervening op eration executed by some other pro cess may change the systems state Thus a predicate that holds in the state when the op eration is called may no longer hold in the state when the op eration b egins to execute The p oint is to realize that in the presence of concurrency there is a new kind of condition to sp ecify
Specify errorsexceptionsfailures
It is as imp ortant to sp ecify erroneous or exceptional b ehavior as it is to sp ecify normal b ehavior If an op eration can lead to an undesired state you should sp ecify the conditions under which this state is reachable If you are lucky the sp ecication language has some notational convenience eg Larchs signals clause or prescrib ed technique eg Zs schema calculus to remind you to describ e error conditions otherwise handling errors may have to b e disguised in terms of input or output arguments that serve as error ags
There is a close correlation b etween preconditions and handling errors Z sp eciers draw this connection by abiding by this convention using schema disjunction
TotalOp NormalOp ErrorOp
There is further confusion in understanding preconditions in Z b ecause even though you migh t write explicitly in your schema the conjunction xpre post where xpre is the explicit precondition the meaning is the implicati on pre post where pre is the calculated precondition and usually not identical to xpre (^) Larch calls the guard a when condition to distinguish it from the standard precondition written in a requires clause
general case of disjunction
p ositively random op returns i int ensures x int i j x j
From a state machine mo del viewp oint for instance when discussing deterministic and nonde terministic nite state automata nondeterminism should not b e confused with choice Supp ose is a state transition relation
State Action State
Then an example of choice is
s a ft g s a fu g
which says from state s you can either do the action a and go to the next state t or do the action a and go to the next state u However an example of nondeterminism is
s a ft u g
which says from state s you can do action a and go to either state t or u
Some formal metho ds for concurrent systems intro duce their own notions of nondetermin ismchoice for example CSP has two op erators one for internal choice u made by the machine and the other for external choice made by the environment^ CCS has yet a di erent way to mo del nondeterminism
The two main p oints are that nondeterminism is a useful and imp ortant way to abstract but b e careful to understand any given metho ds way of mo deling nondeterminismchoice to use it prop erly
Use Atomic Operations
For any system it is imp ortant to identify what the atomic op erations are An atomic op eration is one whose execution is indivisibl e only the states b efore and after its execution are observable At any level of abstraction an atomic op eration may b e implemen ted in terms of sequences of lowerlevel atomic op erations eg a write op eration to a le on disk might b e implemen ted in terms of a sequence of write op erations to individual disk blo cks Even assignment can b e broken down into sequences of loads and stores tofrom memory and registers
It is usually assumed that each pro cedure of a sequential program is executed atomically this assumption is rarely stated explicitly
For a concurrent system it is critical to state explicitly what op erations are atomic The atomicity of an op eration Op guarantees that no other op eration can interfere with Ops execution and that you can abstract away from any intermediate lowerlevel state that it might actually pass through
Hoare calls the former nondeterministi c or and the latter general choice
What to Write
With your p en p oised over a blank sheet of pap er or ngers over your keyb oard you now face the problem of what to write down If you are using a sp ecic formal metho d like Z VDM or Larch you must know the syntax and semantics of its sp ecication language It is not enough to know what the syntactic features are you need to understand what each means
It is imp ortant to understand the di erence b etween syntax and semantics For example a typical algebraic sp ecication language has grammatical rules for formulating syntactically legal terms out of function and variable symb ols Each syntactically legal term denotes a value in some underlying algebraic mo del For example the term insert insert e e is a syntactic entity that denotes the set value fe e g which is a semantic entity For a standard mo del of sets the syntactically di erent term insert insert e e denotes the same semantic set value
Asso ciated with any formal metho d is its assertion language usually based on some variation of rstorder predicate logic With assertions you nail down precisely your systems b ehavior It is in your assertions where the smallest change in syntax can have a dramatic change in semantics Getting the details of your assertions right is typically when you discover most of the conceptual misunderstandings of your systems design
General Rules of Thumb
What distinguishes a formal metho d from mathematics is its metho dological asp ects A sp eci cation written in the style of a given formal metho d is usually not just an unstructured set of formulae Syntactic features make it easier to read the sp ecication eg the lines in a Z schema remind the sp ecier what to write eg the mo di es clause in Larch and aid in structuring a large sp ecication into smaller more mo dular pieces eg Z schemas Larch traits
Implicit vs Explicit
Most formal metho ds have welldened sp ecication languages so the choice of what you explic itly write down is guided by the grammar and constructs of the language
However there is a danger of forgetting the p ower of the unsaid What is not explicitly stated in a sp ecication often has a meaning A naive sp ecier is likely to b e unaware of these implicit consequences thereby b e in danger of writing nonsense Here are three examples
The rst example is the frame issue If you are sp ecifying the b ehavior of one piece of the system in one sp ecication mo dule you should say what e ects that piece has on the rest of the system In some formal metho ds eg InaJo you are forced to say explicitly what other pieces of the system do not change NC
NC ^ x xn
This is sometimes impractical if n is large or worse if you do not or cannot know what the x xn are in advance
but in most algebraic sp ecication languages writing a quantier in the equation is syntactically illegal the tip o to the error is the o ccurrence of the free variable e on the righthand side of the rst equation
Auxiliary Denitions
Do not b e afraid to use auxiliary denitions
To shorten individual sp ecication statements For example when argument lists to functions get to o long say greater than four then it probably means the function b eing dened is doing to o much
To chunkify and enable reuse of concepts When a long expression say involving more than two logical op erators and three function symb ols app ears multiple say more than two times then it probably means that chunk of information can b e given a name and the name reused accordingly
To p ostp one sp ecifying certain details When you nd yourself going into to o much depth while sp ecifying one comp onent of the system in neglect of sp ecifying the rest of the system then introduce a placeholder term to b e dened later
Notation
If your primary purp ose in sp ecifying is the tangible endpro duct ie the sp ecication and you have chosen a particular formal metho d to use stick to its notation Presumably you chose this formal metho d for its brand of expressiveness or for its known applicabilit y to your problem domain A carefully designed sp ecication language should have just the right numb er and kinds of syntactic constructs to let you express all of what you want to say The constructs provided by the language let you highligh t those asp ects of the system that are imp ortant to record eg side e ects in a Larch mo di es clause At the same time they also force you to express yourself in a stylized way using a restricted vo cabulary So once in a while the notation may force you to express something more awkwardly or more verb osely than you wish however either situation may actually b e a sign to rethink your abstractions and decomp ositions
If you are primarily interested in gaining a deep er understanding of your system through the use of formalism and the formal sp ecication you write is a means toward your end then do not feel overly constrained by notation You might happ en not necessarily out of choice to b e using a formal metho d not sp ecically designed for your problem domain If there is a concept you want to express and you cannot express it easily in the given notation invent some convenient syntax say what you want and defer giving it a formal meaning till later Dont let notation get in the way of your making progress in writing your sp ecication On the other hand dont forget to dene your inventions It may b e at o dds with the rest of the semantics If youre lucky however you will have thought of a new sp ecication language idiom that is more generally useful than for just your problem at hand
Since no one metho d is suitable for sp ecifying all asp ects of a system or all kinds of systems you might cho ose to resort to the only practical strategy known to day to mix metho ds and hence to use a mix of notations For example you might use Z to sp ecify the static prop erties of your system state space and CSP its dynamic b ehavior sequences of state transitions Mixing metho ds
x x’ f
g
A A
y y’
Figure A Commuting Diagram
however is dangerous If you use di erent notations from di erent metho ds then b ecause they are based on di erent semantics eg state machines and pro cess algebras you are less likely to detect that you have sp ecied something that is actually semantically inconsisten t Combining di erent formal metho ds is a sub ject of current research eg see
Proofs
Most likely you will not b e proving theorems ab out your system from your sp ecications but if you are the rst dicult asp ect ab out doing pro ofs is knowing how formal to b e For realistic systems or large examples its impractical to do a completely formal pro of in the strictest sense of formal as used in mathematical logic What you should strive for when writing out an informal pro of is to justify each pro of step that in principle could b e formalized
Given that you are doing only informal pro ofs the second dicult asp ect is knowing when you can skip steps Some steps are obvious but others are not Also what may seem obvious often reects a hole in your argument
It is p ossible to do large formal pro ofs using machine aids like pro of checkers and theorem provers There is of course a tradeo b etween the e ort needed to learn to use one of these to ols and its input language and underlying logic and the b enet gained by doing the more formal pro of If what you are trying to prove is critical it may pay to invest the time and energy moreover this cost need b e paid only once the rst time If you plan to do more than one critical pro of it may b e worth your while Finally using machine aids keeps you honest b ecause they do not let you skip steps
Cho osing the degree of formality and how much pro of detail to give takes exp erience and prac tice gained by b oth reading other p eoples pro ofs and constructing your own A background in mathematics usually helps
There are common pro of techniques that you should have in your arsenal pro of by induction case analysis pro of by contradiction and equational reasoning substituting equals for equals You should b e familiar with natural deduction though you probably would use it for only small lo cal pro ofs
Finally the familiar commuting diagram from mathematics plays a central role in pro ofs of correctness for software systems For example an interpretation for Fig in the context of state machines is to supp ose that f is an action of a concrete machine on the concrete state x If hx f x ^ i is a state transition of the concrete machine then there exists an abstract action g such that hA x g A x i is a state transition of the abstract machine
translates to
x x T P x
If you have a complicated predicate with a lot of emb edded quantiers you may nd it helpful to break the predicate into pieces where each piece is in prenex normal form and has only one or two quantiers
Properties of sets functions and relations
When sp ecifying ob jects such as sets bags and sequences that are collections of ob jects you may b e prone to making the following common errors
Saying
x s
in the p ostcondition of an insert op eration on sets is not enough It do es not say that elements in the set that were originally in s are still there
Supp ose you are sp ecifying the b ehavior of a remove op eration which extracts and returns an element x from a set s Saying
s ^ s fx g
in the p ostcondition is too weak You need to say
s s fx g x s
since in the rst case x may not b e a memb er of s and the p ostcondition could hold by returning an arbitrary value in that case the set would also not change in value probably not the intended b ehavior for a remove op eration
Saying
s s ^ fx g
is also not strong enough Here you need to add that s is a prop er subset of s
s s ^ fx g s ^ s
since the rst case allows s ^ to have extra elements
Some sp ecication languages allow functional notation to b e used for relations that are not functions If you try to do ordinary mathematical and sp ecically algebraic reasoning with formulae written using that notation you are headed for trouble For example supp ose choose is a relation that is not a function it returns some element from a set Saying something like
f choose s g choose s
in the p ostcondition of an op eration is weaker than saying
x x choose s f x g x
since in the rst case the di erent o ccurrences of choose could return di erent values Of course if choose is a function then it is guaranteed to return the same value
Recursive denitions commonly found in algebraic sp ecications may at rst lo ok puzzling For example in sp ecifying the delete op eration for sets
delete insert s e e if e e then delete s e else insert delete s e e
a common error is to forget to reapply delete recursively if e and e are equal or to forget to reinsert e if they are not Without reapplying the delete you get a bag not a set and without reinserting the e you lose an element from the set
Summary
The pro cess of writing sp ecications b orrows from and is similar to the pro cesses of writing prose writing programs and writing mathematics You need to worry ab out the big picture eg the overall structure organization and meaning of concepts as well as the ne details eg punctua tion sp elling and sp ecial symb ols There are rules that you must always ob ey and rules that you may break once in a while There are stylistic conventions to learn and follow As with writing prose programs and mathematics writing sp ecications well takes practice and patience
There are many b o oks on how to write goo d prose eg and even some on how to write go o d programs eg This pap er is my attempt and p erhaps the rst such attempt in the formal metho ds community to cull out some common rulesofthumb for writing sp ecications Mayb e these hints can serve eventually as a basis for a set of organized guidelines for sp eciers
Acknowledgments
My views on writing sp ecications have b een greatly inuenced by John Guttag and Jim Horning originating from our joint pap er written in More recently David Garlan and Daniel Jackson have help ed identify common sp ecication stumbling blo cks that we see our students frequently face in our teaching of the Mo dels Metho ds and Analysis courses for the Carnegie Mellon MSE program I thank David and Daniel also for their useful feedback on an earlier draft of this pap er
I thank Jim Horning Leslie Lamp ort David Parnas and Leo Marcus for their critical remarks on the AMAST version of this pap er Jim as usual help ed p olish my writing They all help ed
