# A Novel Approach to Automate Complex Software Modularization Using a Fact Extraction System

Authors: Muhammad Zakir Khan; Rashid Naseem; Aamir Anwar; Ijaz Ul Haq; Ahmad Alturki; Syed Sajid Ullah; Suheer A. Al-Hadhrami
Journal: Journal of Mathematics
 (2022)

---

## Abstract

Complex software systems that support organizations are updated regularly, which can erode system architectures. Moreover, documentation is rarely synchronized with the changes to the software system. This creates a slew of issues for future software maintenance. To this goal, information extraction tools use exact approaches to extract entities and their corresponding relationships from source code. Such exact approaches extract all features, including those that are less prominent and may not be significant for modularization. In order to resolve the issue, this work proposes an enhanced approximate information extraction approach, namely, fact extractor system for Java applications (FESJA) that aims to automate software modularization using a fact extraction system. The proposed FESJA technique extracts all the entities along with their corresponding more dominant formal and informal relationships from a Java source code. Results demonstrate the improved performance of FESJA, by extracting 74 (classes), 43 (interfaces), and 31 (enumeration), in comparison with eminent information extraction techniques.


---

## Body

## 1. Introduction

Software systems are essential in our daily lives, businesses, and governmental organizations, and they require an updated software system to meet their functional and nonfunctional requirements. Client requests or changes in the system’s environment may cause changes in requirements [1–3]. Changes deteriorate the architecture of software systems, making it difficult to maintain them. In such situations, the software system must be designed in such a way that the negative effects of modifications to the software system are kept to a minimum. Updated documentation is required for updated software. If the documentation is outdated, the software systems need to be retired or replaced.Reverse engineering is the first step in re-engineering, and it involves understanding the system and acquiring the necessary information for software system maintenance [4, 5]. Information can be extracted from a software system through documentation, compiled code, development team members, and source code [6]. The most reliable source of information for restoring software architecture has been observed to be source code. The reason is the most recent version of the software, and this source code will be built and eventually run, the information gathered from it is the most reliable. Information extracting from the source code of a software system, on the other hand, is a challenging task since no developer can fully know the code of a large and complex system. As a result, we need tools to automatically extract information from source code, which will help in the recovery of software architecture and the comprehension of software systems [7]. The understanding and recovery of architecture are crucial for software maintenance and evolution.The first step in modularizing a software system is to analyze it since source code is the primary source of information for extracting artifacts. The need for a software modularization technique that transforms low-level artifacts (source code) into abstract views (high-level) [1, 5]. Two approaches can be utilized for code analysis: an exact approach and an approximate one. The exact approach utilized the parser to analyze the whole source code, whilst the approximate approach utilized it to extract the specified parts of the information. We propose a methodology for evaluating Java source code in order to discover entities and their relationships in a Java software system in this paper. The selection of an object-oriented system since it is a more realistic approach to software development. Object-oriented software systems developed in the 1990s are now legacy systems with an unstable structure due to changes made to them [5, 7]. Their documentation is either non-existent or obsolete. A comprehensive understanding of these software systems is necessary for future updates and maintenance.The proposed system is named “Fact Extractor System for Java Application,” or FESJA, which gives an approximate approach to automatic Java application software modularization. Entities such as classes, interfaces, and enumerations and their relationships (formal and informal) can be extracted using the tool. We utilized FESJA to extract formal relationships from classes in several Java software systems; interfaces and informal relationships are 74 and 43, respectively. We have extracted 31 relationships to analyze, which are divided into seven categories: folder-based, implements-based, composition-based, file-based, generality based, and router-based relationships. To the list of contributions, the following items could be added:(1)
A framework for extraction of relationships(2)
Introduction of enumeration is an entity(3)
Introduction of additional formal and informal relationshipsThe organization of the paper is composed of the following sections. Section2 focuses on related work. The source code entities and relationships are described in Section 3. The research methodology for the fact extraction system is described in Section 4. Section 5 discusses the experimental setup. Section 6 presents the results. Section 7 contains the outcome of the experiment as well as a discussion.


## 2. Related Work

In the literature, several fact extractor systems for extracting features from source code have been proposed. To modularize software systems, Raimond and Lovesum [8] followed Anquetil and Lethbridge employed formal and informal features. They used files, routines, classes, and processes as entities. User-defined data types, procedure calls, file inclusion, macro use, and global variables are some of the formal features mentioned. Identifiers and comments are examples of nonformal features. They focused on how to modularize structured language software systems using hierarchical clustering algorithms. They came to the conclusion that identifiers provide good design results that the file has a good expert comparison, and those comments have a good expert comparison, but that bad design results and routine calls perform poorly. The authors in [9–12] proposed a method for improving the accuracy of autonomous software architecture reconstruction. The method uses a combination of graph clustering and partitioning. They considered classes as distinct entities and created eleven relationships between them. The following relationships were discovered: inheritance, implements an interface, members (A has at least one member of type B), method parameter (A has at least one method with a parameter of type B), local variable (A has a local variable of type B in a method), returned type (A has a method that returns type B), field access (A directly accesses at least one field of type B), static method call (A calls a static method of B), object instantiation (an object of type B is instant (inside A a cast to B is done). Their focus was on object-oriented systems (java).Hussain et al. [13] adopted an agglomerative approach for clustering of structured software systems. They considered functions as entities. They took advantage of formal features like entity calling functions, global variables that entities refer to, and user-defined types that entities can access. Aghdasifam et al. [14] carried out work of software modularization using agglomerative hierarchical clustering algorithms. They targeted the structured system. They used functions as an entity. In their work, they utilized use global variables, user-specified data types, and function calls. Based on the results of the experiments, they determined that the type of feature outperforms the global and call features. Zahoor et al. [15] presented a tool called the WAFE tool (Web Application Fact Extractor) which extract features from web application. Similarly, a similar work presented by [16, 17], automate extraction dependency between web component and database resources in java web applications. The Web Page contains classes. The WAFE tool extracted the following information: a class called from a web page, a class function called from a web page, web page form submits on another web page or the same web page, web page link to another web page, web page redirect to another web page, and web page folder or directory. Custom Code Files are included in Web Pages, and Custom Code File functions are called by Web Pages. Web Pages’ classes are derived from these classes. Classes derived from Web Page classes, as well as functions of classes derived from Web page classes.Shah et al. [1] followed Abdul Qudus Abbasi’s research work carried out a detailed study about features between entities. They developed a Fact Extractor that could extract twenty-six features from the source code of object-oriented systems to extract the features. Classes, structs, unions, files, folders, global functions, global variables, and macros were all considered entities by them. Class to class relationships based on inheritance, class to class relationships based on containment, class to class relationships based on genericity, class to class relationships based on member access, class to class relationships based on source files and folders, class to class relationships based on a friend, class to global functions or data relationships or macro, and global function to global function are among relationships extracted by fact extractor. An experimental evaluation of relationships for the modularization of object-oriented software systems was reported by Thakur et al. [18]. Using Abbasi’s Fact Extractor [13], they retrieved the twenty-six features. Direct and indirect relationships were the two types of relationships. They also found that indirect relationships give better modularization results than direct relationships based on the experimental data.Aljarah et al. [19] improved on the work of Tzerpos and Andritso, who developed the LIMBO algorithm for software architecture recovery. They combined structural and nonstructural features to determine the usefulness of nonstructural features to the reverse engineering process. Developers’ names, directory paths, lines of code, and times of the last update were among the nonstructural features they examined at. The experiments revealed that directory structure and ownership information, but not lines of code, are important factors in software clustering. They also concluded that weighing schemes are useful in breaking down software systems.Krishnan preferred Koschke’s Ph.D. thesis [20] to introduce a classification of component recovery techniques. They used several features for architectural component recovery of structured systems. The features are function calls, set (subprogram sets the value of a global variable), use (subprogram uses the value of object T), take-address-of (subprogram takes the address of object T), function parameter (subprogram has a formal parameter of user-defined data type), return (subprogram returns a value of user-defined type), local-obj-of-type (subprogram has a local object of user-defined type), actual-parameter of (object is an actual parameter in a call to subprogram), of type (S is of type T, where S is an object and T is user-defined type), same-expression (S and T occur in the same expression where S and T are objects) and part-type (S is a part type of T where both S and T are user-defined types).Richner and Ducasse proposed an environment for generating high-level views of object-oriented systems from both static and dynamic information, and Alshuqayran et al. [21] followed suit. For modularization of a software system, they used composition, inheritance, invocation (method of sender invokes received method on one of the candidates), access (an attribute of class 1 is accessed by the method of class 2), and method (a class defines a method that belongs to another class) as well as dynamic features.Aljarah et al. [19] proposed MULICsoft, a software clustering algorithm. For the modularization of software systems, they exploited both static and dynamic features. Source files are the objects to be clustered. Procedure calls and variable references are static features, but dynamic features on a software system are the results of profiling the system’s execution, indicating how many times each file called procedures in other files during the run time. In 2003, Trifu [22] proposed a technique that combines clustering with pattern-matching, to automatically recover subsystem decompositions. For the clustering process, they used inheritance, association, aggregation, call, and access features. They also proposed a method for assigning weights to these relationships.Rathee and Chhabra [23] used a combination of static and dynamic features to modularize java software systems. They used inheritance, implementation, containment, calls to methods, and access to variables and assignment relationships along with dynamic features for the software modularization process. Eski and Buzluca [24] presented a comprehensive comparative study of six software clustering algorithms. They developed a lightweight C/C++ source code extractor called CTSX. CTSX is built on CTags and CScope. CTSX uses CTags to extract program entities (functions, variables, and data types) and CScope to retrieve features (function calls).Teymourian et al. [25] presented an approach for the evaluation of dynamic clustering. They used both static and dynamic features for the modularization process. For feature extraction, they used the CPPX fact extractor system. From the experimental results, they concluded that static features perform better than dynamic features. Rafi et al. [26] introduced a systematic study to categorize the critical challenges associated with best practices of software implementation for organizations and Akbar et al. [27] discussed the challenges associated with successful execution of outsource software development. Using a combined algorithm, Alanazi [28] focused on clustering software systems. Functions were considered as entities in their study, and the following features were used: function call (functions called by an entity), global variables (global variables referred to by an entity), and user-defined types (user-defined types accessed by an entity). Tjortjis [29] proposed a method for mining association rules from code in order to capture program structure and achieve a better understanding of the system. To classify code chunks as entities, they used the following characteristics: Code blocks, variables, and data types are all entitled.Yadav et al. [30] proposed an approach for analyzing Java code. They analyzed programs and built tables using a Java code analyzer. They also used a clustering engine, which works with such tables and finds relationships between code elements. They considered files, packages, classes, methods, and parameters as entities. The relationships they used in their study include entities ID, entities Name, imported packages, inheritance, implements relationship, arguments, return value, modifier, parameter type, and parameter used.Rathee and Chhabra [6, 23] followed Tonella presented an approach of using concept analysis for module reconstruction. Accesses to global variables, dynamic location accesses, the presence of a user-defined structured type in the signature, and the presence of a user-defined structured type in the return type are the relationships he used for module reconstruction.


## 3. Source Code Entities and Relationship

This section focused on entity and relationship relationships in source code. These source code entities and relationships have been created based on Java source code entities and relationships.


### 3.1. Entities in Java Source Code

Entities are the smallest significant elements at the architectural level [20]. They are part of the clustering process and become members of clusters during the automated software clustering and modularization process [1]. The proposed “FESJA” extracted three types of entities, these types are classes, interfaces, and enumerations.A class and an interface can be an entity in object-oriented systems, it has been used widely in software architecture reconstruction and recovery [1, 4]. The approach used by [9] helps to create basic, fully automated tools that can help detect the core classes of a software system based on its code. The study done by [22] used a Model-Driven Engineering technique to provide support for Micro Service Architecture Recovery (MiSAR). In their work, they described an empirical study that uses manual analysis on eight microservice-based open-source projects to identify the core elements of the approach. The research helps software developers and maintainers in taking steps at the design level to create maintainable object-oriented software with classes [22, 23, 31]. “An enum type is a form of data that allows a variable to be a set of specified constants.” Enums are java reference types, much as classes. We can add methods, variables, and constructors to an enum in the same way that we would in a regular Java class of Java beat version issued in 2013.


### 3.2. Relationships

Similarities between entities are always calculated during the modularization process based on their connections. It establishes links between the application’s entities. However, the first step is to analyze feature extraction; afterward when, we applied clustering to group entities with similar features or attributes [15]. The relationship types extracted by the proposed fact extractor system, a java-based system, have been identified. Static, dynamic, informal, direct, and indirect relationships are examples of these types of relationships.


## 3.1. Entities in Java Source Code

Entities are the smallest significant elements at the architectural level [20]. They are part of the clustering process and become members of clusters during the automated software clustering and modularization process [1]. The proposed “FESJA” extracted three types of entities, these types are classes, interfaces, and enumerations.A class and an interface can be an entity in object-oriented systems, it has been used widely in software architecture reconstruction and recovery [1, 4]. The approach used by [9] helps to create basic, fully automated tools that can help detect the core classes of a software system based on its code. The study done by [22] used a Model-Driven Engineering technique to provide support for Micro Service Architecture Recovery (MiSAR). In their work, they described an empirical study that uses manual analysis on eight microservice-based open-source projects to identify the core elements of the approach. The research helps software developers and maintainers in taking steps at the design level to create maintainable object-oriented software with classes [22, 23, 31]. “An enum type is a form of data that allows a variable to be a set of specified constants.” Enums are java reference types, much as classes. We can add methods, variables, and constructors to an enum in the same way that we would in a regular Java class of Java beat version issued in 2013.


## 3.2. Relationships

Similarities between entities are always calculated during the modularization process based on their connections. It establishes links between the application’s entities. However, the first step is to analyze feature extraction; afterward when, we applied clustering to group entities with similar features or attributes [15]. The relationship types extracted by the proposed fact extractor system, a java-based system, have been identified. Static, dynamic, informal, direct, and indirect relationships are examples of these types of relationships.


## 4. The Research Methodology of Fact Extraction System

The proposed methodology uses low-level artifacts (source code) to build high-level (abstract views) of the software system in the form of a Java-based Fact Extractor System. Extraction of features is the first stage in modularization, and FESJA has utilized an API namedjava.util.regex to search for necessary parts (approximated approach). Regular expressions were utilized to match patterns in this Java API. FESJA has extracted three categories of entities, as follows:The regular expression above can be used to extract a class myClass{, class myClass {, class myClass<.For the extraction of interfaces, the below regular expression is used.The regular expression above, for example, can retrieve interface myInt {, interface myInt{, interface myInt<.The enumerations are extracted using a regular expression.The regular expression above, for example, can extract the enum myEnum.The Process of fact extraction in FESJA starts with some data being uploaded, folders being extracted, and folder names that are alike being removed. After the extraction process of FESJA, the system check whether the source folder (src) exists or not. The process will end if there is no src folder. The same entity names are removed if the src file exists. Figure1 shows the whole process of the fact extraction system, whereas Figure 2 shows entities with relationships.Figure 1
Process of fact extraction.Figure 2
Process of Relationship extraction.


## 5. Experimental Setup

The experiments are conducted using data sets to evaluate the relationships. These datasets are being designed and implemented using java (object-oriented methodology). JFree Chart (an open-source library for graphs and charts), JUnit (an open-source java unit testing framework), and Weka (an open-source java testing framework) compensate our dataset (Machine learning algorithm for data mining tasks). All these datasets are taken from Github and the source (https://www.grepcode.com). Entities identified by the FESJA tool in the above systems are shown below in Tables 1–4Table 1
Facts about entities in iText dataset.
Entity related informationiText 1.3iText 1.4iText 1.4.8iText 2.1.7Total no. of folders29323469Total no. of files399470502549Total no. of entities462545586669Total no. of classes434513551625Total no. of interfaces28323544Total no. of enumerations0000Total no. of functions in application5330619565177029Total no. of functions in class5258611764316905Total no. of functions in interface727886124Total no. of functions in enum0000sLOC76100868589052694073Blank lines12283138021465514811LOC88383100660105181108884Size in bytes4938428570408161039676696336Table 2
Facts about entities in JFreeChart dataset.
Entity related informationJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Total no. of folders61393940Total no. of files500538538594Total no. of entities516559559616Total no. of classes432468468510Total no. of interfaces849191106Total no. of enumerations0000Total no. of functions in application6705746875228629Total no. of functions in class6209695270068086Total no. of functions in interface496516516561Total no. of functions in enum0000sLOC73148810038149093430Blank lines16149176151767019332LOC892979861899160112762Size in bytes6029995672263867746697700413Table 3
Facts about entities in Junit dataset.
Entity related informationJunit 4.8Junit 4.9Junit 4.10Junit 4.11Total no. of folders33313131Total no. of files175160162164Total no. of entities180165168171Total no. of classes148134137137Total no. of interfaces32303032Total no. of enumerations0112Total no. of functions in application1079101310361143Total no. of functions in class10399729951099Total no. of functions in interface40323233Total no. of functions in enum09911sLOC6727642965797439Blank lines1466134813811603LOC8193777779609042Size in bytes340192330167338458429090Table 4
Facts about entities in weka dataset.
Entity related informationWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Total no. of folders878889110Total no. of files1005102010251050Total no. of entities1352137813841379Total no. of classes1162118511901236Total no. of interfaces149151152119Total no. of enumerations41424224Total no. of functions in application17114175011761818746Total no. of functions in class16513168961700618273Total no. of functions in interface427431438336Total no. of functions in enum174174174137sLOC232297237797240029255774Blank lines54985563195663361449LOC287282294116296662317223Size in bytes13586516138280491394062015213130


### 5.1. Comparative Analysis of Intradataset

This study explores the results of multiple versions of the same data set.


#### 5.1.1. iText

The statistics of the iText software system are shown in Tables5–9. It has been concluded from the statistics that:(i)
Class is the most important entity in the iText software system, and enumerations are not utilized at all(ii)
Folder-based relationships, composition-based relationships, and access-based relationships are the most common relations for classes(iii)
In comparison to file-based and access-based relationships, folder-based relationships occur frequently in interfaces(iv)
Generic or outer implement relationships are not used in the iText software system(v)
Figures3 and 4 illustrate those formal relationships in iText are based on formal relationships of classes, while formal relationships of interfaces contribute to just 3% of formal relationshipsTable 5
Entities in iText.
iText 1.3iText 1.4iText 1.4.8iText 2.1.7Classes434513551625Interfaces28323544Enumerations0000Table 6
Formal and informal relationship in iText.
iText 1.3iText 1.4iText 1.4.8iText 2.1.7Informal43107494745248858601Formal70808587912511245Table 7
Formal relationship in iText.
Formal relationshipsiText 1.3iText 1.4iText 1.4.8iText 2.1.7Formal relationships for class68788350886610849FormalRelationships f or interface202237259396FormalRelationships for enum0000Table 8
Formal relationships for class in iText.
Formal relationships for classiText 1.3iText 1.4iText 1.4.8iText 2.1.7Folder-based relationships2228264328593958File-based relationships434513551625Inheritance-based relationships680833871839Implements-based relationships171203208213Composition-based relationships2115268928473312Generics-based relationships0000Access-based relationships1122131813581630Inner-based relationships646978119Outer inheritance-based relationships14141725Outer implements-based relationships0000Outer composition-based relationships506877128Table 9
Formal relationships for interface in iText.
Formal relationships for interfaceiText 1.3iText 1.4iText 1.4.8iText 2.1.7Folder-based relationships140164182283File-based relationships28323544Extends-based relationships66612Generics-based relationships0000Composition-based relationships0000Access-based relationships28353657Inner-based relationships0000Outer extends relationships0000Outer composition relationships0000Figure 3
Count of formal and informal relationships in iText.Figure 4
Count of formal relationships in iText.Figures3–7 providegraphical representations of iText software system statistics.Figure 5
Count of entities in iText.Figure 6
Count of formal relationships for class in iText.Figure 7
Count of formal relationships for interface in iText.


#### 5.1.2. JFreeChart

Tables10–14 summarizes statistics of the JFreeChart software system. From the statistics, it has been observed that.(i)
Like iText the most dominant entity in the JFreeChart software system is class while enumerations are not used at all.(ii)
The dominant relationships for classes are folder-based relationships, composition-based relationships, and access-based relationships while implements-based relationships and inheritance-based relationships have also good frequency.(iii)
For interfaces the used relationships are folder-based, file-based, extend based and access-based relationships while other relationships are infrequent. Also, among used relationships, folder-based relationships have the highest frequency.(iv)
Same as iText generics-based relationships and outer implements-based relationships are not used in the JFreeChart software system.(v)
By comparing Figures8 and 9 it can be calculated that in JFreeChart 92% of formal relationships are based on formal relationships of classes while 8% of formal relationships are based on formal relationships of interfaces.Table 10
Entities in JFreeChart.
EntitiesJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Classes432468468510Interfaces849191106Enumerations0000Table 11
Formal and informal relationships in JFreeChart.
RelationshipsJFreeChart 1.0.4JfreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Informal48877538625410561294Formal83219059905810056Table 12
Formal relationships in JFreeChart.
Formal relationshipsJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Formal relationships for class7636831483139196Formal relationships for interface685745745860Formal relationships for enum0000Table 13
Formal relationships for class in JFreeChart.
Formal relationships for classJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Folder-based relationships2184238523852599File-based relationships432468468510Inheritance-based relationships8169179171013Implements-based relationships8979709701052Composition-based relationships2069223422332514Generics-based relationships0000Access-based relationships1217130813081475Inner-based relationships14191920Outer inheritance-based relationships2333Outer implements-based relationships0000Outer composition-based relationships5101010Table 14
Formal relationships for interface in JFreeChart.
Formal relationships for interfaceJfreeChart 1.0.4JFreeChart 1.0.7JfreeChart 1.0.9JFreeChart 1.0.14Folder-based relationships411450450526File-based relationships849191106Extends-based relationships81919195Generics-based relationships0000Composition-based relationships0000Access-based relationships109113113133Inner-based relationships0000Outer extends relationships0000Outer composition relationships0000Figure 8
Count number of formal and informal relationships in JfreeChart.Figure 9
Count number of formal relationships in JfreeChart.Figures8–12 provides a graphical representation of statistics of the JFreeChart software system.Figure 10
Count of entities in JfreeChart.Figure 11
Count number of formal relationships for class in JfreeChart.Figure 12
Count number of formal relationships for interface in JfreeChart.Due to the absence of enumerations, no relationships for enumeration exist in the JFreeChart software system.


#### 5.1.3. JUnit

Tables15–20 summarizes the statistics of a JUnit software system. From the statistics, it has been observed that.(i)
In the JUnit software system enumerations are introduced in all versions except JUnit 4.8 but have a very low frequency of occurrence.(ii)
For classes the most used relationships are folder-based relationships while access-based relationships, implements-based relationships, inheritance-based relationships, and file-based relationships have a good frequency of occurrence.(iii)
For interfaces outer extends-based relationships, outer composition-based relationships, and composition-based relationships are not used while extends-based relationships are only used in JUnit 4.8. Also, among used relationships, folder-based relationships have the highest frequency of occurrence.(iv)
Generics bases relationships have been introduced for classes and interfaces.(v)
The used relationships in enumerations are folder-based, file-based, and access relationships while composition-based relationships are only used in JUnit 4.11. Among them, the dominant relationship is folder-based relation.(vi)
By comparing Figures13 and 14 it can be calculated that in JUnit 89% of formal relationships are based on formal relationships of classes while 10% of formal relationships are based on formal relationships of interfaces. Similarly, formal relationships in JUnit 4.9, JUnit 4.10, and JUnit 4.11 are based on 0.57%, 0.55%, and 0.92% of formal relationships of enumerations respectively.Table 15
Entities in Junit.
EntitiesJunit 4.8Junit 4.9Junit 4.10Junit 4.11Classes148134137137Interfaces32303032Enumerations0112Table 16
Formal and informal relationships in Junit.
RelationshipsJunit 4.8Junit 4.9Junit 4.10Junit 4.11Informal6616617162866705Formal1746157216091629Table 17
Formal relationships in Junit.
Formal relationshipsJunit 4.8Junit 4.9Junit 4.10Junit 4.11Formal relationships for class1568139914361441Formal relationships for interface178164164173Formal relationships for enum09915Table 18
Formal relationships for class in Junit.
Formal relationships for classJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships653602617615File-based relationships148134137137Inheritance-based relationships161153154157Implements-based relationships35303434Composition-based relationships207178182188Generics-based relationships19141414Access-based relationships320262270265Inner-based relationships16161718Outer inheritance-based relationships0000Outer implements-based relationships0000Outer composition-based relationships9101113Table 19
Formal relationships for interface in Junit.
Formal relationships for interfaceJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships125120120127File-based relationships32303032Extends-based relationships1000Generics-based relationships3111Composition-based relationships0000Access-based relationships15121212Inner-based relationships2111Outer extends relationships0000Outer composition relationships0000Table 20
Formal relationships for enum in Junit.
Formal relationships for enumerationJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships06610File-based relationships0112Implements-based relationships0000Composition-based relationships0001Genericity-based relationships0000Access-based relationships0222Outer implements relationships0000Figure 13
Count of formal and informal relationships in Junit.Figure 14
Count of formal relationships in Junit.Figures15–18 provide a graphical representation of statistics of a Junit software system.Figure 15
Count of entities in Junit.Figure 16
Count of formal relationships for class in Junit.Figure 17
Count of formal relationships for interface in Junit.Figure 18
Count of formal relationships for enum in junit.


#### 5.1.4. Weka

Table21–26 summarizes the statistics of the Weka software system. From the statistics, it has been observed that.(i)
In the Weka software system the dominant entity is class while enumerations have a low frequency of occurrence.(ii)
For classes composition-based relationships are the most dominant relationships. Other relationships having a good frequency of occurrence are folder-based and access-based relationships.(iii)
Folder-based relationships, file-based relationships, and access-based relationships have a high frequency of occurrence in interfaces while other relationships are either have a very low frequency of occurrence or not used at all. Among used relationships, folder-based relationships have the highest frequency.(iv)
Generics-based relationships are used in classes and interfaces but have very low usage.(v)
Like JUnit the used relationships in enumerations are folder-based, file-based, access relationships, and composition-based relationships. Among them, the dominant relationship is folder-based relation. Access-based and composition-based relationships have the same frequency of occurrence.(vi)
By comparing Figures19 and 20, it can be calculated that in Weka 95% of formal relationships are based on formal relationships of classes, 4% of formal relationships are based on formal relationships of interfaces and, 1% of formal relationships are based on formal relationships of enumerations.Table 21
Entities in weka.
EntitiesWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Classes1162118511901236Interfaces149151152119Enumerations41424224Table 22
Formal and informal relationships in weka.
RelationshipsWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Informal124080129103129948136926Formal20358208472093222695Table 23
Formal relationships in weka.
Formal relationshipsWeka-dev 3.7.5Weka-dev 3.7.6Weka- dev 3.7.7Weka-stable 3.6.6Formal relationships for class19250197201980021852Formal relationships for interface887900905720Formal relationships for enum221227227123Table 24
Formal relationships for class in weka.
Formal relationships for classWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships4705479448165003File-based relationships1162118511901236Inheritance-based relationships1955197619842141Implements-based relationships1532159516041697Composition-based relationships6289645764827671Generics-based relationships810106Access-based relationships2775285828683300Inner-based relationships357368369335Outer inheritance-based relationships97979778Outer implements-based relationships1414146Outer composition-based relationships356366366379Table 25
Formal relationships for interface in weka.
Formal relationships for interfaceWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships556563566442File-based relationships149151152119Extends-based relationships43454540Generics-based relationships6776Composition-based relationships0000Access-based relationships132133134113Inner-based relationships1110Outer extends relationships0000Outer composition relationships0000Table 26
Formal relationships for enum in weka.
Formal relationships for enumerationWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships17618118199File-based relationships41424224Implements-based relationships0000Composition-based relationships2220Genericity-based relationships0000Access-based relationships2220Outer implements relationships0000Figure 19
Count of entities in weka.Figure 20
Count of formal and informal relationships in weka.Figures19–24 provide a graphical representation of statistics of the Weka software system.Figure 21
Count of formal relationships in weka.Figure 22
Count of formal relationships for class in weka.Figure 23
Count of formal relationships for interface in weka.Figure 24
Count of formal relationships for enum in weka.


## 5.1. Comparative Analysis of Intradataset

This study explores the results of multiple versions of the same data set.


### 5.1.1. iText

The statistics of the iText software system are shown in Tables5–9. It has been concluded from the statistics that:(i)
Class is the most important entity in the iText software system, and enumerations are not utilized at all(ii)
Folder-based relationships, composition-based relationships, and access-based relationships are the most common relations for classes(iii)
In comparison to file-based and access-based relationships, folder-based relationships occur frequently in interfaces(iv)
Generic or outer implement relationships are not used in the iText software system(v)
Figures3 and 4 illustrate those formal relationships in iText are based on formal relationships of classes, while formal relationships of interfaces contribute to just 3% of formal relationshipsTable 5
Entities in iText.
iText 1.3iText 1.4iText 1.4.8iText 2.1.7Classes434513551625Interfaces28323544Enumerations0000Table 6
Formal and informal relationship in iText.
iText 1.3iText 1.4iText 1.4.8iText 2.1.7Informal43107494745248858601Formal70808587912511245Table 7
Formal relationship in iText.
Formal relationshipsiText 1.3iText 1.4iText 1.4.8iText 2.1.7Formal relationships for class68788350886610849FormalRelationships f or interface202237259396FormalRelationships for enum0000Table 8
Formal relationships for class in iText.
Formal relationships for classiText 1.3iText 1.4iText 1.4.8iText 2.1.7Folder-based relationships2228264328593958File-based relationships434513551625Inheritance-based relationships680833871839Implements-based relationships171203208213Composition-based relationships2115268928473312Generics-based relationships0000Access-based relationships1122131813581630Inner-based relationships646978119Outer inheritance-based relationships14141725Outer implements-based relationships0000Outer composition-based relationships506877128Table 9
Formal relationships for interface in iText.
Formal relationships for interfaceiText 1.3iText 1.4iText 1.4.8iText 2.1.7Folder-based relationships140164182283File-based relationships28323544Extends-based relationships66612Generics-based relationships0000Composition-based relationships0000Access-based relationships28353657Inner-based relationships0000Outer extends relationships0000Outer composition relationships0000Figure 3
Count of formal and informal relationships in iText.Figure 4
Count of formal relationships in iText.Figures3–7 providegraphical representations of iText software system statistics.Figure 5
Count of entities in iText.Figure 6
Count of formal relationships for class in iText.Figure 7
Count of formal relationships for interface in iText.


### 5.1.2. JFreeChart

Tables10–14 summarizes statistics of the JFreeChart software system. From the statistics, it has been observed that.(i)
Like iText the most dominant entity in the JFreeChart software system is class while enumerations are not used at all.(ii)
The dominant relationships for classes are folder-based relationships, composition-based relationships, and access-based relationships while implements-based relationships and inheritance-based relationships have also good frequency.(iii)
For interfaces the used relationships are folder-based, file-based, extend based and access-based relationships while other relationships are infrequent. Also, among used relationships, folder-based relationships have the highest frequency.(iv)
Same as iText generics-based relationships and outer implements-based relationships are not used in the JFreeChart software system.(v)
By comparing Figures8 and 9 it can be calculated that in JFreeChart 92% of formal relationships are based on formal relationships of classes while 8% of formal relationships are based on formal relationships of interfaces.Table 10
Entities in JFreeChart.
EntitiesJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Classes432468468510Interfaces849191106Enumerations0000Table 11
Formal and informal relationships in JFreeChart.
RelationshipsJFreeChart 1.0.4JfreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Informal48877538625410561294Formal83219059905810056Table 12
Formal relationships in JFreeChart.
Formal relationshipsJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Formal relationships for class7636831483139196Formal relationships for interface685745745860Formal relationships for enum0000Table 13
Formal relationships for class in JFreeChart.
Formal relationships for classJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Folder-based relationships2184238523852599File-based relationships432468468510Inheritance-based relationships8169179171013Implements-based relationships8979709701052Composition-based relationships2069223422332514Generics-based relationships0000Access-based relationships1217130813081475Inner-based relationships14191920Outer inheritance-based relationships2333Outer implements-based relationships0000Outer composition-based relationships5101010Table 14
Formal relationships for interface in JFreeChart.
Formal relationships for interfaceJfreeChart 1.0.4JFreeChart 1.0.7JfreeChart 1.0.9JFreeChart 1.0.14Folder-based relationships411450450526File-based relationships849191106Extends-based relationships81919195Generics-based relationships0000Composition-based relationships0000Access-based relationships109113113133Inner-based relationships0000Outer extends relationships0000Outer composition relationships0000Figure 8
Count number of formal and informal relationships in JfreeChart.Figure 9
Count number of formal relationships in JfreeChart.Figures8–12 provides a graphical representation of statistics of the JFreeChart software system.Figure 10
Count of entities in JfreeChart.Figure 11
Count number of formal relationships for class in JfreeChart.Figure 12
Count number of formal relationships for interface in JfreeChart.Due to the absence of enumerations, no relationships for enumeration exist in the JFreeChart software system.


### 5.1.3. JUnit

Tables15–20 summarizes the statistics of a JUnit software system. From the statistics, it has been observed that.(i)
In the JUnit software system enumerations are introduced in all versions except JUnit 4.8 but have a very low frequency of occurrence.(ii)
For classes the most used relationships are folder-based relationships while access-based relationships, implements-based relationships, inheritance-based relationships, and file-based relationships have a good frequency of occurrence.(iii)
For interfaces outer extends-based relationships, outer composition-based relationships, and composition-based relationships are not used while extends-based relationships are only used in JUnit 4.8. Also, among used relationships, folder-based relationships have the highest frequency of occurrence.(iv)
Generics bases relationships have been introduced for classes and interfaces.(v)
The used relationships in enumerations are folder-based, file-based, and access relationships while composition-based relationships are only used in JUnit 4.11. Among them, the dominant relationship is folder-based relation.(vi)
By comparing Figures13 and 14 it can be calculated that in JUnit 89% of formal relationships are based on formal relationships of classes while 10% of formal relationships are based on formal relationships of interfaces. Similarly, formal relationships in JUnit 4.9, JUnit 4.10, and JUnit 4.11 are based on 0.57%, 0.55%, and 0.92% of formal relationships of enumerations respectively.Table 15
Entities in Junit.
EntitiesJunit 4.8Junit 4.9Junit 4.10Junit 4.11Classes148134137137Interfaces32303032Enumerations0112Table 16
Formal and informal relationships in Junit.
RelationshipsJunit 4.8Junit 4.9Junit 4.10Junit 4.11Informal6616617162866705Formal1746157216091629Table 17
Formal relationships in Junit.
Formal relationshipsJunit 4.8Junit 4.9Junit 4.10Junit 4.11Formal relationships for class1568139914361441Formal relationships for interface178164164173Formal relationships for enum09915Table 18
Formal relationships for class in Junit.
Formal relationships for classJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships653602617615File-based relationships148134137137Inheritance-based relationships161153154157Implements-based relationships35303434Composition-based relationships207178182188Generics-based relationships19141414Access-based relationships320262270265Inner-based relationships16161718Outer inheritance-based relationships0000Outer implements-based relationships0000Outer composition-based relationships9101113Table 19
Formal relationships for interface in Junit.
Formal relationships for interfaceJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships125120120127File-based relationships32303032Extends-based relationships1000Generics-based relationships3111Composition-based relationships0000Access-based relationships15121212Inner-based relationships2111Outer extends relationships0000Outer composition relationships0000Table 20
Formal relationships for enum in Junit.
Formal relationships for enumerationJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships06610File-based relationships0112Implements-based relationships0000Composition-based relationships0001Genericity-based relationships0000Access-based relationships0222Outer implements relationships0000Figure 13
Count of formal and informal relationships in Junit.Figure 14
Count of formal relationships in Junit.Figures15–18 provide a graphical representation of statistics of a Junit software system.Figure 15
Count of entities in Junit.Figure 16
Count of formal relationships for class in Junit.Figure 17
Count of formal relationships for interface in Junit.Figure 18
Count of formal relationships for enum in junit.


### 5.1.4. Weka

Table21–26 summarizes the statistics of the Weka software system. From the statistics, it has been observed that.(i)
In the Weka software system the dominant entity is class while enumerations have a low frequency of occurrence.(ii)
For classes composition-based relationships are the most dominant relationships. Other relationships having a good frequency of occurrence are folder-based and access-based relationships.(iii)
Folder-based relationships, file-based relationships, and access-based relationships have a high frequency of occurrence in interfaces while other relationships are either have a very low frequency of occurrence or not used at all. Among used relationships, folder-based relationships have the highest frequency.(iv)
Generics-based relationships are used in classes and interfaces but have very low usage.(v)
Like JUnit the used relationships in enumerations are folder-based, file-based, access relationships, and composition-based relationships. Among them, the dominant relationship is folder-based relation. Access-based and composition-based relationships have the same frequency of occurrence.(vi)
By comparing Figures19 and 20, it can be calculated that in Weka 95% of formal relationships are based on formal relationships of classes, 4% of formal relationships are based on formal relationships of interfaces and, 1% of formal relationships are based on formal relationships of enumerations.Table 21
Entities in weka.
EntitiesWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Classes1162118511901236Interfaces149151152119Enumerations41424224Table 22
Formal and informal relationships in weka.
RelationshipsWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Informal124080129103129948136926Formal20358208472093222695Table 23
Formal relationships in weka.
Formal relationshipsWeka-dev 3.7.5Weka-dev 3.7.6Weka- dev 3.7.7Weka-stable 3.6.6Formal relationships for class19250197201980021852Formal relationships for interface887900905720Formal relationships for enum221227227123Table 24
Formal relationships for class in weka.
Formal relationships for classWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships4705479448165003File-based relationships1162118511901236Inheritance-based relationships1955197619842141Implements-based relationships1532159516041697Composition-based relationships6289645764827671Generics-based relationships810106Access-based relationships2775285828683300Inner-based relationships357368369335Outer inheritance-based relationships97979778Outer implements-based relationships1414146Outer composition-based relationships356366366379Table 25
Formal relationships for interface in weka.
Formal relationships for interfaceWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships556563566442File-based relationships149151152119Extends-based relationships43454540Generics-based relationships6776Composition-based relationships0000Access-based relationships132133134113Inner-based relationships1110Outer extends relationships0000Outer composition relationships0000Table 26
Formal relationships for enum in weka.
Formal relationships for enumerationWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships17618118199File-based relationships41424224Implements-based relationships0000Composition-based relationships2220Genericity-based relationships0000Access-based relationships2220Outer implements relationships0000Figure 19
Count of entities in weka.Figure 20
Count of formal and informal relationships in weka.Figures19–24 provide a graphical representation of statistics of the Weka software system.Figure 21
Count of formal relationships in weka.Figure 22
Count of formal relationships for class in weka.Figure 23
Count of formal relationships for interface in weka.Figure 24
Count of formal relationships for enum in weka.


## 5.1.1. iText

The statistics of the iText software system are shown in Tables5–9. It has been concluded from the statistics that:(i)
Class is the most important entity in the iText software system, and enumerations are not utilized at all(ii)
Folder-based relationships, composition-based relationships, and access-based relationships are the most common relations for classes(iii)
In comparison to file-based and access-based relationships, folder-based relationships occur frequently in interfaces(iv)
Generic or outer implement relationships are not used in the iText software system(v)
Figures3 and 4 illustrate those formal relationships in iText are based on formal relationships of classes, while formal relationships of interfaces contribute to just 3% of formal relationshipsTable 5
Entities in iText.
iText 1.3iText 1.4iText 1.4.8iText 2.1.7Classes434513551625Interfaces28323544Enumerations0000Table 6
Formal and informal relationship in iText.
iText 1.3iText 1.4iText 1.4.8iText 2.1.7Informal43107494745248858601Formal70808587912511245Table 7
Formal relationship in iText.
Formal relationshipsiText 1.3iText 1.4iText 1.4.8iText 2.1.7Formal relationships for class68788350886610849FormalRelationships f or interface202237259396FormalRelationships for enum0000Table 8
Formal relationships for class in iText.
Formal relationships for classiText 1.3iText 1.4iText 1.4.8iText 2.1.7Folder-based relationships2228264328593958File-based relationships434513551625Inheritance-based relationships680833871839Implements-based relationships171203208213Composition-based relationships2115268928473312Generics-based relationships0000Access-based relationships1122131813581630Inner-based relationships646978119Outer inheritance-based relationships14141725Outer implements-based relationships0000Outer composition-based relationships506877128Table 9
Formal relationships for interface in iText.
Formal relationships for interfaceiText 1.3iText 1.4iText 1.4.8iText 2.1.7Folder-based relationships140164182283File-based relationships28323544Extends-based relationships66612Generics-based relationships0000Composition-based relationships0000Access-based relationships28353657Inner-based relationships0000Outer extends relationships0000Outer composition relationships0000Figure 3
Count of formal and informal relationships in iText.Figure 4
Count of formal relationships in iText.Figures3–7 providegraphical representations of iText software system statistics.Figure 5
Count of entities in iText.Figure 6
Count of formal relationships for class in iText.Figure 7
Count of formal relationships for interface in iText.


## 5.1.2. JFreeChart

Tables10–14 summarizes statistics of the JFreeChart software system. From the statistics, it has been observed that.(i)
Like iText the most dominant entity in the JFreeChart software system is class while enumerations are not used at all.(ii)
The dominant relationships for classes are folder-based relationships, composition-based relationships, and access-based relationships while implements-based relationships and inheritance-based relationships have also good frequency.(iii)
For interfaces the used relationships are folder-based, file-based, extend based and access-based relationships while other relationships are infrequent. Also, among used relationships, folder-based relationships have the highest frequency.(iv)
Same as iText generics-based relationships and outer implements-based relationships are not used in the JFreeChart software system.(v)
By comparing Figures8 and 9 it can be calculated that in JFreeChart 92% of formal relationships are based on formal relationships of classes while 8% of formal relationships are based on formal relationships of interfaces.Table 10
Entities in JFreeChart.
EntitiesJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Classes432468468510Interfaces849191106Enumerations0000Table 11
Formal and informal relationships in JFreeChart.
RelationshipsJFreeChart 1.0.4JfreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Informal48877538625410561294Formal83219059905810056Table 12
Formal relationships in JFreeChart.
Formal relationshipsJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Formal relationships for class7636831483139196Formal relationships for interface685745745860Formal relationships for enum0000Table 13
Formal relationships for class in JFreeChart.
Formal relationships for classJFreeChart 1.0.4JFreeChart 1.0.7JFreeChart 1.0.9JFreeChart 1.0.14Folder-based relationships2184238523852599File-based relationships432468468510Inheritance-based relationships8169179171013Implements-based relationships8979709701052Composition-based relationships2069223422332514Generics-based relationships0000Access-based relationships1217130813081475Inner-based relationships14191920Outer inheritance-based relationships2333Outer implements-based relationships0000Outer composition-based relationships5101010Table 14
Formal relationships for interface in JFreeChart.
Formal relationships for interfaceJfreeChart 1.0.4JFreeChart 1.0.7JfreeChart 1.0.9JFreeChart 1.0.14Folder-based relationships411450450526File-based relationships849191106Extends-based relationships81919195Generics-based relationships0000Composition-based relationships0000Access-based relationships109113113133Inner-based relationships0000Outer extends relationships0000Outer composition relationships0000Figure 8
Count number of formal and informal relationships in JfreeChart.Figure 9
Count number of formal relationships in JfreeChart.Figures8–12 provides a graphical representation of statistics of the JFreeChart software system.Figure 10
Count of entities in JfreeChart.Figure 11
Count number of formal relationships for class in JfreeChart.Figure 12
Count number of formal relationships for interface in JfreeChart.Due to the absence of enumerations, no relationships for enumeration exist in the JFreeChart software system.


## 5.1.3. JUnit

Tables15–20 summarizes the statistics of a JUnit software system. From the statistics, it has been observed that.(i)
In the JUnit software system enumerations are introduced in all versions except JUnit 4.8 but have a very low frequency of occurrence.(ii)
For classes the most used relationships are folder-based relationships while access-based relationships, implements-based relationships, inheritance-based relationships, and file-based relationships have a good frequency of occurrence.(iii)
For interfaces outer extends-based relationships, outer composition-based relationships, and composition-based relationships are not used while extends-based relationships are only used in JUnit 4.8. Also, among used relationships, folder-based relationships have the highest frequency of occurrence.(iv)
Generics bases relationships have been introduced for classes and interfaces.(v)
The used relationships in enumerations are folder-based, file-based, and access relationships while composition-based relationships are only used in JUnit 4.11. Among them, the dominant relationship is folder-based relation.(vi)
By comparing Figures13 and 14 it can be calculated that in JUnit 89% of formal relationships are based on formal relationships of classes while 10% of formal relationships are based on formal relationships of interfaces. Similarly, formal relationships in JUnit 4.9, JUnit 4.10, and JUnit 4.11 are based on 0.57%, 0.55%, and 0.92% of formal relationships of enumerations respectively.Table 15
Entities in Junit.
EntitiesJunit 4.8Junit 4.9Junit 4.10Junit 4.11Classes148134137137Interfaces32303032Enumerations0112Table 16
Formal and informal relationships in Junit.
RelationshipsJunit 4.8Junit 4.9Junit 4.10Junit 4.11Informal6616617162866705Formal1746157216091629Table 17
Formal relationships in Junit.
Formal relationshipsJunit 4.8Junit 4.9Junit 4.10Junit 4.11Formal relationships for class1568139914361441Formal relationships for interface178164164173Formal relationships for enum09915Table 18
Formal relationships for class in Junit.
Formal relationships for classJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships653602617615File-based relationships148134137137Inheritance-based relationships161153154157Implements-based relationships35303434Composition-based relationships207178182188Generics-based relationships19141414Access-based relationships320262270265Inner-based relationships16161718Outer inheritance-based relationships0000Outer implements-based relationships0000Outer composition-based relationships9101113Table 19
Formal relationships for interface in Junit.
Formal relationships for interfaceJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships125120120127File-based relationships32303032Extends-based relationships1000Generics-based relationships3111Composition-based relationships0000Access-based relationships15121212Inner-based relationships2111Outer extends relationships0000Outer composition relationships0000Table 20
Formal relationships for enum in Junit.
Formal relationships for enumerationJunit 4.8Junit 4.9Junit 4.10Junit 4.11Folder-based relationships06610File-based relationships0112Implements-based relationships0000Composition-based relationships0001Genericity-based relationships0000Access-based relationships0222Outer implements relationships0000Figure 13
Count of formal and informal relationships in Junit.Figure 14
Count of formal relationships in Junit.Figures15–18 provide a graphical representation of statistics of a Junit software system.Figure 15
Count of entities in Junit.Figure 16
Count of formal relationships for class in Junit.Figure 17
Count of formal relationships for interface in Junit.Figure 18
Count of formal relationships for enum in junit.


## 5.1.4. Weka

Table21–26 summarizes the statistics of the Weka software system. From the statistics, it has been observed that.(i)
In the Weka software system the dominant entity is class while enumerations have a low frequency of occurrence.(ii)
For classes composition-based relationships are the most dominant relationships. Other relationships having a good frequency of occurrence are folder-based and access-based relationships.(iii)
Folder-based relationships, file-based relationships, and access-based relationships have a high frequency of occurrence in interfaces while other relationships are either have a very low frequency of occurrence or not used at all. Among used relationships, folder-based relationships have the highest frequency.(iv)
Generics-based relationships are used in classes and interfaces but have very low usage.(v)
Like JUnit the used relationships in enumerations are folder-based, file-based, access relationships, and composition-based relationships. Among them, the dominant relationship is folder-based relation. Access-based and composition-based relationships have the same frequency of occurrence.(vi)
By comparing Figures19 and 20, it can be calculated that in Weka 95% of formal relationships are based on formal relationships of classes, 4% of formal relationships are based on formal relationships of interfaces and, 1% of formal relationships are based on formal relationships of enumerations.Table 21
Entities in weka.
EntitiesWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Classes1162118511901236Interfaces149151152119Enumerations41424224Table 22
Formal and informal relationships in weka.
RelationshipsWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable 3.6.6Informal124080129103129948136926Formal20358208472093222695Table 23
Formal relationships in weka.
Formal relationshipsWeka-dev 3.7.5Weka-dev 3.7.6Weka- dev 3.7.7Weka-stable 3.6.6Formal relationships for class19250197201980021852Formal relationships for interface887900905720Formal relationships for enum221227227123Table 24
Formal relationships for class in weka.
Formal relationships for classWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships4705479448165003File-based relationships1162118511901236Inheritance-based relationships1955197619842141Implements-based relationships1532159516041697Composition-based relationships6289645764827671Generics-based relationships810106Access-based relationships2775285828683300Inner-based relationships357368369335Outer inheritance-based relationships97979778Outer implements-based relationships1414146Outer composition-based relationships356366366379Table 25
Formal relationships for interface in weka.
Formal relationships for interfaceWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships556563566442File-based relationships149151152119Extends-based relationships43454540Generics-based relationships6776Composition-based relationships0000Access-based relationships132133134113Inner-based relationships1110Outer extends relationships0000Outer composition relationships0000Table 26
Formal relationships for enum in weka.
Formal relationships for enumerationWeka-dev 3.7.5Weka-dev 3.7.6Weka-dev 3.7.7Weka-stable3.6.6Folder-based relationships17618118199File-based relationships41424224Implements-based relationships0000Composition-based relationships2220Genericity-based relationships0000Access-based relationships2220Outer implements relationships0000Figure 19
Count of entities in weka.Figure 20
Count of formal and informal relationships in weka.Figures19–24 provide a graphical representation of statistics of the Weka software system.Figure 21
Count of formal relationships in weka.Figure 22
Count of formal relationships for class in weka.Figure 23
Count of formal relationships for interface in weka.Figure 24
Count of formal relationships for enum in weka.


## 6. Discussion and Analysis

The above Tables5–26, we have provided the result and analysis of datasets that we have used to conduct our experiment. Different tables and graphs are provided for result analysis, and it can be concluded that the most dominant entity is class, informal relationships have higher occurrence than formal relationships, and formal relationships are mostly based on formal relationships for classes. We provided a framework for the extraction of entities and relationships that exist t in a Java software system. Our Fact Extractor can extract three types of entities which are classes, interface, and enumerations. The fact extractor can be used to extract both formal and informal relationships. For classes, interfaces, and enumerations, the total number of formal relationships retrieved is 74, 43, and 31, respectively. Similarly, the fact extractor extracted a total of 73 informal relationships.


## 7. Conclusion

Fact Extractor System for Java Applications (FESJA) is an automatic software modularization tool, used to extract entities and relationships from java source code. The entities extracted by the fact extractor system are classes, interfaces, and enumerations. The Fact Extractor can extract both formal and informal relationships. The formal relationships are categorized into three parts which are formal relationships for classes, formal relationships for interfaces, and formal relationships for enumerations. For evaluation of relationships, we performed our experiment on four systems (dataset). The systems are iText, JFreeChart, Junit, and Weka software systems. We have provided different graphs and tables for analysis of results and presented our observations which can help researchers to carry out tasks related to software modularization process, software architecture recovery, and software clustering.



---

*Source: 8640596-2022-03-30.xml*