The Emergent Structure of Development Tasks

Slides:



Advertisements
Similar presentations
University of British Columbia Software Practices Lab ECOOP 2005 The Emergent Structure of Development Tasks Gail Murphy Joint work with Mik Kersten, Martin.
Advertisements

Software Lifecycle A series of steps through which a software product progresses Lifetimes vary from days to months to years Consists of –people –overall.
© 2005 UBC; made available under the EPL v1.0 mylar a degree-of-interest model for eclipse Mik Kersten Gail Murphy Shawn.
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Hipikat: A Developer’s Recommender Davor Cubranic, Gail Murphy, and Kelly Booth University of British Columbia.
Methods For Web Page Design 6. Methods Why use one? What it covers –Possibly all stages Feasibility Analysis Design Implementation Testing –Maybe just.
1 N Degrees of Separation: Multi-Dimensional Separation of Concern (MDSOC) HyperJ: language and concepts of general concern combination.
Hipikat: A Project Memory for Software Development The CISC 864 Analysis By Lionel Marks.
Aspect Oriented Programming Sumathie Sundaresan CS590 :: Summer 2007 June 30, 2007.
AOP-1 Aspect Oriented Programming. AOP-2 Aspects of AOP and Related Tools Limitation of OO Separation of Concerns Aspect Oriented programming AspectJ.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
M1G Introduction to Programming 2 3. Creating Classes: Room and Item.
aspectj tools new and noteworthy Mik Kersten University of British Columbia Adrian Colyer IBM Hursley OOPSLA, October
E-Mission + Team of undergraduates = ??? Background and motivation.
Copyright © 2004, Keith D Swenson, All Rights Reserved. OASIS Asynchronous Service Access Protocol (ASAP) Tutorial Overview, OASIS ASAP TC May 4, 2004.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
Presenters: Wei-Chih Hsu Professor: Ming-Puu Chen Date: 12/18/2007
JavaScript/ App Lab Programming:
Advanced Computer Systems
Provide instruction.
Understanding NMC allegations data, and developing a coding frame to categorise future allegations data Rob Francis Matt Reynolds March 2017 Restricted.
Advanced Programing practices
Support for Program Analysis as a First-Class Design Constraint in Legion Michael Bauer 02/22/17.
Learning to Program D is for Digital.
John D. McGregor Session 9 Testing Vocabulary
Connecting Interface Metaphors to Support Creation of Path-based Collections Unmil P. Karadkar, Andruid Kerne, Richard Furuta, Luis Francisco-Revilla,
SURFBRD Michael Margel Dec CSC 2524.
Architecture Concept Documents
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Unified Modeling Language
Brian Leonard ブライアン レオナルド
Arab Open University 2nd Semester, M301 Unit 5
Aspect-Oriented Programming with the Eclipse AspectJ plug-in
Software Documentation
AP CSP: Bytes, File Sizes, and Text Compression
John D. McGregor Session 9 Testing Vocabulary
Frequently asked questions about software engineering
Child Outcomes Summary (COS) Process Training Module
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
The design process Software engineering and the design process for interactive systems Standards and guidelines as design rules Usability engineering.
EE 193: Parallel Computing
ADO.NET Entity Framework Marcus Tillett
 DATAABSTRACTION  INSTANCES& SCHEMAS  DATA MODELS.
Cracking the Coding Interview
Child Outcomes Summary (COS) Process Training Module
Extraversion Introversion
John D. McGregor Session 9 Testing Vocabulary
Performance Task Overview
Design and Programming
System Sequence Diagrams
Introduction To System Analysis and Design PART 2
Human Complexity of Software
Winter 2018 CISC101 12/1/2018 CISC101 Reminders
UNIT 3 CHAPTER 1 LESSON 4 Using Simple Commands.
Systems, Models and Simulations
CS 201 Fundamental Structures of Computer Science
Analysis models and design models
Review CSE116 2/21/2019 B.Ramamurthy.
Code search & recommendation engines
Advanced Programing practices
Automating Profitable Growth™
Analytics – Statistical Approaches
Automated Analysis and Code Generation for Domain-Specific Models
Chapter 5 Architectural Design.
Use Case Analysis – continued
Automating Profitable Growth™
Information Retrieval
Function-oriented Design
Presentation transcript:

The Emergent Structure of Development Tasks University of British Columbia Gail C.Murphy Mik Kersten Martin P. Robillard Davor Cubranic Present by Maryam Arab Spring 2017

Introduction to task structure Development tasks require changes that are scattered across system artifacts spending more time looking for relevant information may not always be finding relevant information support for task structure can improve the effectiveness of existing tools enable support for new operations improve a developer’s individual and group work.

