A Brain Tumor Treatment System

Published Date: 02 Nov 2017

The Structured Object-Oriented Formal Language

(SOFL) three-step approach to the construction of

formal specifications for software systems has been

developed and applied in information systems over

the last nineteen years [1][2]. Compared to wellknown

formal methods, such as VDM [3], B method

[4] and Larch [5], SOFL has many distinct advantages,

mainly because it offers effective ways to integrate

formal methods into the entire process of software

engineering, which allows practitioners to easily

apply formal methods in real software projects. In

particular, the SOFL three-step specification

approach is one of the many important features of the

SOFL method. It emphasizes the fact that

constructing a formal specification for design of a

system significantly contributes to the quality

assurance of the system and the importance of a

progressive process for achieving it. According to the

progressive process, the formal design specification can

be achieved in three steps [1]. The first is to build an

informal specification, documenting the major

functions, necessary data resources, and constraints

(e.g., safety, security, policy). The second is to

transform the informal specification to a semi-formal

specification which is more precise than the informal

one and organized in a modular fashion. The third

step is to build a completely formal specification for

design on the basis of the semi-formal specification by

first defining the architecture of the system and then

defining all the components involved in the

architecture using a mathematically-based notation.

While there is sufficient evidence, resulting from

many applications, to suggest that the SOFL threestep

specification approach be effective in ensuring

software quality and reducing development cost for

information systems, it has not been sufficiently

demonstrated that SOFL is also suitable for the

development of safety-critical systems. In this

paper, we present a case study applying SOFL

three-step approach to formally specify the brain

tumor treatment system [6]. Particularly, we

concentrate on the description of how to write the

informal specification, how to transform it into the

semi-formal specification, and finally how to form the

formal design specification based on the semi-formal

one. The case study demonstrates the suitability of

SOFL for safety-critical system development and

provides us with an insight into the knowledge of how

the SOFL three-step specification approach can be

effectively supported.

The remainder of the paper is organized as follows.

Section 2 describes the background of a brain tumor

treatment system. Section 3 gives a brief introduction

to the SOFL three-step specification approach which

we used in the case study. A brief overview of

related work is given in Section 4. Section 5

discusses how the SOFL approach is applied in

writing the specifications for the brain tumor treatment

system. Section 6 describes * The author is currently doing his doctorate study at the Department of our experience and

Computer & Information Science, Hosei University, Koganei Campus, Tokyo,

Japan and can be contacted via email: [email protected]

ISBN: 978-0-9853483-3-5 �2013 SDIWC 196

lessons learned from this project. Finally, in Section 7

we conclude the paper and provide several suggestions

for future research.

2 BACKGROUND OF BRAIN TUMOR

TREATMENT SYSTEM

Brain tumor [6][7][8] is a mass of unnecessary cells

growing in the brain, and usually is described either

benign or malignant. Benign brain tumors do not

contain cancer cells, which can usually be removed,

and seldom grow back. It edges can be clearly seen

and it does not invade tissues surrounding them or

spread to other parts of the body. However, this kind

of tumors can press on sensitive areas of the brain

and cause serious health problems. It rarely becomes

malignant. The malignant brain tumors contain

cancer cells, generally more serious and often life

threatening to human life. These kinds of tumors are

likely to grow rapidly and invade the surrounding

healthy brain tissue. It is very rare that malignant

brain tumor spreads to other parts of the brain, or to

other part of body. Tumors that begin in brain

tissues are called primary tumors while secondary

tumors are identified when cancer spreads out from

its original location to another part of the body. We

restricted our research by focusing on primary

tumors.

To build a formal specification for such of brain

tumor treatment system to analyze its functional

behaviors and safety properties early, we first need

to explain the mechanism of the system used in our

case study.

2.1 System Mechanism

The Brain Tumor Treatment System contains three

distinct types of objects: TumorPatient, BrainTumor,

and Recommendation. TumorPatient, which was

identified to have a BrainTumor after having

consultation with a doctor, is needed to take more

processes for identification of type, location, size and

grade of tumor. The identification of BrainTumor

might be either benign or malignant, either the

tumor's location is primary or secondary tumor, the

size of the tumor inside the TumorPatient and the

grade of tumor which is assigned as from grade I

(low grade) to grade IV (high grade). This

identification leads the system to recommend what

kind of treatment is best for the TumorPatient.

In Brain Tumor Treatment Recommendation

system, the identification of treatment depends on a

number of factors, such as the type, location, size and

grade of the tumor. The collection of these factors

would assist the doctor to decide and recommend the

appropriate treatment to the TumorPatient. In our

specification, we divided the treatment into two:

basic treatment and advanced treatment [6]. The

option for basic treatment includes surgery, radiation

therapy, chemotherapy or a combination. While,

gamma knife method and gene therapy are example

methods in advanced treatment.

2.2 System Functions

At initial stage, TumorPatient will be diagnosed with

basic diagnosis such as age, sex, race, work

environment, family history, current health problems

and needs to take several questionnaires for

identification if the brain tumor exists or not. When

there is a sign that the tumor might exist, the

TumorPatient is required to go thru the next stage: an

advanced diagnosis for identification of the type, size

and location of the tumor. The doctor might perform

several procedures (i.e. neurologic exam, CT scan,

angiogram, and biopsy) to help them on this

identification. Later on, the next stage is to identify

the grade of tumor, called brain tumor identification

process. This process will require the doctor to

properly diagnose the characteristic of the tumor and

give their opinion to the TumorPatient based on the

list of recommendation at the final stage of

treatment.

3 OVERVIEW OF SOFL APPROACH

SOFL is a formal engineering method that offers

a systematic way to develop software systems using an

intuitive but formal notation. The notation results

from an effective integration of VDM-SL [9], Petri

Nets [10], and Data Flow Diagrams [11]. It provides a

hierarchical condition data flow diagram (CDFD) as a

mechanism for defining system architecture while

allowing formal specifications for processes involved

in the CDFD to be expressed using pre- and postconditions

in modules. Each level of a CDFD

hierarchy is associated with a specification module in

which all components of the CDFD, including

processes, data flows, and data stores, are formally

defined. The diagram remains at a high level of

abstraction, describing interactions between processes

in terms of data flows and data stores, while the module

specification concentrates on the details of the

components. To facilitate the process of achieving

ISBN: 978-0-9853483-3-5 �2013 SDIWC 197

such a formal specification, SOFL offers a three-step

specification approach, which consists of informal

specification, semi-formal specification, and formal

specification. Each stage of the specification has its

own objective and task. In the informal specification,

the objective is to enable the developer to fully

understand and cover all the desired requirements of

the domain problem through communication with the

client. Constructing the semi-formal specification

allows the developer to clarify the ambiguities in the

informal specification and to better understand the

relationships among the functions and data resources,

as well as the constraints. The formal specification,

however, forces the developer to clarify ambiguities in

functionality, and serves as a platform for system

implementation and verification. For verification and

validation, SOFL adopts rigorous inspection [12] and

testing [13].

An important feature of the SOFL three-step

specification approach (as shown in Fig. 1) is that it

defines the specific tasks for each stage of

specification. In the first step, an informal specification

is written, aiming to reflect the result of an informal

requirements analysis on the basis of domain

knowledge and available materials. Such a

specification consists of three parts: (1) functional

description which describes the high-level operations

needed for the system, (2) data resources which

indicate data items necessary for fulfilling the

functions given in (1), and (3) constraints on both

operations and data resources. At this stage, the

descriptions of the operations, data resources, and

constraints are written in a natural language. The

second step is to transform the entire informal

specification into a semi-formal specification. At this

level, all functions, data resources, and constraints

are transformed into appropriate expressions in the

SOFL specification language, except that all logical

expressions, such as type invariants and pre-post

expressions for processes, are still kept informal.

Finally, the third step is to transform the semiformal

specification into a formal specification. In this

step, the system architecture is designed and expressed

using CDFDs, and all the informal expressions of type

invariants and process specifications in the semi-formal

specification are formalized properly.

4 RELATED WORK

In this section, we compare our work with other

approaches to system development such as iterative

models [14] and mural system [15]. An iterative

model consists of four phases in sequence:

requirement, de-sign, implementation and testing, and

final integration and system testing. This model is

also referred to as incremental prototyping, because

each phase consists of repeating the above four phases

in sequence many times to produce a new version of

the software. The development begins by specifying

and implementing just part of the software, which

can then be reviewed in order to identify further

requirements. The requirements of the software are

gathered and analyzed during the requirement phase.

After several iterations, a complete and final

specification of requirements is produced. The

software solution in which it meets the requirements

is designed in the design phase. Again, because of the

iteration process, it might be a new design, or an

extension of an earlier design. Later, the software is

coded, integrated, and tested in the implementation

and testing phase. Before the software is released, it

will go through the final integration and system

testing phase. This is similar to the SOFL threestep

approach in which the development of the

specification is an evolutionary process. However, an

issue arises in the iterative model (but not in SOFL)

in that a decision has to be made regarding how long

the iteration should continue. In addition, there is no

detailed description of the design decision for a flow

diagram of the system. In SOFL, on the other hand,

the CDFD, with distinct input and output ports,

makes the diagram easier to understand.

In the case of mural system, the development of a

formal specification has three steps: (1) creating the

data types and the invariants, (2) creating the

specifications by creating the operations and functions,

and (3) translating to theory and generating proof

obligations. This is contrasts with SOFL, which

emphasizes the importance of communication

between the client and developer in capturing

accurate requirements during the first step of

developing the specification.

Figure 1. SOFL three-step specification approach

ISBN: 978-0-9853483-3-5 �2013 SDIWC 198

5 CASE STUDY

In this section, we discuss how the SOFL three-step

specification approach is applied to the modeling of

the brain tumor treatment system introduced in

Section 2.

5.1 Informal Specification

The process for developing an informal specification

requires continuous communication and interaction

between the client and the software developer for

better understanding of the domain and requirement

analysis.

As a result we completed the informal

specification, as shown in Fig. 2. There are five

major functions in which function 1.5 (Operation on

Treatment) is decomposed into lower-level

functions: 1.5.1 (Operation on Basic_Treatment) and

1.5.2 (Operation on Advanced_Treatment). In the

data resources part, there are six data items and each

data item is connected to the specific potential

required function. For example, data item 2.1

