UML Classes,
Packages, and Objects
Review
An object contains fields (variables) and can execute certain methods (functions):
someObject.field1 // pseudo-syntax for referencing some field of some object
someObject.method1(arg1, arg2, ...) // pseudo-syntax for some object executing some method with arguments
A class contains field and method declarations:
// pseudo syntax for a class declaration:
class SomeClass {
field1 = ...;
field2 = ...;
// etc.
method1(param1, param2, ...) = ...;
method2(param1, param2, ...) = ...;
// etc.
}
A class can be viewed as a template for creating objects:
someObject = new SomeClass(); // pseudo-syntax for creating an object from a class
A package is a collection of related classes and sub-packages:
somePackage.sumSubpackage.someClass // pseudo-syntax for referencing a class in its package
Representing
Classes in UML
A UML class icon represents a class. This could be a class of analysis objects, a design-time class, or an implementation class (Java, C++, C#, etc.)
A UML class icon has three compartments:
Stereotypes
The top compartment contains the name of the class and its optional stereotype.
A stereotype can be used to show an informal role or category of a class.
In an analysis model typical stereotypes are:
<<entity>> = a domain-specific object such as a bank account or employee
<<control>> = an object that excutes user commands
<<boundary>> = an interface between an actor and a control. A control panel, for example.
<<actor>> = a person, device, or server that interacts with a system
Entity classes can be further subdivided into:
<<thing>> = an entity that has mass and volume
<<event>> = an entity that has a start time and duration
<<role>> = an entity that executes tasks. For example: plumber, clerk, nurse
<<type>> = an entity that describes other entities: film genre (Sci Fi, comedy, etc.), film rating (P, PG, etc.)
A well known design-time stereotype:
<<interface>> = a collection of related operations that must be implemented
A well-known implementation stereotype:
<<exception>>
Attributes
The middle compartment contains the attributes all instances of a class will have.
An attribute has four properties:
name
type (this can be a primitive type such as int, boolean, or double or an imported class such as String or Money)
visibility
+ = public = system visibility
~ = package visibility
# = protected = sub-class visibility
- = private = class visibility)
initial value
Operations
The third compartment contains the operations that instances of the class can execute.
Note that an operation is a method without an implementation:
method = operation + implementation
An operation has four properties:
name
scope (same as above)
parameters (each parameter has a name and type)
return type (usually supressed if void)
Examples
Example
Example
Note that we use Java primitive types. We could also use C++ types (string, bool), XSD types, or CORBA types.
By default, the visibility of all attributes should be private. This gives the developer to make the attributes read-write or read only. This can be done by providing getters and setters for the attributes.
Example
Mapping UML to Code
Many CASE tools can automatically generate class declarations in a selected language (Java, C++, C#, etc.) from UML class icons.
Attributes usually map to fields. Operations map to methods with default implementations.
Here's an example of the result of mapping the Employee class icon to a Java class declaration:
Note that age is an example of a derived attribute. It doesn't map to a field because it can be computed from other attributes.
Note that birthDay and id are read-only attributes.
Static Attributes
and Operations
A static attribute or operation is an attribute or operation belonging to a class rather than the instances of the class.
For example, a Trig utility class might contain sin and cos methods as well as the constant PI. There is no need to create objects to execute these methods.
Here's a Java declaration:
class TrigUtils {
static public double PI = 3.1416;
static public double sin(double x) {
... }
static public double cos(double x) {
... }
// etc.
}
Here's how this might be used:
TrigUtils.sin(TrigUtils.PI/2); // should = 1
In UML static operations and attributes are underlined:
Abstract Classes
and Interfaces
An abstract class cannot be instantiated. This usually happens because it has one or more abstract methods. Like an operation, an abstract method has no implementation. It must be implemented in concrete (i.e., non-abstract) subclasses. (The concept of subclass will be introduced later.)
The names of abstract classes and methods are italicized in UML:
An interface can be viewed as an abstract class containing only public abstract methods, no fields, no private members, no methods.
An interface is represented using a class icon with the <<interface>> stereotype:
Active Objects
An object has fields and methods. An active object has fields, methods, and a (virtual) processor that perpetually executes methods until some goal is achieved.
Raising Exceptions
An exception is an object that represents an error. Methods raise or throw exceptions that can be handled or caught by other methods:
UML Object Icons
An object icon has the form:
Note that the attribute-value compartment and name are optional.
For example:
Note that the operations are not shown. This would be tiresome since the operations are the same for all instances of a class.
UML Package Icons
A package icon is a folder:
For example, most of the Java class library is contained in the java package:
This package contains sub-packages such as:
In addition to libraries, packages often contain models:
And sub-systems:
Notes and
Constraints
A note is the UML equivalent of a comment:
A constraint is some Boolean-valued condition that must be satisfied by an object, class, field, or method.
If using a CASE tool that doesn't show constraints, show a constraint as a note bracketed in curly braces:
