Software Design

Introduction

• Software design encompasses the set of principles, concepts, and

practices that lead to the development of a high-quality system or
product.
• The goal of design is to produce a model or representation that exhibits
firmness, commodity, and delight Software design changes continually
as new methods, better analysis.
• Input is SRS and output is SDD (Software design description/document)

SRS-> DESIGN -> SDD

• Interface design: Input ->Black box->Output
• Architectural Design –
• The architectural design is the highest abstract version of the system. It identifies
the software as a system with many components interacting with each other. At this
level, the designers get the idea of proposed solution domain.
• High-level Design –
• The high-level design breaks the ‘single entity multiple component’ concept of
architectural design into less-abstracted view of sub-systems and modules and
depicts their interaction with each other.
• High-level design focuses on how the system along with all of its components can
be implemented in the form of modules. It recognizes modular structure of each
sub-system and their relation and interaction among each other.
• Detailed Design/ Low level Design-
• Detailed design deals with the implementation part of what is seen as a system and
its sub-systems in the previous two designs. It is more detailed towards modules and
their implementations. It defines logical structure of each module and their
interfaces to communicate with other modules.
Modularization
• Modularization is a technique to divide a software system into multiple discrete
and independent modules, which are expected to be capable of carrying out task(s)
independently.
• These modules may work as basic constructs for the entire software. Designers
tend to design modules such that they can be executed and/or compiled separately
and independently.
• Advantage of modularization:
• Smaller components are easier to maintain
• Program can be divided based on functional aspects
• Desired level of abstraction can be brought in the program
• Components with high cohesion can be re-used again
• Concurrent execution can be made possible
• Desired from security aspect
Cohesion and Coupling

• When a software program is modularized, its tasks are divided into

several modules based on some characteristics.
• Modules are set of instructions put together in order to achieve some
tasks. They are though, considered as a single entity but, may refer to
each other to work together.
• There are measures by which the quality of a design of modules and
their interaction among them can be measured. These measures are
called cohesion and coupling .
Coupling
• Coupling is a measure that defines the level of inter-dependability among
modules of a program. It tells at what level the modules interfere and interact
with each other. The lower the coupling, the better the program.
Coupling
• There are Six levels of coupling, namely –
• Data coupling- Data coupling is when two modules interact with each
other by means of passing data (as parameter). If a module passes
data as parameter, then the receiving module should use all its
components, an integer, a float, a character, etc. This data item
should be problem related and not used for the control purpose.
• Stamp coupling- When multiple modules share common data
structure and work on different part of it, it is called stamp coupling.
• Control coupling- Two modules are called control-coupled if one of
them decides the function of the other module or changes its flow of
execution. An example of control coupling is a flag set in one module
and tested in another module.
• External Coupling: Two modules sharing the same resources
(externally).
• Common coupling- When multiple modules have read and write access
to some global data, it is called common or global coupling.
• Content coupling - When a module can directly access or modify or
refer to the content of another module, it is called content level
coupling. A branch from one module into another module.
Cohesion
• Cohesion is a measure that defines the degree of intra-dependability within
elements of a module. The greater the cohesion, the better is the program design.
• There are seven types of cohesion, namely –
• Co-incidental cohesion - It is unplanned and random cohesion, which
might be the result of breaking the program into smaller modules for the
sake of modularization. Because it is unplanned, it may serve confusion
to the programmers and is generally not-accepted.
• Example: For example, in a transaction processing system (TPS), the
get-input, print-error, and summarize-members functions are grouped
into one module. The grouping does not have any relevance to the
structure of the problem.
• Logical cohesion - When logically categorized elements are put together
into a module, it is called logical cohesion.
• An example of logical cohesion is the case where a set of print functions
generating different output reports are arranged into a single module.
• Temporal Cohesion - When elements of module are organized such
that they are processed at a similar point of time, it is called temporal
cohesion.
• The set of functions responsible for initialization, start-up, shutdown
of some process, etc. exhibit temporal cohesion.
• Procedural cohesion - When elements of module are grouped
together, which are executed sequentially in order to perform a task,
it is called procedural cohesion.
• E.g. the algorithm for decoding a message, an algorithm to read the
file and then open the file.
• Communicational cohesion - When elements of module are grouped
together, which are executed sequentially and work on same data
(information), it is called communicational cohesion.
• the set of functions defined on an array or a stack.
• Sequential cohesion - When elements of module are grouped because the
output of one element serves as input to another and so on, it is called
sequential cohesion.
• For example, in a TPS, the get-input, validate-input, sort-input functions are
grouped into one module.
• Functional cohesion - It is considered to be the highest degree of cohesion,
and it is highly expected. Elements of module in functional cohesion are
grouped because they all contribute to a single well-defined function. It can
also be reused.
• For example, a module containing all the functions required to manage
employees’ pay-roll exhibits functional cohesion.
Functional independence
• 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.
Need for functional independence
• Functional independence is a key to any good design due to the following
reasons:
• Error isolation: Functional independence reduces error propagation. The
reason behind this is that if a module is functionally independent, its
degree of interaction with the other modules is less. Therefore, any error
existing in a module would not directly effect the other modules.
• Scope of reuse: Reuse of a module becomes possible. Because each
module does some well-defined and precise function, and the interaction
of the module with the other modules is simple and minimal. Therefore, a
cohesive module can be easily taken out and reused in a different program.
• Understandability: Complexity of the design is reduced, because different
modules can be understood in isolation as modules are more or less
independent of each other.
Design Verification

