SOFTWARE ENGINEERING

(KCS 601)

Lecture Notes

UNIT III – SOFTWARE DESIGN

 Unit-3 Syllabus
Basic Concept of Software Design, Architectural Design, Low Level Design: Modularization, Design
Structure Charts, Pseudo Codes, Flow Charts, Coupling and Cohesion Measures, Design Strategies:
Function Oriented Design, Object Oriented Design, Top-Down and Bottom-Up Design. Software
Measurement and Metrics: Various Size Oriented Measures: Halestead’s Software Science,
Function Point (FP) Based Measures, Cyclomatic Complexity Measures: Control Flow Graphs.

SOFTWARE DESIGN
Software design is the practice of taking a specification of externally observable behavior
and adding details needed for actual computer system implementation, including human
interaction, taskmanagement, and data management details.

Software design is a kind of problem solving. Thinking about design as problem solving has
many advantages.

First it suggests that information may be partitioned between the problem and the solution.

A second advantage of thinking about design as problem solving is the perspective it gives on
the design activity.

A third advantage of thinking about design as problem solving is that it suggests the use of
time honoured general problem solving techniques in design.

Good Design Vs Bad Design

Characteristic Good Design Bad Design

Change Change in one part of system One conceptual change

doesn’t always require a change in requires changes to many
another part of the system. parts of the system.
Logic Every piece of logic has one and one Logic has to be duplicated.
home
Nature Simple Complex

Cost Small Very High

Extension System can be extended with System cannot be extended

changes in only one place so easily.

Software Design Principles

 Design must specify systems that satisfy product requirements in accord with
designconstraints.

 Designs must specify systems that can be constructed on time and within budget

 Designs that specify systems that are easy to change are better.
  Modules should not be too big

 Modules should hide private information

 Modules should not have access to unneeded resources.

 Module coupling should be minimized.

 Module Cohesion should be maximized.

 Simpler designs are better.

 Systems should be designed to reuse existing assets as much as possible.

 Simple and powerful designs are better.

Software Design Models

Software design problems and solutions are often complex, and many aspects of software
systems mustbe modelled.

Software design models may be divided into two broad classes:

 Static Models

o These models represent aspects of software systems that do not change during execution.

o These models represent software components, their characteristics and unvarying

relationships between software components.

Examples – object and class diagrams, use case diagrams, data structure pictures,
implementationdiagrams.

 Dynamic Model

o These models show what happens during software execution.

Examples – interaction diagrams, state charts, DFDs, decision trees and tables, mini specs.

General Design Process

- Analyze the problem

- Generate /Refine the problem
- Evaluate the design
- Review the design
Software Design Process

The software design process can be decomposed mainly into the following three levels of design:

a) Interface Design

b) Architecture Design

c) Detailed Design

a) Interface Design

 Interface design is the specification of the interaction between a system its environment.
 This phase proceeds at a high level of abstraction with respect to inner workings of the
system.
 Attention is focused on the dialogues between target system and the users, devices,
and other systemswith which interacts.

They should usually include the following details –

 Precise description of events in the environment, or messages from agents, to
which thesystem must respond.
 Precise description of the events or messages that the system must produce.
 Specification of 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

User Interface Design

 Specification of user inputs

 User Outputs
 Valid sequences

b) Architectural Design

High Level Design also called architectural design.

Large systems are always decomposed into subsystems that provide some related set of services.
The initial design process of identifying these sub-systems and establishing a framework for sub-
system control and communication is called architectural design.

Architectural design methods look into various alternate architectural style of designing a system.
These are:

Data centric architecture approach involves the use of a central database operations of
inserting, updating it in the form of a table.

Data flow architecture is applied when input data takes the form of output after passing
through various phases of transformations. These transformations can be through various
computations done on data.

In Object oriented architecture, the software design moves around the classes and objects of
the system. The class encapsulates the data and methods.

Layered approach defines the number of layers and each layer performs tasks. The
 outermost layer handles the functionality of user interface and the innermost layer handles
interaction with the hardware.

Issues in architectural design include:

 Gross decomposition of the system into major components.

 Allocation of functional responsibilities to components.
 Component interfaces.
 Component scaling and performance properties, resource consumption
properties, reliabilityproperties.
 Communication and interaction between components.

c) Detailed Design

Also known as Low Level Design. It is the specification of the internal elements of all major system
components, their structure properties,relationships, processing and other their algorithms and
data structures.

Detailed design may include:

 Decomposition of major system components into program units.

 Allocation of functional responsibilities to units.
 Unit interfaces
 Unit states and state changes
 Data and control Interactions between units
 Unit packaging and implementation, including issues of scope and visibility of
programelements.
 Algorithms and data structures.

Modularization
Modularization is the process of separating the functionality of a program into independent,
interchangeable modules, such that each contains everything necessary to execute only one
aspect of the desired functionality.

With modularization, we can easily work on adding separate and smaller modules to a
program without being hindered by the complexity of its other functions.
Advantages of Modularity

 Modular systems are easier to understand and explain because their parts make
