This document discusses key concepts related to software design, including: 1. The design process focuses on determining system modules and their specifications and interconnections at both the module and detailed logic levels. 2. Object-oriented design models the problem domain using concepts like classes, objects, and relationships to make the design easier to produce and understand. 3. Modularization criteria like coupling and cohesion aim to produce loosely coupled and highly cohesive modules to improve qualities like modifiability and understandability.

1. Design
1
The design activity begins when the requirements document for the software to
be developed is available and the architecture has been designed.
 During design further refine the architecture.
 Design focuses on the module.
 During design we determine what modules the system should have and which
have to be developed.
 The design of a system is a blueprint or a plan for a solution for the system.

2. Design
2
 A system is a set of modules with clearly defined behavior which
interact with each other in a defined manner to produce
some behavior or services for its environment.
The design process for software systems has two levels.
Module design
Focuses on deciding which modules are needed for the system, the specifications of
these modules, and how the modules should be interconnected.
Detailed design or logic design.
In this, the internal design of the modules, or how the specifications of the module
can be satisfied, is decided.

3. Design Concepts
3
The design of a system is correct, if a system built according to the
design, satisfies the requirements of that system.
 The goal during the design phase is to produce correct designs.
 The goal of the design process is to find the best possible design within
the limitations imposed by the requirements and the physical and social
environment in which the system will operate.

4. Design Concepts
4
To evaluate a design, we will focus on modularity of a system, which is
decided mostly by design, as the main criteria for evaluation.
A system is considered modular, if it consists of discrete modules so
that each module can be implemented separately, and a change in one
module has minimal impact on other modules.
Modularity helps
1. system debugging easy.
2.Module can implement separately
3.system building easy

5. Design Concepts
5
4. system repair is easy
5.changes in one module has minimum impact on other modules.
To produce modular designs, some criteria must be used to
select modules.
Coupling and cohesion are two modularization criteria, which are often
used together.
The open-closed principle, which is another criteria for modularity.

6. Design Concepts
6
Coupling
 Coupling between modules is the strength of interconnections between
modules or a measure of interdependence among modules.
 The concept of coupling explains “how strongly” different modules are
interconnected.
Highly coupled modules are joined by strong interconnections
 Loosely coupled modules have weak interconnections.
 uncoupled: Independent modules have no interconnections.

7. Design Concepts
7
Coupling
The choice of modules decides the coupling between modules.
 The coupling between modules is decided during system design and
cannot be reduced during implementation.
Coupling increases with the complexity of the interface between
modules.
Ie,coupling is lowest if only data is passed and it is higher if control
information is passed or amount of data passed is increased.

8. Design Concepts
8
Two different approaches for software design are : -
– Functional oriented design
It is a method to software design where the model is decomposed into a set of
modules where each module has a clearly defined function. In this system state or field is
centralised and shared among different functions. Different design notations are used
during the process and are used to represent design or design decisions. graphically or
mathematically.
–object oriented design
In this method ,the system is viewed as a collection of objects (entities).The state or field/
or attribute is distributed among the object and each object handles its state data.In this
system state or field is decentralised among objects and each object manages its own
state information..

9. Design Concepts
9
Coupling
In OO systems, three different types of coupling exist : -
– Interaction coupling
– Component coupling
– Inheritance coupling
Interaction coupling occurs due to methods of a class invoking methods
of other classes.
This is similar to a function calling another function.

10. Design Concepts
10
Coupling
Component coupling :- refers to the interaction between two classes
where a class has variables of the other class.
Eg : -A class C can be component coupled with another class C1, if C has
an instance variable
of type C1, or C has a method whose parameter is of type C1, or if C has
a method which has a local variable of type C1.
 Whenever there is component coupling, there is likely to be interaction
coupling.

11. Design Concepts
11
Coupling
Inheritance coupling :- is due to the inheritance relationship between
classes.
Two classes are considered inheritance coupled if one class is a direct or
indirect subclass of the other.

12. Design Concepts
12
Cohesion
Cohesion of a module represents how tightly bound the internal
elements of the module are to one another.
It is the measure of integrity & efficiency of a module.
Cohesion determines, how closely the elements of a module are related
to each other.
Cohesion and coupling are clearly related.
For a Good s/w design the cohesion of each module will be high & the
coupling between modules will be lowest.

13. Design Concepts
13
Cohesion
Levels of cohesion in function oriented design:
 Coincidental
 Logical
 Temporal
 Procedural
 Communicational
 Sequential
 Functional
HIGH
LOW

14. Design Concepts
14
Cohesion
Coincidental : - It is the lowest level and not permitted.
Coincidental cohesion occurs when there is no meaningful relationship
among the elements of a module.
Coincidental cohesion can occur if an existing program is “modularized”
by chopping it into pieces and making different pieces modules.
Logical :- if there is some logical relationship between the elements of a
module, and the elements perform functions that fall in the same logical
class.ie i/o will be done using some status flag.

15. Design Concepts
15
Cohesion
Temporal : - Same as logical cohesion.The elements are related in time
and are executed together. Modules that perform activities like
“initialization,” “cleanup,” and “termination” are usually temporally bound.
Procedural :- A procedurally cohesive module contains elements that
belong to a common procedural unit.
For example, a loop or a sequence of decision statements in
a module may be combined to form a separate module

16. Design Concepts
16
Cohesion
Communicational : - A module with communicational cohesion has
elements that are related by a reference to the same input or output data.
In this, the elements are together because they operate on the same input
or output data.eg:read,pocess &update using same file.
Sequential :- In this, the elements are together in a module and the
output of one forms the input to another.
Functional :- all the elements of the module are related to performing a
single function. Function like “sort the array” is an example.It is the
strongest cohesion.
eg

17. Design Concepts
17
Cohesion
In OO systems, three different types of cohesion exist : -
– Method cohesion
– Class cohesion
– Inheritance cohesion
Method cohesion: is same as cohesion in functional module
It focuses on why the different code elements of method are together
within the method.

18. Design Concepts
18
Class Cohesion
Class cohesion focuses on why different attributes and
methods are in this class.whenever there are multiple
concepts encapsulated within a class, the cohesion
of the class is not as high as it could be, and a designer
should try to change the design to have each class
encapsulate a single concept for modifiability and
understandability
whenever there are multiple concepts encap for modifiability and
understandabilitysulated within a class, the
cohesion of the class is not as high as it could be, and a designer should try to
change the design to have each class encapsulate a single concept

19. Design Concepts
19
 Inheritance Cohesion
Cohesion focuses on the reason why classes are together in a
hierarchy. The two main reasons for inheritance are to model
Generalization- Specialization relationship, and for code reuse.
Cohesion is considered high if the hierarchy supports
generalization-specialization of some concept.
whenever there are multiple concepts encapsulated within a class, the
cohesion of the class is not as high as it could be, and a designer should try to
change the design to have each class encapsulate a single concept
cohesion focuses on the reason why classes are together in a
hierarchy. The two main reasons for inheritance are to model generalizationspecialization
relationship, and for code reuse. Cohesion is considered high if
the hierarchy supports generalization-specialization of some concept

20. Design Concepts
20
The Open-Closed Principle
The basic principle, as stated by bertrand meyer, is
“software entities should be open for extension, but closed for modification”[66]. A
module being “open for extension” means that its behavior can be extended to
accommodate. New demands placed on this module due to changes in requirements
and system Functionality. The module being “closed for modification” means that the
Existing source code of the module is not changed when making enhancements.
whenever there are multiple concepts encapsulated within a class, the
cohesion of the class is not as high as it could be, and a designer should try to
change the design to have each class encapsulate a single concept
cohesion focuses on the reason why classes are together in a
hierarchy. The two main reasons for inheritance are to model generalizationspecialization
relationship, and for code reuse. Cohesion is considered high if
the hierarchy supports generalization-specialization of some concept

