1. Matt Young 1

2. Patterns  Reusable solution to a problem  Demonstrates good design practices  Can speed up development 2

3. Antipatterns  Similar to patterns  Detail poor solutions to problems  Can have adverse effects on: Performance Maintainability  Offers solutions to correct issues 3

4. Origins of Antipatterns  Upgrading legacy systems  Time/Budget constraints  Limited knowledge of good practices  Laziness (As long as it works!) 4

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 5

6. God Class Example  System contains two classes: Controller Valve  Controller methods: openValve() closeValve()  Valve methods getStatus() Open() Close() 6

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 7

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 8

9. Sisyphus Antipattern Solutions 1. Row Limit Reduces processing on early pages but original issue remains for the last pages 2. Upper/Lower Bounds Only applicable on unique bounding fields 9

10. Sisyphus Antipattern Solutions 3. Sequence Numbers Set needed for every sort method 4. Caching Additional hardware resources 10

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 11

12. Detection Methods  Manual Requires vast knowledge of identified antipatterns  Logic based Rule based detection  Model driven Identification based on software models 12

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 13

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 14

15. 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 16

17. Antipattern Modeling Language (APML)  Mapped to standardized language like UML 17

18. Antipattern Modeling Language (APML)  Object Constraint Language (OCL) expressions created from AP and system models  OCL expressions compared to determine presence of antipattern 18

19. Future Work  Continued solving of known antipatterns  Prolog rules method verification  APML framework 19

20. Questions? 20