winter 2001 review a review of - oak ridge national …sheldon/public/fms_sheldon.pdfreview a review...

140 Volume 2, Issue 4 Copyright © 2002 John Wiley & Sons, Ltd. focussoftware

Frederick Sheldon1

Software Engineering for DependableSystems LaboratorySchool of EECS, Washington StateUniversity, Pullman, Washington99164-2752, USA1 Currently on leave at Daimler ChryslerResearch Information and Community/System Safety (RIC/AS) in Stuttgart.

Winter 2001focusreview

A Review ofSome Rigorous Software

Design and Analysis ToolsIntroductionRigorous development generally meansthe application of some sort of formalmethod(s) in software development. Aformal method [1][2] in softwaredevelopment is a method that usuallyprovides: (1) mathematically basednotations (such notations are mostly eithertextual or graphical, but tabularrepresentations can also be seen in [3][4]),(2) a process for describing how a softwareartifact (specifications, designs, sourcecode, etc.) is produced, and (3) softwaretools for formally deducing or checkingabout properties of the artifact soexpressed. Although the cost of applyingformal methods could be high at earlyphases of the Software Life-Cycle (SLC),the overall cost decreases and the overallproductivity increases [5]. Furthermore,formal methods usually make it easy tofind errors in the requirements,specification and/or design, which iscrucial for the development of mission-critical and safety-critical systems whereextensive tests are generally impossible[6]. The value of such methods hasalready been witnessed in handling severalindustrial-sized examples [7][8]; in somecases, these methods are already beingused on a regular basis in industry.

In any formal method, powerful softwaretools are usually indispensable for theeffective application of formal notationsand for reasoning about various softwareartifacts. In this paper, we survey somepopular software tools for applying formalmethods in rigorous software design andanalysis. They are PVS, Spin, UltraSAN,Statemate and Z/EVES, which are broadly

recognized by both the academic andindustrial sectors. Generally, formalmethods and their supporting tools can beapplied in any phase of the SLC fromrequirements analysis to softwaremaintenance and there are numerousmethods and tools available. However, inthis paper we focus on the tools thatfacilitate the application of formalmethods to the upstream activities of theSLC, namely requirements, specificationand design. This does not mean to saythat formal methods are not important tothe other aspects/phases of the SLC.However, the simple reason is thatobtaining consistent and complete(unambiguous) requirements specificationand design is of overwhelming importanceto safety-critical and mission-criticalsystems with which we are primarilyconcerned. Because these tools are built soclosely upon some basic underpinnings,we cannot proceed without providingsome general characterizations (nextsection). Later, each of five tools isdescribed with some established criterialike history, underlying notation,advantages and disadvantages,applicability and representative examples.We summarize this survey in the closingsection.

Formal MethodsFormal methods can be applied in variousphases of the software developmentprocess, but they are mainly used forsystem specification, verification andvalidation. Therefore, in this section, wewill describe some background onspecification languages, verification

The increasing maturity of formalmethods cannot be attributed to only

the formal notations andmethodologies that are accessible tosystem designers. The developmentof powerful software tools that apply

and facilitate the use of thesenotations and methodologies

effectively has been crucial. In thispaper, FREDERICK SHELDON,

GAOYAN XIE, OREST PILSKALNSand ZHIHE ZHOU survey some well-known software tools that have beendeployed and used by both academic

and industrial sections for rigorousdesign and analysis. The softwaretools are categorized by both the

notations and methodologies, uponwhich they are based. We mainly

discuss the tools’ underlying formalmethods, achievements and scope of

applicability. We finish with thefuture trend of the development of

such software tools.

software2-4 260302 8:49 AM 40

Frederick Sheldon

This is a reprint of an article published in the 'Software Focus," Vol. 4, Number 2, 140-150 (2002). Copyright 2002 John Wiley & Sons, Ltd. http://www.interscience.wiley.com

techniques, program refinementtechniques and validation techniquesrespectively.

Specification Languages

Formal specification languages usuallyprovide mathematically based notations todescribe a system’s structure, behavior anddesired properties. The kinds ofproperties might include functionalbehaviors, timing constraints,performance characteristics, etc. Ingeneral, there are two kinds of formalspecification languages that have beenused to write detailed specifications fornon-trivial software systems [9]:

• Model-based. With model-basedspecification languages, a model of thesystem is created using mathematicalconstructs such as sets and sequencesand the system operations are definedby how they modify the system state.Typical model-based specificationlanguages are CSP [10] and Petri Net[11], while Z [12] is a generalspecification language that is normallyused in a modeling style.

• Algebra-based. With algebra-basedspecification languages, a system isdescribed in terms of operations andtheir relationships. Typical algebra basedspecification languages are Larch [13]and Lotos [14].

Algebraic approaches are suitable todescribe systems where the objectoperations are independent of the objectstate, such as the interface specification.While model-based specification exposesthe system state and defines theoperations in terms of changes to thatstate. Additionally, some specificationlanguages like Z and Larch focus onspecifying behaviors of sequential systems,while specification languages like CSP andPetri Net are generally used to specifyconcurrent systems.

Verification Techniques

Verification techniques go one stepbeyond specification languages; they areused to analyze whether a givenspecification meets its properties. Simply,verification techniques can be groupedinto two categories:

• Deductive Verification. DeductiveVerification normally refers to the use ofaxioms and proof rules to prove the

correctness of a system, such as thepartial correctness proof of programswith the Hoare logic [15] and theoremproving techniques [16]. Typicaldeductive verification systems are HOL[17] and PVS [18].

• Model Checking. Model Checking is atechnique that relies on building a finite-model of a system and uses anexhaustive search of the state space ofthe model to check that a property holdsin that model. The typical modelcheckers are SMV [19] and Spin [20].

Deductive verification is a time-consumingprocess and it also requires muchexpertise in logic reasoning. The proof ofa single protocol can last days or months.Consequently, it is applied primarily tohighly sensitive systems such as securityprotocols. Another disadvantage ofdeductive verification is that it cannot becompletely automated, due to the fact thatcorrect termination of the program is notdecidable. However, an advantage ofdeductive verification is that it can be usedfor reasoning about infinite state systems.Though the model checking technique[21] has the advantage that theverification can be performedautomatically, it has the drawback that itcurrently can only be applied to theverification of the finite-state systems.

Program Refinement Techniques

Program refinement is a technique ofdeveloping computer programs in astepwise way. The idea of programrefinement originates from [22], wherethe author argues that the ‘Program shouldbe gradually developed in a sequence ofrefinement steps. In each step, a given task isbroken up into a number of subtasks. Eachrefinement in the description of a task may beaccompanied by a refinement of the descriptionof the data that constitutes the means ofcommunication between the subtasks.’Generally, refinement is used to refer tothe process of refining an abstractspecification into an imperative programthrough a series of transforming stepswhile preserving all properties that theoriginal specification holds.

A classic formalism that applies this idea isthe Refinement Calculus, described byRalph-Johan Back [23] in his Ph.D. thesisin 1978. This formalism provides ageneral mathematical theory for thestepwise refinement approach to programconstruction. The refinement calculus

extends the weakest preconditiontechnique of Dijkstra [24] to proceduraland data refinement, and can also be usedfor stepwise refinement of parallel anddistributed programs. Algorithms arederived by a series of correctnesspreserving refinements and programtransformations from very high-levelspecifications. The derivation is carried onuntil a program that meets the statedcriteria of efficiency and implementabilityhas been constructed. A group at ÅboAkademi University in Finland hasdeveloped a prototype tool called theRefinement Calculator [25], whichsupports this type of refinement.

One of the earliest approaches to coupleformal methods with stepwise refinementwas the VDM (Vienna DevelopmentMethod) [26]. VDM encompasses theentire program development process fromspecification to implementation.Operations are specified in the nowcommon precondition, post-conditionstyle. After specification, abstract data-types are replaced by concrete data-typesin a process called data reification. Thenext stage of the development, calledoperational decomposition, is the stepwisederivation of an implementation. Eachstep of the decomposition involvesintroducing a programming languageconstruct. There is a small collection ofdecomposition laws that are used to justifythese steps (one per program construct).It is not expected that users of VDM willwant to develop their own decompositionrules. Indeed, the semantics of theprogramming language and the proofs ofthe decomposition laws are not includedin the usual expositions of VDM. VDMalso has an object-oriented extension,called VDM++. VDM++ has been usedin various projects for requirementspecification and validation [27].

One of the most widely used formalmethods in Europe that incorporate theprogram refinement idea is the B-Method,created by Jean-Raymond Abrial [28]. TheB-method makes use of a notation basedon the mathematical concepts of settheory. Generally, the initial requirementis written in natural language, or byjuxtaposition of several descriptions:graphs, automatons, logics tables, PetriNets, etc. A B model is constructed byreusing the requirements description. TheB model is thereafter refined until acomplete implementation of the softwaresystem is obtained. Several refinementscan fulfill a specification and the choice of

Winter 2001 focus review

141Volume 2, Issue 4Copyright © 2002 John Wiley & Sons, Ltd.focussoftware

software2-4 260302 8:49 AM Page 141

solutions rests on various criteria such asthe processing speed, the precision ofcalculation or demonstrable simplicity.The consistency of the model and theconformity of the final program in relationto this model are guaranteed bymathematical proofs. The demonstrationof these proofs in a concrete case can onlybe considered with the use of automaticproof tools, such as those provided byAtelier B [29]. A commercially availablesoftware tool that is based on the B-Methods is the B-Toolkit [30].

Validation Techniques

Initially, a system model is created at anabstract level (i.e., abstract model). To doan analysis of the system we needmeasures of the system using some type ofmeasurement technique (i.e., we start atthe Real System). The Proposed System isdetailed later, but without a real system tocompare to, a great deal of work isneeded to explore the parameter space.The data collected from systemmeasurements are used to parameterizethe abstract model. However, usually thesystem model will still contain too manydetails that prevent an efficient systemanalysis. In a second abstraction step thecomputational model is created whichallows an easier and more efficient systemanalysis. The computational model can beconsidered to be the highest level ofmodel abstraction. The process of refiningthe computational model is a matter ofbuilding confidence in the model. Thus,the process of operational validation isperformed which results in a modifiedsystem and with modified system inputparameters/data. This step can berepeated until the computed performancemeasures fulfill the requirements.

If there exists no way to gather systemmeasurements for the purpose ofparameterizing the system model thenthere may be a great deal of more work toperform. In addition, the stopping rulefor accomplishing operational validationis now based on relative comparisons fromone iteration to the next. Different modelparameterizations are used to comparethe different design (or implementation)candidates with the goal of makingarchitectural design decisions. In simpleterms, using a technique commonlyknown as sensitivity analysis to optimizethe model’s structure toward achievingcritical functional and non-functionalrequirements.

There are two basic methods used to solvethe system model: mathematical andsystem simulation. The mathematicalsolution method may be further classifiedinto analytical (non-state-space-based) andnumerical (state-space-based). Themathematical method works by solving asystem (or set) of linear or differentialequations while a simulation isdifferentiated into discrete eventsimulation and continuous simulation.Combining mathematical techniques withsimulation is called hybrid simulation andwhen possible, independent componentsare solved separately using eithertechnique and are then combined in astepwise fashion (aggregation/disaggregation). One very well knownproblem when using the numericalmethod is the high computational costdue to huge state space.1

The process of validation demonstratesthat the model accurately represents thedesired system behavior with enoughdetail. In general, there are threeimportant steps:

• verify the model assumptions against thereal system (reality check),

• analyze the model structure and thelogical relations among its components,

• compare the behavior of the modelunder different experimental conditions(e.g., different load models).

We distinguish between operational andconceptual validation because there maynot be a way to parameterize the model(i.e., extracting system measures from anexisting system or its analog). In theconceptual validation phase thecomputational model is compared to thesystem model (i.e., its more detailed andless abstract predecessor). Thiscomparison must be done to test theassumptions of the higher-levelabstraction to determine if thecomputational model’s assumptions arecorrect or at least reasonable. In fact, thismay be a process of adjusting things downto a tolerable level of simplification.

Conversely, during operational validation,the computed performance results (i.e.,predictions and/or estimates) arecompared to the system measures. This isa very important step because itdetermines how the system model (andinput parameters) may be modified tomore closely describe the actual systembehavior. This process of refinement givesa computational model that moreaccurately predicts the real systembehavior under different (or new)conditions.

The validation phase will result in avalidated final model that may have beenmodified with respect to its structureand/or its parameterization (i.e.,relationships among variables,initialization and initial state etc.). Forexample, modifications to the model canbe carried out with the goal of predictingthe behavior for the system under study(SUS). When used in this sense, parts ofthe model are removed or changed in aneffort to investigate the cause and effectsof proposed enhancements oradaptations. Furthermore, once a model isvalidated it may be used to performsensitivity analysis, which can be used tosupport or discredit the modelingassumptions and analysis conclusion(s).The two most common forms of sensitivityanalysis include:

• Testing the robustness of thecomputational results against the modelassumptions. This requires that themodel be analyzed some number oftimes to allow comparing the resultsfrom one run to the next.

• Obtaining bounds on the expectedperformance measures by evaluating themodel under worst and/or best caseassumptions.

In effect, the modeling cycle yields manyinsights into the SUS. These insightsresult from the different steps in themodeling cycle and are used to improvethe system in some desired aspect. Thus,given a formal model and its externalconstraints, we can explore whatmechanisms are available to optimize thesystem behavior. For example, considersuch factors as the SUS topology, faulttolerance, timeliness, resource allocation,communications etc. How do suchmechanisms impact the behavioral aspectssuch as reliability and performability?Refining the system model can revealtrade-offs in design alternatives such as



1 Taking a pragmatic view, there are twoways to cope with this. First we may somehowtolerate or modify the large state spaces, orsecond, we may prevent the origination ofsuch large state spaces. Depending on whattype of analysis is desired, either transient orsteady state, different efficient solutiontechniques are available.


deciding what features of the systemshould be changed to improve thesystem’s reliability or validating certainassumptions with respect to variousperformance goals. More detail on thiscan be seen in [31].

Software Tools Used forRigorous DevelopmentThis section elaborates on five typicalsoftware tools for rigorous development,and the comparisons between them aresummarized in Table 1.

The PVS systemPVS [32] (Prototype Verification System) isa deductive verification system developedby SRI and is mainly intended for theformalization of requirements and design-level specifications, and for the analysis ofintricate and difficult problems. It hasbeen chiefly applied to algorithms andarchitectures for fault-tolerant flightcontrol systems, and to problems inhardware and real-time system design.Several examples are described in[18][33][34]. Projects involving PVS areongoing with NASA and several aerospacecompanies including a microprocessor foraircraft flight-control, diagnosis andscheduling algorithms for fault-tolerantarchitectures, and requirements

specification for portions of the SpaceShuttle flight-control system.

Basically, PVS is based on a theoremproving technique. The PVS systemconsists of a specification language, anumber of predefined theories and atheorem prover. PVS exploits the synergybetween a highly expressive specificationlanguage and powerful automateddeduction; for example, some elements ofthe specification language are madepossible because the type-checker can usetheorem proving. This distinguishingfeature of PVS has allowed clear andefficient treatment of many examples thatare considered difficult for otherverification systems.

The specification language of PVS is basedon classical, typed higher-order logic. PVSspecifications are organized intoparameterized theories that may containassumptions, definitions, axioms, andtheorems. An extensive prelude of built-intheories provides hundreds of usefuldefinitions and lemmas and user-contributed libraries provide many more.

The PVS theorem prover provides acollection of powerful primitive inferenceprocedures that are applied interactivelyunder user guidance within a sequentcalculus framework. The primitiveinferences include propositional andquantifier rules, induction, rewriting, anddecision procedures for linear arithmetic.

The implementations of these primitiveinferences are optimized for large proofs:for example, propositional simplificationuses binary decision diagrams, and auto-rewrites are cached for efficiency. User-defined procedures combine theseprimitive inferences to yield higher-levelproof strategies. Proofs yield scripts thatcan be edited, attached to additionalformulas, and rerun. This allows manysimilar theorems to be proved efficiently,permits proofs to be adjusted economicallyto follow changes in requirements ordesign, and encourages the development ofreadable proofs. Figure 1 from JohnRushby’s slides [35] gives an overview ofthe GUI of PVS using Greatest CommonDivisor (GCD) as an example. PVS includesa BDD (binary decision diagram)–baseddecision procedure for the relational mu-calculus and thereby provides anexperimental integration between theoremproving and CTL (computing temporallogic) model checking [36]. As a theoremprover, PVS has the inherent disadvantagesof a deductive verification system wementioned in section 1.1.2. But it is stillworthwhile to use PVS to treat those highlysensitive and dependable systems, such asnuclear power plants [37] and securityprotocols [38].

The Spin model checkerDeveloped at Bell Labs in the formalmethods and verification group starting in1980, Spin [20] has been a widelydistributed software package that supportsthe formal verification of distributedsystems. Spin is mainly used to tracelogical design errors in distributed systemsdesign (e.g., operating systems, datacommunications protocols, switchingsystems, concurrent algorithms). It checksthe logical consistency of a specificationand reports on deadlocks, unspecifiedreceptions, flags incompleteness, raceconditions, and unwarranted assumptionsabout the relative speeds of processes.

Spin’s underlying mechanism is modelchecking. However Spin can bedistinguished from conventional modelchecking tools because it doesn’t requirethe construction of a global state graph[39] (or a Kripke structure), that is whySpin is called an on-the-fly model-checker.As a model checker, Spin uses a high levellanguage called Promela to specify thesystem model, and supports allcorrectness properties expressed as systemor process invariants or as general



Table 1 Comparisons of five rigorous software tools


LTL(linear temporal logic) [40]requirements, either directly in the syntaxof LTL or indirectly as Büchi Automata[41]. Figure 2 shows the Promela andBüchi Automata representations of theLTL formula ‘[](pUq)’ (left) and ‘[] > p’(right) respectively.

Spin can be used in three basic modes:

• As a simulator, allowing for rapidprototyping with a random, guided, orinteractive simulation.

• As an exhaustive state space analyzer,capable of rigorously proving the validityof user specified correctnessrequirements (using partial orderreduction theory to optimize the search).

• As a bit-state space analyzer that canvalidate even very large protocol systemswith maximal coverage of the statespace (a proof approximation technique).

Figure 3 depicts the structure of andworkings of Spin. Besides all the benefits

of model checking, Spin has otheradvantages:

• Spin supports dynamically growing andshrinking numbers of processes, using arubber state vector technique.

• Spin supports both rendezvous andbuffered message passing, andcommunication through shared memory.Mixed systems, using both synchronousand asynchronous communications, arealso supported.

• Spin supports random, interactive andguided simulation, and both exhaustiveand partial proof techniques.

• Spin exploits efficient partial orderreduction techniques, and BDD-likestorage techniques to optimize theverification runs.

However, due to the inherent restrictionsof model checking mentioned in Section1.1.2, Spin can only be used to verify thefinite-state system. Models that can bespecified in PROMELA are, therefore,required to be bounded, and have onlycountably many distinct behaviors. Spin isby far one of the most successful softwaretools for formal verification and it isespecially useful for developingcommunication protocols.

Applications of Spin to real-life problemsalso span a broad range of fields. Theobvious applications are to prove thecorrectness of generic distributedalgorithms, such as the leader electionalgorithm, nonstandard mutual exclusionalgorithms [42], distributed process-scheduling algorithms [43], and



Figure 1 GUI of PVS

Figure 2 Automaton representation of LTL formulas Figure 3 Structure and process of spin


rendezvous algorithms. Spin has also beenapplied to the verification of data transferprotocols [44], error control protocols,controllers for reactive systems [45],railway signaling protocols and circuitry,security protocols [46], flood surge controlsystems, Ethernet collision avoidancetechniques [47], etc. Holzmann [48] givesa detailed treatment on how to design andvalidate communication protocols withSpin. Recently, Spin was used successfullyto analyze modules of a space-craft controlsystem to identify undiscovered missioncritical errors [49]2.

UltraSANUltraSAN is a software tool developed bythe UltraSAN group in the Center ofReliable and High-PerformanceComputing at the University of Illinois atUrbana-Champaign. This tool is verysuitable for mode-based performance,dependability and performabilityevaluation of computer, communicationand other systems [50]. The UltraSANtool provides high-level modelingconstructs and offers hierarchicalmodeling by means of composed models.Both analytic solvers and simulators areprovided, and the tool also has a reportgenerator, which facilitates the generationof graphs and tables from the obtainedresults.

A system is modeled as a stochastic activitynetwork (SAN), which is an extension of aPetri net. A SAN extends Petri nets byallowing transitions to be associated withrandom times and to have multiple output

paths with each having certain probability,and thus transitions are referred to asactivities in a SAN. Gates, a new type ofmodel construct, are introduced, which actas predicates to define which activities areallowed to fire at any given time. Rewardfunctions are given for activities to collectdata for the reward variables that aredefined according to the desiredperformance measurements.

The UltraSAN GUI, shown in Figure 4,provides the main control center whenUltraSAN starts up. It contains menus andbuttons that will bring up other utilitywindows for editing and solving SANs.Figure 5 shows the user interface of theSAN sub-net editor. The entire systemmodel is divided into several subnets, andeach of them is created using the SANsub-net editor. High-level modelconstructs are provided in the sub-neteditor. The SAN model shown in Figure 5gives an example of a CPU module in amulti-processor system.

The process to build and solve a modelfor a given system using UltraSANincludes the following steps:

• Build subnets: The system is dissectedinto subsystems and each subsystem ismodeled as a SAN subnet.

• Create the composed model: Sub-netsand/or replicas of subnets are joined

together according to their shared placesand result in a composed model.

• Create a solvable model: Rewardvariables are defined and the model isnow solvable.

• Study editor: values are assigned tocertain global variables, and ranges andincrements are defined for other globalvariables where we want to know howthe change of their values will impactthe performance of the system.

• Choose an appropriate solver and applyit to solving the system model.

• Generate reports and plot graphs usingthe Report Generator.

The UltraSAN tool is based on stochasticprocess theory. When certain criteria aremet, for example, all activities areassociated with exponentially distributedrandom times, a SAN can be converted toa Markov model because the underlyingstochastic process is actually a Markovprocess. Both the analytic solver anddiscrete event simulators are applicable tosolving Markov models. To handle thestate space explosion problem a ReducedBase Model Generator is provided as atool that generates the state space and thestate transitions of the stochastic process.This tool incorporates a technique basedon subnet replication to reduce the state



2 The Remote Agent (RA) embedded software(for the DEEP SPACE 1 space-craft) wasmodel checked using in the PROMELAlanguage of SPIN and then two properties,that were later formulated by the RAprogrammers, were verified. Interestinglyboth properties were broken and a total offive flawed code fragments were identified (avery successful result). According to the RAprogramming team, the effort has had amajor impact, locating errors that theybelieve would not have been locatedotherwise and in identifying a major designflaw. As an interesting aftermath, one of thefive error patterns identified was mistakenlyreintroduced in a different part of the planexecution module (not examined using SPIN)that caused a deadlock during flight in space.The problem was repaired with the help ofSPIN which avoided a concurrency bug thatcould have caused a mission critical failure.

Figure 4 The UltraSAN control panel


space of the Markov model, which wouldotherwise quickly become unmanageablefor even reasonably sized SANs. For thoseSANs that cannot be converted to Markovmodels, discrete event simulators are theonly solvers applicable.

Unlike Z/EVES or Spin, UltraSAN takesinto consideration time information for agiven system modeled as a stochasticprocess. Hence, UltraSAN is well suitedfor evaluating the system performance.These measures are hard to obtainwithout a stochastic model [51]. UltraSANcan also be used for dependability analysis[52]. The advantages of UltraSAN can besummarized as follows:

• UltraSAN supports composed modelconstruction. Replicating and joiningsmall models can obtain large models.Model replication facilitates reusingsmall models.

• UltraSAN provides both analytic solversand simulators.

• UltraSAN has techniques to reduce statespace.

• UltraSAN can solver both Markov modelsand non-Markov models.

Although UltraSAN provides plenty ofsolvers, there are certain limitations onusing these solvers. Analytic solvers can

only be used for solving Markov or semi-Markov models. These models must havea finite state space. For a semi-Markovmodel, analytic solvers are applicable onlywhen the model has at most one enableddeterministic activity at the time.Simulators can handle all models, but aninherent drawback of simulation is thelong times necessary to obtain reasonableresults for rare event simulation. A SANfor a large system tends to be quitcomplicated. There are many globalvariables and reward variables.Determining the values for those variablesand optimizing these parameters isdifficult. One should have a thoroughknowledge of SANs and the tool to handlesuch models. Moreover, UltraSAN modelsare not easily modified if the interconnecttopology changes.

STATEMATEI-Logix’s STATEMATE is a complexgraphical modeling tool with codegeneration and simulation capabilities. Itis often used in the requirements,specification, and design phases ofreactive embedded systems. Through theuse of graphical formalisms, it allows theuser to create complete specifications thatdescribe a system’s performance. Thespecification is executable, which allows

for simulations that can test the systemscapabilities and check for correct behaviorat the earliest stages of design. Inaddition, the executable specificationallows the customer and engineers toeasily proceed through the iterativeprocess of verifying that all therequirements have been satisfied.

STATEMATE uses modeling languages,which include Statecharts, SequenceDiagrams, Activity-Charts, and Module-Charts. These languages enable the userto develop various behavioral, functional,and structural views of a system.Statecharts and Sequence Diagramsexamine the ‘behavior’ of systems byexploring conditions and events thatcause transitions between states. AStatechart can be considered ageneralized state-transition diagram withmulti-level decomposition. UMLstatecharts specified by the OMG (ObjectManagement Group) are very similar, butdiffer in semantics when compared toSTATEMATE’s statecharts. The OMGdefines implementation-level semanticswhereas STATEMATE uses requirements-level semantics [53]. As an example, anevent will live arbitrarily long and actionstake time with implementation-levelsemantics as opposed to STATEMATE,where events exist for one step andactions are instantaneous. The‘functional’ view of the system isembodied in activity-charts, whichdetermine the processes, functions, andthe flow of information by using graphicaldiagrams. Module-charts are useful inanalyzing the actual ‘structure’ of thesystem from a hierarchical sub-systemperspective.

Let us inspect a simple example of anautomobile’s gear controller thatdemonstrates the diagrammaticcapabilities of STATEMATE. Figure 6,adapted from Ecosoft’s project 10407 [54],contains the top-level design of thecontroller, including the major sub-activities and the interfaces between theseactivities and the external environment:the driver motor, mechanical gearbox,and clutch. In this example, the activitiesare obtained by completing a structuralanalysis of a completed system. Noticethat only the data flow and not the controlflow is present in order to reflect the realsystem, since control flow is an abstractentity. A hierarchy of sub-activities canquickly be formed allowing for a moreunderstandable model by transferring theunnecessary details to other diagrams.



Figure 5 CPU module in subnet editor


The ‘Algorithms’ activity in Figure 6 isbroken out as a separate activity chartpermitting the user to create a detailedspecification without the additionalclutter.

Figure 7 models the transition betweengears and demonstrates how a Statechartcan quickly be created for an activity in anactivity diagram. Once the activity chartsand Statecharts have been completedSTATEMATE can take the specificationfor the gear controller and generate C orADA code that will allow the user to runsimulations. For example STATEMATEwould allow the user to enter an input tothe motor, such as the amount of gaspedal depression. We would then see theresults of our input, hopefully through asuccessful gear change.

To achieve a better understanding of thepower of STATEMATE let us briefly lookat the theoretical underpinnings byexamining one of the diagrammaticlanguages in more detail. Statecharts aresimilar to finite state machines and arerepresented by the tuple <S, T, E, V>where S is a set of states, T is a set oftransitions, E is a set of events and V is aset of variables. There are three possiblestates: BASIC, OR, AND. BASIC stateshave no sub-states, OR and AND stateshave sub-states, known as orthogonalcomponents, that are related relatively bythe exclusive-or relation plus the andrelation. Being in an OR state meansbeing in only one of its sub-states,dissimilarly, being in an AND stateimplies being in all of its orthogonalcomponents. Changes among states arerepresented by a transition (i.e., event[condition] / action). An event is aninstantaneous occurrence of a stimulus(trigger), a condition is a predicate thatmust be satisfied for a transition to occurand an action may generate other eventsor perform computations. Thus,Statecharts = finite state machines +depth + orthogonality + broadcast. Thedepth is achieved by OR states andorthogonality is achieved by AND states.Broadcast is used to communicate amongstates and is achieved by the action of atransition. In other words, when atransition is triggered, an actiongenerates an event, which we assume is tobe globally broadcast [55]. Statecharts(with STATEMATE tool-support) providea natural way to specify complex reactivesystems both in terms of how objectscommunicate and collaborate and howthey carry out their own internal



Figure 6 Activity chart for a gear controller

Figure 7 Statechart for transitions between gears


behavior. Together Activity-charts,Sequence Diagrams and Statecharts areused to describe the system functionalbuilding blocks, activities and the datathat flows between them. The modulecharts are most useful at gainingknowledge of the physical structure of thesystem. These languages are highlydiagrammatic in nature, constituting full-fledged visual formalisms, completewith rigorous semantics providing anintuitive and concrete representation for inspecting and checking for conflicts[56].

In conclusion, STATEMATE provides anexcellent array of tools that can aid in therequirements, specifications, and designphases of a project [57]. Due to its visualnature STATEMATE allows customer andengineering staff to minimize designmiscommunication [54]. One of the onlydrawbacks of STATEMATE is that thegenerated code can be large andunwieldy, however, once running, it doesprovide a venue for quality control at theearliest stages of development.

