A Parser and a Software Visualization Environment to Support the

Comprehension of MATLAB/Octave Programs

Thiago de Lima Mariano

, Glauco de Figueiredo Carneiro

, Miguel Pessoa Monteiro

Fernando Brito e Abreu

and Ethan Munson

Universidade Salvador (UNIFACS), Salvador, Bahia, Brazil

Universidade Nova de Lisboa (NOVALINKS), Lisbon, Portugal

Instituto Universitario de Lisboa (ISCTE-IUL), Lisbon, Portugal

University of Wisconsin Milwaukee (UWM), Milwaukee, Wisconsin, U.S.A.

Keywords:

MATLAB/Octave, Parser, Abstract Syntax Tree (AST), Knowledge Discovery Metamodel (KDM), Software

Comprehension, Software Visualization.

Abstract:

Software comprehension and analysis of MATLAB and Octave programs are not trivial tasks. Programmers

have to devote considerable effort to obtain relevant data from source code and related artifacts. Tools that

provide support for software comprehension activities usually rely on parsers to obtain data from source code.

The problem in the MATLAB/Octave case is the limited number of available parsers and the difﬁcult to build

an extensible solution with them. In this paper, we describe the development of a parser that converts MAT-

LAB and Octave program codes into instances of the Knowledge Discovery Metamodel (KDM), which can

subsequently undergo static analyses to feed different visual representations. The goal of these representations

is to support software comprehension. We describe our experience in the use of this parser to build a software

visualization environment to support the comprehension of MATLAB and Octave programs.

1 INTRODUCTION

Software visualization has supported programmers

and designers to discover information that are hidden

in standard parsing processes (Munzner, 2014)(Seriai

et al., 2014). In this paper, we focus on the parser

implementation and a visualization environment for

two programming languages. The ﬁrst is MATLAB, a

very popular dynamic scripting language for numeri-

cal computation and matrix processing used by scien-

tists, engineers and students (Radpour et al., 2013).

The second is Octave

, a (mostly compatible) open

source MATLAB clone. Both languages provide re-

sources for solving common numerical linear alge-

bra problems, e.g., computing the roots of nonlinear

equations, integrating ordinary functions, manipula-

ting polynomials, as well as integrating ordinary dif-

ferential and differential-algebraic equations. In most

cases, programs written in those languages are of-

ten developed incrementally using a combination of

scripts and functions and frequently build upon exis-

ting code.

https://www.gnu.org/software/octave/about.html

The execution of Octave programs uses its own

interpreter that is available in the project website

This interpreter is a parse-tree library developed in

C++ that generates the code’s Abstract Syntax Tree

(AST). Although it covers all the features of Octave,

it does not include documentation or references regar-

ding its source code. Comprehension of the parser is

not trivial, especially considering the effort to under-

stand the attributes and methods. To illustrate, some

methods found in the parser source code include:

yypull parse, yypstate new, yyparse, yyalloc

and yytnamerr. The MATLAB interpreter also in-

cludes a parser, but it is not possible to verify the type

of output generated, since this language is proprietary

and does not make its source code publicly available.

Our initial aim was to use one of the options men-

tioned above, but this did not prove feasible due to

the aforementioned limitations. Considering the vari-

ations between the MATLAB and Octave languages,

adjustments must be done to the source code of the

parse-tree to cover the programs developed in both

programming languages.

https://ftp.gnu.org/gnu/octave/

de Lima Mariano, T., de Figueiredo Carneiro, G., Pessoa Monteiro, M., Brito e Abreu, F. and Munson, E.

A Parser and a Software Visualization Environment to Support the Comprehension of MATLAB/Octave Programs.

DOI: 10.5220/0006644701790186

In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 179-186

ISBN: 978-989-758-298-1

179

We have identiﬁed a set of parsers developed

for the MATLAB and Octave programming langua-

ges: Octclipse

, GNU Octave

, ANTLRv4

, McSAF

