UML Diagrams

The underlying premise of UML is that no one diagram can capture the different elements of a
system in its entirety. Hence, UML is made up of nine diagrams that can be used to model a
system at different points of time in the software life cycle of a system. The nine UML diagrams
are:

• Use case diagram: The use case diagram is used to identify the primary elements and
processes that form the system. The primary elements are termed as "actors" and the
processes are called "use cases." The use case diagram shows which actors interact with
each use case.
• Class diagram: The class diagram is used to refine the use case diagram and define a
detailed design of the system. The class diagram classifies the actors defined in the use
case diagram into a set of interrelated classes. The relationship or association between the
classes can be either an "is-a" or "has-a" relationship. Each class in the class diagram may
be capable of providing certain functionalities. These functionalities provided by the class
are termed "methods" of the class. Apart from this, each class may have certain "attributes"
that uniquely identify the class.
• Object diagram: The object diagram is a special kind of class diagram. An object is an
instance of a class. This essentially means that an object represents the state of a class at a
given point of time while the system is running. The object diagram captures the state of
different classes in the system and their relationships or associations at a given point of
time.
• State diagram: A state diagram, as the name suggests, represents the different states
that objects in the system undergo during their life cycle. Objects in the system change
states in response to events. In addition to this, a state diagram also captures the transition
of the object's state from an initial state to a final state in response to events affecting the
system.
• Activity diagram: The process flows in the system are captured in the activity diagram.
Similar to a state diagram, an activity diagram also consists of activities, actions,
transitions, initial and final states, and guard conditions.
• Sequence diagram: A sequence diagram represents the interaction between different
objects in the system. The important aspect of a sequence diagram is that it is time-
ordered. This means that the exact sequence of the interactions between the objects is
represented step by step. Different objects in the sequence diagram interact with each other
by passing "messages".
• Collaboration diagram: A collaboration diagram groups together the interactions
between different objects. The interactions are listed as numbered interactions that help to
trace the sequence of the interactions. The collaboration diagram helps to identify all the
possible interactions that each object has with other objects.
• Component diagram: The component diagram represents the high-level parts that
make up the system. This diagram depicts, at a high level, what components form part of
the system and how they are interrelated. A component diagram depicts the components
culled after the system has undergone the development or construction phase.
 • Deployment diagram: The deployment diagram captures the configuration of the
runtime elements of the application. This diagram is by far most useful when a system is
built and ready to be deployed.

Now that we have an idea of the different UML diagrams, let us see if we can somehow group
together these diagrams to enable us to further understand how to use them.

UML Diagram Classification—Static, Dynamic, and Implementation

A software system can be said to have two distinct characteristics: a structural, "static" part and a
behavioral, "dynamic" part. In addition to these two characteristics, an additional characteristic
that a software system possesses is related to implementation. Before we categorize UML
diagrams into each of these three characteristics, let us take a quick look at exactly what these
characteristics are.

• Static: The static characteristic of a system is essentially the structural aspect of the
system. The static characteristics define what parts the system is made up of.
• Dynamic: The behavioral features of a system; for example, the ways a system behaves
in response to certain events or actions are the dynamic characteristics of a system.
• Implementation: The implementation characteristic of a system is an entirely new
feature that describes the different elements required for deploying a system.

The UML diagrams that fall under each of these categories are:

• Static

 Use case diagram

 Class diagram
• Dynamic
 Object diagram
 State diagram
 Activity diagram
 Sequence diagram
 Collaboration diagram
• Implementation
 Component diagram
 Deployment diagram

Finally, let us take a look at the 4+1 view of UML diagrams.

4+1 View of UML Diagrams

Considering that the UML diagrams can be used in different stages in the life cycle of a system,
let us take a look at the "4+1 view" of UML diagrams. The 4+1 view offers a different
perspective to classify and apply UML diagrams. The 4+1 view is essentially how a system can
be viewed from a software life cycle perspective. Each of these views represents how a system
can be modeled. This will enable us to understand where exactly the UML diagrams fit in and
their applicability.

These different views are:

• Design View: The design view of a system is the structural view of the system. This
gives an idea of what a given system is made up of. Class diagrams and object diagrams
form the design view of the system.
• Process View: The dynamic behavior of a system can be seen using the process view.
The different diagrams such as the state diagram, activity diagram, sequence diagram, and
collaboration diagram are used in this view.
• Component View: Next, you have the component view that shows the grouped modules
of a given system modeled using the component diagram.
• Deployment View: The deployment diagram of UML is used to identify the deployment
modules for a given system. This is the deployment view of the
• Use case View: Finally, we have the use case view. Use case diagrams of UML are used
to view a system from this perspective as a set of discrete activities or transactions.

