Unit 3

What is software design

Software Design is the process of transforming user requirements

into a suitable form, which helps the programmer in software coding
and implementation. During the software design phase, the design
document is produced, based on the customer requirements as
documented in the SRS document.

Objectives of Software Design

1. Correctness: A good design should be correct i.e., it should

correctly implement all the functionalities of the system.

2. Efficiency: A good software design should address the

resources, time, and cost optimization issues.

4. Flexibility: A good software design should have the ability to

adapt and accommodate changes easily. It includes designing the
software in a way, that allows for modifications, enhancements,
and scalability without requiring significant rework .

5. Understandability: A good design should be easily

understandable, it should be modular, and all the modules are
arranged in layers.

5. Completeness: The design should have all the components like

data structures, modules, external interfaces, etc.

6. Maintainability: A good software design aims to create a

system that is easy to understand, modify, and maintain over time.
Maintainability in Software and design also enables developers to
fix bugs, enhance features, and adapt the software to changing
requirements without excessive effort or introducing new issues.
Software Design Concepts

Points to be Considered While Designing Software

1. Abstraction (Hide Irrelevant data): Abstraction simply

means to hide background details or unnecessary implementation
abaout data.
Users can see only required information.
Example:- Car
Required information --- Turn_on, Turn_off, break.
Unnecessary details--- set_speed,

3. Modularity (subdivide the system): Modularity simply means

dividing the system or project into smaller parts to reduce the
complexity of the system or project.
After developing modules, they are integrated together to meet the
software requirements.
Modularising a desing helps o effective development ,
accommodate changes easily, conduct testing, dubbuging,
maintenance work easily.
Example: college management system application.
 Faculty Module: set attendance , set marks
Student module: get marks, get question papers

4. Architecture (design a structure of something): Architecture

simply means a technique to design a structure of something.
These components interact with each other in a specialized way.

Structural Properties: Architecture design represents different

types of component, modules, object, relationship between these.

Extra- Functional properties:- how design architecture fulfil

requiremnets like performance, capacity, reliability, secuirity,
adoptability.

Families of related System: They have ability to reuse repeatable

block.

4. Refinement (removes impurities): Refinement simply means

to refine something to remove anyS impurities if present and
increase the quality. The refinement concept of software design is
a process of developing or presenting the software or system in a
detailed manner which means elaborating a system or software.
Refinement is very necessary to find out any error if present and
then to reduce it.
Example: Addition module :- compile and run code(program
execution is in stepwise manner)

6. Design Pattern (a Repeated form): A pattern simply means a

repeated form or design in which the same shape is repeated
several times to form a pattern.

Example:- Shape

Draw()

Circle Square

Draw() Draw()
7. Information Hiding (Hide the Information): In software
design, information hiding is achieved by designing the modules
in a manner that the information gathered or contained in one
module is hidden and can’t be accessed by any other modules.
Only show the required information and hide the hiding
unnecessarily details in a module.
Example :- sign up and login page

7. Refactoring (Reconstruct something): Refactoring simply

means reconstructing something in such a way that it does not
affect the behaviour of any other features.

If we want to remove redundancy, unused design elements,

unnecessarily design algorithm inappropriate data structure or any
other design failure that can be corrected for better design.

Refactoring is the process of of changing a software system in a

way that it does not change the external behaviour of the code
still improves its internal structure”.

Different levels of Software Design

The design phase of software development deals with

transforming the customer requirements as described in the SRS
documents into a form implementable using a programming
language. The software design process can be divided into the
following three levels or phases of design:

1. Architectural Design: The architecture of a system can be

viewed as the overall structure of the system and the way in which
structure provides conceptual integrity of the system. The
architectural design identifies the software as a system with many
 components interacting with each other. At this level, the
designers get the idea of the proposed solution domain.

2. Preliminary or high-level design: Here the problem is

decomposed into a set of modules, the control relationship among
various modules identified, and also the interfaces among various
modules are identified. The outcome of this stage is called the
program architecture. Design representation techniques used in
this stage are structure chart and UML.

3. Detailed design: Once the high-level design is complete, a

detailed design is undertaken. In detailed design, each module is
examined carefully to design the data structure and algorithms.
The stage outcome is documented in the form of a module
specification document.

What is Coupling and Cohesion?

Coupling:-
Coupling refers to the degree of interdependence between software
modules.
We represents coupling in top level design and it describe the inter-
dependencies and interaction between the module of a software.
Coupling should be low for better software design.
High coupling means that modules are closely connected and changes
in one module may affect other modules. Low coupling means that
modules are independent, and changes in one module have little
impact on other modules.
The various types of coupling techniques are shown in fig:
Types of Coupling

No direct coupling : there is no direct coupling between M1 & M2

Data Coupling: If the dependency between the modules is based on

the fact that they communicate by passing only data,(argument list)
then the modules are said to be data coupled.

Module 1
Data
(argument list) coupling

Module 2
Stamp Coupling: two modules are stamp coupled if they
communicate using composite data items such as complete data
structure , algorithm & objects.
No unused or junk data shared between two coupling modules.
Module 1
Stamp
coupling
(data structure)

Module 2

Control Coupling: If the modules communicate by passing control

information, then they are said to be control coupled. Control
coupling handle functional flow between software modules.
Ex. Module 1 (set flag = 1) then only module 2 perform action.
External Coupling: In external coupling, when two or more module
in project access same type of external tools and devices.
Ex. They use same type of external library file, import file,
communication protocol or device interface
Common Coupling: The modules have shared data such as global
data structures. Two modules are common coupled if they share
information through some global data items.

Module 1 Module 1

Global
data

Content Coupling: In a content coupling, two module are connected

as they share the same content like functions, methods.
When a change in one module can modify the data of another module,
or control flow is passed from one module to the other module. This
is the worst form of coupling and should be avoided.

Cohesion :
Cohesion represents detail design and it describe how the elements in
a particular module are closely related to each other and it should be
high for better software design.

Types of Cohesion
Functional Cohesion: if a single module aims to perform all the
similar types of functionalities through its different elements.
Ex. Hotel booking
Sequential Cohesion: Output of one element treats as an input to the
other elements inside the same module.
Ex. Enter the number --> perform addition of that numbers--> display
addition.
Communicational Cohesion: if all the elements of module are
working on the same input and output data and are accesing that data
through same data structure.
Example- update record in the database and send it to the printer.
Procedural Cohesion: Elements of procedural cohesion ensure the
order of execution. All parts of a procedure execute in a particular
sequence of steps for achieve a goal. Procedural cohesion can be
found in structured programming languages.
Ex. Loop statements.
Logical Cohesion: If all the elements of module perform similar
operation. The elements are logically related.
Ex- A component reads inputs from tape, disk, and network. All the
code for these functions is in the same component. Operations are
related, but the functions are significantly different.
Coincidental Cohesion: it perform a set of task that are associated
with each other very loosely.The elements are not related(unrelated).
The elements have no conceptual relationship other than location in
source code.
Ex- calculator : ADD, SUB, MUL, DIV.
 Temporal Cohesion: the activities related in time, where all methods
executed at same time.temporal cohesion is found in the modules of
initialization and termination.
Ex. Counter=0

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module

Cohesion is also called Intra-Module Binding.
Binding.

Coupling shows the relationships between Cohesion shows the relationship within the

modules. module.

Coupling shows the Cohesion shows the module's

relative independence between the modules. relative functional strength.

While creating you should aim for high

While creating, you should aim for low
cohesion, i.e., is associated with several
coupling, i.e., dependency among modules
desirable software traits including robustness,
should be less.
reliability, reusability, and understandability.

In coupling, modules are linked to the other In cohesion, the module focuses on a single

modules. thing.
 Function Oriented design
 System is divided into subsystem where each subsystem has
clearly defined functions.
 It focus on what system can do.
 Every system is associated with some actions.
 ATM Machine Sytem.

System

Subsystem1 Subsystem2
Function() Function()

Subsystem3 Subsystem4 Subsystem5 Subsystem6

