www.jntuworld.

com

Introducing the UML (Unified Modeling Language)

As the world becomes more complex, the computer-based systems that inhabit the world also must
increase in complexity. They often involve multiple pieces of hardware and software, networked
across great distances, linked to databases that contain mountains of information. If you want to
make systems that deal with this, how do you get your hands around the complexity?
The key is to organize the design process in a way that clients, analysts, programmers and other
involved in system development can understand and agree on. The UML provides the organization.
Consider this: Would you tell a building contractor that you want a 4 bedroom, 3 bath home, about
2000 square feet - Start building it! We'll hammer out the details as we go along? We all know this
is ludicrous. But sadly, this method of development is all too common in the software industry. Just
as you would work with an architect to design a blueprint that would diagram exactly how the house is
to be built, you will work with us on an UML diagram that will document exactly how your custom
software system will be built.

What is UML?
The Unified Modeling Language (UML) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business modeling
and other non-software systems. The UML represents a collection of best engineering practices that
have proven successful in the modeling of large and complex systems. The UML is a very important
part of developing object oriented software and the software development process.
The UML uses mostly graphical notations to express the design of software projects. Using the UML
helps project teams communicate, explore potential designs, and validate the architectural design of
the software.

The UML was released in 1997 as a method to diagram software design. It was designed by
a consortium of the best minds in object oriented analysis and design. It is by far the most
exciting thing to happen to the software industry in recent years. Every other engineering
discipline has a standard method of documentation.

Electronic engineers have schematic

diagrams, architects and mechanical engineers have blueprints and mechanical diagrams.
The software industry now has UML.

Goals of UML
The primary goals in the design of the UML were:
1. Provide users with a ready-to-use, expressive visual modeling language so they can develop
and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development processes.
CSE Department,
VNRVJIET

1
www.jntuworld.com

www.jntuworld.com
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks, patterns and
components.
7. Integrate best practices.
Before we move on next lesson consider some of the benefits of UML:
1 Your software system is professionally designed and documented before it is coded. You will
know exactly what you are getting, in advance.
2 Since system design comes first, reusable code is easily spotted and coded with the highest
efficiency. You will have lower development costs.
3 Logic 'holes' can be spotted in the design drawings. Your software will behave as you expect it to.
There are fewer surprises.
4 The overall system design will dictate the way the software is developed. The right decisions are
made before you are married to poorly written code. Again, your overall costs will be less.
5 UML lets us see the big picture. We can develop more memory and processor efficient systems.
6 When we come back to make modifications to your system, it is much easier to work on a system
that has UML documentation. Much less 'relearning' takes place. Your system maintenance costs
will be lower.
7 If you should find the need to work with another developer, the UML diagrams will allow them to get
up to speed quickly in your custom system. Think of it as a schematic to a radio. How could a tech
fix it without it?
8 If we need to communicate with outside contractors or even your own programmers, it is much
more efficient.
Using the Unified Modeling Language will result in lower overall costs, more
reliable and efficient software, and a better relationship with all parties
involved. Software documented with UML can be

modified much more

efficiently. Your software will have a future.

Modeling of systems, old way vs. new way

During this course we will deal with systems, or parts of some larger systems.
System is a combination of software and hardware that provides a solution for a
business problem.
Process of developing that system involves a lot of people. First of all is the client, the person who
has the problem to be solved. An analyst documents the client's problem and relays it to developers,
CSE Department,
VNRVJIET

2
www.jntuworld.com

www.jntuworld.com
programmers who build the software that solves the problem, test it and deploy it on computer
hardware. This is necessary because systems today are so complex, knowledge has become so
specialized that one person can't know all the facets of a business, understand the problem, design a
solution, translate it into a program, deploy the program onto hardware, and make sure the hardware
components all work together correctly.

The waterfall method for modeling of systems

The old way of system modeling, known as the waterfall method, specifies that analysis, design,
coding and deployment follow one another. Only when one is complete can the next one begin. If
an analyst hands off analysis to a designer, who hands off a design to a developer, chances are
that the three team members will rarely work together and share important insights. Usually the
adherents of the waterfall method give coding a big amount of project time; it takes a valuable
time away from analysis and design.
In the new way, contemporary software engineering stress continuing interplay among the stages
of development. Analysts and designers, for example, go back and forth to evolve a solid
foundation for the programmers. Programmers, in turn, interact with analysts and designers to
share their insights, modify designs, and strengthen their code. The advantage is that as
understanding grows, the team incorporates new ideas and builds a stronger system.

CSE Department,
VNRVJIET

3
www.jntuworld.com

www.jntuworld.com

UML Diagram Set of Symbols

This is the complete set of symbols that UML introduces in its diagrams.
Structural Elements

Class:
Classes are composed of three things: a name, attributes, and operations. Below is an example of a class.

Interface:
The symbol of interface is

Use case:
A use case is a set of scenarios that describing an interaction between a user and a system. The following is
the symbol for use case.

Node:
The symbol for the node is as shown below.

Component:
The symbol for the component is as shown below.

CSE Department,
VNRVJIET

4
www.jntuworld.com

www.jntuworld.com
Behavioral Elements

State:
The basic elements are rounded boxes representing the state of the object and arrows indicting the transition
to the next state. The activity section of the state symbol depicts what activities the object will be doing while it
is in that state.

Sequence:
The following diagram is a sequence.

Collaboration:
The following notation is collaboration.

Activity:
The following notation is an activity.

CSE Department,
VNRVJIET

5
www.jntuworld.com

www.jntuworld.com

Relationships

Grouping

Extension

Annotation & Actors

The graphical elements combined into diagrams, because the UML is a language, which has rules for
combining these elements.
The purpose of the diagrams is to present multiple views of a system, and this set of multiple views is called a
model.

UML model describes what a system is supposed to do. It doesn't tell how to implement the
system.

Types of UML Diagrams

Each UML diagram is designed to let developers and customers view a software system from a different
perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools
include:

Use Case Diagram:

This displays the relationship among actors and use cases. A use case is a description of a system's behavior
from a user's standpoint. For system developers, this is a valuable tool: it's a tried-and-true technique for
gathering system requirements from a user's point of view. That's important if the goal is to build a system that
real people can use. In graphical representations of use cases a symbol for the actor is used. Use cases are a
relatively easy UML diagram to draw, but this is a very simplified example. This example is only meant as an
introduction to the UML and use cases.

CSE Department,
VNRVJIET

6
www.jntuworld.com

www.jntuworld.com
Start by listing a sequence of steps a user might take in order to complete an action. For example a user
placing an order with a sales company might follow these steps.
1. Browse catalog and select items.
2. Call sales representative.
3. Supply shipping information.
4. Supply payment information.
5. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

This example shows the customer as an actor because the customer is using the ordering system. The
diagram takes the simple steps listed above and shows them as actions the customer might perform. The
salesperson could also be included in this use case diagram because the salesperson is also interacting with
the ordering system.
From this simple diagram the requirements of the ordering system can easily be derived. The system will need
to be able to perform actions for all of the use cases listed. As the project progresses other use cases might
appear. The customer might have a need to add an item to an order that has already been placed. This
diagram can easily be expanded until a complete description of the ordering system is derived capturing all of
the requirements that the system will need to perform.

The actor is the entity that initiates the use case. It can be a person or another system.

CSE Department,
VNRVJIET

7
www.jntuworld.com

www.jntuworld.com
Class Diagram :
Models class structure and contents using design elements such as classes, packages and objects. It also
displays relationships such as containment, inheritance, associations and others. Things naturally fall into
categories (computers, automobiles, trees...). We refer to these categories as classes.

A class is a category or group of things that have similar attributes and common
behaviors.
Class diagrams are widely used to describe the types of objects in a system and their relationships. Class
diagrams model class structure and contents using design elements such as classes, packages and objects.
Class diagrams describe three different perspectives when designing a system, conceptual, specification, and
implementation. These perspectives become evident as the diagram is created and help solidify the design.
This example is only meant as an introduction to the UML and class diagrams.
Classes are composed of three things: a name, attributes, and operations. Below is an example of a class.

Class diagrams also display relationships such as containment, inheritance, associations and others. Below is
an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The association shows the
relationship between instances of classes. For example, the class Order is associated with the class
Customer. The multiplicity of the association denotes the number of objects that can participate in then
relationship. For example, an Order object can be associated to only one customer, but a customer can be
associated to many orders.
Another common relationship in class diagrams is a generalization. A generalization is used when two classes
are similar, but have some differences. Look at the generalization below:

CSE Department,
VNRVJIET

8
www.jntuworld.com

www.jntuworld.com

In this example the classes Corporate Customer and Personal Customer have some similarities such as name
and address, but each class has some of its own attributes and operations. The class Customer is a general
form of both the Corporate Customer and Personal Customer classes. This allows the designers to just use the
Customer class for modules and do not require in-depth representation of each type of customer.

Object Diagram:

An object is an instance of a class - a specific thing that has specific values of the
attributes and behavior.

Interaction Diagrams:
Sequence Diagram displays the time sequence of the objects participating in the interaction. This
consists of the vertical dimension (time) and horizontal dimension (different objects). Class diagrams
and object diagrams represent static information. In a functioning system, however, objects interact with
one another, and these interactions occur over time. The UML sequence diagram shows the timebased dynamics of the interaction. Sequence diagrams demonstrate the behavior of objects in a use
case by describing the objects and the messages they pass. the diagrams are read left to right and
descending. The example below shows an object of class 1 start the behavior by sending a message
to an object of class 2. Messages pass between the different objects until the object of class 1 receives
the final message.

CSE Department,
VNRVJIET

9
www.jntuworld.com

www.jntuworld.com

Below is a slightly more complex example. The light blue vertical rectangles the objects activation while
the green vertical dashed lines represent the life of the object. The green vertical rectangles represent
when a particular object has control. The represents when the object is destroyed. This diagram
also shows conditions for messages to be sent to other object. The condition is listed between brackets
next to the message. For example, a [condition] has to be met before the object of class 2 can send a
message() to the object of class 3.

The next diagram shows the beginning of a sequence diagram for placing an order. The object an
Order Entry Window is created and sends a message to an Order object to prepare the order. Notice
the names of the objects are followed by a colon. The names of the classes the objects belong to do
not have to be listed. However the colon is required to denote that it is the name of an object following
the objectName:className naming system.
Next the Order object checks to see if the item is in stock and if the [InStock] condition is met it sends a
message to create an new Delivery Item object.

CSE Department,
VNRVJIET

10
www.jntuworld.com

www.jntuworld.com

The next diagrams add another conditional message to the Order object. If the item is [OutOfStock] it
sends a message back to the Order Entry Window object stating that the object is out of stack.

This simple diagram shows the sequence that messages are passed between objects to complete a
use case for ordering an item.
Collaboration Diagram displays an interaction organized around the objects and their links to one
another. Numbers are used to show the sequence of messages. The elements of a system work
together to accomplish the system's objectives, and a modeling language must have a way of
representing this. The UML collaboration diagram is designed for this purpose. Collaboration
diagrams:
Collaboration diagrams are also relatively easy to draw. They show the relationship between objects
and the order of messages passed between them. The objects are listed as icons and arrows indicate
the messages being passed between them. The numbers next to the messages are called sequence
numbers. As the name suggests, they show the sequence of the messages as they are passed
between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1,
2, 3... format can be used, as the example below shows, or for more detailed and complex diagrams a
1, 1.1 ,1.2, 1.2.1... scheme can be used.

CSE Department,
VNRVJIET

11
www.jntuworld.com

www.jntuworld.com

The example below shows a simple collaboration diagram for the placing an order use case. This time
the names of the objects appear after the colon, such as :Order Entry Window following the
objectName:className naming convention. This time the class name is shown to demonstrate that all
of objects of that class will behave the same way.

State Diagram:
This displays the sequences of states that an object of an interaction goes through during its life in response to
received stimuli, together with its responses and actions. At any given time, an object is in particular state. State
diagrams represent these states and their changes during time. Every state diagram starts with symbol that
represents start state, and ends with symbol for the end state. For example every person can be a newborn,
infant, child, adolescent, teenager or adult. State diagrams are used to describe the behavior of a system.
State diagrams describe all of the possible states of an object as events occur. Each diagram usually
represents objects of a single class and track the different states of its objects through the system.
When to Use: State Diagrams
Use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only use
state diagrams for classes where it is necessary to understand the behavior of the object through the entire
system. Not all classes will require a state diagram and state diagrams are not useful for describing the
collaboration of all objects in a use case. State diagrams are other combined with other diagrams such as
interaction diagrams and activity diagrams.
How to Draw: State Diagrams
State diagrams have very few elements. The basic elements are rounded boxes representing the state of the
object and arrows indicting the transition to the next state. The activity section of the state symbol depicts what
activities the object will be doing while it is in that state.

CSE Department,
VNRVJIET

12
www.jntuworld.com

www.jntuworld.com

All state diagrams being with an initial state of the object. This is the state of the object when it is created. After
the initial state the object begins changing states. Conditions based on the activities can determine what the
next state the object transitions to.

Below is an example of a state diagram might look like for an Order object. When the object enters the
Checking state it performs the activity "check items." After the activity is completed the object transitions to the
next state based on the conditions [all items available] or [an item is not available]. If an item is not available
the order is canceled. If all items are available then the order is dispatched. When the object transitions to the
Dispatching state the activity "initiate delivery" is performed. After this activity is complete the object transitions
again to the Delivered state.

CSE Department,
VNRVJIET

13
www.jntuworld.com

www.jntuworld.com

State diagrams can also show a super-state for the object. A super-state is used when many transitions lead to
the a certain state. Instead of showing all of the transitions from each state to the redundant state a super-state
can be used to show that all of the states inside of the super-state can transition to the redundant state. This
helps make the state diagram easier to read.
The diagram below shows a super-state. Both the Checking and Dispatching states can transition into the
Canceled state, so a transition is shown from a super-state named Active to the state Cancel. By contrast, the
state Dispatching can only transition to the Delivered state, so we show an arrow only from the Dispatching
state to the Delivered state.

CSE Department,
VNRVJIET

14
www.jntuworld.com

www.jntuworld.com
Activity Diagram:
This displays a special state diagram where most of the states are action states and most of the transitions are
triggered by completion of the actions in the source states. This diagram focuses on flows driven by internal
processing. The activities that occur within a use case or within an object's behavior typically occur in a
sequence. This sequence is represented with activity diagrams. State diagrams are used to describe the
behavior of a system. State diagrams describe all of the possible states of an object as events occur. Each
diagram usually represents objects of a single class and track the different states of its objects through the
system.

Activity diagrams describe the workflow behavior of a system. Activity diagrams are similar to state diagrams
because activities are the state of doing something. The diagrams describe the state of activities by showing
the sequence of activities performed. Activity diagrams can show activities that are conditional or parallel.
When to Use: Activity Diagrams
Activity diagrams should be used in conjunction with other modeling techniques such as interaction diagrams
and state diagrams. The main reason to use activity diagrams is to model the workflow behind the system
being designed. Activity Diagrams are also useful for: analyzing a use case by describing what actions need to
take place and when they should occur; describing a complicated sequential algorithm; and modeling
applications with parallel processes.
However, activity diagrams should not take the place of interaction diagrams and state diagrams. Activity
diagrams do not give detail about how objects behave or how objects collaborate.
How to Draw: Activity Diagrams
Activity diagrams show the flow of activities through the system. Diagrams are read from top to bottom and
have branches and forks to describe conditions and parallel activities. A fork is used when multiple activities
are occurring at the same time. The diagram below shows a fork after activity1. This indicates that both
activity2 and activity3 are occurring at the same time. After activity2 there is a branch. The branch describes
what activities will take place based on a set of conditions. All branches at some point are followed by a merge
to indicate the end of the conditional behavior started by that branch.

After the merge all of the parallel

activities must be combined by a join before transitioning into the final activity state.

CSE Department,
VNRVJIET

15
www.jntuworld.com

www.jntuworld.com

Below is a possible activity diagram for processing an order. The diagram shows the flow of actions in the
system's workflow. Once the order is received the activities split into two parallel sets of activities. One side
fills and sends the order while the other handles the billing. On the Fill Order side, the method of delivery is
decided conditionally. Depending on the condition either the Overnight Delivery activity or the Regular Delivery
activity is performed. Finally the parallel activities combine to close the order.

CSE Department,
VNRVJIET

16
www.jntuworld.com

www.jntuworld.com

Physical Diagrams:
There are two types of physical diagrams: deployment diagrams and component diagrams. Deployment
diagrams show the physical relationship between hardware and software in a system. Component diagrams
show the software components of a system and how they are related to each other. These relationships are
called dependencies.
When to Use: Physical Diagrams
Physical diagrams are used when development of the system is complete. Physical diagrams are used to give
descriptions of the physical information about a system.
How to Draw: Physical Diagrams
Many times the deployment and component diagrams are combined into one physical diagram. A combined
deployment and component diagram combines the features of both diagrams into one diagram.

Deployment Diagram displays the configuration of run-time processing elements and the
software components, processes, and objects that live on them. Software component instances
represent run-time manifestations of code units. The UML deployment diagram shows the
physical architecture of a computer-based system. It can depict the computers and devices,
show their connections with one another, and show the software that sits on each machine.

CSE Department,
VNRVJIET

17
www.jntuworld.com

www.jntuworld.com
The deployment diagram contains nodes and connections. A node usually represents a piece of hardware in
the system. A connection depicts the communication path used by the hardware to communicate and usually
indicates a method such as TCP/IP.

The component diagram contains components and dependencies. Components represent the physical
packaging of a module of code. The dependencies between the components show how changes made to one
component may affect the other components in the system. Dependencies in a component diagram are
represented by a dashed line between two or more components. Component diagrams can also show the
interfaces used by the components to communicate to each other.
The combined deployment and component diagram below gives a high level physical description of the
completed system. The diagram shows two nodes which represent two machines communicating through
TCP/IP. Component2 is dependant on component1, so changes to component 2 could affect component1. The
diagram also depicts component3 interfacing with component1. This diagram gives the reader a quick overall
view of the entire system.

CSE Department,
VNRVJIET

18
www.jntuworld.com

www.jntuworld.com

Component Diagram displays the high level packaged structure of the code itself. Dependencies
among components are shown, including source code components, binary code components, and
executable components. Some components exist at compile time, at link time, at run times well as at
more than one time. Today in software engineering we have team-based development efforts, where
everyone has to work on different component. That's important to have a component diagram in
modeling process of the system.

System development is a human activity. Without an easy-to-understand

notation system, the development process has great potential for error.
Consisting of a set of diagrams, the UML provides a standard that
enables the system analyst to build a multifaceted blueprint that's
comprehensible to clients, programmers, and everyone involved in the development process.
It's necessary to have all these diagrams because each one speaks to a different stakeholder
in the system. The UML model tells what a system is supposed to do. It doesn't tell how.

Class Diagrams
During this several days you'll firm up your knowledge of object-orientation as you learn more about
the UML.
Next lessons will deal with class diagrams. How to extract classes, their attributes and methods from
interviewing a client, and then bind the classes with relationships to form the class diagram. You'll
learn more about:
1
Visualising a Class (attributes and operations)
2
Associations
CSE Department,
VNRVJIET

19
www.jntuworld.com

www.jntuworld.com
3
Inheritance & Generalization
4
Agregations
5
Interfaces & Realizations
6
Visibility
The last part of this group of lessons consits of an example, which give you all the necessary steps
for building a class diagram.

Visualising a Class
We mentioned in earlier lessons that things fall into categories - classes. The UML class diagram
consists of several classes conected with relationships. But how UML represents a class?
The rectangle is the icon for the class. The name of the class is, by convention, a word
with an initial uppercase letter. It appears near the top of the rectangle. If your class
name has more than one word name, then join the words together and capitalize the first
letter of the every word.
Class name is written at the top of the rectangle
An attribute is a property of a class. It describes a range of values that the property may hold in
objects of the class. A class may have zero or more attributes.
A one-word attribute name is written in lowercase letter. If the name consists of more
than one word, the words are joined and each word other than the first word begins with
an uppercase letter. The list of attribute names begins below a line separating them from
the class name.

In the class icon, you can specify a type for each attribute's value (string,
floating-point, number, integer, boolean or user defined types). Also you
can indicate a default value for an attribute.
An operation is something that a class can do, or that you (or naother class) can do to a class.
Like an attribute name, an operation's name is written in lowercase letter. If the name consists of
more than one word, the words are joined and each word except the first word begins with an
uppercase letter. The list of operations begins below a line separating operations from the attributes.

Also operations may have some aditional information. In the parentheses

that follow an operation name, you can show the parameter that the
operation works on, along with the parameter's type. If the operation is
function, then we must specify the type of the returned value.
Other additional features that can be attached to attributes of the class are constraints and notes.
Constraints are free form text enclosed in braces. The backeted text specifies one or more rules the
class follows.
Notes usually are attached to attributes as well as operations, and they give aditional information to a
class. A note can contain a graphic as well as text.
How can we derives classes from interviewing the clients?
In conversations with clients, be alert to the nouns they use to describe the
entities in their business. Those nouns will become the classes in your model. Be
alert also to the verbs that you hear, because these will constitute the operations
in those classes. The attributes will emerge as nouns related to the class nouns.

CSE Department,
VNRVJIET

20
www.jntuworld.com

www.jntuworld.com

Associations
When classes are connected together conceptually, that connection is called an association.
You visualize the association as a line connecting the two classes, with the name of the
association just above the line.
When one class associates with another, each one
usually plays a role within that association. You can
show those roles on the diagram by writing them near the
line next to the class that plays the role.
Association may be more complex than just one class connected to another. Several classes can
connect to one class.
Sometimes an association between two classes has to follow a rule. You indicate that rule by putting
a constraint near the association line.
Just like a class, an association
can have attributes and
operations. In this case we have an
association class.

You visualize association class the same way you show a regular class, and you use dotted line to
connect it to the association line.
Multiplicity is a special type of association which shows the number of objects from one class that
relate with a number of objects in an associated class.
One class can be relate to another in a
one-to-one
one-to-many
one-to-one or more
one-to-zero or one
one-to-a bounded interval (one-to-two through twenty)
one-to-exactly n
one-to-a set of choices (one-to-five or eight)
The UML uses an asterisk (*) to represent more and to represent many.
Sometimes, a class is in association with itself. This can happen when a class has objects that can
play a variety of roles. These associations are called reflexive associations.
Reflexive association

Without relationships, a class model would be a list of rectangles that represent a

vocabulary of system. Relationships show how the terms in the vocabulary
connect with one another to provide a picture of the slice of the world you're

CSE Department,
VNRVJIET

21
www.jntuworld.com

www.jntuworld.com
modeling. The association is the fundamental conceptual connection between classes. Each
class in an association plays a role, and multiplicity specifies how many objects in one class
relate to one object in the associated class. Many types of associates are possible.

Inheritance & Generalization

If you know something about a category of things, you automatically know some things you can
transfer to other categories.
If you know something is an animal, you take for granted that it eats, sleeps, has a way of being born,
has a way of getting from one place to another... But imagine that mammals, amphibians and reptiles
are all animals. Also cows, dogs, cats... are grouped in category mammals. Object-orientation refers
to this as inheritance.

An inheritance hierarchy in the animal kingdom

One class (the child class or subclass) can inherit attributes and operations from another
(the parent class or superclass). The parent class is more general then the child class.
In generalization, a child is substitutable for a parent. That is, anywhere the parent
appears, the child may appear. The reverse isn't true, however.
In UML inheritance is represented with a line that connects the parent to a child class, and on the
parent's side you put an open triangle.
If we look from the association's side, the inheritance stands for is a kind of association.
What should analysts do to discover inheritance?
The analyst has to realize that the attributes and operations of one class are general and apply to
perhaps several other classes - which may add attributes and operations of their own. Another
possibility is that the analyst notes that two or more classes have a number of common attributes and
operations.
Classes that provide no objects are said to be abstract classes. You indicate an abstract
class by writing its name in italics.
A class can inherit attributes and opeartions from another class. The inheriting
class is the child of the parent class it inherits from. Abstract classes are
intended only as bases for inheritance and provide no objects of their own.

Aggregations
Sometimes a class consists of a number of component classes. This is a special type of relationship
called aggregation. The components and the class they constitute are in a part-whole association.
Aggregation is represented as a hierarchy with the "whole" class at the top, and the
component below. A line joins a whole to a component with an open diamond on the line
near the whole.
Let's take a look at the parts consisting a TV set. Every TV has a TV box, screen, speaker(s),
resistors, capatitors, transistors, ICs... and possibly a remote control. Remote control can have these
parts: resistors, capatitors, transistors, ICs, battery, keyboard and remote lights.

CSE Department,
VNRVJIET

22
www.jntuworld.com

www.jntuworld.com
An aggregation
association in the TV
Set system

Sometimes the set of possible components in an aggregation falls into an OR relationship. To model
this, you would use a constraint - the word OR within braces on a dotted line that connects the two
part-whole lines.
A composite is a strong type of aggregation. Each component in a composite can belong
to just one whole. The symbol for a composite is the same as the symbol for an
aggregation except the diamond is filled.
If you examine the human's outside you'll find out that every person has: head, body, arms and legs.
This is shown on this picture.

A composite association. In this association each

component belongs to exactly one whole.
An aggregation specifies a part-whole association. A "whole" class is made up of
component classes. A composite is a strong form of aggregation, and a
component in a composite can be part of only one whole. Aggregations and
composites are represented as lines joining the whole and the component with open and filled
diamond, respectively, on the whole side.

Interfaces and Realizations

In previous lessons we learned how to refine classes from the interview with client, and relate them
with different relationships between them. But it's possible that some of classes are not related to a
particular parent, but their behaviors might include some of the same operations with the same
signatures. You can code the operations for one of the classes and reuse them in the others.
An interface is a set of operations that specifies some aspect of a class behaviour, and it's
a set of operations a class presents to other classes.
You model an interface the same way you model a class, with the rectangle icon, but
interface has no attributes, only operations. Another way is with a small circle joined with line to a
class.
The computer's keyboard is a reusable interface. Its keystroke operation has been reused from the
typewriter. The placement of keys is the same as on a typewriter, but the main point is that the
keystroke operation has been transfered from one system to another. Also on computer's keyboard
you'll find a number of operations that you won't find on a typewriter (Ctrl, Alt, PageUp, PageDown...)

An interface is a collection of operations that a class carries

out
CSE Department,
VNRVJIET

23
www.jntuworld.com

www.jntuworld.com
To distinguish interfaces from classes, in stereotype construct we put <<interface>> or I at the
begining of the name of any interface.
The relationship between a class and an interface is called realization. This relationship is
modeled as a dashed line with a large open triangle adjoining and pointing to the interface.

Visibility
Visibility applies to attributes or operations, and specifies the extent to which other classes can use a
given class's attributes or operations.
Three levels of visibility are possible (last symbols are used in UML classes to indicate different levels
of visibility):
public level
+
usability extends to other classes
protected level
#
usability is open only to classes that inherit from original class
private level
only the original class can use the attribute or operation

Public and private operations in a HardDisk

Use Case Diagrams

Class diagrams provide a static view of the classes in a system. Next diagrams provide a dynamic
view and show how the system and its classes change over time.
The static view helps an analyst communicate with a client. The dynamic view, helps an
analyst communicate with a team of developers, and helps the developers create programs.
Just as the class diagram is a great way to stimulate a client to talk about a system from his or her
viewpoint, the use case is an excellent tool for stimulating potential users to talk about a system from
their own viewpoints. It's not always easy for users to articulate how they intend to use a system. It's
a fact of life that users often know more than they can articulate: The use case helps break the ice.
Interviews with users begin in the terminology of the domain, but should then shift into the
terminology of the users. The initial results of the interviews should reveal actors and high-level use
cases that describe functional requirement in general terms. this information provides the boundaries
and scope of the system.
Later interviews with users delve into these requirement more closely, resulting in use case models
that show the scenarios and sequences in detail. This might result in additional use cases that satisfy
inclusion and extension relationships. In this phase it is important to your understanding of the
domain, because if you don't understand it well you may create too much use cases and that could
impede the analysis process.
Use case are collection of scenarios about system use. Each scenario describes a sequence of
events. Each sequence is initiated by a person, another system, a piece of hardware, or by the
passage of time. Entities that initiate sequences are called actors. The result of the sequence has to
be something of use either to the actor who initiated it or to another actor.
It's possible to reuse use cases. One way - inclusion, is to use the steps from one use case as part
of the sequence of steps in another use case. Another way - extension, is to create a new use case
by adding steps to an existing use case.

Next lessons will guide you through representing a use case

model and visualizing relationships among use cases. At the
CSE Department,
VNRVJIET

24
www.jntuworld.com

www.jntuworld.com

end an use case example will be given to you.

Introducing a Use Case Model
An actor initiates a use case, and an actor (possibly the initiator, but not necessarily) receives
something of value from the use case.

Use Case model

An ellipse represents a use case, a stick figure represents an actor. The initiating actor is
on the left of the use case, and the receiving actor is on the right. The actor's name
appears just below the actor. The name of the use case appears either inside the ellipse
or just below it. An association line connects an actor to the use case, and represents communication
between the actor and the use case. The association line is solid, like the line that connects
associated classes.
Each use case is a list of scenarios, and each scenario is a sequence of steps. Each scenario of each
use case will also have its own page, listing in text from the:
Actor who initiates the use case
Preconditions for the use case
Steps in the scenario
Postconditions when the scenario is complete
Actor who benefits from the use case
Use case diagrams add more power to the requirements gathering. They
visualize use cases, they facilitate communication between analysts and users
and between analysts and clients. In a use case diagram, symbol for the use
case is an ellipse, actor has a stick figure as a symbol, and association line joins an actor to a
use case. The use cases are usually inside a rectangle that represents the system boundary.

Relationships Among Use Cases

In lesson Use case diagrams, we mentioned that it is possible to reuse use case diagrams. One way
was inclusion, another was extension. These are relationships among use cases, and there are two
other kinds of relationships: generalization and grouping.
Inclusion
Inclusion enables you to reuse one use case's steps inside another use case.
To represent inclusion, you use the symbol you used for dependency between classes dotted line connecting the classes with an arrowhead pointing to the depended-on class.
Jus above the line, you add a stereotype-the word <<include>> enclosed in guillements.
Extension
Extension allows you to create a new use case by adding steps to an existing use case.
Also here a dotted arrowhead line is used to represent extension, along with a stereotype
that shows <<extends>> in guillements. Within the base use case, the extension point
appears below the name of the use case.
Generalization
Classes can inherit from one another and so can use cases. In use case inheritance, the child use
case inherits behavior and meaning from the parent, and adds its own behavior. You can apply the
child wherever you apply the parent.
Generalization is modeled the same way you model class generalization - with a solid line
that has an open triangle pointing at the parent.
The generalization relationship can exist between actors as well as use cases.
Grouping
In some use case diagrams, you might have a multiple of use cases and you'll want to organize them.
This could happen when a system consists of a number of subsystems.

CSE Department,
VNRVJIET

25
www.jntuworld.com

www.jntuworld.com
The most straightforward way is to organize group related use cases into a package (a tabbed
folder).
In next lesson Use Case Diagrams - Example we'll look closely to all of these relationships, to help
you understand use cases as a part of use case diagrams.

Use Case Diagram - Example

In this example we're going to model out use case diagrams for a self-service machine.
The main functions of self-service machine is to allow a customer to by a product(s) from the machine
(candy, chocolate, juice...). Every user that you asked for a set of scenarios happening during usage
of machine, can tell you that main use case can be labeled as "Buy a product". Let's examine every
possible scenario in this use case. These scenarios would be revealed trough conversations with
users.
The "Buy a product" use case
The actor in this use case is customer. This customer wants to buy some of the products offered by
the self-service machine. First of all he/she inserts money into the machine, selects one or more
products, and machine presents a selected product(s) to the customer. Use case diagram for this
scenario can be represented as:

The Buy a Product use case diagram

But if we think a little, others scenarios immediatelly come to mind. It's possible that the self-service
machine is out of one or more products, or the machine hasn't the exact amount of money to return to
customer.
-Are we supposed to handle with these scenarios?
If we are, then let's return at the moment when the customer inserts money into machine and enters
his or hers selection. After this imagine that machine is out of brand. In this case it's preferable to
present a message to the customer that machine is out of brand and allow him or her to make
another selection or return money back. If incorrect-ammount-of-money scenario has hapenned, then
self-service machine is supposed to return original ammount of money to the customer.
The precondition here is hungry or thirsty customer, and postcondition is either product from the
machine or the returned money.
This is use case scenario from one user's viewpoint (the customer). Buth there are other users too. A
supplier has to restock the machine, and a collector has to collect the accumulated money from the
machine. This tells us to create at least two more use cases: "Restock" and "Collect money". Let's
look closely at both of them, by interviewing both suppliers and collectors.
The "Restock" use case
Actions that supplier must do every time interval (say, one or two weeks) are: Supplier unsecures the
machine, opens the front of the machine, and fills each brand's compartment to capacity. (The
supplier may fill each brand according to consuming of article). Then he/ she closes the front of the
machine and secures it.
The precondition is the passage of the interval, and the postcondition is that the supplier has a new
set of potential sales.
This use case diagram is presented on the following picture:

The Restock use case diagram

The "Collect Money" use case
Responsible for this use case is collector. Collector may be the same person as the supplier. The
steps that collector must do are same as the steps of supplier, but the collector don't deal with
products, he/ she deals with money. When the time interval has passed this person collects the
necessary ammount of money from the machine.
CSE Department,
VNRVJIET

26
www.jntuworld.com

www.jntuworld.com
The postcondition here is the money in hands of the collector.
Collect money use case diagram is following:

The Collect Money use case diagram

The steps of unsecuring the machine, front opening, closing and securing the machine are the same
that supplier and collector must do. This is a good place to include a use case. Let's combine the
"unsecure" and "pull open" steps into use case called "Expose the inside" and the "close machine"
and "secure" with use case "Unexpose the inside".
By including a use case Restock and Collect use cases may look as this:

The inclusion process in Restock and Collect Money use

cases
The Restock use case could be basis of another use case: "Restock according to sales". Here
supplier may fill up brands with new products according of sale of that products. This is an extension
of a use case.
After inclusion and extension the Restock use case can be:

The extension process in Restock use case

Also and generalization may take place to the actors supplier and collector. If both of them are the
same person, let's say Supplier Agent, then the restocker and the supplier are both children of the
Supplier Agent. This is showh on next picture:
A generalization between supplier and collector

We reached the end of our analysis for the self-service machine. Completed use case diagram (Click
for the entirely use case diagram) shows the functional requirements of the system, and we are able
to make next move - design and development.

CSE Department,
VNRVJIET

27
www.jntuworld.com

www.jntuworld.com

State Diagrams
In next lessons you'll work with elements that you haven't worked before. That would be behavioral
elements, that show how parts of a UML model change over time. As the system interacts with users
and possibly with other systems, the objects that make up the system go through necessary changes
to acommodate the interactions. If you're going to model systems, you must have a mechanism to
model change. That mechanism in UML is State diagrams.
- When you pull a switch, a light changes its state from off to on.
- When you make keystroke or mousemovement in screen saver mode on your computer, your
computer leaves screen saver mode and returns to working - active mode.
The UML State diagram presents the states an object can be in along with the transitions between
the states, and shows the starting point and endpoint of a sequence of state changes.
A state diagram shows the states of a single object.
States in the state diagram are represented with a rounded rectangle, and the symbol for
the transition is a solid arrowhead line. A solid circle stands for starting point of a
sequence of states, and bull's eye represents the endpoint.

The UML symbols in a state diagram. The top area stands for the state's
name, middle area is for state variables, and the bottom is for activities.
Transitions are represented with solid arrowhead lines, and circles are for
starting and ending state.
Also you can add details to a state icon by dividing it to a three areas. The top area holds the name of
the state (this name you must supply whatever the class is divided or not), the middle area hold state
variables (timers, counters, dates...), and the bottom area hold activities (entry-what happenes when
the system enters the state, exit-what happenes when the system leaves the state, do-what
happenes when the system is in the state).

State Details and Transitions

You can indicate an event that causes a transition to occur (a trigger event) and the computation
(the action) that executes and makes the state change happen.

CSE Department,
VNRVJIET

28
www.jntuworld.com

www.jntuworld.com
To add events and actions you write them near the transition line, using a slash to separate
a triggering event from an action.
Sometimes an event causes a transition without an associated action, and sometimes a transition
occurs because a state completes an activity (rather than because of an event). This type of transition
is caled triggerless transition.
Also possible is a guard condition. When it's met, the transition takes place. (For example screen
saving mode is activated when time interval of n idle minutes has passed).
Some of the states may be more complex that is represented with a rounded rectangle. It is possible
to have states inside one state. These states are called substates (sequential and concurrent).
Sequential substates come in sequences of states which occur one after another.
Concurrent substates must consist of two or more sequential substates which occur at
the same time. This is represented with dotted line between the concurent states.
If you have any problems understanding these concepts please refer to the State Diagram - Example
lesson.
The UML supplies a symbol that shows that a composite state remembers its active substate when
the object transitions out of the composite state. The symbol is
connected by a solid line to the
remembered substate, with an arrowhead that points to the substate.
A message that triggers a transition in the receiving object's state diagram is called a signal. In the
object-oriented world, sending a signal is the same as creating a signal object and transmitting it to
the receiving object. The signal object has properties that are represented as attributes. Because a
signal is an object, it's possible to create inheritance hierarchies of signals.

State Diagram - Example

Suppose you're designing a toaster. You would build a plenty of UML diagrams, but here only state
diagrams will be of our interest.
- What are the steps of making a toast?
First of all we must turn on the toaster, put in the bread and wait for several minutes to bake it. The
initial state diagram is shown below:

The initial state diagram for making a toast

But this is not the final state diagram. To prevent burning out the bread, heater of the toaster must
produce heat in temperature interval (upper and lower temperature limits). For this purpose
thermometer measures the temperature of heater, and when the upper limit of temperature is
reached then heater must go into idle state. This state resists until heater's temperature decreases to
lower limit, and then working state is again aimed. With this new state, extended state diagram will
be:

The extended state diagram for making a toast

CSE Department,
VNRVJIET

29
www.jntuworld.com

www.jntuworld.com
Transition between working and idle state is not presented in details. To do this substates must be
added.

Substates in Working and Idle states

Substates in working and idle states are very similar. both had measure and compare states, but
differentiates in process of temperature comparison. Working state must compare current
temperature with upper temperature limit (if it is reached, working state goes into idle state), and idle
state compares current temperature with lower temperature limit (idle state is replaced with working
state when temperature falls under lower limit).
It's necessary to have state diagrams because they help analysts, designers and
developers understand the behavior of the objects in a system. Developers, in
particular, have to know how objects are supposed to behave because they have
to implement these behaviors in software. It's not enough to implement an object: Developers
have to make that object do something.

Sequence Diagrams
In previous lesson we learned state diagrams, which focus on the states of na object. But it's
necessary to have communication between objects. The UML sequence diagram goes the next step
and shows how objects communicate with one another over time. In this expanded field of view, you'll
include an important dimension: time. The key idea here is that interactions among objects take place
in a specified sequence, and the sequence takes time to go from beginning to end.
The sequence diagram consists of objects represented in the usual way - as named
rectangles (with the name underlined), messages represented as solid-line arroes, and
time represented as a vertical progression.
Let's take a close look at this parts of sequence diagrams.
Objects
The objects are laid out near the top of the diagram from left to right. They're arranged in any order
that simplifies the diagram. Extending downforward from each object is a dashed line called the
object's lifeline. Along the lifeline is narrow rectangle called an activation. The activation represents
an execution of an operation the object carries out. The length of the rectangle signifies the
activation's duration. This is shown on next picture.

Representing an object in a sequence diagram

CSE Department,
VNRVJIET

30
www.jntuworld.com

www.jntuworld.com
Messages
A message that goes from one object to another goes from one object's lifeline to the other object's
lifeline. An object can send a message to itself-that is, from its lifeline back to its own lifeline. This is
called recursion. See recursion example.
Following table lists all of possible messages existing in the UML sequence diagrams, with their
graphical representations:
simple

This is a transfer of control from one object to another.

If an object sends a synchronous message, it waits for an answer to that

message before it proceeds with its business.
If an object sends an asynchronous message, it doesn't wait for an
asynchronous
answer before it proceeds.
Time
The diagram represents time in the vertical direction. Time starts at the top and progresses toward
the bottom. A message that's closer to the top occurs earlier in time than a message that's closer to
the bottom.
synchronous

The essential symbol set of the sequence diagram, with the symbols
working together.
The actor-symbol initiates the sequence, but the stick figure isn't part of the sequence
diagram symbol set.
In a sequence diagram, the objects are laid out from left to right across the top.
Each object' lifeline is a dashed line extending downward from the object. A solid
line with an arrowhead connects one lifeline to another, and represents a message
from one object to another. Time starts at the top an proceeds downward. Although an actor
typically initiates the sequence, the actor symbol isn't part of the sequence diagram's symbol
set.

Activity Diagrams
If you've ever taken an introductory course in programming, you've probably encountered the
flowchart. The flowchart shows a sequence of steps, processes, decision points and branches.
Novice programmers are encouraged to use flowcharts to conceptualize problems and derive
solutions.
The UML activity diagram is much like the flowcharts of old. It shows steps (called, appropriately
enough, activities) as well as decision points and branches. It's useful for showing what happens in a
business process or an operation. You'll wind it an integral part of system analysis.
First and foremost, an activity diagram is designed to be a simplified look at what happens during an
operation or a process. It's an extension of the state diagram. The state diagram shows the states of
an object and represents activities as arrows connecting the states. The activity diagram highlight the
activities.
Each activity is represented by a rounded rectangle - narrower and more oval-shaped
than the state icon. The processing within an activity goes to completion and then an
automatic transmission to the next activity occurs. An arrow represents the transition from
one activity to the next. Also an activity diagram has a strating point represented by filled-in circle,
and endpoint represented by a bull's eye.

CSE Department,
VNRVJIET

31
www.jntuworld.com

www.jntuworld.com
Transition from one activity to another in the Activity Diagram

In next lesson will be explained ways of creating an activity diagram, rules between activities, and at
the end an example for this diagram will be given to you.
The activity diagram is an extension of the state diagram. State diagrams
highlight states and represent activities as arrows between states. Activity
diagrams put the spotlight on the activities. Each activity is represented as a
rounded rectangle, more oval in appearance than the state icon. The activity diagram uses the
same symbols as the state diagram for the startpoint and the endpoint.

Building an Activity Diagram

In this lesson will be explained ways of representing decisions, concurrent paths, signals and
swimlanes in the activity diagrams.
Decisions
Decision point can be represented in two ways, it's all to you to make decision what way to use in
your activity diagrams.
One way is to show the possible paths coming directly out of an activity. the other is to have
the activity transition to a small diamond and have the possible paths flow out of the
diamond. Either way, you indicate the condition with a bracketed condition statement near
the appropriate path.
Imagine that you have to go to the work. You get your car, put the key in the ignition, and there are
two possible situations: your car will start or it will not start it's engine. These possible cases will
produce two other activities: drive a car, or go by a bus, taxi, bike or go walking. This scenario is
shown on this picture (make attention of two ways showing a decision):

