UML Diagrams - A Standardized Visual Language for Software Design
Standardized ways of diagramming software systems.
Overview
Concept
Primitive, standardized, easy-to-draw diagrams to quickly communicate software structure and behavior.
Types of diagrams
UML (Unified Modeling Language) provides for many types of diagrams, divided into two categories:
| Structural | Behavioral |
|---|---|
| Class diagrams | Activity diagrams |
| Package diagrams | Sequence diagrams |
| Object diagrams | Use case diagrams |
| Component diagrams | State diagrams |
| Deployment diagrams | Communication diagrams |
| Interaction diagrams | |
| Timing diagrams |
Types of diagrams
We will explore just a few diagram types for example.
The book, “The Elements of UML Style”, by Scott W. Ambler is a good reference for more - we have pulled some key insights from it here.
Best Practices
Overview
Regardless of which diagram type, following best practices keeps diagrams understandable and avoids common pitfalls.
- Avoid crossed lines
- Avoid diagonal and curved lines
- Use consistent sizes
- Flow from top-to-bottom, left-to-right
Avoid crossed lines
Don’t do this:
Avoid crossed lines
Do this:
Avoid diagonal and curved lines.
Don’t do this:
Avoid diagonal and curved lines.
Do this:
Use consistent sizes
Don’t do this:
Use consistent sizes
Do this:
Flow top-to-bottom, left-to-right
Don’t do this:
Flow top-to-bottom, left-to-right
Do this:
Classes
Concept
Used to display the attributes, methods, and interactions of object-oriented classes in code.
One Class
A single class:
Multiple Classes
Relationships among classes, plus annotations, in a casual style:
Use Cases
Concept
Used to indicate interactions between actors and the system.
Single actor
A single actor, a single system:
Multiple actors
Multiple actors, multiple systems:
Read more about the use of use cases in requirements engineering.
Activities
Concept
Flow charts often used to document a complex operation, the logic of one or more use cases, or any other process.
Example 1
From The Elements of UML Style:
In [this figure], you can see that the business process forks into two parallel streams, one where the person attends a presentation and another where he or she signs up and pays for courses. The process forks – the person performs these activities – and when both streams are complete, the process continues from there (in this case it simply ends).
Shapes
The basic shapes in an activity diagram are:
-
solid circle (start) and solid circle with offset outline (end)
-
rounded rectangle indicating a step in the activity (i.e. an action or activity undertaken by either the user or the system)
-
rhombus/diamond indicating a decision point (i.e. any step that would require if/elif/else logic to determine what to do next in the flow).
-
thick bar indicating two or more sub-activities that are executed in parallel and must all conclude before moving on to the next step in the greater flow. The first bar from whence two or more sub-activities spawn is called a “fork”, and the second bar, where those sub-activities converge, is called a “join”.
-
arrows connecting these shapes to indicate the flow of control
Sequences
Concept
Used to validate and work out the logic and completeness of a certain scenario, often a use case or a part of a use case.
These show the entire sequence of messages sent among the objects and systems involved in the scenario.
Example
State Charts
Concept
Indicate the dynamic behavior of an entity based on its response to events, showing how the entity reacts to various events based on its current state.
- Only useful when behavior changes significantly based on internal state of the object.
Example
A seminar, partial lifecycle:
Example
A seminar, complete lifecycle:
Conclusions
Thank you. Bye.