Class diagram

From Amachu
Jump to: navigation, search

Contents

Class Diagram

Umbrello UML Modeller showing a Class Diagram

Class Diagrams show the different classes that make up a system and how they relate to each other. Class Diagrams are said to be “static” diagrams because they show the classes, along with their methods and attributes as well as the static relationships between them: which classes “know” about which classes or which classes “are part” of another class, but do not show the method calls between them.

Class

Visual representation of an Class in UML

A Class defines the attributes and the methods of a set of objects. All objects of this class (instances of this class) share the same behavior, and have the same set of attributes (each object has its own set). The term “Type” is sometimes used instead of Class, but it is important to mention that these two are not the same, and Type is a more general term.

In UML, Classes are represented by rectangles, with the name of the class, and can also show the attributes and operations of the class in two other “compartments” inside the rectangle.

Attributes

In UML, Attributes are shown with at least their name, and can also show their type, initial value and other properties. Attributes can also be displayed with their visibility:

  • + Stands for public attributes
  • # Stands for protected attributes
  • - Stands for private attributes

Operations

Operations (methods) are also displayed with at least their name, and can also show their parameters and return types. Operations can, just as Attributes, display their visibility:

  • + Stands for public operations
  • # Stands for protected operations
  • - Stands for private operations

Templates

Classes can have templates, a value which is used for an unspecified class or type. The template type is specified when a class is initiated (i.e. an object is created). Templates exist in modern C++ and will be introduced in Java 1.5 where they will be called Generics.

Class Associations

Classes can relate (be associated with) to each other in different ways:

Generalization

Visual representation of an Generalization in UML

Inheritance is one of the fundamental concepts of Object Oriented programming, in which a class “gains” all of the attributes and operations of the class it inherits from, and can override/modify some of them, as well as add more attributes and operations of its own.

In UML, a Generalization association between two classes puts them in a hierarchy representing the concept of inheritance of a derived class from a base class. In UML, Generalizations are represented by a line connecting the two classes, with an arrow on the side of the base class.

Packages

Packages represent a namespace in a programming language. In a diagram they are used to represent parts of a system which contain more than one class, maybe hundereds of classes.

Associations

Visual representation of an Association in UML

An association represents a relationship between classes, and gives the common semantics and structure for many types of “connections” between objects.

Associations are the mechanism that allows objects to communicate to each other. It describes the connection between different classes (the connection between the actual objects is called object connection, or link.

Associations can have a role that specifies the purpose of the association and can be uni- or bidirectional (indicates if the two objects participating in the relationship can send messages to the other, of if only one of them knows about the other). Each end of the association also has a multiplicity value, which dictates how many objects on this side of the association can relate to one object on the other side.

In UML, associations are represented as lines connecting the classes participating in the relationship, and can also show the role and the multiplicity of each of the participants. Multiplicity is displayed as a range [min..max] of non-negative values, with a star (*) on the maximum side representing infinite.

Aggregation

Visual representation of an Aggregation relationship in UML

Aggregations are a special type of associations in which the two participating classes don't have an equal status, but make a “whole-part” relationship. An Aggregation describes how the class that takes the role of the whole, is composed (has) of other classes, which take the role of the parts. For Aggregations, the class acting as the whole always has a multiplicity of one.

In UML, Aggregations are represented by an association that shows a rhomb on the side of the whole.

Composition

Visual representation of an Composition in UML

Compositions are associations that represent very strong aggregations. This means, Compositions form whole-part relationships as well, but the relationship is so strong that the parts cannot exist on its own. They exist only inside the whole, and if the whole is destroyed the parts die too.

In UML, Compositions are represented by a solid rhomb on the side of the whole.

Other Class Diagram Items

Class diagrams can contain several other items besides classes.

Interfaces

Interfaces are abstract classes which means instances can not be directly created of them. They can contain operations but no attributes. Classes can inherit from interfaces (through a realisation association) and instances can then be made of these diagrams.

Datatypes

Datatypes are primitives which are typically built into a programming language. Common examples include integers and booleans. They can not have relationships to classes but classes can have relationships to them.

Enums

Enums are a simple list of values. A typical example is an enum for days of the week. The options of an enum are called Enum Literals. Like datatypes they can not have relationships to classes but classes can have relationships to them.

Examples

Library Domain Model

  • Library Domain Model describes main classes and relationships which could be used during analysis phase to better understand domain area for Integrated Library System (ILS), also known as a Library Management System (LMS).
  • Each physical library item - book, tape cassette, CD, DVD, etc. could have its own item number. To support it, the items may be barcoded. The purpose of barcoding is to provide a unique and scannable identifier that links the barcoded physical item to the electronic record in the catalog. Barcode must be physically attached to the item, and barcode number is entered into the corresponding field in the electronic item record.
  • Barcodes on library items could be replaced by RFID tags. The RFID tag can contain item's identifier, title, material type, etc. It is read by an RFID reader, without the need to open a book cover or CD/DVD case to scan it with barcode reader.
  • Library has some rules on what could be borrowed and what is for reference only. Rules are also defined on how many books could be borrowed by patrons and how many could be reserved.
  • Library catalog provides access for the library patrons and staff to all sources of information about library items, allows to search by a particular author, on a particular topic, or in a particular format, that the library has. It tells the user where materials meeting their specific needs can be found.
Library Class Diagram

Online Shopping Domain

  • This diagram is an example of class diagram which shows some domain model for online shopping. Each customer could have some web user identity. Web user could be in several states and could be linked to one shopping cart.
  • Each customer has exactly one account. Account owns shopping cart and orders. Orders are sorted and unique. Each order is linked to none to several payments.
  • Each order has current order status. Both order and shopping cart have line items linked to specific product.
Online Shopping Class Diagram
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox
Print/export