Software design

Design is the highly significant phase in the software development where the designer plans “how” a software
system should be produced in order to make it functional, reliable,reasonably easy to understand, modify and
maintain

“what” a system does, and becomes input to design process.

“which” tells us how requirements are realized and result is a software design document

Conceptual and technical design-: The process of software design involves the transformation ideas into detailed
implementation descriptions. There are two types of design

Ones the customer accepts the conceptual design we translate it into detailed document

Technical design deals hardware and software needed

A two part design process

 Customer understands what the system is to do

 At the same time, the system builders must understand how the system is to work
 Where will the data come from?
 What will happen to the data in the system?
 How will the system look to the user?
 What choices will be offered to users?
 What is the timeline of project?
 How will the reports and screens look like?

Objectives of Design-:

 It deals a document from which coding can directly be done

 Design fills gap between specification and coding
 The wider the gap, the larger the number of stepping stones
 Correct and complete
 Understandable
 At the right level
 Maintainable and to facilitate maintenance of the produced code

Modularity-:

A module is a well defined, manageable units with well defined interfaces among the units

1
 Each module is a well defined subsystem that is potentially useful in other applications
 Each module has a single ,well defined purpose
 Modules can be separately compiled and stored in a library
 Modules can use other modules
Coupling and Cohesion Module Coupling

 In software engineering, the coupling is the degree of
interdependence between software modules. Two modules that are tightly coupled are strongly
dependent on each other. However, two modules that are loosely coupled are not dependent on each
other.
 Uncoupled modules
 have no interdependence at all within them.

 The various types of coupling techniques are shown in fig:

 A good design is the one that has low coupling. Coupling is measured by the number of
interconnections between the modules(sharing data increases).
 The design with high coupling will have more errors
 Types of couplings-:
 Data Coupling: If the dependency between the modules is based on the fact that they
communicate by passing only data, then the modules are said to be data coupled. In data
coupling, the components are independent of each other and communicate through data. Module
communications don’t contain tramp data. Example-customer billing system.
 Stamp Coupling In stamp coupling, the complete data structure is passed from one module to
another module. Therefore, it involves tramp data. It may be necessary due to efficiency factors-
this choice was made by the insightful designer, not a lazy programmer.
 Control Coupling: If the modules communicate by passing control information, then they are
said to be control coupled. It can be bad if parameters indicate completely different behavior and
good if parameters allow factoring and reuse of functionality. Example- sort function that takes
comparison function as an argument.
 External Coupling: In external coupling, the modules depend on other modules, external to the
software being developed or to a particular type of hardware. Ex- protocol, external file, device
format, etc.
 Common Coupling: The modules have shared data such as global data structures. The changes
in global data mean tracing back to all modules which access that data to evaluate the effect of
the change. So it has got disadvantages like difficulty in reusing modules, reduced ability to
control data accesses, and reduced maintainability.
 Content Coupling: In a content coupling, one module can modify the data of another module,
or control flow is passed from one module to the other module. This is the worst form of
coupling and should be avoided.
Module Cohesion-: cohesion is a measure of degree which elements of a module are functionally
related.A strongly cohesive module implements functionality that is related to one feature of the solution

Functional Cohesion: Every essential element for a single computation is

contained in the component. A functional cohesion performs the task and functions. It is an ideal situation.
 Sequential Cohesion: An element outputs some data that becomes the input for other element,
i.e., data flow between the parts. It occurs naturally in functional programming languages.
 Communicational Cohesion: Two elements operate on the same input data or contribute
towards the same output data. Example- update record in the database and send it to the printer.
 Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions
are still weakly connected and unlikely to be reusable. Ex- calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.

2
 Temporal Cohesion: The elements are related by their timing involved. A module connected
with temporal cohesion all the tasks must be executed in the same time span. This cohesion
contains the code for initializing all the parts of the system. Lots of different activities occur, all
at unit time.
 Logical Cohesion: The elements are logically related and not functionally. Ex- A component
reads inputs from tape, disk, and network. All the code for these functions is in the same
component. Operations are related, but the functions are significantly different.
 Coincidental Cohesion: The elements are not related(unrelated). The elements have no
conceptual relationship other than location in source code. It is accidental and the worst form of
cohesion. Ex- print next line and reverse the characters of a string in a single component.
Software design process-: This process can be perceived as series of well-defined steps
There are two types of approaches
1.Function oriented
2.Object oriented
The design process for software systems often has two levels. At the first level, the focus is on
deciding which modules are needed for the system based on SRS (Software Requirement Specification) and
how the modules should be interconnected.
Function Oriented Design is an approach to software design where the design is decomposed into a set of
interacting units where each unit has a clearly defined function.
Generic Procedure
Start with a high-level description of what the software/program does. Refine each part of the description by
specifying in greater detail the functionality of each part. These points lead to a Top-Down Structure.

Problem in Top-Down Design Method

Mostly each module is used by at most one other module and that module is called its Parent module.
Solution to the Problem
Designing of reusable module. It means modules use several modules to do their required functions.

Function Oriented Design Strategies

Function Oriented Design Strategies are as follows:
1. A data flow diagram (DFD) maps out the flow of information for any process or system. It uses
defined symbols like rectangles, circles and arrows, plus short text labels, to show data inputs,
outputs, storage points and the routes between each destination.
2. Data dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirement stage, data dictionaries contains data items. Data dictionaries include
Name of the item, Aliases (Other names for items), Description / purpose, Related data items,
Range of values, Data structure definition / form.
3. Structure chart is the hierarchical representation of system which partitions the system into
black boxes (functionality is known to users, but inner details are unknown). Components are
read from top to bottom and left to right. When a module calls another, it views the called
module as a black box, passing required parameters and receiving results.
4. Pseudo Code is system description in short English like phrases describing the function. It uses
keyword and indentation. Pseudocodes are used as replacement for flow charts. It decreases the
amount of documentation required
Structure Charts in Function Oriented Design
For a function-oriented design, the design can be represented graphically by structure charts. The structure of
a program is made up of the modules of that program together with the modules of that program together with
the interconnections between modules. The structure chart of a program is a graphic representation of its
structure.
1. In a structure chart a module is represented by a box with the module name written in the box.
2. In general, procedural information is not represented in a structure chart, and the focus is on
representing the hierarchy of modules.
3. However, there are situations where the designer may wish to communicate certain procedural
information explicitly, like major loop and decisions.

3
4. Such information can also be represented in a structure chart.
5. Modules in a system can be categorized into few classes as below:
6. Input module: There are some modules that obtain information from their subordinates and then
pass it to their superordinate.
7. Output module: Module which take information from their superordinate and pass it on to its
subordinates.
8. Transform module: Modules that exist solely for the sake of transforming data into some other
form.
9. Coordinate module: Modules whose primary concern is managing the flow of data to and from
different subordinates.
10. A structure chart is a nice representation for a design that uses functional abstraction.
object oriented design :
object oriented design begins with an examination of real world things that are part of the problem to be
solved
OOSE is developed by Ivar Jacolson in 1992
 The use of use cases in designing is started by OOSE technique
 It includes a requirement , an analysis , a design an implementation and a testing model.
 Interaction diagrams are similar to UML sequence diagram
State transition diagrams are like UML state chart diagram
 Each object are characterized individually in terms of their attributes
 Each object maintain its own state
 Objects are independent entities that may readily be changed because all state are representation
information is held with in the object itself

 Object is used very frequently and convey different meaning in different circumstances
 All objects have unqiue identification and distinguishable
Step 1: The classes are user defined data types on which objects are created. Objects with similar
properties are methods are grouped together to form a class
 Class is a data type
 It generates Objects
 Does not occupy memory location
 Can’t be manipulated
 Static classes are manipulated

Step 2: It is a run time entities that may represent a person, place, any item

4
 Each Object contains data & code to manipulate the data
 Data represents the attributes of that object and functions represents the behaviour of that object
