Uml overview modified

UML Overview
Introduction

Modeling is an activity that has been carried out over the years in software development.
When writing applications by using the simplest languages to the most powerful and
complex languages, you still need to model. Modeling can be as straightforward as
drawing a flowchart listing the steps carried out by an application. Why do we use
modeling? Defining a model makes it easier to break up a complex application or a huge
system into simple, discrete pieces that can be individually studied. We can focus more
easily on the smaller parts of a system and then understand the "big picture." Hence, the
reasons behind modeling can be summed up in two words:

• Readability
• Reusability

Readability brings clarity—ease of understanding. Understanding a system is the first
step in either building or enhancing a system. This involves knowing what a system is
made up of, how it behaves, and so forth. Modeling a system ensures that it becomes
readable and, most importantly, easy to document. Depicting a system to make it
readable involves capturing the structure of a system and the behavior of the system.

Reusability is the byproduct of making a system readable. After a system has been
modeled to make it easy to understand, we tend to identify similarities or redundancy, be
they in terms of functionality, features, or structure.

Even though there are many techniques and tools for modeling, in this article series, we
will be concerning ourselves with modeling object-oriented systems and applications
using the Unified Modeling Language. The Unified Modeling Language, or UML, as it is
popularly known by its TLA (three-letter acronym!), is the language that can be used to
model systems and make them readable. This essentially means that UML provides the
ability to capture the characteristics of a system by using notations. UML provides a wide
array of simple, easy to understand notations for documenting systems based on the
object-oriented design principles. These notations are called the nine diagrams of UML.

So the question arises, Why is UML the preferred option that should be used for
modeling? Well, the answer lies in one word: "standardization!" Different languages have
been used for depicting systems using object-oriented methodology. The prominent
among these were the Rumbaugh methodology, the Booch methodology, and the
Jacobson methodology. The problem was that, although each methodology had its
advantages, they were essentially disparate. Hence, if you had to work on different
projects that used any of these methodologies, you had to be well versed with each of
these methodologies. A very tall order indeed! The Unified Modeling Language is just
that. It "unifies" the design principles of each of these methodologies into a single,
standard, language that can be easily applied across the board for all object-oriented
systems. But, unlike the different methodologies that tended more to the design and
detailed design of systems, UML spans the realm of requirements, analysis, and design
and, uniquely, implementation as well. The beauty of UML lies in the fact that any of the
nine diagrams of UML can be used on an incremental basis as the need arises. For
example, if you need to model requirements for a given system, you can use the use
case diagrams only without using the other diagrams in UML. Considering all these
reasons, it is no wonder that UML is considered "the" language of choice.
UML does not have any dependencies with respect to any technologies or languages.
This implies that you can use UML to model applications and systems based on either of

2

the current hot technologies; for example, J2EE and .NET. Every effort has been made
to keep UML as a clear and concise modeling language without being tied down to any
technologies.

This series aims to cover the basics of UML, including each of the nine diagrams of
UML. In addition, you will get to learn about the tools available that support UML. At the
end of each article, we will incrementally build each of the nine UML diagrams for a case
study system in the coming weeks. We will wrap our study of UML by expanding into two
different areas—Rational Unified Process and Design Patterns.

UML Diagrams

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

• Use case diagram: The use case diagram is used to identify the primary
elements and processes that form the system. The primary elements are termed
as "actors" and the processes are called "use cases." The use case diagram
shows which actors interact with each use case.

• Class diagram: The class diagram is used to refine the use case diagram and
define a detailed design of the system. The class diagram classifies the actors
defined in the use case diagram into a set of interrelated classes. The
relationship or association between the classes can be either an "is-a" or "has-a"
relationship. Each class in the class diagram may be capable of providing certain
functionalities. These functionalities provided by the class are termed "methods"
of the class. Apart from this, each class may have certain "attributes" that
uniquely identify the class.