sense and canstand on their own.

 They are easier to document because each part can be documented as an independent
unit.

 Programming individual modules is easier because the programmer can focus

on just onesmall, simple problem rather than a large complex problem.

 Testing and debugging individual modules is easier.

 Bugs are easier to isolate and understand

 Well composed modules are more reusable because they are more likely to
comprise part of a solution to many problems.
 Algorithm
An Algorithm is a sequence of computational steps that transform the input into the output.
The algorithm describes a specific computational procedure for achieving that input/output
describes a specific computational procedure for achieving thatinput/ output relationship.
Characteristics of Algorithm
1. Finiteness. An algorithm must always terminate after a finite number of steps.
2. Definiteness. Each step of an algorithm must be precisely defined; the actions to be carried
out must be rigorously and unambiguously specified for each case.
3. Input. An algorithm has zero or more inputs, i.e., quantities which are given to it initially
before the algorithm begins.
4. Output. An algorithm has one or more outputs i.e., quantities which have a specified relation
to the inputs.
5. Effectiveness. An algorithm is also generally expected to be effective. This means that all of
the operations to be performed in the algorithm must be sufficiently basic that they can in
principle be done exactly and in a finite length of time.
Algorithm Design Documentation Tools

The tools used for an algorithm design include the following:

• Pseudocode

• Flowcharts

• Structure Charts

Pseudocode
A pseudocode is an informal way of writing a program. However, it is not a computer program. It
only represents the algorithm of the program in natural language and mathematical notations.
Besides, there is no particular programming language to write a pseudocode. Unlike in regular
programming languages, there is no syntax to follow when writing a pseudocode. Furthermore, it is
possible to use pseudocodes using simple English language statements.

 A pseudocode to find the total of two numbers is as follows.

Sum_Of_Two_Numbers()
Begin
Set sum =0;
Read: number 1, number 2;
Set sum = number1 + number 2;
Print sum;
End

 A pseudocode to find the area of a triangle is as follows.

Area_of_Trinagle()
Begin
Read: base, height;
Set area = 0.5 * base * height;
Print area;
End
So, after writing the pseudocode, we can write the actual program using that pseudocode. Moreover,
as it represents the algorithm, we can implement it using any programming language.

Advantages
• It is easy to understand even a complex program
• It does not follow any programming language syntax
• Programs can be easily generated by pseudo-code
• It allows us to understand the logic of a program very quickly
• Pseudo-code can be modified easily

Disadvantages
• Unlike the programs, a pseudo-code cannot be compiled or interpreted from which errors
cannot be identified
• As pseudo-code can be written in any order, so it becomes difficult to understand the flow of
a program

Flowchart
A flowchart represents an algorithm using a diagram. Flow charts, use rectangles, ovals, diamonds
and potentially numerous other shapes to define the type of step, along with connecting arrows to
define flow and sequence. They are widely used in multiple fields to document, study, plan, and
communicate often complex processes in clear, easy-to-understand diagrams.

 A simple flowchart for marks calculation is as follows.

In it, the oval shape denotes the start and end. And, the rhombus shape represents inputs and
outputs. Entering marks is an input while displaying marks is an output. Further, the diamond shape
symbol represents the decision selection. Depending on the decision, the correct output will be
displayed.

Flow Chart
In overall, a flow chart represents the sequence of steps to follow in order to solve the problem.
Thus, the flowchart diagrams are easier to draw and understand.
Advantages of Flowchart
• Effective Communication: Flowcharts are better way of communicating the logic of the
system.
• Effective Analysis: Flowchart which gives broad idea about the logic so that problem can be
analyzed more efficiently.
• Easy Debugging and Efficient Testing: The Flowchart helps in debugging and testing process.
• Efficient Coding: The flowcharts are very useful during program development phase.
• Proper Documentation: Flowcharts serves as a good program documentation, which is
needed for various purposes.
• Efficient Program Maintenance: Maintenance of operating programs becomes easy with the
help of flowchart.

Disdvantages of Flowchart
• Complex Logic: For complicated logic, flowchart becomes complex and clumsy.
• Difficulty in Modifications: If change is required in the logic then flowchart needs to be
redrawn and requires a lot of time.

Difference between Pseudocode and Flowchart

• Definition
Pseudocode is an informal high-level description of the operating principle of an algorithm
while a flowchart is a diagrammatic representation that illustrates a solution model to a given
problem.
• Representation
A pseudocode is written in natural language and mathematical notations help to write
pseudocode. However, a flowchart is written using various symbols.

Structure Charts
A Structure Chart is a chart which shows the breakdown of a system to its lowest manageable parts.
They are used in structured programming to arrange program modules into a tree. Each module is
represented by a box, which contains the module's name. The tree structure visualizes the
relationships between modules, showing data transfer between modules using arrows. Structured
Charts are an example of a top-down design where a problem (the program) is broken into its
components. The tree shows the relationship between modules, showing data transfer between the
models.

Structure chart Notations

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.

• An example of structure chart representing the logic for calculating average: