Case Study
For our case study, we will be the architects assigned the task of constructing the
design elements for a system that can be used to manage coursees/classes for an
organization that specializes in providing training. Let us name the system that we
will be designing as the Courseware Management System. The organization offers a
variety of courses in a variety of areas such as learning management techniques and
understanding different software languages and technologies. Each course is made
up of a set of topics. Tutors in the organization are assigned courses to teach
according to the area that they specialize in and their availability. The organization
publishes and maintains a calendar of the different courses and the assigned tutors
every year. There is a group of course administrators in the organization who
manage the courses including course content, assign courses to tutors, and define
the course schedule. The training organization aims to use the Courseware
Management System to get a better control and visibility to the management of
courses as also to streamline the process of generating and managing the schedule
of the different courses.
Now that we have our problem statement defined, we can proceed to the next step—
analyzing and elaborating on the requirements and then designing the Courseware
Management System.
Use Case Diagram
Over the previous two articles, we took a brief look at the nine UML diagrams and
what kind of tools you can use to model UML diagrams. Now that we have our basics
clear, we will start our study of these nine UML diagrams. Today we will cover the
Use case diagram. We will learn the basics of use case diagrams and try our hand
at drawing a use case diagram. In addition, we will see what a use case specification
is. Finally, we will attempt to apply what we have learned of use cases and model the
use case diagrams for our case study application—the Courseware Management
System.
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.
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) 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.
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.
Creating the Use Case Diagram
For drawing use case diagrams, you need to use any tool that supports use case
diagrams. We will be using the Poseidon Community Edition tool for drawing the use
case diagram, as shown in Figure 3.7. You can use any tool that you are comfortable
with. A use case modeling tool provides a palette of options to draw actors and use
cases and to define relationships between the use cases.
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).
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.
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.
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.
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
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.
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.
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.
Class Diagram
In the last article, we saw what use cases were, and how to identify and create use
cases. Taking the series ahead, in this article, we will see what class diagrams are,
what the elements of a class diagram are, what each of these elements signify, and
how to identify them. In our next article, a sequel to this one, we will see how to
create class diagrams for our case study—Courseware Management System. By the
end of the second article, you will be able to define classes for a system and read
and create class diagrams.
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.
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
No.
1
Symbol
Description
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
1 c. Reflexive Association
2
Association between
classes is bidirectional by default.
You can define the
flow of the
association by using a
directed association.
The arrowhead
identifies the
container-contained
relationship.
No separate symbol. However, An example of this
the relation will point back at the kind of relation is
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.
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
4
Realization
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.
A 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.
Dos 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.
Summary
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.
Case 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.
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
Identifying 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 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
o
o
o
o
o
CourseAdministrator
Tutor
Student
Course
Topic
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()
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,
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.
Identifying 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
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.
Class diagram
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
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.
Forward 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.
Figure 4.2.2 shows forward engineering a class diagram
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.
Reverse 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.
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.
Summary
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.