21. Design Concepts
21
– Functional oriented design techniques
1. structure chart
The structure chart of a program is a graphical representation of its structure.
The structure of a program is made up of the modules of that program together with the
interconnections between modules.In a structure chart a module is represented by a box
with the module name written in the box.
Modules included in the system
1. Input module: modules that obtain information from their subordinates and then pass
it to their superordinate.
2. Output module: which take information from their superordinate and pass it on to its
subordinates.
3. Transformation module:Transforming data into some other form
4. Co-ordinate module: Managing the flow of data to and from different
subordinate .
managing
the flow of data to and from different subordinates.

24. The structure chart of the sort program.
STRUCTURE CHART OF SORT PROGRAM
Subordinate
Superordinate

25. Functional oriented design
25
2.Structured design Methodology
It is a set of guidelines that if applied will produce a design that is modular and
simple It partition the system at the very top level into various subsystems ,one
for managing each major I /p One for major output , one for major
transformation.
The module dealing with I /p have to deal with issues of screen ,reading data,
formats, errors , exceptions completeness of information, structure of information
etc. The module dealing with o/p have to prepare the o/p in presentation
formats ,make charts , produce reports etc.

26. Design Concepts
26
There are four major steps in the methodology
1. Restate the problem as a data flow diagram .In this step a DFD is
constructed that deals with the solution Domain and act as model for the
eventual system.
2. Identify the i/p &o/p data elements: I/P Data elements obtained after
operations like error checking ,data validation ,proper formatting etc and
O/P data elements (logical) that must be transformed into desired output
format . The central transform that perform the basic transformation is
also identified.
.

27. Design Concepts
27
3. First level factorization : In this step , the modules for the system are identified and represented
using structure charts.
.
4. Factorizing of i/p,o/p and transform branches. : The first level factoring results in a very high level
structure ,where each subordinate module has a lot of processing to do. To simplify these module s ,
they must be factored into subordinate modules that will distribute the work of a module Each of the
input , output and transformation modules must be considered for factoring..

28. Metrics
---------A software metric is a measure of software characteristics which are
measurable or countable. They are valuable for many reasons, including
measuring software quality, productivity, benefits etc.
Eg: 1.size(Number of modules)
2. Complexity ( reducing of this improve testability & maintainability)

29. Complexity Metrics
Network Metrics:
* It is a complexity metrics that tries to capture how good the structure chart is..
As coupling of a module increases if it is called by more modules ,a good
structure is considered one that exactly one caller. That is the call graph
structure is simplest if it is a pure tree(node is 1 more than edge ie graph
impurity is 0). Deviation of structure chart from a tree is defined as the graph
impurity of the design. It can be defined as , Graph impurity=n-e-1,where
n=Number of nodes,e=edges It works on the basis that as the graph impurity
increases, the coupling increases.
Two terms used in this metrics are fan-in and fan-out.Fan-in: Is the number of
modules that call a given module. Fan-out: Is the numbers of modules that
called by a given module.Each time a module has a fan-in of more than one,the
graph impurity increases
29
---------
1)

30. 2)Information flow metrics
This metric define the complexity in terms of the total information flowing in to
the module (inflow) and total information flowing out of the module(outflow).
The inflow of a module is the total number of abstract data elements(ie used by
the module) that are flowing in the the module and outflow is the total number
abstract data elements (ie,defined by the module and used by other module)that
are flowing out of the module
.
The module design complexity Dc is defined as
Dc=size*(inflow*outflow)^2
The term (inflow*outflow)refers to the total number of combinations of i/p
source and output destination.
This term is squared, as interconnection between module is considered a more
important factor.

31. Design Concepts
31
Object oriented design
It represent the problem domain,which make it easier to produce and understand
designs.
As requirement changes the object in a system are less immune to these
changes ,thereby permitting changes more closely.
The following are used to modeling Oodesign
1. UML -Unified modeling language
It is a graphical notation for expressing object oriented design . Due to
ability of UMLto create different models ,it has become an aid for understanding
the system ,designing the system as well as representing design.

32. 2.State diagram
It is the initial module level design . In this oodesign as viewed on a set of
states with transitions between the states taking place some event occurs.
3. Activity diagram
For modeling dynamic behavior that take place in it when the system
execute for performing function

