Conﬁg: a case study in combining software engineering techniquesdownloads.hindawi.com/journals/sp/2000/401540.pdf · 2019. 8. 1. · 59 Conﬁg: a case study in combining software

59

Config: a case study in combining softwareengineering techniques

David Maleya and Ivor Spenceb

aSt. Mary’s University College, 191 Falls Road,Belfast BT12 6FE, Northern Ireland, UKE-mail: [email protected]’s University of Belfast, Belfast BT7 1NN,Northern Ireland, UKE-mail: [email protected]

Config is a software component of the Graphical R-MatrixAtomic Collision Environment. Its development is docu-mented as a case study combining several software engineer-ing techniques: formal specification, generic programming,object-oriented programming, and design by contract. It isspecified in VDM++; and implemented in C++, a languagewhich is becoming more than a curiosity amongst the sci-entific programming community. C++ supports object ori-entation, a powerful architectural paradigm in designing thestructure of software systems, and genericity, an orthogonaldimension to the inheritance hierarchies facilitated by objectoriented languages. Support in C++ for design by contractcan be added in library form. The combination of techniquesmake a substantial contribution to the overall software quality.

1. Introduction

The stages of the software development lifecycle arewell-documented [1,2]. Improved techniques for thevarious stages of the process include the use of formalnotation for the specification stage, object-orientationfor the design and implementation stages, and designby contract for the testing stage. There is no implica-tion intended that these stages follow in sequence – an-other overall improvement in software design method-ology has been the development of a more integratedapproach. In addition, the exploitation of genericity hasproven to be a valuable technique at several stages ofthe software engineering process. This paper presentsa case study in the use and interaction of these varioustechniques; the focus is on genericity, as a techniquethat has perhaps received less acclaim that it deservesin the literature to date.

2. Overview

This paper describes how the software engineeringtechniques of generic programming, object-orientedprogramming, formal specification and design by con-tract were employed in tandem in the construction ofthe software component Config [3], with a particularfocus on the utility of genericity.

2.1. Genericity

Generic programming has the potential to enhancesoftware quality in a number of ways. In its simplestform it is a way of avoiding duplicating code in circum-stances where the only distinction between two piecesof code is the types they manipulate. Thus to use a listof INTEGERs and a list of REALs, only one list module(or whatever construct is appropriate) is needed. Soft-ware quality is in this case enhanced by elimination ofduplication: this means that information is in one placeonly, and it therefore cannot be inconsistent. Then ifit needs to be changed, there is no danger of miss-ing an instance where the change is necessary. It alsopromotes reuse, since generic modules can be writtenwhich can serve a wide range of purposes when instan-tiated. This was the motivation for the C++ StandardTemplate Library (STL) [4]. Therefore, the designerand implementer can concentrate on the specific prob-lems of the task at hand without having to reinvent thewheel each time a list of objects or a search algorithmis needed.

In this paper we demonstrate some more sophisti-cated uses of genericity, whereby two distinct aspectsto supporting run-time assertion monitoring in C++ areillustrated: providing a framework in which the be-havioural properties can be monitored, and providinga framework in which behavioural properties can beexpressed.

Generic programming is a static technique,amenableto both object-oriented and non object-oriented pro-gramming. This is borne out in the languages that sup-port it. For example, object-oriented C++ and non

Scientific Programming 8 (2000) 59–71ISSN 1058-9244 / $8.00 2000, IOS Press. All rights reserved

60 D. Maley and I. Spence / Config: a case study in combining software engineering techniques

object-oriented Ada do support it, and object-orientedJava and non object-oriented Fortran90 do not. It willbe demonstrated in this paper how powerful and eleganttechniques for expressing a software architecture areobtained from a language that supports both genericityand inheritance. Therefore genericity is used to besteffect in an object-oriented environment. The imple-mentation language chosen for the software componentdocumented here, Config, was C++ [5]. A rich anddiverse language, C++ now boasts both a standard andnear enough standard-compliant compilers.

In practice, more often than not generic program-ming takes a form known as constrained genericity. Itthen becomes an abstraction technique, like the inher-itance taxonomies of object-oriented languages. Theabstraction in this case is a set of requirements on thedata types that may be used to instantiate a genericparameter.

This case study takes examples from the develop-ment of Config, a software component of the GraphicalR-Matrix Atomic Collision Environment [6]. Softwarefor generating electron distributions and couplings wasavailable in the computation stage of an early versionof the R-matrix program package. However, the orig-inal package is written in FORTRAN 77 and is typ-ical of many similar such large software systems, inthat it has evolved over many years, through the effortsof numerous personnel, in a process of controlled it-erative enhancement. Often the modification and ex-tension of such large, complex and mature softwaresystems is severely hampered because some compo-nents of the system are written in an implementation-dependent fashion, they are inadequately documented,their functionality is not precisely known, and undercertain circumstances they fail to operate correctly.

The design goals of Config therefore included thefollowing:

– write a formal specification of the component inorder to state precisely and unambiguously thefunctionality of the component;

– apply object-orientation as the principal structur-ing mechanism for the system;

– make maximum use of existing libraries in orderto minimise development time, and take advantageof the efforts and expertise of other developers;

– minimise the gap between the formal specificationstatement and the implementation. Ideally thismeans constructing a proof that the implementa-tion is correct with respect to the formal specifica-tion; but if that is unrealistic then to adopt an inter-mediate methodology such as design by contract.

Initial work to address these problems for Config, in-volved developing a formal specification of the problemof generating electron distributions and couplings [7].A version of the formal specification, rewritten to takeadvantage of the newly-emerging object-oriented spec-ification language VDM++ [8] and showing the signif-icant characteristics of the abstract data types of Config,is reproduced in WebAppendix I.