• The output of software design process is design documentation,

pseudo codes, detailed logic diagrams, process diagrams, and
detailed description of all functional or non-functional requirements.
Design Approach
 Architectural Design: Data Flow Diagram (DFD)
• The DFD (also known as a bubble chart) is a graphical tool, useful for communicating with users,
managers, and other personnel.
• It is a hierarchical graphical model of a system that shows the different processing activities or
functions that the system performs and the data interchange among these functions.
DFD Elements:
• Source/ Sink (External entities/ user)
• Data flows
• Processes
• Data stores
Architectural Design: Data Flow Diagram (DFD)
Physical DFD Vs Logical DFD

Physical DFD for cheque encashment

Data Flow Diagram for Banking System
• Transaction Request/Loan Request –
In this customer provides the specific details to initiate or support a
transaction and the customer can apply for a loan through the system.
• Manager –
The manager can access and manage any request as well as input
commands to change or update Employee_Record Database. A Manager
manages the employees of the bank as well as either accepts or rejects any
Loan Request and hence inputs details to update the corresponding
databases as Customer_Record and Employee_Record Database.
• Cashier –
It responds actively to any Transaction Request and assists the Manager.
The cashier can also resolve any query from the Customer and provide
immediate help to the Customer. However, a Cashier can not access any
database independently.
• Bank_Headquarter –
It acts as an entity that controls all the branches of the Bank. The entity can
access all the databases, and it also controls the operations of the Manager. The
Bank can modify or eliminate any policies as well as create new policies for the
Online Banking System.
• Customer_Record –
It stores all the non-personal details of an individual who is a Customer of any
specific branch of the Bank. As an individual initiates a request to open an
account in the Bank, Customer_Records creates a new entry that is unique and
specific to the Customer only. This record is accessible by Managers or
Employees of the Banks as and when required.
• Employee_Record –
It stores the record of all the Employees at the Bank. The record can be accessed
but not modified by the Customer of the Bank. The record can be modified by
either the Manager of a Branch or by the Bank itself.
• Account_Details –
It stores the personal details of every individual Customer. It can be
accessed/modified by the Customer only. The Bank can not modify the personal
details of the Customer.
Level-0
Processes

•Account Management System –

• In this Customer can access all the services offered by the Bank by
adding his details.
• As the Customer avails any services as a transaction or a loan, then
the required data flows to Transaction Management System or the
Loan Management System respectively.
• Any Customer can print the activity status of the account which
fetches information from all the available databases using the
Generate Customer Report System.
•Transaction Management System –
• It helps the Customer to add/transfer money to another account.
• The Cashier may execute or help execute the transaction process on
behalf of the Bank where the Bank updates all the corresponding
details related to the Customer following a successful transaction.
•Loan Management System –
• It is used by the Customer to apply or request a Loan from the Bank.
• The Manager can access the Loan_Details database to either accept
or deny the request for the Loan. The Bank has the access to modify
the Loan Management System as the Bank can set or modify any
policies of the Loan offered by the Bank.
•Online Banking System –
• It provides other services like insurance, bill payments, etc.
Level-1
Level-2
Data flow diagram(DFD) for Online shopping website