USE CASE DIAGRAM

The Use case diagram is used to identify the primary elements and processes that form the
system. The primary elements are termed as "actors" and the processes are called "use cases."
The Use case diagram shows which actors interact with each use case.
The above statement pretty much sums up what a use case diagram is primarily made up of—
actors and use cases.

 A use case diagram captures the functional aspects of a system. More

specifically, it captures the business processes carried out in the system. As you discuss the
functionality and processes of the system, you discover significant characteristics of the
system that you model in the use case diagram. Due to the simplicity of use case diagrams,
and more importantly, because they are shorn of all technical jargon, use case diagrams are a
great storyboard tool for user meetings. Use case diagrams have another important use. Use
case diagrams define the requirements of the system being modeled and hence are used to
write test scripts for the modeled system.
so who should normally be involved in the creation of use cases? Normally, domain experts and
business analysts should be involved in writing use cases for a given system. Use cases are
created when the requirements of a system need to be captured. Because, at this point no design
or development activities are involved, technical experts should not be a part of the team
responsible for creating use cases. Their expertise comes in use later in the software lifecycle.
Elements of a Use Case Diagram
A use case diagram is quite simple in nature and depicts two types of elements: one representing
the business roles and the other representing the business processes. Let us take a closer look at
use at what elements constitute a use case diagram.

• Actors: An actor portrays any entity (or entities) that performs certain roles in a given
system. The different roles the actor represents are the actual business roles of users in a
given system. An actor in a use case diagram interacts with a use case. For example, for
modeling a banking application, a customer entity represents an actor in the application.
Similarly, the person who provides service at the counter is also an actor. But it is up to
you to consider what actors make an impact on the functionality that you want to model. If
an entity does not affect a certain piece of functionality that you are modeling, it makes no
sense to represent it as an actor. An actor is shown as a stick figure in a use case diagram
depicted "outside" the system boundary, as shown in Figure 3.1.

Figure 3.1: an actor in a use case diagram

To identify an actor, search in the problem statement for business terms that portray roles
in the system. For example, in the statement "patients visit the doctor in the clinic for
medical tests," "doctor" and "patients" are the business roles and can be easily identified as
actors in the system.

• Use case: A use case in a use case diagram is a visual representation of a distinct
business functionality in a system. The key term here is "distinct business functionality."
To choose a business process as a likely candidate for modeling as a use case, you need to
ensure that the business process is discrete in nature. As the first step in identifying use
cases, you should list the discrete business functions in your problem statement. Each of
these business functions can be classified as a potential use case. Remember that
identifying use cases is a discovery rather than a creation. As business functionality
becomes clearer, the underlying use cases become more easily evident. A use case is
shown as an ellipse in a use case diagram (see Figure 3.2).

Figure 3.2: use cases in a use case diagram

 Figure 3.2 shows two uses cases: "Make appointment" and "Perform medical tests" in the
use case diagram of a clinic system. As another example, consider that a business process
such as "manage patient records" can in turn have sub-processes like "manage patient's
personal information" and "manage patient's medical information." Discovering such
implicit use cases is possible only with a thorough understanding of all the business
processes of the system through discussions with potential users of the system and relevant
domain knowledge.

• System boundary: A system boundary defines the scope of what a system will be. A
system cannot have infinite functionality. So, it follows that use cases also need to have
definitive limits defined. A system boundary of a use case diagram defines the limits of the
system. The system boundary is shown as a rectangle spanning all the use cases in the
system.

Figure 3.3: a use case diagram depicting the system boundary of a clinic application

Figure 3.3 shows the system boundary of the clinic application. The use cases of this
system are enclosed in a rectangle. Note that the actors in the system are outside the
system boundary.

The system boundary is potentially the entire system as defined in the problem statement.
But this is not always the case. For large and complex systems, each of the modules may
be the system boundary. For example, for an ERP system for an organization, each of the
modules such as personnel, payroll, accounting, and so forth, can form the system
boundary for use cases specific to each of these business functions. The entire system can
span all of these modules depicting the overall system boundary.

Relationships in Use Cases