The formal specification states the properties of thedata types involved, and the properties of the operationson them. It serves a number of important purposes.Firstly, it provides a precise, unambiguous, consistentand complete statement of the functionality of the com-ponent. At the same time, it does not over-specify: itstates what the component should do, but without stat-ing how it should do it. A finished program meets mostof the criteria for being considered a formal specifica-tion: except that it over-specifies. A formal specifica-tion would state that a routine returns the square root ofits input, but it need not state how the square root is to becomputed. The original formal specification of Configwas written in the language VDM-SL [9]. The secondimportant purpose served by the formal specification isthat it provides a basis for program proving, for reason-ing about properties such as completeness and consis-tency, and for thinking in general. Thirdly it serves assystem documentation, so maintainers are not obligedto read the code in order to discover the system’s func-tionality. It has been shown that the predicates in aspecification can be used as component-library searchkeys [10], and also that specifications can be used fortest generation [11–14], animation [15], performancetuning and system integration.

VDM++ provides a number of types for modellingthe problem domain, such as sets, maps and lists (listsare called sequences in VDM++). It is a natural nextstep to use the C++ Standard Template Library to im-plement these types. The types are known collectivelyin the STL as containers, since their purpose is to con-tain collections of objects. The STL provides genericcontainer classes, from which new types can be con-structed without having to be concerned with the imple-mentation of the container data structures. Likewise,many of the common operations upon these containersare provided in the form of parameterised algorithms.These algorithms are in addition to the methods of thecontainer classes. Indeed, some commentators wouldview the STL as a collection of generic algorithms, andconsider containers as being provided simply to givethe algorithms something to work upon.

The similarities between the data structures andstructure manipulation methods provided by VDM++,

D. Maley and I. Spence / Config: a case study in combining software engineering techniques 61

and those provided by C++ STL may lead one to won-der whether the VDM++ is really necessary. Can theSTL instantiations not serve as specification, imple-mentation and documentation? This is not the case,or at least not entirely. It is in the statement of thebehaviour of the operations that constitute the modelof the physical system where VDM++ provides ab-stractions that are not possible in C++/STL. In theory,C++/STL data structures and structure manipulationoperations could be used as the basis for stating theoperations that model the physical system (Larch [16]would permit this, for example),but it would not be pos-sible to achieve the clear, precise and implementation-independent statement possible in VDM++. Further-more, the abstract behavioural properties can then betransformed into validity checks as part of the designby contract process, independently of the algorithmicimplementation of those properties.

One of the underlying principles of the STL is thatcomplexity guarantees are given with the components.This means that operations are guaranteed to completewithin stated time scales: it is recognised that a librarywill not be used if performance is sacrificed for thesake of generality. The recent C++ Standard [17] waseven influenced by this requirement [18], with the ad-dition to the templates section of partial specialisation,which allows algorithms and classes to be much moreefficient. Partial specialisation adds a large degree offlexibility to working with the STL.

The STL also provides specialised support for nu-meric operations. For example, it is recognised thatmuch numeric work relies on relatively straightforwardsingle-dimensional arrays of floating-point values, andthat these structures are supported by high-performancemachine architectures and aggressive code optimisa-tion. Consequently the STL provides a vector (calledvalarray) designed specifically for speed when us-ing the usual numeric vector operations.

It has already been mentioned that the container classstructures and their methods closely mirror the abstractdata types used in the specification language. However,the STL does not provide mechanisms for checking theproperties of the types created from it as they might bestated in a formal specification. A formal specificationof the data types in a software component will specifynot only data structure and permitted operations, butalso constraints. In a language such as VDM++, forthe data structures these will be in the form of invariantson the values of the data; for operations, they will bein the form of preconditions and postconditions on theexecution of operations. Thus, the STL needs to beextended to accommodate this requirement.

It must be understood that the requirement to be ableto monitor the constraints stated in the formal specifica-tion is not merely a luxury desired by computer sciencetheorists: it is a basic tenet of the development tech-nique known as Design by Contract [19], which has sig-nificant implications for software quality. Probably theforemost exponent of this technique is Bertrand Meyer,the designer of the language Eiffel [20]. Eiffel provideslanguage support for Design by Contract. However, thelanguage has had little impact thus far on the scientificcommunity. One significant limitation of Eiffel is thatthe mechanism for expressing constraints is limited,and only simple propositions are permitted: certainlythe assertion mechanism provided is not sufficient formany of the constraints of Config.

So what benefits does Design by Contract offer? Inessence, the method is an aid to constructing correctprograms. It also serves as a tool for documenting soft-ware, enhances the opportunity for reuse, and providesa debugging tool. It relies on the idea of assertions:predicates which express properties of the system. If apredicate is not satisfied, there has been an error. Mon-itoring assertions means that testing can be undertakenin parallel to implementation, not just as a subsequentphase. The source of an error is easiest to identify if theerror is detected immediately following its introductioninto the system; also, if development is suspended un-til the error is removed, the problem does not becomeburied under layers of additional complexity. Takingtime to write a formal specification of the abstract datatypes in the system (that is, data structures and the op-erations upon them), coupled with the use of assertionchecking during implementation, mean that overall de-velopment times and error rates can be reduced for thelifetime of the system [21].

Finally, it must be stated that program correctnessis a relative term: a program is correct (or otherwise)only with respect to its specification. A correct imple-mentation of an incorrectly-specified system will notexhibit the desired behaviour.

2.2. Basics of Config

The essential operation of the Config component isshown in Fig. 1. The component takes an atomic con-figuration, provided by the client, and a data table,which is fixed, and uses them to generate the electroncouplings. The resulting data is termed a configurationtree list. A simple configuration tree is shown in Fig. 2.

Configuration trees have two significant characteris-tics, the symmetry of their root term (5Go in the exam-


CouplingGenerator

AtomicConfiguration

ConfigurationTree List

Russell-Saunders

Table

Fig. 1. Config functionality.

5 o G | +---+---+ | | 2 3 e 3 o 3d . F P | +---+---+ | | 1 2 o 2 e 2p . P S | +---+---+ | | 1 2 e * 1s . S

Fig. 2. A Configuration Tree.

ple) and their electron distribution (1s12p13d2 in theexample). Other components of the GRACE suite re-quire a client to provide as input both the symmetry andthe electron distribution of any trees being processed.However, it may or may not be possible to constructa tree exhibiting both a given symmetry and a givenelectron distribution. Config is used to prevent any in-consistencies of this nature arising: it can determinethe symmetries of all the trees possible from a givenatomic configuration and electron distribution, and allthe electron distributions which give rise to a givensymmetry from a given atomic configuration.

