The Ragnarok Architectural Software Configuration Management Model
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
The
Ragnarok Architectural
Software Configuration Management Model
Henrik Bærbak Christensen
Department of Computer Science
University of Aarhus
DK-8000 Århus C, Denmark
hbc@daimi.aau.dk
Abstract design patterns, software architecture, etc. Still, many tradi-
tional software configuration management (SCM) systems
The architecture is the fundamental framework for de- [11, 7, 27, 24, 4] do not support the concept of software
signing and implementing large scale software, and the architecture directly. Software is viewed as ‘a set of files’
ability to trace and control its evolution is essential. How- and stable configurations are defined implicitly as sets of file
ever, many traditional software configuration management versions with a certain label or tag. This generates an un-
tools view ‘software’ merely as a set of files, not as an ar- fortunate impedance mismatch between the concepts used
chitecture. This introduces an unfortunate impedance mis- in design and implementation (architectural level) and in
match between the design domain (architecture level) and configuration management (file level.) Furthermore, sets of
configuration management domain (file level.) labelled file versions can not provide unambiguous informa-
This paper presents a software configuration manage- tion about the evolution of the architecture itself.
ment model that allows tight version control and configu- This paper outlines an architectural software configura-
ration management of the architecture of a software system. tion management model where the architecture is used as
Essential features of the model have been implemented in a basis for version and configuration control. Thereby, the
research prototype, Ragnarok. Two years of experience us- impedance mismatch is lessened, making the model more
ing Ragnarok in three, real, small- to medium sized, projects ‘natural’ for developers. The architectural SCM model
is reported. The conclusion is that the presented model is vi- places strong emphasis on traceability and reproducibility
able, feels ‘natural’ for developers, and provides good sup- of configurations and architectural changes.
port for handling an evolving architecture.
2. Architecture
1. Introduction
A sound, logical, software design is perhaps the most
The software architecture is the mental framework soft- important aspect in successful software development, and
ware designers and engineers use to design, discuss, doc- abstraction and hierarchy are key concepts in a good design.
ument, and reuse software systems. Here ‘architecture’ is An abstraction is seldom an isolated entity but must
used in the sense ‘the logical decomposition of a system be understood in its architectural context; abstractions are
into a collection of interrelated parts’ [18]. Software devel- organised hierarchically by composition (aggregation/part-
opment is a dynamic process and designers and developers whole), and interrelated by functional dependencies (asso-
must constantly modify and refine the architecture as new ciation/use) and possibly inheritance.
insight is gained. Consequently, an important aspect in the In object-oriented architectures, abstractions are typi-
development process is the ability to track and control the cally classes and class-categories [6]. Composition groups
evolution of the software architecture. classes (or class-categories) into class-categories, forming
In the early days of computing, a program was often a hierarchy, while dependencies relate classes functionally
contained within a single file and systems like SCCS [28] (e.g. that a window class uses a general-purpose rectangle
and RCS [29] provided adequate version control. Mod- class.)
ern software is vastly more complex and to handle it, more Abstractions require a physical manifestation, typically
and more emphasis is put on the underlying architecture— as source code fragments in some programming language.
a trend apparent within research fields like design methods, However, different languages use different storage schemes
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 1Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Model
for the source code. Integrated environments like Smalltalk
present only the logical level while the physical level is hid- 11
den. At the other extreme, the coupling in C++ is mostly
based on conventions.
Terrain
The architectural software configuration management Unit
model views the logical level as primary and the physical 7
9
level as secondary in the sense that source code fragments
are attributes of architectural entities. The central unit in
the model is the software component, which is an object
representing an abstraction. Software components are char- 5
acterised by a unique identity, CID, and a name. The actual
City
physical implementation of the abstraction, as well as its
relations (like composition and dependency) to other com-
ponents, are stored as attributes. This way, a software com- Figure 1: Version 11 of component Model
ponent is a flexible building block that may represent any
granularity in a system from a simple method to a full sys-
tem with a complicated substructure of components. game concepts. Figure 1 shows a milestone, Model ver-
sion 11. In the figure, the version group for a component
3. Versioning Model is depicted as a box with rounded corners containing the
component versions (small quadrants with the version num-
The evolving item is the software component and each bers inside) organised in a version graph. Solid lines going
state is represented by a software component version—in out of a component version represent composition relations,
essence reifying a version of an abstraction. dashed lines dependencies. So, Model version 11 is com-
posed of Terrain version 7, City version 5, and Unit ver-
3.1. Software Component Version sion 9—and City version 5 depends on (Unit, 9) and (Ter-
A software component version is an immutable snapshot rain, 7), and so on.
of the state of a software component and stored in a version
database. 3.2. Check-in
A software component version C is a tuple
(CID,VID,Ssub ,Srel ) For the architecture to evolve, developers modify copies
– CID is the component identity. of component versions in a workspace (modifying sub-
– VID is the version identity. stance and/or relations.) When the resulting changes meet
some criteria of completeness, they can be committed back
– Ssub is a set of software artifacts, defining substance.
to the version database through a check-in procedure.
– Srel is a set of references to other component version
tuples fref i (Ci ); : : : ; ref j (Cj )g, defining relations. The architectural model version controls the full archi-
indicates the type of relation as for instance ‘com- tectural context of a component by means of a transitive
position’, ‘functional dependency’, ‘inheritance’, etc. closure check-in algorithm. To check in a new version,
the algorithm recursively traverses all relation set refer-
The component versions for a given component are ar- ences, depth-first, and creates new versions of all compo-
ranged in a traditional version graph [30, 13]. nents along paths to modified components and updates the
An essential requirement of the model is that: relation set references accordingly.
Requirement 1 For each software component in the ver- Example: To illustrate a check-in, consider a situation
sion database, the elements in its relation set, Srel , must be where an inner class, Weapon, is added to class Unit. Af-
references to specific software component versions, which ter implementation and testing, a new version of Model is
are present in the version database. created in Fig. 2. The check-in is propagated to component
Weapon, it substance stored and a new version identity, 1,
Example: Consider a fictitious software team that is de- established. A reference to (Weapon, 1) of type ‘composi-
veloping a small strategy game. In the game, a player con- tion relation’ is added to the relation set of Unit, and a new
trols a region of land, comprising various cities, by means version 10 created. City lies on a path to a modified com-
of military units. The fundamental game model is imple- ponent and is thus checked-in with a reference to (Unit, 10)
mented in a class-category, Model, that is composed of and finally Model is checked-in. No new version of Terrain
classes Terrain, City, and Unit, modelling the fundamental is necessary, as it does not lie on a path to Weapon.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 2Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Model
3.6. Architectural Differences
11 12
An important consequence of the model is that the soft-
ware architecture itself is under strict version control. An
Terrain architectural diff algorithm can recursively compute differ-
Unit ences in the relation sets between two versions of a compo-
7
9 10
nent and report abstractions added, deleted, or moved, and
how relations have changed. This provides better overview
of architectural changes than the traditional list of file con-
tents differences. For instance, invoking the architectural
5 6 diff on Model version 11 and 12 (or e.g. City version 5
1
and 6) would report that a new component, Weapon, has
City
Weapon been added via a composition relation from Unit.
Figure 2: Version 12 of component Model 4. Architectural Evolution
Whereas major architectural changes may be the respon-
sibility of a small elite of chief designers, minor changes of-
3.3. Check-out
ten have to be made by subteams or individuals in their daily
The check-out trivially reverses the check-in process: work: Introducing new classes, rearranging the dependency
The root component version is checked out, then the check- structure, etc. When stabilised these new configurations has
out is propagated recursively to all component versions ref- to be made available for integration testing.
erenced in the relation sets. The architectural model both supports local introduction
of changes as well as later integration.
3.4. Consistency
4.1. Introduction of Change
As is evident from Fig. 1 and 2 the component versions
and their relationships can be viewed as a directed graph: Introducing changes in the architecture for a part of a
Component versions are nodes and relations are arcs. Thus, system is eased by the fact that the description of archi-
any component version is root in a directed graph that iden- tecture is distributed—relations are local attributes of the
tifies a bound configuration of the abstraction and its context components. Therefore, changes can be made by the sub-
of relations and related abstractions. team/individual with only local effect and without the po-
tential bottleneck of a global architectural description.
The graph interpretation allows us to express a con-
Example: Our game team decides to provide both sea
sistency requirement on the component versions in the
and land terrain in the game. The developer responsible
database:
for the Terrain class decides to model this by viewing the
terrain as a matrix of areas, each area being either water or
Requirement 2 For any given component version in the land. An inner class Matrix is introduced that depends on
version database, the bound configuration it defines cannot superclass Area and subclasses Water and Land. Figure 3
contain more than one version of the same component. shows a version of the new context of Terrain during this
work; dash-dotted lines indicate inheritance relations.
Other developers, working on classes Unit and City, are
If this requirement was not ensured, absurd situations not disturbed by the changes in Terrain because they work
could arise. For instance in Fig. 1 if (City, 5) depended with the stable class (Terrain, 7).
upon, say, (Unit, 8) then the configuration of Model would
refer to two different versions of class Unit.
4.2. Integration
Integration of architectural changes is performed by a
3.5. Versions equal Configurations
check-out. Consider the change made to the Terrain class
It follows from the transitive nature of the model that described above. When the developer has a version of the
the concepts ‘version’ and ‘bound configuration’ are uni- terrain class that is sufficiently stable for the rest of the team
fied. Even complex configurations are identified by a single to test, the only thing needed to be communicated is the
component version, like e.g. ‘Model version 11’ in Fig. 1. proper version identification, here version 9. The other team
Thus, configurations are first class objects and the evolution members can simply check-out Terrain version 9 and will
of configurations is trivially recorded and accessible. automatically get the new configuration including all newly
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 3Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Terrain Model
11 12
7 9
11.1
Matrix
Area Terrain
Unit
2 7
4 7.1 9 10
9.2
Water Land
2 5 6
3
5.2
1
City
Weapon
Figure 3: Class Terrain after restructuring to pro-
vide multiple terrain types
Figure 4: A variant, 11.1, of version 11 of compo-
nent Model
introduced classes, their internal relationships, and the code
fragments defining their substance.
only lightweight data is changed (basically a new version
The check-out thus becomes an ‘architectural merge’:
identification, VID, and a new relation set, Srel ), which con-
The changed architecture of component Terrain is merged
sumes very little storage. (In the prototype this amounts to
into the architecture of e.g. component Unit. Note that no
about 170 bytes although a verbose format is used.)
merge is performed on the source code level, only on the
architectural level.
4.3.2. Merging Usually, the bugfixes made in a main-
Working with stable versions and occasionally integrat-
tenance branch need to be introduced in the main develop-
ing with a new milestone version is a well-proven tech-
ment line as well. An automatic merge is often the heart of
nique. However many fast-paced, small team, development
such a reconcilement process.
projects work with a much faster integration cycle where
developers constantly integrate the newest code. A special In many traditional systems, a merge only extends to the
check-out has been provided in the prototype (section 5.) to file level building a new file version from two file versions
enable this working style. It recursively traverses a given with a common ancestor. In the architectural model the no-
configuration and checks-out the newest version on the cur- tion of merge must be extended to the architectural level as
rent branch of every component unless it is currently being well, i.e. it must handle added and/or deleted components
edited in the developer’s workspace. as well as changed relations.
The algorithm for merging is as follows: Consider two
versions Cr and Cd of a given component, CID. Cr is de-
4.3. Parallel development noted the receptor version, and Cd the donator version, as
Few development efforts proceed in a strictly linear fash- the donator can be viewed as a supplier of deltas that are
ion. The archetypical example of non-linear development is merged into the receptor forming a new, direct, version of
the case where a released system needs to be bugfixed at the the receptor. Both versions are root in a bound configura-
same time as development on the next release is in progress. tion, and the merged configuration is calculated recursively.
In this case, the release version becomes parent in the For each component, a merged version is created based on
version graph for both the bugfixed version(s) and the main- the receptor- and donator versions. The merged relation set
stream development version(s) i.e. a branch point. is a set union of the relation sets in receptor and donator,
constrained by requirement 2 (a component can only appear
4.3.1. Branching In keeping with the transitive nature in one version in a configuration.) Refer to the example
of the architectural model, branching is propagated through- below to see how this works in practice. To merge the sub-
out the configuration, i.e. similar branches are created stance, a merge technique must be used that understands the
within the version graphs of all components in the config- format of the source code fragments; like for instance tradi-
uration. This is exemplified in Fig. 4 where a variant of tional merge programs for textual source code. Our imple-
Model version 11 is shown. (To keep the figure small, the mentation also identifies situations where a merge can be
evolution of Terrain from Fig. 3 is left out.) avoided, namely in case receptor and donator versions have
This approach may sound expensive in terms of storage. identical substances and relation sets.
However, in most components the actual source code frag- Example: Figure 5 shows an example of how merge
ments are identical in the branch and in the main line. Thus, works in practice. Here variant 11.1 of Model is donator and
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 4Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Model
5.1. Projects
11 12 13
11.1 The first project, which has used RCM since March
1996, is ‘ConSys’ [17] . The ConSys team of three develop-
Terrain ers has been developing a Windows NT system, for control-
Unit ling accelerators, storage rings, and other large distributed
7
7.1 9 10 11 equipment in experimental physics. The system consists of
9.2
about 130 components and more than 1100 files. The source
code size is about 225.000 lines of C++ code.
The second project is the BETA compiler team, four
5 6 7
5.2
developers responsible for the development and mainte-
1
nance of the Mjølner BETA compiler [1, 5], a commercial
City
Weapon compiler for the strongly typed object oriented language
BETA [21]. The development is mainly done in the BETA
Figure 5: A merged version 13 of component language itself, however the run-time system is written in C.
Model from receptor version 12 and donator ver- The compiler has been under RCM control since February
sion 11.1 1997, and consists of 35 components containing about 250
files which amounts to about 120.000 lines of code.
The last project is the Ragnarok project itself. Ragnarok
merged back into the main development line, version 12. is about 40.000 lines of code, in about 160 files in 35 com-
Consider component Unit where the branched version 9.2 ponents.
has a single relation, a dependency to Terrain, but the recep-
tor has an additional composition relation to Weapon. The 5.2. Results
result is a union with both a dependency to Terrain and a
composition relation to Weapon. Considering Terrain, sub- Data has been collected from the projects mainly through
stances and relation sets are identical in receptor- and dona- guided, open-ended [26] interviews of the developers on the
tor versions, and thus a potential version 8 is avoided. BETA compiler and ConSys projects. A secondary source
It should be noted that any automatic merge has its limits. of data has been automatically generated usage logs from
A merge between two versions representing radically differ- RCM that have been analysed by simple statistical methods.
ent architectures will most likely be useless and invalid. The conclusion from both interviews and analysis of the
usage data is that the architectural software configuration
management approach is a viable one, at least for small- to
5. Prototype
medium sized projects.
The architectural model is implemented as a subsystem Some key points were made:
in the Ragnarok software development environment [9, 10]. Model ‘feels’ natural: The user groups readily accept the
This subsystem has been equipped with its own, textual, in- software component to represent design entities and claim
terface in a stand-alone software configuration management a close, if not one-to-one, mapping between their design
tool called RCM. RCM has been used for more than two and their software component structure. They ‘think’ SCM
years in three, small- to medium-sized, projects. in terms of components rather than files/directories. This
A number of design decisions had to be made to create a claim is supported by the usage logs data where file related
flexible prototype quickly, in order to evaluate the feasibility commands are seldom used.
of the model. Major decisions include: Focus on bound configurations: Bound configurations
are of course important for milestone- and release manage-
– The substance attribute implemented as a set of RCS-
ment but the developers more emphasised the feeling of ‘se-
controlled [29] files. The drawback is that fine-
curity’ in the daily development cycle as backtracking to
grained abstractions, like individual methods in a
working configurations was easy.
class, are infeasible in practice. However, a large
Traceable architectural evolution: To be able to trace
effort in implementing efficient delta storage was
how the architecture evolves was considered important.
avoided.
During the two year period, the ConSys project has more
– Copy scheme for workspaces like in CVS [4]. This
than tripled its size in terms of components and files, and the
scheme does not scale up, but, again, the implemen-
ability to make local changes to the architecture was consid-
tation is easy.
ered essential.
The RCM prototype is freely available and described on Intermediate versions: The teams were also asked if they
WWW [8]. found the intermediate versions created in components in-
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 5Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
directly modified (i.e. on a path to a modified component) about how it would be to program in a modular program-
annoying. They did not report this a problem; it was ‘the ming language that only offered an is-used-in relation.
job of the tool’ and handled adequately. The box construct in Gandalf [16], family in Adele [3],
and the configuration language PCL [31] also allow describ-
6. Discussion ing physical structure as attributes of the logical structure.
In contrast to our model, these focus on generic configura-
It should be noted that the model does not exclude the tions through rule-based selection [13] (Adele, PCL) or a
use of selection rules to make new configurations in a dynamically bound ‘standard’ version (Gandalf).
workspace, but rule-based selection plays a much lesser part The underlying version and configuration model in
than in many other software configuration management sys- COOP/Orm [22, 23, 25] and POEM [20, 19] share the tran-
tems. Generally, stable subconfigurations can be communi- sitive flavour of our model. Both systems are focused on
cated through their version identifications, which eliminates supporting fine-grained abstractions but are not used in real-
the need for rules to describe them. life projects. As such, we feel that our work complements
A question one may ask, is how to treat parallel work on and adds credibility to COOP/Orm and POEM by reporting
different components that have overlapping configurations; that architectural models are feasible in practice.
for example if City and Unit both depend on a library com-
ponent that both developers need to modify frequently. The 8. Future Work
general answer is that the branch/merge technique comes
into play (section 4.3.), but the experience from the projects Future research proceeds in a number of directions. A
is, that people avoid it. The prototype warns when devel- strong wish is to improve the current implementation to al-
opers want to edit a component version that will need to low larger projects to be handled. The current use of a copy
branch and they can cancel the action. Instead, they retrieve scheme for workspaces is a limitation in this respect, and a
the newest version before editing and avoid the branch. future version must implement a mechanism to share ver-
An important question is that of scale: Does this ap- sions and thereby reduce workspace storage requirements.
proach scale well to large software systems? We believe Another important topic is collaboration and a current
so and base our belief on the fact that human’s best tool to effort is to introduce specific support for cooperative ver-
handle complexity and size is the well-known paradigm of sions [15] that allows several teams/individuals to work in
‘divide-and-conquer’. So, if a ‘well-behaved’ architecture parallel on overlapping configurations. The branch/merge
can emerge with logical boundaries and low coupling, the mechanism will be used as the underlying technique but co-
architectural model should be sound as well. operative branches will be treated specially to emphasise
collaborative awareness and minimise the amount of ’pol-
7. Related Work lution’ of the version graph.
Finally, the current work has grown out of an object-
Many traditional SCM systems [11, 27, 12, 7, 24, 4] rely oriented software engineering context. An important exer-
on labels or tags for defining bound configurations: When cise is to evaluate and analyse the model in a broader ar-
creating, say a milestone, all file versions defining the mile- chitectural perspective, for instance to see if the model is
stone are tagged with a symbolic name. While tagged file suitable for other architectural styles [2]. Furthermore, the
version based systems are easy to understand, they suffer model has similarity to an architecture description language
from a number of conceptual problems. First, tagged file (ADL) and this aspect should be explored further. Relations
versions do not convey information about the evolution of are not first class objects in our model, in contrast to the
the software architecture itself. If you consider the many, connector concept in ADLs, and this increased power of ex-
radical, changes made in Terrain (Fig. 3), the tagging tech- pressiveness should be analysed in the context of software
nique can only account for the file versions used in the two configuration management.
configurations of Terrain. It cannot describe the changed
and newly formed relationships and components. Also, if a 9. Conclusion
given file version bears the tag for one release but not the
other, there are several valid causes: The file could either The architectural software configuration management
have been deleted or added between the two releases, or model takes the logical software architecture as its starting
maybe someone just forgot to tag it. Secondly, conceptually point and uses this structure to ‘drive’ the version- and con-
a tag is an is-used-in relation (stating that ‘this version of figuration control process. Thereby, developers can do SCM
this file is-used-in, say, release 4 of our system’)—however in terms of well-known concepts from the design domain.
developers more naturally think in terms of uses relations Fewer SCM specific concepts are introduced, basically only
like: Release 4 uses graphics library version 14, which uses the notion of ‘version’, resulting in easier learning. The em-
the window class version 22 etc. As an experiment think phasis on bound configurations has as a result that the con-
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 6Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
cepts ‘version’ and ‘bound configuration’ are unified, and [14] J. Estublier, editor. Software Configuration Management,
configurations become first class objects and are organised Lecture Notes in Computer Science 1005. ICSE SCM-4 and
historically. The emphasis also results in a feeling of se- SCM-5 Workshops, Springer Verlag, 1995.
curity in the daily development cycle as earlier, known-to- [15] J. Estublier and R. Casallas. Three Dimensional Versioning.
work, configurations can be easily be reestablished or com- In Estublier [14], pages 118–135.
pared to. Finally, the architecture itself is under tight version [16] A. N. Habermann and D. Notkin. Gandalf: Software De-
control as the full context of abstractions and their interre- velopment Environments. IEEE Transactions on Software
lations are stored during a check-in. Engineering, 12(12):1117–1127, dec 1986.
We generally find the results from using RCM in real [17] ISA. Consys. http://isals.dfi.aau.dk, 1996. ISA: Institute for
projects encouraging, especially seen in the light that the Storage Ring Facilities, University of Aarhus.
prototype is still rather crude. It is a stable, viable, tool for [18] D. A. Lamb. Introduction: Studies of Software Design.
configuration management, and provides good support for In D. A. Lamb, editor, Studies of Software Design, Lec-
controlling and tracing the evolution of the architecture of a ture Notes in Computer Science 1078. ICSE’93 Workshop,
software system. Springer Verlag, 1996.
[19] Y.-J. Lin and S. P. Reiss. Configuration Management in
References Terms of Modules. In Estublier [14].
[1] P. Andersen, L. Bak, S. Brandt, J. L. Knudsen, O. L. Mad- [20] Y.-J. Lin and S. P. Reiss. Configuration Management with
sen, K. J. Møller, C. Nørgaard, and E. Sandvad. The Mjølner Logical Structures. In Proceedings of the 18th International
BETA System. In Object-Oriented Environments - The Conference on Software Engineering, pages 298–307. IEEE
Mjølner Approach, pages 24–35. Prentice-Hall, 93. Computer Society Press, 1996.
[2] L. Bass, P. Clements, and R. Kazman. Software Architecture [21] O. L. Madsen, B. Møller-Pedersen, and K. Nygaard. Object-
in Practice. Addison-Wesley, 1998. Oriented Programming in the BETA Programming Lan-
guage. Addison Wesley, 1993.
[3] N. Belkhatir and J. Estublier. Experience with a Database of
Programs. In Proceedings of the ACM SIGSOFT/SIGPLAN [22] B. Magnusson and U. Asklund. Fine Grained Version Con-
Software Engineering Symposium on Practical Software De- trol of Configurations in COOP/Orm. In I. Sommerville,
velopment Environments, volume 22, pages 84–91, jan 1987. editor, Software Configuration Management, Lecture Notes
in Computer Science 1167, pages 31–48. ICSE’96 SCM-6
[4] B. Berliner. CVS II: Parallelizing Software Development. In Workshop, Springer Verlag, 1996.
USENIX, Washington D.C., 1990.
[5] http://www.daimi.aau.dk/ beta/.
[23] B. Magnusson, U. Asklund, and S. Minör. Fine Grained Re-
vision Control for Collaborative Software Development. In
[6] G. Booch. Object Oriented Design. The Ben- ACM SIGSOFT’93 - Symposium on the Foundations of Soft-
jamin/Cummings Publishing Company, Inc., 1991. ware Engineering, Los Angeles, California, Dec. 1993.
[7] PLATINUM CCC/Harvest Users Guide. [24] Microsoft (R) Corporation: Visual SourceSafe.
[8] H. B. Christensen. RCM Reference Guide. Depart- http://www.microsoft.com/ssafe/.
ment of Computer Science, University of Aarhus, 1998. [25] S. Minör and B. Magnusson. A model for Semi-
http://www.daimi.aau.dk/ hbc/Ragnarok/rcm quickref.html. (a)Synchronous Collaborative Editing. In Proceedings of
[9] H. B. Christensen. The Ragnarok Software Development En- Third European Conference on Computer-Supported Coop-
vironment. In K. A. Mughal and A. L. Opdahl, editors, Pro- erative Work - ECSCW’93, Milano, Italy, 1993. Kluwer Aca-
ceedings of NWPER’98, Nordic Workshop on Programming demic Press.
Environment Research, Bergen, June 1998. Department of [26] M. Q. Patton. Qualitative Evaluation Methods. Sage Publi-
Information Science, University of Bergen. cations, Beverly Hills, Calif., 1980.
[10] H. B. Christensen. Utilising a Geographic Space Metaphor [27] http://www.intersolv.com/products/pvcs-vm.htm.
in a Software Development Environment. In Proceedings [28] M. J. Rochkind. The Source Code Control System. IEEE
of EHCI’98, IFIP Working Conference on Engineering for Transactions on Software Engineering, 1(4), 1975.
Human-Computer Interaction, Crete, Greece, Sept. 1998.
Chapman and Hall. [29] W. F. Tichy. RCS – A System for Version Control. Software
– Practice & Experience, 15(7):637–654, July 1985.
[11] http://www.rational.com/products/clearcase/.
[30] W. F. Tichy. Tools for Software Configuration Management.
[12] Pc-based version control.
http://www.silcom.com/ alobba/pc vc.html.
In J. F. H. Winkler, editor, Proceedings of the International
Workshop on Software Version and Configuration Control.
[13] R. Conradi and B. Westfechtel. Towards a Uniform Version B. G. Teubner, Stuttgart, Jan. 1988.
Model for Software Configuration Management. In R. Con- [31] E. Tryggeseth, B. Gulla, and R. Conradi. Modelling Sys-
radi, editor, Software Configuration Management, Lecture tems with Variability using the PROTEUS Configuration
Notes in Computer Science 1235. ICSE’97 SCM-7 Work- Language. In Estublier [14].
shop, Springer Verlag, 1997.
0-7695-0001-3/99 $10.00 (c) 1999 IEEE 7You can also read
