UNIT III – SOFTWARE DESIGN

Design process – Design Concepts-Design Model– Design Heuristic – Architectural Design

Architectural styles, Architectural Design, Architectural Mapping using Data Flow- User Interface
Design: Interface analysis, Interface Design –Component level Design: Designing Class based
components, traditional Components.

Software Design Basics

“Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation.” For assessing user
requirements, an SRS (Software Requirement Specification) document is created whereas for
coding and implementation, there is a need of more specific and detailed requirements in software
terms. The output of this process can directly be used into implementation in programming
languages.
Software design is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from problem domain to solution domain. It tries to specify how to fulfill the
requirements mentioned in SRS.
Objectives of Software Design

1.​ Correctness:Software design should be correct as per requirement.

2.​ Completeness:The design should have all components like data structures, modules, and
external interfaces, etc.
3.​ Efficiency:Resources should be used efficiently by the program.
4.​ Flexibility:Able to modify on changing needs.
5.​ Consistency:There should not be any inconsistency in the design.
6.​ Maintainability: The design should be so simple so that it can be easily maintainable by
other designers.

Software Design Process

Software Design Levels
 Software design yields three levels of results:
●​ 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 forms of modules. It recognizes modular
structure of each sub-system and their relation and interaction among each other.
●​ Detailed 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.
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 of design:
1.​ Interface Design
2.​ Architectural Design
3.​ Detailed Design

Interface Design:
 Interface design is the specification of the interaction between a system and its environment.
this phase proceeds at a high level of abstraction with respect to the inner workings of the system i.e,
during interface design, the internal of the systems are completely ignored and the system is treated
as a black box. Attention is focussed on the dialogue between the target system and the users,
devices, and other systems with which it interacts. The design problem statement produced during
the problem analysis step should identify the people, other systems, and devices which are
collectively called agents.
Interface design should include the following details:
●​ Precise description of events in the environment, or messages from agents to which the system
must respond.
●​ Precise description of the events or messages that the system must produce.
●​ Specification on the data, and the formats of the data coming into and going out of the system.
●​ Specification of the ordering and timing relationships between incoming events or messages,
and outgoing events or outputs.
Architectural Design:
Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them. In
architectural design, the overall structure of the system is chosen, but the internal details of major
components are ignored.
Issues in architectural design includes:
●​ Gross decomposition of the systems into major components.
●​ Allocation of functional responsibilities to components.
●​ Component Interfaces
●​ Component scaling and performance properties, resource consumption properties, reliability
properties, and so forth.
●​ Communication and interaction between components.
The architectural design adds important details ignored during the interface design. Design of the
internals of the major components is ignored until the last phase of the design.
Detailed Design:
Design is the specification of the internal elements of all major system components, their
properties, relationships, processing, and often their algorithms and the data structures.
The detailed design may include:
●​ Decomposition of major system components into program units.
●​ Allocation of functional responsibilities to units.
●​ User interfaces
●​ Unit states and state changes
●​ Data and control interaction between units
●​ Data packaging and implementation, including issues of scope and visibility of program
elements
●​ Algorithms and data structures

Software Design Principles

Basic design principles enable the software engineer to navigate the design process. Davis [DAV95]
suggests a set of principles for software design, which have been adapted and extended in the
following list:

 The design process should not suffer from “tunnel vision.” A good designer should
consider alternative approaches, judging each based on the requirements of the problem, the
resources available to do the job.

 The design should be traceable to the analysis model. Because a single element of
the design model often traces to multiple requirements, it is necessary to have a means for
tracking how requirements have been satisfied by the design model.
 The design should not reinvent the wheel. Systems are constructed using a set of
design patterns, many of which have likely been encountered before. These patterns should
always be chosen as an alternative to reinvention. Time is short and resources are limited!
Design time should be invested in representing truly new ideas and integrating those patterns
that already exist.

  The design should “minimize the intellectual distance” between the software and
the problem as it exists in the real world. That is, the structure of the software design
should (whenever possible) mimic the structure of the problem domain.

 The design should exhibit uniformity and integration. A design is uniform if it appears
that one person developed the entire thing. Rules of style and format should be defined for a
design team before design work begins. A design is integrated if care is taken in defining
interfaces between design components.

 The design should be structured to accommodate change. The design concepts
discussed in the next section enable a design to achieve this principle.

 The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered. Well- designed software should never
“bomb.” It should be designed to accommodate unusual circumstances, and if it must
terminate processing, do so in a graceful manner.

 Design is not coding, coding is not design. Even when detailed procedural designs are
created for program components, the level of abstraction of the design model is higher than
source code. The only design decisions made at the coding level address the small
implementation details that enable the procedural design to be coded.

 The design should be assessed for quality as it is being created, not after the fact. A
variety of design concepts and design measures are available to assist the designer in
assessing quality.
 The design should be reviewed to minimize conceptual (semantic) errors. There is
sometimes a tendency to focus on minutiae when the design is reviewed, missing the forest for the
trees. A design team should ensure that major conceptual elements of the design (omissions,
ambiguity, inconsistency) have been addressed before worrying about the syntax of the design
model.

Design concepts
The set of fundamental software design concepts are as follows:​

1. Abstraction
An abstraction is a tool that enables a designer to consider a component at an abstract level without
bothering about the internal details of the implementation. Abstraction can be used for existing
element as well as the component being designed.
Here, there are two common abstraction mechanisms
1.​ Functional Abstraction
2.​ Data Abstraction
Functional Abstraction
i.​ A module is specified by the method it performs.
ii.​ The details of the algorithm to accomplish the functions are not visible to the user of the
function.
Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction
Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches

2. Architecture
●​ The complete structure of the software is known as software architecture.
●​ Structure provides conceptual integrity for a system in a number of ways.
●​ The architecture is the structure of program modules where they interact with each other in a
specialized way.
●​ The components use the structure of data.
●​ The aim of the software design is to obtain an architectural framework of a system.
●​ The more detailed design activities are conducted from the framework.

3. Patterns​
A design pattern describes a design structure and that structure solves a particular design problem in
a specified content.

4. Modularity
●​ A software is separately divided into name and addressable components. Sometime they are called
as modules which integrate to satisfy the problem requirements.
●​ Modularity is the single attribute of a software that permits a program to be managed easily.

5. Information hiding​
Modules must be specified and designed so that the information like algorithm and data presented in
a module is not accessible for other modules not requiring that information.​

6. Functional independence
●​ The functional independence is the concept of separation and related to the concept of modularity,
abstraction and information hiding.
●​ The functional independence is accessed using two criteria i.e Cohesion and coupling.
Cohesion
●​ Cohesion is an extension of the information hiding concept.
●​ A cohesive module performs a single task and it requires a small interaction with the other
components in other parts of the program.
Coupling​
Coupling is an indication of interconnection between modules in a structure of software.​

