Hide and Seek: A Look into Antipatterns and Antipattern Detection

1. Matt Young Hide and Seek: A Look into Antipatterns and Antipattern Detection

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: • Performance • Maintainability • 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 types • Contains most of the logic of the system • Contains most of the data referenced by other objects • Increases class to class interactions, reducing performance

6. God Class Example • System contains two classes: • Controller • Valve • Controller methods: • openValve() • closeValve() • Valve methods • getStatus() • 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 valve • Controller.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 • Row Limit • Reduces processing on early pages but original issue remains for the last pages • Upper/Lower Bounds • Only applicable on unique bounding fields

10. Sisyphus Antipattern Solutions • Sequence Numbers • Set needed for every sort method • 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 • Manual • Requires vast knowledge of identified antipatterns • Logic based • Rule based detection • Model driven • Identification based on software models

13. Prolog Rules (God Class) • JTransform converts Java code to a Prolog fact base • Contains all class data and dependencies • 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) • Determine if flagged classes interact with data classes • If all criteria is met, a god class is likely present

15. Model Driven

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?