Skip to content
This repository has been archived by the owner on Nov 19, 2019. It is now read-only.

Software Reengineering Proposed Changes #50

Open
wants to merge 96 commits into
base: master
Choose a base branch
from
Open
Changes from 4 commits
Commits
Show all changes
96 commits
Select commit Hold shift + click to select a range
50bc99e
start of chapter 1
abouter Dec 1, 2014
c908a24
..
mdenhoedt Dec 1, 2014
91e4ceb
...
mdenhoedt Dec 2, 2014
e9abb15
...
mdenhoedt Dec 2, 2014
39f28c5
more H1
abouter Dec 2, 2014
c428596
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Dec 2, 2014
60c84d0
moved and renamed images
abouter Dec 2, 2014
f23519c
move and rename
abouter Dec 3, 2014
0371eb2
kleine aanpassing
mdenhoedt Dec 3, 2014
706ba55
some info about used tools
abouter Dec 3, 2014
6bf4a5f
merge
abouter Dec 3, 2014
361d61e
..
mdenhoedt Dec 3, 2014
e8708fd
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
mdenhoedt Dec 3, 2014
7acfb3f
merged the 2 md files
mdenhoedt Dec 3, 2014
47ce0ad
explanation of solid principles
abouter Dec 3, 2014
e2a2b15
merge
abouter Dec 3, 2014
6f1e924
merge
abouter Dec 3, 2014
8a5e0bf
SRP wall of text
abouter Dec 3, 2014
5417960
incode image
abouter Dec 3, 2014
211756f
more explanation of principles
abouter Dec 3, 2014
af3730c
jpg to png
abouter Dec 3, 2014
28ef761
..
mdenhoedt Dec 3, 2014
739068a
..
mdenhoedt Dec 3, 2014
94fd199
..
mdenhoedt Dec 7, 2014
d12bada
DIP
mdenhoedt Dec 7, 2014
934fce6
x-ray diagram at inheritance structure
abouter Dec 7, 2014
11b022a
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Dec 7, 2014
847eaf8
DIP text
abouter Dec 7, 2014
c8ec602
..
mdenhoedt Dec 7, 2014
51382ea
OCP/LSP
abouter Dec 7, 2014
3d08aab
.
mdenhoedt Dec 7, 2014
0724f7b
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
mdenhoedt Dec 7, 2014
0337723
minor stuff
abouter Dec 7, 2014
1b87418
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Dec 7, 2014
6ec3f5c
added captions
mdenhoedt Dec 7, 2014
028976d
final touch
abouter Dec 7, 2014
4ab73ce
dummie report added
mdenhoedt Jan 14, 2015
fb813a2
added names
mdenhoedt Jan 14, 2015
dbcb1d8
fixed 2 cyclic dependecies between packages
mdenhoedt Jan 14, 2015
4c3956c
stopped infinite loop
abouter Jan 16, 2015
3a4ad42
updated stuff
abouter Jan 16, 2015
570ee17
did the bugfix in SchedularStats.java
mdenhoedt Jan 16, 2015
5099173
kleine aanpassing
mdenhoedt Jan 16, 2015
50715a1
fixed cyclic dependency?
mdenhoedt Jan 16, 2015
a88ce9c
made new tests, renamed some testpackages
mdenhoedt Jan 16, 2015
3548dac
..
mdenhoedt Jan 16, 2015
12fe84f
merge done
mdenhoedt Jan 16, 2015
498ec7e
soort van af
mdenhoedt Jan 16, 2015
e3922f5
small fix
mdenhoedt Jan 16, 2015
a7c8310
toevoeging aanverslag
mdenhoedt Jan 16, 2015
42b5f35
split GitUpdater into 4 files
abouter Jan 16, 2015
cafa462
git updater/processor tests
abouter Jan 16, 2015
fdc2fa6
merge
abouter Jan 16, 2015
1ba329d
git tests
abouter Jan 17, 2015
de21eb6
report
abouter Jan 17, 2015
452a755
all direct dependencies removed between StoredProject and Tag
mdenhoedt Jan 17, 2015
9a06c73
iets meer tekst
mdenhoedt Jan 17, 2015
b63ee20
removed another dependecy
mdenhoedt Jan 17, 2015
53cd721
...
mdenhoedt Jan 17, 2015
6823799
tests for git
abouter Jan 17, 2015
2272bea
stuff works again
abouter Jan 17, 2015
838247e
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Jan 17, 2015
b668fcf
fixed imports
mdenhoedt Jan 17, 2015
f2b92a0
merged
mdenhoedt Jan 17, 2015
d16739f
...
mdenhoedt Jan 17, 2015
cb7eea2
..
mdenhoedt Jan 17, 2015
a16931e
git tests
abouter Jan 17, 2015
4272e82
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Jan 17, 2015
5d61163
Revert "git tests"
abouter Jan 17, 2015
7788805
fixing stuff that was magically broken
abouter Jan 17, 2015
556020d
...
mdenhoedt Jan 17, 2015
097891b
pff
mdenhoedt Jan 17, 2015
2877f33
...
mdenhoedt Jan 17, 2015
de80643
test
abouter Jan 17, 2015
ef66cb5
less code dups
mdenhoedt Jan 17, 2015
1c572aa
Merge branch 'dry-fix'
mdenhoedt Jan 17, 2015
05307aa
report
abouter Jan 17, 2015
72552ec
...
mdenhoedt Jan 17, 2015
853dd60
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
mdenhoedt Jan 17, 2015
a228c21
recommendation section
mdenhoedt Jan 17, 2015
4a412e2
report
abouter Jan 17, 2015
086b498
git tests
abouter Jan 17, 2015
6638499
report merge
abouter Jan 17, 2015
e280753
more tests
mdenhoedt Jan 17, 2015
0a40a09
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
mdenhoedt Jan 17, 2015
66cf35a
report merge
abouter Jan 17, 2015
8a1b16b
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Jan 17, 2015
94e533e
report
abouter Jan 17, 2015
5471d15
cleanup
abouter Jan 17, 2015
277976b
import fix en meer verslag
mdenhoedt Jan 17, 2015
2f1ab92
Update assignment2.md
Jan 17, 2015
221c82d
presentatie
abouter Feb 9, 2015
1c71110
Merge branch 'master' of github.com:mdenhoedt/Alitheia-Core
abouter Feb 9, 2015
35cdc1e
presentatie
abouter Feb 11, 2015
2670bc1
presentatie pretty much af
abouter Feb 11, 2015
811f7ef
...
mdenhoedt Feb 12, 2015
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 95 additions & 0 deletions 4143760-4167562/assignment1.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
<h1>IN4189 Software Reengineering - Reverse Engineering and Detection Report</h1>

<p>By Martijn den Hoedt - 4143760, Anton Bouter - 4167562</p>

<h2>Introduction</h2>

<p><a href="http://www.sqo-oss.org/">Alitheia Core</a> is a platform for automatic evaluation of software that is designed to simplify software engineering research. It can produce a broad picture of the quality of an Open Source project by analysing both hard project artifacts (source code) and soft project artifacts (mailing list, bug tracker entries).
We performed a software analysis on the Alitheia Core to find shortcoming such as design flaws and code smells. The first chapter of this report will describe the system and its structure, while the second chapter is dedicated to pinpointing shortcomings of the Alitheia Core. The focus is on detecting violations of the S.O.L.I.D. object-oriented design principles. These include the following five principles:</p>

<ul>
<li>Single responsibility principle</li>
<li>Open/closed principle</li>
<li>Liskov substitution principle</li>
<li>Interface segregation principle</li>
<li>Dependency inversion principle</li>
</ul>

<p>To simplify the detection procedure, the following software evaluation tools have been used: </p>

<ul>
<li><a href="http://www.sonarqube.org/">SonarQube</a>
<ul>
<li>Open platform to manage code quality, which covers criteria such as complexity, potential bugs, duplications, architecture &amp; design.</li>
</ul></li>
<li><a href="https://www.intooitus.com/products/incode">inCode</a>
<ul>
<li>Detects design flaws automatically and helps you resolve them.</li>
</ul></li>
<li><a href="http://xray.inf.usi.ch/xray.php">X-Ray</a>
<ul>
<li>Software visualization tool that provides e.g. a system complexity form and a class and package dependency view.</li>
</ul></li>
<li><a href="http://www.umlgraph.org/">UMLGraph</a>
<ul>
<li>Allows automatic drawing of UML class and sequence diagrams</li>
</ul></li>
</ul>

<h2>Initial Understanding and Detailed Model Capture</h2>

<p>To find certain shortcomings in the design of the system, we must first understand it. This chapter is dedicated to the process of understanding the model and displaying its properties clearly by using reverse engineering tools to create models.</p>

<h3>Main features</h3>

<p>What makes Alitheia Core stand out is that it not only evaluates the final product, but also the developing process. This is done by evaluating the so called soft project artifacts, such as mailing lists and bug tracker entries, which leads to a broader picture of the quality of the software project. The different aspects of that are analysed are aggregated through a <a href="http://www.dmst.aueb.gr/dds/pubs/conf/2008-OSS-qmodel/html/SGSS08.htm">multilevel quality model</a> <a href="http://www.sqo-oss.org/about">[1]</a>.</p>

<p>The Alitheia Core can also be used to automate and parallellize the execution of custom experiments. Studies on empirical data can easily be performed and the Alitheia Core can also be extended to produce any measurement you are interested in.</p>