Use cases share different kinds of relationships. A relationship between two use cases is basically
a dependency between the two use cases. Defining a relationship between two use cases is the
decision of the modeler of the use case diagram. This reuse of an existing use case using different
types of relationships reduces the overall effort required in defining use cases in a system. A
similar reuse established using relationships, will be apparent in the other UML diagrams as well.
Use case relationships can be one of the following:

• Include: When a use case is depicted as using the functionality of another use case in a
diagram, this relationship between the use cases is named as an include relationship.
Literally speaking, in an include relationship, a use case includes the functionality
described in the another use case as a part of its business process flow. An include
relationship is depicted with a directed arrow having a dotted shaft. The tip of the
arrowhead points to the parent use case and the child use case is connected at the base of
the arrow. The stereotype "<<include>>" identifies the relationship as an include
relationship.

Figure 3.4: an example of an include relationship

For example, in Figure 3.4, you can see that the functionality defined by the "Validate
patient records" use case is contained within the "Make appointment" use case. Hence,
whenever the "Make appointment" use case executes, the business steps defined in the
"Validate patient records" use case are also executed.

• Extend: In an extend relationship between two use cases, the child use case adds to the
existing functionality and characteristics of the parent use case. An extend relationship is
depicted with a directed arrow having a dotted shaft, similar to the include relationship.
The tip of the arrowhead points to the parent use case and the child use case is connected at
the base of the arrow. The stereotype "<<extend>>" identifies the relationship as an extend
relationship, as shown in Figure 3.5.

Figure 3.5: an example of an extend relationship

Figure 3.5 shows an example of an extend relationship between the "Perform medical tests"
(parent) and "Perform Pathological Tests" (child) us-cases. The "Perform Pathological Tests" use
case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform
Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use
case.
 Generalizations: A generalization relationship is also a parent-child relationship between use
cases. The child use case in the generalization relationship has the underlying business process
meaning, but is an enhancement of the parent use case. In a use case diagram, generalization is
shown as a directed arrow with a triangle arrowhead (see Figure 3.6). The child use case is
connected at the base of the arrow. The tip of the arrow is connected to the parent use case.

Figure 3.6: an example of a generalization relationship

On the face of it, both generalizations and extends appear to be more or less similar. But there is a
subtle difference between a generalization relationship and an extend relationship. When you
establish a generalization relationship between use cases, this implies that the parent use case can
be replaced by the child use case without breaking the business flow. On the other hand, an
extend relationship between use cases implies that the child use case enhances the functionality of
the parent use case into a specialized functionality. The parent use case in an extend relationship
cannot be replaced by the child use case.

Let us see if we understand things better with an example. From the diagram of a generalization
relationship (refer to Figure 3.6), you can see that "Store patient records (paper file)" (parent) use
case is depicted as a generalized version of the "Store patient records (computerized file)" (child)
use case. Defining a generalization relationship between the two implies that you can replace any
occurrence of the "Store patient records (paper file)" use case in the business flow of your system
with the "Store patient records (computerized file)" use case without impacting any business flow.
This would mean that in future you might choose to store patient records in a computerized file
instead of as paper documents without impacting other business actions.

Now, if we had defined this as an extend relationship between the two use cases, this would imply
that the "Store patient records (computerized file)" use case is a specialized version of the "Store
patient records (paper file)" use case. Hence, you would not be able to seamlessly replace the
occurrence of the "Store patient records (paper file)" use case with the "Store patient records
(computerized file)" use case.
 CLASS DIAGRAM

The steps you would take would be:

• Identify the main members of the family

• Determine how they are related to each other
• Identify the characteristics of each family member
• Find relations among family members
• Decide the inheritance of personal traits and characters

A class diagram is similar to a family tree. A class diagram consists of a group of classes and
interfaces reflecting important entities of the business domain of the system being modeled, and
the relationships between these classes and interfaces. The classes and interfaces in the diagram
represent the members of a family tree and the relationships between the classes are analogous to
relationships between members in a family tree. Interestingly, classes in a class diagram are
interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or
matriarch of the family, as the case may be) and related child classes under the parent classes.

Similarly, a software application is comprised of classes and a diagram depicting the relationship
between each of these classes would be the class diagram.

By definition, a class diagram is a diagram showing a collection of classes and interfaces, along
with the collaborations and relationships among classes and interfaces.

A class diagram is a pictorial representation of the detailed system design. Design experts who
understand the rules of modeling and designing systems design the system's class diagrams. A
thing to remember is that a class diagram is a static view of a system. The structure of a system is
represented using class diagrams. Class diagrams are referenced time and again by the developers
while implementing the system.

