Version Management for tightly integrated Software Engineering Environments

(1)

Environments

Sabine Sachwehand WilhelmSchafer

Universitat GH Paderb orn

Fachb ereich17 - Mathematik/Informatik

D-33095 Paderb orn

Germany

sachweh@uni-paderb orn.de

wilhelm@uni-pad erb orn .de

Abstract

Thepap erintro ducesaversionmanagementmo delwhichexploitsknowledgeab outthecontents

ofdo cuments. Thisisincontrasttomostexistingmo delswhichbasicallyconsiderversionedobjects

asat (attributed)les. Theb enets ofthe approachare illustrated by describing somesample

op erationswhicharenotp ossible withaconventional mo del. Thepap erthendiscussesafeasible

implementationofthemo delontopofan existingobject-orienteddatabasemanagementsystem.

Finally, it discusses related work and indicates how a sophisticated conguration management

systemisb eing builtontopoftheversionmanagementsystem.

1 Introduction

Theenormousincreaseinthesizeofsoftwareandthereliabilityrequiredfrommo dernsoftwareintensive

systems hasfo cussed attention onlanguages andcorresp onding to ols which donotonlysupp ort pro-

grammingbutalsosp ecication,design,anddo cumentationofsoftware. Infact,sp ecicationordesign

do cumentshave b ecomeequallyimp ortantas the nalco de inorderto check and verifycorrectness,

completeness andreliabilityofadelivered softwarepro duct. Inaddition,theindustrial-scale pro duc-

tion ofsoftwareto day requiresteamsofdevelop ers whoshould b e supp ortedbyto ols whichorganise

access to alargeamountofshared and frequently changinginformation. This informationconsists of

the ab ove mentioneddo cumentsforthevariousphases of thesoftwarepro duction pro cess. Examples

for such do cuments are data-ow diagrams, state-transition diagrams, p etri-nets, entity-relationship

diagrams,andmo dulardesigndescriptions.

To ols supp ort the syntactically and static semantically correct construction of do cuments which is

denoted as intra-document consistency. Atightlyintegrated softwareengineeringenvironment(SEE)

isacollectionofto olssupp ortingvariousphasesofthepro ductionpro cess. Itsmainadditionalfeature

compared with a to ol which supp orts the construction of a single do cument in a single language,

is the p ossibility to maintain so-called inter-document dependency and consistency. An example for

inter-do cument consistency is a name of a function which should b e the same in the requirements

sp ecication,intheinterfacedenitionofamo duleinthedesigndo cumentandintheimplementation.

The advantage of an SEE which maintainssuch ne-grained dep endencies b etween do cuments is its

supp ortofanincremental,intertwinedpro ductionandmaintenancepro cess (incontrasttoawaterfall-

or phase-oriented approach). Consider as an example the situation that a programmer may have

detectedanerrorintheco dewhichisduetoawrongrequirementssp ecicationofaparticularfunction.

If then the sp ecication is changed, the environmentcould informthe user ab out allother places in

all other do cuments which are aected by this change. It could even propagate achange trough all

do cumentsconcernedautomatically,iftheuser(s)requireit. Incontrast,doingsuchasmallincremental

(2)

onacomplete transformationofalldo cumentsconcerned fromone phase intothenextone. Formore

details we referto [ELN +

92].

Furthermore,anSEE shouldsupp ort changecontroland multipleusers. Thisrequiresasophisticated

versionandcongurationmanagementsystem(VM/CM).Although,SEEswhichmaintainne-grained

dep endenciesasmentionedab ove,arenowexisting[Lew88],mostavailableVM/CMmo delsstillassume

a very coarse-grained object mo del. Basically, versioned objects corresp ond to les whose particular

contents is not considered e.g. [Tic82, Fel88, BE87, ML88]. Such a coarse-grained version mo del

makesitimp ossibletopreserve inter-do cumentdep endencies andtocontrolchangepropagationonthe

ne-grained levelsketched ab ove. Illustratingexampleswillfollowinthenextsection.

Themainnewfeaturespresentedinthispap erare:

theconcept of aversion mo delwhich is tuned tone-grained inter-do cumentdep endencies and

corresp ondingchangecontrol