Claim Current tools are not sufficiently supporting a developer to find and manipulate the pieces of a project’s information space on which they are working to manage the multiple problems on which they work at the same time 90% of changes touch more than one file Our claim is that current tools are falling short in helping a developer in two areas: finding and manipulating the parts of artifacts they need to work on, and managing the multiple problems they must constantly deal with. One thing you could be thinking is that the kind of programming work I am talking about are few and far between. After all, we’ve spent a lot of time and energy designing and implementing programming languages that are intended to minimize the number of modules you must typically change as a software system evolves. To give you some sense that changes still require visiting and modifying multiple places in a code base, here is a graph showing modifications made to two open-source systems: Eclipse and Mozilla over a number of months. 90% of the changed touched more than one file and for 20 transactions randomly sampled from Eclipse, 25% represented non-local changes (non-package, non-plug-in).

The Challenge The challenge is that the information space the developer is working with is huge. Here is just part of the information space for the bug we were trying to solve. Taking a bit of a closer look, we can see the kinds of nodes in this graph. The nodes are parts of artifacts (source code, the bugs, test cases, documentation, etc.) and the edges are different relationships that might appear such as a method in StackLayout calling a method that is declared in IFigure, and the bug referring to the start method.

Task Context Parts and relationships of artifacts relevant to a developer as they work on the task Can be approximated as a developer works: algorithmically over the structure of the graph by monitoring a developer’s activity and heuristics on the graph We use a different term, task context, for the structure that emerges as a developer works. In general, task context is a superset of task structure as it includes parts of artifacts that are accessed, not only those parts that are ultimately changed. We can approximate task context in different ways as a developer works. For instance, we could run algorithms over the areas of the information space the developer is working on to extract the probable context. Or we can monitor how the developer is working with the graph and use heuristics. Let’s look at each of these in a bit more detail.

Asynchronous & Task Structure E.g., Imagine a HipikatTS group memory would include structures of completed tasks search group memory with structure of current task How can task structure help these tools? Well, its simple. The task structure provides a richer search context. Imagine a Hipikat with task structure. The group memory would include task structures for completed tasks and you could use this information to provide better searchs – since a problem with Hipikat is that not everything returned is relevant. Imagine here you are working on some AspectJ code involving some kind of updating of figures (sound familiar  ). As you are accessing and forming a task structure, Hipikat could in the background be searching for similar past tasks and recommending them as little bugs in the gutter. If you open up that bug, you see the task structure of the recommended completed bug with the overlap highlighted.

Synchronous & Task Structure E.g., Imagine comparing task structures on check-in compare committer’s task structure to current task structures of other group members perform focused source analyses on those task structures Committer’s Task Structure Other Developer’s Task Structure How can task structure help here? JAZZ and Palantir both already support some comparison of workspace activity. As with the IDE level, task structure can help in focusing the information (and perhaps in speeding the analysis). For instance, imagine a developer reaches the point they want to check-in some code. Right before the actual check-in, a tool could run to compare the developer’s task structure with the task structure’s of their team members. This comparison could involve analyses that run from the task structure, maybe searching out x levels for similarity or interaction. In the example, we have played around with conceptually, the committing developer checks-in code that causes a new call to a method and a team member has code that changes an aspect that narrows some advice affecting that call which might change semantics. We could perform a focused analysis and then present the results using the task structure for context.

Improve IDE Platform Capture and recommend workflow E.g., mine completed task structures for patterns to form best practices or inform UI Simplify tool development E.g., arbitrate competition for limited screen real estate like gutters based on task being performed Task structure could also help us improve the IDE platform. For instance, one problem faced in tools like Rational is that they are now composed of many many many plug-ins. Its hard for developers to even find relevant functionality. We could mine collected task structures to determine which parts of tools were being used and use that to improve the UI (perhaps in a dynamic adaptive way or perhaps not). Embedding some explicit recognition of task structure in the IDE might also simplify tool development so that tools could compete for limited screen real estate depending upon the active task.

Open Questions How should task structure be defined? should it include rationale? should it include how the task was worked on? should it include confidence levels? Can we determine task structure accurately without the developer’s involvement? Can we make more program analyses feasible by using the focus of task structure? Which is better to pursue: tool support for task structure or improve the languages developers use to express their systems? And many more…

Summary There is a mismatch between This mismatch can be reduced by how developers work with software artifacts how tools attempt to support that work This mismatch can be reduced by capturing, retaining and using the structure of tasks to focus tool support niftyIconFile Plugin.xml