Talk given at ICSE 2010
Abstract:
The feature list of modern IDEs is steadily growing and mastering these tools becomes more and more demanding, especially for novice programmers.
Despite their remarkable capabilities, IDEs often still cannot directly answer the questions that arise during program comprehension tasks. Instead developers have to map their questions to multiple concrete queries that can be answered only by combining several tools and examining the output of each of them manually to distill an appropriate answer. Existing approaches have in common that they are either limited to a set of predefined, hardcoded questions, or that they require to learn a specific query language only suitable for that limited purpose.
We present a framework to query for information about a software system using guided-input natural language resembling plain English. For that, we model data extracted by classical software analysis tools with an OWL ontology and use knowledge processing technologies from the Semantic Web to query it.
We use a case study to demonstrate how our framework can be used to answer queries about static source code information for program comprehension purposes.
1. Talking to your
IDE
Supporting Developers with Guided-Input Natural
Language Queries
Michael Würsch, Giacomo Ghezzi, Gerald Reif, Harald C.
Gall
University of Zurich, Switzerland
University of Zurich
Department of Informatics software evolution & architecture lab
7. What fields are declared as
being of this type?
Which classes inherit from this class?
oes this type have any siblings?
Where in the type
What are the
hierarchy is this
field declared?
arguments of this
function?
Who implements this interface?
I wonder whether this method is somewhere
overridden.
What are the callers of this
method?
‣J. Silito, G. C. Murphy, K. De Volder, Asking and Answering Questions during a Programming Change Task, IEEE
TSE ’08.
‣
24. What fields are declared as
being of this type?
Simple
question!
25. What fields are declared as
being of this type?
Not so
simple
answer!
26. Using Natural Language to
express Information Needs
“The most comfortable way for a user
to express an information need is as
a natural language statement”
G. G. Chowdhury. Introduction to Modern Information Retrieval, 2004.
‣ No need to learn a specific syntax
‣ No mapping of conceptual query to a
concrete tool necessary
29. State of the Art:
Predefined Queries
‣ IDEs: Eclipse, NetBeans, IntelliJ IDEA
‣ Research Tools: Ferret1
[1] B. de Alwis and G. C. Murphy, Answering Conceptual Queries with Ferret. ICSE
’08
30. State of the Art:
Query Languages
‣ JQuery from Method caller, Method callee
‣ ASTLog
where caller.calls(callee)
and caller.fromSource()
and callee.fromSource()
‣
and caller != callee
CodeQuest and callee.getName().matches("addChart%")
select caller.getName()
‣ Semmle
http://www.semmle.com
31. Natural Language Queries powered by
Semantic Web Technology
‣ The range of possible queries should
mostly depend on the data available,
not on predefined query structures.
‣ Developers should be able to
formulate queries in (guided-
input)natural language.
32. Query
Layer Architecture
Ginseng
e
e
e
Ontology
e
Ontology for Source Other
Layer
Code Analysis Ontologies
Data Layer
Other Data
FAMIX
Models
Persistency Layer
Evolizer Hibernate Layer
www.evolizer.org
Evolizer Release History Database
33. FAMIX Core Model
superclass
belongsToClass
Class
subclass
belongsToClass
invokedBy
InheritanceDefinition Method Attribute
invokes accessedIn accesses
Invocation Access
S. Tichelaar, S. Ducasse, and S. Demeyer. Famix and Xmi. WCRE
’00
34. The Semantic Web in a
Nutshell
Meta-data to describe the semantics
of data in a machine-processable
way by the means of ontologies:
‣ Classes: JavaClass, JavaMethod
‣ Relationships: declares Method
‣ Properties: has Identifier
56. The Ontology Layer:
Flexible Mappings
@rdf(
isPredicate=true,
value= "evo:hasSuperClass"
) evo:class1
public class Inheritance {
@subject
public FAMIXClass getSubclass() {
// ...
}
evo:hasSuperClass
@object
public FAMIXClass getSuperclass() {
// ...
}
/* attributes, setter methods, and
additional behaviour */ evo:class2
}
57. The Ontology Layer:
Flexible Mappings
@rdf(
isPredicate=true,
value= "evo:hasSuperClass"
) evo:class1
public class Inheritance {
@subject
public FAMIXClass getSubclass() {
// ...
}
evo:hasSuperClass
@object
public FAMIXClass getSuperclass() {
// ...
}
/* attributes, setter methods, and
additional behaviour */ evo:class2
}
58. The Ontology Layer:
Flexible Mappings
@rdf(
isPredicate=true,
value= "evo:hasSuperClass"
) evo:class1
public class Inheritance {
@subject
public FAMIXClass getSubclass() {
// ...
}
evo:hasSuperClass
@object
public FAMIXClass getSuperclass() {
// ...
}
/* attributes, setter methods, and
additional behaviour */ evo:class2
}
59. The Ontology Layer:
Flexible Mappings
@rdf(
isPredicate=true,
value= "evo:hasSuperClass"
) evo:class1
public class Inheritance {
@subject
public FAMIXClass getSubclass() {
// ...
}
evo:hasSuperClass
@object
public FAMIXClass getSuperclass() {
// ...
}
/* attributes, setter methods, and
additional behaviour */ evo:class2
}
60. The Query Layer:
Ginseng
A. Bernstein, E. Kaufmann, C. Kaiser, and C. Kiefer. Ginseng: A Guided Input
Natural Language Search Engine for Querying Ontologies. Jena User Conf ’06.
62. Ginseng Grammar
## E.g., "what methods call (method) m?"
## "what classes are in (package) p?"
<Q> ::= What <S> <P> <O> ?
<S> ::= ...
<P> ::= ...
<O> ::= ...
Classe
63. Ginseng Grammar
## E.g., "what methods call (method) m?"
## "what classes are in (package) p?"
<Q> ::= What <S> <P> <O> ?
<S> ::= ...
<P> ::= ...
<O> ::= ...
Classe Propertie
64. Ginseng Grammar
## E.g., "what methods call (method) m?"
## "what classes are in (package) p?"
<Q> ::= What <S> <P> <O> ?
<S> ::= ...
<P> ::= ...
<O> ::= ...
Instance
Classe Propertie
65. Proof of Concept Validation
‣ JEdit, ~250kLOC
‣ 36 common program
comprehension questions1
‣ We are currently preparing a full user
study
[1] taken from B. de Alwis and G. C. Murphy, Answering Conceptual Queries with Ferret. ICSE
’08
66. Validation Overview
static dynamic evolution plug-ins
inter-class Out of 36 Questions:
20 can be
intra-class ✔ answered right
away
inheritance
✘ 9 can not be
answered
declarations
7 can be
evolution
answered, with
limitations
67. Validation Overview
static dynamic evolution plug-ins
inter-class Out of 36 Questions:
20 can be
intra-class ✔ answered right
away
inheritance
✘ 9 can not be
answered
declarations
7 can be
evolution
answered, with
limitations
68. Validation Overview
static dynamic evolution plug-ins
inter-class Out of 36 Questions:
20 can be
intra-class ✔ answered right
away
inheritance
✘ 9 can not be
answered
declarations
7 can be
evolution
answered, with
limitations
69. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field retrieved?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually used? ✘
70. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What Methods instantiate this type?
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field retrieved?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually used? ✘
71. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field retrieved?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually used? ✘
72. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field
Where is the value of this field retrieved?
retrieved?
Where is the value of this field set?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually used? ✘
73. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field retrieved?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually used? ✘
74. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field retrieved?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used?
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually
Which methods defined by this class were actually used?
used? ✘
75. (Guided-Input) Natural
Conceptual Query in Ferret (inter-class)
Language Queries in Evolizer
What methods return instances of this type? ✔
What methods instantiate this type?
What methods take an argument of this type? ✔
What fields are declared as being of this type? ✔
What calls this method? ✔
Where is the value of this field retrieved?
Where is the value of this field set?
What tests instanceof against this type? ✔
Where are casts to this type? ✔
What throws exceptions of this type? ✔
What catches exceptions of this type? ✔
What references this type by name? ✔
Which of the classes in this package were actually used? ✘
Which methods defined by this class were actually used? ✘
76. (Guided-Input) Natural
Conceptual Query in Ferret (intra-class)
Language Queries in Evolizer
What fields does this type or method access? ✔
What methods does this type or method call? ✔
What types does this type or method reference? ✔
(Guided-Input) Natural
Conceptual Query in Ferret (inheritance)
Language Queries in Evolizer
What interfaces does this type implement? ✔
What are this class’ subclasses? ✔
What classes implement this interface? ✔
What interfaces extend this interface? ✔
What are this type’s siblings? ✔
77. (Guided-Input) Natural
Conceptual Query in Ferret (declarations)
Language Queries in Evolizer
What are all the fields are declared by this type? ✔
What class methods implement this interface method?
What interface methods specify this class method?
What class methods does this method override?
What class methods override this method?
What extension points or extensions reference this [type, file, ✘
folder]?
What types is this type adaptable to? ✘
What types could this type have be adapted from? ✘
What extensions are there of this extension point? ✘
What plug-ins depend on this plug-in? ✘
(Guided-Input) Natural
Conceptual Query in Ferret (evolution)
Language Queries in Evolizer
What transactions changed this element? ✘
Who has changed this element, and when? ✘
What elements were changed in this transaction? ✘
What files were changed in this transaction? ✘
78. (Guided-Input) Natural
Conceptual Query in Ferret (declarations)
Language Queries in Evolizer
What are all the fields are declared by this type? ✔
What class methods implement this interface method?
What interface methods specify this class method?
What class methods does this method override?
What class methods override this method?
What extension points or extensions reference this [type, file, ✘
folder]?
What types is this type adaptable to? ✘
What types could this type have be adapted from? ✘
What extensions are there of this extension point? ✘
What plug-ins depend on depend on
What plug-ins this plug-in? this plug-in? ✘
(Guided-Input) Natural
Conceptual Query in Ferret (evolution)
Language Queries in Evolizer
What transactions changed this element? ✘
Who has changed this element, and when? ✘
What elements were changed in this transaction? ✘
What files were changed in this transaction? ✘
79. (Guided-Input) Natural
Conceptual Query in Ferret (declarations)
Language Queries in Evolizer
What are all the fields are declared by this type? ✔
What class methods implement this interface method?
What interface methods specify this class method?
What class methods does this method override?
What class methods override this method?
What extension points or extensions reference this [type, file, ✘
folder]?
What types is this type adaptable to? ✘
What types could this type have be adapted from? ✘
What extensions are there of this extension point? ✘
What plug-ins depend on this plug-in? ✘
(Guided-Input) Natural
Conceptual Query in Ferret (evolution)
Language Queries in Evolizer
What transactions changed this element? ✘
Who has changed this element, and when? ✘
What elements were changed in this transaction? ✘
What files were changed in this transaction? ✘
80. (Guided-Input) Natural
Conceptual Query in Ferret (declarations)
Language Queries in Evolizer
What are all the fields are declared by this type? ✔
What class methods implement this interface method?
What interface methods specify this class method?
What class methods does this method override?
What class methods override this method?
What extension points or extensions reference this [type, file, ✘
folder]?
What types is this type adaptable to? ✘
What types could this type have be adapted from? ✘
What extensions are there of this extension point? ✘
What plug-ins depend on this plug-in? ✘
(Guided-Input) Natural
Conceptual Query in Ferret (evolution)
Language Queries in Evolizer
What transactions changed this element? ✘
Who has changed this element, and
Who has changed this element, and when? ✘
when?
What elements were changed in this transaction? ✘
What files were changed in this transaction? ✘
81. (Guided-Input) Natural
Conceptual Query in Ferret (declarations)
Language Queries in Evolizer
What are all the fields are declared by this type? ✔
What class methods implement this interface method?
What interface methods specify this class method?
What class methods does this method override?
What class methods override this method?
What extension points or extensions reference this [type, file, ✘
folder]?
What types is this type adaptable to? ✘
What types could this type have be adapted from? ✘
What extensions are there of this extension point? ✘
What plug-ins depend on this plug-in? ✘
(Guided-Input) Natural
Conceptual Query in Ferret (evolution)
Language Queries in Evolizer
What transactions changed this element? ✘
Who has changed this element, and when? ✘
What elements were changed in this transaction? ✘
What files were changed in this transaction? ✘
82. Conclusions
‣ Semantic Web/Ontologies are
valuable for describing SE data
‣ Our (guided-input) NL approach
provides a single point of entry for
program comprehension tasks
within an IDE
83. What fields are declared as Architecture
being of this type?
Which classes inherit from this class?
Query
Does this type have any siblings?
Layer
Ginseng
What are the
Ontology
Ontology for Source Other
Layer
Where in the type
hierarchy is this arguments of this Code Analysis Ontologies
field declared?
function?
Data Layer
Other Data
FAMIX
Models
Who implements this interface?
Persistency Layer
Evolizer Hibernate Layer
I wonder whether this method is somewhere
overridden.
What are the callers of this method? Evolizer Release History Database
‣ J. Silito, G. C. Murphy, K. De Volder, Asking and Answering Questions during a Programming Change Task, IEEE TSE ’08.
‣ B. de Alwis and G. C. Murphy, Answering Conceptual Queries with Ferret. ICSE ‘08.
Evolizer Ontology for The Query Layer:
Source Code Analysis Ginseng
OWL Class: Class OWL Class: Method
→ hasMethod Method → accessesAttribute Attribute
→ hasAttribute Attribute → hasParameter Parameter
→ isReturnTypeOfMethod Method → invokesMethod Method
→ isSubclassOfClass Class → hasReturnType Class
→ isSuperclassOfClass Class → isInvokedByMethod Method
→ hasName String → isMethodOfClass Class
→ hasName String
OWL Class: Attribute OWL Class: Parameter
→ isAttributeOfClass Class → isParameterOfMethod Method
→ isAccessedByMethod Method → hasName String
→ hasName String
A. Bernstein, E. Kaufmann, C. Kaiser, and C. Kiefer. Ginseng: A Guided Input
Natural Language Search Engine for Querying Ontologies. Jena User Conf ’06.
84. What fields are declared as Architecture
being of this type?
Which classes inherit from this class?
Query
Does this type have any siblings?
Layer
Ginseng
What are the
Ontology
Ontology for Source Other
Layer
Where in the type
hierarchy is this arguments of this Code Analysis Ontologies
field declared?
function?
Data Layer
Other Data
FAMIX
Models
Who implements this interface?
Persistency Layer
Evolizer Hibernate Layer
I wonder whether this method is somewhere
s?
overridden.
What are the callers of this method?
on
Evolizer Release History Database
ti
‣ J. Silito, G. C. Murphy, K. De Volder, Asking and Answering Questions during a Programming Change Task, IEEE TSE ’08.
‣ B. de Alwis and G. C. Murphy, Answering Conceptual Queries with Ferret. ICSE ‘08.
es
Evolizer Ontology for Qu The Query Layer:
Source Code Analysis Ginseng
OWL Class: Class OWL Class: Method
→ hasMethod Method → accessesAttribute Attribute
→ hasAttribute Attribute → hasParameter Parameter
→ isReturnTypeOfMethod Method → invokesMethod Method
→ isSubclassOfClass Class → hasReturnType Class
→ isSuperclassOfClass Class → isInvokedByMethod Method
→ hasName String → isMethodOfClass Class
→ hasName String
OWL Class: Attribute OWL Class: Parameter
→ isAttributeOfClass Class → isParameterOfMethod Method
→ isAccessedByMethod Method → hasName String
→ hasName String
A. Bernstein, E. Kaufmann, C. Kaiser, and C. Kiefer. Ginseng: A Guided Input
Natural Language Search Engine for Querying Ontologies. Jena User Conf ’06.
86. OWL Rules
Class A Class B
declares declares
Method X Method Y
invokes
87. OWL Rules
Class A Class B
uses
declares declares
Method X Method Y
invokes
Editor's Notes
Software maintenance is hard work (NEXT), often carried out by junior developers (NEXT). If they want to solve the tasks efficiently that were assigned to them then they need to map all the questions that they have in mind to features of their favorite IDE. These features are usually scattered all over the UI and especially newcomers are often not even aware that they exist.
Software maintenance is hard work (NEXT), often carried out by junior developers (NEXT). If they want to solve the tasks efficiently that were assigned to them then they need to map all the questions that they have in mind to features of their favorite IDE. These features are usually scattered all over the UI and especially newcomers are often not even aware that they exist.
Software maintenance is hard work (NEXT), often carried out by junior developers (NEXT). If they want to solve the tasks efficiently that were assigned to them then they need to map all the questions that they have in mind to features of their favorite IDE. These features are usually scattered all over the UI and especially newcomers are often not even aware that they exist.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
Junior developers are therefore somewhat left alone in the woods (NEXT) when it comes to answering questions related to program comprehension. Examples for such questions are (*read some of the questions on the slide*)... Most of the questions you can see here were identified in the work of Silito and Colleagues and De Alwis and Murphy to be common among developers that are assigned to software evolution tasks.
We believe that IDEs should have a single point of entry to answer such questions - in addition to all those UI elements that are already commonly available in Eclipse, Netbeans, and so on. We further believe that this single point of entry should consist of a natural language interface that allows to pose such questions.
This is what this talk will be about - but let&#x2019;s first look at the state of the art (NEXT), meaning what steps are necessary to answer one particular of this questions in a modern IDE.
You can see Eclipse here, with a single project opened - namely JFreeChart, a well-known open source chart library. If we, for example, need to change some existing feature related to the user interface, in particular concerned with user input, then we could search for all classes that define fields of the type JTextField.
We do so by opening the Java Search Dialog of Eclipse.
Next we can enter JTextField as the &#x2018;Search String&#x2019; here and select &#x2018;Type&#x2019; since we are neither interested in packages, field names, method names or constructors. This would now return also type declarations of the type JTextField, so we need to further restrict the search by using the &#x2018;Limit to&#x2019; feature.
Next we can enter JTextField as the &#x2018;Search String&#x2019; here and select &#x2018;Type&#x2019; since we are neither interested in packages, field names, method names or constructors. This would now return also type declarations of the type JTextField, so we need to further restrict the search by using the &#x2018;Limit to&#x2019; feature.
Next we can enter JTextField as the &#x2018;Search String&#x2019; here and select &#x2018;Type&#x2019; since we are neither interested in packages, field names, method names or constructors. This would now return also type declarations of the type JTextField, so we need to further restrict the search by using the &#x2018;Limit to&#x2019; feature.
...so we select field types and hit ok.
finally we can invoke the search by clicking on the search button...
and the results are presented in an search results view.
What fields are declared as being of this type? A simple information request. Still you need~10 Clicks for a question that has been identified in the literature to be most common among developers.
What fields are declared as being of this type? A simple information request. Still you need~10 Clicks for a question that has been identified in the literature to be most common among developers.
What fields are declared as being of this type? A simple information request. Still you need~10 Clicks for a question that has been identified in the literature to be most common among developers.
As a software maintainer, the probably most convenient way to learn about a piece of code is to ask the original developers some questions. So, in our opinion, it is very natural to express queries, such as the ones that we have seen on the previous slides, in natural language. By providing a natural language interface, programmers do not need to learn any specific syntax and they do not need to establish a mental mapping between the functionality or user interface of a specific tool and the information need that they have in mind.
Let&#x2019;s have a look at our proof of concept tool, meaning how WE think that developers or maintainers should be able to query within Eclipse.
(Show movie)
Example code on the left, question is &#x201C;what fields are declared as being of the type String?&#x201D; When we start typing, we get some guidance in terms of auto-completion and a drop-down.
Before I explain in detail how this works, I would like to briefly have a look at the state-of-the-art in querying information about software systems.
(Show movie)
Example code on the left, question is &#x201C;what fields are declared as being of the type String?&#x201D; When we start typing, we get some guidance in terms of auto-completion and a drop-down.
Before I explain in detail how this works, I would like to briefly have a look at the state-of-the-art in querying information about software systems.
(Show movie)
Example code on the left, question is &#x201C;what fields are declared as being of the type String?&#x201D; When we start typing, we get some guidance in terms of auto-completion and a drop-down.
Before I explain in detail how this works, I would like to briefly have a look at the state-of-the-art in querying information about software systems.
We already mentioned Eclipse, but of course there are other IDEs that follow more or less the same UI paradigms. The structure of the queries that are supported are more or less hard-coded into the user interface and whenever new kind of information becomes available, we need to extend the existing UI in order to allow developers to access it.
Also very worth mentioning is Ferret, a research tool by De Alwis and Murphy. It allows a much more flexible composition of information sources from various domains, but still, someone needs to predefine the structure of the queries and implement an user interface accordingly.
On the other hand, there are query languages, that usually provide more flexibility when it comes to dynamic query composition. But if you want to use them, then you need to learn their syntax and vocabulary. Even though the syntax of these languages often resembles sql, many developers in the industry are - at least to our experience - reluctant to learn them.
These considerations lead to two key requirements for a flexible query solution: The number of different kinds of queries that are possible should automatically grow if more information becomes available
and developers should be able to use the query language they are already most familiar with - namely natural language.
Let&#x2019;s have a quick overview on our overall approach: We can see different layers of our software evolution analysis platform called Evolizer. At the heart of the platform is our so called release history database. Basically a sql database that integrates information about the development history of a software system, including its source code, version control and bug tracking information - In this talk we will only focus on static source code information extracted and stored by Evolizer.
The static source code information is captured by the so called FAMIX meta model, which I will discuss later. The model is implemented in terms of Java classes. Their instances are mapped by Hibernate down to the RHDB.
In many cases it is useful to have additional, machine-processable data semantics available - these semantics are hard to incorporate in Java class models (at least with out the excessive use of annotation-like mechanisms). This is why we have added another ontology layer to Evolizer.
The top-most layer consists of Ginseng, an existing guided natural language interface, developed by the &#x2018;dynamic and distributed systems group&#x2019; at the University of Z&#xFC;rich. It attaches to our ontology layer so that developers can formulate queries about their source code.
I will discuss the data, ontology, and query layer further on the next few slides.
Just to give you an impression of how the language-independent FAMIX meta model for source code looks like: It models the most important concepts and relationships in object-oriented programming languages, for example, classes, methods, inheritance relationships, and so on.
We have a Java parser that is built on top of JDT to instantiate such models from source code.
Briefly some background for those of you that are not familiar with the Semantic Web, before I talk about our ontology layer.
The Semantic Web, was originally brought into being to enrich Webpages with semantics, meaning meta-data so that the information on each page is not only human-readable but also machine-processable. It is, however, also very useful outside the context of the Web.
In Evolizer, we barely use any of the A.I. magic, such as reasoning, that is often associated with the Semantic Web. We rather benefit from the powerful data description framework that comes with it. In particular, we describe data by means of ontologies, meaning in terms of classes, relationships between them, and properties.
The data model of the semantic web is a graph represented by the resource description framework RDF. It is very simple but yet very powerful: Everything is described by triples of subject-predicate-object. Such triples can be queried using SPARQL, a graph-pattern-matching language.
The data model of the semantic web is a graph represented by the resource description framework RDF. It is very simple but yet very powerful: Everything is described by triples of subject-predicate-object. Such triples can be queried using SPARQL, a graph-pattern-matching language.
Using such triples, you can basically build a graph of information.
Using such triples, you can basically build a graph of information.
Using such triples, you can basically build a graph of information.
Using such triples, you can basically build a graph of information.
Using such triples, you can basically build a graph of information.
Using such triples, you can basically build a graph of information.
Here you see an excerpt of our ontology. It is defined using the Web Ontology Language OWL and consists of additional concepts that are not listed on this slide - basically anything that is contained in FAMIX too.
There is further information in the ontology, such as human readable labels or synonyms, as well as for example domain and range restrictions for the properties.
Here you see an excerpt of our ontology. It is defined using the Web Ontology Language OWL and consists of additional concepts that are not listed on this slide - basically anything that is contained in FAMIX too.
There is further information in the ontology, such as human readable labels or synonyms, as well as for example domain and range restrictions for the properties.
Using the concepts defined in the ontology, we can then compose such a graph of information about any piece of code.
Our data layer is implemented as Java classes, whereas the ontology is described in OWL. There is clearly a gap between those two representations. To overcome it, we have implemented custom Java annotations, comparable to the existing EJB 3.0 annotations that are used to persist Java objects.
@rdf at Java-class level maps to owl-classes
@rdf at Java-method level maps to owl properties, return values are the values of the property.
We then use Java reflection to translate a particular Java instance to an instance in the ontology.
This works well in most cases, but let&#x2019;s look at an example where it is not so straight-forward to provide a mapping.
The FAMIX model was influenced by a relational view. Therefore, many relationships are modeled as association classes, so that you can explicitly query for them in a relational database. Why is this bad for us?
If we look at an RDF graph again, we see that a naive mapping approach would lead to unnatural triples - unnatural in terms of that they do not form s-p-o statements anymore in a way how we would use in natural language (left). Instead, we want to have a simple statement, such as the one on the right: class1 hasSuperClass class2.
If we look at an RDF graph again, we see that a naive mapping approach would lead to unnatural triples - unnatural in terms of that they do not form s-p-o statements anymore in a way how we would use in natural language (left). Instead, we want to have a simple statement, such as the one on the right: class1 hasSuperClass class2.
If we look at an RDF graph again, we see that a naive mapping approach would lead to unnatural triples - unnatural in terms of that they do not form s-p-o statements anymore in a way how we would use in natural language (left). Instead, we want to have a simple statement, such as the one on the right: class1 hasSuperClass class2.
If we look at an RDF graph again, we see that a naive mapping approach would lead to unnatural triples - unnatural in terms of that they do not form s-p-o statements anymore in a way how we would use in natural language (left). Instead, we want to have a simple statement, such as the one on the right: class1 hasSuperClass class2.
Therefore, we can flag a class to be mapped to a predicate, rather than an subject or object, meaning a property in the ontology and not a class.
1:n relationships work well (subject = normal reference type, object = collection). n:1 and n:n relationships are not mappable so far.
Therefore, we can flag a class to be mapped to a predicate, rather than an subject or object, meaning a property in the ontology and not a class.
1:n relationships work well (subject = normal reference type, object = collection). n:1 and n:n relationships are not mappable so far.
Therefore, we can flag a class to be mapped to a predicate, rather than an subject or object, meaning a property in the ontology and not a class.
1:n relationships work well (subject = normal reference type, object = collection). n:1 and n:n relationships are not mappable so far.
For the query layer, we have used an existing query interface, called ginseng. It has been developed within a research group in Zurich, lead by Avi Bernstein. However, it is important to note that it can be replaced by almost any kind of query interface that can make some use of RDF data. In particular, there are also keyword-or free-form natural-language-based interfaces around that would work with our Evolizer.
You have already seen this query interface in action right at the beginning of my talk, and you can find more details in the related publication. But let me very briefly explain how it works in principle, to give you an impression of the queries that are possible.
The ginseng grammar consists of a static part and dynamic part. There&#x2019;s also a part that maps these statements above to the sparql query language, which I have omitted here. There are many more such rules, this is just to give you a vague impression of how a rule might look like.
What you see here is the static part of the grammar. These symbols (S, P, O) get replaced dynamically by classes, properties, or instances or literals from the ontology. Ginseng usually checks for human-readable labels, or - if no such labels are present - it does some basic string processing of the class names, the property names, and so on.
The ginseng grammar consists of a static part and dynamic part. There&#x2019;s also a part that maps these statements above to the sparql query language, which I have omitted here. There are many more such rules, this is just to give you a vague impression of how a rule might look like.
What you see here is the static part of the grammar. These symbols (S, P, O) get replaced dynamically by classes, properties, or instances or literals from the ontology. Ginseng usually checks for human-readable labels, or - if no such labels are present - it does some basic string processing of the class names, the property names, and so on.
The ginseng grammar consists of a static part and dynamic part. There&#x2019;s also a part that maps these statements above to the sparql query language, which I have omitted here. There are many more such rules, this is just to give you a vague impression of how a rule might look like.
What you see here is the static part of the grammar. These symbols (S, P, O) get replaced dynamically by classes, properties, or instances or literals from the ontology. Ginseng usually checks for human-readable labels, or - if no such labels are present - it does some basic string processing of the class names, the property names, and so on.
Finally, I would like to talk about our proof of concept validation. We have taken JEdit, a commonly used open source system, and used our infrastructure to answer 36 common program comprehension questions, taken from the Ferret-paper by De Alwis and Murphy.
As a quick side-remark, we have not yet conducted a full user study so far, but first internal results are promising.
These 36 questions are divided into 5 categories, namely inter-class, intra-class, inheritance, declarations, and evolution. They further draw information from four different spheres - the first sphere consists of static source code, the second one of dynamic traces, the third one of evolutionary data and the last one of Eclipse plug-in specific information.
Conceptually, we can answer all of those questions with our approach. However, Evolizer does not incorporate all of these spheres, so in practice, we could answer all the questions that are related to the static sphere right away, that means 20 out of 36 questions, by exactly entering them as they are listed in the paper by De Alwis and Murphy.
We could not answer 9 of these questions. In particular, those that relate to the dynamic, evolution, and plug-in sphere. Evolizer does not handle dynamic traces or Eclipse plug-in specific so far. We are currently working on the evolution part - the data is already in Evolizer and we are working on the ontologies accordingly.
Finally, we could answer 7 additional questions, but with some limitations. Examples are questions that had to be reformulated slightly or decomposed into multiple questions.
These 36 questions are divided into 5 categories, namely inter-class, intra-class, inheritance, declarations, and evolution. They further draw information from four different spheres - the first sphere consists of static source code, the second one of dynamic traces, the third one of evolutionary data and the last one of Eclipse plug-in specific information.
Conceptually, we can answer all of those questions with our approach. However, Evolizer does not incorporate all of these spheres, so in practice, we could answer all the questions that are related to the static sphere right away, that means 20 out of 36 questions, by exactly entering them as they are listed in the paper by De Alwis and Murphy.
We could not answer 9 of these questions. In particular, those that relate to the dynamic, evolution, and plug-in sphere. Evolizer does not handle dynamic traces or Eclipse plug-in specific so far. We are currently working on the evolution part - the data is already in Evolizer and we are working on the ontologies accordingly.
Finally, we could answer 7 additional questions, but with some limitations. Examples are questions that had to be reformulated slightly or decomposed into multiple questions.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
A green check-mark next to the questions denotes that we can answer the question, a red cross means that we cannot answer the question yet and a blue diamond means that we have at least some partial support for the question.
&#x2018;What Methods instantiate this type?&#x2019; - We can query for methods that call a particular constructor of a given type, but we do not make a special case for constructor invocations in our ontology so far. They are treated same as method invocations. Further, we miss dynamic information, for example when instances are created using Java reflection.
&#x2018;Where is the value of this field retrieved or set?&#x2019; - We can ask, for example &#x2018;what method accesses this field?&#x2019; but we do not distinguish reads from writes.
&#x2018;Which of the classes in this package were actually used?&#x201D; and &#x201C;Which method defined by this class were actually used?&#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.
Questions, such as &#x2018;What plug-ins depend on this plug-in&#x2019;, are not supported because we do not incorporate any IDE- or framework-specific information in Evolizer. Looking at the structure of the question itself, it is quite simple and therefore it would be possible to answer such questions, as soon as we add a Eclipse plug-in ontology and data to our release history database.
Evolizer incorporates already evolutionary data that is necessary to answer questions, such as &#x2018;Who has changed this element, and when?&#x2019;. We are currently integrating a version control ontology with our static source code ontology, and then we can answer the questions from the evolution sphere too.