2.3. Object orientation and specification languages

Two of the most common languages used in for-mal specification are VDM-SL and Z [22], neitherof which is object-oriented. For example, in VDM-SL, an uncoupling operation might be stated as be-low. Firstly, there is a specification statement which

states that ConfigurationTree is defined to be asequence of ConfigurationTreeElements.

ConfigurationTree =seq ofConfigurationTreeElement

Following this, the specification statements firststate the signature of the operation, that it takesa ConfigurationTree as input and produces aConfigurationTree as output, and then state thedefinition of the operation using one of VDM-SL’sbuilt-in operators for sequences: the VDM-SL operatortl removes the first element of a sequence. VDM-SLprovides a number of ways to define the behaviour ofan operation, and VDM++ provides still more. Theform shown is known as definitional.

uncoupleConfigurationTree: ConfigurationTree→ConfigurationTreeuncoupleConfigurationTree(ct) ∆ tl ct

Object orientation is a software engineering tech-nique whereby the construction of a system is basedaround varying types of objects. These objects providefunctionality through a stated set of operations. If theobject stores data it is often encapsulated in such a waythat it can only be accessed via the operations. Thus theexecuting system may be viewed as a set of communi-cating objects, wherein objects send messages to oneanother requesting that stated operations be performed(perhaps with given data).

Each object defines precisely the format of the mes-sages it is capable of responding to (its operations).Therefore, a list object might be capable of respondingto a message that requests that a given item be appendedto it, but is unlikely to be capable of responding to amessage that requests the list to return its date of birth.This latter scenario is unlikely in a statically-typed lan-guage like C++, where the compiler can enforce cor-rect protocol; but in other object-oriented languages,such as Smalltalk, any message can be sent to any ob-ject, leaving with the message sender the responsibilityfor ensuring that protocol is observed. The essentialpoint is that each message is intended for and orientedaround a particular type of object.

Both VDM-SL and Z now have object-orientedextensions (VDM++ and Z++ [23] respectively).VDM++ was chosen because the facility in VDM-SLfor the explicit statement of preconditions and post-conditions integrated well with the desire to use de-sign by contract as a basis for testing. The major dif-ferences between VDM-SL and Z are discussed more


fully in [24]. Larch/C++ [25] was also considered,since it offered the prospect of a rich specification li-brary (the Larch Shared Library) and also greater ex-pressivity of implementation concerns. However, theabsence of tool support for typechecking made it animpracticable choice.

These extensions are constantly evolving, and thedebate about how best to incorporate genericity intoVDM++ is on-going; it is unfortunate that the cur-rent state of the language does not currently permit theeconomy of expression that can be enjoyed in C++.However, using VDM++, the object supplies a contextthat at least renders the name repetition in the aboveexample redundant. Clearly there is a lot of repetitionof the name ConfigurationTree in the definitionof the uncouple operation, and using an object-orientedlanguage eliminates this. This hardly constitutes a ra-tionale for adopting an object-oriented approach, butthe example typifies the way many operations are in-herently oriented around a particular data item, in thiscase a ConfigurationTree. Hence in VDM++,a ConfigurationTree class which maintains a listk of ConfigurationTreeElements can be de-fined with an uncouple() member as follows:

class ConfigurationTreeinstance variablesk: seq of ConfigurationTreeElement;. . .operationsuncouple(): →

pre len(k) >0postk = tl k∼

The signature of the operation is in this case empty,and the action is defined in terms of a postconditionwhich states the effect of the operation on the instancevariable k of the ConfigurationTree object. Thepostfix tilde (∼) denotes the ‘old’ value of the sequencek, i.e. the value of the sequence prior to the operation.

2.4. The STL

The STL is a large and extensible body of efficient,generic and interoperable software components. Manyof the fundamental algorithms and data structures ofcomputer science are included, but with a crucial dis-tinction from the way that they are usually found inlibrary form: the algorithms and data structures are de-coupled from one another. The STL can be thought ofsimply as a library of generic algorithms; the container

classes of the library are there merely to give the algo-rithms something to work on. It is perfectly acceptable(and indeed expected) that STL algorithms will be usedon user-defined containers,and that STL containers willbe acted upon by user-defined algorithms. Adoption ofconstrained genericity permits the level of decouplingnecessary to achieve this, using iterators and functionobjects. The STL algorithm find if(..) illustratestheir use.

template <class InputIterator,class Predicate>InputIterator find if(InputIteratorfirst, InputIterator last, Predicatepred) {

while (first != last && !pred(*first)) ++first;return first;

}

It might be called as follows:

void f(vector<int>& v1){

find if (v.begin(), v.end(), pred());}

It is used to search a container to find an elementthat satisfies a given predicate. The type of con-tainer need not be known: it simply is required toimplement the iterator protocol, so that dereferenc-ing the iterator (“*first”) and prefix incrementingit (“++first”) have the expected effect. The pred-icate is a function object: an object for which thefunction application operator operator()(..) isdefined. Thus “pred(*first)” means “apply theoperator()(..) method to the pred object withparameter *first”. Clearly the function applicationoperator of class pred must therefore be defined toreturn a bool, (or a type convertible to a bool). Aniterator to the matching container element is returned.If the search is unsuccessful then an iterator to last,the element after the final element of the container, isreturned.

A key idea of the standard containers is that theyshould be logically interchangeable wherever rea-sonable, so that, for example, code written for avector<T>may not need to be altered if a list<T>is used instead (however, the performance may alter).In order to achieve this, the STL makes use of somenew programming concepts. Principal amongst them