7. Refinement
●​ Refinement is a top-down design approach.
●​ It is a process of elaboration.
●​ A program is established for refining levels of procedural details.
●​ A hierarchy is established by decomposing a statement of function in a stepwise manner till the
programming language statement are reached.
8. Refactoring
●​ It is a reorganization technique which simplifies the design of components without changing its
function behaviour.
●​ Refactoring is the process of changing the software system in a way that it does not change the
external behaviour of the code still improves its internal structure.
9. Design classes
●​ The model of software is defined as a set of design classes.
●​ Every class describes the elements of problem domain and that focus on features of the problem
which are user visible.
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.
Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving strategy this
is because there are many other benefits attached with the modular design of a software.
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
Concurrency
Back in time, all software are meant to be executed sequentially. By sequential execution we mean
that the coded instruction will be executed one after another implying only one portion of program
being activated at any given time. Say, a software has multiple modules, then only one of all the
modules can be found active at any time of execution.
In software design, concurrency is implemented by splitting the software into multiple independent
units of execution, like modules and executing them in parallel. In other words, concurrency provides
capability to the software to execute more than one part of code in parallel to each other.
It is necessary for the programmers and designers to recognize those modules, which can be made
parallel execution.
Example
The spell check feature in word processor is a module of software, which runs along side the word
processor itself.
Coupling and Cohesion
When a software program is modularized, its tasks are divided into several modules based on some
characteristics. As we know, modules are set of instructions put together in order to achieve some
tasks. They are though, considered as 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 coupling and cohesion.
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.
●​ Logical cohesion - When logically categorized elements are put together into a module, it is
called logical cohesion.
●​ Temporal Cohesion - When elements of module are organized such that they are processed
at a similar point in time, it is called 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.
●​ Communicational cohesion - When elements of module are grouped together, which are
executed sequentially and work on same data (information), it is called communicational
cohesion.
●​ 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.
●​ 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.
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.
There are five levels of coupling, namely -
●​ Content coupling - When a module can directly access or modify or refer to the content of
another module, it is called content level coupling.
●​ Common coupling- When multiple modules have read and write access to some global data,
it is called common or global 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.
●​ Stamp coupling- When multiple modules share common data structure and work on different
part of it, it is called stamp coupling.
●​ Data coupling- Data coupling is when two modules interact with each other by means of
passing data (as parameter). If a module passes data structure as parameter, then the
receiving module should use all its components.
Ideally, no coupling is considered to be the best.
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.
The next phase, which is the implementation of software, depends on all outputs mentioned above.
It is then becomes necessary to verify the output before proceeding to the next phase. The early any
mistake is detected, the better it is or it might not be detected until testing of the product. If the
outputs of design phase are in formal notation form, then their associated tools for verification
should be used otherwise a thorough design review can be used for verification and validation.
By structured verification approach, reviewers can detect defects that might be caused by
overlooking some conditions. A good design review is important for good software design, accuracy
and quality.
Problem Partitioning
For small problem, we can handle the entire problem at once but for the significant problem, divide
the problems and conquer the problem it means to divide the problem into smaller pieces so that
each piece can be captured separately.
For software design, the goal is to divide the problem into manageable pieces.
Benefits of Problem Partitioning
Software is easy to understand
Software becomes simple
Software is easy to test
Software is easy to modify
Software is easy to maintain
Software is easy to expand
These pieces cannot be entirely independent of each other as they together form the system. They
have to cooperate and communicate to solve the problem. This communication adds complexity.

Analysis and Design Tools

Software analysis and design includes all activities, which help the transformation of requirement
specification into implementation. Requirement specifications specify all functional and
non-functional expectations from the software. These requirement specifications come in the shape
of human readable and understandable documents, to which a computer has nothing to do.
Software analysis and design is the intermediate stage, which helps human-readable requirements
to be transformed into actual code.
Let us see few analysis and design tools used by software designers:
Data Flow Diagram
Data flow diagram is graphical representation of flow of data in an information system. It is capable
of depicting incoming data flow, outgoing data flow and stored data. The DFD does not mention
anything about how data flows through the system.
There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of control in
program modules. DFDs depict flow of data in the system at various levels. DFD does not contain
any control or branch elements.
Types of DFD
Data Flow Diagrams are either Logical or Physical.
 ●​ Logical DFD - This type of DFD concentrates on the system process, and flow of data in the
system.For example in a Banking software system, how data is moved between different
entities.
●​ Physical DFD - This type of DFD shows how the data flow is actually implemented in the
system. It is more specific and close to the implementation.
DFD Components
DFD can represent Source, destination, storage and flow of data using the following set of
components -

●​ Entities - Entities are source and destination of information data. Entities are represented by
a rectangles with their respective names.
●​ Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.
●​ Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one side
missing.
●​ Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from
the base of arrow as its source towards head of the arrow as destination.
Levels of DFD
●​ Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the entire
information system as one diagram concealing all the underlying details. Level 0 DFDs are
also known as context level DFDs.

●​ Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1 DFD
depicts basic modules in the system and flow of data among various modules. Level 1 DFD
also mentions basic processes and sources of information.
 ●​ Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level 1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper level
