++

RAGHU ENGINEERING COLLEGE(Autonomous)

Dakamarri, Visakhapatnam – 531162
Approved by AICTE
Accredited by NBA
Accredited by NAAC with 'A' Grade
Affiliated to JNTU-Kakinada

COMPUTER SCIENCE & ENGINEERING

IV B.Tech - I Semester
UNIFIED MODELLING LANGUAGE(UNIT-3)
V.TATARAO
Asst.Professor
CSE DEPT
UNIFIED MODELLING LANGUAGE UNIT-3
UNIT-III
Syllabus: UNIT-III
Introduction to UML: Why we model, Conceptual model of UML, Architecture,
Classes, Relationships, Common mechanisms, Class diagrams, object diagrams.
Why we model
The importance of Modeling:
A model is a simplification of reality. A model provides the blueprints of a system. Every system
may be described from different aspects using different models, and each model is therefore a se-
mantically closed abstraction of the system.
A model may be structural, emphasizing the organization of the system, or it may be behavioral,
emphasizing the dynamics of the system. We build models so that we can better understand the sys-
tem we are developing.
Through modeling, we achieve four aims.
1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.
Modeling is not for big systems. Even the software equivalent of a dog house can benefit from
some modeling. For example if you want to build a dog house, you can start with a pile of lumber,
some nails, and a basic tool, such as a hammer, saw, and a tape measure. In few hours, with little
prior planning, you will likely end up a with a dog house that's reasonably functional. Finally your
will happy and get a less demanding dog. If you want to build a house for your family, you can start
with a pile of lumber, some nails, and basic tools. But it's going to take you a lot longer, and your
family will certainly be more demanding than the dog. If you want to build a quality house that
meets the needs of your family and you will need to draw some blue prints.
Principles of Modeling:
UML is basically a modeling language; hence its principles will also be related to modeling con-
cepts. Here are few basic principal of UML.
First: "The choice of what models to create has a profound influence on how a problem is attacked
and how a solution is shaped"
In other words, choose your models well. The right models will brilliantly illuminate the most
wicked development problems. The wrong models will mislead you, causing you to focus on irrele-
vant issues.
Second: “Every model may be expressed at different levels of precision ". Best approach to a given
problem results in a best model.
If the problem is complex mechanized level of approach & if the problem is simple decent approach
is followed.
Third: "The best models are connected to reality." The model built should have strong resemblance
with the system.
Fourth: “No single model is sufficient. Every nontrivial system is best approached through a small
set of nearly independent models."
If you constructing a building, there is no single set of blueprints that reveal all its details. At the
very least, you will need floor plans, elevations, electrical plans, heating plans, and plumbing plans.
Object-Oriented Modeling:
In software, there are several ways to approaches a model. The two most common ways are
1. Algorithmic perspective
2. Object-Oriented perspective
1. Algorithmic perspective:
In this approach, the main building blocks of all software are the procedure or function. This view
leads developers to focus on issues of control and decomposition of larger algorithms into smaller
ones.
2. Object-Oriented perspective:

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

In this approach, the main building blocks of all software are the object or class. Simply
Put, an object is a thing. A class is a description of a set of common objects. Every object has iden-
tity, state and behavior.
For example, consider a simple a three-tier -architecture for a billing system, involving a user inter-
face, middleware, and a data base. In the user interface, you will find concrete objects, such as but-
tons, menus, and dialog boxes. In the database, you will find concrete
Objects, such as tables. In the middle layer, you will find objects such as transitions and business
rules.
The Unified Modeling Language (UML) is a standard language for writing software
blueprints. The UML is a language for
- Visualizing
- Specifying
- Constructing
- Documenting
The artifacts of a software-intensive system.
The UML is appropriate for modeling systems ranging from enterprise information systems
to distributed Web-based applications and even to hard real time embedded systems.

IMPORTANCE OF MODELING
1) If we want to build a dog house, with a little planning, we’ll likely end up with a dog
house that’s reasonably functional and we can do it with no one’s help.
2) If we want to build a house for a family, it’s going to take a lot longer. In this case we
need some detailed planning; we’ll need to draw some blueprints, before we lay the foundation.
3) If we want to build a high-rise office building, we’ll have to do extensive planning; and
we need all sorts of blueprints and models to communicate with one another.

WHAT IS A MODEL
 A Model is a simplification of reality.
 We build models so that we can better understand the system we are developing.
 We build models of complex systems because we cannot comprehend such a system in its
entirety.
Through Modeling, we achieve four aims
1. Models help us to visualize a system as it is or as we want it to be.
2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made.
PRINCIPLES OF MODELING
Four basic principles of modeling are
UNIFIED MODELLING LANGUAGE UNIT-3
1) The choice of what models to create has a profound influence on how a
2) Problem is attacked and how a solution is shaped.
3) Every model may be expressed at different levels of precision.
4) The best models are connected to reality.
5) No single model is sufficient.
CONCEPTUAL MODEL OF UML
To understand UML, you need to form a conceptual model of the language. This requires
learning three major elements:
I. Basic Building Blocks
II. Rules
III. Common Mechanisms

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

I) BASIC BUILDING BLOCKS
There are 3 kinds of basic building blocks
1. Things
2. Relationships
3. Diagrams
UNIFIED MODELLING LANGUAGE UNIT-3
1) THINGS in the UML
There are 4 kinds of things in the UML
i. Structural Things
ii. Behavioral Things
iii. Annotational Things
iv. Grouping Things
i) Structural Things
Structural Things are nouns of UML models. There are 7 kinds of Structural things
a) Class
A class is a set of objects that share the same attributes, operations, relationships and
semantics.
Class Name
At tribut es

Operations()

b) Interface
An Interface is a collection of operations that specify a service of a class or component

olution a million
c) Collaboration times over,
ISpelling
Collaboration describes co-operative work of an element.

d) Use Case
Use Case describes set of sequence of actions that a system performs that yields an
observable result of value to a particular actor.

UseCase
Actor

e) Active Class
Active class is just like a class but its elements are connected to other class elements.

f) Component
Component represents physical packaging of logical elements like classes, interfaces and
collaborations.
Component

g) Node
RAGHU ENGINEERING COLLEGE DEPT. OF CSE
 A Node is physical element that exists at run-time and having at least some memory and
processing capability.
Node

ii) Behavioral Things

Behavioral Things are the verbs of UML representing behavior over time and space. There
are 2 kinds of Behavioral things
Interaction: Interaction is used to show communication between two objects.

a) State Machine
State Machine specifies sequence of states of an object.

iii) Annotational Things

Annotational Things are explanatory parts of UML. Only 1 type.
Note
Note is used to give comments to an element or collection of elements.
Note

iv) Grouping Things

Grouping Things are the organizational parts of the model. Only one type.
Package
Package is a general purpose mechanism for organizing elements or things into
groups or packages.

Package

2) RELATIONSHIPS
There are 4 kinds of Relationships in the UML:

a) Dependency: It is denoted by dashed line with an arrow.

UNIFIED MODELLING LANGUAGE UNIT-3
Dependency is a relationship between two things in which a change to one thing
(Independent thing) may affect the other thing (Dependent thing).

MovieClip
name
Channel
Dependency
screen()
start()
stop()

b) Association: It is denoted by a solid line.

____________________
Association is a structural relationship that describes a set of links, a link being a connection
among objects. Aggregation is a special kind of association, representing a structural relationship
between a whole and its parts.

c) Generalization: It is denoted by a solid line with a hollow arrow head pointing to the parent

Generalization is a relationship in which the child will share the behavior of the parent.

Shape
origin : Integer

display()

Rectangle Circle
length : Integer radius : Integer
breadth : Integer

d) Realization: It is denoted by dashed lines with a hollow arrow head.

Realization is a relationship between classifiers, where one classifier specifies a contract that
another classifier guarantees to carry out

3) DIAGRAMS
There are 9 types of Diagrams in UML, which are classified into 2 types

i) Structural Diagrams (static diagrams)

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

 These are of 4 types
a) Class Diagram
A Class diagram shows a set of classes, interfaces, and collaborations and their
relationships. A class consists of class name, attributes, operations and responsibilities.

College
Department
name : String
location : String D_name : String
D_code : Integer
collect fees()
recruit faculty()

Staff
S_name : String

