SOFTWARE MAINTENANCE: RESEARCH AND PRACTICE, VOL.

4, 119-128 (1992)

A Formal Approach to Perfective Software

Maintenance: Integration Using a Basis
DAVID RINE
Department of Computer Science, School of Information Technology and Engineering, George Mason
University, Fairfax, V A 22030-4444, U.S.A.

SUMMARY
We investigate how a formalism, common to many areas of applied mathematics and engineering,
known as a basis can be applied to perfective maintenance and integration in software engineering,
using an object-oriented approach. It is concluded that this formalism serves as a mathematical model
for perfective software maintenance and integration activities. Theorems and properties about the
model are reported as guides to software maintenance. The model and formal maintenance techniques
have been applied to a software system in the management information systems area to demonstrate
this approach to perfective maintenance and to assist in validating the model.
KEY WORDS Perfective maintenance Basis Baseline Integration of software components Object-oriented
development Configuration control Formal methods

1. INTRODUCTION
Traditionally, software maintenance falls into three categories (Sommerville, 1989): perfective maintenance, adaptive maintenance, and corrective maintenance. A survey by Lientz
and Swanson (1980) reports that 65% of software maintenance is perfective. Ideally,
perfective maintenance changes should add functionality to the software system without
compromising its original functionality. Furthermore, such changes, at either the users
view (abstract level) or changes at the systems view (representation level), should be such
that software system changes are made without compromising its original functionality.
Since at least 50% of effort may be devoted to maintaining an existing system, it is
important to better understand the concepts of software maintenance, perfective maintenance in particular. Moreover, the nature of perfective software maintenance we explore
is fundamental to ongoing integration of new and reusable software components in a
software system.
In other areas of engineering the development of a mathematical model and mathematical methods provides insights into and understanding of structure and processes in those
disciplines. We propose that mathematical methods and models can also provide that kind
of insight and understanding to software maintenance engineering. There has been little
work on mathematical models and methods for perfective maintenance.
Perfective maintenance refers to changes demanded by users at the applications end or
1040-550)(/92/030119-10$10.00

0 1992 by John Wiley & Sons, Ltd

Received 15 October 1990

Revised 20 September l99I

120

D. RINE

by systems support at the representation end. These changes may come as stated new
requirements and are dealt with during change control procedures. The impacts of such
changes may occur at either the specification level or the algorithmic level.
The notion of describing or constructing an application or function from a basis is an
old and important concept in the areas of mathematics, physics, and engineering. Areas
such as Fourier analysis, linear algebra, and functional analysis in applied mathematics
have used the notion to characterize a class or set of applications or functions. Physics
and engineering have used the notion extensively to characterize, analyse and synthesize
(integrate) various waveforms. However, the notion of basis has not so obviously been
included within the formal framework of software engineering. The purpose of this paper
is to investigate how this can become a powerful formal framework in software engineering
perfective maintenance and integration as well.
Therefore, we investigate how a formalism, common to many areas of applied mathematics and engineering, known as a basis, can be applied to perfective maintenance and
integration in software engineering, using an object-oriented approach. It is proposed that
this formalism serves as a mathematical model for perfective software maintenance and
integration activities. Theorems and properties about the model are investigated as guides
to software maintenance. The model and formal maintenance techniques have been applied
to a software system in the management information systems area to demonstrate this
approach to perfective maintenance (Rine, 1991b).

2. THE NOTIONS OF BASELINE AND BASIS

A basis of a universe of discourse or a problem domain is a linearly independent subset
which generates (spans) the whole domain (space).
The notion of a basis is an abstraction of the software engineering notion of baseline
which is founded on the important idea of a set of reusable, stable, standardized software
components. A baseline has also been viewed (IEEE, 1984) as a specification that has
been formally reviewed and agreed upon, that thereafter serves as the basis for further
development. and that can be changed only through formal change control procedures,
including the incorporation of additional requirements arising during perfective or adaptive
maintenance. Software companies have devoted considerable cost to the development of
baseline product libraries that thereafter support the further development of applications.
Such libraries are often domain-specific, for example standardized science and engineering
subroutine libraries or Ada package libraries such as Common Ada Missile Packages
(CAMP) (CAMP, 1987). Another kind of example would be Common APSE Interface
Set (CAIS, 1985) developed as a standardized library or database of Ada packages
meant for the development of sets of tools. Standardized software components have been
developed by use of either the building blocks approach (Lenz, ef af., 1987) or the
patterns approach (Baker, et al., 1983). Such components may be developed as generic
parameterized modules (Meyer, 1988). abstract data types (Meyer, 1988), deferred classes
(Meyer, 1988), meta-views (Lamsweerde et al., 1986), modules (Parnas, 1972), or other
patterns or building blocks.

121

PROTECTIVE SOFTWARE MAINTENANCE

2.1. Introductory formalism

Let E = {el, e2, . . ., e,} denote a basis for a particular baseline of software products.
In this investigation we take an object-oriented approach and consider the members of E
to be abstract data types (ADTs) or ADT representations after Meyer (1988). Hence, the
issue of configurations from the basis will be addressed by means of inheritance and other
related structure operations. The symbol + will denote inheritance, the symbol * will
denote class or ADT intersection (features in common), and the symbol . will denote
class with additional features. For example, using syntax from Meyer (1988), let us consider
the following structural assembly of classes:
class GRAPHICS
export-Graphics interface
inherit POINTS; LINES; TRIG
feature
c1;

c2.;
c3 ;

end-class GRAPHICS
With our notation this is represented by the following expression:
GRAPHICS

= CI

. POINTS

~2

. LINES +

~3

. TRIG

where c , , c2, and c3 are the additional features that must be incorporated with E
{POINTS, LINES, TRIG, . . .} to construct GRAPHICS.

THEOREM 1 (Rine, 1990). Let 0 denote the null class with no exported features. Let
E = {el, e2, . . ., en} represent an abstraction of a baseline which is a proper subset of
possible components such that none of the e, (i in [I, n ] ) is the null class. Then E is a
basis.
Proof. Consider cl, cz, . . ., c, as arbitrary features or subcollections of features, and
suppose that c , - e , + c2.e2 + . . . + c;e, = 0. This means that the result of inheriting
exported features from e l , e2, . . ., e, and adding additional features cl, c2, . . ., cn is the
null class of features. This can only be true if each of the ci-ei is the null class of features,
ci-ei = 0 (i in [ l , n]). Now ei is not the null class and has exported features. So ci has no
features to contribute to the assembly. Hence, ci = 0 (i in [ l , n ] ) .Hence, E is a linearly
independent subset. Since E is a baseline it spans the specified domain space. Hence, E
is a basis.
Notice that we assumed that E is an abstraction of a baseline. This is a rather strong
assumption.

2.2. Fourier analysis

Let E = {el, e2, . . ., e,,}. In the spirit of Fourier analysis one raises the question as
to whether or not E is orthogonal and orthonormal. That is, given an assembled

122

D. RINE

application, A , in the specified domain space, is E orthogonal and orthonormal, and can
one find Fourier coefficients c,, c, . . ., c,, of A relative to E so that A is approximated
by . . . cl.el + c2.e2 + . . , + c;e,, c, = ( A , ei), dependent upon A and ei,i in [ I , n].
QUESTION. When is it the case that if i not equal to j , i, j in [I, n ] , then e,*eJ = 0, the
null class? That is, when is E orthogonal?
Recall that ef*eJis the class intersection of el and ej, that is those features in common with
both classes (or ADTs). That leads us into an important problem regarding an integration
of classes similar to the integration of subschemas in database design. That is, incorporating two different classes into an assembled system, for example by way of inheritance,
may lead to a problem of inconsistency of, for instance, the two classes having some of
the same named features. Hence, if e,*ej is not equal to 0, the null class, then el + ej,
inheritance, can lead to inconsistencies. These inconsistencies must, as with Meyer (1988),
be resolved by appropriate use of renamilig and redefining. Therefore, ideally, it would
be appropriate for e,*e, = 0 when i is not equal to j , i, j in [l, n ] . Of course, if i = j and
if repeated inheritance (Meyer, 1988) is allowed, then one must also address possible uses
of renaming and redefining as well.
RECOMMENDATION. Given E = { e , , e,, . . ., e,z} a baseline which is not orthogonal,
that is, there exist i, j in [ I , n] such that el*ej is not equal to 0, construct a new baseline
E = {e,, e,, . . ., err}which is orthogonal.

THEOREM 2 (Rine, 1990). Assume that it is given that E is an abstraction of a baseline

which is not orthogonal. There exists an abstraction E of the baseline which is orthogonal.
Proof. If el*eJis not equal to 0, then, without loss of generality, let el be e, minus those
exported features in common with ej. Let ej be el plus those exported features in common
with el. Hence, E is orthogonal.
The final issue in the Fourier analysis part of this proposed investigation will deal with
completeness. A completeness theory would suggest that E is complete for a domain in
question if for every application A in the domain, A is approximated by A = c,.e, +
cz.e, + . . . + c,;e,,, where A is a converging approximation to A , suggesting that there
is a systematic way to add more information at each step where A gets closer to A , that
is what the user wants. This is carried out informally in many software engineering
methods, including (rapid) prototyping.

3. DOMAIN MODELLING
Based upon the principles introduced in the previous section, recall the following ideas:
-

basis: baseline, components library (e.g. CAMP), domain-dependent (e.g. missiles)

cs: additional features that need to be developed which refine each of the es

c.e: c refines e

A : application (e.g. missile application).

PROTECTIVE SOFTWARE MAINTENANCE

123

In this investigation our primary domain is in the management information systems (MIS)
arena (RINE, 1991a). From this, primarily in the MIS domain, the following goal statement
follows:
DESIGN GOAL 1. Given an abstraction of a baseline E = {el, e2, . . ., e n } and an
application A ( e l , e2, . . ., en) function of E , show that there exist refinements C = {cI,
c,, . . ., en} of E such that A ( E ) = cl.el + c2-e2+ . . . + c,-en.
In the algebraic methods associated with the logic design of an integrated circuit (Rine,
1984) one is not only concerned with a representation of integrated components, one is
also concerned with a better representation than that which is currently given. By
means of algebraic reduction rules one may simplify, or even minimize, a given formal
representation, arriving at a representation with fewer features. One may also find a
basis with fewer components than the given basis.
Let us address this problem here. Given a basis or baseline E = {el, e2, . . ., e l , } ,
suppose that one can find another basis or baseline F = cfi, f2, . . .,fm} and find features
dl, d2, . . ., d,,,, where m < n and where each dk refines fk, such that A(F) = A ( E ) =
dl*fl + d2.f2 + , . . + dm*fm.
PROBLEM TO BE INVESTIGATED. Which is a better representation, A(F) or A(E)?
Characteristics of better include but are not limited to effort, simplicity, and so forth.
Algebraic completeness is also a potential characteristic of better. E is complete whenever
the previously mentioned goal statement holds.
In developing a system by means of the previously discussed assembly concept using
+ ,*, and -it is not always possible to know all of the application requirements in advance,
or if they are quite numerous then an approximation of the final system would be useful
to consider. These issues are often resolved in practice by use of the tool known as rapid
prototyping. In practice the goal in such cases, and an important implementation goal
based upon our formal model, is the following:
DESIGN GOAL 2. Given basis or baseline E = {el, e,, . . ., e l , } and required
(requirements) application A , find t l ,t2,. . ., tnsuch that tiis used to partially refine el
and such that A = t , . e , + Cz-e2 + . . . + tn.en is a good approximation to A .
Thus, A represents the full requirements of the application (theoretical solution), and
A is a member of a class of related approximations to A , each of which is within an
acceptable tolerance.
Design goals 1 and 2 stated above are achieved theoretically by means of a formal
model in phase one of perfective maintenance, while they are achieved by means of an
actual system in phase two of perfective maintenance.

