Naglaa Dissertation

Al-Azhar University,
Faculty of Science (Girls),

Department of Mathematics
Improving Mobile Applications' Quality via Diagnosis

Anti-patterns
A THESIS
Submitted in Partial Fulfillment of the Requirements for
The Doctor Philosophy Degree (Ph.D.)
In Mathematics (Computer Science)
BY
Naglaa El-Sayed Ibrahim Ghannam
Department of Mathematics, Faculty of Science – Al-Azhar University,
Cairo, Egypt
SUPERVISORS
Prof. Hoda A. Ali Prof. Kamal A. El-Dahshan
Prof. of Mathematics, Faculty of Prof. of Computer Science,
Science (Girls), Al- Azhar Faculty of Science
University- Cairo Al- Azhar University
Cairo
Assoc. Prof. Eman K. Elsayed

Department of Mathematics
Faculty of Science (Girls)
Al-Azhar University
Cairo, Egypt
1440 – 2020
)‫جامعه األزهر (فرع البنات‬
‫كليه العلوم‬
‫الدراسات العليا‬
Plan of Work
Philosophy degree
- Name/ Naglaa El-Sayed Ibrahim said
- Social Status/ Widow
- Occupation / Faculty of Science – Girls –Al-Azhar University
- Education / Master in Computer Science - Pure Math and
computer Science Dep. - Faculty of Science - Al Azhar
University – 2017
- Research is done for / PHD Degree (Philosophy)
:Title of research
Improving Mobile Applications' Quality via Diagnosis
Anti-patterns
Research Plan:
1- Survey about mobile applications' anti-patterns with UML and
Ontology.
2- Propose a framework to solve the quality problems in mobile
applications.
3- Apply the proposed framework on real samples for solving
integration problems and refinement in mobile applications.
Supervisors
1- Prof. Hoda Abdel Daiem Ali
Professor of Mathematics, Faculty of Science (Girls), Al-Azhar
University
2- Prof. Kamal Abdel Raouf ElDahshan

Professor of computer science, Faculty of Science, Al-Azhar University
3- Assoc. Prof. Eman Karam Elsayed

Assoc. Prof. of computer science, Faculty of Science (Girls), Al-Azhar
University
Head of. Department of Mathematics Dean of Faculty of
Science
Approval Sheet
Name: Naglaa Elsayed Ibrahim Said

Thesis: Improving Mobile Applications' Quality via Diagnosis
Anti-patterns
Degree: PHD Degree in Computer Science
Supervisors Position Relation- Signature

ship
Prof. Hoda Abdel Professor of Mathematics,

No …………..
Faculty of Science (Girls),
Daiem Ali
Al-Azhar University
Prof. Kamal Abdel Professor of Computer

No …………..
Science Faculty of Science,
Raouf El dahshan
Al-Azhar University
Assoc.Prof. of Computer
Assoc. Prof. Eman Science, Faculty of No ………….
Karam Elsayed Science (Girls), Al-Azhar
University
Prof. Dr. Lamiaa Deiab

Head of the Department of Mathematics
Faculty of Sciences (Girls)
Al-Azhar University
DEDICATION
To
My parents
And
My family
For their Support and Prayers

Acknowledgements
First, I would like to thank Allah for his immerse

blessings and help provided to me throughout my life and in
particular throughout my PHD work.
I would also like to express with pleasure my gratitude to all

who have contributed to this thesis. In particular, I am heartily
thankful to my supervisors, Prof. Dr. Hoda A. Ali and Prof. Dr.
Kamal A. El-Dahshan for their incredible encouragement help and
support during the whole master period and also thankful to Assoc.
Prof. Eman K. Elsayed for her professional approach and attention
to details.
One simply cannot wish for better, more professional or

friendlier supervisors. My thanks also to the Department of
Mathematics and Faculty members for their help and support.
I would also like to thank members of my family, my

parents for their continuous prayers and support, my two children,
for their emotional support and encouragement especially in
tough periods of my master journey.
Cairo, Egypt Naglaa E. Ghannam

2020
Publications
Publications Related to this Thesis
1. "Comparative Study for Detecting Mobile

Application's Anti-Patterns ".
Kamal A. El-Dahshan, Eman K. Elsayed and Naglaa E. Ghannam. In
Proceedings of the 2019 8th International Conference on Software
and Information Engineering (pp. 1-8). ACM.
2. "Reverse engineering approach for improving the

quality of mobile applications".
Kamal A. El-Dahshan, Eman K. Elsayed, Enas E. El Sharawy and
Naglaa E. Ghannam, PeerJ Computer Science 5:e212
https://doi.org/10.7717/peerj-cs.212. 2019.
3. " Metric method for long life Semantic Applications"

Eman K. Elsayed, and Naglaa E. Ghannam, International Journal of
Intelligent Engineering and Systems (Ijies), Vol.12, No.6, pp.25-36,
2019. http://doi.org/ 10.22266/ijies2019.1231.03.
Abstract
ABSTRACT
The integration and refinement of mobile applications to

design patterns have many challenges. Mobile applications
designed with anti-patterns suffers from poor quality and short
lifetimes.
As both UML and Ontology are formal languages, so
when we detect anti-patterns in them, it means that we detect the
informal parts also. The proposed approach generates the UML
class diagram and the OWL Ontology of the mobile apps and
detects the anti-patterns.
The thesis proposes two general methods to detect mobile
applications' anti-patterns that is capable of detecting both
semantic and structural design anti-patterns and detecting design
smells from big OWL ontologies of the applications.
We propose a general method to generate mobile
applications patterns. It detects and diagnoses the anti-patterns
that’s deeply in mobile application design level.
The proposed method is based on Ontology and reverse

engineering. We divided this work into two parts. The first part
detects the anti-patterns from the design of the mobile
applications. For validating the quality of the first part, we applied
the first proposed method on 29 publicly available mobile
A
Abstract
applications. It detected 15 structural and semantic anti-patterns

which appeared 1262 times in the design of mobile apps.
The second part detects the anti-patterns from big OWL
ontologies and is based on Ontology and Python programming
language. For approving the quality of the second part, we applied
the second proposed method on 12 OWL big ontologies. It
detected 3 structural anti-patterns which appeared 117495 times.
The proposed approach allows the semantic integration of
mobile apps to generate better apps.
Keywords: Patterns, Anti-Patterns, Mobile Applications, UML, Ontology

based, and Python programming language.
B
Contents
CONTENTS
………….…………………………………Abstract A
.……….………….…………………List of Figures I
..……………..….……………………List of Tables III
..………………...……………………List of Charts IV
.………………………………Nomenclatures Table V
1. Introduction
1.1 Problem Description...................................................1
1.2 Thesis Motivation and Contribution ..........................4
1.3 Thesis Outcomes and Organization............................6
2. Patterns and Anti-patterns Overview

2.1 Patterns Definition .....................................................10
2.2 Pattern Form ...............................................................12
2.3 Benefits of Design Patterns.........................................12
2.4 Anti-patterns................................................................13
2.4.1 Anti-pattern Definition.....................................13
2.4.2 Anti-pattern Form..............................................14
2.4.3 Analysis of Anti-patterns...................................15
2.5 Anti-patterns Detection.............................................15

2.5.1 Detection at the Code level..............................16
2.5.2 Detection at the Design level..........................17
Contents
3. Mobile Applications, Unified Modeling Language (UML),

and Ontology
3.1 What are Mobile Applications? ...................................19
3.1.1 Mobile Applications Structure..........................20
3.1.2 Anti-patterns in mobile applications…………..21
3.2 Unified modeling language (UML)............................22
3.2.1 UML Tools........................................................23
3.2.2 UML Diagrams..................................................23
3.2.3 Structural Diagrams...........................................24
3.2.4 UML Class Diagram.........................................25
3.3 Ontology ....................................................................26
3.3.1 Advantages of using Ontology..........................27
3.3.2 Semantic Integration using the Ontology .........28
3.4 The SPARQL Language ............................................30
4. Related Works
4.1 Related Work in reverse engineering comparisons on
UML Tools.......................................................................31
4.2 Related work in reverse engineering in mobile apps. .32
4.3 Related work in anti-patterns detection in mobile
App…………………………………………………..33
4.4 Related works in anti-patterns detection OWL
Ontologies........................................................................ 34
5. Reverse engineering approach for improving the
Contents
Quality of mobile applications

5.1 Introduction ..............................................................37
5.2 UML modeling tools and software engineering ......38
5.3 The proposed method ................................................42
5.3.1 The Implementation ............................................48
5.4 Empirical Validation.....................................................53
5.4.1 Applications under analysis ..............................53
5.4.2 Case study..........................................................55
5.4.3 Detecting of semantic anti-patterns .................60
5.4.4 Detecting of OWL Ontology anti-patterns ......61
5.5 Results and discussion..................................................64
5.5.1 Results of anti-patterns detection.........................64
5.5.2 Results of the integration phase...........................71
6. ONTOPYTHO: Python framework for improving
big ontologies quality
6.1 Introduction...............................................................74
6.2 Ontology and design smells.......................................75
6.3 Ontology smells models............................................77
6.3.1 Blob smell model.............................................77
6.3.2 Lazy class smell model....................................78
6.3.3 Large class smell model...................................79
6.3.4 Singleton smell model .....................................80
6.4 The proposed detection method "ONTOPYTHO". . .81
Contents
6.5 Experimental Evaluation ..........................................87

6.6 Results and discussions.............................................89
7. Conclusion and Future Work

7.1 Conclusion..................................................................99
7.2 Future Work................................................................101
Glossary ……………………………………………………….103
References ................................................................................106
Arabic Summary
List of Figures
LIST OF FIGURES
Figure No. Page
…………………………………Figure 3.1: Application structure 20
...........……….…………………Figure 3.2: UML diagrams types 24
..…….……………Figure 5.1: The validation via using StarUML 42
....……………………Figure 5.2: The proposed detection method 43
Figure 5.3: Merging of the two class diagrams of mobile
..………………………………………………………applications 47
Figure 5.4: The integration of OWL ontologies of the mobile

..………………………………………………………applications 48
..………………………………Figure 5.5: Generating Java classes 49

Figure 5.6: Generating UML class diagram and anti-patterns
detection in Modelio……………………………………………….
50
Figure 5.7: Semantic anti-patterns detection…………………..….. 51
Figure 5.8: The OWL ontologies before merging…………………. 52
Figure 5.9: The OWL slots after merging ………………………… 53
...………Figure 5.10: The generated java classes of the mobile app 55
Figure 5.11: The class diagram hierarchal of the mobile App…….. 56
Figure 5.12: The detected anti-patterns using Modelio ….……..… 57
……...……..…………Figure 5.13: NameSpaces have the same name 58
..Figure 5.14: Generalization between two un-compatible elements 58

Figure 5.15: A public association between two Classifiers one of
...............……………………them is public and the other is privet
58
Figure 5.16: Classifier has several operations with the same
....…………………………………………………………signature
58
..…………………Figure 5.17: NameSpace is Leaf and is derived 59
Figure 5.18: Classifier has attributes with the same name……….. 59
I
List of Figures
…………………………Figure 5.19: A destructor has parameters 59

..…………………Figure 5.20: NameSpace is Leaf and is abstract 59
Figure 5.21: MultiplicityMin must be inferior to MultiplicityMax. 59
Figure 5.22: The status of the attribute is abstract and class……... 60
Figure 5.23: The semantic anti-patterns in "play store app" …..…. 60
Figure 5.24: The result of the reasoner detection………..…….….. 62
.………………Figure 6.1: OWL Ontology model for Blob smell 78
Figure 6.2: The OWL Ontology representing the Lazy class smell 79
Figure 6.3: OWL Ontology representing Large Class Smell ……. 80
Figure 6.4: OWL Ontology representing the Singleton smell…… 81
Figure 6.5: The result of ONTOPYTHO on the case study……… 89
Figure 6.6: The appearance of the detected smells in the DBpedia

OWL Ontologies versions………………………………..……… 91
II
List of Tables
LIST OF TABLES
Table Page
Table 5.1: UML tools support Reverse Engineering Java Code….. 39
Table 5.2: The evaluation of the detection process between tools ... 41
Table 5.3: The Description of the mobile Apps under Analysis…… 54
Table 5.4: Ten Modelio anti-patterns and their method of correction 63
Table 5.5: OntoUML anti-patterns and the method of correction….. 63
Table 5.6: The occurrences of the anti-patterns……………………. 64
Table 5.7: The detected anti-patterns in the 29 mobile applications 66
Table 5.8. The correlation between anti-patterns groups…. 68
Table 5.9: The correlation between detection tools………. 69
Table 5.10: Comparison between the numbers of anti-patterns after

integration using "Modelio" and "Prompt"…. 72
Table 6.1: Description of Owl Ontologies under analysis…. 88
Table 6.2: Design smells per Owl ontologies ………… 90
Table 6.3: ONTOPYTHO results for the detection Of 3 smells in 12

Owl Ontologies………………………….. 92
Table 6.4: The SPSS Pearson correlation coefficient matrix between

the class’ smells………………………………...... 93
Table 6.5: The Ratio of smells according to the classes of Owl

Ontologies………………………………………….. 93
III
List of Tables
LIST OF CHARTS
Chart Page
……… Chart 5.1: The visibility of anti-patterns groups 65
Chart 5.2: The similarities between the means of the

.…………………………………………detection tools 70
Chart 6.1. The similarity between the means of "Blob

and Large-class" smells and differences between them
and "Lazy class" smell
94
………………………………………
IV
Nomenclatures Table
Nomenclatures Table
Symbol Meaning
OMG Object Management Group
UML Unified Modeling Language
OWL Web Ontology Language
XML Extensible Mark-up Language
OCL Object Constraint Language
EA Enterprise Architecture
OLED Ontology Lightweight Editor
RDF Resource Description Framework
RE Reverse Engineering
FE Forward Engineering
DX Dalvik Executable
DVM Dalvik Virtual Machine
JVM Java Virtual Machine
APK Android Package
IL Intermediate Language
OO Object Oriented
MOGP Multi-Objective Genetic Programming
IOT Internet Of Things
VOIP Voice Over IP
UFO Unified Foundational Ontology
V
Nomenclatures Table
ANOVA Analysis of Variance
DF Degree of Freedom
GO Gene Ontology
SPSS Statistical Package for the Social Sciences
VI
Chapter (1) Introduction
Chapter (1)
INTRODUCTION
1.1 Problem Description
One of the most important things in the development of

the software systems is the software quality raising. The success
of software design depends on the availability of the quality
elements such as maintainability, manageability, testability and
performance. These elements are adversely affected by anti-
patterns.
Anti-patterns are bad practice in software design which
impede the maintenance and degrade the performance. Many
tools and methods have been introduced for detecting and
defining the types of these anti-patterns. The automatic detection
of anti-patterns is a good way to keep the maintenance, easy the
evolution tasks and improves the usability and software quality.
We noted that many researches interested in detecting code anti-
patterns, while there is a fact said that the anti-patterns detection
at the design level reduces many code anti-patterns which is more
general.
Mobile applications assume a focal part of our life today. We
utilize them anyplace, whenever to check our emails, to browse
the Internet, and even to access critical services such as banking
1
and health monitoring. According to the importance of mobile

applications in our life, its reliability and quality are critical
Like any other applications, the initial design of mobile apps

is affected by bug-setting, introducing new properties, changes
results. All of these elements can now and again effect the quality
of the design. This phenomenon is known as software decay
which can be exist in the form of design flaws or anti-patterns.
Designing high quality mobile application pattern remains
an ongoing research challenge, the proposed approach aims to
detect structural and semantic anti-patterns in the design of the
mobile apps that is indicating designing high-quality mobile
application pattern. In addition to that, showing which method is
suitable for the integration of the apps. This integration process
produced in some cases big OWL ontologies of the mobile apps
which can't be evaluated by using Ontology reasoner. These apps
became semantic OWL ontologies which are vital in numerous
areas of computer science. Semantic technologies have a wide
range of applications, including model transformations, cloud
security engineering, decision support, search and semantic
integration. The most important technology is the semantic web
technology which makes web contents comprehensible for both
humans and machines. All semantic applications are based on
Ontology which presents the semantic structure of the
applications' domains.
2
Ontology is the cornerstone of the semantic web, so the

quality of the Ontology impacts directly on semantic web
applications' quality.
There are different cases in design Ontology' classes, which

have negative effects as Blob, Lazy Class, Large Class, and
Singleton. These cases called bad smells or anti-patterns on
ontology.
Earlier studies showed that for avoiding software

complexity and low quality, we should measure and control
system components. In big Ontologies systems, we need to
measure them to control their complexity. On the other hand,
reasoners cannot deal with big ontologies or cannot detect all the
anti-patterns. They cannot handle even all the errors resulting
timeout. The proposed anti-patterns detection method can detect
structural anti-patterns without using the reasoners and whatever
the Ontology size.
The detection process of the design anti-patterns usually

involves finding the fragments of design which violate these
software metrics. The proposed approach detects the anti-patterns
in an automatic way and the correction will be manual
This thesis will explore the area of bad practices, namely

anti-patterns, and their consequences in mobile applications. Also,
it can evaluate both small and big ontologies.
3
1.2 Thesis Objectives and Contribution

The main objective of our research study is to improve the
quality of mobile applications. We propose a new approach for
detecting semantic and structural anti-patterns in the design of
mobile apps using Ontology and reverse engineering. In addition,
using Python to manipulate big ontologies and detecting some
design anti-patterns in Ontology models which cannot be detected
by the reasoners. This approach is used in a case study "Play store
app" and bpedia_2015-10". In addition, we applied it in a sample
of twenty-nine mobile apps and twelve OWL big ontologies that
were downloaded from different sources.
This thesis contributes to the improvement of the systems by
using the Ontology and python approach.
Thesis contributions are listed below:
 Presenting a general method for detecting structural
and semantic anti-patterns in mobile applications:
One of the important contributions is the development of
mobile apps. Mobile applications patterns and anti-patterns are
first outlined in chapter 3 which shows the types of the anti-
patterns in these apps. The study is only concerned with design
anti-patterns not code anti-patterns.
 Using Ontology as a detection method
Ontology has many uses; our approach introduces a new use
4
of it. Section 3.3.1 presents different advantages of using the

Ontology. Section 6.4.2 presents the semantic anti-patterns
detection phase.
 Presenting a semantic integration method of mobile
applications which can decrease the occurrences of anti-
patterns in the generated mobile application pattern.
Semantic integration is one of the important advantages of
using the Ontology. Section 5.3.4 presents the integration phase
of mobile application in the forth phase.
 Analyzing the relation between object-oriented anti-
patterns and the detection tools
Section 5.5 presents the statistical analysis using SPSS to
analyze the relation between the detected anti-patterns and also
between the detection tools.
 Assessing the correlation between smell’s existence
and memory consumption.
Section 6.4 shows how the existence of lazy class anti-
patterns causes' memory consumption and detecting and deleting
them reduces ontologies sizes.
 Proposing an Ontology-Python (ONTOPYTHO)
approach for detecting smells on small and big
Ontologies.
Python is a high-level programming language which is
considered as an interpreter with dynamic semantics. It reduces
5
the cost of the program maintenance, supports modules and

packages, which implies code reuse. The proposed approach
detects design smells in small and big Ontologies.
1.3 Thesis Outcomes and Organization
Let us now list the various chapters of the thesis and give a
brief outline of each of them.
Chapter 1: Introduction
First, in section 1.1 a brief Problem Description is

introduced. Section 1.2 shows the thesis objectives and
contribution. Outcomes and thesis organization are presented in
section 1.3.
Chapter 2: Patterns and Anti-patterns Overview
Section 2.1 presents Patterns Definition. Section 2.2

presents the Pattern Form. Design Patterns Benefits are
introduced in section 2.3. Section 2.4 introduces the Anti-patterns,
which contains some sections, in section 2.4.1, we present Anti-
pattern Definition, section 2.4.2 presents Anti-pattern Form;
section 2.4.3 explains the Analysis of the Anti-patterns. Section
2.5 presents the Anti-patterns Detection. Section 2.5.1 presents
the detection at the Code Level. Detection at the design level is
introduced in section 2.5.2.
6
Chapter 3: Mobile Applications, Unified Modeling

Language (UML), and Ontology
An overview of mobile applications is presented in section
3.1. Section 3.1.1 presents the structure of mobile applications.
Section 3.1.2 presents mobile applications anti-patterns. Section
3.2 presents an overview of the unified modelling language
(UML). In section 3.2.1, UML tools are presented. Section 3.2.2
presents UML diagrams. UML Class diagram is presented in
section 3.2.2. Section 3.3 presents an overview of the Ontology.
Section 3.3.1 presents the advantages of using the Ontology while
section 3.3.2 presents the semantic integration using the
Ontology. Section 3.4 presents SPARQL query language.
Chapter 4: Related Works

This chapter is divided into four parts: Section 4.1 presents
the first part, which introduces the related works in reverse
engineering comparisons on UML Tools. Related works in
reverse engineering in mobile apps are presented in the second
part in section 4.2. Section 4.3 presents the third part which shows
the related works in anti-patterns detection in mobile apps.
Related works in anti-patterns detection in OWL Ontologies are
presented in the fourth part in section 4.4.
7
Chapter 5: Reverse engineering approach for

improving the quality of mobile application
In this chapter, we introduce an introduction in section 5.1.
Section 5.2 presents UML modeling tools and software
engineering. Section 5.3 presents the proposed method. The
implementation of the proposed method is presented in section
5.3.1. Section 5.4 presents the empirical validation of the
proposed method. Applications under analysis are produced in
section 5.4.1. For explaining the proposed method, we introduce a
case study in section 5.4.2. Section 5.4.3 presents the detection of
the semantic anti-patterns. Detecting OWL Ontology anti-patterns
is introduced in section 5.4.4. Results and discussions are
introduced in section 5.5 and is divided into two parts. Section
5.5.1 presents results of anti-patterns detection while section 5.5.2
presents the results of the integration phase.
Chapter 6: ONTOPYTHO: Python framework for
improving big Ontologies quality
In this chapter, we introduce an introduction in section 6.1.

Section 6.2 presents the Ontology and design smells. In section
6.3, we introduce the Ontology smells models. Section 6.3.1
introduces blob smell model while section 6.3.2 presents the lazy
class smell' model. The large smell model is introduced in section
6.3.3 while singleton smell model is introduced in section 6.3.4.
8
Section 6.4 presents the proposed detection method

"ONTOPYTHO". The experimental evaluation of the proposed
method is introduced in section 6.5. Section 6.6 presents the
results and discussion.
Chapter 7: Conclusion and Future Work
In section 7.1, we present the Conclusion of the proposed

work and Section 7.2 presents the Future Work.
9
Chapter (2) Patterns and Anti-patterns
Overview
Chapter (2)
Patterns and Anti-patterns Overview
This chapter defines patterns and anti-patterns, their

structures, types and the relation between them.
2.1 Patterns Definition

In software engineering, design patterns encode “good
practices” guiding developers in solving recurring design
problems. They were promoted to make designs more flexible,
modular, reusable, and understandable [1].
According to [2], Design patterns are considered as good

software practices to the design anomalies perceived by the
designer.
According to [3], design patterns express generic solutions

for common problems or properties in software engineering and
design. The pattern describes the way of going from a bad
solution to a good one and describes how it resolves the problem
and why it is a good solution. It is often useful to study how we
can solve the problems.
The idea of a design pattern was originated with

Christopher Alexander, an architect who documented a pattern
10
Overview
language for the planning of towns and the construction of

buildings within towns [4]. He said that each pattern describes a
problem, which occurs repeatedly in our environment, and then
describes the core of the solution to that problem, allowing using
this solution many times over, without ever doing it in the same
way twice.
Design patterns typify the best practices that the

experienced object-oriented software developers used. We got
these solutions through doing many tests in quite a substantial
period by developers.
Patterns help developers to communicate with using well-
known, well-understood names for software interactions.
Common design patterns can be improved over time making them
more rugged.
The success of the design patterns is because they provide
their users with ready prescriptions in a highly unstructured
knowledge domain, namely software design, present knowledge
that designers of object-oriented software have cumulated it in the
last decades.
Each pattern solves a particular problem, so once we learn a
large set of patterns, the design will be easier because the solution
of the problems may be one of the design solutions that we
already have known.
11
Overview
Any design pattern can be bad if it is implemented in the

wrong place; it can be cataclysmic and creates many problems.
However, if it is implemented in the right place, at the right time,
it can be considered as the savior.
2.2 Pattern Form
According to [5], the pattern form allows us to present both
the essence and the key details of the pattern . Every pattern has
its context, problem, solution, structure and example.
Problem Statement: a description of the problem or issue

that the pattern should solve.
Context: Describes the circumstances of the problem
occurrence probability, helps you to identify it.
Solution: It is the recommended solution for the problem.
Structure: a graphical representation of classes in the
pattern.
Example: An example to illustrate the solution.
2.3 Benefits of Design Patterns

According to [6], design patterns have a number of different
benefits:
12
Overview
 Firstly, patterns have a well-defined structure. This constant

layout makes it easy to follow them through a collection of
patterns to find the suitable help and then going further into
the material.
 Secondly, it is better to understand the context in which a
decision is taken, as the design decisions are rarely explicit.
By patterns, we share knowledge rather than just impasses
for a problem.
 Finally, patterns usually have explicit names, making them
more memorable; therefore, patterns can form a shared
vocabulary, which helps to develop the debate and the
communication between developers.
2.4 Anti-patterns
2.4.1 Anti-pattern Definition
Anti-pattern is a description of a bad solution to a recurring

problem [7]. Anti-patterns are bad solutions that reduce the
quality and the correctness of any model. When the pattern
solutions do not fit into the development context or not according
to the programmer’s preferences these may evolve into an anti-
pattern. These anti-patterns when creep deep into the code may
cause negative effects on the quality of the software [2].
13
Overview
According to [8], the anti-pattern is an obvious way of

solving a problem that occurs repeatedly, but unluckily, it is a
poor solution.
The anti-Pattern may be the result of a manager or
developer not knowing any better, not having sufficient
knowledge or experience in solving a particular type of problem,
or having applied a perfectly good pattern in the wrong context.
2.4.2 Anti-Pattern Form
As with the patterns, Anti-patterns must have unique and

meaningful names. According to [9], anti-pattern form is as
follows:
 Anti-pattern name.
 Central Concept: Which is a short description of the anti-
pattern to make it more identifiable.
 Dysfunction: the problems and the symptoms.
 Vignette: The anti-pattern in a real situation.
 Explanation: It is a description of the causes,
consequences and historical analogies for the anti-pattern.
 Band Aid: It is a short-term fix for anyone having the anti-
pattern and having neither the time nor influence to refactor
it properly.
14
Overview
 Self-Repair: It is the first step of telling you how you can

help yourself to improve.
 Refactoring: It is a description of the changes that should
be made to make the corrections.
 Observations: It is the part of adding comments or items of
notes and it is optional.
 Identification: It is an assessment instrument consisting of
some questions for diagnoses of the anti-pattern.
2.4.3 Analysis of Anti-patterns
According to [10], there are three levels of analysis that are

performed for ensuring the accurate capture of anti-pattern
information, these levels are structural, behavioral and semantic
levels.
 Structural analysis: It concentrates on the structural

characteristics of the anti-patterns.
 Behavioral Analysis: Behaviors of a system represent the
dynamic characteristics of it.
 Semantic Analysis: Semantic features of a system capture
the logical relationships between classes. Semantics relate
the structural and behavioral aspects of the system i.e.
information about static structure with dynamic behavior.
15
Overview
2.5 Anti-patterns Detection

Anti-patterns detection is a rich area of research, which
focus on finding bad designs in software systems.
According to [11], Anti-patterns detection needs to be
automated as much as possible since manually detecting them in
large models cannot realistically be done and is potentially error-
prone.
We can detect anti-patterns at the code level (for software re-
engineering purposes), or at the design level (for design quality
improvement purposes).
2.5.1 Detection at the Code Level
There were many works in detecting mobile applications'
anti-patterns at the code level:
 According to [12], they detected 18 OO anti-patterns in
1,343 java mobile apps by using DÉCOR. This study
focused on the relation between smell anti-patterns and
application domain. Also, they showed that the presence of
anti-patterns negatively impacts the software quality
metrics, in particular, metrics related to fault-proneness.
 According to [13], they 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 reveals that the
16
Overview
proposed tool reaches 98% of precision and 98% of recall.

A DOCTOR detected almost all the code smell in-stances
exist in the android apps.
 According to [14], they introduced the PAPRIKA tool to
monitor the evolution of mobile apps quality based on anti-
patterns. They detected the common anti-patterns in the
code of the analyzed apps. They detected seven anti-
patterns three of them are OO anti-patterns and four are
mobile anti-patterns.
The detection of the anti-patterns at the code level is
considered too late and will not reduce the correction cost.
Therefore, we are interested in anti-patterns detection at the
design level.
2.5.2 Detection at the Design Level
Besides the source code level, other works detect anti-
patterns at the design level. Anti-patterns detection at the design
level allows the designer to anticipate the problems that could be
generated by the implementation.
 In [15], they detected the anti-patterns related to inconsistency
in mobile applications that were only related to camera
permissions and similarities.
 In [16], the authors proposed an anti-pattern detection
approach at the design level of mobile applications. They
17
Overview
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.
 In [17], they conducted an empirical study on performance
issues in iOS apps. They found that most performance issues
in iOS apps are related to inefficient UI design, memory
issues, and inefficient thread handling. They also manually
uncovered four performance anti-patterns that recurred in the
studied issue reports. To help developers avoid these
performance anti- patterns in the code, they implemented a
static analysis tool called iPerfDetector and evaluated it on
eight open source and three commercial apps. iPerfDetector
successfully detected 34 performance anti-pattern instances in
the studied apps, where 31 of them are already confirmed and
accepted by developers as potential performance issues.
The resulting design after detecting anti-patterns should

solve the specific problem at hand and at the same time should be
generic enough to be able to address the future requirements and
the needs. By doing so, it is possible to identify points in a system
that need to be modified in order to make it more flexible and
reusable, and to ease system understanding as a whole, including
badly documented systems, by detecting existing design patterns.
18
Overview
Chapter (3)
Mobile Applications, Unified Modeling
Language (UML), and Ontology
This chapter presents the main concepts of the proposed work,
their definition, structure and advantages.
3.1 What are mobile applications?
A mobile application, most commonly referred to as an

app, is a type of application software designed to run on a mobile
device, such as a smartphone or tablet computer [18]. Mobile
applications frequently serve to provide users with similar
services to those accessed on PCs.
Apps are generally small, individual software units with

limited function. This use of app software was originally
popularized by Apple Inc. and its App Store, which offers
19
Overview
thousands of applications for the iPhone, iPad and iPod Touch

[18].
Mobile applications assume a focal part of our life today.

We utilize them anyplace, whenever to check our emails, to
browse the Internet, and even to access critical services such as
banking and health monitoring. Based on the Linux kernel,
Google developed an open source operating mobile system called
Android [19]. This open source characteristic is one of the
motivations for Android system development and improvement.
3.1.1 Mobile applications' Structure?

Android app is written in Java, extended with some native
parts in C and screen layouts in XML. Java source is compiled as
class files (.class), converted into Dalvik Executable using Dx
tool [20]. Android app source executes on Dalvik Virtual
Machine (DVM), a register based Virtual Machine for embedded
devices [20], unlike Java Virtual Machine (JVM), and a stack
based virtual machine. Executable code of the app is inside
Dalvik executable (.dex) file. Typical app structure is shown in
Figure 3.1.
20
Overview
Figure 3.1. Application structure
Androidmanifest.xml has important information like

Package Name, Permissions, Activities, Services, Receivers and
Content Providers. Icons, shortcuts, images, string constants,
dimension constants are made available through resources.
CLASSES.DEX file contains executable code. META.INF

folder has developer certificate information. This content is
compiled into a single package Android Package (APK) [21].
Once the app is developed, developer self-signs it with his private
key and publishes it on Official or third party android market
[21].
21
Overview
3.1.2 Anti-patterns in Mobile applications
Mobile apps are becoming complex software systems that

must be developed quickly and evolve continuously to fit new
user requirements and execution contexts.
According to the importance of mobile applications in our

life, its reliability and quality are critical. Like customary desktop
applications, android applications age as an outcome of changes
in their usefulness, bug-settling, and presentation of new features,
which now and again prompt the decay of the initial design. This
phenomenon is known as software decay which is manifested in
the form of design flaws or anti-patterns [22]. Mobile
applications with anti-patterns have bad quality and short lifetime.
Many empirical studies have demonstrated the negative

impact of anti-patterns on change-proneness, fault-proneness, and
energy efficiency [23], [24] and [25]. In addition to that, [26],
[27] and [28], they observed an improvement in the user interface
and memory performance of mobile apps when correcting
Android anti-patterns. They found that anti-patterns are prevalent
along the evolution of mobile apps. They also confirmed that the
anti-patterns tend to remain in systems through several releases
unless a major change is performed on the system.
22
Overview
3.2 Unified modeling language (UML)

The Unified Modeling Language (UML) is an industry-
standard graphical language used to specify, visualize, construct,
and document the elements of business modeling in the systems
[29].
In 1997, the Object Management Group (OMG) developed

UML as a common architectural framework to model object
oriented systems and applications.
We can use UML as a tool to generate the code in various

languages using UML diagrams. UML has a direct relation to
object oriented analysis and design. After some standardization,
UML is becoming an OMG standard.
OMG introduced UML diagrams for all users, whether they

were developers, business users, common people or anybody
interested in understanding the systems. Therefore, it must be
clear that UML is not a development method, but it accompanies
with processes to make a successful system.
3.2.1 UML Tools
There are many UML tools, some of them are open source
such as ArgoUML [30], StarUML [31] and UMLet [32], and
Modelio [33], and some are not such as Rational Rose XDE [34],
RISE [35] and UModel [36].
23
Overview
3.2.2 UML Diagrams
There are 14 types of UML diagrams as in Figure 3.2; each

one describes a different view of object-oriented software. The
most important diagram of UML is the class diagram, which
describes a static abstraction for any model of the real world.
Different users use any real world system; the users can be
engineers, analyzers, representatives, experts and any more. So
before outlining a system, the design is made because of alternate
points of view. The most imperative part is to visualize the system
from various viewer's viewpoint. The better we comprehend, the
better we make the system.
24
Overview
Figure 3.2. UML Diagrams
3.2.3 Structural diagrams

They show all different objects in the system and emphasize
the things that must be present in the system being modeled.
Since structural diagrams represent the structure, so they are used
extensively in documenting the software architecture of the
software systems.
The work is concerned with the structural diagrams specially

UML class diagram type.
3.2.4 UML Class Diagram
The UML Class diagram is the most used UML diagram

type. It is the type of the structural diagrams which describes the
static view for any model.
Class diagram represents the object-oriented view of a
system, which is static in nature. It shows the classes, the
attributes, the operations of each class, the relationships among
classes and the constraints that were imposed on the system.
The class diagram is the main UML diagram; it can be

mapped to other diagrams types. This is the most generally
utilized diagram at the time of the system development.
25
Overview
The purposes of the class diagram can be summarized as follow:

 Forward and reverse engineering.
 Analysis and design of the static view of an application.
 Describes responsibilities of a system.
 Base for component and deployment diagrams.
When we want to develop any system, the best way to
understand it is modeling it. A UML class diagram plays an
important role in modeling activities and it is known that class
diagram keeps their high quality all along a product life cycle.
Modeling is the designing of software applications before

coding. Modeling is an essential part of large software projects,
and helpful to medium and even small projects as well.
The UML diagrams have the advantages of specification,

visualization, construction and documentation, also they help to
generate the object orientated source code and vice versa so,
UML is the much accessible model language to be used.
3.3 Ontology
Ontology is defined as a formal, explicit specification of a

shared conceptualization [37]. Where, formal means that the
Ontology is machine readable, explicit means that the type of
26
Overview
concepts should be defined and conceptualization refers to an

abstract model for any phenomenon in the real world [37].
In Artificial Intelligence, an Ontology is a formal explicit

description of concepts in a domain of discourse, which concepts
refer to the classes that are the most important component of
Ontology [38].
In computer science and information science, an Ontology is

a formal naming and definition of the types, properties, and
interrelationships of the entities that really are fundamentally exist
for a particular domain of discourse [39]. It is thus a practical
application of philosophical Ontology, with a taxonomy.
Also, from knowledge engineering community perspective,

computational Ontology is defined as "explicit specifications of
conceptualization". So, according to [40] and [41], the important
of sharing knowledge to get the software to more advanced levels
makes us need to define the knowledge in an explicit way to help
the machines to interpret this knowledge. So they decided that the
Ontology is the promising way to address the software
engineering problems.
In software engineering, Ontologies have a wide range of

applications as cloud security engineering, decision support,
27
Overview
search and semantic integration [42], [43], [44] and [45].
3.3.1 Advantages of using Ontology
Using Ontology has many benefits:
 Ontology improves the quality of the design of the software
systems.
 Ontology has the reasoner plugin that we can use to detect the
anti-patterns related to consistency.

 Ontology provide the ability for re-engineering as merging
and mapping, Ontology has many plugins as prompt that

helps to merge ontologies and add the result to the new
project and can map two ontologies and transform data from
one to another.
 Ontology is the backbone of the semantic, so almost any
semantic information will be stored in the form of it and

published in the form of one of its languages as RDF or OWL.
 Ontology focuses on meaning and most applications need to
process the content of information, the OWL not just

presenting information to the humans, but it processes the
content also, that is the reason it was designed for.
3.3.2 Semantic Integration using the Ontology
28
Overview
Semantic integration is the process of merging the semantic

contents of multiple ontologies. The integration may be between
applications that have the same domain (homogenous
applications) or between different domains (heterogonous
applications) to take the properties of both applications. We make
Ontology integration for many reasons:
 Reusing the existing semantic content of the applications.

 Reducing the effort and cost.
 Improving the quality of the source content or the content
itself.
 Fulfilling the user' requirements that the original ontology
does not fill.
 Allowing the combination of the skills of both ontologies
to get new ontology.
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 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
improve pattern combines all advantages without anti-patterns.
29
Overview
The integration process may result in poor design choices,

known as anti-patterns which may incidentally degrade software
quality and performance.
According to the used integration tool, the number of
detected anti-patterns depends. According to [46], the existence of
semantics evaluates method of application analysis, simulates the
interaction between users and applications during application
executions and respects constrains of state changes imposed by
the life cycle of Android applications. Formal semantics can
provide a formal basis.
3.4 The SPARQL Language
Querying the Ontology’s classes and instances is a common

service once Ontology has been created, this querying process
involves semantics and logic operations.
Resource Description Framework (RDF) is used to

represent information on the semantic web in graph format, so the
syntax and the semantics of the SPARQL language is defined in
RDF according to this specification [47].
SPARQL language is a semantic query language that is used

to retrieve data stored in RDF format [47].
The user's queries in semantic web are expressed in

SPARQL over OWL Ontology. Results of SPARQL queries can
30
Overview
be ordered, limited and modified in number. In addition, these

results can be presented in several different forms.
Chapter (4)
Related Works
This chapter presents the related works of the proposed work. It is
divided into four parts:
4.1 Related works in reverse engineering comparisons

on UML Tools
There were many comparison works on reverse engineering UML
tools:
According to [48], they made a comparison between ten
UML tools focusing on the information retrieval of the tools from
the reverse engineering. Our research focuses on selecting the
tools that have the functionality of reverse and forward
engineering of the java code to generate the class diagram model.
31
Overview
According to [49], they presented an approach about

reverse engineering of the java code to compare byte code
between "decompiler" and UML tools. They stated that the
reverse process generated the same class structure from the both
tools. Our research assessed that not all UML tools generate all
components of the class diagram.
According to [50], they presented a study of software
engineering (forward and reverse) in UML tools. They tested four
modeling tools according to the ability of reversing the code and
generating the class diagram. In addition to that, the ability of
generating the code from the class diagram. But the tested
programing language was C#.
In the proposed research, it depends on choosing UML tools that
support both reverse and forward java code as mobile apps are
written in java.
4.2 Related works in reverse engineering in mobile

apps
The importance of the reverse engineering methodology is
the extent to which the good benefits it offers. Understanding the
construction of the user interface and the algorithms of the
applications, knowing all properties of the app such as its
activities, permissions and the ability to read the Mainfest.xml of
the app are all available using the reverse engineering technique.
32
Overview
The reverse engineering methodology was used in many

researches for many purposes:
According to [51], RE technique was used to improve the

Android apps own security. They introduced the AppIS system
that can effectively enhance the app's own security and the
strength against repackaging and cumulative attack. Our
research makes the RE for generating the class diagram of the
apps and detecting the anti-patterns.
 In [52], they used the RE technique to detect the logging
classes, remove the logging calls and remove unnecessary
instructions.
 According to [53], they used RE to perform a program
analysis on a textual form of the executable source and
representing it by an intermediate language (IL). This (IL) has
been introduced to represent applications executable Dalvik (dex)
bytecode in a human-readable form.
4.3 Related Works in anti-patterns detection in

mobile apps
Many efficient researches have been proposed in the literature to
detect the mobile applications anti-patterns:
According to [15], they detected the inconsistency anti-

patterns in the mobile applications which are only related to
33
Overview
camera permissions and similarities.

According to [16], they detected the inconsistency anti-
patterns in the mobile applications by using a tool called
CHECKCAMP that was able to detect 32 valid functional and
data inconsistencies between app versions.
According to [54], they detected 18 OO anti-patterns in
1,343 java mobile apps by using DÉCOR. This study focused on
the relation between smell anti-patterns and application domain.
Also, they showed that the presence of anti-patterns negatively
impacts the software quality metrics, in particular, metrics related
to fault-proneness.
According to [55], they proposed an automated tool called
A DOCTOR. This tool can identify 15 Android code smells. They
made an empirical study conducted in the source code of 18
Android applications reveals that the proposed tool reaches 98%
of precision and 98% of recall. A DOCTOR detected almost all
the code smell instances exist in the android apps.
According to [56], they introduced the PAPRIKA tool to
monitor the evolution of mobile apps quality based on anti-
patterns. They detected the common anti-patterns in the code of
the analyzed apps. They detected seven anti-patterns three of
them are OO anti-patterns and four are mobile anti-patterns.
34
Overview
4.4 Related Works in anti-patterns detection in OWL

Ontologies
Several techniques were proposed in the literature for
detecting and defining anti-patterns types in software systems
generally and some in Ontologies. The automatic detection of
anti-patterns is a good way to keep the maintenance, easy the
evolution tasks and improves usability and software quality.
According to [57] and [58], they proposed the use of

Bayesian Belief Networks to detect 3 anti-patterns which are
Blob, Functional Decomposition, and Spaghetti Code using
machine learning techniques.
 In [59], they detected 29 anti-patterns, 13 of them are
design’s anti-patterns and 16 are lexical anti-patterns. They
proved that classes containing design’ anti-patterns only are more
change- and fault-prone than classes with lexical anti-patterns
only.
In [60], they introduced the "Arcan" tool which is written
in Java 8 to detect architectural anti-patterns. "Arcan" is used to
support the automatic analysis of software architecture through a
graph representation of data, providing support during the
software development and maintenance processes.
In [61], they introduced multi-objective genetic
programming (MOGP) to find the best metrics that increase the
35
Overview
detection of smells examples.

 On the other hand, [62] proposed DÉCOR which contains
a consistent vocabulary about code-smell to specify Smells. The
descriptions of the smells are then converted to detection rules.
This approach has detected only four design code-anti-patterns
which are the Blob, functional decomposition, spaghetti code, and
Swiss-army knife.
Several techniques for detecting Ontology anti-patterns can

be divided into two main branches: Code smells detection and
design smells detection.
According to [63], they presented iSPARQL framework to

detect four anti-patterns in the code of the OWL Ontologies. The
detected smells were Alien spider, God Class, Orphan method
query and long parameter list smells.
 In [64], they presented OCEAN to detect code anti-
patterns from the source-code of Ontology models and the
production of Ontological individuals that represent code smells.
OCEAN detected two code anti-patterns which are God Class and
Brain method.
 According to [65], they presented OntoUml to detect
semantic design anti-patterns. Their approach focused on the
design anti-patterns that cannot be detected as modeling errors.
36
Overview
They detected seven semantic anti-patterns in the design of the

OWL Ontologies.
In [66], they detected nine anti-patterns in the design of
Ontology. They classified them into three groups which are
Logical anti-patterns, Non-logical anti-patterns and Guidelines
anti-patterns.
Chapter (5)
Reverse engineering approach for improving
the quality of mobile application
5.1 Introduction
One of the most important things in the development of the

software systems is the software quality raising. The success of
software design depends on the availability of quality elements
such as maintainability, manageability, testability and
37
Overview
performance. These elements are adversely affected by anti-

patterns.
According to [21], Engineering is the process of designing,

manufacturing, assembling, and maintaining products and
systems. Engineering has two types, forward engineering and
reverse engineering.
Mobile apps are written in java. So for reversing java code

and generating UML class diagram of the app, we are looking for
a UML tool that supports the reverse and forward engineering of
the java code in addition to the ability of validation of the anti-
patterns.
5.2 UML modeling tools and Software Engineering
UML is a graphical modeling language that is widely used

by systems based on object-oriented programming. UML
provides a set of diagrams for modeling and designing the
systems to be developed.
In the proposed study, we first have chosen to address the

ability of the tools to reverse and generate the UML class diagram
of the java source code. This leads us to the first question:
38
Overview
RQ1. Does all UML tools support the reverse engineering

Java Code?
To answer this question, the research performed a study on 9

UML tools which are: ArgoUML, StarUml, Gaphor, UMLet,
yEd, Violet UML Editor, Papyrus, Bouml and Modelio. Table 5.1
shows the ability of each tool for reversing (RE) and generating
UML class diagram followed by generating the java code
(Forward engineering (FE)) of the systems and also the reversed
elements.
Table 5.1. UML tools support Reverse Engineering Java Code
Reversed FE RE
UML Tools No.
elements (Java code) (Java code)
√ √ √ ArgoUML 1
√ √ √ StarUml 2
× × × Gaphor 3
× × × yEd 4
Classes × √ Violet UML Editor 5
√ √ √ Papyrus 6
√ √ √ Bouml 7
√ √ √ Modelio 8
39
Overview
Classes √ √ UMLet 9
Table 5.1 shows that (ArgoUml, StarUml, Bouml, UMLet,

Papyrus and Modelio) UML tools support the software
engineering (reverse and forward).
The tool that has the sign (√) has the functionality for
making the process while the tool has the sign (×) does not have
it. So not all UML tools support the engineering process.
In addition to that, Table 5.1 shows the generated class

diagram components via using the 9 tools. The main components
of the class diagram are the classes and the relations between
them. Every class has its own attributes and operations. The
relations may be associations, aggregations or compositions. So
reversing the source code and generating the class diagram may
not generate all system components. It depends on the used UML
tool. The tools (ArgoUml, Bouml, Papyrus, Staruml and Modelio)
only have the functionality of reversing the java code and
reversing all the class diagram components.
Now, after we have the class diagram of the model, the

validation of the model is required.
RQ2. For validating the generated model against the anti-
patterns, is it available for all UML tools?
40
Overview
From Table 5.1, we have the tools (ArgoUml, Bouml,

Papyrus, Staruml and Modelio) that have the ability to do both
reverse and forward engineering and also generate all components
of the class diagram. The research found that ArgoUml and
Bouml has no functionality in validating the model, while
Papyrus can validate only stereotypes using OCL constraints. The
evaluation of anti-patterns detection is in Table 5.2.
Table 5.2. The evaluation of the detection process between tools

Detection
Results
Tools
Class
#
Attributes
Operations
stereotypes
Association
of
appearances
Elements
ArgoUML X x x x x x x
StarUml √ √ √ √ √ √ x
41
Overview
Papyrus X x x x √ √ √
Bouml X x x x x x x
Modelio √ √ √ √ √ √ √
The research found that Staruml and Modelio can validate

the model against the anti-patterns according to some rules that
guarantee the correctness of the model. But the validation using
StarUml just gives us the number of the anti-patterns exist in the
model. We have no idea about the location, the type of them or
the model elements that have these anti-patterns as in Figure 5.1.
Figure 5.1. The validation via using StarUml

As a result, the research has only the Modelio tool to
validate the anti-patterns. So not all UML tools can validate the
model against the anti-patterns. But the research will assess if it
42
Overview
can validate the class diagram which was generated from the
mobile app or not.
RQ3. Can UML tools detect the Mobile apps' anti-

patterns?
To answer this question, the research will make an
experiment of reverse engineering the java code of the mobile app
to generate the class diagram using Modelio. In addition to that,
we will examine the validation of the model.
5.3 The 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. The proposed method for anti-
pattern detection consists of three main phases and is summarized
in Figure 5.2.
43
Overview
Figure 5.2. The proposed detection method

 The first phase presents the process of reformatting the
mobile application to Java format.
 The second phase presents the reverse-engineering process.
We used RE to reverse Java code of mobile applications and
generating UML class diagram models. Additionally, a lot of
design anti-patterns are detected.
44
Overview
 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 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, it
will be yield one integrated application for doing both services
with minimum anti-patterns.
We will present in details the rationale provided for why this
integration is needed as an optional phase if we need.
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 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 don't change. The advantage of the integration of
45
Overview
mobile applications is 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 improve pattern combines
all advantage without anti-patterns.
To clear our idea, we choose two homogenous applications
as "Viber" and "WhatsApp". They are the most popular
messaging and VoIP (Voice Over IP) applications. Both "Viber"
and "WhatsApp" are similar in services, features, security, and
costs. Where, both are plenty to like, 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, to know which one is better for the
developer to be a pattern for his refinement? We found that
"Viber" has been offering both video and voice calling for a far
longer time than "WhatsApp" and has hidden chat feature. Also,
"Viber" lets you play a list of games you can play along with
other "Viber" contacts. But, "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.
46
Overview
In the case of heterogonous integration applications, the

developer, for example, may want to develop a new health care
hybrid application. From website "free apps for me"
https://freeappsforme.com/ developer can find at least 7
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 developer merges two applications
one for measuring blood pressure as "Smart Blood Pressure" and
the other for controlling diabetes as " OneTouch Reveal
application, the integration phase will yield one integrated
application for doing both services. That is with minimum anti-
patterns. Then the developer can add the new relations between
these diseases 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.
47
Overview
The first integration method is after decompiling the APK of the

applications. We use reverse engineering methodology for
generating one UML class diagram of both applications. Then we
starts the detection of the anti-patterns process for the integrated
application as in Figure 5.3.
48
Overview
Figure 5.3. Merging of the two class diagrams of mobile applications

The second integration method is through merging the OWL
ontologies of both applications using Prompt the plugin in protégé
the editor of Ontology as introduced in Figure 5.4.
Figure 5.4. The integration of OWL ontologies of the mobile apps

using "Prompt"
The Implementation 5.3.1
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,
49
Overview
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 as in
Figure 5.5.
Figure. 5.5. The first phase of the proposed method: Generating Java
Classes
• The Second Phase: We used a RE approach for generating

UML class diagram models of the mobile applications. The
50
Overview
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 as in Figure 5.6.
F
i
g
u
r
. e
5
.
6. The Second phase of the proposed method: Generating UML class
diagram and anti-patterns detection in Modelio
• 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 (UFO). 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'
51
Overview
ontology in Protégé. Protégé is the broad ontology editor

commonly used by many users as in Figure 5.7.
Figure 5.7. The third phase of the proposed method: Semantic anti-
patterns detection
 The integration phase (the forth 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 5.8 shows the both
applications "Viber and WhatsApp" components before
52
Overview
merging. Figure 5.9 shows the integrated application; Figure

5.9 has 3 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.
Figure 5.8. The OWL ontologies before merging
53
Overview
5.4 Empirical Validation

We assess our approach by reporting on the results we
obtained for the detection of 15 anti-patterns on 29 popular
Android apps downloaded from the APK Mirror.
5.4.1 Applications under analysis

We downloaded the mobile apps in Table 5.3 from APK
Mirror. We also considered some popular apps such as YouTube,
WhatsApp, play store and Twitter. The size of the apps includes
the resources of the application as images and data files. The
research study included the identification and repeating of the
anti-patterns across different domains and different sizes.
54
Overview
Table 5.3. The description of the mobile apps under analysis

Description of use Downloads Size(MB) Mobile App Name
Libraries & Demo 1.076.791 3.14

Test DPC 4.0.5
Antivirus Engine & Mobile
1.364 20.71 Avast 6.5.3 Security
Security
Communication 1.537 31.59 Free-Calls-Messages
Photography 497 11.31 Beautiful Gallery 2.3
Google Play Store 6.950 14.17 Play Store 9.3.4
Personalization 9.730 2.29 Wall Paper 1.2.166
privacy protection and parallel
822 2.34 Oasis-Feng/Island 2.5
running
Entertainment 22.043 18.81 Netflix-5-4-0-Build
Remainder 3.612 9.36 Remainder 1.4.02
Samsung Sound picker 2.142 3.9 Sound-Picker 8.0.0
Air command 1.747 0.82 Air-Command 2.5.15
Diet plan, food diary, macro
Lifesum-Healthy-
calculator, calorie counter & 3.594 31.4
Lifestyle
healthy recipes
Background-Defocus
Photography 2.960 3.45
2.2.9
Gasbuddy-Find-Cheap-
Travel and Local 334 29.64
Gas
Soundcloud -Music-
Music and Audio 2,066 33.2
Audio.03.03
Monitor the upload and Network-Monitor-Mini
307 2.88
download speed per second 1.0.197
Messaging app Snapchat 383.765 18.77 Casper Android 1.5.6.6
Communication 260 70.25 Line 8.4.0
Medical 36 6.96 Diagnosises
Communication 1.628 18.4 Viber 7.7.0.21
Communication 28.978 25.81 WhatsApp 2.17.235
Communication 20.423 40.62 Firefox 56.0
Blue- Email And
Productivity 203 43.2.4
Calendar 1.9.3.21
Google Camera
Photography 211.822 36.48
5.1.011.17
Video Players 23.667 24.13 YouTube 13.07
Communication 609 23.09 True Caller 8.84.12
Photography 10.712 17.61 Samsung Gallery 5.4.01
News and Magazines 694 35.82 Twitter 7.48.0
Chrome Browser
Communication 29.129 41.51
66.0.3359
55
Overview
5.4.2 Case Study

For explaining the proposed approach, we present the
snapshot of it in certain case study 'Play Store App'. Figure. 5.10
shows the generated java classes after using jd-gui decompiler
tool. Using reverse engineering, we generated the UML class
diagram model of the java classes in Modelio including its'
(classes, subclasses, class' attributes, operations, and the
associations between them) as in Figure. 5.11.
Figure. 5.10. The generated java classes of the mobile app
56
Overview
Fi
g
e. ur
5.
. 11
he T
cl
s as
di
ag
m ra
hi
er
ar
al ch
of
e th
mobile App
After generating the UML class diagram of the app in

Modelio, we detected 18 anti-patterns and 96 warnings anti-
patterns in the 'play store app'. The number and the location of the
anti-patterns are determined as in Figure 5.12.
57
Overview
Figure 5.12. The detected anti-patterns using Modelio
The detected anti-patterns are (without repeat) 10 anti-

patterns: ("NameSpaces have the same name (NHSN)",
"NameSpace is Leaf and is derived (NLAD)", "NameSpace is
Leaf and is abstract (NLAA)", "Generalization between two un
compatible elements (GBUE)", "A public association between
two Classifiers one of them is public and the other is privet
(PACPP)", "Classifier has several operations with the same
signature (CHSO)", "Classifier has attributes with the same name
(CHSA)", "The status of an Attribute is abstract and
class(SAAC)", "A destructor has two parameters (ADHPS)" and
"MultiplicityMin must be inferior to MultiplicityMax
(MMITMM)" anti-pattern as in Figures 5.13, 5.14, 5.15, 5.16,
5.17, 5.18, 5.19, 5.20, 5.21, 5.22.
58
Overview
Figure. 5.13 NameSpaces have the

same name Figure. 5.14 Generalization
between two un compatible
elements
Figure 5.15 A public association Figure 5.16 Classifier has several

between two Classifiers one of them is operations with the same signature
public and the other is privet
59
Overview
Figure 5.17 NameSpace is Leaf and is Figure 5.18 Classifier has attributes
derived with the same name
Figure 5.19 A destructor has Figure 5.20 NameSpace is Leaf and is

parameters abstract
Figure 5.21 MultiplicityMin must be inferior to MultiplicityMax
60
Overview
Figure 5.22 The status of the attribute is abstract and class
5.4.3 Detection of semantic anti-patterns
After detecting the anti-patterns by using Modelio, we

converted the model into enterprise architecture file (EA) file then
converting it to OLED file. OLED is the editor of OntoUML.
OntoUML supports the validation of the semantic anti-patterns. It
has a list of 21 semantic anti-patterns. In "play store app" OLED
file, OntoUML detects the existed anti-patterns as in Figure 5.23.
Figure 5.23. The semantic anti-patterns in "play store app"
61
Overview
The detected ant-patterns are (16 Association cycle anti-

patterns (AC), 6 Binary relation with overlapping ends anti-
patterns (BinOver), 2 Imprecise Abstraction (ImpAbs) anti-
patterns and 41 Relation Composition anti-patterns (RC).
5.4.4 Detecting of OWL Ontology anti-patterns

After anti-patterns validation in OntoUML editor, OLED
supports the transformation of OLED file to the OWL Ontology
i.e. allows the automatic conversion from UML to OLED to
OWL. In addition, Ontology and UML are both object oriented
models, so they have similar meanings.
After we generate the OWL ontology, we checked the

inconsistency anti-patterns by the Reasoner of Ontology editor
(Protégé). The reasoner detected 28 inconsistency anti-patterns as
in Figure 5.24. The reasoner detected the anti-patterns
(NameSpaces have the same name, Classifier has several
operations with the same signature, Classifier has attributes with
the same name, MultiplicityMin must be inferior to
MultiplicityMax) which were detected by Modelio and detected
the anti-pattern (Association Cyclic) which was detected via
OntoUML.
62
Overview
Figure 5.24. The result of the reasoner detection
The treatment or correction of the detected anti-patterns is

classified into the following:
• Modelio presents the solutions as a list of recommendation
which developer can do them manually. In this case study,
Table 5.4 presents the anti-patterns and the method of
correction.
• OLED presents automatic solutions to correct the anti-patterns
which we list in Table 5.5.
• Reasoner in Protégé presents all inconsistency anti-patterns
where, Reasoner gives just the location of the inconsistent
63
Overview
classes as in Figure 5.26.

Table 5.4 Ten Modelio anti-patterns and their method of correction
The Anti-pattern The method of correction

Change the name of the conflicting
NameSpaces have the same name. NameSpaces
Make the NameSpace non-final.

NameSpace is Leaf and is derived.
NameSpace is Leaf and is abstract. Make the NameSpace non-final.
Change the source or the target in order to link
Generalization between two un compatible
two compatible elements.
elements.
A public association between two Classifiers one

Change the visibility of the target class to
of them is public and the other has different
public.
visibility.
Classifier has several operations with the same Rename one of the Operations or change their
signature. parameters.
Classifier has attributes with the same name. Rename the Classifiers Attributes.
Change the value of the minimum multiplicity
MultiplicityMin must be inferior to
to be less than the maximum multiplicity.
MultiplicityMax
The status of an Attribute is abstract and class at Set only one of the statuses to true.
the same time.
A destructor has parameters. Remove these parameters, or remove the
destructor stereotype from the method.
Table 5.5. The OntoUML anti-patterns and the method of correction
The anti-pattern The method of correction

Association Cycle. Chang the cycle to be closed or open cycle.
Binary relation with Declare the relation as anti-reflexive, asymmetric and

Overlapping Ends. 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
64
Overview
specialization, a subset, a redefinition or disjoint with

relation SR
5. 5 Results and Discussion
5.5.1 Results of anti-patterns detection
We applied the proposed method on a sample of 29 Android

applications which we downloaded from the APK Mirror. The
results presented 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
1262 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 5.6. 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.6. The occurrences of the anti-patterns
Total # of Percentage of occurrences

The Group
occurrences across models
9 0.7131% Anti-patterns in Attributes
91 7.210%
Anti-patterns in Namespaces
5 0.396%
Anti-patterns in Operations
554 43.898%
Anti-patterns in Associations
603 47.78% Anti-patterns in the Class
65
Overview
1262
Total
We found that "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 as in Chart 5.1.
Chart 5.1. The visibility of anti-patterns groups
Table 5.7 shows the detected anti-patterns in each

application using the proposed method and the total number of
anti-patterns in the 29 mobile applications.
66
Overview
Table 5.7. The detected anti-patterns in the 29 mobile applications
67
Overview
We measured the correlation 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 5.8 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.
68
Overview
Table 5.8. The correlation between anti-patterns groups
Anti-patterns Correlation Coefficient(r)
Attributes & Namespaces -0.049
Attributes & Operations 0.884
Attributes & Associations 0.196
Attributes & Classes 0.342
Namespaces & Operations -0.060
Namespaces & Associations -0.121
Namespaces & Classes 0.010
Operations & Associations 0.345
Operations & Classes 0.267
Associations & Classes 0.070
There was a strong negative correlation (-.1) between

"Namespaces anti-patterns" and "Association anti-patterns". Also,
a strong positive correlation (.8) between "Attributes anti-
patterns" and "Operations anti-patterns".
69
Overview
Also, we analyzed the correlation between the detection

tools of the proposed method as in Table 5.9. The greatest
correlations were between Modelio and Protégé.
Table 5.9. The correlation between detection tools
Correlation
Specification Systems
Coefficient(r)
There is a reverse correlation

between Modelio and 0.032- Modelio & OntoUml
OntoUml.
There is a direct correlation
0.966 Modelio & Protégé
between Modelio and Protégé.
There is a reverse correlation
between Protégé and OntoUml 0.060- Protégé & OntoUML
editor.
70
Overview
For assessing the correlation result 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 the 29 mobile applications as in Figure 5.25. It shows the
similarity between both the means of Protégé and Modelio as the
result of the correlation.
71
Overview
Figure 5.25. The similarities between the means of the detection

tools
Now, we want to answer statistically the question “Are we

need to use the three tools?” And "is there a relation between
them?"
For explaining the relation among the three tools and the
anti-patterns' groups, we used the analysis of variance ANOVA
test. That is to determine whether there are any statistically
significant differences between the means of anti-patterns
detection by each one of the tools. Also, if there is any relation
between anti-patterns groups and the features of mobile
applications.
72
Overview
We used 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.
ANOVA proved statistically that there was no concerning in

the features or the specifications of the applications. That is from
low F-value means the group means are close together relative to
the variability within each group.
5.5.2 The results of Integration phase
We separated the result of integration phase because it's 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
73
Overview
that semantic integration decreases the accuracy of anti-patterns

in mobile applications. Table 5.10 shows the number of anti-
patterns in each application in the integration case study (Viber &
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.
Table 5.9. Comparison between the numbers of anti-patterns after

"integration using "Modelio" and "Prompt
The
of anti- #
The of anti- # of anti- # total
patterns in the
integration patterns in patterns in
integrated
method Viber WhatsApp
application
Integration
UML by 49 8 58 115
Modelio
Integration
OWL
51 64 13 128
Ontology by
Prompt
We used the formula (1) to calculate the increasing percent

between the two values:
Percent increase = [(second value – first value)/first value ] *100

(1)
Substitute in formula (1) by the first value of the total

number of anti-patterns detected by using Modelio = 115 and the
74
Overview
second value of the total number of anti-patterns detected by

using Prompt = 128.
We found that 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”.
75
Overview
76
Chapter (6) ONTOPYTHO: Python Framework for
improving big Ontologies Quality
Chapter (6)
ONTOPYTHO: Python Framework for
6.1 Introduction
After the integration between OWL ontologies of the mobile

applications and being one ontology, we found that some cases of
them became big ontologies. These cases can't be manipulated or
also verified using the reasoner of Ontology. In addition to that,
Ontology is the core of the semantic applications, so the quality of
them has a direct proportion with Ontology. It impacts directly on
the long life of the semantic applications.
In large Ontologies systems, we need to measure system

components to control its complexity. On the other hand,
reasoners cannot deal with large Ontologies or cannot detect all
the smells. They cannot handle even all the errors resulting from a
timeout. Reasoners of the Ontology verify the design quality to
get consistency systems. However, reasoners verification against
some structural smells is not found.
The proposed detection method in chapter 5 detected 15

structural and semantic anti-patterns. But there are different
negative effects in the design of Ontology' classes as Blob, Lazy
77
Class, Large Class, and Singleton which did not be detected using
the proposed method. These negative effects called bad smells or
anti-patterns. However, detecting these smells is not also
supported in any Ontology editor.
So, we were looking for a method that can detect these anti-
patterns and also manipulated the ontology for correction
purpose. The proposed detection method can detect structural
smells without using the reasoners and whatever the Ontology
size.
6.2 Ontology and design smells
Over the last few years, semantic advances got to be vital in

numerous areas of computer science. Semantic technologies have
a wide range of applications, including cloud security
engineering, decision support, search and semantic integration
[42], [43], [44], and [45]. The most important technology is the
semantic web technology which makes web content
comprehensible for both humans and machines. All semantic
applications are based on Ontology which presents the semantic
structure of the applications’ domains.
Ontological smells are those structures that reflect analyzed

problems of OWL Ontologies causing inconsistencies, bad
reasoning performance and many other quality problems [66].
78
Smells have many other terms as design defects, design flaws,

pitfalls, and anti-patterns [67].
Generally, Ontology is not big but sometimes there are big

Ontologies as GO (Gene Ontology). According to [68], protégé
needs at least 4G of RAM to manipulate the GO Ontology. Also,
according to [69], they showed that using Gowinda to detect
unbiased enrichment in gene sets from big datasets will cause
memory consumption. As GO needs about 1.2 GB of RAM and
may be increased according to the number of SNPs when be
analyzed using “Gowinda”. On the other hand, according to [70],
they found that there is a correlation between the existence of
smells and memory problems.
According to [71], they classified the detection strategies

into three types which are software metrics, design patterns, and
predefined rules. The proposed method uses the software metrics
strategy. In software metrics techniques, the smells are detected
using metrics and their thresholds. The proposed method
calculates the software design metrics using simple protocol and
RDF query language (SPARQL) and Python programming
language. The greater the number of attributes and operations the
greater the design complexity and greater low quality. Earlier
studies [72] showed that for avoiding software complexity and
79
low quality, we should measure and control system components.

The detection process of the design smell usually involves finding
the fragments of design which violate these software metrics.
6.3 Ontology Smells models
This section presents the different Ontology models of class

smells. We are interested in smells in Ontologies’ classes. The
class is the most vital component of Ontology components.
Without it, there is no structure. The simulation visualizes the
models using Protégé platform.
6.3.1 Blob smell model

Blob smell is characterized by a class that has a great
number of both attributes and operations and has the most
functionalities. Figure. 6.1 shows the OWL Ontology model for
presenting the Blob smell. We can see class1 which has a great
number of both object properties (operations) and “datatype”
properties (attributes). Other classes just have a low number of
operations and all the range of their operations is class1.
80
6.3.2 Lazy Class smell model
The Lazy class smell is a leaf class which has no subclasses

and has a little number of operations may be zero. We can
consider it a data class. Figure 6.2 shows the OWL Ontology
model for presenting the Lazy class smell. It contains four classes
(Class1, Class2, Class3, and Class4). All the classes have
operations (object properties) while Class1 does not has any
operations, in addition to that, it is a leaf class, so it is classified
as a lazy class.
81
Figure.
6.2. The OWL
Ontology
representing the Lazy class smell
6.3.3 Large Class smell model
Large class smell characterized by a great number of

operations or functionalities and has a little number of attributes
or does not have any attributes. Figure 6.3 shows the OWL
Ontology model of the large class smell. The model contains 4
classes; all of them have object properties. So, none of them is a
data class which implying that Blob smell is not satisfied here.
For that, the class here is classified as a large class.
82
Figure 6.3. OWL Ontology representing Large Class Smell
6.3.4 Singleton Smell model
Singleton smell is a design smell that restricts the number of

instances of the class to only one instance. The class has only one
instance and operation for retrieving this instance. Figure 6.4
shows the OWL Ontology for presenting singleton class smell. It
contains (Class1) which has an object property (nn:get_instance)
and only one instance(nn:Instance). The domain and the range of
the object property are the same which implies that the operation
will get the instances from the same class (Class1) as in (1).
While (2) implies that the class has only one instance and (3)
implies that the operation will retrieve that instance.
nn:Class1 ----- nn:get_instance(Domain>Range)nn:Class1

(1)
nn:Class1 ----- has instance ----  nn:Instance
(2)
nn:Class1 ----- nn:get_instance ---- nn:Instance
(3)
83
Figure 6.4. OWL Ontology representing the Singleton smell
6.4 The Proposed detection method "ONTOPYTHO"
This section presents the pseudo code of "ONTOPYTHO"

Algorithm 1; the proposed Ontology smells detection Algorithm.
ONTOPYTHO is used to detect classes’ smells in large

OWL Ontologies. The proposed method is based on merging
Python programming language and RDF query language
(SPARQL). Python is a high-level programming language which
is considered as an interpreter with dynamic semantics. It reduces
the cost of the program maintenance, supports modules and
packages, which implies code reuse [73].
The proposed method deals with Ontology’ design, not the
code or the converted ontology. That is to guarantee that no
84
missing information or parts of the Ontology’ structure according

to the conversion or the code generation. Also, Python has
“rdflib” library to handle big Ontologies as GO and give the
proposed approach the ability to evaluate it without needing to
manipulate it with Ontology editors. Also, adding the proposed
approach to any Python library can improve the quality of the
Ontologies before using in the semantic web.
ONTOPYTHO (Ontology smells detection Algorithm) uses

SPARQL queries to calculate Ontology metrics and to produce a
report of the detected smells and model analysis.
Algorithm 1. Class smells detection’ algorithm
Input: OWL Ontology O, Threshold for attributes x and operations y.

Output: a list of detected smells
1 Insert Ontology O,
2 Counter n is a number of classes in O;
85
For (C > =1 && C < = n):

3 A getNumOfAttributes;
4 P getNumOfOperations;
5 I getNumOfInstances;
6 ð getOperationValue;
7 run Blob query Q1;
8 if Blob classes > =1:
9 print “Blob detected”;
10 else print (" ");
11 run Lazy Class query Q2;
12 if Lazy Classes > =1:
13 print “ Lazy class detected”;
15 run Large Class query Q3;
16 if Large Classes > =1:
17 print ("large class detected");
19 run Singleton query Q4;
20 if Singleton classes > =1:
21 print (" singleton detected");
23 End.
The proposed approach pre-process is analyzing and parsing

OWL Ontology model. This process uses Python libraries as
“rdflib” library. Then synchronously, the four SPARQL queries
run. The four SPARQL queries are:
• Blob detection SPARQL Query Q1.

• Lazy class detection SPARQL Query Q2.
• Large class detection SPARQL Query Q3.
• Singleton detection SPARQL Query Q4.
86
Finally, the visualization process displays the report of the

detected smells in the OWL model.
 Blob detection SPARQL Query
Using SPARQL query Q1, we detected Blob smell and

retrieve Blob classes from the OWL Ontology. The query code as
shown in Algorithm 2. This query returns the Blob classes by
counting their number of operations and their number of
attributes. This detection process has two restrictions. The first
restriction indicates that the number of operations must excessed
than "x". While the second restriction indicates that the number of
attributes must excessed than y. Both "x" and "y" are the accepted
threshold which class should have. This query could be general.
So, according to developers’ accepted thresholds, they can detect
Blob classes.
Algorithm 2. (Q1. Blob detection SPARQL query)
 PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>
 PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
 PREFIX owl: <http://www.w3.org/2002/07/owl#>
 SELECT ?Blob_classes (count(?d) as ?NO_Operations)
(count(?A) as ?No_Attributes)
 where{{?d a owl:ObjectProperty.
 ?d rdfs:domain ?Blob_classes} UNION
 {?A a owl:DatatypeProperty. ?A rdfs:domain ?Blob_classes} }
 group by ?Blob_classes having(?No_Operations>?x && ?
No_Attributes>?y)
 Lazy class detection SPARQL Query
Using SPARQL query Q2, we detected the lazy class smell

as shown in Algorithm 3. The query retrieves the Lazy classes
87
defined by two restrictions. The Filter part of the query presents

the restrictions. The restrictions indicate that Lazy classes have
not any operations and they have leaf classes.
Algorithm 3. (Q2: Lazy Class detection SPARQL Query)
 SELECT distinct ?LazyClasses

 WHERE {?LazyClasses a owl:Class.
 Filter NOT EXISTS{{?h a owl:ObjectProperty.
 ?h rdfs:domain ?LazyClasses.} UNION{?subject
rdfs:subClassOf ?LazyClasses.} }}
 group by ?LazyClasses
 Large class detection SPARQL Query

Using SPARQL query Q3, we detected the large class smells
as shown in Algorithm 4. The query retrieves the large classes.
That is by counting process of the number of operations “?
No_Op”. The restriction implies exceeding the number of
operations more than “y”. Where “y” is the accepted threshold for
the developers. Synchronously, the Large classes might have
datatype properties or not. We concerned with the number of
object properties.
Algorithm 4. (Q3. Large class detection SPARQL Query)
 SELECT ?Large_classes (count(?d) as ?No_Op)
88
 where{?d a owl:ObjectProperty.
 ?d rdfs:domain ?Large_classes.}
 group by ?Large_classes having(?No_Op>?y)
 Singleton detection SPARQL Query
The SPARQL query Q4 for detecting the Singleton smell as

shown in Algorithm 5. The query Q4 retrieves the singleton
classes under three restrictions. We have two Filters. The first
restriction in the first Filter for indicating that both the domain
and the range of the operation are the same. The second Filter
indicates that the retrieved instance is an instance of the same
class that contains the operation. The last restriction is for
indicating that the class has only one instance.
Algorithm 5. (Q4 Singleton detection SPARQL Query)
 SELECT ?Sing_classes
 where{?d a owl:ObjectProperty.
 ?d rdfs:domain ?Sing_classes.
 ?r rdfs:range ?Sing_classes.
 filter (?d=?r).
 ?in rdf:type ?Sing_classes.
 filter exists {?o ?p ?d}.
 ?A a owl:DatatypeProperty.
 ?A rdfs:domain ?Sing_classes.}
 group by ?Sing_classes
 having(count(?A)=1)
6.5 Experimental Evaluation
89
In this section, we assess how well the proposed approach

ONTOPYTHO can predict the quality of OWL Ontology design.
We assess our approach by applying it on twelve popular OWL
Ontologies which are considered as big Ontologies. We
downloaded them from Github, [74], and [75]. The size of the
Ontologies includes all Ontology components. Table 6.1 shows
the OWL Ontologies features. The random sample of twelve
Ontologies in different fields as lexicons, Chemistry, Biology,
Anatomy, Industry, and bioinformatics. The research study
includes the identification and repeating of the smells across
different domains and different sizes.
Table 6.1
Description of Owl Ontologies under analysis
OWL
Specification Classes Size Ontology
Projects
90
739 dbpedia_2015-
2.32 MB
The DBpedia datasets, each release of 10.owl
this Ontology corresponds to a new
release of the DBpedia data set which 754 2.36 MB dbpedia_2016-
contains instance data extracted from 04.owl
the different language versions of
dbpedia_2016-
Wikipedia 760 2.37 MB 10.owl
An Ontology for describing the Gene Ontology

61714 171 MB
function of genes and gene products (go.owl)
Industry Foundation Classes IFC IFC2X3_Final.o

Ontology 1149 3.18 MB wl
EDAM is an Ontology of
bioinformatics types of data including
3379 3.01 MB EDAM.owl
identifiers, data formats, operations,
and topics.
Gazetteer, a gazetteer constructed on

10144 590 MB Gaz.owl
Ontological principles
Chemical Entities of Biological

Interest. A structured classification of
molecular entities of biological interest 32288 471 MB chebi.owl
focusing on ‘small’ chemical
compounds.
The core repository for the FOODON
6556 7.21 MB Foodon.owl
food Ontology project
human-phenotype-Ontology, Ontology
for the description of human clinical 47015 95.3 MB hp-full.owl
features
Xenopus Anatomy Ontology. Anatomy
and development of the African clawed xao.owl
1735 4.26 MB
frog (Xenopus laevis).
Zebrafish anatomy and development
Ontology. A structured controlled
3200 8.27 MB Zfa.owl
vocabulary of the anatomy and
development of the Zebrafish.
91
For explaining the proposed approach, we display a part of

the result of applied ONTOPYTHO on the ‘dbpedia_2015-10.owl
‘in Figure 6.5.
Figure 6.5. The result of ONTOPYTHO on the case study
6.5 Results and Discussion
92
After applying ONTOPYTHO on the OWL Ontologies in

Table 6.1, we detected the smells as presented in Table 6.2. The
proposed approach detected 3 smells which were appeared
117495 times. We can note that lazy class smell is the most
detected smell while Singleton smell has not been detected. Both
Blob and large class smells have a little appearance in the
Dbpedia versions. They decreased in the new versions. The Lazy
class smell is the most appeared one. It increased more and more
in the new versions as in Figure 6.6.
Table 6.2
Design smells per OWL Ontologies
Smells
OWL
Large Lazy Blob
Singleton Ontologies
Classes Classes
0 17 490 8 dbpedia_2015-
10.owl
0 14 502 7 dbpedia_2016-
04.owl
0 14 506 7 dbpedia_2016-
10.owl
Gene
0 0 44155 0
Ontology
(go.owl)
0 9 393 2 IFC2X3_Final
.owl
0 10 2742 0
EDAM.owl
0 7 10023 3
gaz.owl
0 18 12052 8
chebi.owl
93
0 13 5500 5
foodon.owl
0 8 36735 4
hp-full.owl
0 4 1515 0
xao.owl
0 0 2724 0
zfa.owl
94
Figure 6.6. The appearance of the detected smells in the DBpedia OWL
.Ontologies versions
Table 6.3 summarizes the results we obtained for the

detection of 3 smells from our input 12 OWL Ontologies. The
integer value represents the number of occurrences of the smells
in the OWL Ontology. The percentage is the ratio of this value
according to the total number of smells. We noted that the same
class can be affected by more than one smell. For example, a class
can be a large class and a blob class simultaneously.
Table 6.3
ONTOPYTHO results for the detection of 3 smells in 12 OWL
Ontologies
Class Smells
Large Lazy Class Blob
Class
114 117337 44 Total
0.0970% 99.865% 0.0374% Ratio
From Table 3, we can note that Lazy class smell has the
maximum ratio of smells which is 99.865% while Blob smell has
the minimum ratio which is 0.0374%. But is there any relation
between the three smells?
95
The analysis of the relation between class’ smells types

means the determination of the relation between Ontology’s
concepts. So, we used a statistical analysis package as SPSS
(Statistical Package for the Social Sciences) to analyze the
correlation (Pearson correlation coefficient) between the three
detected smells. We found that the highest correlation is between
Blob and Large Class’ smells as the Pearson correlation
coefficient between them equals 0.889 i.e. there is a strong
correlation between them. This means that the presence of one
means the presence of the other by a large percentage. While the
correlation between Lazy class smell and the Blob smell equals
0.276, and between Lazy class and Large-class equals 0.221;
which means that there is a low correlation between them. This
means that the presence of one does not imply the presence of the
other. The SPSS Pearson correlation coefficient matrix is shown
in Table 6.4.
Table 6.4
The SPSS Pearson correlation coefficient matrix between the class’
smells.
96
Figure 6.7 assessed the similarity between both the means of

Blob and Large-class smells like the result of the correlation.
Figure 6.7. The similarity between the means of "Blob and Large-class"
smells and differences between them and "Lazy class" smell
Now, we need to address if there is a relation between the

number of classes and the presence of the smells. Table 6.5
illustrates the ratio between the number of classes and smells in
every OWL Ontology.
97
Table 6.5
The Ratio of smells according to the classes of OWL Ontologies
ratio Smells Classes OWL Ontologies
515 739
69.68%
dbpedia_2015-10.owl
69.36% 523 754
dbpedia_2016-04.owl
69.34%
527 760
dbpedia_2016-10.owl
71.54%
44155 61714
Gene Ontology (go.owl)
35.16% 404 1149

IFC2X3_Final.owl
81.44% 2752 3379

EDAM.owl
98.90% 10033 10144

gaz.owl
37.40% 12078 32288

chebi.owl
84.16% 5518 6556

foodon.owl
98
78.16% 36747 47015

hp-full.owl
87.55% 1519 1735

xao.owl
85.12% 2724 3200 zfa.owl
From Table 6.5, although “gaz.owl” does not has the

maximum number of classes, but it has the maximum ratio of
smells 98.90% in the classes of it. This leads us to the fact that the
number of classes in OWL Ontologies has no effect on smells
presence.
Now we will ask, is there a relation between the size of the

Ontology and smells existence?
To answer this question, we analyzed the correlation

between them using SPSS as in Table 6.6. We found that there is
no relation between them as the correlation coefficient is 0.283.
So, the size of the Ontologies has no effect on smells presence.
.Table 6.6
The SPSS Pearson correlation coefficient matrix between the size of the
.Ontologies and the smells
99
Comparing the proposed method "ONTOPYTHO" to other

techniques in the related work chapter [57], [58], [60], [61], [62],
[63], [64], [65], and [66]. The results of comparison are in Table
6. The related references detected smells generally in software
projects and some of them in OWL Ontologies. References [63],
[65], and [66] just detected smells in OWL ontologies. The
comparison included the number of evaluated software projects,
the number of detected smells, the software systems weather they
were OWL ontologies or not, and the number of occurrences of
smells.
Table 6.7
The comparison between "ONTOPYTHO" and other techniques
# #
Software #
occurrences Detected The techniques
Systems projects
of smells Smells
Bayesian Belief
19 - 1 2
Networks [57]
46 - 3 2 BDTEX [58]
1025 - 4 8 Arcan [60]
725 - 3 7 MOGP [61]
513 - 4 10 DÉCOR [62]
0 OWL 5 1 EvoOnt [63]
445 - 3 4 OCEAN[64]
3612 OWL 7 1 OntoUml[65]
0 OWL 11 0 OWL catalogue
100
[66]
ONTOPYTHO
117495 OWL 4 12
Proposed method
We can note that the proposed method has the maximum

number of the evaluated projects and the maximum number of
occurrences of smells which are 12 projects and 117495 times.
The proposed method detected smells "Blob, Lazy Class, and
Large Class" which were not detected by any other techniques.
But there are some cases in the other techniques which detected
just Blob as in [57], [58], [62], [63], and [64]. Lazy class was
detected only in one case in reference [64] as in Table 6.8. The
proposed method has the maximum number of Lazy Class smell
which is 117337 smells of ratio 99.865%.
.Table 6.8
The shared detected smells using proposed method and other
techniques
# #
The techniques
LazyClass Blob
Bayesian Belief
- 19
Networks [57]
- 13 BDTEX [58]
- 44 DÉCOR [62]
- 9 EvoOnt [63]
21 134 OCEAN [64]
ONTOPYTHO
117337 44
Proposed method
Finally, we recommend treating the detected smells by using

classification for large classes or Blob and distributing the
101
operations between the other classes and delete the lazy classes.
That leads to minimize the Ontology' size to be suitable to
manipulate it in any Ontology editors, save time, and minimize
storage.
102
Chapter (7) Conclusion and Future Work
Chapter (7)
Conclusion and Future Work
7.1 Conclusion
We want to build a hard and stable base generally for new
software projects and particularly for mobile applications.
Definitely, there are no mobile applications without anti-patterns;
we proposed two general methods for the detection of structural
and semantic anti-patterns.
The first method scopes on the design of UML class diagram
and the OWL Ontology of the mobile applications. The proposed
detection method is 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. This
method detected 15 structural and semantic anti-patterns. The
detected anti-patterns appeared 1262 in 29 mobile applications.
For evaluation of the proposed method, we applied it on a
sample of 29 mobile applications. 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
103
Protégé platforms. Also, there is no correlation between OLED

and Protégé and no correlation between Modelio and OLED.
Also, 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. It helps
developing a correct, consistent and coherent integrated pattern
that has few anti-patterns.
After the integration between the mobile applications and
becoming big ontologies, it was necessary to evaluate them to be
sure of their quality. So, we proposed the second detection
method.
The second detection method proposed ONTOPYTHO
approach for detecting the anti-patterns from big ontologies. The
proposed approach is based on the metric method via the
Semantic Web query language SPARQL and Python
programming language. The proposed approach provides the
ability to improve the quality of software systems represented in
the OWL Ontology format. The proposed ONTOPYHO was
applied on 12 OWL big Ontologies. The proposed approach
presented the method for detecting four design smells which are
Blob, Large class, Lazy class, and Singleton smells.
ONTOPYTHO detected three design smells which appeared
104
117495 times in the 12 OWL Ontologies. We found that there is a

direct relation between Blob and Large-class smells while there is
a reverse relation between them and the Lazy class smell. Also,
we found that both the size and the number of classes of the
OWL- Ontology has no effect in the presence of the smells. The
results showed that 69.24% of the classes are lazy classes. This
means that big OWL Ontologies are not big in their nature, but
because of theses lazy classes. So, detecting Lazy classes using
ONTOPYTHO approach and deleting them will reduce the size of
the ontologies. This consequently will allow reasoner check,
manipulation using any ontology editor like protégé and solves
the difficulty of using SPARQL queries directly according to the
Ontology editor plugin. Also, when ONTOPYTHO detects large
Ontology’ classes, users can divide these classes into subclasses.
The proposed approach provides the ability to measure the size
and complexity of the OWL Ontologies. Finally, the strong
correlation between large class and Blob smells leads to solve
Blob when solving large-class.
7.2 Future Work
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 design level is very useful and reduces some anti-
105
patterns in the code level, but we will refine a 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. Also,
we will insert the ONTOPYTHO into Python as a library. Finally,
we will analyze the reasons of the relation between Blob and
Large-class smells in Ontology and how can we avoid smells
happen.
106
Glossary
Concept Definition
Mobile Application A mobile application, most

commonly referred to as an app, is
a type of application software
designed to run on a mobile
device, such as a smartphone or
tablet computer. Mobile
applications frequently serve to
provide users with similar services
to those accessed on PCs.
Software Engineering An engineering discipline that is

concerned with all aspects of
software production.
Software Quality The more closely the software
product meets its requirements,
and those requirements meet the
wants and the needs of its
customers, the higher its quality.
Validation The process of evaluating software
107
to determine whether the products

of a given development phase
satisfy the conditions imposed at
the start of that phase. [IEEE-STD-
610]
Verification The process of evaluating software

during or at the end of the
development process to determine
whether it satisfies specified
requirements. [IEEE-STD-610]
Correctness The quality or state of being free
from error in addition, for each
input it produces the expected
output.
Ontology Engineering Ontological Engineering refers to

the set of activities that concern
the Ontology development
process, the Ontology life cycle, as
well as the methodologies, tools
and languages required for
building ontologies
Visualization It is any technique for creating

images, diagrams, or animations to
108
communicate a message.
Class Diagram In software engineering, a class

diagram in the Unified Modeling
Language (UML) is a type of static
structure diagram that describes
the structure of a system by
showing the system's classes, their
attributes, operations, and the
relationships among objects.
109
References
[1] Khomh, F., & Guéhéneuc, Y. (2018). Design patterns impact on software
quality: Where are the theories? 2018 IEEE 25th International
Conference on Software Analysis, Evolution and Reengineering
(SANER), 15-25.
[2] Sreeji, K. S., & Lakshmi, C. (2018). Dynamic Understanding of Software
System Using Structural and Semantic Based Detection of Design
Patterns and Antipatterns. Journal of Computational and Theoretical
Nanoscience, 15(9-10), 3037-3043.
[3] Matthew Stephan, James R. Cordy, “Identifying Instances of Model
Design Patterns and Antipatterns Using Model Clone Detection”,
Software Engineering (MiSE), (2015).
[4] Alexander, Christopher, “A Pattern Language”, Oxford: Oxford

University Press, 1977.
[5] Douglas Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann,
Pattern-Oriented Software Architecture, Patterns for Concurrent and
Networked Objects, Vol. 2, ISBN: 0471606952, John Wiley & Sons,
2013.
[6] Cambridge Semantic, Semantic Web Design Patterns at

http://www.cambridgesemantics.com/semantic-university/semantic-
web-design-patterns, accessed at (May 2019).
[7] Barbez, A., Khomh, F., & Guéhéneuc, Y. G. (2019). A Machine-learning

Based Ensemble Method For Anti-patterns Detection. arXiv preprint
arXiv:1903.01899.
[8] Martina Hodges, James O’Brien, Communicating the UX Vision: 13

Anti-patterns That Block the Good Ideas, ELSEVIER, (2015).
[9] Colin J Neill, Philip A. Laplante, Colin J. Neill and Joanna F. DeFranco.
Anti-patterns: managing software organizations and people.2nd Edition
Boca Raton, London, 2012.
110
[10] Nadia Nahar and Kazi Sakib, Automatic Recommendation of Software

Design Patterns Using Anti-patterns in the Design Phase: A Case Study
on Abstract Factory, 3rd International Workshop on Quantitative
Approaches to Software Quality (QuASoQ), (2015)
[11] Maged E. Elaasar, An Approach to Design Pattern and Anti-Pattern

Detection in MOF-Based Modeling Languages, Doctoral Dissertation,
Carleton University, Canada, (2012).
[12] M. Linares-Vásquez, S. Klock, C. McMillan, A. Sabané, D.

Poshyvanyk, YG. Guéhéneuc, Domain matters: bringing further
evidence of the relationships among anti-patterns, application domains,
and quality-related metrics in Java mobile apps. In Proc. of the 22nd
International Conference on Program Comprehension (2014)232-243.
ACM.
[13] F. Palomba, D. Di Nucci, A. Panichella, A. Zaidman, A. De Lucia,
Lightweight detection of Android-specific code smells: The aDoctor
project. In 2017 IEEE 24th International Conference on Software
Analysis, Evolution and Reengineering (SANER) (2017)487-491. IEEE.
[14] G. Hecht, R. Rouvoy, N. Moha, L. Duchien, Detecting antipatterns in
android apps. In Proc. 2015 of the Second ACM International
Conference on Mobile Software Engineering and Systems (2015)148-
149. IEEE Press.
[15] Alharbi, K., Blackshear, S., Kowalczyk, E., Memon, A. M., Chang, B.
Y. E., & Yeh, T. (2014, April). Android apps consistency scrutinized. In
CHI'14 Extended Abstracts on Human Factors in Computing Systems, 26
April – 01 May 2014; Toronto, Ontario, Canada. New York, NY, USA:
ACM. pp. 2347-2352. ACM.
[16] Joorabchi, M. E., Ali, M., & Mesbah, A. (2015, November). Detecting
inconsistencies in multi-platform mobile apps. In IEEE 26th
International Symposium on Software Reliability Engineering (ISSRE),
02 - 05 Nov. 2015; Gaithersbury, MD, USA. IEEE. pp. 450-460.
[17] Afjehei, S. S., Chen, T. H. P., & Tsantalis, N. (2019). iPerfDetector:

Characterizing and detecting performance anti-patterns in iOS
applications. Empirical Software Engineering, 1-30.
111
[18] Techopedia, Mobile Applications. Accessed at July 2019.
[19] Wikipedia, Android (operating system). Accessed at July 2019.
[20] Meier, R., & Lake, I. (2018). Professional Android. John Wiley & Sons.
[21] Zhao, Y. L., & Qian, Q. (2018). Android Malware Identification

Through Visual Exploration of Disassembly Files. International Journal
of Network Security, 20(6), 1061-1073.
[22] Venters, C. C., Capilla, R., Betz, S., Penzenstadler, B., Crick, T.,
Crouch, S., & Carrillo, C. (2018). Software sustainability: Research and
practice from a software architecture viewpoint. Journal of Systems and
Software, 138, 174-188.
[23] Liu, H., Li, B., Yang, Y., Ma, W., & Jia, R. (2018). Exploring the
impact of code smells on fine-grained structural change-proneness.
International Journal of Software Engineering and Knowledge
Engineering, 28(10), 1487-1516.
[24] Kessentini, M. (2019). Understanding the Correlation between Code

Smells And Software Bugs.
[25] Palomba, F., Di Nucci, D., Panichella, A., Zaidman, A., & De Lucia, A.
(2019). On the impact of code smells on the energy consumption of
mobile applications. Information and Software Technology, 105, 43-55.
[26] Hecht, G., Benomar, O., Rouvoy, R., Moha, N., & Duchien, L. (2015,
November). Tracking the software quality of android applications along
their evolution (t). In 30th IEEE/ACM International Conference
on Automated Software Engineering (ASE), 9-13 Nov. 2015; Lincoln,
NE, USA. Washington, DC, USA: IEEE, pp. 236-247.
[27] Chatzigeorgiou, A., & Manakos, A. (2010, September). Investigating

the evolution of bad smells in object-oriented code. In Seventh
International Conference on the Quality of Information and
Communications Technology (QUATIC), 10, 106-115. IEEE.
[28] Hecht, G., Moha, N., & Rouvoy, R. (2016, May). An empirical study of
112
the performance impacts of android code smells. In Proceedings of the

International Conference on Mobile Software Engineering and
Systems, 14-22 May; Austin, Texas. New York, NY, USA: ACM. pp. 59-
69. ACM.
[29] OMG, “OMG Unified Modeling Language, Infrastructure, v2.3” ,
http://www.omg.org/spec/UML/2.1.2/Infra structure/PDF, May 2010.
[30] ArgoUML Platform at: http://sourceforge.net/projects/argouml.mirror/
[31] StarUml platform at: http://sourceforge.net/projects/staruml/
[32] Umlet platform at:

http://www.windows7download.com/win7-umlet/download-
meyiwlwg.html
[33] Modelio at, https://www.modelio.org/downloads/download-modelio.html.
[34] Rational Rose Composer platform available at

http://www.fileheap.com/dbquery/1/rational+rose+xde+developer
[35] RISE Platform available at

http://download.cnet.com/RISE-Editor/3000-10254_4-10859273.html
[36] Umodel Platform available at

http://www.altova.com/download/umodel.html.
[37] Nyvlt, V., & Novotny, R. (2019, February). Ontology as a Tool for
Building Life Cycle Modelling. In IOP Conference Series: Materials
Science and Engineering (Vol. 471, No. 10, p. 102007). IOP Publishing.
[38] Guizzardi, G., & Mylopoulos, J. (2019). Taking It to the Next Level:
Nicola Guarino, Formal Ontology and Conceptual Modeling. In
Ontology Makes Sense (pp. 223-241).
[39] Xiao, P., Toivonen, H., Gross, O., Cardoso, A., Correia, J., Machado,
P., ... & Díaz, A. (2019). Conceptual Representations for Computational
Concept Creation. ACM Computing Surveys (CSUR), 52(1), 9.
113
[40] Calero, C., Ruiz, F., & Piattini, M. (Eds.). (2006). Ontologies for software
engineering and software technology. Springer Science & Business
Media.
[41] Happel, H. J., & Seedorf, S. (2006). Applications of ontologies in

software engineering. In Proceedings of Workshop on Sematic Web
Enabled Software Engineering"(SWESE) on the 5th International
Semantic Web Conference (ISWC), (pp. 5-9).
[42] SA. Aljawarneh, A. Alawneh, R. Jaradat, Cloud security engineering:

Early stages of SDLC. Future Genera-tion Computer Systems. 74(1)
(2017)385-92.
[43] P. Maurice, F. Dhombres, E. Blondiaux, S. Friszer, L. Guilbaud, N.

Lelong, B. Khoshnood, J. Charlet,N. Per-rot, E. Jauniaux, D. Jurkovic,
Towards ontology-based decision support systems for complex
ultrasound diagno-sis in obstetrics and gynecology. Journal of
gynecology obstetrics and human reproduction. 46(5)(2017)423-9.
[44] W. Bartussek, T. Weiland, S. Meese, MO. Schurr, M. Leenen, A.

Uciteli, S. Kropf, H. Herre, C. Goller, P. Blohm, W. Lauer, Ontology-
based search for risk-relevant PMS data. In Biomedical Engineering
Conference (SAIBMEC), 2018 3rd Biennial South African (2018)1-4.
IEEE.
[45] G. De Giacomo, D. Lembo, M. Lenzerini, A. Poggi, R. Rosati, Using

ontologies for semantic data integration. In A Comprehensive Guide
through the Italian Database Research Over the Last 25 Years
(2018)187-202. Springer, Cham.
[46] Calzavara, S., Grishchenko, I., & Maffei, M. (2016, March).

HornDroid: Practical and sound static analysis of Android applications
by SMT solving. In 2016 IEEE European Symposium on Security and
Privacy (EuroS&P) (pp. 47-62). IEEE.
[47] Kumar, V. K. (2019). Knowledge Representation Technologies Using

Semantic Web. In Web Services: Concepts, Methodologies, Tools, and
Applications (pp. 1068-1076). IGI Global.
114
[48] Koskinen, J., & Lehmonen, T. (2010). Analysis of ten reverse

engineering tools. In Advanced Techniques in Computing Sciences and
Software Engineering (pp. 389-394). Springer, Dordrecht.
[49] Gahalaut, A. K., & Khandnor, P. (2010). Reverse engineering: an

essence for software re-engineering and program analysis. International
Journal of Engineering Science and Technology, 2(06), 2296-2303.
[50] Boklund, A., Mankefors-Christiernin, S., Johansson, C., & Lindell, H.

(2007). A comparative study of forward and reverse engineering in
UML tools. In IADIS International Conference Applied Computing
(Vol. 2007, p. 49.
[51] Song, L., Tang, Z., Li, Z., Gong, X., Chen, X., Fang, D., & Wang, Z.
(2017, December). AppIS: Protect Android Apps Against Runtime
Repackaging Attacks. In Parallel and Distributed Systems (ICPADS),
2017 IEEE 23rd International Conference on (pp. 25-32). IEEE.
[52] Zhou, X., Wu, K., Cai, H., Lou, S., Zhang, Y., & Huang, G. (2018).
LogPruner: detect, analyze and prune logging calls in Android apps.
Science China Information Sciences, 61, pp. 1-3.
[53] Arnatovich, Y. L., Wang, L., Ngo, N. M., & Soh, C. (2018). A
Comparison of Android Reverse Engineering Tools via Program
Behaviors Validation Based on Intermediate Languages Transformation.
IEEE Access, 6, 12382-12394.
[54] Linares-Vásquez, M., Klock, S., McMillan, C., Sabané, A.,

Poshyvanyk, D., & Guéhéneuc, Y. G. (2014, June). Domain matters:
bringing further evidence of the relationships among anti-patterns,
application domains, and quality-related metrics in Java mobile apps. In
Proceedings of the 22nd International Conference on Program
Comprehension02 – 03 June 2014, Hyderabad, India. New York, NY,
USA: ACM. pp. 232-243.
[55] Palomba, F., Di Nucci, D., Panichella, A., Zaidman, A., & De Lucia, A.
(2017, February). Lightweight detection of Android-specific code
smells: The aDoctor project. In IEEE 24th International Conference on
115
Software Analysis, Evolution and Reengineering (SANER), 20-24 Feb.

2017, Klagenfurt, Austria. IEEE. pp. 487-491.
[56] Hecht, G., Benomar, O., Rouvoy, R., Moha, N., & Duchien, L. (2015,
November). Tracking the software quality of android applications along
their evolution (t). In 30th IEEE/ACM International Conference on
Automated Software Engineering (ASE), 9-13 Nov. 2015; Lincoln, NE,
USA. Washington, DC, USA: IEEE, pp. 236-247.
[57] F. Khomh, S. Vaucher, Y. G. Guéhéneuc, and H. Sahraoui. A bayesian

approach for the detection of code and design smells. In 2009 Ninth
International Conference on Quality Software, Jeju, South Korea. 2009,
pp. 305-314. IEEE.
[58] F. Khomh, S. Vaucher, Y.G. Guéhéneuc, and H. Sahraoui. BDTEX: A

GQM-based Bayesian approach for the detection of Smells. Journal of
Systems and Software, Vo. 84 No. 4, 2011, pp.559-572.
[59] L. Guerrouj, Z. Kermansaravi, V. Arnaoudova, B. C. Fung, F. Khomh,

G. Antoniol, and Y. G. Guéhéneuc. Investigating the relation between
lexical smells and change-and fault-proneness: an empirical study.
Software Quality Journal, Vo. 25 No. 3, 2017, pp.641-670.
[60] F. A. Fontana, I. Pigazzini, R. Roveda, D. Tamburri, M. Zanoni, and E.

Di Nitto. Arcan: a tool for architectural smells detection. In 2017 IEEE
International Conference on Software Architecture Workshops
(ICSAW), Gothenburg, Sweden, 2017, pp. 282-285. IEEE.
[61] U. Mansoor, M. Kessentini, S. Bechikh, and K. Deb. Code-smells

detection using good and bad software design examples. Technical
Report, 2013.
[62] N. Moha, Y.G. Gueheneuc, L. Duchien, and A. F. Le Meur. Decor: A

method for the specification and detection of code and design smells.
IEEE Transactions on Software Engineering, Vo. 36 No. 1, 2010, pp.20-
36.
[63] C. Kiefer, A. Bernstein, and J. Tappolet, May. Mining software

repositories with isparol and a software evolution Ontology. In
116
Proceedings of the Fourth International Workshop on Mining Software

Repositories. 2007, (p. 10). IEEE Computer Society.
[64] L. P. da Silva Carvalho, R. L. Novais, L. do Nascimento Salvador and

M. G. de Mendonça Neto. An Approach for Semantically-Enriched
Recommendation of Refactorings Based on the Incidence of Code
Smells. In International Conference on Enterprise Information Systems,
2017, (pp. 313-335). Springer, Cham.
[65] G. Guizzardi, and T. P. Sales. Detection, simulation and elimination of

semantic Smells in Ontology-driven conceptual models. In International
Conference on Conceptual Modeling. 2014, (pp. 363-376). Springer,
Cham.
[66] C. Roussey, O. Corcho, and L. M. Vilches-Blázquez. A catalogue of

OWL Ontology Smells. In Proceedings of the fifth international
conference on Knowledge capture, 2009, (pp. 205-206). ACM.
[67] K. Alkharabsheh, Y. Crespo, E. Manso, and J. A. Taboada. Software

Design Smell Detection: a systematic mapping study. Software Quality
Journal, 2018, pp.1-80.
[68] Protege setup for GO Eds,

http://wiki.geneOntology.org/index.php/Protege_setup_for_GO_Eds.
(Accessed at February 2019.
[69] R. Kofler, and C. Schlötterer. Gowinda: unbiased analysis of gene set

enrichment for genome-wide association studies. Bioinformatics, Vo. 28
No. 15, 2012, pp.2084-2085.
[70] K. Jezek, and R. Lipka. Smells causing memory bloat: A case study. In
2017 IEEE 24th International Conference on Software Analysis,
Evolution and Reengineering (SANER), Klagenfurt, Austria, IEEE,
2017, pp. 306-315.
[71] Mumtaz, H., Alshayeb, M., Mahmood, S., & Niazi, M. (2019). A survey
on UML model smells detection techniques for software refactoring.
Journal of Software: Evolution and Process, 31(3), e2154.
[72] Chapman, W. (2018). Engineering modeling and design. Routledge.
117
[73] What is Python? Executive Summary.

https://www.Python.org/doc/essays/blurb (Accessed March 2019).
[74] Ontologies & RDF datasets. The OBO Foundry

http://www.obofoundry.org/ (Accessed February 2019).
[75] The DBpedia. https://wiki.dbpedia.org/Datasets (Accessed 15 February

2019).
118

Naglaa Dissertation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Naglaa Dissertation

Uploaded by

Copyright:

Available Formats

Al-Azhar University,

Faculty of Science (Girls),

Improving Mobile Applications' Quality via Diagnosis

Assoc. Prof. Eman K. Elsayed

2- Prof. Kamal Abdel Raouf ElDahshan

3- Assoc. Prof. Eman Karam Elsayed

Name: Naglaa Elsayed Ibrahim Said

Supervisors Position Relation- Signature

Prof. Hoda Abdel Professor of Mathematics,

Prof. Kamal Abdel Professor of Computer

Prof. Dr. Lamiaa Deiab

For their Support and Prayers

First, I would like to thank Allah for his immerse

I would also like to express with pleasure my gratitude to all

One simply cannot wish for better, more professional or

I would also like to thank members of my family, my

Cairo, Egypt Naglaa E. Ghannam

Publications Related to this Thesis

1. "Comparative Study for Detecting Mobile

2. "Reverse engineering approach for improving the

3. " Metric method for long life Semantic Applications"

The integration and refinement of mobile applications to

The proposed method is based on Ontology and reverse

applications. It detected 15 structural and semantic anti-patterns

Keywords: Patterns, Anti-Patterns, Mobile Applications, UML, Ontology

..……………..….……………………List of Tables III

2. Patterns and Anti-patterns Overview

2.5 Anti-patterns Detection.............................................15

3. Mobile Applications, Unified Modeling Language (UML),

Quality of mobile applications

6.5 Experimental Evaluation ..........................................87

7. Conclusion and Future Work

Figure 5.4: The integration of OWL ontologies of the mobile

..………………………………Figure 5.5: Generating Java classes 49

..Figure 5.14: Generalization between two un-compatible elements 58

…………………………Figure 5.19: A destructor has parameters 59

Figure 6.3: OWL Ontology representing Large Class Smell ……. 80

Figure 6.4: OWL Ontology representing the Singleton smell…… 81

Figure 6.5: The result of ONTOPYTHO on the case study……… 89

Figure 6.6: The appearance of the detected smells in the DBpedia

Table 5.1: UML tools support Reverse Engineering Java Code….. 39

Table 5.4: Ten Modelio anti-patterns and their method of correction 63

Table 5.5: OntoUML anti-patterns and the method of correction….. 63

Table 5.6: The occurrences of the anti-patterns……………………. 64

Table 5.7: The detected anti-patterns in the 29 mobile applications 66

Table 5.8. The correlation between anti-patterns groups…. 68

Table 5.9: The correlation between detection tools………. 69

Table 5.10: Comparison between the numbers of anti-patterns after

Table 6.2: Design smells per Owl ontologies ………… 90

Table 6.3: ONTOPYTHO results for the detection Of 3 smells in 12

Table 6.4: The SPSS Pearson correlation coefficient matrix between

Table 6.5: The Ratio of smells according to the classes of Owl

Chart 5.2: The similarities between the means of the

Chart 6.1. The similarity between the means of "Blob

DVM Dalvik Virtual Machine

JVM Java Virtual Machine

APK Android Package

MOGP Multi-Objective Genetic Programming

IOT Internet Of Things

VOIP Voice Over IP

UFO Unified Foundational Ontology

ANOVA Analysis of Variance

SPSS Statistical Package for the Social Sciences

One of the most important things in the development of