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
  • Presentation posted in: General

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

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

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



  • 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

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


Usefulness of stereotypes

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



Goals of dissertation

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

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?


Research contributions

Research Contributions

Method stereotypes

Method Stereotypes

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)


Taxonomy of method stereotypes

Taxonomy of Method Stereotypes

Rules for method stereotype identification in c

Rules for Method Stereotype Identification in C++

  • Access to data members

  • Return type

  • Parameter type

  • Const-ness

  • Type of local variables




Research contributions1

Research Contributions

Problem description

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




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

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

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



Taxonomy of class stereotypes

Taxonomy of Class Stereotypes


Class stereotypes data centric

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


Class stereotypes behavior centric

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


Class stereotypes bad smell

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


Examples of class stereotypes

Examples of Class Stereotypes


Identification of class stereotypes

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


Large class identification

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



  • Subjects assessment

  • Empirical study

Subjects assessment

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


Empirical study

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?


Empirical study1

Empirical Study


Distributions of class stereotypes

Distributions of Class Stereotypes


Findings on class stereotypes

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


Research contributions2

Research Contributions

Classifying software

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)


Stereotype distribution

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



Stereotype category distribution

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



Manual classification

Manual Classification

Hierarchical clustering cobweb

Hierarchical Clustering [COBWEB]

Findings on systems classification

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


The emergent laws

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

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



  • 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

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




  • 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

Commit categorization

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

Examples of commit types

Examples of Commit Types

Commit labeling

Commit Labeling

Deficiencies in existing approaches

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


Structural methods accessors

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;

Structural methods mutators

Structural Methods: Mutators

  • 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

  • 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

  • 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

  • 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

Evaluating UML Class Diagram Layout based on Architectural Importance

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

Problem description1

Problem Description

  • 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

Layout 1

(Multiple Clusters)

Orthogonal Layout

Layout 2

(3 Clusters)




  • 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

Study details

Study Details

  • 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

Clustered layout helped in answering questions based on refactoring

Study results

Study Results

  • 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



  • The study showed support for the hypothesis

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

  • Login