dwyer99 icse patterns

8/15/2019 Dwyer99 Icse Patterns

1/10

Patterns in Property Specificationsfor Finite-State Verification*

Matthew B. DwyerKansas State University

Department of Computingand Information Sciences

Manhattan, KS 66506-2302+l 785 532 [email protected]

George S. AvruninUniversity of MassachusettsDepartment of Mathematics

and Statistics

Amherst, MA 01003-4515+l 413 545 [email protected]

James C. CorbettUniversity of Hawai‘i

Department of Informationand Computer Science

Honolulu, HI 96822+l 808 956 [email protected]

ABSTRACT cess support for formal methods.Model checkers and other finite-state verification toolsallow developers to detect certain kinds of errors au-tomatically. Nevertheless, the transition of this tech-nology from research to practice has been slow. Whilethere are a number of potential causes for reluctance toadopt such formal methods, we believe that a primarycause is that practitioners are unfamiliar with specifi-

cation processes, notations, and strategies. In a recentpaper, we proposed a pattern-based approach to thepresentation, codification and reuse of property specifi-cations for finite-state verification. Since then, we havecarried out a survey of available specifications, collect-ing over 500 examples of property specifications. Wefound that most are instances of our proposed patterns.Furthermore, we have updated our pattern system toaccommodate new patterns and variations of existingpatterns encountered in this survey. This paper reportsthe results of the survey and the current status of ourpattern system.

Keywords

We believe that the recent availability of tool supportfor finite-state verification provides an opportunity tovercome some of these barriers. Finite-state verifica-tion refers to a set of techniques for proving propertiesof finite-state models of computer systems. Propertiesare typically specified with temporal logics or regulaexpressions, while systems are specified as finite-statetransition systems of some kind. Tool support is avail-able for a variety of verification techniques including,for example, techniques based on model checking [19]bisimulation [4], language containment [14], flow anaysis [lo], and inequality necessary conditions [l]. Incontrast to mechanical theorem proving, which oftenrequires guidance by an expert, most finite-state verifi-cation techniques can be fully automated, relieving theuser of the need to understand the inner workings of theverification process. Finite-state verification techniquesare especially critical in the development of concurrentsystems, where non-deterministic behavior makes test-ing especially problematic.

Patterns, finite-state verification, formal specification,concurrent systems

1 INTRODUCTIONAlthough formal specification and verification methodsoffer practitioners some significant advantages over thecurrent state-of-the-practice, they have not been widelyadopted. Partly this is due to a lack of definitive ev-idence in support of the cost-saving benefits of formalmethods, but a number of more pragmatic barriers toadoption of formal methods have been identified [22],including the lack of such things as good tool support,appropriate expertise, good training materials, and pro-

Despite the automation, users of finite-state verificationtools still must be able to specify the system require-ments in the specification language of the tool. Thisis more challenging than it might at first appear. Forexample, consider the following requirement for an elevator: Between the time an elevator is called at a floorand the time it opens its doors at that floor, the ele-vator can arrive at that floor’ at most twice. To verifythis property with a linear temporal logic (LTL) modechecker, a developer would have to translate this infor-mal requirement into the following LTL formula:

q (cal1 A Oopen) +*This work wan partially supported by NSF grants CGR-

9407182, CCR-9633388, CCR-9703094, and CCR-9708184 and byNASA grant NAG-02-1209.

permission to make digital or hard copies )>>>>>

Not only is this formula difficult to read and understand,it is even more difficult to write correctly without somexpertise in the idioms of the specification language.

411


2/10

We contend that acquiring this level of expertise rep-resents a substantial obstacle to the adoption of auto-mated finite-state verification techniques and that pro-viding an effective way for practitioners to draw on alarge experience base can greatly reduce this obstacle.Even with significant expertise, dealing with the com-plexity of such a specification can be daunting. In manysoftware development phases, such as design and cod-ing, complexity is addressed by the definition and useof abstractions. For complex specification problems, ab-straction is just as importan t.

In [9], we proposed to capture the experience base of ex-pert specifiers and enable the transfer of that experiencebetween practitioners by way of a specification patternsystem. This system is, essentially, a collection of pa-rameterizable, high-level, formalism-independent speci-fication abstractions. To maximize the coverage of theseabstractions, we have described a variety of techniquesfor tuning their semantics to meet the needs of differentusers. We adopted a pattern-based approach to pre-senting our specification abstractions because of its fo-