Object->1.attribues(data),2.Function(behaviour(code))
 Object take up space in memory space and have an associated add like structure in c
 When a program is executed the object interact by sending messages to one another

 Object is an instance of class

 It gives life to class
 It occupies memory location
 Objects are manipulated

Data Abstraction: Abstraction refers to the act of representing essential features with out including the
background details or explanation

 It is used for hiding the unwanted data and giving relevant data
 What the object does
 Outer layout used in terms of design

Eg: Outlook of a Mobile phone

Encapsulation: Means hiding the code and data into a single unit to protect data form outside

 How the object does

 Inner implementation of mobile phone
 The wrapping up of data and functions into a single unit is known as encapsulation
 It is also known as information hiding concept
 The data is not accessible to the outside world and only those functions which are wrapped in the class
can access it
 This concept may help to keep data secured

5
Inheritance: Each derived class inherits the attributes of its base class and this process is known as
inheritance

 Inheritance is the process by which objects of one class acquire the properties of objects of another
class
 Code reusability we can add additional features to an existing class with out modifying it
 Highlights relationships
 Helps in code Organization

Polymorphism: In the real world, the same operation may have different meaning in different situation

The three pillars of OOD are

 Encapsulation
 Inheritance
 Polymorphism

Operation of addition :

3+4 here + is operand giving result 7

Dakshith + guduru =Dakshith guduru

Here + operator is used as string concatenation

Operator Overloading: The process of making an operator to exhibit different behaviour in different instance

Function Overloading: Using a single function name to perform different type of task

6
Ex: Printf(“hi mca students”);

Int a=10;

Printf(“%d”,a);

Design Verification:

 Design verification is a method to confirm if the output of a designed software product meets the input
specifications by examining and providing evidence
 The goal of the design verification process during software development is ensuring that the designed
software product is the same as specified
 Design input is any physical and performance requirement that is used as the basis for designing
purpose
 Design output is the result of each design phase and at the end of total design effort. The final design
output is a basis for device master record

Difference between Design Verification and Design validation

Design Verification Design Validation

>design verification is used where the actual >design validation is used to define that the final
design output should be same as expected design is a per the expectations of the user need
design output which satisfies the specification
of the product

>design verification includes unit and >design validation includes secondary or higher-
primary integration level testing level integration and system

>certain aspect of design validation can be >design validation follows successful design
accomplished during the design verification is verification
not a substitute for design validation

Software testing -: It is a evaluation of the software against requirements gathered from users and system
specification

It is conducted at the phase in the software development life cycle

1.Software validation-: It is the process of examining whether the user requirements are satisfied or not

2.Software verification-: It is the process of confirming if the software is meeting the business
requirements. It is developed proper specifications.

Testing-:

1.Errors-:actual coding mistake or difference in estimated output and executed output

7
2.Fault-: When error exists, fault occurs

3.Failure-: failure occurs when fault exists in the system

Two types of testing are there

1.Manual testing: Consumes more time done by people

2.Automated testing: Done using machines

Software testing approaches:

1.Behaviouarl testing (or) Functional testing (or) Black box testing

When Functionality is being tested without taken the actual implementation in concern

There are several testing techniques in functionality testing

1.Equivalence class

2. Boundary class

3. cause-effect graphing

4.Pair wise testing

5.State based testing

1.Equivalence class-: Dividing into similar classes

2.Boundary Values-: Boundary conditions have a higher chance of detecting an error. Here boundary
condition means, an input variable X with a range from 1-100

A program with two input variables X and Y. These input variables have specified boundaries as

A≤x≤b

c ≤ y ≤d

X is bounded by two intervals(a,b)

Y is bounded by two intervals(c,d)

Legitimate input

Xx

Boundary value analysis is a black-box testing technique that helps test whether an application output falls with
in the acceptable range for all input values.It focuses on testing edge or boundary conditions

8
2.Equivalence partitioning-: Dividing the inputs data into different partitions and testing each partitions and
identify any errors are present and test

For example: age accept value 18 to 56

Equivalence partitioning

Invalid valid Invalid

≤=17 18-56 ≥=57

3.Cause effect graphing-: technique in which a graph is used to represent the situations of combinations of
input conditions. The graph is then converted to a decision table to obtain the test cases. Cause-effect
graphing technique is used because boundary value analysis and equivalence class partitioning methods do
not consider the combinations of input conditions. But since there may be some critical behaviour to be tested
when some combinations of input

conditions are considered, that is why cause-effect graphing technique is used.

Identity Function: if c is 1, then e is 1. Else e is 0.

NOT Function: if c is 1, then e is 0. Else e is 1.

OR Function: if c1 or c2 or c3 is 1, then e is 1. Else e is 0.

Pair wise testing-: It is a type of software testing in which permutation and combination method is used to
test the software. Pairwise testing is used to test all the possible discrete combinations of the parameters
involved.
Pairwise testing is a P&C based method, in which to test a system or an application, for each pair of input
parameters of a system, all possible discrete combinations of the parameters are tested. By using the
conventional or exhaustive testing approach it may be hard to test the system but by using the permutation
and combination method it can be easily done.
Example:
Suppose there is a software to be tested which has 20 inputs and 20 possible settings for each input so in that
case there are total 20^20 possible inputs to be tested. Therefore in this case, exhaustive testing is impossible
even all combinations are tried to be tested.
Graphical Representation of Pairwise Testing:

9
Generalized form of Pairwise Testing:
The generalized form of pairwise testing is N-wise testing. Basically, sorting is applied to the set,
X = n{i},
so that P = P{i} gets ordered too.
Let the sorted set be a N tuple:
P{s} = {P{i} } ; i |R(P{i})| < |R(P{j})|
Now take the set X (2) = {P{N-1}, P{N-2}}
And call it the pairwise testing. Generalizing further take the set
X(3) = { P{N-1}, P{N-2}, P{N-3} }
And call it the 3-wise testing. Similarly, we can say,
X(K) = { P{N-1}, P{N-2}, ..., P{N-K} }
K-wise testing.
The N-wise testing is all possible combinations from the above formula.

State based testing-:

Is a type of software testing which is performed to check the change in the state of the application under
varying input. The condition of input passed is changed and the change in state is observed. State Transition
Testing is basically a black box testing technique that is carried out to observe the behaviour of the system or
application for different input conditions passed in a sequence. In this type of testing, both positive and
negative input values are provided and the behaviour of the system is observed. State Transition Testing is
basically used where different system transitions are needed to be tested.

White box testing-:

It is a software testing technique in which internal structure design and coding of a software are tested to
very flow of input-output

It is also called as clear box testing, open box ,transparent, code based testing, glass box.

TYPES OF WHITE BOX TESTING:

10
1. Statement coverage
2. Decision coverage
3. Multiple condition coverage
4. Path coverage
5. Control flow testing
6. Data flow testing

1.Statement coverage:

> statement coverage technique is used to design white box test cases

>This technique involves execution of all statements of the source code at least ones

>It is used to calculate the total number of executed statements present in the source code

>This technique covers dead code, unused code and branches

//greatest of 3 numbers program

Main ()

int n1, n2, n3;

if(n1>=n2&&n1>=n3)

printf(“%d n1 is the largest number”,n1);

else if(n2>=n1&&n2>=n3)

printf(“%d n2 is the largest number”,n2);

else

printf(“%d n3 is the largest number”,n3);

Depending on the values the statement execution covers

2.Decision coverage technique:

Decision coverage technique comes under white box testing which gives decision coverage to Boolean values.
This technique reports true and false outcomes of Boolean expressions. Whenever there is a possibility of two or
more outcomes from the statements like do while statement, if statement and case statement (Control flow
statements), it is considered as decision point because there are two outcomes either true or false. Decision
coverage covers all possible outcomes of each and every Boolean condition of the code by using control flow
graph or chart.

Generally, a decision point has two decision values one is true, and another is false that's why most of the times
the total number of outcomes is two. The percent of decision coverage can be found by dividing the number of
exercised outcomes with the total number of outcomes and multiplied by 100.

let's understand it by an example.

11
Consider the code to apply on decision coverage technique:

1. Test (int a)
2. {
3. If(a>4)
4. a=a*3
5. Print (a)
6. }

Multiple condition coverage technique: The coverage of a program is the number of executed statement
blocks and condition combinations divided by their total number in the program

Path testing

In the path testing, we will write the flow graphs and test all independent paths. Here writing the flow graph
implies that flow graphs are representing the flow of the program and also show how every program is added
with one another as we can see in the below image:

And test all the independent paths implies that suppose a path from main () to function G, first set the
parameters and test if the program is correct in that particular path, and in the same way test all other paths and
fix the bugs.

Control flow testing is a testing technique that comes under white box testing. The aim of this technique is to
determine the execution order of statements or instructions of the program through a control structure. The
control structure of a program is used to develop a test case for the program. In this technique, a particular part
of a large program is selected by the tester to set the testing path. It is mostly used in unit testing. Test cases
represented by the control graph of the program.

Control Flow Graph is formed from the node, edge, decision node, junction node to specify all possible
execution path.

Notations used for Control Flow Graph

1. Node

2. Edge

3. Decision Node

4. Junction node

12
Node

Nodes in the control flow graph are used to create a path of procedures. Basically, it represents the sequence of
procedures which procedure is next to come so, the tester can determine the sequence of occurrence of
procedures.

We can see below in example the first node represents the start procedure and the next procedure is to assign the
value of n after assigning the value there is decision node to decide next node of procedure as per the value of n
if it is 18 or more than 18 so Eligible procedure will execute otherwise if it is less than 18 Not Eligible
procedure executes. The next node is the junction node, and the last node is stopping node to stop the procedure

Edge: Edge in control flow graph is used to link the direction of nodes. We can see below in example all arrows
are used to link the nodes in an appropriate direction.

Decision node: Decision node in the control flow graph is used to decide next node of procedure as per the
value. We can see below in example decision node decide next node of procedure as per the value of n if it is 18
or more than 18 so Eligible procedure will execute otherwise if it is less than 18, Not Eligible procedure
executes.

Junction node: Junction node in control flow graph is the point where at least three links meet.

1. public class VoteEligiblityAge {

2. public static void main (String [] args) {
3. int n=45;
4. if(n>=18)
5. {
6. System.out.println("You are eligible for voting");
7. } else
8. {
9. System.out.println("You are not eligible for voting");
10. }
11. }
12. }

Diagram - control flow graph

13
Data Flow testing: Data flow testing is used to analyse the flow of data in the program. It is the process of
collecting information about how the variables flow the data in the program. It tries to obtain particular
information of each particular point in the process.

Data flow testing is a group of testing strategies to examine the control flow of programs in order to explore the
sequence of variables according to the sequence of events. It mainly focuses on the points at which values
assigned to the variables and the point at which these values are used by concentrating on both points, data flow
can be tested. Data flow testing uses the control flow graph to detect illogical things that can interrupt the flow
of data.

Unit-4

History and origin of patterns-:

A design patterns are well-proved solution for solving the specific problem/task. Design patterns represent the
best practices used by experienced object-oriented software developers. Design patterns are solutions to general
problems that software developers
Now, a question will be arising in your mind what kind of specific problem? Let me explain by taking an
example.
ProblemGiven:
Suppose you want to create a class for which only a single instance (or object) should be created and that single
object can be used by all other classes.
Ans:
Singleton design pattern is the best solution of above specific problem. So, every design pattern has some
specification or set of rules for solving the problems. What are those specifications, you will see later in the
types of design patterns.

But remember one-thing, design patterns are programming language independent strategies for solving the
common object-oriented design problems. That means, a design pattern represents an idea, not a particular
implementation. By using the design patterns you can make your code more flexible, reusable and maintainable.
It is the most important part because java internally follows design patterns. To become a professional software
developer, you must know at least some popular solutions (i.e. design patterns) to the coding problems.

14
15