Class Diagrams

A UML class diagram is a graph-like view of a domain or design model.

Nodes represent classes, interfaces, data types, and enumerations.

Links represent relationships between nodes such as generalizations, realizations, and associations.

Example:

Notes

·        Class properties include: name, stereotype, isAbstract, isLeaf, isActive, etc.

·        Classes own attributes and operations.

·        Attributes properties include: name, type, visibility, default value, isStatic, isLeaf, etc.

·        Operations properties include name, isStatic, isLeaf, and isAbstract.

·        Operations own parameters. Parameter properties include name, default value, and direction (in, out, in-out, return).

·        A generalization arrow connects a subclass to a superclass. Instances of the subclass inherit all of the features from the superclass and therefore can appear in contexts where supertype instances were expected (i.e., polymorphism).

·        The "owns" association represents the relationship "Account holder X owns account Y" or equivalently: "Account Y is owned by account holder X".

·        An association owns two endpoints.

·        Endpoint properties include: name, reference (the class it connects to), visibility, multiplicity (1, 1..3, *, etc.), and navigability (true or false).

·        It's possible to generate class declarations from class diagrams. For example: accounts.

·         Here's a version with details provided (by the programmer): Bank.java.

·        Note that both attributes and associations translate into fields. Also note that administrative methods (constructors, getters, setters, delegators, toString, hashCode, equals, etc,) can be automatically generated.

Object Diagrams

Object diagrams are rarely used. The following diagram depicts the objects and links created by Bank.main:

Notes:

 Links are instances of associations in the same way that objects are instances of classes. We can combine these ideas and say that object diagrams are instances of class diagrams.

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.

A utility or service is a class containing only static members.

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

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 abstract methods.

In Java an interface may not contain fields, private members, or methods. UML relaxes this restriction somewhat.)

An interface is represented using a class icon with the <<interface>> stereotype:

UML's realization arrow indicates that a class implements or realizes one or more interfaces:

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:

 

Data types, Primitive Types, and Enumerations

The UML primitive types:

Boolean
Integer
String
Real
UnlimitedNatural

Data Types and Enumerations

Data types are similar to classes. They can have fields and methods.

Instances of data types are value objects. Value objects often represent quantities (weight, cost) or qualities (color, shape).

The identity of a value object is determined by its properties, not—like reference objects-- by what it might represent in some application domain.

Value objects are usually immutable.

An enumeration is a list of types. Using enumerations to type an object is preferable to using strings that might be case-sensitive or misspelled.

Derived Attributes and Id numbers

A derived property (attribute or endpoint) is computed from the other attributes:

In Java we might implement this as:

class Rectangle {
   private double length;
`  private double width;
   public double getLength() { return length; }
   public double getWidth() { return width; }
   public double getArea() { return length * width; }
   // etc.
}

We can indicate if a property is unique, read-only, or if it's being used as an identifier:

In the above example we indicate that the Employee class is a leaf. In other words, it may not be specialized.