UNIT-4.

Software Design, Coding & Testing

4.1 Good Software Design

 The goodness of a design is dependent on the targeted application

 For example , the memory size used up by a Program may be an important issue to
characterize a good solution for Embedded Software Development

 The criteria used to judge how good a given design solution is can vary widely depending
on the Application

 The design itself varies widely across Software Engineers and Academicians

 Good design should possess certain characteristics that every designer should agree

Characteristics of a Good Software Design

Correctness:

 A good design should correctly implement all the functionalities of the system

 A design has to be correct to be acceptable

Understandability:

 A good design should be easily understandable

 Easy to develop, maintain, and change the design

Efficiency: It should be efficient

Maintainability: it can be changed easily

4.2 Cohesion and Coupling

 Cohesion is a measure of the functional strength of a module

 Coupling between two modules is a measure of the degree of interdependence or

interaction between the two modules

 A Good Software Design implies

 Clean decomposition of the problem into modules

 Neat arrangement of these modules

 What do we really mean by neat decomposition of a problem into modules?

1
  The primary characteristics of a neat module decomposition are high Cohesion and low
Coupling

 A module having high Cohesion and low Coupling is said to be functionally independent
of other modules

 By the term Functional Independence, we mean that a cohesive module performs a single
task or function

 A Functionally Independent Module has minimal interaction with other modules

 Functional Independence is a key to any Good design primarily due to some reasons

4.2.1 Classification of Cohesiveness

 Coincidental Cohesion

 Logical Cohesion

 Temporal Cohesion

 Procedural Cohesion

 Communicational Cohesion

 Sequential Cohesion

 Functional Cohesion

Coincidental Cohesion

 A module is said to have coincidental cohesion, if it performs a set of tasks that relate to
each other very loosely, if at all
 In this case , module contains a random collection of functions
 It is likely that the functions have put in the module out of pure coincidence without any
thought or design

Logical Cohesion

 A module is said to have logical cohesion, if all elements of the module perform similar
operations
e.g. error handling, data input, data output, etc.
 An example : Set of print functions generating different output reports are arranged into
a single module

Temporal Cohesion

 When a module contains functions that all the functions must be executed in the same
time span, the module is said to exhibit temporal cohesion

2
  Example : The set of functions responsible for initialization, start-up, shut-down of
some process, etc. exhibit temporal cohesion

Procedural Cohesion

 A module is said to possess procedural cohesion, if the set of functions of the module are
all part of a procedure in which certain sequence of steps has to be carried out for
achieving an objective

 Example : The algorithm for decoding a message

Communicational Cohesion

 A module is said to have communicational cohesion, if all the functions of the module
refer to or update the same data structure

 Example : The set of functions defined on an array or a stack

Sequential Cohesion

 A module is said to possess sequential cohesion, if the elements of a module form the
parts of a sequence, where the output from one element of a sequence is input to the next

Functional Cohesion

 Functional cohesion is said to exist, if the different elements of a module cooperate to

achieve a single function

 For example, a module containing all the functions required to manage employees
payroll displays functional cohesion

 If module displays functional cohesion, we would be able to describe it using a single

sentence

4.2.2 Classification of Coupling

Coupling

 The degree of coupling between two modules indicates the degree of interdependence
between them

 The degree of coupling between two modules depends on their interface complexity

 The interface complexity is depends on the number of types of parameters that are
interchanged while invoking the functions of the module

 If two modules interchange large amounts of data, then they are highly interdependent

3
Classification of Coupling

Data Coupling

 Two modules are data coupled, if they communicate using an elementary data item that is
passed as a parameter between the two. e.g. an integer, a float, a character, etc.

 This data item should be problem related and not used for the control purpose

Stamp Coupling

 Two modules are stamp coupled, if they communicate using a composite data item
such as a record in PASCAL or a structure in C

Control Coupling

 Control coupling exists between two modules, if data from one module is used to direct
the order of instruction execution in another

 An example of control coupling is a flag set in one module and tested in another module

Common Coupling

“Two modules are common coupled, if they share some global data items.“

