Creating a UML diagram: How-tos, templates, and tips

A UML object diagram is an instance of a class diagram where actual examples are used to demonstrate the system. It represents objects and the relationships between them, which can be useful to create class diagrams, or to verify the accuracy and completeness of a class diagram. Object diagrams are also extensively used in object-oriented programming.

Much like class diagrams, object diagrams are also visualized as follows:

• Object: A rectangle with the name of the object, separated by a colon from its class and underlined, and the attributes of the object. Unlike classes, object attributes must have values assigned to them.
• Relationships between objects: Lines that denote association, inheritance, realization, dependency, aggregation, or composition.
  

A UML component diagram maps the structural relationship of the components of software systems. It visually represents a system’s components (with interfaces and ports) and the relationships between them. Detailed component diagrams make use of subsystems, which inherit the same rules as components.

Component diagrams verify the functionality of a system and act as a communication tool between a system developer and the associated stakeholders.

UML component diagrams are visualized as follows:

• Component: A rectangle with the name of the component, the icon of the component, and the interfaces of the component.
• Relationships between components: UML relationship notation for association, inheritance, realization, dependency, aggregation, or composition.
  

A UML deployment diagram displays how software is implemented on system hardware. The hardware components are called nodes, while the software components are called artifacts. Hence, UML deployment diagrams show the artifacts that run on each node of the system.

Mostly used by system engineers, deployment diagrams help illustrate the view of the system’s hardware arrangement and how software components fit into this topology.

UML deployment diagrams are visualized as follows:

• Nodes: Visualized as 3D boxes. Nodes can also have subnodes which are displayed as nested boxes.
• Artifacts that are deployed on the nodes: Rectangles within the node boxes.
• Relationships between nodes: UML relationship notation for association or dependency.
  

A UML package diagram showcases the structure of packages within a system. A package is a collection of related UML elements (such as classes). Package diagrams are applicable for demonstrating the functionality and layered architecture of a software system, as well as the relationship between these layers.

UML package diagrams are visualized as follows:

• Packages: Visualized as a rectangle with a tab at the top, like a folder. Packages must have different names and can be a combination of entire diagrams or components.
• Package name: Can be on the tab or inside the package rectangle.
• Dependencies between packages: Shown using dotted arrows.
  

A UML composite structure diagram allows you to take a peek into the internal actions, composition, and relationships of classes. While it is similar to a class diagram, a composite structure diagram goes into further detail by showing interfaces, packages, ports, connectors, and the classification of classes.

Composite structure diagrams find their use in programming practices to showcase how ports and parts of a class interact with each other, and with parts of the outside world.

UML composite structure diagrams are visualized as follows:

• Classes: Appears as a rectangle with the class name as a compartment at the top of the rectangle.
• Parts of the class: Represented as rectangles inside the class rectangle. They are named in camel case with the type and multiplicity separated by a colon. For example, "part1: Type [0..2]".
• Relationships between different classes: Shown with connectors or arrows.
  

A UML profile diagram can be thought of as an extension of the UML language, as it offers a mechanism to customize UML models. In other words, you can use UML profile diagrams to create new blocks and add properties and semantics to make UML more suited to your specific needs.

Profile diagrams use the following to extend UML:

• Stereotypes: You can use stereotypes to create new model elements from existing ones. For example, if you need to represent a hub in a networking environment, you can do so by encasing it in double guillemets.
• Tags: Tags are used to add additional information to a UML element as a keyword value pair. For example, you can specify the version of a component as a tag (version="8.1.0").
• Constraints: Constraints are used to specify the conditions for a UML element, which can be added in as notes (visualized as a sticky note). For example, you can specify that the age of a student class must be more than 20.
  

A UML activity diagram depicts the activities, actions, and workflows of computational or organizational processes. It’s basically an advanced flowchart that models the flow of operations of a system or organization.

Activity diagrams have different use cases and are usually used in the design of embedded systems to visualize how use cases relate to business workflows.

UML activity diagrams are visualized as follows:

• Actions: Visualized as rounded rectangles.
• Decisions: Represented as diamonds.
• Concurrent activities: Appears as bars.
• Start of the workflow: Marked by a black circle.
• Stop of the workflow: Visualized using an encircled black circle.
  

A UML sequence diagram displays the sequence required to carry out a functionality. It visualizes the processes and objects involved in the functionality and the sequence of messages exchanged between them.

Sequence diagrams are typically used in software engineering to capture how operations are carried out and how software coding can be done to achieve the use case sequence.

UML sequence diagrams are visualized as follows:

• Actor: Visualized as a stick figure.
• Individual participant in the interaction: Appears as a lifeline, which is a dotted line with a rectangle up top.
• Time between initiation and completion time of the interaction: Depicted as a thin rectangle on the lifeline.
• Message between two lifelines: Visualized by a text beside an arrow showing the direction where the message is going.
• Remarks about the elements: Represented using notes.
  

A UML state machine diagram (also called a state diagram) displays how an entity moves from one state to another in response to events. Software systems are typically event-driven, and state machine diagrams showcase how an event changes the state of different components.

