UML Reference Document HCL Technologies Ltd – Gurgaon

USECASE DIAGRAM

1. BASICS

Before we start off today's article, let us revisit the definition of use a case diagram,
as described in the first article.

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.

1.1.1 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 an entity) 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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

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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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.

1.1.2 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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) use 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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.

1.1.3 WRITING A USE CASE SPECIFICATION

A use case diagram, as we have seen, is a visual depiction of the different scenarios
of interaction between an actor and a use case. The usefulness of use case diagrams
is more as a tool of communication between the requirements capture team and the
user group. The next step after finalizing of use case diagrams is to document the
business functionality into clear-cut and detailed use case specifications. Because use
cases are used as an input to the other project phases such as design, development,
and testing, we need to ensure that the visual depiction of the business requirements
is translated into clear and well-defined requirements in the form of use case
specifications. Elaborate use case specifications are used as an input for design and
development and for writing test cases (unit, system, and regression tests, as the
case may be).

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

A use case specification document should enable us to easily document the business
flow. Information that you document in a use case specification includes what actors
are involved, the steps that the use case performs, business rules, and so forth. A
use case specification document should cover the following areas:

• Actors: List the actors that interact and participate in this use case.
• Pre-conditions: Pre-conditions that need to be satisfied for the use case to
perform.
• Post-conditions: Define the different states in which you expect the system
to be in, after the use case executes.
• Basic Flow: List the basic events that will occur when this use case is
executed. Include all the primary activities that the use case will perform. Be
fairly descriptive when defining the actions performed by the actor and the
response of the use case to those actions. This description of actions and
responses are your functional requirements. These will form the basis for
writing the test case scenarios for the system.
• Alternative flows: Any subsidiary events that can occur in the use case
should be listed separately. Each such event should be completed in itself to
be listed as an alternative flow. A use case can have as many alternative flows
as required. But remember, if there are too many alternative flows, you need
to revisit your use case design to make it simpler and, if required, break the
use case into smaller discrete units.
• Special Requirements: Business rules for the basic and alternative flows
should be listed as special requirements in the use case narration. These
business rules will also be used for writing test cases. Both success and failure
scenarios should be described here.
• Use case relationships: For complex systems, it is recommended that you
document the relationships between use cases. If this use case extends from
other use cases or includes the functionality of other use cases, these
relationships should be listed here. Listing the relationships between use
cases also provides a mechanism for traceability.

1.1.4 DOS AND DON'TS

Use cases should not be used to capture all the details of a system. The granularity
to which you define use cases in a diagram should be enough to keep the use case
diagram uncluttered and readable, yet, be complete without missing significant
aspects of the required functionality. You will encounter such decision points of the
level of granularity that you need to define when you build any of the UML diagrams.

An important rule that gets forgotten during use creation is the creeping in of design
issues. Use cases are meant to capture "what" the system is, not "how" the system
will be designed or built. Use cases should be free of any design characteristics. If
you end up defining design characteristics in a use case, you need to go back to the
drawing board and start again.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.5 CASE STUDY—COURSEWARE MANAGEMENT SYSTEM

Use case modeling, as we have learnt today, involves analyzing the problem
statement to determine the business processes of the system. We will now design
the use case model for the Courseware Management System case study.

Note: In case you need to revisit the problem statement of the Courseware
Management System described in Article 2, click here.

Let us analyze the problem statement to identify the potential actors and use cases
of the system. First, let us list the potential actors. A quick look at the problem
statement shows up the following terms and entities specific to the system:

• Courses and Topics that make up a course

• Tutors who teach courses
• Course administrators who mange the assignment of the courses to tutors
• Calendar or Course Schedule is generated as a result of the
• Students who refer to the Course schedule or Calendar to decide which
courses they wish to take up for study

IDENTIFYING ACTORS OF THE COURSEWARE MANAGEMENT SYSTEM

Out of the preceding list, one thing is clear. There are certain terms and entities in
the list that identify that they perform certain roles or business processes. We will
discuss what these business processes are after we complete our analysis for
identifying actors. For now, we focus on identifying the actors in the system. From
the preceding list, we can see that there are some entities that perform an action
and some that form the target for the action. The entities that perform action will be
the actors for the Courseware Management System. In the above list, the actors that
we can identify are:

• Tutors
• Course administrators
• Students

But, because students are not the potential active participants for this system, we
will drop them from the list of actors. Similarly, tutors are not active participants
from our system's perspective, and hence, we will exclude tutors from our list if
roles. Yet, we will still record them in our use case model since we do not wish to
lose this business information. Our final list of primary actors has now come down to
only one:

• Course administrators

IDENTIFYING USE CASES OF THE COURSEWARE MANAGEMENT SYSTEM