cus on the matching of problem characteristics to so-lution strategies. Patterns were originally developed tocapture recurring solutions to design and coding prob-lems [12]. Design and coding languages are rich ex-pressive formalisms that provide for a wide-variety ofsolutions to a given problem , but the full range of possi-ble solutions is is usually much wider than is necessaryor useful. Patterns are successful because practition-ers want to solve naturally occurring domain prob lems.They don’t need the full expressiveness of the languagesthey use and would often p refer guidance on how bestto use language features to solve commonly occuring

problems.We hypothesized that a pattern-based approach wouldalso be successful in the domain of property specifica-tions for finite-state verification. While there are a num-ber of very expressive formalisms, such as CTL*, mostof the specifications that we knew about fell into a rel-atively small number of categories. Thus, we believedthat a collection of simple patterns could be defined toassist practitioners in mapping descriptions of systembehavior into their formalism of choice, and that thismight improve the transition of these formal methodsto practice.

To evaluate our hypothesis, we surveyed all the sourcesof property specifications we could locate and collectedover 500 examples of property specifications for finite-state verification tools. As expected, we found that thevast major ity (92 ) are instances of patterns in oursystem. We subsequently updated the pattern systemto accommodate new patterns and variations of existingpatterns encountered in the survey. This paper gives anoverview of our updated pattern system and reports the

results of our survey of property specificatia,ns, the onlystudy of its kind we are aware of.

Section 2 describes our specification pattern system forfinite-state verification. Section 3 presents the resultsof our survey. Section 4 compares our approach withrelated work and ‘Section 5 concludes.

2 A SPECIFICATION PATTERN SYSTEMIn this section, we describe our pattern system. Webegin by giving some background on the notion of pat-terns. We then describe how this idea can be appliedto the domain of, property specifications for finite-stateverification. Finally, we describe how a set of such pat-terns can be organized and we give an overview of thecurrent state of our pattern system.

Property Specification PatternsDesign patterns were introduced [12] as a means of lever-aging the experience of expert system designers. Pat-terns are intended to capture not only a description ofrecurring solutions to software design problems, but alsothe requirements addressed by the solution, the means

by which the requirements are satisfied, and examples o fthe solution. All of this information should be describedin a form that can be understood by practitioners sothat they can identify similar requirements in their sys-tems, select patterns that address those requirements,and instantiate solutions that embody those patterns.

For finite-state verification, the system is mode led asa transition system with a finite number o f states anda set of transitions, possibly labeled with events, be-tween these states. A property specification pattern isa generalized description of a commonly occurring re-quirement on the permissible state/event sequences insuch a finite-state mode l of a system. A property speci-fication pattern describes the essential structure of someaspect of a system’s behavior and provides expressionsof this behavior in a range of common formalisms.

An example of a property specification pattern is givenin Figure 1 (we use a variant of the “gang-of-four”pattern format [12]). A pattern comprises a name ornames, a precise statement of the pattern’s intent (i.e.,the structure of the behavior described); mappings intocommon specification formalisms, examples of knownuses, and relationships to other patterns.

Some specification formalism s (e.g., quantified regularexpressions (QRE) [20]) are event-based, while others(e.g., various temporal logics, such as LTL and compu-tation tree logic (CTL) [3]) are state-based. In our pat-terns, capital letters (e.g., P, Q, R, S) stand for eventsor disjunctions of events in event-based formalisms andstand for state formulas in state-based formnlisms.

Each pattern has a scope, which is the extent of theprogram execution over which the pattern must hold.

412


3/10

Precedence

IntentTo describe a relationships between a pair of events/states where the occurrence of the first is a necessarypm-condition for an occurrence of the second. We say that an occurrence of the second is enabled by anoccurrence of the first. Also known as Enables.

Example MappingsIn these mappings S enables the occurrence of P.

CTL S precedes P:Globally -JE[lS U(P A G))]Before R -u?~[(+'A~R)U(PA+A~R A EF(R))]After Q lE[-Q U(QA lE[-dU(P A-S)])]Between Q and R AG(Q+ +3[(+ A TR)U(P AdA -R A EF(R))])After Q until R AG(Q + +[(+ A TR)U(P A+A TR)])

LTL S precedes P:Globally OP -+ (d’ iLd(s A +))Before R OR-+(TPU(SVR))After Q a-QVO(QA (lPU(S V 0-P)))Between Q and R q (Q A OR)+(TPU(S V R)))After Q until R q Q -+ ((-,PU(S v R)) V qhP))

