INTRODUCTION

TO OBJECT
MODELING stide
facilitator: Engr sunjo Ari
.com
Email: aris.sunjo@gmail
 COURSE OUTLINE
1. Basic techniques of modeling computer system
2. Overview of prominent object-oriented Methodologies
3. Introduction to UML (Unified Modeling Language)
4. Overview of the development process
5. Study of the various UML diagrams (structural and behavioral diagrams)
6. Class diagram (attributes, association, aggregation, composition, generalization, parameterized classes)
7. Use Case diagram
8. Interaction diagram (sequence diagram, collaboration diagram)
9. State diagram and activity diagram
10. Introduction to Object-oriented design (inheritance, encapsulation, polymorphism, abstract interfaces,
parameterized types)
11. Design patterns in OOD modeling of the source code modeling executable versions
12. Workshop on object oriented software engineering.
BASIC TECHNIQUES OF
MODELING COMPUTER
SYSTEM
WHAT IS A MODEL?
A model is a mathematical representation of a
physical, biological or information system. Models allow us
to reason about a system and make predictions about how a
system will behave. In this text, we will mainly be
interested in models describing the input/output behavior of
systems and often in so-called “state space” form.
WHY DO WE NEED
TO MODEL IN IT?
 WHY MODEL?
We need to model complex systems in the real world in order to understand them. For
example: we create computerized models of the real world to manipulate large amounts of data
and hence derive information which can assist in decision making.
An analysts will create diagrammatic models of a target or proposed system in order to:
• understand the system, and
• communicate:
• to demonstrate, or clarify, understanding of the existing system and/or to obtain feedback from
users/clients;
• to describe unambiguously the proposed computer system to users/clients and to the programming team.

 Modeling techniques are extremely useful in tackling the complexity which is found when
attempting to analyze and understand a system. Models are also extremely useful
communication tools; ie: complex ideas and concepts can be captured on paper and can be
shown to users and clients for clarification and feedback; or for distribution to other
professionals, team members, contractors etc. In this respect, the final models created in the
Design and Development phases of a system are essentially paper based prototypes.
MODELING TECHNIQUES
The three most important modeling techniques
used in analyzing and building information
systems are:
• Data Flow Diagramming (DFDs)
• Logical Data Structure modelling (LDSs) and
• Entity Life Histories (ELHs)
 DATA FLOW DIAGRAMS (DFDS)
 Data Flow
Diagrams (DFDs) model events and processes (i
.e. activities which transform data) within a
system. DFDs examine how data flows into, out
of, and within the system. (Note: 'data' can be
understood as any 'thing' (e.g.: raw materials,
filed information, ideas, etc.) which is processed
within the system.
 LOGICAL DATA
STRUCTURES (LDSS)
 Logical Data
Structures (LDSs) represent a
system's information and data in
another way. LDSs map the
underlying data structures as entity
types, entity attributes, and the
relationships between the entities.
 ENTITY LIFE HISTORIES (ELHS)
 Entity Life
Histories (ELHs) describe the
changes which happen to 'things'
(entities) within the system.
 DFD PRINCIPLES
• The general principle in Data Flow Diagramming is that a system can be decomposed
into subsystems, and subsystems can be decomposed into lower level subsystems, and
so on.
• Each subsystem represents a process or activity in which data is processed. At the
lowest level, processes can no longer be decomposed.
• Each 'process' (and from now on, by 'process' we mean subsystem and activity) in a
DFD has the characteristics of a system.
• Just as a system must have input and output (if it is not dead), so a process must have
input and output.
• Data enters the system from the environment; data flows between processes within the
system; and data is produced as output from the system
BASIC DFD NOTATIONS
In a DFD,
a process may be shown as a circle, an oval, or
(typically) a rectangular box; and
data are shown as arrows coming to, or going from
the edge of the process box.
In SSADM (Structured Systems Analysis and
Design Methodology)
 SSADM USES 4 DIAGRAMMING
NOTATIONS IN DFDS
• Processes transform or manipulate data. Each box has a unique
number as identifier (top left) and a unique name (an imperative -
eg: 'do this' - statement in the main box area) The top line is used
for the location of, or the people responsible for, the process.
• Data Flows depict data/information flowing to or from a process.
The arrows used to represent the flows must either start and/or
end at a process box.
• Data Stores are some location where data is held temporarily or
permanently.
• External Entities , also known as 'External source/recipients, are
things (eg: people, machines, organizations etc.) which contribute
data or information to the system or which receive
data/information from it.
 DFD LEVELS

 The 'Context Diagram ' is an overall, simplified, view of the target

system, which contains only one process box, and the primary
inputs and outputs.
 The Context diagram above, and the one which follows, are a first
attempt at describing part of a 'Home Catalogue' sales system. In
the modeling process it is likely that diagrams will be reworked and
amended many times - until all parties are satisfied with the
resulting model. A model can usefully be described as a coordinated
set of diagrams.
OVERVIEW OF PROMINENT
OBJECT-ORIENTED
METHODOLOGIES
 OBJECT ORIENTED METHODOLOGY
Object Oriented Methodology (OOM) is a system
development approach encouraging and facilitating
re-use of software components. With this
methodology, a computer system can be developed on
a component basis which enables the effective re-use
of existing components and facilitates the sharing of
its components by other systems.
This methodology employs international standard Unified
Modeling Language (UML) from the Object Management
Group (OMG). UML is a modeling standard for OO
analysis and design which has been widely adopted in the
IT industry.
The OOM life cycle consists of six stages. These stages are
the business planning stage, the business architecture
definition stage, the technical architecture definition stage,
the incremental delivery planning stage, the incremental
design and build stage, and the deployment stage.
 OOM PROCEDURES MANUAL
1. Purpose
The objectives of this document are to describe the Object Oriented Methodology (OOM) process
structure and to detail the procedures involved in conducting OOM projects.
2. Scope
The intended readers of this manual are the practitioners of OOM projects. This manual is structured
according to the stages of the OOM process. For each task in the OOM stages, the following information
is documented :
• Objective
• Description
• Prerequisites
• Deliverables
• Guidelines
• Techniques
• Sub-tasks

 For ease of reference, part of the contents are extracted from the full manual and summarized in the
3. OOM Overview
Object Oriented Methodology (OOM) is a system development approach
encouraging and facilitating re-use of software components. With this
methodology, a computer system can be developed on a component basis which
enables the effective re-use of existing components and facilitates the sharing
of its components by other systems. Through the adoption of OOM, higher
productivity, lower maintenance cost and better quality can be achieved.

The OOM life cycle consists of six stages :

• Business planning;
• Business architecture definition;
• Technical architecture definition;
• Incremental delivery planning;
• Incremental design and build;
• Deployment.
THE OO MODEL IS
BENEFICIAL
• It facilitates changes in the system at low cost.
• It promotes the reuse of components.
• It simplifies the problem of integrating components
to configure large system.
• It simplifies the design of distributed systems.
 ELEMENTS OF OBJECT-ORIENTED SYSTEM
• Objects − An object is something that is exists within problem domain and can be identified
by data (attribute) or behavior. All tangible entities (student, patient) and some intangible
entities (bank account) are modeled as object.
• Attributes − They describe information about the object.
• Behavior − It specifies what the object can do. It defines the operation performed on objects.
• Class − A class encapsulates the data and its behavior. Objects with similar meaning and
purpose grouped together as class.
• Methods − Methods determine the behavior of a class. They are nothing more than an action
that an object can perform.
• Message − A message is a function or procedure call from one object to another. They are
information sent to objects to trigger methods. Essentially, a message is a function or
procedure call from one object to another.
 OBJECT ORIENTED SYSTEM DEVELOPMENT
LIFE CYCLE

It consists of three macro processes −

• Object Oriented Analysis (OOA)
• Object oriented design (OOD)
• Object oriented Implementation (OOI)
INTRODUCTION TO UML
(UNIFIED MODELING
LANGUAGE)
 UNIFIED MODELING LANGUAGE (UML) |
AN INTRODUCTION

Unified Modeling Language (UML) is a

general purpose modelling language. The main aim
of UML is to define a standard way to visualize the
way a system has been designed. It is quite similar to
blueprints used in other fields of engineering.
UML is not a programming language, it is rather a
visual language. We use UML diagrams to portray
the behavior and structure of a system. UML helps
software engineers, businessmen and system architects
with modelling, design and analysis. The Object
Management Group (OMG) adopted Unified Modelling
Language as a standard in 1997. Its been managed by
OMG ever since. International Organization for
Standardization (ISO) published UML as an approved
standard in 2005. UML has been revised over the years
and is reviewed periodically.
DO WE REALLY
NEED UML?
 DO WE REALLY NEED UML?
• Complex applications need collaboration and planning from
multiple teams and hence require a clear and concise way to
communicate amongst them.
• Businessmen do not understand code. So UML becomes
essential to communicate with non programmers essential
requirements, functionalities and processes of the system.
• A lot of time is saved down the line when teams are able to
visualize processes, user interactions and static structure of the
system.
UML is linked with object oriented design and analysis. UML makes
the use of elements and forms associations between them to form
diagrams. Diagrams in UML can be broadly classified as:
1.Structural Diagrams – Capture static aspects or structure of a
system. Structural Diagrams include: Component Diagrams, Object
Diagrams, Class Diagrams and Deployment Diagrams.
2.Behavior Diagrams – Capture dynamic aspects or behavior of the
system. Behavior diagrams include: Use Case Diagrams, State
Diagrams, Activity Diagrams and Interaction Diagrams.

The image below shows the hierarchy of diagrams according to UML

2.2
 OBJECT ORIENTED CONCEPTS USED IN UML
1.Class – A class defines the blue print i.e. structure and functions of an object.
2.Objects – Objects help us to decompose large systems and help us to modularize
our system. Modularity helps to divide our system into understandable
components so that we can build our system piece by piece. An object is the
fundamental unit (building block) of a system which is used to depict an entity.
3.Inheritance – Inheritance is a mechanism by which child classes inherit the
properties of their parent classes.
4.Abstraction – Mechanism by which implementation details are hidden from user.
5.Encapsulation – Binding data together and protecting it from the outer world is
referred to as encapsulation.
6.Polymorphism – Mechanism by which functions or entities are able to exist in
different forms.
 ADDITIONS IN UML 2.0 –
• Software development methodologies like agile have been incorporated and
scope of original UML specification has been broadened.
• Originally UML specified 9 diagrams. UML 2.x has increased the number of
diagrams from 9 to 13. The four diagrams that were added are : timing diagram,
communication diagram, interaction overview diagram and composite structure
diagram. UML 2.x renamed state chart diagrams to state machine diagrams.
• UML 2.x added the ability to decompose software system into components and
sub-components.
STRUCTURAL
UML DIAGRAMS
1.Class Diagram – The most widely use UML diagram is the class diagram. It is the
building block of all object oriented software systems. We use class diagrams to
depict the static structure of a system by showing system’s classes, their methods
and attributes. Class diagrams also help us identify relationship between different
classes or objects.
2.Composite Structure Diagram – We use composite structure diagrams to
represent the internal structure of a class and its interaction points with other parts
of the system. A composite structure diagram represents relationship between parts
and their configuration which determine how the classifier (class, a component, or
a deployment node) behaves. They represent internal structure of a structured
classifier making the use of parts, ports, and connectors. We can also model
collaborations using composite structure diagrams. They are similar to class
diagrams except they represent individual parts in detail as compared to the entire
class.
3. Object Diagram – An Object Diagram can be referred to as a screenshot of the
instances in a system and the relationship that exists between them. Since object
diagrams depict behavior when objects have been instantiated, we are able to study
the behavior of the system at a particular instant. An object diagram is similar to a
class diagram except it shows the instances of classes in the system. We depict
actual classifiers and their relationships making the use of class diagrams. On the
other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.
4. Component Diagram – Component diagrams are used to represent the how the
physical components in a system have been organized. We use them for modelling
implementation details. Component Diagrams depict the structural relationship
between software system elements and help us in understanding if functional
requirements have been covered by planned development. Component Diagrams
become essential to use when we design and build complex systems. Interfaces are
used by components of the system to communicate with each other.
5. Deployment Diagram – Deployment Diagrams are used to represent system
hardware and its software. It tells us what hardware components exist and what
software components run on them. We illustrate system architecture as distribution
of software artifacts over distributed targets. An artifact is the information that is
generated by system software. They are primarily used when a software is being
used, distributed or deployed over multiple machines with different configurations.
6. Package Diagram – We use Package Diagrams to depict how packages and their
elements have been organized. A package diagram simply shows us the
dependencies between different packages and internal composition of packages.
Packages help us to organize UML diagrams into meaningful groups and make the
diagram easy to understand. They are primarily used to organize class and use case
diagrams.
BEHAVIOR
DIAGRAMS
1.State Machine Diagrams – A state diagram is used to represent the condition of
the system or part of the system at finite instances of time. It’s a behavioral
diagram and it represents the behavior using finite state transitions. State diagrams
are also referred to as State machines and State-chart Diagrams . These terms
are often used interchangeably. So simply, a state diagram is used to model the
dynamic behavior of a class in response to time and changing external stimuli.
2.Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in
a system. We can also use an activity diagram to refer to the steps involved in the
execution of a use case. We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows visually using an activity
diagram. An activity diagram focuses on condition of flow and the sequence in
which it happens. We describe or depict what causes a particular event using an
activity diagram.
3. Use Case Diagrams – Use Case Diagrams are used to depict the functionality of
a system or a part of a system. They are widely used to illustrate the functional
requirements of the system and its interaction with external agents(actors). A use
case is basically a diagram representing different scenarios where the system can be
used. A use case diagram gives us a high level view of what the system or a part of
the system does without going into implementation details.
4. Sequence Diagram – A sequence diagram simply depicts interaction between
objects in a sequential order i.e. the order in which these interactions take place. We
can also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in a system
function. These diagrams are widely used by businessmen and software developers
to document and understand requirements for new and existing systems.
5.Communication Diagram – A Communication Diagram(known as Collaboration
Diagram in UML 1.x) is used to show sequenced messages exchanged between
objects. A communication diagram focuses primarily on objects and their
relationships. We can represent similar information using Sequence diagrams,
however, communication diagrams represent objects and links in a free form.
6.Timing Diagram – Timing Diagram are a special form of Sequence diagrams
which are used to depict the behavior of objects over a time frame. We use them to
show time and duration constraints which govern changes in states and behavior of
objects.
7.Interaction Overview Diagram – An Interaction Overview Diagram models a
sequence of actions and helps us simplify complex interactions into simpler
occurrences. It is a mixture of activity and sequence diagrams.
 EXAMPLES OF UML

UML is made up of −
• Diagrams − It is a pictorial representations of process, system, or
some part of it.
• Notations − It consists of elements that work together in a
diagram such as connectors, symbols, notes, etc.
EXAMPLE OF UML NOTATION FOR CLASS
INSTANCE DIAGRAM-UML NOTATION
 OPERATIONS PERFORMED ON OBJECTS

The following operations are performed on the objects −

• Constructor/Destructor − Creating new instances of a class and
deleting existing instances of a class. For example, adding a new
employee.
• Query − Accessing state without changing value, has no side effects. For
example, finding address of a particular employee.
• Update − Changes value of one or more attributes & affect state of
object For example, changing the address of an employee
 ASSOCIATION:
 When we talk about the association in java, then this is nothing but a structural relationship,
in object-oriented modeling, that specifies how objects are related to one another. This
structural relationship can be shown in two forms:
 Class diagram associations
 Use case diagram associations.

 Association represents the unidirectional or bidirectional relationship between two classes.

If the Customer places an order, then this is a unidirectional association.
 Bidirectional Association example: Person and Dog classes that setup a bidirectional
association between a Person object and a Dog object. A Person object behaves like an
owner for a Dog object and the Dog object behaves like a pet for the Person object. An
association may exist between objects of different types or between the objects of the same
type means of the same class. An association in UML is drawn as a solid line connecting
the object of different classes or two objects of the same class.
 AGGREGATION
 In Aggregation, the based object is standalone and can exist even if the object of the
control class is dead. Let’s take an example: suppose we have a class Car and car has a
dependent object as a Wheel. Now when we destroy the car, the Wheel object is still alive
because the wheel can be fit into different cars. So, here the association between Car and
Wheel is the aggregation.
 First of all, to exist an aggregation relationship, there would be some association. In a
plain association, classes are considered at the same level with one class having no more
important than the other. Sometimes we do need to define a “whole/part” relationship
where one class considered as a “whole” that consists of smaller classes that is considered
as a “part”. This kind of relationship is called aggregation. It is also known as “Has-A”
relationship as object of the whole has the object of the parts.
AN AGGREGATION IN UML IS
DRAWN AS AN OPEN
DIAMOND AS BELOW:
 COMPOSITION
 As we have seen aggregation relationship makes a distinction between “whole” and
“part”, but it does not force ownership. Also, the aggregation does not link the
“whole” and “part” object in such a way that if the whole is destroyed then parts are
also destroyed.
 There is a variation of aggregation called “composition”. This has strong
ownership, thus the scope of the whole and part are related. In composition, if there
are two classes, class A(considered as a whole) and class B(considered as part) ,
then the destruction of class object will mean that class B object also does not exist.
This also means that class B object may be a part of class A object only. So, this is a
tight association. Composition in UML is drawn as a “filled diamond” at the whole
end.
 So, here in the above diagram, we have a Department class and school class. There is a
relationship exists from department to school.
 The composition is an even stronger relationship than aggregation. To test for whether you are
dealing with composition, you should use the “no-sharing rule”. This rule states that in a
composition relationship, the part can belong to only one hole. So, in our example above does
musician belong to only one band? This is not true. A musician can belong to a number of
different bands. Same with the product-catalog relationship. Any particular product could
appear in a number of different catalogs.
AGGREGATION VS COMPOSITION
SUMMARY

 Aggregation and Composition are a special type of association and

differ only in the weight of the relationship.
 Composition is a powerful form of “is part of” relationship collated
to aggregation “Has-A”.
 In Composition, the member object cannot exist outside the
enclosing class while same is not true for Aggregation.
INHERITANCE
 Inheritance is basically Is-A relationship. We can achieve
inheritance with the help of extends keyword. I believe you are
already aware of the inheritance basics and the types of inheritance.
I am discussing here the advantages of inheritance and how it is
different from the Composition.
 Main advantage of inheritance is code reusability. Suppose if Class
B extends Class A, then all the properties of class A come into class
B and we can access all the properties of Class A in Class B expect
the private members. Also, we can call methods of A class using B
class object.
 USES OF UML
UML is quite useful for the following purposes −
• Modeling the business process
• Describing the system architecture
• Showing the application structure
• Capturing the system behavior
• Modeling the data structure
• Building the detailed specifications of the system
• Sketching the ideas
• Generating the program code
CLASS DIAGRAM
IN UML
 DEFINITION
 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.
 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
modeling of object-oriented systems because they are the only UML diagrams,
which can be mapped directly with object-oriented languages.
 Class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints. It is also known as a structural diagram.
 PURPOSE OF CLASS
DIAGRAMS
 The purpose of class diagram is to model the static view of an application. Class
diagrams are the only diagrams which can be directly mapped with object-oriented
languages and thus widely used at the time of construction.
 UML diagrams like activity diagram, sequence diagram can only give the sequence
flow of the application, however class diagram is a bit different. It is the most
popular UML diagram in the coder community.
 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.
HOW TO DRAW A CLASS
DIAGRAM?
 Class diagrams are the most popular UML diagrams used for construction of
software applications. It is very important to learn the drawing procedure of
class diagram.
 Class diagrams have a 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. 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, as unnecessary
properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. 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
reworked as many times as possible to make it correct.
 The following diagram is an example of an Order System of an application.
It describes a particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the
system. They have a one-to-many relationship because a customer can have
multiple orders.
 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 ().
 WHERE TO USE CLASS
DIAGRAMS?
 Class diagram is a static diagram and it is used to model the 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 such as Java, C++, etc. From
practical experience, class diagram is generally used for construction purpose.
 In a nutshell it can be said, 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.
USE CASE
DIAGRAMS
 DEFINITION
 To model a system, the most important aspect is to capture the dynamic behavior.
Dynamic behavior means the behavior of the system when it is running/operating.
 Only static behavior is not sufficient to model a system rather dynamic behavior is
more important than static behavior. In UML, there are five diagrams available to
model the 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. Use case diagrams 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.
 Hence to model the entire system, a number of use case diagrams are used.
 PURPOSE OF USE CASE
DIAGRAMS
 The purpose of use case diagram is to capture the dynamic aspect of a system.
However, this definition is too generic to describe the purpose, as other four
diagrams (activity, sequence, collaboration, and Statechart) also have the same
purpose. 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. Hence, when a system is analyzed to gather its functionalities, use
cases are prepared and actors are identified.
When the initial task is complete, use case diagrams are modelled to
present the outside view.
In brief, the purposes of use case diagrams can be said to be as follows −
 Used to gather the requirements of a system.
 Used to get an outside view of a system.
 Identify the external and internal factors influencing the system.
 Show the interaction among the requirements are actors.
 HOW TO DRAW A USE CASE DIAGRAM?
 Use case diagrams are considered for high level requirement analysis of a system. When
the requirements of a system are analyzed, the functionalities are captured in use cases.
 We can say that use cases are nothing but the system functionalities written in an organized
manner. The second thing which is relevant to use cases are the actors. Actors can be
defined as something that interacts with the system.
 Actors can be a human user, some internal applications, or may be some external
applications. When we are planning to draw a use case diagram, we should have the
following items identified.
 Functionalities to be represented as use case
 Actors
 Relationships among the use cases and actors.
 Use case diagrams are drawn to capture the functional requirements of a system. After
identifying the above items, we have to use the following guidelines to draw an efficient use
case diagram
 The name of a use case is very important. 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, as the main purpose of the diagram is to identify the
requirements.
 Use notes whenever required to clarify some important points.

 Following is a sample use case diagram representing the order management system. Hence, if
we look into the diagram then we will find three use cases (Order, SpecialOrder, and
NormalOrder) and one actor which is the customer.
 The SpecialOrder and NormalOrder use cases are extended from Order use case. Hence, they
have extended 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.
 WHERE TO USE A USE CASE DIAGRAM?
 As we have already discussed there are five diagrams in UML to model the 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.
 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. 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, and exceptions. These extra elements
are used to make test cases when performing the testing.
 Although use case is not a good candidate for forward and reverse engineering, still
they are used in a slightly different way to make forward and reverse engineering.
The same is true for reverse engineering. Use case diagram is used differently to
make it suitable 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.
 Use case diagrams can be used for −
 Requirement analysis and high level design.
 Model the context of a system.
 Reverse engineering.
 Forward engineering.
INTERACTION
DIAGRAM
 DEFINITION
 From the term Interaction, it is clear that the diagram is used to describe some type
of interactions among the different elements in the model. This interaction is a part
of dynamic behavior of the system.
 This interactive behavior is represented in UML by two diagrams known as
Sequence diagram and Collaboration diagram. The basic purpose 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 OF INTERACTION DIAGRAMS

 The purpose of interaction diagrams is to visualize the interactive behavior of the system.
Visualizing the interaction is a difficult task. Hence, the solution is to use different types of
models to capture the different aspects of the interaction.
 Sequence and collaboration diagrams are used to capture the dynamic nature but from a
different angle.
 The purpose of interaction diagram is −
 To capture the dynamic behavior of a system.
 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.
 HOW TO DRAW AN INTERACTION
DIAGRAM?
 As we have already discussed, the purpose of interaction diagrams is 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 snapshot of the running system at a particular moment
 We have two types of interaction diagrams in UML. One is the sequence diagram and the other is the
collaboration diagram. The sequence diagram captures the time sequence of the 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.
 Following things are to be 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 the order management system. The first diagram is a
sequence diagram and the second is a collaboration diagram
 THE SEQUENCE DIAGRAM
 The sequence diagram has four objects (Customer, Order, SpecialOrder and
NormalOrder).
 The following diagram shows the message sequence for SpecialOrder object and
the same can be used in case of NormalOrder object. 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. The following diagram mainly
describes 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 the collaboration diagram. It shows the object
organization as seen in the following diagram. In the collaboration diagram, the method call
sequence is indicated by some numbering technique. The number indicates how the
methods are called one after another. We have taken the same order management system to
describe the collaboration diagram.
 Method calls are similar to that of a sequence diagram. However, difference being the
sequence diagram does not describe the object organization, whereas the collaboration
diagram shows the object organization.
 To choose between these two diagrams, emphasis is placed on the type of requirement. If
the time sequence is important, then the sequence diagram is used. If organization is
required, then collaboration diagram is used.
 WHERE TO USE INTERACTION
DIAGRAMS?
 We have already discussed that interaction diagrams are used to describe the 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 purpose of both the diagrams are similar as they are used to capture the dynamic
behavior of a system. However, the specific purpose is more important to clarify and
understand.
 Sequence diagrams are used to capture the order of messages flowing from one object to
another. Collaboration diagrams are used to describe the structural organization 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 it as a whole.
 Interaction diagrams are used when we want to understand the message
flow and the structural organization. Message flow means the sequence
of control flow from one object to another. Structural organization
means the visual organization of the elements in a system.
 Interaction diagrams can be used −
To model the flow of control by time sequence.
To model the flow of control by structural organizations.
For forward engineering.
For reverse engineering.
STATECHART
DIAGRAMS
DEFINITION
 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.
 A Statechart diagram describes a state machine. 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 the next chapter, is a special kind of a Statechart
diagram. As Statechart diagram defines the states, it is used to model the
lifetime of an object.
 PURPOSE OF STATECHART DIAGRAMS
 Statechart diagram is one of the five UML diagrams used to model the dynamic nature of a
system. They define different states of an object during its lifetime and these states are
changed by events. Statechart diagrams are useful to model the 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.
The most important purpose of Statechart diagram is to model lifetime of an object from
creation to termination.
 Statechart diagrams are also used for forward and reverse engineering of a system. However,
the main purpose is to model the reactive system.
 Following are the main purposes of using Statechart diagrams −
 To model the dynamic aspect of a system.
 To model the life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model the states of an object.
 HOW TO DRAW A STATECHART DIAGRAM?

 Statechart diagram is used to describe the states of different objects in its life cycle.
Emphasis is placed 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 should clarify the following points −
 Identify the important objects to be analyzed.
 Identify the states.
 Identify the events.
 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 the 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 exits. This abnormal
exit may occur due to some problem in the system. When the entire life
cycle is complete, it is considered as a complete transaction as shown in
the following figure. The initial and final state of an object is also
shown in the following figure.
 WHERE TO USE STATECHART DIAGRAMS?

 From the above discussion, we can define the practical applications of a Statechart
diagram. Statechart diagrams are used to model the dynamic aspect of a system like other
four diagrams discussed in this tutorial. However, it has some distinguishing
characteristics for modeling the dynamic nature.
 Statechart diagram defines the states of a component and these state changes are dynamic
in nature. Its specific purpose is to define the state changes triggered by events. Events are
internal or external factors influencing the system.
 Statechart diagrams are used to model the states and also the 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
the 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 behavior during its execution.
 The main usage can be described as −
 To model the object states of a system.
 To model the reactive system. Reactive system consists of reactive objects.
 To identify the events responsible for state changes.
 Forward and reverse engineering.
ACTIVITY
DIAGRAMS
DEFINITION
 Activity diagram is another important diagram in UML to describe the
dynamic aspects of the system.
 Activity diagram is basically a flowchart to represent the flow from one
activity to another activity. The activity can be described as an operation of the
system.
 The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of
flow control by using different elements such as fork, join, etc
 PURPOSE OF ACTIVITY

DIAGRAMS
The basic purposes of activity diagrams is similar to other four diagrams. It captures the
dynamic behavior 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 the 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 the activity diagram is the message part.
 It does not show any message flow from one activity to another. Activity diagram is
sometimes considered as the flowchart. Although the diagrams look like a flowchart, they
are not. It shows different flows such as parallel, branched, concurrent, and single.
 The purpose of an activity diagram 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 AN ACTIVITY DIAGRAM?
 Activity diagrams are mainly used as a flowchart that consists of activities performed by the
system. Activity diagrams are not exactly flowcharts 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.
 Before drawing an activity diagram, we should identify the following elements −
 Activities
 Association
 Conditions
 Constraints
 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.
 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 is mainly
used by the business users
 Following diagram is drawn with the four main activities −
 Send order by the customer
 Receipt of the order
 Confirm the order
 Dispatch the 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 ACTIVITY 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.
 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
the 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.
 We will now 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. The diagram has more impact on business understanding rather
than on implementation details.
 Activity diagram can be used for −
 Modeling work flow by using activities.
 Modeling business requirements.
 High level understanding of the system's functionalities.
 Investigating business requirements at a later stage.