Now you now know what a class diagram is. But, how does a class diagram relate to the use case
diagrams that you read about in the earlier article? When you designed the use cases, you must
have realized that the use cases talk about "what are the requirements" of a system. The aim of
designing classes is to convert this "what" to a "how" for each requirement. Each use case is
further analyzed and broken up into atomic components that form the basis for the classes that
need to be designed.

However, besides use cases, the artifacts of a project, such as stakeholder requests, (signed off)
requirement documents, functional specifications, and a glossary of terms for the project serve as
other important inputs to the discovery of classes.

We will now see what the components of a class diagram are, and how to create a class diagram.
Elements of a Class Diagram
A class diagram is composed primarily of the following elements that represent the system's
business entities:

• Class: A class represents an entity of a given system that provides an encapsulated

implementation of certain functionality of a given entity. These are exposed by the class to
other classes as methods. Apart from business functionality, a class also has properties that
reflect unique features of a class. The properties of a class are called attributes. Simply put,
individual members of a family of our family tree example are analogous to classes in a
class diagram.

As an example, let us take a class named Student. A Student class represents student
entities in a system. The Student class encapsulates student information such as student id
#, student name, and so forth. Student id, student name, and so on are the attributes of the
Student class. The Student class also exposes functionality to other classes by using
methods such as getStudentName(), getStudentId(), and the like. Let us take a look at how
a class is represented in a class diagram.

A class is represented by a rectangle. The following diagram shows a typical class in a

class diagram:

Figure 4.1.1—the structure of a class

If you are familiar with object-oriented concepts, you will be aware of the concept of
access modifiers. You can apply access modifiers such as public access, protected access,
and private access applied to methods and attributes of a class—even to a class as well, if
required. These access modifiers determine the scope of visibility of the class and its
methods and attributes.

You also can add documentation information to a class. Notes and constraints can be
added to a list of attributes. Notes contain additional information for reference while
developing the system, whereas constraints are the business rules that the class must
follow, and are text included in curly brace brackets.
During the early phase of the system design conception, classes called Analysis classes are
created. Analysis classes are also called stereotypes. In the UML context, stereotypes are
UML models that that represent an existing UML element, while showing additional
characteristics that are common across the classes to be used for that application. Only one
stereotype can be created for any UML element in the same system.

Analysis classes are of the following types as per their behavior, as shown in the following
table:

Class Behavior

Boundary In an ideal multi tier system, the user interacts only with the boundary classes. For
example, JSPs in a typical MVC architecture form the boundary classes.

Control These classes typically don't contain any business functionality. However, their
main task is to transfer control to the appropriate business logic class, depending on
a few inputs received from the boundary classes.

Entity These classes are those that contain the business functionality. Any interactions
with back-end systems are generally done through these classes.

• Interface: An interface is a variation of a class. As we saw from the previous point, a

class provides an encapsulated implementation of certain business functionality of a
system. An interface on the other hand provides only a definition of business functionality
of a system. A separate class implements the actual business functionality.

So, why would a class not suffice? You can define an abstract class that declares business
functionality as abstract methods. A child class can provide the actual implementation of
the business functionality. The problem with such an approach is that your design elements
get tied together in a hierarchy of classes. So, even though you may not have intended to
connect your design elements representing drastically different business entities, that is
what might result. Hence, the use of the interface design construct in class diagrams.
Different classes belonging to different and discrete hierarchies can maintain their distinct
hierarchies and still realize the functionality defined in the methods of the interface.

An interface shares the same features as a class; in other words, it contains attributes and
methods. The only difference is that that the methods are only declared in the interface and
will be implemented by the class implementing the interface.

In addition to the above, there is one more element used in class diagrams:
 • Package: A package provides the ability to group together classes and/or interfaces that
are either similar in nature or related. Grouping these design elements in a package
element provides for better readability of class diagrams, especially complex class
diagrams.

Figure 4.1.2—a package

From Figure 4.1.2, you can see a package is represented as a tabbed folder. A package can
also have relationships with other packages similar to relationships between classes and
interfaces.

Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the
relationship between them. The following table shows the kinds of relationships between classes,
their notation, and what they mean.

Sr. Relation Symbol Description

No.

1 Association When two classes are

connected to each other in
any way, an association
relation is established. For
example: A "student studies
in a college" association can
be shown as:

1 a. Multiplicity An example of this kind of

association is many students
belonging to the same
college. Hence, the relation
shows a star sign near the
student class (one to many,
many to many, and so forth
kind of relations).
1 b. Directed Association Association between classes
is bi-directional by default.
You can define the flow of
the association by using a
directed association. The
arrowhead identifies the
container-contained
relationship.

1 c. Reflexive Association No separate symbol. However, An example of this kind of

the relation will point back at the relation is when a class has a
same class. variety of responsibilities. For
example, an employee of a
college can be a professor, a
housekeeper, or an
administrative assistant.

2 Aggregation When a class is formed as a

collection of other classes, it
is called an aggregation
relationship between these
classes. It is also called a "has
a" relationship.

2 a. Composition Composition is a variation of

the aggregation relationship.
Composition connotes that a
strong life cycle is associated
between the classes.

3 Inheritance/Generalization Also called an "is a"

relationship, because the child
class is a type of the parent
class. Generalization is the
basic type of relationship
used to define reusable
elements in the class diagram.
Literally, the child classes
"inherit" the common
functionality defined in the
parent class.
4 Realization In a realization relationship,
one entity (normally an
interface) defines a set of
functionalities as a contract
and the other entity (normally
a class) "realizes" the contract
by implementing the
functionality defined in the
contract.

OBJECT DIAGRAM

Although we design and define classes, in a live application classes are not directly used, but
instances or objects of these classes are used for executing the business logic. A pictorial
representation of the relationships between these instantiated classes at any point of time (called
objects) is called an "Object diagram." It looks very similar to a class diagram, and uses the
similar notations to denote relationships.

If an object diagram and a class diagram look so similar, what is an object diagram actually used
for? Well, if you looked at a class diagram, you would not get the picture of how these classes
interact with each other at runtime, and in the actual system, how the objects created at runtime
are related to the classes. An object diagram shows this relation between the instantiated classes
and the defined class, and the relation between these objects, in the logical view of the system.
These are very useful to explain smaller portions of your system, when your system class diagram
is very complex, and also sometimes recursive.

Let us now see what the components of an object diagram are. After this, we will build an object
diagram for our case study—Courseware Management system.

Elements of an Object Diagram

Because an object diagram shows how specific instances of a class are linked to each other at
runtime, at any moment in time it consists of the same elements as a class diagram; in other
words, it contains classes and links showing the relationships. However, there is one minor
difference. The class diagram shows a class with attributes and methods declared. However, in
an object diagram, these attributes and method parameters are allocated values.
As an example, in the last article, a class diagram for a multiplicity relation between college and
students was shown, as you cam see in Figure 5.1:

Figure 5.1—an example College-Student class diagram

This class diagram shows that many students can study in a single college. Now, if we were to
add attributes to the classes "College" and "Student," we would have a diagram as shown in
Figure 5.2:
Figure 5.2—the class diagram with attributes

Now, when an application with the class diagram as shown above is run, instances of College and
Student class will be created, with values of the attributes initialized. The object diagram for such
a scenario will be represented as shown in Figure 5.3:

Click here for a larger image.

Figure 5.3—the object diagram for the College-Student class diagram

