A Comprehensive Guide to UML Class Diagram

The Unified Modeling Language (UML) is a general-purpose, developmental modeling language in the field of software engineering, designed to provide a standard approach to visualizing system design. The original motivation for creating UML was the desire to standardize different notation systems and software design methods. In UML, a class diagram is one of six types of structure diagrams. Class diagrams are the basis of the object modeling process and model the static structure of the system.

Structure diagrams show the static structure of the system and its parts on different abstraction and implementation levels and how they are related to each other. The elements in a structure diagram represent the meaningful concepts of a system, and may include abstract, real world and implementation concepts, there are seven types of structure diagram as follows:

 

Overview of the 14 UML Diagram Types

What is a Class Diagram?

A class diagram in the Unified Modeling Language (UML) is a static structure diagram that describes the structure of a system by showing its classes, their attributes, operations (or methods), and the relationships between objects. A class diagram is a blueprint for a system or subsystem. You can use class diagrams to model the objects that make up the system, show the relationships between objects, and describe the roles of these objects and the services they provide.

The Origin of UML

The goal of UML is to provide a standard notation that can be used by all object-oriented methods and to select and integrate the best elements of precursor notations. UML has been designed for a broad range of applications. Hence, it provides constructs for a broad range of systems and activities (e.g., distributed systems, analysis, system design and deployment).

UML is a notation that resulted from the unification of OMT from

  1. Object Modeling Technique OMT [James Rumbaugh 1991] – was best for analysis and data-intensive information systems.
  2. Booch [Grady Booch 1994] – was excellent for design and implementation. Grady Booch had worked extensively with the Ada language, and had been a major player in the development of Object Oriented techniques for the language. Although the Booch method was strong, the notation was less well received (lots of cloud shapes dominated his models – not very tidy)
  3. OOSE (Object-Oriented Software Engineering [Ivar Jacobson 1992]) – featured a model known as Use Cases. Use Cases are a powerful technique for understanding the behaviour of an entire system (an area where OO has traditionally been weak).

In 1994, Jim Rumbaugh, the creator of OMT, stunned the software world when he left General Electric and joined Grady Booch at Rational Corp. The aim of the partnership was to merge their ideas into a single, unified method (the working title for the method was indeed the „Unified Method”).

UML History

The Purpose of Class Diagram

Class diagrams are useful in many phases of system design. During the analysis phase, class diagrams can help you understand the requirements of the problem domain and identify its components. In object-oriented software projects, the class diagram created in the early stages of the project contains classes that are often converted into actual software classes and objects when writing code.

Later, you can refine the early analysis and conceptual models into class diagrams to show specific parts of the system, user interfaces, logic implementations, and so on.

Class diagrams are widely used in modeling object-oriented systems because they are the only UML diagrams that can be mapped directly to object-oriented languages. During the implementation phase of the software development cycle, you can use class diagrams to transform models into code and code into models. 

Class Example

A dog has states – color, name, breed as well as behaviors -wagging, barking, eating. An object is an instance of a class.

 

UML Class Notation

A class represent a concept which encapsulates state (attributes) and behavior (operations). Each attribute has a type. Each operation has a signatureThe class name is the only mandatory information.

Class Name:

  • The name of the class appears in the first partition.

Class Attributes:

  • Attributes are shown in the second partition.
  • The attribute type is shown after the colon.
  • Attributes map onto member variables (data members) in code.

Class Operations (Methods):

  • Operations are shown in the third partition. They are services the class provides.
  • The return type of a method is shown after the colon at the end of the method signature.
  • The return type of method parameters are shown after the colon following the parameter name. Operations map onto class methods in code

Class Relationships

A class may be involved in one or more relationships with other classes. A relationship can be one of the following types: (Refer to the figure on the right for the graphical representation of relationships).

Relationship Type Graphical Representation
Inheritance (or Generalization):
  • Represents an „is-a” relationship.
  • An abstract class name is shown in italics.
  • SubClass1 and SubClass2 are specializations of Super Class.
  • A solid line with a hollow arrowhead that point from the child to the parent class
Inheritance (or Generalization)
Simple Association:
  • A structural link between two peer classes.
  • There is an association between Class1 and Class2
  • A solid line connecting two classes
Simple association
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
Aggregation
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
Dependency

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.

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: publicprotectedprivate, 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

Class Visibility Example

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 (~)
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

Multiplicity

How many objects of each class take part in the relationships and multiplicity can be expressed as:

  • Exactly one – 1
  • Zero or one – 0..1
  • Many – 0..* or *
  • One or more – 1..*
  • Exact Number – e.g. 3..4 or 6
  • Or a complex relationship – e.g. 0..1, 3..4, 6.* would mean any number of objects other than 2 or 5

Multiplicity Example

  • Requirement: A Student can take many Courses and many Students can be enrolled in one Course.
  • In the example below, the class diagram (on the left), describes the statement of the requirement above for the static model while the object diagram (on the right) shows the snapshot (an instance of the class diagram) of the course enrollment for the courses Software Engineering and Database Management respectively)

Object Diagram

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
Aggregation Example

Inheritance Example – Cell Taxonomy

  • 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.
Inheritance Example

 

Class Diagram – Diagram Tool Example

A class diagram may also have notes attached to classes or relationships. Notes are shown in grey.

Class Diagram Example

 

In the example above:

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.

Class Diagram Example: Order System

Class Diagram Example: Order System

Class Diagram Example: GUI

A class diagram may also have notes attached to classes or relationships.

Class Diagram Example: GUI

Dealing with Complex System – Multiple or Single Class Diagram?

Inevitably, if you are modeling a large system or a large business area, there will be numerous entities you must consider. Should we use multiple or a single class diagram for modeling the problem? The answer is:

  • Instead of modeling every entity and its relationships on a single class diagram, it is better to use multiple class diagrams.
  • Dividing a system into multiple class diagrams makes the system easier to understand, especially if each diagram is a graphical representation of a specific part of the system.

Perspectives of Class Diagram in Software Development Lifecycle

We can use class diagrams in different development phases of a software development lifecycle and typically by modeling class diagrams in three different perspectives (levels of detail) progressively as we move forward:

Conceptual perspective: The diagrams are interpreted as describing things in the real world. Thus, if you take the conceptual perspective you draw a diagram that represents the concepts in the domain under study. These concepts will naturally relate to the classes that implement them. The conceptual perspective is considered language-independent.

Specification perspective: The diagrams are interpreted as describing software abstractions or components with specifications and interfaces but with no commitment to a particular implementation. Thus, if you take the specification perspective we are looking at the interfaces of the software, not the implementation.

Implementation perspective: The diagrams are interpreted as describing software implementations in a particular technology and language. Thus, if you take the implementation perspective we are looking at the software implementation.

Looking for a free class diagramming tool?

Visual Paradigm Online (VP Online) Free Edition is a free online drawing software that supports class diagrams, other UML diagrams, ERD tools and organization chart tools. It has a simple yet powerful editor that allows you to create class diagrams quickly and easily. This free UML editor has no ads, no access deadlines, and no restrictions, for example, on the number of diagrams, the number of shapes, etc. You own the diagrams you create for personal and non-commercial purposes.

Online Class Diagram Tool

Looking for more formal UML modeling on your desktop ?

Visual Paradigm Community Edition was launched since 2004 to provide a free UML software for sole non-commercial purpose, supporting users who was making their first steps in UML modeling, and who need a free and cross-platform UML modelling software for personal use, such as applying UML on student projects.

Visual Paradigm screen

UML modelling tool free for all sorts of non-commercial purpose. Supporting the 13 UML 2.x diagrams

Free UML Tool with 13 UML 2.x Diagrams Supported

We are adopted by over 1 Million installations around the globe, and is still growing. Many people are using the paid editions of Visual Paradigm to draw professional UML and ERD diagrams for system and database design & analysis, everyday.

Reason 2

Trust by IT professionals and large organizations

Many blue chip organizations, IT companies, consultants, universities, NGO and government units throughout the world have adopted Visual Paradigm (the paid editions). The figure below shows some of our paid customers.

Visual Paradigm Customers

Reason 3

High quality – Award-winning

We do not just trusted by the best-known enterprises world-wide, but also by the industry. Visual Paradigm is a multiple international awards winner.

Visual Paradigm Awards

Reason 4

The most widely-used modeling platform for academia

Most widely-used UML tool for academia, adopted by thousands of Universities and Colleges.

Schools Using Visual Paradigm

Reason 5

Huge collection of FREE learning resources (support by VP Community Circle)

Hundreds of UML and ERD diagram examples and templates

Hundreds of UML and ERD eaxamples ready for importing into Visual Paradigm for instant experiment or to get started with your own UML model. All for FREE.

Reason 6

Upgrade path to the commercial editions for wide spectrum of applications and possibilities

Easy upgrading for a huge set of additional features (say, BPMN and team collaboration support) and for commercial use, starting at $6 / month.

Packed features in Visual Paradigm

Reason 7

Active user forum to get helps and exchange ideas & Experiences

Support, share and exchange your ideas with other people in the Visual Paradigm’s active user forum.

Visual Paradigm forum

Reason 8

Cross-Platform, user friendly, fast & responsive application

Visual Paradigm can run on different platforms such as Windows, Linux and Mac. Its intuitive interface and powerful modeling features make modeling fast and easy!

Leave a Reply

Twój adres e-mail nie zostanie opublikowany.