A Formal Description of Design Patterns Using OWL

schoolmistInternet and Web Development

Oct 22, 2013 (4 years and 22 days ago)

95 views


Page
1



A
F
ormal
D
escription
of Design Patterns
U
sing OWL





Jens Dietrich, Chris Elgar


Massey University New Zealand
, SolNet Solutions

Ltd


j.b.dietrich@massey.ac.nz ,
chris.elgar@gmail.com




Abstract


Design patterns have been used
successfully
in the la
st decade
to re
-
use a
nd
communicate object
-
oriented
design. However,
the documentation of pattern

usage
is often
very poor. This motivates the use of tools
which can detect and document design patterns
found in software. A couple of approaches
have been pr
oposed in recent years. The
approach introduced here is based on a formal
description of design patterns using the web
ontology language OWL. Software artefacts
used to
define

design patterns in a formal and
machine processable fashion are represented
by u
niform resource identifiers (URIs). This
yields a description that is open and extensible,
and facilitates the sharing

of design among
software engineers.

We discus
s

the developed
software design ontology, and how this
approach relates to the meta


modell
ing
architecture of the OMG.

In the second part, an effective pattern
scanner fo
r the java language is presented.
This scanner is based on the ontology
developed in part
one
and uses reflection and
AST analysis to verify constraints. Various
a
pplications o
f this scanner are discussed.


key words:
software design theory, object
-
oriented programming, semantic web, design
patterns, web ontologies
, automated pattern
detection



1.
Introduction


Software design patterns are an approach to
facilitate design re
-
u
se in software engineering.
Used by practitioners in
the OO community for
many years
,

design patterns w
ere first
catalogued by Beck
[2]

and Gamma, Helm,
Johnson and Vlissides

[13]

inspired by the
work

of on architectural patterns

by Alexander
[1]
. While the original intention for creating
pattern catalog
ue
s was to provide a toolbox for
designers, there are other use cases as well. In
particular, the knowledge about design
pa
tterns

helps to comprehend complex software.
This is
backed up by Cline

[5]

who
observed

that
patterns can be used in several ways.

The first
is reactively where they can be used as a
documentation tool, making it easier for a t
eam
to absorb new developers. Patterns can be used
proactively for building robust designs with
well understood tradeoffs. Finally, they can be
used to give software a hinge. A hinge is a
place where software is designed to be adapted
to provide new functi
onality. Identifying
patterns can help prevent maintenance
programmers accidentally damaging the
software’s well designed adaptability.


Recognising patterns in most cases requires
the documentation of the respective patterns.
This is mainly due to the us
er interface (the
source code view) software engineers have to
visualise software: one particular software
artefact

(usually a class or a method) is
displayed on the computer screen at a time, it
is taken out of context while a design patterns
is an arrang
ement of many
artefacts
. If UML
diagrams or similar

graphical representations
are used, the pattern is hidden by
the presence
of
other
artefacts

which are not part of the
patterns but
also
displayed in the
respective
diagram. A pattern documentation can ha
ve
different forms, as a separate document
(separate from the source code), a UML class
diagram

showing only or highlighting
the
participants of the pattern

or documentation in
source code comments. If a formal language is
used
to markup patterns
(like jav
adoc tags) this
can be the

base for various tools (such as

XD
oclet
) which can produce
high

level design
pattern documentation.


Unfortunately
, disciplined source code
documentation is not
practi
c
ed
very often. Its

Page
2


importance is underestimated by programme
rs
and under
-
prioritised by project managers. As
an activity which does not yield short
-
term
benefits, documentation is one of the first
victims when projects come under pressure.
Moreover, experienced software engineers
tend to use sophisticated design pa
tterns
without being aware of this,
for them it
is
simply best practi
c
e. This becomes a problem
if they collaborate with less experienced
software engineers who desperately look for
clues in the source code and documentation
which could help them to unders
tand the
complex structure of the design, such as
references to design patterns. A possible
solution for this dilemma is the automatic
detection and documentation of design
patterns. This would also fit well into
the

agile
software engineering approach wit
h a design
patterns detection and documentation tool
integrated into
a

build
script
, updating the
design pattern document at build time, usually
at least daily.


Tools like this have to be based
on