Content Coupling

 Content coupling exists between two modules, if their code is shared

 Example : A branch from one module into another module

4.3 Software Design Approaches

Two Approaches to Software Design:

 Function Oriented Design Approach. ( FOD )

 Algorithmic perspective

 Object Oriented Design Approach. ( OOD )

 Object orientation perspective

4
4.3.1 Function Oriented Design
 Focuses on functional abstraction and functional decomposition

 A system is viewed as performing a set of functions.

 Starting at high-level view of the system, each function is successively refined into more
detailed sub functions

 Importance is given to either function or data

 Focuses on design algorithms to solve the problems i.e. Algorithmic perspective

Four Steps:

 Restate the problem as a Data Flow Diagram ( DFD )

 Identify the input and output data elements

 First level factoring of I/O elements and functions

 Second level factoring and transform branches i.e decomposition in sub-functions

An Example Function Oriented Design

Application: Library Management System

Problem: Create-New-Library Member

This function may consist of the following sub-functions:

 Create-member-record

 Assign-membership-number

 Print-bill

 Each of these sub-functions may be split into more detailed sub-functions

 The system state is centralized and shared among different functions

4.3.2 Object Oriented Design

 The system is viewed as a collection of objects which encapsulates the object data &
provides actions

 Main thrust is on data abstraction

 Both data and actions are equally important

 Well designed objects are independent units, so reusability is possible

 Objects communicate by passing messages

5
Design Activities to be carried out:

 Identify Core Objects

 Identify Object Attributes and Operations

 Identify Relationships between objects

 Identify Classes

 Identify the Modules

OOD -Advantages

 Data is highly secured. The functions defined for one object cannot change data of other
objects

 Well designed objects are independent units, so re-usability is possible

 Implementation details are hidden in the object

 Responsibility driven design ( Actions carried out are entirely the responsibility of
objects )

 OOD reduces the level of complexity

 Objects enter early in to the life cycle of Software development, better refined
requirements

 Smooth transition from phase to phase in OOD hence less errors / faults

 Maintenance is easier in OOD

 Development is easier in OOD

4.3.3 Function Oriented Vs Object Oriented Design

 In FOD, System is decomposed in to basic functions i.e. a System is viewed as that
performs a set of functions

 In OOD, System is decomposed in to basic units called objects. The System is viewed as
a collection of objects

 In FOD, The System state is centralized and shared among different functions

 In OOD, the System state is decentralized among the objects and each object manages its
own state information

 In FOD, function or operation performs an activity

 In OOD, object is not an operation, it is an entity that represents some data items
together with operation

6
  In FOD, data is not secured

 In OOD, Data is highly secured

 In FOD, design contains data items and procedures to manipulate data

 In OOD, data and procedures cannot be separated

 In FOD, it is Structured Paradigm that gives importance to either action or data

 In OOD, Both data and actions are equally important

 FOD, limited success as 2/3 of cost is spent on maintenance

 OOD gained high success as maintenance is easier

 In FOD, it is difficult to incorporate future changes

 OOD is adoptable to changes just by adding a new object to the system

 In FOD, as an example, PUSH and POP are two functions

 In OOD, single object of stack, but two operations are visible outside

 Function-oriented techniques, such as SA/SD, group the functions together if, as a group,
they constitute a higher-level function

 On the other hand, the object-oriented techniques group the functions together on the
basis of the data they operate on

4.4 Concept of User Interface

4.4.1 Characteristics of a Good User Interface

 Speed of Learning

 Speed of Use

 Speed Recall

 Error Prevention

 Attractiveness

 Consistency
 Feedback
 Support for Multiple Skill Levels
 Error Recovery ( Undo Facility)
 User Guidance and Online Help

Speed of Learning

 Good user interface should be easy to learn

7
  Not have complex syntax and semantics to facilitate better speed of learning

 GUI should not require its users to memorize commands

 Simple and not required user to remember on progress in screens

Speed of Use

 The speed of use of an User Interface is determined by the time and user effort necessary
to initiate and execute different commands

 This characteristic of the interface is sometimes referred to as productivity support of the

interface

Speed of Recall

 Once users learn how to use an Interface, the speed with which they recall the command
issue procedure should be maximized.

 This characteristic is very important for intermittent users

 The speed of recall is improved of the Interface is based on some metaphors, symbolic
command issue procedures, and intuitive command names

Error Prevention

 Good User Interface should minimize the scope of committing errors while initiating
different commands

 The Error Rate of an Interface can be easily determined by monitoring the errors
committed by an average User while using the interface

Attractiveness

 Good User Interface should be attractive to use

 An attractive User Interface catches user attention and fancy

 In this respect, graphics-based user interfaces have a definite advantage over the text-
based interfaces

Consistency

 The commands supported by a User Interface should be Consistent

 Consistency is to help users generalize the knowledge of aspects of the Interface from
one part to another

 Consistency facilitates speed of learning, speed of recall, and also helps in reducing the
error rate

Feedback
8
  Good User Interface must provide feedback to various User Actions

Especially, if any user request takes more than a few seconds to process, the user should be
informed about the state of the processing of his request

 In the absence of any response from the computer for a long time, a novice user might
even start recovery / shutdown procedures

 If required, the user should be periodically informed about the progress being made in
processing his command

Support for Multiple Skill Levels

 Good User Interface should support multiple levels of sophistication of command issue
procedure for different categories of users

 This is necessary because users with different levels of experience in using an application
prefer different types of Users Interfaces

Error Recovery

 While issuing commands even the expert users can commit errors

 Therefore a Good User Interface should allow a user to undo a mistake committed by
him while using the interface

 Users are inconvenienced if they cannot recover even from very simple types of errors,
they feel irritated, helpless, and out of control

User Guidance and Online Help

 Users seek guidance and online help when they either forget a command or unaware of
some features of the software

 Whenever users need guidance or seek help from the system, they should be assisted in
overcoming the problem at hand

4.4.2 Basic Concepts of a User Interface

 User Guidance and Online Help.

 Mode – Based vs. Modeless Interface.

 Graphical User Interface vs. Text-Based User Interface

User Guidance and Online Help

• Online Help System

• Guidance Messages

• Error Messages
9
User Guidance and Online Help

• Users may seek help to learn about the operation of the software any time using Online
Help System while using the Software

• Online Help is different from the Guidance and Error Messages which are flashed
automatically without the User asking for them

• The Guidance messages prompt the User with the options he has regarding the next
command and the status of the last command

• Users expect the Online Help Messages to be tailored to the context in which they invoke
the ‘Help System’.

• A Good Online Help System should keep track of what a user is doing while invoking
the Help system and provide the output message in a context-dependent way.

• A Good Online Help System should take advantage of any graphics and animation
characteristics of the screen and just not be a copy of the user’s Manual

• The Help Messages should be tailored to the user’s experience level

Guidance Messages

• The Guidance Messages should be carefully designed

– to prompt the user to the next actions he might pursue,

– to apprise him of the current status of the System and

– the progress made in processing his last command

• A Good Guidance System should have different levels of sophistication for different
categories of users.

– Provide a User with a menu or iconic interface

– Provide option to turn off the detailed messages

Error Messages

• Proper Error Messages should be generated in case of errors encountered by the system
or user due to some exceptional conditions, such as out of memory Avoid error messages
that are either ambiguous or too general such as ‘ invalid input or system error ’

• Error messages should be polite. Error messages should not have associated noise which
might embarrass the user

10
 • The message should be informative how a given error can be rectified

Mode Based vs Modeless Interface

• A mode is a state or collection of states in which only a subset of all user interaction tasks
can be performed.

• In a modeless interface, the same set of commands can be invoked at any time during the
running of the software.

• Mode based interface have multiple modes of operations

• Modeless interface has only a single mode

• In a Mode-based Interface , different sets of commands can be invoked depending on the

mode in which the system is currently working

• In Modeless, all the commands are invoked

– The Mode at any instant is determined by the sequence of commands already

issued by the user.

• A mode based Interface can be represented using a state transition diagram

