In chapter 2, based on the survey of relevant literature, a number of problems were identified
which the thesis should address. In this section the approach developed in this thesis is evaluated
against each of these problem statements.
Problem Statement 1 Ensuring the safety of an OO software system requires that the con-
tribution of the software to system level hazards be identified and mitigated.
This thesis has developed a hazard-driven approach which identifies hazardous failure modes for
the software system. The thesis has shown how the ways in which the software might fail, and
lead to these failure modes, can be identified, and how such failures may be prevented through
the use of safety contracts.
Problem Statement 2 There exist a number of techniques for analysing OO software designs,
however, there is a lack of a coherent process.
This thesis has presented a process developed based on a number of analysis requirements
which are necessary to meet one overall aim, that of identifying behaviour of the software that
may contribute to a system hazard. The techniques used are identified based on their ability
to generate particular desired results as part of achieving this aim. In this way this thesis
demonstrates how the techniques may be used in combination in order to ensure the safety of
the developed system.
Problem Statement 3 As part of any such process, it is necessary that safety requirements
may be generated in a way that supports the OO paradigm.
It would be possible to specify the DSRs arising from the analysis in any number of ways.
they provide excellent support for key features of OO systems such as inheritance. The analysis
process described in this thesis has been specifically developed to facilitate the representation
of DSRs in the form of safety contracts between objects.
Problem Statement 4 There exists little guidance on how a defensible safety argument may
be produced for an OO system based on the use of a combination of techniques.
This thesis has demonstrated how it is possible to structure a defensible safety argument for
an OO software system. This does not mean that the method proposed in this thesis provides
a proof of the safety of the resulting system, nor was it the intention of this thesis to do so.
As with existing approaches to software safety, this method proposes an argument structure to
be developed which argues only the acceptability of the software. Acceptability is a judgement
which is made based upon the rigour of the evidence provided about the safety of the system,
and the level of risk associated with the system hazards. The safety argument patterns which
have been developed identify how the evidence generated throughout the process described in
the thesis can be used to support the safety argument claims.
Problem Statement 5 It is essential that safety process can be successfully integrated with
existing development processes.
In chapter 2, it was identified as being crucial to the success of a safety process that it is
integrated with the development process, rather than being seen as a separate activity. In
order to achieve this, the process must be able to be integrated with the existing development
processes used for the software. The approach developed in this thesis has achieved this aim in
two ways.
Firstly, through focusing the analysis on design artifacts, rather than on particular steps in the
design process. This enables the safety process to fit within an existing development process
rather than imposing any particular process. Secondly, the approach is not specifically depen-
dent upon any particular design methodology. Although the example design artifacts used in
the thesis are generally in UML (being by far the most common notation), the use of UML is
not required, and the same approach is applicable whatever notation is used.
7.6
Conclusions
The thesis proposition stated that it was possible through the use of safety contracts to establish
their contribution to system-level hazards. In this chapter the extent to which this thesis
addresses the proposition has been evaluated. Firstly, the approach was shown to satisfy the
criteria for an effective process which were set out in the thesis proposition. It was also shown
how the thesis addressed the problem statements identified from the literature survey. This
suggests that the approach developed in this thesis is an effective one, however it is only through
the extended practical application of the approach to real projects that a full evaluation of the
Conclusions
8.1
Concluding Remarks
This thesis has developed a systematic, thorough and scalable process to identify the properties
required of software objects to adequately address their contribution to system-level hazards.
Specifically, the contribution of the work presented in this thesis lies in the following three areas:
• Definition of a coherent hazard-driven process for the rigorous analysis of OO software designs.
• Use of the safety contract concept to elicit safety requirements in a manner which supports OO features.
• Development of safety argument patterns for making defensible claims about the safety of the resulting software system.
In the remaining sections, some conclusions are drawn from each of these areas of research, and
finally in section 8.2 some areas worthy of further work are proposed.
8.1.1
Conclusions on the analysis process contribution
The key contribution made by the safety analysis process described in chapter 3 is to provide a
structured approach to the analysis of OO software designs. The process largely makes use of
existing analysis techniques, however crucially provides a framework in which each technique
makes a specific and clear contribution to the overall objectives of the process. As well as
derivation of safety requirements in safety contract form. Through focussing on interactions
between objects, the analysis process facilitates the development of safety contracts.
The analysis process has been argued to be systematic, thorough and scalable in chapter 7,
and its applicability to an industrially sized design has been demonstrated in the case study
presented in chapter 6.
8.1.2
Conclusions on the use of safety contracts
The use of safety contracts provides an important contribution in a number of ways. Firstly the
use of contracts has been shown to help support maintainability, inheritance and reuse within
OO designs. The use of safety contracts therefore helps to ensure that the safety activities do
not overly detract from the potential benefits of using an OO approach.
Just as importantly, however, safety contracts provide a link between the analysis process and
the safety argument. The safety argument structure proposed in chapter 5 is structured in a
modular fashion, with separate modules of argument for the interactions which occur between
classes, and each of the classes themselves. This structure brings many advantages, which were
discussed in detail in chapter 5. It is the use of safety contracts which allow such a modular
argument structure to be used, by enabling the claims to be modularised in this manner.
Through developing the safety contracts, the analysis process therefore identifies the evidence
which is required by the safety argument.
It has been shown how the properties required for safety contracts can be represented using
OCL notation, which provides a formal and side-effect free expression language. Using OCL
the safety contracts can be integrated as part of the design, facilitating their implementation.
8.1.3
Conclusions on the safety argument patterns
The contribution provided by the development of the safety argument patterns is that they show
explicitly how a defensible argument for an OO software system may be structured. No such
guidance exists elsewhere. The case study in chapter 6 illustrated how a safety argument can
be constructed through appealing to specific evidence generated through following the process
described in this thesis.
As discussed previously, the modular structure of the argument has been chosen such that it
may minimise the effect of changes to the design, and maximises the amount of argument that