(patient's data) is required in function 1.1

(Register_Potential_Patient). In the constraints part,

there are two constraints that described the constraint

for data resource 2.1 (patient's data) and the

constraint of function 1.4 (Brain_Tumor_Treatment).

5.2 Semi-formal Specification

Developing a semi-formal specification is aimed at

achieving accuracy of the requirements. To achieve

this goal, three activities are involved.

� Group function, data resources and

constraints

The Register_Potential_Patient function is

analyzed if it requires decomposition or has a

relationship with data resources and in what

kind of constraint. Since

Register_Potential_Patient is a function, then

it is transformed into a process called process

Register_Potential_Patient (as shown in Fig.

3), and requires input variables, state

variables, state changes and output variables

need to be defined by the user. This pattern

would then be a basis for the next activity of

declaring necessary data types.

� Declare data type

During this activity, the user is required to

declare the variables for process

Register_Potential_Patient. We can apply a

bottom-up approach to data declaration, in

which the user writes the input variable

patient, type Patient, and external variable

patients_data with type TumorPatient, before

declaring them in the type section. As shown

in Fig. 4, we define TumorPatient as a set of

Patient. Patient is a composite type and each

of it has a value of seven fields: the

information about patient's name, his identity

number, race, sex, age, his/her work

environment, and the family history if the

tumor problem exists in his family. The

information of TumorPatient is kept in data

store called, patients_data.

� Define all pre- and post-conditions

In this stage, the user is required to describe

the pre and post-conditions for process

Register_Potential_Patient. Based on the

SOFL approach, during the semi-formal

specification construction, the pre- and postcondition

of a processes can be expressed in

natural language. As shown in Fig. 5, with the

pre-condition being true, the process of

Register_Potential_Patient will update the

1. The required functions:

1.1. Register_Potential_Patient

1.2. Basic_Diagnose

1.3. Advanced_Diagnose

1.4. Brain_Tumor_Identification

1.5. Operation_on_Treatment

1.5.1. Operation_on_Basic_Treatment

1.5.2. Operation_on_Advanced_Treatment

2. Data resources:

2.1. Patient�s data (1.1)

2.2. Patient�s current health situation (1.2)

2.3. Current symptoms (1.3)

2.4. Available physical procedure data (1.3)

2.5. Doctor�s second opinion (1.4)

2.6. List of treatment technology (1.5.1,

1.5.2)

3. The constraints:

3.1. Patient�s data only covers his/her

patient_id, race, sex, age, work

environment and family history (2.1)

3.2. The identification of brain tumor only

covers the primary brain tumors (1.4)

Figure 2. Sample of a complete informal specification

process Register_Potential_Patient(input_Var)

output_Var

ext ExternalVariables

pre PreCondition

post PostCondition

comment InformalExplanation

end_process;

Figure 2. Pattern for a process of

Register_Potential_Patient

ISBN: 978-0-9853483-3-5 �2013 SDIWC 199

data store of patients_data. In conjunction to

that, before the process of

Register_Potential_Patient description is

ended, the user is reminded to explain what

the purpose of this process is all about. The

sample of the pre- and post-condition for

process Register_Potential_Patient in the

semi-formal specification is shown in Fig. 5.

In this stage, a CDFD is constructed to

provide guidelines for formalizing the

components of the system. At the same time,

the CDFD describes the behavior of the

modules in a hierarchical manner. Fig. 6

shows the CDFD module level two of the

brain tumor treatment system. In this diagram,

a potential patient, who has registered and

showing a symptom of having a brain tumor

will undergo for a diagnosis step. In this step,

the detection of the brain tumor is based on a

size and location of the brain tumor. The

recommendation of the treatment will be

decided based on the detection and grade of

the brain tumor. Several criteria are used for

the grading including abnormality and

invasion of the brain tumor.

5.3 Formal Specification

Once an appropriate CDFD has been created for the

design of the system, it may contain new components

in addition to the existing components of the CDFDs

in the semi-formal specification. The goal of writing a

formal design specification is to make the informal

expressions in the semi-formal specification precise

and to define the meaning of the new components.

Specifically speaking, all necessary constant identifiers,

types, variables, and invariants in a module must be

formally define, and all processes involved in the

corresponding CDFD must be defined using pre- and

post-conditions. Such a formal specification is

expected to serve as a firm foundation for system

validation and implementation.

In the case of our system, we formally specified

the module called Grading, as shown in Fig. 7. In

this module, a process Assign_Grading needs one

module Primary_Brain_Tumor_Treatment_System;

type

Patient = composed of

name: string

id: int

race: string

sex: PatientSex

age: int

work_env: string

family_history: string

end;

PatientSex = {<MALE>, <FEMALE>};

TumorPatient = set of Patient;

PatientLeft = TumorPatient;

HealthSituation = composed of

customer_name: string

situation_name: string

location: string

prescription: string

duration: int

end;

Questionnaire = composed of

question_no: int

question: string

weightage: real

end;

var

ext #patients_data: TumorPatients;

ext #questionaire_list: Questionnaire;

process Register_Potential_Patient(patient: Patient)

ext wr patients_data: TumorPatient

pre true

post adds the input patient to the store patients_data, if

it is does not exist in

the patients_data.

end_process;

process Basic_Diagnose(current_health_situation:

HealthSituation)

no_tumor: string

ext rd patients_data: TumorPatient

ext rd questionnaire_list: Questionnaire

ext wr patients_data: TumorPatient

total_weightage : real

pre patient is exist in patients_data

post if total_weightage is below than 0.2 from

questionnaire_list then display

result that no brain tumor is detected and update

patients_data.

end_process;

process Operation_on_Treatment()

end_process;

end_module;

Figure 4. Sample pre-and post-conditions in the

process

module Primary_Brain_Tumor_Treatment_System;

type

Patient = composed of

name: string

id: int

race: string

sex: PatientSex

age: int

work_env: string

family_history: string

end;

TumorPatient = set of Patient;

PatientLeft = TumorPatient;

var

ext #patients_data: TumorPatients;

process Register_Potential_Patient(patient: Patient)

ext wr patients_data: TumorPatient

pre true

post adds the input patient to the store patients_data, if

it is does not exist in the patients_data.

end_process;

Figure 3. Sample for declaring data type to process

Register_Potential_Patient

ISBN: 978-0-9853483-3-5 �2013 SDIWC 200

input parameter and produces one output. Within this

process, we applied condition-based SOFL

specification to assign a grade for the brain tumor.

For example, the grade is one if the mitotic_index

(related to growth of the brain tumor) is <Slow>,

atypia (referring to the appearance of the tumor) is

<Almost Normal>, has the least invasion, and does

not have a dead tumor.

6 DISCUSSION

With regard to the practical application of the threestep

approach in SOFL, we found that the process of

writing a formal specification was easier than using

pure formal methods, such as VDM and Z [16]. This

was because both the informal and semi-formal

specifications clearly present the targets for

formalization whose process is again guided by the

intuitive graphical CDFDs. Furthermore, the SOFL

method, like all other formal methods, is suitable for

designing safety-critical systems. Our experience in

this case study shows that many important aspects,

such as the type, location, size and grade of tumor

are required to be thoroughly analyzed, defined, and

understood. Compared to natural language, the

SOFL formal notation has the power to �force� the

developer to examine and express every object

precisely. Such a formal specification allows the

developer to analyze, at a detailed level, important

properties (e.g., safety, efficiency) of the system and

to predicate the potential behaviors of the systems.

Without it, the analysis and predication would be

difficult to perform accurately and efficiently.

On the other hand, we have also found some

deficiency in the SOFL tool technology. Currently,

there is a prototype tool, known as SOFL GUI

Editor, to support the process of formal specification

construction in SOFL, but it does not support the

entire three-step specification process. In our case

study, we used Microsoft Word Editor for writing

informal specifications and SOFL GUI Editor for

writing semi-formal and formal specifications. This

proved to be feasible, but difficulties in specification

modification, verification, and validation have been

encountered. We believe that the SOFL method has

set up a solid foundation for developing an effective

tool support for the three-step specification approach,

and plan the development of the tool as our major

task in our future work.

7 CONCLUSION AND FUTURE WORK

This case study demonstrates how SOFL can be

used as a formal engineering method for writing a

formal specification in a safety-critical system

application. The process of writing the formal

specification involves a three-step approach, consisting

of informal, semiformal, and finally formal

specification. We have found, based on our experience

in the case study, that the use of SOFL is

straightforward, easy to follow, and understandable,

but when the scale increases, it will require more time

Figure 5. CDFD module level two of the brain tumor

treatment system

Diagnose

Treatment

criterias Grading

possible_tumors

symptoms

Register_Potential

_Patient

location

size tumor_detected

grade

recommendation

module Grading_Decom/SYSTEM_BTTS;

behav CDFD_6

process Assign_Grade(criterias: Grade) grade:int

post ((if criteria.mitotic_index = <Slow> and

criteria.atypia = <Almost Normal> and

criteria.invasion = <Least> and

criteria.dead_tumor = None and

criteria.blood_supply = 0

then grade = 1) or

(if criteria.mitotic_index = <Relatively_Slow> and

criteria.atypia = <Slightly Abnormal> and

criteria.invasion = <invade> and

criteria.dead_tumor = None and

criteria.blood_supply = 0

then grade = 2) or

(if criteria.mitotic_index = <Actively Reproduce Abnormal

Cell> and

criteria.atypia = <Very Abnormal> and

criteria.invasion = <infiltrate> and

criteria.dead_tumor = None and

criteria.blood_supply = 0

then grade = 3) or

(if criteria.mitotic_index = <Abnormal Cells Rapidly

Reproduced> and

criteria.atypia = <Very Abnormal> and

criteria.invasion = <infiltrate> and

criteria.dead_tumor = Exist and

criteria.blood_supply = 1

then grade = 4) or

comment This process will determine the grade of the brain tumor

based on several criterias.

end_process;

end_module;

Figure 6. Example of formal specification for Grading

ISBN: 978-0-9853483-3-5 �2013 SDIWC 201

and efforts in writing a specification. This problem

can be effectively solved by a powerful tool support.

As future work, we will concentrate on the

research and development of a powerful tool support

for SOFL, studying how artificial intelligence

technology can be used to improve the capability of

the tool to ease difficulties in choosing appropriate

mathematical expressions, reduce efforts in organizing

specifications, and shorten the process of constructing

specifications.

ACKNOWLEDGMENT

This work is supported by Universiti Malaysia

Sarawak under FPI Grant ((F08)/83/2012(43)). We

would like to thank Dr Edwin Mit for valuable

discussion regarding this research.