Class Stereotypes
A class stereotype is a simple description of the role of a class in a software system. Class stereotypes can be useful for a variety of software maintenance and evolution tasks. For example, class stereotype information can give clues on how different classes are interacting with each other.[1]
A class signature is a frequency distribution of method stereotypes for a class. It can be used to derive the class's stereotype.
A class signature can be presented in two complementary views that highlight the different areas of a class's design: detailed and summarized.[1]
In the detailed view, the frequency distribution counts of the stereotypes is given (get, set, controller, etc). The detailed view shows the internal components of a class and its responsibilities in terms of types of methods. It minimizes, to a large degree, interaction with other classes.[1]
FIGURE 1. Detailed view of two class signatures (from the open source system HippoDraw).[1]
In the summarized view, the frequency distribution counts of the stereotype categories is given (accessor, mutator, creational, etc). The summarized view shows the degree of coupling of the class with other classes in the system. It also shows the degree of cohesion within the class iteself. Additionally, parts of the system not yet implemented (degenerate) are shown.[1]
FIGURE 2. Summarized view of two class signatures (from the open-source system HippoDraw).[1]
Class stereotypes can be classified into the following categories:
| Class Stereotype | Description |
|---|---|
| Entity | Encapsulates data and behavior. Keeper of data model and/or business logic. No controller methods. |
| Minimal Entity | Special case of Entity. Consists only of get, set, and command methods |
| Data Provider | Encapsulates data and consists mainly of accessor methods |
| Commander | Encapsulates behavior and consists mainly of mutator methods |
| Boundary | Communicator with a large percentage of collaborational methods and a low percentage of controller methods. It also doesn't have many factory methods |
| Factory | Creator of objects and has mostly factory methods |
| Controller | Provides functionality to control external objects. Consists mostly of controller and factory methods |
| Pure Controller | Special case of controller. Consists only of controller and factory methods |
| Large Class | Contains a large number of methods that combine multiple roles, such as Data Provider, Commander, Controller, and Factory |
| Lazy Class | Consists mostly of get, set, and degenerates methods. Occurrence of other methods is low |
| Degenerate | Consists mostly of degenerate methods that do not read/write to the object's state |
| Data Class | Consists only of get and set methods |
| Small Class | Consists only of one or two methods |
TABLE 2. Class Stereotype Classification.[5]
A given class may have one or more of these stereotypes. For example, a Boundary-Data Provider class consists mostly of accessor and collaborational methods.
To determine the stereotypes of classes in a given software system, we start by identifying the method stereotypes. This information is then used to calculate the class signatures. Class stereotypes can then be derived from these class signatures using a set of rules that map the class signatures' characteristics to the class stereotype taxonomy.[1]
Notation used in the rules:
-
{stereotype} is the set of method stereotypes of the type stereotype. For example, {get} is a set consisting of methods such as get, get-collaborator, get-incidental, etc.
-
{stereotype category} is the set of method stereotypes of the category stereotype category. For example, {accessor} is a set consisting of all accessors (get, set, predicate, etc), accessors collaborators (get-collaborator, predicate-collaborator, etc) and accessors degenerate (predicate-incidental, voidaccessor-empty, etc). The set {collaborators} consists of all the collaborational methods (get-collaborator, set-collaborator, factory-collaborator, etc). Thus, the set {non-collaborators} = {methods} - {collaborators}.
-
{methods} is the set of all methods in a class.
-
|stereotype| denotes the cardinality of the set {stereotype}.
To identify the class stereotype Entity, the following rules need to be satisfied:
-
They contain an accessor besides get and a mutator besides set
{accessors} - {get} ≠ ∅ &
{mutators} - {set} ≠ ∅ -
The ratio of collaborational to non-collaborational methods is 2:1
|collaborators| / |non-collaborators| = 2 -
They can have factory methods but no controller methods
|controller| ≠ 0
To identify the class stereotype Minimal Entity, the following rules need to be satisfied:
-
The only method stereotypes are get, set, and command/non-void-command
{methods} - ({get}∪ {set} ∪ {command} ∪ {non-void-command}) = ∅ & |get| ≠ 0 & |set| ≠ 0 & ({command} ∪ {non-void-command}) ≠ ∅ -
The ratio of collaborational to non-collaborational methods is 2:1
|collaborators| / |non-collaborators| = 2
To identify the class stereotype Data Provider, the following rules need to be satisfied:
-
It consists mostly of accessors
|accessors| > 2 |mutators| -
Low control of other classes
|accessors| > 2 (|controller| + |factory|)
To identify the class stereotype Commander, the following rules need to be satisfied:
-
It consists mostly of mutators
|mutators| > 2 |accessors| -
Low control of other classes
|mutators| > 2 (|controller| + |factory|)
To identify the class stereotype Boundary, the following rules need to be satisfied:
-
More collaborators then non-collaborators
|collaborators| > |non-collaborators| -
Not all the methods are factory methods
|factory| <${1\over2}$ |methods| -
Low number of controller methods
|controller| <${1\over3}$ |methods|
To identify the class stereotype Factory, the following rules need to be satisfied:
- It consists mostly of factory methods
|factory| >${2\over3}$ |methods|
To identify the class stereotype Controller, the following rules need to be satisfied:
-
High control of other classes
|controller| + |factory| >${2\over3}$ |methods| -
Accessor or mutator are present
|accessors| ≠ 0 ∨ |mutators|≠ 0
To identify the class stereotype Pure Controller, the following rules need to be satisfied:
-
Only controller and factory methods with no mutator, accessor, or collaborator methods
|controller| + |factory| ≠ 0 &
|accessors| + | mutators| + |collaborator| = 0 -
There must be at least one controller method
|controller| ≠ 0
To identify the class stereotype Large Class, the following rules need to be satisfied:
-
Categories of stereotypes (accessor with mutator) and stereotypes, factory and controller, are approximately in equal proportions
${1\over5}$ |methods| < |accessors| + |mutators|
<${2\over3}$ |methods|
&${1\over5}$ |methods| < |factory| + |controller|
<${2\over3}$ |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
Note that average and stdev of number of methods are calculated per system. Their default values are 21 and 1 respectively in the stereocode tool.
To identify the class stereotype Lazy Class, the following rules need to be satisfied:
-
It has to contain get/set methods
|get| + |set| ≠ 0 -
It might have a large number of degenerate methods
|degenerate|>${1\over3}$ |methods| -
Occurrence of other stereotypes is low
|methods| – (|get| + |set| + |degenerate|) <=${1\over5}$ |methods|
To identify the class stereotype Degenerate Class, the following rules need to be satisfied:
- It consists of many degenerate methods
|degenerate| >${1\over2}$ |methods|
To identify the class stereotype Data Class, the following rules need to be satisfied:
- Only the simple accessor/mutators get and set are present
|get| + |set| ≠ 0 & |methods| – (|get| + |set|) = 0
To identify the class stereotype Small Class, the following rules need to be satisfied:
- Number of methods in a class is less than 3
|methods| < 3
FIGURE 3. Class stereotypes and their signatures (from the open source system HippoDraw).[1]
Stereocode is a tool that is used to statically analyze and re-document all the methods and classes with stereotype information. The information is added as a comment to the source code.[2]
The stereocode tool is based on the srcML infrastructure (srcML.org). srcML (srouce M L) is an XML representation for source code. The stereocode tool takes the XML representation of a source code as input and computes the stereotypes of all methods and classes using static analysis and XPath, which is used to address locations in XML.[1]
The stereocode tool is fast and efficient. It can identify and re-document big projects in minutes.
[1] Dragan, N., Collard, M. L., & Maletic, J. I. (2010, September). Automatic identification of class stereotypes. In 2010 IEEE International Conference on Software Maintenance (pp. 1-10). IEEE.