afeasibleapproachhowsuchaconceptisimplementedontopofanexistingcommerciallyavailable

fullyobject-orienteddatabase system.

The reminder of this pap er is organised as follows: The next section describ es and formalises our

underlying version mo del whereas section 3 gives an overview on the version op erations which are

availabletoauser. Thissectiontriestoclarifywhataretheb enetsofourmo del. Section4describ es

howsuchamo delisimplementedontopofanobject-orienteddatabasemanagementsystemandthus

providesevidencethattheapproachisfeasible. Section5dealswithrelatedworkandsection6sketches

ongoingwork.

2 The VM Model

TheVMMo delisdenedbyasystemversiongraph,whichisatwolevelgraphstructurewhichconsists

of the version level and the increment level. The objects (no des) on theversion level corresp ond to

do cumentversions,whereas theno desontheincrementlevelcorresp ondtothesyntactic constructsof

ado cumentversion,i.e. do cumentversions arerepresentedinternallybyabstractsyntax graphs. The

relations(edges)ontheversionlevelarerenedontheincrementlevelanalogouslytotheno des. Con-

sequently,theincrementlevelrepresentstherenementoftheversionlevel. Note,thatthegranularity

ofversioningisado cument,consequentlythetermversionisusedassynonymforadocument version

inthe following. Furthermore, theincrement levelis needed to preserve theconsistency of do cument

versions,whereas theversionlevelisusedas baseforcongurationmanagement.

2.1 Version Level

Theversionlevelcontainsadocumentversiongraphforeachdo cumentofthesystem,whichrepresents

the developmenthistory of this do cument. A do cumentversion graph consists ofno des which repre-

sentthedierentversions(andtheirrenementsas explainedinthefollowingsection)andasuccessor

relationwhich denes thedevelopmenthistory. A do cument version graph is singlero oted, since the

developmentofeach do cumentstartswithaninitialversionfromwhichallotherversionsofthisdo cu-

mentarederived,anditisacyclic,b ecause itrepresentsthedevelopmentstepsduring thepro duction

ofado cument.

Inter-do cument dep endencies, as sketched in the previous section, are expressed by further relations

whichconnect versions indierent do cumentversion graphs. We callthesource versionof arelation

depending versionandthetarget versiondetermining versionresp ectively. Basically,aversion can b e

adepending version andadetermining versionat the sametime. Forexample, adesignversionmay

(3)

do cumentdep endencies are distinguished,whicharethebasedon relationandthedepend onrelation,

as isillustratedingure1.

Agenda:

WindowStack .c Window

WindowStack

consistent_with relation Version1

successor_of relation Version1

depend_on relation version

based_on relation version graph/document

Version2

Version3

Version1

Version1.2 Version1.1

Version2 Version2

Version2.1 Version2.2

Version2.3

Figure 1: Anexample forthe versionlevelofa system version graph

Adepend onrelationdescrib es inter-do cumentdep endencies whicharedenedbyreferencingaversion

based on the contents of a version of another do cument. As an example assume that Window and

WindowStackareexcerptsfromasystemdesignwhichisgivenintermsofmo dulesanduse-relationships

b etweenmo duleswhicharedenedbyaMIL(Mo duleInterconnection Language). Inadditionassume

that the two mo dules have b een designed rather indep endently p ossibly by two dierent designer

(groups). WindowStackdep endsonWindowb ecauseitimp ortsresourcesdenedintheexp ortinterface

of window. Thus asystemdesignerhasto indicate explicitlywhichversion oftheWindowshould b e

used, as shown in gure 2. (Note that the exp ort interface of dierent versions of Window could

actually b e dierent.) Note that gure 2do es not showan extract of asystem version graph, but it

w:WINDOW);

Window (Version3) WindowStack (Version2.3)

PROCEDURE Pop(ws:WINDOWSTACK);

/* Removes element from stack ws. */

EXPORT INTERFACE

FUNCTION Create : WINDOWSTACK;

/* Creates a new window. */ TYPE WINDOWSTACK;

newy: INTEGER);

/* Moves window to new (newx,newy)-position.*/

FUNCTION Create : WINDOW;

