Within the profession of Business Analysis, a key function is for the Analyst to be able to communicate ideas effectively, in a way that an intended audience is easily able to understand.
One way of doing this is visually modelling a process or system; a large benefit of this is to be able to distil complex concepts down into one easy-to-digest visual. Additionally, it’s easy to iterate on a model based on feedback, and new requirements coming to light.
In order to help Business Analysts, various standardised modelling languages have been created. In this article, we’ll focus on two of the most common ones: Unified Modelling Language (UML) and Business Process Modelling Notation (BPMN). When should you use them, and what do they consist of?
Unified Modelling Language 🌐
UML is an object-oriented modelling language, intended for use in a broad range of different domains, architectures and coding languages. It is focussed on the design of IT systems specifically, and as such can be used for software or architectural designs.
What is UML good for?
- Interactions within an IT system or between IT systems.
- Determining objects used by a system, and the data items within them.
- Communicating architectural designs to stakeholders with technical expertise.
- Automated generation of code and/or test cases.
There are two different types of UML diagrams:
Structure diagrams
These demonstrate the objects and components within an IT system and how they relate to each other. Various types of structure diagrams are available, including:
Class diagrams
Denote object classes within the system, and the relationships between them.
Object diagrams
Similar to class diagrams, but show how the user of a system might see the objects within it.
Composite structure diagrams
Also similar to class diagrams, but also show the composite parts within classes.
Component diagrams
Depict how system components hang together and depend on each other.
Deployment diagrams
Denote the distribution order and configuration required when deploying an IT system.
Package diagrams
Model how packages in the system fit into the overall application model and their dependencies.
Profile diagrams
Allow you to document prototype data structures using “stereotypes” - domain-specific data models which can be used for more formal class or object diagrams later.
Example
Example class diagram on Diagrams.net
Behaviour diagrams
These demonstrate dynamic changes which may occur within an IT system as a result of user or automated triggers. Many different behaviour diagrams exist, including:
Use case diagrams
Describe how users and systems functionally interact with an IT system, in a series of steps.
Activity diagrams
Graphical representations of the workflow through a system, organised into swim lanes.
Interaction overview diagrams
Similar to activity diagrams, but with a focus on interactions over workflow.
Sequence diagrams
Models dependencies in the flow of an IT system in sequence.
Communication diagrams
Similar to sequence diagrams, but more focussed on how processes interact than on the time sequence.
Timing diagrams
Also similar to sequence diagrams, but with an emphasis on the amount of time each process takes.
State diagrams
Show which state transitions are permitted and how they are triggered.
Example
Example use case diagram on Diagrams.net
Business Process Modelling Notation 🔁
BPMN is a process-oriented modelling language, intended to represent the full business process supporting an IT system. It is based on flow charts, and likely to cover areas outside of the scope of a software or architectural change being investigated or proposed.
What is BPMN good for?
- Mapping out business processes underpinned by an IT system.
- Determining the different scenarios that may occur, and how a system should behave in each scenario.
- Communicating system behaviour to all business stakeholders, regardless of technical knowledge.
BPMN has four main components:
Flow objects
These can be events (triggers for the beginning or end of a flow), activities (processes or sub-processes undertaken by a user or system within the flow), or gateways (decision points where the flow can branch off in multiple directions).Connecting objects
These can be flows of activities or messages (denoted by a solid or dashed arrow, respectively) or associations (links between an artefact and a flow object).Swimlanes
These can exist on two levels: Pools (groupings of roles such as a function or organisation) and, within them, lanes (individual roles within the process).Artefacts
These can be data objects (information required for a process), groups (which link together activities in a process), or annotations (textual descriptions of to give additional context).
Latest comments (0)