A Framework for Analysis

As discussed in chapter 2, one of the principal aims of PSSA of software is deriving a set of

software safety requirements which are sufficient to ensure that the behaviour of the software

will not contribute to the identified system hazards, and thus ensure that the system is safe.

The approach can be summarised as shown in figure 3.1.

Missile fired at friendly target Target located incorrectly Inadvertent launch Etc….

Missile

Targeting

Hazard

Software Component

Functional Failure

System

Figure 3.1: Deriving safety requirements for a software system

The safety process starts at the level of the system. The hazards associated with the system

under consideration are identified. Through performing the hazard analysis, it is hoped to

understand how these hazards may be brought about, so that they may be prevented from

occurring or otherwise controlled. The next stage of analysis is therefore to identify the failures

which may occur at the sub-system level to contribute to the hazards of interest. Chapter 2

discusses the techniques available to perform such analysis. These higher level PSSA techniques

(such as FTA) are applicable to any software system, including one developed using OO.

specify derived safety requirements for the software which prevent those failures occurring or

detect and mitigate them. It is at this point in the analysis that the existing techniques become

more difficult to apply to an OO system. With a traditional (i.e. functionally decomposed)

software system the functions will be allocated such that there will generally be many black

box sub-systems responsible for different functions. The safety requirements can be assigned to

the relevant sub-system and the software implemented to meet these requirements.

For example in figure 3.1, the functional failure of interest is ‘Target located incorrectly’. Due

to the functional decomposition of the software components in the system, it is fairly easy to

identify which part of the system may contribute to that failure (i.e. there will be part of the

system which has responsibility for that function). So safety requirements could be derived for

the missile targeting component.

If we now consider an OO system, as was discussed in chapter 2, we know that in such systems

the software is not directly decomposed according to the system functions, but into a set of

objects. There will not be a ‘missile firing’ object. The missile firing function is realised by

a number of collaborating objects passing messages between themselves. In this case how can

the safety requirement be assigned? No one object has responsibility for a particular function.

As illustrated in figure 3.2, there is no longer a direct relationship between a functional failure,

and one particular part of the software system. In addition, objects may be involved in many

different system functions as part of separate object collaborations. In addition, the basic unit

of any OO system is not the function but the object. To support the use of an OO approach,

and facilitate reuse, it is desirable that safety requirements can be derived for objects. The

safety requirements obviously need to be broken down further in some way. This raises the

question of how this may be achieved.

In order to answer this question it will be necessary to better understand the way in which

faulty behaviours, and therefore hazards, manifest themselves in an OO system. Firstly, the

way in which functionality is realised in an OO system is examined in more detail.

It was previously mentioned that functionality is achieved in an OO system due to a collab-

oration between interacting objects. The way in which this occurs is illustrated in figure 3.3.

This shows four different objects, O1 to O4, with a sequence of interactions occurring between

them, i1 to i3. Within this thesis, an interaction is defined as any communication which occurs

between objects in order to perform a function. Each of the objects can be considered to have

a set of states associated with it. The object can therefore be represented using the statechart

Target located incorrectly

Missile

Targeting

Figure 3.2: Identifying software contributions for functional (left) and OO (right) systems

can trigger that other object to change its state. For example in figure 3.3, the transition of

object O2 from state A to state B is of the form: i1[c]/i2. So if O2 is in its initial state A, then

the interaction, i1, sent from object O1, will cause the transition to state B if condition c is

met. As well as changing the state of O2, this transition will also result in the event i2, which is

an interaction with object O3. In the example in figure 3.3 this can cause a further transition

to occur in O3, and so on. It is through such interaction sequences that an OO system realises

its required functionality.

O1 O2 O3 O4 i1 i2 i3 A C B D E O2 O3 i1 i2 i1 [c] / i2 i2 [c] / i3 i3

Figure 3.3: Sequence of interactions occurring in an OO system

It is the interactions between the objects which are crucial to the safety of OO software. These

interactions must be constrained such that the software’s behaviour will not contribute to haz-

ards. The survey in chapter 2 identified that contracts provide an excellent way of constraining

this purpose. The analysis carried out on the OO design at the PSSA stage must provide the

necessary information for forming safety requirements in the form of contracts. This chapter

explores an analysis approach for gaining such information.