Reverse engineering approach for improving the quality of mobile applications

Introduction

Mobile applications take center stage in our lives today. We utilize them anywhere, at any time and for everything. We use them to peruse websites, shop, search for everything we need and for basic administration such as banking. For the importance of mobile applications, their reliability and quality are critical. Like any other applications, the initial design of mobile applications is affected by bug-settling and the introduction of new properties, which change the initial design; this can occasionally affect the quality of design (Parnas, 1994). This aspect is known as software degeneration, which can exist in the form of design flaws or anti-patterns (Eick et al., 2001).

One of the most important factors in the development of software systems is improving software quality. The success of software design depends on the availability of quality elements such as maintainability, manageability, testability, and performance. These elements are adversely affected by anti-patterns (Afjehei, Chen & Tsantalis, 2019; Yamashita & Moonen, 2013). Anti-patterns are bad practice in software design. The automatic detection of anti-patterns is a good way to support maintenance, uncomplicate evolution tasks, and improve usability. In addition to the general advantages of detecting anti-patterns, we think that detecting anti-patterns provides developers with a way to ensure that the detected anti-patterns will not be repeated in applications revisions. Also, detecting anti-patterns may improve both operational characteristics and user experience.

We note that there are many other approaches interested in detecting anti-patterns in the code level as introduced by Morales et al. (2016) and Alharbi et al. (2014). However, it has been noted that anti-pattern detection at the design level reduces many code anti-patterns and is more general.

According to Raja (2008), engineering is the process of designing, manufacturing, assembling, and maintaining products and systems. Engineering has two types, forward engineering, and reverse engineering (RE) as presented by Raja (2008). Chikofsky & Cross (1990) defined RE as the process of analyzing software systems to identify the components of the systems and the interrelationships between them and presenting the systems in other forms or at a higher level of abstraction. The term RE according to our approach, refers to the process of generating UML diagrams followed by generating OWL ontologies of mobile applications through importing and analyzing the bytecode.

Generally, we can use ontology re-engineering for direct incorporation as an Ontology development method (Obrst et al., 2014) by allowing the designer to analyze the common components dependence.

Designing a pattern of mobile application remains an ongoing research challenge. The proposed approach aims to detect structural and semantic anti-patterns in the design of mobile applications as well as to show which method is better for the integration of applications.

Motivated by the research mentioned above, the major contributions of this paper are sixfold:

• Presenting a new method for generating OWL ontology of mobile applications.

• Presenting a general method for enhancing the design of a pattern of a mobile application.

• Illustrating how the proposed method can detect both structural and semantic anti-patterns in the design of mobile applications.

• Describing how we evaluate the proposed method in 29 mobile applications. Showing how it detects and treats 15 designs’ semantic and structural anti-patterns that appeared 1,262 times.

• Showing how semantic integration among mobile applications decreases the occurrences of anti-patterns in the generated mobile application pattern.

• Analyzing the relationships among the object-oriented anti-patterns and the detection tools.

In the rest of the paper, we subsequently present the related work. Next, we present some basic definitions, and the details of the proposed approach is described. After that, the empirical validations of the proposed method are presented, followed by the results and discussion. Finally, the concluding remarks are given, along with scope for future work.

Related Works

Many empirical studies have demonstrated the negative impact of anti-patterns on change-proneness, fault-proneness, and energy efficiency (Romano et al., 2012; Khomh et al., 2012; Morales et al., 2016). In addition to that, Hecht et al. (2015a), Chatzigeorgiou & Manakos (2010), Hecht, Moha & Rouvoy (2016) observed an improvement in the user interface and memory performance of mobile apps when correcting Android anti-patterns. They found that anti-patterns were prevalent in the evolution of mobile applications. They also confirmed that anti-patterns tend to remain in systems through several releases unless a major change is performed on the system. Many efficient approaches have been proposed in the literature to detect mobile applications’ anti-patterns.

