(IJCNS) International Journal of Computer and Network Security, 11

Vol. 2, No. 1, January 2010

MCDMfJ : Mining Creational Design Motifs from

Java source code
Praneeth Kumar G1, Aditya Kumar K2
1
Corresponding Author,
Department Of Computer Science And Engineering,
Medha College Of Engineering,
Bibinagar, Andhra Pradesh, India
praneethkumar@hotmail.com
2
Department Of Computer Science And Engineering,
Krishna Murthy Institute Of Engg. & Tech.,
Ghatkesar, Andhra Pradesh, India
Kommera_adi@yahoo.com

Abstract: Design patterns are important in object-oriented
programming because they offer design motifs, elegant solutions
to recurrent design problems, which improve the quality of
software systems. Design motifs facilitate system maintenance by
helping maintainers to understand design and implementation.
However, after implementation, design motifs are spread
throughout the source code and are thus not directly available to
maintainers. We present MCDMfJ, a tool to semiautomatically
identify microarchitectures that are similar to creational design
motifs in source code and to ensure the traceability of these
microarchitectures between implementation and design. Thee
model followed consists of two layers: first layer to recover an
abstract model of the source code, including binary class
relationships, and another layer to identify design patterns in the
abstract model.
Keywords: Design pattern Identification. Design patterns in
Java, Interclass Relationships.
implementation of the model. Section 7 shows the results on
applying the model.
2. GOF CREATIONAL PATTERNS
Erich Gamma, Richard Helm, Ralph Johnson and John
Vlissides with a foreword by Grady Booch. Often called as
Gang of Four(GoF). GoF Creational patterns are Abstract
Factory , Builder , Factory Method, Prototype, Singleton.
Abstract Factory provides an interface for creating families
of related or dependent objects with out specifying their
concrete classes.
Builder separates the construction of a complex object from
its representation so that the same construction process can
create different representations.

1. Introduction Factory Method defines an interface for creating an object,

but let subclasses decide which class to instantiate.
A major task in software comprehension is the
understanding of its design and architecture. As software Prototype specify the kinds of objects to create using a
can get large, this task should be supported by tools prototypical instance, and create new objects by copying this
performing automatic analyses. Design, however, is hard to purpose.
detect automatically, as it is not tangible. Fortunately,
standard solutions to solve certain design problems have Singleton ensures a class has one instance, and provide a
been established. These design patterns are described global point of access to it.
together with the design problem(s) they intend to solve [1]. Most GoF patterns have concrete definitions on their
Many of them have been formalized, for example to realization in code structure and system behavior. Such
introduce them automatically into software [2]. If it were concrete definitions are traceable.
possible to detect these patterns in software systems, one
would be able to deduce the intended design.
3. Juxtaposition of current approaches
GoF creational patterns encapsulate standard ways of
These approaches analyze inter-class relationships to
creating objects in object-oriented design. The GoF
identify the structural aspect of patterns, regardless of their
catalogue describes, using a standard but informal notation,
behavioral aspect. The targeted inter-class relationships
five such patterns, each of which offers different features.
include: class inheritance; interface hierarchies; modifiers of
classes and methods; types and accessibility of attributes;
The rest of this paper is organized as follows :
Section 2 deals with a brief description of GoF creational
method delegations, parameters and return types. Some
Patterns . Section 3 juxtaposes the current pattern detection
approaches first extract inter-class relationships from source
tools. Section 4 presents the microarchitectures of different
code and then perform pattern recognition based on the
patterns. Section 5 and 6 gives a brief structure and
12 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 1, January 2010
extracted information. For example, DP++ [15], SPOOL
[14], Osprey [16], and Reference [13] extract interclass
relationships from C++ source to a database; patterns are
then recovered through queries to the database. Reference
combines the Columbus reverse-engineering framework
with the MAISA architectural metrics analyzer (which
analyzes software at the design level and had reported
limited results on recovering anti-patterns [12]) to build a
pattern recognizer. However, pattern recognition requires
analyzing program behavior, which can be abstracted away
at the design level. Reference [2] use the Columbus schema
for the extracted abstract semantics graphs (ASG) and
recover patterns based on graph comparison. Reference [11] Factory method :
extracts inter-class relationships and then uses software
metrics to reduce search space. SOUL [10] is a logic
inference system, which has been used to recognize patterns
(in Java and SmallTalk) based on inter-class-based code
idioms and naming conventions. SPQR [9] uses
denotational semantics to find patterns on the ASG obtained
by gcc. The accuracy of these approaches depends in part on
the capability of the program facts extractors they use.
FUJABA [7] extends the work from [8] and uses a bottom-
up-top-down approach to speed up the search and to reduce
the false positive rate (due to more complicated inter-class
relationship, such as aggregation [8,7]). It uses a
combination of inter-class relationships to indicate a pattern.
Thus, when such information is obtained from the bottom-
up search, even partially, FUJABA assumes the existence of
a possible pattern and tries to complete the rest of the
search—i.e., the top-down search—to confirm that such a
pattern actually exists. This iterative approach allows going
back to their annotated abstract syntax tree (AST) for Prototype Pattern :
further analysis on demand.

