Software Design

Requirements Analysis and Design

• Requirement Analysis produces a specification of what

a system should do.
• Design phase refines the findings from the analysis to
give a clear picture of how the solution has to be
implemented.
 What is Software design?

It is a process to transform user requirements into some

suitable form, which helps the programmer in software
coding and implementation.
Design
• The design of a system is essentially a blueprint or a
plan for a solution for the system
• The details of how the actual software implementation
will be done are specified.
• The output of this phase is the design documents
specifying
– The complete software architecture,
– Data design,
– Procedural detail
– and interface design
Broadly the design process for software systems often
has two levels
• At the first level the focus is on deciding on
– what modules are needed for the system
– The specifications of these modules
– How these modules will be interconnected.
This is called system design or top-level design.
• In the second level the internal design of the
modules is decided. This is called detailed design or
logic design.
Design technique can be

– Object – oriented
– Function – oriented/ Structured Design
 Function – oriented Design
The design consists of
• Module definitions with each module supporting a functional
abstraction
• The system is viewed as a transformation function,
transforming the inputs to the desired output.
• The output from the design phase following function-oriented
approach are
– The definition of all the major data structures in the system
– All the modules of the system
– How the modules interact with each other
Concept of a module –
A module is a software component with parts, at any
level of abstraction.
At the highest level of abstraction, an entire system is a
module whose immediate parts are the sub-systems
of which it is composed. In other words, a system is a
module whose parts are its architectural components.
 Modularization
Modularization is the process of dividing a software
system into multiple independent modules where each
module works independently.
 Modularity
A system is modular if it is composed of well-defined,
conceptually simple and independent units interacting
through well-defined interfaces.
Advantages of a Modular System
– are easier to understand
– Are easier to document
– Programming individual modules are easier because the programmer
can focus on just one small , simple problem rather than a large
complex problem.
– Testing and debugging becomes easier
– Modules can be reusable
– Changes to the system can be made easily
 Module Coupling
• Coupling is a measure of degree of independence
between modules.
• When the interaction between two modules is too
little, the modules are described as loosely coupled
modules
• When there is a high degree of interaction the
modules are described as tightly coupled modules
• Good design requirement –
– Modules should loosely coupled. i.e. should kept as
independent as possible.
As coupling increases as the number of calls
between modules increase or the amount of shared
data is large. Thus, it can be said that a design with
high coupling will have more errors.
 Types of Module Coupling

• Data Coupling
• Stamp Coupling
• Control Coupling
• External Coupling
• Common Coupling
• Content Coupling
Data Coupling

– If the dependency between the modules is based on the

fact that they communicate by passing only data, then
the modules are said to be data coupled.
– Occurs when module passes non-global variable to
another module.
– Modules are independent of each other.
– Can only communicated through passing data elements
or informational flags.
Stamp Coupling
• Occurs when module passes non-global data
structure or entire structure to another module.
• Here, modules are more dependent on each other.
• Exposes modules to more data than they need.
• A change in data structure will affect all modules
that use it.
Control Coupling

• Occurs when module passes control flags or

switches to another modules.
• The sending module must know a great deal of
about the inner workings of the receiving module.
External Coupling

• In external coupling, the modules depend on other

modules, external to the software being
developed or to a particular type of hardware.
Ex- protocol, external file, device format, etc.
Common Coupling
• Occurs when modules refer to the same global data
area or data structure
• Modules that use the same area have quite high level of
interdependence.
• This is undesirable as errors can spread throughout the
system.
Content Coupling
• Occurs when one module directly refer to the inner
workings of another module.
• Modules are highly interdependent to each other.
• One module can alter data in other module or change a
statement coded in other module.
 Module Cohesion
• Cohesion is the measure of strength of the association
of elements within a module
• In other words, the extent to which all instructions in a
module relate to a single function.
• In a truly cohesive module, all of the instructions in the
module pertain to performing a single task.
• Cohesion in modules should me maximized.
 Types of Module Cohesion