• Context level DFD – 0 level

• The context level data flow diagram (dfd) is describe the whole
system. The (o) level dfd describe the all user module who operate
the system. Below data flow diagram of online shopping site shows
the two user can operate the system Admin and Member user.
Admin can first add
category of item and
then add items by
category wise. and admin
can manage order and
payment detail.
• User can first select product
for buy, user must have to
register in our system for
purchase any item from our
website. after register he can
login to site and buy item by
making online payment
through any bank debit card or
credit card.
User Interface Design
• User interface is the front-end application view to which user interacts in order to use
the software. The software becomes more popular if its user interface is:
• Attractive
• Simple to use
• Responsive in short time
• Clear to understand
• Consistent on all interface screens
There are two types of User Interface:
• Command Line Interface:
• Command Line Interface provides a command prompt, where the user types the
command and feeds to the system.
• Graphical User Interface:
• Graphical User Interface provides the simple interactive interface to interact with
the system. GUI can be a combination of both hardware and software. Using GUI,
user interprets the software.
Best Practices for Designing an Interface

• Keep the interface simple: The best interfaces are almost invisible to
the user. They avoid unnecessary elements and are clear in the
language they use on labels and in messaging.
• Create consistency and use common UI elements: By using common
elements in your UI, users feel more comfortable and are able to get
things done more quickly.
• Be purposeful in page layout: Careful placement of items can help
draw attention to the most important pieces of information and can
aid scanning and readability.
• Use typography to create hierarchy and clarity. Carefully consider
how you use typeface. Different sizes, fonts, and arrangement of the
text to help increase scalability, legibility and readability.
• Make sure that the system communicates what’s
happening. Always inform your users of location, actions, changes in
state, or errors.
• Think about the defaults. By carefully thinking about and anticipating
the goals people bring to your site, you can create defaults that
reduce the burden on the user.
• Strategically use color and texture: You can direct attention toward
or redirect attention away from items using color, light, contrast, and
texture to your advantage.
Golden rules
1. Place the user in control :
• Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions:
• The user should be able to easily enter and exit the mode with little or no effort.
2. Reduce the user’s memory load :
• When users are involved in some complex tasks the demand on short-term memory
is significant.
• So the interface should be designed in such a way to reduce the remembering of
previously done actions, given inputs and results.
3. Make the interface consistent :
• Many interfaces have dozens of screens. So it is important to provide indicators
consistently so that the user know about the doing work.
• The user should also know from which page has navigated to the current page and
from the current page where can navigate.
 USER INTERFACE ANALYSIS AND DESIGN
(1) interface design
(2) interface construction
(3) interface validation
(4) interface analysis and modeling,
• Interface analysis focuses on the profile of the users who will interact with the
system. Skill level, business understanding, and general receptiveness to the new
system are recorded; and different user categories are defined. For each user
category, requirements are elicited.
• Once general requirements have been defined, a more detailed task analysis is
conducted. Those tasks that the user performs to accomplish the goals of the
system are identified, described, and elaborated (over a number of iterative passes
through the spiral)
• Finally, analysis of the user environment focuses on the physical work
environment. Among the questions to be asked are
• Where will the interface be located physically?
• Will the user be sitting, standing, or performing other tasks unrelated to the
interface?
• Does the interface hardware accommodate space, light, or noise constraints?
• Are there special human factors considerations driven by environmental
factors?
• The goal of interface design is to define a set of interface objects and actions that
enable a user to perform all defined tasks in a manner that meets every usability
goal defined for the system.
• Interface construction normally begins with the creation of a prototype that
enables usage scenarios to be evaluated. As the iterative design process
continues, a user interface tool kit may be used to complete the construction of
the interface.