Fundamentals of UML Diagrams

1. Basic Use Case Notation

Introduction

A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships). You draw diagrams to visualize a system from  different perspectives, so a diagram is a projection into a system. UML has a lot of different diagrams (models). The reason for this is that it is possible to look at a system from different  viewpoints. UML being a graphical language includes nine such diagrams models):

UML nine diagrams can be divided into two categories

(a) Four diagram types represent static application structure:

(b) Five represent different aspects of dynamic behaviour

Source: Ellen Ambakisye Kalinga
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

1.1. A Class Diagram

In Object Oriented design and development terms, a class has a name, a set of methods (also known as operations) and related data members (also known as attributes) as shown in Figure 2.1. Class by itself is not very useful. A large software system may have thousands of classes, Modelling the relationships (association, inheritance, composition or aggregation) between them really defines systems behaviour.

Class diagrams show a set of classes, interfaces, and collaborations and their relationships. Class diagrams are the most common diagrams found in modelling object-oriented systems. It is an essential aspect of any Object Oriented Design method. 

Class diagrams address the static design view of a system. They are used at the analysis stage as well as design. Class diagrams that include active classes address the static process view of a system. Class Diagram syntax is being used to draw a plan of the major concepts for anyone to understand. This is called the Conceptual Model. Together with use cases, a conceptual diagram is a powerful technique in requirements analysis. Figure 2.2 shows an example of a class diagram.

Figure 2.2: An Example of a Class Diagram2.2.3

1.2. Object Diagram

Object Diagrams show a set of objects and their relationships. They are static snapshots of element instances found in class diagrams. Figure 2.3 shows an example of an object diagram.

Figure 2.3: Example of a UML Object Diagram

1.3. A Use Case Diagram

Use cases are versatile and valuable techniques for describing user requirements. A use case is a high-level description of a major user requirement. It represents the functionality of the system. It is a description of the system’s behaviour from a user’s viewpoint and constitutes a complete interaction with the system initiated by a user or another system. 

Use case diagrams address the static use case view of a system. The different types of people and/or devices (called actors) that interact with the system are identified along with the functions that they perform or initiate. A Use Case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

These diagrams are especially important in organizing and modelling the behaviors of a system. They are valuable aid during analysis, since developing Use Cases helps to understand requirements. Use Cases and a Conceptual Model are the powerful techniques in requirement analysis. Notations used when representing use case diagrams include:

Basic Use Case Notation 

The Actor represents a user of the system, or any external system that interacts with the system. The Use case represents a piece of functionality that is important to the user. Mostly we see the actor as a human user, but it can also represent a system or other nonhuman artifact. Figure 2.4 shows the basic notation of a use case diagram.

Figure 2.4: Basic Notation of a Use Case Diagram

2. Using the <> Relationship

This feature encourages re-use. If a use-case needs the functionality of another use-case in order to perform its task, it "uses" the 2nd use case. The relationship is drawn as a line with arrowhead pointing to the use case that is being "used" as shown in Figure 2.5.

Figure 2.5: A < > Relationship in a Use Case Diagram

3. Using the <> relationship

The "extends" notation extends the functionality of a use case to deal with errors or exceptions. "extends" relationship as shown in Figure 2.6 is being used when there is one use case that is similar to another but does a bit more. The relationship is drawn as a line with arrowhead pointing to the major use case.

The following is the essence of the "extends" relationship:

Figure 2.6: An < > Relationship in a Use Case Diagram

Using the << include >> relationship 

"include" relationship as shown in Figure 2.7 can be used for making up a big use case from simpler ones.

Figure 2.7: An < > Relationship in a Use Case Diagram

Use Case diagrams serve a number of purposes. Use case diagrams provide: 

Use Case Scenario 

A scenario is a description of a use case as a story. It is a story of one user's interaction with the system. It can be described in terms of:

The steps involved usually take the form of the normal flow of events, followed by alternate flows and/or exception flows.

Example:

In an ATM banking system, a use case would be "Validate User". The steps involved in authenticating a user are described in scenarios. There will be a number of different scenarios for "Validate User", describing different situations that can arise.

Main (primary) flow of events for "validate user" use case could be: 

Exception Flow of events 

By using scenarios, you are able to discover the objects that must collaborate to produce the results needed.

3.1. Sequence and Collaboration Diagrams

When developing Object-Oriented software, anything our software needs to do is going to be achieved by objects collaborating. We can draw a collaboration diagram to describe how we want the objects we built to collaborate. 

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams.