Some researchers concentrate on ensuring that the soft is free of contradictions which are called consistency. Alharbi et al. (2014) detected the anti-patterns related to inconsistency in mobile applications that were only related to camera permissions and similarities. Joorabchi, Ali & Mesbah (2015) detected the anti-patterns related to inconsistency in mobile applications using a tool called CHECKCAMP that was able to detect 32 anti-patterns related to inconsistencies between application versions. Hecht et al. (2015b) used the Paprika approach to detect some popular object-oriented anti-patterns in the code of mobile applications using threshold technique. Linares-Vásquez et al. (2014) detected 18 object oriented (OO) anti-patterns in 1,343 Java mobile applications by using DÉCOR. This study focused on the relationship between smell anti-patterns and application domain. Also, they showed that the presence of anti-patterns negatively impacts software quality metrics; in particular, metrics related to fault-proneness. Yus & Pappachan (2015) analyzed more than 400 semantic Web papers, and they found that more than 36 mobile applications are semantic mobile applications. They showed that the existence of semantic helps in better local storage and battery consumption. The detection of semantic anti-patterns will improve the quality of mobile applications. Palomba et al. (2017) proposed an automated tool called A DOCTOR. This tool can identify 15 Android code smells. They made an empirical study conducted on the source code of 18 Android applications and revealed that the proposed tool reached 98% precision and 98% recall. A DOCTOR detected almost all the code smell instances existing in Android applications. Hecht et al. (2015b) introduced the PAPRIKA tool to monitor the evolution of mobile application quality based on anti-patterns. They detected the common anti-patterns in the code of the analyzed applications. They detected seven anti-patterns; three of them were OO anti-patterns and four are mobile applications anti-patterns.

Reverse engineering is the process of analyzing software systems to identify the components of the systems and the interrelationships between them and presenting the systems in other forms or at a higher level of abstraction (Chikofsky & Cross, 1990).

In this paper, we used RE to transfer code level to design level for detecting mobile applications’ anti-patterns. RE techniques are important for understanding the construction of the user interface and algorithms of applications. Additionally, we can know all the properties of the application, its activities, and permissions and can read the Mainfest.xml of the applications. RE techniques have been used with mobile applications for many purposes not just for detecting anti-patterns. Song et al. (2017) used RE for improving the security of Android applications. While Zhou et al. (2018) used the RE technique to detect logging classes and to remove logging calls and unnecessary instructions. Also, Arnatovich et al. (2018) used RE to perform program analysis on a textual form of the executable source and to represent it with an intermediate language (IL). This IL has been introduced to represent applications executable Dalvik (dex) bytecode in a human-readable form.

Ontology and Software Engineering

According to the IEEE Standard Glossary of Software Engineering Terminology-Description (1990), software engineering is defined as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.”

Also, from the knowledge engineering community perspective, computational ontology is defined as “explicit specifications of a conceptualization.” According to Calero, Ruiz & Piattini (2006), Happel & Seedorf (2006), the importance of sharing knowledge to move the software to more advanced levels require an explicit definition to help machines interpret this knowledge. Happel & Seedorf (2006) decided that ontology is the most promising way to address software engineering problems.

Elsayed et al. (2016) proofed the similarities in infrastructures between UML and ontology components. They proposed checking some UML quality features using ontology and ontology reasoning services to check consistency and redundancies over UML models. This would lead to a strong relationship between software design and Ontology development.

In software engineering, ontologies have a wide range of applications, including model transformations, cloud security engineering, decision support, search, and semantic integration (Kappel et al., 2006; Aljawarneh, Alawneh & Jaradat, 2017; Maurice et al., 2017; Bartussek et al., 2018; De Giacomo et al., 2018). Semantic integration is the process of merging the semantic contents of multiple ontologies. The integration may be between applications that have the same domain or have different domains to take the properties of both applications. We make ontology integration for many reasons: to reuse the existing semantic content of applications, to reduce effort and cost, to improve the quality of the source content or the content itself, and to fulfill user requirements that the original ontology does not satisfy.

Proposed Method

In this section, we introduce the key components of the proposed method for analyzing the design of mobile applications to detect design anti-patterns, and for making semantic integration between mobile applications via ontology reengineering.

The proposed method for anti-pattern detection consists of three main phases and is summarized in Fig. 1. Also, there is an optional phase called the integration phase.

1. The first phase presents the process of reformatting the mobile application to Java format.

2. The second phase presents the reverse-engineering process. In this phase, we used RE to reverse the Java code of mobile applications and generating UML class diagram models. Additionally, many design anti-patterns were detected. The presented reverse approach is accurate enough to analysis the information that we need about APK to reverse UML models of the applications.

