Detecting Patterns and Antipatterns in Software using Prolog Rules

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

2. 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 Design Patterns and Antipatterns

3. 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 “Talking in patterns”

4. 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] State of the Art and Objectives • 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

5. 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

6. Example: Observer pattern definition in [Go4]

7. 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=[_|_].

8. 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”

9. 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,_,_,_)),!.

10. Detection results for patterns

11. Detection results for antipatterns

12. 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.