is the idea of iterators: the purpose of an iterator isto provide a way to sequentially access the elementsof an aggregate object without exposing its underly-ing representation. Moreover, they make it possible totraverse the container in different ways (such as fromthe end to the beginning). Iterators make it possible todecouple the algorithms and data structures. They arean example of a design pattern [26]. Design patternsare high level abstractions that can be adopted in thesolution of various commonly encountered problems inobject-oriented design.

Not every class can be used to instantiate vector<T>. For example, the instantiating class must providea default constructor. When there is a requirement likethis on the instantiating types, the genericity is knownas constrained genericity.vector<T> is used a number of times in Config,

but in fact more often that not what is required is in factan ordered vector. An ordered vector can be createdfrom an unordered vector, and there is a discussion onhow best to achieve this in WebAppendix II.

3. Example Config types

3.1. OrderedShellConfigurationList

In order to consider anOrderedShellConfigu-rationList, it is necessary to first consider the onefixed data item in Config, the Russell-Saunders table.A contraction of the Russell-Saunders table is shown inWebAppendix III. The properties of this data abstrac-tion are stated in the formal specification. It is reason-ably straightforward to map the data structures statedin the specification to instantiations of data structuresprovided by the STL. However, there is no such directcorrelation with the stated behavioural properties forthe physical operations.

The Russell-Saunders table is used to create anOrderedShellConfigurationList, which isan ordered list of ShellConfigurations. All themembers of an OrderedShellConfiguration-List have identical ShellDescription compo-nents, and are ordered by their ShellTerms. TheShellTerms are obtained from the table. Thus an ex-ample of anOrderedShellConfigurationListwould be

2p4 10S

e 2p4 32P

e 2p4 12D

e

In Fortran90 an implementation of an Ordered-ShellConfigurationList would need to pro-

vide operations such as create empty, length,head, tail, copy and append (the full imple-mentation is given in WebAppendix IV). The choice ofa linked list implementation (requiring the additionalfunctions mallocate and dispose) is not essen-tial for an OrderedShellConfigurationListsince there is a known upper bound on its length, butthe choice is not crucial to the illustration. There aretwo points to note about this implementation.

(i) the major point is that the implementation of anumber of other modules in the component, suchas ShellList, ConfigurationTree andConfigurationTreeList (not to mentionlist modules in other components) would lookpractically identical. They must also provide op-erations such as create empty, length,head, tail, copy and append. Thisrepetition is tedious and unnecessary – if not er-ror prone – for the programmer. In addition, itis not readily amenable to change, and the largerthe scale of the change, the worse the situationbecomes. If a bug is found in a list routine, anamendment is required for each of the list typesused. If it is found that the list implementationis inefficient and must be changed in its entirety,the amount of work increases in proportion.

(ii) a less significant point is that the programmerhas to be concerned with handling dynamicstorage. A different choice of representationwhich does not use dynamic storage can be madefor OrderedShellConfigurationList,but not for the other list types in Config, so the is-sue cannot be avoided. Handling dynamic stor-age can be a serious issue which can impair im-plementation performance, not to mention pro-grammer productivity. One immediate conse-quence is that if routines are defined to returnuser-defined types, then unavoidable memoryleakage can result [27].

Using the STL, both of these problems are immedi-ately overcome. To define an OrderedShellCon-figurationList, once the list element typeShellConfiguration has been defined, an Or-deredShellConfigurationList can be de-fined by instantiating the container class vector<T>with the type ShellConfiguration:

class OrderedShellConfigurationList:public vector<ShellConfiguration>{


public:OrderedShellConfigurationList(ShellDescription);

};

The STL container class vector<T> providespractically all the functionality required to implementanOrderedShellConfigurationList, such asinsert(..), erase(..) and size() operations.Only the construction functionality is missing. InC++, when an object is created its constructor is called.Constructors can be overloaded, and so the parametersgiven at the point of creation determine which con-structor is called. If no constructors are given, thecompiler will generate empty constructors. In the caseshown, an OrderedShellConfigurationListis constructed from a ShellDescription (and theRSTable, which need not be a parameter to theconstructor since it is a constant). In order to pro-vide this additional constructor the class must inheritfrom vector<ShellConfiguration> (and notjust typedef it).

However, there is another aspect of the specificationof OrderedShellConfigurationList besidesconstruction that the STL does not provide. The speci-fication also states an invariant. This is a property thatany OrderedShellConfigurationList mustobserve in order to be valid.

The invariant states that theShellTerms of the ele-ments of anOrderedShellConfigurationListmirror those in the RS-Table, and that the ShellDes-criptions in a given row are all identical. Italso makes a statement about the symmetry of theRSTable, and states a simplifying assumption aboutshells with OrbitalAngularMomenta that aregreater than or equal to three. This last point reflectsthe remark made at the end of the introduction, thatcorrectness is a relative notion.

This invariant must hold both before and after everyoperation on anOrderedShellConfiguration-List object. It must also hold after construction: it istherefore an implicit postcondition on the constructor.However, it does not state how the construction processis to be carried out: it is simply a predicate on the stateof the object when construction has been completed. Ina development environment, ideally one implementorwrites the constructor and another writes an implemen-tation of the invariant that checks that the constructoris creating valid objects.

Notice that the code that has to be written – the con-structor – is precisely that which is particular to the

system. The writer of the STL can provide operationssuch as appending, and erasing, but is unlikely to knowabout, and certainly cannot cater for, the construction ofan OrderedShellConfigurationList from aShellDescription and the RSTable: but that isnot necessary. The power of inheritance and genericitycombined mean that very often there is an appropriateand unique point for each piece of programming thatis specific to the component. Not only can the imple-menter concentrate on the specific problems of the taskin hand without having to reinvent the wheel each timea list of objects is needed, better still very often thereis no need to invent the wheel in the first place since ithas already been invented by someone else.

The implementation of an OrderedShellCon-figurationList therefore amounts to writing theconstructor, which must ensure that the constructedobject satisfies the invariant. Therefore it is necessaryto have the formal specification available in order toinform the writing of the constructor (and also to informthe independent writing of the code that verifies theproperties of the constructor).

3.2. ConfigurationTreeList

A ConfigurationTreeList is declared as fol-lows:

class ConfigurationTreeList:public vector<ConfigurationTree>{

public:ConfigurationTreeList(ConfigurationTree,OrderedConfigurationList);ConfigurationTreeList(AtomicConfiguration);

};

It therefore follows the same pattern as Ordered-ShellConfigurationList, of inheriting a con-tainer instantiation and adding functionality. In thiscase the functionality is in the form of two constructors.

Most of the operations on a Configuration-TreeList are indistinguishable from those on otherlists in the system (and any system), and these areimplemented simply by picking them off the shelf byinstantiating a generic component. The code that isspecific to a ConfigurationTreeList has oneand only one place in the system, within the two con-structors, which encapsulate all the work involved ingenerating a ConfigurationTreeList from anAtomicConfiguration.


3.2.1. STL algorithmsIt is important to bear in mind that whatever form

of ordered container is used for a Configuration-TreeList, the term ‘ordered’ simply refers to thefact that the ordering is a property that is expectedto be displayed by the container: it is not main-tained by it. (It is of course possible to create sucha container, whereby each operation ensures that or-dering is maintained). However, in Config, it isthe responsibility of the container instantiator to en-sure that ordering is maintained. In the case of theconstruction of a ConfigurationTreeList, theConfigurationTrees are not appended to the listin the desired order. Consequently it is necessary tosort the list to put the trees in order after generation.This step highlights the power of the STL. To sort theConfigurationTreeList ctl, it is only neces-sary to write:

sort(ctl.begin(), ctl.end());

Clearly for this to be possible, constrained gener-icity is again at work. The sort algorithm inthe STL relies on an ordering operator < be-ing defined for ConfigurationTree, or un-ambiguously for some type T on the inheritancechain of ConfigurationTree. Apart fromthis, the sort algorithm knows nothing else aboutConfigurationTrees, and all it knows about thecontainer they are in is that it observes the iterator proto-col. If a ConfigurationTreeList was reimple-mented using a list<T> instead of a vector<T>,the sort line in the code would not need to be changed.It is said to be ‘loosely coupled’.

4. Supporting design by contract

4.1. The notion of contract

Human contracts involving two parties are charac-terised by two major properties:

– each party is persuaded to enter into the contractby the benefits on offer; they accept that alongwith privilege comes responsibility, and are will-ing to therefore incur some obligations to obtainthe benefits;

– these benefits and obligations are documented ina contract document. The contract document pro-tects both parties. It protects the client by specify-ing the minimum that should be done: the client is

entitled to receive a certain result. It protects thesupplier by specifying how little is acceptable: thecontractor must not be liable for failing to carryout tasks outside of the specified scope.

Clearly, what is an obligation for one party involvedis usually a benefit for the other. Design by Contractapplies the notion of contract to software design. Eachroutine states the contract it is willing to enter into witha client. It states a precondition, which must be sat-isfied by the client in order for the client to enjoy thebenefits of the contract; and it states a postcondition,which details the benefits of the contract for the client.If either the precondition or postcondition of a routineare not met at any stage in the execution of the system,the contract has been broken and the error can be high-lighted. Properties that must be maintained by all rou-tines of a class can be grouped, and has become knownas the class invariant.

One important aspect of Design by Contract is whathappens to the contract when one class inherits fromanother. This issue (often cited as the Liskov Substi-tutability Principle [28]) is discussed by Meyer, and itsemulation in C++ is dealt with in another paper by thecurrent authors [29].

4.2. Supporting design by contract in general

The VDM++ language permits the precise spec-ification of the properties of the Config component.These properties can be stated in terms of an abstractmodel, without concern for how this behaviour can beproduced algorithmically or for the details of a particu-lar implementation language. This frees the mind fromunnecessary detail, facilitating analytical thought andcommunication of ideas. However, Bertrand Russel-l’s aphorism that ‘the advantages of implicit definitionover construction are roughly those of theft over honesttoil’ holds true, and the honest toil stage remains. Thissection gives an example of using the generic librarieswe have developed which help verify that the outcomeof the honest toil is the same as that obtained by theft.

In order to achieve this in C++, it is necessary toprovide a framework in which the behavioural proper-ties stated in VDM++ can be monitored, and also pro-vide a framework in which behavioural properties canbe expressed. The current authors have demonstratedhow a framework for the expression of preconditionsand postconditions, along with class invariants, can beadded to C++ classes by the instantiation of templates,and in such a way that the code of the class methods


remains unchanged [29]. We are now working on aframework for expressing the behavioural properties,and what is below is very much a snapshot of the cur-rent state of our work. The next section on addingpredicates to the STL may be more accessible for thosenot familiar with generic programming.

Consider, for example, the VDM++ statement ofthe ShellList::erase(index) routine, which isstated like this.

class ShellListinstance variables. . .shells: seq of ShellOccupancyRange;. . .operations. . .erase(index : nat1)ext rd shellspre index<=len(shells);post forall i in set inds(shells) &i < index => shells(i)=shells∼(i) andi >= index => shells(i)=shells∼(i+1)andlen(shells)=len(shells∼)-1;. . .end ShellList

The instantiation

typedef DBC0<ShellList, int> Erase;

within the scope of the ShellList class in C++brings the function

bool ShellList::Erase::post(int)

into scope. The definitions of the templates ensurethat this function is automatically evaluated after theerase(..) method has executed, and an exception isthrown if the stated condition is not met. This functionhas a generic definition, but this can be overridden byspecialisation so that it mirrors the VDM++ statement,and this is done in this case as follows:

bool ShellList::Erase::post(intindex){return forall(shells,ShellListErasePost(* object, index,* old))}

The parameter object is a pointer to the cur-rent object (i.e. in this case, a ShellList) whichis brought into the scope of the pre(..) andpost(..) routines by the instantiation of the genericclass DBC0<.>. The parameter old is a pointer toa (deep) copy of the object state prior the operation,again made automatically accessible by the instantia-tion. The definition makes use of the generic functionforall(..). We are developing a library of functionswhich facilitate the rapid transformation of VDM++statements into executable predicates in C++. Quan-tifiers, comprehensions and sequence/set transformersare all amenable to this approach.

The forall(..) function takes a function objectShellListErasePost(..) as a parameter. Thisfunction object is a specialisation of the generic classternary predicate<Object, T1, T2>. It isfundamental to the utilisation of constrained gener-icity that the instantiating type may be required todisplay certain properties. The instantiator can behelped in this by providing them with a templateclass displaying some or all of the required prop-erties, which can be specialised or inherited. Theclass ternary predicate<Object, T1, T2>is therefore provided, (which itself inherits fromthe template class unary function<T, bool>,which is provided by the STL).

The function object is defined

typedef ternary predicate<ShellList,int, ShellList>ShellListErasePost;bool ShellListErasePost(int i) {

int index(object1);ShellList old(object2);return ((i<index)?(object[i]==old[i]):

(object[i]==old[i+1])) && \onject.size()==old.size()-1

}

One of the unfortunate consequences of usinggeneric functions is that semantically significant infor-mation can be lost through the parameter-passing mech-anism. We are still investigating the best approach totackling this difficulty; in this case it has been reintro-duced locally.

Note that iterators have not been used in this exam-ple. This is because the VDM++ refers to values inthe current ShellList and the ShellList prior tothe erase operation using the same index; but the sameiterator would not be valid. This is another aspect ofthe technique that we are hoping to improve upon.


The use of function objects and generic routines in-volving iterators is an unfamiliar style of programmingfor many. However, it is a powerful abstraction tech-nique and once mastered permits concentration on thespecific details of the problem in hand and offers thepotential for a great deal of code reuse .

4.3. Supporting design by contract using the STL –monitoring and managing objects

It has been shown how the STL provides the datastructures, and many of the operations, needed to im-plement the specification of a component. However,the specification also states constraints on the data andoperations, and the STL as it stands does not provideany way to incorporate these into the implementation.In order to ensure software quality, it is important thatthe constraints stated in the specification are monitoredduring the development of the software to ensure thatthe program behaviour is conforming to that stated bythe specification writer.

In order to accommodate Design by Contract intothe STL, it was necessary to find a way to extend thecapabilities of the STL, but without interfering with thecode. This can be done using the general approachoutlined in the previous section, but there is an alter-native approach which requires less familiarity withgeneric programming. This work is documented fullyelsewhere [30], and only a brief description is givenhere. It is not necessary to be fully cognisant of howthe mechanism works in order to take advantage of theenhanced STL.

In essence, the capabilities of the STL can be ex-tended by using namespaces. A new version of the STLis written within a new namespace. The client code,occupying a third namespace, can remain unaltered, butits behaviour changes depending upon which names-pace it imports the named features of the STL from.Thus, in a production version of the code, the clientcan choose to revert to the original STL to abandonconstraint checking in favour of maximising executionspeed.

The claim that the client code can remain unalteredneeds some clarification. Clearly, in order to moni-tor constraints, the client must supply definitions ofboolean functions that check the various assertions.However, it is not necessary to declare these in the classdeclarations: they are declared by the enhanced STL,and given default definitions. The client simply de-fines a specialisation of the required function, and thecompiler adopts it in preference to the default. Thus,

when reverting back to the original STL, these defi-nitions must be removed since the functions that theyspecialise are no longer declared. This can be achievedby conditional compilation – there is no need for actualediting.

The container types of the STL are enhancedin a namespace stdpp by deriving new classesfrom the existing containers. These new classescan appear to have the same names as the orig-inal ones (of course, in fact, the names are dif-ferent: for example, ::std::vector<T> and::stdpp::vector<T>). Loose coupling ensuresthat the algorithms work on the new containers. stdppcan be used as an alternative to the STL by any client.

The methods of the class can also be redefined insuch a way that they call the original methods, butcheck that the precondition is satisfied beforehand andthe postcondition is satisfied afterwards. The client hasthe option of supplying specific definitions of precon-ditions and postconditions in the form of partial spe-cialisations. Clearly granularity of control over whichchecks are employed can be introduced.

There are really two separate cases to consider.Firstly, there is the case of preconditions and postcon-ditions which are inherent to a container operation be-cause of the properties of the container. For example,it is an error to try to erase an element from an emptyvector, so there should be a precondition on erasingfrom a vector stating that the iterator parameter lies inthe range of iterators of the vector. Secondly, there arethe precondition and postconditions which are specificto the instantiation of an operation for a particular type.Both can be accommodated.

Once constraint monitoring is employed, the ques-tion is immediately raised of what action should betaken when a constraint is found to be violated. Thisissue is beyond the scope of this paper. The defaultchoice is to throw an exception.

4.3.1. Creating and using managersIn Config, the enhanced STL containers inherit the

original container and a generic class. This genericclass, CoManager<T>, provides the additional func-tionality required to create a type hierarchy which par-allels the existing type structure of an object. This isa more sophisticated (and resource-hungry) approachthan that described in the previous section. The typesub-structure of any object can be paralleled by a Man-ager structure which is automatically generated sim-ply by instantiation of a Manager object. The sub-Managers are generated recursively by calls in the Man-


Fig. 3. Atomic state editor.

ager constructors; constructors are written for each typeof container. These Managers creates a platform fromwhich a number of services can be administered. Mon-itoring constraints is just one of these services; othersare described below.

4.3.1.1. Editing structured types.Whether the useris permitted to enter values directly when editing astructured type, or whether the user must choose froma selection of pre-validated options, it is unlikely thatan instance of the type in its entirety will be changed. Itwill be a component of the type that is under scrutiny,such as using the Atomic State Editor to increment aPrincipalQuantumNumber (Fig. 3).