• Object diagram: The object diagram is a special kind of class diagram. An object
is an instance of a class. This essentially means that an object represents the
state of a class at a given point of time while the system is running. The object
diagram captures the state of different classes in the system and their
relationships or associations at a given point of time.

• State diagram: A state diagram, as the name suggests, represents the different
states that objects in the system undergo during their life cycle. Objects in the
system change states in response to events. In addition to this, a state diagram
also captures the transition of the object's state from an initial state to a final state
in response to events affecting the system.

• Activity diagram: The process flows in the system are captured in the activity
diagram. Similar to a state diagram, an activity diagram also consists of activities,
actions, transitions, initial and final states, and guard conditions.

• Sequence diagram: A sequence diagram represents the interaction between
different objects in the system. The important aspect of a sequence diagram is
that it is time-ordered. This means that the exact sequence of the interactions
between the objects is represented step by step. Different objects in the
sequence diagram interact with each other by passing "messages".

• Collaboration diagram: A collaboration diagram groups together the interactions
between different objects. The interactions are listed as numbered interactions

3

that help to trace the sequence of the interactions. The collaboration diagram
helps to identify all the possible interactions that each object has with other
objects.

• Component diagram: The component diagram represents the high-level parts
that make up the system. This diagram depicts, at a high level, what components
form part of the system and how they are interrelated. A component diagram
depicts the components culled after the system has undergone the development
or construction phase.

• Deployment diagram: The deployment diagram captures the configuration of
the runtime elements of the application. This diagram is by far most useful when
a system is built and ready to be deployed.

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

UML Diagram Classification—Static, Dynamic, and Implementation

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

• Static: The static characteristic of a system is essentially the structural aspect of
the system. The static characteristics define what parts the system is made up of.

• Dynamic: The behavioral features of a system; for example, the ways a system
behaves in response to certain events or actions are the dynamic characteristics
of a system.

• Implementation: The implementation characteristic of a system is an entirely
new feature that describes the different elements required for deploying a
system.

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

• Static

o Use case diagram
o Class diagram

• Dynamic

o Object diagram
o State diagram
o Activity diagram
o Sequence diagram
o Collaboration diagram

4

Implementation

o Component diagram
o Deployment diagram

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

4+1 View of UML Diagrams

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

These different views are:

• Design View: The design view of a system is the structural view of the system.
This gives an idea of what a given system is made up of. Class diagrams and
object diagrams form the design view of the system.

• Process View: The dynamic behavior of a system can be seen using the
process view. The different diagrams such as the state diagram, activity diagram,
sequence diagram, and collaboration diagram are used in this view.

• Component View: Next, you have the component view that shows the grouped
modules of a given system modeled using the component diagram.

• Deployment View: The deployment diagram of UML is used to identify the
deployment modules for a given system. This is the deployment view of the

• Use case View: Finally, we have the use case view. Use case diagrams of UML
are used to view a system from this perspective as a set of discrete activities or
transactions.

Summary

In the first article of this series, we took a quick background at what UML is and where it
fits in the overall software life cycle. Each of the nine diagrams that make up UML will be
covered step by step in the coming weeks. Before we start with our study of each of
these nine diagrams, we will take a look at what UML tools are available in the market in
the next article.

5

UML Tools

By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

In the previous article, we gained an overview of what the Unified Modeling Language
stands for and what are the nine diagrams that make up UML. Because UML is
essentially a set of diagrams, you can simply draw them by hand on a piece of paper.
But, drawing UML diagrams on a piece of paper is certainly not a best practice to design
systems. Software applications simplify the task of drawing diagrams of software
designs. In addition, because the design is in an electronic format, archiving the design
for future use, collaborating on the design becomes much easier. Also, routine tasks can
be automated by using a UML tool. Hence, using a UML tool is by far the most preferred
way for designing software applications.

Features in UML Tools

This takes us to an important question—what exactly should we look for in a UML tool?

Because the primary use of a UML tool is to enable you to draw diagrams, first and
foremost, we need to see what types of UML diagrams the tool supports. But, is drawing
UML diagrams all that you would expect from a UML tool? For example, wouldn't it be
great if the class diagrams that you draw in the tool can somehow be used to generate
the source code for actual Java classes or C++ classes?

Let us take a look at another scenario. Suppose you were given a large set of source
code files with lots and lots of classes. Wouldn't it be a nightmare wading through the
code trying to figure out how all the classes are interconnected? This is where UML tools
step in to make things a lot easier by providing support for such features. Now, let's
define these features in technical terms:

• UML diagram support: The UML tool should support all the nine diagrams that
make up UML. You should look for a tool that supports drawing use cases,
designing the static view diagrams such as class diagrams and object diagrams,
defining the dynamic view diagrams such as sequence, activity, state, and
collaboration diagrams and the component and deployment diagrams that form
the implementation view of the system.

• Forward engineering: A UML tool should not have its use limited to just a
pictorial depiction of diagrams. Because the structure of the system defined by
the diagram is translated by a developer into actual source code (classes), the
UML tool should bridge this step by generating the source code of the classes
with the methods stubbed out. Developers can take up this stub code and fill in
with the actual code. This characteristic of automating the generation of source
code is called forward engineering. Forward engineering support by a UML tool is
normally for a specific language or a set of languages. If you are a Java
developer, verify that the UML tool that you want to use has forward engineering
support for Java. Similarly, if you are a C++ developer, the UML tool should
provide you forward engineering support for C++.

• Reverse engineering: Reverse engineering is exactly the opposite of forward
engineering. In reverse engineering, the UML tool loads all the files of the
application/system, identifies dependencies between the various classes, and
essentially reconstructs the entire application structure along with all the
relationships between the classes. Reverse engineering is a feature normally
provided by sophisticated and high-end UML tools.

6

• Round-trip engineering: Another useful feature apart from forward and reverse
engineering is round-trip engineering. Forward and reverse engineering are
essentially one-off activities that take input and generate the required output.
Round-trip engineering extends these features.

• An important rule in software design is that no design remains unchanged. This is
as true for small systems as it is for large systems. During development, the
design structure defined in the UML model does undergo changes to incorporate
physical differences in implementation that may not have been envisaged during
design. It becomes very difficult to keep the design of the system updated with
the changes in the source code. The round-trip engineering feature enables the
UML tool to synchronize the model with the changes in the application code.

• Documentation: Documentation is an integral aspect of a UML tool. Software
designing, by nature, is an abstract process. Apart from a few syntax and
semantic ground rules, there are no other rules. The thought process of a
software architect who designs applications using UML can be lost if the reasons
behind certain design decisions are not captured and well documented. This
becomes painfully clear when large systems are maintained and no one has a
clue to why a subsystem was designed in a certain way. Hence, a UML tool must
necessarily provide some way for the designer to document design decisions in
the diagrams by using simple things such as annotations or comments. In
addition to this, the UML tool should support the generation of reports/listings of
the different design elements of the diagram.

Apart from the above features, you should also identify a few features that would
definitely be useful to have in the UML tool.

• Version control: A very important feature that we want to have in the UML tool is
either an integrated version control mechanism or connectivity to a standard
version control system. Configuration management is an integral part in the
building of software systems. Considering that the design of a system is a very
important artefact of the software lifecycle, maintaining versions and baselines of
the system design is a desirable feature to have in UML tools. In the absence of
direct support for version control, it is the responsibility of the designer to
maintain versions of the design.

• Collaborative modeling environment: Enterprise systems are huge and their
designs are quite complex. While designing complex systems, there may be
different teams involved and may carry out design work on different subsystems
in parallel. This collaborative design effort needs to be properly synchronized by
the UML tool. The UML tool should provide support for a collaborative modeling
environment with capability to compare different versions designs for differences
or even merge different versions of a design. Collaborative modeling is always a
nice feature to have in UML tools.