Quantified Regular Expressions Let C be the set of all events, let [-P, Q, R] denote the expression thatmatches any symbol in E except P, Q, and R, and let e? denote zero or one instance of expression e.Event S precedes P:Globally [-PI* 1 [-s,P]*;s;c*)Before R [-RI* 1 [-P,R]*;R;C*) ) ([-S,P,R]*;S;C*)After Q [--Ql*; Q;W’l* I W, PI*;S;C*>>>’Between Q and R [- I*;( ;([-P,R]* 1 [-S,P,R]*;S;[-R]*));R;[-Q]*)*;(Q;[-RI')?After Q until R f-Q]*; (Q; (L-p, RI* I (k-s, p, RI*; S; [-RI*)); R; [-Ql*)*;

(Q; 1-CRI* (L-s,p,RI’;S;k--RI*)))?Examples and Known Uses

Precedence properties occur quite commonly in specifications of concurrent systems. One example is describinga requirement that a resource (e.g., a lock) is only granted in response to a request.

Precedence and response properties often go together. A response property says that when S occurs then anoccurrence of P must follow. If we want to restrict P to only follow S then we use a precedence property.Note that these properties do not guarantee a one-to-one correspondance between an occurrence of S and anoccurrence of P. Such additional constraints can be added using the constrained variations of these patterns.The mappings given in this pattern do not describe precedence properties where P and S occur simultanously(i.e., S must strictly precede P). To relax this constraint use the possibly empty variation of the pattern.

RelationshipsA generalization of precedence properties that allows for multiple separate states/events to constitute P andS is called the precedence chain pattern.

Figure 1: Precedence PatternThere are five basic kinds of scopes: global (the en- not occur). The scope is determined by specifying atire program execution), before (the execution up to a starting and an ending state/event for the pattern.given state/event), after (the execution after a givenstate/event), between (any part of the execution from For state-delimited scopes, the interval in which the

one given state/event to another given state/event) and property is evaluated is closed at the left and open at the

after-until (like between but the designated part of the right end. Thus, the scope consists of all states begin-

execution continues even if the second state/event does ning with the starting state and up to but not includingthe ending state. We chose closed-left open-right scopes

413


4/10

Global

BeforeI

After Q

Between Q and R

After until R

State Sequence R Q QRQ

Figure 2: Pattern Scopes

because they are relatively easy to encode in specifica-

tions and they have been the most commonly encoun-tered in the real property specifications we studied. Itis possible, however, to define scopes that are open-leftand closed-right; we explain how to construct these vari-ants of the mappings in a special part of the pattern sys-tem (described below). In event-based formalisms theunderlying model does not allow two events to coincide,thus event-delimited scopes are open at both ends.

Figure 2 illustrates the portions of an execution thatare designated by the different kinds of scopes. We notethat a scope itself should be interpreted as optional; ifthe scope delimiters are not present in an execution thenthe specification will be true.

Scope operators are not present in most specificationformalisms (interval logics are an exception). Never-theless, our experience indicates that many informal re-quirements are specified as properties of segments ofprogram executions. Thus a pattern system for proper-ties should mirror this view to enhance usability.

We note that the various specification formalisms havedifferent semantics and expressive power, and that aproperty that can be expressed easily in one formalismmay be unnatural, or even impossible to capture pre-

cisely, in a different formalism. For instance, in state-based formalisms such as LTL or CTL, it is reasonableto specify that a certain proposition hold throughout ascope (the Universality pattern), and to regard this asbeing in some sense dual to the Absence property stat-ing that a proposition holds at no state in the scope.In event-based formalisms, although it is easy to re-quire that only certain events occur within a scope, theproperty that a proposition holds throughout the scopewould probably be expressed in terms of the appropriate

occurrence of an event indicating that the propositionhas become true and the absence of an event indicatingthat it has become false, which does not bear a sim-ple relation to the Absence pattern. Similarly, we notethat some formalisms can express conditions involvinginfinite executions, while others are limited to finite sequences of states or events. Although we expect that,in practice, almost all of the properties to be specifiedcan be expressed in almost all of the com.monly usedformalisms, the pattern system should point out thesedifferences to the user.

A System of Specification PatternsWe have developed a system of property specificationpatterns for finite-state verification tools. The patternsystem is a set of patterns organized into one or morehierarchies, with connections between related patternsto facilitate browsing. A user would search. for the ap-propriate pattern to match the requirement being spec-ified, use the mapping section to obtain a template ofthe property in the formalism used by a particular tool,and then instantiate that template by plugging in the

state formulas or events specific to the requirement.

In defining a specification formalism, one attempts togive a small set of independent concepts from whicha large class of interesting specifications can be con-structed. With the collection of specification patterns,however, we are neither trying to give a smallest set thatcan generate the useful specifications nor a completelisting of specifications. Patterns are in the system be-cause they appear frequently as property specifications.We hypothesize that only a small fraction of the possibleproperties that can be specified using logics or regularexpressions commonly occur in practice. These proper-ties, and simple variants of them, make up our patternsystem. We expect the set of patterns to grow overtime as developers encounter property specifications ofreal systems that do not easily map onto the existingpatterns.

The PatternsSpace limitations prohibit description of the patternsin full detail; for that we have set up a web-site IS]The full patterns contain additional examples, explana-tion of relationships among the patterns, and mappingsto various formalisms. A list of our set of patterns,

with short descriptions, follows. In the descriptions, forbrevity, we use the phrase “a given state/event occurs”to mean “a state in which the given state formula istrue, or an event from the given disjunction of events,occurs.”

Absence A given state/event does not occur within ascope.

Existence A given state/event must occur within a

414


5/10

scope.

Bounded Existence A given state/event must occur ktimes within a scope. Variants of this pattern specifyat least k occurrences and at most k occurrences of astate/event. The elevator property in Section 1 is aninstance of this pattern.

Universality A given state/event occurs throughout ascope.

Precedence A state/event P must always be precededby a state/event Q within a scope. Figure 1 gives thekey elements of the pattern.

Response A state/event P must always be followed bya state/event Q within a scope.

Chain Precedence A sequence of states/events9 , . . . , P,, must always be preceded by a sequenceof states/events Qi, . . . , Qm. This pattern is a gen-eralization of the Precedence pattern.

Chain Response A sequence of states/eventss >*-* 1P,, must always be followed by a sequenceof states/events Qi, . , . , Qm. This pattern is ageneralization the Response pattern. It can be usedto express bounded FIFO relationships.

OrganizationWe believe the most useful way to organize the patternsis in a hierarchy based on their semantics. For exam-ple, some patterns require states/events to occur or notoccur e.g., the Absence pattern), while other patternsconstrain the order of states/events e.g., the Responsepattern). One organization for our pattern system is