a formal
description of design patterns which can then
be
translated into a host programming
language. Starting from the original “Gang of
Four” catalog
ue

[13]

p
atterns have been
defined in a
semi
-
formal fashion by using
various
OMT diagrams
. UML remains a
popular

modelling language fo
r design
patterns
, although it
does not support

variables
that are

required to define pattern
s

[12]
. While
standard UML is
employed

to describe
classical object
-
oriented design patterns,
extension
s

like UML profiles and even new

modelling languages defined using the meta
object facility (MOF)
could

be used to describe
patterns which use other code artefacts not
included in the
core UML
vocabulary
(su
ch as
point cuts and advi
c
e for AOP

related patterns

and
request forwarding in we
b application
design patterns). Tagged values can be used to
associate

meta data

with patterns and pattern
participants
.


Cataloguing

and publishing

design patterns
is a community effort.
Catalogues

are used to
gather and share knowledge
about

software
de
sign.
This motivates the use of a modelling
language that is inherently designed for
distributed modelling. RDF (resource
description framework)

[24]

and OWL (we
b

ontology language)

[26]

are standards

which
are cornerstones

of the W3C semantic web
initiative. They are powerful languages to
represent knowledge in a machine
understandable fashion

based on a simple
data
model
using

linked resources
. While RDF is a
simple language to express binary relatio
nships
between resources identified by URIs
,
OWL
can be used to define vocabularies which are
then used to describe resources. One of the
biggest advantages of using semantic web
mark
-
up languages to represent knowledge is
its openness: once a consensus ha
s been
reached how to represent resources using
URIs, new knowledge can be easily added by
adding new statements about these resources.
This includes making statements associating
resources with classes and other resources.
While there might be one documen
t containing
one ontology in which a certain core of design
patterns is described, other documents can
easily extend these descriptions by making
additional

asse
rtions about the same resources.

This is,

pattern descriptions can take advantage
of the

OWL op
en wor
l
d assumption

[21]
.
Models using different URIs can be explicitly
merged
or disjoined
using
sameAs

and similar
constructs OWL offers

for this purpose
. There
is no doubt that such an open, decentralised
approach can lead to

inconsistenc
ies
. This
would

just reflect that different experts do not
agree on how to define particular design
patterns.

But semantic web technology also
offers the means to handle inconsistency


statements can be tagged with meta
information using RDF
reification (e.g., using
the Dublin Core meta data vocabulary

[8]
), and
applications can use this meta information to
consolidate inconsistencies. In many cases, this
turns out to be a matter of trust


applications
will prefer
knowledge from so
urces they trust
most
.


The approach presented here is based on
the idea to represent design patterns and
software artefacts participating in these
patter
ns as resources identified by
URI
s
, and to
develop a simple set of
relationships bet
ween
constraints

which can then be used to describe
these patterns. This leads us to a programming
language independent representation of design
patterns. Moreover, by using formal languages
like RDF and OWL with a well
-
defin
ed syntax
and
a
formal semantic
s

we
can
support tools to
access these descriptions and to use them to
detect design patterns in programs. Further
services can then be investigated which are
based on these pattern detectors.


In
the next chapter

w
e
introduce

the
vocabulary used to descr
ibe design patterns
.
W
e
then
outline how the constraints defined in
this description can be
translated into formal
logic
. This forms the base for a pattern
scanner
.

Finally, we discus
s

some applications
that can be
built using the pattern scanner, and
disc
u
s
s a couple of related approaches.


Page
3


2.
The Software Design Ontology


URIs are designed to represent objects that
are not necessarily network
-
accessible. In our
approach, URIs
used to describe design

patterns are composed from
a

base UR
L

derived from the h
osting academic institution

(Massey University NZ)
,
the project name
,

and
the common pattern name. Using
sameAs
,
this URI can be declared as a synonym for
alternative URIs, for instances URIs which
consist of the ISBN number of the book where
the pattern h
as been introduced (like the GoF
catalogue
[12]
) and the number of the page
where the pattern has been defined. We build
URIs for artefacts which are part of a pattern
by using the pattern URI and appending the
name of the role
the respective a
rtefact has
within the pattern using the dot character as
separator.