Next, let us identify the potential business processes in the Courseware Management
System. The primary business flows in the system are:

• Manage courses

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

• Manage course assignments

As we analyze the problem statement further, we can determine some discrete

processes within these primary business flows. To manage courses, the actor needs
to have the ability to view existing courses, manage the course information for a
course, such as duration and so forth, and also manage the addition or removal of
topics for a course. So, within the "Manage courses" use case, we can identify the
following sub processes:

• View courses
• Manage topics for a course
• Manage course information

And similarly, the "Manage course assignment" use case can be refined into smaller
discrete processes such as viewing the course calendar, viewing tutors, managing the
tutor information of tutors working for the organization, and of course, assigning
courses to tutors. Now, the use cases that we have identified within the "Manage
course assignment" use case are:

• View course calendar

• View tutors
• Manage tutor information
• Assign courses to tutors

Our final list of use cases for the courseware management system will now be:

• View courses
• Manage topics for a course
• Manage course information
• View course calendar
• View tutors
• Manage tutor information
• Assign courses to tutors

If you were analyzing a sentence in English, the subject in the sentence can be
identified as a potential actor and the verb part of the sentence can be a potential use
case. Remember, this may or may not apply to the problem at hand, but is a good
starting point for use case modeling.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

USE CASE DIAGRAM

Figure 3.8: the use case diagram for the Courseware Management System

We have completed identifying potential use cases and actors. Take a look at the use
case diagram for the Courseware Management System in Figure 3.7. The use case
diagram of the Courseware Management System includes all the actors and use
cases that we identified during our analysis of the problem statement.

1.1.6 SUMMARY

Use case diagrams were the starting point of our journey in exploring each of the
UML diagrams. Business functionality can be quickly represented in a simple and
lucid fashion by using use case diagrams. Once the groundwork for depicting use
cases is completed, the next step, as we learnt today, is writing detailed use case
scenarios that will be used as the base functional requirements for the system. Our
exercise in defining the use case diagram for the Courseware Management System
case study was useful and enabled us to get a hands-on experience in applying what
we learnt today.

In the coming article, we will study the next UML diagram—the Class diagram

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

2. CLASS DIAGRAM

1.1.7 BASICS

So, what is a class diagram? Imagine you were given a task of drawing a family tree.
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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

We will now see what the components of a class diagram are, and how to create a
class diagram.

1.1.8 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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:

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

• 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.

1.1.9 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).

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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
the relation will point back at kind of relation is
the same class. when a class has a
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

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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.

1.1.10A FEW TERMS

Here are a few terms that we will be using to annotate our class diagrams. You
should be familiar with them:

1. Responsibility of a class: It is the statement defining what the class is

expected to provide.
2. Stereotypes: It is an extension of the existing UML elements; it allows you to
define new elements modeled on the existing UML elements. Only one
stereotype per element in a system is allowed.
3. Vocabulary: The scope of a system is defined as its vocabulary.
4. Analysis class: It is a kind of a stereotype.
5. Boundary class: This is the first type of an analysis class. In a system
consisting of a boundary class, the users interact with the system through the
boundary classes.
6. Control class: This is the second type of an analysis class. A control class
typically does not perform any business functions, but only redirects to the
appropriate business function class depending on the function requested by
the boundary class or the user.
7. Entity class: This is the third type of an analysis class. An entity class consists
of all the business logic and interactions with databases.
1.1.11CREATING A CLASS DIAGRAM

Class diagrams can be modeled by using any UML tool that supports class diagrams.
We will be using the Poseidon Community Edition tool to draw the class diagram. You
can use any tool that you are comfortable with.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

The screen shot of the Poseidon tool in Figure 4.1.3 shows the different options to
model class diagrams and establish relationships among the packages, classes, and
interfaces.

Some additional features that you can check in your modeling tool are:

• Support for forward and reverse engineering for class diagrams. A few
sophisticated modeling tools also integrate with standard IDEs with support
for round-trip engineering.
• Documentation and report generation features
1.1.12DOS AND DON'TS

Classes in a class diagram should be descriptive and must be named after business
entities. Using business entities as names ensures greater readability of class
diagrams.

Relationships between classes may not be apparent in the first iteration. Revise and
refine your class diagrams to determine possible relationships during each iteration.

Designing is an incremental process and class diagrams are updated as the system
gets built. Hence, do not try to capture and freeze the class diagrams of a system in
the first pass.

1.1.13SUMMARY

Class diagrams are the basic building block used to define the design of a system.
Today, we learned about the elements of a class diagram—classes, interfaces, and
packages—and the different types of relationships among these elements such as
association, aggregation, composition, generalization, and realization.