PROCEDURE MoveTo (newx: INTEGER;

/* Shows window w on screen. */

PROCEDURE Hide(w:WINDOW);

/* Creates a new window stack. */

PROCEDURE Show (w:WINDOW);

TYPE WINDOW;

/* Hides window w from screen. */

Version1 Version2 Version3 Module Window Select Version of

/* Pushes windpw w on stack ws. */

EXPORT INTERFACE

PROCEDURE Push (ws:WINDOWSTACK);

MODULE WindowStack;

IMPORT INTERFACE

END IMPORT WINDOW, Create;

INTEGER;

MODULE Window;

IMPORT INTERFACE

END IMPORT INTEGER;

FROM Integer IMPORT: FROM Integer IMPORT:

FROM Window

depend_on relation

Figure2: Anexample for explicitreferencingunderversion control

gives an examplehowdependon relations of a systemversion graph can b e established ina textual

representation,i.e. howtheusersees them.

A basedon relation describ es that a text frame of the depending version was generated or up dated

based onthecorresp onding determiningversion,likeforexamplethegenerationofco de-framesbased

onadesign do cument. Changingthedep ending version meansto llinthegeneratedframe,i.e. the

generatedframeofthedepending versioncannotb echanged. Considerforexamplegure3thatshows

(4)

do cumentnamed WindowStack (Version2). For each imp ort-clausein the designversion an include

statementwasgeneratedandforeachexp ortedop eration,theinterfaceofthecorresp ondingc-function

wasgenerated. ThismeansalmostallincrementsofWindowStack.c(Version1)showninthisgureare

generatedexcept ofthoseenclosedinbrackets(<...>),i.e. onlythelatterincrementscanb eexpanded

inordertollintheframe. Theconsistencyb etweentheseversionsisensuredbypropagatingchanges

fromthedeterminingversiontothedependingversion. Again,analogouslytogure2gure3do esnot

w:WINDOW);

WindowStack (Version2)

WindowStack.c (Version1)

* Descript.:

* Parameter:

* Return: WINDOWSTACK

************************************************************/

*

* Function: Create

/*-ftn-******************************************************

* Parameter:

* Descript.:

************************************************************/

/*-ftn-******************************************************

*

* Function: Create

* Descript.:

*

************************************************************/

/*-module****************************************************

*

* Descript.:

* Author: <author>

* Date: <date>

* Changes:

* changed on by comment:

*

************************************************************/

* Parameter:

#include "Integer.h" ;

#include "WindowStack.h";

WINDOWSTACK

* Function: Create

* Module : WindowStack (DATATYPE MODULE)

<declaration_list>

<statement_list>

} /*-end-ftn-*/

/*-ftn-******************************************************

*

* Descript.:

* Function: Push

* Parameter: (o)ws: WINDOWSTACK

* (i)w: WINDOW PROCEDURE Push (ws:WINDOWSTACK);

/*-includes-*/

EXPORT INTERFACE TYPE WINDOWSTACK;

FROM Integer IMPORT:

INTEGER;

FROM Window IMPORT:

WINDOW, Create;

IMPORT INTERFACE

END IMPORT MODULE WindowStack;

