main.tex

\documentclass[conference]{IEEEtran}

%\usepackage{xspace}
\usepackage{ifpdf}
\usepackage{diagbox}
\usepackage{cite}
\ifCLASSINFOpdf
  \usepackage[pdftex]{graphicx}
  \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  \usepackage[dvips]{graphicx}
  \DeclareGraphicsExtensions{.eps}
\fi 
\usepackage[cmex10]{amsmath}
\usepackage{algorithmic}
\usepackage{array}
\usepackage{mdwmath}
\usepackage{mdwtab}
\usepackage{eqparbox}
\usepackage{fixltx2e}
\usepackage{hyperref}
\usepackage{booktabs}
\usepackage{numprint}
\usepackage{xcolor}
\npdecimalsign{.} 
\npthousandsep{,} 
% \usepackage{stfloats} 
\usepackage{xspace}

\usepackage{listings}
\usepackage{rascallst}
\lstset{language=rascal,
showspaces=false,
showtabs=false,
breaklines=true,
morekeywords={pointcut,execution,cflowbelow,cflow,percflow,aspect,otherwise},
showstringspaces=false,
breakatwhitespace=true,
escapeinside={(*@}{@*)},
basicstyle=\ttfamily\small, % maybe also \small or \footnotesize
%frame=TB,
numbers=left,
numberstyle=\tiny\color{gray},
tabsize=3,
captionpos=b,
columns=flexible,
}


\newcommand{\Rascal}{\textsc{Rascal}}
% \newcommand{\DCFlow}{\textsc{DCFlow}\xspace}
\newcommand{\DeFacto}{\textsc{DeFacto}\xspace}
      
% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.
  
%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/

\hyphenation{op-tical net-works semi-conduc-tor}
\usepackage{etex}  
\usepackage{amssymb}
\usepackage{multicol}
\usepackage{mathrsfs}
\usepackage{microtype}
\usepackage{tabularx}
\usepackage{comment}
\usepackage{synttree}
\usepackage{stmaryrd}
\usepackage{wrapfig}

%% REMOVE PAGE NUMBERS!
%%\pagestyle{plain}

\newcommand{\loc}[1]{\small{\texttt{#1}}\xspace}
\newcommand{\mthree}{\ensuremath{M^3}\!\xspace}

\usepackage{tikz}
\usetikzlibrary{shapes.geometric}
\usetikzlibrary{positioning}

\begin{document}

\title{$M^3$: a General Model for Code Analytics in Rascal}

% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
% TODO: Other authors?
%\author{ Anastasia Izmaylova, Paul Klint, Ashim Shahi and Jurgen Vinju, Davy, Michael}
\author{
\IEEEauthorblockN{Bas Basten\IEEEauthorrefmark{2}, Mark Hills\IEEEauthorrefmark{1}, Paul Klint\IEEEauthorrefmark{2}, 
Davy Landman\IEEEauthorrefmark{2}, Ashim Shahi\IEEEauthorrefmark{2}, Michael Steindorfer\IEEEauthorrefmark{2}, 
Jurgen Vinju\IEEEauthorrefmark{2}}
\IEEEauthorblockA{\IEEEauthorrefmark{2}Centrum Wiskunde \& Informatica, Amsterdam, The Netherlands\\\{Bas.Basten,Paul.Klint,Davy.Landman,Ashim.Shahi,Michael.Steindorfer,Jurgen.Vinju\}@cwi.nl}
\IEEEauthorblockA{\IEEEauthorrefmark{1}East Carolina University, Greenville, NC, USA\\mhills@cs.ecu.edu}
}

\maketitle

\begin{abstract}
This short paper introduces M3, a simple and extensible model for capturing facts about source code for future analysis. M3 is a core part of the standard library of the Rascal meta programming language. We motivate it, position it to related work and detail the key design aspects.
\end{abstract}

\section{Motivation}

In the context of the EU FP7 project ``OSSMETER'' we have developed an
infrastructure for measuring source code. The goal of OSSMETER is to obtain
insight into the quality of open-source projects from all possible perspectives,
including product, process, and
community.\!\footnote{\url{http://www.ossmeter.org}}

% \textbf{NOTE: we have accuracy in here to distance ourselves from the srcML
% approach, variability is a given and integration is here due to the Call for Papers}
The challenges faced by our part of the design, which focuses on source code,
are \emph{variability}, \emph{integration}, and \emph{accuracy}. Variability is
necessary to support the different languages, including dialects, we support,
as well as the different metrics we will compute. Integration is necessary at
a semantic level, where metrics are computed across programming language and
domain boundaries and are combined for further analysis. Accuracy is a
prerequisite for insightful analyses. When accuracy is lost in the early stage
of fact extraction from source code, the downstream analyses may show
interesting but nevertheless meaningless information.

The standard solution for variability and integration is to put an explicit
reusable model (e.g., database, graph) in the center, such that model
producers (parsers \& extractors) can be decoupled from model consumers
(metrics \& visuals). Examples of such intermediate models are
FAMIX~\cite{famix}, RSF~\cite{Mueller88}, GXL~\cite{HWS00}, KDM~\cite{omg-kdm},
and ATerms~\cite{BJKO00}. A positive side-effect of intermediate models
is that the data are pushed into a general form, which enables integrating
information from different sources. We have been inspired by these examples.

This paper is a brief description of \mthree, a set of code models which
should be easy to construct, easy to extend to include language specifics, and
easy to consume to produce metrics and other analyses.\!\footnote{An earlier,
shorter version of this paper was presented at BENEVOL 2014.} \mthree consists of an abstract syntax tree (AST) layer
(hierarchical) and a relational (flat) layer. The AST layer uses a standard
interface, but is expected to be language specific, while the relational layer
is more abstract in nature and made for reuse.

\emph{The main threat to validity of any intermediate model which is generic
enough to be reusable between different programming languages is that accuracy
may be lost. This is why the \mthree standard first prescribes precise
language-specific AST models and then language agnostic relational models
where it is possible to abstract.} The reader should be aware that we do
\emph{not} intend to create a unified model for programming language
semantics. Such a language independent model would be inaccurate (wrong), and
deliver meaningless metrics. Instead we opt for a unified \emph{form} for
storing facts about programs. This means that all models will have a
predictable shape, but we do not assume any reusability of metrics or
visualizations between models that are produced by different front-ends. The
design of \mthree  gives accuracy a higher priority than reuse.



The context of \mthree\ is the Rascal meta-programming language~\cite{KvdSV-
Rascal11,rascalscam}.\footnote{\url{http://www.rascal-mpl.org}} This is a
domain specific language specifically designed to include primitives we need
to model the syntax and semantics of any programming language, and to analyze
and manipulate these models. Three essential design elements related to this
paper are that Rascal has value semantics for all in-memory data, including
sets and relations; it has support for URI literals, called ``source
locations''; and it has term rewriting and relational calculus primitives to
deal with hierarchical and relational data, respectively. This includes
generic traversals~\cite{Traversals} and pattern matching primitives as well
as relational operators such as transitive closure and comprehensions.

The differences between \mthree and the aforementioned models is that \mthree
deals with purely \emph{immutable}, typed data which can be directly
produced, manipulated and analyzed using Rascal primitives. Two unique
elements are the introduction of URI literals to identify source code
artifacts in a language agnostic manner and support for fully structured type
symbols.

\section{Experience Report}

We developed \mthree to satisfy the requirements of the OSSMETER project, but
we have been using it for a broader range of studies related to software
analytics.
%
We have used \mthree to construct comparable models of Android API evolution
from three sources: source code, jar files and online
documentation.\!\footnote{Thanks to the students of the UvA Software
Evolution course 2013.}
Creating the same model out the three sources required writing three different
fact extractors. The first is based on the Eclipse JDT, the second uses
ASM,\!\footnote{\url{http://asm.ow2.org/}} and the last uses Rascal's HTML
library model. The analysis reveals interesting differences between the models
which may influence the conclusions of related work~\cite{apianalysis}. For example, the Android source code releases contain undocumented public classes and methods. Nevertheless, these are available after deployment and developers use them. 

\begin{figure}[t]
\centering
	\resizebox{.8\columnwidth}{!}{\input{architecture}}
\caption{An Overview: From Code to Metrics and Visuals via \mthree Models.}
\vspace{-5mm}
\end{figure}
For OSSMETER, \mthree is applied to measure a plethora of object-oriented and
procedural code metrics~\cite{mood,ck} for Java and PHP. The metrics output
between Java and PHP are comparable, and we also achieved some level of reuse
when the metrics were based on the relational part of \mthree, such as
inheritance, overriding and containment relations.

We are using \mthree to improve our PHP static analysis framework called PHP
AiR~\cite{phpair}, supporting over-approximations of dynamic features such as
file inclusion~\cite{ase2014} and types.

We have used \mthree to analyze a large body of Java source code, comparing
the cyclomatic complexity of methods to their size, refuting earlier
scientific results reporting on a strong linear model between the two
dimensions~\cite{davy}.

Finally a number of Universiteit van Amsterdam masters theses are based on
using \mthree for PHP refactoring, PHP security analysis, quality metrics,
concurrency-related Java refactorings, and Java reverse engineering.

\section{Design aspects}

\subsection{Textual Models}

\mthree is, like all Rascal data, fully typed and fully serializable as
readable text with a standard notation that is equal to the expression syntax
for literals. This means that any intermediate step can be visualized as plain
text and not only searched and edited using standard text editing facilities,
but also stored and retrieved persistently. One particular aspect of the
Rascal IDE is that all printed source location literals (see below) in editors
and consoles are treated as \emph{hyperlinks}. M3 models are therefore
``programmer friendly'': easy to explore both interactively and
programmatically using low-brow techniques.

\subsection{Locations} 

To verify the correctness of metrics, or for explaining them, we want to trace
measurements back to code. For example, when we present the largest class in a
project, we need the size as well as a link to the source code of this class.
In other words, we want to link information back to source code for all
derived facts we produce. From the semantic web we take the idea of using URIs
(Uniform Resource Identifiers), of the form 
\loc{|<scheme>://<auth>/<path>?<qry>|(<off>,<len>)}, 
to model the identity of any artifact. We
distinguish between two kinds of code locations: physical and logical. A
\emph{physical} location identifies a storage location, and may be absolute or
relative. Examples of absolute physical locations are
\loc{|file:///tmp/Hello.java|} and \loc{|http://foo.com/index.html|}, while an
example of a relative location is \loc{|project://MyPrj/Hello.java|}. It is always the
\emph{scheme} of a URI that defines to
which root a URI is relative. In the case of \texttt{project}, it is an
Eclipse project in the current workspace, while in the case of \texttt{file}
it is the file system's root. The set of physical schemes is open and
extensible, with schemes for Eclipse projects, Java class resources, OSGI
bundle resources, JDBC data sources, jar files, and other resources.

A \emph{logical} code location is akin to a fully qualified name. For each
specific language we design a naming scheme for each source code element that
is, in some sense, declared. An example of a logical location is
\loc{|java+class://myProject/java/util/List|}. The scheme represents both the
language and the kind of artifact that is identified. The URI
\textit{authority} declares the scope from which the name is resolved, in this
case from \texttt{myProject} which depends on a particular version of the Java
runtime. Finally, the path identifies the qualified name of the artifact in
this scope. One goal of logical locations is to uniquely link to physical
locations, at a certain moment in time, and at the same time be more or less
stable under irrelevant code movement (such as moving the root source
directory within a project). Another goal is for such links to be readable,
writeable, recognizable and memorizable by human beings when developing new
extractors, metrics or visuals. For instance, we might explore an \mthree\
model by projecting the information for an arbitrary class: the Rascal command
\texttt{m@inheritance[|class://myPrj/java/util/List|]} would produce all
interfaces that inherit from \verb|java.util.List|.

%The query part of a URI is used to \emph{modify} identities, for example to
%scope them for a particular version of a system:
%\loc{class://myPrj/java/util/List?svn=4242}. The offset and length fields are
%used to identify consecutive slice of characters of the identified artifact.

\mthree\ models are built on this concept of logical and physical source
locations. \mthree\ uses binary relations between locations; annotates AST nodes
with these locations; and embeds these locations into symbolic facts (such
as types) to link back to source code whenever possible.

\subsection{Relations} The \mthree\  model is both layered and compositional.
This means that \mthree\ models can be combined (``linked'') and extended
(``annotated''). The core relations are all between code locations (see
Table~\ref{table:core}). An example containment tuple would be
\loc{<|class:///foo/Bar|,|pkg:///foo|>}.

\begin{table}[t]
\caption{Core Binary relations of \mthree \label{table:core}}
\begin{tabularx}{\columnwidth}{|l|l|X|}\hline
 Layer & \lstinline!rel[loc, loc]! & Description \\ \hline 
\textbf{Generic} & \lstinline!containment! & logical containment of 
code entities \\
\textbf{~core} & \lstinline!declarations! & maps logical \lstinline!loc! to physical \lstinline!loc! \\
& \lstinline!uses! & maps physical \lstinline!loc! to logical \lstinline!loc! \\ \hline
 \textbf{OO} & \lstinline!extends! & who extends who (logical \lstinline!loc!) \\
& \lstinline!implements! & who implements who  (logical \lstinline!loc!) \\
& \lstinline!methodInvocation! & who invokes who (logical \lstinline!loc!) \\
& \lstinline!methodOverrides! & who overrides who (logical \lstinline!loc!) \\
& \lstinline!fieldAccess! & who accesses who (logical \lstinline!loc!)\\ \hline
\end{tabularx}
\vspace{-5mm}
\end{table}

This core model is language independent, facilitating not only volume metrics,
browsing visuals (drill-down) and generic aggregation over containment
relations, but also dependence between artifacts and thus impact and
coupling/cohesion analyses. Also note that this core model is not restricted
to handling programming languages. It can be used to model other kinds of
formal languages like grammars, schema languages, or even pictorial languages.

For modeling language specific information we annotate the above core model
with extra relations. Again these are binary relations between logical
locations (Table~\ref{table:core}). These relations model key aspects of the static semantics
of a programming language. Note that we never refer to instantiated or dynamic
objects here, not even parametric type instantiations. All relations refer to
source locations literally. 
For the accuracy of source code metrics, it is
essential that \mthree\  separates what is written in the source code from
what the code means dynamically. 
For example, if an abstract method from an
interface is called we should not immediately infer all the call sites and add
those to the invocations relation. Some metrics may want to count the fan-out
to abstract methods, while other metrics want to know the impact on concrete
implementations. You can compute such information by composing basic
facts---e.g. ``\lstinline!invocation o overrides!'' gives all the concrete callees
for calls to abstract methods---and then compute a metric over the resulting
relation.

\subsection{Trees} For abstract syntax trees we use a general concept of
algebraic data-types in Rascal. Every language comes with its own definitions.
Algebraic data-types are easy to extend with new constructors (new programming
language constructs). For \mthree\ we standardize some of the names used in
defining AST types. In the core we standardize on five algebraic sorts to use
when defining an abstract syntax: \texttt{Expression}, \texttt{Declaration},
\texttt{Statement}, \texttt{Type}, \texttt{Modifier}. The goal is to add as
few extra sorts as possible when adding a new language. This leads to models
which \emph{over-approximate} the possible programs, but also increases the
chance of reuse and extending existing fact extractors. For example, if all
statements are in the same sort, then a basic function computing the
cyclomatic complexity can be extended to cover a new language by just adding
cases for the new types of statements (e.g. a \texttt{foreach} statement). We
also provide annotation types for specific nodes, i.e. all nodes have a
\texttt{src} annotation to point to the physical source location, all
declarations may have a \texttt{decl} annotation to their logical location
identifier and all Expressions may have a \texttt{type} annotation (see
below).
%
Trees are useful mostly for the computation of metrics over code units that
contain statements, such as cyclomatic complexity, but also to infer data and
control flow information for use in the more advanced analyses. 

%Trees are also
%expensive to keep in memory, so in M3 models they are always computed \emph
%{on-demand} for a particular logical location.

\subsection{Types} For types we introduce a single sort called
\texttt{TypeSymbol}. We use this to represent any kind of abstract value that
variables and expressions in a language may produce. For Java we have a
default set of type symbols to represent (parameterized) class and interface
types, method signatures, and primitive types. These symbols can be used to
compute with raw and parameterized types, either instantiated or
uninstantiated. An example of a type symbol is:
\loc{class(|class:///java/util/List|, [class(|class:///java/lang/String|,[])])}, 
meaning the instantiated
parameterized List type generated by the List class definition with its type
parameter instantiated by the String class. We extended the core \mthree\
model with initial types---a relation from declarations to the types they
generate---and we annotate the trees of expressions with the types they produce.
Using type symbols we may compute with and reason about dynamic artifacts that
are never declared yet may exist at run-time. For example, an upper-bound for
the number of possible instantiations of a parameterized type can be computed
based on such information.

\subsection{Model Composition} When we extract \mthree\  models we do this
incrementally, i.e. per file, per project, per composition of a project with
its dependencies. Each file (in a given programming language) produces one
\mthree\  model. Then the models for all files in a project are fused into one
single \mthree\  model by applying set union to all the relations of the
model. Finally, if there are project dependencies, we may fuse the \mthree\
models for different projects.
%
Some analyses are best done before fusion. We compute the volume of a project
before we fuse in the declarations of the jars we depend on. Other analyses
are done only after fusing: depth of inheritance can only be computed if the
models of classes we depend on are fully available. Since \mthree\  models are
immutable values, like all Rascal values, such models can never be accidentally
mixed. The \texttt{compose} function is called
explicitly by the programmer to union the relation between two \mthree\ models;
the \texttt{link} function does the same, but updates the authority fields
of all logical locations such that uses in one project may point to
declarations in another.

%Currently we have extractors of \mthree models for jar files (i.e. from
%bytecode) from the JRE and Eclipse plugins, and from the source code of
%Eclipse project separately.  We then link these independently acquired M3
%models to form complete models for further analysis.

\subsection{Efficiency and Memory Consumption}

In essence a loaded \mthree model is an in-memory database of source code
artifacts. For a large software system, the memory requirements are large and the
efficiency is limited by I/O bottlenecks (network access, disk access and
cache misses). Our current implementation still suffers from these effects,
which are aggravated by value immutability.
%
Since \mthree and Rascal are implemented on the JVM we are using ``soft
references'' to store \mthree models, such that we can re-compute caches which
have been garbage collected. The fused \mthree model and AST models for
specific files often drop out of memory because of this, releasing necessary
space. Soft references mitigate memory limitations nicely at the cost of
runtime efficiency.
%
On the other hand we are investing in low level optimizations for in-memory
hierarchical data-structures~\cite{BJKO00,gpce}. These results are hopeful,
making it feasible to scale to even larger analyses without sacrificing
immutability. Also scaling out in parallel will be facilitated by the immutability of \mthree.

\subsection{Example}

Listing~\ref{code:coverage} shows a concrete example of an \mthree analysis in
Rascal. Function \lstinline{estimateCoverage} analyzes any M3
model produced for Java and produces an over-estimate of a
system's test coverage, given a JUnit4 test harness. The basic
binary relations \lstinline{methodInvocations}, \lstinline{methodOverrides}
and \lstinline{containment} are used to find out who calls who. Relational
operators such as infix \lstinline{o} (composition), infix \lstinline{+} (set
union), infix \lstinline{-} (set difference) and postfix \lstinline{+}
(transitive closure) are used to separate reachable from unreachable code.
Comprehensions are used to generate and filter intermediate relations, and
eventually a library function is called to compute the overall result, a percentage with given
precision.

%This example is typical for an analysis based on the abstract relations in \mthree. We refer to Landman's analysis of cyclomatic complexity and lines of code~\cite{davy} for an AST-based code example.

\begin{figure}[t]

\begin{lstlisting}[caption=Statically estimating test coverage using \mthree., label=code:coverage,language=rascal]
real estimateCoverage(M3 m) {
  allCalls = m@methodInvocations + implicitCalls(m);
  allCalls += allCalls o m@methodOverrides<to,from>;
  testMethods = jUnit4TestMethods(m);
  ifaceMethods = {met | <t, met> <- m@containment, isMethod(met), isInterface(t)};  
  reachable = {met | met <- reach(allCalls, testMethods), met in methods(m)} - allTestMethods - interfaceMethods;
  total = methods(m) - testMethods - ifaceMethods;
  return percentage(size(reachable), size(total), precision=0.01);       }
\end{lstlisting}
\vspace{-5mm}
\end{figure}

\section{Related Work}

There is far too much related work to fit in this abstract. We only list primary inspirations for Rascal and \mthree here as an acknowledgment.
%
Lexical techniques for fact extraction from source code use regular expression patterns to extract facts from
program source code. These techniques are supported by languages such as Lex and AWK, Perl, or Python. Murphy and
Notkin~\cite{DBLP:journals/tosem/MurphyN96} extended the
basic regular expression support provided by these tools and languages
to include additional contextual information such that relations can be extracted once scanning is complete.

Approaches based on grammars naturally handle the nested constructs common to
programming languages
%, but, in contrast to lexical techniques, generally
%require the source code to be syntactically correct so it can be parsed.
Parsing tools such as Yacc and ANTLR provide basic support for hand-coded
fact extraction using the parser's semantic actions. A number of tools also
exist with direct support for extracting facts from programs. Examples are
the Rigi system~\cite{Mueller88}, which provides fixed fact extractors for
several languages and represents facts as tuples in the Rigi Standard Format
(RSF). Meta programming languages, such as Stratego~\cite{BKVV06}, TXL~\cite{TXL06} and ASF+SDF~\cite{BDHJJKKMOSVVV01} provide integrated parsing and tree processing support for source code fact extraction and manipulation in any programming language. SrcML~\cite{srcml} generates XML-annotated source code for the C language which can be queried directly using XML processors. 
Frameworks like JastAdd, Silver and Kiama make use of attribute
grammars~\cite{FNC2,Paakki95,EkmanHedin07,kiama,DBLP:journals/scp/WykBGK10},
using synthesized attributes to specify facts and inherited attributes to
propagate these facts through the parse tree.

Relational approaches support extracting facts into relations which can then
be combined and analyzed. Rigi relations are formed over RSF tuples and
processed using operations in the Rigi Command Library (RCL).
GROK~\cite{Holt96} and CrocoPat~\cite{BeyerEtAl03} (using a
notation called RML) instead use relational algebra; GROK supports only binary
relations, while CrocoPat supports n-ary relations. The \DeFacto
system~\cite{DBLP:conf/sle/BastenK08}, using RScript~\cite{KlintRscript}, also
supports n-ary relations and relational algebra, as does Vankov's work on
formulating program slicing using relational techniques~\cite{Vankov05}.
% \Rascal~\cite{KvdSV-Rascal11,rascalscam} includes n-ary relations as a native
% datatype and relational operations (e.g., projection, transitive closure,
% products) as standard \Rascal expressions.

Model-based approaches extract facts into models, representing abstractions of
the systems being analyzed. MoDisco~\cite{DBLP:journals/infsof/BruneliereCDM14,DBLP:conf/kbse/BruneliereCJM10},
a model-based tool for modernizing legacy
systems, supports extracting information about these systems into models
defined using the Knowledge Discovery Metamodel~\cite{omg-kdm}, an OMG
standard for modeling the structure and behavior of software systems. 
Moose~\cite{DBLP:conf/sigsoft/NierstraszDG05,DBLP:journals/sigsoft/Nierstrasz12}
extracts facts about software systems into models defined using the FAMIX~\cite{famix}
family of metamodels. Finally, we recommend reading about source code query mechanisms based on logic meta programming, such as Ekeko~\cite{ekeko} and SOUL~\cite{soul}.

\section{Conclusion}

We have shown you a taste of \mthree, an extensible and composable model for
source code artifacts based on relations and trees, with immutable value
semantics, source location literals, and extensibility with new types of binary relations. It has
support for basic language independent analyses, and we have a detailed model
for Java and PHP. \mthree is designed for variability, integration and accuracy, all required for software analytics research with a source code component.

%The ``heavy lifting'' is done in the front-ends, where parsing, name analysis (including a naming schemes for logical source code locations) and possibly type analysis have be to devised, and the ``harvesting'' is done in Rascal code which easily, combines, compares, measures, elaborates and visualizes the acquired \mthree models.

The key open challenges for \mthree applications are efficiency and scalability, which we address using low level optimization techniques for hash-tries. Otherwise we are adding support for more programming languages. \mthree is open-source, EPL licensed (\href{https://github.com/cwi-swat/rascal/tree/master/src/org/rascalmpl/library/analysis/m3}{https://github.com/cwi-swat/rascal/library/analysis/m3}).

\bibliographystyle{IEEEtran}
\bibliography{cited}

\end{document}