In the next part in this article, we will take up a practical example, the Courseware
Management system, and create the class diagrams for the system.

1.1.14INTRODUCTION

In the last article of this series, we saw what class diagrams were, and how to create
class diagrams. In today's article, we will see a practical example building on our
Courseware Management system case study.

1.1.15CASE STUDY—COURSEWARE MANAGEMENT SYSTEM

The class diagram of our Courseware Management System case study can be built
after a careful analysis of the requirements. In the previous article, we identified the
primary actors and use cases in the use case model of the case study. Because we
did much of the groundwork of our analysis while building the use case model, we
will use those analysis steps as the basis for identifying the classes and interfaces of
this system.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Let us recap our analysis that we had performed when we designed the use case
model. The following terms and entities specific to the system were identified from
the problem statement:

• Courses and Topics that make up a course

• Tutors who teach courses
• Course administrators who mange the assignment of the courses to tutors
• Calendar or Course Schedule is generated as a result of the
• Students who refer to the Course schedule or Calendar to decide which
courses for which they wish to sign up

The potential actors of the system were:

• Tutors
• Course administrators
• Students

And the use cases of the system were:

• View courses
• Manage topics for a course
• Manage course information
• View course calendar
• View tutors
• Manage tutor information
• Assign courses to tutors
1.1.15.1IDENTIFYING CLASSES OF THE COURSEWARE MANAGEMENT SYSTEM

As we did in use case modeling, we will identify the classes and interfaces using an
incremental approach.

1. Identify the "active" entities in the system

The basic rule that we learned until now for identifying classes and interfaces
is that classes and interfaces reflect important entities of the business domain
of the system being modeled. We will apply this rule to determine classes and
interfaces of the case study system. At first glance, the actors identified in the
use case appear to be prime candidates for being listed as potential classes.
Even though we had excluded Students and Tutors from our final list of
actors, we will still include them in our list as potential classes. So, our first
list of classes in the system appears to be:

o Course administrators
o Tutors
o Students
2. Identify business domain ("passive") entities in the system

But these are the "active" entities of the system. We had also identified
"passive" elements in the system as well in the analysis for our use case

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

model. These entities reflect the business domain and hence are potential
classes for our system.

o Courses
o Topics that make up a course
o Course calendar generated

Entities that reflect the business terms are also called business domain classes
or just "domain classes." Some of the business domain classes hold transient
data and some hold persistent data for the application. Normally, such business
domain classes map to either one or many database tables.

For example, in our case study, the Course class can be modeled as a database
table cms_course. The data in this table for a particular course will be
represented by an instance of the Course class and made available to the rest
of the application.

Our two-step process has definitely yielded promising results! We have

covered all the relevant items in our analysis. So, let us list the list of classes
and interfaces that we have identified in the Courseware Management
System.

o CourseAdministrator
o Tutor
o Student
o Course
o Topic
o CourseCalendar

3. Categorize and map the use cases and any relevant business functionality to
either the passive or active entities. These will become the business methods
of the classes in the system.

Classes encapsulate functionality. The classes that we have identified for the
Courseware Management System also provide business functionality related
to the application. The functionality encapsulated by these classes is distinct
in nature and differs from each class. Recall from our use case model, that,
along with actors, we had identified a set of use cases that the actors
interacted with. Let us try to associate them with our classes. Because our
primary actor is the course administrator and the use cases were related to
this actor, we can directly map the use cases to the CourseAdministrator
class as methods.

ClassName Methods
CourseAdministrator viewCourses()
manageCourse()

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

manageTopic()
viewCourseCalendar()
viewTutors()
manageTutorInformation()
assignTutorToCourse()

In addition to this, we also can determine some implicit functionality of classes that
reflect business entities. For example, what functionality should the Course class
provide? Intuitively, we would define the Course class to provide functionality to view
all courses in the system, ability to create new courses or modify information of
existing courses, view the details of a particular course, or even remove a course
from the system. We expect the Course class to provide such business functionality
because the Course class reflects a business entity in the system. Hence, these
become the methods exposed by the Course class. So, we can now refine the class
diagram and add methods to each of these classes.

To cut a long story short, each of the classes that reflect business entities will provide
similar implicit business functionality. Let us list all such "implicit" functionality for
each of these classes.

ClassName Methods
Course viewAllCourses()
viewCourseInformation()
createCourse()
modifyCourse()
removeCourse()
Topic viewAllTopics()
viewTopicInformation()
createTopic()
modifyTopic()
removeTopic()
Tutor viewTutorInformation()
createTutor()
modifyTutor()
removeTutor()
CourseCalendar viewCourseCalendar()
Student viewAllStudents()
viewStudentInformation()

Refine and revise the list of classes and interfaces