(Doherty and Hendren, 2012), Magica tool (Joisha

and Banerjee, 2003) and MaJIC (Alm

asi and Padua,

2002). However, we have observed that they are not

suitable nor provide appropriate conditions to be ex-

tended and adapted to provide data to software com-

prehension tools. For example, none of them produce

or export KDM representations to be further used in

such tools. Octclipse is an Eclipse plugin that sup-

ports the development of Octave applications. It has

no development activity since 2015 and according to

its documentation, is compatible to Octave only until

version 3.6. Therefore, some features found in more

recent versions of Octave are not covered by its cor-

responding parser. Similar limitations are reported in

the ANTLRv4 documentation, as regards the capabi-

lity of generating the AST from MATLAB programs.

Updates to this parser were not made since 2015 and

likewise does not support the more recent language

features. In addition, the parser does not cover fe-

atures such as switch statements, structures and cell

arrays. McSAF is a compiler analysis framework that

is intended to enable compiler research by providing

both an intermediate representation and an intraproce-

dural analysis framework which can be used both for

MATLAB and language that are extensions of MAT-

LAB (Doherty and Hendren, 2012). However, the

main limitation of McSAF is the signiﬁcant effort it

requires to produce or export KDM representations.

The Magica tool (Joisha and Banerjee, 2003) de-

als with type inference for matrix operations and

functions. In addition to inferring the intrinsic type

of matrices, such as int32, double, or char, it also in-

fers matrix sizes and shapes. Magica has the goal to

perform code optimization. Another compiler project

for MATLAB is MaJIC (Alm

asi and Padua, 2002).

It uses a Just-In-Time (JIT) compiler component to

achieve speedups. The main difference of focus bet-

ween these two projects and the parser presented here

is that their main goal was to improve the performance

of MATLAB programs. They do not have the main

goal to provide data to tools that support the compre-

hension of programs coded in the two aforementioned

languages.

Although tools are available to support the deve-

lopment of MATLAB and Octave applications, to the

best of our knowledge just a few seem to be geared to

source code analysis and comprehension. We could

https://sourceforge.net/projects/octclipse/

https://www.gnu.org/software/octave/

https://github.com/ericharley/matlab-parser

perhaps mention MATLAB Online

, Octave Online

, JDoodle

and Coding Ground

. MATLAB Online

is a web version of the Mathworks software develop-

ment tool. In this release, source code ﬁles are stored

in MATLAB Drive. Octave Online is a web tool used

in the development of Octave applications. JDoodle

and Coding Ground are web tools for developing ap-

plications in various programming languages, inclu-

ding MATLAB and Octave. However, these tools lis-

ted before mainly provide an online programming en-

vironment where programmers can type and run their

code. They lack sophisticated support for software

comprehension and analysis such as the use of visua-

lization resources to identify the entities that comprise

code and their relationship (Storey, 2006) or traceabi-

lity between functional requirements of the program

and the correspondent piece of code that implements

it (Chen, 2010).

In previous work, we implemented an Eclipse

plug-in to support MATLAB and Octave pro-

grams comprehension through visualization resources

(Lessa et al., 2015b)(Lessa et al., 2015a). The plug-in

relied on a parser provided by the GNU Octave pro-

ject. The tool was dependent on Eclipse IDE and it

was not possible to export or import data from/to the

tool. Moreover, the visual metaphors that represented

code entities and possible relationships between them

were implemented using the Draw2d layout and ren-

dering toolkit building on top of SWT in Eclipse (The

Standard Widget Toolkit), which does not provide vi-

sualization resources such as those used by some web

pages currently available. From the users perspective,

this has an impact on the attractiveness of the visual

metaphors.

The rest of this paper is organized as follows.

Section 2 presents the parser implemented to con-

vert MATLAB/Octave source code to instances of the

Knowledge Discovery Metamodel (KDM). Section 3

describes how the proposed parser was integrated to

a visual interactive environment aimed at supporting

the comprehension of MATLAB/Octave programs.

Section 4 conclusions and directions of future work.

2 PARSER IMPLEMENTATION

The goal of the proposed parser is to support different

kinds of tasks, including the provisioning of data to

https://www.mathworks.com/products/matlab-

online.html

https://octave-online.net/

https://www.jdoodle.com/execute-octave-matlab-

online

https://www.tutorialspoint.com/codingground.htm

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

180

feed visual metaphors to represent MATLAB/Octave

programs. The literature has already called attention

to this need. For example, in (Monteiro et al., 2010),

the authors provide a short review of the state-of-the-

art of aspect mining and particularly the identiﬁcation

and localization of crosscutting concerns (CCCs) as

latent aspects. They conclude that until that time, not

enough attention was paid to this topic in the context

of MATLAB systems.

In the context of compilers in programming lan-

guages, a parser aims at analyzing the given sequence

of tokens to build a hierarchical data structure ac-

cording to previously established syntactic rules. In

most cases, the output of this transformation is a tree

structure, whose building process is carried out either

through top-down or bottom-up approaches. In the

ﬁrst case, the tree is built from the root to the leaf

nodes, while in the bottom-up approach the ﬂow is

in the opposite way (Aho et al., 2007). One of the

main advantages of the parser presented in this paper

is the conversion of source code of MATLAB/Octave

programs to KDM instances that can be subsequently

used to provide data to support the analysis and com-

prehension of target systems. In our case, we use the

data converted by the proposed parser to feed a soft-

ware comprehension visualization environment.

Parser Steps. Having this in mind, we developed the

parser in two steps. Step 1 comprises an intermedi-

ate parser capable of generating the AST of MAT-

LAB/Octave programs from its source code (parts A,

B and C of Figure 1). Step 2 comprises another partial

parser to generate KDM instances from AST (parts C,

D and E of Figure 1). In this case, part E shows the

data to be provided to software comprehension tools

to support program analysis.

To deal with several small differences between

MATLAB and Octave, we performed a prior analysis

of their grammars (Version 4.2.0 of the GNU Octave)

, the packages that comprise the KDM metamodel

and how the KDM metamodel can effectively repre-

sent MATLAB/Octave programs. This is a key issue

for the proposed parser presented in this paper.

During the language analysis phase (part A of Fi-

gure 1), the set of operations is identiﬁed, how they

work and which operators can be used. This inclu-

des arithmetic operators, comparison operators, bool-

ean expressions, function calls, assignment expressi-

ons, increment operators, and role deﬁnitions. Mo-

reover, several control structures (e.g., if, switch,

while, etc) and statements such as continue, break,

unwind, protect, try and continuation lines are also

considered. The ASTOctave library recognizes each

www.gnu.org/software/octave/doc/v4.2.0/

index.html#SEC Contents

of these operations, creates an element to represent

them and registers them as an AST node (part C of

the Figure 1). The version 4.2.0 of the GNU Octave

documentation

was used as a support for this imple-

mentation.

The analysis of the KDM metamodel was a requi-

rement to implement part D of Figure 1. More speci-

ﬁcally, we identiﬁed twelve packages from the KDM

metamodel whose elements aimed at representing a

speciﬁc part of the system under analysis. Packa-

ges from the KDM metamodel are deﬁned in layers.

The Code package is the main package upon which

all the others provide their respective services. In

the Parser implementation described here, we use

elements from the ﬁve lower packages: Core, kdm,

Source, Code and Action. These elements where

then selected to be part of the XMI ﬁle to describe

the target system.

Considering all the steps presented in Fi-

gure 1 to convert MATLAB/Octave programs

to KDM instances, we implemented the follo-

wing ﬁve libraries ASTOctave, ASTOctaveToKDM,

OctaveKDMStructure, OctaveKDMToJSON and

OctaveKDMToXMI.

The ﬁrst library of the pipeline is

ASTOctaveToKDM whose goal is to scan all the

source ﬁles from an Octave or MATLAB target

project. Library ASTOctaveToKDM is the central

mediator of the proposed set of libraries, being

responsible for instantiating the KDM representation

of the project to be parsed. It is also responsible

for controlling when and how other libraries are

instantiated and used. In this scenario, it instantiates

and calls library ASTOctave aimed at reading a MAT-

LAB or Octave ﬁle and generating the corresponding

AST. Library ASTOctave also creates the project’s

KDM metamodel. Library OctaveKDMStructure

represents the KDM structure of MATLAB and

Octave applications.

KDM Packages Description (OMG, 2016). Core:

Deﬁnes the basic elements to be used by all other

packages, including the entities, their relationships,

and the basic data types, such as String, Boolean,

and Integer. Therefore all other packages depend

on it but Core does not depend on any of them. These

basic data types are used to represent the KDM attri-

butes, their operations, and their parameters.

KDM: Deﬁnes key environment elements setting

the standards for building KDM views on the target

system. The elements described in this package, to-

gether with the elements described in Core, comprise

the KDM framework.

www.gnu.org/software/octave/doc/v4.2.0/

index.html#SEC Contents

A Parser and a Software Visualization Environment to Support the Comprehension of MATLAB/Octave Programs

181

Figure 1: Parser Steps: from the Source Code to the KDM Instance.

Figure 2: Hierarchical structure of the KDM objects.

Source: Deﬁnes elements that are used to repre-

sent the physical artifacts of existing software, e.g.,

images, source ﬁles, conﬁguration ﬁles. For instance,

if the target system has ten ﬁles, each ﬁle will be re-

presented by an element deﬁned in Source.

Code: Has an extensive set of elements used to re-

present the implementation of the target system. Each

instance of a Code element corresponds to a region of

the source code of an artifact from the target system.

Action: Deﬁnes a set of elements representing be-

havior determined by programming languages, e.g.,

declarations, operators, conditions.

The KDM elements used to represent MAT-

LAB/Octave programs, with their respective hierar-

chy, is represented in Figure 2. Finally, libraries

OctaveKDMToXMI and OctaveKDMToJSON scan the

data stored under the project’s KDM structure and re-

spectively generate the XMI and JSON ﬁles of that

structure. We decided to use the JSON format for the

parser output, to allow native manipulation of the data

using NoSQL database. The goal is to facilitate infor-

mation retrieval from the data stored in NoSQL data-

bases. This was the motivation for developing library

OctaveKDMToJSON.

Parser Execution. The execution of the proposed

parser entails using library ASTOctaveToKDM as the

central point and reference for the other libraries. The

method parseProjectToKDM is responsible for crea-

ting the KDM structure to be located in the path indi-

cated as a parameter.

After the process is initiated, library

ASTOctaveToKDM traverses all the project’s source

code ﬁles. For each ﬁle found, it calls library

ASTOctave through method generateAST, passing

the ﬁle as parameter. Library ASTOctave reads the

contents of the ﬁle and generates the corresponding

AST, returning it to library ASTOctaveToKDM. Library

ASTOctaveToKDM scans all nodes and converts each

AST element into a KDM element through the use of

library OctaveKDMStructure. When all within AST

nodes are converted, library ASTOctaveToKDM passes

the KDM instance to libraries OctaveKDMToXMI and

OctaveKDMToJSON. In fact, these instances represent

the project under analysis. The last mentioned two

libraries (OctaveKDMToXMI and OctaveKDMToJSON)

read all KDM elements and respectively generate the

corresponding XMI and JSON ﬁles.

3 BUILDING A SOFTWARE

VISUALIZATION

ENVIRONMENT

In this section, we report on the experience gained

during development of the software visualization en-

vironment -whose main goal is to support the compre-

hension of MATLAB/Octave programs based on visu-

alization resources using data provided by the parser.

Its architecture is presented in Figure 4, which high-

lights the role of the proposed parser to convert data

from part A to part B of the Figure.

The technologic solution is comprised of the Apa-

che Tomcat web container, the CouchDB NoSQL data-

base management system, the REST Java API to cre-