b) Object Diagram
An Object diagram shows a set of objects and their relationships. They represent snapshots
of instances of the things found in class diagrams.
Object diagrams commonly contain
• Objects
• Links
Like all other diagrams, object diagrams may contain notes and constraints.
Object diagrams may also contain packages or subsystems
Common Uses
You use object diagrams to model the static design view or static process view of a system just as
you do with class diagrams, but from the perspective of real or prototypical instances. This view
UNIFIED MODELLING LANGUAGE UNIT-3
primarily supports the functional requirements of a system that is, the services the system should
provide to its end users. Object diagrams let you model static data structures.
When you model the static design view or static process view of a system, you typically use object
diagrams in one way:
• To model object structures
Modeling object structures involves taking a snapshot of the objects in a system at a given mo-
ment in time. An object diagram represents one static frame in the dynamic storyboard repre-
sented by an interaction diagram. You use object diagrams to visualize, specify, construct, and
document the existence of certain instances in your system, together with their relationships to
one another.
Common Modeling Techniques of object diagrams:
Modeling Object Structures
To model an object structure,
• Identify the mechanism you'd like to model. A mechanism represents some function or behavior
of the part of the system you are modeling that results from the interaction of a society of classes,
interfaces, and other things.
• For each mechanism, identify the classes, interfaces, and other elements that participate in this
collaboration; identify the relationships among these things, as well.
• Consider one scenario that walks through this mechanism. Freeze that scenario at a moment in
time, and render each object that participates in the mechanism.
• Expose the state and attribute values of each such object, as necessary, to understand the sce-
nario.
• Similarly, expose the links among these objects, representing instances of associations among
them.
For example, Figure shows a set of objects drawn from the implementation of an autonomous ro-
bot. This figure focuses on some of the objects involved in the mechanism used by the robot to
calculate a model of the world in which it moves. There are many more objects involved in a run-
ning system, but this diagram focuses on only those abstractions that are directly involved in cre-
ating this world view.
As this figure indicates, one object represents the robot itself (r, an instance of Robot), and r is cur-
rently in the state marked moving. This object has a link to w, an instance of World, which repre-
sents an abstraction of the robot's world model. This object has a link to a multi object that con-
sists of instances of Element, which represent entities that the robot has identified but not yet as-
signed in its world view. These elements are marked as part of the robot's global state.
At this moment in time, w is linked to two instances of Area. One of them (a2) is shown with its
own links to three Walls and one Door object. Each of these walls is marked with its current width,
and each is shown linked to its neighboring walls. As this object diagram suggests, the robot has
recognized this enclosed area, which has walls on three sides and a door on the fourth.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

c) Component Diagram
A Component diagram shows the organizations and dependencies among a set of
components.

d) Deployment Diagram
A Deployment diagram shows the configuration of run-time processing nodes and the
components that are present in them.

Component and Deployment diagrams are called as Physical Diagrams.

ii) Behavioral Diagrams (Dynamic diagrams)
These are of 5 types
a) Use Case Diagram
A Use Case diagram shows a set of use cases and actors and their relationships. An Actor
can be a human or a system. The role of actor is written below.
UNIFIED MODELLING LANGUAGE UNIT-3

b) Interaction Diagrams
An Interaction diagram shows an interaction, consisting of a set of objects and their
relationships, including the messages they exchange among them.
2 types of Interaction diagrams are: Sequence Diagram and Collaboration Diagram

b) Sequence Diagram
A Sequence diagram is an interaction diagram that emphasizes the time-ordering of
messages. To show interaction between objects we use 3 types of messages.
Simple Messages:

A Simple message shows how control is passed from one object to other without describing
communication in detail i.e. without indicating whether it is synchronous or asynchronous message.
Synchronous Messages:

If sender object waits for a reply from receiver object from destination, such messages are
called Synchronous messages. Here, only one object can send a message at a given instance of time.
Asynchronous Messages:

If sender object continues executing while target is processing the message then such
messages are said to be Asynchronous messages. Here, multiple messages are executed at a time.
Object Lifeline: An Object life line is vertical dashed lines that represent the existence of
an object over a period of time.
Focus of Control: It is represented by rectangle that shows the period of time during which
an object performs some actions.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

c) Collaboration Diagram
A Collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages.
3: fill form 5: check form

1: Request form
4: submit
S: Student A: Admin

