the emergent laws of method and class stereotypes in object oriented software n.
Skip this Video
Download Presentation
The Emergent Laws of Method and Class Stereotypes in Object Oriented Software

Loading in 2 Seconds...

play fullscreen
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

Download Now 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



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?


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)


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


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


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?


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


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



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