An Object Oriented implementation of a K

An Obje
t-Oriented Implementation of a KE Tableau Prover
Adolfo Gustavo Serra Se
a Neto
De
ember 11, 2003

Abstra
t
The implementation of Automated Theorem Provers (ATP's) has been a resear
h theme in Computer
S
ien
e for a long time. ATP's have many appli
ations and some important results were obtained with
them. But the implementation of tableau based theorem provers has to be better developed, be
ause
tableau provers are usually
onsidered to be less eÆ
ient than Resolution-based provers. The KE system
[16℄ is an improvement, in the

omputational sense, over traditional Smullyan's Analyti
Tableaux [75℄,
that is more `natural' and more eÆ
ient than Smullyan's tableaux. Tableau-based theorem provers
an
be very useful for studying properties of logi
al dedu
tion, spe
ially if we
an give a good modularization
of proof strategies. Obje
t-orientation, aspe
t-orientation and other related te
hniques
an help us better
modularize proof strategies. That is the the main obje
tive of our resear
h: to a
hieve a better modularization of strategies in tableau provers. Having this in mind, we are in
rementally developing a KE

Tableau Prover. We have just nished our rst version, an obje
t-oriented KE tableau prover, whi
h we
will present here.

1 Introdu
tion
The implementation of Automated Theorem Provers (ATP's) has been a resear
h theme in Computer
S
ien
e for a long time. ATP's have many appli
ations and some important results were obtained with
them. But there is still mu
h to be done in this area. For instan
e, the implementation of tableau based
theorem provers has to be better developed, be
ause tableau provers are usually
onsidered to be less
eÆ

ient than Resolution-based provers. The Tableau method is a formal proof pro
edure that has many
variants and exists for several logi
s [28℄. One of these variants is the KE system [16℄, whi
h was presented
as an improvement, in the
omputational sense, over traditional Smullyan's Analyti
Tableaux [75℄. That
is, the KE System is a `natural' proof method and it is more eÆ
ient than Smullyan's tableaux.
Tableau-based theorem provers
an be very useful for studying properties of logi
al dedu
tion, spe
ially
if we
an give a good modularization of proof strategies. Obje
t-orientation, aspe
t-orientation and other
related te

hniques
an help us better modularize proof strategies. That is the the main obje
tive of our
resear
h: to a
hieve a better modularization of strategies in tableau provers. Having this in mind, we are
in
rementally developing a KE Tableau Prover. We have just nished our rst version, an obje
t-oriented
KE tableau prover, whi
h we will present here.

1

1.1

Outline

In se
tion 2 we will present automated theorem provers (ATP's) and automated reasoning (AR). ATP's

appli
ations, results and some other issues related to ATP's and AR will be brie
y dis
ussed. Then, in
se
tion 3 we will des
ribe our proje
t: an investigation into the
onstru
tion of Tableau based Automated
Theorem Provers using obje
t-orientation, design patterns, aspe
t-orientation, and some extreme programming te
hniques. After that, in se
tion 4 we will des
ribe with some diagrams and texts our
urrent
implementation.
Test results
omparing the performan

e of our system with an existing system are presented in se
tion 5.
Then some future works will be dis
ussed in se
tion 6: refa
toring (both obje
t-oriented and aspe
toriented), the writing of analysis patterns for ATP's, of a
omponent-based ar
hite
ture for Tableau
Provers and the development of a framework. In se
tion 7 we shall present our
on
luding remarks.

2 Automated Theorem Provers and Automated Reasoning
The implementation of Automated Theorem Provers (ATP's) has been a resear
h theme in Computer
S

ien
e for a long time. The history of this eld dates ba
k to the 1950s. Read below an ex
erpt of [14℄:
Automati
dedu
tion, or me
hani
al-theorem proving, has been a major
on
ern of AI sin
e
its earliest days. At the rst formal
onferen
e on AI, held at Dartmouth College in the
summer of 1956, Newell and Simon (1956) dis
ussed the Logi
Theorist, a dedu
tion system for
propositional logi

. Misnky was
on
urrently developing the ideas that were later embodied in
Gelernter's theorem prover for elementary geometry (see M
Cordu
k, 1979, p. 106; Gelernter,
1963). Shortly after this, Wang (1960) produ
ed the rst implementation of a reasonably
eÆ
ient,
omplete algorithm for proving theorems in propositional logi
.

ATP's have many appli
ations, among whi
h we highlight the following [15℄:
 proof of mathemati
al theorems

{ proof veri

ation: to dete
t and to
orre
t errors in proofs
{ theorem proving: to nd new proofs automati
ally
{ helping the tea
hing of mathemati
s
 suuport for designing reliable software
{ veri
ation: to nd errors or prove
orre
tion
{ optimization: to in
rease performan
e
{ synthesis: to generate
ode from spe
i

ations
 inferen
e engine for Arti
ial Intelligent systems
{ general problem solvers
{ robot planning
{ intelligent agents
In [69℄, one
an nd that \the rst published results from resear
h on automated dedu
tion using
ele
troni

omputers were those of Newell, Shaw, and Simon (1957) on the Logi
Theorist. This program
was based on an attempt to model human thought pro
esses. Martin Davis (1957) had a
tually designed
2

a program that
ame up with a proof in 1954, but the Logi
Theorist's results were published slighty
earlier. Both Davis's 1954 program and the Logi
Theorist were based on somewhat ad ho
methods that
did not strongly in
uen
e later automated dedu
tion.
(: : :)
Another use of theorem provers is as an assistant, providing advi
e to, say, a mathemati
ian. In this
mode the mathemati
ian a
ts as a supervisor, mapping out the strategy for determining what to do next
and asking the theorem prover to ll in the details. This alleviates the problem of semi-de
idability to
some extent, ba
ause the supervisor
an
an
el a query and try another approa
h if the query is taking
too mu
h time. A theorem prover
an also a
t as a proof-
he
ker, where the proof is given by a human
as a series of fairly large steps; the individual inferen
es required to show that ea
h step is sound are lled
in by the system."
Some theorem provers have even
ome up with new mathemati
al results, su
h as the settling of the
Robbins problem by the ATP System EQP in 1996. The Robbins problem remained open for 63 years.
The eld of Automated theorem-proving (ATP) is also known as:
 Automated dedu
tion [69℄
 Automati
dedu
tion [14℄
 Me
hani
al theorem-proving [13, 14℄
 Automated reasoning [82℄.
And theorem provers [69℄ are also known as
 Automated reasoners [69℄
 Theorem-proving systems [61℄.
However, in my opinion the use of the word reasoning is deli
ate. Reasoning is an a
tivity that
an
only be performed by human beings. In its beginnings, the eld of AI had too mu
h expe
tations. For
instan
e, a

ording to [69℄ (page 17), in a workshop at Dartmouth in 1956, Allen Newell and Herbert
Simon, two resear
hers from Carnegie Te
h, presented a reasoning program, the Logi
Theorist (LT),
about whi
h Simon
laimed, \We have invented a
omputer program
apable of thinking non-numeri
ally,
and thereby solved the venerable mind-body problem." This was
learly an exaggeration, although this
program later was able to prove most of the theorems in Chapter 2 of Russell and Whitehead's Prin
ipia
Mathemati
a.

But the denition of reasoning in the area of automated reasoning is mu
h more modest. For example,
[82℄ writes the following:
Reasoning is the pro
ess of drawing
on
lusions from fa
ts. For the reasoning to be sound,
these
on
lusions must follow inevitably from the fa
ts from whi
h they are drawn. (: : :)
The obje
t of automated reasoning is to write
omputer programs that assist in solving
problems and in answering questions requiring reasoning. The assistan
e provided by an automated reasoning program is available in two dierent modes. You
an use su
h a program in
an intera
tive fashion, that is, you
an instru
t it to draw some
on
lusions and present them
to you, and then it will ask you for further instru
tions. Or you
an use su
h a program in a
bat
h mode, that is, you
an assign it an entire reasoning task and await the nal result.
The implementation of ATP's has been dis
ussed in several books su
h as [82℄ and [27℄. Nowadays
there are several ATP's based on dierent proof te
hniques (Resolution, Natural Dedu
tion, Tableaux)
3

and implemented in distin
t languages (C, Prolog, Java, among others). A broad list of known systems
an be found in [49℄. Competitions are held amongst these systems [77℄ that use databases of problems
su
h as [77, 71℄.
The Journal of Automated Reasoning is the prin
ipal journal for theorem proving. And the major
onferen
e in this eld is the annual International Conferen
e on Automated Dedu
tion (CADE), as
informed by [69℄.

3 Proje
t
In our work we are investigating the
onstru
tion of Tableaux-based Automated Theorem Provers. We
are going to use obje
t-orientation, design patterns, aspe
t-orientation, and some extreme programming
te
hniques. Below we shall explain ea
h of these items. The result will be a tableau prover for
lassi
al
propositional logi
. It will be implemented in Java and Aspe
tJ and during its development we intend to
use, whenever we feel it is adequate, design patterns and some extreme programming te
hniques.
Two tableaux-based automated theorem provers will serve as a base for our studies: the system
presented in [20℄ and jTAP [6℄. Besides being tableau-based, both were implemented in obje
t-oriented
programming languages.
3.1

Tableaux

The Tableaux method is a formal proof pro
edure that has many variants and exists for several logi
s
[28℄. Tableau methods have been found to be a
onvenient formalism for automating dedu
tion in various
non-standard logi
s as well as in
lassi
al logi
[79℄. It was with Smullyan [75℄ that tableaux be
ame
well-known in the logi

ommunity. In his book he presented a system
alled \Analyti
Tableaux". The
tableaux method is a refutational pro
edure. That is, in order to prove that a formula X is valid we try to
show that it is not valid. Having this in mind, we apply a pro
edure for inferring the logi
al
onsequen
es
of the formulas present in the tableaux. If any bran
h of the generated proof tree remains open, then we
have a refutation of X .
3.1.1

The KE System

Mar
o Mondadori and Mar
ello D'Agostino presented the KE System [16℄, a refutation system that, they
argued, though \being
lose to the tableau method, is not ae
ted by the anomalies of
ut-free systems."
KE Tableaux are very similar to Analyti
Tableaux be
ause they also use signed formulas, have expansion
rules with premises and
on
lusions and have the same rules for the
onstru
tion of the initial tableau
and the
losing of the tableau.
D'Agostino proposed KE Tableaux as an improvement, in the
omputational sense, over Smullyan's
Analyti
Tableaux. He proved that a
anoni
al restri
tion of the KE System
an polynomially simulate
the tableau method but the tableau method
annot polinomially simulate the
anoni
al restri
tion of KE1 .
That is, the KE System is a `natural' proof method and it is more eÆ
ient than Smullyan's tableaux.
The set of rules for the KE System (see Figure 1) has only one rule of the bran
hing type, the PB rule,
orresponding to the prin
iple of bivalen
e. With this rule, in
onjun
tion with the usual tableau rules,
1 In

n, there is a KE-Tableau proof with size polynomial in n. But there is
n whose
orresponding proof in Analyti
Tableaux has size superpolynomial in n.

other words, for ea
h analyti
tableau proof of size

at least one proof in KE Tableau of size

4

it is not diÆ
ult to
onstru
t short refutations of the `hard examples' showed for Smullyan's tableaux in
[18℄.

Disjun
tion Rules
T A_B
FA
TB

T A_B
FB
TA

T _ 1)

(E

(E

F A_B
FA
FB

T _ 2)

(E

F _)

Conjun
tion Rules
F A^B
TA
FB

(E

F A^B
TB
FA

F ^ 1)

(E

F ^ 2)

T A^B
TA
TB

(E

T ^)

Impli
ation Rules
TA!B
TA
TB

(E

TA!B
FB
FA

T ! 1)

(E

F ! 2)

FA!B
TA
FB

(E

F !)

Negation Rules
T :A
FA

(E

F :A
TA

T :)

(E

F :)

Prin
iple of Bivalen
e
T AjF A

(PB)

Figure 1: KE tableau expansion rules

Besides that, the KE System introdu
es simple elimination rules of linear type whi
h
ombined with
PB yield a refutation system for
lassi
al logi
that is
omplete and sound. And the system
an be
restri
ted to analyti
appli
ations of PB, i.e. appli
ations whi
h do not violate the subformula property,
and remain
omplete and sound.

5

3.1.2

Nondeterminism in the KE system

In [18℄, a simple but
omplete refutation pro
edure for the KE system, the so-
alled
anoni
al pro
edure
is presented. But this pro
edure \is not, stri
tly speaking, a
ompletely deterministi
algorithm. Some
steps involve a
hoi
e and dierent strategies for making these
hoi
es will lead to dierent algorithms."
For instan
e, for some of the problems used in the tests of se
tion 5, this
hoi
e
an lead to linear or
exponential proofs of the same set of formulas. Therefore, strategies
an be more important than data
stru
tures and programming languages when one is implementing a tableau prover.
3.2

Obje
t Orientation

The obje
t-oriented (OO) development paradigm is regarded nowadays as the dominant software development paradigm. An important obje
tive of OO is reuse. Reuse of
ode as well as resuse of analysis and
design artifa
ts. In order to a
hieve this, several basi

on
epts are present in OO modeling and programming languages, su
h as inheritan
e, en
apsulation, abstra
tion and
omposition. The most widely used
modeling language, UML (Unied Modeling Language) [19℄, as well as the more popular programming
languages (su
h as C++ and Java) are based on this paradigm.
3.2.1

Design Patterns

Sin
e their appearan
e in [33℄, design patterns have be
ome one of the most important tools for OO
systems designers. Their development was motivated by the following observation: \designing obje
toriented software is hard, and designing reusable obje
t-oriented software is even harder" [33℄. Design
patterns are abstra
t des
riptions of design solutions that appear repeatedly in well-designed systems.
They make it easier to reuse su

essful ar
hite
ture and design artifa
ts. The [33℄ book has presented
23 design patterns and in the literature nowadays one
an nd many more design patterns for dierent
kinds of appli
ation, as well as other kinds of patterns, su
h as ar
hite
tural patterns [12, 72℄ and analysis
patterns [29℄.
3.3

Aspe
t Orientation

The obje
t oriented paradigm (OOP) has some limitations su
h as the s
attering and tangling of
ode
with dierent purposes. Part of these limitations
an be over
ome with the use of te
hniques of design
patterns. Aspe
t oriented programming (AOP) is an attempt to solve these and other problems identied
in the obje
t oriented paradigm. It is a te
hnique that intends to a
hieve more modularity in situations
where obje
t orientation and the use of design patterns is not enough.
The main motivation for the development of AOP was the alleged inability of OOP and other
urrent
programming paradigms to fully support the separation of
on
erns prin
iple [46℄. A

ording to AOP
proponents, AOP solves some problems of OOP by allowing an adequate representation of the so-
alled
ross
utting
on
erns [76℄. With AOP,
ode that implements
ross
utting
on
erns, i.e. that implements
spe
i
fun
tions that ae
t dierent parts of a system, and would be s
attered and tangled in an OOP
implementation,
an be lo
alized, in
reasing modularity. With this in
rease in modularity, one
an a
hieve
software that is more adaptable, maintainable and evolvable in the fa
e of
hanging requirements.
There are several expe
ted benets of using AOP [65℄:
 more readable and reusable
ode;
6

 a more natural mapping of system requirements to programming
onstru
ts;
 software that is more adaptable, maintainable and evolvable in the fa
e of
hanging requirements.

It is also assumed that there will be an improvement in the
omprehension and maintanability of
omplex
programs by lo
alizing behaviors (
on
erns) that would otherwise be s
attered and tangled [56℄.
Aspe
tJ seems to be the most promising approa
h to adding support for aspe
ts to Java. At least,
it is regarded as the most mature approa
h at the time of this writing. Aspe
tJ is a general purpose,
seamless aspe
t-oriented extension to the Java language that enables the modular implementation of a
wide range of
ross
utting
on
erns [3℄. Therefore, an Aspe
tJ program is a Java program with some
extra
onstru
ts. These language
onstru
ts in
luded allow the implementation of AOP features su
h as
point
uts, advi
e, inter-type de
larations and aspe
ts. Point
uts and advi
e dynami
ally ae
t program
ow, while inter-type de
larations stati
ally ae
t the
lass hierar
hy of a program.
The modularization unit in Aspe
tJ is
alled an aspe
t, just as a
ommon
on
ern's implementation in
OOP is
alled a
lass. In Aspe
tJ, aspe
ts are units of modular
ross
utting implementation,
omposed of
point
uts, advi
e, and ordinary Java member de
larations [46℄. Aspe
ts are dened by aspe
t de
larations,
whi
h have a form similar to that of
lass de
larations. Aspe
ts
an implement interfa
es and extend
other aspe
ts. However, aspe
ts have no
onstru
tors and
annot be instantiated. Aspe
t de
larations
may in
lude point
ut de
larations, advi
e de
larations, inter-type de
larations as well as other kinds of
de
larations permitted in
lass de
larations.
3.4

Extreme Programming

Extreme Programming (XP) is a lightweight (or agile) methodology that fo
uses on
oding as the main
task in software development [38℄. Amongst the so-
alled \twelve pra
ti
es of XP" presented in [38℄, we
are interested in the following:
1. \Simple design": The idea behind \simple design" is to keep the
ode simple. The simplest design
possible does not try to solve future problems by guessing future needs.
2. \Testing": The pra
ti
e of testing is key to XP. And the tests should be automated so that the
ode
an be modied and refa
tored safely, without the in
lusion of errors in the system.
3. \Refa
toring": The a
t of refa
toring enables developers to add features while keeping the
ode
simple. The idea is to not dupli
ate
ode nor write ugly, smelly
ode. The a
t of refa
toring
enters
on testing to validate that the
ode still fun
tions. Refa
toring is not limited to when you need to
the addition of features|refa
toring
an be done in order to make the
ode easier to understand.
3.5

Obje
tive

The main obje
tive of our resear
h is to investigate if proof strategies for tableau provers
an be well
modularized by using obje
t-oriented and aspe
t-oriented software development. Having this in mind, we
are in
rementally developing a KE Tableau Prover. Right now we have just nished our rst version: a
very simply designed KE Tableau prover for
lassi
al propositional logi
.
For our development, we are using a number of tools. Below are the ones that we regard as most
improtant:
E
lipse is an integrated development environment (IDE) that has support for Java, Aspe
tJ and JUnit.
It also enables some automation of refa
torings
7

is a set of tools for working with Java, an multiplatform, obje
toriented programming language, in E
lipse;
AJDT - Aspe
tJ Development Tools is a set of tools for programming in Aspe
tJ (an aspe
t-oriented
extension to Java) in E
lipse;
JUnit is framework for automating tests for Java programs;
JFlex is a lexi
al analyzer generator for Java written in Java. It is based on the well-known lex lexi
al
analyzer;
CUP (Java(tm) Based Constru
tor of Useful Parsers) is a system for generating LALR parsers
from simple spe
i
ations. It serves the same role as the widely used program YACC and in fa
t
oers most of the features of YACC. However, CUP is written in Java, uses spe
i
ations in
luding
embedded Java
ode, and produ
es parsers whi
h are implemented in Java [39℄.

JDT - Java Development Tools

4 Implementation details
Our implementation eorts are still in the beginning. There is mu
h more to be done. We are trying to
keep the design of the
lasses as simple as possible; we are following some guidelines for designing
exible
obje
t-oriented systems [66℄. For instan
e, we are avoiding to add unne
essary
exibility too early. This
is also advo
ated by XP, as well as in
remental development, test-driven programming (writing the tests
before writing a
lass) and refa
toring, whi
h we are also doing whenever possible. Finally, we have tried
to apply design patterns to solve some problems that have appeared in the beginning of the development.
In Figure 6 we depi
t only what is essential for our design; more information
an be found in the
sour
e
ode. A KETableau obje
t
an be instantiated using one of two
onstru
tors:
 the rst one for an unsigned formula:
KETableau(Formula f, FormulaFa
tory ff);
 the se
ond for a set of signed formulas:

publi
KETableau(SignedFormulaList sfl, SignedFormulaFa
tory sff, FormulaFa
tory ff).

A problem
an
onsist of one unsigned formula or a set of signed formulas. If it is an unsigned formula
X , then the signed formula F X is added to the KETableau. In our test
ases we
an see example
alls of
these
onstru
tors. It is important to noti
e that one or two fa
tories have to be passed to the KETableau
obje
t. These fa
tories are the result of an in
omplete2 appli
ation of the Flyweight design pattern [33℄ to
the
reation of formulas and signed formulas. With the use of this pattern, the system does not
reate two
dierent instan
es of the same formula in a tableau, even if that formula appears in dierent bran
hes.
The fa
tory obje
ts are
reated and updated during the analysis (lexing and parsing) of the problem
that gives origin to the (signed) formulas. This analysis was implemented by using two tools: JFlex [48℄
and CUP [39℄ (see subse
tion 3.5). We have written two3 grammars: one for the SAT format in [70℄ and
other for the format used in [20℄.
After
reating a KETableau obje
t, we have to
all the
lose() method in order to try to arrive
at a proof of the problem. If it does
lose the tableau, then the method isClosed() will return true.
Otherwise, it will return false.
2 In
omplete be
ause the (signed) formulas do not have an extrinsi
state.
3 A
tually four, two for JFlex and two for CUP.

8

Ea
h KETableau has one proof tree. This proof tree obje
t in
ludes a list of signed formulas (the
signed formula or formulas passed to the tableau
onstru
tor) and possibly pointers to its su

essors, but
no parent. Initially, the

left, right

and

parent

pointers are set to

null.

The

both assigned to new proof tree obje
ts if and when we apply a PB rule (when we
are used). These new proof tree obje
ts will re
eive have as

parent

left and right will be
addLeft and addRight

the proof tree that gave origin to

them.
Everytime a rule is applied, a formula is added to the list of signed formulas of the
urrent proof tree.
It is based on this that ea
h proof tree (that is in fa
t a bran
h of the tableau) is set to
losed or not.
Although nary
onne
tives are allowed (be
ause they are used in [20℄ examples), we have only binary
bran
hing rules.
A SignedFormula formula obje
t
onsists of a pointer to a FormulaSign obje
t (for
lassi
al logi
there
are only two signs:

T for true and F for false) and a pointer to a Formula.

Therefore, ea
h Formula obje
t

an give origin to 0 to 2 Signed Formula obje
ts (in the
lassi
al
ase).

KETableau
+KETableau(aFormula,aFormulaFactory)
+KETableau(aSignedFormulaList,aSignedFormulaFactory,aFormulaFactory)
+close()
+isClosed(): boolean
1

1
ProofTree

parent

left

+addSignedFormula(aSignedFormula)
+isClosed(): boolean
+addLeft(aSignedFormula): ProofTree
+addRight(aSignedFormula): ProofTree
+hasChildren(): boolean

right

*
signedFormulas
*

*

SignedFormula

0..2

1

1

FormulaSign

Formula

Figure 2: Simplied
lass diagram of the KE Tableau Prover.
9

We have four other diagrams that
an help one to understand the sour
e
ode. The
lasses for formulas
use the Composite design pattern [33℄.

Connective
+ Connective(symbol:String)
+getSymbol(): String
+toString(): String

ZeroaryConnective

UnaryConnective

BinaryConnective

This diagram shows the classes
for connectives and the constants
added to these classes by the
ClassicalConnectives aspect.

NaryConnective

aspect Classical Connectives

TRUE:
ZeroaryConnective

NOT:
UnaryConnective

AND:
BinaryConnective

AND:
NaryConnective

_symbol = "*T*"

_symbol = "-"

_symbol = "*"

_symbol = "*"

FALSE:
ZeroaryConnective

OR:
BinaryConnective

OR:
NaryConnective

_symbol = "*F*"

_symbol = "+"

_symbol = "+"

IMPLIES:
BinaryConnective
_symbol = "->"

Figure 3: Class diagram for
lassi
al propositional logi

onne
tives.

10

aFormula: NaryFormula
_connective = NaryConnective.OR
_formulas = [*(A,TRUE), -A, B]

This diagram shows
an object that
represents the
n-ary formula
+(*(A,TRUE),-A,B).

anAndFormula: BinaryFormula

aNegatedAtom: UnaryFormula

_connective = BinaryConnective.AND
_leftFormula = A
_rightFormula = TRUE

_connective = UnaryConnective.NOT
_formula = A

anAtom: AtomicFormula
atom = "B"

aSharedAtom: AtomicFormula
atom = "A"

TRUE: ZeroaryFormula
_connective = ZeroaryConnective.TRUE

Figure 4: Obje
t diagram for
lassi
al propositional logi
formulas and
onne
tives.

11

Formula
1+toString(): String 1..*
1

ZeroaryFormula

AtomicFormula

-_connective: ZeroaryConnective
+ ZeroaryFormula(connective:ZeroaryConnective)
+getConnective(): ZeroaryConnective

-atom: String
+ AtomicFormula(atom:String)

UnaryFormula

formula
0..*

-_connective: UnaryConnective
+ UnaryFormula(connective:UnaryConnective,formula:Formula)
+getConnective(): UnaryConnective
+formula(): Formula

formulas
NaryFormula
1
-_connective: NaryConnective
+_formulas: List
+ NaryFormula(connective:NaryConnective,formulas:List)
+getConnective(): NaryConnective
+formulas(): List
+toString(connective:NaryConnective,formulas:List): String

leftFormula
rightFormula
BinaryFormula
0..*
0..*
-_connective: BinaryConnective
+ BinaryFormula(connective:BinaryConnective,leftFormula:Formula,rightFormula:Formula)
+getConnective(): BinaryConnective
+leftFormula(): Formula
+rightFormula(): Formula
+toString(connective:BinaryConnective,leftFormula:Formula,rightFormula:Formula): String

This diagram shows the classes defined
for representing formulas.

Figure 5: Class diagram for
lassi
al propositional logi
formulas.

12

KETableau
+isClosed(): boolean
+ KETableau(f:Formula) rules
1
0..1
1
1

Formula
1
0..1

1

parent
ProofTree
1
+state: = {OPEN, CLOSED, SATURATED}
+addSignedFormula(f:SignedFormula)
0..1
left 0..1
1

list
1
1..*
right
1

SignedFormula 0..2
+sign:
1..*

KERule

KEAlpha1ConclusionRule

KELinearRule

KEBranchingRule

+premissesPattern: FormulaPattern

+getFirstProofTree(f:SignedFormula): ProofTree
+getSecondProofTree(f:SignedFormula): ProofTree

KEAlphaRule

KEBetaRule

+isApplicable(f:SignedFormula): boolean

+isApplicable(f1:SignedFormula,f2:SignedFormula): boolean
+getConclusion(f1:SignedFormula,f2:SignedFormula): SignedFormula

KEAlpha2ConclusionsRule

+getConclusion(f:SignedFormula): SignedFormula +getFirstConclusion(f:SignedFormula): SignedFormula
+getSecondConclusion(f:SignedFormula): SignedFormula

KEAlphaNConclusionsRule
+getConclusions(f:SignedFormula): SignedFormulaList

Figure 6: Class diagram for
lassi
al propositional logi
rules.

13

5 Test results
We have tested our implementation and an implementation of the KE method [20℄ with some instan
es
of the families of formulas presented in that work. In the tables below, KETP stands for our KE tableau
prover, while DFTP4 stands for the implementation of the KE method with heuristi
s Ki in the system
des
ribed in [20℄.
The results were obtained in a personal
omputer running Linux. It is important to noti
e that KETP
was implemented in Java and DFTP in C++. Other important aspe
t is that KETP
urrently only
supports the KE method, whilst DFTP was built using a framework for many tableau methods.
For , n and Statman formulas, KETP runs faster and, more important than that, requires less nodes
and formulas. This is due to the fa
t that DFTP
loses only on atomi
formulas, whilst our system
loses
on any kind of formula. For H , Hn , PHP and Statmann fornulas, although our system required less nodes
and formulas, DFTP was faster. For PHPn fornulas, DFTP was generally faster, but the analysis based
on the number of nodes and formulas does not show a pattern.
5.1

formulas

Instan
e
1
2
3
4
5
6
7
8
9
10
11

5.2

n

KETP
# nodes # formulas
1
9
3
17
7
31
15
57
31
107
63
205
127
399
255
785
511
1555
1023
3093
2047
6167

Time (s)
0.054000
0.080000
0.060000
0.041000
0.043000
0.119000
0.199000
0.447000
0.909000
2.001000
4.527000

DFTP
# nodes # formulas Time (s)
3
13
0.000479
13
42
0.005284
37
117
0.024991
109
338
0.115548
325
997
0.289457
973
2970
1.053867
2917
8885
4.057999
8749
26626
15.474049
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a
n/a

Time (s)
0.002000
0.007000
0.023000
0.077000
0.127000
0.280000
0.450000

DFTP
# nodes # formulas
9
26
23
72
65
207
191
608
569
1807
1703
5400
5105
16175

formulas

Instan
e
n1
n2
n3
n4
n5
n6
n7

KETP
# nodes # formulas
1
11
9
29
25
63
57
129
121
259
249
517
505
1031

4 Here
allled Dias-Finger Tableau Prover.

14

Time (s)
0.001247
0.035664
0.058102
0.152668
0.527771
2.079130
7.934750

5.3

5.4

5.5

5.6

H

formulas

KETP
Instan
e # nodes # formulas
H1
1
4
H2
3
15
H3
7
49
H4
15
197
H5
31
973

Hn

formulas

KETP
Instan
e # nodes # formulas
Hn1
1
5
Hn2
5
20
Hn3
19
81

PHP formulas

KETP
Instan
e # nodes # formulas
PHP1
1
3
PHP2
3
26
PHP3
11
116
PHP4
63
963

PHPn formulas

KETP
Instan
e # nodes # formulas
PHPn1
1
4
PHPn2
13
65
PHPn3
263
819
PHPn4
2265
8846

DFTP
Time (s) # nodes # formulas
0.000000
1
4
0.002000
3
17
0.117000
21
103
0.601000
105
677
10.811000 465
4777

Time (s)
0.000068
0.000456
0.006212
0.156424
2.895325

DFTP
Time (s) # nodes # formulas
0.000000
1
6
0.009000
5
21
0.139000
27
113

Time (s)
0.000094
0.000507
0.015503

DFTP
Time (s) # nodes # formulas
0.001000
1
6
0.013000
3
29
0.217000
61
261
3.388000 483
2219

Time (s)
0.000116
0.001226
0.121501
3.685126

DFTP
Time (s) # nodes # formulas
0.000000
3
16
0.109000
19
92
3.476000
183
812
113.016000 2147
9860

Time (s)
0.000340
0.035145
0.284629
15.200194

15

5.7

Statman formulas

Instan
e

Statman1
Statman2
Statman3
Statman4
Statman5
Statman6
5.8

KETP
# nodes # formulas
1
2
7
18
15
57
39
162
87
435
183
1236

DFTP
Time (s) # nodes # formulas
0.000000
1
5
0.001000
7
30
0.046000
31
124
0.088000 207
711
0.435000 1079
3696
1.833000 5391
19539

Time (s)
0.000092
0.001055
0.038595
0.138840
1.017628
8.911378

DFTP
# nodes # formulas
1
5
7
48
51
276
243
1211

Time (s)
0.000096
0.001506
0.045459
0.161938

Statmann formulas

Instan
e

Statmann1
Statmann2
Statmann3
Statmann4

KETP
# nodes # formulas
1
2
7
30
19
101
43
266

Time (s)
0.000000
0.003000
0.076000
0.259000

16

6 Future works
There is mu
h more to do in our eort towards the implementation of tableau provers. Here we highlight
some areas for future works.
6.1

Refa
toring

In order to a
hieve better results, we need to refa
tor the ar
hite
ture, the design and the implementation
of our system. Some points for immediate attention are:
 in the sour
e
ode, there are many targets for refa
toring a

ording to the
atalog presented in [31℄;

urrently there are two versions of the system: one for Windows and other for Linux. The dieren
es
are minor: problems with the `/' and `n' signs and with the Aspe
tJ
onguration in the Linux version
of E
lipse. I had to make a version for Linux without the aspe
t for the truth-table prover5 ;
 I had problems trying to make a Java AR
hive (JAR) le (a pa
kage
ontaining several
ompressed
.
lass les)
ontaing all
lasses of the system be
ause I am using
omputational re
e
tion in the
parsers pa
kage;
 the
lasses in the parsers pa
kage need to be rewritten in order to be
ome even more general;
 the
lass hierar
hy for KE rules is too
omplex. Maybe we
an use interfa
es instead of sub
lasses;
 the test
ases for some
lasses must be
ompleted.
After refa
toring, I plan to do some additions to our system. First we will try to lo
alize all de
isions
related to the proof strategy in a
lass or an aspe
t, probably by using the Strategy design pattern [33℄,
su
h as [20℄ has done. Strategies will ae
t many
lasses in our system, therefore they are a natural
andidate for aspe
t-orientation. For instan
e, a strategy might dene:
 the order of appli
ation of rules or, more generally, to de
ide whi
h is the next rule to be applied in
a given tableau at a spe
i
moment;
 if a bran
h of the tableau is going to be
losed when one nds T X and F X and X is any kind
of formula (this leads to shorter proofs) or only when it is an atomi
formula (this simplies the
he
king{it was done this way in [20℄);
 when to
he
k that a bran
h is
losed. In the
urrent system, it is done every time a formula is
added to the tableau. But for tableaus with many formulas this
an be
ostly. It
ould be done on
e
for ea
h three formulas added, for example, or just before the appli
ation of a PB rule;
 the data stru
tures used for the lists of signed formulas and for the proof tree.
We are going to build both a proof
he
ker and a proof viewer. The proof
he
ker will enable us to
he
k if a proof is
orre
t more rapidly and with greater a

ura
y. And the proof viewer shall enable us
to browse the proof and see how ea
h formula was added to the tableau (i.e. the rule and the premiss(es)
that led to that formula, if it is not a formula of the problem), among other things.
We will try to make the best possible use of OO features and design patterns but, at the same
time, we are going to try to refa
tor for aspe
ts [63℄, that is, to try to use aspe
t-orientation for a
5 I have built an aspe
t-oriented truth-table prover in order to test the design of formulas and
onne
tives. It uses an aspe
toriented implementation of the Interpreter pattern [33℄.

17

better modularization of strategies and the overall system. For instan
e, we are going to study the
possibility of giving an AO implementation of the Flyweight pattern, that is, to try to remove referen
es
to FormulaFa
tory and SignedFormulaFa
tory in the
ode.
6.2

Analysis Patterns

A

ording to [29℄, \many books on obje
t modeling talk about analysis and design. There is little agreement on where the boundary between these two a
tivities lies." So, what is an analysis model? In [30℄,
he answers that analysis is about understanding how the domain works and obje
t-oriented analysis is
building a des
ription of the domain that in
reases our understanding of that domain, in order to help
us build an obje
t-oriented software system. So, there is an important pla
e in software development for
analysis and analysis patterns.
Logi
has been analysed for
enturies. In the beginning of our development, when we were designing
the
lasses for representing
lassi
al propositional formulas and
onne
tives, we rst thought of
onsidering
the two
onstants (true and false) as
onstant atomi
formulas. But logi
textbooks su
h as [27℄
lassify
these
onstants as zeroary
onne
tives. Prof. Mar
elo Finger pointed out this to me and then I
hanged
my design. To my surprise, the design of other
lasses that depended upon these
onstants be
ame mu
h
more
lear.
We think we already have satisfa
tory analyzed
lassi
al propositional formulas and
onne
tives. But
we are not satised with the analysis for KE Tableau rules. And we have not yet begun to analyse proof
strategies.
6.3

Software ar
hite
ture and Component-based systems

The software ar
hite
ture of a program or
omputing system is the stru
ture or stru
tures of the system,
whi
h
omprise software elements, the externally visible properties of those elements, and the relationship
among them [4℄. In other words, it is the overall system stru
ture, des
ribing its
omponents and its
interrelationships.
A

ording to [78℄, \software
omponents are binary units of independent produ
tion, a
quisition, and
deployment that intera
t to form a fun
tioning system." Modern
omputation systems require evolving
software that is built from existing software
omponents, developed by independent sour
es [9℄. An
initial draft of the ar
hite
ture of our system is depi
ted in Figure 7 and following is a des
ription of its
omponents:
The Problem Analyser
omponent re
eives two inputs: (i) a problem des
ription grammar
(su
h as the ones des
ribed in TPTP [77℄ or in [70℄) from the Congurator
omponent and
(ii) a problem des
ription in that grammar (e.g. the ones in TPTP or SATLIB) from the User
Interfa
e
omponent. Then it outputs a problem obje
t for the Prover
omponent.
The Prover then tries to prove that problem in the logi
al system given by the Congurator
and, su

eding or not, produ
es a proof obje
t that is given to the Proof Verier. The Proof
Verier
omponent
he
ks the proof obje
t and if it is OK, passes it along to the Proof Optimizer
omponent. The Proof Optimizer tries to nd a shorter version of the proof obje
t and gives
this version to the Proof Viewer, where the proof
an be browsed by the user.
The Congurator is set a

ording to
hoi
es made by the user through the User Interfa
e.
In order to set other
omponents, the Congurator has to a

ess to the Logi
s Database and
18

Problem Analyser

Problem Object

Prover

Proof Verifier

Proof Object

Proof Object
logical system
problem description grammar
problem descrpition

User Interface

Proof Optimizer

user choices

Configurator

Proof Object

Proof Viewer

Logics Database

Problems Database

Figure 7: Ar
hite
ture of the desired ATP system.

19

the Problems Database.
In [73℄ some representative, broadly-used ar
hite
tural styles are presented. An ar
hite
tural style
denes a family of systems in terms of a pattern of stru
tural organization. Some of these ar
hite
tural
styles are presented in [12℄ as patterns for software ar
hite
ture. Our draft has points in
ommon with
two ar
hite
tural patterns (styles) presented in [12, 73℄:
 The Pipes and Filters ar
hite
tural pattern provides a stru
ture for systems that pro
ess a stream
of data. Ea
h pro
essing step is en
apsulated in a lter
omponent. Data is passed through pipes
between adja
ent lters. Re
ombining lters allow you to build families of related systems.
 The Bla
kboard ar
hite
tural pattern is useful for systems for whi
h no deterministi
solution strategies are known. In Bla
kboard several spe
ialized subsystems assemble their knowledge to build a
partial or approximate solution.
It is
lear that our draft does not follow these patterns stri
tly, but that is not the intention of a
pattern.
We known that mu
h more
an be done in this system, but our obje
tive is to keep this initial
des
ription as simple as possible. The main
on
ern of our work is to be able to dene strategies for
proofs and
ompare strategies. That is why the Congurator
omponent, where the strategies are to be
represented and input to the Prover, plays a
entral role in our draft.
6.4

Frameworks

An obje
t-oriented framework is a set of related
lasses designed for solving a spe
i
problem. Frameworks
[41, 24℄ are well-established as a te
hnology for building obje
t-oriented systems. But frameworks are not
usually designed upfront; they evolve. A rule of thumb is that you must have implemented at least three
appli
ations in a given subje
t area in order to derive a framework. In the future we may arrive at a
position where we
an dene an aspe
t-oriented framework for tableau provers.

7 Con
lusion
In this report we have given an a

ount of the
urrent state of our proje
t of implementing tableau provers
with obje
t-oriented programming, design patterns, aspe
t-oriented programming and some te
hniques
from Extreme Programming. We are still in the beginning, but we have just nished an obje
t-oriented
implementation of a KE tableau prover.
Our goal is to be able to give a satisfa
tory modularization of proof strategies for the KE system. We
believe that by using aspe
t-orientation along with obje
t-orientation and other te
hniques, this modularization will be possible.

Referen
es
[1℄ asato
(asaton
freak.
om).
Refa
toring
in
Aspe
tJ,
http://www.n
freak.
om/asato/do
/refa
toring-in-aspe
tj.html.
[2℄ Aspe
t-Oriented Software Asso
iation.
AOSD Te
hnology,
http://www.aosd.net/te
hnology/index.php.
20

September
De
ember

2003.
2003.

[3℄ Aspe
t-Oriented Software Asso
iation. aosd.net, De
ember 2003. http://www.aosd.net.
[4℄ L. Bass, P. Clements, and R. Kazman.

Software Ar
hite
ture in Pra
ti
e.

Addison-Wesley Pub Co,

Reading, MA, se
ond edition, 2003.
[5℄ Kent Be
k and Ralph Johnson. Patterns generate ar
hite
tures.

Le
ture Notes in Computer S
ien
e,

821:139{149, 1994.
[6℄ Bernhard Be
kert, Ri
hard Bubel, Elmar Habermalz, and Andreas Roth. jTAP - a Tableau Prover
in Java. Universitat Karlsruhe, February 1999.
[7℄ Bernhard Be
kert and Joa
him Posegga. leanTAP: Lean tableau-based dedu
tion.

mated Reasoning,

Journal of Auto-

15(3):339{358, 1995.

[8℄ K. Broda, M. D'Agostino, and M. Mondadori. A Solution to a Problem of Popper, 1995.
[9℄ A. Brown and K. Wallnau.

The
urrent state of CBSE.

IEEE Software,

15(5):37{46,

Septem-

ber/O
tober 1998.
[10℄ Bill Burke. JBoss Aspe
t Oriented Programming, 2003.
http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/proje
ts/jboss/aop.
[11℄ Bill

Burke

and

Adrian

Bro
k.

Aspe
t

Oriented

Programming

and

JBoss,

May

2003.

http://www.oreillynet.
om/pub/a/onjava/2003/05/28/aop jboss.html.
[12℄ F. Bus
hmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal.

Ar
hite
ture - A System of Patterns.

Pattern-Oriented Software

John-Wiley and Sons, 1996.

[13℄ Chin-Liang Chang and Ri
hard Char-Tung Lee.

Symboli
Logi
and Me
hani
al Theorem Proving.

A
ademi
Press, London, 1973.
[14℄ P.R. Cohen and E.A. Feigenbaum.

The Handbook of Arti
ial Intelligen
e 3,
hapter XII - Automati

Dedu
tion, pages 75{124. William Kaufmann In
., Los Altos, CA, 1982.
[15℄ Robert Constable and Cristoph Kreitz.

Automated Reasoning, 2002.

Slides from a presentation

available at http://www.
s.
ornell.edu/Info/People/kreitz.
[16℄ M. D'Agostino and M. Mondadori. The taming of the
ut: Classi
al refutations with analyti

ut.

Journal of Logi
and Computation,

pages 285{319, 1994.

[17℄ Mar
ello D'Agostino. Are Tableaux an Improvement on Truth-Tables? Cut-Free proofs and Bivalen
e.
Avaliable at: http://
iteseer.nj.ne
.
om/140346.html.
[18℄ Mar
ello D'Agostino. Tableau methods for
lassi
al propositional logi
. In Mar
ello D'Agostino et al.,
editor,

Handbook of Tableau Methods,

hapter 1, pages 45{123. Kluwer A
ademi
Press, 1999.

Modelagem orientada a objetos
om a UML. Futura, 2003.
Implementa
~oes de Tableaux para Ra
io
nio por Aproxima
o~es. Master's

[19℄ Jos
e Eduardo Zindel Deboni.
[20℄ Wagner Dias.

thesis,

Departamento de Ci^
en
ia da Computa
~
ao, Instituto de Matem
ati
a e Estat
sti
a, Universidade de
S~
ao Paulo, 2002.
[21℄ Tzilla Elrad, Robert E. Filman, and Atef Bader.

of the ACM, 44,

Aspe
t-Oriented Programming.

Communi
ations

2001.

[22℄ U. Endriss. A KE based theorem proving assistant, 1996. Master's thesis, Department of Computing,
Imperial College, London, 1996.

21

[23℄ Luis Fari~nas del Cerro, David Fauthoux, Olivier Gasquet, Andreas Herzig, Dominique Longin, and
Fabio Massa

i. Lotre
: the generi
tableau prover for modal and des
ription logi
s. In International
Joint Conferen
e on Automated Reasoning, LNCS, page 6. Springer Verlag, 18-23 juin 2001.
[24℄ Mohamed Fayad and Douglas S
hmidt. Obje
t-Oriented Appli
ation Frameworks.
of the ACM, 40(10):32{38, O
tober 1997.

Communi
ations

[25℄ R. Filman and D. Friedman.
Aspe
t-oriented programming is quanti
ation and obliviousness. In Workshop on Advan
ed Separation of Con
erns (OOPSLA), 2000. http://i
www.ar
.nasa.gov/i
/darwin/oif/leo/lman/text/oif/aop-is.pdf.
[26℄ Robert E. Filman. What is Aspe
t-Oriented Programming, Revisited. In

Workshop on Advan
ed

Separation of Con
erns, 15th European Conferen
e on Obje
t-Oriented Programming,

[27℄ Melvin Fitting.
1996.

First-Order Logi
and Automated Theorem Proving.

Springer-Verlag, se
ond edition,

[28℄ Melvin Fitting. Introdu
tion. In Mar
ello D'Agostino et al., editor,
hapter 1, pages 1{43. Kluwer A
ademi
Press, 1999.
[29℄ Martin Fowler. Analysis Patterns: Reusable
Wesley, Reading, Massa
husetts, 1997.

Obje
t Models.

June 2001.

Handbook of Tableau Methods,

Obje
t Te
hnology Series. Addison-

[30℄ Martin Fowler. Is There Su
h a Thing as Obje
t-Oriented Analysis?
41, O
tober 1999.

Distributed Computing,

[31℄ Martin Fowler.

Adisson-Wesley Longman, 1999.

Refa
toring: Improving the Design of Existing Code.

[32℄ Martin Fowler. Who Needs an Ar
hite
t?

IEEE Software,

(10):40{

(1):2{4, August 2003.

[33℄ Eri
h Gamma, Ri
hard Helm, Ralph Johnson, and John Vlissides.
Reusable Obje
t-Oriented Software. Adisson-Wesley, 1994.

Design Patterns: Elements of

[34℄ Joseph D. Grade
ki and Ni
holas Lesie
ki. Mastering Aspe
tJ: Aspe
t-Oriented Programming in Java.
John Wiley & Sons, 2003.
[35℄ William Grosso. Aspe
t-Oriented Programming and Aspe
tJ.

Dr.Dobbs Journal,

August 2002.

[36℄ Jan Hahnemann and Gregor Ki
zales. Design Pattern Implementation in Java and Aspe
tJ. In Pro
eedings of the 17th Annual ACM
onferen
e on Obje
t-Oriented Programming, Systems, Languages,
ans Appli
ations (OOPSLA),

pages 161{173, November 2002. http://www.
s.ub
.
a/~jan/AOPDS/.

[37℄ R. Hahnle. Tableaux and related methods. In A. Robinson and A. Voronkov, editors,
Automated Reasoning, volume I,
hapter 3, pages 100{178. Elsevier S
ien
e, 2001.
[38℄ Ri
hard Hightower and Ni
holas Lesie
ki.

Handbook of

Java Tools for eXtreme Programming - Mastering Open

Sour
e Tools in
luding Ant, JUnit and Ca
tus.

Wiley, 2002.

[39℄ S
ott Hudson, Frank Flannery, C. S
ott Ananian, Dan Wang, and Andrew W. Appel. CUP User's
Manual, 1999.
[40℄ Obje
t Te
hnology International In
. E
lipse Platform Te
hni
al Overview, February 2003.
[41℄ Ralph E. Johnson. Components, frameworks, patterns.
Reusability, 1997.
22

ACM SIGSOFT Symposium on Software

[42℄ Ralph E. Johnson and Brian Foote. Designing reusable
lasses. Journal of Obje
t-Oriented Programming, 1(2):22{35, June/July 1988.
[43℄ Louis H. Kaufmann. The Robbins Problem:
omputer proofs and human proofs. Kybernetes - The
International Journal of Systems and Cyberneti
s, 30, 2001.
[44℄ Gregor Ki
zales. Interview with Gregor Ki
zales, July 2003.
http://www.theserverside.
om/events/videos/GregorKi
zalesText/interview.jsp.
[45℄ Gregor Ki
zales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jerey Palm, and William G. Griswold.
Getting Started with Aspe
tJ. Communi
ations of the ACM, 44:59{65, 2001.
[46℄ Gregor Ki
zales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jerey Palm, and William G. Griswold.
An overview of Aspe
tJ. Le
ture Notes in Computer S
ien
e, 2072:327{355, 2001.
[47℄ Gregor Ki
zales, John Lamping, Anurag Menhdhekar, Chris Maeda, Cristina Lopes, Jean-Mar
Loingtier, and John Irwin. Aspe
t-oriented programming. In Mehmet Aksit and Satoshi Matsuoka,
editors, Pro
eedings European Conferen
e on Obje
t-Oriented Programming, volume 1241, pages 220{
242. Springer-Verlag, Berlin, Heidelberg, and New York, 1997.
[48℄ Gerwin Klein. JFlex User's Manual, 2001. Available at http://www.j
ex.de.
[49℄ Mi
hael Kohlhase and Carolyn Tal
ott. Database of existing me
hanized reasoning systems, 2003.
Available at http://www-formal.stanford.edu/
lt/ARS/systems.html.
[50℄ Ramnivas Laddad. I want my AOP!, Part 1. Java World, January 2002.
[51℄ Ramnivas Laddad. I want my AOP!, Part 2. Java World, Mar
h 2002.
[52℄ Ramnivas Laddad. I want my AOP!, Part 3. Java World, April 2002.
[53℄ Ramnivas Laddad. Aspe
tJ in A
tion. Manning, 2003.
[54℄ Ken Wing Kuen Lee. An Introdu
tion to Aspe
t-Oriented Programming, August 2002. Reading
Assignment. COMP 610E 2002 Spring Software Development of E-Business Appli
ations. The Hong
Kong University of S
ien
e and T
ehnology.
[55℄ Ni
holas Lesie
ki. Test
exibly with Aspe
tJ and mo
k obje
ts. IBM's Developer Works, May 2002.
[56℄ Karl Liebebrherr, David H. Lorenz, and Johan Ovlinger. aspe
tual Collaborations: Combining
Modules and Aspe
ts. The Computer Journal, 542{565, 2003.
[57℄ Katharina Mehner and Awais Rashid.
GEMA: A Generi
Model for AOP.
In Belgian and Dut
h Workshop on AOP, Twente, The Netherlands,
2003.
http://www.
omp.lan
s.a
.uk/
omputing/oop/Publi
ations.php.
[58℄ Katharina Mehner and Awais Rashid.
Towards a Generi
Model for AOP (GEMA).
Te
hni
al Report CSEG/1/03, Computing Department, Lan
aster University, 2003.
http://www.
omp.lan
s.a
.uk/
omputing/oop/Publi
ations.php.
[59℄ Tzilla Elrad (Moderator), Mehmet Aksit, Gregor Ki
zales, Karl Liebherr, and Harold Ossher. Dis
ussing Aspe
ts of AOP. Communi
ations of the ACM, 44:33{38, O
tober 2001.
[60℄ Gail C. Murphy, Robert J. Walker, Elisa L. A. Baniassad, Martin P. Robillard, Albert Lai, and Mik A.
Kersten. Does Aspe
t-Oriented Programming Work? Communi
ations of the ACM, 44:75{77, 2001.
[61℄ Nils J. Nilsson. Arti
ial Intelligen
e: A New Synthesis. Morgan Kaufmann, San Fran
is
o, 1998.
23

[62℄ William F. Opdyke. Refa
toring Obje
t-Oriented Frameworks. PhD thesis