1 / 29

Configuration Management Workspace Awareness for Distributed Software Development

Configuration Management Workspace Awareness for Distributed Software Development. Anita Sarma Department of Informatics & Institute for Software Research University of California, Irvine asarma@ics.uci.edu www.ics.uci.edu/~asarma Faculty Advisor: Andr é van der Hoek. Overview.

denis
Download Presentation

Configuration Management Workspace Awareness for Distributed Software Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Configuration Management Workspace Awareness for Distributed Software Development Anita SarmaDepartment of Informatics & Institute for Software ResearchUniversity of California, Irvineasarma@ics.uci.edu www.ics.uci.edu/~asarma Faculty Advisor: André van der Hoek

  2. Overview • Topic: Awareness in Configuration Management • Status: • Passed qualifying exam • Currently working on survey • Need to complete • Survey • Topic proposal • Final defense • Estimated Graduation Date: Nooit • Plans after graduation: ?

  3. A Typical Development Scenario Pete’s workspace Ellen’s workspace A B C D E C C D C C D CMrepository

  4. Direct Conflicts Pete’s workspace Ellen’s workspace A B C D E C C D C C D CMrepository Conflicting changes to the same artifact

  5. Indirect Conflicts Pete’s workspace Ellen’s workspace A B C D E C C D C C D CMrepository Conflicting changes to different artifacts

  6. Key Observations • A CM workspace in reality provides two kinds of isolation: • Good isolation • Shields developers from parallel changes to artifacts • Bad isolation • Hides knowledge of what artifacts other developers are changing • Opportunities for breaking isolation are limited • Based on repository information only • Initiated by developer only • Addressing direct conflicts only

  7. Objective • To increase awareness of ongoing workspace activities • Collect • Distribute • Organize • Present • To do so automatically and continuously • Push information • To, thereby, move earlier the point at which potential direct and indirect conflicts can be detected

  8. Approach • Provide continuous workspace awareness • Which artifacts are being changed by whom? • What is the severityand impact of the changes? • Design constraints • Non-obtrusiveness • Flexibility • Configurability • Scalability

  9. Palantír Architecture Visualizations Visualizations Extractor Extractor Internal state Internal state Event service Event wrapper Event wrapper CM client CM server CM client CMrepository Workspace Workspace

  10. Palantír Components • Extractor • Tasks • Intercept workspace activity • Interpret workspace activity • Determine whether the activity is relevant to Palantír • If relevant, gather information regarding the activity • Construct and emit one or more events • Internal State • Maintain overview of activities in both the local and remote workspaces • Subscribe to relevant workspace activities • Those pertaining to the artifacts in the local workspace but occurring in other workspaces • Siena-based event routing

  11. Palantír Components cont.. • Extractor • Further narrow down the events to be viewed • Set of workspaces • Set of authors • Set of artifacts • Visualizations • Organize and display events • Varying degrees of obtrusiveness • Ticker tape • Tabular • Explorer • Fully graphical

  12. Populating a Workspace Ellen populates her workspace withdirectories & files

  13. Making Changes in the Workspace • Ellen makes changes • edit – creates redo.c • write.c & dict.c • ‘?’ denotes artifacts are • undergoing changes • Green color denotes • changes by workspace • owner

  14. Committing Changes Ellen has finished her changes and committed them ‘?’ has changed to ‘!’ denoting changes are known Blue bars denote Severity of changes

  15. More Changes (by Other Developers) Layers denote concurrent changes Other authors denoted by shades of red color Layers can be brought forward

  16. Critical Feature: Pair-Wise Comparisons

  17. Removing and Moving Artifacts Icons denote CM activities namely move and remove

  18. Visualizations

  19. Work to Date • Basic infrastructure is in place • Four visualizations created • Integrated with three CM systems (RCS, CVS, Subversion) • Addressed the design constraints • But still need to address scalability further

  20. Current Research Plan • Research Question: Can Palantír provide more detailed and precise information such that developers can better coordinate their parallel activities? • Key Insight: Incorporate analysis in Palantír • Approach: Calculate and present severity and impact of changes • Evaluation: Case study Palantír in actual development setting

  21. Severity Analysis • “The amount (size) of change between two versions of an artifact” • Currently calculated as the percentage of lines of code that have changed, a simple but not completely accurate measure • Proposed algorithms • Token based difference • Measures structural changes, but language dependent • Abstract syntax tree • Very detailed analyses, but likely too expensive (and language dependent) • Fits easily into the infrastructure

  22. Impact Analysis • “The effect of changes on my current work(space)” • Proposed algorithms • Overlapping lines of code • Simple, but inaccurate • Changed interfaces • Potentially accurate and effective, but language dependent • Dependency analysis • Very precise, semantic results, but complex (and language dependent) • Does not fit easily in the infrastructure

  23. Evaluation • Case study to determine the effectiveness of Palantír • Does it reduce the number of conflicts? • Does it speed up development time? • Does it improve coordination? • Does it scale? • Comparison • Current prototype in a real development scenario to determine baseline information • Palantír as enhanced with advanced severity and change impact measures to determine the effectiveness of these measures in conflict detection

  24. Back-Up Evaluation • Simulate an actual development environment • Obtain a representative CM archive • “Run” through Palantír • Compare actual problems with highlighted problems

  25. Conclusions • We have demonstrated the feasibility of a novel approach to increasing workspace awareness with a basic prototype of Palantír • We have to determine which measures of severity and impact analysis we can use • Determine which of these measures are accurate in highlighting potential conflicts • Evaluate Palantír to determine its effective-ness in reducing conflicts in software development

  26. Related Work • Configuration Management Systems • CVS and many other CM systems • Only e-mail notifications • Coven • Developers do not know in advance what they will change • Night Watch • Cover

  27. Related Work cont.. • In the area of CSCW • BSCW, TUKAN, COOP/Orm • No pair-wise comparisons, no severity measure • State Treemap • No pair-wise comparisons • Sepia

  28. Acknowledgements • Effort funded by the National Science Foundation under grant numbers CCR-0093489 and IIS-0205724. • Special thanks to undergraduates • Peggy Lin • Zahra Noorozi

More Related