• Functional Cohesion
• Sequential Cohesion
• Communicational Cohesion
• Procedural Cohesion
• Temporal Cohesion
• Logical Cohesion
• Coincidental Cohesion
Functional Cohesion
• The name of the module will indicate its function
• All statements within a module are based on one function.
• It is the best cohesion
Ex- CALCULATE_SALES_TAX
IF PRODUCT IS SALES_TAX EXEMPT THEN
SALES_TAX = 0
ELSE
IF PRODUCT_PRICE <100 THEN
SALES_TAX = PRODUCT_PRICE * 0.25
ELSE
SALES_TAX = PRODUCT_PRICE * 0.35
ENDIF
ENDIF
Sequential Cohesion
• The instructions inside a module are related to each other
thorough the input data.
• The output from first instruction becomes input to the
second and so on.
• Sequence of events is very important.
Ex – TOTAL_PURCHASES =0
READ NO_OF_PURCHASES
DO LOOP_INDEX = 1 TO NO_OF_PURCHASES
GET PURCHASES
ADD PURCHASES TO TOTAL_PURCHASES
ENDDO
SALES_TAX = TOTAL_PURCHASES * SALES_TAX_PERCENTAGES
AMT_DUE = TOTAL_PURCHASES + SALES_TAX
END
Communicational Cohesion
• The activities are related to each other by the data that the modules
uses.
• Sequence is not important

Ex- VALIDATE_PRODUCT_REC
IF TRANS_TYPE NOT = ‘0’ THEN
WRITE _ERR_REPORT
ENDIF
IF CUST_NO NOT NUMERIC THEN
WRITE_ERR_REPORT
ENDIF
IF PRODUCT_NO = BLANKS
WRITE_ERR_REPORT
ENDIF
END
Procedural Cohesion

• The instructions in a module are related with each other through

flow of control
• The instructions are grouped together because of a particular
procedural order.
• Sequence is important.
Ex-
Calculate student GPA, Print student record, Calculate cumulative GPA, Print
cumulative GPA.
Temporal Cohesion
• The instructions in a module are related to each other through
the flow of control.
• The instructions are grouped together because they occur at
about the same point in time.
• These instructions perform more than one function.
Ex – INITIALIZATION
OPEN TRANS_FILE
ISSUE PROMPT ‘ENTER DATE – DDMMYY’
READ TODAYS_DATE
SET TRANS_COUNT TO 0
SET REPORT_TOTAL TO 0
OPEN REPORT_FILE
END
Logical Cohesion

• The instructions are hardly related to each other at all

• The instructions are grouped together due to certain classes or activities.

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
• The instructions have no relationship to each other at all, it
is just a coincidence they fall in the same module.
• It is the worst type of cohesion.
Ex- FILE PROCESSING
OPEN EMPLOYEE_UPDATE FILE
READ EMPLOYEE REC
PRINT_PAGE_HEADING
OPEN MASTER FILE(EMPLOYEE)
SET PAGE_COUNT TO 1
SET ERR_FLAG TO FLASE
END
 Coupling & Cohesion
Cohesion Coupling
Cohesion is the concept of intra Coupling is the concept of inter
module. module.
Cohesion represents the relationship Coupling represents the relationships
within module. between modules.
Increasing in cohesion is good for Increasing in coupling is avoided for
software. software.
Cohesion represents the functional Coupling represents the
strength of modules independence among modules.
Highly cohesive gives the best Loosely coupling gives the best
software. software.
Structure Charts
• For a function-oriented design, the design can be represented
graphically by structure charts.
• Structure Chart represent hierarchical structure of modules.
• It breaks down the entire system into lowest functional modules,
describe functions and sub-functions of each module of a
system to a greater detail.

• An arrow from module A to module B indicates module A invokes

module B.
• B is called subordinate to A and A is called superordinate of B
• The arrow is labeled by the parameters received by B as input and
parameters returned by B as output. These are represented by
small arrows with a small circle at the tail of the arrow. (Unfilled
circle represents data and filled circle represents control)
 Symbols used in construction of Structure Charts
Module - It represents process or subroutine or task. A control module branches to
more than one sub-module. Library Modules are re-usable and invokable from any
module.
In a structure chart a module is represented by a box, with the module name in
the box.
Control Module

Sub Module Library Module

 Symbols used in construction of Structure Charts

• An arrow from module A to module B indicates module A invokes

