Process diagrams are a way to visualize processes, whether sequential or concurrent, distributed or nondistributed, deterministic or nondeterministic, synchronous or asynchronous, stochastic or nonstochastic.
They can be used to represent the flow of control and data in a system, making it easier to understand complex interactions. They can be used as a design aid, or generated after the fact to document a system's behavior.
There are (at least) two historically notable notations of interest.
At Wikipedia
At Wikipedia • Original Paper
In the mid-1990s, some folks including Grady Booch, Ivar Jacobson, and James Rumbaugh starting looking at tons of ways people were diagramming computing systems and put together the Unified Modeling Language, or UML. UML became a standard in 1997 with Version 1, and Version 2 followed in 2005.
UML is intended to express just about everything related to software systems, including structure, behavior, and interactions, and lets you model individual entities such as classes, objects, messages, states, ports, parts, lifelines, regions, and more.
UML had a good 10-20 years on top, but newer agile methods have challenged its dominance. Still, it is influential and useful to study.
UML version 2 consists of 14 diagram types that can be classified into three groups:
| STRUCTURAL DIAGRAMS | |
|---|---|
| Diagram Type | What it Models |
| Class Diagram | Classes and interfaces, with their attributes and operations, and the relationships among the classes and interfaces |
| Object Diagram | The structure of a system at a specific time |
| Component Diagram | Depicts how components are wired together to form larger components or systems |
| Composite Structure Diagram | The internal structure of a class and the collaborations that this structure makes possible |
| Package Diagram | How entities are grouped |
| Deployment Diagram | Constructs that define the execution architecture of systems and the assignment of software artifacts to system elements, in particular the assignment of software components to hardware nodes |
| Profile Diagram | Custom stereotypes, tagged values, and constraints |
| BEHAVIORAL DIAGRAMS | |
| Diagram Type | What it Models |
| Use Case Diagram | The interactions between actors and the system |
| Activity Diagram | Workflows of stepwise activities and actions with support for choice, iteration, and concurrency |
| State Machine Diagram | States and the transitions between them and the events that trigger the transitions and the actions performed on entry, exit, or transition |
| Interaction Overview Diagram | Control flow with nodes that can contain nested communication, sequence, and timing diagrams |
| Sequence Diagram | Process interactions arranged in time sequence |
| Communication Diagram | Interactions between objects in terms of sequenced messages |
| Timing Diagram | Temporal behaviors, durations, and constraints of objects and events |
Following are examples of UML behavioral diagrams that relate to processes, with a focus on the ways they express concurrency.
At Lucidchart • Wikipedia • Agile Modeling
At Lucidchart • Wikipedia • Agile Modeling
At Lucidchart • Wikipedia • Agile Modeling
At Lucidchart • Wikipedia • Agile Modeling
At Lucidchart • Wikipedia • Agile Modeling
Browse more examples at these sites:
When used in the design and modeling phases of software development, some have argued that the modern world of microservices, cloud-native architectures and the shift to lean and agile methodologies—with rapid iterative development, continuous delivery, prototyping, MVPs, tight feedback loops, and visual collaboration—make UML less relevant in the early stages of the software development lifecycle. However, UML can still be useful for documenting existing systems, understanding complex architectures, and communicating design decisions.
You will see a few things billed as UML alternatives which may be of interest to study:
We’ve covered: