Formal specification Software Engineering 9th ed (intro txt) I. Sommerville (Pearson, 2011)
334 Chapter 12
■
Dependability and security specification
The starting point for all formal development processes is a formal system model, which serves as a system specification. To create this model, you translate the sys-
tem’s user requirements, which are expressed in natural language, diagrams, and tables, into a mathematical language which has formally defined semantics. The for-
mal specification is an unambiguous description of what the system should do. Using manual or tool-supported methods, you can check that a program’s behavior is
consistent with the specification.
Formal specifications are not just essential for a verification of the design and implementation of software. They are the most precise way of specifying systems,
and so reduce the scope for misunderstanding. Furthermore, constructing a formal specification forces a detailed analysis of the requirements and this is an effective
way of discovering requirements problems. In a natural language specification, errors can be concealed by the imprecision of the language. This is not the case if the
system is formally specified.
Formal specifications are usually developed as part of a plan-based software process, where the system is completely specified before development. The system
requirements and design are defined in detail and are carefully analyzed and checked before implementation begins. If a formal specification of the software is developed,
this usually comes after the system requirements have been specified but before the detailed system design. There is a tight feedback loop between the detailed require-
ments specification and the formal specification.
Figure 12.12 shows the stages of software specification and its interface with soft- ware design in a plan-based software process. As it is expensive to develop formal
specifications, you may decide to limit the use of this approach to those components that are critical to the system’s operation. You identify these in the architectural
design of the system.
Over the past few years, automated support for analyzing a formal specification has been developed. Model checkers Clarke et al., 2000 are software tools that take a
state-based formal specification a system model as an input, along with the specifica- tion of some formally expressed desirable property, such as ‘there are no unreachable
states.’ The model checking program exhaustively analyzes the specification and either reports that the system property is satisfied by the model or presents an example
that shows it is not satisfied. Model checking is closely related to the notion of static analysis and I discuss these general approaches to system verification in Chapter 15.
Formal specification techniques Formal system specifications may be expressed using two fundamental approaches, either as models of the
system interfaces algebraic specifications or as models of the system state. You can download an extra web chapter on this topic, where I show examples of both of these approaches. The chapter includes a formal
specification of part of the insulin pump system.
http:www.SoftwareEngineering-9.comWebExtraChapsFormalSpec.pdf
12.5
■
Formal specification 335
The advantages of developing a formal specification and using this in a formal development process are:
1. As you develop a formal specification in detail, you develop a deep and detailed
understanding of the system requirements. Even if you do not use the specifica- tion in a formal development process, requirements error detection is a potent
argument for developing a formal specification Hall, 1990. Requirements problems that are discovered early are usually much cheaper to correct than if
they are found at later stages in the development process.
2. As the specification is expressed in a language with formally defined semantics,
you can analyze it automatically to discover inconsistencies and incompleteness. 3.
If you use a method such as the B method, you can transform the formal speci- fication into a program through a sequence of correctness-preserving transfor-
mations. The resulting program is therefore guaranteed to meet its specification.
4. Program testing costs may be reduced because you have verified the program
against its specification. In spite of these advantages, formal methods have had limited impact on practical
software development, even for critical systems. Consequently, there is very little experience in the community of developing and using formal system specifica-
tions. The arguments that are put forward against developing a formal system specification are:
1. Problem owners and domain experts cannot understand a formal specification
so they cannot check that it accurately represents their requirements. Software engineers, who understand the formal specification, may not understand the
application domain so they too cannot be sure that the formal specification is an accurate reflection of the system requirements.
2. It is fairly easy to quantify the costs of creating a formal specification, but more
difficult to estimate the possible cost savings that will result from its use. As a result, managers are unwilling to take the risk of adopting this approach.
Increasing Contractor Involvement Decreasing Client Involvement
Specification Design
User Requirements
Definition System
Requirements Specification
Architectural Design
Formal Specification
High-Level Design
Figure 12.12 Formal
specification in a plan-based software
process
336 Chapter 12
■
Dependability and security specification
Formal specification costs Developing a formal specification is an expensive process as quite a lot of time is needed to translate the
requirements into a formal language and check the specification. Experience has shown that savings can be made in system testing and verification and it seems that specifying a system formally does not significantly
increase the overall development costs. However, the balance of costs changes, with more costs incurred early in the development process.
http:www.SoftwareEngineering-9.comWebFormalSpecCosts
3. Most software engineers have not been trained to use formal specification lan-
guages. Hence, they are reluctant to propose their use in development processes. 4.
It is difficult to scale current approaches to formal specification up to very large systems. When formal specification is used, it is mostly for specifying critical
kernel software rather than complete systems.
5. Formal specification is not compatible with agile methods of development.
Nevertheless, at the time of writing, formal methods have been used in the devel- opment of a number of safety- and security-critical applications. They may also be
used cost effectively in the development and validation of critical parts of a larger, more complex software system Badeau and Amelot, 2005; Hall, 1996; Hall and
Chapman, 2002; Miller et al., 2005; Wordworth, 1996. They are the basis of tools used in static verification such as the driver verification system used by Microsoft
Ball et al., 2004; Ball et al., 2006 and the SPARKAda language Barnes, 2003 for critical systems engineering.
K E Y P O I N T S
■ Risk analysis is an important activity in the specification of security and dependability
requirements. It involves identifying risks that can result in accidents or incidents. System requirements are then generated to ensure that these risks do not occur and, if they do, that
they do not lead to an incident or accident.
■ A hazard-driven approach may be used to understand the safety requirements for a system. You
identify potential hazards and decompose these using methods such as fault tree analysis to discover their root causes. You then specify requirements to avoid or recover from these problems.
■ Reliability requirements can be defined quantitatively in the system requirements specification.
Reliability metrics include probability of failure on demand POFOD, rate of occurrence of failure ROCOF, and availability AVAIL.
Chapter 12
■
Exercises 337
■ It is important not to overspecify the required system reliability as this leads to unnecessary
additional costs in the development and validation processes. ■
Security requirements are more difficult to identify than safety requirements because a system attacker can use knowledge of system vulnerabilities to plan a system attack, and can learn
about vulnerabilities from unsuccessful attacks.
■ To specify security requirements, you should identify the assets that are to be protected and
define how security techniques and technology should be used to protect these assets. ■
Formal methods of software development rely on a system specification that is expressed as a mathematical model. Developing a formal specification has the key benefit of stimulating a
detailed examination and analysis of the system requirements.
F U R T H E R R E A D I N G
Safeware: System Safety and Computers. This is a thorough discussion of all aspects of safety- critical systems. It is particularly strong in its description of hazard analysis and the derivation of
requirements from this. N. Leveson, Addison-Wesley, 1995.
‘Security Use Cases.’ A good article, available on the Web, that focuses on how use cases can be used in security specification. The author also has a number of good articles on security
specification that are referenced in this article. D. G. Firesmith, Journal of Object Technology, 2 3, May–June 2003. http:www.jot.fmissuesissue_2003_05column6.
‘Ten Commandments of Formal Methods . . .Ten Years Later.’ This is a set of guidelines for the use of formal methods that was first proposed in 1996 and which are revisited in this paper. It is a good
summary of the practical issues around the use of formal methods. J. P. Bowen and M. G. Hinchey, IEEE Computer, 39 1, January 2006. http:dx.doi.org10.1109MC.2006.35.
‘Security Requirements for the Rest of Us: A Survey.’ A good starting point for reading about security requirements specification. The authors focus on lightweight rather than formal approaches. I. A.
Tøndel, M. G. Jaatun, and P. H. Meland, IEEE Software, 25 1, JanuaryFebruary 2008. http:dx.doi.org10.1109MS.2008.19.
E X E R C I S E S
12.1.
Explain why the boundaries in the risk triangle shown in Figure 12.12 are liable to change with time and changing social attitudes.
12.2.
Explain why the risk-based approach is interpreted in different ways when specifying safety and security.
338 Chapter 12
■
Dependability and security specification
12.3.
In the insulin pump system, the user has to change the needle and insulin supply at regular intervals and may also change the maximum single dose and the maximum daily dose that
may be administered. Suggest three user errors that might occur and propose safety requirements that would avoid these errors resulting in an accident.
12.4.
A safety-critical software system for treating cancer patients has two principal components: ■
A radiation therapy machine that delivers controlled doses of radiation to tumor sites. This machine is controlled by an embedded software system.
■ A treatment database that includes details of the treatment given to each patient.
Treatment requirements are entered in this database and are automatically downloaded to the radiation therapy machine.
Identify three hazards that may arise in this system. For each hazard, suggest a defensive requirement that will reduce the probability that these hazards will result in an accident.
Explain why your suggested defense is likely to reduce the risk associated with the hazard.
12.5.
Suggest appropriate reliability metrics for the classes of software systems below. Give reasons for your choice of metric. Predict the usage of these systems and suggest appropriate
values for the reliability metrics.
■
a system that monitors patients in a hospital intensive care unit
■
a word processor
■
an automated vending machine control system
■
a system to control braking in a car
■
a system to control a refrigeration unit
■
a management report generator
12.6.
A train protection system automatically applies the brakes of a train if the speed limit for a segment of track is exceeded, or if the train enters a track segment that is currently signaled
with a red light i.e., the segment should not be entered. Giving reasons for your answer, choose a reliability metric that might be used to specify the required reliability for such
a system.
12.7.
There are two essential safety requirements for the train protection system: ■
The train shall not enter a segment of track that is signaled with a red light.
■
The train shall not exceed the specified speed limit for a section of track.
Assuming that the signal status and the speed limit for the track segment are transmitted to onboard software on the train before it enters the track segment, propose five possible
functional system requirements for the onboard software that may be generated from the system safety requirements.
338 Chapter 12
■
Dependability and security specification
Chapter 12
■
References 339