Choosing a Formal Method

Choosing a Formal Method

Scope

This document is aimed at those who have decided that it would be agood idea for their project or organisation to use a formal method, butare not sure what steps to take next: which formal method or which kindof formal method will be best for their purposes.

In order to result in a successful outcome, choosing aformal method requires the same approach as any other technicaldecision. First, one needs to be clear about one’s objectives and toknow what are the technical, organisational and management constraints.Then one may focus on the characteristics of a formal method which willmeet those objectives and constraints. Finally a method can be selectedwhich most closely conforms to, and whose tools, experience and supportmost closely conforms to those characteristics.

General Approach

This guide is a framework which, we hope, will helpyou to construct for yourself a decision process tailored to your ownapplication and organisation. The sections which follow consist ofpossible aims, criteria, characteristics and needs. Considering whethereach of these applies should help to focus on and define theobjectives, constraints and other criteria particular to an applicationand organisation which form the context of a choice of formal method,i.e. your application and that part of your organisation which will beusing a proposed formal method. The bulleted points, which can betreated as a set of questions for you to ask yourselves, are a guideonly; they can be extended or modified according to each individualorganisational and technical environment. What is important is toestablish and define that environment as clearly as possible beforeproceeding to make a selection. The purpose of the questions is to helpthe user organisation to determine appropriate criteria. Accordingly,the questions are grouped into some principal categories in thefollowing sections:

• General reasons for choosing formality
• Characteristics of the application
• Criteria for success ofapplication
• Needs and constraints of the organisation 

The answers to these questions form acontext in which you can then focus on what are the characteristics ofthe formal method which is most suitable for your needs. To help you todo that, the “possible characteristics” of a formal method arepresented in the last main section:

• Characteristics of a formal method 

Having gone through this process you can then match your list ofrequirements against what is on offer, talking to tool suppliers etc.

General reasons for choosing formality

Software and system quality, consistency and integritycan be improved by formalising different products and processes in thedevelopment cycle. Are the reasons you want to apply formal techniques:

• to improve quality and rigour of whole development process? 

This would be the case if yourorganisation wished to adopt a formal approach to software or systemdevelopment as part of a general improvement of its developmentprocess. An improvement of development technology, like adopting formalmethods, is a valid aspect of process improvement just as areimprovements in documentation, configuration management, measurementetc.

• to improve integrity, reliability or other characteristics of the system?

In some circumstances formal methods maybe applied to system development as well as software development. Theanalysis and design of the system architecture usually precedes thespecification of software components. Do you propose to apply formalmethods to the development of the larger system as well as the software?

• to reduce specification errors?

Expressing the specification,particularly the functional specification, of software and systemcomponents helps greatly to reduce errors in specifications. Is thisyour principal motivation?

• to improve requirements definition?

Requirements, especially systemrequirements, are usually expressed in non-formal language. The processof deriving formal expressions of specifications from them nearlyalways has the effect of improving those requirements definitions.Experience indicates that omissions and inconsistencies in therequirements statements are found more reliably than with othertechniques. Is requirements analysis and definition the phase of thelife-cycle which you particularly wish to address?

• to improve documentation and understanding of designs?

There is at present a great quantity oflegacy software which is undocumented or with very inadequatedocumentation. Maintaining the software is as a result extremelydifficult and confidence in its reliability is low. Good documentationreduces these problems and formal descriptions of the life-cycleproducts dramatically reduces them. Is this your motivation for usingformal methods?

• to provide a firmer foundation for maintenance and enhancement? See above.
• to explore the properties of a design architecture?

In some applications it is not possibleto characterise the behaviour of the context of the software; in sometelecommunications environments, for example, patterns of traffic maybe to an extent unpredictable. A formal model of the design of thesoftware can provide an understanding of its properties andlimitations. Do you wish to improve your knowledge of your software’sproperties by more accurately modelling the design?

• to provide a more rational basis for choosing test data?

Relatively recently, techniques havebeen developed for deriving test data from functional specifications ofsoftware components. Such test sets may be more closely related to thespecifications which the software is designed to fulfil, and theprocess of test set derivation is more systematic if formal methods areused for functional specification.

• to be as certain as possible that the design and implementation are error-free?

In safety-critical and other criticalcontexts it can be of utmost importance to ensure that the software isfunctionally free from errors. Applying formal descriptions tospecifications and designs enables proofs of correctness between thosesuccessive stages of the development cycle.

• to meet particular customer or standards requirements?

Some contracts mandate the use of formalmethods during certain stages of the development cycle, or mandateadherence to standards which do so.

 

 原文地址http://www.fmeurope.org/?page_id=264