Supporting Distributed Software Development with fine ... - IEEE Xplore

Supporting Distributed Software Development with fine-grained Artefact Management Bernd Bruegge*, Andrea De Lucia†, Fausto Fasano†, Genoveffa Tortora† [email protected], [email protected], [email protected], [email protected] *

Institut für Informatik - Technische Universität München – Boltzmannstraße, 3 - 85748 Garching b. München – Germany Dipartimento di Matematica e Informatica - Università di Salerno - Via Ponte don Melillo - 84084 Fisciano (SA) - Italy

†

Abstract Distributed software development is increasingly becoming a common practice in the software industry. The increased complexity of software systems also reflects in the complexity of design documentation, thus requiring a specific tool support for change and configuration management in distributed development settings. We present the fine-grained versioning management approach adopted in the ADAMS artefact management system, focusing on support to high level documentation versioning. We also present the results of experimenting the tool in software development projects developed at the University of Salerno.

1. Introduction Geographically Distributed Development offers several benefits to software development organisation, such as working cost reduction, enhanced availability of the development staff, flexibility to allow in-house staff and adapt quickly to volatile business needs. However, software development in geographically distributed environments also creates software engineering challenges due to the impact of temporal, geographical and socio-cultural differences. In such a scenario managing consistency and concurrency among project artefacts, is an issue. Computer Supported Cooperative Work (CSCW) environments provide an infrastructure to manage such difficulties. In particular, change management and configuration management capabilities help to manage changes and assets across geographic boundaries in a secure environment. Software Version Control is the branch of Software Configuration Management (SCM), addressing the management of different versions of documents [14]. Unfortunately, many current version control systems are built on the top of the early developed versioning tools [3], [24], [27] or share with them the same approach focused on lower CASE (Computer Aided

IEEE International Conference on Global Software Engineering (ICGSE'06) 0-7695-2663-2/06 $20.00 © 2006

Software Engineering) tool support, thus being mostly concerned about implementation and testing issues. As a result, there is an implicit assumption on the textual nature of (mainly source code) documents. However, due to the increasing complexity of software systems, nowadays software development processes involve several analysis and design documents. Many of such documents have a complex structure that is not well fitted by the file oriented approach of the currently available tools. An example of such a kind of documents is represented by design diagrams. Diagrams are widely used in the software engineering practice to deal with the complexity of software systems, as they provide a high level abstraction of the system and enable the description of complex ideas succinctly and precisely. However, diagrams are inadequately managed by common versioning tools as their non-textual nature prevents them from taking advantage of many interesting functionalities, such as delta versioning and automatic merging. Even though the delta versioning is not an issue, considering the continuously decreasing storage cost, the automatic merge represents a key issue during development of large and complex systems, where development pressures of productivity and deadlines often force organisations to require that multiple developers are allowed to simultaneously edit copies of the same revision controlled file [3]. Such highly structured documentation requires a specific support by CSCW tools. In fact, a fine-grained artefact management for such documentation where each piece of the document is versioned apart from the other, having the system to manage the document structure, helps in reducing the occurrence of conflicts arising when different software engineers modify the same document, and reduces the necessity of concurrent branches. Moreover, having the document decomposed in a hierarchy of simpler document components, enables the definition of more precise access policies to the document sections, also allowing a finer task allocation and development responsibility

identification. This is particularly important in a distributed environment where a work breakdown structure is usually defined to decompose the project components into manageable tasks eventually assigned to distributed development teams. Finally, in large and complex software systems, information is not merely contained within documents, but also in relationships among the documents. An example is represented by the relations among issues, options, arguments, decisions, and criteria that provide an insight of an issue resolution process. Without such relations it is very complicated to understand the information contained in such documents. More generally, all types of traceability information provide important insights into system development and evolution facilitating comprehension and changes during maintenance, impact analysis, and reuse of existing software, and giving an essential support in understanding the relationships existing within and across software artefacts [20]. When documents are changed during the software development process, such information can evolve accordingly, thus requiring the system to maintain different versions of the link to avoid loosing such important information when recovering old revisions of the system under development. We present the versioning management approach used in ADAMS (ADvanced Artefact Management System), an artefact-based process support system for the management of human resources, projects, and software artefacts [10]. ADAMS allows the software engineer to decompose a complex artefact in a finegrained hierarchy of sub-artefacts, providing change and configuration management functionalities for both the composite artefact and its components. The versioning approach proposed expressly takes into account the peculiarity of the different artefact types and distinguishes between the artefact content and the file(s) used to store it, allowing the software engineer to tailor the versioning granularity level according to his/her needs. Moreover, traceability links are versioned, thus providing consistent information when recovering old versions from the repository. The remaining of the paper is organised as follows. Section 2 presents an overview of ADAMS, while Section 3 focuses on the versioning management approach adopted in ADAMS. Section 4 describes the hierarchic versioning, while Section 5 presents an application of the described approach to manage diagram artefacts versioning. Section 6 presents some feedbacks collected during the development of several different projects where development teams were provided with the versioning functionalities presented.


Section 7 discusses related work, while Section 8 concludes.

2. ADAMS Overview ADAMS (ADvanced Artefact Management System) is an artefact-based process support system. It enables the definition of a process in terms of the artefacts to be produced and the relations among them [10]. ADAMS poses a great emphasis on the artefact life cycle by associating software engineers with the different operations they can perform on each artefact. This, together with the resource permissions definition and management, represents a first process support level and allows the Project Manager to focus on practical problems involved in the process and avoid getting lost in the complexity of process modelling, like in workflow management systems. ADAMS also supports quality management by associating each artefact type with a standard template and an inspection checklist, according to the quality manual of the organisation. Each template can be customised for specific projects or artefacts according to the quality plan. As well as the artefact standard template, standard checklist can be associated with each artefact type and used during the review phase of the artefact life cycle. ADAMS enables software engineers to create and store traceability links between artefacts. A traceability link can be a dependence (directed link) between a source and a target artefact (the target artefact depends on or is impacted by changes to the source artefact), an undirected link (artefacts impact on each other), or a composition (the source artefact is part of the target artefact). Traceability links in ADAMS are useful for impact analysis and change management during software development and evolution. Usually, traceability link identification is delegated to the software engineer, who has the responsibility to define and maintain such information during software evolution. In order to support the software engineer in such a hard and time consuming task, ADAMS integrates a traceability link recovery tool based on Information Retrieval techniques, that proposes candidate traceability links and highlights possible incorrect traceability links [11]. The support for cooperation is provided through typical configuration management features. In fact, ADAMS enables groups of people to work on the same artefact, depending on the required roles. Different software engineers can access the same artefact according to a lock-based policy or concurrently, if branch versions of the artefact are allowed.

The system has been enriched with features to deal with some of the most common problems faced by cooperative environments, in particular context awareness and communication among software engineers. A first context-awareness level is given by the possibility to see at any time the people who are working on an artefact. Context awareness is also supported through event notifications: software engineers working on an artefact are notified whenever relevant events happen to the artefacts they are interested in. An example of such events is the creation of a new version of an artefact. A number of events are automatically notified without any need for subscription (e.g., a software engineer is notified as soon as he/she has been allocated to an artefact). Event notifications are also propagated through the traceability layer of ADAMS to the artefacts impacted directly or indirectly by the change (and consequently to the software engineers responsible for them) [12]. This reduces the overload of subscribing several events for notification and prevents from forgetting indirect but essential subscriptions. Besides the delivery of notifications concerning the evolution of the system, event notification mechanisms can also be used by the software engineers to send a feedback whenever they discover problems in artefacts their work depends on. Such feedbacks are delivered to the software engineer responsible for the artefact. ADAMS integrates a tool to graphically visualise the traceability graph (the graph having the artefacts of a project as nodes and the traceability links as graph edges). Such a traceability graph can also be browsed to look at the state of previously developed artefacts, to download latest artefact versions, or to subscribe events on them in order to receive notifications concerning their development. ADAMS is a web application implemented using JSP and Servlet technology according the MVC model. The application logic layer is provided by several subsystems using MySQL relational DBMS to store metadata information [13].

3. Versioning Management in ADAMS ADAMS versioning management is based on the check-out/check-in paradigm adopted in most of the current versioning and configuration management tools. The software engineer repeatedly edits a given revision (usually working on a local copy of the file), until freezing it. Once a revision is frozen, it is stored permanently and no change can be applied to it. Usually, such a revision freezing is performed with a check-in or commit command. Different versioning management systems adopt different strategies to store


the version content and implement concurrency policies. Each of them has pros and cons in terms of performance, disk space, reliability, or concurrency criteria. ADAMS adopts a pessimistic approach to manage concurrency. In fact, to edit a frozen revision the software engineer has to declare his/her intentions by performing a check-out operation, thus locking the artefact. Once all the changes are applied, the file is checked-in again, causing the production of a new revision. This approach prevents conflicts due to modifications applied by different software engineers to the same artefact. The drawback of such an approach is a serialisation of the changes to the artefact that results in a poor support to cooperative development. In order to allow the concurrent development within a cooperative development environment, ADAMS supports the branching and merging of artefacts. Whenever an artefact has to be modified concurrently by different software engineers, each software engineer creates a new branch and starts working on it. It is worth noting that in case the artefact has been locked by another software engineer, he/she will be notified by the system by means of a notification informing him/her about the creation of the new branch. Each branch can be edited similarly to a main trunk artefact until all the changes are applied and the branch is (eventually) merged into the main trunk. This possibility, together with the hierarchic versioning management, provides an adequate concurrency level, while improving the context awareness on the project as concurrent development is always explicit and no unexpected conflict can arise. ADAMS is primarily a software project management system. This means that the files it has to manage are not merely source code files or even textual files, but range from documentation (including diagrams) and rationale information, to software programs and source code. However, most of the versioning management tools are optimised for source code management and their support is limited for such a heterogeneous document space. The approach we adopted to manage versions and configurations in ADAMS, expressly takes into account the peculiarity of the different types of artefacts produced during software development, taking advantage of the knowledge about such artefacts provided by the artefact management subsystem. This resulted into an integrated versioning management that poses a great emphasis to the hierarchic nature of most of the artefacts managed. ADAMS does not identify an artefact with a single file, as most of the available versioning management systems do. In fact, an artefact can be composed of a

file chunk as well as a collection of files. Such a decoupling between the artefact to manage and the way it is represented within the file system, allows the software engineer to tailor the granularity level of the versioning according to his/her needs. As an example, in case a cluster of artefacts has a very high cohesion between its elements, such that the software engineer wants to be sure that no change can be applied to a component of the cluster without also reviewing the other files in the cluster, he/she can create a single (multi-file) artefact containing all the files of the cluster and the system will treats them as an atomic entity. On the other hand, a complex artefact such as the Requirements Analysis Document can be considered as a collection of textual artefacts, diagrams, and images, even if they are stored into the same file. While the case described in the former example merely adds a consistency check with respect to a traditional management having multiple files clustered by tags or labels, the latter situation is much more interesting as it allows an improved versioning management with respect to traditional file-based approaches. Before discussing the hierarchic versioning approach implemented in ADAMS, it is worth to introduce the way the system keeps different versions for the same artefact. ADAMS relies on a relational database to store the metadata related to the artefacts and their versions. The data content for each artefact is instead stored relying on the file system. The interface towards the file system is implemented using a subsystem of the versioning system that actually does nothing more than reading and writing the files of the artefact. This choice has been taken to improve the performance and the simplicity of storing and retrieving functionalities. However, it is obviously possible to interface such a subsystem with a wrapper for other versioning systems (e.g., CVS [3] or Subversion [9]) as well as to implement additional features such as caching and delta versioning. Among the metadata stored with each artefact version, ADAMS records the timestamp of each checkin operation. Such a version timestamp is used to reconstruct the state of the project in a precise instant of the system evolution. The current state of the project is simply recovered by accessing to the state of the project at the request time (obviously the system distinguishes between the main development trunk and its branches, depending on the user request). However, it is possible to browse the artefact repository setting up a past timestamp and having the system to show the snapshot of the system in that precise instant of the development process. This can be useful for configuration management, but also provides support


whenever it is necessary to recover any other intermediate (non baselined) version of the system. Besides time stamping each artefact version, the system also records such information for each traceability link, so that also this information is coherent with the past view of the project. Traceability links are also versioned such that it is possible to modify the nature of a link without loosing its history. Moreover, traceability links do not merely store the timestamp of their creation, but similarly to the artefacts they are provided a temporal interval starting with their creation and ending with their deletion. This allows to precisely determining the content of the project for a stated past timestamp without considering not yet created entities and excluding (logically) deleted entities.

4. Hierarchic Versioning Artefacts in ADAMS can either be an atomic entity (associated to one or more files) or they can be composed of an arbitrary number of atomic and further composed artefacts. Most of the documents produced during the software development have a well-defined hierarchic structure. Textual documentation structure is usually defined in the quality manual and is essentially composed of chapters, sections, subsections, and paragraphs (we can further decompose paragraphs in sentences composed of words, made up of characters, but the benefit of such a fine decomposition usually does not pay the overhead of such a complex structure), each of them providing a part of the whole document content. Even diagrams, usually included in such documents must comply with a well-specified meta-model (most of them have a graph-based structure, e.g., UML use case, class, statechart, activity, component and deployment diagrams). Source code is typically organised in packages, each of them containing classes composed of attributes and methods (composed of instructions). All these kind of documents can be considered as unstructured documents and versioning can be provided by keeping track of any change applied to the file they are contained in. However, a finer-grained document management, in which each single element of the document is managed as a different entity and versioning is provided for both the atomic entity changed and the entities it is contained in, is more desirable, as it gives the possibility to define more detailed traceability links. In fact, the software engineer is enabled to specify traceability links between entities within the same document, as well as between parts of two different documents, resulting in a more precise impact analysis. Moreover, such a fine-

grained artefact management reduces the likelihood of conflicts arising when different software engineers apply changes to the same document. In fact, in case the document is decomposed in sub-artefacts, a conflict occurs only if changes concern the same sub-artefact. It is worth noting that, even if such kind of conflict (i.e., changes occurring in different parts of a document) can be usually addressed by automatic merge algorithms for textual documents, the scenario is much more complicated when dealing with non-textual documents (e.g., UML diagrams), where an automatic conflict resolution is generally impractical even when changes do not affect the same model element. In ADAMS, the composition of artefacts is realised by defining a special type of traceability link between the composite artefact and each of the contained artefacts. This approach has the advantage of inheriting some of the functionalities provided by the standard traceability link, such as the propagation of event notification through the hierarchy and the graphical visualisation of the compositional structure. Artefact hierarchies in ADAMS can be defined bottom-up (putting simple artefacts together to form a composite artefacts), top-down (starting from high level documents and incrementally adding subartefacts or decomposing parts of the composite artefact), or in any combination of the previous approaches, linking together already defined trees. Such a composition process is dynamic, as the artefact manager can decide to change the artefact structure even when the development is already started. This gives the flexibility necessary in a highly changeable and evolving environment, like a software development project, and allows changing the grain of the decomposition as soon as the document size becomes inadequate for the selected decomposition. ADAMS manages simple artefacts (i.e., artefacts not involved in any hierarchy) similarly to composite artefacts. Thus, a composite artefact may have files associated with it and versioning is provided for them. The usefulness of having a file associated with a composite artefact (whose content is actually provided by accessing its children content) is twofold. In case the artefact structure can be specified by means of a description file (e.g., a UML diagram can be represented by means of an XML-based document), the file associated with the composite artefact is used by the system to automatically reconstruct the artefact starting from its children node content. It is worth noting that, being such a file versioned by the system, it is possible to modify the internal structure of the composite artefact (i.e., how to put its components together) whenever needed, by merely updating the file associated to the composite artefact. This also guarantees that the internal organisation of the previous


version of the artefact is preserved into the previous versions of its description file. In case it is not easy to define the structure of the composite artefact the associated file can be used to store the composite artefact manually recomposed by the software engineer. Obviously, at each level of the hierarchy the content reconstruction is achieved by merely looking at the children of the artefact. This approach allows the software engineer to define a hybrid composition, in which only those “unstructurable” components need a manual reconstruction, while the system handles all the other components reconstruction. Note that in case a manual reconstruction is needed the content of the composed artefact can be out of sync with respect to the content of the artefacts it is composed of. The system notifies such a situation by means of an exclamation mark over its icon in the graph visualisation tool or close to the artefact name in the project to-do list or in any other artefacts view (see Figure 1).

Figure 1. Out-of-sync visual notification It is important to note that the locking policy is influenced by the composition of hierarchic artefacts. In particular, to ensure a pessimistic access control to the document parts, aimed at avoiding concurrent development of both the component and an artefact containing it (even indirectly), whenever a component is checked-out, a lock have to be recursively propagated to the composite artefact it is contained in, thus ensuring that the container is not modified until the component changes are committed. On the other hand, whenever a composite artefact is checked-out, the sub-trees rooted in the artefact have to be locked. Even though most of the documentation produced during the software development process has a treelike structure, in ADAMS there is more flexibility on the way the nodes can be linked to form a composite artefact. The system only performs a cycle prevention check whenever the software engineer creates or modifies a composition, to prevent an artefact from being part of itself (even indirectly)1. Such flexibility gives the software engineer the possibility to define a 1

This check is necessary in order to avoid the automatic content reconstruction mechanism being involved into an infinite loop.

compositional structure by means of a Direct Acyclic Graph (DAG), thus allowing a component being part of several composite artefacts. Such a possibility allows the software engineer to reuse already defined components, thus resulting in an incremented consistency between different artefacts having commonalities.

Figure 2. Multiple check-outs in the tree view It is worth noting that fine-grained artefact decomposition leads to a higher number of artefacts to manage, with respect to a coarse-grained approach. This can cause some manageability problems, as the visualisation graph can be hard to browse. Moreover it is often the case that some related pieces of a document are developed by the same software engineer within the same working session. To this aim ADAMS provides an alternative tree view on the artefacts, where the software engineer can browse the repository by folding and unfolding a directory-like structure showing the project artefacts. Such a view can also be used to select a set of artefact to be checked-out with a single operation (see Figure 2).

5. UML Models Versioning One of the possible applications of the hierarchic versioning capabilities of ADAMS deals with the (design) diagrams versioning problem. Diagrams versioning is generally not supported by the tools used to model them and, even when supported or manually accomplished by the model developers, it is limited to maintaining different versions of the files used to represent the diagram. In same cases such a coarse-grained versioning approach is insufficient and ineffective. Suppose, as an example, you are modelling a class diagram, producing several versions of the diagram, each of them introducing changes to one of the classes or relations of the diagram. After producing several versions of the diagram, you realise that you need to turn back to an older version for a specific class. Even if you have created a new version for each of the


implemented changes, you cannot effectively use them (unless the change to be discarded is the last applied to the diagram) as the recovery of the file containing the older version of the class may undo all the changes applied to the remaining element of the diagram. The problem is even more evident when the tool uses a single file to store all the diagrams within the same project or workspace (e.g., the zargo file for ArgoUML [23]). Even if you anyway have to possibility to create different workspaces to keep diagrams (and the files they are stored in) disjoint, such a break up prevents from sharing components among different diagrams, which can result in some inconsistencies among the same element used in different diagrams. To address this issue we can take advantage of the hierarchic versioning functionality provided by ADAMS. In fact, the class diagram of the example can be associated with a composite artefact having a subartefact for each of the nodes of the diagram. Relations between elements of the diagram can either be modelled as a specialised type of traceability link or associated to further sub-artefacts.

5.1 An Use Case Example In this section we present an example aiming at illustrating the proposed approach. We also show how the fine-grained versioning supports changes to the model elements, providing a better consistency among elements across different models with respect to traditional coarse-grained versioning. The example illustrated concerns to the modelling of a use case diagram. However, the model proposed is flexible enough to deal with any kind of UML diagrams. In fact, each diagram is treated as a simple composition of diagram elements. In our example, the elements can be actors, use cases, or associations. Each element of the diagram can be related to a description (e.g., the description of a use case can contain its flow of events). Figure 3 shows the model adopted to support the fine-grained versioning of a use case diagram. It is important to note that everything is an artefact and, as a consequence, versioning is achieved relying on the functionalities provided by the artefact management subsystem. Figure 4 depicts a simple use case produced during the modelling of a distributed information system for accident management [7]. In the example, two actors and three use cases have been identified. The description for the AllocateResource use case is provided in Table 1. In the following, two developers, namely Alice and Bob, want to modify the diagram. Alice wants to add a new use case called ViewMap that is included in both

the OpenIncident and AllocateResource use cases, while Bob wants to rename the AllocateResource use case to AllocateResources. At the same time, a third developer wants to modify the flow of events in the AllocateResource use case. Such a situation is usually managed having a unique file to manage the use case diagram while the use case description is generally contained in a requirement analysis document. However, even if the changes to the model affect the same use case (AllocateResource) there is no need to serialise them. In fact, renaming the use case does not influence the semantics of the relation with the new use case it has to be linked to. Moreover, having the use case descriptions included into a single document is helpful during traceability link definition.

elements containing all information related to these elements. It is worth noting that an instance of the model (i.e. a use case diagram created during the software design process), also contains syntactic elements, representing semantic elements inside a specific diagram, such as the position and the size of the elements. Such information is diagram specific and is maintained in the artefact associated to the diagram (the composite artefact). In order to take advantage on the proposed approach, the modelling tool should be able to manage both types of elements separately.

Table 1. AllocateResource Description Name Participating Actors

Entry Condition

Flow of Events

Exit Condition

Special Requirements

AllocateResource Field Officer, Dispatcher, Resource Allocator, Field Supervisor The Resource Allocator has selected an available resource The resource is currently not allocated The Resource Allocator selects an Emergency Incident. The Resource is committed to the Emergency Incident. The use case terminates when the resource is committed The selected Resource is now unavailable to any other Emergency Incidents or Resource Requests The Field Supervisor is responsible for managing the Resources

Instead of considering the use case diagram of the example as a coarse-grained configuration item, the approach proposed consists of creating an artefact for each diagram element and considering the use case diagram as a composition of such fine-grained artefacts. As a consequence, Alice’s change is achieved by creating a new artefact for the use case ViewMap and two artefacts for the include relations, while Bob’s change requires the creation of a new version for the AllocateResource. On the other hand, the change to the AllocateResource use case description produces a new version for the artefact representing the description section of the use case. It is important to note that the model is correct independently of the order the changes are applied. Moreover, the consistency between the renamed use case, the related elements (even occurring in different diagrams), and its description is also preserved. The model presented is used to manage the versioning of semantic model elements, i.e., conceptual


Figure 3. Entity objects of ADAMS use case model (UML class diagram)

Figure 4. Incident Management UML Use Case Diagram We are currently developing a cooperative visual modelling tool for UML diagrams that supports the model presented in the example. Besides providing modelling functionalities, the tool allows the developer to access the description of each model element (e.g. the use case description of the example). Since element description contains textual information, such information is also achievable using the standard configuration management functionalities. This gives the developers the possibility to use the preferred tool to edit the description, while maintaining consistency and navigability across the project.

Table 2. Questionnaire results Characteristic Functionality

Usability

Robustness and Performance

Question ADAMS provided an useful support during the software development process A fine-grained artefact management is preferred to a coarse-grained artefact management It is easy to provide the system with input data It is easy to get output data from the system It is easy to learn the main procedure Interface components are well organized on the screen Terms denoting commands are clear. It is easy to learn and remember single interface component roles The interface interaction mechanism prevents errors The performances of the traceability management subsystem of ADAMS are good A.“I totally agree” B.“I agree” C. “I disagree” D.“I totally disagree”

6. Evaluation ADAMS has been experimented from April 15th to July 20th 2005 in the Software Engineering courses of the Computer Science program at the University of Salerno (Italy). The experimentation included about 150 students involved in seventeen different projects. Each development team was composed of two managers (a project manager and a quality manager) and 6-8 developers. In addition to source code components, each team was asked to produce the Requirements Analysis Document (RAD), the System Design Document (SDD), the Object Design Document (ODD), the Test Plan, and the test execution documents, besides project and quality management documents [6]. At the end of the projects, the students evaluated ADAMS through a questionnaire. Each question refers to an attribute of four quality characteristics of interest, namely functionality, usability, robustness, and performance. Table 2 shows for each question the distribution of the student answers. We noticed that all the team managers performed a detailed decomposition of complex artefacts into finegrained hierarchies of sub artefacts. The decomposition for the main design documents (RAD, SDD, and ODD) has followed the section, subsection, and paragraph organisation provided by the document template structured by the quality manager. In some cases a further decomposition has been performed. In particular, within the RAD the sections containing Functional and Non-functional Requirements were decomposed creating an artefact for each requirement, and specific sub-artefacts were created for each scenario, use cases, and UML diagram. In some projects, such behaviour led to the decomposition of the RAD into more the one hundred sub-artefacts. Such a fine-grained decomposition has been motivated by the team managers with the necessity to


A 22.86 22.14 17.65 26.47 50.00 55.88 38.24 35.29 23.53 38.24

Answer (%) B C 52.14 14.29 19.29 33.57 64.71 14.71 55.88 14.71 41.18 8.82 35.29 8.82 50.00 8.82 47.06 14.71 58.82 14.71 47.06 8.82

D 10.71 25.00 2.94 2.94 0.00 0.00 2.94 2.94 2.94 5.88

define a work breakdown structure and allocate each team member to the subset of tasks assigned to them, thus easily managing permission granting. Moreover the users appreciated the possibility to avoid the necessity of creating branches when working on different functionalities addressed in the same document. Finally, the users highlighted how a finegrained approach enabled a more precise traceability links definition. On the other hand, the necessity to deal with many configuration items was perceived as an increment in the work effort required to manage them, also resulting in a time performance decrease. Such considerations, together with the resistance to change, led to a substantial equality between supporters and opponents of the fine-grained approach. However, it is important to note that both performance and work effort issues are going to be addressed by specific front-ends doing much of the work (e.g., check-out, check-in, and merge of component artefacts) under the covers.

7. Related Work Despite of the research effort addressing such an important field, some of the first approaches [3], [9], [24], [27] are still in use and most of the newest tools follow the steps of the pioneers in this field. Among these, Subversion [9] is one of the most interesting tool, as it is a new free/open-source version control system which is supposed to replace CVS [3]. Subversion has most of the features of CVS and a similar interface, but also several improved features such as true atomic commits, faster and simpler branching and directory versioning. However, CVS, RCS, SCCS, and Subversion do not provide finegrained versioning features. Moreover, such tools are mainly intended to deal with text-based documentation, while our focus is on all types of artefacts produced during the software development process, including system models.

Several commercial tools are available that provide configuration management functionalities [4], [5], [17], [21], [22], [25]. Similarly to Subversion, such tools do not provide a direct support to fine-grained versioning management especially with respect to versioning of high level documentation. Even if the user can organise composite artefacts using folders, such an approach is limited to an enumeration of components, without providing any structural information relating components to the composite. Odyssey-VCS [19], is a research version control system developed at the Federal University of Rio de Janeiro, addressing the diagram versioning problem, by proposing a tool for UML model elements versioning. Even if Odyssey-VCS provides very interesting functionalities, especially to deal with conflict resolution, it is limited to UML diagrams. Volzer et al. [28], propose to extend traditional filebased CMS functionalities to take in account compositions. The approach is implemented in SubCM, a lightweight tool designed to be used on top of a CMS, enabling users to define hierarchical views of product structure, independently of the underlying artefact-repository structure. Differently from us, SubCM is intended for configuration management of hierarchies of subsystems and not for documentation. Hierarchical versioning has been approached by Asklund et al. [1] which propose a unified extensional versioning model. In this model, a document is a tree structure consisting of local data, a composite node (which is a collection of nodes), or a link node (which is used to represent arbitrary relations between documents). The model has been implemented in COOP/ Orm [16] and CoEd [2]. COOP/Orm [16] is a research tool developed at the University of Lund, in Sweden, supporting the natural hierarchic structure of textual documents, and providing version control and merge facilities within distributed groups. CoEd [2] is a visual environment for textual hierarchic document versioning, developed at the University of Aalborg, in Denmark. CoEd uses the same document management approach adopted by COOP/Orm, focusing on support to LaTeX documents. However, both COOP/Orm and CoEd are limited to textual documentation. CoVer [15] is a hypermedia version server implemented on top of the HyperBase hypermedia engine [26]. Versioned objects are represented by multi-state objects, representing a composite of references to the states of versioned objects. CoVer is intended for hypermedia documents and does not provide support for most of the artefacts produced during software development. Stellation [8] is another fine-grained CMS aiming to provide versioning functionalities for source code. Instead of having the code organization of the system


dominated by its layout in source files for storage, programs and related development artefacts are stored as small, fine-grained units called fragments. In Stellation, all storage is in terms of fragments and aggregation is used for combining groups of fragments into larger structures. Differently from us, Stellation is only intended for source code versioning. Molhado [18] is an interesting fine-grained version control system supporting versioning of any finegrained units at any structural levels in a software document (including source code and documentations), and providing version history and change information at the semantic level. Molhado was specifically designed to support the development of object-oriented SCM systems. However, Molhado do not provide a specific support to high level documentation, such as UML diagrams. Differently from us, the approaches described above are mainly focused on a specific type of artefact. ADAMS aims at providing support to the software engineering from the early phases of the software development process to the maintenance phase, thus allowing versioning of requirements, diagrams, and classes in a coherent environment using traceability to link related artefacts. Moreover, ADAMS uses the finer document management to enhance its support for cooperative development. The possibility to know who is working on an artefact and which portion of the document is going to be modified, together with the possibility to receive personalised notifications concerning relevant events occurring on specific artefacts or sub-artefact is valuable in a distributed setting, where communication is limited and context awareness is an issue.

8. Conclusion Software Configuration Management is one of the best practices to address the challenges on the global software development processes and organizations due to fewer direct communication and interactions. Unfortunately, many current version control systems are focused on textual (mainly source code) documents. However, software artefacts also include several documents having a hierarchic structure and being involved in several relations with the other artefacts. Such information is not well addressed by the file oriented approach of the currently available tools. In this paper we described the fine-grained versioning approach adopted in the ADAMS artefact management system. The approach described is flexible enough to manage simple files with an approach similar to the current version control systems. However, the traceability links versioning functionality

and the hierarchic versioning approach also allow the software engineer to address the versioning of complex high level documentation. In particular, we proposed a versioning model to represent UML use case diagram, discussing the advantages that a fine-grained approach provides when dealing with such high level design documentation. We also presented an evaluation of the described approach conducted within software engineering courses at the University of Salerno.

References [1] U. Asklund, L. Bendix, H.B. Christensen, and B. Magnusson, “The Unified Versioning Model,” Proceedings of 9th International Symposium on System Configuration Management, 1999, pp. 100-122. [2] L. Bendix, P.N. Larsen, A.I. Nielsen, and J.L.S. Petersen, “CoEd: a tool for versioning of hierarchical documents”. Proceedings of the 8th International Symposium on System Configuration Management, New York, NY, 1998, pp. 174-187. [3] B. Berliner, “CVS II: Parallelizing software development”, Proceedings of 1990 Winter USENIX Conference, Washington, D.C., USA, 1990, pp. 341-352 [4] BitKeeper web site: http://www.bitkeeper.com [5] Borland Star Team web site:http://www.borland.com/ us/products/starteam [6] B. Bruegge and A.H. Dutoit, “Object-Oriented Software Engineering: Using UML, Patterns and Java”, 2nd Edition, Chapter 12: Rationale Management, Prentice Hall, Upper Saddle River, NJ, USA, 2003. [7] B. Bruegge, K. O’Toole, and D. Rothenberger, “Design consideration for an accident management system”, Proceedings of 2nd International Conference on Cooperative Information Systems, Toronto, Canada, 1994, pp. 90-100. [8] M. Chu-Carroll, J. Wright, and D. Shields, “Supporting aggregation in fine grained software configuration management”, Proceedings of the 10th ACM SIGSOFT Ssymposium on Foundations of Software Engineering, Charleston, South Carolina, USA, 2002, pp. 99-108. [9] B. Collins-Sussman, B.W. Fitzpatrick, and C.M. Pilato, “Version Control with Subversion”, O’Reilly (ed.), 2004. [10] A. De Lucia, F. Fasano, R. Francese, and G. Tortora, “ADAMS: an Artefact-based Process Support System”, Proceedings of 16th International Conference on Software Engineering and Knowledge Engineering, Banff, Alberta, Canada, 2004, pp. 31-36. [11] A. De Lucia, F. Fasano, R. Oliveto, and G. Tortora, “ADAMS Re-Trace: a Traceability Recovery Tool”, Proceedings of 9th IEEE European Conference on Software Maintenance and Reengineering, Manchester, UK, IEEE Computer Society Press, 2005, pp. 32-41. [12] A. De Lucia, F. Fasano, R. Francese, and R. Oliveto, “Traceability Management in ADAMS”, Proceedings of 1st International Workshop on Distributed Software Development, Paris, France, 2005, pp. 135-149.


[13] A. De Lucia, F. Fasano, R. Oliveto, and G. Tortora, "ADAMS: ADvanced Artefact Management System", in Proceedings of 10th European Conference on Software Maintenance and Reengineering, Bari, Italy, 2006, pp. 347-348. [14] J. Estublier, D. Leblang, G. Clemm, R. Conradi, A. van der Hoek, W. Tichy, D. Wiborg-Weber, “Impact of the Research Community on the Field of Software Configuration Management”, ACM Transactions on Software Engineering and Methodology, vol. 14, no. 4, 2005, pp. 1–48. [15] A. Haake and J.M. Haake. “Take CoVer: Exploiting Version Support in Cooperative Systems”. Proceedings of Conference on Human Factors in Computing Systems, Amsterdam, The Netherlands, 1993, pp. 406-413. [16] B. Magnusson and U. Asklund, “Fine grained version control of configurations in COOP/Orm”, Proceedings of the 6th International Workshop on Software Configuration Management, New York, NY, 1996, pp. 31-48. [17] MKS Source Integrated Enterprise web site: http://www.mks.com/products/sie [18] T. N. Nguyen, E. V. Munson, J. T. Boyland, and C. Thao, "Infrastructures for Development of Object-Oriented Configuration Management Services", in Proceedings of the 27th ACM/IEEE International Conference on Software Engineering, St. Louis, Missouri, USA, 2005, pp. 215-224. [19] H. Oliviera, L. Murta, and C. Werner, “Odyssey-VCS: A Flexible Version Control System for UML Model Elements”, Proceedings of the 12th International Workshop on Software Configuration Management, Lisbon, Portugal, 2005, pp. 1-16. [20] J. D. Palmer, “Traceability”, R. H. Thayer and M. Dorfman (eds.), Software Requirements Engineering, 2nd Edition, IEEE Computer Society Press, 2000, pp. 412-422. [21] Perforce Software, Alameda, California. “Networked Software Development: SCM over the Internet and Intranets”, 1998. [22] Rationale ClearCase web site: http://www306.ibm.com/software/awdtools/clearcase/index.html [23] J.E. Robbins and D.F. Redmiles, “Cognitive support, UML adherence, and XMI interchange in Argo/UML”, Journal of Information and Software Technology, vol. 42, no. 2, 2000, pp. 79-89. [24] M.J. Rochkind, “The Source Code Control System”, IEEE Transactions on Software Engineering, vol. 1, no. 4, 1975, pp. 364-370. [25] Serena ChangeMan web site: http://www.serena.com/ Products/changeman/Home.asp [26] H. Schütt and N. Streitz. “HyperBase: A Hypermedia Engine Based on a Relational Database Management System”. A. Rizk, N. Streitz, and J. André, editors, Proceedings of the European Conference on Hypertext, Versailles, France, 1990, pp. 95–108. [27] W.F. Tichy, “RCS: A System for Version Control”, Software Practice & Experience, vol. 15 no. 7, 1985, pp. 637-654. [28] H. Volzer, A. MacDonald, B. Atchison, A. Hanlon, P. Lindsay, and P. Strooper, “SubCM: A Tool for Improved Visibility of Software Change in an Industrial Setting”, IEEE Transaction on software Engineering, vol. 30, no. 10, 2004, pp. 675-693.