33. Design Concepts
33
Object oriented design
The following steps are included in creation of oodesign
1. Identify classes and relationship between them(Define initial class diagram of
design)
2. Develop dynamic model(activity diagram) and use it to define operation on
classes(Module level design)
3. Develop functional model (DFD) and use it to define operation on
classes,identify i/o.
4.Identify internal classes and operations( Issues in implementation )
5. Optimize and package(Issues in Efficiency): final structures should not
deviate too much from the logical structure produced.

34. Design Concepts
34
Complexity metrics for OO Design
These metrics focus on evaluating class
1. Weigted Methods per class(WMC)
This Metric combines the number of methods and complexity of methods can be
useful in estimating the overall complexity of class
Suppose a class C has methods M1,M2...Mn defined on it.Let the complexity of the
method Mi be ci.The WMC is defined as
If the complexity of each method is considered to be 1.WMC gives the total number of
methods in the class. High value of WMC indicates the class is more complex than that
of low values.

35. Design Concepts
35
2. Depth of Inheritance Tree(DIT)
DIT metric provides for each class a measure of the inheritance
levels from the object heirarchy top.The minimum value of DIT for a class is 1.
A DIT value of 0 indicate a root while a value of 2 /3 indicates a higher degree of
reuse.
3..Coupling between classes(CBC)
The Coupling Between Object classes metric represents the number of classes
coupled to a given class. This coupling can happen through:
method call, class extends, properties or parameters, method arguments, or return
types, variables in methods

36. -A value of 0 indicates that a class has no relationship
A value between 1 and 4 is good,
-A number higher than this may indicate that the class if too tightly coupled
4. The Response for Class (RFC) metric
It is the total number of methods that can potentially be executed in response to a
message received by an object of a class. This number is the sum of the methods
of the class, and all distinct methods are invoked directly within the class
methods.

37. Detailed Design
37
Once the modules are identified and specified during the highlevel
design, the internal logic that will implement the given specifications can
be designed.
The detailed design is useful for the more complex and important
modules.
The basic goal in detailed design is to specify the logic for the different
modules that have been specified during system design.

38. Detailed Design
38
1. Logic/Algorithm Design
Specifying the logic will require developing an algorithm that will implement
the given specifications.
The starting step in the design of algorithms is statement of the problem.
The problem for which an algorithm is developing has to be clearly stated and
properly understood by the person responsible for designing the algorithm.
For detailed design, the problem statement comes from the system design.

39. Detailed Design
39
1. Logic/Algorithm Design
The next step is development of a mathematical model for the problem.
In modeling, one has to select the mathematical structures that are best suited
for the problem.
The next step is the design of the algorithm.
During this step the data structure and program structure are decided. Once the
algorithm is designed, its correctness should be verified.

40. Detailed Design
40
1. Logic/Algorithm Design
The most common method for designing algorithms or the logic for a
module is to use the stepwise refinement technique.
The stepwise refinement technique breaks the logic design problem
into a series of steps.
The process starts by converting the specifications of the module into
an abstract description of an algorithm containing a few abstract
statements.
In each step, one or several statements are decomposed into more
detailed instructions.

41. Detailed Design
41
2. State Modeling of Classes
In object-oriented design, class is not a functional abstraction and
cannot be viewed as only a collection of functions (methods).
An object of a class has some state and many operations on it.
To understand a class, the relationship between the state and various
operations and the effect of interaction of various operations have to be
understood.
Once the class is better understood, the algorithms for its various
methods can be developed.

42. Detailed Design
42
2. State Modeling of Classes
A method to understand the behavior of a class is to view it as a finite
state automaton, which consists of states and transitions between
states.
When modeling an object, the state is the value of its attributes, and
an event is the performing of an operation on the object.
 A state diagram relates events and states by showing how the state
changes when an event is performed.
A state diagram for an object will generally have an initial state, from
which all states are reachable.

43. Detailed Design
43
2. State Modeling of Classes
FSA model of a stack.