The Emergent Laws of Method and Class Stereotypes in Object Oriented Software

1. The Emergent Laws of Method and Class Stereotypes in Object Oriented Software Natalia Dragan Visiting Assistant Professor Cleveland State University

2. Stereotypes • Classify objects in terms of role and responsibility [Wirfs-Brock 1993] • In UML (Unified Modeling Language) a mechanism to extend a basic modeling element specific to a given problem • Generalizations that reflect some intrinsic or atomic behavior of a method or class 10/15/10

3. Method Stereotypes Example • A getmethod is an accessor that returns the value of a data member const string& DataSource::getName() const { return m_ds_name; } • A set method is a mutator that changes the value of a data member void DataSource::setName(const string& name) { m_ds_name = name; notifyObservers (); }

4. Class Stereotypes in Analysis Model [Booch, Jacobson, Rumbaugh 1999] Boundary class models interaction between the system and its actors Control class is used to represent the dynamics of the system and the control tasks performed by the system Entity class represents the persistent information tracked by the system 4 4

5. Class Stereotypes in UML 10/15/10

6. Usefulness of Stereotypes Simple means to document source code and UML to highlight complex semantics Supports program comprehension Common, well understood, vocabulary for developers to discuss low level design Clues for refactoring Unfortunately, programmers rarely explicitly document classes and methods with stereotypes 6 6

7. Goals of Dissertation • Uncover emergent patterns and relationships between stereotypes and high-level design by comprehensive empirical investigation of OO software • Create a taxonomy of stereotypes • Reverse engineer stereotypes for methods and classes in a software system

8. Research Questions • Are method stereotypes indicative of class or system design? • Are there emergent class stereotypes similar to the case of method stereotypes? • Are there evolutionary patterns related to method and class stereotypes? 10/15/10

9. Research Contributions

10. Method Stereotypes Behavioral characteristics Structural Provide/support the structure of the class Collaborational Communication between different objects Creational Create/destroy objects Degenerate Limited functionality Type of data access to data members Read (accessors) Write (mutators) 10

11. Taxonomy of Method Stereotypes

12. Rules for Method Stereotype Identification in C++ • Access to data members • Return type • Parameter type • Const-ness • Type of local variables

13. Example 13

14. Research Contributions

15. Problem Description Automatically reverse-engineer class stereotypes from object-oriented software systems Create a taxonomy of class stereotypes through empirical investigation of open-source systems and analysis of the diverse features of a class Automatically analyze the structure of a class and determine the stereotype for all classes in a system 15

16. Approach Automatically identify stereotypes for all methods in a system using a taxonomy of method stereotypes [Dragan et al. 2006] Calculate distributions of method stereotypes for each class (class signature) Identify a class stereotype for all classes in a system based on the class signature 16

17. Class Signature Stereotype Distribution Emphasizes behavioral characteristics and class’s responsibilities Stereotype Category Distribution Emphasizes access type to data members and collaborations 17

18. Creating a Taxonomy of Class Stereotypes Validated the taxonomy of method stereotypes on 21 open-source C++ systems and identified common patterns at the system-level [Dragan et al. 2009] Observed emergent patterns of design at the class-level Formulated detection rules considering diverse features of a class with respect to method stereotype distributions 18

19. Systems Examined 19 19

20. Taxonomy of Class Stereotypes 20

21. Class Stereotypes: Data-Centric An Entity is the keeper of the data model and/or business logic A Minimal Entity has only get/set and command methods A Data Provider is a class that encapsulates data and consists mainly of accessors A Commander is a class that encapsulates data and behavior, and mainly consists of mutators 21

22. Class Stereotypes: Behavior-Centric A Boundary is a communicator in a system and has a large percentage of collaborational methods A Factoryisa creator of objects and has mostly factory methods A Controller is a class that provides functionality and processes data of external objects A Pure Controller has 100% controller and factory methods and worksonly on external objects 22

23. Class Stereotypes: Bad Smell A Large Class has many methods and combines multiple roles, such as Data Provider, Commander, Controller, and Factory A Lazy Class has get/set methods and a low percentage of other methods (could have significant number of degenerate methods) A DegenerateClass is when the state and behavior are degenerate (half or more methods are incidental or empty) A Data Class is a class with degenerate behavior - it has only get and set methods A Small Class is a class that only has one or two methods 23

24. Examples of Class Stereotypes 24

25. Identification of Class Stereotypes Stereotype and Stereotype Category distributions are used Data Provider Consists mostly of accessors |accessors| > 2 ∙ |mutators| Low control of other classes |accessors| > 2 (|controller| + |factory|) 25

26. Large Class Identification • Categories of stereotypes (accessor with mutator) and stereotypes, factory and controller, are approximately in equal proportions 1/5 |methods| < |accessors| + |mutators| < ⅔ |methods| & 1/5 |methods| < |factory| + |controller|< ⅔ |methods| • Controller and factory have to be present|factory| ≠ 0 &|controller|≠ 0 • Accessor and mutator have to be present|accessors| ≠ 0 &|mutators|≠ 0 • Number of methods in a class is high |methods| > average + stdev

27. Validation • Subjects assessment • Empirical study

28. Subjects assessment 45 classes (about 15%) of HippoDraw were labeled by the tool and subjects Each subject was given description of the taxonomy of method stereotypes examples of method stereotypes class signatures for 45 HippoDraw classes 28

29. Empirical Study 5 open source systems were examined to identify distributions of class stereotypes RQ: Is the taxonomy of class stereotypes applicable and useful for real systems? 33

30. Empirical Study 34

31. Distributions of Class Stereotypes 35

32. Findings on Class Stereotypes Class stereotypes proposed and identified by the tool exist in nontrivial quantities in real systems Most classes fit into at least one class stereotype Based on the distribution of the class stereotypes some similarities and differences between the systems were observed 36

33. Research Contributions

34. Classifying Software 21 open source systems along their method stereotype profiles were examined StereoCode tool automatically labeled each method with its corresponding stereotype and then calculated the total number of each for the entire system Systems were manually classified and automatically clustered based on method stereotypes distribution per system (system signature) 40

35. Stereotype Distribution Qt and wxWidgets (GUI frameworks)have a similar distribution with significant percentage of command, property, and get methods ACE has a very different distribution, e.g., non-void-command, command, and property are the most numerous methods 06/03/09 41

36. Stereotype Category Distribution Stereotype category distribution shows different patterns: Code::Blocks and KDevelop are a Mutator-Collaborator driven IDE HippoDraw is an Accessor-Mutator-Controller driven application 06/03/09 42

37. Manual Classification

38. Hierarchical Clustering [COBWEB]

39. Findings on Systems Classification Method stereotypes distribution is a good indicator of system architecture/design System signatures can be used to automatically cluster systems with similar architectures together Automatic clustering produced very similar results to the manual classification 45

40. The Emergent Laws • Existence of stereotypes in practice • Increasing diversity of stereotypes • Stereotypes are indicators of software design at different abstraction levels • Stereotypes are descriptors of software evolution

41. Lessons Learned • Challenges in collecting a large corpus of open source systems representing a wide range of architecture and problem domains • Putting the data together and making sure my tools work • Learning well-designed C++ open-source systems with accessible on-line documentation • Applying metrics for classifications did not work well

42. Contributions • Taxonomic description of object-oriented method and class stereotypes • Implementing tools for the extraction of method and class stereotypes and applying them for • source-code redocumentation • identification of descriptors and classifications of software systems • commit categorization • Evaluation of the approach by empirical studies on historical data for a wide range of open source C++ systems

43. Future work Apply the class stereotypes for automated layout of class diagrams Construct design-quality metrics based on stereotype classification Map class stereotypes to design pattern roles, and to detect bad-smell classes for refactoring Analyze evolutionary patterns at the class- and system-level 49

44. Publications • Dragan, N., “The Emergent laws of method and Class Stereotypes in Object-Oriented Software” , 27th IEEE International Conference on Software Maintenance (ICSM'11)Williamsburg, VA, Doctoral Symposium, Sep 27-29 2011, 6 pages • Dragan, N., Collard, M.L., Hammad, M., Maletic, J.I., “Using Stereotypes to Help Characterize Commits” , 27th IEEE International Conference on Software Maintenance (ICSM'11)Williamsburg, VA, Early Research Achievements Track, Sep 27-29 2011, 4 pages • Dragan, N., Collard, M.L., Maletic, J. I., "Automatic Identification of Class Stereotypes", in the Proceedings of the IEEE 26th IEEE International Conference on Software Maintenance (ICSM'10), Timisoara, Romania, Sept 12 - 18, (10 pages to appear). • Dragan, N., Collard, M.L., Maletic, J.I., "Using Method Stereotype Distribution as a Signature Descriptor for Software Systems", in Proceedings of the 25th IEEE International Conference on Software Maintenance (ICSM'09), Edmonton, Alberta Canada, September 20-26, 2009, pp. 567-570 • Dragan, N., Collard, M.L., Maletic, J.I., "Reverse Engineering Method Stereotypes", in Proceedings of the 22nd IEEE International Conference on Software Maintenance (ICSM'06), Philadelphia, Pennsylvania USA, September 25-27, 2006, pp. 24-34 _________________________________________________________________________________ • Sharif, B., Dragan, N., Sutton, A., Collard, M., Maletic, J. I., (2010), "Identifying Design Activities via Discourse and Content Analysis", at the NSF Workshop on Studying Professional Software Design, UC-Irvine, Feb 8-10, 10 pages • Andriyevska, O., Dragan, N., Simoes, B., Maletic, J.I., (2005), "Evaluating UML Class Diagram Layout based on Architectural Importance", in the Proceedings of the 3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT’05), Budapest Hungary, September 25th, 2005, pp. 14-20

45. Research Contributions

46. Commit Categorization • Goal: to gain a higher-level perspective of the changes to a system over its history • Commit signature (method stereotypes distributions of the added and deleted methods) are used to automatically categorize commits • Case study of four open-source project histories illustrated the potential benefits of the categorization

47. Examples of Commit Types

48. Commit Labeling

49. Deficiencies in Existing Approaches Collaborations between methods/classes (if they are used at all) are limited to inheritance relationships Only access type to the data members is considered Means for detection are not always given and tools to support automatic identification are rarely presented Evolution patterns on the method- and class-level have not yet been investigated extensively 55

50. Structural Methods: Accessors • A getmethod is an accessor that returns the value of a data member const string& getName() const; • A predicate method is an accessor that returns a Boolean result bool isEmpty() const; • A property method is an accessor that returns information about an object based on data member values int indexOfMinElement (int index) const; • A void-accessor method is an accessor that returns some information about data members through a parameter void MinElement (Element& element) const;