collaborative software engineering: an annotated bibliography
TRANSCRIPT
Collaborative Software Engineering:
An Annotated Bibliography
Carl Cook
Technial Report TR-02/04 (Revision 0.2), May 2005(First published June 2004)
Software Engineering & Visualisation Group,Department of Computer Science and Software Engineering,
University of Canterbury, Private Bag 4800,Christchurch, New Zealand
The contents of this work reflect the views of the authorswho are responsible for the facts and accuracy of the datapresented. Responsibility for the application of the ma-terial to specific cases, however, lies with any user of thereport and no responsibility in such cases will be attributedto the author or to the University of Canterbury.
This technical report contains a research paper, devel-opment report, or tutorial article which has been submittedfor publication in a journal or for consideration by the com-missioning organisation. We ask you to respect the currentand future owner of the copyright by keeping copying of thisarticle to the essential minimum. Any requests for furthercopies should be sent to the author.
Abstract
This work is intended to be a useful starting point for those researching the field ofCollaborative Software Engineering (Cse). We list research articles related to current Csetools, models and discussions, as well as relevant papers in related fields. This paper does notpresent a taxonomy of CSE research, rather it is simply a categorised, annotated listing ofarticles that are likely to be of use to Cse researchers during their preliminary investigations.
Please note:
• This bibliography is periodically updated to incorporate new or overlooked papers relatedto Collaborative Software Engineering. If you would like to nominate a paper for inclusionwithin this bibliography, please contact the author.
2
Contents
1 Introduction 41.1 What is Collaborative Software Engineering? . . . . . . . . . . . . . . . . . . . . . 41.2 Purpose of this Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Existing Cse Tools 52.1 Management Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Design Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Development tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Inspection Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Discussion Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Fields Related to Cse Research 163.1 Software Engineering Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1 Classical Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.2 Object Oriented Methodologies . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.3 Agile Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.4 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Groupware and Cscw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.1 General Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.2 Programmable Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.3 Desktop Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.4 Constructed Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2.5 Limitations of CSCW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Source Code Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Human Computer Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.5 Distributed Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6 Software Engineering Metrics and Visualisation . . . . . . . . . . . . . . . . . . . . 38
4 Concluding Remarks 404.1 Future Directions for CSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Author Index 42
3
1 Introduction
Collaborative software engineering (Cse) is afast growing area of Computer Science. WhileCse has been researched in detail for decades,the discipline also draws on many other relatedareas of Computer Science, each with their owndedicated area of research activity. There aremany exhaustive surveys on these related areas;this bibliography presents selected papers fromthese related areas that are pertinent to Cse,as well as listing papers core to Cse frameworksand tools. This bibliography presents a cate-gorised listing of all such papers, accompaniedby annotations that describe the content of thepapers and their relevance to the field of Cse.
1.1 What is Collaborative Soft-ware Engineering?
Almost all modern software engineeringmethodologies involve several distinct groupsof people working on many artifacts with differ-ent types of tools to produce multiple versions ofsoftware products. Software engineering is un-avoidably collaborative, and Cse looks at waysof lending computer-based support for program-mer and tool communication, management ofartifacts, and coordination of tasks.
Research into Cse is progressing rapidly.Driving factors include the advent of industrialstrength open source IDEs, a solidification ofstandards for distributed computing, significantadvances in processing speeds and memory ca-pacities, and more powerful, interoperable pro-gramming languages. Reliable high-speed net-working reduces the boundaries between remotedevelopers, programming frameworks such as.Net and J2EE provide inexpensive access torich information related to any given softwareproject, and new collaborative features can beincorporated into IDEs through open APIs.
Despite these recent technological advances,it is unlikely that one monolithic system will bedeveloped that solves all the current challengesin supporting Cse. Instead, specific tools havebeen designed to support specific software en-gineering tasks or to provide specific collabora-tive enhancements over conventional tools, andthis is likely to be the direction that Cse re-search follows for some time to come. Given theneed to provide more collaborative support tosoftware engineers than what is currently avail-able through conventional development tools,
the minimum list of considerations is:
Location Are the developers in a face-to-faceand constantly co-located setting, or arethey distributed throughout several de-partments or organisations?
Time Will developers typically work at thesame time, different times, or a combina-tion of both possibilities?
Task type What type of software engineer-ing tasks are to be supported? Typicaltasks likely to be supported in CASE toolsinclude requirements gathering, analysis,system design, implementation, validationand verification.
Task complexity What is the level of com-plexity for the typical task? Are thirdparty components used? Is legacy codeemployed? Is there extensive use of exter-nal libraries? What is the size of the typ-ical task in terms of files, classes/modulesand lines of code?
Task process Which development methodolo-gies should be supported? Classicalclosed-source SDLC? eXtreme Program-ming? Open source development (wherethere are often no time pressures, mini-mal documentation and heavy moderationof changes)?
Artifact management How are artifacts con-trolled? Is a pessimistic locking schemeemployed, an optimistic locking scheme,or is realtime artifact sharing possible? Ifso, what floor control policies are in placeto manage collaboration?
Group size What number of people are likelyto be supported? What is the maximumnumber of people likely to be workingclosely together on the same subset of ar-tifacts within the project?
Group culture What are the ability levels ofeach developer? Should a mix of abilitiesbe supported? Does a culture exist withinthe team where certain informal processesare likely to be followed, such as postingcode update notifications to a mailing list?
Extensibility Should the tool support extensi-bility/customisation, different languages,and/or different views of the same arti-fact?
4
Implementation How should the tool mon-itor developer activity and analyse pro-gram changes?
Usability How should the tool deliver feedbackto the user? Will such feedback be em-braced by the user or seen as a hindrance?
After considering the above points, it is ap-parent that for a successful implementation ofCse tools, a knowledge of several related disci-plines of Computer Science is required. Whilstan understanding of all aspects of software en-gineering is compulsory, other topics that mustbe addressed are human factors and usability,software configuration management, distributedsystems, groupware and computer-supportedcollaborative work, and software visualation. Aspresented in the following figure, Cse forms anintersection of these six areas. After presentingthe literature directly relevant to Cse, this bib-liography will discuss each of these related areasin turn.
1.2 Purpose of this Document
This article is intended to be used as an intro-duction to Cse, Cse tools and related fields. Itprovides most of the main research articles re-lated to Cse, and many other useful related pa-pers can be found from these key articles. Themain thrust of this article is to provide a usefulteaching and learning resource for initial inves-tigations into Cse.
This article does not present a major tax-onomy of Cse research, nor does it attempt toclassify Cse literature in a new or novel way.It is purely a bibliographic listing of important
work classified into subcategories of Cse and re-lated fields, with supporting annotations.
2 Existing Cse Tools
Software engineering encompasses a wide rangeof tasks ranging from requirements outliningto code debugging, and researchers have devel-oped prototype Cse tools for each conceivabletask. Subsequently, many developmental Csetools and frameworks exist today, and supportfor real-time collaborative operation is becom-ing commonplace within this class of tools. Atthe time of writing, a handful of commercial Csetools also exist for relatively simple software en-gineering tasks, and the research world is con-stantly publishing new and novel architectures,tools and perspectives on collaborative softwareengineering.
This bibliography classifies the literature onCse tools and frameworks into five sections:management tools, design tools, developmenttools, inspection tools and discussion papers.For each section, an overview of the researcharea is presented, followed by a listing of keyresearch articles.
2.1 Management Tools
The main objective of management tools is tosupport the organisation of software engineer-ing workspaces. Such tools might allow the in-dexing and searching of source code and otherartifacts but typically will not support directediting of files, shared or otherwise. Manage-ment tools typically do not support design ormodelling concepts within software engineering;rather their principle concern is the manage-ment of users and artifacts within a softwareengineering project. Management tools of thesetypes are used to keep track of large artifactbases, groups of engineers, and interactions be-tween artifacts and engineers.
Publications
[1] Pauline Wilcox, Craig Russell, Mike Smith,Alan Smith, Rob Pooley, Lachlan MacK-innon, Rick Dewar, and David Weiss.A CORBA-oriented approach to hetero-geneous tool integration; OPHELIA. InESEC/FSE Workshop on Tool-Integrationin System Development, pages 1–5. Helsinki,Finland, 2003.
5
Annotation: This paper describesOPHELIA, a framework to integrate hetero-geneous software engineering tools. Severalpapers have been published that describethe large research effort of OPHELIA, butthis relatively short paper suitably coversthe main aspects. The main thrust of the pa-per, in describing the framework, is to claimthat many insights will be discovered by theongoing work of integrating standalone toolsinto collaborative environments.
As described in this paper, the OPHE-LIA architecture creates global views of ar-tifacts, and allows relationships to be definedbetween any project elements via a compo-nent called Traceplough. Additionally, eventdriven metrics are also supported, with up-dates broadcasted to all relevant listeners.In this paper, the OPHELIA architecture isillustrated by a brief example of integrat-ing the ArgoUML tool, however very littleis written about the benefits this provides.
[2] J. Altmann and R. Weinreich. An Envi-ronment for Cooperative Software Develop-ment: Realization and Implications. In Pro-ceedings of the Hawaii International Con-ference On System Sciences. Kona, Hawaii,January 1997.
Annotation: This paper describes an ar-chitecture for collaborative software engi-neering where the emphasis is focused onminimising the number of constraints placedon the users of the system. As describedwithin, two main components exist to facili-tate distributed annotation of source code,bug tracking, and scheduling of tasks: aworkspace manager and a cooperation man-ager. Many screenshots are presented toillustrate the system, and excellent back-ground and architectural description sec-tions are given, with compelling and usefulreferences.
Unfortunately, no mention of systemevaluations are made, either qualitative orquantitative. Whilst the architecture pre-sented is very compressive system with richuser interfaces for communication and co-ordination, the question on whether or notit is genuinely usable remains unanswered.Regardless, this is a valuable article due tothe comprehensive discussion of the archi-tecture’s construction.
[3] Stephen E. Dossick and Gail E. Kaiser.CHIME: A Metadata-Based DistributedSoftware Development Environment. InProceedings of the 7th European Engineer-ing Conference held jointly with the 7thACM SIGSOFT International Symposiumon Foundations of Software Engineering,pages 464–475. Springer-Verlag, 1999. ISBN3-540-66538-2.
Annotation: CHIME, as presented inthis paper, is a metadata-based virtual envi-ronment for visualising and managing arte-facts within a software engineering project.Artifacts are held within their original repos-itories, such as source code control systems,databases, and bug-tracking tools; CHIMEis used as a navigation tool amongst theseartifacts via generated virtual environments.Whilst leaving the artifacts in their originat-ing repositories, CHIME manages the stor-age of annotations and chat sessions heldbetween users. CHIME supports collabora-tion by displaying the avatar of users withinthe virtual world; once two or more avatarsare inspecting artifacts within the same loca-tion, a collaborative chat session is enabled.
The CHIME architecture is interesting inits separation of spaces and views; the archi-tecture is well defined and described withinthis document. This paper presents collab-orative software engineering research fromboth the fields of development and visual-isation; accordingly it is useful as a surveypaper as well. A major drawback of this pa-per is the absence of visualisation examples,which is a central theme to this researchproject.
[4] Ian Gorton, Igor Hawryszkiewycz, KennyRagoonaden, Charles Chung, and Shijian LuGuneet. Groupware Support Tools for Col-laborative Software Engineering. In Proceed-ings of the 30th Hawaii International Con-ference on System Sciences, volume 2, pages157–166. Maui, Hawaii, January 1997.
Annotation: This paper introduces anenvironment for the development and testingof software within highly distributed teams.The system, named GWSE, is based uponLotus Notes because of the access to a flexi-ble data repository. GWSE has facilities forconfiguration management and project man-agement; these facilities are demonstratedin detail with the assistance of numerous
6
screenshots and discussions.This paper also introduces the concept of
‘Gain Effect Exploitation’, where the hourslost due to incomplete deliverables were cal-culated in a field trial. This is interesting asit illustrates some of the issued related tothe isolation caused by traditional softwareengineering tools. The paper could benefitfrom having more references to support thestated requirements of the architecture, butit is still a very informative paper that de-scribes one approach for the management oflarge distributed groups of developers.
2.2 Design Tools
Design tools within the field of Cse have some orall focus on supporting collaboration during thedesign of software engineering artifacts. Toolswithin this category typically support the designof relatively simple and low-detailed artifactssuch as class diagrams and Class-Responsibility-Collaborators (CRC) diagrams. Other UML-based diagrams such as state transition dia-grams and use-case diagrams appear too com-plex to be supported by Cse tools, although afew commercial implementations of such toolshave been recently released, such as Poseidon forUML Enterprise Edition. Cse design tools alsoappear to focus more on workflow, communi-cation and coordination rather than on artifactdevelopment and progression to implementationartifacts such as source code.
Publications
[1] Hurwitz Report. Collaborative UML Devel-opment. White Paper, CanyonBlue Incorpo-rated, November 2001. URL http://www.canyonblue.com/whitepapers.htm.
Annotation: Konesa, initially known asCittera, is presented in this white paperas the first UML tool to support real-timecollaborative modeling. There are no pub-lished refereed papers that describe Konesa,but the tool’s website is a useful sourceof reference information that may not havebeen covered within this white paper. Asdescribed in this paper, Konesa supportsuser communication via chat and sharedwhiteboard facilities. Additionally, a bulletinboard service stores all user correspondenceand changes to the model; these events canbe searched as a form of model inspection.
Konesa also supports change-tracking toprovide graphical representations of changesover time per user. Finally, Konesa also hasthe concept of module ownership; ownerscan review changes before accepting or re-jecting them.
This white paper also provides a qual-ity discussion about the evolution of soft-ware engineering from stand-alone singleuser projects to real-time collaborative dis-tributed development of large-scale systems.Unfortunately, the white paper only givesa brief outline of the features of Konesa—without any serious attention to providingproof of concepts or literature-based sup-port. Additionally, there are no publishedpapers with further information relating toKonesa as of yet. Finally, and whilst notmentioned in this white paper, the organi-sation that develops Konesa is part of theEclipse consortium, and develops propri-etary Konesa plugins for the Eclipse frame-work. For a description of Eclipse, please seeSection 3.1.4 on page 20.
[2] Marko Boger, Thorsten Sturm, Erich Schild-hauer, and Elizabeth Graham. Poseidonfor UML User Guide. Gentleware AG,2002. URL http://www.gentleware.com/support/documentation.php4.
Annotation: Poseidon is a commer-cial version of the ArgoUML modelingtool. The research related to ArgoUML iswell published—please see Section 3.1.4 onpage 20. There are no formally refereed pa-pers on Poseidon, however many have beenpublished that cite the product. Apart frombeing one of the most popular UML model-ing tools in current practice, the enterpriseedition of Poseidon has been designed for usein highly collaborative environments.
This paper represents the user guide forPoseidon, providing a solid overview of thesystem’s architecture and plugin infrastruc-ture. The Poseidon website provides furtherinformation relating specifically to the en-terprise edition’s collaborative features, in-cluding Jabber-based instant messaging andcoarse-grain version control.
[3] Nicholas Graham, Hugh Stewart, AuthurRyman, Reza Kopaee, and Rittu Rasouli. AWorld-Wide-Web Architecture for Collabo-rative Software Design. In Software Technol-
7
ogy and Engineering Practice, pages 22–32.Pittsburgh, Pennsylvania, August 1999.
Annotation: Rosetta is a light-weighttool for web-based collaborative develop-ment of UML design diagrams. This pa-per introduces the Rosetta architecture, de-scribes the types of documents that can bedeveloped using Rosetta, and then explainshow the architecture supports collaborativedevelopment. The paper also gives details onevaluation of Rosetta, and discusses some ofthe experiences in using the Internet as theplatform for all Rosetta-based applications.
This is a well written paper that de-scribes an architecture currently being usedwithin a commercial environment. This pa-per gives insights related to the design anddeployment of a simple yet useful collabo-rative and distributed software engineeringtool. This paper also provides many use-ful references in the introduction and back-ground sections relating to the need for suchtools, and the problems pertaining to dis-tributed collaboration.
[4] Neville Churcher and Carl Cerecke.GroupCRC: Exploring CSCW Supportfor Software Engineering. In Proceed-ings of the 4th Australasian Conferenceon Computer-Human Interaction. IEEEComputer Society Press, Hamilton, NewZealand, November 1996.
Annotation: This paper describesGroupCRC, a multiuser implementation ofa tool to facilitate the Class, Responsibility,Collaborator (CRC) object oriented analysistechnique. The purpose of this paper is todemonstrate how CSCW technologies sup-port and enhance the ability of groups toaccomplish shared goals. For the unfamiliar,the paper also provides a useful descriptionof the CRC process.
The paper describes the roles of CASEtools, the roles of CSCW applications, andthen illustrates why the two types of systemshave different priorities. The main researcheffort of this paper is to demonstrate howenhanced collaboration and maintainance ofdocument structures can be achieved simul-taneously.
[5] Josef Altmann and Gustav Pomberger. Co-operative Software Development: Concepts,Model and Tools. In Proceedings of the
30th Conference on Technology of Object-Oriented Languages and Systems, pages194–209. California, USA, August 1999.
Annotation: This paper introduces amodel for the organisational support of col-laborative software engineering. A solid dis-cussion of the role of collaboration is pro-vided, and an interesting model to map thedomain of software engineering is proposed,based on collaboration, coordination, andcommunication. The model supports twomain views: processes and products; thepaper then presents a rather comprehensivesuit of tools in support of the model.
This paper is six years old now, and nofollow-up systems or evaluations have beenpublished to our knowledge. Rather strongclaims for improved productivity and qual-ity are also made, but no specific goals de-fined. There are also no specific referencesto planned user evaluations—yet such eval-uations are surely essential due to the expan-sive user interfaces and system interactions.
2.3 Development tools
The task of designing and implementing suc-cessful Cse development tools is difficult; notonly is a knowledge of collaborative software en-gineering required, but the implementors mustalso be able to program concurrent distributedsystems and be competent of designing complexyet usable user interfaces. Subsequently, thereare many prototype Cse development tools butthey are typically designed for only a single taskor programming language. Such developmenttools are also quite trivial when compared tocommercial-scale IDEs, therefore, Cse develop-ment tools still have a significant advance tomake before they will have a serious impacton mainstream software engineering. Similarly,there are very few frameworks that allow therapid development and extension of Cse toolsand the migration of single user tools to beingcollaborative. Instead, the majority of Cse re-search activity appears to be based around thedevelopment of ‘throw-away’ prototype tools.
There are many tools available which sup-port real-time modelling, design and manage-ment of software. Development tools, however,are typically based upon conventional softwareengineering tools and technologies: as develop-ers check in or check out source code from a cen-
8
tral repository, users are alerted to possible con-flicts. Only a few real-time editing and diagram-ming tools exist where the conventional modelof copy-modify-merge is replaced with fully syn-chronous file sharing.
Publications
[1] Uwe M. Borghoff and Gunnar Teege. Appli-cation of Collaborative Editing to Software-Engineering. In SIGSOFT Software En-gineering Notes, volume 18, pages 56–64.ACM, July 1993.
Annotation: This paper presents IRIS,a collaborative editor for software engineer-ing artifacts. Written ten years ago, thisis another paper where the importance isfor its historical contribution to the field ofcollaborative software engineering, ratherthan the relevance of IRIS today. IRIS, asdescribed within the paper, is a collabora-tive system for the editing and managementof well structured documents, specificallysource code. Collaborative features includedynamic voting and notification of changesto all current users, and IRIS uses a repli-cated data architecture to allow concurrentediting of artifacts.
This paper provides a good survey ofsimilar systems at the time of writing, andpresents a very detailed and informative de-scription of the IRIS architecture. Unfortu-nately, the paper lacks a discussion of anevaluation of the system, justifications ofdesign choices, and illustratory examples.However, since IRIS was one of the firstcollaborative tools for software engineering,this paper is still essential reading.
[2] Prasun Dewan and John Riedl. TowardComputer-Supported Concurrent SoftwareEngineering. IEEE Computer, 26(1):17–27,1993.
Annotation: This is an early paperwithin the field of collaborative software en-gineering, but it is still very relevant andinformative today. The references through-out the paper are of well respected publica-tions, therefore the paper in itself is a goodsurvey. The paper was well cited the yearfollowing publication, but perhaps surpris-ingly, it has not received much attentionsince then.
FLECSE is an architecture comprised
of a collection of multiuser tools: edi-tors, inspection tools, code repositories,and debuggers. The architecture also pro-vides multimedia support. As well as de-scribing the FLECSE architecture, a gooddefinition of collaborative software engi-neering is provided, which includes the keyconcepts of tools, concepts, life cycles, in-tegration, and sharing. An observation ad-mitted by the authors is that this paperlacks arguments to support why the pro-posed tools are genuinely useful. This paperis still very useful however, and as the au-thors state, it should give readers an ideaof the benefits that collaborative technol-ogy can bring to software engineering.
[3] Carl Cook and Neville Churcher. An Ex-tensible Framework for Collaborative Soft-ware Engineering. In Deeber Azada, editor,Proceedings of the Tenth Asia-Pacific Soft-ware Engineering Conference, pages 290–299. IEEE Computer Society, Chiang Mai,Thailand, December 2003.
Annotation: This is a self-citation tothe paper that describes the CAISE collab-orative software architecture. As describedin this paper, CAISE is an extensible ar-chitecture that supports the integration ofsoftware engineering tools. The storage andsynchronous sharing of software artifacts ismanaged by CAISE, and changes to arti-facts by client tools update the underlyingmodel of the software, as maintained by theCAISE server. Any artifact and program-ming language can be supported by CAISE;the more formally defined the grammar ofthe language, the finer the level of model-ing.
This paper describes the motivation forsuch a framework, highlights related work,and then illustrates the key concepts via anexample set of collaborative tools.
[4] Anita Sarma and Andr van der Hoek.Palantr: Coordinating DistributedWorkspaces. In 26th Annual InternationalComputer Software and Applications Con-ference. IEEE, Oxford, England, August2002.
Annotation: Palantir is a framework forthe realtime notification of software engi-neering events within a distributed group ofdevelopers. It is based upon a SCM system,
9
and monitors check-ins to produce changeimpact and severity analysis reports. Suchreports are delivered to end users, wherethey are visualised in real time.
After providing an example scenario ofusage, this paper gives implementation de-tails of Palantir, followed by a brief listingof related work. In the conclusion the paperasserts that more development of Palantiris required, including case studies to inves-tigate the effectiveness of the framework.
[5] Carl Cook, Neville Churcher, and WarwickIrwin. Towards Synchronous CollaborativeSoftware Engineering. In Proceedings ofthe Eleventh Asia-Pacific Software Engi-neering Conference, pages 230–239. IEEEComputer Society, Busan, Korea, Decem-ber 2004.
Annotation: This paper is an update tothe original description of the CAISE Cseframework. The paper asserts a definitionof Cse, and then goes on to discuss the col-laborative spectrum of tools and processes.Prior to detailing the latest version of thecollaborative architecture, the paper dis-cusses the factors that influence collabora-tion within software development, and thetypes of feedback that users require whendeveloping software. Another key point ofthis paper is the identification of the real-time logical area of critical code for eachspecific development task—a set of sourcefiles which is typically larger than what cur-rent single user tools support.
After describing the latest version ofCAISE, the paper presents new tools de-veloped for the architecture. The paperdemonstrates how these tools provide thetypes of feedback required by collaborativedevelopment teams, and shows how fur-ther tools can be developed. The paper con-cludes by detailing future work, which in-cludes the identification of patterns of col-laboration, and analysis of realtime user ac-tivity.
[6] Till Schummer. Lost and Found in Soft-ware Space. In 34th Annual Hawaii In-ternational Conference on System Sciences.Maui, Hawaii, January 2001.
Annotation: This paper presentsTUKAN, a system for the collaborativeediting of SmallTalk software projects.
TUKAN is built upon the Orwell con-figuration management section (see Sec-tion 3.3 on page 29), and provides a col-laborative class browser and editor for eachprogrammer to use as they inspect and de-velop their code base.
This paper provides an insightful us-age scenario to describe the key features ofTUKAN, with a good balance of screen-shots, discussions, and formal definitions.Of particular interest to CSE researchersare the spatial models, where dynami-cally updated representations for presenceawareness and user locations are presented.Apart from describing the TUKAN archi-tecture, this paper gives an interesting dis-cusses the role of user awareness and pro-gram comprehension in order to justifyTUKAN’s design. Whilst limited to a sin-gle interface for the SmallTalk language,the discussion of the TUKAN architecturewithin this paper is comprehensive.
[7] Li-Te Cheng, Cleidson R. B. de Souza, Su-sanne Hupfer, John Patterson, and StevenRoss. Building Collaboration into IDEs. InACM Queue, volume 1, pages 40–50. ACM,January 2004.
Annotation: The Jazz architectureis a Java-specific collaborative develop-ment extension to the Eclipse integratedplatform—see Section 3.1.4 on page 20 forinformation on Eclipse. After a detailed dis-cussion of need for and challenges of inte-grating collaboration within an IDE, thispaper provide several simple examples andproof of concepts, and also gives a detaileddescription of Jazz’s features. One point tonote is that Jazz is designed for use in officeenvironments to facilitate a higher level ofcollaboration and communication betweendevelopers; in this light, Jazz is not nec-essarily suitable for highly distributed set-tings.
There are several earlier papers thatintroducing Jazz in more detail, but thispaper is a polished summary of the re-searchers’ work to date. The paper pro-vides a useful ‘Lessons Learned’ section,and also details some recent publicationsand research projects.
[8] W. R. Bischofberger, C. F. Kleinferchner,and K. U. Matzel. Evolving a Programming
10
Environment Into a Cooperative SoftwareEngineering Environment. In Proceedingsof the International Conference on Soft-ware Engineering, pages 95–10. McGraw-Hill, New Delhi, India, February 1995.
Annotation: Sniff is a project devel-oped for industrial collaborative softwareengineering. From the prototype came acommercial version called Sniff+. This pa-per discusses the mechanisms for collab-oration within Sniff+, such as its parser-based source code analysis, class visualisa-tion system, and communication facilities.Additionally, the paper discusses a researchproject that is a continuation of the originalsniff research named BeyondSniff, which in-tegrates additional tools into the Sniff en-vironment.
Whilst this paper is low on referencesand arguments to support the design of thearchitecture, the paper is valuable for itsdescription of a novel, commercial collab-orative system that is still popular today.The paper provides many screenshots of theSniff+ tools, and presents a good discussionon the merits of both pessimistic and opti-mistic artifact control.
[9] C. M. Werner, M.S. Mangan, L. Murta,R. Pinheiro, M. Matoso, R. Braga, andM. R. S Borges. OdysseyShare: an En-vironment for Collaborative Component-Based Development. In The IEEE Inter-national Conference on Information Reuseand Integration, pages 61–68. Las Vegas,USA, October 2003.
Annotation: OdysseyShare is a set oftools to support the collaborative devel-opment of component-based systems. Fora given domain, the OdysseyShare envi-ronment provides support for the develop-ment, editing, and reverse-engineering ofsoftware artifacts—including source files,binary components, and diagrams. The en-vironment is supported by a workflow en-gine, and a distributed component library.
In this paper, a collaborative class dia-grammer is presented, with a focus on tworeal-time collaborative widgets: a ‘radarview’ and telepointers. The general goal isto provide realtime support for a team ofsoftware engineers by increasing the levelof intra-team awareness and communica-tion. Little mention is made to the type
of tasks that OdysseyShare supports, andit is also unclear what sized terms the sys-tem is designed for, the types of languagessupported, and the general capabilities ofthe collaborative tools provided. Regard-less, the workflow-based approach is inter-esting, and there are many useful referenceswithin the paper.
[10] Scott Lewis. Eclipse CommunicationFramework. Internet Homepage, April2005. URL http://www.eclipse.org/ecf/goals.html.
Annotation: The Eclipse Communi-cation Framework (ECF) is a new re-search initiative that was demonstrated atEcipseCon 2005. Once released, the ECFwill provide a platform to rapidly developeclipse based collaborative tools, includ-ing software engineering tools based uponthe Eclipse Modelling Framework (EMF).While no official papers have been pub-lished yet, the above URL provides the firstglimpse of what the ECF promises to be.
There are three core components tothe ECF: and API for sharing the eclipseproject model, APIs for supporting com-munication and collaboration, and the RichClient Platform (RCP) for building eclipse-based tools. The article given here provideslinks to the first prototype tools developedunder the ECF, such as a shared text editorand shared graphing program. Whilst rela-tively unheard of at time of writing, ECFpromises a great deal in terms of increasingthe degree of collaboration within softwareengineering, and it is gaining attention andsupport from within and outside the eclipsecommunity.
2.4 Inspection Tools
Inspection tools within the field of Cse typ-ically support one of two functions: allowingusers to collaboratively inspect code and designsas a group, or allowing single users to inspectcode and designs that have been collaborativelydeveloped. Inspection tools differ from man-agement tools in that their key role is the in-spection and investigation of software engineer-ing artifacts for the benefit of future develop-ment and refinement, as opposed to manage-ment tools that are more concerned with groupcoordination and artifact control.
11
Publications
[1] Vahid Mashayekhi, Chris Feuller, and JohnRiedl. CAIS: Collaborative AsynchronousInspection of Software. Proceedings ofthe Second ACM SIGSOFT Symposium onFoundations of Software Engineering, 19(5):21–34, December 1994.
Annotation: Whilst ten years old now,this paper describes an interesting tool forthe collaborative inspection of software sys-tems named CAIS, which was built using Lo-tus Notes and Suite. The system does notsupport shared browsing of software arti-facts; rather it facilitates asynchronous dis-cussions between users as they inspect soft-ware systems. Although the CAIS architec-ture itself is not groundbreaking in terms ofsupport for collaborative software engineer-ing, the evaluation as presented in this paperis very informative in terms of user behaviorwhen inspecting code.
The paper is well referenced through-out, and has thorough sections on relatedwork and lessons learnt. The evaluation con-cluded that meetings take longer in CAISthan in face to face, and that many meetingsrequire synchronous interaction—somethingthat CAIS can not provide. More faults,however, were reported in the software whenusing CAIS than without. Another interest-ing point raised in this paper was that userspreferred less detailed and structured meet-ings if given the choice.
[2] Michael Stein, John Riedl, Soren J. Harner,and Vahid Mashayekhi. A Case Study ofDistributed, Asynchronous Software Inspec-tion. In Journal of Collaborative SoftwareEngineering, pages 107–117. ACM, Boston,MA, USA, May 1997.
Annotation: This paper, which presentsthe collaborative software inspectiontool named AISA, has quality referencesthroughout. The AISA system, as describedwithin, is a web-based advance on theprevious systems of CSI and CAIS. AISAallows voting between users, asynchronousmeetings, and structured fault tracking.AISA also allows the graphical display of thedomain being inspected as an interface forinspection. It should be noted however thatAISA only supports asynchronous meetingsand feedback; real-time collaboration is not
possible with this system.In the background sections, this paper
includes solid theoretical underpinningsfor the proposed system. In the evaluationsection, results were reported from the mea-surement of fault corrections resulting frominspections in an industrial setting. Thepaper concludes that people enjoy using thesystem, but the system delay is noticeableover the intercontinental link. As a positiveaspect, a proportion of users continuedusing the tool after the trial, even with theseven hour time difference between the twogroups of users. As a final point, the authorsemphasise that the tool is not intended toreplace face to face meetings, but to supportexisting synchronous activities.
[3] Robert Lougher and Tom Rodden. Support-ing Long-term Collaboration in SoftwareMaintainance. In Simon Kaplan, editor,Proceedings of the Conference on Organiza-tional Computing Systems, pages 228–238.ACM, Milpitas, California, USA, November1993.
Annotation: Maintainance of softwaresystems is progressively becoming a highlycollaborative task—especially as systemsizes increase. This paper presents an archi-tecture that supports long term collabora-tion between maintainers by capturing an-notations of the design rationale. Using thisarchitecture, maintainers of the software sys-tem can add structured comments to units ofcode, draw contextual diagrams, and searchthe change-log for comments as the systemevolves.
The paper provides an excellent dis-cussion of “documentation by annotation”.There are also many good formal discus-sions in this paper to justify the design ofthe system, including a section on the under-standing of collaboration in software main-tainance. The paper also gives numerous ex-amples of the system illustrated by screen-shots, and there are additional sample sce-narios to show usage of the architecture. Aninteresting point raised within the paper isthat this system is different in its ability tosupport documentation in a parallel threadto the main artifacts—this is essential due tothe relatively unstructured task of softwaremaintainance.
12
[4] Carl Cook and Neville Churcher. Modellingand Measuring Collaborative Software Engi-neering. In Vladimir Estivill-Castro, editor,Proceedings of ACSC2005: Twenty-EighthAustralasian Computer Science Conference,volume 38 of Conferences in Research andPractice in Information Technology, pages267–277. ACS, Newcastle, Australia, Jan-uary 2005. 25% acceptance rate.
Annotation: This paper discusses themodelling, analysis and visualisation of fine-grained activity data gathered from collab-orative software engineering tools as theywork on a shared project. Through the use oftree maps, several distinct patterns of collab-oration were apparent from a short periodof activity between four co-located program-mers. Through analysis of the event datasuch as file modifications, chat messages,and model change events, it was possibleto identify times when users worked on con-centrated code fragments, navigated aroundseveral files within a short period of time, ex-perienced difficulties in compiling, and spentlarge amounts of time communicating withothers via the messaging utility. By havingaccess to fine-grained information related touser activity, it is also possible to producesimple visualisations of the intersections ofartifacts and the users that modified them.It is intended that such visualisations canprovide a greater understanding of the fine-grained actions of developers.
As a separate thread in this paper, theconcept of heuristic evaluations for Csetools is introduced. It is intended that theseheuristics are used to constantly refine Csetools so that they adhere to principles ofgood design and fundamental requirementsof Cse.
[5] Jon Froehlich and Paul Dourish. UnifyingArtifacts and Activities in a Visual Tool forDistributed Software Development Teams.In 6th International Conference on Soft-ware Engineering (ICSE’04), pages 387–396.IEEE, Edinburgh, Scotland, United King-dom, May 2004.
Annotation: This article presents Au-gur, a comprehensive visualisation tool forinspecting and exploring software develop-ment activity. Augur consists of a data gath-ering architecture based on the semanticanalysis of source code repositories and a set
of visualation tools. These tools allow devel-opers to monitoring their activity and ex-plore the distribution of their combined ac-tivities over time and artifacts.
This article gives four interesting casestudies of developers that used Augur as asupplement to their regular software engi-neering tools. The feedback suggests thatAugur is both valuable and meaningful asa feedback tool. After presenting the designand implementation details of augur, the pa-per provides a sound section on related work.The paper concludes by asserting that devel-opers were assisted in their work through thecombined views of artifacts and user activ-ity.
2.5 Discussion Papers
These papers present general discussions andsurveys on aspects of Cse, rather than present-ing a tool that performs a specific task or ful-fills a certain role. Within the field of Cse re-search there are many discussion papers relatedto conceptual frameworks rather than actual im-plementations, and these papers provide usefulinsights for any researcher considering the de-sign or development of new Cse tools. Thissection also presents papers related to the so-cial protocols of collaboration, including opensource development practices.
Publications
[1] Uwe Busbach. Activity Coordination inDecentralized Working Environments. InAlan Dix and Russell Beale, editors, Re-mote Cooperation: CSCW Issues for Mobileand Tele-workers, chapter 8. Springer/BCS,September 1996.
Annotation: This paper discusses theperils and pitfalls of asynchronous collabora-tion within highly distributed environments;topics explored include activity coordinationand conflict resolution. An activity coordina-tion tool named Task Manager is also pre-sented in this paper, which is used to illus-trate the assertions made within. One of themost important points raised in this paperis the trade-off between uninhibited collabo-ration and consistency of data objects.
13
[2] Stan Jarzabek and Riri Huang. The Casefor User-Centered CASE Tools. Communi-cations of the ACM, 41(8):93–99, 1998.
Annotation: This paper is another gooddiscussion of what researchers should beaware of when selecting or designing CASEtools, and analyses the recent state-of-the-art. Similar to other CASE tool discussionpapers, it does not refer specifically to multi-user tools, but the discussion is certainly ap-plicable for researchers who are developingshared software engineering tools. This pa-per is a discussion document on why toolsshould become more user-centric; no at-tempt is made to study users or evaluatetools.
The paper raises the interesting pointthat the market for CASE tools is increasing,but such tools are still not widely utilised.For CASE tools to be more widely used, thepaper argues that such tools need to moveaway from being method and process based,and begin supporting programmers dynam-ically, based on what they are developing,and the level of programmer expertise. Thepaper continues by suggesting that we needto first take a look at what the behaviour ofprogrammers is, and then build tools aroundthe models of system development. This is alight paper to read, but worthwhile for theinteresting discussion on design considera-tions for CASE tools.
[3] J. Iivari. Why are CASE Tools Not Used?In Communications of the ACM, volume 39,pages 94–103. ACM Press, October 1996.
Annotation: This paper provides a com-prehensive study and discussion of problemswith CASE tools, centered upon a statisticalanalysis of a survey of CASE tool users. Thedata was collected in 1993; whilst the toolsunder investigation are no longer in use to-day, the lessons learnt are still relevant read-ing. A key point of this paper is that muchresearch into CASE tool usage is based ondescription rather than identifying theoret-ical underpinnings or explaining of factors;therefore this paper performed a major sur-vey to illustrate and validate the theoreticalarguments within.
The paper gives a conceptual model andhypothesis about drivers for CASE adop-tion, and then surveyed 35 organisations.Whilst this is a worthy research effort, only
1 of the 105 individual respondents was em-ployed primarily as a programmer. This sug-gests that the results are relevant for anal-ysis and design tasks rather than program-ming duties. The paper places importanceon its statistical results to illustrate the fac-tors related to CASE tool adoption, but it isworth considering that it may be dangerousto infer causality for software engineering inthe large based solely on this survey. Regard-less, the suggestions based from observationwithin this paper, such as stronger supportfrom management for CASE tools, are wellworth noting. Additionally, many referencesto papers describing the adoption of CASEtools, from viewpoints of both theory andpractice.
[4] Iris Vessey and Ajay Paul Sravanapudi.CASE Tools as Collaborative Support Tech-nologies. In Communications of the ACM,volume 38, pages 83–95. ACM Press, Jan-uary 1995.
Annotation: CASE tools are designedto aid software developers, and this paperpoints out that most CASE tools are not col-laborative. Accordingly, the potential bene-fits of collaboration-aware CASE tools areinvestigated in this paper, and in doing sorepresents one of the first exploratory inves-tigations into collaborative CASE tools.
This paper begins with an in-depth dis-cussion about the difference between coor-dination and collaboration, and the some-times opposing objectives they support. Asan evaluation, this paper examined fourCASE tools for systems analysis, and rankedeach of them in terms of control, informa-tion sharing, monitoring, and cooperation.Whilst the study appears to be minimal inevaluating ‘cooperation’, the analysis of ‘co-ordination’ features is useful. The paper con-cludes with a comprehensive discussion onthe implications of CASE tool design for de-velopers and researchers.
[5] G. Booch and A. W. Brown. Collabora-tive Development Environments. In MarvinZelkowitz, editor, Advances In Computers,volume 59. Academic Press, August 2003.
Annotation: This article represents anexcellent discussion on the current state ofresearch into collaborative development en-vironments (CDEs). Key to the article is a
14
vivid metaphor—points of friction. The ar-ticle discusses the points of friction withincurrent collaborative development, and sug-gests ways to create a frictionless surface.
The article starts with an excellent open-ing discussion on the role of developer, andthe dynamics of software. Useful discussionsthen follow related to CDE features, withcategorization into coordination, collabora-tion, and community building. After a dis-cussion on the evolution of CDEs, and thepresentation of a conceptual model of CDEs,the article finishes with a five-step guide toprepare organisations for CDE adoption.
Included in this article is an excellent andup-to-date survey of CDE systems, with use-ful screenshots from various applications. Auseful taxonomy of CDEs is then given, cat-egorising CDEs into the non-software do-main, asset management, information ser-vices, infrastructure, community, and soft-ware development. Apart from being a veryinformative and insightful read, the articlealso gives many useful references.
[6] Yunwen Ye and Kouichi Kishida. Towardan Understanding of the Motivation of OpenSource Software Developers. In Proceedingsof the International Conference on SoftwareEngineering (ICSE2003). Portland, Oregon,May 3-10 2003.
Annotation: This paper leads an inter-esting discussion as to what might moti-vate people to contribute to open sourcesoftware projects. A case study is presentedbased upon the GIMP project, one of themost popular open source projects in ex-istence. Using learning theory, this papersuggests that Legitimate Peripheral Partic-ipation (LPP) might be one of the drivingforces behind contributions to open sourceprojects, where users feel legitimised fortheir efforts and further their own softwareengineering knowledge.
This paper provides a good discussionof the nature of open source development:the economics, the social structure and thedynamics of change. It presents the com-plicated field of open source software de-velopment from a new analytical viewpoint,providing practical guidelines for the cre-ation, management and development of OSprojects.
[7] Anita Sarma. A Survey of CollaborativeTools in Software Development. TechnicalReport UCI-ISR-05-03, Donald Bren Schoolof Information and Computer Sciences, Uni-versity of California, Irvine, March 2005.
Annotation: This document presents anexcellent taxonomy of Cse tools and re-lated papers. The related work section pro-vides several conceptual models that cate-gorise Cse in various ways, such as spaceand time, model domains, and software en-gineering processes. The survey then intro-duces a well-designed classification frame-work, which pairs level of coordination sup-port against three elements of collaboration:communication, artifact management andtask management. The remainder of the sur-vey then categorises and discusses a massive228 Cse papers according to classificationframework, and concludes with a discussionof observations made during the classifica-tion process.
[8] Carl Gutwin, Reagan Penner, and KevinSchneider. Group awareness in distributedsoftware development. In CSCW ’04:Proceedings of the 2004 ACM Conferenceon Computer Supported Cooperative Work,pages 72–81. ACM Press, New York, NY,USA, 2004. ISBN 1-58113-810-5.
Annotation: This paper leads an inter-esting discussion as to how distributed opensource developers maintain awareness ofother users. The paper presents the findingsof a process that involved interviewing devel-opers, reading communications, and examin-ing artifacts and repositories for three largeand successful open source projects. Thepaper explains that developers do need tomaintain an awareness in two senses: a gen-eral project awareness and a closer aware-ness of others that are working on highly re-lated code.
The investigation shows that developersbuild up a mental model of the project andits associated developers, and this modelis maintained through an ethic of regu-larly reading and posting to the developmentmailing lists and chat servers. An interestingcharacteristic was revealed upon inspectionof the projects’ artifacts—large numbers ofstrongly partitioned files exist, which sug-gests that the projects are in parts main-tained by single developers only. Other key
15
findings to come out of this study is thatmany developers feel that they require littleadditional tool support due to the successof their manual coordination efforts. Accord-ingly, given the option of visualisation toolsand proactive tools such as CVS edit, manyprogrammers responded negatively. It ap-pears that with well run development groupsthat have clearly established work ethics,such as those presented in this paper, prob-lems in duplicated and conflicting efforts arerare and easily resolved. As stated in thepaper, the only time when problems do oc-cur and have a significant impact is whenthe open source teams are placed under timepressures.
[9] Frederick P Brooks Jr. The Mythical ManMonth: Essays on Software Engineering.Addison-Wesley, second edition, 1995. ISBN0-201-83595.
Annotation: This famous work is essen-tial reading for any computer science re-searcher. For the Cse researcher in par-ticular, it provides many great discussionsabout how projects are constructed in teams,and makes many observations related toteam dynamics and leadership within soft-ware projects. For those unaccustomed tolarge-scale industrial software development,this book gives great insight into the perilsand pitfalls of collaborative software devel-opment.
3 Fields Related to Cse Re-search
This section does not represent an exhaustivecollection of all papers related to the associa-tive fields of collaborative software engineering.Rather, it represents all the papers that wefound useful as background research into theconstruction of an architecture and associatedtools for collaborative real-time software engi-neering. As comprehensive surveys already existfor each discipline in its own right, the followingsections are focused primarily on relevance tosupporting collaborative software engineering.
The following sections discuss the areas ofComputer Science identified within the Venn di-agram of figure 1.1. These area are: Human Fac-tors, Source Code Management Systems, Dis-tributed Systems, Software Visualisation and
Metrics, Groupware and Computer SupportedCollaborative Work, and Software EngineeringProcesses. We do not claim that Cse researchis at the core of each related discipline, but wedo assert that each of the above areas are keyin supporting and enabling successful Cse toolsand frameworks.
3.1 Software Engineering Pro-cesses
Software engineering is a very practical areawithin the discipline of Computer Science. Assuch, the theories related to software engineer-ing are often produced empirically by observa-tion of practicing software engineers and theinduction of facts, rather than by deduction,proofs and foresights conceived in research labo-ratories. This is not to say that research papersrelated to software engineering are of less signif-icance than papers in other fields of ComputerScience; we merely observe that the software en-gineering industry is driven by demand, and the‘best ideas’ and practices are often developedin the field and then analysed and documented,as opposed to all ideas being conceived withinacademia and progressing to the practicing in-dustry.
Due to the large range of tasks within soft-ware engineering and the considerable amountof variance in methodologies, team dynamicsand duties to be performed, it is difficult to per-fectly map what happens within software engi-neering projects to a set of rules and processes.Consequently, many of the highly cited arti-cles related to software engineering are chapterswithin books that document entire processes,not scientific conference and journal papers.
This section presents key articles related tothree core methodologies of software engineer-ing: classical methodologies, object orientedmethodologies and agile methods. The final list-ing of articles is for software engineering toolsupport, providing details on some of the mostpopular tools used by software engineers to-day. It is intended that this section providesthe reader with an understanding of contempo-rary software engineering practices and support-ing tools.
3.1.1 Classical Methodologies
After the ‘software crisis’ of the 1980s, the prac-tice of software engineering matured consider-
16
ably with the birth of formal software engi-neering processes and methodologies. Struc-tured, controlled ways of developing softwarewere introduced, such as top-down and bottom-up development, the waterfall, spiral and chaosmodels, and data-driven development. Com-mon to all of these methodologies were require-ments analysis, design, implementation, testingand maintenance. The books given in this sec-tion provide an overview of these methodologies,working examples and case studies.
Publications
[1] Ian Summerville. Software Engineering. Ad-dison Wesley, Reading, MA, 6th edition,2000. ISBN 020139815X.
Annotation: In terms of the Software De-velopment Lifecycle, this is a classic text-book. Whilst several chapters are dedicatedto object oriented design, the content fo-cuses mainly on the SDLC methodologyof component-based software engineering—namely specific and isolated stages of de-velopment. This textbook is very compre-hensive, covering everything from system re-quirements gathering to formal specificationwith Z schemas. In particular to collabo-rative software engineering, this text inte-grates content on CASE tools throughoutthe book, and also includes specific chap-ters on group working, configuration man-agement, and large-scale project manage-ment. This is a classic software engineeringtextbook, but it also very valuable for thosewanting more of an insight into group devel-opment.
[2] Steven C. McConnell. Code Complete: APractical Handbook of Software Construc-tion. Microsoft Press, Redmond, Washing-ton, 2nd edition, June 2004.
Annotation: Ten years after the first edi-tion, this popular ‘practitioner’s guide’ tosoftware engineering has been revised andreleased. This book is not heavy on the aca-demic aspects of software engineering; ratherit offers great advice on the implementationand design issues that programmers face ona daily basis. This book is respected for itsadvice on everything from testing to usingbug databases to coding conventions.
Whilst most software engineering re-searchers are not necessarily interested in ev-
ery chapter of this 900-page book, it is anexcellent guide for those wish to gain moreof an insight into the ‘real-world’ complica-tions of software development. Code Com-plete noticeably stays away from most soft-ware engineering methodologies, but doeshave a chapter specifically dedicated to XP-styled refactoring. As an insight into real-world and large-scale development, and asan up-to-date discourse of the systems andprocesses that are being used within the soft-ware engineering industry today, this book iswell worth examining.
3.1.2 Object Oriented Methodologies
Object oriented design and programming is amethodology that enforces modular program-ming and data hiding through encapsulation.This methodology specifically encourages soft-ware reuse via inheritance and polymorphism,where general-purpose components can be ex-tended by ‘differences only’ to provide a suitablesolution rather than ‘reinventing the wheel’.
There have been two key peaks of popularityfor object oriented development. The first wasin the 1970s when the SmallTalk language wasintroduced. Subsequent to this, object orienta-tion became popular again in the 1990s throughthe advent of C++ and then Java. Object ori-ented design and implementation is now thede facto standard within the software engineer-ing industry and is supported by recently intro-duced languages such as C#, and Python.
This listing again provides references todefinitive books on object oriented methodolo-gies which are considered by many to be es-sential reading for all software engineers. Thislisting provides references to overviews of ob-ject orientated programming and development,as well as best practices for practical system de-velopment.
Publications
[1] Bernd Bruegge and Allen Dutoit. Object-Oriented Software Engineering. Prentice-Hall, New Jersey, 2000. ISBN 0-13-489725-0.
Annotation: As a good example of atextbook for object oriented software en-gineering, this book by Bruegge and Du-toit is worth examining. All examples within
17
the text are based upon the UML nota-tion, and the extensive use of design pat-terns are made. Apart from being a populartext for object oriented software engineer-ing, this book also makes specific referencesto distributed and group development.
[2] Erich Gamma, Richard Helm, Ralph John-son, and John Vlissides. Design Patterns :Elements of Reusable Object-Oriented Soft-ware. Addison-Wesley Professional Com-puting Series. Addison Wesley, 1995. ISBN0201633612.
Annotation: This books constitutes theseminal publication on design patterns; it ishighly cited in all modern contexts of soft-ware engineering. Design Patterns—knowninformally as the Gang-of-Four book—provides a concise taxonomy of design pat-terns for software construction, categorisedinto creational, structural, and behavioralpatterns.
The Gang-of-Four book is an excellentreference guide for common patterns, andalso has well written introductory chaptersdemonstrating how design patterns solve de-sign problems. An extensive case study isused for illustratory purposes. Examples forevery pattern are provided in either C++,SmallTalk, or both.
This book sits next to nearly every soft-ware architect, and is compulsory reading forevery CS student. Every pattern is consis-tently documented in terms of intent, pur-pose, motivation, known uses, implemen-tation notes, and related patterns. Whilstagain this book is not specifically written forcollaborative software engineering, it is veryrelevant in terms of implementation consid-erations.
[3] John Vlissides. Pattern Hatching: DesignPatterns Applied. Addison Wesley, Reading,MA, 1998. ISBN 0-201-43293-5.
Annotation: To supplement the ‘Gangof Four’ book [2], this short paperback arti-cle has been produced. It has many insight-ful comments and code examples on the im-plications of applying design patterns. Nonew patterns are introduced; rather it is justa best-practices guide for programmers andsystem architects. This book does not makespecific reference to addressing aspects ofcollaborative software engineering, but as a
general guide for modern-day programming,it is essential reading. It is also useful forwish to gain insight into some ‘real-world’issues and solutions when designing and im-plementing modern computer software.
[4] Marin Fowler. UML Distilled: A Brief GuideTo The Standard Object Modeling Language.Object Technology Series. Addison Wesley,Reading, MA, 3rd edition, 2004.
Annotation: This is the latest editionof the popular UML distilled title, and rep-resents a significant rewrite of the previousedition. UML Distilled covers UML version2.0—the latest OMG UML standard.
This book is more than just a referenceto UML–it is also a practical guide for usage.There are plenty of examples and explana-tions, along with a few code snippets for il-lustratory purposes. Additionally, this bookmentions how UML integrates with specificdevelopment processes such as waterfall andRUP, and a section on integrating UML withpatterns. The book also has detailed discus-sions on when and where to use UML.
UML Distilled is a modern-day classicsoftware engineering book—again not specif-ically for the collaborative software engineer-ing researcher, but it is essential readingfor any practitioner wishing to design large-scale contemporary applications.
3.1.3 Agile Methods
Agile methods is a collective term given to arelatively new software engineering approach.Agile methods encourages software developmentthat deals effectively with issues such as chang-ing requirements and fluctuations in resourcinglevels. It encourages practices that emphasiserotation of duties and stakeholder involvement.Agile methods also promote the iterative devel-opment of small yet functional pieces of the to-tal project. This is in considerable contrast withthe waterfall process described in section 3.1.1.
This listing provides details on agile meth-ods, including pair programming and the eX-treme Programming process. Pair programmingis particularly important to Cse research dueto its inherently collaborative nature. All otheragile method approaches are also important toCse, due to incorporating teamwork as a cor-nerstone of the methodology.
18
Publications
[1] Alistair Cockburn. Agile Software Develop-ment. Addison-Wesley, 1st edition, Decem-ber 2001.
Annotation: The terms ‘Agile Methods’and ‘Agile Development’ are becoming in-creasingly common within the software engi-neering literature. As the agile methods ban-ner is relatively new, little literature existswithin the research community. This book,however, provides a comprehensive overviewof the agile development methodology, andis well cited within both the industry andresearch communities.
Surprisingly enough, the book is tends tobe focused on group communication ratherthan methodologies. The book does not nec-essarily attempt to ‘sell’ agile methods asthe one true software engineering religion;rather it provides a detailed and somewhatexhaustive description of what constitutesagile methods, what they can be applied to,and where they originated from. The bookalso provides many excellent illustrations ofpeer programming environments, challeng-ing scenarios, and the like.
This book is an excellent resource forthe collaborative software engineering re-searcher, in particular the sections relat-ing to communication within and betweenteams, co-location vs distributed environ-ments, artifact types and life-cycles, andforms of communication.
[2] Laurie Williams, Robert R. Kessler, WardCunningham, and Ron Jeffries. Strengthen-ing the Case for Pair Programming. In IEEESoftware, volume 17, pages 19–25. July 2000.
Annotation: Pair programming, an in-tegral component of XP, is becoming com-mon practice within development teams ofall sizes. This paper presents some empiricalevidence that the practice of pair program-ming has its advantages.
The paper starts with a comprehensivehigh-level description of pair programming,and then describes a new experiment to as-sert the claims of that peer programmingis not significantly slower than conventionalapproaches, reduces bugs, and subjects en-joy it more. The study involved 41 univer-sity students, and concluded that the pairsworked 40-50 percent faster than individu-
als, with slightly higher test cases passed.Unfortunately, the paper is weak on the
documentation of the experimental design,however the anecdotal comments made bystudents, and the subsequent discussion bythe authors make for useful reading. Regard-less of the experiment writeup, this paperprovides a solid description of XP, includ-ing the history of pair programming. Theanecdotal comments, such as programmersenjoyed peer programming more, and feltmore confident about their coding due to thepresence of an observer, make this paper animportant one in the story of collaborativesoftware engineering.
[3] Hans Gallis, Erik Arisholm, and Tore Dyb.An Initial Framework for Research on PairProgramming. In International Symposiumon Empirical Software Engineering, pages132–142. Rome, Italy, October 2003.
Annotation: This article examines theclaims made about the reported benefits ofpair programming. After a complete yet con-cise overview of pair programming, the pa-per surveys and discusses six recent and well-cited papers that empirically evaluated pairprogramming. In the context of this sur-vey, a framework is proposed to assist on-going qualitative and quantitative empiricalresearch on peer programming. The frame-work is described by three main aspects: in-dependent variables such as programmer col-laboration, dependent variables such as de-velopment time and cost, and context vari-ables such as the programmers being evalu-ated and the task to be completed.
The majority of this paper discusses anddescribes the framework, and while this pro-vides an informative insight into the issuessurrounding peer programming, no evalua-tion of the framework is made. Regardless,the discussion of peer programming, andthe degree of examination of peer program-ming evaluation techniques makes this pa-per recommended reading for all researchersof collaborative software engineering. Addi-tionally, the paper has many great referencesto leading related work.
[4] Kent Beck. Extreme Programming Ex-plained: Embrace Change. Addison-Wesley,Reading, MA, 1st edition, October 1999.
19
Annotation: Extreme Programming(XP) is a collaboration-centric software en-gineering methodology. Whilst literature re-lated to XP is limited—most probably dueto the very nature of XP itself, this bookappears to be the authoritative backgroundmaterial for XP. This book discusses theroots and philosophies of XP, and outlinesthe motivating factors for the use of XP,including a discussion on why previous yetaccepted methodologies often fail. After ex-plaining the problems that XP endeavorsto solve, this book outlines the concretemethodology for practicing and adoptingXP. This book is recommended reading forany collaborative software engineering re-searchers who want to learn about the the-oretical underpinnings of XP, including pairprogramming, code walk-throughs, and the‘planning game’.
3.1.4 Tool Support
There is a wide range of tools available to thesoftware engineer. At one end of the spectrum,well designed simple tools have always enjoyedwidespread use and popularity. At the otherend of the spectrum, massively complicated,monolithic and expensive Computer Aided Soft-ware Engineering (CASE) tools that incorporatecode editors, diagrammers, project managementcomponents and debuggers are used exclusivelyby some corporations, but have not gained widespread acceptance elsewhere.
The listing presented here provides articleson tools that have been successful in commer-cial and open source development groups alike.All of the tools presented in this listing are sin-gle user tools, with the exception that they canintegrate with code repositories such as CVS.It is important for potential Cse researchers tobe aware of these tools, including their capabil-ities and limitations—it is from these tools thatwe can envisage how collaboration can be sup-ported in future generations of development.
Publications
[1] Christopher Garrett. Software Modeling In-troduction: What Do You Need from a Mod-eling Tool? White Paper, Borland SoftwareCorporation, 28 May 2003.
Annotation: As the title suggests, thiswhite paper presents the core features that
a modeling tool should require. The authordoes not cite any supporting publications;therefore this paper should only be used asan introduction into the Together ControlCenter IDE. An interesting aspect of thispaper is that even though there are numer-ous screenshots of the Together IDE, the pa-per fails to name the system—the screen-shots are only there to support the paper’sarguments about what an IDE should pro-vide. Despite its name, Together does notpossess any specific collaborative properties,but it has been a very popular and extensibleIDE for many years. Multiple language sup-port, and support for all UML diagrams, de-sign patterns, refactoring, reverse engineer-ing, reporting, and round trip engineeringare all features of this tool. Together also hassupport for source code management mod-ules. As an aside, Together is widely re-garded as the largest Java application in ex-istence, but the system’s main claim is thatit is the first tool that supports ‘continuouslysynchronised’ models and code—otherwiseknown as roundtrip engineering.
This white paper provides an excellentdiscussion relating to the role of modelswithin software engineering, and makes sen-sible analogies between software engineersand other professions. The paper also arguesthat tools such as Together help bridge thecommunication gap apparent amongst de-velopers. Even though this is just a white pa-per, it is written in an unbiased manner. Itsintroduction provides an excellent contextfor the remained of the material, and the ex-ample screenshots are useful to researchersas well as users of IDEs.
[2] Jason E. Robbins, David M. Hilbert, andDavid F. Redmiles. Argo: A Design En-vironment for Evolving Software Architec-tures. In Journal of Collaborative SoftwareEngineering. ACM, Boston, MA, USA, May1997.
Annotation: ArgoUML, as described inthis short paper, was one of the first toolsto support analysis continually during theevolution of the model, not just at the endof each completed stage. ArgoUML providesfeedback by critiquing the model and thenappending notes to a ‘todo’ list, with theappropriate problems highlighted within the
20
model. This short paper is restricted to in-troducing the second conceptual version ofArgoUML, and presenting a few of the ar-guments why continuous analysis is usefulto the modeling of software systems.
The version of ArgoUML presented inthis paper was constructed in Java; thefirst version was written in SmallTalk anddemonstrated in ICSE-17. Whilst this is ashort paper, there is a very detailed and in-formative thesis written by Robbins to readas background information if required. Fur-thermore, the commercial and collaborativeversion of the product has extensive userdocumentation—see Section 2.2 on page 7.
[3] IBM Rational Rose XDE Developer.White Paper, April 2004. URL http://www3.software.ibm.com/ibmdl/pub/software/rational/web/datasheet%s/version6/xde.pdf.
Annotation: XDE, whilst now ownedand maintained by IBM, previously existedas Rational Corporation’s main set of toolsto support the Rational Software Develop-ment Process. Since being taken over byIBM, the set of tools has been ported to ex-ist within several popular IDEs, includingEclipse, WebSphere, and Visual Studio. Itcan also run in standalone mode. This articlepresents a brief summary of the main com-ponents provided by XDE, and gives detailson the different environments that they canrun in.
XDE is another family of products tosupport the complete lifecycle of softwareengineering. In particular, XDE supports anextensive range of modeling, including UML,data modeling, and IDE specific models. Interms of development, it supports most pop-ular design patterns, software reuse, andtemplate generation. It also support an ar-ray of runtime testing and debugging tools.For researchers of collaborative software en-gineering, this article gives brief details onXDE’s collaborative features, including con-figuration management, multiple softwaremodels, and merge support. The XDE tool-set is particularly interesting in its abilityto support numerous source code repositorysystems including Microsoft’s Source Safe,IBM’s Clear Case, and the generic SCC in-terface.
[4] Eclipse Platform Technical Overview Ver-sion 2.1. White Paper, Object TechnologyInternational Incorporated, February 2003.URL http://www.eclipse.org/articles/.
Annotation: Eclipse is currently thelargest research and development platformfor IDEs and related tools. Whilst it hasno published refereed research papers de-scribing its architecture, a wealth of tech-nical articles and white papers are availablefrom the official web site, including the pa-per listed here. It is important to includethe Eclipse platform within this bibliographydue to its large following, including nearly allthe major players in the software engineer-ing research community.
This white paper describes the overall ar-chitecture of the Eclipse platform—an opensource, open community project for the de-velopment and extension of software toolsbased on a commercial-strength underlyingarchitecture. Currently, plugins for Eclipsethat form a Java IDE are used by approx-imately half of the world’s Java program-mers, and many companies have developedthird party extensions for Eclipse via theplugins API—including various plugins tosupport collaborative software engineering.Additionally, since the advent of Eclipse,many of the main IDEs have introducedcompatibility frameworks not just to allowinteroperability with Eclipse, but for inter-operability with each other.
For an overview of the Eclipse IDE, theplugins API, or the Eclipse consortium of de-velopers, this white paper is the most suit-able single reference. It includes detailed in-formation related to the key components ofEclipse, along with a useful case study ofhow the a java development tool is imple-mented in Eclipse. Eclipse is a platform wellworth considering for researchers of collab-orative software engineering; many collabo-rative features have already been introducedby third-party developers.
[5] Visual Studio Developer Center, MicrosoftCorporation, July 2003. URL http://msdn.microsoft.com/vstudio.
Annotation: Visual Studio is a largeplayer in the IDE market, and the URL sup-plied in the above reference is the authorita-tive source for numerous white-papers and
21
other technical documents. Within indus-try, Visual Studio is one of the most com-monly used software engineering tools, andit is also the IDE of choice for many com-puter science laboratories—within both theresearch and education sectors. Visual Stu-dio has well-tuned support for code editing,including class library browsing, and exten-sive code completion capabilities. It also hasplugin-based version control and configura-tion management support.
Interestingly enough, Visual Studio is notactually ‘visual’. To date, it still does notsupport round-trip engineering for code anddiagrams; it only allows specific types of di-agrams to be imported from Microsoft Vi-sio and translated to skeleton code. Recentlyhowever, Together has provided a plugin forVisual Studio, allowing Together’s round-trip modeling capabilities to be utilisedwithin Visual Studio. It is important how-ever to emphasis that Visual Studio by itselfis not a design environment—it only sup-ports the editing of code. Additionally, verylittle support for software metrics or unittesting is provided. It does, however, haveexcellent facilities for memory leak detec-tion, and the debugger is second to none.
[6] WebSphere Studio Application DeveloperVersion 5.1.1. White Paper, January2004. URL www-306.ibm.com/software/integration/wsadie/library.
Annotation: After the retirement of theVisualAge suite of development tools, IBM’smain commercial IDE environment is Web-Sphere Studio. WebSphere is current hostedwithin the Eclipse environment to providethe User Interface components, but under-lying this is an array of design and runtimesupport tools.
This white-paper contains many usefulscreen shots of various parts of the IDE,and describes the main components of Web-Sphere in a logical objective manner. Thewhite-paper also provides a comprehensivespecification listing, which details the fea-tures currently supported by WebSphere—the main categories are Web, Web Ser-vices, Database, and Team Development.For the collaborative software engineeringresearcher, this paper is well worth readingto obtain a brief overview of the teamworkfeatures supported by WebSphere, including
its support for Rational’s ClearCase config-uration manager (see Section 3.3).
3.2 Groupware and Cscw
Groupware and Computer Supported Collabo-rative Work (CSCW) is an area that clearlylends itself to Cse tools and research. Throughgroupware technologies, user interfaces for sim-ple tools can be replicated and shared in realtime by multiple users, and such technology canbe directly applied to assist the development ofmultiuser software engineering tools.
Conventional applications constructedthrough groupware are typically shared white-board editors, chat facilities, and map and graphbrowsers. The Cse researcher must be aware,however, that for complicated applications suchas software engineering tools, groupware has itslimitations that are of particular concern forCse tools.
In this section, we present general literaturerelated to groupware as well as specific classesof groupware including programmable toolkits,desktop systems and constructed applications ofgroupware. This section then presents articlesthat discuss the limitations of groupware, whichis pertinent to any researcher considering theconstruction of a Csetool.
3.2.1 General Literature
The listing given here presents essential back-ground reading for Cse researchers. A compre-hensive survey and taxonomy of groupware tech-nology is given along with articles that provideguidance for the application of groupware.
Publications
[1] Saul Greenberg. The 1988 Conferenceon Computer-Supported Cooperative Work:Trip Report. In SIGCHI Bulletin, volume 20of 5, pages 49–55, July 1989. Also publishedin Canadian Artificial Intelligence, 19, April1989.
Annotation: This report is Saul Green-berg’s writeup of the 2nd Annual ACM con-ference on CSCW. From this introductionto CSCW, Saul worked on many projects,and soon became recognised as a leaderwithin the field of groupware and collab-oration. This report represents a snapshotof the state-of-the-art of CSCW in 1988,
22
where ideas based upon remote collabora-tion and information sharing were just beingconceived.
The report outlines each of the sessionspresented in the conference, including syn-chronous communication, evaluation of sys-tems, enabling environments, and practicalsystem development experiences. One warn-ing within this paper was that researchersmust remember to work on is likely to berelevant and useful to the general commu-nity, given the broad spectrum of possibili-ties with CSCW.
[2] W. Greg Phillips. Architectures for Syn-chronous Groupware. Technical report,Department of Computing and Informa-tion Science, Queen’s University, Ontario,Canada, May 1999.
Annotation: A comprehensive survey ofsynchronous groupware systems. The sur-vey discusses over 100 architectures thatwere presented in the 1990s. Each system isdescribed by one of three views—referencemodels, architectural styles, or distributionarchitectures. For distribution architectures,a new descriptive framework named Inter-lace is used. This survey is an excellent start-ing point for any background informationrelating to real-time collaboration architec-tures.
[3] Prasun Dewan. An Integrated Approachto Designing and Evaluating CollaborativeApplications and Infrastructures. ComputerSupported Cooperative Work, 10(2):75–111,January 2001.
Annotation: This paper introduces aresearch plan for the design and evalua-tion of collaborative systems. Whilst the re-search plan of system decomposition andevaluation appears to be well formed, thepaper is more notable for its comprehen-sive survey of collaborative frameworks andapplications—this survey was required toillustrate the suitability of the evaluationmethod amongst an array of CSCW researchprojects. This paper surveys many group-ware systems including GroupKit and XTV,but also presents collaborative software en-gineering tools such as FLEECE and Suite.Please see Section 2 on page 5 for a discus-sion of such tools.
3.2.2 Programmable Toolkits
Programmable groupware toolkits are used torapidly construct CSCW applications from com-mon multiuser components. Essentially, pro-grammable groupware toolkits are all that de-velopers require to facilitate communication be-tween a group of distributed applications unlesshighly specific networking or collaborative fea-tures is to be supported.
Typical components within groupware toolk-its includes shared text editors, chat facilities,sketch-pads, voting facilities and mechanisms tosupport group membership, connection and dis-connection. Some programmable toolkits alsoprovide comprehensive floor control policies; forthe remainder, all concurrency control must beimplemented by hand.
A multitude of programmable toolkits existtoday. The articles presented in this listing de-scribe some of the more prominent systems, andeach article describes how to construct applica-tions from the given toolkit. For the Cse re-searcher, it is useful to determine what facili-ties and components are available from the cur-rent range of programmable toolkits, which inturn provides the scope of CSCW possibilitiesfor Cse tools. Any collaborative facilities out-side this scope will more than likely have to becreated by the tool designer.
Publications
[1] Mark Roseman and Saul Greenberg. Build-ing Real Time Groupware with GroupKit, AGroupware Toolkit. ACM Transactions onComputer-Human Interaction, 3(1):66–106,March 1996.
Annotation: GroupKit, a toolkit to allowthe development of collaborative applica-tions, is arguably the most notable researchoutput from within the CSCW field. Thispaper provides a comprehensive overview ofthe second, and vastly improved version ofGroupKit. The first chapter provides a briefintroduction to the GroupKit architecture,and also presents the core requirements forany groupware toolkit. Aside from the dis-cussion and an extensive related work sec-tion at the end of the paper, the remainderof this article provides a user guide for de-velopers of collaborative applications.
Whilst detailed enough to illustrate pro-gramming concepts, the user guide is rich in
23
observations and research-related comments;the experiences shared in the developmentof this toolkit are well worth noting, regard-less of whether the reader intends to use thetoolkit or not.
[2] Bela Ban. Design and Implementation ofa Reliable Group Communication Toolkitfor Java, September 1998. URL http://citeseer.nj.nec.com/ban98design.html. Cornell University.
Annotation: This paper presents the de-sign and implementation of JavaGroups, atoolkit for group communication for Java ap-plications that is closely based upon the Ho-rus group communications system. The mo-tivation for such a system is that very fewgroup communication mechanisms are avail-able for the Java language; this toolkit in-tends to provide object-oriented componentsthat are relatively easy to integrate with ex-isting Java applications.
JavaGroups focuses on reliability, usingthe concept of redundancy to cater for com-ponents that could fail within a group ofcommunication processes. As well as pre-senting the system architecture, this pa-per also identifies and discusses the designpatterns within JavaGroups, which may bevaluable to both users of the system, andany researchers of other group communica-tion toolkits. This paper is essential readingfor any researcher who wishes to design anobject oriented group communication frame-work, or any associated applications.
[3] Rich Burridge. Java Shared Data ToolkitUser Guide, October 1999. URL java.sun.com/products/java-media/jsdt.
Annotation: This manual provides anoverview of the Java Shared Data Toolkit(JSDT). The first chapter presents the needfor a toolkit that supports highly interac-tive applications, and abstractly describeshow the JSDT is suitable for most collabora-tive programming needs. The second chapteroutlines the key components of the toolkit,and explains abstractions made to supportthe notion of users, sessions, and data. Theremainder of the manual provides a userguide, outlining keys classes and example us-ages. The JSDT is a useful and very compre-hensive tool for designing collaborative ap-plications, and this manual is the definitive
source of information for researchers and de-velopers.
[4] H. Abdel-Wahab, B. Kvande, O. Kim, andJ.P. Favreau. An Internet CollaborativeEnvironment for Sharing Java Applications.In Proceedings of the Fifth IEEE Workshopon Future Trends of Distributed ComputingSystems. Tunis, Tunisia, October 1997.
Annotation: This paper describes a Javapackage named JCE which allows single-userapplications to be adapted to multi-user ver-sions, with minimal effort. The Java Col-laborative Environment, as this paper de-scribes, overrides the existing Java AbstractWindows Toolkit (AWT) with multiusercomponents. Given these specialised compo-nents, a session manager, and a frameworkthat captures, distributes, and remotely re-produces user input events, the JCE allowssimple applications to be shared collabora-tively.
This paper presents an example of awhiteboard that can be replicated on anynumber of remote systems, and given this ex-ample, the session manager is also presented,along with a discussion of JCE’s floor controlpolicies. One considerable drawback of thesystem is the need to rewrite the AWT com-ponents upon every new version release fromSun, and no literature has been found thatsuggests JCE still exists now that the AWThas been superseded by the Swing toolkit.
[5] E. James Whitehead Jr. and Yaron Y.Goland. WebDAV: A Network Protocolfor Remote Collaborative Authoring on theWeb. In Proceedings of the Sixth EuropeanConference on Computer Supported Collab-orative Work, pages 291–310. Copenhagen,Denmark, September 1999.
Annotation: This article presents a high-level overview of the aim, purpose, andmechanisms of the WebDAV protocol. Web-DAV was proposed by the Internet Engi-neering Task Force as a mechanism to sup-port the continual editing of web resourcessuch as web pages and images. Tradition-ally, such resources were only downloaded,but the WebDAV protocol defines a set ofstandards to allow continual refinement andalteration from any number of authorisedusers. WebDAV employs only course-grainfile locking and simple ftp-like protocols for
24
the obtaining and uploading of resources; be-cause of this, many non-collaborative appli-cations have enjoyed an easy migration pathto collaboratively maintain web servers.
WebDAV has experienced widespreadadaptation—the apache web server and Mi-crosoft’s suite of Office tools both supportthe full WebDAV protocol. Recently, Adobehas released its latest version of the AcrobatPDF reader tool—with WebDAV support itnow allows the collaborative editing of an-notations to online PDF documents. WhilstWebDAV is only a protocol for web-basedhandling of resources, its existence at thenetwork-layer allows any set of tools to in-tegrate with no additional third-party com-ponents. This suggests that use of the Web-DAV protocol is well worth considering forany collaborative tool or framework that isclient/server based.
[6] Till Schummer. COAST: An Open SourceFramework to Build Synchronous Group-ware with Smalltalk, German NationalResearch Center for Information Technol-ogy, October 2002. URL http://www.opencoast.org/documentation.
Annotation: This is a draft chapterthat discusses the COAST framework for ayet to be published collaborative SmallTalkbook. Whilst the seminal paper on COASTwas published in the proceedings of the1996 ACM conference on CSCW (pages 30–38), this book chapter presents more de-tailed and updated material on the COASTframework—a toolkit for providing collabo-ration support for SmallTalk applications.
The paper starts with an outline ofthe requirements for a groupware frame-work, which are very-much inline withthose specified in the initial GroupKit [1]paper. The paper then presents an ex-ample application—that of a collaborativeUML editing tool, using a related-WYSIWISstyle. The paper also discusses the underly-ing COAST architecture, including detailsabout its model-view-controller design, andthe concept of the COAST domain model.During this description, the paper presentsa large and informative ‘behind the scenes’section, discussing many of the real issuesthat face developers of collaborative applica-tions and support tools. The paper concludes
by showing some excellent example applica-tions that use the COAST framework.
[7] Jason Hill and Carl Gutwin. Awareness Sup-port in a Groupware Widget Toolkit. InProceedings of the International ACM SIG-GROUP Conference on Supporting GroupWork, pages 256–267. ACM Press, SanibelIsland, Florida, USA, November 2003.
Annotation: This paper presentsMAUI—a Java toolkit for the construc-tion of collaboration-aware user interfacesand applications. The paper describes thecomponents of the MAUI toolkit, includingmulti-user replacements for the standardSwing UI components, and specialisedcomponents such as telepointers. All com-ponents within the toolkit are packaged asJava Beans, allowing easy integration withIDEs; the paper presents an example appli-cation being constructed via the JBuilderdevelopment environment. An interestingfeature of MAUI, and something new tothe field of groupware, is that of bothdesign-time run-time customisation of themultiuser widgets.
The paper gives several screen-shotswell worth examining, descriptions, anddiscussions of the MAUI widgets, and therun-time and design-time custom dialogs.The system architecture is also described indetail, and the paper concludes by present-ing an example MAUI-based applicationin the form of a shared web browser. Thispaper introduces an excellent new toolkitfor the construction of multiuser Javaapplications, and should be read by anydeveloper considering the construction ofnew collaborative tools.
3.2.3 Desktop Systems
Desktop CSCW systems are designed to supportgeneral workflow and collaboration without theneed for customisation or special tool develop-ment. They are monolithic systems that allowcommon applications, documents and data setsto be shared, often in real-time. Such systemsare useful for most general workflow contextssuch as document editing and project schedul-ing, but do not lend themselves directly to mostsoftware engineering tasks. Desktop systemsdo however provide a good illustration of howCSCW technologies can be applied to facilitate
25
computerised structured teamwork.Many desktop CSCW systems exist; this list-
ing provides articles of such systems that havea strong research theme. The range of desktopCSCW systems presented in this listing is variedfrom simple chat applications such as NetMeet-ing and JAMM to full artifact and workflowmanagement such as CVW and Lotus Notes.
Publications
[1] Windows NetMeeting, Microsoft Corpora-tion, February 2004. URL http://www.microsoft.com/windows/netmeeting/Authors.
Annotation: This is a reference to the of-ficial documentation for Windows Netmeet-ing. Whilst no cited publications are dedi-cated to NetMeeting, this tool is arguablythe most popular piece of commercial col-laboration software ever built. Netmeetingallows single-user applications to be repli-cated transparently between several users,with the original instance of the applicationacting as the server. NetMeeting also sup-ports instant audio, video, and text-basedchat, along with a simple shared whiteboardutility. This reference also includes a link tothe NetMeeting API documentation, whereWindows-based programs can integrate andembed NetMeeting services.
[2] James Begole, Mary Beth Rosson, and Clif-ford A. Shaffer. Flexible CollaborationTransparency: Supporting Worker Inde-pendence in Replicated Application-SharingSystems. Transactions on Computer-HumanInteraction, 6(2):95–132, June 1999.
Annotation: This article presents an en-hanced application sharing system namedJAMM - Java Applets Made Multiuser.The authors argue that conventional ap-plication sharing systems, where collabora-tion is transparent to the developers andusers of the shared applications, are inef-ficient and lack key support for groupwareprinciples such as concurrency control andgroup awareness. Additionally, examplesare given to strengthen these claims. Theauthors then introduce the collaboration-transparent JAMM framework, where fea-tures previously available only within spe-cialised, collaboration-aware applicationsare provided, such as multiuser widgets and
awareness mechanisms.The JAMM architecture operates by re-
placing conventional user interface compo-nents with multiuser versions at runtime;this article demonstrates the system usingan example of a document editor that isconverted at runtime to support concurrentediting, telepointers, and a ‘radar view’ ofall users currently editing the document.
A pleasing aspect of this article is thewell-described evaluation section, where re-sults suggest that JAMM is faster for taskcompletion and preferable to the NetMeet-ing application sharing system for severalsimple text-editing trials that varied in de-gree of required collaboration.
[3] Peter Spellman, Jane Mosier, Lucy Deus,and Jay Carlson. Collaborative VirtualWorkspace. In Proceedings of the Inter-national ACM SIGGROUP Conference onSupporting Group Work, pages 197–203.ACM Press, NY, Phoenix, AZ, November1997.
Annotation: This paper introducesthe Collaborative Virtual Workspace - a”placed-based” system for supporting bothsynchronous and asynchronous collaborativetools. The authors argue that a merger ofsession-based tools such as netmeeting [1]and document-based tools such as LotusNotes [4] is required, because realistic col-laboration requires both solid support forreal-time communication as well as docu-ment management.
This paper describes the CVW architec-ture, and details the lessons learnt from itsinitial deployment. CVW uses the roomsmetaphor to separate different groups ofusers, and provides video and audio con-ferencing, shared whiteboards, and a doc-ument tracking utility. Roles for users areloosely defined, and searching of a collabora-tive workspace for people and documents ispossible. Whist the CVW framework is nowseveral years old, this paper is well worthreading for a detailed example of a large-scale collaboration manager.
[4] Berthold Reinwald and C. Mohan. Struc-tured Workflow Management with Lo-tus Notes Release 4. In Proceedingsof the 41st IEEE Computer Society In-ternational Conference (CompCon), pages
26
451–457. Santa Clara, California, February1996. URL http://citeseer.nj.nec.com/reinwald96structured.html.
Annotation: This paper describes howto implement customised workflow manage-ment using Lotus Notes Release 4. Whilst attime of writing the seminal reference for theLotus Notes architecture is the Lotus NotesDeveloper’s Guide, Version 4.0, Cambridge,MA, the paper referenced here also gives agood description of the Lotus Notes architec-ture, and this paper has been peer reviewed.
This paper focuses on implementation oftools for workflow management, however,the background information and referencelist provides a comprehensive overview ofthe Lotus Notes architecture. The paper dis-cusses the Notes database, the address book,multimedia documents, customisable forms,event-based agents, and user views. LotusNotes, as described in this article, is a typicalexample of a workflow management frame-work, where artifacts are routed to specificusers based upon the defined processes androles. A handful of collaborative softwaretools have been constructed using LotusNotes, including the GWSE data repositoryand the CAIS software inspection tool (seeSection 2.4 on page 11 and Section 2.1 onpage 5 respectively).
[5] Ludwin Fuchs, Steven E. Poltrock, and In-grid Wetzel. TeamSpace: An Environmentfor Team Articulation Work and VirtualMeetings. In DEXA Workshop, pages 527–531, 2001.
Annotation: This article presentsTeamSpace, a collaborative workspacesystem that supports general developmentteams. Within this article, screen-shots ofthe TeamSpace system show web interfacesfor group discussions, shared project man-agement utilities, and an artifact trackingsystem. TeamSpace allows general objectsto be shared such as text documents, meet-ing schedules, and presentations. A generalpool of formally-specified information foreach development team is also shared,including a breakdown of each task, statusreports, testing plans, and work artifactssuch as documents. Task are broken downto small single-person components, andthe TeamSpace architecture monitors theprogress of completion, and is also used to
facilitate group communication.This article also provides an objective
discussion, relating TeamSpace to otherworkspace collaboration systems withinthe field of research. The paper concludesby proposing enhancements to TeamSpacethat will allow it to systematically monitorchanges in artifacts and notify all relatedusers.
[6] W. Appelt. WWW Based Collaborationwith the BSCW System. In Proceedings ofthe 26th Conference on Current Trends inTheory and Practice of Informatics, number1725 in Lecture Notes in Computer ScienceSeries, pages 66–78. Springer-Verlag, Milovy,Czech Republic, November 1999.
Annotation: BSCW (Basic Support forCollaborative Work) was introduced in 1995at the first web-based groupware system.Since its introduction, many research andcommercial projects have used BSCW toprovide asynchronous and synchronous col-laboration between participating users, us-ing the shared-workspace metaphor. BSCWis still being developed today—the last ver-sion release was in February 2004. This pa-per presents a concise overview of the morerecent versions of BSCW.
The paper describes the general goals,implementation, and features of BSCW, in-cluding several application screen shots andminor examples of usage. The paper ad-dresses the full range of BSCW features, in-cluding the event model, user authentica-tion, search facilities, and discussion man-agement. Only a brief mention of relatedwork and the theoretical underpinnings forBSCW is made, but the overview is very in-formative.
[7] Ward Cunningham. Wikiwikiweb frontpage, April 2005. URL http://c2.com/cgi/wiki?WikiWikiWeb.
Annotation: Wiki is a collective termused to describe websites that are editableby all subscribed users, and are described byits inventor as”The simplest online databasethat could ever work”. There have beenmany implementations of discussion serversthat allow collaborative editing of pages, butWikis have been immensely popular withcomputer scientists since their introductionin the mid 1990s. An important feature of
27
Wikis is their policy of allowing any userto add new pages, and to automatically linkpages both from within the Wiki and otherexternal Wikis and web resources. Wikis donot allow synchronous editing of pages, butdo allow CVS-based page locking for control-ling multiple concurrent edits. Through theuse of a CVS back-end, the full change his-tory of an evolving wiki is accessible.
The URL given in this listing is the frontpage for the wiki wiki web. From here thereare many links to frequently asked questionsand answers, wiki editing tutorials, and dis-cussion documents. Wikis are already usedfor collaboration in software development,and will undoubtedly play a large part infuture Cse tools in one form or another.The idea of computer-supported editing andautomatic management of hypertext docu-ments, as provided by Wikis, is likely to bepopular with the next generation of group-ware technologies.
3.2.4 Constructed Applications
This listing presents articles which describethe implementation of applications constructedwith groupware toolkits. These papers are in-tended to give the Cse developer insight into theadvantages and disadvantages of using group-ware, assisting in the design and implementa-tion decisions of Cse tool mechanisms and userinterfaces.
For additional papers of this nature, sec-tion 2 presents a paper describing GroupARC,a collaborative tool built from the GroupKittoolkit. The GroupKit toolkit, as presented insection 3.2.2, also includes comments from de-velopers who have used the toolkit to constructcollaborative applications.
Publications
[1] Neville Churcher and Clare Churcher. Real-time Conferencing in GIS. Transactions inGIS, 3(1):23–30, March 1999.
Annotation: This article discusses howCSCW has been applied to Geographi-cal Informations Systems (GIS). A sys-tem for collaborative GIS browsing, namedGroupARC, was developed using the Group-Kit multiuser toolkit, and this paper de-scribes the lessons learned from the devel-opment of this system. GroupARC allows
the display of spatial information, typicallymaps or other rich data sets, in a relaxed-WYSIWIS manner. This system is a compre-hensive example of a tool that successfullyuses the GroupKit toolkit; browsing this pa-per will give the reader a solid perspective onthe task of constructing non-trivial collab-orative applications using groupware tech-nologies.
[2] Donald Cox and Saul Greenberg. Sup-porting Collaborative Interpretation in Dis-tributed Groupware. In Proceedings of theACM Conference on Computer SupportedCooperative Work, pages 289–298. ACMPress, Philadelphia, PA, December 2000.
Annotation: This paper presents thePreSS—a system for supporting distributedcollaborative interpretation within a spatialvisual workspace, where collaborative inter-pretation is defined as the process of cate-gorising a set of many fragments of informa-tion into a coherent set of meaning descrip-tions. Whilst collaborative interpretation isnot directly related to collaborative softwareengineering, this paper is valuable for its de-scription of the implementation and evalua-tion of a complex system that accommodatesthe social dynamics of its users.
PreSS was developed using GroupKit,and this paper presents numerous screen-shots giving the reader an appreciation ofthe types of interfaces that are possible toconstruct with this toolkit. The evaluationsection is also valuable, in particular thepoints raised relating to issues workspaceawareness between users.
3.2.5 Limitations of CSCW
Despite the original claims and promises madein CSCW and groupware literature, it is still adaunting task to implement Cse tools. CSCWtechnology is based on the support of unstruc-tured and transient documents that have littleor no semantic relationship to other artifacts.This is converse to the foundations of softwareengineering: highly structured, evolving docu-ments that have vast interdependencies and longlifetimes.
The literature surrounding CSCW originallyspoke of solving all problems related to com-puterised collaborative work, suggesting that
28
Cse would be trivial to implement once tech-nology had naturally progressed. Unfortunately,twenty years on from those claims, we are still nofurther to having a ‘silver bullet’ technology thatfacilitates collaborative software engineering orany other complicated application. Accordingly,the literature listed here discusses the failings ofCSCW, and makes reassessments of the usefulscope of CSCW technology.
Publications
[1] Jonathan Grudin. Why CSCW ApplicationsFail: Problems in the Design and Evaluationof Organizational Interfaces. In D. Marcaand G. Bock, editors, Groupware: Softwarefor Computer-Supported Cooperative Work,pages 552–560. IEEE Press, Los Alamitos,CA, 1992.
Annotation: This is an excellent andwell cited article written when research intoCSCW was in its infancy. Grudin showedgreat insight when he pointed out in thisarticle that many CSCW applications willfail given the current approach into CSCWapplication development. The key problemsidentified are: the disparity between thepeople making the effort to build the sys-tem and the people who use the system,the poor intuitions of developers for build-ing multi-user applications, and the extremedifficulty in analysing and evaluating suchcomplex applications. This paper gives a de-tailed discussion on each of these problems,and presents four case studies of applicationsthat have already failed due to some or allof these problems.
The conclusion to this paper suggeststhat we must have a better understandingof how groups function and evolve before at-tempting to develop an application to auto-mate the collaboration. This paper also in-clude very useful appendices, where discus-sions related to different types of collabora-tive applications are presented. The appen-dices conclude by stating that CSCW ap-plications should not cause considerable dis-ruption to users and their roles if they are tobe introduced and utilised successfully.
[2] Jonathan Grudin. Groupware and social dy-namics: Eight challenges for developers. InCommunications of the ACM, volume 37 of1, pages 92–105. ACM Press, January 1994.
Annotation: This is another high qualitydiscussion document from Grudin related tothe challenges and perils of CSCW develop-ment. This article can be viewed, in part, asan updated of Grudin’s earlier paper “WhyCSCW applications fail” [1], but it also pro-vides some examples of CSCW successes. Af-ter providing a brief history of groupware,this paper described eight problem areas—much of which builds upon the problems pre-sented previously. The conclusion gives ad-vice on how to build successful CSCW ap-plications, including extending existing sys-tems rather than writing applications fromscratch, finding niches where existing group-ware applications succeed, and ensuring thatthe groupware systems benefit all users ofthe system, not just people in specific roles.
3.3 Source Code ConfigurationManagement
Source Code Configuration Management (SCM)systems are core to software engineering. Suchsystems enable the versioning, branching andmanagement of software engineering artifacts toease the burden of producing multiple versionsof software products derived from the efforts ofpotentially hundreds of developers. Even forsingle user projects, the benefits gained fromSCMs including the ability to roll-back changesmakes the use of such systems warranted andvaluable. SCMs also attempt to keep sourcefiles coordinated as they evolve by allowing reg-ular check-ins and project builds. Without suchfacilities, it is possible for individual coding ef-forts to skew the project into several separateand hard-to-consolidate directions.
SCMs address the fact that many peoplemay be working on the same code base, andthat often several developers will want to workon the same source file. To facilitate controlledfile sharing, two schemes are typically employed:file locking or file coping and subsequent merg-ing. As explained by the various articles in thissection, both approaches have their advantagesand problems. Regardless of the issues sur-rounding the use of SCMs, such systems are afundamental component for most software engi-neering tools, both collaborative and single user.
This section provides references to articlesabout conventional SCMs, as well as articles on
29
the latest versions of SCMs that have some ma-jor advantages over their predecessors. This sec-tion also provides some Cse specific SCM sys-tems as well. The articles in this listing are es-sential reading for Cse researchers—it is imper-ative that an understanding of the challenges ofconcurrent development is obtained before con-sidering the development of Cse tools. Addi-tionally, social protocols dictate the use, effec-tiveness and impact of SCM systems; this aspectof SCM use is discussed within several of the ar-ticles presented here.
Publications
[1] Walter F. Tichy. RCS — A System for Ver-sion Control. Software — Practice and Ex-perience, 15(7):637–654, 1985.
Annotation: This is the main paper pub-lished to describe RCS (a Revision ControlSystem), one of the first globally-popularSCM systems. While readers could also lookat ”The Source Code Control System”, M. J.Rochkind, IEEE Transactions on SoftwareEngineering, December 1975 as the first everpublished SCM system, this paper by Tichyis probably the most relevant article relatedto the first generation of modern day SCMsystems. Even this paper is very old now,but it is an important read for those wishingto understand the basis of how SCM systemsworks today.
This paper represents both a design doc-ument and a user manual for the RCS sys-tem. It presents the concept of branching indetail, and also discusses how the Make util-ity and RCS can be integrated to managesoftware engineering projects. Other top-ics included in this paper include a discus-sion about the fundamentals of delta stor-age, algorithms used to computing file deltaswithin RCS and details of locking in RCS.The paper then provides statistics of Pur-due’s RCS research repository, and con-cludes with a survey of other SCM toolsavailable in the year of publication.
[2] Brian Berliner. CVS II: Parallelizing Soft-ware Development. In Proceedings of theUSENIX Winter 1990 Technical Conference,pages 341–352. USENIX Association, Berke-ley, CA, 1990.
Annotation: Surprisingly, there are not alot of academic papers on CVS. This paper,
however, is well cited and gives a good his-torical account of how CVS was conceivedand developed. CVS is a front-end thatsits atop RCS, and provides a copy-modify-merge optimistic scheme of version control,as opposed to the lock-modify-unlock mech-anism employed by RCS and SCCS. CVSwas a natural progression from these firstgeneration of SCM systems, and gained im-mediate widespread use. In the decade af-ter the publication of this article, CVS hasbeen enhanced considerably, with server-based CVS being one of the most significantadvances.
This paper gives a basic overview of theCVS architecture, showing how optimisticlocking operates, and how the files can bepatched upon concurrent modification. Thepaper also shows how CVS can be used tobranch between revisions, using two versionsof a kernel as an example. This paper givessome statistics on file changes for the Prismakernel, showing how many files and lines ofcodes have changed, for example. Finally,the paper makes brief mention of CVS’s per-formance. This is an old paper now, but itis useful in understanding how today’s revi-sion control systems work, and where suchtechnologies originated from.
[3] Open Source Development Network. Source-Forge.net Home Page. Internet Url, OpenSource Technology Group, July 2003.URL http://sourceforge.net/docman/display_doc.php?docid=6025&group_id=1/.
Annotation: There are no definitive aca-demic papers that describe source forge, anopen-source code repository, but as it is theworld’s largest source code repository is itwell worth mentioning within this annotatedbibliography. The article given here providesa brief overview of source forge, including adescription of what open source software is,and where to obtain further information onsource forge.
Source forge is essentially a web-based in-terface for a CVS repository, but in addition,each project has a home page, a bug track-ing database, a documentation area, usagestatistics, public forums and mailing lists.At the time of writing, there were 100,000projects with 1,000,000 users in the sourceforge repository. The most popular project,
30
GAIM, has had to date 13,000 file commits,3000 file adds, and the web pages within theproject have been accessed 34 million timesin the last four years. The basic version ofsource forge is free to use via the main sourceforge servers, or you can locally install an en-terprise edition that provides better securityand integration options from a commercialvendor.
[4] Ben Collins-Sussman, Brian W. Fitzpatrick,and C. Michael Pilato. Version Controlwith Subversion. O’Reilly Media, 1 edi-tion, June 2004. URL http://svnbook.red-bean.com/en/1.0/svn-book.pdf.
Annotation: Subversion is becoming ac-cepted worldwide as the replacement forCVS. Subversion is essentially a rewrite ofCVS, with the same underlying repositorymodel, but without the bugs and designflaws. Major advantages over CVS are: itincorporates directories and symbolic linksas well as files in the repository, and as aresult, it can now handles file renames anddeletes as modification events rather thantreating these actions as the end of a revisionbranch. Subversion also handles atomic com-mits, which means that either all changesare accepted, or none at all. This preventsproblems that can occur when only a subsetof updated files are checked back into therepository. Subversion can also handle sev-eral different supporting network layers suchas Webdav and secure shell (SSH).
This book is the official documentationfor subversion. It is available free on line,and a hard copy is available for purchasefrom O’Reilly Media. This is a very well writ-ten book that provides three main aspects:it gives an excellent overview of the subver-sion system, it provides a clear and conciseuser manual, and it also gives a lot of ma-terial for the further development of subver-sion and associated tools. For articles relatedto subversion that have more academic con-tent, the best place to look is actually papersrelated to CVS, as subversion is based nearlycompletely on CVS.
[5] Mark C. Chu-Carroll and Sara Spren-kle. Coven: Brewing Better Collabora-tion through Software Configuration Man-agement. In SIGSOFT ’00/FSE-8: Pro-ceedings of the 8th ACM SIGSOFT Inter-
national Symposium on Foundations of Soft-ware Engineering, pages 88–97. ACM Press,New York, NY, USA, 2000. ISBN 1-58113-205-0.
Annotation: This paper introducesCoven, a collaboration-centric SCM thatsupports multiple organisational views ofsoftware artifacts, driven by a query-basedrepository The paper argues that people useSCM to work as a team on a subset of aproject, and Coven’s hierarchical structureis based upon this observation. Coven al-lows soft-locking of artifact fragments, whereusers can break the lock if they really wishto concurrently modify an artifact. This re-sults in notification to all involved parties.This paper states that Coven does not in-troduce any new features to SCM, but doescombine many useful features of existing sys-tems to provide a SCM system suitable foruse within collaborative software engineer-ing tools.
Aside from describing the Coven archi-tecture, this paper gives realistic scenarios ofcollaborative development, and shows howCoven is used within such a setting. The pa-per also provides a solid section on relatedwork, and concludes with directions for fu-ture work such as building a user interfacefor collaborative development and studyingreal patterns of collaboration under Coven.
[6] Cleidson R. B. de Souza, David F. Redmiles,Gloria Mark, John Penix, and MaartenSierhuis. Management of Interdependen-cies in Collaborative Software Development.In International Symposium on EmpiricalSoftware Engineering (ISESE), pages 294–303. IEEE Computer Society, Rome, Italy,September 2003. ISBN 0-7695-2002-2.
Annotation: This article presents aneight-week observation of a group of 31 co-located software engineers working on a suiteof tools within the NASA/Ames ResearchCentre. The code base consisted of 1 millionlines of code, and the engineers were com-prised of a development team and a testingteam. The paper examined the activities ofthe software engineers to discover how inter-dependencies were managed from the view-points of both formal and informal softwareengineering methodologies.
The paper gives an interesting discus-sion on the realities of industrial software
31
development, in particular how the infor-mal approaches are utilised to address short-comings in tool support for the more for-mal methods. For example, email was usedwhenever a file is checked back in to alertothers to possible conflicts. Whilst this wasnot part of the formal software developmentprocess, it was necessary to employ email,due to no other notification mechanism inplace. By comparing the formal methodolo-gies with the actualities of team-based de-velopment, this paper gives useful insight asto where further advancements can be madefor computer supported collaborative soft-ware engineering. This paper also providesmany useful references to previous case stud-ies and discussion papers.
[7] Dave Thomas and Kent Johnson. Or-well: A Configuration Management Sys-tem for Team Programming. In Proceedingsof Object-Oriented Programming Systems,Languages, and Applications (SIGPLAN),pages 135–141. San Diego, CA, 1988.
Annotation: This paper presents Orwell,a configuration management tool for multi-person Smalltalk projects. Orwell supportsthe sharing of source code and object code,and also provides version control. The au-thors claim that whist they only describe theimplementation of a tool for multi-personSmalltalk programming, many of the designideas can be easily adapted for other lan-guages. Orwell defines classes as the unitof ownership with a Smalltalk project, andprojects can be developed with or withoutthe presence of a central server.
Whilst Orwell has been placed in the con-figuration management section of this bibli-ography, it could also be placed in the sec-tion related to existing Cse tools, as it pro-vides many of the services that a collabora-tive software engineering tool requires, suchas file sharing, revision control, and class li-brary browsing. The more recent Tukan sys-tem (see Section 2.3 on page 8) uses Orwellas the underlying mechanism for its collab-orative services.
3.4 Human Computer Interaction
A vast amount of Human Computer Interaction(HCI) research has been published over the lastfew decades. Whilst virtually all HCI research is
relevant to Cse, this section contains a selectionof papers that are directly related to the designof Cse tools and frameworks. There are cer-tainly many other HCI papers that investigateteam work, coordination of artifacts, and sup-porting awareness and collaboration, but theseare not mentioned here for the sake of brevity.The papers presented in this section lead inter-esting discussions on the usefulness and effec-tiveness of collaboration within software engi-neering processes and tools.
HCI papers typically present micro-levelevaluations where problems are isolated into amost simplistic form. This is a scientificallycorrect and well-accepted practice, but unfor-tunately for the purposes of Cseresearch, suchresearch can be too trivial for software engineer-ing purposes—gainly research into software en-gineering requires an acceptance that tools arecomplex and artifacts are numerous, and thatsimplification can yield results that are not sig-nificant in ‘real world’ terms. Accordingly, mostHCI papers that address Cse only assess pro-gramming within isolated environments such asspreadsheeting tools. Therefore, the Cse re-searcher needs to be aware that HCI studies maynot necessarily scale to realistic software engi-neering scenarios—often the papers are usefulfor general guidance only.
Of the papers presented in this section, manygive detailed information on user trials and toolevaluations related to program understanding,task completion rates and levels of user satisfac-tion under collaborative settings. For the Cseresearcher, such papers are useful in terms ofproviding general insights about patterns of col-laboration in software engineering. These pa-pers are also useful for providing examples ofwell-formed scientific evaluations.
Publications
[1] M. A. Storey, K. Wong, and H. A. Muller.How Do Program Understanding Tools Af-fect How Programmers Understand Pro-grams? Science of Computer Programming,36(2–3):183–207, 2000.
Annotation: This paper presents an eval-uation of the effectiveness of software en-gineering tools to reducing cognitive over-heads and improve program comprehension.The paper includes a detailed discussion ofSNiFF+, a well researched and contrastedmotlier development environment. SNiFF’s
32
collaborative features not used in this study,but this paper does provide an example ofa well-planned evaluation to explore howtools affect programmers understandings. Tolearn more about SNiFF, its collaborativefeatures are presented in section 2.3.
A user evaluation of 30 subjects is de-scribed where a range of tools was provided.The task for users was to identify units ofcode or to answer questions related to thestructure and semantics of a non-trivial pro-gram. Users were free to use whichever toolsthey pleased, and they were also allowed touse whatever features of the individual toolsthat suited. After describing the experimen-tal design, many detailed discussions are pre-sented on the findings, with numerous ob-servations given. The main outcomes of thisstudy were that the tools did appear to en-hance users comprehension strategies, or inother words, the exploratory features of thetools were utilised. In some cases, however,information overloading was observed. Otherfindings of the evaluation were that usersfelt the dependency visualisations were use-ful for program comprehension, as too wasthe ability to switch between high and lowlevel views.
Apart from a well described and insight-ful evaluation, this paper provides an ex-cellent range of references for further read-ing into program comprehension tools. ForCse researchers, this paper is worth readingfor details as to what users do when theyare navigating around source files within acomplex program. The paper also provides awell-formed template for further evaluationsof this type, which is useful for future Csetool evaluations.
[2] J. W. Atwood, M. Burnett, R. Walpole,E. M. Wilcox, and S. Yang. Steering Pro-grams Via Time Travel. In IEEE Symposiumon Visual Languages, pages 4–11. Boulder,CO, September 1996.
Annotation: This paper introduces thedimension of time for supporting the devel-opment of software. Whilst the topic is notdirectly related to collaboration, it is usefulfor investigating how future Cse tools couldsupport new modes of development, partic-ularly from the aspect of private work. Thepaper uses the Forms/3 spreadsheet inter-face as the example programming environ-
ment, and illustrates how programmers canmove back and forward in time to view dif-ferent runtime program states, which the au-thors argue can assist in debugging and pro-gram development.
This article has a lot of content aboutvisual programming languages. It also dis-cusses a platform different to most softwareengineering tools, where runtime inspectionand design time coding are not usually com-bined as they are in spreadsheets. Regardlessof these differences, however, this paper isvery useful to Cse researchers in terms ofproject exploration, problem isolation anddevelopment visualisation. The paper sug-gests possibilities that could be built intofuture Cse tools, and shows approaches tosupport private workspaces within a globalproject.
[3] Joanna DeFranco-Tommarello, Fadi P.Deek, Starr Roxanne Hiltz, Julian P.Keenan, and Cesar Perez. CollaborativeSoftware Development: Experimental Re-sults. In Proceedings of the 36th Hawaii In-ternational Conference on System Sciences(HICSS’03). Big Island, Hawaii, January2003.
Annotation: This article presents one ofthe very few papers that details a structuredexperimental design for a Cse evaluation.A study was undertaken to assess whethera collaborative system could help subjectsunderstand programming problems betterand devise superior solutions. 174 subjectswere tested over a three week period, us-ing combinations of a collaborative system,groupware, and control configurations. Twojudges assessed the approach and solutionof each group, with results suggesting mostoutcomes were the same regardless of thetool mode used.
This paper is an important read due toits well written description of a thoroughlyplanned Cse evaluation, rather than becauseof its findings. Of the few significant results,however, it was shown that under collabora-tive conditions, participants did manage tounderstand the programming problem morethoroughly and were also judged to haveplanned their solutions better.
[4] Bonnie A. Nardi and James R. Miller. AnEthnographic Study of Distributed Problem
33
Solving in Spreadsheet Development. InProceedings of the Conference on ComputerSupported Cooperative Work, pages 197 –208. Los Angeles, CA, October 1990.
Annotation: This paper presents a re-fined version of the original article ”Twin-kling Lights and Nested Loops”. The basisof this paper is a discussion into the collab-orative design and development of spread-sheets, which is of a high relevance to Cseresearch. The paper gives details on casestudies and user comments related to thedevelopment of spreadsheets within organ-isations, and shows how multiple users co-operate in designing, developing and debug-ging them. An interesting observation madein this article is that the users generally havea high success rate in developing functionalspreadsheets, even though spreadsheets werenever intended to support collaborative de-velopment.
This paper observes that cooperativespreadsheet development within the inves-tigated organisations was spontaneous andcasual, where users employed existing infor-mal social networks to initiate collaboration.The study also observed that many differ-ent levels of programming ability go into thedevelopment of single spreadsheets, spread-sheets are complicated with complex controlstructures, macros, and graphs, yet the de-sign and development of spreadsheets is stilla relatively easy process for most users.
This paper represents a very interestingread for all user interface designers: it showsa success story for collaborative develop-ment, makes some very informative observa-tions, and provides guidelines for the futuredevelopment of groupware and collaborativesystems. For Cse researchers, it provides aninteresting story of how socially driven col-laboration can lead to the successful devel-opment of complex computational artifacts.
[5] E. M. Wilcox, J. W. Atwood, M. Bur-nett, J. J. Cadiz, and C. R. Cook. DoesContinuous Visual Feedback Aid Debuggingin Direct-Manipulation Programming Sys-tems? In Proceedings of CHI 97: Hu-man Factors in Computing Systems. At-lanta, GA, 22-27 March 1997.
Annotation: This paper does not di-rectly related to user collaboration, but doesprovide an interesting and well structured
evaluation into continuous visual feedback,something very important to Cse research.The study used the Forms/3 Visual Pro-gramming Language (VPL) to study 29 stu-dents, half of which were used as a controlgroup. The evaluation showed that whilstcontinuous feedback did not significantlyhelp in general, there were specific taskswhere it did. The study also showed thatsubjects made significantly more changeswhen working with live continuous visualfeedback. Another important observationwas that three factors appeared to controlthe results: type of bug, type of user andtype of problem.
This is a good article to read prior todesigning evaluations of Cse systems as itgives a detailed illustration of a well struc-tured and carried out evaluation. This arti-cle also gives an interesting discussion andinsight into the merits of continuous visualfeedback, a feature that most Cse systemsaim to provide.
3.5 Distributed Systems
In terms of providing facilities for interprocesscommunication, groupware technology can offerbasic distributed communication support. Forthe carrying of application specific data, or forwhere more complex and efficient systems are tobe supported, then a distributed systems tech-nology may be the only answer to support Csetools.
Distributed systems aim to make the bound-aries between computers invisible, a term of-ten referred to as global computing. Dis-tributed systems provide facilities to supportclient/server, pair-to-pair, and grid computingarchitectures. For the development of Cse tools,distributed systems allow tools to communicatewith each other, send and receive custom data,access peripheral servers, and make calls to re-mote functions and methods.
Distributed systems technology has madesignificant advances in the last few years, par-ticularly with the introduction of .net, J2EE,SOAP, and web services, all of which are ex-plained in the annotations within this section.Due to these advances, it is possible to imple-ment very comprehensive collaborative featureswithin Cse tools, with functions more advancedthan those typically supported in conventional
34
groupware toolkits. Additionally, with the ad-vent of the Internet and wireless networking, thephysical boundaries of computer networks arediminishing, allowing Cse tools to be supportedfar further than just the local network.
This section presents many of the key dis-tributed systems papers and specifications. Forthe Cse researcher, the references here provideoverviews, descriptions and tutorials of the ma-jor distributed systems architectures and proto-cols. By becoming familiar with these articles,the Cse researcher should have enough under-standing of distributed systems technologies tounderstand the challenges and goals of this areaof research, and to make the correct architec-tural selection for Cse tool development.
Publications
[1] David Chappell. Understanding .NET.Independent Technology Guides. AddisonWesley, 1st edition, May 2002.
Annotation: There are now hundredsof books and articles on Microsoft’s .netarchitecture. The book given here presentsan easy to read lightweight tutorial on thefundamentals of the architecture along withmany useful references for more in-depthreading. The .net framework is a collectionand refinement of the previous generationof tools and technologies for the Windowsplatform of operating systems. Whilst im-possible to describe in a single paragraph,it can be viewed as a way of allowing pro-grams written in any language to commu-nicate, even in a distributed setting.
Any distributed application develop-ment on the Windows platform will nowrequire the use of the .net framework.Through web services, soap, xml, a com-mon language runtime model and net-work centric APIs it is possible to rapidlydevelop complex distributed applicationssuch as Cse tools, and this book is an excel-lent starting point to introduce and explainall the related technologies and languages.
[2] Jim Keogh. J2EE: The Complete Refer-ence. McGraw Hill/Osborne, California,USA, 1st edition, 2002.
Annotation: Java 2 Enterprise Edi-tion (J2EE) can be viewed as Sun’s alter-native to Microsoft’s .net framework, al-though it can be shown historically that
J2EE has been around for longer than .net.J2EE contains a vast range and number ofJava technologies to support complex com-mercial applications and services. Such en-terprise technologies include web services,databases, interconnectivity facilities, xmland servlets. The book listed here presentseach of these technologies in turn, givingcomprehensive explanations and tutorials.
Cse tools will require the use of dis-tributed systems technology, and the ser-vices of J2EE are attractive. Java 2 Stan-dard Edition (J2SE) has many built-in fea-tures that would be useful to Cse tooldevelopers: platform independence, ven-dor support, type reflection and network-centric language features. With J2EE, de-velopers also have the support of databasesystems, web services and interconnectivityAPIs. Accordingly, this book is well worthreading for the Cse researcher who wantsto know the design possibilities and im-plementation details of complex distributedapplications.
[3] Tim Bray, Jean Paoli, C M Sperberg-McQueen, Eve Maler, and FrancoisYergeau. Extensible Markup Language 1.0Third Edition. Technical report, W3C Con-sortium, February 2004. URL http://www.w3.org/TR/REC-xml.
Annotation: In terms of distributed sys-tems, XML is becoming a leading technol-ogy for vendor-independent transfer of ap-plication data between processes. The ref-erence provided here is the official XMLspecification recommendation of the WorldWide Web Consortium (W3C). The mainpurpose of this document is to providetechnical details for vendors that imple-ment XML-compliant technologies, how-ever, many other useful sections are pro-vided giving the background of XML, us-age examples, and references to many otheruseful articles for further reading.
There are many books that give detailedtutorials on the use of XML, in fact, most ofthe books given in this section’s listing havechapters on XML. For the Cse researcher,however, the article presented here is an ex-cellent starting point for learning about thestructure and purpose of XML—a technol-ogy core to many modern distributed sys-tems.
35
[4] Nilo Mitra. SOAP Version 1.2 Part 0:Primer. Technical report, W3C Consor-tium, June 2003. URL http://www.w3.org/TR/soap12-part0.
Annotation: This article presents a sim-ple overview of the Simple Object AccessProtocol (SOAP). SOAP is employed asa lightweight protocol for exchanging well-defined information in a distributed envi-ronment, and is a key driver for the suc-cess of web services. Web services are com-ponents that provide client applicationswith programmatic access to databasesand other resources, which effectively re-places server-side web page access to re-mote servers with more intelligent alterna-tives.
As described in this article, SOAP mes-sages, which provides the transportationbackbone for web service communication,are defined entirely in XML. Key to thesuccess of SOAP in providing a globally-adopted distributed messaging frameworkis its vendor, technology, and language neu-trality.
SOAP provides a way to communicatebetween distributed applications in a man-ner that is simpler than other interpro-cess communication methods such as IIOPand DCom. Additionally, it has gained sup-port from main industry cooperations suchas Microsoft, IBM and Sun Microsystems.SOAP was designed to operate over HTTP,which gives it the benefit of not requiringspecial firewall configurations. For the Cseresearcher, an understanding of web ser-vices, and more specifically, SOAP, is essen-tial if tools are to be implemented that arecompatible with J2EE or the .net frame-work. Accordingly, the primer listed here isa suitable starting point for code examplesand tutorials related to SOAP and web ser-vices.
[5] Emerald Chung, Yennun Huang, ShaliniYajnik, Deron Liang, Joanne Shih, Chung-Yih Wang, and Yi-Min Wang. DCom andCorba Side by Side, Step By Step, andLayer by Layer. In C++ Report. Journalof Object-Oriented Programming, January1998.
Annotation: This article presents acomprehensive overview of DCom and
Corba. These technologies are now some-what obsolete in terms of distributed com-puting, but it is valuable for the Cseresearcher to have a basic understandingof their architectural structure. A basicknowledge of object request broker systemssuch as DCom and Corba is also very use-ful in helping understand the design andmotivation for modern frameworks such asJ2EE and .net.
This article does not present perfor-mance statistics, rather is represents a com-parison of the two frameworks. It discussesthree aspects of the frameworks: the ba-sic programming architecture, the remot-ing architecture and the wire protocol ar-chitecture. To make a comparison, the ar-ticle presents a simple application, and il-lustrates how it is implemented in both ar-chitectures. This article provides excellentreferences to the applicable specificationsfrom within the case studies, and also in-cludes other useful reference articles as well.
[6] Bobby Krupxzak, Kenneth L. Calvert, andMostafa H. Ammar. Implementing Com-munication Protocols in Java. In Com-munications Magazine, pages 93–98. IEEE,October 1998.
Annotation: This paper discusses theperformance and implementation details ofnetwork protocols implemented in the Javaprogramming language. Java is a networkcentric programming language, and this pa-per provides useful insight related to thecustomisation of networking for distributedtools, which is an important topic for Cseresearchers.
An excellent discussion is provided onhow to customize existing network proto-cols and implement custom protocols whenthe conventional ones are not suitable. Thisarticle shows that tool implementors havea large degree of flexibility in implementingcustomised networking capabilities, whichis useful reading for Cse researchers consid-ering the design of tools with custom net-working demands. The paper also is one ofthe very few to incorporate a discussion ofnetwork security issues and best practices.
[7] Java(TM) Message Service SpecificationFinal Release 1.1, Sun Microsystems,
36
March 2002. URL http://java.sun.com/products/jms/docs.html.
Annotation: The Java Messaging Sys-tem (JMS) represents the low-level dis-tributed communication API of the J2EEframework. The document presented heregives the definitive description of JMS andits API. JMS appears to be a reimplemen-tation of the Java Shared Data Toolkit (seesection 3.2.2), but with major enhance-ments to support both push-subscribeasynchronous messaging and point-to-pointsynchronous communication.
For the Cse developer this messagingframework is very useful; it provides mech-anisms to implement both central serverand tool-to-tool communication. The doc-ument presented here gives several codingexamples, API details and architectural de-scriptions. This is not, however, a tuto-rial document. It is instead a good start-ing point for learning the basic concepts ofthe JMS architecture and also servers as adefinitive specification document.
[8] RMI Architecture and Functional Spec-ification, Sun Microsystems, 2002. URLftp://ftp.java.sun.com/docs/j2se1.4/rmi-spec-1.4.pdf.
Annotation: This document introducesJava’s Remote Method Invocation (RMI)framework. RMI allows Java applicationsto call methods in remote processes, andany type of return value can be marshalledback to the calling application. RMI allowsthe development of fast, complex network-ing functions between two or more partici-pating applications, which makes it candi-date technology for many Cse tools. RMIis however a complicated framework, andrequires considerable coding and setup ef-fort. It is also normally restricted by fire-walls unless it runs in HTTP proxy mode.
For distributed client/server appli-cations, SOAP is fast becoming thenumber one technology. If customizedapplication-to-application data transmis-sion and method invocation is requiredhowever, then RMI is still an effectivemechanism. The article listed here providesa complete overview of RMI, coding ex-amples, and installation and execution in-structions. It also discusses the wire proto-col and garbage collection mechanisms for
those who require specialised informationon the RMI architecture.
[9] JINI Technology Architectural Overview ,Sun Microsystems, January 1999.URL www.sun.com/jini/whitepapers/architecture.html.
Annotation: The JINI framework is anarchitecture that allows network protocolsand services to be developed, published andused in an arbitrary manner. It is a com-plicated, expansive architecture, but es-sentially it provides users and applicationswith access to networked devices throughJava APIs. Additionally, it allows customcode to be written and installed automati-cally within a distributed system, modify-ing the network or networked services. Keyto the framework is the concept of servicediscovery, where network devices are madeavailable for sharing upon detection.
This paper talks about the goals, in-frastructure and discovery mechanisms ofJINI. Simple example usage scenarios andlinks to other useful references are pro-vided. JINI is a valuable mechanism forthe Cse researcher; it may well be a verysuitable technology for supporting complexnetwork functions and services in a veryeasy manner. This document provides agood starting point for those wishing tolearn about the JINI framework; it providesa concise overview of the general concepts,making good sense of a very complicatedand expansive technology.
[10] Carl Cook and Neville Churcher. A Pure-Java Group Communication Framework.Technical Report TR-COSC 02/03, De-partment of Computer Science and Soft-ware Engineering, University of Canter-bury, Christchurch, New Zealand, July2003.
Annotation: This article describes aPure-Java simplification of the Java SharedData Toolkit. Called caise.messaging, thisframework provides simple asynchronouscommunication capabilities between agroup of distributed processes with anevent-based delivery method. The paperlisted here describes caise.messaging’s de-sign and implementation, and provides auser manual with code examples.
There are many similar systems to
37
caise.messaging such as JGroups andTribe. For Cse researchers, however, thecaise.messaging system provides a simpleway for applications to join a meeting andsend and receive data, without the needfor RMI, XML, or any system configura-tion. The caise.messaging system has beenused as the distributed systems compo-nent for several applications, and gives Cseresearchers insight into how customisedgroup communication can be implemented.
3.6 Software Engineering Metricsand Visualisation
The field of software metrics and visualisationconcentrates on the analysis and extraction ofuseful metrics from software projects. Findingsare then presented back to engineers in a waythat is useful and minimises information over-loading. For Cse research, the field of softwaremetrics and visualisation is immediately inter-esting: the functions of metrics gathering andreporting are a core function of most Cse tools.Additionally, many Cse tools now employ vi-sualisations are their main mode of feedback,or provide visualisations as supplementary in-formation.
Software metrics and visualisation is usefulto software engineers as a independent area ofresearch. As software engineering becomes morecollaborative, however, visualisations may be-come even more important to the developers ofCse tools. The additional dimension of multipleusers and their interactions with artifacts overtime provides richer information to the softwareteam, but the correct modes of visualisation forCse tools are yet to be fully explored.
The field of software metrics and visualisa-tion may well be worth further investigation forCse researchers; metric generation by itself canbe very useful to support the monitoring of useractivity and team progress. The papers listedin this section provide basic reading for the Cseresearcher; for the interested reader, the papersprovided here also give references to other rele-vant metrics papers.
Publications
[1] Thomas Ball and Stephen G. Eick. SoftwareVisualization in the Large. IEEE Computer,29(4):33–43, 1996.
Annotation: This paper gives a compre-hensive motivation section on software vi-sualisation for improving program compre-hension. While this paper is now dated, itgives the Cse researcher a good backgroundon the goals of software visualisation, andpresents some typical visualisation tasks andoutputs.
The paper presents four visualation rep-resentations: line, pixel, file summary andhierarchical. Through five case studies, newvisualisation techniques are shown to ad-dress program comprehension. Techniquesinclude code age listings, program compar-isons, highlighting of deep nesting levels andruntime code coverage graphs. Key to all vi-sualisations is the concept of focus + context,where a global overview is provided withlocal detail. The paper concludes with aninteresting discussion on the problems fac-ing software visualisation researchers, suchas information overloading and graph layoutprocessing times.
This paper gives the Cse researchermany references to key articles on relatedwork, examples of prototype visualisations,and provides insight for potential Cse visu-alisations.
[2] Neville Churcher, Lachlan Keown, and War-wick Irwin. Virtual Worlds for Software Vi-sualisation. In A. Quigley, editor, SoftwareVisualisation Workshop (SoftVis99), pages9–16. 1999.
Annotation: This paper presents visual-isation of software engineering data and in-troduces a framework to produce such visu-alisations for Virtual Reality Markup Lan-guage (VRML) viewers. The paper discussesthe software visualisation issues of informa-tion overload, highly skewed distributions ofdata, and the importance of preserving out-liers within large data sets. The paper thendiscusses the use of VRML to represent suchdatasets in some novel ways such as 3D tree-maps, contrasting inheritance trees of dif-ferent modelling techniques, and visualisa-tions where large distributions of data aredisplayed in immersive worlds.
This paper is simple to comprehend yetgives considerable insight into the complexi-ties related to the visualisation of real-worldsoftware engineering data. A framework ispresented to transform and visualised such
38
data in VRML, providing insight into possi-ble Cse visualisations. This paper also dis-cusses the problems associated with gener-ating and displaying software engineeringdata, and such problems are applicable toCse researchers as well.
[3] M. Gogolla, O. Radfelder, and M. Richters.Towards Three-Dimensional Representationand Animation of UML Diagrams. In UML99—Beyond the Standard, pages 489–502,1999.
Annotation: This paper shows a varietyof Unified Modeling Language (UML) dia-grams represented in three-dimensional visu-alisations. As a point of inspiration for pos-sible Cse visualisations, this paper makesgood reading. The paper also introduces thepossibility of using animations to displayUML diagrams such as sequence diagrams.Even from a static, paper representation, theuse of animations appear intuitive as a mech-anism to illustrate diagrams that contain theelements of time and sequence.
The use of animation and 3D visualisa-tions to show the affects of change over timeis well suited for application within the fieldof Cse. This paper provides a good overviewof 3D representations of diagrams and thepotential for animated sequences to assistinformation display, and presents a range ofpossibilities for further study.
[4] Warwick Irwin and Neville Churcher. Ob-ject Oriented Metrics: Precision Tools andConfigurable Visualisations. In 9th Interna-tional Software Metrics Symposium. Sydney,Australia, September 2003.
Annotation: This paper addresses theimportance of extracting the correct metricsfrom programs through rigorous semanticanalysis of source code. The paper demon-strates the difficulties and inconsistencies inextracting metrics from source files usingstandard compiler generation techniques,and presents a framework for obtaining met-rics from standard grammars free from man-ual manipulation. The paper discusses atransparent pipeline which uses a standardgrammar and source files as the input, whichthen leads to XML-based parse trees and afull semantic model of the project. The pa-per concludes by presenting novel VRML vi-sualisations resulting from custom rendering
of a large application’s semantic model.This paper leads an interesting discussion
into the difficulties of extracting correct in-formation from source files based on theirlanguage’s formal specification. For the Cseresearcher, this is an interesting aspect, ascorrect and full information is required tosupport non-trivial Cse tools.
[5] Hideki Koike and Hui-Chu Chu. How Does3-D Visualization Work in Software Engi-neering?: Empirical Study of a 3-D Ver-sion/Module Visualization System. In ICSE’98: Proceedings of the 20th InternationalConference on Software Engineering, pages516–519. IEEE Computer Society, Washing-ton, DC, USA, 1998. ISBN 0-8186-8368-6.
Annotation: This short paper presentsa tool that visualises an RCS repositoryand allows users to execute RCS com-mands via the interface. Code repositoriestypically have numerous artifacts, branchesand dependencies, which makes them andideal candidate for visualation. This paperpresents a simple VRML visualisation ofRCS repositories and details an evaluationof the task completion rates when subjectsused the visual interface compared to thestandard RCS command line. Rather un-surprisingly, the subjects task completionrates were considerably lower when using theGUI-based system rather than the standardcommand line interface.
The evaluation presented in this paper isperhaps not highly significant to the progressof software engineering, but the paper isuseful for Cse researchers in that it clearlyshows the potential of software engineeringvisualisations and visual interfaces.
[6] James A. Jones, Mary Jean Harrold, andJohn Stasko. Visualization of Test Informa-tion to Assist Fault Localization. In ICSE’02: Proceedings of the 24th InternationalConference on Software Engineering, pages467–477. ACM Press, New York, NY, USA,2002. ISBN 1-58113-472-X.
Annotation: This paper presents aframework that analyses unit tests of sourcecode, and visualises statements in the codethat are highly correlated with failed exe-cutions. After demonstrating the way thatthe erroneous code correlations are gener-ated, the paper presents a system called
39
Tarantula, which displays a complete sourcecode listing shaded according to areas ofinterest. Evaluation of the system showedthat the correlation technique employed washighly effective for identifying erroneousstatements.
This paper provides an excellent exampleof visualising local detail within a global con-text. Developers of Cse systems can learnfrom this paper in terms of information lay-out and effective use of colour to assist invisualisations of collaborative software engi-neering information.
[7] Andrian Marcus, Louis Feng, andJonathan I. Maletic. Comprehensionof Software Analysis Data Using 3DVisualization, May 2003.
Annotation: To assist comprehension oflarge-scale programs, this paper introducesa tool called source viewer 3D (sv3D). Sv3Dextends many previous software visualisa-tion and program comprehension tools byproviding three dimensional visualisations ofthe same data. An interesting observationmade in this paper is that while large dis-tributions of data are easier to visualise in athree dimensional representation, the prob-lem of occlusion is significant. To alleviatethis issue, techniques for elevation and trans-parency are introduced, minimising the riskof obscuring distant data points.
This paper presents effective visualisa-tion techniques for complex programs in athree dimensional space. It provides insightinto the task of rendering real-world pro-grams to a displayable form, and the prob-lems that three dimensional visualisationscan bring. For the Cse researcher, this isanother paper that provides valuable guid-ance related to processing and visualisinglarge volumes of complex software engineer-ing data.
4 Concluding Remarks
The field of Cse is rapidly expanding. Thedemand for computer-supported collaborativesoftware engineering tools steadily grows as thefields of interprocess communication, groupwareand configuration management continue to ma-ture. This, coupled with recent technologicaladvances in IDEs and programming languages
gives the Cse researcher plenty of scope for sig-nificant advances within his or her area of inter-est.
Cse tools may take many forms and func-tions, and there is a lot of freedom and possiblealternatives for the developers of such tools. Abasic understanding of all the fields that con-stitute Cse is important however, and that wasthe motivation for compiling the bibliographypresented here. The listings provided in thisbibliography are intended to provide the Cse re-searcher with a solid understanding of the mostrecent advances within the field, and a briefsummary of key papers in all fields related toCse.
4.1 Future Directions for CSE
As the related fields of research progress, so toowill Cse. At present, the technology availableto Cse researchers enables the construction ofmany new and powerful tools. Research neverstops, however, and the following points makesuggestions in the related fields for the furtheradvancement of Cse tools and research.
Configuration Management Code reposito-ries could become synchronous, possiblyautomatically attempting to merge newcommits to the main build with individ-ual user’s working copies of files. Built-in collaborative code editors could also besupplied with code repository systems forpeer programmers and others who do notwish to work on separate copies of projectfiles.
CSCW and Groupware Groupware toolkitshave matured to be useful in minor ap-plications, or as a compliment to majorapplications. There is, however, a need toaddress wide area network latencies as net-working delays are often inevitable. Ad-ditionally, users are already are becomingmore distributed by moving out of localarea networks and into more error-proneinternet-based virtual private networks.
Software Engineering Processes A ques-tion yet to be asked within Software En-gineering is that of how the developmentprocess will change given realtime Csetools. At present, we only know soft-ware engineering methodologies that work
40
around the mechanisms of code reposito-ries, but perhaps more effective ways ofdevelopment are possible as tools becomemore collaborative. Similarly, further re-search into the patterns of collaborationwould be useful to fully expose the be-haviour within current software engineer-ing teams.
Software Visualisations and MetricsThere are many possibilities for furtherresearch into software metrics and visu-alisation as it relates to Cse. With thedimension of individual user activity overtime, and ability of realtime Cse toolsto capture programmer activity to a highdegree of accuracy and fine level of gran-ularity, the potential for new metrics andtypes of visualisations and animations isunbounded. Virtual and augmented re-ality visualisations for Cse data are stillonly in the early stages of investigation.
Human Factors Further human factors re-search into Cse could have a major im-
pact on the future directions of Cse tools.Many current Cse tools offer large vol-umes of feedback, both immediate and pe-riodically, yet little research has addressedhow useful feedback information is, or thecorrect ways to deliver such information tousers.
Distributed Systems Much research is goinginto distributed systems at present. Givenframeworks such as .Net and J2EE, it isnow possible to access objects and invokemethods on remote machines as if theywere within the same process. There isstill a high degree of programmer overheadin doing so however, and for Cse tools,completely invisible boundaries betweenremote processes would reduce the pro-gramming effort considerably. At present,for example, it is difficult to add a listenerfor an event in a remote process—to do sorequires a substantial coding effort. Even-tually, research may allow a group of sep-arate processes to share data and invokemethods natively.
41
Author Index
Abdel-Wahab, H., 24Altmann, J., 6Altmann, Josef, 8Ammar, Mostafa H., 36Appelt, W., 27Arisholm, Erik, 19Atwood, J. W., 33, 34Azada, Deeber, 9
Ball, Thomas, 38Ban, Bela, 24Beale, Russell, 13Beck, Kent, 19Begole, James, 26Berliner, Brian, 30Bischofberger, W. R., 10Bock, G., 29Boger, Marko, 7Booch, G., 14Borges, M. R. S, 11Borghoff, Uwe M., 9Braga, R., 11Bray, Tim, 35Brooks Jr., Frederick P, 16Brown, A. W., 14Bruegge, Bernd, 17Burnett, M., 33, 34Burridge, Rich, 24Busbach, Uwe, 13
Cadiz, J. J., 34Calvert, Kenneth L., 36Carlson, Jay, 26Cerecke, Carl, 8Chappell, David, 35Cheng, Li-Te, 10Chu-Carroll, Mark C., 31Chu, Hui-Chu, 39Chung, Charles, 6Chung, Emerald, 36Churcher, Clare, 28Churcher, Neville, 8–10, 13, 28, 37–39Cockburn, Alistair, 19Collins-Sussman, Ben, 31Cook, C. R., 34Cook, Carl, 9, 10, 13, 37Cox, Donald, 28Cunningham, Ward, 19, 27
Davidson, Ken, 35de Souza, Cleidson R. B., 10, 31
Deek, Fadi P., 33DeFranco-Tommarello, Joanna, 33Deus, Lucy, 26Dewan, Prasun, 9, 23Dewar, Rick, 5Dix, Alan, 13Dossick, Stephen E., 6Dourish, Paul, 13Dragan, Richard V., 35Dutoit, Allen, 17Dyb, Tore, 19
Eick, Stephen G., 38Estivill-Castro, Vladimir, 13
Favreau, J.P., 24Feng, Louis, 40Feuller, Chris, 12Fitzpatrick, Brian W., 31Fowler, Marin, 18Froehlich, Jon, 13Fuchs, Ludwin, 27
Gallis, Hans, 19Gamma, Erich, 18Garrett, Christopher, 20Gogolla, M., 39Goland, Yaron Y., 24Gorton, Ian, 6Graham, Elizabeth, 7Graham, Nicholas, 7Greenberg, Saul, 22, 23, 28Grudin, Jonathan, 29Guneet, Shijian Lu, 6Gutwin, Carl, 15, 25
Harner, Soren J., 12Harrold, Mary Jean, 39Hawryszkiewycz, Igor, 6Helm, Richard, 18Hilbert, David M., 20Hill, Jason, 25Hiltz, Starr Roxanne, 33Huang, Riri, 13Huang, Yennun, 36Hupfer, Susanne, 10
Iivari, J., 14Irwin, Warwick, 10, 38, 39
Jarzabek, Stan, 13Jeffries, Ron, 19
42
Johnson, Kent, 32Johnson, Ralph, 18Jones, James A., 39
Kaiser, Gail E., 6Kaplan, Simon, 12Keenan, Julian P., 33Keogh, Jim, 35Keown, Lachlan, 38Kessler, Robert R., 19Kim, O., 24Kishida, Kouichi, 15Kleinferchner, C. F., 10Koike, Hideki, 39Kopaee, Reza, 7Krupxzak, Bobby, 36Kvande, B., 24
Lewis, Scott, 11Liang, Deron, 36Lougher, Robert, 12
MacKinnon, Lachlan, 5Maler, Eve, 35Maletic, Jonathan I., 40Mangan, M.S., 11Marca, D., 29Marcus, Andrian, 40Mark, Gloria, 31Mashayekhi, Vahid, 12Matoso, M., 11Matzel, K. U., 10McConnell, Steven C., 17Miller, James R., 33Mitra, Nilo, 36Mohan, C., 26Mosier, Jane, 26Muller, H. A., 32Murta, L., 11
Nardi, Bonnie A., 33
Open Source Development Network, 30
Paoli, Jean, 35Patterson, John, 10Penix, John, 31Penner, Reagan, 15Perez, Cesar, 33Phillips, W. Greg, 23Pilato, C. Michael, 31Pinheiro, R., 11Poltrock, Steven E., 27Pomberger, Gustav, 8Pooley, Rob, 5
Quigley, A., 38
Radfelder, O., 39Ragoonaden, Kenny, 6Rasouli, Rittu, 7Redmiles, David F., 20, 31Reinwald, Berthold, 26Report, Hurwitz, 7Richters, M., 39Riedl, John, 9, 12Robbins, Jason E., 20Rodden, Tom, 12Roseman, Mark, 23Ross, Steven, 10Rosson, Mary Beth, 26Russell, Craig, 5Ryman, Authur, 7
Sarma, Anita, 9, 15Schildhauer, Erich, 7Schneider, Kevin, 15Schummer, Till, 10, 25Shaffer, Clifford A., 26Shih, Joanne, 36Sierhuis, Maarten, 31Smith, Alan, 5Smith, Mike, 5Spellman, Peter, 26Sperberg-McQueen, C M, 35Sprenkle, Sara, 31Sravanapudi, Ajay Paul, 14Stasko, John, 39Stein, Michael, 12Stewart, Hugh, 7Storey, M. A., 32Sturm, Thorsten, 7Summerville, Ian, 17
Teege, Gunnar, 9Thomas, Dave, 32Tichy, Walter F., 30
van der Hoek, Andr, 9Vessey, Iris, 14Vlissides, John, 18
Walpole, R., 33Wang, Chung-Yih, 36Wang, Yi-Min, 36Weinreich, R., 6Weiss, David, 5Weiss, Richard, 35Werner, C. M., 11Wetzel, Ingrid, 27Whitehead Jr., E. James, 24
43
Wilcox, E. M., 33, 34Wilcox, Pauline, 5Williams, Laurie, 19Wong, K., 32
Yajnik, Shalini, 36Yang, S., 33Ye, Yunwen, 15Yergeau, Francois, 35
Zelkowitz, Marvin, 14
44