Class Diagrams

A UML Class diagram is a type of diagram in the Unified Modeling Language (UML) that represents the structure and relationships of classes in a software system. It provides a static view of the system by illustrating the classes, their attributes, methods, and associations.

In a UML Class diagram, classes are represented as rectangles divided into three compartments:

  1. Class name: The top compartment of the rectangle contains the name of the class. It represents a template or blueprint for creating objects.

  2. Attributes: The middle compartment lists the attributes or data members of the class. These are the variables that store data associated with objects created from the class.

  3. Methods: The bottom compartment lists the methods or operations that define the behavior of the class. These methods represent the actions or functions that objects of the class can perform.

Additionally, the UML Class diagram depicts relationships between classes using various types of connectors:

  1. Association: An association represents a relationship between two classes. It indicates that objects of one class are connected to objects of another class. The association can have multiplicity (indicating the number of instances involved) and roles (describing the nature of the association).

  2. Inheritance: Inheritance is represented using an arrow with an open triangle. It shows that one class (subclass or derived class) inherits attributes and methods from another class (superclass or base class). The subclass specializes the superclass and may add or override behavior.

  3. Dependency: A dependency represents a relationship where one class depends on another class. It is typically represented by a dashed arrow pointing from the dependent class to the class it depends on.

  4. Aggregation: Aggregation represents a "has-a" relationship where one class contains or owns objects of another class. It is depicted by a line with a diamond-shaped arrowhead pointing to the class being contained.

  5. Composition: Composition is a stronger form of aggregation, indicating a whole-part relationship where the parts cannot exist without the whole. It is depicted with a solid diamond-shaped arrowhead pointing to the class being composed.

UML Class diagrams help visualize the structure and relationships between classes in a software system. They provide an overview of the system's architecture and facilitate the understanding, communication, and design of the system. They are particularly useful for modeling object-oriented systems and can serve as a blueprint for implementation.

Class Relationships

Relationship Type

Graphical Representation

Relationship Type

Graphical Representation

Inheritance (or Generalization):

  • Represents an "is-a" relationship.

  • An abstract class name is shown in italics.

  • SubClass1 and SubCass2 are specializations of Super Class.

  • A solid line with a hollow arrowhead that point from the child to the parent class

Simple Association:

  • A structural link between two peer classes.

  • There is an association between Class1 and Class2

  • A solid line connecting two classes

 

Aggregation:

A special type of association. It represents a "part of" relationship.

  • Class2 is part of Class1.

  • Many instances (denoted by the *) of Class2 can be associated with Class1.

  • Objects of Class1 and Class2 have separate lifetimes.

  • A solid line with an unfilled diamond at the association end connected to the class of composite

 

Composition:

A special type of aggregation where parts are destroyed when the whole is destroyed.

  • Objects of Class2 live and die with Class1.

  • Class2 cannot stand by itself.

  • A solid line with a filled diamond at the association connected to the class of composite

 

Dependency:

  • Exists between two classes if the changes to the definition of one may cause changes to the other (but not the other way around).

  • Class1 depends on Class2

  • A dashed line with an open arrow

 

Relationship Names

Names of relationships are written in the middle of the association line.Good relation names make sense when you read them out loud:"Every spreadsheet contains some number of cells","an expression evaluates to a value"They often have a small arrowhead to show the direction in which direction to read the relationship, e.g., expressions evaluate to values, but values do not evaluate to expressions.

 

Relationship - Roles

  • A role is a directional purpose of an association.

  • Roles are written at the ends of an association line and describe the purpose played by that class in the relationship.

    • E.g., A cell is related to an expression. The nature of the relationship is that the expression is the formula of the cell.

 

Navigability

The arrows indicate whether, given one instance participating in a relationship, it is possible to determine the instances of the other class that are related to it.

The diagram above suggests that,

  • Given a spreadsheet, we can locate all of the cells that it contains, but that

    • we cannot determine from a cell in what spreadsheet it is contained.

  • Given a cell, we can obtain the related expression and value, but

    • given a value (or expression) we cannot find the cell of which those are attributes.

Visibility of Class attributes and Operations

In object-oriented design, there is a notation of visibility for attributes and operations. UML identifies four types of visibility: public, protected, private, and package.

The +, -, # and ~ symbols before an attribute and operation name in a class denote the visibility of the attribute and operation.

  • + denotes public attributes or operations

  • - denotes private attributes or operations

  • # denotes protected attributes or operations

  • ~ denotes package attributes or operations

 

In the example above:

  • attribute1 and op1 of MyClassName are public

  • attribute3 and op3 are protected.

  • attribute2 and op2 are private.

Access for each of these visibility types is shown below for members of different classes.

Access Right

public (+)

private (-)

protected (#)

Package (~)

Access Right

public (+)

private (-)

protected (#)

Package (~)

Members of the same class

yes

yes

yes

yes

Members of derived classes

yes

no

yes

yes

Members of any other class

yes

no

no

in same package

Aggregation Example - Computer and parts

  • An aggregation is a special case of association denoting a "consists-of" hierarchy

  • The aggregate is the parent class, the components are the children classes

Inheritance Example

  • Inheritance is another special case of an association denoting a "kind-of" hierarchy

  • Inheritance simplifies the analysis model by introducing a taxonomy

  • The child classes inherit the attributes and operations of the parent class.

Class Diagram - Diagram Example

We can interpret the meaning of the above class diagram by reading through the points as following.

  1. Shape is an abstract class. It is shown in Italics.

  2. Shape is a superclass. Circle, Rectangle and Polygon are derived from Shape. In other words, a Circle is-a Shape. This is a generalization / inheritance relationship.

  3. There is an association between DialogBox and DataController.

  4. Shape is part-of Window. This is an aggregation relationship. Shape can exist without Window.

  5. Point is part-of Circle. This is a composition relationship. Point cannot exist without a Circle.

  6. Window is dependent on Event. However, Event is not dependent on Window.

  7. The attributes of Circle are radius and center. This is an entity class.

  8. The method names of Circle are area(), circum(), setCenter() and setRadius().

  9. The parameter radius in Circle is an in parameter of type float.

  10. The method area() of class Circle returns a value of type double.

  11. The attributes and method names of Rectangle are hidden. Some other classes in the diagram also have their attributes and method names hidden.