2: give form
6: eligible
d) State chart Diagram
A State chart diagram shows a state machine, consisting of states, transitions, events, and
activities.
Event: It refers to happening of an activity at a given time and place.
UNIFIED MODELLING LANGUAGE UNIT-3
e) Activity Diagram
An activity diagram is a special kind of state chart diagram that shows the flow from activity
to activity within a system, which are connected by a triggerless transition. We can check some
conditions using decision box, which is denoted by a diamond.

Activity: It is a major task that must take place in order to fulfill an operation contract.
Initial Activity: This shows the starting point of the flow. It is denoted by solid circle
Final Activity: This shows the end of the flow in the activity diagram. It is denoted by a solid circle
nested in a circle.
Decision Box: A point in an Activity diagram where a flow splits into several mutually exclusive
guarded flows. It has one incoming transition and two outgoing transitions.
Forking and Joining:-We use synchronization bar to specify the forking and joining of parallel
flows of control.
A synchronization bar is a thick horizontal or vertical line.
A Fork may have one incoming transition and two or more outgoing transitions, each of which
represents an independent flow of control.
A Join may have two or more incoming transitions and one outgoing transition.

Student

synchronization
Forking bar

Listen W atch

Joining

Success

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

 Swimlanes:
They are used to group related activities into one column.
II) RULES
There are 2 kinds of rules
1) Well formed rules
2) Less-well formed rules
1) Well formed rules:
These are of 5 types:
a) Names: What you call things, relationships, and diagrams
b) Scope: The content that gives specific meaning to a name.
c) Visibility: How these names can be seen and used by others.
d) Integrity: How things properly and consistently relate to one another.
e) Execution: To run a model.
2) Less-well formed rules:
These are of 3 types
a) Elided: Certain elements are hidden to simplify the view.
b) Incomplete: Certain elements may be missing.
c) Inconsistent: The integrity of the model is not guaranteed.
III) Common Mechanism:
To make our model simpler we have to follow the following 4 common mechanisms:
a) Specification: Provides all the parts of the model that the system should contain.
b) Adornments: Provides visual representation of most important aspects of the elements
c) Common Divisions: Provides division between classes & objects and interface &
implementation.
d) Extensibility Mechanisms: It is possible to extend the UML in a controlled ways.
There are 3 mechanisms:
i) Stereotypes: Allows creating new kind of building blocks that are derived from the
existing one.
ii) Tagged Values: Used to extend the properties of UML building blocks.
iii) Constraints: Allows adding new rules or modifying existing one.
Architecture:-
Software architecture is not only concerned with structure and behavior, but also with usage, func-
tionality, performance, resilience, reuse, comprehensibility, economic and technology constraints.
Below Figure shows, the architecture of a software-intensive system can best be described by five
interlocking views. Each view is a projection into the organization and structure of the system, fo-
cused on a particular aspect of that system.
UNIFIED MODELLING LANGUAGE UNIT-3
1. Design view:
The design view of a system encompasses the classes, interfaces, and collaborations that form the
vocabulary of the problem and its solution. This view primarily supports the functional require-
ments of the system, meaning the services that the system should provide to its end users. With the
UML, the static aspects of this view are captured in class diagrams and object diagrams; the dy-
namic aspects of this view are captured in interaction diagrams, state chart diagrams, and activity
diagram.
2. Process view:
The process view of a system encompasses the threads and processes that form the system's concur-
rency and synchronization mechanisms. This view primarily addresses the performance, scalability
and throughput of the system. With the UML, the static aspects of this view are captured in class di-
agrams and object diagrams; the dynamic aspects of this view are captured in interaction diagrams,
state chart diagrams, and activity diagram.
3. Use case view:
The use case view of a system encompasses the use cases that describe the behavior of the system as
seen by its end users, analysts, and testers. With the UML, the static aspects of this view are cap-
tured in use case diagrams; the dynamic aspects of this view are captured in interaction diagrams,
state chart diagrams, and activity diagrams.
4. Implementation View:
The Implementation View of a system encompasses the components and files that are used to as-
semble and release the physical system. This view primarily addresses the configuration manage-
ment of the system. With the UML, the static aspects of this view are captured in component dia-
grams; the dynamic aspects of this view are captured in interaction diagrams, state chart diagrams,
and activity diagrams.
5. Deployment view:
The deployment view of a system encompasses the nodes that form the system's hardware topology
on which the system executes. This view primarily addresses the distribution, delivery, and installa-
tion of the parts that make up the physical system. With the UML, the static aspects of this view are
captured in deployment diagrams; the dynamic aspects of this view are captured in interaction dia-
grams, state chart diagrams, and activity diagrams.
Forward and Reverse Engineering
Forward engineering is the process of transforming a model into code through a mapping to an im-
plementation language. Forward engineering results in a loss of information, because models writ-
ten in the UML are semantically richer than any current object-oriented programming language.
To forward engineer a class diagram,
 Identify the rules for mapping to your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
 Depending on the semantics of the languages you choose, you may have to constrain your use of
certain UML features. For example, the UML permits you to model multiple inheritance, but
Smalltalk permits only single inheritance. You can either choose to prohibit developers from mod-
eling with multiple inheritances (which makes your models language dependent) or develop idioms
that transform these richer features into the implementation language (which makes the mapping
more complex).
 Use tagged values to specify your target language. You can do this at the level of individual
classes if you need precise control. You can also do so at a higher level, such as with collaborations
or packages.
 Use tools to forward engineer your models.

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

Figure illustrates a simple class diagram specifying an instantiation of the chain of responsibility
pattern. This particular instantiation involves three classes: Client, Event Handler, and GUIEve
tHandler. Client and EventHandler are shown as abstract classes, whereas GUIEventHandler is con-
crete. EventHandler has the usual operation expected of this pattern (handleRequest), although
two private attributes have been added for this instantiation.
All of these classes specify a mapping to Java, as noted in their tagged value. Forward engineering
the classes in this diagram to Java is straightforward, using a tool. Forward engineering the class
EventHandler yields the following code.
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest() {}
}
Reverse engineering is the process of transforming code into a model through a mapping from a
specific implementation language
To reverse engineer a class diagram,
• Identify the rules for mapping from your implementation language or languages of choice. This is
something you'll want to do for your project or your organization as a whole.
• Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new
model or modify an existing one that was previously forward engineered.
• Using your tool, create a class diagram by querying the model. For example, you might start with
one or more classes, then expand the diagram by following specific relationships or other neigh-
boring classes. Expose or hide details of the contents of this class diagram as necessary to commu-
nicate your intent.

Example − The following figure shows an object diagram of a portion of the class diagram of the
Banking System.
UNIFIED MODELLING LANGUAGE UNIT-3
Example − The following figure shows an Class diagram for College
College
Department
name : String
location : String D_name : String
D_code : Integer
collect fees()
recruit faculty()

Staff
S_name : String

Example − The following figure shows an Class diagram for shape

Shape
origin : Integer

display()

Rectangle Circle
length : Integer radius : Integer
breadth : Integer

Example − Class diagram for ATM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

CLASS DIAGRAM FOR ONLINE FOOD ORDERING SYSTEM
UNIFIED MODELLING LANGUAGE UNIT-3

CLASS DIAGRAM FOR HOSPITAL SYSTEM

RAGHU ENGINEERING COLLEGE DEPT. OF CSE

CLASS DIAGRAM FOR ONLINE SHOPPING
UNIFIED MODELLING LANGUAGE UNIT-3

UNIT-III
UNIFIED MODELLING LANGUAGE QUESTION BANK
1. Describe about five interlocking views involved in the architecture of a software-intensive sys-
tem modeling
2. Explain about common mechanisms in the UML.
3. Explain the Conceptual model of UML in detail.
4. Briefly explain various building blocks of UML.
5. List out the common properties of object and class diagram and demonstrate the classes and ob-
jects in bank management system with neat sketch.
6. Briefly explain various things in UML?
7. Explain the structural Diagrams with example?
8. Explain the Behavioral Diagrams with example?
9. Briefly explain various Relations in UML?
10. What is a model, what is the important of modeling and explain the Principles of Modeling?
11. Explain in detail about Class Diagram and draw Class diagram for ATM?
12. Discuss in detail about Class Diagram and draw Class diagram for Library Management
System?
13. a. Discuss in detail about Forward and Reverse engineering
b. Discuss in detail about rules in UML?
14. Draw Class and Object diagram for online shopping?
15. Draw Class and Object diagram for Railway Reservation system?

RAGHU ENGINEERING COLLEGE DEPT. OF CSE