Activity diagram showing two ways of decision

Concurrent paths
When you modeling activities, very frequently you'll have a occasion to separate a transition into two
separate paths that run at the same time (concurrently), and the come together.
Split is represented by a solid bold line perpendicular to the transition and show the paths
coming out of the line. To represent the merge, show the paths pointing at another solid
bold line.

CSE Department,
VNRVJIET

32
www.jntuworld.com

www.jntuworld.com

Activity diagram representing a transition split into two paths

that run concurrently and then come together
Signals
During a sequence of activities, it's possible to send a signal. When received, the signal causes an
activity to take a place.
The symbol for sending a symbol is a convex pentagon, and the symbol for receiving a
signal is a concave polygon.
Sending and receiving a signal
Swimlanes
The activity diagram adds the dimension of vizualizing roles. To do that, you separate the diagram
into parallel segments called swimlanes. Each swimlane shows the name of a role at the top, and
represents the activities of each role. Transitions can take place from one swimlane to another.
It's possible to combine the activity diagram with the symbols from other diagrams and thus produce a
hybrid diagram.
Following lesson will give you a written example for an activity diagram.

Activity Diagram - Example

This example will deal with mathematics. Sometimes (when calculating combinations) you'll need to
calculate a factoriel of n - n!.
The formula for this is n!=n*(n-1)*(n-2)*...*2*1.
Let's dive into the problem. From definition of factoriels we have 0!=1 and 1!=1. For the rest of the
numbers we must use the given formula. In computer programming this problem is written with
recursion. Here also when building an activity diagram recursion will be introduced. You might call the
operation computeFact(n). You'll need a counter to keep track of whether or not the operation has
reached the nth factoriel, a variable that keep a track of your computations, and two more to store the
values of 0! and 1!.
The complete activity diagram is shown on next picture:

CSE Department,
VNRVJIET

33
www.jntuworld.com

www.jntuworld.com

If you're dealing with computer programming you will conclude that this activity diagram is very similar
with a procedure (function) that computes factoriels.

More About Interfaces and Components

In previous lessons, you learned about diagrams that deal with conceptual entities. In next lessons,
you're going to learn about a UML diagram that represent a real-world entity: software component.
But what is a software component?
A software component is a physical part of a system. It resides in a computer, not in the mind of an
analyst.
What's the relationship between a component and a class?
Think of a component as the software implementation of a class. The class
represents an abstraction of a set of attributes and operations. And one component
can be implementation of more than one class.
You model components and their relationships so that:
1 Clients can see the structure in the finished system
2 Developers have a structure to work toward
3 Technical writers who have to provide documentation and help files can understand what they're
writing about
4 You're ready for reuse
When you deal with components, you have to deal with their interfaces. Interface is the object's "face"
to the outside world, so that other objects can ask the object to execute its operations, which are
hiden with encapsulation.
An interface is a set of operations that specifies something about a class's behavior. It is a set of
operations the a class represent to other classes. For you as a modeler, this means that the way you
represent an interface for a class is the same as the way you represent an interface for a component.
As is the case with a class and its interface, the relation between a component and its interface is
called realization. See, Interfaces & Realizations.
You can replace one component with another if the new component conforms to the
same interfaces as the old one. You can reuse a component in another system if the new
system can access the reused component trough that component's interfaces.
As you progress in your modeling career, you'll deal with three kinds of components:
1 Deployment components, wich form the basis of executable systems (DLL's, executables,
ActiveX controls, JavaBeans)
2 Work product components, from which deployment components are created (data files and
source code files)
CSE Department,
VNRVJIET

34
www.jntuworld.com

www.jntuworld.com
3 Execution components, created as result of a running system
Instead of representing a conceptual entity such as a class or a state, a
component diagram represents a real-world item - a software component.
Software components reside in computers, not in the minds of analysts.
A component is accessible trough its interface. The relation between a component and its
interface is called realization. When one component access the services of another, it uses an
import interface. the component that realizes the interface with those services provides an
export interface.

Collaboration Diagrams
Collaboration diagrams like the sequence diagrams, shows how objects interact. It shows the objects
along with the messages that travel from one to another. But, if sequence diagram does that, why
UML need another diagram? Don't they do the same thing?
The sequence diagram and the collaboration diagram are similar. They're semantically
equivalent, that is, the present the same information, and you can turn a sequence to a
collaboration diagram and vice versa. The main distinction between them is that the
sequence diagram is arranged according to time, the collaboration diagram according to space.
A collaboration diagram is an extension of object diagram. In addition to the associations among
objects, collaboration diagram shows the messages the objects send each other.
Messages among objects are represented with arrows that points to receiving object, near
the association line between two objects. A label near the arrow shows what the message
is. The message typically tells the receiving object to execute one of its operations. A pair
of parentheses ends the message. Inside the parentheses, you put the parameters the opearation
works on.
Collaboration diagrams can be turned into sequence diagrams and vice versa. Thus, you have to be
able to represent sequence information in a collaboration diagram. To do this you must know that:
Add a number to the label of a message, with the number corresponding to the message's
order in the sequence. A colon separates the number from the message.
This is the basis of collaboration diagrams. In addition next two lessons will describe the process of
writing collaboration diagrams.

Writing Collaboration Diagrams

You can show an object's change of state in a collaboration diagram, also you can show
conditions the same way you represent them in sequence diagram.
In the object rectangle, indicate the state of the object. To the diagram, add another
rectangle that stands for the object and indicate the changed state. Connect the two with
the dashed line and label the line with a <<become>> stereotype.
You put the condition inside a pair of square brackets, and the conditionprecedes the message-label.
The important thing is to coordinate the conditions with the numbering.
To get closer to this concepts please refer to the Collaboration Diagram - Example.
Also you can present object creation.
In object's creation process you add a <<create>> stereotype to the message that creates
the object.
In the collaboration diagram, you can represent multiple objects and returned results.
The representation of multiple objects is a stack of rectangles extending "backward". You add a
bracketed condition preceded by an asterisk to indicate that the message goes to all objects.
Returned results are written as expression that has a name of the returned value on the left, followed
by :=, followed by the name of the operation, and a list of possible attributes that operation can
accept, to produce the result.The right side of the expression is called a message-signature.
A proffesor asks a group of students to
hand in an assignment.
CSE Department,
VNRVJIET

35
www.jntuworld.com

www.jntuworld.com

A message can be a request for an object to

perform a calculation and return a value.
In some interactions, a specific object controls the flow. This active object can send messages to
passive objects and interact with other active objects. Also you might run into an object sending a
message only after several other (possibly nonconsecutive) messages have been sent. That is, the
object must sinchronize its message with a set of other messages.
The collaboration diagram represents an active object the same way as other, except that
its border is thick and bold.
Sinchronizing messages, are precede with a list of the messages that have to be
completed prior to that message take place. A comma separates one list-item from
another, and the list ends with a slash.
Now when you have all this concepts, you're ready to go to the next lesson the Collaboration Diagram
- Example.

Collaboration Diagram - Example

Self-service machine again will be target for this example. In previos example (See, Sequence
Diagram - Example) the sequence diagram for this system was built. This is good time to try the ways
of converting sequences into collaboration diagrams.
The best-case scenario consists of several steps:
1 The customer inserts money in the machine and makes selection of one or more product(s)
present in the machine.
2 When the register gets the money (in this case customer puts the correct amount of money,
and there is allways a product in the selected brand), the selected product is delivered to the
dispenser.
3 The dispenser delivers the product to the front of the machine, and the customer gets that
product.

But when we examined this machine and its work in detail, new scenarios were introduced: incorectamount-of-money and out-of-product scenario. While building the sequence diagrams, conditions
were introduced to display the work of the machine. Here conditions will be used too.
You put the condition inside a pair of square brackets, and the condition precedes the message-label.
The important thing is to coordinate the conditions with the numbering. When you're modeling if
statement there are two possible conditions. Messages for these conditions have a same number,
and you add a decimal point and another number. This is called nesting.
In out-of-product scenario, the machine has to display an out of product message, and prompt the
customer for another product or return the money back. If customer makes another selection this

CSE Department,
VNRVJIET

36
www.jntuworld.com

www.jntuworld.com
process must be repeated. Also a correct-amount-of-money scenario may be introduced.
Collaboration diagram for this case is shown on the picture:

As you can see, from this picture two possible scenarios may happen. Out-of-product and Product-in
are that two possibilities. If we assume that this happened after message 1:add(input,selection), the
number for this messages will be 2, and we add 1 for the Product-in and 2 for the out-of-product
scenarios, after the decimal point.
What happens when the machine doesn't have the correct change? The machine has to display an
out of change message, return the money, and prompt the customer for the correct change. In effect,
the transaction is over. When the machine has the correct change, it returns the change to the
customer and delivers selected product.
Two branches that are produced from nesting process are numbered with 2.1 and 2.2. And three
posibilities in condition-message 3 will be:3.1, 3.2 and 3.3. Collaboration diagram is shown on the
following picture:

Thats all for this example, and for this day. All you have to do now is answering the questions given in
Questions & Answers and Workshop part from this day. Next day will introduce to you the last three
UML diagrams.

Component Diagrams
A component diagram contains components, interfaces and relationships. Also other types of
symbols that you've already learned can also appear in a component diagram.
The component diagram's main icon is a rectangle that has two rectangles overlaid on its
left side. You put the name of the component inside the icon. The name is string. If the
component is a member of a package, you can prefix the component's name with the
name of the package.

The component icon

A component and the interfaces it realizes are representable in two ways.
One way is to show the interface as a rectangle that contains interface-related
information. It's connected to the component by the dotted line and empty triangle that
CSE Department,
VNRVJIET

37
www.jntuworld.com

www.jntuworld.com
vizualize realization.Other way to represent interface is as a small circle connected to the component
by a solid line, which represents a realization relationship.
Interface can be represented as a rectangle containing
information, connected to the component by a realization
arrow
Interface is a small circle, connected to the component with a
solid line, wich stands for realization

Component Diagram - Example

Suppose that we need to build up a software for playing a music from a CD-ROM Drive. A visual
programming language might be used (VisualBasic or Delphi for example). If language supports
multimedia controls, than we can use its components an reprogramm them if necessary, or we can
programm new components. One possible graphical design for our player might be:

As you can see this UML Music Player needs these controls:
play
stop
eject
pause
fast forward
rewind
power
These controls will be realized by buttons, thus we'll have a button performing these controls. If we
look at buttons as separete components, we can draw out a component UML diagram. This is shown
on the following picture:

The component diagram for the MusicPlayer.

All the components shown on the previous diagram belongs to one global component - Button, but
actions they perform are diferent. We must obtain these actions by programming them.

CSE Department,
VNRVJIET

38
www.jntuworld.com

www.jntuworld.com

Deployment Diagrams
We reached the end of the UML diagrams. Now it's perfect time to look at the hardware. As you can
see, we moved from items that live in analysis, to components that live in computers, to hardware that
lives in the real world.
Hardware, of course, is a prime topic in a multicomponent system. A solid blueprint for hardware
deployment is essential to system design. The UML provides you with symbols for creating a clear
picture of how the final hardware setup should look.
The main hardware item is a node, a generic name for any kind of computing resource. Two types of
nodes are possible. A processor is a node that can execute a component, and a device that can't
execute a component. A device typically interfaces in some way with the outside world.
In the UML a cube represent a node. Node has its name, and you can use a stereotype to
indicate the type of resource it is. If a node is a part of package, then and the name of
package preceeds the name of the node. A line joining the two cubes represents a
connection between two nodes. You can use a stereotype to provide information about the
connection.
The cube is representation of a node in the UML

Also every node deployes some of software components in the system. To indicate deployed
components, you show them in dependency relationships with a node.
Let's build a deployment diagram for a home computer system. Computer consists of these hardware
elements: CPU, monitor, printer, mouse, keyboard. And installed software components: Windows98,
Office98, InternetExplorer4, FrontPage, DOS, NortonCommander, TurboPascal.

The main node is CPU which consists of all the

software components with their relationships.
Other hardware elements are devices
connected to the main processor unit.
You may extend this diagram by adding a modem and connection to the Internet. Try to redraw the
diagram with this extension.
The UML deployment diagram provides a picture of how the physical system will
look when it's all put together. A system consists of nodes (represented by a
cube) with line connecting them, called connections. There are two types of
nodes: a processor (can execute a component) and a device (interface with the real world).
Deployment diagrams are useful for modeling networks.

Deployment Diagram - Example

This example will describe you the thin Ethernet network. If you're familiar with computer networks
this one will be easy to you, but if not then try to understand the following explanation:
CSE Department,
VNRVJIET

39
www.jntuworld.com

www.jntuworld.com
The thin ethernet is a popular type of network. It is used in local places eg.rooms or buildings, where
connecting cable can be placed. There are some mathematics calculations for the length of the cable
of all the network, and length of cable from computer to computer. These calculation for the
deployment diagram are not important.
Computers connect to a network cable via connection devices called Tconnectors, or sometimes vampire-taps are used. T-connector has three
connecting points. Its form is similar with T-letter and thats why their name
cames from. Network cable goes from one end-point to the other end-point
of the connector, and the third end-point has a cable going to the computer.
Because length of the network is limited, ending points of the cable must have a devices called
terminators, which gave infinite resistance to the end of cable. Also one network segment may join
another via a repeater. The repeater is a device which amplifies the signal to reduce losing of signal.
The thin Ethernet is represented on the following

picture:
When we get familiar with the thin Ethernet network concept let's draw the deployment diagram for it.
This diagram wil look like:

CSE Department,
VNRVJIET

40
www.jntuworld.com

www.jntuworld.com

Deployment Diagram for Ethernet network

With this example all of the UML diagrams are shown to you. In this day, only that you have to do, are
the exercises. But before make some exercises, A global picture with all of the UML symbols is given
to you. See it.

UML Diagram Set of Symbols

This is the complete set of symbols that UML introduces in its diagrams.
Structural Elements

CSE Department,
VNRVJIET

41
www.jntuworld.com

www.jntuworld.com
Behavioral Elements

Relationships

Grouping

Extension

Annotation & Actors

The Digital Library - Example

We finished UML diagram's theory. Now is a perfect time to dive into practice. This and next day are
concerned with Digital Libraries. If you're not introduced with them, don't worry. Things will be much
clearer after these two days.
Back in time we remember the clasical library structure in which there is a librarian with a great deal
of paperwork, the user must be physically there to get the book and know which book is of his/hers
interest. If he/she doesnt know the desired book, than is in the hands of librarian to recommend
some book for him/her.
The new wave in this direction, based on the software development and Internet is headed into new
library entity- the Digital Library. This kind of library is world-wide accessed, with a quick review
possibilities, digital books and a lot of multimedia files. They can recommend you a book or a journal,
give a statistical aspect of the recent books and a lot of features that are making the life easier all of
that with the comfort of lying in the sofa with remote keyboard in your hands. Remote reservation is
even making possible of getting a hard copy of a book or journal using a efficient postal system
connected with the library.
Day 5 and Day 6 will guide you trough the process of analyzing and implementing a digital library.
You will find out all the steps introduced in Rapid Application Development process, and their workproducts UML diagrams. First two lessons, during interviews, will describe you the work of one digital
library in detail. Let's go to work now.

Discovering Business Processes 1

In this lesson you'll find how to make an interview with a client. This will be a dialog between an
analyst and a client. The final product of this conversation will be an activity diagram.
CSE Department,
VNRVJIET

42
www.jntuworld.com

www.jntuworld.com

In the following text A will stand for Analyst and C for the client.
A Let's start with the work. Tell me what's happening when a customer enters in your library?
C He or she goes to the corridor where data search can be done. After selection of which books or
journals to lend, the customer goes to the place where he or she can take the sample of that book
or journal.
A You said data search. What kind of data?
C There is main data record for every book, author or journal, sorted alphabetically. Every record
consist of different data according to type of the product: (book or journal). These records are
printed on paper cards, and they are putted on different folders. Access to these records can be
done also by computer terminals which can be found in the corridor.
A That means that your library is computerized. Why using a computers and a paper records?
C As we live in hi-technological era, we must to follow time steps. Computers were introduced few
years ago, but paper records are here since the library was built. Also some impatient customers,
can use them if all of the computer terminals are occupied.
A Are the same data put in the paper records and in the computer records?
C Yes. All of old data from paper records is converted to computer records, and new data that we
write in paper cards also is writen in electronic format.
A Where is your database located on?
C Our database is located on a computer server. This server is a heart of our local area network - all
of the terminals located in our library.
A Let's backtrack to the data. You said that same data is stored in the electronic format and in the
paper format. Next in our conversation we can refer to these with same name, let's say index.
C I agree.
A When we talk about index, what kind of information is necessary to perform a search?
C Data for the books and for the journals is very similar. Both have ISBN-the unique number for
every book/journal, title, publishing year, publishing house, but books have author and genre, and
journals have volume and area. For the data search are usefull ISBNs, titles, authors, genres,
volumes and areas. Retreived results specifies the type of the books or journals.
A Just a second. What are the kinds of books and journals?
C Except paper books and journals, electronic books and journals are supperted in our library.
A Electronic books and journals. How do you manage these types of items (books / journals)?
C The server we had is used for storage of these types of items. We produced some of the
electronic items, but also in our database we have Internet addresses from electronic books or
journals from other libraries we used to cooperate.
A You have a lot of ammount of data. Is everyone concerned with data input and data maintenance?
C We have employees to do this.
A You said employees. I think that they are not parts from this conversation for now. We will talk
about them later. The customers are not finished yet. Before going to the process of lending let's
assume what we have at this point of interview, things come clearer to me now. Every customer
can perform a data search for the books or journals. Electronic formats of books retrived from the
search, can be accessed imidiately. Paper formats can be lended if there is a free sample.
Now you may go to the process of lending.
C At the begining, I've stress out that user who is in the library after data search can perform a
lending. Lending can be done if books or journals are in paper format, and it's done in the lending
area in the library. Searched books or journals can be given to the user if free samples of them are
in the library.
A Let's look at the both cases - present and not present sample of the book/journal. What is the flow
of events?
CSE Department,
VNRVJIET

43
www.jntuworld.com

www.jntuworld.com
C When sample is not present, the user can make a reservation for it. After that library must inform
the user for a free sample, when one is set free. User, than should go the the library and make a
lending for that sample. I must say that free sample is kept for the user few weeks after informing
it.
A What if there is a free sample?
C In that case emloyee who is concerned with lending (let's say - lender), must check the users data
to see if user is a library member or not. If the user is a library member, he or she takes the ISBN
of lended books or journals and personal data for the user, and writes them in the lending record.
Also a date is writen in this record, which is stored in the lending database. Every user has a limit
of books/journals to lend, and also there is a limit for time keeping of books/journals.
A Do you allow employees to lend books or journals?
C Yes we do. Every employee in our library has the same record as members. That we have lending
records for employees too.
A You said that lending records are stored in a lending database. Is this a work of "lender" or
someone else do this?
C Our local network doesn't consists only from searh terminals. A "lender" also has a terminal from
which he or she can check for user data and free samples. Also a quick reports can be done to
see which users have books to return.
A Wait a minute. Our conversation gone in other direction. We started to talk about employee's
duties, we didn't finished with the customers. Let's see to made a lending a free sample of the
book or journal can be present in the library, and a lending record is produced after it.
C That's it. I'll stress again that only paper formats can be lended, because they have a samples.
Electonic formats of books and journal doesn't have a samples. In other words they have infinite
number of samples, or they are present in the library everytime.
A Is it possible to have no present samples of books or journals from searched user's list? Can users
ask a lender to recommend them a book or journal?
C Certainly lender can take a brief look at the user's history of lended books and journals, and if he
or she had read a books or journals from the user's interest areas, then he or she can recommend
something to the user. User can accept that or not.
A This will be all for now. I think that user's diagram is done, and we can take a look at it:

CSE Department,
VNRVJIET

44
www.jntuworld.com

www.jntuworld.com

Member Activity diagram

corresponding to the
previous interview

Discovering Business Processes 2

This lesson is extension of previous one. Now we'll give you the interview with the client - explanation
of work of the employees in the library. Let's see at all given details and analyze the produces activity
diagram.
A In previous interview we talked about customers, and all the activities related to them, like lending,
reservation, recommendation, and search. In lending and recommendation process interaction
with the employees was introduced. Let's turn to the employees now, and talk about employees
CSE Department,
VNRVJIET

45
www.jntuworld.com

www.jntuworld.com

A
C
A
C

A
C

A
C

A
C

A
C
A
C

A
C
A
C
A

which interact with clients, books and journals.

Allright. The lenders were introduced in previous interview, and we see that their work is to take
care of lending and returning of books and journals. They post reports to the members who have
books to return, and members who have reserved books and their samples are present in the
library.
Is it all for the lenders?
Yes.
When we talk about a customers, we mentioned that for huge amount of data, some of the
employees are employed. Can you tell me more about them?
After buying a computers, a part of our old employees, involved in process of writing paper cards,
were trained to work with computers. These DataEntry clerks now operate with some of terminals
for data entering and maintenace. Also for maintenance of our databases DatabaseSpecialists
were employed.
If I waht to become a member to your library. What I'm supposed to do?
First of all every new member must go to the reception place to conclude his or her membership.
Employee that enters new memberships, opens a new record with a name and last name of the
member, address and place of living and Personal Registration Number added to it. Also
telephone e-mail and date of birth are stored in this record. After registration, a member's card is
given to the member, and a paper record is printet for the library's documentation.
How do you make data input of books and journals?
Books and journals have a plenty of attributes in common. That are ISBN, title, year of publishing
and publishing house. Also every item has a number of samples. Sometimes a multimedia data
are supported with the item. If that is a propaganda material in paper form we convert it into
electric form and put it into the database.
Do you support multimedia data only for electronic items, or paper items has multimedia too?
The form of the book/journal is not important. Both for paper and electronic formats we support
multimedia data. Popular books in the world, can be more popular if a multimedia is supported for
them. Every user is curious to meet with these types of information.
If I perform a data search, can I browse the multimedia data supported for the item? And what kind
of multimedia is supported?
It's true. During computer's searching in returned results if an item has a multimedia data, user can
browse that data. Types of multimedia which are supported are Text, Audio, Video and Picture.
How do you enters a data for the book's author?
I'm sorry. I forgot to tell you that authors are entered separately. For the authors name and last
name, year and place of birth are inputed. During the process of book's input if the book's author
is in the entered list of authors, then he or she is chosen from that list. Otherway we used an
author creation process. Also for books their genre is inputed.
What about a journals?
For the journals volume and area are entered.
You said that a parallel evidence is made (paper and electronic). How do you represent
multimedia data in your paper cards?
Multimedia data is entered only in electronic format. I said that paper cards are printed from
electonic records, but only necessary information for cards is printed.
We examined a work of lenders, employees who enters a data for authors, books, journals and
members. But I don't see here a sample input. In lending process you said that free samples can
be lended. How do you perform sample input?
I notioned when we talk about book entering, that process of book's input also consists of inputing
a number of new samples. But it is possible new samples to arrive in library, and a record for the
book to exist in database. In that case only sample data is entered. This data consists of sample's
signature, which only concerns the lenders (information about stored place of sample in the

CSE Department,
VNRVJIET

46
www.jntuworld.com

www.jntuworld.com
storage room).
A Do you think that we have finished the employee's analysis?
C Sure. We reached the end. I hope that all my spelling out all the steps in library work, makes
clearer view to you about libraries like ours.

The Lender's Activity diagram gained

from previous interview

CSE Department,
VNRVJIET

47
www.jntuworld.com

www.jntuworld.com

The Data Entry Clerk's Activity diagram extracted from the interview

Domain Analysis
Before haveing additional interviews, the development team first must work within the context of the
business-process interview. This is the job of an object modeler. The objective is to produce initial
class diagram.
The object modeler looks for nouns, verbs and verb phrases. Some of the nouns will
become classes in the model, some will become attributes. The verb and verb phrases
can become operations or the labels of associations.
Let's put ourselves in the role of the modeler and start developing the class diagram. From the client's
interview we can filtered out these nouns:

Move your mouse over the word list and you'll see what nouns from the list can be eliminated as an attributes, synonyms with other nouns, and
nouns that represent classes out of the domain's scope.

CSE Department,
VNRVJIET

48
www.jntuworld.com

www.jntuworld.com
And these verbs:
go, search, lend, take, sort, print, put, do, has, have, convert, write, manage, access, read,
preview, take a sample, reserve, give, inform, make, set free, check the data, recommend,
post, buy, operate, maintain, conclude, browse, input
Now we'll try to form some meaningful groups of nouns.
One group consists of people: member, author, employee, lender, DatabaseSpecialist, DataEntry
clerk. This group could stand some subdivision because everyone except the member and author are
employees.
Another group consists of library's items like books, journals, samples, reservation, lending.
Third group consists of areas within the library: corridor, lending area, reception place.
In forth group may be these nouns: member's card, data record, paper card, multimedia data, lending
record.

Abstract classes partition the class diagram into

meaningful groups
This is the initial class diagram, next we'll discover associations between classes and produce more
descriptive class diagram tha this one.

Forming Associations
Now we'll create and label associations between some of the classes. The verbs and verb phrases
can help us with the labeling, but we won't limit ourselves to the ones from the interview.
Labels that are somewhat more descriptive might suggest themselves.
Let's start with the member first. Let's label the associations by generating phrases that characterize
the associations. Here are some phrases that immidiately come to mind:
The member searches the paper cards or data records.
The member goes to the lending place.
The member lends a sample.
The member makes a reservation.
The members takes a sample.
The member browse the multimedia data.
The member goes to the reception area.
The member prints the electronic item.
When we labeled out the associations, we can put multiplicities into associations lines. After this
customer's class will look like this:

CSE Department,
VNRVJIET

49
www.jntuworld.com

www.jntuworld.com

The member class with included multiplicities in the

associations
The associations for the item's (here item is standing for both book and journal) class might be the
phrases from the following list:
The item can be recommended to the member.
The item is reserved by a member.
The item (electronic) is printet by a member.
The items are sorted alphabeticaly in paper cards and data records.
The item has sample(s).
The item has multimedia data.
After filling out associations names and multiplicities, the item's class will be:

Associations with the items (books and journals)

Interesting, also is the process of forming associations and multiplicities for the emplyee's class. Bear
in mind that employees are also a members of the library, thus all the member's class associations
can be putted into the emplyee's class, but some of the employees perform some actions that
members are not allowed:
The lender produces a lending record.
CSE Department,
VNRVJIET

50
www.jntuworld.com

www.jntuworld.com
The lender lends an item to the member.
The DataEntry clerk enters data for the books.
The DataEntry clerk enters data for the journals.
The DataEntry clerk enters data for the authors.
The DataEntry clerk enters data for the members.
The DataEntry clerk enters data for the samples.
After filling out associations names and multiplicities, the lender's and DataEntry clerk's classes will
be:

Associations with the lender

Associations with the DataEntry clerk

Try drawing out the associations with the Author's class and Sample's class. This will be also an
exercise for you given in the workshop for this day.
We've been forming and naming abstract classes and associations, and another organizational
dimension awaits. The next step will be finding out classes that are components of other classes. A
library for instance consists of a set of parts, but for as interesting will be: corridor, lending area and
reception area. Next picture shows this compozition.

Compozition in the Digital Library domain

If you have some probles understanding processes of forming associations, multiplicities and
compozitions, please see these lessons learned in DAY 2: Associations and Aggregations.

Filling Out the Classes

We can begin the refinement now by adding some attributes and operations. Our most important
classes appear to be Member, Author, Employee, Book, Journal, and Sample.
The Member
In nouns list some of the nouns are appropriate to be used as member's attributes. And from vers list
we can chose some of the possible operations for the member. These two lists are given in the
following table:

CSE Department,
VNRVJIET

51
www.jntuworld.com

www.jntuworld.com
List of attributes
name
lastname
address
date of birdth
place of living
PersonalRegistrationNumber
telephone
e-mail
memberID
The member class now will look as:

List of operations
newMember()
search()
lend()
reserve()

The Member class

The Author
Lists of attributes and operations for the author will be:
List of attributes
name
lastname
date of birdth

List of operations
createAuthor()
bookReference()

The Author class

The Employee
Lender and the DataEntry clerk are childern of the abstract class Employee. First we'll assign
attributes to the Employee class and the children classes will inherits them. Also we must bear in
mind that every employee has a member record. This will guide us that in the Employee class list of
member's attributes may appear, plus an attribute to differs employees from members. Also
DataEntry clerk class will have new attribute which determines the type of data entry performing that
clerk. List of attributes and operations (for Lender and DataEntry clerk) are given in fillowing table:
List of attributes for the
List of operations for the
List of operations for the
Employee class
Lender class
DataEntryClerk class
name
newMember()
lastname
makeLending()
address
newBook()
date of birdth
place of living
returnLending()
newJournal()
PersonalRegistrationNumber
CSE Department,
VNRVJIET

52
www.jntuworld.com

www.jntuworld.com
telephone
newSample()
e-mail
sendReport()
memberID
newMultimedia()
employee
The structure of the Employee class with its subclasses is given on the following picture:

The Employee class and its children

Try finding out an attributes and operations for the Book class. This class will be very simmilar with
next - the Journal class.
The Journal
List of attributes and operations for the Journal class are following:
List of attributes
List of operations
title
freeSamples()
volume
area
newJournal()
publishing year
publishing house
makeLending()
ISBN
status
makeReservation()
numberOfSamples
The "status" attribute indicates the type of the journal: electronic or paper. The Journal class will be:

The Journal class

The Sample
The lending process may produce lended book or journal only if a free sample of that book or journal
is present in the library. For that purpose a Sample class must be present. The sample class will have
CSE Department,
VNRVJIET

53
www.jntuworld.com

www.jntuworld.com
only two attributes (in this moment) - signature and status (lended or free), and one operation
newSample(). The Sample class is present on next picture:

The Sample class

When you're putting together interview results, business processes, and domain
analyses, keep a model dictionary. This is a glosary of all the terminology in the
model. It will help you maintain consistency and avoid ambiguity.
Also it's not a good idea to have every detail of your class model in one hude diagram. You'll
need a master diagram that shows all the connections, associations and generalizations, but
it's the best to elide attributes and operations from this picture. You can turn the spotlight on
selected classes by putting them in separate diagrams.

Developing the Vision

Now it's time for the team to work on the technical backbone for the Digital Library. They've got
business processes and class diagrams. Can they begin with the coding now, or not? They're not
even close to writing a program, first, they have to develop a vision of the system.
The team will use its business process knowledge and newly acquired domain
knowledge to see where infusion of technology enhances the library work. The players in
this conversation are an analyst, a modeler, a librarian, a lender, a DataEntry clerk, a
member and a system engineer. A facilitator runs the meeting. The facilitator distributes copies of the
business process diagrams developed in previous lessons.
See Discovering business processes 1, and Discovering business processes 2.
This conversation is about information movement. Some of the processes in the library business
depends on the movement of the information. If we can speed that movement along - something
technology is really good at - we'll meet our goal. From this conversation was concluded that
information movement takes place when:
The member lends a book's sample
The member lends a journal's sample
The lender recommends a book to the member
The lender recommends a journal to the member
The member contracts the membership with the DataEntry clerk
Next will be given a part from this conversation. Here modeler has some interesting ideas about
adding new attributes in the class diagram. Let's see what is happening:
Analyst
Let's go to the process of lending. It was mentioned that members has time limit and
copies limit for a lending. How the lender knows how many books or journals to give to
the member?
Lender
First of all I take a look at member's lending record, and count how many items he or she
has lended. Also I check the lending date to see if there is a books or journals with
overloaded time limit.
Modeler
I've been working on my class diagrams while I've been listening to all of you. And I have
some questions to ask. In the Member class, we may add new attributes like timeLimit
and copiesLimit which are common for every member. Also an attribute that holds the
number of lended samples - samplesLended may be introduced, and a derived attribute numberToLend, which is the difference between copiesLimit and samplesLended.
Lender
That's a nice idea. Then I'd know the number of allowed samples to lend to the member.
Analyst
What about timeLimit?
Modeler
We have an attribute that holds the lending time. If we add timeLimit to it, a result is
aimed. Then if the result is greater than current date, we can inform the member that he
or she has a time pass over for a lended book or journal.
CSE Department,
VNRVJIET

54
www.jntuworld.com

www.jntuworld.com
Analyst

What about multimedia data? It was said that for some of the books, journals or authors
multimedia data is supported.
Modeler
It's a perfect time to introduce a new class in our class diagram - Multimedia. For that
purpose, Multimedia class will have two attributes type (text, audio, video or picture) and
file (physical location of the multimedia file) and one operation - newMultimedia().
Facilitator Analyst are you satisfied?
Analyst
I agree. Now things comes clearer to me. Every part of the puzzle is putted on its place.
Modeler
Here's another possibility. Look carefuly at the Book and the Journal classes. Both are
haveing common attributes like ISBN, title, publishing year, publishing house, number of
samples. They are differing in author and genre data for the book, and volume and area
data for the journal. This is perfect situation for a new inheritance. Common attributes
can be putted in new parent class, let's say Item. Also in this new class some of the
operations can take place like: freeSamples(), makeLending() and makeReservation().
With this we can save memory space in our database.
Facilitator I'm glad that we're making some optimization. Before going to the next steps, san I
suggest you to look at new classes?
(All agree)

Changes in the Member class. New Multimedia

class and hierarchy between books and journals,
the parent class is the new one - Item class
Analyst

Modeler

During reservation process or lending process, current date must be somewhere stored.
In our class diagram I don't see place in the classes where this data is stored. Please tell
me where do you put information about date of lending and date of reservation?
According to many-to-many association between the Sample class and the Member
class, we are supposed to add a new class for that association holding the intersection
data for that association. Right here we can add two new classes, the Reservation and
the Lending. Here date of reservation and date of lending can take place. Also in the
Reservation class an attribute for timeLimit of the reservation can be added. This is
necessary for calculating the time period of holding a reservation to the member. These
new classes are given in the following pictures

CSE Department,
VNRVJIET

55
www.jntuworld.com

www.jntuworld.com

New classes added in our class diagram are the Reservation

class and the Lending class
Analyst

Allright. For this moment I think that we've resolved all the problems about classes. Now,
can we move on to some ideas about what the system should specifically do?
Facilitator Sure. Ideas everyone?
Member
I think that this sytem will be more productive if we, the members, can access to all the
data in the library from home. Sometimes, when I go to the library with tought to lend
some book that I realy need, I hear the Lender's words: "Sory, but we're out of free
samples for that book. Can I recommend you something else?". In that moment I'm
saying into me: "My chef will kill me. I spent so much time and I didn't finished my work. I
hope that there will be a little bit crowd in traffic."
Analyst
Yes. Our system has to somehow keep the members from walking to the library so much.
Obviously they have to go to the library when they made a reservation from their home
and a free sample is holded for them. Also a lending process can be done if a member is
present in the library.
System
I think we're onto something. We can allow members to access to the library's LAN
Engineer directly from their homes or work offices, using the global network - Internet. Then the
information would move around very quickly. Also I heed to tell you that our system will
cooperate with library's LAN, but new software will be implemented everywhere.
Analyst
The system you're talking about would resolve a number of issues. Like data search from
home and makeing a reservation for a book or journal from your home or office. I'll have
a feeling that I'm in the library and using their local area network and I don't care for a
free terminal.
Member
That's beautifull. When I have a lot of work to do, I can turn on my computer, make a
connection with the library and search the data to find out a free sample of books or
journals I need to lend. But from library's network I can't make a reservation for a book of
journal. How can I make a reservation from my home or office?
System
We are going to implement a Web interface that allows you to access data stored in the
Engineer library's database, and allows you to make a reservation from your home or office by
clicking a button that sends a message from your computer with your personal data and
book's data that you want to reserve. This message will open a new reservation record in
our database holding the data until you get your reservation, or time limit is oversteped.
Member
But how can my computer know my personal data?
System
First of all, Web interface can be used only be library's members. In our class diagram we
Engineer have memberID - number printed on your member's card with all the neccesary personal
data. When you search the data you make a selection of books/journals to reserve. This
list is also sent when you click the button. But if you aren't a member in the library, first
that you must do is to make a library's membership.
Librarian Is it possible some of our employees to access the system if they aren't present in the
library too?
System
Of course. Data entry clerks can do their job even if they are not present in their work
Engineer offices. They can access the database data from every place in the world that has a
computer and Internet connection.
Librarian How are you going to make this happen?
System
Let's don't worry about that right now. Very soon you'll find out how this will be realized.
Engineer
Facilitator So we're all set, then? Our system will incorporate the library's local area network and
Internet. Now is time to give a name for our system.
System
How about Digital Library.
CSE Department,
VNRVJIET

56
www.jntuworld.com

www.jntuworld.com
Engineer
Facilitator Can we all agree with Digital Library?
(All agree)
Facilitator Okay. I think our work here is done.

JAD Session
Now that the team has a vision for the system, can the programmers program and the system
engineers engineer? Absolutely not. The team must center the Digital Library system around the
user's needs, not around nifty technology. Altough they have a few insights from the team meeting,
they haven't exposed the Digital Library concept to a group of employees and end users - the
members, to get feedback and ideas from the user's point of view. The next GRAPPLE action does
just that. In a Joint Application Development session, the team will gather and document system
requirements.
The JAD session takes place in conference room. Led by a facilitator, it's called a joint
because it includes members of the development team along with potencial system users
and domain experts. The development team members are analyst, a modeler, two
programmers and a system engineer. The potential users are two members, a lender, two data entry
clerks and a librarian. This meeting will produce a package diagram that shows the major functionality
of the system.
This session starts with a facilitator's speech about the Digital Library concept. The structure of a
Digital Library system is represented on this picture, which is given to all the participants in the
meeting.

The physical structure and

connections between
components in the Digital
Library
The group starts their conversation by figuring out what the major pieces of functionality should the
system had. It was decided to use following functionality of the system:

CSE Department,
VNRVJIET

57
www.jntuworld.com

www.jntuworld.com

The packages of functionality for the

Digital Library
Next will be given a part of the meeting conversations between some of the participants:
Facilitator Now that we have the major pieces, does anyone have a preference as to where to start?
Member1 How about the Member part?
Facilitator Sounds good. Alright, what kinds of functionality would you waht to see in this package?
Remember, group, just because we're doing a piece that happens to not coincide with
your particular job, you can still participate. everyoune's insights are welcome.
Member1 I like to perform a search from my home and selected books and journals reserve until I
go to the library and lend them.
Facilitator Okay. What else?
Member2 I want to print electronic books and journals directly from my office.
Analyst
By the way I don't see any information about electronic items in our class diagram. How
can we manage these items?
Modeler
You're right. In the Item class we must add new attributes for an electronic
books/journals. A status will be one. With this one we can check the type of the item
(electronic or paper). Also we must add an attribute that holds the location of the
electronic item (on the local storage device or on Internet). This attribute will be named
as link.
Facilitator Has anyone had another kind of functionality to add?
Member1 I want to take a list of recommended books and journals onto my computer.
Facilitator OK. You'll notice that I'm writing these in labeled ellipses. We refer to these as use
cases. We'll be asking some of you to come back and help us analyze those use cases,
but that's another meeting.
When JAD session has finished, participants had a set of requirements that appear as use cases
arranged in the packages. The list of uses cases for every package is given to you.
The member package use cases:
transmit the reservation to the library's
enter data for searching
database
transmit the data to the library's database
receive notification from library's database
retreive a list of items
take a list of recommended books
make a reservation for some of them
take a list of recommended journals
The book package use cases:
select an author
check for reservations
receive an author data
receive number of reservations
enter data for a new book
find out the oldest reservation
edit data for an existing book
make a reservation
enter multimedia data
receive notification for reservation
receive notification from multimedia adding
make a lending
check for free samples
transmit lending data
receive number of free samples
receive notification for lending
CSE Department,
VNRVJIET

58
www.jntuworld.com

www.jntuworld.com
The sample package use cases:
add new sample
receive a request for free samples
set it free
return number of free samples
edit data for an existing sample
The reservation package use cases:
receive a request for reservation
transmit a reservation result to the member
perform a reservation
delete a reservation
The lending package use cases:
receive a request for new lending
receive a request for returning a lending
perform a lending
return a lending
transmit a lending result to the lender and
transmit a result to the lender
book
delete lending
check for reservations
receive oldest reservation
transmit information for reservations
The author package use cases:
enter new author
receive request for author's data
edit old author's data
transmit data to the book
The lender package use cases:
enter new lending
perform a lending return
receive notification from lending
receive a result from returning a lending
For exercise try adding the use cases in DataEntry clerk package, Multimedia package, and to the
Journal package.
Click here to see how will look our functionality package diagram filled with use cases!

CSE Department,
VNRVJIET

59
www.jntuworld.com

www.jntuworld.com

In a JAD session, the development team meets with potential users and domain
experts to gather the requirements for the system. The result is a package
diagram in wich each package represent a major piece of functionality. Use
cases inside a package elaborate on the functionality.

Analysis of the system

We've finished the requirements gathering process for the Digital Library model. During this day an
analysis of the Digital Library model will be done.
First we'll meet with use case analysis, after what a use case diagram for every package will be
gained. Next we're going to discover and analyze an icteractions among objects in the Digital Library
system, and we'll produce collaboration diagrams. And at the end of the day we'll examine the
interactions between our Digital Library with existing systems, like Library's local network, and we'll
produce detailed deployment diagram, and a few user interfaces will be introduced.
Let's start with the work, and learn the material given in this, the last day, of UML course.

Developing the Use Cases

The use cases from the package diagram in JAD Session lesson from DAY 5, give a good picture of
what the system will have to do. The team will have to flesh out each one. They've moved gradually
from understanding the domain to understanding the system. The use cases have provided the
bridge.
At no point in the JAD session did the development team discuss how the system would accomplish
all the activities specified in the panolopy of use cases. The idea was just enumerate all the possible
use cases. As the use cases become fleshed out in this hour, notice how the components of the
CSE Department,
VNRVJIET

60
www.jntuworld.com

www.jntuworld.com
Digital Library system start to materialize. At this point in the development effort, the system begins to
take center stage.
To analyze the use cases, we have to run another JAD session. The discussion in this JAD
session is intended to derive analysis for each use case.
The use case JAD session is usually the most difficult one, as it calls for the participants - potential
users of the finished system - to become analysts. In their own niche, each one is a domain expert,
and you have to tap into their expertise. Typically, they're not used to either verbalizing or analyzing
what they know. It's also probably true that they haven't been part of a system design effort before,
and they may be uncomfortable with trying to specify what a system should do to help them do their
work.
The system-related steps in the scenario are extremely important. They'll show how the
system is supposed to work. When the JAD session participants tell us these steps, they're
telling us, in efect, what the system will ultimately look like. After this JAD session, we should
have a good idea about the components of the system.
In Introducing a Use Case Model lesson in DAY 2, we see that each use case is a sequence of
scenarios, and each scenarion is a sequence of steps. For each scenario in each use case, we'll want
to show:
A brief description of the scenario
Assumptions for the scenario
The actor who initiates the use case
Preconditions for the use case
System-related steps in the scenario
Postconditions when the scenario is complete
The actor who benefits from the use case
Use cases that we're going to examine are numerous. That's why when we're performing an use case
analysis number of them will be examined in detail, and the rest of them will be given to you as an
exercise. Now let's dive into process of analysis the use case.

The Use Case Analysis 1

In this lesson we'll meet with the process of analysis of the use cases. We're going to examine a
member's package of use cases and a book's package of use cases. The rest of them are given to
you, to try yourself in the use case analysis.
The Member package

The Member's package of use cases developed in earlier stages of the system analysis
- Enter data for searching
CSE Department,
VNRVJIET

61
www.jntuworld.com

www.jntuworld.com
The good-one sentence description for this use case may be: The member enters a data for
serching into search form.
Here initialing actor will be Member, which is also a benefiting actor.
The assumptions are that a member wants to find out books or journals. Another assumption is that
the Digital Library's interface has a form dedicated for search data entry.
The precondition is that a member has a necessary data to make a search. The postcondition is that
a member enters necessary data into Digital Library.
The steps in the use case are:
From the Library's LAN or from home/office, the member activates the user interface for search
entry.
The search form appears on the screen.
The member enters necessary data patterns into search form.
- Transmit data for searching
The description for this use case may be: Take a data pattern entered in search form, and send it
to the Digital Library's database search engine.
The assumptions are that we have communication via the Internet or library's LAN, and we have a
search form in the member's interface.
We must make repetitions of some of the assumptions, because each use case will
eventually appear on a separate page in the design document, which will serve as a
reference about the system.
The precondition is entered data pattern in search form, the postcondition is that the data pattern has
arrived in the Digital Library database search engine.
The steps in the use case are:
Click on the SUBMIT button on the search form.
Activate the transmiting mechanizam for data in network(s).
The data pattern arrives in Digital Library database search engine.
On the member's screen appears a message that data has been sent, and to wait a moment
during receiveing the data.
Because this use case is related to the previous one, we must make a change to the Member
package. It has to show <<include>> dependency between this one and "Enter data for searching"
use case.
- Take a list of searched items
This one use case is the last part for completion the searching process. Description here is: Receive
a list of book or journals, after entering a data in search form and send it to the Digital Library
database.
The assumptions are that a member uses a search form, and a communication via network(s) is
good.
The precondition is clicked SUBMIT button on search form, and the postcondition is printed list of
items on the member's screen. The actor here again is Member.
The steps of this use case are:
Wait until search is performed (in paralell a Digital Library search engine performs a search).
Digital Library database transmits a list of items to the member's interface via the network(s).
The member receives a list of items satisfying entered search-data pattern.
Inclusion also appears in this use case. <<include>> joins this use case with the previous one.
- Make reservation
CSE Department,
VNRVJIET

62
www.jntuworld.com

www.jntuworld.com
Description for this use case will be: The member wants to make a reservation for the item
gained from searching process or recommendation process.
As you can see this use case depends on two different use cases - search and recommendation.
Thus reservation process may take place only when one of these two processes take turn. Thats
because an inclusion is presented between these three use cases.
The assumptions are a list of items, and a button for reservation.
The precondition is clicked RESERVE button, and a postcondition is transmited reservation record to
the Digital Library.
The steps of this use case are:
The member receives a list of items (from searching or from recommendation)
The member clicks the RESERVE button for the items that he or she wants to reserve
The member fills in the information in the form that appears for the reservation
- Transmit reservation
This use case wouldn't be explained in detail, because it is almost the same with the "transmit the
data for searching" use case. Only we'll say that this use case is related with "make reservation" and
"receive notification" use cases. The connection is <<include>>.
- Receive notification
Description is: After pressing the SUBMIT button in the reservation form, a notification from the
Digital Library must arrive that the reservation has been accepted, and infrom the member
with the status of reservation.
Here status of reservation is for haveing or not a free sample for reserved item. If a free sample is
present how many weeks it'll be holded for the member.
The assumptions are good communication in the network(s) and clicked SUBMIT button.
The precondition is clicked SUBMIT button, and a postcondition is received status of reservation
The steps of this use case are:
Wait until notification is received
Transmit the necessary information via the network to the member's interface
Members receives the status of reservation
- Take a list of recommended items
Description is: The member activates the recommendation part of the system, and gets a list of
recommended items
The assumptions are clicking the RECOMMEND button, and a working recommendation algorithm.
The precondition is clicked RECOMMEND button, and a postcondition is received list of items.
The initiating and benefiting actor is Member.
The steps of this use case are:
Activate the recommendation part from the user's interface.
The Digital Library activates a recommendation algorithm which produces a list of items.
Print this list of items to the member's screen.

CSE Department,
VNRVJIET

63
www.jntuworld.com

www.jntuworld.com

The updated use case diagrams for the Member package

The Use Case Analysis 2

Now let's take look at the Book package use cases, and analyze them separately.
The Book package

The Book package of use cases developed in earlier stages of the system analysis
- Enter data for a new book
Description: Fill in the data in book's entry form.
Initialing actor is DataEntry clerk.
Assumptions: Activated entry form in the DataEntry clerk's interface, and entered information.
Precondition is new book's data.
Postcondition is entered data into Digital Library database.
The steps are:
From the library's LAN or from internet the DataEntry clerk activates an interface for a book's
entry.
The form appears on the screen.
CSE Department,
VNRVJIET

64
www.jntuworld.com

www.jntuworld.com
The clerk enters necessary information.
- Select an author
Description: Select a book's author from the author list.
Initialing actor is DataEntry clerk.
Assumptions: There are author records in the database, and user makes a selection from that list.
Precondition is book's author data.
Postcondition is selected author's data.
The steps are:
In data entry form for the book, a clerk selects one author from the list of authors.
This information is send to the database.
Searching is performed into the database for that information.
An inclusion may be introduced here. This use case includes steps from "edit data for an existing
book" use case and from "enter data for a new book" use case.
- Retreive author's data
Description: Receive all the necessary information about the selected author in previous use
case.
Assumptions: User has made a selection from the author's list.
Precondition is selected author.
Postcondition is retreived author's information.
The steps are:
After searching, database selects the record for that author and extracts necessary information
about the author.
Sends that information to the book's data entry form.
Prints the information onto the user's screen.
This use case includes the "select an author" use case.
- Enter multimedia data
Description: If the book has a multimedia data, then it is entered into the book's record.
Assumptions: Book has a multimedia data, and a multimedia file(s) is(are) saved somewhere in the
server.
Precondition is book has a multimedia data and a MMEDIA button is clicked.
Postcondition is entered multimedia data.
The steps are:
If book has a multimedia data, a MMEDIA button is clicked, and a entry form appears on the
screen.
User enters type of multimedia data, and a location on the server where that data is saved.
SUBMIT button is clicked and multimedia record is transmited to the database.
An inclusion may be introduced here. This use case includes steps from "edit data for an existing
book" use case and from "enter data for a new book" use case.
- Receive notification from multimedia adding
Description: After filling the multimedia entry form, database sends a message how succesfull
was performed a process of adding new multimedia data.
Assumptions: Filled multimedia data entry form, good communication via network, and existing
multimedia file.
Precondition is transmited multimedia entry form to the database.
CSE Department,
VNRVJIET

65
www.jntuworld.com

www.jntuworld.com
Postcondition is received status of this transaction.
The steps are:
The multimedia data arrives into the database, and a process of creation of new record is
started.
This process may finish with a result, or may end with failure.
The type of ending of the creation process is returned to the book's data entry form.
This use case is inclusion of previous one - "enter multimedia data" use case.
- Edit data for an existing book
Description: If a wrong information is entered for some book, it is possible to change that
information.
Assumptions: Existing book's record for changeing, and clicked EDIT button.
Precondition is false entered information into book's record.
Postcondition is changed book's record.
The steps are:
User clicks the EDIT button and filled form with the old book's information appears on the screen.
False information is selected and changed.
If an author's information or multimedia information has to be changed, the same process like
entering new data is repeated.
- Make a reservation
Description: Member wants to reserve a sample for the book, and after that a lending can be
performed in the library.
Assumptions: Book must be present in the retreived list of books during the search or
recommendation process, books must have samples present in the library.
Precondition is Member wants to make a reservation for a book.
Postcondition is book's necessary data and member's necessary data are transfered to the Digital
Library.
The steps are:
Member clicks the RESERVE button and fills in the necessary information to perform a
reservation.
The Digital Library database receives request for reservation.
The steps of checking the data with database records are made.
Digital Library checks for free samples, and performs a new reservation.
After that a wait period is introduced, while the notification from the reservation is achieved.
- Receive notification from reservation
Description: After clicking the RESERVE button, and filling the form, Digital Library receives a
request for a reservation, and after performing a reservation process, a status message is
received.
Assumptions: RESERVE button, and sent request for reservation.
Precondition is clicked RESERVE button.
Postcondition is reservation status.
The steps are:
The status of performing a new reservation is achieved.
This status is sent trough the network to the user.
Meggase about status of reservation is printed on the screen.
This use case includes "make a reservation" use case.
CSE Department,
VNRVJIET

66
www.jntuworld.com

www.jntuworld.com
- Check for free samples
Description: Count how many samples from that book are available, and return that number to
the reservation process.
Assumptions: request for reservation, sample(s) for the book.
Precondition is new reservation.
Postcondition is number of free samples
The steps are:
Receive a request for a number of free samples.
Count the available samples (those one with status="available").
Sent that number to the Digital Library.
This use case includes "make a reservation" use case.
- Return number of free samples
Description: Gives a number of free samples.
Assumptions: samples of that book, request for number of free samples.
Precondition is request for number of samples.
Postcondition is transmiting the number of free samples
The steps are:
Receive the transmited number of free samples.
Check the result to determine the reservation status.
Transmit the reservation status to the Digital Library.
This use case includes "check for free samples" use case.
- Make a lending
Description: Member wants to lend a book.
Assumptions: user must be present in the library, book must be in paper form, a free sample for the
book must be available.
Initiatin actor is Lender and benefiting actor is Member.
Precondition is request for lending.
Postcondition is transmited lending request to the Digital Library.
The steps are:
Lender activates interface for makeing and returning a lending.
Lender enters data for the sample and the member in the lending data entry form.
After pressing the LEND button a new lending process is activated.
- Receive notification for lending
Description: After pressing the LEND button in the lending form, a new reservation record is
writen to the database, and the result of this transaction is returned to the lender's interface.
Assumptions: communication via network, and LEND button present in the interface.
Precondition is entered data in lending form.
Postcondition is status of performed transaction.
The steps are:
Wait until lending process ends, and receive a lending result status.
Transmit the status via network to the lender's screen.
If there are free samples, member gets one.
This use case includes "make a lending" use case.
Another use cases related to the lending process are:
CSE Department,
VNRVJIET

67
www.jntuworld.com

www.jntuworld.com
Receive number This use case take place when new lending record is created. If a book has a
of reservations pending reservations (free samples with status="reserved" are available), and
no free samples with status="available" are present, then lending process must
fail.
Check for
If a member has a reservation for a book's sample, then if a holded sample is
reservation
available, the member takes that sample, else a lending process will fail.
Find out the
This use case is used in the process of updating reservation records. When a
oldest
member make a request for a reservation and there is no free sample, then
reservation
when only one sample is set free, this use case take place and finds out the
oldest reservation for that book, and sets the sample's status from "available" to
"reserved". Sample can be set free when it is returned from a user who lends it.
Inclusions that appears here are between: "make a lending" and a "check for reservation" use cases;
"make a lending" and a "receive number of reservations" use cases.

The updated use case diagrams for the Book package

Analyzing the use cases has helped conceptualize the working parts of the system.
Although we know a lot about the use cases, we still have to model how those working
parts will interact with one another and how (and when) they change state. Passing this
information to the programmers will make their jobs a lot easier. They will have a vision of how to
code classes and make them wotk together.
See Interactions in the System.

Refine the Class Diagram

Now is the time to complete our class diaram. We will analyze every class gained from previous
analysis.
It is obvious to have a deleting process invert to the creation process. This is said because in almost
every class we have a creatind operation (in Object Oriented programming known as constructor),
therefore an operation for deleting an object must be obtained in every class (in Object Oriented
programming this is known as destructor).
A new attributes must be added for a Member class. They are alias, password and status. Alias and
password will serve as an attributes for logging onto the system. It is obvious that Internet interface
will allow a lot of people to access the Digital Library, but only those who have contracted
membership with the library, can browse the data, make reservations and printing the electronic
items. The Status attribute is introduced to distinguish between ordinary member and library
employee-member. We said that every employee also can be a member of a library.

CSE Department,
VNRVJIET

68
www.jntuworld.com

www.jntuworld.com
New operations for the Item class can be introduced according to the previous use case analysis.
This operations are findOutTheOldestReservation(), checkForReservation() and
receiveNumberOfReservations(), and they are described in previous lesson.
If we take a look at Member class attributes, Employee class attributes and an Author class atributes,
we'll see that most of them are comon for these three classes. Therefore an inheritance may be
introduced. We will create hew class Person wich will hold name, lastname and date of birdth
attributes.
Description for classes is not longer necessary, because you are going to see all the classes with
their last and final state. They are presented in the following list of classes.

The Lending class

The parent class Person with it's children

The Multimedia
class

The Reservation
class

CSE Department,
VNRVJIET

69
www.jntuworld.com

www.jntuworld.com

The Item class hierarchy

The Employee class and it's children

The Sample class

Click Here to see associations between these classes!

Interactions in the System 1

One way to find out the interactions in the system is to enumerate the system components
suggested in each package of use cases. The task to perform is to show how the system
components interact in order to complete each use case.
Altough we didn't explicitly analyze all the use cases in all the packages in the previous lessons, we
can still extract the system components those use cases assume. Let's start to reanalyze the
packages that were analyzed in previous lessons. That were the Member package and the Book
package. We're going to find interactions between components of these packages, but only for
reservation and lending process. Because this course is too short to comprise all the interactions
between components, we'll analyze only these two interactions, and a rest of them you'll need to do
like an exercise in the workshop part of the day.
The Member package
The member package use cases:
transmit the reservation to the library's
enter data for searching
database
transmit the data to the library's database
receive notification from library's database
retreive a list of items
take a list of recommended books
make a reservation for some of them
take a list of recommended journals
Let's exsamine again the process of reservating the book. Suppose that you have to reserve a book
from retreived list of recommended books. Now let's look at the steps necessary to perform these
operations.

The part of use case diagram in the

Member package
- Take a list of recommended books
The steps of this use case are:
CSE Department,
VNRVJIET

70
www.jntuworld.com

www.jntuworld.com
1 Activate the recommendation part from the member's interface.
2 After clicking the RECOMMEND button on the interface, a signal is sent to the Digital Library, to
activate the recommendation algorithm.
3 The Digital Library activates a recommendation algorithm* which produces a list of
recommended books.
4 The Digital Library sends this list of books to the member's interface.
5 Print this list of items to the member's screen.
* For the purpose of Digital Library a special algorithm for recommendation is developed. If you need some detailed information about this algorithm
please refer to the webmaster of this course.

To activate the reservation process, a RESERVE button must be obtained beyond every item in the
list. Pressing this button another use case sequence is activated. This sequence includes "make
reservation" use case, "transmit reservation" use case, and "receive notification" use case. The steps
for everyone use case are given in following tables:
- Make reservation
1
2
3
4

The member receives a list of items (from searching or from recommendation)

The member clicks the RESERVE button for the items that he or she wants to reserve
The form for acknowledging a reservation appears
The member fills in the information in the form

- Transmit reservation
1
2
3
4

Click on the SUBMIT button on the reservation form.

Digital Library transmits the reservation request to the Reservation database.
The request arrives in the Reservation database.
On the member's screen appears a message indicating "request sent", and a message " wait to
receive acknowledge".
Before going to the "receive notification" use case we'll take a look at Reservation package use
cases. A "new reservation" and "transmit notification" use cases will take part at this process of
interactions.
- New reservation
1 A request arrives in the Reservation database, and the process of creation new reservation is
activated.
2 Result of this process is status of reservation, which is sent to the Digital Library.
3 Send the status of reservation to the Digital Library.
- Transmit notification
1 Digital Library sents the status of reservation to the member's interface.
2 Status arrives in the member's side.
- Receive notification
1 Member's interface receives arrived status.
2 Status is decoded.
3 A message is printed on the member's screen according to the decoded status of reservation.

CSE Department,
VNRVJIET

71
www.jntuworld.com

www.jntuworld.com

The sequence diagram for

reservation process of recommended
book
As you can see some of use case steps are modified. These modifications are example of
the way one phase of a project can influence another.
Note also the state changes on the first lifeline. It's intended to clarify how the user
interface sets up to handle a particular kind of activity. We could include all the possible state
changes as separate state diagrams, but this would be overkill. Putting them on the sequence
diagrams appears to be more economical.

Interactions in the System 2

Suppoose that member wants to lend a book. First of all, member must be present in the library, the
book for lending must be in paper format, and a free sample must be present in the library's storage.
If all of these conditions are realized then a sample of book can be lended to the member.
To avoid going to the library and search for free sample, the member can perform a reservation to the
Digital Library system, and after receiving a notification that a free sample for the reservation is
present in the library, can go to the library and make his or hers lending.
Let's look at use cases in the Book package necessary for this operation.
The Book package
The book package use cases:
select an author
check for reservations
receive an author data
receive number of reservations
enter data for a new book
find out the oldest reservation
edit data for an existing book
make a reservation
enter multimedia data
receive notification for reservation
receive notification from multimedia adding
make a lending
check for free samples
transmit lending data
receive number of free samples
receive notification for lending
For process of lending we'll need these use cases: "make a lending", "transmit lending data", "receive
number of reservations", "check for reservation" and "receive notification from lending". Let's take a
look at steps of every use case.
- Make a lending
1 Activate the make/return lending part from the lender's interface.
2 A lending form appears on the lender's screen.
CSE Department,
VNRVJIET

72
www.jntuworld.com

www.jntuworld.com
3 The lender enters the necessary data.
4 Lending data are transmited to the Digital Library
- Transmit lending data
1 The lender clicks the SUBMIT button on the lending form, and lending data is sent to the Digital
Library
2 The Digital Library receives this data, and a request for new lending is sent to the Lending
database
3 The request is sent to the Lending database, and an acknowledge is waited to receive
When data is transmited to the Lending database, a mechanizam for adding a new record in the
database is activated. This operation incorporates these use cases located in the Lending package:
"receive request for new lending", "perform a lending" and "transmit lending result". When performing
a lending, also results from the Book package use cases are obtained. This process needs results for
pending reservation made by that member for that book, and this will be done only if a result from
"receive number of reservations" use case is not equal to zero. Checking for pending reservations is
necessary, because if a reservation is made for a book ( a sample for that book is holded for the
member), then when a lending is done, that reservation from Reservation database must be deleted.
- Receive request for new lending
1 The Lending database receives a request for performing a process of creating a new record
2 This activates the process of creating and adding a new record to the database
- Perform a lending
1 Database has activated its mechanizams for creating a new record
2 The result of creation a new record is aimed
3 This result is sent to the Digital Library
- Transmit lending result
1 Result from lending is sent to the Digital Library
2 This result is transmited to the lender's interface
Now we can continue with use cases from the Book package:
- Receive notification from lending
1 Lender's interface has received result from lending
2 This result is decoded, and a message is printed on a screen
3 A request for current state in the member's lending record is sent to the Lending database
4 A list of records is retreived form the Lending database
5 This list is printed on the lender's screen
The sequence diagram for these use cases steps is shown on the next picture:

CSE Department,
VNRVJIET

73
www.jntuworld.com

www.jntuworld.com

The sequence diagram for "Make a

lending"
As you can see some of use cases in the given list were not used for this purpose. They
are internaly used in the activation of object in the Lending database. The operation for
creation a record incorporates these use cases, and after that returns a result, that is
dotted line message going out from the activation in the LendingDB lifeline.
For an exercise try drawing out the sequence diagrams for "return a lending" use case from the Book
package, and for "enter data for a new journal" use case from the Journal package.
After you model interaction among components, the system is much closer to
becoming reality. As you model the interactions, you may find that it's
appropriate to modify the use cases at the base of these interactions. The results
of this analysis should make it easy for programmers to code the system objects
and how they communicate with one another.

Analyze Integration with Cooperate Systems

After the GRAPPLE analysis segment has produced the generel concept of the Digital Library
system, a system engineer will strat thinking about how the physical structure should look. He or she
will start considering alternative network topologies and how to implement them, and will start figuring
out which software components belong on which nodes in the network.
The development team have made decision that a library local network will take part in the Digital
Library system, and that an Internet interface will be implemented on the LAN's server.
First let's look at the physical architecture of the library's local area network.

CSE Department,
VNRVJIET

74
www.jntuworld.com

www.jntuworld.com

The Deployment diagram for the library LAN

As you can see from this deployment diagram, library LAN consists from these hardware
components:
Component name
Amount
Server
1
DataEntry PC
2
Lender's PC
1
Search terminal
6
Passive hub
2
Server and DataEntry PCs are located in the same room, also one Passive hub is located in that
room. A cable from this passive hub goes out from the room, to the corridor. There another passive
hub is located. From this hub cables goes to the Search terminals located in the corridor, and to the
Lender's PC located in the Lending area.
When we have a physical architecture in front of us, let's look at possibility od implementing an
Internet interface on the Server. This interface will be used locally from the Search terminals, from
Lender's PC and from DataEntry PCs and trough the Internet from member's homes or offices.
Therefore a new hardware must be implemented in the library's LAN.
Library's LAN will have the same structure. New hardware will be added only to the Server's side, and
that is a Network Interconnection Facility (NIF). The NIF consists of a name server (a database that
validates connections), a router (a device for linking networks together), and a gateway (a device for
translating information from one communication protocol to another). The gateway allows Internet
members to access the Digital Library from home or from their office.
On the member's side only a computer with Internet connection, and Internet browser is necessary.
Also a member must have an alias and password to make access to the Digital Library's Web page.
To ilustrate the deployment, the System Engineer delivers the deployment diagram shown on the
following picture:

CSE Department,
VNRVJIET

75
www.jntuworld.com

www.jntuworld.com

The Deployment diagram for the Digital Library system

Designing Look (GUI)

You've come trough a lot of use-case driven analysis. Now you're going to look some of aspects of
system analysis. They are traceable to use cases, and both are extremly important to the final
product. Graphical User Interfaces (GUIs) determine system usability. Let's dive into GUI desing
process.
Some General Principles of GUI Design
User interface design, equals parts art and science, draws upon the vision of the graphic artist, the
findings of the human factors researcher, and the intuitions of the potential user. Some general
principles in GUI design are:
1. Understand what the user has to do. User interface designers typically perform a task analysis
to understand the nature of the user's work. Our use case analysis roughly corresponds to this.
2. Make the user feel in control of the interaction. Always include the capability for the user to cancel
an interaction after it's started.
3. Give the user multiple ways to accomplish each interface-related action (like closing a window or
a file) and forgive user errors gracefully.
4. Because of cultural influences, our eyes are drawn to the upper-left corner of a screen. Put the
highest priority information there.
5. Take advantage of spatial relationships. Screen components that are related should appear near
one another, perhaps with a box around them.
6. Emphasize readability and understanding. Use active voice to communicate ideas and concepts.
7. Limit the number of colors you use. Limit that number severely. Too many colors will distract the
user from the task at hand.
8. If you're thinking of using color to denote meaning, remember it's not always easy for a user to
see an association between a color and a meaning.
9. As is the case with the color, limit your use of fonts. Avoid italics and ornate fonts.
10. Try to keep components (like the buttons and list boxes) the same size as much as possible. If
you use different-size components, a multiplicity of colors, and a variety of fonts, you'll create a
patchwork that GUI specialists call a clown-pants design.
11. Left-align components and data fields - line them up according to their left-side edges. This
minimizes eye movements when the user has to scan the screen.
12. When the user has to read and process information and then click a button, put the buttons in a
CSE Department,
VNRVJIET

76
www.jntuworld.com

www.jntuworld.com
column to the right of the information or in a row below and to the right of the information. This is
consistent with the natural tendency to read left to right. If one of the buttons is a default button,
highlight it and make it the first button in the set.
The GUI JAD Session
For this session, you recruit potential users of the system. For the Digital Library we'd recruit
members, lenders and data entry clerks. The users' participation in the session is a two-part affair. In
the first part, they derive the user interface screens. In the second, they approve prototypes
generated by the development team.
How the users derive the screens? The facilitator suggests a use case to strat from, and the users
discuss ways to implement that use case via the system. When they're ready to start talking at the
level of a specific screen, the users work with paper mockups. The facilitator provides a large sheet of
easel paper in landscape view to represent the screen. Post-is note stickies represent the GUI
components. The users' task is to work as a group to position the components appropriately.
When they reach agreement on which components should be on a screen and where those
components should be located, development team members create prototype screens. As they work,
they use appropriate GUI principles. Then, they present those screens on computers, and the users
make any necessary modifications.
It's your turn to draw out the users' screens. Let your imagination and GUI principles guide you when
constructing these screen shots. To make your work easier a set of UML diagrams for the member,
lender and data entry clerk screens are given to you. Look at these diagrams and draw out necessary
screen shots. DataEntry clerk's diagrams are too large and complex, and if you want you may draw
out these screen shots or not.

The UML state diagram for the Member interface

The UML composite diagram for the Member screen hierarchy

CSE Department,
VNRVJIET

77
www.jntuworld.com

www.jntuworld.com

The UML state diagram for high-level screen flow in the Employee interface

The UML composite diagram for the Employee-Lender screen hierarchy

Something About Implementation of Digital Library

When all appropriate analysis and design parts of GRAPPLE are complete, the team complies its
result into a design document and hads off copies to the client and to the programmers. It then falls to
the programmers to start turning the design into code.After writing the code it will be teste, rewriten
according to the results of the tests, and retested - a process that will continue back and forth until the
code passes all tests. The use case analysis forms the basis of the tests.
The one possible implemented Digital Library that you'll wisit after today's workshop, is
coded in Jasmine OODBMS. Jasmine is used because it is Object Oriented language,
has possibility of adding Multimedia data into your database, and allows you to create
stand alone applications, or applications that have Web interfaces. Other agvantages of using Web
interface are client software shouldn't be installed to the client's machine (client only should have an
Internet browser) and Web software doesn't depend on the hardware platform that runs on.
The Server side in the deployment diagram developed for the purpose of Digital Library, now will look
like:

CSE Department,
VNRVJIET

78
www.jntuworld.com

www.jntuworld.com

The server node with part of its components

* The Jasmine OODBMS and WebLink are parts from the Jasmine package. With Jasmine OODBMS we created necessary classes, and with
WebLink we implemented the web interface.

Document specialists begin creating documentation for the system, and they create training materials
as well. A godd document creation effort should proceed like a good system development effort, with
careful planing, analysis, and testing, and should begin early in the development process.
The main idea of modeling one system is to focus intense efforts on analysis and
design so that implementation confronts as few challenges as possible and the
result of the project is a system that fully meets the client's needs.

A class model is comprised of one or more class diagrams and the supporting specifications that
describe model elements including classes, relationships between classes, and interfaces. There are
guidelines for:
1.
2.
3.
4.
5.
6.

1.

General issues
Classes
Interfaces
Relationships
Inheritance
Aggregation and Composition

General Guidelines

Because class diagrams are used for a variety of purposes from understanding requirements to
describing your detailed design you will need to apply a different style in each circumstance. This
section describes style guidelines pertaining to different types of class diagrams.

CSE Department,
VNRVJIET

79
www.jntuworld.com

www.jntuworld.com
Figure 1. Analysis and design versions of a class.

Figure 2. Modeling association classes.

1.
2.
3.
4.
5.
6.

Identify Responsibilities on Domain Class Diagrams.

Indicate Visibility Only On Design Models.
Indicate Language-Dependent Visibility With Property Strings.
Indicate Types Only On Design Models.
Indicate Types On Analysis Models Only When The Type is an Actual Requirement.
Design Class Diagrams Should Reflect Language Naming Conventions. In Figure 1 you see
that the design version of the Order class uses names that conform to common Java
programming conventions such as placementDate and calculateTaxes().
7. Model Association Classes On Analysis Diagrams. Figure 2 shows that association classes are
depicted as class attached via a dashed line to an association the association line, the class,
and the dashed line are considered one symbol in the UML.
8. Do Not Name Associations That Have Association Classes.
9. Center The Dashed Line of an Association Class.

CSE Department,
VNRVJIET

80
www.jntuworld.com

www.jntuworld.com

2.

Class Style Guidelines

A class is effectively a template from which objects are created (instantiated). Although in the real
world Doug, Wayne, John, and Bill are all student objects we would model the class Student instead.
Classes define attributes, information that is pertinent to their instances, and operations, functionality
that the objects support. Classes will also realize interfaces (more on this later). Note that you may
need to soften some of the naming guidelines to reflect your implementation language or software
purchased from a third-party vendor.
Figure 3. The OrderItem class with and without scaffolding code.

Figure 4. Indicating the exceptions thrown by an operation.

+ findAllInstances(): Vector {exceptions=NetworkFailure, DatabaseError}
1.
2.
3.
4.
5.

Use Common Terminology for Names

Prefer Complete Singular Nouns for Class Names
Name Operations with a Strong Verb
Name Attributes With a Domain-Based Noun
Do Not Model Scaffolding Code. Scaffolding code refers to the attributes and operations
required to implement basic functionality within your classes, such as the code required to
implement relationships with other classes. Figure 3 depicts the difference between the
OrderItem class without scaffolding code and with it.
6. Never Show Classes With Just Two Compartments
7. Label Uncommon Class Compartments
8. Include an Ellipsis ( ) At The End of Incomplete Lists
9. List Static Operations/Attributes Before Instance Operations/Attributes
10. List Operations/Attributes in Decreasing Visibility
11. For Parameters That Are Objects, Only List Their Type
12. Develop Consistent Method Signatures
CSE Department,
VNRVJIET

81
www.jntuworld.com

www.jntuworld.com
13. Avoid Stereotypes Implied By Language Naming Conventions
14. Indicate Exceptions In An Operations Property String. Exceptions can be indicated with a
UML property string, an example of which is shown in Figure 4.

3.

Interfaces

An interface is a collection of operation signature and/or attribute definitions that ideally defines a
cohesive set of behaviors. Interfaces are implemented, realized in UML parlance, by classes and
components to realize an interface a class or component must implement the operations and
attributes defined by the interface. Any given class or component may implement zero or more
interfaces and one or more classes or components can implement the same interface.
Figure 5. Interfaces on UML class diagrams.

1. Interface Definitions Must Reflect Implementation Language Constraints. In Figure 5 you see
that a standard class box has been used to define the interface PersistentObject (note the use
of the <<interface>> stereotype).
2. Name Interfaces According To Language Naming Conventions
3. Apply Lollipop Notation To Indicate That A Class Realizes an Interface
4. Define Interfaces Separately From Your Classes
5. Do Not Model the Operations and Attributes of an Interface in Your Classes. In Figure 5 youll
notice that the Shipment class does not include the attributes or operations defined by the two
interfaces that it realizes.
6. Consider an Interface to Be a Contract

4.

Relationship Guidelines

For ease of discussion the term relationships shall include all UML concepts such as associations,
aggregation, composition, dependencies, inheritance, and realizations in other words, if its a line on
a UML class diagram well consider it a relationship.
Figure 6. Shipping an order.
CSE Department,
VNRVJIET

82
www.jntuworld.com

www.jntuworld.com

Figure 7. Modeling an order.

Figure 8. Professors and seminars.

Figure 9. Modeling people at a university.

CSE Department,
VNRVJIET

83
www.jntuworld.com

www.jntuworld.com

1.
2.
3.
4.

Model Relationships Horizontally

Collaboration Indicates Need for a Relationship
Model a Dependency When The Relationship is Transitory
Depict Similar Relationships Involving A Common Class As A Tree. In Figure 6 you see that
both Delivery and Order have a dependency on OIDGenerator. Note how the two
dependencies are drawn in combination in tree configuration, instead of as two separate
lines, to reduce clutter in the diagram.
5. Always Indicate the Multiplicity
6. Avoid a Multiplicity of *
7. Replace Relationships By Indicating Attribute Types. In Figure 7 you see that Customer has a
shippingAddress attribute of type Address part of the scaffolding code to maintain the
association between customer objects and address objects.
8. Do Not Model Implied Relationships
9. Do Not Model Every Single Dependency
10. Center Names on Associations
11. Write Concise Association Names In Active Voice
12. Indicate Directionality To Clarify An Association Name
13. Name Unidirectional Associations In The Same Direction
14. Word Association Names Left-To-Right
15. Indicate Role Names When Multiple Associations Between Two Classes Exist
16. Indicate Role Names on Recursive Associations
17. Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions. The
lives at association of Figure 9 is uni-directional.
18. Redraw Inherited Associations Only When Something Changes
19. Question Multiplicities Involving Minimums And Maximums

6.

Inheritance Guidelines

Inheritance models is a and is like relationships, enabling you to easily reuse existing data and
code. When A inherits from B we say that A is the subclass of B and that B is the
superclass of A. Furthermore, we say that we have pure inheritance when A inherits all of the
attributes and methods of B. The UML modeling notation for inheritance is a line with a closed
arrowhead pointing from the subclass to the superclass.
1.
2.
3.
4.

7.

Apply the Sentence Rule For Inheritance

Place Subclasses Below Superclasses
Beware of Data-Based Inheritance
A Subclass Should Inherit Everything

Aggregation and Composition Guidelines

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage,
wings, engines, landing gear, flaps, and so on. A delivery shipment contains one or more packages. A
CSE Department,
VNRVJIET

84
www.jntuworld.com

www.jntuworld.com
team consists of two or more employees. These are all examples of the concept of aggregation, which
represents is part of relationships. An engine is part of a plane, a package is part of a shipment, and
an employee is part of a team. Aggregation is a specialization of association, specifying a whole-part
relationship between two objects. Composition is a stronger form of aggregation where the whole and
parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its
parts. From a stylistic point of view, because aggregation and composition are both specializations of
association the guidelines for associations apply.
Figure 10. Examples of aggregation and composition.

1.
2.
3.
4.
5.
6.

Apply the Sentence Rule for Aggregation

You Should Be Interested In Both The Whole And The Part
Depict the Whole to the Left of the Part
Apply Composition to Aggregates of Physical Items
Apply Composition When the Parts Share The Persistence Lifecycle With the Whole
Dont Worry About Getting the Diamonds Right

8. Recommended Resources
Are You Ready For the MDA?
Be Realistic About the UML
Examining The Model Driven Architecture (MDA)
Introduction to the Diagrams of UML 2
Introduction to Object Orientation (OO) and UML
Introduction to UML Class Diagrams
Modeling Style Guidelines
Pavel Hruby's UML 2.0 Stencil for Visio
Roadmap for Agile MDA
Why Extend the UML Beyond Object and Component Technology?
XP and the UML?

CSE Department,
VNRVJIET

85
www.jntuworld.com

www.jntuworld.com

The Elements of UML 2.0 Style describes a collection of standards, conventions, and
guidelines for creating effective UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams that are easier to understand and work
with. These conventions exist as a collection of simple, concise guidelines that if applied
consistently, represent an important first step in increasing your productivity as a modeler.
This book is oriented towards intermediate to advanced UML modelers, although there are
numerous examples throughout the book it would not be a good way to learn the UML (instead,
consider The Object Primer). The book is a brief 188 pages long and is conveniently
pocket-sized so it's easy to carry around.

The Object Primer 3rd Edition: Agile Model Driven Development with UML 2
is an important reference book for agile modelers, describing how to develop 35 types of
agile models including all 13 UML 2 diagrams. Furthermore, this book describes the
techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to
give you the fundamental testing skills which you require to succeed at agile software
development. The book also shows how to move from your agile models to source code ( Java
examples are provided) as well as how to succeed at implementation techniques such as
refactoring and test-driven development (TDD). The Object Primer also includes a
chapter overviewing the critical database development techniques (database refactoring,
object/relational mapping, legacy analysis, and database access coding) from my
award-winning Agile Database Techniques book.

Agile Modeling: Effective Practices for Extreme Programming and the Unified
Process is the seminal book describing how agile software developers approach modeling
and documentation. It describes principles and practices which you can tailor into your
existing software process, such as XP, the Rational Unified Process (RUP) , or the
Agile Unified Process (AUP), to streamline your modeling and documentation efforts.
Modeling and documentation are important aspects of any software project, including agile
projects, and this book describes in detail how to elicit requirements, architect, and then
design your system in an agile manner.

UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying,
constructing and documenting the components of software and non software systems. Here the
Visualization is the most important part which needs to be understood and remembered by heart.
UML notations are the most important elements in modeling. Efficient and appropriate use of
notations is very important for making a complete and meaningful model. The model is useless
unless its purpose is depicted properly.
So learning notations should be emphasized from the very beginning. Different notations are
available for things and relationships. And the UML diagrams are made using the notations of things
and relationships. Extensibility is another important feature which makes UML more powerful and
flexible.
The chapter describes the UML Basic Notations in more details. This is just an extension to the UML
buildling block section I have discussed in previous chapter.

Structural Things:
Graphical notations used in structural things are the most widely used in UML. These are considered
as the nouns of UML models. Following are the list of structural things.
CSE Department,
VNRVJIET

86
www.jntuworld.com

www.jntuworld.com
Classes
Interface
Collaboration
Use case
Active classes
Components
Nodes

Class Notation:
UML class is represented by the diagram shown below. The diagram is divided into four parts.

The top section is used to name the class.

The second one is used to show the attributes of the class.
The third section is used to describe the operations performed by the class.
The fourth section is optional to show any additional components.

Classes are used to represent objects. Objects can be anything having properties and responsibility.

Object Notation:
The object is represented in the same way as the class. The only difference is the name which is
underlined as shown below.

CSE Department,
VNRVJIET

87
www.jntuworld.com

www.jntuworld.com
As object is the actual implementation of a class which is known as the instance of a class. So it has
the same usage as the class.

Interface Notation:
Interface is represented by a circle as shown below. It has a name which is generally written below
the circle.

Interface is used to describe functionality without implementation. Interface is the just like a template
where you define different functions not the implementation. When a class implements the interface it
also implements the functionality as per the requirement.

Collaboration Notation:
Collaboration is represented by a dotted eclipse as shown below. It has a name written inside the
eclipse.

Collaboration represents responsibilities. Generally responsibilities are in a group.

Use case Notation:

Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.

CSE Department,
VNRVJIET

88
www.jntuworld.com

www.jntuworld.com

Use case is used to capture high level functionalities of a system.

Actor Notation:
An actor can be defined as some internal or external entity that interacts with the system.

Actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation:

Initial state is defined show the start of a process. This notation is used in almost all diagrams.

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation:

Final state is used to show the end of a process. This notation is also used in almost all diagrams to
describe the end.

CSE Department,
VNRVJIET

89
www.jntuworld.com

www.jntuworld.com

The usage of Final State Notation is to show the termination point of a process.

Active class Notation:

Active class looks similar to a class with a solid border. Active class is generally used to describe
concurrent behaviour of a system.

Active class is used to represent concurrency in a system.

Component Notation:
A component in UML is shown as below with a name inside. Additional elements can be added
wherever required.

Component is used to represent any part of a system for which UML diagrams are made.

Node Notation:
A node in UML is represented by a square box as shown below with a name. A node represents a
physical component of the system.

CSE Department,
VNRVJIET

90
www.jntuworld.com

www.jntuworld.com

Node is used to represent physical part of a system like server, network etc.

Behavioural Things:
Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to
represent the dynamic part of software and non software systems. These features include
interactions and state machines.
Interactions can be of two types:

Sequential (Represented by sequence diagram)

Collaborative (Represented by collaboration diagram)

Interaction Notation:
Interaction is basically message exchange between two UML components. The following diagram
represents different notations used in an interaction.

CSE Department,
VNRVJIET

91
www.jntuworld.com

www.jntuworld.com

Interaction is used to represent communication among the components of a system.

State machine Notation:

State machine describes the different states of a component in its life cycle. The notations are
described in the following diagram.

CSE Department,
VNRVJIET

92
www.jntuworld.com

www.jntuworld.com

State machine is used to describe different states of a system component. The state can be active,
idle or any other depending upon the situation.

Grouping Things:
Organizing the UML models are one of the most important aspects of the design. In UML there is only
one element available for grouping and that is package.

Package Notation:
Package notation is shown below and this is used to wrap the components of a system.

Annotational Things:
In any diagram explanation of different elements and their functionalities are very important. So UML
has notes notation to support this requirement.

CSE Department,
VNRVJIET

93
www.jntuworld.com

www.jntuworld.com

Note Notation:
This notation is shown below and they are used to provide necessary information of a system.

Relationships
A model is not complete unless the relationships between elements are described properly. The
Relationship gives a proper meaning to an UML model. Following are the different types of
relationships available in UML.

Dependency
Association
Generalization
Extensibility

Dependency Notation:
Dependency is an important aspect in UML elements. It describes the dependent elements and the
direction of dependency.
Dependency is represented by a dotted arrow as shown below. The arrow head represents the
independent element and the other end the dependent element.

Dependency is used to represent dependency between two elements of a system.

Association Notation:
Association describes how the elements in an UML diagram are associated. In simple word it
describes how many elements are taking part in an interaction.

CSE Department,
VNRVJIET

94
www.jntuworld.com

www.jntuworld.com
Association is represented by a dotted line with (without) arrows on both sides. The two ends
represent two associated elements as shown below. The multiplicity is also mentioned at the ends (1,
* etc) to show how many objects are associated.

Association is used to represent the relationship between two elements of a system.

Generalization Notation:
Generalization describes the inheritance relationship of the object oriented world. It is parent and
child relationship.
Generalization is represented by an arrow with hollow arrow head as shown below. One end
represents the parent element and the other end child element.

Generalization is used to describe parent-child relationship of two elements of a system.

Extensibility Notation:
All the languages (programming or modeling) have some mechanism to extend its capabilities like
syntax, semantics etc. UML is also having the following mechanisms to provide extensibility features.

Stereotypes (Represents new elements)

Tagged values (Represents new attributes)
Constraints (Represents the boundaries)

CSE Department,
VNRVJIET

95
www.jntuworld.com

www.jntuworld.com

Extensibility notations are used to enhance the power of the language. It is basically additional
elements used to represent some extra behaviour of the system. These extra behaviours are not
covered by the standard available notations.
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of
software systems.
UML was created by Object Management Group (OMG) and UML 1.0 specification draft was
proposed to the OMG in January 1997.
OMG is continuously putting effort to make a truly industry standard.
UML stands for Unified Modeling Language.
UML is different from the other common programming languages like C++, Java, COBOL etc.
UML is a pictorial language used to make software blue prints.
So UML can be described as a general purpose visual modeling language to visualize, specify,
construct and document software system. Although UML is generally used to model software systems
but it is not limited within this boundary. It is also used to model non software systems as well like
process flow in a manufacturing unit etc.
UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design. After some
standardization UML is become an OMG (Object Management Group) standard.

Goals of UML:
A picture is worth a thousand words, this absolutely fits while discussing about UML. Object oriented
concepts were introduced much earlier than UML. So at that time there were no standard
methodologies to organize and consolidate the object oriented development. At that point of time
UML came into picture.
There are a number of goals for developing UML but the most important is to define some general
purpose modeling language which all modelers can use and also it needs to be made simple to
understand and use.

CSE Department,
VNRVJIET

96
www.jntuworld.com

www.jntuworld.com
UML diagrams are not only made for developers but also for business users, common people and
anybody interested to understand the system. The system can be a software or non software. So it
must be clear that UML is not a development method rather it accompanies with processes to make a
successful system.
At the conclusion the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today.s complex environment.

A conceptual model of UML:

To understand conceptual model of UML first we need to clarify What is a conceptual model? and
Why a conceptual model is at all required?
A conceptual model can be defined as a model which is made of concepts and their
relationships.
A conceptual model is the first step before drawing a UML diagram. It helps to understand the
entities in the real world and how they interact with each other.
As UML describes the real time systems it is very important to make a conceptual model and then
proceed gradually. Conceptual model of UML can be mastered by learning the following three major
elements:

UML building blocks

Rules to connect the building blocks
Common mechanisms of UML

Object oriented concepts:

UML can be described as the successor of object oriented analysis and design.
An object contains both data and methods that control the data. The data represents the state of the
object. A class describes an object and they also form hierarchy to model real world system. The
hierarchy is represented as inheritance and the classes can also be associated in different manners
as per the requirement.
The objects are the real world entities that exist around us and the basic concepts like abstraction,
encapsulation, inheritance, polymorphism all can be represented using UML.
So UML is powerful enough to represent all the concepts exists in object oriented analysis and
design. UML diagrams are representation of object oriented concepts only. So before learning UML, it
becomes important to understand OO concepts in details.
Following are some fundamental concepts of object oriented world:
Objects: Objects represent an entity and the basic building block.
Class: Class is the blue print of an object.
Abstraction: Abstraction represents the behavior of an real world entity.
Encapsulation: Encapsulation is the mechanism of binding the data together and hiding them
from outside world.
Inheritance: Inheritance is the mechanism of making new classes from existing one.
Polymorphism: It defines the mechanism to exists in different forms.
CSE Department,
VNRVJIET

97
www.jntuworld.com

www.jntuworld.com

OO Analysis and Design

Object Oriented analysis can be defined as investigation and to be more specific it is the investigation
of objects. Design means collaboration of identified objects.
So it is important to understand the OO analysis and design concepts. Now the most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also done
for an existing system. Now an efficient analysis is only possible when we are able to start thinking in
a way where objects can be identified. After identifying the objects their relationships are identified
and finally the design is produced.
So the purpose of OO analysis and design can described as:
Identifying the objects of a system.
Identify their relationships.
Make a design which can be converted to executables using OO languages.
There are three basic steps where the OO concepts are applied and implemented. The steps can be
defined as
OO Analysis --> OO Design --> OO implementation using OO languages

Now the above three points can be described in details:

During object oriented analysis the most important purpose is to identify objects and
describing them in a proper way. If these objects are identified efficiently then the next job of
design is easy. The objects should be identified with responsibilities. Responsibilities are the
functions performed by the object. Each and every object has some type of responsibilities to
be performed. When these responsibilities are collaborated the purpose of the system is
fulfilled.
The second phase is object oriented design. During this phase emphasis is given upon the
requirements and their fulfilment. In this stage the objects are collaborated according to their
intended association. After the association is complete the design is also complete.
The third phase is object oriented implementation. In this phase the design is implemented
using object oriented languages like Java, C++ etc.

Role of UML in OO design:

UML is a modeling language used to model software and non software systems. Although UML is
used for non software systems the emphasis is on modeling object oriented software applications.
Most of the UML diagrams discussed so far are used to model different aspects like static, dynamic
etc. Now what ever be the aspect the artifacts are nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all would
basically be designed based on the objects.
So the relation between OO design and UML is very important to understand. The OO design is
transformed into UML diagrams according to the requirement. Before understanding the UML in
details the OO concepts should be learned properly. Once the OO analysis and design is done the
next step is very easy. The input from the OO analysis and design is the input to the UML diagrams.
CSE Department,
VNRVJIET

98
www.jntuworld.com

www.jntuworld.com
As UML describes the real time systems it is very important to make a conceptual model and then
proceed gradually. Conceptual model of UML can be mastered by learning the following three major
elements:

UML building blocks

Rules to connect the building blocks
Common mechanisms of UML
This chapter describes all the UML building blocks. The building blocks of UML can be defined as:

Things
Relationships
Diagrams

(1) Things:
Things are the most important building blocks of UML. Things can be:

Structural
Behavioral
Grouping
Annotational

Structural things:
The Structural things define the static part of the model. They represent physical and conceptual
elements. Following are the brief descriptions of the structural things.

Class:
Class represents set of objects having similar responsibilities.

Interface:
Interface defines a set of operations which specify the responsibility of a class.

Collaboration:
Collaboration defines interaction between elements.
CSE Department,
VNRVJIET

99
www.jntuworld.com

www.jntuworld.com

Use case:
Use case represents a set of actions performed by a system for a specific goal.

Component:
Component describes physical part of a system.

Node:
A node can be defined as a physical element that exists at run time.

Behavioral things:
A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things:

Interaction:
Interaction is defined as a behavior that consists of a group of messages exchanged among elements
to accomplish a specific task.

State machine:
State machine is useful when the state of an object in its life cycle is important. It defines the
sequence of states an object goes through in response to events. Events are external factors
responsible for state change.

CSE Department,
VNRVJIET

100
www.jntuworld.com

www.jntuworld.com

Grouping things:
Grouping things can be defined as a mechanism to group elements of a UML model together. There
is only one grouping thing available:

Package:
Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things:
Annotational things can be defined as a mechanism to capture remarks, descriptions, and
comments of UML model elements. Note is the only one Annotational thing available.

Note:
A note is used to render comments, constraints etc of an UML element.

(2) Relationship :
Relationship is another most important building block of UML. It shows how elements are associated
with each other and this association describes the functionality of an application.
There are four kinds of relationships available.

Dependency:
Dependency is a relationship between two things in which change in one element also affects the
other one.

CSE Department,
VNRVJIET

101
www.jntuworld.com

www.jntuworld.com

Association:
Association is basically a set of links that connects elements of an UML model. It also describes how
many objects are taking part in that relationship.

Generalization:
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes inheritance relationship in the world of objects.

Realization:
Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are
used to make a complete UML diagram and the diagram represents a system.
The visual effect of the UML diagram is the most important part of the entire process. All the other
elements are used to make it a complete one.
UML includes the following nine diagrams and the details are described in the following chapters.

1.
2.
3.
4.
5.
6.
7.
8.
9.

Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Activity diagram
Statechart diagram
Deployment diagram
Component diagram

Any real world system is used by different users. The users can be developers, testers, business people,
analysts and many more. So before designing a system the architecture is made with different
CSE Department,
VNRVJIET

102
www.jntuworld.com

www.jntuworld.com
perspectives in mind. The most important part is to visualize the system from different viewer.s
perspective. The better we understand the better we make the system.
UML plays an important role in defining different perspectives of a system. These perspectives are:
Design
Implementation
Process
Deployment
And the centre is the Use Case view which connects all these four. A Use case represents the
functionality of the system. So the other perspectives are connected with use case.
Design of a system consists of classes, interfaces and collaboration. UML provides class
diagram, object diagram to support this.
Implementation defines the components assembled together to make a complete physical
system. UML component diagram is used to support implementation perspective.
Process defines the flow of the system. So the same elements as used in Design are also used
to support this perspective.
Deployment represents the physical nodes of the system that forms the hardware. UML
deployment diagram is used to support this perspective.
It is very important to distinguish between the UML model. Different diagrams are used for different
type of UML modeling. There are three important type of UML modelings:

Structural modeling:
Structural modeling captures the static features of a system. They consist of the followings:

Classes diagrams
Objects diagrams
Deployment diagrams
Package diagrams
Composite structure diagram
Component diagram
Structural model represents the framework for the system and this framework is the place where all
other components exist. So the class diagram, component diagram and deployment diagrams are the
part of structural modeling. They all represent the elements and the mechanism to assemble them.
But the structural model never describes the dynamic behavior of the system. Class diagram is the
most widely used structural diagram.

Behavioral Modeling:
Behavioral model describes the interaction in the system. It represents the interaction among the
structural diagrams. Behavioral modeling shows the dynamic nature of the system. They consist of
the following:

CSE Department,
VNRVJIET

103
www.jntuworld.com

www.jntuworld.com
Activity diagrams
Interaction diagrams
Use case diagrams
All the above show the dynamic sequence of flow in a system.

Architectural Modeling:
Architectural model represents the overall framework of the system. It contains both structural and
behavioral elements of the system. Architectural model can be defined as the blue print of the entire
system. Package diagram comes under architectural modeling.
UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying,
constructing and documenting the components of software and non software systems. Here the
Visualization is the most important part which needs to be understood and remembered by heart.
UML notations are the most important elements in modeling. Efficient and appropriate use of
notations is very important for making a complete and meaningful model. The model is useless
unless its purpose is depicted properly.
So learning notations should be emphasized from the very beginning. Different notations are
available for things and relationships. And the UML diagrams are made using the notations of things
and relationships. Extensibility is another important feature which makes UML more powerful and
flexible.
The chapter describes the UML Basic Notations in more details. This is just an extension to the UML
buildling block section I have discussed in previous chapter.

Structural Things:
Graphical notations used in structural things are the most widely used in UML. These are considered
as the nouns of UML models. Following are the list of structural things.

Classes
Interface
Collaboration
Use case
Active classes
Components
Nodes

Class Notation:
UML class is represented by the diagram shown below. The diagram is divided into four parts.

The top section is used to name the class.

The second one is used to show the attributes of the class.
The third section is used to describe the operations performed by the class.
The fourth section is optional to show any additional components.
CSE Department,
VNRVJIET

104
www.jntuworld.com

www.jntuworld.com

Classes are used to represent objects. Objects can be anything having properties and responsibility.

Object Notation:
The object is represented in the same way as the class. The only difference is the name which is
underlined as shown below.

As object is the actual implementation of a class which is known as the instance of a class. So it has
the same usage as the class.

Interface Notation:
Interface is represented by a circle as shown below. It has a name which is generally written below
the circle.

CSE Department,
VNRVJIET

105
www.jntuworld.com

www.jntuworld.com
Interface is used to describe functionality without implementation. Interface is the just like a template
where you define different functions not the implementation. When a class implements the interface it
also implements the functionality as per the requirement.

Collaboration Notation:
Collaboration is represented by a dotted eclipse as shown below. It has a name written inside the
eclipse.

Collaboration represents responsibilities. Generally responsibilities are in a group.

Use case Notation:

Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities.

Use case is used to capture high level functionalities of a system.

Actor Notation:
An actor can be defined as some internal or external entity that interacts with the system.

CSE Department,
VNRVJIET

106
www.jntuworld.com

www.jntuworld.com

Actor is used in a use case diagram to describe the internal or external entities.

Initial State Notation:

Initial state is defined show the start of a process. This notation is used in almost all diagrams.

The usage of Initial State Notation is to show the starting point of a process.

Final State Notation:

Final state is used to show the end of a process. This notation is also used in almost all diagrams to
describe the end.

The usage of Final State Notation is to show the termination point of a process.

Active class Notation:

Active class looks similar to a class with a solid border. Active class is generally used to describe
concurrent behaviour of a system.

CSE Department,
VNRVJIET

107
www.jntuworld.com

www.jntuworld.com
Active class is used to represent concurrency in a system.

Component Notation:
A component in UML is shown as below with a name inside. Additional elements can be added
wherever required.

Component is used to represent any part of a system for which UML diagrams are made.

Node Notation:
A node in UML is represented by a square box as shown below with a name. A node represents a
physical component of the system.

Node is used to represent physical part of a system like server, network etc.

Behavioural Things:
Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to
represent the dynamic part of software and non software systems. These features include
interactions and state machines.
Interactions can be of two types:

Sequential (Represented by sequence diagram)

Collaborative (Represented by collaboration diagram)

Interaction Notation:

CSE Department,
VNRVJIET

108
www.jntuworld.com

www.jntuworld.com
Interaction is basically message exchange between two UML components. The following diagram
represents different notations used in an interaction.

Interaction is used to represent communication among the components of a system.

State machine Notation:

State machine describes the different states of a component in its life cycle. The notations are
described in the following diagram.

CSE Department,
VNRVJIET

109
www.jntuworld.com

www.jntuworld.com

State machine is used to describe different states of a system component. The state can be active,
idle or any other depending upon the situation.

Grouping Things:
Organizing the UML models are one of the most important aspects of the design. In UML there is only
one element available for grouping and that is package.

Package Notation:
Package notation is shown below and this is used to wrap the components of a system.

Annotational Things:
In any diagram explanation of different elements and their functionalities are very important. So UML
has notes notation to support this requirement.

CSE Department,
VNRVJIET

110
www.jntuworld.com

www.jntuworld.com

Note Notation:
This notation is shown below and they are used to provide necessary information of a system.

Relationships
A model is not complete unless the relationships between elements are described properly. The
Relationship gives a proper meaning to an UML model. Following are the different types of
relationships available in UML.

Dependency
Association
Generalization
Extensibility

Dependency Notation:
Dependency is an important aspect in UML elements. It describes the dependent elements and the
direction of dependency.
Dependency is represented by a dotted arrow as shown below. The arrow head represents the
independent element and the other end the dependent element.

Dependency is used to represent dependency between two elements of a system.

Association Notation:
Association describes how the elements in an UML diagram are associated. In simple word it
describes how many elements are taking part in an interaction.

CSE Department,
VNRVJIET

111
www.jntuworld.com

www.jntuworld.com
Association is represented by a dotted line with (without) arrows on both sides. The two ends
represent two associated elements as shown below. The multiplicity is also mentioned at the ends (1,
* etc) to show how many objects are associated.

Association is used to represent the relationship between two elements of a system.

Generalization Notation:
Generalization describes the inheritance relationship of the object oriented world. It is parent and
child relationship.
Generalization is represented by an arrow with hollow arrow head as shown below. One end
represents the parent element and the other end child element.

Generalization is used to describe parent-child relationship of two elements of a system.

Extensibility Notation:
All the languages (programming or modeling) have some mechanism to extend its capabilities like
syntax, semantics etc. UML is also having the following mechanisms to provide extensibility features.

Stereotypes (Represents new elements)

Tagged values (Represents new attributes)
Constraints (Represents the boundaries)

CSE Department,
VNRVJIET

112
www.jntuworld.com

www.jntuworld.com

Extensibility notations are used to enhance the power of the language. It is basically additional
elements used to represent some extra behaviour of the system. These extra behaviours are not
covered by the standard available notations.
In the previous chapters we have discussed about the building blocks and other necessary elements
of UML. Now we need to understand where to use those elements.
The elements are like components which can be associated in different ways to make a complete
UML pictures which is known as diagram. So it is very important to understand the different diagrams
to implement the knowledge in real life systems.
Any complex system is best understood by making some kind of diagrams or pictures. These
diagrams have a better impact on our understanding. So if we look around then we will realize that
the diagrams are not a new concept but it is used widely in different form in different industries.
We prepare UML diagrams to understand a system in better and simple way. A single diagram is not
enough to cover all aspects of the system. So UML defines various kinds of diagrams to cover most
of the aspects of a system.
You can also create your own set of diagrams to meet your requirements. Diagrams are generally
made in an incremental and iterative way.
There are two broad caetgories of diagrams and then are again divided into sub-categories:
Structural Diagrams
Behavioral Diagrams

Structural Diagrams:
The structural diagrams represent the static aspect of the system. These static aspects represent
those parts of a diagram which forms the main structure and therefore stable.
These static parts are represents by classes, interfaces, objects, components and nodes. The four
structural diagrams are:

Class diagram
Object diagram
CSE Department,
VNRVJIET

113
www.jntuworld.com

www.jntuworld.com
Component diagram
Deployment diagram

Class Diagram:
Class diagrams are the most common diagrams used in UML. Class diagram consists of classes,
interfaces, associations and collaboration.
Class diagrams basically represent the object oriented view of a system which is static in nature.
Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. So it is generally used for development
purpose. This is the most widely used diagram at the time of system construction.

Object Diagram:
Object diagrams can be described as an instance of class diagram. So these diagrams are more
close to real life scenarios where we implement a system.
Object diagrams are a set of objects and their relationships just like class diagrams and also
represent the static view of the system.
The usage of object diagrams is similar to class diagrams but they are used to build prototype of a
system from practical perspective.

Component Diagram:
Component diagrams represent a set of components and their relationships. These components
consist of classes, interfaces or collaborations.
So Component diagrams represent the implementation view of a system.
During design phase software artifacts (classes, interfaces etc) of a system are arranged in different
groups depending upon their relationship. Now these groups are known as components.
Finally, component diagrams are used to visualize the implementation.

Deployment Diagram:
Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities
where the components are deployed.
Deployment diagrams are used for visualizing deployment view of a system. This is generally used by
the deployment team.
Note: If the above descriptions and usages are observed carefully then it is very clear that all the
diagrams are having some relationship with one another. Component diagrams are dependent upon
the classes, interfaces etc which are part of class/object diagram. Again the deployment diagram is
dependent upon the components which are used to make a component diagrams.
CSE Department,
VNRVJIET

114
www.jntuworld.com

www.jntuworld.com

Behavioral Diagrams:
Any system can have two aspects, static and dynamic. So a model is considered as complete when
both the aspects are covered fully.
Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be
further described as the changing/moving parts of a system.
UML has the following five types of behavioral diagrams:

Use case diagram

Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram

Use case Diagram:

Use case diagrams are a set of use cases, actors and their relationships. They represent the use
case view of a system.
A use case represents a particular functionality of a system.
So use case diagram is used to describe the relationships among the functionalities and their
internal/external controllers. These controllers are known as actors.

Sequence Diagram:
A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals with
some sequences, which are the sequence of messages flowing from one object to another.
Interaction among the components of a system is very important from implementation and execution
perspective.
So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific
functionality.

Collaboration Diagram:
Collaboration diagram is another form of interaction diagram. It represents the structural organization
of a system and the messages sent/received. Structural organization consists of objects and links.
The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of
collaboration diagram is to visualize the organization of objects and their interaction.

Statechart Diagram:
Any real time system is expected to be reacted by some kind of internal/external events. These
events are responsible for state change of the system.
CSE Department,
VNRVJIET

115
www.jntuworld.com

www.jntuworld.com
Statechart diagram is used to represent the event driven state change of a system. It basically
describes the state change of a class, interface etc.
State chart diagram is used to visualize the reaction of a system by internal/external factors.

Activity Diagram:
Activity diagram describes the flow of control in a system. So it consists of activities and links. The
flow can be sequential, concurrent or branched.
Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared to
capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have an
idea of how the system will work when executed.
Note: Dynamic nature of a system is very difficult to capture. So UML has provided features to
capture the dynamics of a system from different angles. Sequence diagrams and collaboration
diagrams are isomorphic so they can be converted from one another without losing any information.
This is also true for statechart and activity diagram.

Overview:
The class diagram is a static diagram. It represents the static view of an application. Class diagram is
not only used for visualizing, describing and documenting different aspects of a system but also for
constructing executable code of the software application.
The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object oriented
languages.
The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram.

Purpose:
The purpose of the class diagram is to model the static view of an application. The class diagrams
are the only diagrams which can be directly mapped with object oriented languages and thus widely
used at the time of construction.
The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the
application but class diagram is a bit different. So it is the most popular UML diagram in the coder
community.
So the purpose of the class diagram can be summarized as:
Analysis and design of the static view of an application.
Describe responsibilities of a system.
Base for component and deployment diagrams.
Forward and reverse engineering.
CSE Department,
VNRVJIET

116
www.jntuworld.com

www.jntuworld.com

How to draw Class Diagram?

Class diagrams are the most popular UML diagrams used for construction of software applications.
So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and represents
different aspects of the application. So a collection of class diagrams represent the whole system.
The following points should be remembered while drawing a class diagram:
The name of the class diagram should be meaningful to describe the aspect of the system.
Each element and their relationships should be identified in advance.
Responsibility (attributes and methods) of each class should be clearly identified.
For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.
Use notes when ever required to describe some aspect of the diagram. Because at the end of
the drawing it should be understandable to the developer/coder.
Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct.
Now the following diagram is an example of an Order System of an application. So it describes a
particular aspect of the entire application.
First of all Order and Customer are identified as the two elements of the system and they have
a one to many relationship because a customer can have multiple orders.
We would keep Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
The two inherited classes have all the properties as the Order class. In addition they have
additional functions like dispatch () and receive ().
So the following class diagram has been drawn considering all the points mentioned above:

CSE Department,
VNRVJIET

117
www.jntuworld.com

www.jntuworld.com

Where to use Class Diagrams?

Class diagram is a static diagram and it is used to model static view of a system. The static view
describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams. Class
diagrams are not only used to visualize the static view of the system but they are also used to
construct the executable code for forward and reverse engineering of any system.
Generally UML diagrams are not directly mapped with any object oriented programming languages
but the class diagram is an exception.
Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So from
practical experience class diagram is generally used for construction purpose.
So in a brief, class diagrams are used for:
Describing the static view of the system.
Showing the collaboration among the elements of the static view.
Describing the functionalities performed by the system.
Construction of software applications using object oriented languages.

Overview:
Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams.

CSE Department,
VNRVJIET

118
www.jntuworld.com

www.jntuworld.com
Object diagrams represent an instance of a class diagram. The basic concepts are similar for class
diagrams and object diagrams. Object diagrams also represent the static view of a system but this
static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an instance.

Purpose:
The purpose of a diagram should be understood clearly to implement it practically. The purposes of
object diagrams are similar to class diagrams.
The difference is that a class diagram represents an abstract model consists of classes and their
relationships. But an object diagram represents an instance at a particular moment which is concrete
in nature.
It means the object diagram is more close to the actual system behaviour. The purpose is to capture
the static view of a system at a particular moment.
So the purpose of the object diagram can be summarized as:
Forward and reverse engineering.
Object relationships of a system
Static view of an interaction.
Understand object behaviour and their relationship from practical perspective

How to draw Object Diagram?

We have already discussed that an object diagram is an instance of a class diagram. It implies that
an object diagram consists of instances of things used in a class diagram.
So both diagrams are made of same basic elements but in different form. In class diagram elements
are in abstract form to represent the blue print and in object diagram the elements are in concrete
form to represent the real world object.
To capture a particular system, numbers of class diagrams are limited. But if we consider object
diagrams then we can have unlimited number of instances which are unique in nature. So only those
instances are considered which are having impact on the system.
From the above discussion it is clear that a single object diagram cannot capture all the necessary
instances or rather cannot specify all objects of a system. So the solution is:
First, analyze the system and decide which instances are having important data and
association.
Second, consider only those instances which will cover the functionality.
Third, make some optimization as the numbers of instances are unlimited.
Before drawing an object diagrams the following things should be remembered and understood
clearly:
Object diagrams are consist of objects.
The link in object diagram is used to connect objects.
CSE Department,
VNRVJIET

119
www.jntuworld.com

www.jntuworld.com
Objects and links are the two elements used to construct an object diagram.
Now after this the following things are to be decided before starting the construction of the diagram:
The object diagram should have a meaningful name to indicate its purpose.
The most important elements are to be identified.
The association among objects should be clarified.
Values of different elements need to be captured to include in the object diagram.
Add proper notes at points where more clarity is required.
The following diagram is an example of an object diagram. It represents the Order management
system which we have discussed in Class Diagram. The following diagram is an instance of the
system at a particular time of purchase. It has the following objects
Customer
Order
SpecialOrder
NormalOrder
Now the customer object (C) is associated with three order objects (O1, O2 and O3). These order
objects are associated with special order and normal order objects (S1, S2 and N1). The customer is
having the following three orders with different numbers (12, 32 and 40) for the particular time
considered.
Now the customer can increase number of orders in future and in that scenario the object diagram will
reflect that. If order, special order and normal order objects are observed then we you will find that
they are having some values.
For orders the values are 12, 32, and 40 which implies that the objects are having these values for
the particular moment (here the particular time when the purchase is made is considered as the
moment) when the instance is captured.
The same is for special order and normal order objects which are having number of orders as 20, 30
and 60. If a different time of purchase is considered then these values will change accordingly.
So the following object diagram has been drawn considering all the points mentioned above:

CSE Department,
VNRVJIET

120
www.jntuworld.com

www.jntuworld.com

Where to use Object Diagrams?

Object diagrams can be imagined as the snapshot of a running system at a particular moment. Now
to clarify it we can take an example of a running train.
Now if you take a snap of the running train then you will find a static picture of it having the following:
A particular state which is running
A particular number of passengers. which will change if the snap is taken in a different time.
So here we can imagine the snap of the running train is an object having the above values. And this
is true for any real life simple or complex system. In a brief, object diagrams are used for:
Making the prototype of a system.
Reverse engineering.
Modeling complex data structures.
Understanding the system from practical perspective.

Overview:
Component diagrams are different in terms of nature and behaviour. Component diagrams are used
to model physical aspects of a system.
Now the question is what are these physical aspects? Physical aspects are the elements like
executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships among components
in a system. These diagrams are also used to make executable systems.

Purpose:
Component diagram is a special kind of diagram in UML. The purpose is also different from all other
diagrams discussed so far. It does not describe the functionality of the system but it describes the
components used to make those functionalities.
So from that point component diagrams are used to visualize the physical components in a system.
These components are libraries, packages, files etc.
Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.
A single component diagram cannot represent the entire system but a collection of diagrams are used
to represent the whole.
So the purpose of the component diagram can be summarized as:
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.

CSE Department,
VNRVJIET

121
www.jntuworld.com

www.jntuworld.com

How to draw Component Diagram?

Component diagrams are used to describe the physical artifacts of a system. This artifact includes
files, executables, libraries etc.
So the purpose of this diagram is different, Component diagrams are used during the implementation
phase of an application. But it is prepared well in advance to visualize the implementation details.
Initially the system is designed using different UML diagrams and then when the artifacts are ready
component diagrams are used to get an idea of the implementation.
This diagram is very important because without it the application cannot be implemented efficiently. A
well prepared component diagram is also important for other aspects like application performance,
maintenance etc.
So before drawing a component diagram the following artifacts are to be identified clearly:
Files used in the system.
Libraries and other artifacts relevant to the application.
Relationships among the artifacts.
Now after identifying the artifacts the following points needs to be followed:
Use a meaningful name to identify the component for which the diagram is to be drawn.
Prepare a mental layout before producing using tools.
Use notes for clarifying important points.
The following is a component diagram for order management system. Here the artifacts are files. So
the diagram shows the files in the application and their relationships. In actual the component
diagram also contains dlls, libraries, folders etc.
In the following diagram four files are identified and their relationships are produced. Component
diagram cannot be matched directly with other UML diagrams discussed so far. Because it is drawn
for completely different purpose.
So the following component diagram has been drawn considering all the points mentioned above:

CSE Department,
VNRVJIET

122
www.jntuworld.com

www.jntuworld.com

Where to use Component Diagrams?

We have already described that component diagrams are used to visualize the static implementation
view of a system. Component diagrams are special type of UML diagrams used for different
purposes.
These diagrams show the physical components of a system. To clarify it, we can say that component
diagrams describe the organization of the components in a system.
Organization can be further described as the location of the components in a system. These
components are organized in a special way to meet the system requirements.
As we have already discussed those components are libraries, files, executables etc. Now before
implementing the application these components are to be organized. This component organization is
also designed separately as a part of project execution.
Component diagrams are very important from implementation perspective. So the implementation
team of an application should have a proper knowledge of the component details.
Now the usage of component diagrams can be described as:
Model the components of a system.
Model database schema.
Model executables of an application.
Model system's source code.

Overview:

CSE Department,
VNRVJIET

123
www.jntuworld.com

www.jntuworld.com
Deployment diagrams are used to visualize the topology of the physical components of a system
where the software components are deployed.
So deployment diagrams are used to describe the static deployment view of a system. Deployment
diagrams consist of nodes and their relationships.

Purpose:
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used
for describing the hardware components where software components are deployed. Component
diagrams and deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how
they are deployed in hardware.
UML is mainly designed to focus on software artifacts of a system. But these two diagrams are
special diagrams used to focus on software components and hardware components.
So most of the UML diagrams are used to handle logical components but deployment diagrams are
made to focus on hardware topology of a system. Deployment diagrams are used by the system
engineers.
The purpose of deployment diagrams can be described as:
Visualize hardware topology of a system.
Describe the hardware components used to deploy software components.
Describe runtime processing nodes.

How to draw Component Diagram?

Deployment diagram represents the deployment view of a system. It is related to the component
diagram. Because the components are deployed using the deployment diagrams. A deployment
diagram consists of nodes. Nodes are nothing but physical hardwares used to deploy the application.
Deployment diagrams are useful for system engineers. An efficient deployment diagram is very
important because it controls the following parameters
Performance
Scalability
Maintainability
Portability
So before drawing a deployment diagram the following artifacts should be identified:
Nodes
Relationships among nodes
The following deployment diagram is a sample to give an idea of the deployment view of order
management system. Here we have shown nodes as:
Monitor
CSE Department,
VNRVJIET

124
www.jntuworld.com

www.jntuworld.com
Modem
Caching server
Server
The application is assumed to be a web based application which is deployed in a clustered
environment using server 1, server 2 and server 3. The user is connecting to the application using
internet. The control is flowing from the caching server to the clustered environment.
So the following deployment diagram has been drawn considering all the points mentioned above:

Where to use Deployment Diagrams?

Deployment diagrams are mainly used by system engineers. These diagrams are used to describe
the physical components (hardwares), their distribution and association.
To clarify it in details we can visualize deployment diagrams as the hardware components/nodes on
which software components reside.
Software applications are developed to model complex business processes. Only efficient software
applications are not sufficient to meet business requirements. Business requirements can be
described as to support increasing number of users, quick response time etc.
To meet these types of requirements hardware components should be designed efficiently and in a
cost effective way.

CSE Department,
VNRVJIET

125
www.jntuworld.com

www.jntuworld.com
Now a day's software applications are very complex in nature. Software applications can be stand
alone, web based, distributed, mainframe based and many more. So it is very important to design the
hardware components efficiently.
So the usage of deployment diagrams can be described as follows:
To model the hardware topology of a system.
To model embedded system.
To model hardware details for a client/server system.
To model hardware details of a distributed application.
Forward and reverse engineering.

Overview:
To model a system the most important aspect is to capture the dynamic behaviour. To clarify a bit in
details, dynamic behaviour means the behaviour of the system when it is running /operating.
So only static behaviour is not sufficient to model a system rather dynamic behaviour is more
important than static behaviour. In UML there are five diagrams available to model dynamic nature
and use case diagram is one of them. Now as we have to discuss that the use case diagram is
dynamic in nature there should be some internal or external factors for making the interaction.
These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of an
application. A single use case diagram captures a particular functionality of a system.
So to model the entire system numbers of use case diagrams are used.

Purpose:
The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is
too generic to describe the purpose.
Because other four diagrams (activity, sequence, collaboration and Statechart) are also having the
same purpose. So we will look into some specific purpose which will distinguish it from other four
diagrams.
Use case diagrams are used to gather the requirements of a system including internal and external
influences. These requirements are mostly design requirements. So when a system is analyzed to
gather its functionalities use cases are prepared and actors are identified.
Now when the initial task is complete use case diagrams are modelled to present the outside view.
So in brief, the purposes of use case diagrams can be as follows:
Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the system.
Show the interacting among the requirements are actors.

CSE Department,
VNRVJIET

126
www.jntuworld.com

www.jntuworld.com

How to draw Component Diagram?

Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.
So we can say that uses cases are nothing but the system functionalities written in an organized
manner. Now the second things which are relevant to the use cases are the actors. Actors can be
defined as something that interacts with the system.
The actors can be human user, some internal applications or may be some external applications. So
in a brief when we are planning to draw an use case diagram we should have the following items
identified.
Functionalities to be represented as an use case
Actors
Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system. So after identifying
the above items we have to follow the following guidelines to draw an efficient use case diagram.
The name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.
Give a suitable name for actors.
Show relationships and dependencies clearly in the diagram.
Do not try to include all types of relationships. Because the main purpose of the diagram is to
identify requirements.
Use note when ever required to clarify some important points.
The following is a sample use case diagram representing the order management system. So if we
look into the diagram then we will find three use cases (Order, SpecialOrder and NormalOrder) and
one actor which is customer.
The SpecialOrder and NormalOrder use cases are extended from Order use case. So they have
extends relationship. Another important point is to identify the system boundary which is shown in the
picture. The actor Customer lies outside the system as it is an external user of the system.

CSE Department,
VNRVJIET

127
www.jntuworld.com

www.jntuworld.com

Where to use Deployment Diagrams?

As we have already discussed there are five diagrams in UML to model dynamic view of a system.
Now each and every model has some specific purpose to use. Actually these specific purposes are
different angles of a running system.
So to understand the dynamics of a system we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system requirements and actors.
Use case diagrams specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black box where only
the input, output and the function of the black box is known.
These diagrams are used at a very high level of design. Then this high level design is refined again
and again to get a complete and practical picture of the system. A well structured use case also
describes the pre condition, post condition, exceptions. And these extra elements are used to make
test cases when performing the testing.
Although the use cases are not a good candidate for forward and reverse engineering but still they
are used in a slight different way to make forward and reverse engineering. And the same is true for
reverse engineering. Still use case diagram is used differently to make it a candidate for reverse
engineering.
In forward engineering use case diagrams are used to make test cases and in reverse engineering
use cases are used to prepare the requirement details from the existing application.
So the following are the places where use case diagrams are used:
Requirement analysis and high level design.
Model the context of a system.
Reverse engineering.
Forward engineering.
CSE Department,
VNRVJIET

128
www.jntuworld.com

www.jntuworld.com

Overview:
From the name Interaction it is clear that the diagram is used to describe some type of interactions
among the different elements in the model. So this interaction is a part of dynamic behaviour of the
system.
This interactive behaviour is represented in UML by two diagrams known as Sequence diagram and
Collaboration diagram. The basic purposes of both the diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration diagram
emphasizes on the structural organization of the objects that send and receive messages.

Purpose:
The purposes of interaction diagrams are to visualize the interactive behaviour of the system. Now
visualizing interaction is a difficult task. So the solution is to use different types of models to capture
the different aspects of the interaction.
That is why sequence and collaboration diagrams are used to capture dynamic nature but from a
different angle.
So the purposes of interaction diagram can be describes as:
To capture dynamic behaviour of a system.
To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.

How to draw Component Diagram?

As we have already discussed that the purpose of interaction diagrams are to capture the dynamic
aspect of a system. So to capture the dynamic aspect we need to understand what a dynamic aspect
is and how it is visualized. Dynamic aspect can be defined as the snap shot of the running system at
a particular moment.
We have two types of interaction diagrams in UML. One is sequence diagram and the other is a
collaboration diagram. The sequence diagram captures the time sequence of message flow from one
object to another and the collaboration diagram describes the organization of objects in a system
taking part in the message flow.
So the following things are to identified clearly before drawing the interaction diagram:
Objects taking part in the interaction.
Message flows among the objects.
The sequence in which the messages are flowing.
Object organization.
Following are two interaction diagrams modeling order management system. The first diagram is a
sequence diagram and the second is a collaboration diagram.

CSE Department,
VNRVJIET

129
www.jntuworld.com

www.jntuworld.com

The Sequence Diagram:

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).
The following diagram has shown the message sequence for SpecialOrder object and the same can
be used in case of NormalOrder object. Now it is important to understand the time sequence of
message flows. The message flow is nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call is confirm () which is a
method of SpecialOrder object and the last call is Dispatch () which is a method of SpecialOrder
object. So here the diagram is mainly describing the method calls from one object to another and this
is also the actual scenario when the system is running.

The Collaboration Diagram:

The second interaction diagram is collaboration diagram. It shows the object organization as shown
below. Here in collaboration diagram the method call sequence is indicated by some numbering
technique as shown below. The number indicates how the methods are called one after another. We
have taken the same order management system to describe the collaboration diagram.
The method calls are similar to that of a sequence diagram. But the difference is that the sequence
diagram does not describe the object organization where as the collaboration diagram shows the
object organization.
Now to choose between these two diagrams the main emphasis is given on the type of requirement.
If the time sequence is important then sequence diagram is used and if organization is required then
collaboration diagram is used.

CSE Department,
VNRVJIET

130
www.jntuworld.com

www.jntuworld.com

Where to use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe dynamic nature of a
system. Now we will look into the practical scenarios where these diagrams are used. To understand
the practical application we need to understand the basic nature of sequence and collaboration
diagram.
The main purposes of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. But the specific purposes are more important to clarify and understood.
Sequence diagrams are used to capture the order of messages flowing from one object to another.
And the collaboration diagrams are used to describe the structural organizations of the objects taking
part in the interaction. A single diagram is not sufficient to describe the dynamic aspect of an entire
system so a set of diagrams are used to capture is as a whole.
The interaction diagrams are used when we want to understand the message flow and the structural
organization. Now message flow means the sequence of control flow from one object to another and
structural organization means the visual organization of the elements in a system.
In a brief the following are the usages of interaction diagrams:
To model flow of control by time sequence.
To model flow of control by structural organizations.
For forward engineering.
For reverse engineering.

Overview:
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a
system.

CSE Department,
VNRVJIET

131
www.jntuworld.com

www.jntuworld.com
A Statechart diagram describes a state machine. Now to clarify it state machine can be defined as a
machine which defines different states of an object and these states are controlled by external or
internal events.
Activity diagram explained in next chapter, is a special kind of a Statechart diagram. As Statechart
diagram defines states it is used to model lifetime of an object.

Purpose:
Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system. They
define different states of an object during its lifetime. And these states are changed by events. So
Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as a
system that responds to external or internal events.
Statechart diagram describes the flow of control from one state to another state. States are defined
as a condition in which an object exists and it changes when some event is triggered. So the most
important purpose of Statechart diagram is to model life time of an object from creation to termination.
Statechart diagrams are also used for forward and reverse engineering of a system. But the main
purpose is to model reactive system.
Following are the main purposes of using Statechart diagrams:
To model dynamic aspect of a system.
To model life time of a reactive system.
To describe different states of an object during its life time.
Define a state machine to model states of an object.

How to draw Component Diagram?

Statechart diagram is used to describe the states of different objects in its life cycle. So the emphasis
is given on the state changes upon some internal or external events. These states of objects are
important to analyze and implement them accurately.
Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.
Before drawing a Statechart diagram we must have clarified the following points:
Identify important objects to be analyzed.
Identify the states.
Identify the events.
The following is an example of a Statechart diagram where the state of Order object is analyzed.
The first state is an idle state from where the process starts. The next states are arrived for events
like send request, confirm request, and dispatch order. These events are responsible for state
changes of order object.
During the life cycle of an object (here order object) it goes through the following states and there
may be some abnormal exists also. This abnormal exit may occur due to some problem in the
CSE Department,
VNRVJIET

132
www.jntuworld.com

www.jntuworld.com
system. When the entire life cycle is complete it is considered as the complete transaction as
mentioned below.
The initial and final state of an object is also shown below.

Where to use Interaction Diagrams?

From the above discussion we can define the practical applications of a Statechart diagram.
Statechart diagrams are used to model dynamic aspect of a system like other four diagrams disused
in this tutorial. But it has some distinguishing characteristics for modeling dynamic nature.
Statechart diagram defines the states of a component and these state changes are dynamic in
nature. So its specific purpose is to define state changes triggered by events. Events are internal or
external factors influencing the system.
Statechart diagrams are used to model states and also events operating on the system. When
implementing a system it is very important to clarify different states of an object during its life time and
statechart diagrams are used for this purpose. When these states and events are identified they are
used to model it and these models are used during implementation of the system.
If we look into the practical implementation of Statechart diagram then it is mainly used to analyze the
object states influenced by events. This analysis is helpful to understand the system behaviour during
its execution.
So the main usages can be described as:
To model object states of a system.
To model reactive system. Reactive system consists of reactive objects.
To identify events responsible for state changes.
Forward and reverse engineering.
CSE Department,
VNRVJIET

133
www.jntuworld.com

www.jntuworld.com

Overview:
Activity diagram is another important diagram in UML to describe dynamic aspects of the system.
Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The
activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be sequential, branched or
concurrent. Activity diagrams deals with all type of flow control by using different elements like fork,
join etc.

Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic
behaviour of the system. Other four diagrams are used to show the message flow from one object to
another but activity diagram is used to show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used for visualizing
dynamic nature of a system but they are also used to construct the executable system by using
forward and reverse engineering techniques. The only missing thing in activity diagram is the
message part.
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.
So the purposes can be described as:
Draw the activity flow of a system.
Describe the sequence from one activity to another.
Describe the parallel, branched and concurrent flow of the system.

How to draw Component Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system. But
activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.
Before drawing an activity diagram we must have a clear understanding about the elements used in
activity diagram. The main element of an activity diagram is the activity itself. An activity is a function
performed by the system. After identifying the activities we need to understand how they are
associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
Activities
Association
Conditions
Constraints

CSE Department,
VNRVJIET

134
www.jntuworld.com

www.jntuworld.com
Once the above mentioned parameters are identified we need to make a mental layout of the entire
flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram four
activities are identified which are associated with conditions. One important point should be clearly
understood that an activity diagram cannot be exactly matched with the code. The activity diagram is
made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:
Send order by the customer
Receipt of the order
Confirm order
Dispatch order
After receiving the order request condition checks are performed to check if it is normal or special
order. After the type of order is identified dispatch activity is performed and that is marked as the
termination of the process.

Where to use Interaction Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is to
model the control flow from one activity to another. This control flow does not include messages.
The activity diagram is suitable for modeling the activity flow of the system. An application can have
multiple systems. Activity diagram also captures these systems and describes flow from one system
to another. This specific usage is not available in other diagrams. These systems can be database,
external queues or any other system.

CSE Department,
VNRVJIET

135
www.jntuworld.com

www.jntuworld.com
Now we will look into the practical applications of the activity diagram. From the above discussion it is
clear that an activity diagram is drawn from a very high level. So it gives high level view of a system.
This high level view is mainly for business users or any other person who is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.
Following are the main usages of activity diagram:
Modeling work flow by using activities.
Modeling business requirements.
High level understanding of the system's functionalities.
Investigate business requirements at a later stage.

CSE Department,
VNRVJIET

136
www.jntuworld.com