---
title: "Short note: Synchronization bar"
subject: "Object Oriented Analysis and Design"
chapter: 2
key: "semester_6/object_oriented_analysis_and_design:short-note-synchronization-bar"
source: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/short-note-synchronization-bar
site: BCT Engineering
---

# Short note: Synchronization bar

Object Oriented Analysis and Design · Chapter 2: Object Oriented Analysis

- Asked in: 2069 Poush, 3 marks
- Video: [Activity Diagram - Step by Step Guide with Example](https://www.youtube.com/watch?v=knM8BGY9yVI) — Master2Teach
- Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14
- Page: https://www.bctengineer.com/q/semester_6/object_oriented_analysis_and_design/short-note-synchronization-bar
- Whole chapter: https://www.bctengineer.com/md/semester_6/object_oriented_analysis_and_design/chapter-2

## Question

Write a short note on Synchronization bar.

## Short answer

A synchronization bar (fork/join) in activity diagrams models concurrency. A fork splits one flow into parallel actions; a join waits for all parallel flows to complete before continuing. Example: 'Receive Order' forks to 'Pack Items' and 'Process Payment'; they join before 'Ship Order'.

## Answer

A **synchronization bar** is a thick horizontal (or vertical) line used in UML **activity diagrams** to show **concurrency**. It has two uses:

- **Fork:** one incoming flow is split into two or more outgoing flows that execute in parallel (concurrent flows).
- **Join:** two or more incoming flows are combined into one outgoing flow. The join waits until **all** incoming flows have arrived before the flow continues.

```text
        ( Receive Order )
               |
        ======================  fork
          |             |
   [Pack Items]   [Process Payment]
          |             |
        ======================  join
               |
          [ Ship Order ]
```

**Rules**
- In a well-structured diagram, the flows that leave a fork meet again at a matching join.
- Guard conditions are normally not placed on fork branches, since all of them run.
- A join is different from a merge: a merge (diamond) continues as soon as any one incoming flow arrives, while a join waits for all of them.

In UML 2 these are called the *fork node* and *join node*. They bring the model close to real parallel processing, e.g. multi-threaded implementations.

## Check yourself

The answer's key points as multiple-choice questions, with the correct option and why.

1. A synchronization bar is used in which UML diagram?
   A. Deployment diagram
   B. Class diagram
   C. Activity diagram
   D. Use case diagram
   Answer: C. It shows concurrency in activity diagrams. (Key point: Where it is used)

2. At a fork, the outgoing flows are:
   A. Chosen by guard conditions, only one taken
   B. Executed in parallel
   C. Executed one after another in order
   D. Discarded
   Answer: B. A fork splits one flow into concurrent flows. (Key point: Fork behaviour)

3. A join continues the outgoing flow when:
   A. The first guard is true
   B. The last flow starts
   C. Any one incoming flow arrives
   D. All incoming flows have finished
   Answer: D. A join waits for all incoming flows, unlike a merge. (Key point: Join behaviour)

4. How does a merge diamond differ from a join?
   A. They are identical
   B. A merge needs only one incoming flow
   C. A merge needs all flows
   D. A merge starts parallel flows
   Answer: B. Merge passes whichever alternative flow arrives; join synchronises all. (Key point: Join vs merge)