In OWL, resources can be associated with
(
owl
-
) classes, which are themselves
considered to be
resources. Resources are
associated with resources representing classes
w
ith statements using
rdf:type

property.

The v
ocabulary defined so
far
contains

the
following OWL classes:



These classes have
properties and
associations which can be used to define
design patterns, in particular properties such as
isAbstract
,
isStatic

a
nd associations
such as
contains

(associating
ClassTemplate

and
MemberTemplate
)
and
isSubclass
-
Of

(associating
ClassTemplate

and
ClassTemplate
).
Further information is attached to the resources
by using the standard Dublin Core meta data
vocabulary
[8]
.

The “
T
emplate
” postfix is
used to indicate that the instances of this type
are not (OO
-
) classes or members but roles for
classes and members.
For instance
, if we have
a resource
ConcreteFactory

of the type
ClassTemplate

which is
part of the
definition for the design pattern
AbstractFactory
, then this resource is a
role for a concrete OO
-
class in
the context of
this

design pattern.


Observe

that the description of a design
pattern does not include concrete classes,
members or othe
r software artefacts, although
the common use of UML models describing
design patterns seems to suggest this. If a
pattern like
AbstractFactory

is described
and a class
ConcreteProduct

is used
within this description, this does not mean that
there is a cla
ss with this name. It is just a place
holder for a class, a role name. Only a pattern
instance

would have concrete classes
implemented in a particular programming
language, and there would be an instantiation
relationship between these classes and the

role
s
in the pattern, and between the pattern instance
and the pattern definition.
This is the reason
that UML class models as well as other M1
models are inadequate to describe design
patterns (see also
[12]
).
This motivates

the
fo
llowing stack of meta
-
models to represent
design patterns.




This is different from the standard OMG
four layer meta modelling architecture
consisting of 4 layers

[20]
: object instances
(M0), model
(s) (M1), meta model(s) (M2) and
a
hard
-
wired
meta
-
metamodel

M3. While M0
and M1 are kept as they are, three new layers
are used to describe patterns. The OWL layer
is the meta
-
metamodelling layer which
consists of OWL as a language to define
models.
It

co
rresponds to M3 (MOF).
Concepts like OWL classes and properties are
defined in this layer

and these concepts

are
then being
used to define ontologies.
This layer
contains the

ontology firmware.
The OO
Design Ontology layer

(ODOL)
is the meta
modelling laye
r (corresponding to M2) which
contains the definition of concepts of the
design ontology. These concepts are instances
of OWL concep
ts like classes and properties
.
The
*Template

classes and the
Pattern

class are defined here. We refer to these
classes as

O
WL

classes
. The pattern
description layer (PDL) contains assertions

Figure
2
.

Meta Modelling Architecture
Used



Figure
1
.

Core classes in the OO
design Ontology, a
ll edges represent
owl:subClassOf

predicates.



Page
4


made using the vocabulary developed in the
ODOL layer. In terms of knowledge
representation it

is the A
-
Box, while ODOL
represents the T
-
Box.
The resources used in
this descr
iption are sti
ll not OO classes or

members (i.e., instances of M1) but roles
classes

and other artefacts
have

in a certain
context.
T
hese roles are associated with types
defined in ODOL.


A pattern definition itself is an instance of
the
OWL

class
Pattern
. It is repres
ented by
a set of
RDF

statements which associate
certain resources representing the participants
in the design patterns (such as classes and
members),
define property

values (statements
with literals) and associating the appropriate
OWL type with the resou
rce. While this can be
done manually by writing the respective
RDF/XML file, ontology ed
itors such as
Protégé
[23]

can be used to facilitate the
authoring of the pattern definitions.


The current vocabulary developed is rather
small, and does not support programming
language specific features. While design
patterns have been introduced as programming
language independent in order to facilitate
design re
-
use across languages, it does make
sense to have programming language
depend
ent patterns. Language features such as
interfaces and inner classes have been
introduced to facilitate good design, and are
used in design patterns even

if this restricts the
scope of

re
-
use to languages supporting these
features.
Supporting these feature
s
would
require
an extension of
the current vocabulary.
Recent developments like Aspect
-
Orient
ed
Programming (AOP)

and meta data
annotation
[16]