Revisit the class diagram and revise it by identifying shared features and/or common
functionality between classes or interfaces. These will translate into reusable pieces
of code for your system. To some extent, we can say that CourseAdministrator,
Tutor, and Student are essentially users of the system. Hence, we can define a
shared parent class named User and define basic functionality like for example,
authentication, in the User class that can be inherited by the CourseAdministrator,

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Tutor, and Student classes. It is left to the design expertise to identify reusable
classes/functionality.

This completes our analysis of the problem statement to define the classes for the
Courseware Management System.

1.1.15.2IDENTIFYING RELATIONSHIPS BETWEEN THE CLASSES OF THE COURSEWARE

MANAGEMENT SYSTEM

The next step after defining the classes of the Courseware Management System is to
define the relationships and dependencies between these classes and interfaces. To
define the relationships between the classes, we need to analyze the
interconnections between the classes—whether implicit or explicit. Relationship
analysis can be broken up into three steps:

1. Identify relationships between "active" entities

Active entities normally share generalization relationships ("is-a"). Essentially,

the common attributes and functionality between classes are defined in a
common parent class. All the related child classes inherit functionality from
the parent class. Apart from generalization, a few active entities can also be
interconnected by a realization relationship. Recall that elements in a
realization relationship implement declared functionality as a "contract." For
example, a set of classes may implement functionality declared as methods in
an interface, and this can be modeled as a realization relationship between
the interface and the classes implementing the interface.

In our case study, we do not find an example of inheritance relationship

between the active entities such as Student, Tutor, and
CourseAdministrator or any realization relationships.

2. Identify relationships between "passive" business entities

Passive business entities frequently share plain association or aggregation

relationships ("has-a"). This is especially true because these business entities
are non-transactional in nature and reflect data more than behavior. It is by
far quite intuitive to identify aggregation as well as its variations—composition
relationships for passive business entities.

Some of the classes in our case study do exhibit aggregation relationships.

Because a set of topics makes up a course, we can define an aggregation
relationship between the Course and Topic classes. Moreover, we can define
this as a directed aggregation, meaning that you can check for the topics of a
course but not vice versa. Similarly, we can define a plain association
relationship between the Course and Tutor classes and Course and Student
classes.

Identify relationships between "active" and "passive" entities

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Relationships between active and passive entities can easily be represented using
directed association. The directed association, a variation of the "vanilla" association
relationship, provides easy identification of which is the container class and which is
the contained class. The CourseAdministrator class can be modeled to have a
directed association with the Course class. This association can be named as
"manages" because the course administrator manages courses as a business activity.
In addition to this, because the course administrator also manages the tutor
information and topic information, we can model a directed relationship named as
"manages" between the CourseAdministrator and the Course and Topic classes,
respectively. We can enhance the readability of the association between
CourseAdministrator and the Course, Tutor, and Topic classes by defining the
multiplicity for the association—one to many, one to one, many to many, and so
forth.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.15.3CLASS DIAGRAM

Click here for a larger image.

Figure 4.2.1 shows the class diagram for the Courseware Management System

We have completed identifying the classes for the Courseware Management System
and established the relationships among the classes. Take a look at the class diagram
in Figure 4.2.1. The class diagram of the Courseware Management System includes
all the classes and their relationships that we identified during our analysis of the
problem statement.

Model View Controller Design

The class diagram that we designed for the Courseware Management System defined
the basic classes necessary for representing the basic structure of the system. But this
is by no means a complete design if the architecture of your system is to be based on
the Model View Controller (MVC) architecture. Because an MVC model defines clear
separation of classes among the three layers—business, presentation, and flow control
—you need to define additional classes and revise your design to include them. In case
your UML tool does not support explicit partitioning of classes, you can mark classes in
each of the layers using stereotypes such as <<entity>>, <<boundary>>,
<<control>>, and so forth.

For example, in our case study application, we can revise the class diagram to define a
new CMSController class that manages the flow of the application. The model layer

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

primarily consists of classes relevant to the business domain. Next, the classes that we
had defined can be categorized as transactional and persistent classes. The
CourseAdministrator class performs most of the activities in the system. Hence, this
class can be designated as a transaction class of the model layer. Similarly, the
Course, Topic, Tutor, CourseCalendar, and Student classes represent persistent
business data. Hence, these can be categorized as persistent classes of the model
layer. Finally, you can define a set of classes that represent the presentation layer; in
other words, the user interface of the system.
1.1.16FORWARD ENGINEERING FROM CLASS DIAGRAMS

