Brian de Alwis and Gail Murphy Dept of Computer Science University of British Columbia, Canada Presented at the International Conference on Software Engineering.

Slides:



Advertisements
Similar presentations
A Method for Validating Software Security Constraints Filaret Ilas Matt Henry CS 527 Dr. O.J. Pilskalns.
Advertisements

Testing Relational Database
The Problem Decomposition of programs in terms of classes and in terms of crosscutting concerns are both useful, but languages based on source files allow.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Relational Algebra Chapter 4, Part A Modified by Donghui Zhang.
INFS614, Fall 08 1 Relational Algebra Lecture 4. INFS614, Fall 08 2 Relational Query Languages v Query languages: Allow manipulation and retrieval of.
1 The JQuery Tool A Generic Query-Based Code browser for Eclipse Project leaders: Kris De Volder, Gregor Kiczales Students: Doug Janzen, Rajeswari Rajagopalan,
Exploring the Neighborhood with Dora to Expedite Software Maintenance Emily Hill, Lori Pollock, K. Vijay-Shanker University of Delaware.
Software Practices Lab. -- The University of British Columbia 1 The JQuery Tool A Generic Query-Based Code browser for Eclipse Project leaders: Kris De.
Using Information Fragments to Answer the Questions Developers Ask Thomas Fritz and Gail C. Murphy University of British Columbia.
Train Control Language Teaching Computers Interlocking By: J. Endresen, E. Carlson, T. Moen1, K. J. Alme, Haugen, G. K. Olsen & A. Svendsen Synthesizing.
Dynamic Ontologies on the Web Jeff Heflin, James Hendler.
PDDL: A Language with a Purpose? Lee McCluskey Department of Computing and Mathematical Sciences, The University of Huddersfield.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Combining Static and Dynamic Data in Code Visualization David Eng Sable Research Group, McGill University PASTE 2002 Charleston, South Carolina November.
Writing Good Software Engineering Research Papers A Paper by Mary Shaw In Proceedings of the 25th International Conference on Software Engineering (ICSE),
Database Management Systems, R. Ramakrishnan and J. Gehrke1 Relational Algebra Chapter 4, Part A.
1 Software Testing and Quality Assurance Lecture 30 – Testing Systems.
Rutgers University Relational Algebra 198:541 Rutgers University.
Relational Algebra Chapter 4 - part I. 2 Relational Query Languages  Query languages: Allow manipulation and retrieval of data from a database.  Relational.
CSCD343- Introduction to databases- A. Vaisman1 Relational Algebra.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Relational Algebra, R. Ramakrishnan and J. Gehrke (with additions by Ch. Eick) 1 Relational Algebra.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Concordia University Department of Computer Science and Software Engineering Click to edit Master title style ADVANCED PROGRAMING PRACTICES API documentation.
Advanced Database CS-426 Week 2 – Logic Query Languages, Object Model.
Introduction to Systems Analysis and Design Trisha Cummings.
XFindBugs: eXtended FindBugs for AspectJ Haihao Shen, Sai Zhang, Jianjun Zhao, Jianhong Fang, Shiyuan Yao Software Theory and Practice Group (STAP) Shanghai.
© 2005 University of British Columbia mylar a degree-of-interest model for IDEs Mik Kersten Gail Murphy University of.
1 N Degrees of Separation: Multi-Dimensional Separation of Concern (MDSOC) HyperJ: language and concepts of general concern combination.
Architecture-Based Runtime Software Evolution Peyman Oreizy, Nenad Medvidovic & Richard N. Taylor.
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
Introduction to Software Design Chapter 1. Chapter Objectives  To become familiar with the software challenge and the software life cycle  To understand.
Mining and Analysis of Control Structure Variant Clones Guo Qiao.
HCI in Software Process Material from Authors of Human Computer Interaction Alan Dix, et al.
Lecture 05 Structured Query Language. 2 Father of Relational Model Edgar F. Codd ( ) PhD from U. of Michigan, Ann Arbor Received Turing Award.
Reviewing Recent ICSE Proceedings For:.  Defining and Continuous Checking of Structural Program Dependencies  Automatic Inference of Structural Changes.
Debug Concern Navigator Masaru Shiozuka(Kyushu Institute of Technology, Japan) Naoyasu Ubayashi(Kyushu University, Japan) Yasutaka Kamei(Kyushu University,
AOP-1 Aspect Oriented Programming. AOP-2 Aspects of AOP and Related Tools Limitation of OO Separation of Concerns Aspect Oriented programming AspectJ.
2007. Software Engineering Laboratory, School of Computer Science S E Web-Harvest Web-Harvest: Open Source Web Data Extraction tool 이재정 Software Engineering.
Lesson Overview 3.1 Components of the DBMS 3.1 Components of the DBMS 3.2 Components of The Database Application 3.2 Components of The Database Application.
STASIS Technical Innovations - Simplifying e-Business Collaboration by providing a Semantic Mapping Platform - Dr. Sven Abels - TIE -
1 Asking and Answering Questions during a Programming Change Task, By Jonathan Sillito, Member, IEEE, Gail C. Murphy, Member, IEEE, and Kris De Volder.
1 Relational Algebra and Calculas Chapter 4, Part A.
1.1 CAS CS 460/660 Introduction to Database Systems Relational Algebra.
Presented by: Ashgan Fararooy Referenced Papers and Related Work on:
Hassen Grati, Houari Sahraoui, Pierre Poulin DIRO, Université de Montréal Extracting Sequence Diagrams from Execution Traces using Interactive Visualization.
1 Relational Algebra Chapter 4, Sections 4.1 – 4.2.
1. 2 Preface In the time since the 1986 edition of this book, the world of compiler design has changed significantly 3.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Database Management Systems Chapter 4 Relational Algebra.
CSCD34-Data Management Systems - A. Vaisman1 Relational Algebra.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University IWPSE 2003 Program.
Design and Implementation of a Rationale-Based Analysis Tool (RAT) Diploma thesis from Timo Wolf Design and Realization of a Tool for Linking Source Code.
Data Structures and Algorithms Dr. Tehseen Zia Assistant Professor Dept. Computer Science and IT University of Sargodha Lecture 1.
Modularly Typesafe Interface Dispatch in JPred Christopher Frost and Todd Millstein University of California, Los Angeles
Visualization Four groups Design pattern for information visualization
Generating Software Documentation in Use Case Maps from Filtered Execution Traces Edna Braun, Daniel Amyot, Timothy Lethbridge University of Ottawa, Canada.
Text TCS INTERNAL Oracle PL/SQL – Introduction. TCS INTERNAL PL SQL Introduction PLSQL means Procedural Language extension of SQL. PLSQL is a database.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
ECE 750 Topic 8 Meta-programming languages, systems, and applications Automatic Program Specialization for J ava – U. P. Schultz, J. L. Lawall, C. Consel.
1 CS122A: Introduction to Data Management Lecture #7 Relational Algebra I Instructor: Chen Li.
Chapter 6 - Database Implementation and Use
Relational Algebra Chapter 4, Part A
Relational Algebra 461 The slides for this text are organized into chapters. This lecture covers relational algebra, from Chapter 4. The relational calculus.
Introduction to Systems Analysis and Design
Multiple Aspect Modeling of the Synchronous Language Signal
Relational Algebra Chapter 4, Sections 4.1 – 4.2
Course: Module: Lesson # & Name Instructional Material 1 of 32 Lesson Delivery Mode: Lesson Duration: Document Name: 1. Professional Diploma in ERP Systems.
Presentation transcript:

Brian de Alwis and Gail Murphy Dept of Computer Science University of British Columbia, Canada Presented at the International Conference on Software Engineering (ICSE 2008) Class: CISC 879 Oct Giriprasad Sridhara

Motivation  Software Maintenance  Hard (60 to 90% of development costs)  Scenario: Developer maintaining code written by another programmer, in an auction bidding software  Now she is interested in knowing… How is “remove auction” implemented? Which method(s) call RemoveAuction? Who last changed RemoveAuction and why did he change it? What other methods in this class are used (addAuction…)? Conceptual Queries Feature Location

Answering Conceptual Queries  Conceptual queries can be answered by  Looking at version history  Browsing call graph,  Checking inheritance hierarchy ……  But  Tedious (in the best case)  Data overload and disorientation (worst case)  Net effect: Programmer is more likely to introduce buggy code

Three problems with using existing tools for answering conceptual queries  Map & scope  Map query to existing concrete queries and scope the results to those of interest  Example: Conceptual Query: Where is this exception thrown?  Mapping: Manually search references to exception  Scoping: Manually examine results to find actual throw

Three problems with using existing tools for answering conceptual queries  Compose  To answer a single conceptual Query:  May need to make multiple concrete queries  And compose the results  Example: Conceptual Query: Where is this interface created?  Step 1: Find concrete classes implementing the interface  Step 2: Find locations in code where the implementing classes are created.

Three problems with using existing tools for answering conceptual queries  Integrate and reason  To answer a single conceptual Query:  Integrate across different sources of information  Reason across different sources of information  Tools have potentially different internal representations of an element  Conceptual Query: When is this interface method called (during a run)?  Step 1: Static Information: Find classes implementing the interface  Step 2: Dynamic information: Look for calls on implementing classes in execution traces Wish I could get answers to all my questions easily!

Problem Statement  Define a model that supports integration of different sources of information about a program.  The model should enable: the results of concrete queries in separate tools to be brought together to directly answer many of a programmer’s conceptual queries  Show that the model is practical by implementing a proof of concept tool StaticDynamicEvolution Combined (Static+Dynamic+Evolution)

State of the art  Integrate different tools  Wassermann (90)  Drawback: Assumes direct correspondence between artifacts  Cross artifact search  GSEE (Favre 05)  SEXTANT (Schafer et al. 06)  Drawback: Assumes direct correspondence between artifacts  Query Languages  CodeQuest (Hajiyev and de Moor 06)  JQuery (Janzen and de Volder 03)  SCA (Paul and Prakash 96)  Drawback: No support for correspondences between elements

Proposed Approach  Integrate the different sources of information  Develop a model that  Supports composition and integration of different sources of program information  Form a single queryable knowledge base that can answer conceptual queries

Contribution  Theory: Development of a model for answering 36 different conceptual queries  Conceptual queries have been obtained from  Prior research (Sillito et al. 06, Voinea et al. 07)  Blogs  Experience  Practice: Ferret – implementation of the model

Theory: The Sphere Model  Spheres – different sources of program information  Example:  Static Java relations in the source  Revision history  Dynamic execution trace

Theory: Formal Definition of a Sphere  Sphere S is a tuple, S =  E = Set of elements in the source  L = Set of relation labels existing between elements  R = Subset of L X E X E  Example: Element Type Static Dynamic Evolution Eclipse Plug-in

Theory: Example of Sphere elements and relations Relation TypeRelations StaticImplements, calls, instantiates… DynamicCalls, was-invoked, was-instantiated… EvolutionModified-by Eclipse plug-insDepends, extends… Element TypeElements StaticClasses, methods, fields… DynamicClasses, methods EvolutionRevisions, transactions Eclipse Plug-inExtension points… Elements Relations

Theory: Composing Sphere Relations  Conceptual Query:“which of the implementations of this interface were actually instantiated in this last run?”  Insight: Composing static information with dynamic information allows a tool to answer such a conceptual query.  Composition of sphere S1 by S2:  S1 O f S2 = (E1 U E2, L1 U L2, f (R1;R2))

Theory: Composition functions  For the relations R1 and R2 in the spheres S1 and S2,  Union:  Includes relations from both spheres involved in the composition  Supposing 5 methods m1, m2, m3, m4, m5 have calls in a program to a method m  Supposing during two different runs of the program Relation (calls, m1, m) (calls, m2, m) Relation (calls, m3, m) (calls, m4, m) Union Relation (calls, m1, m) (calls, m2, m) (calls, m3, m) (calls, m4, m)

Theory: Composition functions  For the relations R1 and R2 in the spheres S1 and S2,  Replacement  Relations of R1 with a label from R2 are removed and replaced with relations from R2  Supposing 5 methods m1, m2, m3, m4, m5 have calls in a program to a method m Relations (calls, m1, m) (calls, m2, m) (calls, m3, m) (calls, m4, m) (calls, m5, m) Other relations Relation (calls, m1, m) (calls, m3, m) Relations (calls, m1, m) (calls, m3, m) Other relations

Theory: Composition functions  For the relations R1 and R2 in the spheres S1 and S2,  Transformation  Joins relations of R1 by a subset of R2 with a particular label l r of R2

Practice: Ferret Tool Proof of concept tool for the model (Eclipse view) Implements 36 conceptual queries across 4 spheres Conceptual queries are issued in the context of a program element like method name

Practice: Ferret implementation  Ferret implements 4 spheres SphereImplementation Static JavaEclipse JDT Dynamic javaEclipse Test and Performance Tools (TPTP) Software EvolutionKenyon Plug-in developmentEclipse PDE

Practice: Ferret implementation  Ferret implements 36 conceptual queries  Example CategoryQuery Inter-classWhat calls this method? Inter-classWhere is the value of this field retrieved? Intra-classWhat methods does this method call? InheritanceWhat classes implement this interface? DeclarationsWhat are all the fields are declared by this type? EvolutionWho has changed this element and when?

Practice: Realization of a Conceptual query  Conceptual query: Relational operators over relation names  Example: Conceptual Query “What instantiates this type?”  Implementors O instantiators  Implementors relation  Takes an input, say some type T  Returns all concrete classes implementing T  Instantiators relation  Take as input all concrete classes implementing T  Return all methods instantiating a class C

Evaluation  Evaluate tool  Evaluate underlying model  Two types of evaluation  Benchmarking  Study of tool usage by real world programmers

Evaluation (benchmarking)  Question: What is Ferret’s querying performance?  Configuration 1 : Ferret uses only static information.  How does it compare with a normal static Java tool?  Configuration 2 : Ferret uses only static and dynamic information.  Is time taken for query through Ferret < time taken by programmer to use different existing tools and combine the results?  Setup:  Average timings for Ferret invocation on ARGOUML project  Select certain types and methods to trigger Ferret

Evaluation Results (benchmarking)  Ferret Benchmark timings in seconds:  First three rows represent Ferret performance for types  Last three rows represent Ferret performance for methods/field Conclusion: Timings faster than time required by developer if he was using multiple tools and combining the results.

Evaluation: Field Study Questions  Question: Are the 36 queries implemented by Ferret useful to real world programmers?  Question:  Which conceptual queries implemented in Ferret are useful to programmers?  Is the composition of static and dynamic program information, which have some overlap in their concrete queries, useful?  Are there features of Ferret that programmers find particularly useful?

Evaluation: Field Study Setup  Two day diary study with four Java programmers (P1-P4) working on their own code base  Each programmer used Ferret instrumented to record queries used by the programmers  Spheres used in Ferret  Static (JDT)  Dynamic (Eclipse TPTP)  Plug-in (PDE)  Could not configure Evolution Sphere (Kenyon)  Two programmers used integration of Static and PDE spheres  One programmer used integration of Static, PDE and Dynamic Java Sphere  Interview with developers at the end

Evaluation: Field Study Results  Programmers found Ferret useful!  Frequently used conceptual queries:  Comparatively fewer Eclipse searches were used  Authors conclude that this shows Ferret satisfied the programmers needs for contextual queries Conceptual QueryPercentage usage What calls this method?28 Where is the value of this field retrieved?8 What methods does this method call?8 What types does this type reference6.5 What fields does this method access6

Conclusions  Problem Statement: Define a model that supports integration of different sources of information about a program to easily answer conceptual queries.  Contribution: Introduced the sphere model for conceptual queries  Problem Statement: Determine if the model is practical.  Contribution: As proof of concept, implemented the sphere model for 36 conceptual queries in the tool Ferret.

Conclusions  Evaluation:  Is the performance of the tool (time) acceptable?  YES! Measured by timing on ArgoUML project.  Do real world programmers find Ferret useful?  YES! Field study done on 4 real world Java programmers.  Implication  For many of the conceptual queries used by programmers, we now have an easy way of getting answers  No need to struggle across multiple tools and their outputs

Future work  Presentation issues  Extending Ferret for other conceptual queries  In theory, what all conceptual queries can the sphere model support?

Class Discussion  All opinions expressed regarding this paper are my own.  They do not necessarily reflect the views of the instructor.  Overall,  The concept of conceptual queries is good (i.e., background work of Sillito et al.)  Motivating examples for the tool are weak (especially the map and scope example in the introduction)  Evaluation:  is particularly weak  Need more rigorous benchmark tests  Benchmarking runs claim that performance w.r.t time is comparable to static tools offered by Eclipse  But in the Field Study, programmer P1 used Eclipse instead of Ferret as he said he did not want to wait for Ferret  Ferret slow?

Class Discussion  Evaluation Field Study:  Need more rigorous study  Basically only 3 spheres were used (Version information Sphere Kenyon could not be configured)  Only one programmer used 3 spheres  Effectively studied with only 2 spheres (static and PDE)  Not sure how necessary was the PDE sphere  So probably 2 programmers needed only the static sphere  How easy is it to add more information spheres to Ferret?