UML Class Diagrams

This page explains the use of UML Class Diagrams to represent a Business Object Model — a static collection of classes and interfaces and the collaborations and relationships among them.

Take the Brainbench certification test on the Unified Modeling Language (UML)

Topics this page:

Site Map  
About this site  

Class Diagrams

UML Class Diagrams focus on the responsibilites for classes rather than operations on attributes (such as totaling calculations). In contrast, Data models focus only on logical data relationships.

UML class diagrams like this are referenced by developers while implementing the system.

Even though it is generically called a "Class" diagram, it also represents Interfaces that define the business functionality implemented by classes.

Different types of classes are represented in a UML Class Diagram: During the Analysis phase, several stereotypes (analysis classes) are created. In a MVC (Model View Controller) architecture:

• Boundary (GUI) classes that interacts with users.
• Control classes transfer control.
• Entity classes contain business functionality and interact with back-end systems (databases).

as well as Abstract, Active, passive, and implementation classes.

When interfaces are displayed in compartments, it is preferable to add the (Microsoft style) “lollipop” symbol instead of adding the <<interface>> stereotype with a dotted realization line.

Operations and attributes defined by an interface are not repeated in the classes which realize that interface. Interfaces are like a contract that the classifier fulfills.

AgileModeling.com's description
Developer.com's 3 pages
PrimaryView.org
Self.com.au
dotNetcoders.com

Compartments for Role, Attributes, Operations

role	Customer
attributes	name credit limit credit rating ...
operation	get... set.. remind ...

In a UML Class Diagram, entities are represented by a sectioned rectangular box identified by a role name centered in the top compartment.

The middle compartment holds attributes (properties of the class) associated with each instance. Statics (data obtained through a function) are underlined.

Operations (OO Methods) — functionality that the class supports— in the 3rd compartment should begin with strong active verbs.

Ellipsis (...) appear at the bottom of a list in place of additional items not shown.

Additional "non-standard" compartments may be added to the class to list exceptions thrown or other notes pertaining to the class.

In accordance with Java coding style, class names should begin with an uppercase letter. while operations and attributes should begin with a lowercase letter. During the design phase, class attribute names are prefixed by a special character to specify visibility, usually in order of decreasing visibility.

Class names are singular because cardinality symbols express how many of them are involved in associations.

During design work (not during analysis), the data type (such as Date, Currency, Vector, etc.) are added to class attributes. Some tools enable a user to toggle between viewing or omitting data type, arguments, modifiers, and other detailed design information.

Scaffolding accessors such as getItem() and mutators such as setItem() (getters and setters) are assumed because they can be automatically generated for each class.

Text enclosed in {braces} are constraints — conditions among model elements that must be maintained as true. Braces are also used with a UML property string to indicate exceptions. Example: {exceptions=NetworkFailure, DBError}

Relationships (Associations) Among Classes


• Open arrowheads optionally specify "Flat Flow" navigability.
• Asychronous flows have one-sided arrowheads. Optional text on the line help to explain the relationship.

• A solid line defines an association between classes at the same conceptual level. They define extensions -- subclasses extending a superclass:
  • ClassA is the superclass of ClassB.
  • ClassB is a superclass of ClassC and ClassD.
  • ClassB is a subclass of ClassA.
  • By inheritance, ClassC and ClassD are both a subclass of ClassA.
  Ideally, a subclass is placed below its superclass.
• A dotted line defines a dependency relationship, such as
  • reference to a class or object that doesn't exist at the instance scope
  • an object obtained via a method call
  • using a parameter
  • using a member variable of another class.
• A hollow triangle next to a class being inherited defines a generalization relationship between classes at different levels of abstraction (specificity).
  • Java ClassB extends ClassA
  • For example, within a university, a Professor extends Employee.
• A filled triangle models a Procedure Call.
• A generalization with a dotted line represents a realization relationship -- a contract between two entities in which one entity defines functionality that another entity implements.
  • Java ClassB implements (realizes) InterfaceF.
  • ClassB IS-A InterfaceF.
  • ClassC IS-A ClassB, ClassA, and InterfaceF.
• A clear (hollow) diamond next to a class identifies it as "Shared" on a conceptually higher level than the part at the end of the line (such as OrderItem under an Orders class or CatalogItems under the Catalog). Aggregations are a unidirectional relationship such as a Java instance variable.
  • ClassE contains at least one reference to ClassB.
  • ClassE HAS-A ClassB reference within it.
• A solid diamond defines a composition -- a variation of the aggregation relationship but with a strong life cycle between the classes, such as maintaining state (keeping alive a part object that can belong only to one Whole object at any one time.
• A clear box is a qualifier, new to UML 2.

• The active class controlling all this is shown with a bold outline.
• An <<implementationClass>>

Class Multiplicity and Cardinality Adornments

Cardinality Symbol	Meaning
0	None. The application will not allow nulls.
1	One only (not zero). MUST know a single object.
n	Only n (where n < 1). An integer value.
0..1	Zero or one. MAY know a single object.
*	Many (including none). Avoid using this.
0..*	Zero or more. MAY know many objects.
0..n	Zero to n (where n > 1)
1..*	One or more. MUST know at least a single object.
n..*	n or more
m, n	m or n
m..n	At least m, but not more than n (where n & both > 1)

The number and letters next to each class symbolize its frequency of occurance: the cardinality of associations between objects. Cardinality indicates if a an array/linked-list/collection data structure is needed to store items.

For example, the multiplcity for a child with a maximum of two biological parents, would be 0..2.

A multiplicity of 1..* implies that the application will have code to ensure the Vector always has at least one item.

Use the word "may" if zero is allowed.
Use the word "must" if zero is not allowed.

Real Time UML

iming Expressions: A time expression is an expression that resolves to a time value.

Timing marks: A timing mark is a denotation of the specific time at which a given event or message occurs

Timing Constraint: A timing constraint is a constraint that involves an absolute or relative value of time

From http://softdocwiz.com/UML.htm