module B.
• B is called subordinate to A and A is called superordinate of B
• The arrow is labeled by the parameters received by B as input and
parameters returned by B as output. These are represented by small
arrows with a small circle at the tail of the arrow. (Unfilled circle
represents data and filled circle represents control)
Example -

Main

sum
a, n a, n a
a,n

readnum sort Add_n

Note Represents Control transfer

 A
A

B C D B C D

A repeatedly calls module C & D Invocation of C & D depends upon

some decision on A
 Some other Design Notations

• Flow Charts & its notations

• Pseudo Code
 Flow Charts

Flowchart is a graphical representation of an algorithm.

In flowchart, the steps in the algorithm are represented in
the form of different shapes of boxes and the logical flow
is indicated by interconnecting arrows.
 Flow Chart Symbols
Terminal: The oval symbol indicates Start, Stop Terminal is the
first and last symbols in the flowchart.

Input/Output: A parallelogram denotes any function of

input/output type. Program instructions that take input from input
devices and display output on output devices are indicated with
parallelogram in a flowchart.

Processing: A box represents arithmetic instructions. All

arithmetic processes such as adding, subtracting, multiplication
and division are indicated by action or process symbol.
 Flow Chart Symbols
Decision Diamond symbol represents a decision point.
Decision based operations such as yes/no question or true/false
are indicated by diamond in flowchart.
Connectors: Whenever flowchart becomes complex or it spreads
over more than one page, it is useful to use connectors to avoid
any confusions. It is represented by a circle.

Flow lines: Flow lines indicate the exact sequence in which instructions
are executed. Arrows represent the direction of flow of control and
relationship among different symbols of flowchart
 Flow Chart Example
Draw a flow chart to test
Start
whether a person is
eligible for voting or not.
Enter Age

Is Age Eligible
Eligible >= 18

Start
 Pseudo Code
• A pseudo code is a technique for structured program design that uses
English like statements to outline the logic of a program.
• An alternative to flowchart is pseudo code.
• This structured technique uses English like statements in place of the
flowchart's graphic symbols.
• Pseudo code looks more like a program than a flowchart
• it's often easier to code a program from pseudo code than from a
flowchart,
• unlike a flowchart, pseudo code is relatively easy to modify and can be
embedded into the program as comments.
 Example Pseudo Code

Input Age of the person

If Age is greater than or equal to 18
Then
display “ Eligible for voting
Else
Display “Not Eligible for voting”
End If
 Example Pseudo Code

If student's grade is greater than or equal to 60

Print “Passed"
else
Print “Failed"
End if
 Some Keywords That Should be Used

looping and selection - Do While...EndDo; Do

Until...Enddo; Case...EndCase; If...Endif; Call ... with
(parameters); Call; Return ....; Return; When;
Words such as - set, reset, increment, compute,
calculate, add, sum, multiply, ... print, display, input,
output, edit, test , etc

Note - Do not include data declarations in your

pseudo code.
Software Design Strategies

There are mainly two strategies used

• Top-Down design
• Bottom-Up design
Top-down Design
• A top-down approach starts by identifying the major
components of the system, decomposing them into their
lower-level components and iterating until the desired level of
detail is achieved.
• It is a step wise refinement method.
• Starting from an abstract design, in each step the design is
refined to a more concrete level, until we reach a level where
no more refinement is needed.
• Suitable only if the requirements are clearly known and the
system development is from the scratch.
• It is a reasonable approach if a waterfall type of process
model is being used.
Bottom-up Design
• A bottom-up approach starts with the lowest level component of
the hierarchy and proceeds through progressively higher levels
to the top level component.
• Starts with the most basic or primitive components and
proceeds to higher level components that uses these lower level
components.
• If a system is to be built from an existing system , a bottom-up
approach is more suitable, as it starts with some existing
components.
• If an iterative enhancement type of process is being followed, in later
iterations, the bottom-up approach could be more suitable.
• Object-oriented languages such as C++ or JAVA use bottom-up
approach where each object is identified first.
 Difference Between Structured Design &
Object-Oriented Design

Structured Approach Object Oriented Approach

It works with Top-down approach. It works with Bottom-up approach.
Program is divided into number of Program is organized by having number of
submodules or functions. classes and objects