As can be seen from Figure 5.3, the object diagram shows how objects are instantiated in the
running system represented by the College-Student class diagram. The class diagram shows that a
single college has many students, and defines the variables. The object diagram for the same
system shows instantiated classes of Student (Student #1 and Student #2) enrolled in College
(Graduate School of Business).

The object diagram shows the name of the instantiated object, separated from the class name by a
":", and underlined, to show an instantiation.
Eg. Graduate School of Business: College

In the diagram, values are assigned to variables and represented using the notation variable
name=variable value.

This example was the representation of the relation of only two classes with each other. However,
in a real application system, there will be multiple classes. An object diagram then shows the
relation between the instantiations of these classes. We shall see this in our case study.
A class that defines the flow of the system is called as an active class. This class instance in the
object diagram is represented by thick border. In an MVC application architecture, the controller
servlet is the action class, and is denoted by a thicker border. Also, multiple instances of the same
class, as in a factory pattern, if the attributes of the individual objects are not important, or are not
different, these can be represented by a single symbol of overlapping rectangles (see Figure 5.4):

Figure 5.4—the object diagram for a Factory class

A class that performs more than one role, and is self-linked, is represented by a curve starting and
ending on itself, as illustrated in Figure 5.5:

Figure 5.5—the object diagram for a self-linked class

Activity Diagram

Basics
The easiest way to visualize an Activity diagram is to think of a flowchart of a code. 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

Let us 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 Symbol

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

Let us 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.

Swim Lanes
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, we 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, we 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.
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

SEQUENCE DIAGRAM

Basics
A Sequence diagram depicts the sequence of actions that occur in a system. The invocation of
methods in each object, and the order in which the invocation occurs is captured in a Sequence
diagram. This makes the Sequence diagram a very useful tool to easily represent the dynamic
behavior of a system.

A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows the life of the
object that it represents, while on the vertical axis, it shows the sequence of the creation or
invocation of these objects. Because it uses class name and object name references, the Sequence
diagram is very useful in elaborating and detailing the dynamic design and the sequence and
origin of invocation of objects. Hence, the Sequence diagram is one of the most widely used
dynamic diagrams in UML.
Defining a Sequence diagram
A sequence diagram is made up of objects and messages. Objects are represented exactly how
they have been represented in all UML diagrams—as rectangles with the underlined class name
within the rectangle. A skeleton sequence diagram is shown in Figure 8.1. We shall discuss each
of these elements in the next section:

Figure 8.1: Sample Sequence diagram, showing the general elements of a sequence diagram

An object can call itself recursively. An arrow commencing and ending at itself denotes this.

Defining a Sequence diagram

Let us take a look at the building blocks of a Sequence diagram.

Elements of a Sequence diagram

A Sequence diagram consists of the following behavioral elements:

Element and its description Symbol

Object: The primary element involved in a sequence diagram is an

Object—an instance of a class. A Sequence diagram consists of
sequences of interaction among different objects over a period of
time. An object is represented by a named rectangle. The name to the
left of the ":" is the object name and to its right is the class name.

Message: The interaction between different objects in a sequence

diagram is represented as messages. A message is denoted by a
directed arrow. Depending on the type of message, the notation
differs. In a Sequence diagram, you can represent simple messages,
special messages to create or destroy objects, and message responses.
Case Study—Courseware Management System
From the discussion in the previous section, we are clear on the different notations that are used in
Sequence diagrams. Armed with this knowledge, we will proceed to design a Sequence diagram
for our Courseware Management System case study application. Because a Sequence diagram
represents the dynamic flows in an application, we will aim to represent one of the flows using a
Sequence diagram. 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

For these use cases, we had modeled the classes and interfaces using the class diagram in Article
4 (parts 1 and 2). Now, we will combine the flow defined by the use cases and the classes
involved in the use cases together to represent the different flows in the Courseware Management
System.

As an example, we will represent the "Manage course information" flow using a Sequence
diagram.

Identifying the activities and transitions for managing course information

The "Manage course information" flow contains one participant: the Course Administrator. Apart
from this, there are a few entities with which the course administrator interacts in this flow—
Course, Topic, and Tutor. The sequence of steps carried out in the "Manage course information"
flow are:

• A user who is a course administrator invokes the manage course functionality.

• The manage course functionality of the course administrator invokes either the course
creation or course modification functionality of a course.
• After the course is either created or modified, the manage topic functionality of the
course administrator calls the topic creation or modification functionality of a topic.
• Finally, the user invokes the assign tutor to course functionality of the course
administrator to assign a tutor to the selected course.

Now, let us model these steps into a Sequence diagram for the "Manage course information"
functionality.

Sequence diagram
 COLLABERATION DIAGRAM
Basics
In the previous article, we covered the basics of a Sequence diagram. A Sequence diagram is
dynamic, and, more importantly, is time ordered. A Collaboration diagram is very similar to a
Sequence diagram in the purpose it achieves; in other words, it shows the dynamic interaction of
the objects in a system. A distinguishing feature of a Collaboration diagram is that it shows the
objects and their association with other objects in the system apart from how they interact with
each other. The association between objects is not represented in a Sequence diagram.

A Collaboration diagram is easily represented by modeling objects in a system and representing

the associations between the objects as links. The interaction between the objects is denoted by
arrows. To identify the sequence of invocation of these objects, a number is placed next to each of
these arrows.

Defining a Collaboration diagram

A sophisticated modeling tool can easily convert a collaboration diagram into a sequence diagram
and the vice versa. Hence, the elements of a Collaboration diagram are essentially the same as
that of a Sequence diagram.

Let us see in detail what the elements of Collaboration diagram are.

Elements of a Collaboration diagram

A Collaboration diagram consists of the following elements:
Element and its description Symbol

Object: The objects interacting with each other in the system. Depicted
by a rectangle with the name of the object in it, preceded by a colon and
underlined.

Relation/Association: A link connecting the associated objects.

Qualifiers can be placed on either end of the association to depict
cardinality.

Messages: An arrow pointing from the commencing object to the

destination object shows the interaction between the objects. The number
represents the order/sequence of this interaction.

Component Diagram

Basics
The different high-level reusable parts of a system are represented in a Component diagram. A
component is one such constituent part of a system. In addition to representing the high-level
parts, the Component diagram also captures the inter-relationships between these parts.
So, how are component diagrams different from the previous UML diagrams that we have seen?
The primary difference is that Component diagrams represent the implementation perspective of a
system. Hence, components in a Component diagram reflect grouping of the different design
elements of a system, for example, classes of the system.

Let us briefly understand what criteria to apply to model a component. First and foremost, a
component should be substitutable as is. Secondly, a component must provide an interface to
enable other components to interact and use the services provided by the component. So, why
would not a design element like an interface suffice? An interface provides only the service but
not the implementation. Implementation is normally provided by a class that implements the
interface. In complex systems, the physical implementation of a defined service is provided by a
group of classes rather than a single class. A component is an easy way to represent the grouping
together of such implementation classes.

You can model different types of components based on their use and applicability in a system.
Components that you can model in a system can be simple executable components or library
components that represent system and application libraries used in a system. You also can have
file components that represent the source code files of an application or document files that
represent, for example, the user interface files such as HTML or JSP files. Finally, you can use
components to represent even the database tables of a system as well!

Now that we understand the concepts of a component in a Component diagram, let us see what
notations to use to draw a Component diagram.

Elements of a Component Diagram

A Component diagram consists of the following elements:

Element and its description Symbol

Component: The objects interacting with each other in the system.

Depicted by a rectangle with the name of the object in it, preceded by
a colon and underlined.

Class/Interface/Object: Similar to the notations used in class and

object diagrams

Relation/Association: Similar to the relation/association used in

class diagrams

Case Study—Courseware Management System

From our above discussion of the Component diagram, we will apply the criteria for identifying
components to the Courseware Management System. In the first instance, the application may
seem to be too simplistic to contain components. But wait! The Courseware Management System
has its own share of components, some implicit in the design.

Before we move to identifying the components, let us recap a quick discussion that we had
regarding the Model View Controller architecture in the UML Class Diagram Part II article. In
this article we had mentioned that the different classes in the class diagram can be partitioned
along the lines of the three layers of this architecture viz. Model, View, and Controller. This
partitioning of the different classes of the application poses its own challenges, the primary one
being how do the classes in one layer interact with the classes in the other layers. Let us elaborate
this by reviewing the classes in the Courseware Management System.

Identifying Components in the Courseware Management System

The different classes that we have modeled for the Courseware Management System, such as
CourseAdministrator, Course, Topic, CourseCalendar, and Student that fall in the Model layer
need to provide a consistent interface to enable other classes and components to interact with
them and utilize their services. We can as well define our own set of simple interface methods to
access these services. But, to enable our application components to be used by external
applications, we can consider basing the components on well-defined component standards.

Hence, based on the technology that you use, you would model these as, maybe Enterprise
JavaBeans (EJBs) or Component Object Model/Distributed Component Object Model
(COM/DCOM) components. EJB and COM/DCOM are nothing but industry-standard component
models that you can base your application component design on. This becomes the "physical"
implementation of the logical class diagram. An added advantage of basing your application
components on these component models is that your components become "reusable!"

So, if we had introduced a controller class for the application named CMSController, it would
interact with the components in the Model layer via the EJB or the COM/DCOM interfaces.

Based on this, let us now draw the components in the Model layer for the Courseware
Management System.

Component Diagram
Click here for a larger image.

Figure 2 Component diagram for the Courseware Management System

Figure 2 shows the Component diagram for the Model layer of the Courseware Management
System. The diagram shows the different components, such as CourseAdministrator, Course,
Topic, Tutor, and so forth in the Model layer and how the Controller layer component interacts
with these components. The diagram also depicts a database access component that represents a
library component that the Model layer components will use to interact with a database.

DEPLOYMENT DIAGRAM
Basics
After all the UML diagrams that we have seen till now, you might groan—one more UML
diagram? Well, until now we have discussed UML diagrams that cover the application side in
terms of both static and dynamic behavior. The component diagram that we covered in the
previous article still focused on the representation of the physical implementation of the
application components that perform and provide required functionality. The deployment diagram
provides a different perspective of the application. The deployment diagram captures the
configuration of the runtime elements of the application.

This diagram is by far more useful when a system is built and ready to be deployed. But, this does
not mean that you should start on your deployment diagram after your system is built. On the
contrary, your deployment diagram should start from the time your static design is being
formalized using, say, class diagrams. This deployment diagram then evolves and is revised until
the system is built. It is always a best practice to have visibility of what your deployment
environment is going to be before the system is built so that any deployment-related issues are
identified to be resolved and not crop up at the last minute. The general rule of thumb is that
correction costs due to changes increase as the project nears completion.

So, how are deployment diagrams and component diagrams related? Essentially, the components
in a component diagram are contained in the deployment diagram elements. Hence, while
components provide the application functionality, the deployment diagram elements provide the
necessary environment for the components to execute in.

The basic deployment diagram element is the node. The node represents the environment in
which a component or a set of components execute. This means that a node in a deployment
diagram can represent a multitude of things—physical hardware such as a server machine, a
system software like an operating system, or even application infrastructure software like a Web
server, application server, database server, and so forth. The different nodes in the deployment
diagram can be interconnected to represent interdependencies, thus providing a deployment
diagram that is easy to comprehend and provides the complete deployment environment of a
system.

Now that we understand the concepts of a component in a component diagram, let us see what
notations to use to draw a component diagram.

Elements of a Deployment Diagram

A deployment diagram consists of the following elements:

Element and its description Symbol

Node: The element that provides the execution environment for the
components of a system. Depicted by a cube with the name of the
object in it, preceded by a colon, and underlined.

Connection: Similar to the relation/association used in class

diagrams to define the interconnection between nodes.

Identifying deployment elements in the Courseware Management System

Since components of the Courseware Management System will be the primary elements
represented in the deployment diagram, we will add the components from the component diagram
(discussed in the previous article) to the deployment diagram. These components are:

• View
• Controller
 • Model
• Database Access

The next step is to identify the deployment environment for the Courseware Management System.
A good deployment environment is normally well partitioned to ensure that the application
components have proper resources in their execution environment. Hence, we will define the
nodes of our deployment environment as follows:

• Web Server—This node represents the Web server that will receive user requests and
send responses from the application.
• Application Server—The application server node that will process user requests from the
Web server and send application responses back to the Web server is represented by this
node. The application server node will host the different components of the Courseware
Management System, such as View, Controller, Model, and Database Access.
• Database Server—The database server node will host the database server used by the
components in the application server node to store and retrieve the data used by the
Courseware Management System.

Notice that the nodes that we have listed above were not referred at all until this point in the
article series. This is because these are implementation level details—exactly the stuff you should
avoid considering when you work on the design of the application.

The different modeling diagrams that make up your application design must not have any
dependencies on or references to the deployment environment.

These extra implementation elements that we have introduced are standard for a multi-tier Web
application architecture. Let us see how this is so.

If, for example, the same Courseware Management System application were to deployed on, say,
a deployment environment consisting of, say, Apache Web Server, BEA WebLogic application
server, and Oracle database server, the deployment diagram would hold true. Now, if we want to
replace BEA WebLogic application server with, say, IBM Websphere, neither the UML models
(static and dynamic) nor the deployment diagram will change.

On the other hand, if we now wanted to make this a client/server application, the changes will be
required only to the deployment diagram by removing the Web server node and changing the
deployment environment to something more suited for a client/server software environment. The
components that run in this deployment environment will have none to minimal changes. This in
effect demonstrates the clean separation of deployment diagram from the other UML diagrams
and demonstrates the robustness of the application's design.
Now that we have an idea of the nodes that will make up the deployment diagram and the
components in each of these nodes, we are ready to draw the deployment diagram using our UML
modeling tool.

Deployment Diagram

Click here for a larger image.

Figure 2 Deployment diagram for the Courseware Management System

Figure 2 shows the Deployment diagram for the Courseware Management System. The
deployment diagram shows the three nodes PRD_WEB_SERVER, PRD_APP_SERVER, and
PRD_DB_SERVER that represent the nodes for the Web server, application server, and database
server, respectively. The View, Controller, and Model components are depicted in the application
server node and the three nodes are interconnected to denote association between them in the
Courseware Management System.