4. Micro Architectures Of GoF Creational

patterns

Abstract Factory pattern :

Singleton Pattern :

Builder Pattern :
 (IJCNS) International Journal of Computer and Network Security, 13
5. MCDMfJ : A Bi-layered Approach
MCDMfJ relies on a bi-layered approach, detailed in
the following sections. This model is developed on the basis
of reference[17], DEMIMA, Which is a generalized one for
identifying Design patterns from any kind of Source code.
5.1 First Layer : Source Code Model
The first layer consists of an infrastructure, e.g., parsers, to
Obtain models Ms of the source code of system. It includes
all the constituents found directly in any Java object-orinted
system: class, interface, member class and interface,
method, field, implementation and inheritance relationships,
and rules containing their relationships. The constituents
describe the structure of systems and a subset of their
behavior. We have implemented this layer in java.
5.2 Second Layer : Design-Level Model
In this layer, we first describe a model MDM of a design
motif with java, then MCDMfJ looks for the micro-
architectures similar to the design motif we described
earlier.
6. Implementation
Based on our methodology (Section 5), we have
implemented a fully automated pattern detection tool, called
MCDMfJ (Mining Creational Design Motifs form Java
Source code ). The current implementation of MCDMfJ
recognizes all the GoF creational patterns.
MCDMfJ is implemented as a GUI tool, with an
embedded pattern analysis engine. There are number of
advantages of using a compiler as the basis of a pattern
detection tool. A compiler constructs symbol tables and AST
that facilitate the inter-class and static behavioral analyses.
Compilers also perform some semantic checks that help
pattern analysis. Most importantly, compilation errors
reflect the incompleteness of symbol tables and AST, which
result in incorrect pattern detection results. However, some
tools, such as FUJABA and PTIDEJ, are able to partially
(with a fuzzy number) detect patterns from incomplete
source. Such tools can be desirable if pattern detection is
used as part of software forward-engineering, such as
building and incorporating patterns on the run. In our case,
pattern detection is reserved for reverse- engineering, where
accuracy is vital.
MCDMfJ begins its detection process for a given
pattern based on what is most likely to be most effective in
identifying that pattern (i.e., declarations, associations, or
delegations). This reduces the search space by pruning the
least likely classes or methods. The completeness of a
pattern detection tool is determined by the ability of
recognizing pattern implementation variants. For practical
reasons, MCDMfJ focuses on detecting common
implementation variants used in practice. Thus, some
behavioral analysis techniques are not fully applied to each
behavior-driven pattern. As an example, data-flow analysis
is applied to analyzing the activities of the flag variable that
guards the lazy instantiation in the Singleton pattern. The
flag can have any data type, but java.lang.Object (when the
Vol. 2, No. 1, January 2010
reference for the Singleton instance also acts as the flag) and
boolean are more common. Although a flag may be an
integer, it is not as common in this case and would require
much more computation
MCDMfJ only analyzes lazy instantiation that uses
boolean or java.lang.Object types. Inter-procedural data-flow
and alias analyses are only used for detecting patterns that
often involve method delegations in practice, such as
Abstract Factory, Factory Method.
7. Results and Analysis
We compared MCDMfJ with three other similar tools:
PINOT[1], HEDGEHOG [4] and FUJABA 4.3.1 (with
Inference Engine version 2.1).HEDGEHOG reads pattern
specifications from SPINE, which allows users to specify
inter-class relationships and other path-insensitive semantic
analysis (e.g., for Factory Method pattern, the predicate
“instantiates(M, T)” checks whether a method M creates
and returns an instance of type T.), but other more
complicated semantic analysis is hard-wired to its built-in
predicates (e.g., “lazyInstantiates(...)”). Thus, SPINE is
bounded by the capability of semantic analysis provided by
HEDGEHOG. To use the tool, the user specifies a target
class and a target pattern to verify against (i.e., attempt to
recognize).
Table 1: three tools
Tools
FUJA
Pattern MCDMfJ PINOT HEDGEHOG
BA
Abstract
Y Y Y N
Factory
Builder Y - - -
Factory
Y Y Y N
Method
Prototype Y - N -
Singleton Y Y Y Y
Y the tool claims to recognize the pattern and is able to
identify it in the AJP example
N the tool claims to identify this pattern but fails to identify
in AJP
- tool excludes recognition for this pattern.
FUJABA has a rich GUI for software re-engineering. Its
pattern inference engine provides a UML-like visual
language for user-defined patterns. The language allows
specifying inter-class relationships and a “creates”
relationship (which is the same as the “instantiates”
predicate defined in SPINE). FUJABA is easy to use: the
user simply specifies the location of the source code and
then runs the pattern inference engine. FUJABA displays
the results graphically. FUJABA can run entirely
automatically or incorporate interactive user guidance to
reduce its search space. PINOT is fully automated; it takes a
source package and detects the pattern instances. All
detection algorithms are currently hard-coded to prove the
correctness of our techniques on the structure- and behavior-
driven patterns.
14
Although these three tools were built for different uses,
they all involve pattern recognition. Thus, we compare these
tools in terms of accuracy. Table 1 shows the results of
testing each tool against the demo source from “Applied
Java Patterns”(AJP) [3]. Each AJP pattern example is
similar to the one illustrated in the GoF book [6]. Thus,
MCDMfJ tests a class against all pattern definitions.
FUJABA was also tested in the same fashion. HEDGEHOG,
however, is not an automated verification tool and users are
responsible of picking the patterns to verify against the
target class. Thus, HEDGEHOG’s results shown in Table 1
were based on prior knowledge of the source and only likely
patterns were verified against a class [4].
Future Work
The future work with MCDMfJ will : expand its pattern
identification capability to recognize more complicated user-
defined data structures; experiments with its use in tracking
software evolution by design; and its overall usability by
providing a visual specification language for defining
patterns and exporting our analysis results as XML for
external viewing.
References
[1] Nija Shi and Ronald A. Olsson, “ Reverse Engineering
of Design Patterns from Java Source Code”. 21st
IEEE/ACM International Conference on Automated
Software Engineering, August 2006.
[2] Z.Balanyi and R. Ferenc. “Mining Design Patterns
form C++ Source code”. In Proc. Of International
Conference On Software Maintainence.
[3] Stephen Stelting and Olav Maassen, Applied Java
Patterns, Prenctie Hall PTR.
[4] Alex Blewitt, Alan Bundy and Ian Stark “Automatic
Verification Of Java Design Patterns,” In Proc. of the
16th annual conference on Automated Software
Engineering. Nov. 2001 Pg.’s 324-327
[5] Pattern Stories : Java AWT. http://wiki.cs. uiuc.edu
/PatternStories/JavaAWT
[6] E. Gamma, R Helm, R Johnson, and J. Vlissides.
Design Patterns : Elements of Reusable Object –
Oriented Software. Addison – Wesley,
Reading,Masachussets,1995.
[7] J. Niere, W. Shafer, J.P. Wadsack, L. Wendehals, and
J.Welsh Towards Pattern Based Design Recovery. In
ICSE, pg.’s 338-348. IEEE Computer Society Press,
May 2002.
[8] J. Seemann and J. W. von Gudenberg. Pattern-based
design recovery of Java software. In Proc. of the 6th
ACM SIGSOFT International Symposium on
Foundations of Soft-ware Engineering, pg.’s 10-16.
ACM Press,1998
[9] J.M.Smith and D.Stotts. SPQR : flexible automated
design pattern extraction from source code. In ASE,
pg.’s 215-224. IEEE Computer Society Press, October
2003.
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 1, January 2010
[10] J. Fabry and T. Mens. Language Independent Detection
of Object-oriented Design Patterns. Computer
Languages, February 2004.
[11] G.Antonoil, R. Fiutem, and L.Cristoforetti. Design pat-
tern recovery in object-oriented software. In Proc. Of
the 6th International Workshop on program
Comprehension, pg.’s 153-160. IEEE Computer
Society Press, June 1998.
[12] J. Paakkii, A. Karhinen, J. Gustafsson, L.Nenonen, and
A.I Verkamo. Software metrics by architectural pattern
mining. In Proc. Of the International Conference on
Software Theory and Practice, pg.’s 325-332. 16th IFIP
World Computer Congress, August 2000.
[13] M. Vok´aˇc. An efficient tool for recovering design patterns
from C++ code. Journal of Object Technology,5(2), March-
April 2006.
[14] R. Keller, R. Shauer, S. Robitaille, and P. Pag´e. Pattern-
based reverse-engineering of design components. In Proc. Of
the 21st International Conference on Software Engineering,
pg.’s 226-235. IEEE Computer Society Press. May 2002.
[15] J. Bansiya. Automating design pattern identification -
DP++ is a tool for C++ programs. Dr. Dobbs
Journal,1998.
[16] A.Asenico, S. Cardman, D.Harris, and E. Laderman.
Relating expectationsto automatically recovered design
patterns. In WCRE, pg.’s 87-96,2002.
[17] Gue´he´neuc and G. Antonoil “ DEMIMA: A Multi-
layered approach for Design Pattern Identification.
IEEE Transactions on Software Engineering. Sep/Oct.
2008.
Authors Profile
Praneeth Kumar G received the B.Tech
degree in Computer Science And
Engineering from Progressive Engineering
College in 2008 . During May 2008-August
2009, he worked in Concepts Of
Computing(CIC) as a Software Engineer.
Now he is working with Medha College Of
Engineering as an Assistant Professor. His
area of interests include software
engineering, Information Security.
Aditya Kumar K received the B.Tech
degree in Information Technology from
Aurora Engineering College in 2008 .
During May 2008-August 2009, he worked
in Concepts Of Computing(CIC) as a
Software Engineer. Now he is working with
Krishna Murthy Institute Of Engineering
and Technology as an Assistant Professor.
His area of interests include software
engineering, Information Security.