Classes

Modeling a system involves identifying the fundamental things (objects) in the system. These things are represented as classes in UML. The classes form the vocabulary (basic elements) of the system.

 

Definition

 

A class is a template or description for similar objects. Similar means objects have same attributes, operations, responsibilities and semantics. These classes may belong to problem domain or may belong to the solution or implementation for the problem. The graphical representation of a class in UML is a rectangle.

 

Example:

 

Names

 

Every class must have a name that distinguishes it from the other classes. The name is written as simple text. A class name can contain letters, numbers and punctuation marks except a colon. The name can be a simple name or a path name.

 

Example:

 

 

Attributes

 

An attribute represents a named property of a class that can hold a range of values that instances of the class can hold. Attributes are optional. Attributes are written in the compartment below the class name. Attributes may be represented simply by their names as shown below:

 

Example:

 

 

We can also specify an attribute with a type and a default initial value.

 

 

Operations

 

An operation is a service provided by the objects of a class. An operation is the abstraction of what can be done to an object. Operations are shared by all the objects. Operations are listed in a compartment below the attributes of the class. Operations are listed as simple names.

 

Example:

 

 

Operations can also be listed along with their signature which contains the name, return type and parameters of the operation.

 

 

Responsibilities

 

The responsibilities of a class specify the contract between the class and its objects. The responsibilities of a class represent its features (attributes and operations).

 

For example, the responsibility of a wall class is to represent the height, width and thickness of the wall. Responsibilities are represented as text in a compartment at the bottom of the class.

 

Example:

 

 

Common Modeling Techniques

 

Modeling the Vocabulary of a System

• Identify those things that users or implementers use to describe the problem or solution. Use CRC cards and use case-based analysis to help find these abstractions.
• For each abstraction, identify a set of responsibilities. Make sure that each class is crisply defined and that there is a good balance of responsibilities among all your classes.
• Provide the attributes and operations that are needed to carry out these responsibilities for each class.

 

 

Modeling the Distribution of Responsibilities in a System

• Identify a set of classes that work together closely to carry out some behavior.
• Identify a set of responsibilities for each of these classes.
• Look at this set of classes as a whole, split classes that have too many responsibilities into smaller abstractions, collapse tiny classes that have trivial responsibilities into larger ones, and reallocate responsibilities so that each abstraction reasonably stands on its own.
• Consider the ways in which those classes collaborate with one another, and redistribute their responsibilities accordingly so that no class within a collaboration does too much or too little.

 

 

Modeling Nonsoftware Things

• Model the thing you are abstracting as a class.
•  If you want to distinguish these things from the UML’s defined building blocks, create a new building block by using stereotypes to specify these new semantics and to give a distinctive visual cue.
• If the thing you are modeling is some kind of hardware that itself contains software, consider modeling it as a kind of node, as well, so that you can further expand on its structure.

 

 

Modeling Primitive Types

• Model the thing you are abstracting as a type or an enumeration, which is rendered using class notation with the appropriate stereotype.
•  If you need to specify the range of values associated with this type, use constraints.