Final Year Project II
Detection of Problems in Class hierarchies and their correction
through Formal Concept
FCA Parser
Version<1.1>
Samia Azhar
06-0155
Shahzadi Samia 06-0112
Supervisor: Dr. Muhammad Usman Bhatti
BS (CS) Final Year Project
Date: 20-2-2010
Table of Contents
I. Abstract: ............................................................................................................... 3
II.
User-Interface .................................................................................................... 3
1.
Functionalities: ............................................................................................................................................................ 3
2.
Alerts and Confirmation Messages: ............................................................................................................................ 5
III. Techniques Supported: .................................................................................. 6
1.
Method Attribute ......................................................................................................................................................... 6
2.
Common Members...................................................................................................................................................... 8
3.
Class Coupling: ......................................................................................................................................................... 10
4.
Client Code: .............................................................................................................................................................. 12
5.
Class Association ...................................................................................................................................................... 14
IV. References: ..................................................................................................... 18
I.
Abstract:
FCA Parser is a tool that parses java files to generate input for the Concept Explorers, Conexp or Galicia
depending on what is chosen by the user. The concept Explorer that is selected later generates the concept
lattice which can be used to compare the results produced by the various techniques the tool supports. It
provides an interface to the user to either select a package containing multiple java files or a single file
followed by selection of technique to be applied, binary file storage, selection of the concept Explorer and
lattice generation at the end.
II.
User-Interface:
The user interface of this tool is shown in the figure below:
1. Functionalities:
The functionality provided by each button is as follows:
i)
Select a Java package: If the user selects this button, he is prompted to browse for the Java
package that contains the software source code as shown by the image below:
ii)
iii)
Select a Technique: This choice group lets user select one of the four techniques he wants to apply
.
Select a Class/Multiple Classes: Using this button the user can select either a single java file or
multiple java files, depending on what he wants to analyze
iv)
Select an Explorer: It represents a choice group that enables the user to select one of the two
explorers, Conexp and Galicia. The reason for adding Galicia to the interface was that for large
number of classes having lots of methods and attributes, ConExp generates a huge lattice which
makes it difficult to study. Galicia on the other hand displays only meaningful information which
makes the lattice easier to analyze.
v)
Save Output File As: This button generates the binary file in the format supported by the concept
explorer previously chosen and lets the user save the generated file to a path of his choice.
vi)
Start Concept Explorer: This button launches a concept explorer, depending on what the user has
chosen from the choice group. In the image shown below, Conexp has been launched.
2. Alerts and Confirmation Messages:
While using the tool if the user misses a step before proceeding on to the next one the tool generates
appropriate alerts. The four alerts that are generated are as follow:
i)
No file Selected: If the user does not select any package of file and selects "Save Output File As"
button, this alert is generated. It is shown by the image below:
ii)
iii)
iv)
No technique Selected: This alert is generated if the user presses "Save Output As" button without
selecting any technique
.
No Explorer Selected: This alert is generated if the user presses "Save Output As" or "Start Concept
Explorer" button without selecting any technique.
Exit Confirmation Message: This confirmation dialog appears whenever the user closes the
application uses the close button at the top right corner. It is shown below:
III. Techniques Supported: The tool implements four techniques that help us to detect
problems found in class hierarchies and suggests possible refactoring that can be applied to make the
software free of these defects.
1. Method Attribute: This technique determines the relationship between methods and attributes. It tells
us about the attributes accessed by various methods in a single java class. The following example
explains the technique.
Example: Assume that you need to parse the following java class:
i)
Java Code:
ii)
Binary File: By browsing this java class from the tool, applying "Method-Attribute" technique, and
selecting Conexp as the explorer , the following binary file is generated as output.
iii)
Context: When this file is given as input to "ConExp", it displays the following context:
For each row a cross indicates that a method accesses an attribute.
iv)
Concept Lattice: Finally the Concept Explorer, "Conexp", uses the context and builds up a lattice
for the java class. The lattice for the above java code is as follows:
v)
Findings:
This lattice shows that the methods: getId() and setId() access the variable , "id" only. The methods:
getName() and setName() access the attribute , "name" only whereas the method, "TestMethod()" in
addition to name and id accesses an additional attribute, "score". We also get to know that the
attribute age is not being used. In short it tells us about the degree of cohesion of a class.
2. Common Members: This technique determines the class hierarchies among multiple java classes by
extracting information about the methods and attributes that are common among these classes.
Example: Suppose that you had the following java classes, "Test" and "Test1"in a package:
i)
Java Package:
ii)
Binary File: By browsing this file into the tool , the binary file generated is as follows:
In this binary file the header represents a union of all methods and attributes in "Test" and
'Test1". The first row depicts that the class, "Test" accesses all the methods and attributes, where
as "Test1" accesses only some of the methods and attributes accessed by "Test".
iii)
Context: On giving this file as input to "ConExp", the following context is displayed:
iv)
Concept Lattice : The lattice generated by ConExp for the above java package is as follows:
v)
Findings:
This lattice shows that the methods getPerimeter() and getArea() and the attribute , length are
common to both the classes . It suggests us that we can possibly derive a hierarchy, which could
reduce the duplication. We can construct a parent class(may be an interface) that would contain
the methods getPerimeter() an getArea() with each class providing its own implementation for
the respective methods.
3. Class Coupling: This technique takes the takes a java package or multiple java classes as input and
gives information about the methods invoked and atrributes accessed across classes. Suupose we have
two classes A and B. When these files are given as input to the tool it generates a binary file telling
about the methods of B invoked in A , the variuos attributes that are accessed (if any) and vice versa.
The following example illustrates this technique.
Example: Suppose we have the following java package.
i)
Java Package:
ii)
Binary File: The binary file is as follows:
iii)
Context: The context generated by conExp is as follows:
iv)
Concept lattice: The lattice generated by ConExp is as follows:
v)
Findings: We can see through the lattice that class A is accessing all the attributes and methods
of B and vice versa, therfore the two classes can either be merged or we can use "Move
Method".
4. Client Code: This technique suggests refactoring of java classes by taking as input the client code that
uses these classes. It examines how the methods and attributes of classes are being accessed by their
respective objects that are declared in the client code. The following example illustrates the technique.
Example: Consider the following java classes and the client code written for them.
i)
Java package: The java classes used by the client code are as follows:
ii)
Client Code:
iii)
Binary file: The binary file generated by the tool when given client code as input is as follows:
iv)
Context: It is as follows:
v)
Concept Lattice: The concept explorer generated by Conexp is as follows;
vi)
Findings: This lattice suggests that there should be a class A1 that contains an attribute X. and
another Class A2 should be its subclass and having the method f (). Likewise B1 and B2 should
be two classes having methods g() and h() respectively .
5. Class Association: This technique examines the relationship between the methods of a java class and
the attributes and classes referenced by these methods. The lattice generated reflects the degree of
cohesion of a class and tells us about how its methods are coupled to other classes.
Example: Consider the following java class:
i)
Java Code:
ii)
Binary File: The binary file for Conexp generated by the tool is as follows:
iii)
Context: The context is as follows:
iv)
Concept Lattice: The concept lattice is as follows:
v)
Findings: The lattice shows that the method calculateResult() is referring to Class "Result" in
addition to other attributes of its own class and the attribute age is not being used
6. Principle Class Views: The group of methods and the type that these methods access and modify is
known as a principal class. While extracting principle Classes from a given java package we consider
only end user Types, primitive types are not considered. All methods that read from, write to or call the
methods of a particular type are associated with the principle class of that type. Once we have these
principle classes we generate three types of views names as fundamental View, common interaction
view and association view.
Example: Consider the following java package:
i)
Principle Classes Extracted: Using this java package as input the principle classes extracted by our
tool are shown below where the first entry represents a class and the ones below it are its methods.
ii)
Generating Views: Three views can be extracted using FCA called fundamental, interaction and
association. These views help in detecting class hierarchies by examining principal classes. These
also help in reducing structure and information provided by the concept lattices generated for the
classes. The views are explained as follows:
i)
Fundamental View: It provides a hierarchy of methods using attributes in a principal class. Its
FCA context tells us the relationship between the methods and attributes of a principal class.
Concept Lattice: The concept lattice for the fundamental view of each principle class is as
follows. The lattice for principle class C is empty as this class contains only one method
which is not accessing any attributes of the class.
ii)
Common Interaction View: This view helps understanding the interaction of various methods
present within the principal classes for their possible categorization as interface methods or
functionality provider.
Concept Lattice: The concept lattices for this view are as follows. The lattice of each principle class
shows the relationship between its own methods and methods of other principle classes that are being
invoked.
iii)
Association View: This view depicts the degree of usage of a principal class within methods of the
current principal and hence its place within the hierarchy of the principal class.
Concept lattice: The required lattices are shown below which tell about an attribute of its own type or
other principle classes that are being accessed by a method.
Findings: Each view generated has its significance and tell us how a set of java classes can be
hierarchically arranged to remove various design defects.
IV.
References:
1.
Fernandez-Manjon, B. and Fernandez-Valmayor, A. 1998. Building Educational Tools Based on
Formal Concept Analysis. Education and Information Technologies 3, 3-4 (Dec. 1998), 187-201.
2.
Formica, A. 2008. Concept similarity in Formal Concept Analysis: An information content
approach. Know.-Based Syst. 21, 1 (Feb. 2008), 80-87.
3.
Dekel, U. and Gil, Y. 2003. Revealing Class Structure with Concept Lattices. In Proceedings of the
10th Working Conference on Reverse Engineering (November 13 - 17, 2003). WCRE. IEEE
Computer Society, Washington, DC, 353.
4.
Bhatti, M. U., Ducasse, S., and Huchard, M. 2008. Reconsidering Classes in Procedural ObjectOriented Code. In Proceedings of the 2008 15th Working Conference on Reverse Engineering Volume 00 (October 15 - 18, 2008). WCRE. IEEE Computer Society, Washington, DC, 257-266.
5.
Moha, N. 2007. Detection and correction of design defects in object-oriented designs. In
Companion To the 22nd ACM SIGPLAN Conference on Object-Oriented Programming Systems and
Applications Companion (Montreal, Quebec, Canada, October 21 - 25, 2007). OOPSLA '07. ACM,
New York, NY, 949-950.
6.
Ar´evalo, G., Ducass, S., Nierstrasz O., Understanding Classes using XRay Views
Institut f¨ur Informatik und angewandte Mathematik, University of Bern
3012 - Bern, Switzerland
7.
Streckenbach, M. and Snelting, G. 2004. Refactoring class hierarchies with KABA. In Proceedings
of the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems,
Languages, and Applications (Vancouver, BC, Canada, October 24 - 28, 2004). OOPSLA '04. ACM,
New York, NY, 315-330.