640 likes | 842 Views
The Emergent Laws of Method and Class Stereotypes in Object Oriented Software. Natalia Dragan Visiting Assistant Professor Cleveland State University . Stereotypes. Classify objects in terms of role and responsibility [Wirfs-Brock 1993]
E N D
The Emergent Laws of Method and Class Stereotypes in Object Oriented Software Natalia Dragan Visiting Assistant Professor Cleveland State University
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
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 (); }
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
Class Stereotypes in UML 10/15/10
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
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
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
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
Rules for Method Stereotype Identification in C++ • Access to data members • Return type • Parameter type • Const-ness • Type of local variables
Example 13
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
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
Class Signature Stereotype Distribution Emphasizes behavioral characteristics and class’s responsibilities Stereotype Category Distribution Emphasizes access type to data members and collaborations 17
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
Systems Examined 19 19
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
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
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
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
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
Validation • Subjects assessment • Empirical study
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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;