Z/EVESZ/EVES [58][59] is an interactive softwaretool developed by Odyssey ResearchAssociates (ORA), Canada, whichintegrates the Z [12][60] specificationlanguage with EVES [61] — an automateddeduction system of ORA. The Z’snotations are based on some mathematicstructures like sets, sequences, relationsand functions. It is mainly used to write asystem’s specification by defining all statesof a system [62], and the ways in whichstates may change. It can also be used todescribe system properties by definingsome theorems about the system, and toreason about possible refinements of asystem design. Though Z is flexible forspecifying a system’s function andstructure, it is not intended for thedescription of non-functional properties,such as usability, performance, size, andreliability, neither is it intended for thedescription of timed or concurrentbehaviors.

The Z/EVES has a GUI, which canfacilitate the development of a specificationwith almost all Z notations. Figure 8provides you with the specification windowof Z/EVES. Furthermore, Z/EVES canenable you to analyze or explore aspecification in several ways: (1) Syntaxand type checking, (2) Schema expansion,(3) Precondition calculation, (4) Domain

checking, and (5) General theoremproving.

Though Z/EVES is a useful tool toprecisely write down a system’sspecification and to reason about thespecification, two main drawbacks preventit from being a handy tool for manysystem designers. The first drawback isthat it is inconvenient to input the variousirregular mathematic symbols of Z whencomposing a specification. AlthoughZ/EVES provides a soft-keyboard whereyou can directly select with mousewhatever symbols you need, it is still atedious task. The second drawback isrelated to its ability to reason about aspecification’s properties defined in termsof theorems. Although Z/EVES providessome high-level proof commands, whichcan automatically carry out part of theproof work, the inherent hardness oftheorem proving still makes explorationof a specification nontrivial andchallenging.

One of the notable examples of Z’sapplication is the success of using Z toformalize part of IBM’s CustomerInformation Control System [60].Measurements taken by IBM throughoutthe development process indicated anoverall improvement in the quality of theproduct, a reduction in the number oferrors discovered, and earlier detection oferrors found in the process. IBM alsoestimated a 9% reduction in the total

development cost of the new release. In[63], Z proof is compared with varioustypes of testing approach, and “the moststriking result is that the Z proof appears to besubstantially more efficient at finding faultsthan the most efficient testing phase”.However, Z’s notations being too abstracthas the flexibility to describe complexsystems but it makes it not an easy task towork out such an abstract description.Though Z/EVES’s is useful to reason aboutsome desired properties about a systemspecification, it requires too muchexpertise on theorem proving. And thesetwo aspects still hinder them from beinggenerally accepted by system designers.

SummaryWe have introduced some basics of formalmethods and five typical software toolsthat can be used for rigorous design andanalysis. It is indisputable that thesesoftware tools, together with other toolsthat are not fully discussed here, such asthe Alloy Constraint Analyzer [64],Möbious [65] etc., have greatly facilitatedthe application of their underlying formalmethods. However, the effectiveness andapplicability of these software tools arealso restricted by the limitations of theirunderlying formal methods. An excitingresearch trend [66] is to combine severalformal methods into one software tool toeliminate some restrictions. For anexample, the PVS system has adopted a



Figure 8 The specification window of Z/EVES




References

[1] M. Clarke and J.M. Wing, Formal Methods:State of the Art and Future Directions. ACMComputing Surveys, 1996. 28(4): p. 626–643.

[2.] D. Craigen, S. Gerhart, and T. Ralston,Formal Methods Reality Check: Industrial Usage.IEEE Transactions on Software Engineering, 1995.21(2): p. 90–98.

[3.] D.L. Parnas and D.K. Peters. An EasilyExtensible Toolset for Tabular MathematicalExpressions. in Proceedings of the FifthInternational Conference on Tools And AlgorithmsFor The Construction And Analysis Of Systems(TACAS ‘99). 1999. Amsterdam, Netherlands.

[4.] J. Kirby, J. Archer, and C. Heitmeyer. SCR: APractical Approach to Building a High AssuranceCOMSEC System. in Proceedings of the 15thAnnual Computer Security ApplicationsConference (ACSAC ‘99). 1999: IEEE ComputerSociety Press.

[5.] A. Hall, Seven Myths of Formal Methods.IEEE Software, 1990. 7(5): p. 11–19.

[6.] C. Heitmeyer, J. James Kirby, B. Labaw, M.Archer, and R. Bharadwaj, Using Abstraction andModel Checking to Detect Safety Violations inRequirements Specifications. IEEE Trans. onSoftware Engineering, 1998. 24(11): p.927–948.

[7.] J. Crow and B.D. Vito, Formalizing spaceshuttle software requirements: four case studies.ACM Transactions on Software Engineering andMethodology, 1998. 7(3): p. 296–332.

[8.] M. Hinchey and J. Bowen, Industrial-StrengthFormal Methods in Practice. Formal Approachesto Computing and Information Technology series(FACIT), ed. S.A. Schuman. 1999, London:Springer-Verlag.

[9.] I. Sommerville, Software Engineering. 6th ed.2001: Addison Wesley.

[10.] C.A.R. Hoare, Communicating SequentialProcesses. 1985, London: Pretice-Hall.

[11.] J.L. Peterson, Petri Net Theory and theModeling of Systems. 1981, New York: McGraw-Hill.

[12.] J. Jacky, The Way of Z: PracticalProgramming with Formal Methods. 1997:Cambridge University Press.

[13.] J.V. Guttag and J.J. Horning,Larch:Languages and Tools for FormalSpecification. 1994, Heidelberg: Springer-Verlag.

[14.] E. Brinksma and T. Bolognesi, Introductionto the ISO specification language LOTOS.Computer Networks and ISDN Systems, 1987.14(1): p. 25–59.

[15.] K.R. Apt, Ten Years of Hoare’s Logic: ASurvey — Part I. ACM Transactions onProgramming Languages and Systems, 1981.3(4): p. 431—483.