– Each node of the state transition diagram would represent a mode

Graphical User Interface Vs Text Based User Interface

11
4.4.3 Types of User Interfaces
• Three Categories of User Interfaces :

1. Command Language Based Interfaces

2. Menu Based Interfaces

3. Direct Manipulation Interfaces

Command Language Based Interface

• User can issue commands based on a command language

• Design appropriate commands using the language and assign unique names to different
commands

• Allows user to compose complex commands by using set of primitive commands which
reduces the number of command names available

• Allows faster interaction with the computer and simplify the input of complex commands

Advantages of Command Language Based Interface

• Allows user to compose complex commands by using set of primitive commands which
reduces the number of command names available

• Allows faster interaction with the computer and simplify the input of complex commands

• Permits efficient command issue procedure requiring minimal typing, can be

implemented even on a cheap alphanumeric terminals

• Easier to develop compared to other Interfaces, because compilers are available such as
LEX and YACC

12
Command Language Based Interface Disadvantages

• Difficult to learn and requires user to memorize the set of primitive commands

• Not suitable for casual and inexperienced users

• Error prone while designing & typing commands

• All interactions with the system are through a keyboard not through mouse

Menu Based Interface

• A menu I is based on recognition of the command names, rather than recollection

• User need not remember exact syntax of the commands

• Minimized typing : All interactions are carried through menu selection using pointing
device such as mouse

• Composing commands is not possible because logical connection of actions are awkward
to specify

• It is slower than Command language interface

• Difficult to design a menu based interface, if the number of choices are large

Menu Based Interface – A Challenge

A major challenge in the design of a Menu Based Interface is that of structuring the large
number of menu choices into manageable forms

Techniques for Structuring Large Number of Menu Options

Some of the techniques available to structure a large amount of menu items:

– Scrolling menu.

– Walking menu.

– Hierarchical menu.

Issues in Scrolling Menu

• When a full choice cannot be displayed within the menu area, scrolling of the menu items
is required

• This enables the user to view and select the menu items that cannot be accommodated on
the screen

• In a scrolling menu, all the commands should be highly correlated, so that the user can
easily locate a command that he needs
13
 • User cannot see all the commands at any one time

Font Size Selection using Scrolling Menu

Walking Menu

• Walking menu is a commonly used menu to structure a large collection of menu items

• In this technique, when a menu item is selected, it causes submenus displayed on right
side of the selected option

• Used to structure commands if there are limited choices

An Example Walking Menu

Hierarchical Menu

• The menu items are organized in a hierarchy or tree structure

• Selection a menu item causes the current menu display to be replaced by an appropriate
submenu

• One can consider the menu and its various sub-menus to form a hierarchical tree-like
structure

14
 • It is a walking menu can be considered to be a form of hierarchical menu which is
practicable when the tree is shallow

• Hierarchical menu can be used to manage a large number of choices, but the users are
likely to face navigational problems and therefore lose track of their where abouts in the
menu tree

• This type of interface is very rarely used

Direct Manipulation Interfaces

• Direct manipulation present the interface to the user in the form of visual models i.e.
icons or objects

• Direct manipulation Interfaces are also called iconic Interfaces

• In Direct Manipulation Interface, user issues commands by performing actions on icons.

example dragging and drop to delete a file

• Advantages - Icons can be recognized very easily and icons are language independent

• Slow to experienced users and difficult to design complex commands

4.5. Study the concepts of the Unified Modelling Language

Unified Modeling Language (UML) is a general purpose modeling 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 modeling, design and analysis.

4.5.1. List the goals of UML

o Since it is a general-purpose modelling language, it can be utilized by all the modellers.
o UML came into existence after the introduction of object-oriented concepts to systemize
and consolidate the object-oriented development, due to the absence of standard methods
at that time.
o The UML diagrams are made for business users, developers, ordinary people, or anyone
who is looking forward to understand the system, such that the system can be software or
non-software.
o Thus it can be concluded that the UML is a simple modelling approach that is used to
model all the practical systems.

15
4.5.2. Know the role of UML in Object Oriented Design
UML is a modelling language used to model software and non-software systems. Although
UML is used for non-software systems, the emphasis is on modelling OO software applications.
Most of the UML diagrams discussed so far are used to model different aspects such as static,
dynamic, etc. Now whatever be the aspect, the artefacts is nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
Hence, 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 detail, the OO concept should be learned properly. Once the OO analysis and
design is done, the next step is very easy. The input from OO analysis and design is the input to
UML diagrams.
4.5.3. List the building blocks of UML.
The building blocks of UML can be defined as −

 Things
 Relationships
 Diagrams
4.5.4. Explain the UML building blocks
The building blocks of UML can be defined as −

 Things
 Relationships
 Diagrams

Things
Things are the most important building blocks of UML. Things can be −

 Structural
 Behavioral
 Grouping
 An notational

Structural Things

Structural things define the static part of the model. They represent the physical and
conceptual elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

16
Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

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

Component −Component describes the 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

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 −

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

An notational Things

An notational things can be defined as a mechanism to capture remarks, descriptions, and

comments of UML model elements. Note - It is the only one An notational thing available. A
note is used to render comments, constraints, etc. of an UML element.

Relationship
Relationship is another most important building block of UML. It shows how the 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.

Association

Association is basically a set of links that connects the elements of a 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 the inheritance relationship in the world of objects.

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

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 complete.
UML includes the following nine diagrams, the details of which are described in the subsequent
chapters.

 Class diagram
 Object diagram
 Use case diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 State chart diagram
 Deployment diagram
 Component diagram
4.5.5. Know the different symbols used in UML notation
Class:

Interface:

Collaboration:

Use case:

19
Component:

Node :

Message:

State machine :

Package:

Note -

Dependency

Association

Generalization

Realization

20
4.5.6. Classify and list standard UML diagrams

4.6 Know the purpose of Class diagram and draw simple class diagrams
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.

21
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 ().
The following class diagram has been drawn considering all the points mentioned above.

22
4.7 [Link] the term Use case
A use case is a list of actions or event steps typically defining the interactions between a role
(known in the Unified Modeling Language (UML) as an actor) and a system to achieve a goal.
[Link] the purposes of Use casediagram
The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and elements
accountable for the implementation of use case diagrams. It represents how an entity from the
external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4. It represents the interaction between the actors.

[Link] to draw the Use Case Diagram

It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified, they
are then transformed into the use cases to be used in the use case diagram.

After that, we will enlist the actors that will interact with the system. The actors are the person or
a thing that invokes the functionality of a system. It may be a system or a private entity, such that
it requires an entity to be pertinent to the functionalities of the system to which it is going to
interact.

Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.

Following are some rules that must be followed while drawing a use case diagram:

1. A pertinent and meaningful name should be assigned to the actor or a use case of a
system.
2. The communication of an actor with a use case must be defined in an understandable
way.
3. Specified notations to be used as and when required.
4. The most significant interactions should be represented among the multiple no of
interactions between the use case and actors.

23
Example of a Use Case Diagram

A use case diagram depicting the Online Shopping website is given below.

Here the Web Customer actor makes use of any online shopping website to purchase online. The
top-level uses are as follows; View Items, Make Purchase, Checkout, Client Register. The View
Items use case is utilized by the customer who searches and view products. The Client
Register use case allows the customer to register itself with the website for availing gift
vouchers, coupons, or getting a private sale invitation. It is to be noted that the Checkout is an
included use case, which is part of Making Purchase, and it is not available by itself.

4.8. Interaction Diagram

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.
4.8.1. Know the purposes of Interaction Diagram
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 behaviour 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.

24
4.8.2. List the types of interaction diagrams

This interactive behavior is represented in UML by two diagrams

knownas Sequence diagram and Collaboration diagram. The basic
purpose of both the diagrams are similar.

4.8.3. Learn to draw the Interaction Diagrams

The Sequence Diagram

The sequence diagram has four objects (Customer, Order, Special Order and Normal Order).
The following diagram shows the message sequence for Special Order object and the same can
be used in case of Normal Order 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 Special Order 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.

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

26