are likely to require an extension of this
vocabulary as well.



It is not our intent

to develop a
complete

monolithic vocabulary that covers all aspects
of object
-
oriented technology.
R
ather
, we are

interested to define a small core vocabulary
,

and show how
some
patterns can be described,
and how tools and s
ervices can work with
these
definitions
. It is

hop
ed

that other groups
will define their own vocabularies which can
then be combined.
In practical terms,
extending the vocabulary means
:


1.

C
reate

an OWL
document
.

2.

I
mport the existing vo
cabulary
[28]
.

3.

A
dd new
OWL
classes (such as
AspectTemplate
) and
/or

properties
(such as
isInnerClassOf
)
.

4.

P
ublish the document on
an

http server
.


The documents containing the
vocabulary

definition and the pattern descriptions are
different resources li
nked by
<owl:imports>

elements. This amounts to
a
physical
separation of TBox and ABox. An
additional resource, the catalog
ue

document,
consists of
<owl:imports>

references to
the elements of the catalog
ue
.








3.
Detecting

P
atterns


Detecting the patterns which occur in a piece
of software (a program or library) amounts to
find
ing

a set of instances for the templates used
in the pattern description. This can be formally
expressed as a derivation rule
if the statements
are map
ped to predicate logic.
Using predicate
logic to formally describe patterns has been
proposed by Eden
[12]
.



Definition

A a pattern description is a tupel
(R
A
,R
B
,R
U
,B,U
)

consisting of



a finite set
R
A
= {art
i
}

of resources
rep
resenting software artefact.



a finite set
R
ASS

= {ass
i
}

of
resources representing associations
between artefacts.



a finite set
R
PROP

= {prop
i
}

of
resources representing properties of
artefacts.



a set L of property values (literals)



a relation
C
ASS



R
A



R
A


R
ASS

called
association constraints
.



a relation
C
PROP



R
A



L


R
PROP

called
property constraints
.



Figure
3
.

The Abstract Factory Pattern
as RDF graph



Figure
4
.

The modular

struct
ure of the
OWL documents.







Page
5


In the
AbstractFactory

pattern
example used before, the pattern description
consists of the following elements:


R
A

=

{AbstractProduct,Abstrac
tFactory,
AbstractFactory.Creator,
ConcreteProduct, ConcreteFactory,
ConcreteFactory.Creator}

R
ASS

=

{
isSubclassOf,overrides,contains,

returnType}

R
PROP

=

{isAbstract,namingPatterns}




{dublin core attributes}

C
ASS
=

{(AbstractFactory
.Creator
,

AbstractP
roduct,returnType),

(ConcreteProduct,AbstractProduct,
isSubClassOf), ..}

C
PROP

=

{
(AbstractFactory,isAbstract,
abstract
)
,..
}


These constraints can be translated into a
derivation rule as follows:

1.

each element
art
i



R
A

is associated with
a variable ter
ms
<art
i
>
.

2.

each element of
ass
i



R
ASS

is
associated with a binary predicate
p
-
ass
i


3.

each element of
prop
i



R
PROP

is
associated with a binary predicate
p
-
prop
i


4.

each literal

l

L
is associated with a
constant term

[l]

5.

we introduce a n
-
ary predicate symb
ol
pattern_instance
, n is the size of
R
A
.


Using this mapping, the description can be
translated into the following derivation rule:


pattern_instance
(<art
1
>,..,<art
n
>)



i
{
p
-
ass
i

(<art
i1
>,<art
i2
>)}



j
{
p
-
prop
j
(<art
j1
>,
[
l
j2
]
)}


To find pattern in
stances means finding
substitutions for the variables in thi
s rule. To
achieve this, a fact

base is necessary consisting
of facts built for the predicates
p
-
ass

and
p
-
prop

and containing constant terms which can
be used to replace the variables. Establishi
ng
this fact base defines a model
for

the pattern
definition. Once the fact base is known,
standard derivation mechanisms like
unification can be used to find the pattern
instances. Suitable tools
include Prolog

or
Prolog like systems with direct support f
or
objects
such as

mandarax
[7]
[19]
.



