FUTURE WORK IN COLLABORATIVE SOFTWARE ENGINEERING

By June 20, 2015

 

While the field of software engineering and configuration management is rich and has a long tradition (dating back to 1968), much work remains to be explored. CASE-based tools are continuously being developed to enhance the productivity of software developers and those who work with them. This last section of this paper examines three interesting fields of future work in collaborative software engineering: the integration of software engineering support into the integrated development environment (IDE), Augur – an interesting software visualization tool, and an open-systems approach to coordinating and managing artifacts among multiple users.

The first topic within future directions of collaborative software engineering we examine involves integrating collaborative and support tools within the IDE. More and more, the IDE is becoming the central point of communication among developers and those who work with them. Certainly the IDE is the tool that is used most frequently among software engineering practitioners. Consequently, we see a trend in adding tools to support collaboration and the software engineering process in to the IDE. As stated earlier, the Eclipse project adds the “Rear View Window” into the IDE to display presence information about the others in the shared space. As another example, Microsoft is releasing its new IDE, Visual Studio 2005, this year with many new collaborative features; this new suite is called Visual Team Services and is designed to integrate software engineering processes – from architecture and design to testing – into the IDE to create a common, shared space among all involved in the development process [Microsoft, 2005b]. The following figures show how testing is being integrated into Visual Studio 2005. Notice the ability to create unit tests within the code space in the IDE. Additionally, the list of tests and their status is easily determined within the IDE. Finally, the source code is highlighted in such a way as to denote which parts of the code are covered under tests and which are not covered under any test (indicating a possible problem in untested code).

In the above figure, the green highlighted code indicates parts of the source code that have been tested via unit tests. The red highlighted code indicates parts of the source code that have not been tested (i.e. no unit test exists to validate the code’s correctness). While an interesting study, Microsoft is not the only IDE provider that is integrating software engineering and collaborative tools into their IDE; IBM and others are also moving in this direction.

Next we examine the second trend in future software engineering work –source code visualization. For over a decade, tools have existed to display meta-information about source code, but there are new trends in this field. Most notable is the system entitled Augur that was recently presented at the International Conference on Software Engineering in 2004. This system allows many source code files to be displayed simultaneously with many different views. These views are customized to see different information, including who editing the code, when the code was last edited, and the structure of the code (whether the line is a comment, structural, or core code). Interesting observations are apparent from such views. [Froehlich and Dourish, 2004] report their experience using Augur with the Apache open source community and others; the users of the study indicate finding interesting information about edit patterns among users such as:

• Which users contributed to the project
• What was changed and when was it changed
• Structure of large source code files

The following figure shows the information captured in each line of the Augur system: who the author is, what is the structure of the line (i.e. code, comment, etc.), and how long ago the change/addition was made (the color varies with age). Additionally, the length of the line indicates the original code line’s length.

The above figure shows the type of information that the Augur and other similar code visualization tools provide. Users are able to view large amounts of code at a time and are able to glean information about the source (as indicated above). Each author is given a unique color; each type of line of code is provided a unique color; and the line of text changes color with age (most recent changes “fade” to older changes over time).

This line-by-line coloring scheme provides meta-information about the source code, and users can “zoom” in and view the actual code as needed; additionally, the user can change the view of the code as desired to see different information. The following figure shows one view of the Augur system. Notice that many files can be viewed simultaneously, and information such as when additions and changes were made, who made each change/addition, and the overall structure of the code (comments to code ratio, block size, etc.) is readily apparent.

Above, we see that some source code files are authored by principally one author, while files are authored by many users. The age of the modifications is clearly indicated by the color of the source code lines, and the structure of the code is visible as well. The “spike” graph in the lower right denotes flurries of activity over time (i.e. much work is clustered around key dates).

As the third and final topic of future research in distributed software engineering, we turn our attention to work on open-systems architectures to allow collaborators access to artifacts via Web services. Recent software engineering research demonstrates that formal and informal mechanisms that support collaboration are necessary to coordinate large groups of developers working concurrently [Gutwin et al, 2004; O’Reilly, 2004; van der Hoek et al, 2004]. As a result of this research, Dr. Sushil K. Prasad and Jon Preston are currently working on a system that defines the core functionality of an artifact-management system that utilizes open-systems architecture and Web services [Preston, 2005]. By adopting a Web services approach for a collaborative editing system, we are able to couple disparate integrated development environments (IDEs), SCM systems, and communication systems (email, instant messaging, etc.). The users of a system can use their preferred, current tools for editing, communication, and configuration management. Additionally, this approach enables distributed configuration management.

They define the following as the core functionalities for collaborative editing systems:

1. Optimistic check out an artifact (shared)
2. Pessimistic check out an artifact (exclusive)
3. Check in an artifact
4. Subscribe (user will be notified on event to artifact) and unsubscribe to artifact
5. Publish lists of artifacts, artifacts’ states, users (contact information), and subscriptions

This set of core functionalities provides for an open-system architecture that achieves the needed services defined in previous CSCW and SCM systems [Estublier, 2000; Magnusson et al, 1993; van der Lingen, 2004]. Similar work utilizing Web services for collaborative editing was done by [Younas and Iqbal, 2003] and [Merha et al, 2004].

The proposed system will allow users to subscribe to artifacts in the repository and receive notification (via email, instant message, etc.) upon events to such artifacts. The system will also provide a façade access to and integrate with existing software configuration management (SCM) systems, allowing Web-service-based check in and check out of managed artifacts. Additionally, a middleware component provides fine-grain, optimistic configuration management to legacy SCM systems that do not currently provide such services. Finally, a middleware component will provide the ability to integrate into existing modern integrated development environments (IDEs) and document editors so that users may use their current, preferred methods of editing. The net effect will be an open-systems architecture that allows various editing applications access to various artifact management systems through Web services. This architecture is shown in the following figure.

The above architecture shows the client editors on the left; these include IDEs and document editors (such as those from the Microsoft Office suite and the Open Office suite). These editors are connected via middleware hooks to the network and send and receive content through the Web services provided by servers; these Web service enabled servers will provide the core functionality outlined above. The Web services are connected to legacy artifact management systems such as file systems and repositories (like VSS, CVS, and RCS) [Tichy, 1985; Tichy, 1988]; the middleware connecting these systems provides fine-grain locking (i.e. the middleware checks artifacts in and out and acts as a proxy for the actual clients). Consequently, legacy systems are able to provide new, current functionality and clients are able to connect from any where and at any time.

While there are certainly other areas of active research in distributed software engineering, these three areas of work are interesting and prove to offer much to the field in the coming years.