the hierarchy illustrated in Figure 3. This hierarchydistinguishes properties that deal with the occurrenceand ordering of states/events during system execution.

In addition to the patterns themselves, we provide a setof pattern notes, which explain how to combine and/orvary the patterns. For example, pattern templates aretypically parameterized by individual events or stateformulae. In some cases, however, we can allow pat-terns of states/events to be substituted into the tem-plates. Pattern notes give the user guidance on when itis safe to make these substitutions. There are also pat-tern notes describing how to construct known variantsof the patterns, such as those with left-open right-closedscopes, or those in which specific states/events are ab-sent from segments of a pattern.

In the original pattern system described in [9], we pro-vided mappings to three formalisms: LTL, CTL, andQREs. We have since added mappings for two addi-tional formalisms: Graphical Interval Logic GIL) [7]and the INCA query language [5] due to space limita-tions, we do not show these mappings in Figure 1).

3 SURVEY OF PROPERTY SPECIFICA-TIONS

In [9], we first proposed the idea of a pattern system forproperty specifications for finite-state verification. Weassumed that the specifications people write fall intoa small number of categories, although we gave littleempirical evidence for this important assumption. Sincethen, we have collected over 500 example specificationsand found that, indeed, most fall into a small number offamiliar categories. We describe our survey of propertyspecifications in this section.

Data CollectionWe collected example specifications from:

l Verification papers in the literature.l Others who have written/collected specifications.

In particular, we contacted researchers who havebuilt/used verification tools and asked for examplespecifications. We also sent a request for examplesto several mailing lists and newsgroups.

l Student projects from two offerings of the first au-

thor’s graduate course in finite-state verification.

In all, we collected 555 specifications from at least 35different sources. The specifications collected were inmany forms. For most we had an expression of therequirement in a specific specification formalism e.g.,LTL). For many we also had an informal prose descrip-tion of the requirement. The specifications came froma wide variety of application domains, including: hard-ware protocols, communication protocols, GUIs, controlsystems, abstract data types, avionics, operating sys-tems, distibuted object systems, and databases. Com-

plete descriptions of these specifications can be foundon our Specification Patterns web page [8], along withcitations for 34 published papers from which many ofthem were taken.

We examined each specification and manually deter-mined whether it matched a pattern and, if so, the scopeof the property. In most cases, he formal version of thespecification was an instantiation of a template mappingfor a specific pattern/scope; in this case.the classifica-tion was trivial. If we could not find a trivial match,we looked at the specification more carefully and stillcounted it as a match if:

