Adolfo Gustavo Serra Sea Neto
Deember 11, 2003
Abstrat
TheimplementationofAutomated TheoremProvers (ATP's)hasbeena researh themeinComputer
Siene fora long time. ATP's have many appliationsand some important resultswere obtained with
them. But the implementation of tableau based theorem provers has to be better developed, beause
tableauprovers areusuallyonsideredto be lesseÆientthanResolution-based provers. The KEsystem
[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 veryusefulforstudyingpropertiesof logialdedution,speiallyifwe angive agoodmodularization
ofproofstrategies. Objet-orientation, aspet-orientationandother relatedtehniquesanhelpusbetter
modularize proof strategies. That is the the main objetive of our researh: to ahieve a better
modu-larization of strategies in tableau provers. Having this in mind, we are inrementally developing a KE
Tableau Prover. We have just nishedourrst version, an objet-oriented KEtableau prover, whihwe
willpresenthere.
1 Introdution
The implementation of Automated Theorem Provers (ATP's) has been a researh theme in Computer
Siene fora long time. ATP's have many appliationsand some important resultswere obtained with
them. But there isstillmuh to bedonein thisarea. Forinstane, theimplementationoftableau based
theorem provers has to be better developed, beause tableau provers are usually onsidered to be less
eÆient thanResolution-basedprovers. The Tableau method is aformal proof proedure thathas many
variantsandexistsforseverallogis[28 ℄. OneofthesevariantsistheKEsystem[16℄,whihwaspresented
asanimprovement,intheomputationalsense,overtraditionalSmullyan'sAnalytiTableaux[75 ℄. That
is,theKESystem is a`natural'proofmethod and itis moreeÆient thanSmullyan'stableaux.
Tableau-basedtheoremproversanbeveryusefulforstudyingpropertiesoflogialdedution,speially
ifweangive agood modularizationof proofstrategies. Objet-orientation, aspet-orientationandother
related tehniquesan helpus better modularize proof strategies. That is thethe mainobjetive of our
researh: to ahieve abetter modularizationof strategies intableauprovers. Havingthisinmind,we are
inrementallydevelopingaKETableau Prover. Wehavejustnishedourrstversion,anobjet-oriented
In setion 2we willpresent automated theorem provers (ATP's) and automated reasoning (AR). ATP's
appliations, results and some other issues related to ATP's and AR willbe briey disussed. Then, in
setion3wewilldesribeourprojet: aninvestigationintotheonstrution ofTableaubasedAutomated
Theorem Provers using objet-orientation, design patterns, aspet-orientation, and some extreme
pro-grammingtehniques. After that, insetion 4we willdesribewithsome diagramsand textsoururrent
implementation.
Testresultsomparingtheperformaneofoursystemwithanexistingsystemarepresentedinsetion5.
Then some future works will be disussed in setion 6: refatoring (both objet-oriented and
aspet-oriented), the writing of analysis patterns for ATP's, of a omponent-based arhiteture for Tableau
Provers and thedevelopment ofa framework. Insetion 7 we shallpresent ouronludingremarks.
2 Automated Theorem Provers and Automated Reasoning
The implementation of Automated Theorem Provers (ATP's) has been a researh theme in Computer
Sienefora longtime. The historyofthiselddatesbakto the1950s. Readbelowanexerptof [14 ℄:
Automatidedution,ormehanial-theoremproving,hasbeenamajoronernofAIsine
its earliest days. At the rst formal onferene on AI, held at Dartmouth College in the
summerof1956,NewellandSimon(1956)disussedtheLogiTheorist,adedutionsystemfor
propositionallogi. Misnkywasonurrentlydevelopingtheideasthatwerelaterembodiedin
Gelernter's theoremproverforelementarygeometry(see MCorduk,1979, p. 106; Gelernter,
1963). Shortly after this, Wang (1960) produed the rst implementation of a reasonably
eÆient,ompletealgorithm forprovingtheoremsinpropositionallogi.
ATP's have manyappliations,among whih we highlight thefollowing[15℄:
proofof mathematialtheorems
{ proof veriation: to detet and to orreterrors inproofs
{ theorem proving: to ndnew proofsautomatially
{ helpingthe teahing ofmathematis
suuportfordesigningreliablesoftware
{ veriation: to nderrorsorprove orretion
{ optimization: to inreaseperformane
{ synthesis: to generateode from speiations
inferene engineforArtiialIntelligentsystems
{ generalproblemsolvers
{ robot planning
{ intelligentagents
In [69 ℄, one an nd that \the rst published results from researh on automated dedution using
eletroniomputerswere thoseofNewell,Shaw, andSimon(1957) ontheLogi Theorist. Thisprogram
earlier. BothDavis's1954 programandtheLogi Theoristwerebasedonsomewhatadhomethodsthat
didnotstronglyinuenelater automated dedution.
(:::)
Another useof theorem provers is asan assistant,providingadvie to, say, a mathematiian. Inthis
mode themathematiian ats asasupervisor,mappingoutthestrategyfordeterminingwhat to donext
and asking the theorem prover to llin the details. This alleviates the problemof semi-deidabilityto
some extent, baause the supervisor an anel a query and try anotherapproah if the query is taking
toomuhtime. Atheorem proveran also atasa proof-heker, wheretheproofis givenbyahuman
asaseriesoffairlylargesteps;theindividualinferenesrequiredtoshowthateahstepissoundarelled
inbythe system."
Some theorem provers have even ome up with new mathematial results, suhas thesettling of the
RobbinsproblembytheATPSystem EQP in1996. TheRobbinsproblem remainedopenfor63 years.
The eldof Automated theorem-proving(ATP) isalso known as:
Automated dedution [69 ℄
Automati dedution[14 ℄
Mehanial theorem-proving [13 ,14 ℄
Automated reasoning[82 ℄.
Andtheorem provers [69 ℄ arealso known as
Automated reasoners[69 ℄
Theorem-provingsystems [61 ℄.
However, inmyopinion the use of the word reasoningis deliate. Reasoning is an ativity that an
onlybe performed by human beings. In its beginnings, theeld of AI had too muh expetations. For
instane, aording to [69 ℄ (page 17), in a workshop at Dartmouth in 1956, Allen Newell and Herbert
Simon, two researhers from Carnegie Teh, presented a reasoning program, the Logi Theorist (LT),
aboutwhihSimonlaimed,\Wehaveinventedaomputerprogramapableofthinkingnon-numerially,
and thereby solved the venerable mind-bodyproblem." This was learly an exaggeration, althoughthis
programlaterwasableto prove mostofthetheoremsinChapter2 ofRussellandWhitehead'sPrinipia
Mathematia.
Butthedenitionofreasoningintheareaofautomatedreasoningismuhmoremodest. Forexample,
[82 ℄ writesthefollowing:
Reasoning is theproess of drawingonlusionsfrom fats. Forthe reasoningto be sound,
these onlusions mustfollow inevitablyfrom thefats fromwhihthey aredrawn. (:::)
The objet of automated reasoning is to write omputer programs that assist in solving
problemsandinansweringquestionsrequiringreasoning. Theassistaneprovidedbyan
auto-mated reasoningprogram is available intwo dierent modes. You an use suh a program in
an interative fashion,that is,you an instrut itto draw some onlusions and present them
to you, and then itwill ask you forfurther instrutions. Or you an use suh a programin a
bathmode,thatis,you an assign itan entirereasoning taskand await thenal result.
The implementation of ATP's has been disussed in several books suh as [82 ℄ and [27 ℄. Nowadays
an be found in[49℄. Competitionsare held amongst these systems [77℄ that use databases of problems
suh as[77 ,71 ℄.
The Journal of Automated Reasoning is the prinipal journal for theorem proving. And the major
onferene in this eld is the annual International Conferene on Automated Dedution (CADE), as
informedby[69 ℄.
3 Projet
In our work we are investigating the onstrution of Tableaux-based Automated Theorem Provers. We
aregoing to use objet-orientation, design patterns, aspet-orientation, and some extreme programming
tehniques. Below we shall explaineah of these items. The result willbe a tableau prover forlassial
propositionallogi. ItwillbeimplementedinJava andAspetJand duringitsdevelopment we intendto
use,wheneverwefeel itis adequate, designpatterns andsome extremeprogrammingtehniques.
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 inobjet-oriented
programminglanguages.
3.1 Tableaux
The Tableaux method is a formal proof proedure that has many variants and exists for several logis
[28 ℄. Tableaumethodshavebeenfoundto beaonvenientformalismforautomatingdedutioninvarious
non-standard logis as well as in lassial logi [79 ℄. It was with Smullyan [75 ℄ that tableaux beame
well-known inthe logiommunity. In his book he presenteda system alled\Analyti Tableaux". The
tableauxmethodisarefutationalproedure. Thatis,inordertoprovethataformulaX isvalidwetryto
showthatitisnotvalid. Havingthisinmind,weapplyaproedureforinferringthelogialonsequenes
oftheformulas present inthetableaux. If any branh ofthe generatedproof tree remainsopen,thenwe
have a refutationof X.
3.1.1 The KE System
MaroMondadoriand MarelloD'AgostinopresentedtheKESystem[16 ℄,a refutationsystemthat,they
argued,though\beingloseto thetableaumethod,isnotaetedbytheanomaliesofut-free systems."
KETableauxareverysimilartoAnalytiTableauxbeausetheyalsousesignedformulas,haveexpansion
rules with premises and onlusions and have the same rules for the onstrution of the initial tableau
andthe losingof thetableau.
D'Agostino proposed KE Tableaux as an improvement, in the omputational sense, over Smullyan's
Analyti Tableaux. He proved that a anonial restrition of the KE System an polynomiallysimulate
thetableaumethodbutthetableaumethodannotpolinomiallysimulatetheanonialrestritionofKE 1
.
Thatis, theKESystem isa `natural' proofmethod and itismore eÆient thanSmullyan'stableaux.
ThesetofrulesfortheKESystem(seeFigure1)hasonlyone ruleofthebranhingtype,thePBrule,
orresponding to the priniple of bivalene. With this rule, inonjuntion withthe usual tableau rules,
1
Inotherwords,foreahanalytitableauproofofsizen,thereisaKE-Tableauproofwithsizepolynomialin n. Butthereis
[18 ℄.
Figure 1: KE tableauexpansion rules
Besides that, the KESystem introdues simple elimination rulesof linear type whihombined with
PB yield a refutation system for lassial logi that is omplete and sound. And the system an be
restritedto analyti appliationsof PB, i.e. appliationswhih do not violatethe subformulaproperty,
In[18 ℄, a simplebut ompleterefutationproedure fortheKE system, the so-alledanonial proedure
is presented. But this proedure \is not, stritly speaking, a ompletely deterministi algorithm. Some
stepsinvolve a hoie and dierent strategies for making these hoieswilllead to dierent algorithms."
For instane, for some of the problems used in the tests of setion 5, this hoie an lead to linear or
exponential proofsof the same set of formulas. Therefore, strategies an be more important than data
struturesand programminglanguages when oneis implementinga tableauprover.
3.2 Objet Orientation
The objet-oriented (OO) development paradigm isregarded nowadays as thedominant software
devel-opment paradigm. AnimportantobjetiveofOOisreuse. Reuseofodeaswellasresuseofanalysisand
designartifats. Inorderto ahievethis,several basioneptsarepresentinOOmodelingand
program-minglanguages,suh asinheritane,enapsulation, abstration and omposition. The mostwidely used
modeling language, UML (Unied Modeling Language) [19 ℄, as well as the more popular programming
languages(suh asC++and Java) arebased on thisparadigm.
3.2.1 Design Patterns
Sine their appearane in [33 ℄, design patterns have beome one of the most important tools for OO
systems designers. Their development was motivated by the following observation: \designing
objet-oriented software is hard, and designing reusable objet-oriented software is even harder" [33 ℄. Design
patterns are abstrat desriptions of design solutions that appear repeatedly in well-designed systems.
They make it easier to reuse suessful arhiteture and design artifats. The [33℄ book has presented
23 design patterns and in the literaturenowadays one an nd many more designpatterns for dierent
kindsofappliation,aswellasotherkindsofpatterns,suhasarhiteturalpatterns[12 ,72 ℄andanalysis
patterns[29℄.
3.3 Aspet Orientation
The objet oriented paradigm (OOP) has some limitations suh as the sattering and tangling of ode
with dierent purposes. Part of these limitations an be overome with the use of tehniques of design
patterns. Aspetorientedprogramming(AOP) isanattempttosolvetheseandotherproblemsidentied
inthe objet orientedparadigm. It isa tehniquethat intends to ahieve more modularityin situations
whereobjetorientationandthe useof designpatternsis notenough.
The mainmotivationforthedevelopmentof AOP wastheallegedinabilityofOOPand otherurrent
programming paradigms to fully support the separation of onerns priniple [46 ℄. Aording to AOP
proponents, AOP solvessome problems of OOPbyallowing an adequate representation of the so-alled
rossutting onerns [76 ℄. With AOP,ode that implementsrossutting onerns,i.e. thatimplements
spei funtions thataet dierent partsof a system, and wouldbe sattered and tangled inan OOP
implementation,anbeloalized,inreasingmodularity. Withthisinreaseinmodularity,oneanahieve
software thatis more adaptable,maintainableand evolvable inthefaeof hangingrequirements.
Thereare several expeted benetsof usingAOP [65 ℄:
softwarethat ismore adaptable,maintainable and evolvableinthe faeofhangingrequirements.
Itisalso assumedthatthere willbeanimprovementintheomprehensionandmaintanabilityofomplex
programsbyloalizingbehaviors (onerns)that would otherwisebe sattered and tangled[56 ℄.
AspetJ seems to be the most promising approah to adding support for aspets to Java. At least,
it is regarded as the most mature approah at the time of this writing. AspetJ is a general purpose,
seamless aspet-oriented extension to the Java language that enables the modular implementation of a
wide range of rossutting onerns [3 ℄. Therefore, an AspetJ program is a Java program with some
extraonstruts. Theselanguage onstrutsinluded allow theimplementationof AOPfeatures suh as
pointuts, advie,inter-type delarations and aspets. Pointuts and advie dynamiallyaet program
ow, whileinter-typedelarationsstatially aet thelass hierarhyof aprogram.
ThemodularizationunitinAspetJisalledanaspet, justasaommononern'simplementationin
OOPisalledalass. InAspetJ,aspetsareunitsofmodularrossuttingimplementation,omposedof
pointuts,advie,andordinaryJavamemberdelarations[46 ℄. Aspetsaredenedbyaspetdelarations,
whih have a form similar to that of lass delarations. Aspets an implement interfaes and extend
other aspets. However, aspets have no onstrutors and annot be instantiated. Aspet delarations
may inlude pointut delarations, advie delarations, inter-type delarations as well as other kinds of
delarationspermitted inlassdelarations.
3.4 Extreme Programming
ExtremeProgramming (XP) is a lightweight (or agile) methodology that fouseson oding as themain
taskin software development [38 ℄. Amongst the so-alled\twelve praties of XP"presented in[38 ℄, we
areinterested inthefollowing:
1. \Simpledesign": The idea behind \simple design"is to keeptheode simple. The simplestdesign
possibledoesnottry to solve futureproblems byguessing future needs.
2. \Testing": Thepratieoftestingiskeyto XP.Andthetestsshouldbeautomatedsothattheode
an be modiedand refatored safely,withouttheinlusionof errorsin thesystem.
3. \Refatoring": The at of refatoring enables developers to add features while keeping the ode
simple. Theideaisto notdupliateode norwriteugly,smellyode. The atofrefatoringenters
on testing to validate that theode still funtions. Refatoring is not limited to when you needto
theaddition of features|refatoringan be doneinorder to makethe ode easier to understand.
3.5 Objetive
The main objetive of our researh is to investigate if proof strategies for tableau provers an be well
modularizedbyusingobjet-orientedandaspet-orientedsoftwaredevelopment. Havingthisinmind,we
areinrementally developing a KE Tableau Prover. Right now we have just nished ourrst version: a
very simplydesignedKE Tableau proverfor lassialpropositionallogi.
For our development, we are using a number of tools. Below are the ones that we regard as most
improtant:
Elipse isan integrated developmentenvironment(IDE) thathassupportforJava,AspetJ and JUnit.
oriented programminglanguage, inElipse;
AJDT - AspetJ Development Tools isasetoftoolsforprogramminginAspetJ(anaspet-oriented
extension to Java) inElipse;
JUnit isframework forautomatingtestsforJava programs;
JFlex is alexial analyzergenerator for Java writteninJava. It is based on thewell-knownlex lexial
analyzer;
CUP (Java(tm) Based Construtor of Useful Parsers) is a system for generating LALR parsers
from simple speiations. It serves the same role as the widely used program YACC and in fat
oers mostof thefeaturesof YACC.However, CUPis writteninJava,uses speiationsinluding
embedded Java ode,and produes parsers whih areimplementedinJava [39 ℄.
4 Implementation details
Our implementationeorts arestill inthe beginning. There ismuh more to be done. We aretrying to
keepthedesignofthelassesassimpleaspossible;wearefollowingsome guidelinesfordesigningexible
objet-oriented systems [66 ℄. Forinstane, we are avoiding to add unneessary exibilitytoo early. This
isalso advoated byXP,aswellasinrementaldevelopment,test-driven programming(writingthetests
before writingalass) and refatoring,whihwe arealso doingwheneverpossible. Finally,we have tried
toapplydesignpatternsto solve someproblemsthathaveappearedinthebeginningofthedevelopment.
In Figure 6 we depit only what is essential for our design; more information an be found in the
soureode. A KETableau objetan be instantiatedusingone oftwoonstrutors:
therst one foran unsignedformula:
KETableau(Formula f, FormulaFatory ff);
theseond fora setof signedformulas:
publi KETableau(SignedFormulaList sfl, SignedFormulaFatory sff, FormulaFatory ff).
Aprobleman onsistofoneunsignedformulaorasetofsignedformulas. Ifitisanunsignedformula
X,then thesignedformulaFX isaddedto theKETableau. Inourtest ases we an seeexamplealls of
theseonstrutors. Itisimportanttonotiethatoneortwofatorieshavetobepassedto theKETableau
objet. Thesefatoriesaretheresultofaninomplete 2
appliationoftheFlyweightdesignpattern[33 ℄to
thereationofformulasandsignedformulas. Withtheuseofthispattern,thesystemdoesnotreatetwo
dierentinstanesof thesame formulaina tableau, even ifthatformulaappears indierent branhes.
The fatory objets are reatedand updated duringtheanalysis (lexingand parsing) of the problem
thatgives originto the(signed) formulas. This analysis wasimplementedby usingtwo tools: JFlex[48 ℄
andCUP [39℄(see subsetion3.5). We have writtentwo 3
grammars: one forthe SATformatin[70 ℄ and
otherforthe formatusedin[20 ℄.
After reating a KETableau objet, 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,itwillreturnfalse.
2
Inompletebeausethe(signed) formulasdonothaveanextrinsistate.
3
signedformulaorformulaspassedto thetableauonstrutor) and possiblypointers to itssuessors,but
no parent. Initially,the left, right and parentpointers areset to null. The leftand rightwill be
bothassignedtonewprooftreeobjetsifandwhenweapplyaPBrule(whenweaddLeftandaddRight
are used). These new proof tree objets will reeive have as parent the proof tree that gave origin to
them.
Everytime aruleisapplied,a formulaisaddedtothelistofsignedformulas oftheurrentprooftree.
Itis basedon thisthateah prooftree (that isinfata branhof thetableau) isset to losedornot.
Althoughnary onnetives areallowed (beause they areused in[20 ℄ examples),we have onlybinary
branhing rules.
ASignedFormulaformulaobjetonsistsofapointertoaFormulaSignobjet(forlassiallogithere
areonlytwosigns: TfortrueandFforfalse)andapointertoaFormula. Therefore,eahFormulaobjet
an giveorigin to 0to 2 SignedFormulaobjets (inthe lassialase).
KETableau
+KETableau(aFormula,aFormulaFactory)
+KETableau(aSignedFormulaList,aSignedFormulaFactory,aFormulaFactory)
+close()
+isClosed(): boolean
1
1
ProofTree
+addSignedFormula(aSignedFormula)
+isClosed(): boolean
+addLeft(aSignedFormula): ProofTree
+addRight(aSignedFormula): ProofTree
+hasChildren(): boolean
left
right
parent
SignedFormula
signedFormulas
*
*
FormulaSign
Formula
1
*
0..2
1
usetheCompositedesignpattern[33 ℄.
Connective
+<<constructor>> Connective(symbol:String)
+getSymbol(): String
+toString(): String
ZeroaryConnective
UnaryConnective
BinaryConnective
NaryConnective
TRUE:
ZeroaryConnective
_symbol = "*T*"
FALSE:
ZeroaryConnective
_symbol = "*F*"
NOT:
UnaryConnective
_symbol = "-"
AND:
BinaryConnective
_symbol = "*"
IMPLIES:
BinaryConnective
_symbol = "->"
OR:
BinaryConnective
_symbol = "+"
AND:
NaryConnective
_symbol = "*"
OR:
NaryConnective
_symbol = "+"
aspect Classical Connectives
This diagram shows the classes
for connectives and the constants
added to these classes by the
ClassicalConnectives aspect.
TRUE: ZeroaryFormula
_connective = ZeroaryConnective.TRUE
aSharedAtom: AtomicFormula
atom = "A"
aNegatedAtom: UnaryFormula
_connective = UnaryConnective.NOT
_formula = A
anAndFormula: BinaryFormula
_connective = BinaryConnective.AND
_leftFormula = A
_rightFormula = TRUE
aFormula: NaryFormula
_connective = NaryConnective.OR
_formulas = [*(A,TRUE), -A, B]
anAtom: AtomicFormula
atom = "B"
This diagram shows
an object that
represents the
n-ary formula
+(*(A,TRUE),-A,B).
Formula
This diagram shows the classes defined
for representing formulas.
formulas
1
1..*
KERule
+state: = {OPEN, CLOSED, SATURATED}
+addSignedFormula(f:SignedFormula)
We have tested ourimplementation and an implementationof the KE method [20 ℄ withsome instanes
ofthefamiliesofformulas presentedinthatwork. In thetablesbelow, KETPstandsforourKEtableau
prover, whileDFTP 4
stands forthe implementationof theKE method with heuristisK
i
inthe system
desribedin[20 ℄.
TheresultswereobtainedinapersonalomputerrunningLinux. ItisimportanttonotiethatKETP
was implemented in Java and DFTP in C++. Other important aspet is that KETP urrently only
supports theKEmethod,whilst DFTPwasbuiltusingaframework formanytableau methods.
For ,
n
andStatmanformulas,KETPrunsfasterand,moreimportantthanthat, requireslessnodes
andformulas. Thisisdueto thefatthatDFTPloses onlyonatomiformulas,whilstoursystemloses
onanykindofformula. ForH,H
n
,PHPandStatman
n
fornulas,althoughoursystemrequiredlessnodes
and formulas,DFTP was faster. ForPHP
n
fornulas, DFTP was generally faster, butthe analysis based
onthe numberof nodesand formulas doesnotshow apattern.
5.1 formulas
KETP DFTP
Instane #nodes # formulas Time(s) #nodes #formulas Time (s)
1
1 9 0.054000 3 13 0.000479
2
3 17 0.080000 13 42 0.005284
3
7 31 0.060000 37 117 0.024991
4
15 57 0.041000 109 338 0.115548
5
31 107 0.043000 325 997 0.289457
6
63 205 0.119000 973 2970 1.053867
7
127 399 0.199000 2917 8885 4.057999
8
255 785 0.447000 8749 26626 15.474049
9
511 1555 0.909000 n/a n/a n/a
10
1023 3093 2.001000 n/a n/a n/a
11
2047 6167 4.527000 n/a n/a n/a
5.2
n
formulas
KETP DFTP
Instane #nodes #formulas Time(s) #nodes #formulas Time (s)
n
1 1 11 0.002000 9 26 0.001247
n
2 9 29 0.007000 23 72 0.035664
n
3 25 63 0.023000 65 207 0.058102
n
4 57 129 0.077000 191 608 0.152668
n
5 121 259 0.127000 569 1807 0.527771
n
6 249 517 0.280000 1703 5400 2.079130
n
7 505 1031 0.450000 5105 16175 7.934750
4
KETP DFTP
Instane #nodes # formulas Time(s) # nodes #formulas Time (s)
H
1
1 4 0.000000 1 4 0.000068
H
2
3 15 0.002000 3 17 0.000456
H
3
7 49 0.117000 21 103 0.006212
H
4
15 197 0.601000 105 677 0.156424
H
5
31 973 10.811000 465 4777 2.895325
5.4 H
n
formulas
KETP DFTP
Instane #nodes #formulas Time(s) #nodes #formulas Time (s)
H
n1
1 5 0.000000 1 6 0.000094
H
n2
5 20 0.009000 5 21 0.000507
H
n3
19 81 0.139000 27 113 0.015503
5.5 PHP formulas
KETP DFTP
Instane #nodes #formulas Time(s) #nodes #formulas Time (s)
PHP
1
1 3 0.001000 1 6 0.000116
PHP
2
3 26 0.013000 3 29 0.001226
PHP
3
11 116 0.217000 61 261 0.121501
PHP
4
63 963 3.388000 483 2219 3.685126
5.6 PHP
n
formulas
KETP DFTP
Instane #nodes #formulas Time(s) # nodes #formulas Time (s)
PHP
n1
1 4 0.000000 3 16 0.000340
PHP
n2
13 65 0.109000 19 92 0.035145
PHP
n3
263 819 3.476000 183 812 0.284629
PHP
n4
KETP DFTP
Instane #nodes #formulas Time (s) #nodes #formulas Time (s)
Statman
1
1 2 0.000000 1 5 0.000092
Statman
2
7 18 0.001000 7 30 0.001055
Statman
3
15 57 0.046000 31 124 0.038595
Statman
4
39 162 0.088000 207 711 0.138840
Statman
5
87 435 0.435000 1079 3696 1.017628
Statman
6
183 1236 1.833000 5391 19539 8.911378
5.8 Statman
n
formulas
KETP DFTP
Instane #nodes #formulas Time (s) #nodes #formulas Time (s)
Statman
n1
1 2 0.000000 1 5 0.000096
Statman
n2
7 30 0.003000 7 48 0.001506
Statman
n3
19 101 0.076000 51 276 0.045459
Statman
n4
Thereismuhmore to doinoureorttowardstheimplementationoftableauprovers. Here we highlight
some areas forfutureworks.
6.1 Refatoring
Inorder toahievebetterresults,weneedtorefatorthearhiteture,thedesignandtheimplementation
ofoursystem. Some pointsforimmediateattentionare:
inthesoureode,thereare manytargetsforrefatoringaordingto theatalogpresentedin[31 ℄;
urrentlytherearetwoversionsofthesystem: oneforWindowsandotherforLinux. Thedierenes
areminor: problemswiththe`/'and`n'signsandwiththeAspetJongurationintheLinuxversion
of Elipse. Ihad to make aversionforLinuxwithouttheaspetforthe truth-tableprover 5
;
Ihad problemstrying tomake aJava ARhive(JAR) le(a pakage ontainingseveral ompressed
.lass les) ontaing all lasses of the system beause I am using omputational reetion in the
parsers pakage;
thelasses intheparserspakage needto be rewritteninorder to beome even more general;
thelass hierarhyforKE rulesistoo omplex. Maybe we an useinterfaesinstead ofsublasses;
thetest ases for some lassesmustbeompleted.
After refatoring, Iplanto do some additionsto oursystem. Firstwe willtry to loalizeall deisions
related to theproofstrategy ina lass oran aspet, probablybyusingtheStrategy designpattern [33 ℄,
suh as [20 ℄ has done. Strategies will aet many lasses in our system, therefore they are a natural
andidateforaspet-orientation. Forinstane,a strategymight dene:
theorder ofappliation ofrulesor, more generally,to deidewhihis thenextruleto beappliedin
a given tableauat aspeimoment;
if a branh of the tableau is going to be losed when one nds TX and FX and X is any kind
of formula (this leads to shorter proofs) or only when it is an atomi formula (this simplies the
heking{itwasdonethiswayin[20℄);
when to hek that a branh is losed. In the urrent system, it is done every time a formula is
addedtothetableau. Butfortableauswithmanyformulasthisanbeostly. Itouldbedoneone
foreah three formulasadded, forexample, orjustbeforethe appliationof aPB rule;
thedata struturesused forthelistsofsignedformulas and fortheproof tree.
We are going to build botha proof heker and a proof viewer. The proof heker will enable usto
hek ifa proofis orret more rapidly and withgreater auray. Andthe proof viewershall enableus
tobrowsetheproofandsee howeahformulawasaddedto thetableau(i.e.theruleand thepremiss(es)
thatledto thatformula,if itisnota formulaof theproblem),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 refator for aspets [63 ℄, that is, to try to use aspet-orientation for a
5
Ihavebuiltanaspet-orientedtruth-table proverinorder totestthedesignofformulasandonnetives. Itusesan
possibilityofgiving an AO implementationof theFlyweightpattern, that is,to try to remove referenes
to FormulaFatoryand SignedFormulaFatoryintheode.
6.2 Analysis Patterns
Aordingto [29 ℄, \manybookson objetmodelingtalkaboutanalysisand design. There islittle
agree-ment on wherethe boundarybetween these two ativities lies." So, what is an analysis model? In [30 ℄,
he answers that analysis is about understanding how the domain works and objet-oriented analysis is
buildinga desriptionof the domain that inreases our understanding of that domain, in order to help
usbuildanobjet-orientedsoftware system. So,there isan important plae insoftware development for
analysisand analysis patterns.
Logi has been analysedforenturies. In thebeginning of ourdevelopment, when we weredesigning
thelassesforrepresentinglassialpropositionalformulasandonnetives,werstthoughtofonsidering
thetwo onstants (true and false) asonstant atomi formulas. But logitextbooks suh as[27℄ lassify
these onstantsas zeroary onnetives. Prof. Marelo Finger pointedoutthisto me and then Ihanged
mydesign. To mysurprise,thedesignof otherlassesthatdependeduponthese onstantsbeame muh
more lear.
We thinkwe alreadyhave satisfatoryanalyzed lassialpropositional formulas and onnetives. But
we arenotsatisedwiththeanalysis forKETableaurules. Andwe have notyetbegunto analyseproof
strategies.
6.3 Software arhiteture and Component-based systems
Thesoftwarearhiteture ofaprogram oromputingsystemis thestrutureorstrutures ofthesystem,
whihomprisesoftwareelements, theexternallyvisiblepropertiesofthoseelements,and therelationship
among them [4 ℄. In other words, it is the overall system struture, desribing its omponents and its
interrelationships.
Aording to[78 ℄, \softwareomponentsarebinaryunitsofindependentprodution, aquisition,and
deployment that interat to form a funtioning system." Modern omputation systems require evolving
software that is built from existing software omponents, developed by independent soures [9 ℄. An
initialdraft of the arhitetureof our systemis depited inFigure 7 and following isa desription ofits
omponents:
The Problem Analyseromponent reeivestwo inputs: (i) a problemdesription grammar
(suh as the ones desribed in TPTP [77 ℄ or in [70 ℄) from the Congurator omponent and
(ii) aproblemdesriptioninthatgrammar(e.g.theonesinTPTPorSATLIB)fromtheUser
Interfaeomponent. Thenit outputsa problemobjet fortheProver omponent.
TheProverthentriestoprovethatprobleminthelogialsystemgivenbytheCongurator
and, sueding ornot, produes a proof objetthat is given to the Proof Verier. The Proof
VerieromponenthekstheproofobjetandifitisOK,passesitalongtotheProofOptimizer
omponent. The Proof Optimizertries to nda shorter version of the proof objet and gives
thisversion to theProof Viewer,wheretheproofan bebrowsedbythe user.
The Congurator is set aording to hoies made by theuser throughtheUser Interfae.
Problem Analyser
Prover
Proof Verifier
Configurator
Proof Optimizer
Proof Viewer
Logics Database
Problem Object
Proof Object
Proof Object
Proof Object
logical system
problem description grammar
User Interface
user choices
Problems Database
problem descrpition
In [73 ℄ some representative, broadly-used arhitetural styles are presented. An arhitetural style
denes a family of systems in terms of a pattern of strutural organization. Some of these arhitetural
styles are presented in [12 ℄ as patterns forsoftware arhiteture. Our draft has points in ommon with
two arhitetural patterns(styles) presentedin[12 , 73 ℄:
The Pipes and Filters arhitetural pattern provides a struture forsystems that proess a stream
of data. Eah proessing step is enapsulated in a lter omponent. Data is passedthrough pipes
between adjaent lters. Reombiningltersallow you to buildfamiliesof relatedsystems.
TheBlakboardarhiteturalpatternisusefulforsystemsforwhihnodeterministisolution
strate-gies are known. In Blakboard several speialized subsystems assemble their knowledge to build a
partialorapproximatesolution.
It is lear that our draft does not follow these patterns stritly, but that is not the intention of a
pattern.
We known that muh more an be done in this system, but our objetive is to keep this initial
desription as simple as possible. The main onern of our work is to be able to dene strategies for
proofsand ompare strategies. That is why theCongurator omponent, where thestrategies areto be
represented andinputto theProver, plays aentralrole inour draft.
6.4 Frameworks
Anobjet-orientedframeworkisasetofrelatedlassesdesignedforsolvingaspeiproblem. Frameworks
[41 ,24 ℄arewell-establishedasatehnology forbuildingobjet-orientedsystems. Butframeworksarenot
usuallydesignedupfront;theyevolve. A ruleof thumb isthatyoumust haveimplementedat leastthree
appliations in a given subjet area in order to derive a framework. In the future we may arrive at a
positionwherewean dene anaspet-orientedframework fortableauprovers.
7 Conlusion
Inthisreportwehavegivenanaount oftheurrentstateofourprojetofimplementingtableauprovers
with objet-oriented programming, design patterns, aspet-oriented programming and some tehniques
from ExtremeProgramming. We arestill inthe beginning,butwe have just nishedan objet-oriented
implementationof a KEtableauprover.
Our goalisto beableto givea satisfatorymodularizationofproofstrategies fortheKE system. We
believe that byusing aspet-orientation along with objet-orientation and other tehniques, this
modu-larizationwillbe possible.
Referenes
[1℄ asato (asatonfreak.om). Refatoring in AspetJ, September 2003.
http://www.nfreak.om/asato/do/refatoring-in-aspetj.html.
[2℄ Aspet-Oriented Software Assoiation. AOSD Tehnology, Deember 2003.
[4℄ L.Bass, P. Clements, and R. Kazman. Software Arhiteture in Pratie. Addison-Wesley PubCo,
Reading,MA,seond edition,2003.
[5℄ Kent BekandRalphJohnson. Patternsgeneratearhitetures. LetureNotesin ComputerSiene,
821:139{149, 1994.
[6℄ Bernhard Bekert, RihardBubel, Elmar Habermalz, and Andreas Roth. jTAP - a Tableau Prover
inJava. UniversitatKarlsruhe,February 1999.
[7℄ Bernhard Bekert and JoahimPosegga. leanTAP:Leantableau-based dedution. Journal of
Auto-mated Reasoning,15(3):339{358, 1995.
[8℄ K. Broda, M. D'Agostino,and M. Mondadori. A Solutionto a Problem of Popper, 1995.
[9℄ A. Brown and K. Wallnau. The urrent state of CBSE. IEEE Software, 15(5):37{46,
Septem-ber/Otober 1998.
[10℄ BillBurke. JBossAspetOrientedProgramming,2003.
http://www.jboss.org/index.html?module=html&op=userdisplay&id=developers/projets/jboss/aop.
[11℄ Bill Burke and Adrian Brok. Aspet Oriented Programming and JBoss, May 2003.
http://www.oreillynet.om/pub/a/onjava/2003/05/28/ ao p jboss.html.
[12℄ F. Bushmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software
Arhiteture - A System of Patterns. John-Wiley and Sons,1996.
[13℄ Chin-LiangChang and Rihard Char-Tung Lee. Symboli Logi and Mehanial Theorem Proving.
Aademi Press, London,1973.
[14℄ P.R.CohenandE.A.Feigenbaum.TheHandbookof ArtiialIntelligene3,hapterXII-Automati
Dedution,pages 75{124. WilliamKaufmann In.,Los Altos,CA, 1982.
[15℄ Robert Constable and Cristoph Kreitz. Automated Reasoning, 2002. Slides from a presentation
availableat http://www.s.ornell.edu/Info/People/kreitz.
[16℄ M. D'Agostino and M. Mondadori. The taming of the ut: Classial refutations with analyti ut.
Journal of Logi and Computation, pages 285{319, 1994.
[17℄ MarelloD'Agostino.AreTableauxanImprovementonTruth-Tables? Cut-FreeproofsandBivalene.
Avaliableat: http://iteseer.nj.ne.om/140346.html.
[18℄ MarelloD'Agostino.Tableaumethodsforlassialpropositionallogi. InMarelloD'Agostinoetal.,
editor, Handbook of Tableau Methods, hapter 1, pages45{123. KluwerAademi Press, 1999.
[19℄ Jose EduardoZindelDeboni. Modelagem orientada a objetosom a UML. Futura,2003.
[20℄ Wagner Dias. Implementa~oes de Tableaux para Raionio por Aproxima~oes. Master's thesis,
Departamento de Ci^enia da Computa~ao, Instituto de Matematia e Estatstia, Universidadede
S~ao Paulo,2002.
[21℄ Tzilla Elrad, Robert E. Filman, and Atef Bader. Aspet-Oriented Programming. Communiations
of the ACM,44, 2001.
[22℄ U.Endriss. AKEbasedtheoremprovingassistant,1996. Master'sthesis,DepartmentofComputing,
FabioMassai. Lotre: thegeneritableauproverformodalanddesriptionlogis.InInternational
JointConferene on Automated Reasoning,LNCS,page 6.SpringerVerlag, 18-23 juin2001.
[24℄ Mohamed Fayad andDouglas Shmidt. Objet-OrientedAppliationFrameworks. Communiations
of the ACM,40(10):32{38, Otober1997.
[25℄ R. Filman and D. Friedman. Aspet-oriented programming is quantiation and
oblivi-ousness. In Workshop on Advaned Separation of Conerns (OOPSLA), 2000.
http://i-www.ar.nasa.gov/i/darwin/oif/leo/lman/text/oif/aop-is.pdf.
[26℄ Robert E. Filman. What is Aspet-Oriented Programming, Revisited. In Workshop on Advaned
Separation of Conerns, 15th European Confereneon Objet-Oriented Programming, June2001.
[27℄ MelvinFitting. First-OrderLogi andAutomated Theorem Proving. Springer-Verlag,seondedition,
1996.
[28℄ Melvin Fitting. Introdution. In Marello D'Agostino et al., editor, Handbook of Tableau Methods,
hapter 1,pages1{43. KluwerAademi Press,1999.
[29℄ Martin Fowler. Analysis Patterns: Reusable Objet Models. Objet Tehnology Series.
Addison-Wesley,Reading, Massahusetts, 1997.
[30℄ MartinFowler.IsThereSuhaThingasObjet-OrientedAnalysis? Distributed Computing,(10):40{
41,Otober1999.
[31℄ MartinFowler.Refatoring: ImprovingtheDesignofExistingCode. Adisson-WesleyLongman,1999.
[32℄ MartinFowler. WhoNeeds an Arhitet? IEEE Software,(1):2{4, August 2003.
[33℄ Erih Gamma, Rihard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of
ReusableObjet-Oriented Software. Adisson-Wesley,1994.
[34℄ JosephD.GradekiandNiholasLesieki.MasteringAspetJ:Aspet-OrientedProgramminginJava.
JohnWiley&Sons, 2003.
[35℄ WilliamGrosso. Aspet-OrientedProgrammingand AspetJ. Dr.Dobbs Journal,August 2002.
[36℄ JanHahnemannandGregor Kizales. DesignPatternImplementationinJava andAspetJ. In
eedingsof the 17th AnnualACMonfereneon Objet-OrientedProgramming, Systems,Languages,
ansAppliations(OOPSLA),pages161{173,November2002. http://www.s.ub.a/~jan/AOPDS/.
[37℄ R. Hahnle. Tableaux and related methods. In A. Robinson and A. Voronkov, editors, Handbook of
Automated Reasoning,volume I, hapter 3, pages100{178. ElsevierSiene, 2001.
[38℄ Rihard Hightower and NiholasLesieki. Java Tools for eXtreme Programming - Mastering Open
SoureTools inluding Ant,JUnit andCatus. Wiley,2002.
[39℄ Sott Hudson, Frank Flannery, C. Sott Ananian, Dan Wang, and Andrew W. Appel. CUP User's
Manual, 1999.
[40℄ ObjetTehnology International In. ElipsePlatformTehnial Overview,February2003.
[41℄ Ralph E. Johnson. Components, frameworks, patterns. ACM SIGSOFT Symposium on Software
ming,1(2):22{35, June/July1988.
[43℄ LouisH. Kaufmann. The RobbinsProblem: omputer proofs and human proofs. Kybernetes - The
International Journal of Systemsand Cybernetis,30, 2001.
[44℄ Gregor Kizales. Interview withGregor Kizales,July2003.
http://www.theserverside.om/events/videos/GregorKizalesText/interview.jsp.
[45℄ Gregor Kizales,ErikHilsdale, JimHugunin,Mik Kersten, JereyPalm,and William G. Griswold.
GettingStartedwith AspetJ. Communiations of the ACM,44:59{65, 2001.
[46℄ Gregor Kizales,ErikHilsdale, JimHugunin,Mik Kersten, JereyPalm,and William G. Griswold.
An overview of AspetJ. LetureNotes in Computer Siene,2072:327{355, 2001.
[47℄ Gregor Kizales,John Lamping,AnuragMenhdhekar, ChrisMaeda, CristinaLopes, Jean-Mar
Lo-ingtier, and John Irwin. Aspet-oriented programming. In Mehmet Aksit and Satoshi Matsuoka,
editors,ProeedingsEuropean Confereneon Objet-OrientedProgramming,volume1241,pages220{
242.Springer-Verlag, Berlin,Heidelberg,and New York,1997.
[48℄ GerwinKlein. JFlexUser's Manual, 2001. Availableat http://www.jex.de.
[49℄ Mihael Kohlhase and Carolyn Talott. Database of existing mehanized reasoning systems, 2003.
Availableat http://www-formal.stanford.edu/lt/ARS/systems.html.
[50℄ RamnivasLaddad. Iwant myAOP!, Part 1. JavaWorld, January 2002.
[51℄ RamnivasLaddad. Iwant myAOP!, Part 2. JavaWorld, Marh 2002.
[52℄ RamnivasLaddad. Iwant myAOP!, Part 3. JavaWorld, April2002.
[53℄ RamnivasLaddad. AspetJin Ation. Manning,2003.
[54℄ Ken Wing Kuen Lee. An Introdution to Aspet-Oriented Programming, August 2002. Reading
Assignment.COMP610E2002 SpringSoftware Development ofE-BusinessAppliations.TheHong
Kong Universityof Sieneand Tehnology.
[55℄ NiholasLesieki. TestexiblywithAspetJand mokobjets. IBM's Developer Works, May2002.
[56℄ Karl Liebebrherr, David H. Lorenz, and Johan Ovlinger. aspetual Collaborations: Combining
Modulesand Aspets. TheComputer Journal,542{565, 2003.
[57℄ Katharina Mehner and Awais Rashid. GEMA: A Generi Model for AOP.
In Belgian and Duth Workshop on AOP, Twente, The Netherlands, 2003.
http://www.omp.lans.a.uk/omputing/oop/Publiations.php.
[58℄ Katharina Mehner and Awais Rashid. Towards a Generi Model for AOP (GEMA).
Tehnial Report CSEG/1/03, Computing Department, Lanaster University, 2003.
http://www.omp.lans.a.uk/omputing/oop/Publiations.php.
[59℄ Tzilla Elrad(Moderator), Mehmet Aksit, Gregor Kizales, Karl Liebherr, and Harold Ossher.
Dis-ussingAspets ofAOP. Communiations of the ACM, 44:33{38,Otober 2001.
[60℄ GailC.Murphy,RobertJ.Walker,ElisaL.A.Baniassad,MartinP.Robillard,AlbertLai,andMikA.
Kersten. DoesAspet-OrientedProgrammingWork? Communiations of the ACM,44:75{77,2001.
USA, 1992.
[63℄ CarlosPerez.RefatoringtoAspets,May2003.http://www.artima.om/weblogs/viewpost.jsp?thread=4842.
[64℄ Eduardo Kessler Piveta and Luiz Carlos Zananella. Observer Pattern using Aspet-Oriented
Pro-gramming. InThird Latin Amerian Conferene on Pattern Languagesof Programming, 2003.
[65℄ Awais Rashid and Lynne Blair. Editorial: Aspet-oriented Programming and Separation of
Cross-uttingConerns. TheComputer Journal, 46(5):527{528, 2003.
[66℄ CharlesRihter. Designing Flexible Objet-Oriented Systems with UML. Mamillan Tehnial
Pub-lishing,1999.
[67℄ DonRoberts andRalphJohnson. EvolvingFrameworks. ????,12(1):23{41, January1965. Avaliable
at http://st-www.s.uiu.edu/users/droberts/evolve.html.
[68℄ J. A. Robinson. A mahine-oriented logi based on the resolution priniple. JACM, 12(1):23{41,
January 1965. Reprintedin[74 ℄.
[69℄ Start Russel and Peter Norvig. Artiial Intelligene: A Modern Approah. Prentie Hall, 1995.
Preis: 70,-DM.
[70℄ Satisabilitysuggestedformat, 1993. Avaliableat http://www.satlib.org.
[71℄ Satisabilitylibrary,2003. http://www.satlib.org.
[72℄ D.Shmidt,M.Stal,H.Rohnert,andF.Bushmann.Pattern-OrientedSoftwareArhiteture,volume
2: Patterns forConurrentand Networked Objets. John-Wiley &Sons, 2000.
[73℄ M. Shaw and D. Garlan. Software Arhiteture: Perspetive on an Emerging Disipline. Prentie
Hall,1996.
[74℄ Jorg Siekmann and Graham Wrightson, editors. Automation of Reasoning: Classial Papers in
Computational Logi 1957{1966, volume1. Springer-Verlag,1983.
[75℄ Raymond M. Smullyan. First-Order Logi. Springer-Verlag,1968.
[76℄ SergioSoares and PauloBorba. AspetJ - Programa~ao orientadaa aspetos em Java. Tutorial no
SBLP 2002, 6o.Simposio Brasileiro de Linguagens dePrograma~ao.5 a 7 deJunho, PUC-Rio, Rio
de Janeiro, Brasil, pages39{55, 2002.
[77℄ Geo Sutlie and Christian Suttner. The CADE ATP System Competition, 2003. Available at
http://www.s.miami.edu/ tptp/CASC.
[78℄ C.Szyperski. Component Software: Beyond Objet-Oriented Programming. Addison-Wesley,Seond
edition,2003.
[79℄ Tableaux onferene, 2003. http://i12www.ira.uka.de/TABLEAUX/.
[80℄ AspetJ Team. The AspetJ Programming Guide, Deember 2003.
http://dev.elipse.org/viewvs/indexteh.gi/hekout /aspetj-home/do/progguide/index.html.
[81℄ Andrei Voronkov. Algorithms, Datastutures, and Other Issues in EÆient Automated Dedution.
In International Joint Conferene on Automated Reasoning, LNCS, pages 13{28. Springer-Verlag,
Appliations. Prentie-Hall,1984.
[83℄ Mihael J. Yuan and Norman Rihards. Lightweight Aspet-Oriented Programming - Puuting the