Forward engineering is the process of generating source code (in a specific language)
from a class diagram model. The extent to which a UML class diagram can be used to
generate source code depends upon the limitations of the source code language.
Because UML is pictorial, and can depict a lot of details, these details could be lost in
the code. Hence, before creating a complete class model, it is a good idea to be
aware of the language that is going to be used, to limit the class model accordingly.
Typically, the association relationships between classes are generated as member
variables between the related classes in the source code. Generalization relationships
are generated as inheritance relationships in the source code.

Click here for a larger image.

Figure 4.2.2 shows forward engineering a class diagram

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

The above screenshot shows the source code file generated for the
CourseAdministrator Java source code file as a result of forward engineering the
class diagram of the Courseware Management System case study. You need to check
how forward engineering works in the tool that you use.

1.1.17REVERSE ENGINEERING OF CLASS DIAGRAMS

Obtaining a class model from existing source code is called reverse engineering. This
is generally done when it is required to understand the architecture of an existing
system, either for re-engineering, or for maintenance. Reverse engineering is of
great use especially when trying to figure out the static structure and organization of
a complex system. Typically, classes defined as member variables in the source code
are modeled as association relationships between the classes. Inheritance
relationships in the source code are generated as generalization relationships
between the classes.

Click here for a larger image.

Figure 4.2.3 shows reverse engineering a sample source code file

The above screenshot shows a class diagram generated as a result of reverse

engineering a sample source code file. You need to check how reverse engineering
works in the tool that you use.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.18SUMMARY

In the last article, we saw how class diagrams are the basic building blocks that
define the design of a system. We learned about the elements of a class diagram—
classes, interfaces, and packages—and the different types of relationships among
these elements, such as association, aggregation, composition, generalization, and
realization.

Today, we defined a few steps to identify classes and interfaces of a system from a
problem statement for designing the class diagram for the Courseware Management
System case study.

In the next part in this series, we will study the Object diagram.

1.1.19 CREATING AN OBJECT DIAGRAM IN POSEIDON

In Poseidon, you will find the option to create object diagrams clubbed with the
option to create deployment and component diagrams. Presently, Poseidon does not
support display of attributes and methods in the object diagram; in other words, you
can as of now only define an object of class, its type, and the linked objects. Hence,
for our case study, we will use Microsoft Word to create an object diagram.

The steps for creating an object diagram in Poseidon are as follows:

1. Open your Poseidon project file (the .zargo file) in which you created your
class diagram earlier.
2. Make sure you are viewing your class diagram in the "Package centric,"
"Diagram centric," or "Inheritance centric" modes to view the deployment
diagram. See Figure 5.6.

Click here for a larger image.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Figure 5.6—the creation of an object diagram in Poseidon

3. Click on Create diagram -> Deployment/Object/Component diagram (or

Ctrl+D) in the menu bar above.
4. Click on the object icon (shown in the black circle) in the icon menu bar on
the top, to create an object. See Figure 5.7.
5. Fill in the Name of the Object instantiated, in the properties bar below. Select
the class of which this object is an instance, in the area titled "Type."
6. After creating all the objects, click on the icon for "link" (shown in the red
circle in Figure 5.7) to link the objects. Give the name of the link.
7. In case of our Case study, if we show an object diagram for the
CourseAdministrator managing the Courses scenario, we get a diagram as
shown in Figure 5.7.

Click here for a larger image.

Figure 5.7—the object diagram in Poseidon for the case study

Courseware management system

1.1.20DOS AND DON'TS

1.1.20.1DOS
1. Use the object diagram as a means of debugging the functionality of your
system.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

2. Object diagrams can also be used to check whether the system has been
designed as per the requirements, and behaves how the business
functionality needs the system to respond.
3. Show associations of any kind between objects as linkages (for example, a
single segment joining two objects, without arrows), and not as a dependency
or any other specific type of association. An object diagram only shows the
linkages, but not the type of association.
1.1.20.2DON'TS
1. Avoid representing all the objects of your system in an object diagram.
Because an object diagram represents the state of objects, it can become
quite complex if you try to represent all the objects. Hence, it is always better
to represent the state of objects in certain important/critical flows in your
application using an object diagram. This will keep your object diagram
readable, yet useful enough to capture the state of objects that are
important.
2. Because object diagrams represent the state of objects, forward engineering
of object diagrams does not make sense.

1.1.21CASE STUDY: COURSEWARE MANAGEMENT SYSTEM

Now, we shall create an object diagram for the courseware system. To do this, we
will first build up on our class diagram, and include the possible attributes and define
the parameters of to the classes defined earlier.

We will follow the following convention for the variable names:

Names starting with "s_" are of the String data type
Names starting with "i_" are of the int data type
Names starting with "v_" are of the Vector data type

The following table outlines the attributes, methods, and their return types for each
of the classes:

Class Name Attributes Methods