• Integration with popular Integrated Development Environments (IDE): With
the increasing use of iterative methodologies for building software systems, it
becomes very difficult to keep the design of the system in sync with the
developed code. Hence, it would be useful if the UML tool provides integration
with popular IDEs. This feature would enable the UML tool to be updated with the
changes in the source code made in the IDE.

7

• Test script generation: The system or subsystem designed in a UML tool may
represent a set of functional aspects as well. Hence, it would be really useful if, in
addition to generating stub code, the tool also generates test scripts that can be
used for testing how the generated class functions.

• Model View Controller (MVC) modeling: Enterprise application architectures
have increasingly begun to standardize and are based on the Model View
Controller architecture. Hence, if you design n-tier, Web-enabled enterprise
applications, you should look for a UML tool that supports designing applications
based on the MVC architecture. Support for MVC modeling makes it easier to
organize and clearly distinguish the design elements along the lines of the MVC
layers. This will help in the long run in improving the readability of the model.

Template-driven modeling
Re-usability is the key to improving productivity. An application design may consist of
several classes with relationships defined. Quite a few times, while designing
applications, you encounter the same design problems or scenarios and end up defining
the same design again and again. By using a modeling tool, you can define certain
components or even subsystems that might potentially be reusable in the future. For
example, design elements of an application used to define access to the database using,
say, a ConnectionPool class are potentially reusable. You might need to define a similar
database connection pool in another application as well. Hence, it would benefit us in the
long run if we design the ConnectionPool class separately. We then can include the
ConnectionPool design in any future subsystems and avoid the need of reinventing the
wheel.

Such reusable designs or models are termed as templates and the entire modeling
process involving the identification and use of templates is called template-driven
modeling. The benefits of template-driven modeling are apparent in the savings in design
time. You can consider model templates to be very similar to reusable code libraries used
in application development.

Popular UML Tools

We will list here a few of the "movers and shakers" of vendors of UML tools. Please note
that this list is by no means exhaustive and is not meant to provide any ranking for any
UML tool.

• Rational Rose: No discussion of UML tools is complete without the mention of
the Rational Rose modeling tool from Rational Software Corporation. Rational
Rose (the Rose stands for "Rational Object-oriented Software Engineering") is a
visual modeling tool for UML. It comes in different versions suited to different
requirements. Rational Rose provides support for all the standard features that
we discussed in the previous section such as UML diagram support, forward and
reverse engineering support, and documentation and round-trip engineering
support. Apart from this, Rational Rose also provides support for version control,
IDE integration, design pattern modeling, test script generation, and collaborative
modeling environment. In addition, Rational Rose also supports the designing of
data models within the same environment. An interesting feature of Rational
Rose is the ability to publish the UML diagrams as a set of Web pages and
images. This enables you to share and distribute your application design where
the Rational Rose tool is not installed.

8

• Together Control Center: Together Control Center (formerly from Togethersoft)
from Borland is an entire suite of visual modeling tools for UML. Together Control
Center supports UML diagrams, MVC modeling, forward and reverse
engineering, and round-trip engineering, as well as integration with IDEs such as
IBM WebSphere Studio.

It supports comprehensive documentation and a powerful collaborative modeling
environment.

An added feature of Together Control Center is the pattern repository. The
pattern repository (similar to the template-driven modeling concept discussed
above) makes frequently used diagrams and design patterns readily available for
reuse in modeling. Together Control Center supports the Rational Unified
Process as well as the eXtreme Programming methodologies.

• Poseidon: Poseidon from Gentleware has its roots in the ArgoUML open source
project. The ArgoUML modeling tool evolved as an open source effort and is a
useful, full-featured UML tool freely available under the Open Publication
License. Gentleware has taken ArgoUML a step further and turned it into a good
modeling tool. Poseidon comes in different flavors suited to different
requirements. Poseidon supports forward and reverse engineering and
documentation generation by using special-purpose plug-ins.

Gentleware has not forgotten its open source moorings and offers the Poseidon
for UML Community Edition 1.5 free for individual software developers.

Integration of UML Tools with Integrated Development Environments (IDEs)

One interesting feature in UML tools that we discussed in the previous section was
round-trip engineering. For round-trip engineering to be useful, we need to have the UML
tool to be used in conjunction with an IDE. This integration of a UML tool with the IDE will
help you to really benefit from round-trip engineering. Any changes in the application
code that you make in the IDE are immediately reflected in the model in the UML tool
and vice versa. For our discussion, we will be considering IDEs for the Java language.

Quite a few of the UML tools on the market can be integrated with the popular IDEs such
as IBM's WebSphere Studio, Borland's JBuilder, WebGain's Visual Café, or Sun's Forte.
For instance, Rational Rose (Java edition) provides integration with all of these popular
IDEs. Together Control Center has a special version that integrates with IBM's
WebSphere Studio.

The downside of UML tool integration is that the integration solution is proprietary to the
UML tool vendor. Hence, you might not always find a UML tool providing integration with
popular IDEs in the market. But all this is changing. (See box for details on the Eclipse
project.)

9

Eclipse
Eclipse is an open source effort that has tool integration as the long-term goal. The
interesting aspect of Eclipse is that the effort is supported by major tool vendors. Eclipse
aims to define across-the-board integration standards that will enable vendors of different
tools to seamlessly work together and provide a cohesive and single development
environment. The beauty of Eclipse is that the integration between tools is not a
proprietary solution. In layman's terms this means that, for example, you can buy an off-
the-shelf UML tool and integrate it into your development environment without having to
worry that you might be stuck with a particular vendor or group of vendors. Eclipse is
definitely an area to watch out for in the near future! (www.eclipse.org)

Case Study

We will apply the UML concepts that we will be discussing through the coming weeks
and design an entire real world application. Each session in the coming weeks will be
rounded off with designing the case study application incrementally using each of the
UML diagrams.

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 in the coming weeks.

Summary

UML tools will form the basis of our activities in the coming weeks. Each of the UML
diagrams that we will cover will be built using any of the available UML tools in the
market. Today's discussion helped us understand what features we should look for when
selecting a UML tool. Apart from the "must-have" features, we also checked out a "wish
list" of features that a UML tool could have. The classroom courseware case study
application that we discussed will be designed using when we cover each of the UML
diagrams in the coming weeks.

10

Creating Use Case Diagrams

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.

11

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.

12

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

13

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

14

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.

.

Figure 3.7: a screen shot of the Poseidon tool

Take a look at the screen shot of the Poseidon tool. You can see the different options it
provides to draw the use case diagram elements. In addition to drawing the use case
diagram elements such as actors and use cases, you also can define relationships
between use cases. Apart from this, the tool also provides capability to document the
different elements that we draw. This documentation can be viewed as a consolidated
report for future reference.

15

An additional feature that you can check in your modeling tool is support for generating
test scripts from the use case diagram. A comprehensive use case diagram provides a
good foundation for basing test cases for the system that you model.

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

16

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:


17

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

18

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.

The UML Class Diagram: Part 1

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.

19

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.

20

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

21

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.

22

Sr. No. Relation Symbol Description
1 Association When two classes are
connected to each
other in any way, an
association relation is
established. For
example: A "student
studies in a college"
association can be
shown as:
1 a. Multiplicity An example of this kind
of association is many
students belonging to
the same college.
Hence, the relation
shows a star sign near
the student class (one
to many, many to
many, and so forth kind
of relations).
1 b. Directed Association between
Association 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 No separate symbol. However, An example of this kind
Association the relation will point back at the of relation is when a
same class. 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

23