Therefore,
the task of
detecting design patterns
in software is reduced to finding a fact base for
the above
-
mentioned rule. The constant terms
of these facts co
nsist of references to software
artefacts such as classes, methods and fields.
We can think of these references as unique
names for the artefacts. Since these artefacts
are implemented in a certain programming
language, the fact base itself is programming
language dependent. For instance, the
following are facts built from standard java
classes and methods

(
the
package name


java.lang


is
omitted
)
:


isSubclassOf(
String
,
Object)

contains(Object,

Object#equals)

overrides
(
S
tring#equals,Object#equals)


The refer
ences used here are strings which are
unique through the uniqueness of java package
names. Methods and other members are scoped
by the full class names, anonymous inner
classes can be named using numbers. The
software artefacts itself may have different
re
presentations which can be explored by
builder programs to build the fact base. In
particular, the following representations are of
interest:


1.

Reflection
.
Many

programming languages
support reflection. Classes, methods and
related concepts are represented

by objects,
and their relationships can be explored by
using the API of the respective classes.
This also includes analysis of meta data like
JSR
-
175 style meta data annotation.

2.

Source code analys
i
s. Here, the source code
for the respective artefacts is p
arsed and
represented as abstract source code tree
(AST).
A good use case
for source code
analysis
is detection of
the single class
pattern
Immutable
[14]
.

The AST of classes
must be parsed in order to detect
expressions assigni
ng
values to instance
variables. If all expressions occur in the
scope of constructors, then the class is an
instance of the immutable pattern.

3.

Dynamic runtime analysis.
T
he code is
executed and
monitored
. This can be done
with debugging interfaces or usin
g newer
approaches like
AOP style method
interception. If the software has been
developed using test driven development,
the test cases can be used as entry points for
the runtime analysis.


4.

Document annotation analysis. This is only
useful if patterns hav
e been documented
using a formal notation. Then tools like
XDoclet can be used to
build

the respective
facts.

5.

Analysis of naming patterns.


Observe that t
he fact base

for certain
predicates can be buil
t

using several
representations. Documentation analysis

and
the analysis of naming patterns are
inherently
weak
as

they include a human factor. However,
there are
situations

when it is necessary to
resort to these means. For instance, consider
the pattern Remote Proxy or Ambassador

[6]
[13]
, a variation of the
P
roxy pattern.
Let us

Page
6


assume that we try to build facts for a property
forwardToRemote

for methods. The
semantics of this method is
as follows
: each
method
call
is forwarded

in a call to a remote
serv
ice
,
optionally with
some
additional
pre
-

or
post processing
. The protocol
s

used here could
include CORBA, DCOM, SOAP or RMI.
Methods 1
-
3 are highly impractical here:
higher level programming languages use OS
services for networking, these services are
usu
ally written in a different programming
language and the source code is not available.

A better solution is to perform call graph
analysis
up to

a point where frameworks such
as CORBA, RMI or calls into OS functions are
recognised based on their names.


F
or

some patterns the fact base depends on the
context.
P
attern instances might only appear in
a
certain

environment. For example, consider
Dynamic Linkage
[14]
.
This pattern contains a
participant

ConcreteLoadableClass
.
Classes

in this role are loaded
dynamically;

their class names do not occur in the code but
are configured using configuration files,
system properties or similar mechanism.
Therefore, an instance of this pattern might not
occur in a design time context (unless i
nstances
of
ConcreteLoadableClass

are pre
-
sent, for instance in order to facilitate

unit

test
cases
)
. In this case we might even question
whether we are interested to find an instance of
the pattern
according to the definition given, or
whether it is the
very nature of the pattern that
an occurrence (to avoid the term instance here)
does contain a free variable.

4.
Building a Design Pattern Scanner


Using a
n

SLD
-
resolution based approach such
as Prolog to find the pattern instances can be
very ineffective
. When searching solutions
goals such as
isSubclassOf(x,y)

have to
be proved. In most cases one of the variables
will have a binding since it occurs in another
goal that has already been proved. For
instance, let

u
s assume that
x

has a binding:
x/MyClass
,
with
MyClass

being the name
of a class in the target programming language.
It would be extremely ineffective to scan the
entire fact base (or at least all facts with the
isSubclassOf

predicate) and to match the
first term with
MyClass

(i.e. applying a
simp
lified unification algorithm) for each fact
to find the substitution for
y
. It is more
effective to use the existing variable bindings
to reduce the search space for all open
variables. In the example given, we only have
to search facts like
isSubClass
Of

(
MyClass,C1)
,

isSubClass
Of(
My
-
Class,


C2)
, .. for all classes
{C1,C2,

..}

which are super classes of
MyClass
.
This is a small number determined by the class
hierarchy depth.


A reference implementation of a design
pattern scanner based on the OWL model ha
s
been developed for the java programming
language

[27]
[28]
. The pattern descriptions are
imported using the Jena RDF API
[15]

and the
constraint names are mapped by a
Cons
traintFactory

object to instances of
the
Constraint

class
providing

the intended
semantics of the constraint. In particular, they
have methods returning possible variable
substitutions for one variable if the other
variable has already been replaced. This
is to
support an effective search algorithm described
in the last paragraph. The constraint resolver
works relative to a
WorkSpace

object that
describes the domain. This includes references
to the objects representing classes, methods
and other
artefacts

o
btained by reflection,
source code analysis and other means. Source
code analysis is used for constraints such as
ActualReturnType

(which can not be
evaluated using reflection, in contrast to
DeclaredReturnType
). The source code
analysis layer uses the AST

representation of
the Eclipse IDE. This

tool dependent
layer is
designed in a way that it can be easily replaced
by an alternative tool providing AST analysis,
such as NetBeans.


The
scanner is built around
classes
representing

the
concepts,
properties a
nd
associations
introduce
d in ODOL layer
.
In
these classes, the semantics of these
associations within the given context (Java and
the
particular
tool environment)
is
implemented
. In particular, binary constraints
have to implement the following methods

de
clared in the
Binary
Constraint

inter
-
face
:




String getName()

-

used to establish the
associations with the ODOL concepts.



boolean c
heck(Object,Object,Work
-

space)



check whether there is an
association between template instances
(e.g. instances of
Class

or
Method
)
.



Iterator getPossibleInstances1(Work
-

space, Object)



get the extension of the
second variable within the workspace if
there
i
s a binding for the variable in the
first slot.



Iterator getPossibleInstances2(Work
-

space, Object)



get the extensio
n of the
second variable within the workspace if

Page
7


there
i
s a binding for the variable in the
second slot.


These methods are used by the
ConstraintResolver

to implement the
effective search algorithm described.


The tool has been designed to fit into agi
le
software
engineering

practise. It can be
deployed as standalone program or as an ANT
task. The intention is that the tool can be used
alongside other quality assurance and
documentati
on tasks such as JUnit, JDepend,

Clover and
y
D
ocs
. The ANT task output
s an
HTML
report which is generated from a
Apache V
elocity template
. This document has
the form of a pattern report. There are various
test
cases based on the examples in
[14]

to
validate that the tool is finding a correct and
c
omplete set of patterns in test environments.



The following table summarises some
result obtained with version 0.2. It should be
noted that the results are not yet final since the
source code analysis is not yet complete
ly
imp
lemented
. In particular, the
current
version

of the tool

does not yet analyse
the AST of
anonymous inner classes.

Profiling the
application reveals that a significant portion of
the time is used to parse the source code files.
Since the AST objects are cac
hed, the
performance will improve if software is
scanned for more than one pattern.

The scanner
can be configured to omit certain constraints.
In the examples given here, the naming pattern
constraints are not checked. Adding naming
patterns improves the p
erformance of the tool
dramatically, but also reduces the number of
pattern instances found. Some instances
detected are strange in the sense that they
contain classes which
are
instances of more
than one participant. In particular, methods
with a copy / c
lone like semantics cause the
scanner to detect
AbstractFactory

instances
with classes being factories and products at the
same time.
This situation

is not yet
concept
ual
ised in the current version of the
ontology, and ignored by the scanner.



Library

Cl
asses

Abstra
ct
-
Factory

Instances

Time

(ms)

AWT and Swing


(JDK 1.4.2 for
Windows) Standard
java GUI Libraries.

610

4

22,703

JDBC API and

MySQL
ConnectorJ Driver
Database con
-
nectivity API and
implementation for
MySQL database.

104

21

2469

Mandarax 3.3.
1
Java API for
derivation rules.

358

44

4,547

Xerces 2.6.2
Apache XML
Parser and W3C
DOM but no SAX
APIs.

817

44

1,325,906

= 22 min

WOP 0.1 The
pattern scanner
itself.

182

4

1,016


These results have been obtained on a
Windows XP platform using Suns JD
K 1.4.2,
the Eclipse 3.0 AST API, a
Mobile
Pentium 4
3.06 MHz
CPU

and 512
M
B

of memory.

6.

Further and Related Work


The existing ontology is rudimentary and
must be extended to add enough
expressiveness to describe a larger number of
patterns. At the same
time, the relationships
defined in the vocabulary must be
implemented in the

target
programming
language
s

in order to support tools like the
pattern scanner
. This task remains challenging
and requires time and resources. Another
useful extension is to deve
lop
parallel
ontologies
which extend the core ontology by
adding

language dependent features,
for
instance
a
JDK

5 “Tiger”

ontology.


The concept of describing design patterns
which are considered to represent “wanted”
design fragments can be easily extend
ed to anti
patterns representing “unwanted” design
fragments.
The natural next step is
a formal
description of
transformation
s

(refactoring
s)
from anti
patterns
to

patterns and the generation
of constraints and test cases to safeguard these
transformations.



There are numerous approaches to a formal
description of design patterns.
To our
knowledge, there is no approach that uses
semantic web technology to describe software
<target name="scan">

<taskdef

name="runScanner"

classname="nz.ac.massey.c
s.

wop.scanner.anttask.WOP"
/
>

<runScanner

jarfile="
mylibrary
.jar"

o
utputfile="
report
.html"

patternfile="http://www
-
ist.massey.ac.nz/wop/wop
-
ca
talog.rdf"/>


</target>


Page
8


design.

The approach
close
st

to what has been
presented here is Eden’s
approach to us
e
predicate logic to
describe design patterns
[9]
[10]
[12]
. Eden uses the term design model
for the fact base.
For the formal specification
of patterns Lepsus (
Languag
e

for

Patterns
Uniform Specification
)
is used. Lepsus is a
subset of higher order logic, and has a
symbolic and a visual language. Eden shows
how the formal representation can be for
reasoning, e.g. to proof refinement
relationships between patterns

[10]
.
A more
practical approach by Krämer and Prechelt is
based on Prolog
[17]
. The terminology used to
define patterns is expressed as a set of Prolog
predicates, and pattern instances are solved
based on a Pr
olog rule similar to the rule
introduced here. Prolog queries are used to find
the pattern instances.


Taibi and Ngo
[25]

introduce the Balanced
Pattern Specification Language (BPSL) based
on a combination of PL1 to represent st
ructural
aspects and temporal action logic to represent
behavioural aspects. The language is based on
the syntax of formal logic.


Dong and Yang
[8]

propose using the UML
extension mechanism to define a modelling
language for p
atterns.
D. Mapelsden, J.
Hosking and

J. Grundy

[18]

propose a visual
modelling language called Design Pattern
Description Language (DPML).
The CrocoPat
tool
[3]
[4]

support
s the detection of design
patterns which can be defined using
the
Relation Manipulation Language (RML).
These descriptions can be evaluated with
respective to a set of relations defined using
the Rigi Standard Format. This database
is

built before the tool

scans for design patterns.


A related interesting open source project is
PMD
[22]
. It is a source code analysis tool that
analyses Java source code for antipatterns.
Patterns are considered as node sets in the
source code tree

and described using XPath.

6.
References


[1]

C.
Alexander
,

S.
Ishikawa,

M.

Silverstein,

M.

Jacobson,
I. Fiksdahl
-
King
,
S.
Angel
,


A Pattern
Language
”,

Oxford University Press, New York,
1977.

[2]

K. Beck,


S
malltalk Best Practice Patterns”,

Prentice Hall. 1996
.

[3]

D. Beyer, A. Noac
k, C. Lewerentz,


Simple and
efficient relational querying of software structures
”,
Proceedings of the 10th Working Conference on
Reverse Engineering (WCRE 2003), pages 216

225. IEEE Computer Society, 2003.

[4]

D. Beyer, A. Noack
, “
CrocoPat
2.1 Introduction
an
d Reference Manual”,

Report No. UCB//CSD
-
04
-
1338. Computer Science Division (EECS),
University of California Berkeley, California. 2004.

[5]

M. P.

Cline,


The Pros and Cons of Adopting
and Applying De
sign Patterns in the Real World”,

Communi
cations of the ACM, vol. 39, no. 10,
October 1996, pp. 47
-
49.

[6]

J. O. Coplien,


Advanced C++ Program
-
ming
Styles and Idioms”,

Addison
-
Wesley, 1992.

[7]

J. Dietrich,


A Rule
-
Based Sy
stem for
eCommerce Applications”,

Proceedings KES 2004,
LNAI 3213 p 455. Springer
, 2004.

[8]

J. Dong, S. Yang, “
Visualizing Des
ign Patterns
With A UML Profile”,

Proceedings of the IEEE
Symposium on Visual/Multimedia Languages (VL),
pp123
-
125, Auckland, New Zealand, 2003.

[9]

The Dublin Core Metadata Initiative.
http://dublincore.org/

[10]

A. H. E
de
n, Y. Hirshfeld, A. Yehudai
,


LePUS
-

A Declarative Pattern Speci
-
fication
Language
”,

Technical report 326/98, Department of
Computer Science, Tel Aviv University.


[11]

A. H. Eden
,


LePUS: A Visual Formalism fo
r
Object
-
Oriented Architectures

,

The 6th World
Co
nference on Integrated Design and Process
Technology
, Pasadena, California, June 22

28,
2002.

[12]

A. H. Eden,


A Th
eory of Object
-
Oriented
Design”,

Information Systems Frontiers 4 (4),
Nov.

Dec. 2002. Kluwer Academic Publishers.


[13]

E. Gamma, R. Helm, R. Johnson,

J. Vlissides.
Design Patterns: Elements of Reusable Object
Oriented Software. Addison
-
Wesley, 1994.

[14]

M. Grand,


Patterns in Java. A Catalog of
Reusable Design Patterns Illustrated with UML
”,

Wiley, 1998.

[15]

The Jena Project


A Semantic Web
Framework for Java
.

http://jena.sourceforge.net/.

[16]

JSR 175: A Metadata Faci
lity for the JavaTM
Programming Language.
http://jcp.org/en/jsr/detail?id=175
.

[17]

C
.

Kr
ä
mer, L
.

Prechelt, “
Design Recovery by
Automated Search for Structural Design Patterns in
Object
-
Oriented Software

,

Proceedings of the 3rd
Working Conference on
Reverse Engineering
(WCRE '96) , 1996.

[18]

D. Mapelsden, J. Hosking, J. Grundy
, “
Design
Pattern Modelling and Instantiation using DPML
”,
Proceedings of the Fortieth International Conference
on Tools Pacific. Austr
alian Computer Society,
2002.

[19]

The Mandarax Pro
ject,
http://www.mandarax.org.

[20]

Meta Obje
ct Facility (MOF) Specification,
http://www.omg.org/docs/formal/02
-
04
-
03.pdf

[21]

OWL Web Ontology Language

Guide
.
W3C
Recommendation 10 February 2004
,

http://www.w3.org/TR/owl
-
guide/
.

[22]

The PMD Project
,


http://pmd.sourceforge.net/
.

[23]

The Protégé Ontology Editor and Knowledge
Acquisition System. http://protege.stanford.edu/.

[24]

Resou
rce Description Framework (RDF),

W3C Recommendation 10 February 2004
,

http://w
ww.w3c.org/RDF/
.

[25]

T. Taibi, D.C.L. Ngo, “
Formal Specification
of Design

Patterns


A Balanced Approach”,

Journal of Object Technoloy, vol. 2, no. 4, 2003, pp.
127
-
140.


Page
9


[26]

Web Ontology Language (OWL). W3C
Recommendation 10 February 2004.
http://www.w3.org/2004/
OWL/

[27]

WOP Project on sourceforge
,
http://sourceforge.net/projects/webofpatterns

[28]

WOP Ontology documents homepage.
http://www
-
ist.massey.ac.nz/wop/