Context Capture in Software Development
CContext Capture in Software Development
Bruno Antunes (cid:63) , Francisco Correia and Paulo Gomes
Knowledge and Intelligent Systems LaboratoryCognitive and Media Systems GroupCentre for Informatics and Systems of the University of CoimbraCoimbra, Portugal
Abstract.
The context of a software developer is something hard todefine and capture, as it represents a complex network of elements acrossdifferent dimensions that are not limited to the work developed on anIDE. We propose the definition of a software developer context modelthat takes into account all the dimensions that characterize the workenvironment of the developer. We are especially focused on what thesoftware developer context encompasses at the project level and how itcan be captured. The experimental work done so far show that usefulcontext information can be extracted from project management tools.The extraction, analysis and availability of this context information canbe used to enrich the work environment of developers with additionalknowledge to support their work.
Key words:
Context, Software Development, Knowledge Management.
The term context has an intuitive meaning for humans, but due to this intu-itive connotation it remains vague and generalist. Furthermore, the interest inthe many roles of context comes from different fields such as literature, philos-ophy, linguistics and computer science, with each field proposing its own viewof context [1]. The term context typically refers to the set of circumstances andfacts that surround the center of interest, providing additional information andincreasing understanding.The context-aware computing concept was first introduced by Schilit andTheimer [2], where they refer to context as “location of use, the collection ofnearby people and objects, as well as the changes to those objects over time” .In a similar way, Brown et al. [3] define context as location, identities of thepeople around the user, the time of day, season, temperature, etc. In a moregeneric definition, Dey and Abowd [4] define context as “any information thatcan be used to characterize the situation of an entity. An entity is a person, (cid:63)
Supported by FCT grant SFRH/BD/43336/2008. a r X i v : . [ c s . S E ] J a n B. Antunes, F. Correia and P. Gomes place, or object that is considered relevant to the interaction between a user andan application, including the user and applications themselves” .In software development, the context of a developer can be viewed as a richand complex network of elements across different dimensions that are not limitedto the work developed on an IDE (Integrated Development Environment). Due tothe difficulty on approaching such challenge, there is not a unique notion of whatit really covers and how it can be truly exploited. With the increasing dimensionof software systems, software development projects have grown in complexityand size, as well as in the number of functionalities and technologies involved.During their work, software developers need to cope with a large amount ofcontextual information that is typically not captured and processed in order toenrich their work environment.Our aim is the definition of a software developer context model that takesinto account all the dimensions that characterize the work environment of thedeveloper. We propose that these dimensions can be represented as a layeredmodel with four main layers: personal, project, organization and domain. Also,we believe that a context model needs to be analyzed from different perspectives:capture, modeling, representation and application. This way, each layer of theproposed context model will be founded in a definition of what context capture,modeling, representation and application should be for that layer.This work is especially focused on the project layer of the software developercontext model. We give a definition of what the context model encompasses atthe project layer and present some experimental work on the context captureperspective.The remaining of the paper starts with an overview of the software developercontext model we envision. In section 3 we describe the current work on contextcapture, some preliminary experimentation and the prototype developed. Anoverview of related work is given in section 4. Finally, section 5 concludes thepaper and point out some directions for future work.
The software developer context model we propose takes into account all thedimensions that comprise the software developer work environment. This way,we have identified four main dimensions: personal, project, organization anddomain. As shown in figure 1, these dimensions form a layered model and willbe described from four different perspectives: context capture, context modeling,context representation and context application.The personal layer represents the context of the work a developer has athands at any point in time, which can be defined as a set of tasks. In order toaccomplish these tasks, the developer has to deal with various kinds of resourcesat the same time, such as source code files, specification documents, bug reports,etc. These resources are typically dispersed through different places and systems,although being connected by a set of explicit and implicit relations that exist ontext Capture in Software Development 3 D OM A I N L A YE R O R G AN I Z A T I O N L A YE R P R O J E C TL A YE R PERSONALLAYER
CONTEXT CAPTURE C O N T EX T M O D E L I N G C O N T EX T R EP R ESE N T A T I O N CONTEXT APPLICATION
Fig. 1.
The software developer context model layers and perspectives.between them. At this level the context model represents the resources that areimportant for the tasks the developer is working on.The project layer focuses on the context of the project, or projects, in whichthe developer is somehow involved. A software development project is an aggre-gation of a team, a set of resources and a combination of explicit and implicitknowledge that keeps the project running. The team is responsible for accom-plishing tasks, which end up consuming and producing resources. The relationsthat exist between people and resources are the glue that makes everything work.The project layer represents the people and resources, as well as their relations,of the software development projects where the developer is included.The organization layer takes into account the organization context to whichthe developer belongs. Similarly to a project, an organization is made up ofpeople, resources and their relations, but in a much more complex network.While in a project the people and resources are necessarily connected due to therequisites of their work, in a software development organization these projectseasily become separate islands. The knowledge and competences developed ineach project may be of interest in other projects and valuable synergies can becreated when this information is available. The organization layer represents theorganizational context that surrounds a developer.The domain layer takes into account the knowledge domain, or domains, inwhich the developer works. This layer goes beyond the project and organizationlevels and includes a set of knowledge sources that stand out of these spheres.Nowdays, a typical developer uses the Internet to search information and to keepinformed of the advances in the technologies s/he works with. These actions arebased on services and communities, such as source code repositories, developmentforuns, news websites, blogs, etc. These knowledge sources cannot be detached
B. Antunes, F. Correia and P. Gomes from the developer context and are integrated in the domain layer of our contextmodel. For instance, due to the dynamic nature of the software development field,the developer must be able to gather knowledge from sources that go beyondthe limits of the organization, either to follow the technological evolution or tosearch for help whenever needed.The four context dimensions described before can be described through fourdifferent perspectives: context capture , which represents the sources of contextinformation and the way this information is gathered, in order to build the con-text model; context modeling , which represents the different dimensions, entitiesand aspects of the context information (conceptual model); context representa-tion , which represents the technologies and data structures used to represent thecontext model (implementation); and context application , which represents howthe context model is used and the objectives behind its use.
Our current work is focused on the project layer of our developer context model,and we will discuss our work at this level from the different perspectives we havepresented before.Concerning context capture, the main sources of contextual information thatfeed up the developer context model at the project level are project managementtools. These tools store a big amount of explicit and implicit information aboutthe resources produced during a software development project, how the peopleinvolved relate with these resources and how the resources relate to each other.We are focusing on two types of tools:
Version Control Systems (VCS) and
IssueTracking Systems (ITS). As shown in figure 2, the former deals with resourcesand their changes, the second deals with tasks. These systems store valuableinformation about how developers, tasks and resources relate and how theserelations evolve over time. We are especially interested in revision logs and tasks.Briefly described, a revision log tell us that a set of changes were applied by adeveloper to a set of resources in the repository. A task commonly represents aproblem report and the respective fix.The network of developers, resources, tasks and their relations will be used tobuild our context model at the project level. This way, the context model of thedeveloper, from a project point of view, will be modeled as a set of implicit andexplicit relations, as shown in figure 3. The lines with a filled pattern representthe explicit relations and those with a dotted pattern represent the implicit ones.The developers are explicitly related with revisions, as they are the ones whocommit the revisions, and with tasks, as each task is assigned to a developer.The relation between tasks and resources is not explicit, but we believe it canbe identified by analyzing the information that describe tasks and revisions. Theproximity between developers can be inferred by analyzing the resources werethey share work. Also, the resources can be implicitly related by analyzing howoften they are changed together. ontext Capture in Software Development 5
RESOURCEREVISION TASKVERSIONCONTROLSYSTEM ISSUETRACKINGSYSTEM
REFERENCES REFERENCESRISESMANAGES MANAGES
DEVELOPER
PERFORMS PERFORMS
Fig. 2.
The project layer relevant entities and their roles.In order to extract relations from the information stored in project man-agement tools, that information is previously imported and stored locally foranalysis. The prototype developed uses a database to store both the importeddata and extracted relations. In the next phase, we intend to represent theserelations and connection elements in an ontology [5], which will gradually evolveto a global developer context model ontology. We believe that representing thecontext model in an ontology and formalising it using the Semantic Web [6] tech-nologies promote knowledge sharing and reusability, since these technologies arestandards accepted by the scientific community.
DEVELOPERRESOURCE TASK5 214 3
Fig. 3.
The elements that compose the context model in the project layer.The context information extracted at the project level will be used to informthe developer about the network that links people, resources and tasks on theproject s/he works. This information can be prepared to facilitate consultingand presented to the developer easily accessible in her/his working environment.
B. Antunes, F. Correia and P. Gomes
We have implemented connectors that allowed us to collect all the desired infor-mation from the
Subversion and
Bugzilla systems, as they are among the mostpopular in use. Through the collected information, we could already perceive aset of explicit relations: which resources are created/changed by which develop-ers, which tasks have been assigned to which developers (see relations number 1and 2 in figure 3). There is also a set of implicit relations that would be valuableif disclosed.Our approach to extract implicit relations between resources and tasks (seerelation number 3 in figure 3) relies on the analysis of the text provided byrevision messages, task summaries and task comments. It is common to findreferences to task identifiers in revision messages, denoting that the revision wasmade in the context of a specific task. Also, task summaries and comments com-monly reference specific resources, either because a problem has been identifiedin a specific class or because a error stack trace is attached to the task summaryto help developers identify the source of the problem. Taking this into account,we have defined three algorithms to find resource/task and task/revision rela-tions: – Resource/Task (I) . For each resource referenced in a revision, the respectivename was searched in all task summaries. The search was performed usingthe file name and, in case it was a source code file, the full qualified name(package included) and the class name separately. – Resource/Task (II) . For each resource referenced in a revision, the respec-tive name was searched in task comments. This search was performed asdescribed for the previous relation. – Task/Revision . For each task, the respective identification number was searchedin revision messages. The search was performed using common patterns suchas “ < id > ”, “bug < id > ”and “ < id > ”.The implicit relations between resources (see relation number 4 in figure 3)can be extracted by analyzing resources that are changed together very often.Revisions are often associated with specific goals, such as the implementation ofa new feature or the correction of a bug. When developers commit revisions, theytypically change a set of resources at a time, those that needed to be changed inorder to accomplish a goal. When two resources are changed together in variousrevisions, this means that these resources are somehow related, even if theydo not have any explicit relation between them, because when one of them ismodified there is a high probability that the other also needs to be modified.The proximity between developers (see relation number 5 in figure 3) canalso be inferred by analyzing the resources they share work. Developers canshare work when they commit revisions on the same resources or when theyare assigned to tasks that are related to the same resources. This way, if twodevelopers often make changes, or perform tasks, on the same resources, theyare likely to be related. ontext Capture in Software Development 7 Table 1.
Number of extracted relations.
Resource/Task (I) Resource/Task (II) Task/Revision gEclipse 2527 31671 629Subversive 208 9076 773
To validate the relation extraction algorithms, these were tested against twoopen-source projects from the Eclipse foundation: – gEclipse . The gEclipse framework allows users and developers to access Com-puting Grids and Cloud Computing resources in a unified way, independentlyof the Grid middleware or Cloud Computing provider. Our analysis was per-formed over the work of 19 developers in a time window of approximately 3years and 3 months, which included 3279 revisions and 1508 tasks with 7765comments. – Subversive . The Subversive project supports the development of an Eclipseplug-in for Subversion integration. Our analysis was performed over the workof 10 developers in a time window of approximately 3 years and 2 months,which included 1120 revisions and 1013 tasks with 3252 comments.By applying the relation extraction algorithms to the information relatedwith these two projects, we have gathered the results represented in table 1.The table shows the number of distinct relations extracted using each one of thealgorithms in the two projects analyzed.The results show that a large amount of implicit relations can be extractedfrom the analysis of the information associated to tasks and revisions. Theserelations complement the context model we are building by connecting taskswith related resources. With a more detailed analysis we have identified someproblems with the algorithms creating some relations that do not correspond toan effective correlation between the two entities analyzed. These problems aremainly related with string matching inconsistencies and can be corrected withminor improvements in the way expressions are searched in the text.
We have developed a prototype, in the form of an Eclipse plug-in, to show howthe context information can be integrated into the an IDE and used to helpdevelopers. In figure 4 we show a screenshot of the prototype, where we cansee an Eclipse View named “Context” that shows context information relatedto a specific resource. Each time the developer opens a resource, this view isupdated with a list of developers, resources and tasks that are related with thatresource through the relations we have described before. This way the developercan easily gather information about what resources are likely to be related with
B. Antunes, F. Correia and P. Gomes that resource, what other tasks affected that resource in the past, and whatother developers may be of help if extra information is needed. The availabilityof this information inside the IDE, where developers perform most of their work,increases developers awareness and reduces their effort on finding informationthat would be hidden and dispersed otherwise.
Fig. 4.
The context plugin for Eclipse.
The EPOS (Evolving Personal to Organizational Knowledge Spaces) project,presented by Schwarz [7], aims to build organizational structured knowledgefrom information and structures owned by the elements of the organization.The world of a knowledge worker is defined as containing document-like ob-jects, objects used for classification and applications. This work environmentis taken into account when modeling the user context, which comprises infor-mation about various aspects, including currently or recently read documents,relevant topics, relevant persons, relevant projects, etc. The context model isformalized using RDFS [8], and each user’s context is an up-to-date instance ofthis context model. The context information is gathered and modeled throughuser observation and/or user feedback. The gathering and elicitation of contex-tual information is done in two ways: context-polling, by requesting a snapshot ontext Capture in Software Development 9 of the user’s current context; and context-listening, by subscribing the ContextService to be informed of every change in the user’s context. Being a developera knowledge worker, much of the concepts referenced in this work apply to thesoftware development domain, but the specificities of this domain demand fora context model adapted to the reality of the work environment of a softwaredeveloper.Modularity is in the basis of the development of complex software systemsand largely used to support a programmer’s tasks, but not always help the pro-grammer finding the desired information or delimit the point of interest for aspecific task. Based on this, Kersten and Murphy [9] have been working on amodel for representing tasks and their context. The task context is derived froman interaction history that comprises a sequence of interaction events represent-ing operations performed on a software program’s artifact. They then use theinformation in a task context either to help focus the information displayed inthe IDE, or to automate the retrieval of relevant information for completing atask. The focus of this work is the task and the knowledge elements present inthe IDE that are more relevant for the fulfillment of that task. Our approachaims to define a context model that goes beyond the IDE and explores the knowl-edge provided by the different systems that support the software developmentprocess.In the same line of task management and recovery, Parnin and Gorg [10]propose an approach for capturing the context relevant for a task from a pro-grammer’s interactions with an IDE, which is then used to aid the programmerrecovering the mental state associated with a task and to facilitate the explo-ration of source code using recommendation systems. Their approach is focusedon analyzing the interactions of the programmer with the source code, in order tocreate techniques for supporting recovery and exploration. Again, this approachis largely restricted to the IDE and the developer interaction with it.With the belief that customized information retrieval facilities can be usedto support the reuse of software components, Henrich and Morgenroth [11] pro-pose a framework that enables the search for potentially useful artifacts duringsoftware development. Their approach exploits both the relationships betweenthe artifacts and the working context of the developer. The context informationis used to refine the search for similar artifacts, as well as to trigger the searchprocess itself. The context information model is represented with RDF [12] state-ments and covers several dimensions: the user context, the working context, andthe interaction context. While the focus here is in software reuse, our approachfocuses on the information captured during the process development.
We have presented our approach of a software developer context model. Ourcontext model is based on a layered structure, taking into account four maindimensions of the work environment of a software developer: personal, project,organization and domain.
The current work is focused on the project layer of the software developercontext model. We have discussed this layer in more detail and presented pre-liminary experimentation on the context capture perspective. The results showthat it is possible to relate tasks and revisions/resources using simple relationextraction algorithms. These relations were then used in a plug-in for Eclipse tounveil relevant information to the developer.As future work we plan to improve the prototype we have developed withbetter visualization, search and filtering functionality. We also want to explorethe use of ontologies to represent the developer context model. The remaininglayers of the context model will be addressed iteratively, as an extent to thework already developed. Finally, we intend to test our approach with developersworking in with real world projects.
References
1. Mostefaoui, G.K., Pasquier-Rocha, J., Brezillon, P.: Context-aware computing: Aguide for the pervasive computing community. In: Proceedings of the IEEE/ACSInternational Conference on Pervasive Services, ICPS 2004. (2004) 39–482. Schilit, B., Theimer, M.: Disseminating active map information to mobile hosts.IEEE Network (1994) 22–323. Brown, P.J., Bovey, J.D., Chen, X.: Context-aware applications: From the labora-tory to the marketplace. Personal Communications, IEEE (1997) 58–644. Dey, A.K., Abowd, G.D.: Towards a better understanding of context and context-awareness. In: CHI 2000 Workshop on the What, Who, Where, When, and Howof Context-Awareness, The Hague, The Netherlands (2000)5. Zuniga, G.L.: Ontology: Its transformation from philosophy to information sys-tems. In: Proceedings of the International Conference on Formal Ontology inInformation Systems, ACM Press (2001) 187–1976. Berners-Lee, T., Hendler, J., Lassila, O.: The semantic web. Scientific American284