Detecting Patterns and Antipatterns in Software using Prolog Rules Alecsandar Stoianov, Ioana Sora Department of Computers Politehnica University of Timisoara, Romania

Design Patterns and Antipatterns Design pattern: “describes a commonly-recurring structure of communicating components that solves a general design problem within a particular contex” AntiPatterns: “like their design pattern counterparts, describe common mistakes occuring in software projects “ Catalogues of patterns and antipatterns: [Go4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software [POSA] Frank Buschmann et al.: Pattern Oriented Software Architecture [Brown] William J. Brown, Raphael C. Malveau, Hays W. McCormick III, Thomas J. Mowbray: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis [Fowler] M. Fowler, Refactoring: Improving the Design of Existing Code. [Lanza&Marinescu] Michele Lanza, Radu Marinescu: Object-Oriented Metrics in Practice

“Talking in patterns” Example: “The system has a clear client-server structure, but the MySpecialProcesser server is spaghetti-code” Benefits: Patterns and AntiPatterns define a higher-level vocabulary : it simplifies communication between software practitioners enables concise description of abstract concepts. Knowing about the presence of Patterns or AntiPatterns helps program comprehension Problem: lack of documentation in many cases the usage of patterns is seldom documented, while antipatterns are never described as such in the product documentation. Solution: automatic or semiautomatic tools for discovering both Patterns and AntiPatterns from source code can help program comprehension

State of the Art and Objectives State of the art: Different tools address specific issues – usually each tools is based on one catalog Different approaches – most do static analysis, few dynamic analysis, some metric-based Tool examples: Pinot – design pattern detection => [Go4] pattern catalogue Decor – detection of code and design smells => [Brown] IPlasma – detection of design flaws => [Lanza&Marinescu] Our objectives: tool for program comprehension – “one tool for all” easy definition of both patterns and antipatterns possibility to define patterns and antipatterns by both structural connections among classes and also by specific sequences of actions and interactions of the objects

Our approach Prerequisites: The program to be analysed must be available as Java sourcecode) we use Jtransformer to obtain a complete AST representation in form of Prolog clauses Our analysis tool: based on Prolog predicates that define queries for patterns and antipatterns queries are able to include both structural and behavioural conditions

Example: Observer pattern definition in [Go4]

Example: Our Observer pattern detection observerPattern(Project, SubjectN, ObserverN, ConcrSubjsN, ConcrObserversN, UpdateMsN, AttDetMeths,NotifyMeth):- observer(Observer,ObserverN,Project), subject(Subject,SubjectN,Observer,AttDetMeths, NotifyMeth,UpdateMsN), findall(X,concreteSubject(_,X,Subject), ConcrSubjsN), findall(Y,concreteObserver(_,Y,Observer), ConcrObserversN). observer(Observer,ObserverN,Project):- myProject(Observer,Project,ObserverN), interfaceT(Observer), classDefT(Observer,_,_,UpdateMs), member(UpdateM,UpdateMs), methodDefT(UpdateM,_,_,_,_,_,_). subject(Subject,SubjectN,Observer, AttDetMeths,NotifyMeths,UpdateMeths):- classDefT(Subject,_,SubjectN,Fields), attachDetachMeths(Fields,Subject, Observer,AttDetMeths), findall(X,notifyMeth(_,X, Subject,Observer,_),NotifyMeths), NotifyMeths=[_|_], findall(Y,notifyMeth(_,_, Subject,Observer,Y),UpdateMeths), UpdateMeths=[_|_].

Example: Blob antipattern definition in [Brown] “The Blob is found in designs where one class monopolizes the processing, and other classes primarily encapsulate data. This AntiPattern is characterized by a class diagram composed of a single complex controller class surrounded by simple data classes”

Example: Our Blob antipattern detection godClass(Project,GO):- myProject(Cls,Project,GO), cycloClass(Cls,V), V>55, callToDataClass(Cls), classDefT(Cls,_,GO,Fields), length(Fields,Nr), Nr>=25. callToDataClass(GO):- methodDefT(Meth,GO,_,_,_,_,_), getFieldT(_,_,Meth,_,_,Field), not(fieldDefT(Field,GO,_,_,_)),!. callToDataClass(GO):- methodDefT(Meth,GO,_,_,_,_,_), callT(_,_,Meth,_,_,_,Field), setMethod(Field), not(fieldDefT(Field,GO,_,_,_)),!. callToDataClass(GO):- methodDefT(Meth,GO,_,_,_,_,_), callT(_,_,Meth,_,_,_,Field), getMethod(Field), not(fieldDefT(Field,GO,_,_,_)),!.

Detection results for patterns JHotDraw 6.0b.1 Java AWT 1.3 Java Swing 1.4 Java io Java net Apache Ant OPOPOPOPOPOP Observer Singleton Strategy Adapter Decorator

Detection results for antipatterns JHotDraw 6.0b.1 Java AWT 1.3 Java Swing 1.4 Java io Java net Apache Ant OD/iPO O O O O DataClass 10iP CallSuper Blob 13D/iP Refused Interface 25iP Yoyo Poltergeist

Conclusion In this article we propose detection methods for a set of patterns and antipatterns, using a logic-based approach. The main advantage of this approach is the simplicity of defining Prolog predicates able to describe both structural and behavioural aspects of patterns and antipatters. This advantage becomes more visible in the case of patterns and antipatterns that are characterised not only by structural aspects, but also by complex behavioural aspects that are difficult or not possible to describe by code metrics.