LA CAJA Y EL PINCULLO

tracts

As discussed in chapter 2, encapsulation is a feature of OO systems that provides a great

potential for reusing elements of one system in another similar system. If software classes

providing the required functionality already exist, then encapsulation ensures that including

them in a new system is relatively straight forward. The advantages of this are that the part

of the system being reused does not need to be developed from scratch, considerably saving

on effort and hence cost. However, as was discussed for design changes previously, in safety

critical applications it must be ensured that reused design elements will not affect the safety of

the system. It is desirable that assuring safety can be achieved in a way which will minimise

the effort required. Once again, safety contracts can be used to facilitate this. The part of

the design which is to be reused must behave safely as part of the system in which it is to

be used. This means that the reused element’s behaviour must not contribute to any HSFMs.

Since safety contracts are in place within the system design, the safety obligations relevant to

the elements to be reused can be clearly identified. When reusing classes in the new system it

is therefore not sufficient that they provide the functionality required, it is also necessary that

they meet the safety obligations identified from the contracts. If the elements to be reused can

fulfill these obligations then then they can be safely used as part of the system. It is important

to note that the safety obligations are specific to the the system for which they were derived.

This means that the safety obligations of a reused element from another system cannot be

simply carried across into the new system. Instead it is necessary always to demonstrate that

the reused element meets the safety obligations imposed upon it by the system in which it is to

be used. Where the reused element is from a very similar system, which placed similar safety

obligations on that element, it would be relatively easy to demonstrate compliance with the

safety obligations in the new system, however it is necessary that this is done explicitly.

is possible to know if an existing element is safe to use in that system. If this were not possible

then the system would need to be reanalysed as a result of the change, and thus the benefits of

reuse would not be realised.

4.5

Conclusions

In this chapter, the concept of safety contracts was introduced as an ideal way to represent

DSRs as part of an OO design. It has been shown how such safety contracts can be constructed

based on the analysis that was described in chapter 3. It has also been shown how OCL provides

an implementation independent notation for specifying contracts, and has the expressive power

necessary for representing the constraints required in a safety contract. These safety contracts

can be then be used to identify the safety obligations relating to objects in the system. It

has been shown how the specification of safety contracts makes it easier to deal with changes

to an OO design, and the reuse of design elements, whilst ensuring that the system under

consideration remains safe. In this way a safety contract approach supports maintainability

and reuse, key benefits of adopting an OO approach, for safety critical OO systems.

By showing that the safety obligations arising from safety contracts have been met, evidence as

to the safety of the system is generated. This evidence can be used in demonstrating that the

OO system is safe to operate. In order to demonstrate this clearly, it is necessary to produce

a safety argument for the system. In the next chapter, the way in which a safety argument

can be generated, to demonstrate that an OO system, developed using the approach described

in chapters 3 and 4, is safe to operate, is investigated. It shall be seen how the development

of safety contracts assists in establishing an effective safety argument structure. Producing a

successful safety argument is a key aspect of certifying an OO system such that it may be used

Creating a Safety Argument for

OO Systems

5.1

Introduction

In chapter 2 it was seen that in order to certify a safety related system it is necessary to

produce a safety case for that system. A key part of this is providing a clear and defensible

safety argument that the system is acceptably safe to operate within a particular context. For

the approach described in this thesis to be used successfully in safety related systems, it is

necessary that a robust safety argument can be produced, which shows how the process ensures

the resulting software system is safe. Chapter 3 described a process for analysing OO systems

for safety, then in chapter 4 the output of the analysis was used to define safety requirements

in the form of safety contracts on the system design. Once these requirements for the system

have been defined, the system is verified against these requirements to generate evidence that

the requirements have been met. This evidence will form part of the safety argument. In this

chapter an appropriate structure for such an argument is developed. The structure should

provide the flexibility required to support change and reuse of the system. If the argument

structure does not provide this flexibility then the certification effort could easily negate the

advantages gained elsewhere in the process. Safety case patterns are developed which can be