4. PERFECTIVE MAINTENANCE
Recall the introductory comments about perfective maintenance from section 1 where
perfective maintenance refers to functional-oriented or data-oriented changes made to a
system S, deriving a new version of the system S , without changing the original functionality of S , assuming use of S is still needed. In this section we will show how the

124

D. RINE

formal modelling approach outlined in section 2 and section 3 can be used to more
concisely understand perfective maintenance. It makes sense to continue this explanation
with the notion of formal software specification.
A formal software specification is a specification expressed in a language whose vocabulary, syntax and semantics are formally defined (Sommerville, 1989). The need for formal
semantic definition means that the specification languages cannot be based on natural
languages but must be based on mathematics. Formal software specifications are mathematical entities and may be studied and analysed using mathematical models and methods.
The development of a mathematical model and mathematical methods provides insights
into and understanding of software maintenance. While there have been other investigations using semi-mathematical methods to investigate software maintenance, for example
Yau (1982), there has been little work on mathematical models and methods for perfective
maintenance. We are, however, aware of other formal specification tools, such as SXL
(Lee and Sluizer, 1991), that may be of some related use in building prototypes from
formal models.
We will further pursue the mathematical modelling ideas, using a basis, introduced in
section 2, but we first need to introduce a bridge between perfective maintenance and
formal concepts of such perfective maintenance changes.
Recall that perfective maintenance refers to changes demanded by users at the applications end or by systems support at the representation end. These changes may come as
stated new requirements and are dealt with during change control procedures. The impacts
of such changes may occur at either the specification level or the algorithmic level. One
of the serious considerations when making such changes is the result of impact analysis.
A question that often arises is how such alterations will affect the operation of the original
software. Zimmer (1989) has pursued a method for verifying that the revised version
functions much the same as the original version of the software. That paper considers
small programs and alterations at the algorithmic level. The key is to study principles
leading to a greater understanding of how alterations to the first version of the software,
through requested additional user requirements or representation requirements, will not
lead to undesirable or unanticipated changes in the original functionality in the second
version of the software. One can also address this problem through the software development by contract notion of Meyer (1988). In that case if an alteration is represented as
an inheritance of an additional class, then the parents invariant rule could catch certain
new assertions in the alterations that may lead to changes in the present set of assertions
for the first version of software. However, without very rigorous use of assertions, some
unanticipated changes may go undetected when the first version is merged with the
required alterations. as in Meyer (1988), the usage and semantics of ADTs and class
representations of ADTs are given by means of assertions. If an A DT or class A inherits
an ADT or class B and if A is a component of an existing software system S, then the
addition of Bs assertions may change the usage and semantics of S in possibly undesirable
or unexpected ways. Answers to the following questions are worth investigating and are
being pursued in our continuing investigation.
Q1. Will the software system S continue to perform and behave as before?