3. The third phase completes the anti-patterns detection and correction processes. This phase converts UML mobile application model to OWL ontology, then analyzes the relationships among object-oriented anti-patterns and offers methods to resolve the anti-patterns related to semantic and inconsistency. After that, we can regenerate the Java code of mobile applications. The developer can ensure that anti-patterns in existing applications will not be repeated in application revisions and may improve both operational characteristics and user experience.

4. The integration phase is an optional fourth phase. In this phase, we integrate two applications by merging the OWL ontologies of both applications. From these two ontologies, we will yield one integrated application for doing both services with minimum anti-patterns.

We will present in detail the rationale provided for why this integration is needed as an optional phase if we need.

The integration of mobile applications

The integration process is most for the inclusion of new skill sets for applications such as IOT or monitoring applications or potentially voice-activation integration into an existing application. But, here we were interested in presenting a new manner for homogenous integration to combine the advantages of two mobile applications in a new pattern. In this section, we provided a rationale for why this integration is needed and presenting the integration as an extra phase if we need where the other detection phases do not change. Patterns are advanced methods to develop any mobile applications. The integration or merging of mobile applications is a good step in mobile application development. The advantage of the integration of mobile applications is in responding to the puzzling selection of the appropriate application from a set of applications. This will achieve the same objective if each application has a different advantage and the developer wants to start to improve pattern combines all advantage without anti-patterns.

To clear our idea, we choose two homogenous applications: Viber and WhatsApp. They are the most popular messaging and Voice Over IP applications. Both Viber and WhatsApp are similar in services, features, security, and cost. There is plenty to like about both applications: they produce the same services as end-to-end encryption, support groups and video calls, support on any operating system, allow transmission of documents or multimedia, and work over 3G, 4G, and Wi-Fi. Well, both are fantastic in their way, but which one is better for the developer as a pattern for refinement? We found that Viber had been offering both video and voice calling for a far longer time than WhatsApp and has a hidden chat feature. Also, Viber permits the user to play a list of games with other Viber contacts. However, WhatsApp is popular and easy to use. We can make the integration of both applications and take the best skills of both.

We imagine that when producing a new application we can directly integrate it to the old one without replacing.

