Empirical studies on fault behaviour in evolving complex software systems have shown that communication structures among the software entities such as classes, modules, software units and communications among them, is signicantly aecting the system fault behaviour. Therefore, we were motivated to further investigate software structures. One interesting question is to investigate software structures from software products written in dierent programming languages. In this work we present our preliminary study for which we developed tools to examine software structures of software products written in Java and Erlang programming language. We provide details on how we extract software structure from software product and provide preliminary results analyzing four Erlang software products and four Java software products.
18:2
in terms of network graphs. Like we did in ou
The rest of the paper is organized as follows. At first, in Section 2 is description of background, in Section 3 we present the used tools to extract the software structures in different programming languages. Then in Section 4 we present the preliminary results obtained by simple comparison of results obtained for Erlang and Java code. Finally, in Section 6 we conclude the paper.
To analyze software structure we can define different types of structures, modules, classes and different
types of software unites. Graph theory is a field of study that looks into the formal description and
analysis of graphs [Bullmor
In this work we used four different tools.
For analyzing Java written applications we used the tool rFind [Petric and Grbac 2014; Petric et al. 2014a]. The input of rFind is an application code written in Java.
As an output we receive two files that allow us to see all calls between classes. One of those files is .classlist where a list of all classes is displayed using class ids for easier reading. Each class represents a node in the network. The other file is a .graph where all connections between class ids are presented. Every connection is viewed as an edge between nodes.
For getting the same information from Erlang applications we used the tool RefactorErl [Bozó et al. 2011]. RefactorErl is an open source static source code analyser and transformer tool for Erlang. RefactorErl supports dependency examination both on module and function level, and is able to present it as a graph to the user. The input of the tool were applications written in Erlang, and it was able to produce a textual representation of dependencies as an output. Although the presentation of the result was quite different from the output of rFind, but the main idea was the same: present communication between modules.
The SuBuCo tool [Petric et al. 2014b] is an application that expects an Rfind output as input: the .classlist and .graph. Then it searches for three-node subgraph structures inside .graph file. Its output is a list of all subgraphs that appear in the given code. The file created contains a list of all subgraphs separated by subgraph type and ids of every class/module contained in specific subgraph.
Since the output of RefactorErl was not in the form for SuBuCo analysis, we wrote a parser to adjust the result so that it also contains .classlist and .graph. The parser was implemented in Java where the input files were files gathered from RefactorErl and the output files were the two needed files. The whole analysis process can be seen in Figure 2.
Our tests were conducted on four different software implemented in the Erlang programming language and four written in Java. The analysed Erlang software are: Mnesia for distributed telecommunications database; Dialyzer that allows static analysis for identifying software discrepancies; Cowboy which is a http server for Erlang/OTP; and RabbitMQ server that runs a multi-protocol messaging 18:4 broker. The former two are part of the standard Erlang/OPT distribution, the latter two applications were taken from open git repositories. For analyzing software written in Java we used Java Development Kit (JDT) and Plug-in Development Environment (PDE) projects from Eclipse project, Open Microscopy Environment that is an open-source software and data format standards for the storage and manipulation of biological microscopy data, and Ultimate Android, development framework, from git repository.
ERLANG PROJECT Mnesia Cowboy Dialyzer RabbitMq JAVA PROJECT OpenMicroscopy Ultimate Android JDT PDE
The number of edges and nodes for each tested software can be seen in Table I. Number of edges seems to be much larger in Java software, even where number of nodes is lesser then in Erlang software. In examples where the number of nodes are similar, Mnesia and Ultimate Android applications, number of edges is still much greater in Java application than in Erlang. Communication is far more common in Java written software. We can see that in all tested applications number of edges grows with the number of nodes.
Subgraph ids discussed in this section are referring to the network subgraphs in Figure 1. In three out of four applications in Erlang subgraph with id 36 was the most common. The same subgraph id also was the most present in both Java projects and in projects gathered from git repositories. It seems that the communication in which multiple classes/modules heavily use one library is the most frequent one. Only one had different results, Dialyzer. We can see from the Tables II-V that in all Erlang applications subgraph ids 36,6 and 12 are the most common ones, most often in that exact order. Subgraph with id 6 presents communications where one node needs multiple resources from other nodes and the subgraph with id 12 could be the situation where communication flows from one node to the other and when the second node is triggered he calls for the third node. In Tables VI-IX. we can see that Java projects behave similarly. In all projects it is the same order of frequency while in PDE id 38 is present more often than 12.
In terms of subgraph id appearance, we can see that subgraphs with id 238 and 110 do not appear in any of Erlang application and neither in Java applications. Subgraph with ids 102 and 98 were found in Erlang application, but not in any of Java applications. We can see that applications written in Erlang and Java have similar behavior in terms of subgraph id appearance, even though Java software products are greater in class/module size. 18:6
Looking at Pareto diagrams on Figures 3 and 4 we can see that there is significant growth only for subgraph types 36,6,12 and 38 in both Java projects and Erlang projects.
Data collection and analysis is possible on any code written in Erlang or Java. Erlang applications that were tested are server implementations, database and static analytic tool. Java software applications were frameworks for developing Java software and software for working with specific types of data. Software function is not the same in Erlang and Java applications. Since Erlang is a language used for scalable soft real-time systems and Java is general purpose programming language, comparing software applications written in each of them could not give us generalized conclusions. Comparing similar types of languages could be a better approach.
In this study our main focus was to analyze code structure on software written in Erlang and compare it to the software written in Java.
To do that we used several tools and combined them together to get the appropriate output that we can analyze. We represented class/module communication using thirteen subgraph types.
In code written in Java, there was much larger number of communicating classes in comparison to communicating functions in Erlang code. Subgraph types 38,36,6,46,12,74 and 14 were present in all tested code. Types 108 and 78 were present in two software applications. Besides id 46, they are the only ones present that have the number of edges higher then 3. The one with the highest occurrence was subgraph type 36 in every tested application, followed by types 6 and 12. Subgraph ids 102,238,98 and 110 did not appear at all. There is no communication where more then four interactions between three classes are existent.
Unlike in Java applications, in Erlang applications subgraph id 98 occurred in all tested applications and id 102 appeared in two tested applications. Subgraph with id 98 is the only one where communication is circular, it starts and ends in the same node with just one interaction between each node. Just as in Java application, in Erlang applications ids 36,6 and 12 had the highest occurrence but in different percentage. While in Java applications subgraph id 36 occupied over 89% of all subgraphs, in Erlang the same id occupied between 58% and 68% while in Dialyzer it had appearance of only 34%. On tested java software, had a low appearance rate of under 10%. In Erlang applications result was different. Id 6 had a presence of around 20% in Mnesia and RabbitMQ. In Dialyzer, it had the largest number of appearance, 51%.
We can see that in Java written code, subgraph id 36 occupies more then 90% of all the communication while in Erlang code, ids 36 and 6 together occupy 80-90%.
Based on the code analysis, we can conclude that although there is similar behavior between languages, there are some differences. There are structures that appear in Erlang, but not in Java. Specifically structures where there is more communication edges between modules and id 98 where communication is circular. It is possible that those types are specific to that language. There is also a difference in percentage of the subgraph. While id 36 is in an extensive number of subgraph in Java, types of communication where one library is being heavily used by other classes, in Erlang that number is much lesser. We can see that the usage of libraries is greater in Java programs. There is also a big difference in number of communicating classes/modules. It seems that classes in Java programming language tend to communicate more often than Erlang modules. It is possible that those results are because of the fact that Java is an object oriented language and is based on object communication.
In our future work we aim to do the analysis on code written in other programming and scripting languages, both functional and object oriented. Doing that we can come to the determinant conclusion in aspect of which subgraph types are specific for individual programming languages or applications.