Function() Function() Function() Function()

Function Oriented Design Strategies:-

1. Data Flow Diagram
2. Data Dictionary
3. Structure Chart
4. Pseudo Code
1. Data Flow Diagram
 DFD stands for data flow diagram. It is also known as “Bubble Chart”
through which we can represent the flow of data graphically in an
information system.
 By using DFD we can easily understand the overall functionality of
system because diagram represents the incoming data flow, outgoing data
flow and stored data in a graphical form.
 It describe how data is processed in a system in term of input and output.
 DFD models uses a notations and Symbol to represent flow of data are as
follows

Symbol Name Function

Connect process
Data Flow

Process Perform some

transformation of its
input data to yield output
data.
Source or sink A source of system inputs
or sink of system outputs

Data Store A repository of data, the

arrowhead indicate net
input and net outputs to
store
Rules of DFD

1. Each process should have at least one input and one output

Ex.

Input Process output

2. Each data store should have at least one data flow in and one data
flow out.

Ex.
In Out

3. All process in DFD go to either another process or data store

Ex.

Proc Proc
ess 1 ess 2

Data store

4. All the external entities must

be connected through a process and entity can provide something to the software as
well as the entity can consume some data from the software.

entity Input Proc

ess 1

Output
 Levels of DFD

1. level 0 DFD
It is a diagram which provides the entire sytem data flows and processing with a single
process (bubble) is also called as context.

Ex. Input
entity

Proc
output
ess 1
entity input

2. level 1 DFD
this is more detailed version of the previous level that includes the database and various
important unit.

Ex. Input
entity

Proc
ess 1
output
Proc
ess 2
Data store

Example:- Create a DFD for Library Management System

1. 0th level DFD

REQUEST FOR BOOK Get Book

Name & Author Info

student LMS Librarian

Got Book Issued

 1. 1 st level DFD

student Book
Details

Book Not Available Librarian

Book Detail

Issued By Librarian

2. Data Dictionary

Data dictionary is a file or a set of files that includes a database's

metadata. The data dictionary hold records about other objects in the
database, such as data ownership, data relationships to other objects, and
other data. The data dictionary is an essential component of any
relational database. Ironically, because of its importance, it is invisible to
most database users. Typically, only database administrators interact
with the data dictionary.
The data dictionary, in general, includes information about the following:
1. Aliases: include other names by which this data item is called
DEO for Data Entry Operator and DR for Deputy Registrar.

2. Description/purpose :- is a textual description of what the data

item is used for or why it exists.
3. Related data items:- capture relationships between data items
e.g., total_marks must always equal to internal_marks plus
external_marks.
4. Range of values:- records all possible values, e.g. total marks
must be positive and between 0 to 100.
5. Data structure Forms:- Data flows capture the name of
processes that generate or receive the data items. If the data item
is primitive, then data structure form captures the physical
structures of the data item. If the data is itself a data aggregate,
then data structure form capture the composition of the data
items in terms of other data items.

The mathematical operators used within the data dictionary are

defined in the table:

Notation Meaning
x= a+b x consists of data element a & b
x={a/b} x consists of either a or b
x=(a) x consists of an optional data element a
x= y{a} x consists of y or more occurrences
x={a}z x consists of z or fewer occurrences of a
x=y{a}z x consists of between y & z occurrences of a{
 3. What is a Structure Chart?

Structure Chart partitions the system into black boxes (functionality

of the system is known to the users, but inner details are unknown).
Structure Chart represents the hierarchical structure of modules. It
breaks down the entire system into the lowest functional modules
They are used in structure programming to arrange modules into a
tree.
Each module is represented by a box, which contains the modules
name.
The tree structure visualizes the relationships between modules.
Modules at the top level are called modules at low level.
Components are read from top to bottom and left to right.
When a module calls another, it views the called module as a black
box, passing the required parameters and receiving results.

Symbols in Structured Chart

1. Module

It represents the process or task of the system. It is of three types:

 Control Module: A control module branches to more than one
submodule.
 Sub Module: Sub Module is a module which is the part (Child)
of another module.
 Library Module: Library Module are reusable and invokable
from any module.
2. Conditional Call

It represents that control module can select any of the sub module on
the basis of some

condition.

3. Loop (Repetitive call of module)

It represents the repetitive execution of module by the sub module. A

curved arrow represents a loop in the
module.
All the submodules cover by the loop repeat execution of module.

4. Data Flow

It represents the flow of data between the modules. It is represented

by a directed arrow with an empty circle at the

end.

5. Control Flow

It represents the flow of control between the modules. It is

represented by a directed arrow with a filled circle at the

end.
6. Physical Storage

It is that where all the information are to be

stored.

Example
Structure chart for an Email server
5. Pseudo Code
A Pseudocode is defined as a step-by-step description of an algorithm.
Pseudocode does not use any programming language in its
representation instead it uses the simple English language text as it is
intended for human understanding rather than machine reading.
Pseudocode is an intermediate state between algorithm and program

Reserved commands or keywords must be represented in capital

letters. Example: if you are writing IF…ELSE statements then make
sure IF and ELSE be in capital letters.
Don’t write the pseudocode in a programming language. It is
necessary that the pseudocode is simple and easy to understand
What is UML
 It is an Unified Modelling Language.
 An industry - standards graphical language for specifying ,
visualizing, constructing and documenting the software system.
 The UML uses mostly graphical notations to express the OO
analysis and design of software projects.

Why UML use for Modelling?

 Uses graphical notation to communicate more clearly than natural
language and code.
 Makes it easier for programmers and software architects to
communicate.
 It helps to understand overall view of a system.
 UML Is not Dependant on any one technology or language.
Types of UML Diagrams.
1. Use Case Diagram
2. Class Diagram
3. Interaction Diagram
4. Activity Diagram
5. State Chart Diagram
6. Package Diagram
7. Component Diagram
8. Deployment Diagram
1. Use Case Diagram

Use Case Diagram Notations

1. Actors
Actors are external entities that interact with the system. These can
include users, other systems, or hardware devices. In the context of a
Use Case Diagram, actors initiate use cases and receive the outcomes.
Proper identification and understanding of actors are crucial for
accurately modeling system behavior.

2. Use Cases
A set of scenarios that describe an interaction between a user and
system. They represent specific things your system can do.
Each usecase has a description which describe the functionality that
will be built in a proposed system.
In the online shopping system, examples of use cases could be “Place
Order,” “Track Delivery,” or “Update Product Information”. Use
cases are represented by ovals.
3.System Boundary

 The system boundary is a visual representation of the scope or

limits of the system you are modeling.
 It defines what is inside the system and what is outside. The
boundary helps to establish a clear distinction between the
elements that are part of the system and those that are external to it.
 The system boundary is typically represented by a rectangular box
that surrounds all the use cases of the system.
 Scope Definition: It clearly outlines the boundaries of the system,
indicating which components are internal to the system and which
are external actors or entities interacting with the system

Relationships in Use Case Diagram

In a Use Case Diagram, relationships play a crucial role in depicting
the interactions between actors and use cases.

1. Association Relationship
The Association Relationship represents a communication or
interaction between an actor and a use case. It is depicted by a line
connecting the actor to the use case. This relationship signifies that
the actor is involved in the functionality described by the use case.

Example: Online Banking System

 Actor: Customer
 Use Case: Transfer Funds
 Association: A line connecting the “Customer” actor to the
“Transfer Funds” use case, indicating the customer’s involvement
in the funds transfer process.

2. Include Relationship(implicit function)

The Include Relationship indicates that a use case includes the

functionality of another use case. It is denoted by a dashed arrow
pointing from the including use case to the included use case.
Example: Social Media Posting
 Use Cases: Compose Post, Add Image
 Include Relationship: The “Compose Post” use case includes
the functionality of “Add Image.” Therefore, composing a post
includes the action of adding an image.

3. Extend Relationship(explicit function)

The Extend Relationship illustrates that a use case can be extended

by another use case under specific conditions. It is represented by a
dashed arrow with the keyword “extend.” This relationship is useful
for handling optional behavior.
Example: Flight Booking System
 Use Cases: Book Flight, Select Seat
 Extend Relationship: The “Select Seat” use case may extend
the “Book Flight” use case when the user wants to choose a
specific seat, but it is an optional step.
.4. Generalization Relationship

The Generalization Relationship establishes an “is-a” connection

between two use cases, indicating that one use case is a specialized
version of another. It is represented by an arrow pointing from the
specialized use case to the general use case.
Example: Vehicle Rental System
 Use Cases: Rent Car, Rent Bike
 Generalization Relationship: Both “Rent Car” and “Rent Bike”
are specialized versions of the general use case “Rent Vehicle.”
Example.
Use Case Diagram For online shopping application

Class diagram
Each class is represented by a rectangle subdivided into three
compartments.

UML Class Notation

class notation is a graphical representation used to depict classes and
their relationships in object-oriented modeling.

1. Class Name:
 The name of the class is typically written in the top
compartment of the class box and is centered and bold.

2. Attributes:
 Attributes, also known as properties or fields, represent
the data members of the class. They are listed in the second
compartment of the class box and often include the visibility (e.g.,
public, private) and the data type of each attribute.

3. Methods:
 Methods, also known as functions or operations, represent
the behavior or functionality of the class. They are listed in the
third compartment of the class box and include the visibility (e.g.,
public, private), return type, and parameters of each method.
4. Visibility Notation:
 Visibility notations indicate the access level of attributes
and methods. Common visibility notations include:
o + for public (visible to all classes)
o - for private (visible only within the class)
o

Relationships between classes

1. Simple Association:
 A structural link between two peer classes.
 There is an association between Class1 and Class2
 A solid line connecting two classes

2. Association

Values of association-
Exactly one 1
Zero or more 0...*
One or more 1...*
Zero or one 0...1
Specified range (any value) (2….4)
Multiple disjoint (2.4…..6,7)

Types of association

1Aggregation:

-
 A special type of association. It represents a "part of" relationship.
 Class2 is part of Class1.
 Many instances (denoted by the *) of Class2 can be associated
with Class1.
 Objects of Class1 and Class2 class 3 have separate lifetimes.
 A solid line with an hollow diamond at the association end
connected to the class of composite
engine

car

headlights

2.Composition:

A special type of aggregation where parts are destroyed when the

whole is destroyed.
 Objects of Class2 live and die with Class1.
 Class2 cannot stand by itself.
 A solid line with a filled diamond at the association connected
to the class of composite
Scroll bar

menubar
window

Title bar

3. Dependency:

 Exists between two classes if the changes to the definition of

one may cause changes to the other (but not the other way
around).
 Class1 depends on Class2
  A dashed line with an open arrow

4. Inheritance (or Generalization):

 inheritance represents an “is-a” relationship between classes,

where one class (the subclass or child) inherits the properties and
behaviors of another class (the superclass or parent).
 Inheritance is depicted by a solid line with a closed, hollow
arrowhead pointing from the subclass to the superclass.
 The Bank Account class serves as the generalized representation
of all types of bank accounts, while the subclasses (Current
Account, Savings Account, Credit Account) represent specialized
versions that inherit and extend the functionality of the base class.

Example:- class diagram for library management system.

What are Sequence Diagrams?
 Sequence diagrams are a type of UML (Unified Modeling
Language) diagram that visually represent the interactions between
objects or components in a system over time.
 They focus on the order and timing of messages or events
exchanged between different system elements.
 The diagram captures how objects communicate with each other
through a series of messages, providing a clear view of the
sequence of operations or processes.

Sequence Diagram Notations

1. Actors
An actor in a UML diagram represents a type of role where it
interacts with the system and its objects. It is important to note here
that an actor is always outside the scope of the system we aim to
model using the UML diagram.

2. Lifelines & Objects

Objects are shown as boxes at a top.
Object existance are shown as dashed lines(lifelines).
Object activation shown as a rectangle on lifeline.

3. Messages
Communication between objects is depicted using messages. The
messages appear in a sequential order on the lifeline.
 We represent messages using arrows.
Messages can be broadly classified into the following categories:

1. Synchronous messages

The sender waits until the receiver has completed the processing of
the message.
 We use a solid arrow head to represent a synchronous
message.

2. Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver.
The interaction moves forward irrespective of the receiver processing
the previous message or not. We use a lined arrow head to represent
an asynchronous message.
4.Activation Bar
It is used to indicate that an object is active (or instantiated) during an
interaction between two objects. The length of the rectangle indicates
the duration of the objects staying active.

5. Create message
We use a Create message to instantiate a new object in the sequence
diagram. There are situations when a particular message call requires
the creation of an object. It is represented with a dotted arrow and
create word labelled on it to specify that it is the create Message
symbol.

6. Self Message
Certain scenarios might arise where the object needs to send a
message to itself. Such messages are called Self Messages and are
represented with a U shaped arrow.
7. Reply Message
Reply messages are used to show the message being sent from the
receiver to the sender. We represent a return/reply message using
an open arrow head with a dotted line.
What is an Activity Diagram?
Activity diagrams show the steps involved in how a system works,
helping us understand the flow of control.
They display the order in which activities happen and whether they
occur one after the other (sequential) or at the same time (concurrent).
These diagrams help explain what triggers certain actions or events in
a system.
An activity diagram starts from an initial point and ends at a final
point, showing different decision paths along the way.

Activity Diagram Notations

1. Initial State
The starting state before an activity takes place is depicted using the
initial state.
We use a black filled circle to depict the initial state of a system.

2. Action or Activity State

An activity represents execution of an action on objects or by objects.
We represent an activity using a rectangle with rounded corners.
Basically any action or event that takes place is represented using an
activity.
3. Action Flow or Control flows
Action flows or Control flows are also referred to as paths and edges.
They are used to show the transition from one activity state to another
activity state.
We use a line with an arrow head to depict a Control Flow.

4. Decision node and Branching

When we need to make a decision before deciding the flow of control,
we use the decision node. The outgoing arrows from the decision
node can be labelled with conditions or guard expressions. It always
includes two or more output arrows.

6. Fork

Fork nodes are used to support concurrent activities. When we use a

fork node when both the activities get executed concurrently i.e. no
decision is made before splitting the activity into two parts. Both
parts need to be executed in case of a fork statement.

7. Join

Join nodes are used to support concurrent activities converging into

one. For join notations we have two or more incoming edges and one
outgoing edge.

8. Merge or Merge Event

Scenarios arise when activities which are not being executed

concurrently have to be merged. We use the merge notation for such
scenarios. We can merge two or more activities into one if the
control proceeds onto the next activity irrespective of the path
chosen.
9. Swimlanes

We use Swimlanes for grouping related activities in one column.

Swimlanes group related activities into one column or one row.
Swimlanes can be vertical and horizontal.

11. Final State or End State

The state which the system reaches when a particular process or

activity ends is known as a Final State or End State. We use a filled
circle within a circle notation to represent the final state in a state
machine diagram
State-Chart Diagrams.

A state diagram is a uml diagram which 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 Machine diagrams are also known as State Diagrams and State-
Machine Diagrams.

Basic components and notations of a State chart diagram

1. Initial state

We use a black filled circle represent the initial state of a System or a

Class.

2. Transition & Event

We use a solid arrow to represent the transition or change of control

from one state to another. The arrow is labelled with the event which
causes the change in state.
3. State

We use a rounded rectangle to represent a state. A state represents

the conditions or circumstances of an object of a class at an instant of
time.

5. Decision Box

When we need to make a decision before deciding the flow of control,

we use the decision node.

5. Self transition

We use a solid arrow pointing back to the state itself to represent a

self transition. There might be scenarios when the state of the object
does not change upon the occurrence of an event. We use self
transitions to represent such cases.

6. Final State

We use a filled circle within a circle notation to represent the final

state in a state machine diagram.
Example: