1

HIDE AND SEEK: A LOOK INTO ANTIPATTERNS AND

ANTIPATTERN DETECTION

Matt Young

2

Patterns

Reusable solution to a problem

Demonstrates good design practices

Can speed up development

3

Antipatterns

Similar to patterns

Detail poor solutions to problems

Can have adverse effects on:PerformanceMaintainability

Offers solutions to correct issues

4

Origins of Antipatterns

Upgrading legacy systems

Time/Budget constraints

Limited knowledge of good practices

Laziness (As long as it works!)

5

The God Class Class having the majority of the

responsibility

Two typesContains most of the logic of the systemContains most of the data referenced by other

objects

Increases class to class interactions, reducing performance

6

God Class Example

System contains two classes:ControllerValve

Controller methods:openValve()closeValve()

Valve methodsgetStatus()Open()Close()

7

God Class Example Controller.openValve()

{ if(Valve.getStatus() == true)

Valve.open();}

Eliminate Controller as a god class:Valve.open() should check its own status and to

determine to open the valveController.openValve() will simply call Valve.open()Message traffic reduced by half

8

Sisyphus Database Retrieval Antipattern Retrieval of database records displayed

in paged format

Full record set returned for each page request

Discarding unneeded records repeatedly causes performance concerns

9

Sisyphus Antipattern Solutions

1. Row LimitReduces processing on early pages but

original issue remains for the last pages

2. Upper/Lower Bounds Only applicable on unique bounding fields

10

Sisyphus Antipattern Solutions

3. Sequence Numbers Set needed for every sort method

4. Caching Additional hardware resources

11

Solutions Presented to eCal Developers believed the performance

issues were minimal

Agreed that with large datasets, issues may arise

Implemented sequence number solution for large lists

12

Detection Methods

ManualRequires vast knowledge of identified

antipatterns

Logic basedRule based detection

Model drivenIdentification based on software models

13

Prolog Rules (God Class)

1. JTransform converts Java code to a Prolog fact base

Contains all class data and dependencies

2. Prolog queries designed to find key attributes

Calculate average number of data members Flag classes exceeding average as candidates Flag classes whose method calls exceed

member_average*factor

14

Prolog Rules (God Class)

3. Determine if flagged classes interact with data classes

4. If all criteria is met, a god class is likely present

Model Driven

15

16

Antipattern Modeling Language (APML) Serves as generic representation of

antipatterns

Software Modeling Language (SML) – contains minimal modeling components describing the antipattern system

SML+ - An extension of SML which includes the performance parameters

Refactoring Modeling Language (RML) – contains the changes that need

performed to solve the antipattern

17

Antipattern Modeling Language (APML) Mapped to standardized language like

UML

18

Antipattern Modeling Language (APML) Object Constraint Language (OCL)

expressions created from AP and system models

OCL expressions compared to determine presence of antipattern

19

Future Work

Continued solving of known antipatterns

Prolog rules method verification

APML framework

20

Questions?