s_adminId Vector viewCourses()
v_courses Vector manageCourse(s_courseId)
s_courseId Vector manageTopic(s_topicId)
v_tutors Vector viewCourseCalendar(s_courseId)
CourseAdministrator
v_tutorInfo Vector viewTutors()
s_tutorId Vector manageTutorInformation(s_tutorId)
v_topics Boolean assignCourseToTutor(s_courseId,
s_topicId s_tutorId)
s_studentId
Vector viewAllStudents()
Student v_studentInfo
Vector viewStudentInformation(s_studentId)
v_studentList
Tutor s_tutorId Vector viewTutorInformation(s_tutorId)
v_tutorInfo String createTutor(v_tutorInfo)
v_tutorList Boolean modifyTutor(v_newTutorInfo)

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Boolean removeTutor(s_tutorId)
Vector viewAllCourses()
s_courseId Vector viewCourseInfo(s_courseId)
Course v_courseList Boolean createCourse(v_courseInfo)
v_courseInfo Boolean modifyCourse(v_newCourseInfo)
Boolean removeCourse(s_courseId)
Vector viewAllTopics()
s_topicId Vector viewTopicInformation(s_topicId)
Topic v_topicList Boolean createTopic(v_topicInfo)
v_topicInfo Boolean modifyTopic(v_newTopicInfo)
Boolean removeTopic(s_topicId)
CourseCalender v_courseCalendar Vector viewCourseCalendar(s_courseId)

To follow a logical sequence now, let us consider that the course administrator,
courses, tutors, and topics already exist. Let us now make an object diagram for the
case where the administrator with user id "admin" wishes to access the course
calendar of a course with course id "Math_Course_001."

Hence, the following will be the attribute values, and method calls:

CourseAdministrator
Attributes: s_adminId = admin
s_courseId = Math_Course_001
Methods: viewCourseCalendar("Math_Course_001")

This method will call the method viewCourseInfo of class Course, which returns a
Vector object populated with all the details of the course "MathCourse_001" (see
Figure 5.8)

Course
Methods: viewCourseInfo("Math_Course_001")

Click here for a larger image.

Figure 5.8—the object diagram for the courseware management system, for
a simple scenario of the course administrator managing a math course.

In Figure 5.8, for the single case where the flow is from Course Administrator to
Course, when the CourseAdministrator is requesting the course information for a
particular course.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.22SUMMARY

In the last article, we saw how to make class diagrams, and made a class diagram
for the case study—the Courseware Management system. In this article, we saw:

• What an object diagram is

• Notation used in an object diagram
• What the significance and use of an object diagram is
• How to make an object diagram in Poseidon
• The object diagram for a simple scenario in our Courseware Management
system

In the next article of this series, we will study the state diagram.

State Diagram in UML

1.1.23THE BASICS

Until now, we have seen Use Cases, Class diagrams, and Object diagrams. These
diagrams give an architectural and high-level view of a system. In a typical software
life cycle, the business or functional domain experts define Use Case diagrams. The
Class diagrams and Object diagrams are made by senior-level developers, with the
help of system architects. Once this has been accomplished, and the system design
and architecture is in place, these artifacts are passed on to the developer, who
actually codes the system. All the above diagrams are static diagrams, which means
that they help in visualizing what the elements of the complete system would be, but
do not say anything about the flows any object of the system can have when an
event occurs. Structural elements are used to depict static diagrams.

While coding, it is necessary to understand the details of the modes an Object of a

Class can go through and its transitions at time intervals with the occurrence of any
event or action.

State diagrams (also called State Chart diagrams) are used to help the developer
better understand any complex/unusual functionalities or business flows of
specialized areas of the system. In short, State diagrams depict the dynamic
behavior of the entire system, or a sub-system, or even a single object in a system.
This is done with the help of Behavioral elements.

It is important to note that having a State diagram for your system is not a
compulsion, but must be defined only on a need basis.

1.1.23.1DEFINING A STATE DIAGRAM

Just as we define classes for a Class diagram, it is necessary to define the elements
of a State diagram. Let us first see what the elements of a State diagram are.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.23.2ELEMENTS OF A STATE DIAGRAM

A State diagram consists of the following behavioral elements:

Element and its Description Symbol