relationship.
Composition connotes
that a strong life cycle
is associated between
the classes.
3 Inheritance/General Also called an "is a"
ization relationship, because
the child class is a type
of the parent class.
Generalization is the
basic type of
relationship used to
define reusable
elements in the class
diagram. Literally, the
child classes "inherit"
the common
functionality defined in
the parent class.
4 Realization In a realization
relationship, one entity
(normally an interface)
defines a set of
functionalities as a
contract and the other
entity (normally a
class) "realizes" the
contract by
implementing the
functionality defined in
the contract.

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.

24

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.

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

Figure 4.1.3—a screen shot of the Poseidon tool

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

25

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.

UML DIAGRAM PART II

Introduction

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.

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:

26

• Tutors


• Students

And the use cases of the system were:

• View courses




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

27

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()
manageTopic()
viewCourseCalendar()
viewTutors()
manageTutorInformation()
assignTutorToCourse()

28

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.

29

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.

30

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.

31

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.

32

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.

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.

Object Diagrams in UML

Introduction

In the last article, you saw how your application could be represented in a class diagram.
A class diagram is a static representation of your system. It shows the types of classes,
and how these classes are linked to each other. In this edition of our series we introduce
the object diagram.

33

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

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

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

Elements of an Object Diagram

Because an object diagram shows how specific instances of a class are linked to each
other at runtime, at any moment in time it consists of the same elements as a class
diagram; in other words, it contains classes and links showing the relationships.
However, there is one minor difference. The class diagram shows a class with attributes
and methods declared. However, in an object diagram, these attributes and method
parameters are allocated values.

As an example, in the last article, a class diagram for a multiplicity relation between
college and students was shown, as you cam see in Figure 5.1:

Figure 5.1—an example College-Student class diagram

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

Figure 5.2—the class diagram with attributes

34

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

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

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

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

Eg: Graduate School of Business: College

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

This example was the representation of the relation of only two classes with each other.
However, in a real application system, there will be multiple classes. An object diagram
then shows the relation between the instantiations of these classes. We shall see this in
our case study.

A class that defines the flow of the system is called as an active class. This class
instance in the object diagram is represented by thick border. In an MVC application
architecture, the controller servlet is the action class, and is denoted by a thicker border.
Also, multiple instances of the same class, as in a factory pattern, if the attributes of the
individual objects are not important, or are not different, these can be represented by a
single symbol of overlapping rectangles (see Figure 5.4):

Figure 5.4—the object diagram for a Factory class

35

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

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

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.

the creation of an object diagram in Poseidon(objdiagram1)

• Click on Create diagram -> Deployment/Object/Component diagram (or Ctrl+D) in
the menu bar above.

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

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

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

• In case of our Case study, if we show an object diagram for the Course
Administrator managing the Courses scenario, we get a diagram as shown in
Figure 5.7.

objectdiagram2—the object diagram in Poseidon for the case study Courseware
management system

Dos and Don'ts

Dos

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

36

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.

Don'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.

Case 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
CourseAdministrator s_adminId Vector viewCourses()

v_courses Vector manageCourse(s_courseId)

s_courseId Vector manageTopic(s_topicId)

v_tutors Vector viewCourseCalendar(s_courseId)

v_tutorInfo Vector viewTutors()

s_tutorId Vector manageTutorInformation(s_tutorId)

v_topics Boolean assignCourseToTutor(s_courseId,
s_tutorId)
s_topicId

37

Student s_studentId Vector viewAllStudents()

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)

Boolean removeTutor(s_tutorId)
Course s_courseId Vector viewAllCourses()

v_courseList Vector viewCourseInfo(s_courseId)

v_courseInfo Boolean createCourse(v_courseInfo)

Boolean modifyCourse(v_newCourseInfo)

Boolean removeCourse(s_courseId)
Topic s_topicId Vector viewAllTopics()

v_topicList Vector viewTopicInformation(s_topicId)

v_topicInfo Boolean createTopic(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)

38

Uml overview modified

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (9)

Semelhante a Uml overview modified

Semelhante a Uml overview modified (20)

Último

Último (20)

Uml overview modified