l The specifichtion was formally equivalent to an in-stantiation of one of our ternplate mappings. Forexample, the LTL formula YOP is equivalent toq TP, which is our mapping for global) absence ofP.

l The specification can be obtained from one of ourpatterns using parameter substitution. As de-scribed in Section 2, the template mapping pa-rameters for logics are usually state-formulae i.e.,

415


6/10

/ paa\OCCUAW Order

*bd/ \\&cl Preceded lhhainExistence

Universality ExistencePrecedence Response

Figure 3: A Pattern Hierarchyboolean combinations of propositions). For somepatterns/scopes, it is safe to substitute tempo-ral formulae into the template; guidance on whenthis is correct is given in a pattern note. We en-countered 13 cases in which the requirement “in-finitely often P” was realized using the CTL for-mula AG(AF(P)), which is a universal pattern in-stantiated with the parameter AF(P).

l The specification was a known variant of one of ourpatterns. As noted in Section 2, the mappings forour scopes are closed on the left and open on theright. Nearly all of the non-global specificationswe collected were left-closed right-open, but threewere left-open right-closed. As mentioned in Sec-tion 2, a pattern note explains how to open the leftend of the scope and how to close the right, end.Other variants mentioned in the pattern notes in-clude chain patterns where certain states or eventsare forbidden between elements of the chains.

l The specification was a new van’ant of one of ourpatterns. We discovered two interesting variants ofthe Response pattern. The first, describes an execu-tion in which S must respond to P and there mustbe no Zs between the (stimulus) P and the (re-sponse) S. The second requires that the responsebe in the next s tate/event. We found 41 instancesof the constrained response variant and 8 instancesof the next response variant. We have added pat-tern notes explaining how to adjust the mappingsto obtain these variants.

l The formal expression of the specification wasclearly in error, and the correct specification wasa instance of one of our patterns. About 10 of thespecifications we collected were clearly in error-

either the formal expression did not match theprose description, or the formal expression did notmake sense. When the intent of the specificationwas clear, and the intent matched one of the pat-terns, we counted the example as a match.

For each specification, we recorded the following infor-mation (when available) :

Requirement A prose description of the requirement,.

Pattern The pattern of which we determined this re-quirement is an instance (if any).

Scope The scope of the pattern.

Parameters Notes on the parameters provided to thetemplate (e.g., arrays of propositions, nested tempo-ral formulae).

Mappings Mappings of the property to formal specification languages (LTL, CTL, QR.Es, GIL, INCA)Most examples collected have exactly one mapping.

Source The source of the example (i.e., person, cita-tion).

Domain The application domain the example is from.

Note Any additional information on the example.

An sample entry for a specification is:

REQUIREXNT: When a server requests its registration inthe ROT, it will eventually be registered.

PATTERN: ResponseSCOPE: Global

PARAMIZTERS:ropositions (boolean vector)LTL: [](RequestedRegisterImpl[i] -> 0ServerRegisteredCil)NOTE: this is replicated for all modeled serversSOURCE:Gregory Duval \cite, RI, pp. 48DOMAIN: Distributed Object System

As noted above, all of the specifications we found areavailable on the World Wide Web at [8].

ResultsThe data are summarized in Table 1, which gives to-tals for each pattern/scope combination, and in Fig-ure 4, which graphs the totals for each pattern andscope (examples not matching any pattern are groupedunder UNKNOWN). Of the 555 example specificationswe collected, 511 (92 ) matched one of our patterns.As shown in Figure 4, the most, common pattern in thesample is Response, with the next, most common beingUniversality and its dual Absence. Together, these threepatterns accbunted for 80 of the sample.

Although we found at least one instance of each pattern,Figure 4 shows that a few patterns cover a majority ofthe samtile. In fact, the frequencies of the patterns,

416


7/10

ScopePattern Glbl Aftr Btwn Untl TotAbsence 41 5 12 18 9 85Universality 110 5 2 1 119Existence 12 4 8 1 26Bound Exist 0 0 1 0 1Response 241 3 0 0 245Precedepce 25 1 0 0 26Fksp. Chain 8 0 0 0 8Prec. Chain 1 0 0 0 1

UNKNOWN 1 44Total 438 8 25 29 11 1 555

Table 1: Totals for Patterns/Scopes (All Data)

Patterns

UNKNOWN

GlobalBetween

After

Until

Before

Scopes

Figure 4: Total Number of Instances for Pat-terns/Scopes