Initial State: This shows the starting point or first activity of
the flow. Denoted by a solid circle. This is also called as a
"pseudo state," where the state has no variables describing it
further and no activities.
State: Represents the state of object at an instant of time. In a
state diagram, there will be multiple of such symbols, one for
each state of the Object we are discussing. Denoted by a
rectangle with rounded corners and compartments (such as a
class with rounded corners to denote an Object). We will
describe this symbol in detail a little later.
Transition: An arrow indicating the Object to transition from
one state to the other. The actual trigger event and action
causing the transition are written beside the arrow, separated
by a slash. Transitions that occur because the state completed
an activity are called "triggerless" transitions. If an event has
to occur after the completion of some event or action, the event
or action is called the guard condition. The transition takes
place after the guard condition occurs. This guard
condition/event/action is depicted by square brackets around
the description of the event/action (in other words, in the form
of a Boolean expression).
History States: A flow may require that the object go into a
trance, or wait state, and on the occurrence of a certain event,
go back to the state it was in when it went into a wait state—its
last active state. This is shown in a State diagram with the help
of a letter H enclosed within a circle.
Event and Action: A trigger that causes a transition to occur is
called as an event or action. Every transition need not occur
due to the occurrence of an event or action directly related to
the state that transitioned from one state to another. As
described above, an event/action is written above a transition
that it causes.
Signal: When an event causes a message/trigger to be sent to
a state, that causes the transition; then, that message sent by
the event is called a signal. Represented as a class with the
<<Signal>> icon above the action/event.

Final State: The end of the state diagram is shown by a bull's

eye symbol, also called a final state. A final state is another
example of a pseudo state because it does not have any
variable or action described.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Note: Changes in the system that occur, such as a background thread while the
main process is running, are called "sub states." Even though it affects the main
state, a sub state is not shown as a part of the main state. Hence, it is depicted as
contained within the main state flow.

As you saw above, a state is represented by a rectangle with rounded edges. Within
a state, its Name, variables, and Activities can be listed as shown in Figure 6.1.

Figure 6.1: the structure of the state element

1.1.24CREATING A STATE DIAGRAM

Let us consider the scenario of traveling from station A to station B by the subway.
Figure 6.2 would be a state diagram for such a scenario. It represents the normal
flow. It does not show the sub states for this scenario.

Click here for a larger image.

Figure 6.2: an example flow in a state diagram

1.1.25THINGS TO REMEMBER

Create state diagrams when the business logic for a particular flow is very complex,
or needs greater understanding by the developer to be coded perfectly.

Arrange the states and transitions to ensure that the lines that cross each other are
minimal. Criss-crossing lines are potential sources of confusion in conveying the
diagram's meaning.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.26CASE STUDY—COURSEWARE MANAGEMENT SYSTEM

Because our Courseware Management System case study does not undergo any
noticeable state changes, we will drill down our attention to the Course object in the
system. Recall that a state diagram can be defined not only for a system or
subsystem, but also for an object in the system.

1.1.26.1IDENTIFYING STATES AND EVENTS OF THE COURSE OBJECT

The Course object does undergo state changes during its lifecycle, right from course
creation to deleting a course. Let us depict the Course object's lifecycle by using a
state diagram to understand it better. The events that occur in the lifecycle of the
Course object are listed below:

• Create new course—add information for the course or update an existing

course; update information for the course
• Add topics—add topics to the course
• Assign tutors—assign the available tutors for the course
• Close—finished adding or updating the course

Consider the event of adding a new course to the Courseware Management System
by the course administrator. The course administrator fills in the course information,
thus initiating the creation of the Course object.

This event kicks off two events that change the state of the Course object, but are
part of the new course event. These two events contained within the new course
creation event are adding topics to the Course object and assigning tutors for the
course. This results in the Topic objects getting associated with the Course object.
Next, the course administrator may wish to assign tutors to teach the course by
identifying the tutors that teach this course (based on their specialty/preferences)
and checking the availability of the tutors for a given period of time.

This completes the lifecycle Course object until the time an update course event
occurs.

Figure 6.3 shows the state diagram for the Course object. The state diagram depicts
the changes in the state of the Course object as it transitions through the various
events in its lifecycle.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Click here for a larger image.

Figure 6.3: the state diagram of the Course object

1.1.27SUMMARY

This article covered the first of the series of dynamic diagrams in UML. The state
diagram is one of the simplest ways to represent the lifecycle of an entire system or
a subsystem or even an object of a system. In the next article of this series, we will
learn about Activity diagrams.

Activity Diagram in UML.

1.1.28BASICS

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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.28.1DEFINING AN ACTIVITY DIAGRAM

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

1.1.28.2ELEMENTS 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

CREATING AN ACTIVITY DIAGRAM

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.

1.1.29SWIM 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.30CASE 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.

1.1.30.1 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".

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

This completes the activities involved in managing course information carried out by
the course administrator.

1.1.30.2ACTIVITY 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.

1.1.31SUMMARY

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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Sequence Diagram in UML

1.1.32BASICS

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.

1.1.32.1DEFINING 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:

Click here for a larger image.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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.

1.1.32.2DEFINING A SEQUENCE DIAGRAM

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