ate the services, the jQuery Ajax, and D3.js, a Java

Script library to manipulate DOM objects based on

JSON data. These technologies are used to imple-

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

182

ment parts B, C, D, and E of the visualization pipeline

shown in Figure 4.

3.1 The Persistence Level

One of the main reasons for selecting a NoSQL do-

cument oriented database is its native ﬂexible schema

functionality. As a result, two or more documents can

have very different schema and data values, unlike in

the relational model, where each row in a table will

have same columns (Li and Manoharan, 2013). For

example, data related to different MATLAB and Oc-

tave programs can be stored in a document-oriented

database where each document can contain the soft-

ware entities of a speciﬁc ﬁle and their respective re-

lationship. Each software entity has a set of attributes

that may vary from one entity to another. In that case,

a relational model would not be suitable to deal with

this variation.

Considering the four options of NoSQL database

templates available, we decided to use the model that

best ﬁts the way data is stored within the application

source code is document-oriented. The suitability of

the data structure of document-oriented databases to

the data structure of the JSON ﬁles (a tree, where a

code block can have one or more blocks inside it in

a nested form) created by the parser presented in this

paper inﬂuenced the adoption of a document-oriented

database.

We decided to adopt the document-oriented

NoSQL CouchDB database (Cluster of Unreliable

Commodity Hardware

) for the environment, as it

is a distributed schema database providing a ResTful

JSON (Java Script Object Notation) to manage do-

cuments stored through HTTP calls. The CouchDB-

based HTTP mechanism is scalable to heavy loads of

requests by responding to HTTP calls using the GET,

POST, PUT, or DELETE http methods (Anderson et al.,

2010).

3.2 Parsing Raw Data

Part A of the environment described in Figure 4 cor-

responds to the raw data - the code of the projects to

be analyzed in this case. We chose the Github repo-

sitory, mainly due to the number of MATLAB and

Octave designs available. In addition, Github is a

world-renowned public repository, widely used and

respected by free software developers. Part B of the

environment from Figure 4 represents the transforma-

tion from code to data structures - to be stored in a

database - performed by the parser. See section 2 for

https://goo.gl/mtnk

details on the transformation steps of the original data

(program code).

The data is stored in the database as KDM ele-

ments, which represent the entities that comprise the

projects and their respective information, such as their

relationship with other elements of the program. We

needed to map these elements to documents in the

JSON format, a task that was also carried out by the

parser. The resulting JSON ﬁles are illustrated in part

B of Figure 4. The ﬁrst element found in the KDM

structure is the KDMSegment object, which represents

the project itself and is converted into a JSON docu-

ment with the following attributes: id, type and name.

In attributes id and name, the project name was en-

tered and the String ”kdm:Segment” was inserted into

attribute type. The attribute of all other documents

is generated automatically by the database. Figure 3

shows a section of this document.

Figure 3: A JSON Document Sample Representing the

KDMSegment Object.

The next element found is object CodeModel. In

addition to the attributes created in the KDMSegment,

two new attributes are created: idParent and idPro-

ject, which will have the same value corresponding

to attribute id of object KDMSegment. The same

goes for object InventoryModel. Attribute type en-

tered in the document that represents the CodeMo-

del receives as value the String ”code:CodeModel”.

In the case of the InventoryModel object, the String

”source:InventoryModel” is assigned to the attribute

type. All other documents have the idProject attribute

and the id of the document that represent the KDM-

Segment is added to this attribute.

InventoryModel objects can contain Directory and

SourceFile objects. It is a part of the KDM instance

environment. As a general rule, each instance of the

inventory model represents a ﬁle or a set of ﬁles in a

given KDM instance.

This meta-model element is a container of instan-

ces of other inventory meta-model elements. In ad-

dition to the attributes already mentioned, the do-

cuments that represent these objects also have the

attributes path and language. The String ”MAT-

LAB/Octave” is assigned to the language attribute,

whereas the path attribute receives the directory path

in which these ﬁles or folders are located within the

project. The type attribute of the SourceFile object

receives the String ”source:SourceFile”. In the case

A Parser and a Software Visualization Environment to Support the Comprehension of MATLAB/Octave Programs

183

Figure 4: Environment to Support the Visual Analysis of MATLAB/Octave Programs.

of the Directory object, the type attribute receives the

String ”source:Directory”. The idParent attribute of

these documents receives the id of the document that

represents the InventoryModel object.

Each CompilationUnit object found in the Code-

Model object is converted to a different JSON docu-

ment with the attributes id, name, type, idProject, and

idParent. The name attribute is given the name of the

source ﬁle that this element represents. The type attri-

bute receives the String ”code:CompilationUnit” and

idParent receives the id of the document that repre-

sents the CodeModel element. We decided to convert

the CodeModel object to different JSON documents

due to performance reasons. The memory storage ca-

pacity of CouchDB does not accept a single document

containing multiple CodeModel objects. We obser-

ved that carrying out queries targeting multiple docu-

ments, one for each object, also provided better per-

formance results. Element CallableUnit is converted

into a document with attributes id, type, name, idPa-

rent, idProject, idCompilation and compilation. At-

tribute type receives the String ”code:CallableUnit”.

Attribute name is given the name of the function re-

presented by this element. Attribute idParent receives

the id of the document that represents the Compilati-

onUnit to which this function belongs. Attribute id-

Compilation receives the id of the document that re-

presents the CompilationUnit element to which this

function is part and attribute compilation is given the

name of the ﬁle itself.

The documents representing the Blockunit, Co-

deElement and StorableUnit elements have attribu-

tes id, kind, name, idParent , idProject, idCom-

pilation, and compilation. These documents can

also receive attributes idCallable and nameCalla-

ble, if the elements they represent are inside an ele-

ment that represents a function. Attribute type of

the documents that representing elements BlockUnit,

CodeElement and StorableUnit respectively receive

values ”action:BlockUnit”, ”action:ActionElement”

and ”code:StorableUnit”. Attribute kind is populated

with the value stored in variable kind of the KDM ele-

ment. The same thing happens with attribute name.

The rule for ﬁlling in the remaining attributes is ex-

actly the same as that used in the document represen-

ting element CallableUnit.

Figure 5 shows an example of a JSON ﬁle repre-

senting the CallableUnit element of the KDM of a

MATLAB/Octave program. Attributes id and rev cor-

respond to the unique identiﬁer of this document in

the database. They are generated automatically by

CouchDB. The rev attribute indicates the version of

the document. The same document may have multi-

ple versions in the CouchDB. The value assigned to

attribute type signals that this element matches the

function within a MATLAB/Octave program. Attri-

bute name has the name of this function. Attribute

idParent indicates the id of the parent document of

that element representing a function. In this case, the

parent document represents the BlockUnit element of

the KDM. This BlockUnit corresponds to the code

block of a program code ﬁle. Attribute idProject has

the id of the document that represents the KDMSeg-

ment element of the KDM, represented in Figure 3.

This element identiﬁes the project under analysis. At-

tributes idCompilation and compilation identify the

code ﬁle that contains this function. The KDM ele-

ment that represents a code ﬁle is CompilationUnit.

Attribute idCompilation has the id of the document

that represents CompilationUnit and attribute com-

pilation stores the name of the code ﬁle. Attribute

signature stores the signature of a MATLAB/Octave

function along with its parameters.

Through Figures 3 and 5, it is possible to verify

that, in the KDM structure, the CallableUnit element

represented in Figure 5 is hierarchically below ele-

ment BlockUnit. Element BlockUnit is hierarchically

below element CompilationUnit. Element Compila-

tionUnit is hierarchically below element CodeModel

and element CodeModel is hierarchically below ele-

ment KDMSegment represented in Figure 3. This ve-

riﬁcation can be veriﬁed by linking attributes idParent

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

184

and id of each of these elements.

To ﬁnd information about MATLAB/Octave pro-

jects stored inside DBMS, CouchDB provides a fea-

ture for accessing data called view. Views are created

within CouchDB itself as a JSON document and are

deﬁned through Java Script functions. Figure 6 repre-

sents a view created inside the CouchDB. This view

is able to return all documents stored in the database

whose attribute type has the value ”kdm:Segment”.

Figure 5: Data Structure of a JSON File Representing a

KDM CallableUnit Element.

Figure 6: CouchDB View Sample.

The view displayed in Figure 6 was executed

through the Futon tool, which corresponds to a web

application used to manage CouchDB. This tool al-

lows one to create databases, documents and views. In

addition, these can be modiﬁed or removed. It is also

possible to manage the CouchDB settings through Fu-

ton. This view functionality of CouchDB was used

to loop through the set of documents that make up

the KDM structure of a given project and mount a

JSON ﬁle with the information needed for visualiza-

tion. This process of transforming the original data

into a new ﬁle in the format required for visualization

is illustrated in part C of the environment described

in Figure 4.

The Server Side of the Environment. The server

side of the application, represented in part D of Fi-

gure 4, consists of Java classes that are responsible

for containing the business rules of the application,

the access to the CouchDB database and the servi-

ces to access the data. It is also the responsibility of

the server to use the library ASTOctaveToKDM to ge-

nerate the KDM metamodel of the MATLAB/Octave

programs and store it in the database.

We developed some methods in the server appli-

cation controller that are responsible for traversing all

the elements contained in the created KDM structure

and converting them into JSON documents, which

were subsequently saved in CouchDB. After mapping

the KDM elements in the corresponding JSON do-

cument, a feature was developed to store it in the

database through the use of the Java library Light-

couch, which corresponds to a Java Application Pro-

gramming Interface (API) for communication with

the CouchDB database.

The Client Side of the Environment: Imple-

menting the Visualization Resources. The client

side of the view environment represented in part E

of Figure 4 corresponds precisely to the joining of the

html pages with their Java Script functions and style

sheets. It is at this stage that the visual metaphors,

containing the MATLAB/Octave program data, are

displayed. The visual metaphors available in the envi-

ronment use the D3.js, which is an open source Java

Script library that provides resources for manipula-

ting HTML documents. It uses Java Script as the lan-

guage for implementing data mapping for documents

(Bostock et al., 2011).

The ﬁrst visual metaphor indicated to be used in

the proposed environment is Treemap

. This visual

metaphor is capable of representing large volumes of

hierarchical data through recursively nested rectang-

les representing domain-relevant entities also known

as real attributes. Examples of these attributes are the

number of source lines, the source code ﬁles, their re-

spective functions, and other real attributes that can be

visually represented by visual attributes such as rec-

tangle, color, and size (Shneiderman, 1992). The se-

cond visual metaphor indicated to be used in the pro-

posed environment is chord

. The chord view is ca-

pable of displaying a set of arcs forming a circle and

a set of lines connecting each of these arcs to repre-

sent their relationships. The size of the arcs in the cir-

cle varies according to the number of connections you

have with the other arcs of the circumference. While a

small amount of data could be represented in a circu-

lar diagram using straight lines to show interconnecti-

ons, a diagram with numerous lines would quickly be-

come unreadable. To reduce visual complexity, chord

https://bl.ocks.org/mbostock/4063582

http://bl.ocks.org/NPashaP/ba4c802d5ef68f70c019a97

06f77ebf1

A Parser and a Software Visualization Environment to Support the Comprehension of MATLAB/Octave Programs

185

diagrams employ a technique called hierarchical edge

grouping (Holten, 2006). The chord view has been

mapped to contain in each arc of the circumference

a source code ﬁle of a MATLAB/Octave project and

the lines thet connecting the arcs represent the afferent

and efferent couplings between each of these ﬁles.

The communication between the client side of the

application and the server side is done through of calls

by the Java Script functions to services available on

the server side by the REST technology. Rest is an

architectural style that allows the development of ser-