Function call is used. Message passing is used.

DFD & E-R diagram model the data. Class diagram, sequence diagram, state
chart diagram, and use cases all
contribute.
 Class Diagram

• Class diagrams are a type of UML (Unified Modeling Language)

diagram used in software engineering to visually represent the
structure and relationships of classes within a system.
• They are a fundamental tool in object-oriented design and play a
crucial role in the software development lifecycle.
 What is a class?
• In object-oriented programming (OOP), a class is a blueprint
or template for creating objects.
• Objects are instances of classes, and each class defines a
set of attributes (data members) and methods (functions or
procedures) that the objects created from that class will
possess.
• The attributes represent the characteristics or properties of
the object, while the methods define the behaviors or
actions that the object can perform.
UML Class Notation
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:

+ for public (visible to all classes)

- for private (visible only within the class)
# for protected (visible to subclasses)
~ for package or default visibility (visible to classes in the same package)
 Relationships between classes

In class diagrams, relationships between classes describe how classes

are connected or interact with each other within a system.
Simple Association:
If two classes in a model need to communicate with each other, there must be a link between
them.
This link can be represented by an association.
Associations can be represented in a class diagram by a line between these classes with an
arrow indicating the navigation direction.

Class A Class B
Association Example
• Inheritance (or Generalization):
– Represents an "is-a"
relationship.
– An abstract class name is
shown in italics.
– SubClass1 and SubClass2 are
specializations of Super Class.
– A solid line with a hollow
arrowhead that point from the
child to the parent class
Generalization(Inheritance)
• Aggregation:

• 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.
• A solid line with an unfilled
diamond at the association end
connected to the class of composite

The aggregate is the parent class,

the components are the children
classes
Composition

Composition is a stronger form of aggregation.

In composition, the part class cannot exist independently of the whole class.
Composition is represented by a filled diamond shape on the side of the whole
class.
 Composition Example

Imagine a digital contact book

application. The contact book is
the whole, and each contact
entry is a part. Each contact entry
is fully owned and managed by the
contact book. If the contact book is
deleted or destroyed, all associated
contact entries are also removed.
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
 Dependency Example
Let’s consider a scenario where a
Person depends on a Book.
•Person Class: Represents an
individual who reads a book. The
Person class depends on the Book
class to access and read the content.

•Book Class: Represents a book that

contains content to be read by a
person. The Book class is
independent and can exist without the
Person class.
Class Diagram ATM
 Sequence Diagram

• The sequence diagram represents the flow of messages in the

system and is also termed as an event diagram.
• It portrays the communication between any two
lifelines as a time-ordered sequence of events, such
that these lifelines took part at the run time.
 Notations of a Sequence Diagram

• Lifeline - An individual participant in

the sequence diagram is represented
by a lifeline. It is positioned at the top
of the diagram.
• Activation
It is represented by a thin rectangle on the
lifeline. It describes that time period in
which an operation is performed by an
element, such that the top and the
bottom of the rectangle is associated
with the initiation and the completion
time, each respectively.
• Messages
The messages depict the interaction between the objects
and are represented by arrows. They are in the sequential
order on the lifeline. The core of the sequence diagram is
formed by messages and lifelines.
Call Message: It defines a particular communication between the lifelines of an
interaction, which represents that the target lifeline has invoked an operation.
Return Message: It defines a particular communication between
the lifelines of interaction that represent the flow of information from
the receiver of the corresponding caller message.
Self Message: It describes a communication, particularly between the lifelines
of an interaction that represents a message of the same lifeline, has been
invoked.
• Destroy Message: It describes a communication, particularly
between the lifelines of an interaction that depicts a request to
destroy the lifecycle of the target.
 Design of Output
• Output from an system should accomplish one or more of the
following objectives
Convey information about past activities, current status, or
projections of the future
Signal important events, problems, or warnings
Trigger an action
Confirm an action
• System Output may be
A report
A document
A message
 Design of Output Cont..
5 Key output questions
1. Who will receive the output?
– Is the user inside or outside the organization? External users may
have specific requirements governing content, format, media.
2. What is its planned use?
– Uses determines content, form and media.
3. How much detail is needed?
4. When and how often is the output needed?
5. By what method? Should the output be displayed or printed?
 How to represent Information
• Tabular Format
• Graphic Format
 Pi-chart
 Line Chart
 Histograms
 Curves etc.
• Using Icons
 Designing Printed Output
The output layout should show the location and
position of the following
• All variable information
 Item details
 Summaries and Total
 Control breaks
 Separators (e.g. underline and the dash)
• All preprinted details
 Headings
 Document names and titles
 Corporate names and Address
 Instructions
 Notes and Comments
Type of Data Symbol Explanation
Numeric 9 Numeric Digit
Alphabetic A Alphabetic Character
Alphanumeric X Alphanumeric Character
Simple Insertion , Comma
/ Slash
B Blank Space
- Minus Sign
. Decimal Point
+ Plus Sign
CR Credit Symbol
DB Debit Symbol

$ Dollar Sign
 INVENTORY REPORT DATE : DD/MM/YYYY

ITEM DESCRIPTION UNIT ON HAND PRICE TOTAL

NUMBER

99999999 XXXXXXXXXXXXX XXXX 999999 99999999.99 9999999.99

99999999 XXXXXXXXXXXXX XXXX 999999 99999999.99 9999999.99
99999999 XXXXXXXXXXXXX XXXX 999999 99999999.99 9999999.99

Total 9999999999.99
User Interface Design
 User Interface

• User interface refers to the methods and devices that are

used to accommodate interaction between machines and
the user. It performs two tasks
 Communicating information from the machine to the user
 Communicating information from the user to the machine.
Why be concerned about INPUT DESIGN?

Garbage In - Garbage Out (GIGO)

 Data Capture Guideline
Capture
variable data: data items that change for each transaction
(customer name)
identification data: key (product code)
DO NOT capture
constant data: data that is the same for each entry
details that the system can retrieve: (product name)
details that the system can calculate: (total cost)
 Retrieved from System
Provided By Operator

Date : 02/09/09

Quantity Item Description Unit Cost Total Cost

Calculated
By System
10 11 Chocolate 20
200

Item Total 200

Sales Tax 20

Grand Total
220

Retrieved Tax Rate from System

 Qualities of Good UID
• Simplicity
– Should simple
– Minimize the number of mouse clicks or keystrokes required to
accomplish a particular task.
• Consistency
– Inconsistency will make it more difficult to use.
– Ex – should apply typeface, size, style in a consistent manner to all
the components of the interface.
• Intuitiveness
– Easy to learn and use.
– Icons should be concise and cogent(convincing).
 Qualities of Good UID Cont..
• Prevention
– A useful interface should prevent users from performing an
inappropriate task.
– This is possible by disabling some parts, limiting data entry in
text boxes etc.
• Graphic Interface Design
• Aesthetics
– Should be an attractive user interface
– Users will be happier and therefore
 Graphical User Interface Design
• Elements of GUI Design
 Windows
 Events
 Pull-down Menus/Drop-down Menus
 Push Buttons
 Icons
 Checkboxes
 Radio Buttons
 Scrolling Lists
 Text Fields
 Popup List
 Popup Menu
 Spin Boxes
 Sliders
 Combo Boxes
 Color Effect
Guidelines for the design of color user interfaces

• Should always use for Graphical Interface

• Experts recommend avoiding red and blue to display text.
• Light blue on a white background is hard to read,
especially for small objects or thin lines. Thus important
thing should not shown by using light blue.
• High contrast colors create eye pain & headache. So
avoid them.
 Form Design

• make forms easy to fill out: to reduce errors, speed

completion, facilitate data entry
form flow : (top to bottom, left to right)
form sections : logical grouping of info
form captions : Captions tell the person completing the
form what to put on a blank line, space, or box.

• ensure that forms meet the intended purpose: effectiveness

(specialty forms)
 Form Design

• Make Information Visible

 Provide the information users need when they need it
 Suggest formats with examples
 Provide immediate feedback
• Keep forms attractive: uncluttered, enough space to fill,
fonts and line weights to separate categories
• Ask each item of data only once
Data Entry Form/Window With Navigation Choices

Option (Radio) Buttons (choose one) Command Buttons

Spinner

Window
That’s all folks!