Presentation is loading. Please wait.

Presentation is loading. Please wait.

CONTI Automatic Detection of Missing Abstract Factory Design Pattern in Object-Oriented Code as. eng. Călin-Viorel Jebelean.

Similar presentations


Presentation on theme: "CONTI Automatic Detection of Missing Abstract Factory Design Pattern in Object-Oriented Code as. eng. Călin-Viorel Jebelean."— Presentation transcript:

1 CONTI 2004calin@cs.utt.ro Automatic Detection of Missing Abstract Factory Design Pattern in Object-Oriented Code as. eng. Călin-Viorel Jebelean

2 CONTI 2004calin@cs.utt.ro Design Patterns Design pattern = a general solution to a frequently occurring design problem that guarantees better flexibility, extendibility and maintainability of object- oriented code 23 such design problems have been identified and documented [GoF] A good design often contains many design pattern instances A bad design surely needs some design pattern instances

3 CONTI 2004calin@cs.utt.ro Goals of the Paper To propose a methodology for identifying places within object-oriented code where a design pattern should have been used, but wasn’t To simply indicate suspect entities, without correcting the underlying problem Chosen design pattern = Abstract Factory Chosen programming language = Java

4 CONTI 2004calin@cs.utt.ro Abstract Factory AntiPattern (1) Symptoms: Clients depend on a fixed family of products Hard to introduce a new family No restriction to use products from different families

5 CONTI 2004calin@cs.utt.ro Abstract Factory AntiPattern (2) Client code (how it looks): … if * product family 1 is chosen then … new ProductA1(…); … new ProductB1(…); … else if * product family 2 is chosen then … new ProductA2(…); … new ProductB2(…); … end if Client code (how it should look): … Factory factory = new Factory2(…); … factory.createProductA(…); // will create a ProductA2 … factory.createProductB(…); // will create a ProductB2 …

6 CONTI 2004calin@cs.utt.ro The Approach ICP of a method = Instantiations along one Control Path of a method An ICP for a method is a set of classes (no duplicates are allowed) instantiated along one of the control paths of that method A method would typically contain many control paths, and also many ICPs We should compute the ICPs for every method in the target project Then, the conceptual algorithm would be …

7 CONTI 2004calin@cs.utt.ro Conceptual Algorithm Let ICP 1 and ICP 2 be two different ICPs of the system Then, ICP 1 belongs to some method m 1 of class C 1 and ICP 2 belongs to some method m 2 of class C 2 If: ICP 1 contains 2 classes CA 1 (ProductA1) and CB 1 (ProductB1) ICP 2 contains 2 classes CA 2 (ProductA2) and CB 2 (ProductB2) CA 1 and CA 2 are brothers CB 1 and CB 2 are brothers Then: (C 1, m 1 ) is a suspect and so is (C 2, m 2 )

8 CONTI 2004calin@cs.utt.ro The Approach – Quick View Suspects Metamodel (Prolog KB) OO code (Java) automatic manual

9 CONTI 2004calin@cs.utt.ro From Sources to Metamodel class C extends SC { public void m(int x, int y) { new X(); if (x > y) { if (x > 0) new Y(); else { new Z(); } else if (y > x) { new W(); } % Prolog metamodel – tool generated class(‘C’). extends(‘C’, ‘SC’). method(‘m’, ‘C’). instantiates(‘m’, ‘C’, [‘X’, ‘Y’]). instantiates(‘m’, ‘C’, [‘X’, ‘Z’]). instantiates(‘m’, ‘C’, [‘X’, ‘W’]). instantiates(‘m’, ‘C’, [‘X’]).

10 CONTI 2004calin@cs.utt.ro From Metamodel to Suspects suspect(C1, M1, CA1, CB1, C2, M2, CA2, CB2) :- instantiates(M1, C1, ICP1), member(CA1, ICP1), member(CB1, ICP1), not(brothers(CA1, CB1)), brothers(CA1, CA2), brothers(CB1, CB2), not(member(CA2, ICP1)), not(member(CB2, ICP1)), instantiates(M2, C2, ICP2), member(CA2, ICP2), member(CB2, ICP2).

11 CONTI 2004calin@cs.utt.ro Practical Results We ran the tools on 4 medium-size projects, one of them containing a “planted” Abstract Factory anti- pattern Metamodel generation and suspect identification were successful in under 2 seconds each The largest project successfully analyzed had 35 Kloc The metamodel generator ran out of memory on the JDK 1.4.2 sources

12 CONTI 2004calin@cs.utt.ro Conclusions & Future Work Conclusions Abstract Factory identification is feasible on large projects if smarter algorithms are used to compute ICPs Metamodel generation is exponential in the number of conditionals, yet, in practical situations, this complexity does rarely show up Future work Improve ICP computation by disregarding classes that do not extend other classes Improve ICP computation by factoring out classes that are instantiated on all or more control paths Imagine detection strategies for other design patterns


Download ppt "CONTI Automatic Detection of Missing Abstract Factory Design Pattern in Object-Oriented Code as. eng. Călin-Viorel Jebelean."

Similar presentations


Ads by Google