Software Engineering Tutorial

Software Design Basics

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

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.

91
 Software Engineering Tutorial

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

37
 Software Engineering Tutorial

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

 Emporal Cohesion - When elements of module are organized such that

they are processed at a similar point of 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.

38
 Software Engineering Tutorial

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.

39
Software Engineering Tutorial

40
 Software Engineering Tutorial

Software Analysis and

Design Tools 6
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 (DFD) is a 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. It 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 -

91
 Software Engineering Tutorial

 Entities - Entities are sources and destinations of information data. Entities

are represented by 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.

42
 Software Engineering Tutorial

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

43
 Software Engineering Tutorial

 Condition - It is represented by small diamond at base of the 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.

44
 Software Engineering Tutorial

 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
Hierarchical Input Process Output (HIPO) diagram is a combination of two
organized methods 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

45
 Software Engineering Tutorial

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 Input Process Output (IPO) 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 designing of software program as well as documentation of the same.

46
 Software Engineering Tutorial

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.

Different methods, which use graphs or diagrams, at times might be interpreted

in a different way 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. Here, both Structured English and Pseudo-Code tries to mitigate that
understanding gap.

Structured English 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

47
 Software Engineering Tutorial

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.

48
 Software Engineering Tutorial

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

49
 Software Engineering Tutorial

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

50
 Software Engineering Tutorial

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:

 one to one
 one to many
 many to one
 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

51
 Software Engineering Tutorial

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)

52
 Software Engineering Tutorial

 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

53
 Software Engineering Tutorial

Software Design Strategies

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

91
 Software Engineering Tutorial

Function Oriented Design

In function-oriented design, the system comprises 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 change data and state of the 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 (OOD) 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.

55
 Software Engineering Tutorial

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

56
 Software Engineering Tutorial

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 own set of sub-systems 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 the 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.

57
 Software Engineering Tutorial

Software User Interface Design

8
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 in 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. It is the 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.

91
 Software Engineering Tutorial

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.

59
 Software Engineering Tutorial

Graphical User Interface

Graphical User Interface (GUI) 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

60
 Software Engineering Tutorial

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.

61
 Software Engineering Tutorial

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

62
 Software Engineering Tutorial

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

63
 Software Engineering Tutorial

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

64
 Software Engineering Tutorial

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

65
 Software Engineering Tutorial

 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 to be consolidated, window-motion frequency be
reduced, and sufficient training time be allotted for codes, mnemonics, and
sequences of actions.

66
 Software Engineering Tutorial

Software Design Complexity

9
The term complexity stands for state of events or things, which have multiple
interconnected links and highly complicated structures. In software programming,
as the design of software is realized, the number of elements and their
interconnections gradually emerge to be huge, which becomes too difficult to
understand at once.

Software design complexity is difficult to assess without using complexity metrics

and measures. Let us see three important software complexity measures.

Halstead's Complexity Measures

In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software
complexity. Halstead’s metrics depends upon the actual implementation of
program and its measures, which are computed directly from the operators and
operands from source code, in static manner. It allows to evaluate testing time,
vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code.

According to Halstead, “A computer program is an implementation of an algorithm

considered to be a collection of tokens which can be classified as either operators
or operands”. Halstead metrics think a program as sequence of operators and
their associated operands.

He defines various indicators to check complexity of module. Following table

states the parameters and the meanings:

91
 Software Engineering Tutorial

Parameter Meaning

n1 Number of unique operators

n2 Number of unique operands

N1 Number of total occurrence of operators

N2 Number of total occurrence of operands

When we select source file to view its complexity details in Metric Viewer, the
following result is seen in Metric Report:

Metric Meaning Mathematical Representation

n Vocabulary n1 + n2

N Size N1 + N2

V Volume Length * Log2 Vocabulary

D Difficulty (n1/2) * (N1/n2)

E Efforts Difficulty * Volume

B Errors Volume / 3000

T Testing time Time = Efforts / S, where S=18 seconds.

Cyclomatic Complexity Measures

Every program encompasses statements to execute in order to perform some task
and other decision-making statements that decide, what statements need to be
executed. These decision-making constructs change the flow of the program.

If we compare two programs of same size, the one with more decision-making
statements will be more complex as the control of program jumps frequently.

68
 Software Engineering Tutorial

McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity

of a given software. It is graph driven model that is based on decision-making
constructs of program such as if-else, do-while, repeat-until, switch-case and goto
statements.

Process to make flow control graph:

 Break program in smaller blocks, delimited by decision-making constructs.

 Create nodes representing each of these nodes.

 Connect nodes as follows:

o If control can branch from block i to block j

Draw an arc

o From exit node to entry node

Draw an arc.

To calculate Cyclomatic complexity of a program module, we use the formula -

V(G) = e – n + 2

Where:

e is total number of edges

n is total number of nodes

The Cyclomatic complexity of the above module is

e = 10

n=8

Cyclomatic Complexity = 10 - 8 + 2

69
 Software Engineering Tutorial

=4

According to P. Jorgensen, Cyclomatic Complexity of a module should not exceed

10.

Function Point
It is widely used to measure the size of software. Function Point concentrates on
functionality provided by the system. Features and functionality of the system are
used to measure the software complexity.

Function point counts on five parameters, named as External Input, External

Output, Logical Internal Files, External Interface Files, and External Inquiry. To
consider the complexity of software each parameter is further categorized as
simple, average or complex.

Let us see parameters of function point:

External Input
Every unique input to the system, from outside, is considered as external input.
Uniqueness of input is measured, as no two inputs should have same formats.
These inputs can either be data or control parameters.

 Simple - if input count is low and affects less internal files

 Complex - if input count is high and affects more internal files

70
 Software Engineering Tutorial

 Average - in-between simple and complex.

External Output
All output types provided by the system are counted in this category. Output is
considered unique if their output format and/or processing are unique.

 Simple - if output count is low

 Complex - if output count is high

 Average - in between simple and complex.

Logical Internal Files

Every software system maintains internal files in order to maintain its functional
information and to function properly. These files hold logical data of the system.
This logical data may contain both functional data and control data.

 Simple - if number of record types are low

 Complex - if number of record types are high

 Average - in between simple and complex.

External Interface Files

Software system may need to share its files with some external software or it may
need to pass the file for processing or as parameter to some function. All these
files are counted as external interface files.

 Simple - if number of record types in shared file are low

 Complex - if number of record types in shared file are high

 Average - in between simple and complex.

External Inquiry
An inquiry is a combination of input and output, where user sends some data to
inquire about as input and the system responds to the user with the output of
inquiry processed. The complexity of a query is more than External Input and
External Output. Query is said to be unique if its input and output are unique in
terms of format and data.

 Simple - if query needs low processing and yields small amount of output
data

 Complex - if query needs high process and yields large amount of output
data

71
 Software Engineering Tutorial

 Average - in between simple and complex.

Each of these parameters in the system is given weightage according to their class
and complexity. The table below mentions the weightage given to each parameter:

Parameter Simple Average Complex

Inputs 3 4 6

Outputs 4 5 7

Enquiry 3 4 6

Files 7 10 15

Interfaces 5 7 10

The table above yields raw Function Points. These function points are adjusted
according to the environment complexity. System is described using fourteen
different characteristics:

 Data communications
 Distributed processing
 Performance objectives
 Operation configuration load
 Transaction rate
 Online data entry,
 End user efficiency
 Online update
 Complex processing logic
 Re-usability
 Installation ease
 Operational ease
 Multiple sites
 Desire to facilitate changes
These characteristics factors are then rated from 0 to 5, as mentioned below:

 No influence

72
 Software Engineering Tutorial

 Incidental
 Moderate
 Average
 Significant
 Essential
All ratings are then summed up as N. The value of N ranges from 0 to 70 (14
types of characteristics x 5 types of ratings). It is used to calculate Complexity
Adjustment Factors (CAF), using the following formulae:

CAF = 0.65 + 0.01N

Then,

Delivered Function Points (FP)= CAF x Raw FP

This FP can then be used in various metrics, such as:

 Cost = $ / FP

 Quality = Errors / FP

 Productivity = FP / person-month

73