when put in order, drop off very quickly. This raisesthe issue of size: how many patterns should be in thepattern system? The more patterns in the system, themore likely a match will be found. On the other hand,the system should be small enough to be easily browsed.Adding patterns that match very few real specificationsmay not be worth the slight increase in the pattern sys-tem’s size.

As can be seen from Figure 4, most examples (80 )used a global scope. Also, note that almost all exam-

Patterns

Response 48

Universality32

Absence

UNKNOWN

Precedence

Existence

Resp. Chain

Pm. Chain


8/10

Response

Universality

Absence

UNKNOWN

Precedence

Existence

Resp.Chain

Prec.Chain

Patterns

Bounded xist. y

Scopes

Global

Between

Beforei

8

614

BeforeAfter

Figure 6: Percentage of Specifications for Each Pat-tern/Scope (Before vs. After)

four most common patterns (Response, Universality,Absence, UNKNOWN) is the same. The rankings forthe remaining patterns were different, but given thesmall number of instances of these patterns in the dataset (fewer than lo), the data are likely to be noisy. Onedifference is that we wrote more specifications with non-global scopes, although the vast majority of our specifi-cations also used a global scope. Interestingly, we wrotemore specifications that fall outside the pattern systemthan others.

Another interesting question is whether having the pat-tern system affects the kind of specifications peoplewrite. Finite-state verification is often used to checkcritical requirements, but the exact choice of require-

ments to be checked, as well as the way these require-ments are expressed n terms of the model, is usually leftto the analyst. Given a pattern system to assist in theformulation of property mappings, an analyst might bemore likely to use more complex patterns and/or scopes.To investigate this, we took the set of specifications weor those affiliated with us had written (the “us” set fromabove), and divided it into the 165 specifications writ-ten before we developed the pattern system and the 139specifications written after. This comparison is shownin Figure 6.

The differences in this case are more pronounced (al-though the sample size is smaller, so there may be morenoise). Several more complex patterns (e.g., chains)only appear after the pattern system was introduced.More specifications created after the development o f thepattern system used non-global scopes (33 vs. 5 ),and those later specifications were more evenly (thoughnot uniformly) spread over the different patterns. Alsonote that all specifications written after the pattern sys-tem matched one of the patterns.

We have demonstrated that a pattern system for prop-erty specifications for finite-state verification is potentially useful by showing that most specifications fall inta small number of categories. To show that. the systemis actually useful would require answering several moredifficult questions, including:

l Do-patterns facilitate the learning of the specification formalisms?

l Do patterns allow specifications to be written morequickly?

a Are the specifications generated from patternsmore likely to be correct?

Although we believe that the answer to all of thesequestions is yes, definitive answers would require ex-periments with human subjects. To date, we have onlyannecdotal evidence to support our claims, largely fromthe first author’s experience teaching a finite-state ver-ification course in a Masters level software engineeringcurriculum.

4 RELATED WORKTraditionally, specification formalisms are presented in

terms of a minimal set of operators in order to sim-plify their semantics definition. Additional operatorare then defined in terms of those operators, e.g., q IP =YOTP, so only a few primitives need to be formally defined. Users of such formalisms would prefer to writespecifications at a higher level than this, so many for-malisms provide built-in higher-level operators or abstractions. The classic example is leads-to, introducedby Owicki and Lamport [21], which plays a critical roin formalisms such as UNITY [2] and TLA 11151.eads

418


9/10

to corresponds to a global response pattern in our sys-tem. A number of formalisms have been designed toallow for the definition of additional higher-level de-rived operators. For example, LUSTRE [13] propertyspecifications, which are safety properties written in alinear-time temporal logic, are often written in terms ofderived operators. In [13], the authors illustrate this ca-pability by defining since and never operators in termsof the basic LUSTRE operators. These derived opera-tors correspond to an existence with an after scope andan absence with a global scope, respectively. Our pat-tern system supports a common, but fixed set of specifi-cation abstractions in formalisms that lack explicit sup-port for defining abstractions.

Like our patterns, interval logics e.g., [7]) provide theuser with a higher-level mechanism for defining the seg-ments of the system’s execution over which a propertymust hold. In fact, the interval construction operatorsprovided by such logics are much more general than ourfive scopes. We have essentially taken five commonly oc-curing intervals and packaged them with the patterns.

Some recent work in requirements engineering has ex-plored the use of templates or patterns in the construc-tion of requirements. For instance, van Lamsweerde andhis co-authors [6,18] have suggested using a library of re-finements to construct detailed requirements from goals,and the Attempt0 Controlled English project [ll], whichuses a restricted subset of natural language to formulaterequirements, offers annotated templates to guide non-expert users. These efforts are aimed at the develop-ment of essentially complete requirements for a system,while our pattern system is concerned more with thetranslation of particular aspects of such requirements