[16.] D.A. Cyrluk and M.K. Srivas. TheoremProving: Not an Esoteric Diversion, but theUnifying Framework for Industrial Verification. inProceedings of the International Conference onComputer Design: VLSI in Computers andProcessors (ICCD ‘95). 1995. Austin, TX.

[17.] S. Agerholm. Mechanizing ProgramVerification in HOL. in Proceedings of the 1991International Workshop on the HOL TheoremProving System and its Applications. 1991. Davis,California: IEEE Computer Society Press.

[18.] S. Owre, S. Rajan, J.M. Rushby, N.Shankar, and M.K. Srivas. PVS: CombiningSpecification, Proof Checking, and ModelChecking. in Proceedings of the Computer-AidedVerification, CAV ‘96. 1996: Springer-Verlag.

[19.] K.L. McMillan, Symbolic Model Checking —an Approach to the State Explosion Problem, inSCS. 1992, Carnegie Mellon University:Pittsburgh.

[20.] G.J. Holzmann, The Model Checker Spin.IEEE Trans. on Software Engineering, 1997.23(5): p. 279–295.

[21.] E.M. Clarke, O. Grumberg, and D.A. Pled,Model Checking. 1999, Cambridge,Massachuesetts: The MIT Press.

[22.] N. Wirth, Program Development by StepwiseRefinement. Communications of the ACM, 1971.14(4): p. 221–227.

[23.] R.J. Back and J.v. Wright, RefinementCalculus: A Systematic Introduction. GraduateTexts in Computer Science. 1998: Springer-Verlag.

[24.] E.W. Dijkstra, A Discipline of Programming.1976: Prentice-Hall.

[25.] M. Butler, J. Grundy, T. Långbacka, R.Ruksenas, and J.v. Wright. The RefinementCalculator: Proof Support for ProgramRefinement. in Formal MethodsPacific’97:Proceedings of FMP’97. 1997.Wellington, New Zealand: Springer-Verlag.

[26.] C.B. Jones, Systematic SoftwareDevelopment Using VDM. 2 ed. Prentice HallInternational Series in Computer Science. 1990,London: Prentice Hall International.

[27.] J. Hörl and B.K. Aichernig, Validating VoiceCommunication Requirements Using LightweightFormal Methods. IEEE Software Magazine, 2000.17(3): p. 21–27.

[28.] J.R. Abrial, The B Book. 1996: CambridgeUniversity Press.

[29.] Atelier Bhttp://www.atelierb.societe.com/PAGE_B//uk/atb-01.htm,

[30.] B-core, http://www.b-core.com/,

[31.] F.T. Sheldon and S.A. Greiner, Composing,Analyzing and Validating Software Models toAssess the Performability of Competing DesignCandidates. Annals of Software Engineering

–Special Volume on Software Reliability, Testingand Maturity, 1999. 8: p. 239–287.

[32.] S. Owre, J. Rushby, N. Shankar, and D.Stringer-Calvert, PVS: An Experience Report, inApplied Formal Methods — FM-Trends 98, D.Hutter, W. Stephan, P. Traverso, and M. Ullman,Editors. 1998, Springer-Verlag: Boppard,Germany. p. 338—345.

[33.] J. Rushby, Specification, Proof Checking,and Model Checking for Protocols and DistributedSystems with PVS. 1997, SRI InternationalComputer Science Laboratory.

[34.] D.W.J. Stringer-Calvert, S. Stepney, and I.Wand. Using PVS to Prove a Z Refinement: ACase Study. in Proceedings of the FME ‘97:Formal Methods: Their Industrial Application andStrengthened Foundations. 1997: Springer-Verlag.

[35.] J. Rushby, A Brief Overview of PVS., SRIInternational Computer Science Laboratory.

[36.] H. Saïdi and N. Shankar. Abstract andModel Check while you Prove. in Proceedings ofthe Computer-Aided Verification (CAV’99). 1999.Trento, Italy: Springer-Verlag.

[37.] S. Koo, H. Son, and P. Seong, MathematicalVerification of a Nuclear Power Plant ProtectionSystem Function with Combined CPN and PVS.Journal of the Korean Nuclear Society, 1999. 31:p. 157–171.

[38.] D. Monniaux. Decision Procedures for theAnalysis of Cryptographic Protocols by Logics ofBelief. in Proceedings of the 12th ComputerSecurity Foundations Workshop. 1999. Mordano,Italy: IEEE Computer Society.

[39.] G.J. Holzmann and A. Puri, A Minimizedautomaton representation of reachable states.Software Tools for Technology Transfer, 1999.3(1).

[40.] R. Gerth, D. Peled, M.Y. Vardi, and P.Wolper. Simple On-the-fly Automatic Verificationof Linear Temporal logic. in Proceedings of thePSTV 1995 Conference. 1995. Warsaw, Poland.

[41.] M.Y. Vardi and P. Wolper. An Automata-theoretic Approach to Automatic ProgramVerification. in Proceedings of the First IEEESymposium on Logic in Computer Science. 1986.

[42.] G.J. Holzmann, Protocol Design: RedefiningThe State of the Art. IEEE Software, 1992. 9(1):p. 17–22.

[43.] R. Pike, D. Presotto, K. Thompson, and G.J.Holzmann. Process Sleep and Wakeup on aShared-Memory Multiprocessor. in Proceedings ofthe Spring EurOpen Conference. 1991. Tromso,Norway.

[44.] R. Bharadwaj and C. Hemeyer. VerifyingSCR Requirements Specifications Using StateExploration. in Proceedings of the FirstACM/SIGPLAN Workshop Automatic Analysis ofSoftware. 1997. Paris, France.

model-checking technique during thetheorem proof process and thus, thedegree of automation of proof can beimproved. Another trend is that sometraditional design tools [67] and modelinglanguages [68][69] are including somekinds of formal notations and reasoningfunctionalities, which can be seen as agood sign of the realization andacceptance of the importance of formalmethods by general software practitioners.

The authors would like to expressthanks to the reviewers for their kindand knowledgeable critique. Theyprovided practical and concretesuggestions. We wish also to thank DrStefan Greiner, Markus Degen and DrJuergen Schwarz at DaimlerChryslerResearch Information andCommunication for their discussion ofoperational and conceptual validation.