of understanding unless the desired level of specification is achieved.
Structure Charts
Structure chart is a chart derived from Data Flow Diagram. It represents the system in more detail
than DFD. It breaks down the entire system into lowest functional modules, describes functions and
sub-functions of each module of the system to a greater detail than DFD.
Structure chart represents hierarchical structure of modules. At each layer a specific task is
performed.
Here are the 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.
●​ Condition - It is represented by small diamond at the base of module. It depicts that control
module can select any of sub-routine based on some condition.

●​ Jump - An arrow is shown pointing inside the module to depict that the control will jump in the

middle of the sub-module.

●​ Loop - A curved arrow represents loop in the module. All sub-modules covered by loop

repeat execution of module.

●​ Data flow - A directed arrow with empty circle at the end represents data flow.
 ●​ Control flow - A directed arrow with filled circle at the end represents control flow.

HIPO Diagram
HIPO (Hierarchical Input Process Output) diagram is a combination of two organized method to
analyze the system and provide the means of documentation. HIPO model was developed by IBM in
year 1970.
HIPO diagram represents the hierarchy of modules in the software system. Analyst uses HIPO
diagram in order to obtain high-level view of system functions. It decomposes functions into
sub-functions in a hierarchical manner. It depicts the functions performed by system.
HIPO diagrams are good for documentation purpose. Their graphical representation makes it easier
for designers and managers to get the pictorial idea of the system structure.

In contrast to IPO (Input Process Output) diagram, which depicts the flow of control and data in a
module, HIPO does not provide any information about data flow or control flow.

Example
Both parts of HIPO diagram, Hierarchical presentation and IPO Chart are used for structure design
of software program as well as documentation of the same.
Structured English
Most programmers are unaware of the large picture of software so they only rely on what their
managers tell them to do. It is the responsibility of higher software management to provide accurate
information to the programmers to develop accurate yet fast code.
 Other forms of methods, which use graphs or diagrams, may are sometimes interpreted differently
by different people.
Hence, analysts and designers of the software come up with tools such as Structured English. It is
nothing but the description of what is required to code and how to code it. Structured English helps
the programmer to write error-free code.
Other form of methods, which use graphs or diagrams, may are sometimes interpreted differently by
different people. Here, both Structured English and Pseudo-Code tries to mitigate that
understanding gap.
Structured English is the It uses plain English words in structured programming paradigm. It is not
the ultimate code but a kind of description what is required to code and how to code it. The following
are some tokens of structured programming.
IF-THEN-ELSE,
DO-WHILE-UNTIL
Analyst uses the same variable and data name, which are stored in Data Dictionary, making it much
simpler to write and understand the code.
Example
We take the same example of Customer Authentication in the online shopping environment. This
procedure to authenticate customer can be written in Structured English as:
Enter Customer_Name
SEEK Customer_Name in Customer_Name_DB file
IF Customer_Name found THEN
Call procedure USER_PASSWORD_AUTHENTICATE()
ELSE
PRINT error message
Call procedure NEW_CUSTOMER_REQUEST()
ENDIF
The code written in Structured English is more like day-to-day spoken English. It can not be
implemented directly as a code of software. Structured English is independent of programming
language.
Pseudo-Code
Pseudo code is written more close to programming language. It may be considered as augmented
programming language, full of comments and descriptions.
Pseudo code avoids variable declaration but they are written using some actual programming
language’s constructs, like C, Fortran, Pascal etc.
Pseudo code contains more programming details than Structured English. It provides a method to
perform the task, as if a computer is executing the code.
Example
Program to print Fibonacci up to n numbers.
void function Fibonacci
Get value of n;
Set value of a to 1;
Set value of b to 1;
Initialize I to 0
for (i=0; i< n; i++)
{
if a greater than b
{
Increase b by a;
Print b;
}
else if b greater than a
{
increase a by b;
print a;
}
}
Decision Tables
A Decision table represents conditions and the respective actions to be taken to address them, in a
structured tabular format.
It is a powerful tool to debug and prevent errors. It helps group similar information into a single table
and then by combining tables it delivers easy and convenient decision-making.
Creating Decision Table
To create the decision table, the developer must follow basic four steps:
●​ Identify all possible conditions to be addressed
●​ Determine actions for all identified conditions
●​ Create Maximum possible rules
●​ Define action for each rule
Decision Tables should be verified by end-users and can lately be simplified by eliminating duplicate
rules and actions.
Example
Let us take a simple example of day-to-day problem with our Internet connectivity. We begin by
identifying all problems that can arise while starting the internet and their respective possible
solutions.
We list all possible problems under column conditions and the prospective actions under column
Actions.
Conditions/Actions Rules
Shows Connected N N N N Y Y Y Y
Conditions Ping is Working N N Y Y N N Y Y
Opens Website Y N Y N Y N Y N
Check network cable X
Check internet router X X X X
Actions Restart Web Browser X
Contact Service provider X X X X X X
Do no action
Table : Decision Table – In-house Internet Troubleshooting
Entity-Relationship Model
Entity-Relationship model is a type of database model based on the notion of real world entities and
relationship among them. We can map real world scenario onto ER database model. ER Model
creates a set of entities with their attributes, a set of constraints and relation among them.
ER Model is best used for the conceptual design of database. ER Model can be represented as
follows :

●​ Entity - An entity in ER Model is a real world being, which has some properties
called attributes. Every attribute is defined by its corresponding set of values,
called domain.
For example, Consider a school database. Here, a student is an entity. Student has various
attributes like name, id, age and class etc.
●​ Relationship - The logical association among entities is called relationship. Relationships
are mapped with entities in various ways. Mapping cardinalities define the number of
associations between two entities.
Mapping cardinalities:
o​ one to one
o​ one to many
o​ many to one
o​ many to many
Data Dictionary
Data dictionary is the centralized collection of information about data. It stores meaning and origin of
data, its relationship with other data, data format for usage etc. Data dictionary has rigorous
definitions of all names in order to facilitate user and software designers.
Data dictionary is often referenced as meta-data (data about data) repository. It is created along with
DFD (Data Flow Diagram) model of software program and is expected to be updated whenever DFD
is changed or updated.
Requirement of Data Dictionary
The data is referenced via data dictionary while designing and implementing software. Data
dictionary removes any chances of ambiguity. It helps keeping work of programmers and designers
synchronized while using same object reference everywhere in the program.
Data dictionary provides a way of documentation for the complete database system in one place.
Validation of DFD is carried out using data dictionary.
Contents
Data dictionary should contain information about the following
●​ Data Flow
●​ Data Structure
●​ Data Elements
●​ Data Stores
●​ Data Processing
Data Flow is described by means of DFDs as studied earlier and represented in algebraic form as
described.
= Composed of
{} Repetition
() Optional
+ And
[/] Or
Example
Address = House No + (Street / Area) + City + State
Course ID = Course Number + Course Name + Course Level + Course Grades
Data Elements
Data elements consist of Name and descriptions of Data and Control Items, Internal or External data
stores etc. with the following details:
●​ Primary Name
●​ Secondary Name (Alias)
●​ Use-case (How and where to use)
●​ Content Description (Notation etc. )
●​ Supplementary Information (preset values, constraints etc.)
Data Store
It stores the information from where the data enters into the system and exists out of the system.
The Data Store may include -
●​ Files
o​ Internal to software.
o​ External to software but on the same machine.
o​ External to software and system, located on different machine.
●​ Tables
o​ Naming convention
o​ Indexing property
Data Processing
There are two types of Data Processing:
●​ Logical: As user sees it
●​ Physical: As software sees it

Software Design Strategies

Software design is a process to conceptualize the software requirements into software
implementation. Software design takes the user requirements as challenges and tries to find
optimum solution. While the software is being conceptualized, a plan is chalked out to find the best
possible design for implementing the intended solution.
There are multiple variants of software design. Let us study them briefly:
Structured Design
Structured design is a conceptualization of problem into several well-organized elements of solution.
It is basically concerned with the solution design. Benefit of structured design is, it gives better
understanding of how the problem is being solved. Structured design also makes it simpler for
designer to concentrate on the problem more accurately.
Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken into
several small problems and each small problem is individually solved until the whole problem is
solved.
The small pieces of problem are solved by means of solution modules. Structured design emphasis
that these modules be well organized in order to achieve precise solution.
These modules are arranged in hierarchy. They communicate with each other. A good structured
design always follows some rules for communication among multiple modules, namely -
Cohesion - grouping of all functionally related elements.
Coupling - communication between different modules.
A good structured design has high cohesion and low coupling arrangements.
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems known as
functions. These functions are capable of performing significant task in the system. The system is
considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide and conquer
methodology is used.
This design mechanism divides the whole system into smaller functions, which provides means of
abstraction by concealing the information and their operation.. These functional modules can share
information among themselves by means of information passing and using information available
globally.
Another characteristic of functions is that when a program calls a function, the function changes the
state of the program, which sometimes is not acceptable by other modules. Function oriented design
works well where the system state does not matter and program/functions work on input rather than
on a state.
Design Process
●​ The whole system is seen as how data flows in the system by means of data flow diagram.
●​ DFD depicts how functions changes data and state of entire system.
●​ The entire system is logically broken down into smaller units known as functions on the basis
of their operation in the system.
●​ Each function is then described at large.
Object Oriented Design
Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategies focuses on entities and its characteristics.
The whole concept of software solution revolves around the engaged entities.
Let us see the important concepts of Object Oriented Design:
●​ Objects - All entities involved in the solution design are known as objects. For example,
person, banks, company and customers are treated as objects. Every entity has some
attributes associated to it and has some methods to perform on the attributes.
●​ Classes - A class is a generalized description of an object. An object is an instance of a
class. Class defines all the attributes, which an object can have and methods, which defines
the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined by
means of methods or procedures.
●​ Encapsulation - In OOD, the attributes (data variables) and methods (operation on the data)
are bundled together is called encapsulation. Encapsulation not only bundles important
information of an object together, but also restricts access of the data and methods from the
outside world. This is called information hiding.
●​ Inheritance - OOD allows similar classes to stack up in hierarchical manner where the lower
or sub-classes can import, implement and re-use allowed variables and methods from their
immediate super classes. This property of OOD is known as inheritance. This makes it easier
to define specific class and to create generalized classes from specific ones.
●​ Polymorphism - OOD languages provide a mechanism where methods performing similar
tasks but vary in arguments, can be assigned same name. This is called polymorphism, which
allows a single interface performing tasks for different types. Depending upon how the
function is invoked, respective portion of the code gets executed.
Design Process
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the following
steps involved:
●​ A solution design is created from requirement or previous used system and/or system
sequence diagram.
●​ Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
●​ Class hierarchy and relation among them is defined.
●​ Application framework is defined.
Software Design Approaches
Here are two generic approaches for software designing:
Top Down Design
We know that a system is composed of more than one sub-systems and it contains a number of
components. Further, these sub-systems and components may have their on set of sub-system and
components and creates hierarchical structure in the system.
Top-down design takes the whole software system as one entity and then decomposes it to achieve
more than one sub-system or component based on some characteristics. Each sub-system or
component is then treated as a system and decomposed further. This process keeps on running
until the lowest level of system in the top-down hierarchy is achieved.
Top-down design starts with a generalized model of system and keeps on defining the more specific
part of it. When all components are composed the whole system comes into existence.
Top-down design is more suitable when the software solution needs to be designed from scratch
and specific details are unknown.
Bottom-up Design
The bottom up design model starts with most specific and basic components. It proceeds with
composing higher level of components by using basic or lower level components. It keeps creating
higher level components until the desired system is not evolved as one single component. With each
higher level, the amount of abstraction is increased.
Bottom-up strategy is more suitable when a system needs to be created from some existing system,
where the basic primitives can be used in the newer system.
Both, top-down and bottom-up approaches are not practical individually. Instead, a good
combination of both is used.

Software User Interface Design

User interface is the front-end application view to which user interacts in order to use the software.
User can manipulate and control the software as well as hardware by means of user interface.
Today, user interface is found at almost every place where digital technology exists, right from
computers, mobile phones, cars, music players, airplanes, ships etc.
User interface is part of software and is designed such a way that it is expected to provide the user
insight of the software. UI provides fundamental platform for human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying hardware and
software combination. UI can be hardware or software or a combination of both.
The software becomes more popular if its user interface is:
●​ Attractive
●​ Simple to use
●​ Responsive in short time
●​ Clear to understand
●​ Consistent on all interfacing screens
UI is broadly divided into two categories:
●​ Command Line Interface
●​ Graphical User Interface
Command Line Interface (CLI)
CLI has been a great tool of interaction with computers until the video display monitors came into
existence. CLI is first choice of many technical users and programmers. CLI is minimum interface a
software can provide to its users.
CLI provides a command prompt, the place where the user types the command and feeds to the
system. The user needs to remember the syntax of command and its use. Earlier CLI were not
programmed to handle the user errors effectively.
A command is a text-based reference to set of instructions, which are expected to be executed by
the system. There are methods like macros, scripts that make it easy for the user to operate.
CLI uses less amount of computer resource as compared to GUI.
CLI Elements

A text-based command line interface can have the following elements:

●​ Command Prompt - It is text-based notifier that is mostly shows the context in which the
user is working. It is generated by the software system.
●​ Cursor - It is a small horizontal line or a vertical bar of the height of line, to represent position
of character while typing. Cursor is mostly found in blinking state. It moves as the user writes
or deletes something.
●​ Command - A command is an executable instruction. It may have one or more parameters.
Output on command execution is shown inline on the screen. When output is produced,
command prompt is displayed on the next line.
Graphical User Interface
Graphical User Interface provides the user graphical means to interact with the system. GUI can be
combination of both hardware and software. Using GUI, user interprets the software.
Typically, GUI is more resource consuming than that of CLI. With advancing technology, the
programmers and designers create complex GUI designs that work with more efficiency, accuracy
and speed.
GUI Elements
GUI provides a set of components to interact with software or hardware.
Every graphical component provides a way to work with the system. A GUI system has following
elements such as:
 ●​ Window - An area where contents of application are displayed. Contents in a window can be
displayed in the form of icons or lists, if the window represents file structure. It is easier for a
user to navigate in the file system in an exploring window. Windows can be minimized,
resized or maximized to the size of screen. They can be moved anywhere on the screen. A
window may contain another window of the same application, called child window.
●​ Tabs - If an application allows executing multiple instances of itself, they appear on the
screen as separate windows. Tabbed Document Interface has come up to open multiple
documents in the same window. This interface also helps in viewing preference panel in
application. All modern web-browsers use this feature.
●​ Menu - Menu is an array of standard commands, grouped together and placed at a visible
place (usually top) inside the application window. The menu can be programmed to appear
or hide on mouse clicks.
●​ Icon - An icon is small picture representing an associated application. When these icons are
clicked or double clicked, the application window is opened. Icon displays application and
programs installed on a system in the form of small pictures.
●​ Cursor - Interacting devices such as mouse, touch pad, digital pen are represented in GUI
as cursors. On screen cursor follows the instructions from hardware in almost real-time.
Cursors are also named pointers in GUI systems. They are used to select menus, windows
and other application features.
Application specific GUI components
A GUI of an application contains one or more of the listed GUI elements:
●​ Application Window - Most application windows uses the constructs supplied by operating
systems but many use their own customer created windows to contain the contents of
application.
●​ Dialogue Box - It is a child window that contains message for the user and request for some
action to be taken. For Example: Application generate a dialogue to get confirmation from
user to delete a file.
 ●​ Text-Box - Provides an area for user to type and enter text-based data.
●​ Buttons - They imitate real life buttons and are used to submit inputs to the software.

●​ Radio-button - Displays available options for selection. Only one can be selected among all
offered.
●​ Check-box - Functions similar to list-box. When an option is selected, the box is marked as
checked. Multiple options represented by check boxes can be selected.
●​ List-box - Provides list of available items for selection. More than one item can be selected.

Other impressive GUI components are:

●​ Sliders
●​ Combo-box
●​ Data-grid
●​ Drop-down list
User Interface Design Activities
There are a number of activities performed for designing user interface. The process of GUI design
and implementation is alike SDLC. Any model can be used for GUI implementation among Waterfall,
Iterative or Spiral Model.
A model used for GUI design and development should fulfill these GUI specific steps.
 ●​ GUI Requirement Gathering - The designers may like to have list of all functional and
non-functional requirements of GUI. This can be taken from user and their existing software
solution.
●​ User Analysis - The designer studies who is going to use the software GUI. The target
audience matters as the design details change according to the knowledge and competency
level of the user. If user is technical savvy, advanced and complex GUI can be incorporated.
For a novice user, more information is included on how-to of software.
●​ Task Analysis - Designers have to analyze what task is to be done by the software solution.
Here in GUI, it does not matter how it will be done. Tasks can be represented in hierarchical
manner taking one major task and dividing it further into smaller sub-tasks. Tasks provide
goals for GUI presentation. Flow of information among sub-tasks determines the flow of GUI
contents in the software.
●​ GUI Design & implementation - Designers after having information about requirements,
tasks and user environment, design the GUI and implements into code and embed the GUI
with working or dummy software in the background. It is then self-tested by the developers.
●​ Testing - GUI testing can be done in various ways. Organization can have in-house
inspection, direct involvement of users and release of beta version are few of them. Testing
may include usability, compatibility, user acceptance etc.
GUI Implementation Tools
There are several tools available using which the designers can create entire GUI on a mouse click.
Some tools can be embedded into the software environment (IDE).
GUI implementation tools provide powerful array of GUI controls. For software customization,
designers can change the code accordingly.
There are different segments of GUI tools according to their different use and platform.
Example
Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a list of few tools which come handy to
build GUI:
●​ FLUID
●​ AppInventor (Android)
●​ LucidChart
●​ Wavemaker
●​ Visual Studio
User Interface Golden rules
The following rules are mentioned to be the golden rules for GUI design, described by Shneiderman
and Plaisant in their book (Designing the User Interface).
●​ Strive for consistency - Consistent sequences of actions should be required in similar
situations. Identical terminology should be used in prompts, menus, and help screens.
Consistent commands should be employed throughout.
●​ Enable frequent users to use short-cuts - The user’s desire to reduce the number of
interactions increases with the frequency of use. Abbreviations, function keys, hidden
commands, and macro facilities are very helpful to an expert user.
●​ Offer informative feedback - For every operator action, there should be some system
feedback. For frequent and minor actions, the response must be modest, while for infrequent
and major actions, the response must be more substantial.
●​ Design dialog to yield closure - Sequences of actions should be organized into groups
with a beginning, middle, and end. The informative feedback at the completion of a group of
actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to
drop contingency plans and options from their minds, and this indicates that the way ahead
is clear to prepare for the next group of actions.
●​ Offer simple error handling - As much as possible, design the system so the user will not
make a serious error. If an error is made, the system should be able to detect it and offer
simple, comprehensible mechanisms for handling the error.
●​ Permit easy reversal of actions - This feature relieves anxiety, since the user knows that
errors can be undone. Easy reversal of actions encourages exploration of unfamiliar options.
The units of reversibility may be a single action, a data entry, or a complete group of actions.
●​ Support internal locus of control - Experienced operators strongly desire the sense that
they are in charge of the system and that the system responds to their actions. Design the
system to make users the initiators of actions rather than the responders.
●​ Reduce short-term memory load - The limitation of human information processing in
short-term memory requires the displays to be kept simple, multiple page displays be
consolidated, window-motion frequency be reduced, and sufficient training time be allotted
for codes, mnemonics, and sequences of actions.