In the previous article, State Diagrams in UML, you learned about State diagrams, the notations to be used in State diagrams, their significance, and how to build a State diagram for a specific scenario in the Courseware Management system.
Now you’ll learn about the next dynamic diagram—the UML Activity diagram. You are about to learn what an Activity diagram is, what its elements are, and you will be able to create Activity diagrams for your system.
Basics of UML Active Diagrams
Thinking of a flowchart of code is the easiest way to visualize an Activity diagram. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place.
Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state.
So, what is the importance of an Activity diagram, as opposed to a State diagram? A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows.
An Activity diagram talks more about these transitions and activities causing the changes in the object states.
Defining an Activity Diagram
It is time to take a look at the building blocks of an Activity diagram.
Elements of an Activity Diagram
An Activity diagram consists of the following behavioral elements:
|Element and its description
|Initial Activity: This shows the starting point or first activity of the flow. Denoted by a solid circle. This is similar to the notation used for Initial State.
|Activity: Represented by a rectangle with rounded (almost oval) edges.
|Decisions: Similar to flowcharts, a logic where a decision is to be made is depicted by a diamond, with the options written on either sides of the arrows emerging from the diamond, within box brackets.
|Signal: When an activity sends or receives a message, that activity is called a signal. Signals are of two types: Input signal (Message receiving activity) shown by a concave polygon and Output signal (Message sending activity) shown by a convex polygon.
|Concurrent Activities: Some activities occur simultaneously or in parallel. Such activities are called concurrent activities. For example, listening to the lecturer and looking at the blackboard is a parallel activity. This is represented by a horizontal split (thick dark line) and the two concurrent activities next to each other, and the horizontal line again to show the end of the parallel activity.
|Final Activity: The end of the Activity diagram is shown by a bull’s eye symbol, also called as a final activity.
Creating an Activity Diagram
Consider the example of attending a course lecture, at 8 am.
Figure 7.1—an example Activity diagram
As you can see in Figure 7.1, the first activity is to get dressed to leave for the lecture. A decision then has to be made, depending on the time available for the lecture to start, and the timings of the public trains (metra). If there is sufficient time to catch the train, then take the train; else, flag down a cab to the University. The final activity is to actually attend the lecture, after which the Activity diagram terminates.
Activity diagrams provide another ability, to clarify which actor performs which activity. Consider the Activity diagram in Figure 7.1. Were we to break down the activities further, we can break up the activity of taking the metra to “wait for the train to arrive at the station,” alight train, wait for train to arrive at destination, and so forth. The activity of hailing a cab would involve hail cab, wait for cab driver to stop, inform driver of your destination, and finally alight. In this, you can see that two more actors are involved, one is the metra driver, and the other is the cab driver. If you wish to distinguish in an Activity diagram the activities carried out by individual actors, vertical columns are first made, separated by thick vertical black lines, termed “swim lanes,” and name each of these columns with the name of the actor involved. You place each of the activities below the actor performing these activities and then show how these activities are connected.
Case Study—Courseware Management System
Let us now apply the information that we have gained from the previous sections to our Courseware Management System case study application. An Activity diagram depicts different workflows in a system. In Article 3, we had defined the following use cases for the Courseware Management System:
- View courses
- Manage topics for a course
- Manage course information
- View course calendar
- View tutors
- Manage tutor information
- Assign courses to tutors
Each of these use cases is actually a workflow. Hence, you can easily depict these use cases by using the Activity diagram. Ideally, you should use an Activity diagram to model a workflow by basing it on the different business entities (classes) involved in the workflow.
Hence, you will take a candidate use case and model it to gain a hands-on understanding of creating an Activity diagram. In this instance, we will model the “Manage course information” use case in the system using the Activity diagram.
Identifying the activities and transitions for managing course information
The course administrator is responsible for managing course information in the Courseware Management System. As part of managing the course information, the course administrator carries out the following activities:
- Check if course exists
- If course is new, proceed to the “Create Course” step
- If course exists, check what operation is desired—whether to modify the course or remove the course
- If the modify course operation is selected by the course administrator, the “Modify Course” activity is performed
- If the remove course operation is selected by the course administrator, the “Remove Course” activity is performed
In the first step in this Activity diagram, the system determines whether the course that is to be managed is a new course or an existing course. For managing a new course, a separate activity, “Create Course,” is performed. On the other hand, if a course exists, the course administrator can perform two different activities—modify an existing course or remove an existing course. Hence, the system checks the type of operation desired based on which two separate activities can be performed—”Modify Course” or “Remove Course”.
This completes the activities involved in managing course information carried out by the course administrator.
UML Activity diagram
Figure 7.2—Activity diagram for the “Manage course information” use case
Figure 7.2 shows the Activity diagram for the “Manage course information” use case. The Activity diagram depicts the steps involved in this workflow. At the end of each of the activities in the “Manage course information” workflow, the Course object is the one that is affected and, hence, we have included this in the Activity diagram.
The Activity diagram is a simple way to represent the workflows and their steps of an entire system or a subsystem. In the next article of this series, we will learn about Sequence diagrams.
About the Authors
Mandar S. Chitnis, Lakshmi Ananthamurthy and Pravin S. Tiwari are the co-founders of Novusware inc. They have co-authored the book Teach Yourself BEA WebLogic Server 7.0 in 21 Days (SAMS publishing Oct 2002) based on the recently launched WebLogic Server 7.0 by BEA Systems inc.
For any questions or queries regarding the article contents, please contact firstname.lastname@example.org.