The scheme is that where appropriate Managersprovide an operation – constructValue() – thatchanges the value they manage. This change ispropagated throughout the Manager hierarchy bya call to constructValues(..). This callsconstructValue() for the local value, and passesthe call on to its parent. Disassembly and reassem-bly are modularised. The interface writer does nothave to consider how to provide an operation to updatethePrincipalQuantumNumberof a givenShellof a given ShellOccupancyRange of a givenShellList of a given AtomicConfiguration(and then repeat the process for OrbitalAngular-Momentum). The Manager writer encodes the as-sembly of an instance of the Managed type fromthe existing value and one amended component intoconstructValue(). This process of assembly prop-agates up the structure through the hierarchy of Man-agers.

The process of disassembly is undertaken by sup-plying the structure navigation information. The pro-cess of reassembly is undertaken by a single callto constructValues(..), which recurses up theManager hierarchy.

4.3.1.2. Edit operation sensitivity.Considering againFig. 3, it can be seen that some operations on the currentAtomicConfiguration are sensitive – availableto the user – and some are not. The button sensitivityreflects the constraints given in the specification: theuser is not permitted to create an invalid instance of anAtomicConfiguration.

The sensitivity of a given button in the editor at agiven time (i.e. in a given state) can be determinedby fully stating the precondition of the operation. Theprecondition states for which values of the domain ofthe operation the postcondition is guaranteed. An im-plicit part of any precondition or postcondition is thatthe class invariant holds after the operation. The com-plete class invariant of a container object is made upof the conjunction of the invariants of its elements andthe invariant specific to the container. When the ac-tion of the operation, and the desired postcondition areknown, mathematically determining the preconditionis a daunting task even in such a straightforward case.

A simpler approach is for the system to try the oper-ation beforehand and see if an invalid object results. Ofcourse, this is not an approach that can be adopted inall circumstances: ‘erase hard disc’, ‘fire missiles’ areexamples of operations where it would be undesirableto determine availability by this means. Clearly, it onlyworks for readily-reversible operations, or when it canbe performed on a harmless copy of the object in ques-tion. This is possible in Config, where the Managerstructure readily facilitates this.

4.3.1.3. Data display prototyping.One of the aims ofthe GRACE project, which has been ongoing for a num-ber of years, has been to provide a graphical user inter-face on UNIX workstations to computational physicssoftware running on supercomputers. MOTIF [31] waschosen from the outset for this purpose, and subse-quently it has become necessary to develop ways to useit with C++. Encapsulation of graphics elements intoreusable classes is dealt with by Young [32] amongstothers. The Manager and CoManager classes provide aplatform for developing data display prototypes whichinteract well with MOTIF.

The MOTIF specifics needed to display each typeof container class can be provided by classes such as


vectorDisplay<T> and pairDisplay<pair<T1, T2>>. These classes can be used to dis-play all types used within Config, although particu-lar requirements at times require special adaptationsto be written, such as that used to display largeConfigurationTrees.

5. Conclusions

The traditional approach to component design hasvery often been functional decomposition. However,this model is not always congruent with the systemunder consideration, and conceptual integrity is lost.The object-oriented approach proposes object-baseddecomposition, and argues in addition that this ap-proach will yield more stable units of reuse. Onemechanism for facilitating this structuring process isinheritance, and is an essential characteristic of object-orientation. A second mechanism, which is largely or-thogonal to the first, and is not restricted to object ori-ented languages, is genericity. An implementation lan-guage which provides both facilities offers the softwareengineer a very powerful structuring tool.

In order to take best advantage of these mechanisms,it is important to produce a precise statement of thenature of the component under consideration. Often,it takes bitter experience of the classic maxim, ‘imple-ment in haste, debug at leisure’ to convince softwarewriters of the benefits of investing in the early partsof the software design lifecycle. Basing design andimplementation on formal specification is an approachwhich is invaluable when striving to improve softwarequality. A criticism sometimes made of formal specifi-cation is that specifications tend to become out-of-dateand inconsistent with the implementation. However,we would argue that if the specification language is de-scribing the data types which reflect a physical realitythen these do not go out of date, and it is the implemen-tation alone that runs the risk of inconsistency. The useof design by contract can help to highlight wheneversuch an inconsistency is introduced.

This paper focuses on the benefits of using an imple-mentation language that supports generic expression.In the implementation phase, it is demonstrated thatgenericity enables the reuse of existing components.The STL provides both containers and algorithms thatpermit rapid implementation of precisely specified datatypes. Common functionality can be obtained ‘off theshelf’, enabling the implementor to concentrate on the

aspects that are specific to the particular problem do-main.

In addition to facilitating the reuse of existing com-ponents, genericity makes it possible for the implemen-tor to capture commonalities within the current compo-nent, and to create reusable components. The intentionmay be for reuse within the same component or it maybe wider afield.

The combination of VDM++ and C++ also permitspredicates specifying component behaviour to be statedin an abstract mathematical language, and then encodedinto checks that can be carried out at runtime. Thelikelihood of introducing errors during this encodingprocess can be minimised by constructing a library offunctions in C++ that mirror the language constructsof VDM++. It should be noted that these checks canpotentially be very expensive and are intended as adevelopment aid – they are not intended to be performedin production code (although preconditions in libraryroutines may optionally be validated if desired).

The powerful combination of inheritance and gener-icity provided by C++ make it possible to add a sub-stantial degree of support for design by contract. Inthe absence of formal proof, this technique minimisesthe gap between the formal specification statement andthe implementation. For whilst the data structures andthe basic operations that manipulate them are similarin a specification language such as VDM++ and ina generic library such as the C++ STL, the use of aformal specification language permits the expression ofproperties that cannot be obtained ‘off the shelf’. Thesemust be encoded algorithmically by the scientific pro-grammer; effort can be concentrated here because thebasic data structures have been provided. The formalspecification informs the design, the design directs theimplementation, and genericity makes it possible to addsupport for checking that the implementation does in-deed display the stated properties, adding to confidencein the quality of the product.

WebAppendices