into the formal specifications suitable for use with finite-state verification tools.

There has been little study of the classes of specifica-tions that developers may or do write. Manna andPnueli [17] address this issue from a theoretical angle byproposing a syntactic classification of LTL formula thatcompletely describes the space of possible specificationsone may write in LTL. Their taxonomy of specificationsincludes categories that are much broader than our pat-terns. As a consequence, most of our patterns are eas-ily categorized in their classification: precedence, ab-sence, and universal patterns with global scopes are allsafety properties, existence patterns with global scopeare guarantee properties, and response patterns withglobal scope are response properties. Our k-bounded ex-istence pattern is very similar to their k-bounded over-taking property which is a safety property). With chainpatterns and complex scopes the’mapping to syntacticcategories is more difficult due to the nature o f thecanonical forms which define the categories). In con-trast to this work, the goal of our work is to give a

constructive description of the classes of specificationsthat occur most frequently in practice.

In [16], Manna and Pnueli adopt a more pragmatic ap-proach that is in line with the intent of our pattern sys-tem. They claim that very little of the general theory oftemporal logic is required to handle the most important,and common, correctness properties of concurrent pro-grams. They define a restricted proof-system that han-dles invatiance properties which subsume most univer-

sal and absence patterns), response properties whichsubsume response patterns) and precedence propertieswhich subsume precedence and bounded existence and

are similar to chain patterns). Their precedence proper-ties also subsume after-until scope versions of universaland absence patterns. The data we present in this papersupport Manna and Pnueli’s intuition about commonproperties, since we found that absence, universal andresponse patterns constitute the bulk of the propertiesin our survey.

5 CONCLUSIONSWe believe that the definition and use of high-levelabstractions in writing formal specifications is an im-portant factor in making automated formal methods,specifically finite-state verification tools, more usable.Our specification pattern system provides a set of com-monly occuring high-level specification abstractions forformalisms that do not support the definition of such ab-stractions directly. We have described an updated pat-tern system we developed for property specifications infinite-state verification and have collected a large sam-ple of specifications that suggests that most propertyspecifications people write are instances of patterns inthis system.

We are currently exploring several directions for furtherwork on specification patterns. We are working to definepatterns to simplify writing a class of assume-guaranteeproperties in CTL. Writing such specifications in LTL isstraightforward; in CTL, however, such properties canbe quite tricky to express. We are studying the benefitsof defining a language for property specification basedon the patterns, providing automated support for com-piling properties expressed in that language to specificformalisms and checking the legality of pattern substi-tutions. We are studying approaches for checking theconsistency of pattern mappings expressed in multipleformalisms. For example, while CTL and LTL are not,in general, co-expressive, all of our CTL and LTL map-pings lie in the all-paths fragment of CTL*; thus wemay be able to formally justify the equivalence of thosemappings.

The survey described in this paper is certainly not ex-haustive, and we expect that, as the application offinite-state verification technology spreads, the types of

419


10/10

specifications used by developers may change over time.We view the pattern system as a dynamic entity thatwill grow through a process of dialog and critical reviewby the.community of developers and users of finite-stateverification techniques and we welcome contributionsfrom that community.

ACKNOWLEDGMENTSWe would like to thank Laura Dillon, Hamid Alavi andCorina Pasareanu for making significant contributions

to the pattern system. We would like to thank thefollowing people for contributing specifications, directlyor indirectly: G. Holzmann, B. Yang, T. Chamillard,F. Cassez, A. van Lamsweerde, E.H. Ache, J. Atlee,S. Berezin, A. Biere, V. Carr, T. Cattel, W. Ghan, A.Cimatti, E. Clarke, R. Cleaveland, B. Donahue, G. Du-val, Y. Gao, F. Giunchiglia, R. Gulla, K. Havelund, L.Hines, J. Isom, H. Ejersbo Jensen, J. Julliand, K.G.Larsen, P.B. Ladkin, S. Leue, M. Lowry, P. Merino, J.McClelland, T. McCune, G . Mongardi, T. Nakatani, G.Naumovich, M. Novak, J. Penix, S. Probst, M. Ryan, A.Skou, A. Srikauth, F. Torielli, P. Traverso, J. M. ‘Ikoya,

M. Vaziri-Farahani, J.M. Wing, and K. Winter.REFERENCES

PI

PI

131

PI