In the case of heterogonous integration applications, the developer, for example, may want to develop a new health care hybrid application. From the website “free apps for me” (https://freeappsforme.com/), a developer can find at least seven applications for measuring blood pressure. All of them are free and available on a different platform. There are also at least 13 diabetes applications. When a developer merge two applications (one for measuring blood pressure as the “Smart Blood Pressure” application and the other for controlling diabetes as the “OneTouch Reveal” application), the integration phase will yield one integrated application for doing both services, with minimum anti-patterns. Then the developer can add the new relations between these disease controller without conflict.

The integration allows the combination of the skills of both applications to get new mobile application pattern. These two examples of two types of integration answer the question of why we need to integrate mobile applications.

We suggest using the integration pattern, then comparing between the two integration proposed methods to select the suitable one.

The first integration method is for after decompiling the APK of the applications. We use RE methodology for generating one UML class diagram of both applications. Then we start the detection of the anti-patterns process for the integrated application (Fig. 2).

The second integration method is through merging the OWL ontologies of both applications using the Prompt plugin in protégé as the ontology editor as introduced in Fig. 3.

The implementation

In this section, we propose the implementation of the proposed detection method and determine which packages are suitable for each phase.

• The first phase: APK files are zip files used for the installation of mobile apps. We used the unzip utility for extracting the files stored inside the APK. It contained the AndroidManifest.xml, classes.dex containing the Java classes we used in the reverse process, and resources.arsc containing the meta-information. We de-compiled the APK files using apktool or Android de-compiler. Android de-compiler is a script that combines different tools to successfully de-compile any (APK) to its Java source code and resources. Finally, we used a Java de-compiler tool such as JD-GUI to de-compile the Java classes. JD-GUI is a standalone graphical utility that displays the Java code of “.class” files. The input of the first phase was the APK file of the mobile application and the output was the Java classes of the APK application. JD-GUI is accurately enough to generate the Java code that we use to reverse the models of the applications.

• The second phase: We used a RE approach for generating the UML class diagram models of the mobile applications. Elsayed, El-Dahshan & Ghannam (2019) compared between UML tools, the authors found that Modelio 3.6 is a suitable tool for modeling and detecting UML design anti-patterns. The UML class diagram was generated by reversing the Java binaries of the mobile app. Detecting anti-patterns in the UML model is the first step in the detection process. The input of the second phase was classes.java of the app and the output was the UML class diagram model of the app with a list of the detected anti-patterns.

• The third phase: By converting the model to XML format, we could generate it as an OntoUML model in OLED, which is the editor of OntoUML for detecting semantic anti-patterns. OntoUML is a pattern-based and ontologically well-founded version of UML. Its meta-model has been designed in compliance with the ontological distinctions of a well-grounded theory named the unified foundational ontology. OLED editor also supports the transformation of the OLED file to the OWL ontology of the mobile app, allowing the detection of inconsistency and semantic anti-patterns using the “reasoner” ontology in Protégé. Protégé is the broad ontology editor commonly used by many users.

The integration phase (the fourth optional phase): we propose two methods for integrating mobile applications. The first method is merging the UML models at the second phase when we reverse the models from Java code and then completing the detection phases over the integrated application. The second method is merging the OWL ontologies of the both applications using a Prompt (Protégé plugin) to generate one OWL ontology pattern. Figure 4 shows the both applications “Viber and WhatsApp” components before merging. Figure 5 shows the integrated application; Fig. 5 has three tabs (classes, slots, and instances) which are the components of the ontology. Every tab shows the components of its type after integration. Finally, we used “Reasoner in Protégé” to check the consistency after integration.

Empirical Validations

We assessed our approach by reporting the results we obtained for the detection of 15 anti-patterns on a random sample of 29 popular Android applications downloaded randomly from the APK Mirror.

Case study on “Avast Android Mobile Security”

To explain the proposed method, we presented a snapshot of it in a different case study “Avast Android Mobile Security.” The case study is one of the 29 mobile applications that is proposed in this article for the evaluation of the proposed method. The case study is downloaded from the APKMirror. The “Avast Android Mobile Security” secures the devices against phishing attacks from emails, phone calls, infected websites, or SMS messages. Also, it has many other features as Antivirus Engine, App Lock, Call Blocker, Anti-Theft, Photo Vault, virtual private network, and Power Save. The reason for choosing “the Avast Android Mobile Security” application as a case study is that it has the maximum number of the detected anti-patterns using the proposed method. Using the reverse methodology, we generated the UML class diagram model of the Java classes in Modelio. The model includes the classes, subclasses, class attributes, operations, and the associations between them (Fig. 6).

After generating the UML class diagram of the application in Modelio, we detected 229 repeated anti-patterns in the “Avast Android Mobile Security.” The anti-patterns are shown in Fig. 7. The number and the location of the anti-patterns were determined.

There were 10 detected anti-patterns (without repeat): “NameSpaces have the same name,” “NameSpace is Leaf and is derived,” “NameSpace is Leaf and is abstract,” “Generalization between two incompatible elements,” “A public association between two Classifiers one of them is public and the other is privet,” “Classifier has several operations with the same signature,” “Classifier has attributes with the same name,” “The status of an Attribute is abstract and class,” “A destructor has two parameters,” and finally “MultiplicityMin must be inferior to MultiplicityMax.” Figure 8 shows a sample of them.

To convert the UML model to XML format, we converted it into an enterprise architecture file then converted it to an OLED file. In the “Avast Android Mobile Security” OLED file, we validated the model for detecting the anti-patterns. The detected anti-patterns in the different apps were: association cycle anti-patterns, Binary relations with overlapping ends anti-patterns, imprecise abstraction anti-patterns, and relation composition anti-patterns.

After anti-patterns detection using OntoUML editor, OLED supports the transformation of OLED file to the OWL ontology. We checked the inconsistency anti-patterns using the reasoner of the ontology editor (Protégé). The reasoner detected the anti-patterns related to inconsistency as (similar name, multiplicity constraints, and cyclic inheritance). Using the reasoner of ontology over the case study, we detected the anti-patterns in the classes that have the anti-patterns NameSpaces have the same name, classifier has several operations with the same signature, classifier has attributes with the same name, and MultiplicityMin must be inferior to MultiplicityMax, which we detected after generating the class diagram in Modelio, and detected the anti-pattern (association cyclic) which was detected via OLED.

The treatment or correction of the detected anti-patterns is classified into the following:

• Modelio presents the solution as a list of recommendation which developer can do it manually. In this case study, Table 2 presents the anti-patterns and the method of correction.

• OLED presents automatic solutions to correct the anti-patterns which we list in Table 3.

• Reasoner in Protégé presents all inconsistency anti-patterns where as Reasoner gives just the location of the inconsistent classes as in Fig. 9.

Table 2:

Ten Modelio anti-patterns and their correction way.

The anti-pattern	The method of correction
NameSpaces have the same name	Change the name of the conflicting NameSpaces
NameSpace is Leaf and is derived	Make the NameSpace non-final
NameSpace is Leaf and is abstract	Make the NameSpace non-final
Generalization between two incompatible elements	Change the source or the target in order to link two compatible elements
A public association between two Classifiers one of them is public and the other has different visibility	Change the visibility of the target class to public
Classifier has several operations with the same signature	Rename one of the Operations or change their parameters
Classifier has attributes with the same name	Rename the Classifiers Attributes
MultiplicityMin must be inferior to MultiplicityMax	Change the value of the minimum multiplicity to be less than the maximum multiplicity
The status of an Attribute is abstract and class at the same time	Set only one of the statuses to true
A destructor has parameters	Remove these parameters or remove the destructor stereotype from the method

DOI: 10.7717/peerj-cs.212/table-2

Table 3:

OntoUML anti-patterns and the correction way.

The anti-pattern	The method of correction
Association cycle	Chang the cycle to be closed or open cycle
Binary relation with overlapping ends	Declare the relation as anti-reflexive, asymmetric, and anti-transitive
Imprecise abstraction	Add domain-specific constraints to refer to which subtypes of the association end to be an instance of the other end may be related
Relation composition	Add OCL constraints which guarantee that if there is a relation between two types and one of them has subtypes, there must be constraints says that the subtypes are also in a relation with the other type
Relation specialization	Add constraints on the relation between the type and the super-type, declaring that the type is to be either a specialization, a subset, a redefinition or disjoint with relation SR

DOI: 10.7717/peerj-cs.212/table-3

Results and Discussion

We applied our proposed method on a sample of 29 Android applications, which we downloaded from the APK Mirror. The results present the detected anti-patterns in the 29 mobile applications and the relation between the different types of anti-patterns. The proposed method detected 15 anti-patterns. The total number of anti-patterns that appeared in the 29 applications was 1,262 anti-patterns. We classified the anti-patterns according to their existence in the UML class diagram components. The occurrences of the anti-patterns are given in Table 4. Every group has the anti-patterns that were detected in it. For example, the group “Anti-patterns in Operations” presents all anti-patterns that were detected in the operations using the three tools.

Table 5 shows the detected anti-patterns in each application using the proposed method and the total number of anti-patterns in the 29 mobile applications.

We found that the “anti-patterns in the class” group is the most commonly detected anti-pattern in Android applications. The “anti-patterns in operation” is the least commonly appeared anti-pattern (Fig. 10).

We measured the relations between anti-patterns groups using correlation coefficient. Correlation coefficient is a statistical measure of the degree to which changing the value of one variable predict changing to the value of the other. A positive correlation indicates that the extent to which those variables increase or decrease in parallel. While a negative correlation indicates the extent to which one variable increases as the other decreases. Table 6 presents the correlations between anti-patterns groups. The tool can detect certain group, it also can detect in parallel the other as attributes anti-patterns with operations anti-patterns. Also, appearance of attributes anti-patterns in certain applications indicates the appearance of operations anti-patterns strongly. Then the correlation between the five groups of anti-patterns is used to know if the existence of any type of them implies the existence of other type. There was a strong negative correlation (−0.1) between namespaces anti-patterns and association anti-patterns. Also, a strong positive correlation (0.8) between attributes anti-patterns and operations anti-patterns.

Also, we analyzed the correlation between the detection tools of the proposed method (Table 7). The greatest correlations were between Modelio and Protégé. For assessing the direct relation between Protégé and Modelio, we calculated the statistical means of anti-patterns which were detected by each tool (Modelio, Protégé, and OLED) on 29 mobile applications as in Fig. 11. Figure 11 shows the similarity between both the means of Protégé and Modelio as the result of the correlation. Now, we want to statistically answer the question “Do we need to use the three tools” and “is there a relation between them?”

In order for statistical analysis to explain the relation among the three tools and the anti-patterns’ groups, we used the analysis of variance ANOVA test. This is to determine whether there are any statistically significant differences between the means of anti-patterns detection by each one of the tools, and also to determine if there is any relation between anti-patterns groups and the features of mobile applications.

We use ANOVA to calculate a test (F-ratio) with which we can obtain the probability P-value (usually taken as P < 0.05) suggests that at least one group mean is significantly different from the others. The null hypothesis is (all population means are equal). The alternative hypothesis is (at least one population mean is different from the rest). Where the degree of freedom (df) between groups is 28 and df within the group is 116. We found that the significant differences are 0.578, 0.464, and 0.926 for Protégé, Modelio, and OLED, respectively. This implies that the null hypothesis is false, i.e., all the detection tools are necessary and required for the detection of the anti-patterns.

The ANOVA statistically proved that there was no concern for the features or the specifications of the applications; that is, the low F-value meant that the groups are close together relative to the variability within each group.

We separated the result of integration phase because it is an optional phase. In the case of homogeneous applications, we found that the number of the detected anti-patterns in the output application was not the same. The detected anti-patterns using the ontology integration tool Prompt was less than the number of anti-patterns detected by using the Modelio tool. This indicates that semantic integration decreases the increases the accuracy of detecting anti-patterns in mobile applications. Table 8 shows the number of anti-patterns in each application in the integration case study (Viber and WhatsApp) and the number of them in the mobile application pattern after merging. The enhancement using ontology is approximately by 11.3% in addition to a consistency check.

Where the formula to calculate the increasing percent between two values is (1) $$\text{Percent increase}=\left[\frac{\left(\text{Second value}-\text{First value}\right)}{\left(\text{First value}\right)}\right]\times 100$$

Substitute in Eq. (1) by

The first value is the total number of anti-patterns according to using Modelio = 115.

The second value is the total number of anti-patterns according to using Prompt = 128.

Then the percent is increased by ≅ 11.3% which implies that using ontology integration by Prompt (Protégé plugin) instead of using UML integration by Modelio increases the percent of detection.

Additionally, using ontology to separately refine Viber or WhatsApp as a pattern enhanced them approximately 4.04% and 89%, respectively, in addition to a consistency check by “Reasoner.”

Conclusions

In this paper, we focused on improving the quality of mobile applications. We introduced a general method to automatically detect anti-patterns not by using specific queries, but by using Modelio, OLED, and Protégé in a specific order to get positive results. Also, concerning the related work section, our proposed method is more general than other methods as the proposed method supports semantic and structural anti-pattern detection at the design level.

For evaluation of the proposed method, we applied it on a sample of 29 mobile applications. It detected 15 semantic and structural design anti-patterns. According to the proposed classification of anti-patterns, “the anti-patterns in the class group” was the most frequent anti-pattern, and “the anti-patterns in the attribute group” was the least frequent. From the perspective of anti-patterns detection, the analysis of results also showed that there is a correlation between the Modelio and Protégé platforms. Also, there is no correlation between OLED and Protégé and no correlation between Modelio and OLED.

We found that using ontology in the integration phase increases the detection percentage approximately by 11.3% and guarantees consistency which is assessed by the reasoner of the ontology. Accordingly, semantic ontology integration has a positive effect on the quality of the new application. This helped with developing a correct, consistent, and coherent integrated pattern that has few anti-patterns.

Finally, we recommend that the developer, before using any mobile application as a pattern, should check the design of the selected application against the anti-pattern.

When a developer concerned with avoiding certain anti-patterns type, the correlations between anti-patterns groups, and between tools will help him. Also, the proposed method considered the issues and problems of developers who are revising Android applications and integrating new packages of code skill sets. A code review such as the methodology proposed could be very valuable in terms of not carrying forward existing anti-patterns and not incorporating new code flawed with poor design. The reverse deeply in OWL ontology of a mobile application very useful.

In the future, we are going to solve the problem of big ontologies which cannot be opened in ontology editors as Protégé to complete the detection process. Although, detection of anti-patterns at the design level is very useful and reduces some anti-patterns in the code level, we will refine the metric method for detecting code level anti-patterns on big ontology. Also, we will create a semantic web application for anti-patterns to collect all detection tools of the two levels and anti-patterns catalog. Finally, the correction phases in Modelio and Reasoner are still open issues.

Supplemental Information