vices that can be accessed via calls by url.

4 CONCLUSION AND FUTURE

WORK

The main goal of the parser is to generate KDM in-

stances of programs developed in languages MAT-

LAB/Octave, which in turn can be used as input to

support processes of analysis and understanding.

In short, the advantages of the proposed parser

in comparison with the related work are summari-

zed as follows. The proposed parser convert MAT-

LAB/Octave programs in KDM instances and these

instances can be manipulated by tools and APIs that

know the KDM metamodel.

REFERENCES

Aho, A. V., Sethi, R., and Ullman, J. D. (2007). Compilers:

principles, techniques, and tools, volume 2. Addison-

wesley Reading.

Alm

asi, G. and Padua, D. (2002). Majic: Compiling mat-

lab for speed and responsiveness. In ACM SIGPLAN

Notices, volume 37, pages 294–303. ACM.

Anderson, J. C., Lehnardt, J., and Slater, N. (2010). Cou-

chDB: the deﬁnitive guide. ” O’Reilly Media, Inc.”.

Bostock, M., Ogievetsky, V., and Heer, J. (2011). D

data-

driven documents. IEEE transactions on visualization

and computer graphics, 17(12):2301–2309.

Chen, X. (2010). Extraction and visualization of traceabi-

lity relationships between documents and source code.

In Proceedings of the IEEE/ACM international confe-

rence on Automated software engineering, pages 505–

510. ACM.

Doherty, J. and Hendren, L. (2012). Mcsaf: a static analy-

sis framework for matlab. In European Conference

on Object-Oriented Programming, pages 132–155.

Springer.

Holten, D. (2006). Hierarchical edge bundles: Visualiza-

tion of adjacency relations in hierarchical data. IEEE

Transactions on visualization and computer graphics,

12(5):741–748.

Joisha, P. G. and Banerjee, P. (2003). The magica type in-

ference engine for matlab

. In International Con-

ference on Compiler Construction, pages 121–125.

Springer.

Lessa, I. M., Carneiro, G. d. F., Monteiro, M. P., and

e Abreu, F. B. (2015a). On the use of a multiple

view interactive environment for matlab and octave

program comprehension. In International Conference

on Computational Science and Its Applications, pages

640–654. Springer.

Lessa, I. M., de Figueiredo Carneiro, G., Monteiro, M. P.,

and e Abreu, F. B. (2015b). Scaffolding matlab and

octave software comprehension through visualization.

In SEKE, pages 290–293.

Li, Y. and Manoharan, S. (2013). A performance com-

parison of sql and nosql databases. In Communica-

tions, Computers and Signal Processing (PACRIM),

2013 IEEE Paciﬁc Rim Conference on, pages 15–19.

IEEE.

Monteiro, M., Cardoso, J., and Posea, S. (2010). Identi-

ﬁcation and characterization of crosscutting concerns

in matlab systems. In Conference on Compilers, Pro-

gramming Languages, Related Technologies and Ap-

plications (CoRTA 2010), Braga, Portugal, pages 9–

10.

Munzner, T. (2014). Visualization analysis and design.

CRC press.

OMG, O. M. G. (2016). Architecture-driven moderniza-

tion: Knowledge discovery meta-model (kdm). No

Informado.

Radpour, S., Hendren, L., and Sch

afer, M. (2013). Refacto-

ring matlab. In International Conference on Compiler

Construction, pages 224–243. Springer.

Seriai, A., Benomar, O., Cerat, B., and Sahraoui, H. (2014).

Validation of software visualization tools: A systema-

tic mapping study. In Software Visualization (VIS-

SOFT), 2014 Second IEEE Working Conference on,

pages 60–69. IEEE.

Shneiderman, B. (1992). Tree visualization with tree-maps:

2-d space-ﬁlling approach. ACM Transactions on

graphics (TOG), 11(1):92–99.

Storey, M.-A. (2006). Theories, tools and research methods

in program comprehension: past, present and future.

Software Quality Journal, 14(3):187–208.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

186