http://www.stmarys-belfast.ac.uk/˜ d.maley/research/. . .I. config1.rtf; II. OrderedVector.doc;III. RSTable.doc; IV. F90Verbosity.doc.

References

[1] I. Sommerville, Software Engineering,(2nd ed.), Addison-Wesley, Wokingham, 1985.


[2] M. Jackson, System Development,Prentice-Hall, EaglewoodCliffs, 1983.

[3] D. Maley, I. Spence and P. Kilpatrick, Config: A GRACE toolfor constructing configuration trees. Computer Physics Com-munications Special Issue on continuum states of atoms andmolecules, Computer Physics Communications114 (1998),271–294, Elsevier, North Holland.

[4] Alexaner Stepanov (Silicon Graphics Inc.) and Meng Lee(Hewlett Packard Laboratories), The Standard Template Li-brary, 1995.

[5] B. Stroustrup, The C++ Programming Language, (3rd ed.),Addison Wesley, 1997.

[6] V.M. Burke, P.G. Burke and N.S. Scott, GRACE, ComputerPhysics Communications69 (1992), Elsevier, North Holland.

[7] Scott, Kilpatrick and Maley, The Formal Specification of Ab-stract Data Types and their Implementation in Fortran 90,Computer Physics Communications84 (1994), 201–225, El-sevier, North Holland.

[8] IFAD documentation, http://www.ifad.dk.[9] Cliff Jones, Systematic Software Development using VDM,

(2nd ed.), Prentice Hall, 1980.[10] Eugene J. Rollins and Jeannette M. Wing, Specifications as

search keys for software libraries, Proceedings of the Interna-tional Conference on Logic Programming,1991.

[11] Christophe Meudec, Automatic Generation of Software TestCases from Formal Specification, PhD thesis,Queen’s Uni-versity of Belfast, 1998.

[12] M. Holcombe, An Integrated methodology for the specifica-tion, verification and testing of systems, Journal of SoftwareTesting, Verification and Reliability3(3–4) (1993), 149–163.

[13] I. Hayes, Specification Directed Module Testing, IEEE Trans-actions on Software Engineering12(1) 124–133.

[14] L. Zucconi and K. Reed, Building Testable Software, SoftwareEngineering Notes,Sep. 1996, pp. 51–55.

[15] J. Bicarregui, J. Dick, B. Matthews and E. Woods, Making themost of formal specification through animation, testing andproof, Science of Computer Programming29 (1997), 53–78.

[16] J. Guttag and J.J. Horning, Larch: languages and tools forformal specification,Springer Verlag, 1993.

[17] C++ International Standard ISO/IEC 14882, Section 14.7.3,ANSI 1998.

[18] Alexander Stepanov, Interviewed by Al Stephens in Dr. Dobb’sJournal, 1995.

[19] Bertrand Meyer, Applying Design by Contract, Computer(IEEE) 25(10) (Oct. 1992), 40–51.

[20] Betrand Meyer, Object-Oriented Software Construction,(2nded.), Prentice Hall, 1997.

[21] Bennet P. Lientz and E. Burton Swanson, Software Mainte-nance Management: a Study of the Maintenance of ComputerApplication Software in 487 Data Processing Organisations,Addison Wesley, Reading (Mass.), 1980.

[22] J. Michael Spivey, The Z Notation: A Reference Manual,(2nded.), Prentice-Hall, Englewood Cliffs, NJ, 1992.

[23] Kevin Lano, Formal Object Oriented Development,SpringerVerlag, 1995.

[24] I.J. Hayes, C.B. Jones and J.E. Nicholls, Understanding thedifferences between VDM and Z: Technical Report UMCS-93-8-1,Department of Computer Science, Manchester University,1993.

[25] Gary T. Leavens and Yoonsik Cheon, Preliminary Design ofLarch/C++, in: Proceedings of the First International Work-shop on Larch,U. Martin and J.M. Wing, eds., Dedham,Springer Verlag, July 1992.

[26] Erich Gamma, Richard Helm, Ralph Johnson and John Vlis-sides, Design Patterns for Object Oriented Software,AddisonWesley, 1994.

[27] D. Maley, P.L. Kilpatrick, N.S. Scott, E.W. Schreiner andG.H.F. Diercksen, The Formal Specification of Abstract DataTypes and their Implementation in Fortran 90: Implementa-tion Issues Concerning the Use of Pointers, Computer PhysicsCommunications84 (1994), 201–225, Elsevier.

[28] Barbara H. Liskov and Jeannette M. Wing, A behavioral notionof subtyping, ACM Transactions on Programming Languagesand Systems16(6) (Nov. 1994, 1811–1841.

[29] David Maley and Ivor Spence, Supporting Design by Contractin C++ with Subtyping, Journal of Object-oriented Program-ming(2000), (to appear).

[30] David Maley and Ivor Spence, Emulating Design by Con-tract in C++, TOOLS-29 (Europe), Richard Mitchell, AlanCameron Wills, Jan Bosch and Bertrand Meyer, eds., pp. 66–75, IEEE, 1999.

[31] Marshall Brain, MOTIF – The Essentials and more,DigitalPress, 1992.

[32] Douglas Young, Object-Oriented Programming with C++and OSF/MOTIF,Prentice Hall, 1995.

Submit your manuscripts athttp://www.hindawi.com

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttp://www.hindawi.com

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation http://www.hindawi.com Volume 2014


Applied Computational Intelligence and Soft Computing

Advances in

Artificial Intelligence


Advances inSoftware EngineeringHindawi Publishing Corporationhttp://www.hindawi.com Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

http://www.hindawi.com Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling & Simulation in EngineeringHindawi Publishing Corporation http://www.hindawi.com Volume 2014

The Scientific World JournalHindawi Publishing Corporation http://www.hindawi.com Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in


Documents

Conﬁg: a case study in combining software engineering techniquesdownloads.hindawi.com/journals/sp/2000/401540.pdf · 2019. 8. 1. · 59 Conﬁg: a case study in combining software