<h3>Important source code entities</h3>

<p>The main class of the Alitheia Core is AlitheiaCore.java, in the eu.sqooss.core package, which initializes the core components of the system and provides a static instance of AlitheiaCore. All services of the AlitheiaCore classes can then be called by using the methods defined in the AlitheiaCoreService interface, which is present in the same package as the AlitheiaCore class. These services are implemented in the eu.sqooss.service package and divided into a large number of packages, such as admin, db, scheduler, updater and util. Each package can also contain classes that the service depends on.</p>

<h3>Impression of design and implementation</h3>

<p>We think that the Alitheia Core system looks well structured, because the classes seem to be properly distributed among packages with names that provide useful information. The core is properly isolated from the classes that provide services. Many classes also contain javadoc comments and additional comments to clarify functions when needed. However, the number of tests is very limited. We therefore have a relatively good first impression of the design and implementation of the system. Although the test suite should be expanded, we think reengineering the Alitheia Core is feasible, because the javadoc documentation makes it much easier.</p>

<h3>Exceptional entities</h3>

<p>To study the exceptional entities, such as packages, classes and methods, a UML diagram can be very useful. Such a diagram shows which classes are related and in what way. A UML diagram can also be reverse engineered by a tool such as <a href="http://www.umlgraph.org/">UMLGraph</a>. The diagram in figure 1 displays all database objects and was created by Georgios Gousios using the UMLGraph tool on the Alitheia Core system <a href="http://www.umlgraph.org/doc/ceg-er.html">[2]</a>. From this diagram we can clearly see that many classes depend on the StoredProject class. The same goes for the Metric, ProjectVersion and Bug classes. All of these classes are part of the eu.sqooss.service.db package, which definitely is an exceptional entity, because it contains a very large number of classes. </p>

<p><img src="./img/uml.png" width="931" height="437px" /></p>

<p><center><em>Figure 1: UML Diagram of Alitheia Core</em></center></p>

<h3>Inheritance structure</h3>

<p>As described earlier, the system is composed of many service interfaces that extend the AlitheiaCoreService interface, such as DBService, AdminService, LogManager and RestService. The implementations of all these classes must also implement the basic functions of the AlitheiaCoreService class.</p>

<h3>Step through execution</h3>

<p>Finally, collisions are handled by locking the database whenever a thread starts a database session, such that no other threads can commit changes to the database. When changes are committed, the current session is closed and the lock on the database is released. The changes made during the current session can also be reverted by the function rollbackDBSession in DBService.</p>

<h2>Problem Detection</h2>

<p><a href="https://www.intooitus.com/products/incode">inCode</a> found nine God classes, two of them are scoring a 10 out of 10 (<code>GitUpdater</code> and <code>ContributionMetricImpl</code>). The <code>GitUpdater</code> 767 LOC, but another bigger class called <code>SVNUUpdaterImpl</code> has 993 LOC. </p>

<h3>Single Responsibility Principle</h3>

<p>Both the <code>ContributionMetrixImpl</code> and the <code>GitUpdater</code> classes have many methods, use many attributes from many external classes. The <code>GitUpdater</code> class also contains multiple to-do's and code that is commented out. These two classes keep track of many things and can perform many actions, therefore they violate the single responsbility principle. Another example is the definition of <code>DecreasingLongComparator</code> and <code>RandomizedCompatator</code> within <code>MetricActivatorImpl.java</code>. In this way it's not easy to know such classes actually exists, not to mention reusing the code. </p>

<h3>Open/Closed Principle (OCP) or Liskov Substitution Principle (LSP)</h3>

<h3>Dependency Inversion Principle (DIP)</h3>

<h3>Acyclic Dependencies Principle (ADP)</h3>

<h3>Don't Repeat Yourself (DRY)</h3>

<p>We have looked for duplicated code with <a href="http://www.sonarqube.org/">SonarQube</a>. This tool found 313 lines of code (LOC) in a total of 31,760 LOC. Thus only 1% of the Alitheia Core project is duplicate code. The project contains 15,688 LOC with Java, the rest is comments or whitespace. We investigated a few instances of code duplication. One of them is <code>BugResolution</code> (lines 121-135) and <code>BTSEntry</code> (lines 203-216). </p>

<h3>Simple shortcomings</h3>

<p>SonarQube is also able to detect a lot of other issues. In Alitheia Core are 1770 issues. These issues can point out confusing code formatting, like inconsistently placing curly braces. Also more important issues like never throw generic exceptions, such as <code>Exception</code>, are detected in the Alitheia Core project.</p>

<p>SonarQube is also able to calculate the complexicity of the code. The <a href="http://docs.codehaus.org/display/SONAR/Metrics+-+Complexity">complexity metrics</a> used by SonarQube is count every <code>if</code>, <code>for</code>, <code>while</code>, <code>case</code>, <code>catch</code>, <code>throw</code> and <code>return</code> statement. The <code>PluginsView</code> has the highest complexity per function, but also a high amount of code per method. inCode also found classes and methods with a high complexcity.</p>
29 changes: 22 additions & 7 deletions 4143760-4167562/assignment1.md
Original file line number Diff line number Diff line change
@@ -57,18 +57,33 @@ As described earlier, the system is composed of many service interfaces that ext

The S.O.L.I.D. design principles were already named in the introduction, but to find shortcoming in the code, we shall explain them further in this section.

### Interface Segregation Principle
According to this principle, no client should be forced to depend on methods it does not use. When the superclass of some class A contains methods that are not applicable to A, the Interface Segregation Principle is violated. When this happens, the superclass should be split such that its children do not have access to methods that are not applicable.

## Problem Detection
[inCode](https://www.intooitus.com/products/incode) found nine God classes, two of them are scoring a 10 out of 10 (`GitUpdater` and `ContributionMetricImpl`). The `GitUpdater` 767 LOC, but another bigger class called `SVNUUpdaterImpl` has 993 LOC.

### Single Responsibility Principle
This principle states that every software entity (class, function, variable, etc.) should have a single purpose and only one reason to change. If it is violated, the violating entity should be split into two or more entities that satisfy the Single Responsibility Principle.
This principle states that every software entity (class, function, variable, etc.) should have a single purpose and only one reason to change. If it is violated, the violating entity should be split into two or more entities that satisfy the Single Responsibility Principle.

Both the `ContributionMetrixImpl` and the `GitUpdater` classes have many methods, use many attributes from many external classes. The `GitUpdater` class also contains multiple to-do's and code that is commented out. These two classes keep track of many things and can perform many actions, therefore they violate the single responsbility principle. Another example is the definition of `DecreasingLongComparator` and `RandomizedCompatator` within `MetricActivatorImpl.java`. In this way it's not easy to know such classes actually exists, not to mention reusing the code.

### Open/Closed Principle (OCP) or Liskov Substitution Principle (LSP)

### Open/Closed Principle
According to the Open/Closed principle, software entities should be open for extension, but closed for modification. This means that the software must be extensible without modifications to its source code. Also, an extension may not lead to a change in behaviour of the code that is extended.

### Liskov Substitution Principle
The principles of object oriented programming are underlined by this principle. It states that subtypes must be substitutable for their base types. Therefore, if a method expects some object A as a parameter, this method should also accept any class that is a superclass of A. The post-conditions of the method should still hold after such a substitution.
The principles of object oriented programming are underlined by the Liskov Substitution principle. It states that subtypes must be substitutable for their base types. Therefore, if a method expects some object A as a parameter, this method should also accept any class that is a superclass of A. The post-conditions of the method should still hold after such a substitution.

### Interface Segregation Principle
According to this principle, no client should be forced to depend on methods it does not use. When the superclass of some class A contains methods that are not applicable to A, the Interface Segregation Principle is violated. When this happens, the superclass should be split such that its children do not have access to methods that are not applicable.
### Dependency Inversion Principle (DIP)

### Dependency Inversion Principle
This principle states that high-level modules should not depend on low-level modules. Additionally, abstractions should not depend on details, but details should depend on abstractions. This means that the high-level modules cannot simply use low-level modules to perform some task. An interface should be used that implements the functions of the low-level module. The high-level class then calls the methods of the interface and the low-level class implements the interface.

### Acyclic Dependencies Principle (ADP)

### Don't Repeat Yourself (DRY)
We have looked for duplicated code with [SonarQube](http://www.sonarqube.org/). This tool found 313 lines of code (LOC) in a total of 31,760 LOC. Thus only 1% of the Alitheia Core project is duplicate code. The project contains 15,688 LOC with Java, the rest is comments or whitespace. We investigated a few instances of code duplication. One of them is `BugResolution` (lines 121-135) and `BTSEntry` (lines 203-216).

### Simple shortcomings
SonarQube is also able to detect a lot of other issues. In Alitheia Core are 1770 issues. These issues can point out confusing code formatting, like inconsistently placing curly braces. Also more important issues like never throwing generic exceptions, such as `Exception`, are detected in the Alitheia Core project.

SonarQube is also able to calculate the complexicity of the code. The [complexity metrics](http://docs.codehaus.org/display/SONAR/Metrics+-+Complexity) used by SonarQube count every `if`, `for`, `while`, `case`, `catch`, `throw` and `return` statement. The `PluginsView` has the highest complexity per function, but also a high amount of code per method. The inCode tool also found classes and methods with a high complexity.
10 changes: 0 additions & 10 deletions 4143760-4167562/h2.md

This file was deleted.