3.2. Sequence Diagrams

A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages. Sequence diagrams focus on the order in which the messages are sent. They provide a sequential map of messages passing between objects over time. The Sequence Diagrams are driven by the Use Cases which are the system requirements. In this form objects are shown as vertical lines with the messages as horizontal lines between them. The sequence of messages is indicated by reading down the page (read left to right and descending). Sequence Diagrams are about deciding and modelling "how" the system will achieve "what" we described in the Use Case model.

Although there is no fixed recipe for developing Sequence Diagrams, we can follow an approach that will result in a logical sequence diagram. This is as follows:

An analysis of the Sequence Diagrams shows the following (Shown in Figure 2.8):

i. A Class (Figure 2.8(a)) 

ii. A Lifeline (Figure 2.8(b)) 

iii. A focus of control (Figure 2.8(c)) 

iv. A message (Figure 2.8(d)) 

Example of a "Make a Cup of Tea" sequence diagram generated from its corresponding use case description is as shown in Figure 2.9.

Figure 2.9: A Sequence Diagram for "Make a Cup of Tea" Use Case

3.3. Collaboration Diagram

A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. Collaboration diagrams express both the context of a group of objects and the interaction between these objects. It focuses upon the relationships between the objects. They are very useful for visualizing the way several objects collaborate to get a job done and for comparing a dynamic model with a static model. When creating collaboration diagrams, patterns are used to justify relationships. Patterns are best principles for assigning responsibilities to objects. Figure 2.10 shows an example of a collaboration diagram.

Figure 2.10: Example of a Collaboration Diagram

Note for Sequence and Collaboration Diagrams

3.4. Statechart Diagrams

Statechart is a diagram that shows all possible object states. Some objects can at any particular time be in a certain state. A Statechart or simply a state diagram shows a state machine, consisting of states, transitions, events, and activities. Statechart diagrams address the dynamic view of a system. UML State charts are not normally needed. They are needed when an object has a different reaction dependent on its state; an example of a Statechart diagram is shown in Figure 2.11.

Figure 2.11: Example of a Statechart Diagram Activity Diagrams

An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system. They are used to show how different workflows or processes in a system are constructed, how they start, the many decision paths that can be taken from start to finish and where parallel processing may occur during execution. Activity diagrams address the dynamic view of a system. They are especially important in modelling the function of a system and emphasize the flow of control among objects. An Activity diagram as shown in Figure 2.12 generally does not model the exact internal behaviour of a software system (like a Sequence diagram does) but rather it shows the general processes and pathways at a high level.

Figure 2.12: Example of Activity Diagram

3.5. Package Diagrams

Any non-trial system needs to be divided up in smaller, easier to understand "chunks". A package is basically a logical container into which related elements can be placed, "like a folder or directory in an operating system". We can display groups of packages and relationships between them on the UML package diagram. 

Packages does not show actually what is inside the package, it provides a very "high-level" view of the system. Some case tools allow the user to double-click on the package icon in order to open-up the package and explore the contents. The common use of a package is to group related classes together, sometimes group related use cases.

Packages can be used to: 

Package diagram in Figure 2.13 shows three UML packages representing a "three-tier model"

Figure 2.13: Example of a Package Diagram

3.6. Component Diagrams

A component diagram is similar to the package diagram. It works in the same way as the package diagram, showing the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system. Component diagrams emphasize the physical software entity e.g. files headers, executables, link-libraries etc, rather than the logical partitioning of the package diagram. It is based heavily on the package diagram, but has added ".dll" to handle I/O, and has added a test harness executable. Not heavily used, but can be helpful in mapping the physical, real life software code and dependencies between them. Figure 2.14 shows a symbol used for a software component.

Figure 2.14: A Symbol for a Software Component

3.7. Deployment Diagrams

Deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of an architecture. They are related to component diagrams in that a node typically encloses one or more components. Figure 2.15 shows a node symbol used in a deployment diagram.

Figure 2.15: A Node Symbol for a Deployment Diagram

3.8. Design Class Diagrams

We built a class (conceptual or Domain) diagram made using concepts having properties of these concepts. No behaviour was allocated to any of these concepts. After creating collaboration diagrams, we can progress the conceptual model, and build it into a true "Design Class Diagram (DCD)". DCDs are based on the collaboration diagram. Attribute visibility is shown for permanent connections. DCD is a diagram which we can base our final program code upon. We can say that a DCD is a modification of a class diagram.

4. Summary on UML Diagrams