{ Create()

based_on relation

<date> <name> <comm

/*-ftn-******************************************************

Figure 3: Anexample fora generationdep endency

showanexcerpt ofasystemversiongraph,but auser's viewontwoparticularversions.

A nal relation which is established on the version level is the consistent with relation. It describ es

that twoversionsareconsistent witheachother. Thisrelationwillformthebasisforacorresp onding

congurationmanagementmo del,i.e. congurationsareusuallybuiltbasedonconsistentversions.

Twoversionsv

1

(determiningversion)andv

2

(dep endingversion)areconsistentconcerningabasedon

or dependon relation, if for each incrementi

2 of v

2

that is determined by anincrement i

1 of v

1 the

followingequationholds: i

2

=i

1

. (Insteadoftakingtheidentityfunction(aschosen inthispap er) any

otherfunctionf canb eused, i.e. moregeneraltheequationtob e heldis: i

2

=f(i

1 ).)

Thebasedon relationandthedepend onrelationonlydescrib e dep endencies b etween versionsbut do

notdene whether or nottwoversions areconsistent. Rememb ertheexampleshown gure 2. Ifthe

exp orted typ e WINDOW inversion 3 ofdo cumentWindow is changed to SCROLLBAR-WINDOW,

version 2.3 of do cument WindowStack is still dep ending on this version of Window, b ecause of its

imp ort-clause. Butb othversionsarenotconsistentanylonger,since thetyp eWINDOWhasnotb een

changed intheimp ortpartofversionWindowStack sofar.

(5)

We havedistinguished dierent typ es of inter-do cumentdep endencies andcorresp onding relationson

theversionlevelbasedonhowthesourceandtargetversionsofthosedep endencies haveb eencreated.

Theedgesontheversionlevelhoweverdonotprovidetheinformationonthelevelofversioncontents,

e.g. thedepend onrelationandp ossiblytheconsistentwithrelationb etweenWindowStackandWindow

donotdescrib ethatthisdep endencyisinparticular,duetotheimp ortoftyp eWINDOWandfunction

Create.Therefore,itisnotp ossibletoidentifyonlybytheinformationwhichisprovidedbytheversion

level,that achange ofpro cedure Show or Hideresp ectively (e.g. extendingtheparameterlist)would

notviolatetheconsistency b etweenWindowand WindowStack.

Inordertoprovidethis missinginformation,versionno des,depend onrelationsandbasedonrelations

arerened ontheincrementlevel. A version isrepresented byitsabstract syntax graph(ASG). This

is expressed bya has contents relationb etween ano de onthe version leveland the ro otno de of the

abstractsyntaxgraphofitscorresp ondingversion. Similarlytono desthedependon,basedonandthe

successorof relationare renedonthe incrementlevel. Thoserelations startat no desof theASG of

the source version and end at corresp onding no des of theASG of the target version. Corresp onding

no desmeansthero otno desofthesyntacticconstructs(intheASG-representations)whichcorresp ond

to theconstructs intheversionsconcerned which have b eeneither identied explicitlybytheuser in

the case of a dependon relation (e.g. typ e WINDOW and pro cedure Create inFig. 2) or which are

dened by themappingb etween thelanguageof thedetermining and thelanguageofthe dep ending

versioninthecaseof abasedon relation(e.g. theIMPORTINTERFACEand theinclude commands

inFig. 3). Figure4showstheunderlyinggraph structure oftheexamplegiveningure 2. Note,that

thesuccessor of relationisrenedanalogously.

The onlyrelationoftheversionlevel,that is notrenedontheincrementlevelis theconsistent with

relation. Theconsistency concerning anexistinginter-do cumentdep endencyis checkedautomatically

bythe environmentusingthe ne-grainedbasedon or depend on relations, i.e. itis derivedfromthe

informationavailablethrough thelattertworelationsand thedenitionof aconsistentstate b etween

twoversions.

2.3 Formalisation of the Graph Model

Sofar,wehavedescrib ed informallyourversionmo delwhichbasicallycorresp ondstoatwo-levelgraph

structure. Thisgraph structure isnowformalisedwhich enablesto formallydene theconsistent, i.e.

practicallyreasonablestatesofaversiongraph.Thosedenitionsarethebasisfortheimplementationof

theVM-op erationswhichareexplainedinthenextsection,i.e. theycanb econsideredasthedenitions

oftheop erations'invariants(similarlyto thedenitionofinvariantsinalanguagelikeEIFFEL).

Asystemversiongraphconsistsoftwodisjointno desubsets, namelyVERandINC,whichrepresent

theno desoftheversionlevelandincrementlevelresp ectively. Analogously,thesetofedgesconsistsof

threedisjointsetsofedges,namelyVERREL,INC RELandVERINC REL,whereasVERREL

denotesamulti-setsincethedependonrelationaswellasthebasedonrelationmayb edenedb etween

thesameno desas theconsistentwith relation.

VERREL inturn consists ofsets which represent thedependon, basedon, successor of andconsis-

tent with relationoftheversionlevelandanalogouslyINC RELconsists ofsets which represent the

abstractsyntax, statsemantic, ne grained depend on, ne grained based on and ne grained succes-

sor ofrelationoftheincrementlevel:

VERREL=D EPEND O N[BASED O N[SUCCESSO R O F[

CO NSISTENT WITH.

VERVER

(6)

Version1

Version2

Version3

Version1

Version2

Version2.3 Version2.2 Version2.1

Module Name

ModWindow Stack

Name TypeWINDOW

STACK

Function

Function OpNameCreate

Using Type

WINDOW STACK

Import Interface

Import List Import

List Module

Imp Integer

Type Import^INTEGER

Module Imp Window

Type Import^WINDOW

Import Op Create

Module Name

ModWindow

Name Type WINDOW

Function

Using Type WINDOW OpNameCreate

Function OpNameShow

Using Type

meter

Para- Using

w Type WINDOW

Function

Function OpName MoveTo

Using

Function OpNameHide

Type

meter

Para- Using

w Type WINDOW

: fine grained depend_on relation : abstract_syntax and stat_semantic relation : successor_of relation

: has_contents relation

OpNamePush

OpNamePop

: depend_on relation

Figure4: Anexample fora systemversiongraph

INC REL= ABSTRACT SYNTAX [STAT SEMANTIC[REF D EPEND O N[

REF BASED O N[REF SUCCESSO R O F

. INCINC.

TheVERINC REL setcontainsalledgesofthetyp ehas contents, whichareedgesconnectingb oth

levels:

VERINC REL=HAS CO NTENTSVERINC

Firstorderlogicisusedtoformallydescrib ewhichrestrictionsholdforthecombinationofthoseedges,

i.e. theab ovementionedconsistentstatesofaversiongrapharedened. Wedonotgiveallrestrictions

here butrathersketchafewexamplestoillustrate thebasic idea.

In order to preserve the consistency of asystem, the environmentshould provide consistency preser-

vation ondemand. Thus, temp oraryinconsistencies areallowed,but theuser maycallafunctionfor

change propagation to make a depending version consistent with adetermining version. Inorder to

(7)

than one outgoing depend on or basedon relation to versions of the same do cument version graph.

ThismeansifO

v s

isdened asthesetofoutgoingdependonandbasedon edgesofaversionv

s ,

8v

s

2VER:O

v s

=f(v

s

;v

t )jv

t

2VER ^((v

s

;v

t

)2D EPEND O N_(v

s

;v

t

)2BASED O N)g

thefollowingconsistency conditionhastob e fullledbyeachversiongraph:

8(v

s

;v

t )2O

v s ::9v

t

0 2VER:(v

s

;v

t 0)2O

v s

^

(((v

t

;v

t

0)2(SUCCESSO R O F)

_(v

t 0;v

t

)2(SUCCESSO R O F)

)_

(9v

p

2VER:(v

p

;v

t

)2(SUCCESSO R O F)

^

(v

p

;v

t 0)

2(SUCCESSO R O F)

)))

Note, that(SUCCESSO R O F)

denotesthetransitiveclosureofSUCCESSO R O F.

The ab ove consistency conditionwillb e illustratedbythe followingexample. Assume that aversion

w:WINDOW);

(Version3.1)

(Version2.3)

(Version3.2) Window

WindowStack Window

Agenda:

IMPORT INTERFACE

END IMPORT

/* Creates a new window. */

newy: INTEGER);

INTEGER;

/* Moves window to new (newx,newy)-position.*/

EXPORT INTERFACE

MODULE Window;

TYPE WINDOW;

INTEGER;

IMPORT INTERFACE

END IMPORT

/* Creates a new window. */

WINDOW, Create;

/* Deletes window w. */

MODULE Window;

EXPORT INTERFACE TYPE WINDOW;

depend_on relation

fine grained depend_on relation

FROM Window IMPORT:

INTEGER;

TYPE WINDOWSTACK;

EXPORT INTERFACE

FUNCTION Delete (w: WINDOW);

MODULE WindowStack;

END IMPORT IMPORT INTERFACE

PROCEDURE Push (ws:WINDOWSTACK);

Figure 5: Fine-grainedinter-do cumentdep endencies

ofdo cumentWindowStackandtwoversionsofdo cumentWindowaregiven,wherebytheversions(3.1

and 3.2) of the latter do cument are variants.(Variants are versions which are memb ers of dierent