State machine diagrams can be useful in software development settings to understand, document, and test the state of an object at some point in time. They are used in conjunction with sequence diagrams.

UML state machine diagrams are visualized as follows:

• States: Represented as a rounded rectangle with the name compartment at the top, and the activities listed in the bottom compartment.
• Start of the state diagram: Visualized by a black circle.
• Stop of the state diagram: Visualized using an encircled black circle.
• Transitions from one state to another: Appears as arrows.
• Events that trigger the state transition: Written as text beside the corresponding transition.
  

A UML communication diagram is an extension of object diagrams and displays the interaction between objects. Taking its cues from class diagrams, sequence diagrams, and use case diagrams, communication diagrams display both the structure and behavior of a system.

Communication diagrams are similar to sequence diagrams but the former arranges elements according to space while the latter arranges elements according to time. These diagrams are also used in software engineering to identify objects, their classes, and their attributes and visualize the messages passed between these objects.

UML communication diagrams are visualized as follows:

• Objects: Visualized as rectangular boxes.
• Messages between objects: Represented by arrows pointing from the sending object to the receiving object. The message text is situated just beside the arrow.
  

A UML interaction overview diagram displays the flow of activities between nodes in a system. You can think of it as a combination of activity and sequence diagrams. Each activity in the interaction overview diagram is visualized as a frame, which in turn contains a nested sequence diagram. The visualization used for an interaction overview diagram is the same as that on an activity diagram.

A UML timing diagram is a variant of the interaction diagram and a special form of a sequence diagram. It is used to explore object behavior over a certain period of time. The difference between a timing diagram and a sequence diagram is the reversal of axes. In timing diagrams, the time increases from left to right and the lifelines are shown in separate compartments.

Timing diagrams allow business users to see which steps in a system take a significant amount of time, thus helping improve business processes.

UML timing diagrams are visualized as follows:

• Individual participant in the interaction: Shown by a lifeline, which is a rectangle with a name. Multiple lifelines can be stacked in the same frame to showcase the interaction between them.
• States of the interaction: Stacked on the left margin of the lifeline and moved from top to bottom.
  

Once you decide on the types of UML diagrams to create, collect the information you need from all sources available. To do this, you can consult with stakeholders, review existing documentation, conduct interviews, or observe the system that you are trying to capture.

For instance, information about class diagrams might require expertise from software developers, while a UML use case diagram might require information gathering from product designers.

With a host of UML diagram maker tools readily available in the market, gone are the days of drawing UML diagrams by hand.

You can find UML diagram examples for almost every scenario. If you start with a template, you usually get all the required UML symbols and arrows, as well as directions on how you can use these elements in your design. Prefilled templates can help you improve the consistency, efficiency, and quality of your diagram without hours of manual work.

Using your chosen template, build your diagram’s primary structure first before moving on to the complexities and additional information required of your diagram. This prevents your graph from looking messy and overwhelming.

Once you have a foundation, you can start heading into the finer details. Edit or add more shapes, insert text, and connect them with lines and arrows. Remember to use the right symbols and lines for the elements and relationships you’re illustrating.

As you build your diagram, make sure you create a natural left-to-right or top-to-bottom flow. Grouping related elements together, as well as maintaining consistent spacing between them, help make your diagram look easier on the eye. For better clarity, avoid lines from crossing each other, and keep your names and descriptions short.

Once you are done creating elements and connecting them with UML diagram arrows, add annotations and extra information such as links to other resources wherever appropriate. However, refrain from doing this too much as it might turn things messy. If you feel like your diagram needs a lot of extra information to convey something, it is usually a good idea to split it down into sub-diagrams.

Cross-check if your requirements are met, verify the relationships between entities, review the names and notations used in the diagram, review the behavioral accuracy of your diagram, gather feedback, and refine the diagram to ensure that it finally, accurately represents your system.

For this purpose, it’s good to use a UML diagram tool that allows you to continually work and pick up where you left off without losing progress. With it, you can quickly make adjustments and share your UML diagram to your teammates without the trouble of repeatedly publishing and sharing versions that aren’t final yet.

The meaning of an open arrowhead depends on what kind of line it’s connected to, and what type of UML diagram you’re making.

For example, in class diagrams, when connected to a solid line, it means that there’s a “has a” relationship between the two things it connects. When connected to a dotted line, it means dependency between them. In sequence diagrams, a solid line with an open arrowhead means that the message being delivered is asynchronous.

In a class UML diagram, a public member is marked by the plus sign ‘+’.

Private members are marked with the minus sign ‘-’, while protected members are denoted by the octothorpe (or hashtag) ‘#’.

UML diagrams visually model your system. This not only makes it easier to comprehend, but also helps you assess the viability of your system, which can be helpful when you’re trying to design one.

For example, through object diagrams, you can test your system by modeling it using real-life examples. Similarly, with use case diagrams, you can identify the inside and outside factors affecting your system, as well as the behaviors between the actors within it.