Talking to your
IDE
Supporting Developers with Guided-Input Natural
Language Queries
Michael Würsch, Giacomo Ghezzi, Geral...
Software
Maintenance
Software
Maintenance




       Junior Dev
Software
Maintenance




       Junior Dev



                    Feature-rich IDEs
What fields are declared as
                                         being of this type?
       Which classes inherit from ...
What fields are declared as
       being of this type?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as being of the type JTextField?
What fields are declared as
       being of this type?
What fields are declared as
              being of this type?
  Simple
question!
What fields are declared as
       being of this type?




                     Not so
                     simple
        ...
Using Natural Language to
express Information Needs

“The most comfortable way for a user
to express an information need i...
What fields are declared as being of the type String?
What fields are declared as being of the type String?
State of the Art:
  Predefined Queries


‣ IDEs: Eclipse, NetBeans, IntelliJ IDEA
‣ Research Tools: Ferret1




           ...
State of the Art:
    Query Languages

‣   JQuery                  from Method caller, Method callee

‣   ASTLog
         ...
Natural Language Queries powered by
      Semantic Web Technology



   ‣ The range of possible queries should
     mostly...
Query
 Layer                          Architecture

                                  Ginseng




                        ...
FAMIX Core Model

                          superclass
                                                                bel...
The Semantic Web in a
      Nutshell

Meta-data to describe the semantics
of data in a machine-processable
way by the mean...
The Semantic Web:
      RDF



S→P→O
Class A → hasMethod →   Method B
The Semantic Web:
      RDF




Class A → hasMethod →   Method B
The Semantic Web:
      RDF

Class A → hasMethod →   Method B
The Semantic Web:
      RDF

Class A → hasMethod →   Method B
The Semantic Web:
      RDF

Class A → hasMethod →    Method B

                            ↓

                        cal...
The Semantic Web:
      RDF

Class A → hasMethod →    Method B

                            ↓

                        cal...
The Semantic Web:
      RDF

Class A → hasMethod →    Method B

                            ↓

                        cal...
The Semantic Web:
      RDF

Class A → hasMethod →     Method B

                             ↓

                         ...
The Semantic Web:
      RDF

Class A → hasMethod →     Method B

              ↑              ↓

          inverseOf      ...
The Semantic Web:
       RDF

 Class A → hasMethod →     Method B

    ↑            ↑            ↓

isSiblingOf   inverseO...
Evolizer Ontology for
     Source Code Analysis
OWL Class: Class                OWL Class: Method
→ hasMethod Method      ...
Evolizer Ontology for
     Source Code Analysis
OWL Class: Class                OWL Class: Method
→ hasMethod Method      ...
Evolizer Ontology for
     Source Code Analysis
OWL Class: Class                OWL Class: Method
→ hasMethod Method      ...
Example: RDF Graph

                                                                  evo:Method
                         ...
The Ontology Layer:
             General Approach
@rdf("evo:Class")
public class FAMIXClass {
  	 	
  	 @rdf("evo:hasName"...
The Ontology Layer:
     The Relational View
                          superclass
                                        ...
The Ontology Layer:
     The Relational View
                          superclass
                                        ...
The Ontology Layer:
          The S-P-O View
                                                                             ...
The Ontology Layer:
          The S-P-O View
                                                                             ...
The Ontology Layer:
          The S-P-O View
                                                                             ...
The Ontology Layer:
          The S-P-O View
                                                                             ...
The Ontology Layer:
       Flexible Mappings
@rdf(
	      isPredicate=true,
 	     value= "evo:hasSuperClass"
	   )       ...
The Ontology Layer:
       Flexible Mappings
@rdf(
	      isPredicate=true,
 	     value= "evo:hasSuperClass"
	   )       ...
The Ontology Layer:
       Flexible Mappings
@rdf(
	      isPredicate=true,
 	     value= "evo:hasSuperClass"
	   )       ...
The Ontology Layer:
       Flexible Mappings
@rdf(
	      isPredicate=true,
 	     value= "evo:hasSuperClass"
	   )       ...
The Query Layer:
                            Ginseng




A. Bernstein, E. Kaufmann, C. Kaiser, and C. Kiefer. Ginseng: A G...
Ginseng Grammar

## E.g., "what methods call (method) m?"
##       "what classes are in (package) p?"

<Q> ::= What <S> <P...
Ginseng Grammar

## E.g., "what methods call (method) m?"
##       "what classes are in (package) p?"

<Q> ::= What <S> <P...
Ginseng Grammar

## E.g., "what methods call (method) m?"
##       "what classes are in (package) p?"

<Q> ::= What <S> <P...
Ginseng Grammar

## E.g., "what methods call (method) m?"
##       "what classes are in (package) p?"

<Q> ::= What <S> <P...
Proof of Concept Validation


 ‣ JEdit, ~250kLOC
 ‣ 36 common program
   comprehension questions1


 ‣ We are currently pr...
Validation Overview
   static                   dynamic   evolution   plug-ins



              inter-class               ...
Validation Overview
   static                   dynamic   evolution   plug-ins



              inter-class               ...
Validation Overview
   static                   dynamic   evolution   plug-ins



              inter-class               ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (inter-class)
                                                     ...
(Guided-Input) Natural
     Conceptual Query in Ferret (intra-class)
                                                 Lang...
(Guided-Input) Natural
    Conceptual Query in Ferret (declarations)
                                                     ...
(Guided-Input) Natural
    Conceptual Query in Ferret (declarations)
                                                     ...
(Guided-Input) Natural
    Conceptual Query in Ferret (declarations)
                                                     ...
(Guided-Input) Natural
    Conceptual Query in Ferret (declarations)
                                                     ...
(Guided-Input) Natural
    Conceptual Query in Ferret (declarations)
                                                     ...
Conclusions

‣ Semantic Web/Ontologies are
  valuable for describing SE data
‣ Our (guided-input) NL approach
  provides a...
What fields are declared as                                                                                                ...
What fields are declared as                                                                                                ...
Software Evolution
                           Ontology
Version Control Ontology                                    ver:Fil...
OWL Rules


    Class A              Class B


declares                     declares



   Method X             Method Y
 ...
OWL Rules


    Class A              Class B
               uses


declares                     declares



   Method X   ...
Talking to your IDE
Talking to your IDE
Upcoming SlideShare
Loading in …5
×

Talking to your IDE

530 views

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
530
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

  • 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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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 &amp;#x2018;Search String&amp;#x2019; here and select &amp;#x2018;Type&amp;#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 &amp;#x2018;Limit to&amp;#x2019; feature.
  • Next we can enter JTextField as the &amp;#x2018;Search String&amp;#x2019; here and select &amp;#x2018;Type&amp;#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 &amp;#x2018;Limit to&amp;#x2019; feature.
  • Next we can enter JTextField as the &amp;#x2018;Search String&amp;#x2019; here and select &amp;#x2018;Type&amp;#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 &amp;#x2018;Limit to&amp;#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&amp;#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 &amp;#x201C;what fields are declared as being of the type String?&amp;#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 &amp;#x201C;what fields are declared as being of the type String?&amp;#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 &amp;#x201C;what fields are declared as being of the type String?&amp;#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&amp;#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 &amp;#x2018;dynamic and distributed systems group&amp;#x2019; at the University of Z&amp;#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&amp;#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&amp;#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&amp;#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&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#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.

    &amp;#x2018;What Methods instantiate this type?&amp;#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.

    &amp;#x2018;Where is the value of this field retrieved or set?&amp;#x2019; - We can ask, for example &amp;#x2018;what method accesses this field?&amp;#x2019; but we do not distinguish reads from writes.

    &amp;#x2018;Which of the classes in this package were actually used?&amp;#x201D; and &amp;#x201C;Which method defined by this class were actually used?&amp;#x201D; - Ferret answers this question by using dynamic traces, which we do not support so far.

  • Questions, such as &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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 &amp;#x2018;What plug-ins depend on this plug-in&amp;#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 &amp;#x2018;Who has changed this element, and when?&amp;#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.





  • Talking to your IDE

    1. 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
    2. 2. Software Maintenance
    3. 3. Software Maintenance Junior Dev
    4. 4. Software Maintenance Junior Dev Feature-rich IDEs
    5. 5. 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. ‣
    6. 6. What fields are declared as being of this type?
    7. 7. What fields are declared as being of the type JTextField?
    8. 8. What fields are declared as being of the type JTextField?
    9. 9. What fields are declared as being of the type JTextField?
    10. 10. What fields are declared as being of the type JTextField?
    11. 11. What fields are declared as being of the type JTextField?
    12. 12. What fields are declared as being of the type JTextField?
    13. 13. What fields are declared as being of the type JTextField?
    14. 14. What fields are declared as being of the type JTextField?
    15. 15. What fields are declared as being of the type JTextField?
    16. 16. What fields are declared as being of the type JTextField?
    17. 17. What fields are declared as being of the type JTextField?
    18. 18. What fields are declared as being of the type JTextField?
    19. 19. What fields are declared as being of the type JTextField?
    20. 20. What fields are declared as being of the type JTextField?
    21. 21. What fields are declared as being of this type?
    22. 22. What fields are declared as being of this type? Simple question!
    23. 23. What fields are declared as being of this type? Not so simple answer!
    24. 24. 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
    25. 25. What fields are declared as being of the type String?
    26. 26. What fields are declared as being of the type String?
    27. 27. 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
    28. 28. 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
    29. 29. 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.
    30. 30. 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
    31. 31. 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
    32. 32. 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
    33. 33. The Semantic Web: RDF S→P→O Class A → hasMethod → Method B
    34. 34. The Semantic Web: RDF Class A → hasMethod → Method B
    35. 35. The Semantic Web: RDF Class A → hasMethod → Method B
    36. 36. The Semantic Web: RDF Class A → hasMethod → Method B
    37. 37. The Semantic Web: RDF Class A → hasMethod → Method B ↓ callsMethod
    38. 38. The Semantic Web: RDF Class A → hasMethod → Method B ↓ callsMethod ↓ Method D
    39. 39. The Semantic Web: RDF Class A → hasMethod → Method B ↓ callsMethod ↓ isMethodOf ← Method D
    40. 40. The Semantic Web: RDF Class A → hasMethod → Method B ↓ callsMethod ↓ Class E ← isMethodOf ← Method D
    41. 41. The Semantic Web: RDF Class A → hasMethod → Method B ↑ ↓ inverseOf callsMethod ↑ ↓ Class E ← isMethodOf ← Method D
    42. 42. The Semantic Web: RDF Class A → hasMethod → Method B ↑ ↑ ↓ isSiblingOf inverseOf callsMethod ↑ ↑ ↓ Class E ← isMethodOf ← Method D
    43. 43. Evolizer Ontology for Source Code Analysis 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
    44. 44. Evolizer Ontology for Source Code Analysis 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 Domain OWL Class: Attribute OWL Class: Parameter → isAttributeOfClass Class → isParameterOfMethod Method → isAccessedByMethod Method → hasName String → hasName String
    45. 45. Evolizer Ontology for Source Code Analysis 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 Domain OWL Class: Attribute OWL Class: Parameter → isAttributeOfClass Class → isParameterOfMethod Method → isAccessedByMethod Method → hasName String → hasName String Range
    46. 46. Example: RDF Graph evo:Method rdf:type evo:Class evo:method5 evo:hasName rdf:type getTitleText evo:hasMethod evo:class123 evo:hasName evo:hasMethod evo:Method rdf:type DefaultTitleEditor evo:method6 evo:hasName getTitleFont
    47. 47. The Ontology Layer: General Approach @rdf("evo:Class") public class FAMIXClass { @rdf("evo:hasName") public String getName() { // ... evo:Method } rdf:type evo:Class evo:method5 evo:hasName @rdf("evo:hasMethod") rdf:type getTitleText public Set<FAMIXMethod> getMethods() { evo:hasMethod // ... evo:class123 } evo:hasName evo:hasMethod evo:Method rdf:type DefaultTitleEditor evo:method6 /* attributes, setter methods, and evo:hasName additional behaviour */ getTitleFont }
    48. 48. The Ontology Layer: The Relational View superclass belongsToClass Class subclass belongsToClass invokedBy InheritanceDefinition Method Attribute invokes accessedIn accesses Invocation Access
    49. 49. The Ontology Layer: The Relational View superclass belongsToClass Class subclass belongsToClass invokedBy InheritanceDefinition Method Attribute invokes accessedIn accesses Invocation Access
    50. 50. The Ontology Layer: The S-P-O View evo:Method rdf:type evo:Class evo:method5 evo:hasName rdf:type getTitleText evo:hasMethod evo:class1 evo:hasName evo:hasMethod evo:Method rdf:type DefaultTitleEditor evo:method6 evo:hasName getTitleFont evo:subClass evo:inheritance123 evo:Class evo:superClass rdf:type rdf:type evo:Inheritance evo:class2 evo:hasName JPanel
    51. 51. The Ontology Layer: The S-P-O View evo:Method rdf:type evo:Class evo:method5 evo:hasName rdf:type getTitleText evo:hasMethod evo:class1 evo:hasName evo:hasMethod evo:Method rdf:type DefaultTitleEditor evo:method6 evo:hasName getTitleFont evo:subClass evo:inheritance123 evo:Class evo:superClass rdf:type rdf:type evo:Inheritance evo:class2 evo:hasName JPanel
    52. 52. The Ontology Layer: The S-P-O View evo:Method rdf:type evo:Class evo:method5 evo:hasName evo:class1 rdf:type getTitleText evo:hasMethod evo:class1 evo:hasName evo:hasMethod evo:Method rdf:type DefaultTitleEditor evo:method6 evo:hasName getTitleFont evo:subClass evo:hasSuperClass evo:inheritance123 evo:Class evo:superClass rdf:type rdf:type evo:Inheritance evo:class2 evo:hasName evo:class2 JPanel
    53. 53. The Ontology Layer: The S-P-O View evo:Method rdf:type evo:Class evo:method5 evo:hasName evo:class1 rdf:type getTitleText evo:hasMethod evo:class1 evo:hasName evo:hasMethod evo:Method rdf:type DefaultTitleEditor evo:method6 evo:hasName getTitleFont evo:subClass evo:hasSuperClass evo:inheritance123 evo:Class evo:superClass rdf:type rdf:type evo:Inheritance evo:class2 evo:hasName evo:class2 JPanel
    54. 54. 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 }
    55. 55. 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 }
    56. 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. 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. 58. 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.
    59. 59. Ginseng Grammar ## E.g., "what methods call (method) m?" ## "what classes are in (package) p?" <Q> ::= What <S> <P> <O> ? <S> ::= ... <P> ::= ... <O> ::= ...
    60. 60. Ginseng Grammar ## E.g., "what methods call (method) m?" ## "what classes are in (package) p?" <Q> ::= What <S> <P> <O> ? <S> ::= ... <P> ::= ... <O> ::= ... Classe
    61. 61. 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
    62. 62. 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
    63. 63. 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
    64. 64. 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
    65. 65. 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
    66. 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. 67. (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? ✘
    68. 68. (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? ✘
    69. 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. 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 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? ✘
    71. 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. 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 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? ✘
    73. 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. 74. (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? ✔
    75. 75. (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? ✘
    76. 76. (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? ✘
    77. 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. 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 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? ✘
    79. 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. 80. 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
    81. 81. 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.
    82. 82. 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.
    83. 83. Software Evolution Ontology Version Control Ontology ver:File ver:Revision ver:Person rdf:type rdf:type rdf:type ver:commits DefaultTitleEditor.java ver:file123 ver:revision123 ver:developer123 ver:hasName ver:hasRevision ver:hasNumber ver:hasName ver:containsClass 1.2 mwuersch evo:Method 132 rdf:type evo:Class evo:method5 evo:hasName issue:hasNumber rdf:type evo:hasMethod getTitleText issue:bug12 evo:class123 issue:affectsClass evo:hasName evo:hasMethod evo:Method rdf:type rdf:type DefaultTitleEditor evo:method6 evo:hasName issue:Issue getTitleFont Issue Tracking Ontology Code Ontology
    84. 84. OWL Rules Class A Class B declares declares Method X Method Y invokes
    85. 85. OWL Rules Class A Class B uses declares declares Method X Method Y invokes

    ×