Modeling OO Concepts

Section 0: Module Objectives or Competencies

Section 1: Overview

The Unified Modeling Language (UML) is a notation for expressing object-oriented designs.

The most important step of the design phase is designing the individual classes and methods.

• Object-oriented systems can be quite complex, so analysts need to create instructions and guidelines for programmers that clearly describe what the system must do.
• Class and method design is where all the work actually gets done during design. No matter which layer you are focusing on, the classes, which will be used to create the system objects, must be designed.

This section shows how some of the OO concepts covered earlier are modeled in UML.

Section 2: Class Diagram

A class diagram shows the classes relevant to a portion of a system, as well as the relationships between the classes.

• A class is represented most simply as a box that encloses the class name.
  
  • For more detail, the box may include a compartment for key attributes and a compartment for key methods.
    
  • Some or all of the attributes or methods may be omitted in order to highlight the remaining members and/or class relationships.
    • Three consecutive dots are sometimes included to indicate that some attributes or methods have been omitted.
   
• The class name may be preceded with a stereotype that further characterizes the class; examples include abstract or interface.
  • Elements that are abstract (including the names of abstract classes and interfaces) appear in italics.
• Each attribute is specified on a separate line with its type followed by its name.
  • An alternative notation is to specify the attribute name, followed by a colon, followed by the type.
• Each method is specified on a separate line with its return type, followed by its name, followed by a parameter list.
  • Constructor methods have no return type.
  • Parameters are specified by their type, but may not be named.
  • An alternative notation is to list the return type at the end, preceded by a colon.
• Every attribute and method is optionally preceded by a symbol to indicate its scope.
  • The appropriate symbols are public (+), private (-), and protected (#).
  • Methods can be grouped into categories that are preceded by notations like constructor, query (accessor), or update (mutator).

Section 3: Object

The UML notation for an object consists of a rectangle with the object name, followed by a colon, followed by the class name.

A second compartment can be added to specify the attribute values for that object, and it lists the attribute name followed by an equals sign and the value.

Section 4: Association

There is an association between two classes if it is possible for instances of one of the classes to create or send messages to instances of the second class.

An association is shown by a line that connects the two class boxes.

Section 5: Navigability

One-way navigability may be shown by attaching an arrow to one end of the line; messages may be sent only in the direction indicated by the arrow.

The next diagram indicates that instances of Source may send messages to instances of Target, but not the reverse.

• If the arrows are omitted, navigability is either two-way – instances of either class can send messages to instances of the other class – or left unspecified.

Section 6: Multiplicity

Multiplicity values (also called cardinality constraints) may be included at either or both ends of a line linking two class boxes.

• The multiplicity values indicate the number of objects involved in the relationship.
• The variables that appear in the following notation represent non negative integers.

The next diagram shows that an instance of Class A is associated with between four and seven instances of Class B, and that an instance of Class B is associated with exactly one instance of Class A.

Section 7: Composition

Composition is a kind of association (and is sometimes referred to as "association") that models the whole-part relationship between classes.

• Objects of one class (the composite) own, or interact with, instances of the second class.
• The second class is declared within and contained within the first class.
• Composition is shown by including a filled diamond on the composite's end.

In the following diagram, a Class A object owns one or more instances of Class B.

Section 8: Aggregation

Aggregation is another kind of association that models the whole-part relationship between classes.

• Aggregation expresses a "has a" relationship in which attributes of one class are made up of instances of the second class.
• In aggregation, the classes are declared individually and are distinct.
• A class object has as attributes one or more objects of other classes.
• Aggregation is shown by including a hollow diamond on the whole's end.

The class diagram below shows that a Class A object contains two Class B objects.

• The multiplicity values also indicate that a Class B object may be shared by any number of Class A objects.

Section 9: Inheritance

Inheritance is shown by including a hollow triangle on the parent class end of the line joining two classes.

• A solid line is used to show extension and a dashed line to show implementation of an interface.
• Inheritance expresses an "is a" relationship.

In following diagram, classes Subtype 1 and Subtype 2 both extend Supertype, and Subtype 2 implements Interface 1.

Section 10: Example 1

Here is an example UML diagram from this assignment.

Section 11: Additional UML Graphical Notation

Here are some additional notations, including some special diagrams: