Visualisation provides good support for software analysis. It copes with the intangible nature of software by providing concrete representations of it. By reducing the complexity of software, visualisations are especially useful when dealing with large amounts of code. One domain that usually deals with large amounts of source code data is empirical analysis. Although there are many tools for analysis and visualisation, they do not cope well software corpora. In this paper we present Explora, an infrastructure that is speci cally targeted at visualising corpora. We report on early results when conducting a sample analysis on Smalltalk and Java corpora.
A software corpus is a curated catalogue of software systems intended to be
used for empirical studies of code artefacts. The advantage of doing research on
corpora is that it encourages repeatable analyses. Corpus analysis is especially
used in the context of empirical software engineering, where results should be
repeatable [
Imagine Edgar, an empirical software engineering researcher, who wants to assess the prevalence of reuse of software in di erent languages. To begin, he chooses to study reuse through inheritance and invocation in one of the oldest object-oriented languages, Smalltalk and one of the most popular, Java. To gain an initial insight into the data, he must carry out explorative data analysis, including visualisation.
To set up the environment for the analysis, he needs to overcome several problems: 1) visualising one system at a time (as most visualisation systems allow) prevents patterns from being recognized at the corpus level; 2) the lack of means for real-time data manipulation (such as sorting, ltering, searching, inspecting) discourages experimentation; and 3) two technical issues, memory consumption and performance, complicate fetching and manipulating corpus data.
In this paper we introduce our approach, Explora, which copes with these issues.
Edgar wants to target Smalltalk and Java corpora. He has a fair experience implementing and maintaining systems in both languages. He realises that in his experience Smalltalk systems have deeper hierarchies than Java ones, so he wants to explore whether increased specialisation in Smalltalk systems correlates with less reuse of their classes. Thus, he wants to answer the following research question:
RQ: \How di erent is reuse by inheritance and invocation in Smalltalk and Java systems? "
He believes that metrics are a suitable way for tackling this research question.
He chooses four metrics from a catalogue of metrics proposed by Lanza and
Marinescu to characterise two types of reuse: reuse via inheritance and reuse via
invocation [
Edgar decides to start his analysis by visualising these metrics on all the
systems in both corpora. He decides to use Explora for his analysis. He downloads
the models of the systems in the two corpora following the installation
instructions of Pangea1 locally and places them in a dedicated folder called the model
workspace. To query corpora, Explora uses a so-called interactive Playground
implemented on top of the Moldable Inspector infrastructure [
The Mapper pane shows a query written in plain Smalltalk for collecting AHH (line 3), and the aggregated maximum value of DIT (line 7), Fan-In (line 9) and Fan-Out (line 11) from every system in the two studied corpora. The query de nes an inline array of associations, where each association is linked to a di erent metric. The query uses the bound variable eachModel to refer to the FAMIX meta-model of each system. The model enables code such as \eachModel allModelClasses" and \c superclassHierarchy".
The user can evaluate metrics de ned in the system model, as is the case of AHH, Fan-In and Fan-Out, or compute custom ones such as the one speci ed for DIT. The query is sent to all the models of the systems in the model workspace 2) The right pane shows the result of the query, which is always a collection of objects retrieved from the queried system models by executing the query in the Mapper pane. The objects in this collection can be further manipulated (i.e. sorted, ltered, further queried, visualised).
Each pane of the Playground is linked to an object. By using the bound variable self the user can manipulate the object. The Playground supports navigation using the Miller column technique2 on which the evaluation of a script in a pane adds a new pane to the right that is linked with the returned object. The Mapper is a special pane (since it is the rst) that uses a di erent bound variable (eachModel) for referencing speci cally system models. Step 2: Generating an Initial Visualisation A special type of manipulation supported in right pane of the Playground uses the result object (i.e. the collection of dictionaries) as input for a visualisation. To use this feature, Edgar switches from the list view of the result to the Raw tab, which allows him to write a visualisation script. For instance, Figure 2 shows in the left pane an implementation of a lightweight visualisation using the Mondrian DSL. The result object is referred to in this script as \self" (see lines 4, 5, 11 and 12).
The right pane shows the generated visualisation. Each box represents a system, Smalltalk ones being grouped at the bottom while Java systems are at the top. The width of each box is mapped to AHH and the height to DIT. Edgar mapped the metrics in this way so that boxes with a larger area will indicate systems with many deep hierarchies. Furthermore, the darker the green
of the box the higher the value of Fan-In. At a rst glance, the analysis of the visualisation seems to reveal a pattern. Smalltalk systems are landscape oriented in lighter colour and Java ones have a portrait orientation with a darker colour. Since he took the maximum values of Fan-In and DIT, Edgar realises that in general the Java corpus contains the most invoked class (highest Fan-In), and the deepest hierarchy (highest AHH and DIT). This suggests that Java systems exhibit more reuse than Smalltalk ones. This can be a misleading result due to the decision of aggregating DIT and Fan-In using maximum values, since they do not provide Edgar insight into a general tendency.
Step 3: Exploring alternative Visualisations In consequence, Edgar decides to nd out if this pattern still prevails when values are aggregated using the median. He modi es the implementation accordingly, by aggregating the values of DIT and Fan-In using the median. Without leaving the environment, he goes to the left pane shown in Figure 1 and changes lines 9 and 11 accordingly (collecting median instead of maximum values). The Playground recallsl the implementation of the previous visualisation generating a new one automatically (Figure 3). Edgar notes the di erence between system Chronos in Figure 2 and in Figure 3. The analysis shows that even though it has neither the most invoked class in the two corpora (light green in Figure 2), nor the deepest hierarchy (lower height in Figure 2), in general its classes are the most invoked and have deep hierarchies (large and dark box in Figure 3). Figure 3 shows that most systems of the Smalltalk corpus exhibit more reuse by having larger, deeper and more invoked hierarchies.
Diving Into an Individual System Figure 4 shows a detailed visualisation of Chronos which is a library for manipulating dates and times.3 Classes are represented by circles. The darker the circle, the more invoked the class (higher Fan-In). The size of the circle is mapped to Fan-Out allowing the user to compare classes that behave as clients and providers in invocation relationships. Blue edges between classes show inheritance relationships and grey edges represent invocations. For a better analysis, only invocations of highly invoked classes are shown (Fan-In greater than 90). From the visualisation Edgar can distinguish main provider classes that are highly invoked (dark circles), even though some of them are clients as well (darker and larger circles). Most notably, there is a hierarchy in Figure 4-A that includes many highly invoked classes (ChronosObject ). 3 http://smalltalkhub.com/#!/~Chronos/Chronos Besides, there are two classes in Figure 4-B TimeZoneAnnualTransitionPolicyFactory and DateSpec that without being part of a hierarchy attract many invocations. Finally in Figure 4-C Edgar notes a small hierarchy of chained invocations.
The top-down exploration starting from the visualisation at the corpora level enabled Edgar to decide what systems to focus on. It gave him an overall assessment of reuse between the two corpora as well as a detailed vision of the reuse in a system, when he drilled down into Chronos. He learned that the greater specialisation of Smalltalk systems seems not to a ect reuse. Indeed he found deep hierarchies in the Chronos system but he also found that those hierarchies are heavily reused. 3
When designing Explora we combined several tools for accomplishing the analysis
task. Explora is inspired by Pangea [
Explora is written in Pharo, an open-source Smalltalk dialect. The Pharo
live programming environment allows users to explore and navigate data in a
dynamic fashion. Explora uses a Playground built on top of the Moldable
inspector [
Work ow
1) The user de nes and triggers a query for collecting data from the corpora.
2) A main process looks for OMSs available in a local folder called the source
workspace, and evaluates the query in each of them (there are sequential and
parallel modes). An OMS is used as a cache holding a live version of the
system model that can be awakened, queried, and put back to sleep again.
3) The independent result returned by each OMS is serialised using Fuel [
Although the architecture scales up by adding more OMSs horizontally, it is still constrained to the memory available in the Pharo 32 bit environment for materialising objects. A workaround for this issue is to collect less data by including into each OMS only essential information.
Example's Benchmark Table 1 shows a benchmark with the performance results and memory consumption at each step when we run the example analysis. The data were collected by: 1) calling the garbage collector; 2) measuring the memory used (average among 10000 times); 3) executing the step; 4) measuring the memory used (average among 10000 times); and 5) calculating the di erence between 4) and 2).
Note that during the execution of the step 1 (Computing the Metrics) new processes are created (in parallel or sequentially) using more memory, however this is released after the execution.
Automatic Visualisation Although Roassal provides a number of expressive DSLs for di erent tasks, it requires expertise to generate useful visualisations. We envision an approach that exploits expertise of proven well-designed visualisations automatically visualise results. Users without expertise should be able to pro t from such visualisations. Lately we are studying how experts visualise software. We have been classifying their visualisations into several dimensions such as goal, domain, granularity. We are working to develop an approach that makes use of this classi cation to provide automatic visualisation.
ment data visualisations would bene t from Automatic Visualisation Assessment AVA. While users are implementing visualisations, AVA would give them feedback about visual design guidelines that are violated, and suggest how to resolve them. Our idea is to develop a model of visual design constraints covering the main pitfalls that developers encounter when visualising data, such as visual cluttering, layout selection, and colour con ict.
Expanding the Corpora There are a few systems in Qualitas Corpus that do not t into an OMS. This will be solved with a 64-bit version of Pharo. We also realise that SqueakSource-100 should be expanded to more systems to provide more interesting results. Finally, we think that adding more corpora from other languages would be an advantage for experimental analysis. 5
Explora expands related work by scaling up software visualisation to corpora. Explora's design is based on three pillars: 1) liveness of the Pharo environment which enables interactive exploration; 2) ready-to-use software corpora models which encourage repeatable analyses; and 3) agile visualisation to provide support for data analysis. Figure 5 shows how related work and Explora cover these concepts. 5.1
To the best of our knowledge there is no visualisation tool that provides support for software corpora. Some of them allow users to load into memory several models of systems, but they cannot visualise systems together. Only one of these systems o ers liveness.
CodeCrawler [
SHriMP [
jGrasp [
JIVE [
Softwarenaut [
Rascal [
Bauhaus [
Pangea [
In conclusion, although there are many tools for software analysis and visualisation most of them do not scale to software corpora. Data analysis tools that do scale to corpora are not live. On the other hand, visualisation tools that do o er liveness do not scale to corpora. In this paper we presented Explora, an infrastructure for scaling up software visualisation to corpora. We presented an example of analysis stressing its strengths, showing how visualisation can help one to explore and understand software. However, we acknowledge that useful visualisations are di cult to achieve. In consequence, in the future we want to tackle this issue by automatically visualising software by mapping queries to suitable, proven visualisations. We also think that users with the knowledge for visualising software can pro t from automatic visualisation assessment, a dynamic evaluation of the visualisation that provides feedback concerning violations of visual design rules and guidelines.
We gratefully acknowledge the nancial support of the Swiss National Science Foundation for the project \Agile Software Assessment" (SNSF project No. 200020-144126/1, Jan 1, 2013 - Dec. 30, 2015). This work has been partially funded by CONICYT BCH/Doctorado Extranjero 72140330.