1.1.32.3ELEMENTS 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.

1.1.33CREATING A SEQUENCE DIAGRAM

If your UML tool supports modeling class diagrams, you should be able to model
Sequence diagrams as well. We will be using the Poseidon Community Edition tool to
draw the class diagram. You can use any tool that you are comfortable with.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

The screen shot of the Poseidon tool in Figure 8.2 shows the different options to
model Sequence diagrams and define interactions between objects participating in
these interactions.

1.1.34CASE 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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.34.1IDENTIFYING 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.

1.1.34.2SEQUENCE DIAGRAM

Click here for a larger image.

Figure 8.3: Activity diagram for the "Manage course information" flow

Figure 8.3 shows the Sequence diagram for the "Manage course information" flow.
The Sequence diagram uses the CourseAdministrator, Course, Topic, and Tutor
classes that we had defined earlier (see Article 4, parts 1 and 2) when we modeled
the different classes in the Courseware Management System. The methods used in
the Sequence diagram are the same methods that we had defined for these classes
previously.

1.1.35SUMMARY

A Sequence diagram, as we saw today, represents the interaction among the

different objects of a system. In the next article of this series, we will learn about

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Collaboration diagrams that are similar to Sequence diagrams, but represented as a

set of graphs.

For more information, click on the following attached document

UML-SequenceDiagra
m.doc

Collaboration Diagram in UML

1.1.36BASICS

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.

1.1.36.1DEFINING 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.

1.1.36.2ELEMENTS OF A COLLABORATION DIAGRAM

A Collaboration diagram consists of the following elements:

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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.

CREATING A COLLABORATION DIAGRAM

Click here for a larger image.

Figure 9.1: Screen shot of the Poseidon tool

The screen shot of the Poseidon tool in Figure 9.1 shows the different options to
model Collaboration diagrams and define associations and interactions between
objects. Since a Collaboration diagram is very similar to a Sequence diagram, a few
sophisticated UML tools provide automatic generation of Collaboration diagrams from
Sequence diagrams.

1.1.37CASE STUDY—COURSEWARE MANAGEMENT SYSTEM

In the Sequence diagram in the previous article, we had modeled the interaction for
the "Manage course information" scenario. The static model of the Courseware
Management System was built as a Class diagram (see Article 4, Part II). We will use
these as the basis for modeling the Collaboration diagram of the "Manage course
information" scenario.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.37.1IDENTIFYING STATES AND EVENTS OF THE COURSE OBJECT

Per our Class diagram (see Article 4, Part II), we had defined that the primary
(active) entity in the model is the Course Administrator. The Course Administrator
interacted with different entities in the system, such as Course, Topic, and Tutor. The
following associations were modeled:

• The "User" entity interacted with the system as a Course Administrator

• The Course Administrator entity has a "manages" association with the Course,
Topic, and Tutor entities
• The Course entity can contain 0 or more Topics

The interactions between these entities for the "manage course information" scenario
upon which we modeled the sequence diagram (see Article 8) were as under:

• 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.

Based on this, we will now model these associations and interactions in the
Collaboration diagram for the "Manage course information" scenario.

1.1.37.2COLLABORATION DIAGRAM

Figure 9.2: Collaboration diagram for the "Manage course information" flow

Figure 9.2 shows the Collaboration diagram for the "Manage course information"
flow. The Collaboration diagram uses the CourseAdministrator, Course, Topic, and

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Tutor classes that we had defined earlier and used to defined the sequence of events
in the Sequence diagram in the previous article. Notice that, in addition to the
messages that we had represented for the sequence diagrams, we also represent the
association between these entities in the Collaboration diagram.

1.1.38SUMMARY

After this overview of Collaboration diagrams, we will cover the Component diagrams
in UML in the next article.

Component Diagrams in UML

1.1.39BASICS

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.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.40ELEMENTS 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

CREATING A COMPONENT DIAGRAM

Click here for a larger image.

Figure 1 Screen shot of the Poseidon tool

The screen shot of the Poseidon tool in Figure 1 shows the different options to model
components in a Component diagram and define interactions between these
components.

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

1.1.41CASE 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.

1.1.42COMPONENT DIAGRAM

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

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.

1.1.43SUMMARY

In this article, we briefly discussed Component diagrams. In the next article, we will
cover the last UML diagram—the Deployment diagram.

UML By Examples

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

Home
Collabration diagrams:
UML

Resources

Collabration Digaram for Serving Elevator Button

Collabration Digaram for Serving Door Button

CONFIDENTIAL Created by – Jegadeesan Danavelu

UML Reference Document HCL Technologies Ltd – Gurgaon

CONFIDENTIAL Created by – Jegadeesan Danavelu