In addition, we thank two WSUGraduate Students: Geir Bjune for his contribution regarding BüchiAutomata and Hye Yeon Kim for hercontribution regarding Statemate.Finally, we thank C. Michael Hollowayat NASA LaRC for pointing out theoxymoron viz. specification is sometimes (appropriately) misspelledspecifiction!




[45.] T. Cattel. Using Concurrency and FormalMethods for the Design of Safe Process Control. inProceedings of PDSE/ICSE018 Workshop. 1996.Berlin, Germany.

[46.] A. Joesang. Security Protocol VerificationUsing SPIN. in Proceedings of the First SPINWorkshop. 1995. INRS Quebec, Canada.

[47.] H.E. Jensen, K. Larsen, and A. Skou.Modeling and Analysis of a Collision AvoidanceProtocol Using SPIN and UPPAAL. in Proceedingsof the Second SPIN Workshop. 1996. RutgersUniv., New Brunswick, N.J.: AmericanMathematical Society.

[48.] G.J. Holzmann, Design and Validation ofComputer Protocols. 1991, Englewood Cliffs,N.J.: Prentice Hall.

[49.] K. Havelund, M. Lowry, and J. Penix,Formal Analysis of a Space-Craft Controller UsingSPIN. IEEE Trans. on Software Engineering,2001. 27(8): p. 749–765.

[50.] UltraSAN User’s Manual: Version 3.0.1995, Center for Reliable and High-PerformanceComputing Coordinated Science Laboratory,University of Illinois at Urbana-Champaign.

[51.] K. Goseva-Popstojanova and K. Trivedi,Stochastic Modeling Formalisms for Dependability,Performance and Performability. Lecture Notes inComputer Science, 2000(1769): p. 403–422.

[52.] J. Couvillion, R. Freire, R. Johnson, W.D.Obal, M.A. Qureshi, M. Rai, W. Sanders, and J.Tvedt, Performability Modeling with UltraSAN.IEEE Software, 1991. 8(5): p. 69–80.

[53.] R. Eshuis and R. Wieringa, Requirements-level Semantics for UML Statecharts, in Formal

Methods for Open Object-Based DistributedSystems IV — Proc. FMOODS’2000, September,2000, Stanford, California, USA. 2000, KluwerAcademic Publishers.

[54.] W. Gerst, A. Imminger, and R. Pfister,Improvements in Specification, Design and Test ofSoftware for Industrial and Automotive Controllers.1996, Getreg.

[55.] S.D. Cha and H.S. Hong. Specification andAnalysis of Real-Time Systems in Statecharts. inProceedings of the 2nd International Workshopon Object-Oriented Real-Time Systems ‘96. 1996.

[56.] D. Harel and M. Politi, Modeling ReactiveSystems with Statecharts. 1998: McGraw-Hill.

[57.] D. Harel, From Play-In Scenarios to Code:An Achievable Dream. IEEE Computer Magazine,2001. 34(1): p. 53–60.

[58.] I. Meisels and M. Saaltink, The Z/EVESReference Manual. 1997.

[59.] M. Saaltink. The Z/EVES System. inProceedings of the10th International Conferenceof Z Users. 1997. Reading, UK: Springer-Verlag.

[60.] J. Davies and J. Woodcock, Using Z:Specification, Refinement and Proof. 1996:Prentice Hall International Series in ComputerScience.

[61.] D. Craigen, S. Kromodimoeljo, I. Meisels, B.Pase, and M. Saaltink. Eves System Description.in Proceedings of the Conference on AutomatedDeduction. 1992.

[62.] D. Craigen, I. Meisels, and M. Saaltink,Analysing Z Specifications with Z/EVES, in

Industrial-Strength Formal Methods in Practice,J.P. Bowen and M.G. Hinchey, Editors. 1999,Springer-Verlag: London. p. 255–285.

[63.] S. King, J. Hammond, R. Chapman, and A.Pryor, Is Proof More Cost-Effective Than Testing?IEEE Trans. on Software Engineering, 2000.26(8): p. 675–686.

[64.] D. Jackson. Automating first-OrderRelational Logic. in Proceedings of the ACMSIGSOFT Eighth International Symposium on theFoundations of Software Engineering. 2000. SanDiego CA.

[65.] D. Daly, D.D. Deavours, J.M. Doyle, P.G.Webster, and W.H. Sanders. Möbius: AnExtensible Tool for Performance andDependability Modeling. in ComputerPerformance Evaluation: Modelling Techniquesand Tools: Proceedings of the 11th InternationalConference. 2000. Schaumburg, IL: Springer-Verlag.

[66.] S. Rajan, N. Shankar, and M.K. Srivas. Anintegration of model checking with automatedproof checking. in Proceedings of the 1995Workshop on Computer-Aided Verification. 1995:Springer-Verlag.

[67.] T. Quatrani, Visual Modeling with RationalRose 2000 and UML. 2000: Addison Wesley.

[68.] J. Warmer and A. Kleppe, The ObjectConstraint Language: Precise Modeling with UML.Object Technology Series. 1999: Addison Wesley.

[69.] OMG, Unified Modeling Language (UML)Specification, 2001.http://www.omg.org/technology/documents/formal/uml.htm

Objects right out of the bag!INTRODUCTION TO PROGRAMMING AND OBJECT-ORIENTED DESIGN USING JAVAJaime Niño, University of New OrleansFrederick A. Hosch, University of New OrleansISBN: 0-471-35489-9, 650 Pages, Paper, 2001www.wiley.com/college/nino

With Niño and Hosch’s new text, you can teach yourstudents how to design applications with objects fromthe very beginning, while stressing design, problemsolving, and good programming habits.

Features• Emphasizes the distinction between

specification and implementation.• Focuses on developing components that

are conceptual parts of a larger system.• Covers established design patterns.

For more information:Visit us on the Web at www.wiley.com/college/nino.You can also order your examination copy on this site.


winter 2001 review a review of - oak ridge national …sheldon/public/fms_sheldon.pdfreview a review...

Documents