UML Diagrams

1. Main diagrams:

Behavioral Diagram

Activity Diagram
Use Case Diagram
Timing Diagram
State Machine Diagram
Communication Diagram
Sequence Diagram

Structural Diagram

Class Diagram
Object Diagram
Component Diagram
Composite Structure Diagram
Deployment Diagram
Package Diagram
Profile Diagram

2. Some important diagrams:

Activity Diagram

It is generally used to describe the flow of different activities and actions. These can be both sequential and in parallel. It is used to:

Model workflows between/within use cases
Model complex workflows in operations on objects
Model in detail complex activities in a high level activity Diagram

Activity Diagram - Modeling a Word Processor

Open the word processing package.
Create a file.
Save the file under a unique name within its directory.
Type the document.
If graphics are necessary, open the graphics package, create the graphics, and paste the graphics into the document.
If a spreadsheet is necessary, open the spreadsheet package, create the spreadsheet, and paste the spreadsheet into the document.
Save the file.
Print a hard copy of the document.
Exit the word processing package.

Activity Diagram Example - Student Enrollment

An applicant wants to enroll in the university.
The applicant hands a filled out copy of Enrollment Form.
The registrar inspects the forms.
The registrar determines that the forms have been filled out properly.
The registrar informs student to attend in university overview presentation.
The registrar helps the student to enroll in seminars
The registrar asks the student to pay for the initial tuition.

Use Case Diagram

A cornerstone part of the system is the functional requirements that the system fulfills. Use Case diagrams are used to analyze the system’s high-level requirements. These requirements are expressed through different use cases. We notice three main components of this UML diagram:

Functional requirements – represented as use cases; a verb describing an action

Actors – they interact with the system; an actor can be a human being, an organization or an internal or external application

Relationships between actors and use cases – represented using straight arrows

Dependencies

A number of dependency types between use cases are defined in UML. In particular, <<extend>> and <<include>>.

<<extend>> is used to include optional behavior from an extending use case in an extended use case.
<<include>> is used to include common behavior from an included use case into a base use case in order to support re-use of common behavior.

The example below depicts the use case UML diagram for an inventory management system. In this case, we have the owner, the supplier, the manager, the inventory clerk and the inventory inspector.

Within the circular containers, we express the actions that the actors perform. Such actions are: purchasing and paying for the stock, checking stock quality, returning the stock or distributing it. As you might have noticed, use case UML diagrams are good for showing dynamic behaviors between actors within a system, by simplifying the view of the system and not reflecting the details of implementation.

Sequence Diagram

Sequence diagrams describe the sequence of messages and interactions that happen between actors and objects. Actors or objects can be active only when needed or when another object wants to communicate with them. All communication is represented in a chronological manner.

It is used in software development to represent the architecture of the system and how the different components are interconnected

Timing diagram

We are not interested in how the objects interact or change each other, but rather we want to represent how objects and actors act along a linear time axis.

The main components of a timing diagram are:

Lifeline – a line forming steps since the individual participant transits from one stage to another.
State timeline – a single lifeline can go through different states within a pipeline
Duration constraint – a time interval constraint that represents the duration of necessary for a constraint to be fulfilled
Time constraint – a time interval constraint during which something needs to be fulfilled by the participant
Destruction occurrence – a message occurrence that destroys the individual participant and depicts the end of that participant’s lifeline

The stages of human growth:

State Machine (Statechart) Diagram

Describe the different states of a component and how it changes based on internal and external events within a system.

A chess game state machine:

Statecharts find usage mainly in forward and reverse engineering of different systems.

Class Diagram

Class UML diagram is the most common diagram type for software documentation. Since most software being created nowadays is still based on the Object-Oriented Programming paradigm, using class diagrams to document the software turns out to be a common-sense solution. This happens because OOP is based on classes and the relations between them.

Class diagrams contain classes, alongside with their attributes (also referred to as data fields) and their behaviors (also referred to as member functions).

The ‘Checkings Account' class and the ‘Savings Account' class both inherit from the more general class, ‘Account'.

Object Diagram

Object diagrams help software developers check whether the generic abstract structure that they have created (class diagram), represents a viable structure when put into practice, i.e: when the objects of a class are instantiated. Some developers see it as a secondary level of accuracy checking.

The class 'Client' has an instance "James".

The class 'Checkings' and 'Savings' has instances Checkings and Savings account.

- 'account_number' and 'routing_number' are different for the Checkings and Savings account. It makes more sense to put those attributes in their respective classes, rather than in the more generic class 'Account'.

- 'wire_routing_number' and 'bic' are not used.

Component Diagram

Component Diagram describes the organization and wiring of the components in a system.

Component diagrams help model implementation details and double-check that every aspect of the system's required functions is developed.

The components are less physical and more conceptual stand-alone design elements.

The components provide or require interfaces to interact with other components in the system.

A component is a logical unit block of the system, a slightly higher abstraction than classes.

The Difference Between a Package Diagram and a Component Diagram:

- Package diagram elements are always public, while component diagram elements are private.

- Components are groups of classes that are deployed together and packages are a general grouping device for model elements. Packages can group any model elements, even things like use cases, but in practice they usually group classes, so components and packages tend to be synonymous.

Parts of a component diagram:

Component

Interface

A full circle represents an interface created or provided by the component. A semi-circle represents a required interface (input).

Dependencies

Dependencies among components

Port

A port is to help expose required and provided interfaces of a component.

Component Diagram - Online Shopping

Component Diagram for ATM

Package Diagram

It is used to show the organization and relationship of various model elements in the form of packages.

A package is a grouping of related UML elements, such as diagrams, documents, classes, or even other packages.

Parts of Package Diagram:

There are two sub-types involved in dependency. They are <<import>> & <<access>>.

Importing a package is equivalent to importing it's all public elements. So, the visibility of import can be thought of the visibility of the elements (imported elements).

import is public

access is private

Package Diagram Example - Order Processing System

The Problem Description

Design package diagram for "Track Order" scenario for an online shopping store. Track Order module is responsible for providing tracking information for the products ordered by customers. Customer types in the tracking serial number, Track Order modules refers the system and updates the current shipping status to the customer.

Identify the packages of the system

There is a track order module, it has to talk with other module to know about the order details, let us call it "Order Details".

Next after fetching Order Details it has to know about Shipping details, let us call that as "Shipping".

Identify the dependencies in the System

Track order should get order details from "Order Details" and "Order Details" has to know the tracking info given by the customer. Two modules are accessing each other which suffices <<access>> dual dependency