Software Development by Evolution
3
Shaoying Liu Department of Computer Science Faculty of Information Sciences Hiroshima City University, Japan Email:
[email protected]
1 Introduction Software development is a process of creating and changing documents from unexecutable speci cations to executable programs. To achieve an e ective control of the process and reliable documents produced during this process, precise and sensible rules are needed to serve as the guidelines and criteria for producing and verifying the documents. In this paper we propose an evolutionary approach to dealing with this important problem, based on the existing re nement and incremental techniques [1, 2]. It is our belief that software development usually involves three di erent kinds of activities: improving functions, extending functions, and modifying functions. By improving functions we mean that a given operation P can be improved to Q with the preservation of the function of P . The improvement can mean two things. One is to eliminate non-determinism in operation P , and another is to strengthen the capability of P so that Q will be able to o er more functions under the constraint of P . Such an improvement is called re nement by Jones and Morgan. By extension we mean that a given operation P or its function (e.g., a di erent named operation with the same function) will be sustained when it is expanded to another operation Q. For example, such a Q can be like Q Str(P ), where Str(P ) can be any available construct, such as P1 ; P ; P2, if B then P1 ; P else P2 ; P , and while B do P1 ; P ; P2. Such an extension does not deal with the improvement of P itself, instead, it addresses the problem of how to reuse P in the extended operation Q. By modifying functions we mean that a given operation P is modi ed into another operation Q so that Q neither preserves the function of P nor reuses the function of P . Such a modi cation usually re ects a change of original requirements for the function of P . The proposed evolutionary approach is intended to unify those three activities with di erent natures. In other words, we attempt to provide a uni ed rule as a guideline for developing software. We also show how the evolutionary approach can be e ectively taken to control the process of software development.
2 The de nition of evolution Let operations P : DP ! RP
P
and Q have the signatures:
3 This work is supported by the Ministry of Education of Japan under Grant-in-Aid for Scienti c Research on Priority Areas (A) No.10139236)
1
and Q
:
D
Q ! RQ .
where DP and RP denote the domain and range of the operation P , respectively; and DQ and RQ are those for operation Q. P can be a relation or function, and so is Q, depending on their current speci cation. De nition 2.1 Operation Q is an evolution of P i (1) Q is are nement of P , (2) Q is an extension of P , or (3) Q is a modi cation of P . We use P j= Q to denote that Q is an evolution of P , or P is evolved to Q. De nition 2.2 Operation Q is a re nement of P i (1) pre-P ) pre-Q and (2) pre-P ^ post-Q ) post-P We use P v Q to represent that Q is a re nement of P . This de nition shows that operation P is improved to Q by weakening and strengthening its precondition and postcondition, respectively. In other words, Q must possess the function required by P , but can extend to o er additional functions under the functional constraint of P . Figure 1 depicts a re nement. RQ DQ
RP
0 1 1 0 0 1
11 00 0 DP 1 00 11 01 1 00 0011 11 0 00 11 0 1 0 1 00 11 0 1 00 11 00 11 0 1 00 11 0 1 00 11 00 11 00 11 001 11 00 11 0 1 0 00 11 0 1 00 11 0 1 0 1 0 1 0 00 11 01 1 01 1 0 0 1 00 11 0 00 1 11
0 1 00 11 00 11 0 1 00 11 00 11 00 11 0 1 00 11 11 00 0 1 00 11 00 11 0 1 00 11 0 1 0 1 00 11 00 11 0 1 0 1 0 1 0 1 00 11 0 1 01 1 0 1 00 11 0 00 011 1 00 11
Figure 1: Illustration of re nement For example, two operations
OP
and OP1 are given below:
c-process OP(x : nat) y: nat ext rd a : nat pre: x > a post: y > x + a end-process where nat denotes the natural number type (including zero). c-process OP1(x : nat, b: nat1) y, z: nat ext rd a : nat pre: x > a or x > b post: y > x + a and z >= x + b end-process 2
As we have pre-OP ) pre-OP1, and -OP ^ post-OP1 ) post-OP, we can claim that OP1 is an evolution of OP. Note that although there are additional input b and output z in the operation OP1, it still satis es the re nement rule. Compared with the function of OP, OP1 has a weaker precondition and stronger postcondition. De nition 2.3 Operation Q is an extension of P i Q Str(P ).
pre
where Str(P ) is a construct that contains P as its component. P < Q denotes that Q is an extension of P . Note that in theory the operation P in Str(P ) can be replaced by an equivalent operation P1. By equivalent we mean that P and P1 have the same function, but possibly with di erent syntax. However, application of this rule will increase signi cantly the diculty in verifying whether Q is an extension of P in practice. Therefore, this rule can be simpli ed to the level that the syntax of P is sustained in Str(P ) when it is applied in practice. For example, Str(P ) can be one of the constructs: (1) Str(P ) P1 ; P ; P 2, (2) Str(P ) if b then P1 else P , (3) Str(P ) while b do begin P ; P1 end where P1 and P2 are additional operations. De nition 2.4 Operation Q is a modi cation of P i it is neither a re nement nor extension of P . We use P = Q to denote that Q is a modi cation of P . For example, the operation OP given previously is changed to the operation OP2:
c-process OP2(x : nat) y: nat ext rd a : nat pre: x x + 2 * a end-process
As OP2 is neither a re nement nor extension of OP, it is regarded as a modi cation of
OP.
3 Application of evolutionary approach to SOFL SOFL was developed in our project FM-ISEE1 based on the rst author's Ph.D research [3]. It consists of a speci cation language and implementation language [4]. As we did not use the implementation language in the study presented in this paper, we only introduce the SOFL speci cation language in this section. Readers who are interested in the detailed description of SOFL can refer to the rst 1 FM-ISEE,
standing for Formal Methods and Intelligent Software Engineering Environment, was an international joint project funded by the Ministry of Education of Japan in the period of 1996-1997.
3
author's previous publication [4]. When building a SOFL speci cation, development of the CDFD hierarchy usually requires extension and/or modi cation, in addition to decomposition. Decomposition refers to the improvement of a condition process, whereas extension or modi cation refers to changes in the structure or functionality of a condition process or CDFD. A condition process is decomposed by constructing a corresponding lower level CDFD to re ne
the process. Extension or modi cation of a condition process or a CDFD changes its structure or functional de nition to make a new version of the current speci cation.
Decomposition extends a speci cation in a top-down fashion while extension or modi cation
improves it in a horizontal direction, as shown in Figure 2. Increment or modification
X A
B
B
C
C
A
Decomposition
E
E D
D
11 00 0 1 0 00 11 0 1 1 0 1
F
F
G G
I
I Y
11 00 00 11 00 11 00 11 11 00 11 00
Figure 2: Illustration of evolution using the SOFL speci cation language The following approach is an e ective way to use evolution when constructing a speci cation: Decomposition and extension or modi cation are interleaved, but decomposition usually comes
rst and then extension or modi cation steps are made if necessary.
When decomposition of a condition process reveals the need for a change to the condition process
itself, then an extension or modi cation of the condition process and/or the associated CDFDs needs to be carried out. The result of the extension or modi cation is another hierarchy of CDFDs that properly re ects the decomposition relation between high level condition processes and their decomposed CDFDs.
4 Successive evolution approach to software development We believe that software development is a successive evolution process, and our proposed evolution rules can be employed to make this process under control. Speci cally speaking, when changing an operation P , one must rst consider re ning P . If it does not t the purpose (e.g., P needs extension), 4
he must consider extending P . If the original function of P needs to be changed to meet the changed requirements, he must consider modifying P . Each of those three activities must be carried out according to their corresponding rules given previously. For brevity, we call all the documents produced during a software development speci cations, which may include requirements speci cations, designs, and programs. Figure 3 shows the evolutionary process of software development. Specification1 evolution
Specification2 evolution
evolution Specification n
Figure 3: Evolutionary process of software development
5 Conclusions and future research We have proposed an evolutionary approach to software development. It consists of three activities: re nement, extension, and modi cation. We have also given a formal de nition for evolution, which includes rules for re nement, extension, and modi cation. We have described how the evolution can be used to control the process of software development, in particular the development using SOFL speci cation language. As we have realized that a good quality software environment for evolution is crucial in enforcing the evolutionary disciplines in real software projects, improving and extending the existing tools remains as the highest priority in our future research.
References [1] Carroll Morgan. Programming from Speci cations. Prentice-Hall International(UK) Ltd., 1990. [2] John A. McDermid (editor). Software Engineer's Reference Book. Butterworth-Heinemann Ltd., 1993. [3] Shaoying Liu. A Structured and Formal Requirements Analysis Method based on Data Flow Analysis and Rapid Prototyping. PhD thesis, University of Manchester, U.K., August 1992. [4] Shaoying Liu, A. Je O utt, Chris Ho-Stuart, Yong Sun, and Mitsuru Ohba. SOFL: A Formal Engineering Methodology for Industrial Applications. IEEE Transactions on Software Engineering, 24(1):337{344, January 1998. Special Issue on Formal Methods.
5
