The emergent laws of method and class stereotypes in object oriented software
1 / 63

The Emergent Laws of Method and Class Stereotypes in Object Oriented Software - PowerPoint PPT Presentation

  • Uploaded on

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]

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' The Emergent Laws of Method and Class Stereotypes in Object Oriented Software' - cullen

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The emergent laws of method and class stereotypes in object oriented software

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

Natalia Dragan

Visiting Assistant Professor

Cleveland State University

Stereotypes Oriented Software

  • 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


Method stereotypes example
Method Stereotypes Example Oriented Software

  • 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
Class Stereotypes in Analysis Model Oriented Software[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


Entity class represents the persistent

information tracked by the system



Class stereotypes in uml
Class Stereotypes in UML Oriented Software


Usefulness of stereotypes
Usefulness of Stereotypes Oriented Software

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



Goals of dissertation
Goals of Dissertation Oriented Software

  • 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
Research Questions Oriented Software

  • 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?


Research contributions
Research Contributions Oriented Software

Method stereotypes
Method Stereotypes Oriented Software

Behavioral characteristics


Provide/support the structure of the class


Communication between different objects


Create/destroy objects


Limited functionality

Type of data access to data members

Read (accessors)

Write (mutators)


Rules for method stereotype identification in c
Rules for Method Stereotype Identification in C++ Oriented Software

  • Access to data members

  • Return type

  • Parameter type

  • Const-ness

  • Type of local variables

Example Oriented Software


Research contributions1
Research Contributions Oriented Software

Problem description
Problem Description Oriented Software

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


Approach Oriented Software

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


Class signature
Class Signature Oriented Software

Stereotype Distribution

Emphasizes behavioral characteristics

and class’s responsibilities

Stereotype Category Distribution

Emphasizes access type to data members

and collaborations


Creating a taxonomy of class stereotypes
Creating a Taxonomy of Class Stereotypes Oriented Software

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


Systems examined
Systems Examined Oriented Software



Taxonomy of class stereotypes
Taxonomy of Class Stereotypes Oriented Software


Class stereotypes data centric
Class Stereotypes: Data-Centric Oriented Software

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


Class stereotypes behavior centric
Class Stereotypes: Behavior-Centric Oriented Software

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


Class stereotypes bad smell
Class Stereotypes: Bad Smell Oriented Software

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


Examples of class stereotypes
Examples of Class Stereotypes Oriented Software


Identification of class stereotypes
Identification of Class Stereotypes Oriented Software

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|)


Large class identification
Large Class Oriented Software 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 Oriented Software

  • Subjects assessment

  • Empirical study

Subjects assessment
Subjects assessment Oriented Software

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


Empirical study
Empirical Study Oriented Software

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?


Empirical study1
Empirical Study Oriented Software


Findings on class stereotypes
Findings on Class Stereotypes Oriented Software

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


Research contributions2
Research Contributions Oriented Software

Classifying software
Classifying Software Oriented 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)


Stereotype distribution
Stereotype Distribution Oriented Software

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



Stereotype category distribution
Stereotype Category Distribution Oriented Software

Stereotype category distribution shows different patterns:

Code::Blocks and KDevelop are a Mutator-Collaborator driven IDE

HippoDraw is an

Accessor-Mutator-Controller driven application



Manual classification
Manual Classification Oriented Software

Findings on systems classification
Findings on Systems Classification Oriented Software

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


The emergent laws
The Emergent Laws Oriented Software

  • 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
Lessons Learned Oriented Software

  • 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 Oriented Software

  • 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
Future work Oriented Software

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


Publications Oriented Software

  • 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

Research contributions3
Research Contributions Oriented Software

Commit categorization
Commit Categorization Oriented Software

  • 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

Examples of commit types
Examples of Commit Types Oriented Software

Commit labeling
Commit Labeling Oriented Software

Deficiencies in existing approaches
Deficiencies in Existing Approaches Oriented Software

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


Structural methods accessors
Structural Methods: Accessors Oriented Software

  • 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;

Structural methods mutators
Structural Methods: Mutators Oriented Software

  • A set method is a mutator that changes the value of a data member

    void setName(const string& name);

  • A command is a mutator that executes a complex change of the object’s state

    • The change may involve several data members

    • May change the data members either directly or indirectly using another mutator

      void draw(int x, int y);

  • A non-void-command is a command which returns a value

    int reshape(int x, int y);

Collaborational methods
Collaborational Methods Oriented Software

  • A collaborator is a method that works on objects of classes different from itself

    • It changes

      • Parameters that are objects

      • Local objects

      • Objects accessed indirectly through a data member (e.g., a vector of object pointers)

        bool hasControlPoints(const PlotterBase* plotter)const;

  • A controller is a method that works only on objects of classes different from itself

Creational methods factory
Creational Methods: Factory Oriented Software

  • A factory method is one that creates an object and returns it to the client (object creation method)

    • Factory methods work outside of the class and change the state of the external objects with which they have relations

      PlotterBase* createDisplay (const

      string& name);

Degenerate methods
Degenerate Methods Oriented Software

  • Incidental is a degenerate method which does not read or change an object’s state directly nor indirectly

  • Empty is a degenerate method which has no statements

Uml layout study
UML-Layout study Oriented Software

Evaluating UML Class Diagram Layout based on Architectural Importance

[O. Andriyevska, N. Dragan, B. Simoes, J. I. Maletic]

Problem description1
Problem Description Oriented Software

  • Investigate new layout guidelines for UML class diagrams considering architectural importance

  • Architectural importance in a UML class diagram is identified by control, boundary and entity class stereotypes

Layouts used
Layouts Used Oriented Software

Layout 1

(Multiple Clusters)

Orthogonal Layout

Layout 2

(3 Clusters)


Hypothesis Oriented Software

  • Layout of UML class diagrams based on architectural importance is more helpful in system comprehension compared to layouts focusing primarily on aesthetics and/or abstract graph guidelines

Study design
Study Design Oriented Software

Study details
Study Details Oriented Software

  • The study used HippoDraw ( approx. 200 classes)

  • Questions were multiple choice and related to maintenance, identifying the role of a class and refactoring

  • Each quantitative question had a time limit

    • Speed and accuracy of each participant’s response was recorded

  • Qualitative questions had no time limit

Results on refactoring questions
Results on Refactoring Questions Oriented Software

Clustered layout helped in answering questions based on refactoring

Study results
Study Results Oriented Software

  • Most participants preferred clustered layouts (experts preferred multiple clusters to 3-cluster)

  • The group with the 3-cluster layout had more correct answers as well as less unanswered questions than the other two groups

Conclusions Oriented Software

  • The study showed support for the hypothesis

  • Clustered layouts were found to be more helpful in answering questions and in system comprehension