Q2. Will the original contract (Meyer, 1988) between users and producers of S still hold
and be undisturbed or unviolated?

PROTECTIVE SOFTWARE MAINTENANCE

125

Q3. Will the addition of B, and new requirements, lead to undesirable or unexpected
side-effects in the usage o r semantics of S?
A partial answer to these questions lies in the notion that S will not be disturbed if the
usage and semantics, defined by assertions, of S are not changed by adding B through
the previously mentioned inheritance.
Let us continue the earlier discussion by formalizing the notion of perfective maintenance. Let E = { e l , e2, . . ., en} be a basis or baseline and let A(el, e2, . . ., e,J = c , . e ,
+ c2.e2+ . . . + c;e,. Let e denote a component, in ADT form, associated with a new
user requirement. The general perfective maintenance problem then is to find ci,i in [l,
n], C such that A ( e l ,e2, . . ., en) = cl.el + c2.e2 + . . . + c,lr.e,l+ cae. The question
then is: What are the important properties of the resulting A ? ,which A may or may
not possess.
Possible properties of new version A :

(I) Let Z(A) denote the user inputs for the first version of A , and let AlI(A) = A
denote A restricted to I ( A ) ; the new software system performs as usual on the old
data.
(2) e produces no usage or semantic changes on the original A .
(3) Let d be the prototype approximation of A . Then the relation of A to A, prototype
approximation to A , is that d + cee = d.
(4) d does not need to be revised, that is ci = ci, i in [l, n ] ; all changes are local to
cae.
EXAMPLE. Let A be relational database processing, and let I (A ) denote the original
relational database input which A uses. Let e denote the component, in ADT form,
associated with a new requirement. Assume the new requirement to be that the present
version of the system be expanded so as to allow object-oriented processing, but by means
of the original relational database. Using our notion, Wiederhold (1990) suggests a c
termed the view object. Then c.e denotes the interface to relational processing. Property
(1) should hold. Another important characteristic of that proposed extended system is
that A = c,-e, + c2.e2 + . . . + c;e, + cae = A + cae, that is that property (4) above
holds.
In summary, e is said to produce no usage or semantic changes on A if c, = c,, c2 =
c2, . . ., c, = c, that is no significant adjustments need to be made to the original
(requirements of) A .
According to Meyer (1988) there are two kinds of features that may be added to a
class. The first kind of features are those which only affect the representation behaviour
of the class and system in which the class resides; these may be associated with strictly
internal side-effects that may, in fact, sometimes have redeeming qualities, such as internal
performance adjustments. These may change, therefore, internal representation level
assertions such as representation invariants. The second kind of features that may be
added are those which affect the abstract behaviour of the class and system in which the
class resides; these may be associated with specification level usage and semantic changes
at the users level of the system, that is, associated with user functional requirements. The

126

D. RINE

c,, i in [ l , n], to which we have referred in the previous discussion may be at either the
representation or abstract levels. We, therefore, state an important formal property of
perfective maintenance.
( 5 ) Let e denote a component, in A D T form, associated with a newly specified set of
user requirements. Then at the abstract level A ( E ) = A ( E ) + c-e if for all i, i in
[l, n ] , c;, c;. are abstract level (as opposed to representation or concrete level
(Meyer, 1988) features, and c, e contain no naming, usage or semantic conflicts
with respect to A ( E ) . Here we assume that c and e are orthogonal as described in
section 2.
If this is indeed the case, then the original contracts between users and developers of A
should not be compromised, and A is upward compatible with A .
However, in general a proposed addition of e, where the c,, i in 11, n ] , are both
representation level (concrete level) and abstract level features, will lead to some ck not
equal to c k . That is, internal representation level features may need to be changed to
improve non-functional requirements and performance. Or behaviour, naming, usage or
semantics may be changed, and A ( E ) is not equal to A ( E ) + c . e .

5. RESEARCH WORK
In this research we investigate how a formalism, common to many areas of applied
mathematics and engineering, known as a basis, can be applied to perfective maintenance
in software engineering, using an object-oriented approach. We show how this formalism
serves as a mathematical model for perfective maintenance activities. Theorems and
properties about the model are investigated as guides to software maintenance.
In the first phase of the research we complete the formal model, that is architecture,
for perfective software maintenance and integration. In the second phase of the research
we show (Rine, 1991b) by means of a software demonstration how this above-mentioned
formalism can be applied to perfective maintenance and integration of a particular system
using an object-oriented rapid prototyping approach. We used object-oriented requirements analysis procedures to address perfective maintenance on the to-be-updated software
system. These procedures enable us to identify connectivity and relationships among the
components of that system and thereby form our formal model of the software system.
Within this model, a set of mathematical relations allows us to show how a change may
possibly affect other components of the formally described system. We then apply a rapid
prototyping technique to validate the model by using a prototype approximation concept,
previously discussed, to see if the original, undisturbed system requirements continue to
hold as before. Our formalism should afford construction of a mathematical model
enabling us to formulate, describe and characterize solutions for problems in perfective
maintenance. For example, we should be able to describe the prevention of unanticipated
impacts due to changes of the example software system.

6.

CONCLUSIONS

We have investigated how a formalism, common to many areas of applied mathematics

and engineering, known as a basis, can be applied to perfective maintenance in software

PROTECTIVE S O f l W A R E MAINTENANCE

127

engineering, using an object-oriented approach. It is proposed that this formalism serves

as a mathematical model for perfective software maintenance activities. Theorems and
properties about the model are to be used in the first phase of perfective maintenance as
guides to software maintenance. In the second phase of perfective maintenance the model
and formal maintenance techniques are applied to a software system in the management
information systems area to demonstrate this approach to perfective maintenance and to
assist in validating the model.

7. FUTURE WORK
We are carrying out a research project covering a period of time. In this period of time
we are proceeding by working on an improved and expanded theoretical basis and model
for performing perfective maintenance on software systems using our basis approach in
specific domain areas. We are also proceeding to build an experimental software research
product that will demonstrate concepts of our theory and model.

7.1. Procedures and methods

In previous work we have done some preliminary investigation on perfective maintenance for software systems using a basis and object-oriented approach and have successfully
argued for a need to investigate further how perfective maintenance and integration on
software systems using our basis approach can be modelled and implemented in at least
certain domains. In the research period we are attempting to develop a convincing
theoretical basis and model for performing perfective maintenance using basis-oriented
software components and systems in the specific domain of management information
systems, see for example (Rine, 1991a).

7.2. Research products

In the second phase of this ongoing project we will develop a working software prototype
of a perfectively maintained software system using our basis approach in the management
information systems area, using basis-oriented software components and demonstrating
concepts and model features produced in the first phase of work.

7.3. Other related work

Weber (1991) has presented a framework for integration of reusable software components. In that authors section on Engineered integration three integration frameworks
are mentioned. In that authors second framework a procedural nesting mechanism is
mentioned and data flow methods are later mentioned in that article. This framework
falls within functional methods as opposed to object-oriented methods. Our framework
in this paper uses an object-oriented framework. In the Software component model
section of the Weber (1991) paper there is discussion of a canonical software component
and a general notion of an invariant property. In our paper we present a more precise
notion of an invarient property based upon formal methods from object-oriented design
and abstract data type integration. Some of the later examples of the Weber (1991) paper

128

D. RINE

deal with data integration problems that are well-known from much prior work on data
systems design and integration. Weber is familiar with these database design problems
and has referred to them in earlier work (see references based upon those in the Weber
(1991) paper). We propose that the work in our paper complements work previously
reported, for example, the Weber (1991) paper.

References
Balzer, R., Cheatham, T. E. and Green, C. (1983) Software technology in the 1990s: using a new
paradigm, IEEE Computer, 13.
CAIS (1985) Military Standard Common APSE Interface Set, US Department of Defense, MILSTD-CAIS.
CAMP (1987) Common Ada Missile Packages: reusable software parts, McDonnell Douglas
Astronautics Co. (MDAC-STL), St. Louis, MO.
IEEE (1984) Software Engineering Standards, The Institute of Electrical and Electronics Engineers
(IEEE), New York.
Lamsweerde, A. van, Buyse, M., Delcourt, B., Delor, E., Ervier, M. and Schayes, M. C. (1986)
The kernel of a generic software development environment, Proceedings of the ACM SZGSOFT
and SIGPLAN Symposium, ACM, New York.
Lee, S. and Sluizer, S. (1991) An executable language for modeling simple behavior, IEEE
Transactions on Software Engineering, 17.
Lenz, M., Schmid, H. A. and Wolf, P. F. (1987) Software reuse through building blocks, IEEE
Software, July.
Lientz, B. and Swanson, E. (1980) Software Maintenance Management, Addison-Wesley, New York.
Meyer, B. (1988) Object-oriented Software Construction, Prentice Hall, Englewood Cliffs, NJ.
Parnas, D. L. (1972) On the criteria to be used in decomposing systems into modules, Communications of the ACM, 5 .
Rine, D. C. (1984) Computer Science and Multiple-Valued Logic , NorthiHolland, New York.
Rine, D. C. (1990) A formal approach to perfective maintenance: using a basis, Technical report,
Department of Computer Science, George Mason University, Fairfax, VA, August.
Rine, D. (1991a) The use of object-oriented construction to develop an expanded management
information system, Cybernetics and Systems: A n International Journal, 22.
Rine, D. (1991b) Perfective maintenance on an expanded MIS using a formal approach, Technical
report, CS Department, George Mason University, Fairfax, VA.
Sommerville, I. (1989) Software Engineering, 3rd edn, Addison-Wesley, Reading, MA.
Weber, H. (1991) The integration of reusable software components, Journal of Systems Integration,
1.

Wiederhold, G., Risch, T., Rathmann, P., DeMichiel, L., Chaudhuri, S., Lee, B. S . , Law, K. H.,
Barasalou, T. and Quass, D. (1990) A mediator architecture for abstract data access, Technical
report no. STAN-CS-90-1303, Department of Computer Science, Stanford University, February.
Yau, S. and Collofello, J. (1982) Design stability measures for software maintenance, Proceedings
of COMPSAC 82, November, 1982, IEEE Computer Society.
Zimmer J. (1989) Altering without change, Journal of Software Maintenance: Research and Practice,
1 (l), 2946.