[51

PI

[71

G. Avrunin, U. Buy, J. Corbett, L. Dillon, and J. Wile-den. Automated analysis of concurrent systems withthe constrained expression toolset. IEEE Transactionson Software Engineering, 17(11):1204-1222, Nov. 1991.

K. M. Chandy and J. Misra. Parallel Program Design:A Foundation. Addison Wesley Publishing Company,Inc., Reading, Massachusetts, 1988.

E. Clarke, E. Emerson, and A. Sistla. Automatic ver-ification of finite-state concurrent systems using tem-poral logic specifications. ACM Transactions on Pro-

gramming Languages and Systems, 8(2):244-263, Apr.1986.

R. Cleaveland, J. Parrow, and B. Steffen. The Con-currency Workbench: A semantics based tool for theverification of concurrent systems. ACM Transactionson Programming Languages and Systems, 15(1):36-72,Jan. 1993.

J. C. Corbett and G. S. Avrunin. Using integer pro-gramming to verify general safety and liveness proper-ties. Formal Methods in System Design, 6:97-123, Jan.1995.

R. Darimont and A. van Lamsweerde. Formal refine-ment patterns for goal-driven requirements elaboration.

In D. Garlan, editor, Proceedings of the Fourth ACMSIGSOFT Symposium on the Foundations of SoftwareEngineering, pages 179-190, San Francisco, Oct. 1996.ACM (Proceedings appeared in Software EngineeringNotes, 21(6).

L. K. Dillon, G. Kutty, L. E. Moser, P. M. Melliar-Smith, and Y. S. Ramakrishna. A graphical inter-val logic for specifying concurrent systems. ACMTransactions on Software Engineering and Methodol-ogy, 3(2):131-165, Apr. 1994.

PI

PI

PO1

WI

PI

[131

P41

P51

WI

P71

WI

PI

WI

Pll

PI

M. Dover, G. Avrunin, and J. Corbett. A Systemof Spec ication Patterns. http: //uvw . cis . ksu. edu/santos/spec-patterns, 1997.

M. Dwyer, G. Avrunin, and J. Corbett. Propertyspecification patterns for finite-state verification. InM. Ardis, editor, Proceedings of the Second Workshopon Formal Methods in Software Practice, pages 7-15,Mar. 1998.

M. Dwyer and L. Clarke. Data flow analysis fo r veri-fying properties of concurrent programs. Software En-gineering Notes, 19(5):62-75, Dec. 1994. Proceedingsof the Second ACM SIGSOFT Symposium on Founda-tions of Software Engineering.

N. E. Fuchs ‘and R. Schwitter. Attempt0 ControlledEnglish (ACE). In CLAW 96, the First InternationalWorkshop on Controlled Language Applications, 1996.

E. Gamma, R. Helm, R. Johnson, and J. Vlissides. De-sign Patterns: Elements of Reusable Object-OrientedSoftware. Addison-Wesley, 1994.

N. Halbwachs, P. Caspi, P. Raymond, and D. Pi-laud. The synchronous programming language LUS-TRE. Proceedings o f the IEEE, 79(9), Sept. 1991.

Z. Har’El and R. P. Kurshan. Software for analyticaldevleopment of communication protocols. AT&T Tech-nical Journal, 69(1):44-59, 1990.

L. Lamport. The Temporal Logic of Actions. ACMTransactions on Programming Languages and Systems,16(3):872-923, May 1994.

Z. Manna and A. Pnueli. Tools and rules for the practic-ing verifier. Technical Report STAN-CS-90-1321, Stan-ford University, July 1990. appeared in Carnegie MellonComputer Science: A 25 year Commemorative, ACMPress, 1990.

Z. Manna and A. Pnueli. The Temporal Logic of Reac-

tive and Concurrent Systems: Specification. Springer-Verlag, 1991.

P. Massonet and A. van Lamsweerde. Analogical reuseof requirements frameworks. In Proceedings of RE ‘97-Third International Conference on Requirements Engi-neering, 1997.

K. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993.

K. Olender and L. Osterweil. Cecil:, A sequencingconstraint language for automatic static analysis gen-eration. IEEE nansuctions on Software Engineering,16(3):268-280, Mar. 1990.

S. S. Owicki and L. Lamport. Proving liveness prop-erties of concurrent systems. ACM ‘i’+ansactions onProgramming Languages and Systems, 4:455495, July1982.

D. Rosenblum. Formal methods and testing: Whythe state-of-the-art is not the state-of-the-practice (IS-STA’96/FMSP’96 panel summary). ACM SIGSOFTSoftware Engineering Notes, 21(4), July 1996.

420

dwyer99 icse patterns

Documents