Santosh V. Kadam ,W.I.E.T.

1
:- Santosh V. Kadam ,W.I.E.T

2
 4. Software Design
Design Principles & Concepts
Effective Modular Design
Cohesion
Coupling
Architectural design

Santosh V. Kadam ,W.I.E.T. 3

Santosh V. Kadam ,W.I.E.T. 4
 Design Process
• Software design is a mechanism to transform user requirements into some suitable
form, which helps the programmer in software coding and implementation.
• “The process of defining the architecture, components, interfaces, and other
characteristics of a system or component” and “the result of [that] process”.
• It deals with representing the client's requirement, as described in SRS (Software
Requirement Specification) document, into a form, i.e., easily implementable using
programming language.
• The purpose of Design phase in the Software Development Life Cycle is to produce
a solution to a problem given in the SRS(Software Requirement Specification)
document. The output of the design phase is Software Design Document (SDD).
• Software design is an iterative process using which the user requirements can be
translated into the software product.
• At the initial stage of the software is represented as an abstract view. During the
subsequent iterations data, functional and behavioral requirements are traced in
detail. That means at each iteration the refinement is made to obtain lower level
details of the software product.
The following items are designed and documented during the design phase:
1. Different modules required.
2. Control relationships among modules.
3. Interface among different modules.
4. Data structure among the different modules.
Santosh V. Kadam ,W.I.E.T. 5
5. Algorithms required to implement among the individual modules.
• Design is a two-part iterative process.
• First part is Conceptual Design that tells the customer what the system
will do.
• Second is Technical Design that allows the system builders to understand
the actual hardware and software needed to solve customer’s problem.
Conceptual design of the system:
• Written in simple language i.e. customer understandable language.
• Detailed explanation about system characteristics.
• Describes the functionality of the system.
• It is independent of implementation.
• Linked with requirement document.
Technical Design of the system:
• Hardware component and design.
• Functionality and hierarchy of software components.
• Software architecture
• Network architecture
• Data structure and flow of data.
• I/O component of the system.
• Shows interface.
Santosh V. Kadam ,W.I.E.T. 6
Santosh V. Kadam ,W.I.E.T. 7
Santosh V. Kadam ,W.I.E.T. 8
 Objectives of Software Design
• Correctness:
A good design should be correct i.e. it should correctly implement all
the functionalities of the system.
• Efficiency:
A good software design should address the resources, time, and cost
optimization issues.
• Understandability:
A good design should be easily understandable, for which it should be
modular and all the modules are arranged in layers.
• Completeness:
The design should have all the components like data structures,
modules, and external interfaces, etc.
• Flexibility: Able to modify on changing needs.
• Consistency: There should not be any inconsistency in the design.
• Maintainability:
A good software design should be easily amenable to change whenever
a change request is made from the customer side.

Santosh V. Kadam ,W.I.E.T. 9

 Characteristics of Good Design
1. The good design should implement all the
requirements that are mentioned in the explicitly
analysis model. It should accommodate all the implicit
requirements demanded by the customer.
2. The design should be simple enough so that the code
developer, code tester as well as those who are
supporting the software will find it readable and
understandable.
3. The design should be comprehensive. That means it
should provide a complete picture of software,
addressing the data, functional and behavioral
domains from an implementation perspective.

Santosh V. Kadam ,W.I.E.T. 10

 Software Design Principles
• Software design principles are concerned with providing means to handle
the complexity of the design process effectively.
• Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors
during design.
Davis suggested a set of principles for software design as :
• Should not suffer from “Tunnel Vision” –
While designing the process, it should not suffer from “tunnel vision”
which means that it should not only focus on completing or achieving the
aim but on other effects also.
• Traceable to analysis model –
The design process should be traceable to the analysis model which
means it should satisfy all the requirements that software requires to
develop a high-quality product.
• Should not “Reinvent The Wheel” –
The design process should not reinvent the wheel that means it should
not waste time or effort in creating things that already exist. Due to this,
the overall development time/effort will get increased.
Santosh V. Kadam ,W.I.E.T. 11
• Minimize Intellectual distance –
The design process should reduce the gap between real-world problems and
software solutions for that problem meaning it should simply minimize
intellectual distance.
• Exhibit uniformity and integration –
The design should display uniformity which means it should be uniform
throughout the process without any change. Integration means it should mix or
combine all parts of software i.e. subsystems into one system.
• Accommodate change –
The software should be designed in such a way that it accommodates the
change implying that the software should adjust to the change that is required
to be done as per the user’s need.
• Degrade gently –
The software should be designed in such a way that it degrades gracefully which
means it should work properly even if an error occurs during the execution.
• Assessed for quality –
The design should be assessed or evaluated for the quality meaning that during
the evaluation, the quality of the design needs to be checked and focused on.
• Review to discover errors –
The design should be reviewed which means that the overall evaluation should
be done to check if there is any error present or if it can be minimized.
• Design is not coding and coding is not design –
Design means describing the logic of the program to solve any problem and
coding is a type of language that is used for the implementation of a design.
Santosh V. Kadam ,W.I.E.T. 12
 Quality Guideline
• The goal of any software design is to produce high quality software. In order to evaluate
quality of software there should be some predefined rules or criteria that need to be
used to assess the software product.
The quality guidelines are as follows
• The design architecture should be created using following issues –
i. The design should be created using architectural styles and patterns.
ii. Each component of design should posses good design characteristics
iii. The implementation of design should be evolutionary, so that testing can be
performed at each phase of implementation.
• In the design the data, architecture, interfaces and components should be clearly
represented.
• The design should be modular. That means the subsystems in the design should be
logically partitioned.
• A design must carry appropriate data structure and recognizable data patterns.
• The components should be used in the design so that functional independency can be
achieved in the design.
• Using the information obtained in software requirement analysis the design should be
created.
• The interfaces in the design should be such that the complexity between connected
components of the system gets reduced. Similarly interface of the system with external
interface should be simplified one.
• Every design of the software system should convey its meaning appropriately a
effectively. Santosh V. Kadam ,W.I.E.T. 13
 Quality attributes
The attributes of design name as 'FURPS' are as follows:
Functionality:
It evaluates the feature set and capabilities of the program.
Usability:
It is accessed by considering the factors such as human factor, overall
aesthetics, consistency and documentation.
Reliability:
It is evaluated by measuring parameters like frequency and security of failure,
output result accuracy, the mean-time-to-failure(MTTF), recovery from failure
and the the program predictability.
Performance:
It is measured by considering processing speed, response time, resource
consumption, throughput and efficiency.
Supportability:
• It combines the ability to extend the program, adaptability, serviceability. These
three term defines the maintainability.
• Testability, compatibility and configurability are the terms using which a system
can be easily installed and the problems are found easily.
• Supportability also consists of more attributes such as fault tolerance,
modularity, reusability, robustness, security, portability, scalability.
Santosh V. Kadam ,W.I.E.T. 14
Software Design Concepts

Santosh V. Kadam ,W.I.E.T. 15

 Design concepts
Abstraction
• An abstraction is a tool that enables a designer to consider a component
at an abstract level without bothering about the internal details of the
implementation.
• Abstraction can be used for existing element as well as the component
being designed.
• Common abstraction mechanisms
1. Functional Abstraction
2. Data Abstraction
3. Control Abstraction
Functional abstraction
• This involves the use of parameterized subprograms. Functional
abstraction can be generalized as collections of subprograms referred
to as ‘groups’.
• Within these groups there exist routines which may be visible or
hidden. Visible routines can be used within the containing groups as
well as within other groups, whereas hidden routines are hidden from
other groups and can be used within the containing group only.
Santosh V. Kadam ,W.I.E.T. 16
Data abstraction
• This involves specifying data that describes a data object. For
example, the data object window encompasses a set of
attributes (window type, window dimension) that describe the
window object clearly. In this abstraction mechanism,
representation and manipulation details are ignored.
• Details of the data elements are not visible to the users of
data. Data Abstraction forms the basis for Object Oriented
design approaches.
Control abstraction
• This states the desired effect, without stating the exact
mechanism of control. For example, if and while statements in
programming languages (like C and C++) are abstractions of
machine code implementations, which involve conditional
instructions.
• In the architectural design level, this abstraction mechanism
permits specifications of sequential subprogram and exception
handlers without the concern for exact details of
implementation.
Santosh V. Kadam ,W.I.E.T. 17
Architecture
• The complete structure of the software is known as
software architecture.
• Structure provides conceptual integrity for a system in a
number of ways.
• The architecture is the structure of program modules
where they interact with each other in a specialized way.
• The components use the structure of data.
• The aim of the software design is to obtain an architectural
framework of a system.
• The more detailed design activities are conducted from the
framework.

Santosh V. Kadam ,W.I.E.T. 18

• Patterns
A design pattern describes a design structure that solves a particular design problem in a
specified content.
The objective of each pattern is to provide an insight to a designer who can determine the
following.
1. Whether the pattern can be reused .
2. Whether the pattern is applicable to the current project .
3. Whether the pattern can be used to develop a similar but functionally or structurally
different design pattern.
Types of Design Patterns
• Software engineer can use the design pattern during the entire software design process.
1. Architectural patterns: These patterns are high-level strategies that refer to the overall
structure and organization of a software system. That is, they define the elements of a
software system such as subsystems, components, classes, etc. In addition, they also
indicate the relationship between the elements along with the rules and guidelines for
specifying these relationships. Note that architectural patterns are often considered
equivalent to software architecture.
2. Design patterns: These patterns are medium-level strategies that are used to solve design
problems. They provide a means for the refinement of the elements (as defined by
architectural pattern) of a software system or the relationship among them. Specific design
elements such as relationship among components or mechanisms that affect component-
to-component interaction are addressed by design patterns. Note that design patterns are
often considered equivalent to software components.
3. Idioms: These patterns are low-level patterns, which are programming-language specific.
They describe the implementation of a software component, the method used for
interaction among software components, etc., in a specific programming language. Note
that idioms are often termed as coding patterns.
Santosh V. Kadam ,W.I.E.T. 19
Problem Partitioning
• For small problem, we can handle the entire problem at once but for the
Large problem, divide the problem into smaller pieces so that each piece
can be captured separately.
• For software design, the goal is to divide the problem into manageable
pieces.
• These pieces cannot be entirely independent of each other as they
together form the system. They have to cooperate and communicate to
solve the problem. This communication adds complexity.
• The structure of the program can be partitioned either horizontally or
vertically.
• In horizontal partitioning, the control modules are used to communicate
between functions and execute the functions.
• Horizontal partitioning has some disadvantage also. It requires to pass
more data across the module interface, which makes the control flow of
the problem more complex. This usually happens in cases where data
moves rapidly from one function to another.
• In vertical partitioning, the functionality is distributed among the
modules–in a top-down manner. The modules at the top level
called control modules perform the decision-making and do little
processing whereas the modules at the low level called worker
modules perform all input, computation and output tasks.
Santosh V. Kadam ,W.I.E.T. 20
Benefits of Problem Partitioning
1. Software is easy to understand.
2. Software becomes simple.
3. Software is easy to test.
4. Software is easy to modify.
5. Software is easy to maintain.
6. Software is easy to expand.
Santosh V. Kadam ,W.I.E.T. 21
 Modularity
• Modularity specifies to the division of software into separate
modules which are differently named and addressed and are
integrated later on in to obtain the completely functional
software.
• It is the only property that allows a program to be intellectually
manageable.
• Single large programs are difficult to understand and read due
to a large number of reference variables, control paths, global
variables, etc.
The desirable properties of a modular system are:
1. Each module is a well-defined system that can be used with
other applications.
2. Each module has single specified objectives.
3. Modules can be separately compiled and saved in the library.
4. Modules should be easier to use than to build.
5. Modules are simpler from outside than inside.
Santosh V. Kadam ,W.I.E.T. 22
Advantages of Modularity
1. It allows large programs to be written by several or different people
2. It encourages the creation of commonly used routines to be placed in
the library and used by other programs.
3. It simplifies the overlay procedure of loading a large program into main
storage.
4. It provides more checkpoints to measure progress.
5. It provides a framework for complete testing, more accessible to test
6. It produced the well designed and more readable program.

Disadvantages of Modularity
1. Execution time maybe, but not certainly, longer
2. Storage size perhaps, but is not certainly, increased
3. Compilation and loading time may be longer
4. Inter-module communication problems may be increased
5. More linkage required, run-time may be longer, more source lines must
be written, and more documentation has to be done

Santosh V. Kadam ,W.I.E.T. 23

Functional Independence
• Functional independence is achieved by developing functions
that perform only one kind of task and do not excessively
interact with other modules.
• Independence is important because it makes implementation
more accessible and faster.
• The independent modules are easier to maintain, test, and
reduce error propagation and can be reused in other programs
as well.
• Thus, functional independence is a good design feature which
ensures software quality.
It is measured using two criteria:
i. Cohesion: It measures the relative function strength of a
module.
ii. Coupling: It measures the relative interdependence among
modules.

Santosh V. Kadam ,W.I.E.T. 24

Increase Cohesion
• Cohesion means grouping things that make sense together — sort of as one
package.
• From a development point of view, you can choose to design your packages,
modules, or classes cohesively.
• Cohesion brings about the organization of your code, and it will make it much
easier to find things, thus simplifying the system. Everything will make more sense.
• Example : math package in Python. The math package is cohesive because it has
everything related to mathematical operations within it. You will not find anything
within it that is not mathematical.
Reducing Coupling
• In simple terms, coupling occurs when packages, modules, classes, or files are very
interdependent.
• If one package has some changes to it or breaks, the whole system could be
compromised because some of its parts depend on the package that has
malfunctioned.
• Having a highly coupled system is easier to implement in the beginning, but it will
be much harder to debug and fix should any component fail.
• Oftentimes, systems are so highly coupled that it is very difficult to determine
where the coupling is occurring.
• There may be a situation where you have no idea why one package is not working
when another one hidden under four levels of coupling might be malfunctioning.
• If you can make your components as independent as possible, you will have an
easier time debugging. That is a better design. 25
Information hiding
• IEEE defines information hiding as ‘the technique of encapsulating
software design decisions in modules in such a way that the module’s
interfaces reveal as little as possible about the module’s inner workings;
thus each module is a ‘black box’ to the other modules in the system.
• The fundamental of Information hiding is that modules should be specified
such that, data include within a module is inaccessible to other modules
that do not need for such information.
• The use of information hiding as design criteria for modular system
provides the most significant benefits when modifications are required
during testing's and later during software maintenance.
• This is because as most data and procedures are hidden from other parts
of the software, inadvertent errors introduced during modifications are less
likely to propagate to different locations within the software.
• Information hiding is of immense use when modifications are required
during the testing and maintenance phase.
Advantages associated with information hiding
1. Leads to low coupling
2. Emphasizes communication through controlled interfaces
3. Decreases the probability of adverse effects
4. Restricts the effects of changes in one component on others
5. Results in higher quality software. 26
Refinement
• Refinement is a top-down design approach.
• It is a process of elaboration.
• A program is established for refining levels of procedural
details.
• A hierarchy is established by decomposing a statement
of function in a stepwise manner till the programming
language statement are reached.
• Software designers start the stepwise refinement process by
creating a sequence of compositions for the system being
designed.
• Each composition is more detailed than the previous one
and contains more components and interactions.
• The earlier compositions represent the significant
interactions within the system, while the later compositions
show in detail how these interactions are achieved. 27
Refactoring
• It is a reorganization technique which simplifies the design of
components without changing its function behavior.
• Refactoring is the process of changing the software system in a way
that it does not change the external behavior of the code still improves
its internal structure.
• During the refactoring process, the existing design is checked for any
type of flaws like redundancy, poorly constructed algorithms and data
structures, etc., in order to improve the design.
• For example, a design model might yield a component which exhibits
low cohesion (like a component performs four functions that have a
limited relationship with one another). Software designers may decide
to refactor the component into four different components, each
exhibiting high cohesion. This leads to easier integration, testing, and
maintenance of the software components.
Design classes
• The model of software is defined as a set of design classes.
• Every class describes the elements of problem domain and that focus
on features of the problem which are user visible.

Santosh V. Kadam ,W.I.E.T. 28

Strategy of Design
• A good system design strategy is to organize the
program modules in such a method that are easy to
develop and latter too, change.
• Structured design methods help developers to deal
with the size and complexity of programs.
• Analysts generate instructions for the developers
about how code should be composed and how pieces
of code should fit together to form a program.
To design a system, there are two possible approaches:
1. Top-down Approach
2. Bottom-up Approach
Santosh V. Kadam ,W.I.E.T. 29
Top-down Approach

30
 Bottom-up Approach
• A bottom-up approach begins with the lower details and moves towards
up the hierarchy, as shown in fig. below
• This approach is suitable in case of an existing system.
• Bottom-Up Model is a system design approach where the parts of a
system are defined in details. Once these parts are designed and
developed, then these parts or components are linked together to
prepare a bigger component. This approach is repeated until the
complete system is built.
• The advantage of Bottom-Up Model is in making decisions at very low
level and to decide the re-usability of components.

31
 Key Bottom-Up Model Top-Down Model
In Bottom-Up Model, the focus is
In Top-down Model, the focus is on
on identifying and resolving
breaking the bigger problem into
Focus smallest problems and then
smaller one and then repeat the
integrating them together to
process with each problem.
solve the bigger problem.
Bottom-Up Model is mainly used Top-Down Model is followed by
Language by object oriented programming structural programming languages
languages like Java, C++, etc. like C, Fortran, etc.
Bottom-Up model is better suited
Top-down model has high ratio of
as it ensures minimum data
Redundancy redundancy as the size of project
redundancy and focus is on re-
increases.
usability.
Bottom-Up model have high Top-down model has tight coupling
Interaction interactivity between various issues and low interactivity between
modules. various modules.
Bottom-up model is based on Top-down model is based on
Approach
composition approach. decomposition approach.
In Bottom-Up, sometimes it is
In Top-Down, it may not be possible 32
to
difficult to identify overall
Santosh V. Kadam ,W.I.E.T.
Issues break the problem into set of smaller
functionality of system in initial
 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.
Santosh V. Kadam ,W.I.E.T. 33
 Coupling
• Coupling effectively represents how the modules can
be “connected” with other module or with the
outside world.
• Coupling is a measure of interconnection among
modules in a program structure.
• Coupling depends on the interface complexity
between modules.
• The goal is to strive for lowest possible coupling
among modules in software design.
• The property of good coupling is that it should reduce
or avoid change impact and ripple effects. It should
also reduce the cost in program changes, testing and
maintenance. Santosh V. Kadam ,W.I.E.T. 34
 Coupling
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 :
• A good design is the one that has low coupling. Coupling is measured by the
number of relations between the modules. That is, the coupling increases as
the number of calls between modules increase or the amount of shared data
is large. Thus, it can be said that a design with high coupling will have more
errors.

Santosh V. Kadam ,W.I.E.T. 35

Santosh V. Kadam ,W.I.E.T. 36
 Types of Coupling
• No Direct Coupling: There is no direct coupling
between M1 and M2.In this case, modules are
subordinates to different modules. Therefore, no
direct coupling.

Santosh V. Kadam ,W.I.E.T. 37

 Data Coupling
• When data of one module is passed to another module, this is called data coupling.
• Data coupling is more commonly used in procedure-oriented and object-oriented
software programming.
Example
• Let us consider an example program that passes values between functions, thereby
establishing a data coupling.
main( ) {
int x, y, z, sum ; //declare variables
printf ( "\nEnter three numbers " ) ;
scanf ( "%d %d %d", &x, &y, &z ) ;
sum = calculate ( x, y, z ) ; //data is passed through the parameters
printf ( "\nSum = %d", sum ) ;
}
calculate ( int d,e,f ) {
int g ;
g= d +e +f ;
return ( g) ;
}
Output
Enter three numbers 10 20 30 Sum = 60
Santosh V. Kadam ,W.I.E.T. 38
• Data coupling is a very strong form of coupling, and it has
its own advantages and disadvantages :
Advantages
• Data coupling is the best form of coupling amongst all the
other types of couplings.
• If the argument list is small, using data coupling is very
much advisable.
• Data coupling is the loosest form of coupling.
• Using the data coupling properly will endure good results
in the program.
Disadvantages
• If there are many parameters passed between the
modules, maintaining the same becomes a difficult task.
• The usage of too many parameters indicates that the
partitioning is not properly done between the modules. 39
Santosh V. Kadam ,W.I.E.T.
 Stamp Coupling
• Two modules are stamp coupled if they communicate using composite data items
such as structure, objects, etc. When the module passes non-global data
structure or entire structure to another module, they are said to be stamp
coupled. For example, passing structure variable in C or object in C++ language to
a module.
• A component passes a data structure to another component that does not have
access to the entire structure. Requires a second component to know how to
manipulate the data structure (e.g., needs to know about the implementation).
• May be necessary due to efficiency factors: this is a choice made by insightful
designers, not lazy programmer.
Stamp Coupling Example
Address verification
Address verification accepts a Customer data structure as an argument,
“parses it” and verifies the address
bool VerifyAddress (Customer customer) {…}
Better
bool VerifyAddress (
String address1,
String address2,
String city,
String state,
String zipcode) {…} 40
 Control Coupling
• Control Coupling exists among two modules if data from one module is
used to direct the structure of instruction execution in another.
• A component passes control parameters to coupled components.
• The control coupling process falls under the loosely coupled model.
• May be good or bad depending upon the situation. Bad when the
component must be aware of internal structure and logic of another
component. Good if parameters allow factoring and reuse of functionality
Control Coupling Example
Acceptable :A sort function that accepts a comparison function as an
argument.
Component p calls component q and q returns a flag indicating an error
(if any) occurred.
Unacceptable: Component p calls component q and q returns a string
indicating the error (if any) that occurred.
• Why is this bad?
– modules are not independent
• module b must know the internal structure of module a
• affects reusability
Santosh V. Kadam ,W.I.E.T. 41
 Example
• bool foo(int x){
if (x == 0)
return false;
else
return true;
}
void bar(){
// Calling foo() by passing a value which controls its flow:
foo(1);
}

Santosh V. Kadam ,W.I.E.T. 42

 External Coupling
• External coupling refers to the dependence of multiple modules related to
external factors.
• External Coupling arises when two modules share an externally imposed
data format, external files, infrastructure system, communication
protocols, or device interface.
• Two or more modules may be connected to a common part of the
background external to the software.
• External coupling falls under high level of coupling i.e. tight coupling which
is undesirable but probably necessary.
• External coupling is related to the communication to external devices
rather than a common data or flow of data.
• Any change performed by one module on external file or a communication
protocol will definitely influence other modules. These changes can be
considered as beneficial for all other modules as well as problematic.
• It is advisable to have a weak external coupling in the modules to avoid
the conflict between them.
Example : Suppose the modules in information system development are using
a common file format to read and store the files, but one of the module
demands for a different file format; it becomes objectionable for other
modules to handle. Santosh V. Kadam ,W.I.E.T. 43
 Common Coupling
• Two modules are common coupled if they share information through
some global data items.
• All components have read/write access to a global data block.
• Components exchange data using the global data block (instead of
arguments).
• A single component with write access where all other components have
read access is not Common Coupling.
• Have to look at many components to determine the current state of a
variable.
• Changes in one component to the declaration requires changes in all
other components. Identical list of global variables must be declared for
component to be reused.
• Why is this bad?
– resulting code is unreadable ccb

• modules can have side-effects cca

• must read entire module to understand

– difficult to reuse
– module exposed to more data than necessary global variable
– Usually, common coupling offers tight coupling which
44
reduces the module’s flexibility and re-usability.
 Content Coupling
• Content Coupling exists among two modules if they share code,
e.g., a branch from one module into another module.
• Example
– module a modifies statements of module b
– module a refers to local data of module b in terms of some
numerical displacement within b
– module a branches into local label of module b
• Why is this bad?
– almost any change to b requires changes to a

Santosh V. Kadam ,W.I.E.T. 45

Santosh V. Kadam ,W.I.E.T. 46
 Advantages & Disadvantages
Advantages
• Low coupling components do not force ripple effect
to other components
• Low coupled components can be reused
• With Low Coupling among components ,system can
be build faster
Disadvantages
• High coupling components are difficult to
understand.
• High coupling Component forces change in other
components if one component changes.
• High coupling slows down the development process.
Santosh V. Kadam ,W.I.E.T. 47
 Module Cohesion
• In computer programming, cohesion defines to the degree to which the
elements of a module belong together.
• Thus, cohesion measures the strength of relationships between pieces
of functionality within a given module.
• For example, in highly cohesive systems, functionality is strongly related.
• Cohesion is an ordinal type of measurement and is generally described
as "high cohesion" or "low cohesion.”

Santosh V. Kadam ,W.I.E.T. 48

Santosh V. Kadam ,W.I.E.T. 49
Functional Cohesion
• The best or highest cohesion among all the cohesion types
is functional cohesion.
• In the functional cohesion system, all kinds of essential
elements which are used for a single computation are
grouped in a single component which helps to perform the
tasks and functions smoothly.
Examples of Functional Cohesion
• One of the most common example of functional cohesion
includes reading transaction records because all the
elements related to single transaction are involved in it.
• When a passenger books a ticket in an airline service, then
assigning a seat to the passenger is also an example of
functional cohesion.

Santosh V. Kadam ,W.I.E.T. 50

Advantages of Functional Cohesion
• There are some advantages of functional cohesion which are given
below:
• Functional cohesion helps in error reduction from the module because
it reduces the complexity of the module. When the complexity of the
module becomes less, then the modules generate less errors. Task of
the modules works more independently because of functional
independence.
• Functional cohesion of the module helps to increase the reusability of
the module. It will help application developers to easily find the most
needed and used component among the cohesive set of operations
which is provided by the module, which helps to increase the
robustness of the system.
• Understandability is one of the most important advantages of
functional cohesion. Because the components of the module have less
complexity as these are functionally independent, so it is easy for the
programmer to understand.
• In functional cohesion, the components of one module are not fully
connected with the other components of other modules. So, it can be
understood that modules are in an isolated state during functional
cohesion.
Santosh V. Kadam ,W.I.E.T. 51
Sequential Cohesion
• A module is said to possess sequential
cohesion if the element of a module form the
components of the sequence, where the
output from one component of the sequence
is input to the next.
• For example, a function is reading data or
information from a file and processes the data.
• Sequential cohesion usually helps in data flow
between the parts of the different modules.

Santosh V. Kadam ,W.I.E.T. 52

Example
• Sequential cohesion can be best explained with the help of a binary search
example.
• A binary search is a technique that is used to find out an element in the list. To
perform a binary search, the following steps must be followed:
Step 1: The user must input the list of elements.
Step 2: The list given by the user must be sorted.
Step 3: The middle element from the sorted list must be obtained by dividing the
number of elements in the list by 2.
Step 4: Using the middle element, the presence/absence of an element to be
searched for must be determined.
Step 5: The result must be displayed to the user as “Element found “or “Element
Not found”.
• The data elements that are given by the user become the input for the sorting
process in the ascending or descending order.
• The sorted list (the output of the sorting process becomes the input to find out
the middle term).
• The output of the middle term finding process becomes the input to determine
whether the element to be searched is in the list or not.
• The output of the search process then becomes the input to decide whether to
display to the user the message - “Element found” or “Element not Found”.
• In all the above said four steps, it is evident that there is sequential cohesion in
the binary search module, that is, how the output of one segment becomes the
input for another segment. Santosh V. Kadam ,W.I.E.T. 53
Advantages of Sequential Cohesion
• Sequential cohesion helps to understand the system easily.
• Sequential cohesion makes the maintenance process
simpler.
• Sequentially, cohesive system modules can be reused as
many times as per the user’s need.
Disadvantages of Sequential Cohesion
• Since the output of one component becomes the input to
another component, a fallacy in any one of the components
will be reflected with its connected components also.
Applications
• Sequential cohesion is used in software programs in which
the continuity of the flow of information needs to be
preserved through all the modules.
• Sequential cohesion occurs more commonly in the software
programs that use mathematical calculations to obtain their
desired result
Santosh V. Kadam ,W.I.E.T. 54
Communicational Cohesion
• In a cohesion system, when two elements work
on the same input data and also participates to
produce the same output data, then the cohesion
is known as communicational cohesion.
• A module is said to have communicational
cohesion, if all tasks of the module refer to or
update the same data structure, e.g., the set of
functions defined on an array or a stack.
• For example, the user tries to update the data
into the database and after that, sends that data
to the printer.
Santosh V. Kadam ,W.I.E.T. 55
 Advantages of Communicational Cohesion
• Communicational cohesion is considered as a good
cohesion. Due to its robust quality, the
communication between different components of a
module is established properly.
• Understanding the ability between different
components of a module is one of the most
important advantages of communicational cohesion.
Since the components of the modules work on the
same database and at the same time and if there is
no understanding between those components, then
the functions will not work properly.
• In communicational cohesion, the components of
one module are semi connected with the other
components of other modules, which hold the
benefits of less dependencies between the modules.
Santosh V. Kadam ,W.I.E.T. 56
Procedural Cohesion
• A module is said to be procedural cohesion if the
set of purpose of the module are all parts of a
procedure in which particular sequence of steps
has to be carried out for achieving a goal, e.g.,
the algorithm for decoding a message.
• In short, it ensures the execution order. In
procedural cohesion, the connection between
the actions are very weak and unlikely to be
reusable.
• For example, to calculate students’ annual result
after exam, print the students’ detailed record.

Santosh V. Kadam ,W.I.E.T. 57

Temporal Cohesion
• In temporal cohesion, all the functions and the methods of a modules are
executed at the same time.
• In this cohesion, timing plays a very important role between the different
elements of the module.
• A module is said to be in temporal cohesion when all the methods and
functions are executed in the same time span.
• Temporal cohesion holds the code for initializing all the parts of the module.
Example 1
init( )
{
check_memory( );
check_harddisk( );
initialize ports ( );
display_login_screen ( );
}
Although there is no relationship or any similarities in the functionalities of the
source codes among them, the only relationship that prevails is that all the
functions in the module in it gets processed in the same time frame. The
processes terminate once the compiler executes the init module.

Santosh V. Kadam ,W.I.E.T. 58

Advantages of temporal cohesion:
• Temporal cohesion helps the execution of functions with varied
functionalities under the same time frame.
• Temporal cohesion certainly ranks a step above logical cohesion
for the reason that here all the elements get executed at every
invocation.
Disadvantages of temporal cohesion
• Temporal cohesion does not support the concept of re-usability
to a greater extent.
• Temporal cohesion leads to tight coupling. Tight coupling means
that there will be more bonding between the modules and less
bonding between the data inside the modules.
• Maintenance activities in temporal cohesion segments are very
difficult as the programmer must share the common codes that
are related only with the time frames.
Applications
• Temporal cohesion is mostly applied for catching exception
sequences in software programming.
• Temporal cohesion is used in programming modules where they 59
get invoked only at their intended timings to get processed.
 Logical Cohesion
• In logical cohesion, all the elements of a module
execute the same kind of task or operation and the
elements are not connected functionally but are
connected logically.
• A module is said to be logically cohesive if all the
elements of the module perform a similar operation.
• In this method, the operations are related with each
other, but the functions are not similar.
• For example Error handling, data input and data output,
etc.
• For example, reading of the input data, producing of
the output data.

Santosh V. Kadam ,W.I.E.T. 60

Example for Logical Cohesion
• Consider a print function. It may happen that we can give several print
commands for different files at once. Now, the output will be different
files & contents printed on paper. Hence, there are a set of print functions
generating different output reports, arranged into a single module.
Writing programs for modules- Understanding Logical Cohesion
• Modules are effective in the sense that the individual modules are now
existing as a stand-alone function and may be reused repeatedly. Suppose
we write a program which adds two numbers. We may simply put it like
this
int main()
{
int var1, var2;
cout<< “Enter number1 input”;
cin>>var1;
cout<< “Enter number2 input”;
cin>>var2;
cout<<“Sum is :” <<var1+var2;
}
Santosh V. Kadam ,W.I.E.T. 61
• It is a very simple program, and easy to write. Now, consider a scenario where
addition of two numbers is to be done 10 times in your program. In such cases,
it will be tedious to write the same lines of code ten times. This is where
modular design helps. The module will be prepared as shown below:
int sumFunc(int var1, int var2)
{
return var1+var2;
}
int main()
{
int sum=0;
cout<< “The program will add 3 seven times!”;
for(int i=0;i<10;i++)
sum= sumFunc(sum,3); //Reusing the module/function sumFunc
cout<<"Sum is"<<sum;
}
The output of the program is as follows:
The program will add 3 Ten times!
Sum is 30
The above program is now much more effective as it is logically bound in a function.

Santosh V. Kadam ,W.I.E.T. 62

Coincidental Cohesion
• The worst-case cohesion is known as
coincidental cohesion.
• A module is said to have coincidental cohesion if
it performs a set of tasks that are associated with
each other very loosely, if at all
• In coincidental cohesion, the elements of the
module are related arbitrarily because of their
location in source code. Otherwise they are not
conceptually related with each other.

Santosh V. Kadam ,W.I.E.T. 63

 Advantages
• High cohesion among system components
results in better program design
• High cohesion components can be easily reused.
• High cohesion components are more reliable.
Disadvantages
• Low cohesion components are difficult to
maintain.
• Low cohesion components cannot be reused.
• Low cohesion components are difficult to
understand.
• Low cohesion components are less reliable.
Santosh V. Kadam ,W.I.E.T. 64
Benefits of High Cohesion
• Readability: Closely related functons are contained in
single module.
• Maintainability: Debugging tends to be contained in a
single module.
• Reusability: Classes that have concentrated
functionalities are not polluted with useless functions
Benefits of Low Coupling
• Maintainability: Changes are confined in a single
module.
• Testability: Modules involved in unit testing can be
limited to minimum.
• Readability: Classes that need to be analyzed are kept
at minimum.

Santosh V. Kadam ,W.I.E.T. 65

Coupling Cohesion

Coupling is also called Inter-Module Cohesion is also called Intra-Module

Binding. Binding.
Coupling shows the relationships Cohesion shows the relationship within
between modules. the module.
Coupling shows the Cohesion shows the module's
relative independence between the relative functional strength.
modules.
While creating, you should aim for low While creating you should aim for high
coupling, i.e., dependency among cohesion, i.e., a cohesive component/
modules should be less. module focuses on a single function (i.e.,
single-mindedness) with little interaction
with other modules of the system.

In coupling, modules are linked to the In cohesion, the module focuses on a

other modules. single thing.

Santosh V. Kadam ,W.I.E.T. 66

 Software Design Levels
• Software design yields three levels of results:
1. Architectural Design
2. High-level Design
3. Detailed Design

Santosh V. Kadam ,W.I.E.T. 67

 Architectural Design
• Architectural design is the specification of the major components of a
system, their responsibilities, properties, interfaces, and the relationships
and interactions between them. In architectural design, the overall
structure of the system is chosen, but the internal details of major
components are ignored.
• 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.
Issues in architectural design includes:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces
4. Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
5. Communication and interaction between components.
• The architectural design adds important details ignored during the
interface design. Design of the internals of the major components is
ignored until the last phase of theV. Kadam
Santosh design.
,W.I.E.T. 68
 High Level Design
• High Level Design in short HLD is the general system design means it
refers to the overall system design.
• It describes the overall description/architecture of the application.
• 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.
• It includes the description of system architecture, data base design,
brief description on systems, services, platforms and relationship
among modules.
• It is also known as macro level/system design.
• It is created by solution architect.
• It converts the Business/client requirement into High Level Solution.
• It is created first means before Low Level Design.
Santosh V. Kadam ,W.I.E.T. 69
 Detailed/Low Level Design
• Low Level Design in short LLD is like detailing HLD
means it refers to component-level design process.
• It describes detailed description of each and every
module means it includes actual logic for every
system component and it goes deep into each
modules specification.
• It is also known as micro level/detailed design.
• It is created by designers and developers.
• It converts the High Level Solution into Detailed
solution.
• It is created second means after High Level Design.
Santosh V. Kadam ,W.I.E.T. 70
 Detailed Design
• Design is the specification of the internal elements of all major system
components, their properties, relationships, processing, and often their
algorithms and the data structures.
• Detailed design deals with the implementation part of what is seen as a
system and its sub-systems in the previous two designs.
• It is more detailed towards modules and their implementations.
• It defines logical structure of each module and their interfaces to
communicate with other modules.
The detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces
4. Unit states and state changes
5. Data and control interaction between units
6. Data packaging and implementation, including issues of scope and
visibility of program elements
7. Algorithms and data structures
Santosh V. Kadam ,W.I.E.T. 71
S.No HIGH LEVEL DESIGN LOW LEVEL DESIGN

High Level Design is the general Low Level Design is like detailing HLD
01. system design means it refers to means it refers to component-level
the overall system design. design process.

High Level Design in short called as

02. Low Level Design in short called as LLD.
HLD.

It is also known as macro It is also known as micro level/detailed

03.
level/system design. design.

It describes the overall

It describes detailed description of each
04. description/architecture of the
and every module.
application.

High Level Design expresses the Low Level Design expresses details
05.
brief functionality of each module. functional logic of the module.

It is created by designers and

06. It is created by solution architect.
developers. 72
S.No. HIGH LEVEL DESIGN LOW LEVEL DESIGN

Here in High Level Design the Here in Low Level Design participants are
07. participants are design team, review design team, Operation Teams, and
team, and client team. Implementers.

It is created first means before Low It is created second means after High Level
08.
Level Design. Design.

In HLD the input criteria is Software In LLD the input criteria is reviewed High
09.
Requirement Specification (SRS). Level Design (HLD).

High Level Solution converts the

Low Level Design converts the High Level
10. Business/client requirement into High
Solution into Detailed solution.
Level Solution.

In HLD the output criteria is data

In LLD the output criteria is program
11. base design, functional design and
specification and unit test plan.
review record.

Santosh V. Kadam ,W.I.E.T. 73

 Developing a Design Model
• Software design is model of software which translates the requirements
into finished software product in which the details about software data
structures, architecture, interfaces and components that are necessary to
implement the system are given.
• To develop a complete specification of design (design model), four design
models are needed. These models are listed below.
Data design: This specifies the data structures for implementing the
software by converting data objects and their relationships identified
during the analysis phase. Various studies suggest that design
engineering should begin with data design, since this design lays the
foundation for all other design models.
Architectural design: This specifies the relationship between the structural
elements of the software, design patterns, architectural styles, and the
factors affecting the ways in which architecture can be implemented.
Component-level design: This provides the detailed description of how
structural elements of software will actually be implemented.
Interface design: This depicts how the software communicates with the
system that interoperates with it and with the end-users.
Santosh V. Kadam ,W.I.E.T. 74
Santosh V. Kadam ,W.I.E.T. 75
 Data design
• Data design is the first design activity, which results in less complex,
modular and efficient program structure.
• The information domain model developed during analysis phase is
transformed into data structures needed for implementing the software.
• The data objects, attributes, and relationships depicted in entity
relationship diagrams and the information stored in data dictionary
provide a base for data design activity.
• During the data design process, data types are specified along with the
integrity rules required for the data.
• For specifying and designing efficient data structures, these principles
should be followed :
1. The data structures needed for implementing the software as well-as
the operations that can be applied on them should be identified.
2. A data dictionary should be developed to depict how different data
objects interact with each other and what constraints are to be
imposed on the elements of data structure.
3. Stepwise refinement should be used in data design process and
detailed design decisions should be made later in the process.
Santosh V. Kadam ,W.I.E.T. 76
4. Only those modules that need to access data stored in a data structure
directly should be aware of the representation of the data structure.
5. A library containing the set of useful data structures along with the
operations that can be performed on them should be maintained.
6. Language used for developing the system should support abstract data
types.
• The structure of data can be viewed at three levels,
namely, program component level, application level, and business level.
• At the program component level, the design of data structures and the
algorithms required to manipulate them is necessary, if high-quality
software is desired.
• At the application level, it is crucial to convert the data model into
a database so that the specific business objectives of a system could be
achieved.
• At the business level, the collection of information stored in different
databases should be reorganized into data warehouse, which enables
data mining that has an influential impact on the business.

Santosh V. Kadam ,W.I.E.T. 77

 Architectural Design
• The software needs the architectural design to represents the design of software.
• IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the
framework for the development of a computer system.”
• The architectural design is the design process for identifying the subsystems
making up the system and framework for subsystem control and communication.
• The goal of architectural design is to establish the overall structure of software
system.
• Architectural design represents the link between design specification and actual
design process.
• In architectural design logical system components and communication between
them are identified.
• The common activities in design process are
The system is subdivided into principle subsystems
• System structuring – components and communications between these subsystems
are identified.
• Control modelling – A model of control relationships between different parts of the
system is established.
• Modular decomposition– The identified subsystems are decomposed into
modules.
Santosh V. Kadam ,W.I.E.T. 78
 Functions of Architectural Design
• An architectural design performs the following functions.
1. It defines an abstraction level at which the designers can specify the
functional and performance behavior of the system.
2. It acts as a guideline for enhancing the system (when ever required) by
describing those features of the system that can be modified easily
without affecting the system integrity.
3. It evaluates all top-level designs.
4. It develops and documents top-level design for the external and internal
interfaces.
5. It develops preliminary versions of user documentation.
6. It defines and documents preliminary test requirements and the
schedule for software integration.
7. The sources of architectural design are listed below.
8. Information regarding the application domain for the software to be
developed
9. Using data-flow diagrams
10. Availability of architectural patterns and architectural styles.

Santosh V. Kadam ,W.I.E.T. 79

 Software Architecture
• The software architecture gives the hierarchical structure of software
components and their interactions.
• In software architecture the software model is designed and structure of
that model is partitioned horizontally or vertically.
• Each model represents different perspective on the architecture for
instance :
Structural model-Represents architecture as an organized collection of
components.
Framework model- Identifies the repeatable architectural design
frameworks and event thereby increases the level of abstraction.
Dynamic model – Represents the behavior aspects of the program
architecture. Behavior means change in functioning of the system on
occurrence of external events.
Process model – Focuses on the design of the business or technical
process.
Functional model – It can be used to represent functional hierarchy of the
system.
Santosh V. Kadam ,W.I.E.T. 80
 Architectural Design Output
• The architectural design process results in an Architectural Design
Document (ADD). This document consists of a number of graphical
representations that comprises software models along with associated
descriptive text.
• The software models include static model, interface model, relationship
model, and dynamic process model. They show how the system is
organized into a process at run-time.
• Architectural design document gives the developers a solution to the
problem stated in the Software Requirements Specification (SRS).
• Note that it considers only those requirements in detail that affect the
program structure.
• In addition to ADD, other outputs of the architectural design are listed
below.
1. Various reports including audit report, progress report, and
configuration status accounts report
2. Various plans for detailed design phase, which include the following
i. Software verification and validation plan
ii. Software configuration management plan
iii. Software quality assurance plan
iv. Software project management plan. 81
 Architectural Design Styles
• The architectural model or style is a pattern for creating the system
architecture, for given problem. However, most of the large systems are
heterogeneous and do not follow single architectural style.
• System categories define the architectural style.
1. Components : They perform a function. For example : Database, simple
computational modules, clients, servers and filters.
2. Connectors : Enable communications. They define how the components
communicate, co-ordinate and co-operate. For example, Call, event
broadcasting, pipes.
3. Constraints : Define how the system can be integrated.
4. Semantic models : Specify how to determine a system’s overall
properties from the properties of its parts.
The commonly used architectural styles are
• Data centered architectures
• Data flow architectures
• Call and return architectures
• Object oriented architectures
• Layered architectures. Santosh V. Kadam ,W.I.E.T. 82
 Data Centered Architectures
• A data store will reside at the center of this architecture
and is accessed frequently by the other components that
update, add, delete or modify the data present within the
store.
• The figure illustrates a typical data centered style. The
client software access a central repository. Variation of
this approach are used to transform the repository into a
blackboard when data related to client or data of interest
for the client change the notifications to client software.
• This data-centered architecture will promote integration
ability. This means that the existing components can be
changed and new client components can be added to the
architecture without the permission or concern of other
clients.
• Data can be passed among clients using blackboard
mechanism.
Santosh V. Kadam ,W.I.E.T. 83
Santosh V. Kadam ,W.I.E.T. 84
Advantages of the data-centered architecture
1. Clients operate independently of one another.
2. Data repository is independent of the clients.
3. It adds scalability (that is, new clients can be
added easily).
4. It supports modifiability.
5. It achieves data integration in component-based
development using blackboard.

Santosh V. Kadam ,W.I.E.T. 85

 Data flow architectures
• This kind of architecture is used when input data to be
transformed into output data through a series of
computational manipulative components.
• The figure represents pipe-and-filter architecture since it uses
both pipe and filter and it has a set of components called
filters connected by pipes.
• Pipes are used to transmit data from one component to the
next.
• Each filter will work independently and is designed to take
data input of a certain form and produces data output to the
next filter of a specified form. The filters don’t require any
knowledge of the working of neighboring filters.
• If the data flow degenerates into a single line of transforms,
then it is termed as batch sequential. This structure accepts
the batch of data and then applies a series of sequential
components to transform it.
Santosh V. Kadam ,W.I.E.T. 86
Santosh V. Kadam ,W.I.E.T. 87
• Advantages associated with this architecture are :
1. It supports reusability.
2. It is maintainable and modifiable.
3. It supports concurrent execution.
Disadvantages associated with this architecture are:
1. It often degenerates to batch sequential system.
2. It does not provide enough support for
applications requires user interaction.
3. It is difficult to synchronize two different but
related streams.

Santosh V. Kadam ,W.I.E.T. 88

 Call and Return architectures
• It is used to create a program that is easy to scale
and modify. Many sub-styles exist within this
category. Two of them are explained below.
– Remote procedure call architecture: This components is
used to present in a main program or sub program
architecture distributed among multiple computers on a
network.
– Main program or Subprogram architectures: The main
program structure decomposes into number of
subprograms or function into a control hierarchy. Main
program contains number of subprograms that can
invoke other components.

Santosh V. Kadam ,W.I.E.T. 89

Main program or Subprogram architectures
Santosh V. Kadam ,W.I.E.T. 90
Object Oriented architecture
• This architecture is the latest version of call-and-return
architecture.
• It consist of the bundling of data and methods.
• The components of a system encapsulate data and the operations
that must be applied to manipulate the data.
• The coordination and communication between the components
are established via the message passing.
• This architectural style has two important characteristics, which
are listed below.
1. Objects maintain the integrity of the system.
2. An object is not aware of the representation of other objects.
• Advantages associated with the object-oriented architecture are
listed below.
1. It allows designers to decompose a problem into a collection of
independent objects.
2. The implementation detail of objects is hidden from each other
and hence, they can be changed without affecting other
objects. Santosh V. Kadam ,W.I.E.T. 91
 Layered architecture
• A number of different layers are defined with each layer
performing a well-defined set of operations. Each layer
will do some operations that becomes closer to machine
instruction set progressively.
• At the outer layer, components will receive the user
interface operations and at the inner layers, components
will perform the operating system
interfacing(communication and coordination with OS)
• The inner layers are application layer, utility layer and
the core layer.Intermediate layers to utility services and
application software functions.
• In many cases, It is possible that more than one pattern
is suitable and the alternate architectural style can be
designed and evaluated.
Santosh V. Kadam ,W.I.E.T. 92
Santosh V. Kadam ,W.I.E.T. 93
 Example of Layered Architecture

Each layer provides a set of services to the layer above it and acts as a client to the layer
below it. The interaction between layers is provided through protocols (connectors) that
define a set of rules to be followed during interaction. One common example of this
architectural style is OSI-ISO (Open Systems Interconnection-International Organization for
Standardization) communication system.
Santosh V. Kadam ,W.I.E.T. 94
 Component Level Design
• Component is nothing but a model for computer software.
• The OMG (Object Management Group is a computer industry standards
consortium) Unified Modeling Language Specification defines the concept of
component more formally and it is - " Component is a modular, deployable and
replaceable part of system that encapsulates the implementation and exposes
the set of interfaces".
• Components are the part of software architecture and hence they are important
factors in achieving the objectives and requirements of system to be built.
• Components can communicate and collaborate with other components.
• Design models can be prepared using object oriented views and conventional
views.
• The component-level design can be represented by using different approaches.
One approach is to use a programming language while other is to use some
intermediate design notation such as graphical (DFD, flowchart, or structure
chart), tabular (decision table), or text-based (program design language)
whichever is easier to be translated into source code.
• The component-level design provides a way to determine whether the defined
algorithms, data structures, and interfaces will work properly. Note that a
component (also known as module) can be defined as a modular building block
for the software. However, the meaning of component differs according to how
software engineers use it.
Santosh V. Kadam ,W.I.E.T. 95
The components has different views as follows:
1. An object-oriented view
• An object-oriented view is a set of collaborating classes.
• The class inside a component is completely elaborated and it consists of all the
attributes and operations which are applicable to its implementation.
• To achieve object-oriented design it elaborates analysis classes and the
infrastructure classes.
2. The traditional view
• A traditional component is known as module.
• It resides in the software and serves three important roles which are control
component, a problem domain component and an infrastructure component.
• A control component coordinate is an invocation of all other problem domain
components.
• A problem domain component implements a complete function which is needed
by the customer.
• An infrastructure component is responsible for function which support the
processing needed in the problem domain.
3. The Process related view
• This view highlights the building system out of existing components.
• The design patterns are selected from a catalog and used to populate the
architecture.

Santosh V. Kadam ,W.I.E.T. 96

Principles for class-based design component
• Open Closed Principle (OCP)
Any module in OCP should be open for extension and should be closed
for modification. A designer should design a component in such a
manner that some functionalities can added to it if required but in doing
so there should not be any change in the internal design of the
component itself.
1) The Liskov Substitution Principle (LSP)
• This principle was suggested by Liskov.
• The subclass must be substitutable for their base class.
• A component that contains the base class and if that component works
properly then the same component should work properly even if the
derived class of that base class is used by the component as a substitute.
3) Dependency Inversion Principle (DIP)
• It depends on the abstraction and not on concretion. This is because if
some component has to be extended then it becomes easy to enhance it
using other abstract component instead of concrete component.
• Abstraction is the place where the design is extended without difficulty.

Santosh V. Kadam ,W.I.E.T. 97

4) The Interface Segregation Principle (ISP)
• Many client specific interfaces is better than the general
purpose interface
• If a general purpose interface is created then multiple
clients may try to access it for different operations at the
same time.
5) The Release Reuse Equivalency Principle (REP)
• A fragment of reuse is the fragment of release.
• The class components are designed for reuse which is an
indirect contract between the developer and the user.
6) The common closure principle (CCP)
The classes change and belong together i.e the classes
are packaged as part of design which should have the
same address and functional area.
7) The Common Reuse Principle (CRP)
The classes that are not reused together should not be
grouped together. Santosh V. Kadam ,W.I.E.T. 98
 Component Level Design Guideline
Ambler suggested guideline for conducting component level design -
Components :
• Components are the part of architectural model.
• The naming conventions should be established for components. The
component names should be specified from the problem domain. These
names should be meaningful.
Interfaces :
• Interfaces serve important role in communication and collaboration.
• The interface should be drawn as a circle with a solid line connecting it to
another element.
• This indicates that the element to which it is connected offers the
interface.
• The interface should flow from left side of component.
• Only important interfaces must be drawn.
Dependencies and interfaces :
• The dependencies must be shown from left to right.
• The inheritance should be shown from bottom to top i.e. from derived to
base class.
• The component interdependencies should be represented via interfaces. 99
 Interface Design
• Interface design is the specification of the interaction between a system
and its environment.
• An interface is the intersection between the system and the
environment.
Interface = System ∩ Environment

• This phase proceeds at a high level of abstraction with respect to the

inner workings of the system i.e, during interface design, the internal of
the systems are completely ignored and the system is treated as a black
box.
• Attention is focused on the dialogue between the target system and the
users, devices, and other systems with which it interacts.
• The design problem statement produced during the problem analysis step
should identify the people, other systems, and devices which are
collectively called agents.
Santosh V. Kadam ,W.I.E.T. 100
Interface design should include the following details:
1. Precise description of events in the environment,
or messages from agents to which the system
must respond.
2. Precise description of the events or messages
that the system must produce.
3. Specification on the data, and the formats of the
data coming into and going out of the system.
4. Specification of the ordering and timing
relationships between incoming events or
messages, and outgoing events or outputs.
Santosh V. Kadam ,W.I.E.T. 101
 User Interface Design
• User interface, or UI, describes the way in which a human
interacts with a machine. Though technically something as
simple as a light switch could be considered an instrument of
UI, most modern references relate to computers and other
electronic devices.
• The visual part of a computer application or operating system
through which a client interacts with a computer or software.
• It determines how commands are given to the computer or the
program and how data is displayed on the screen.
• UI makes the exchange between users and machines possible.
Without it, this vital form of communication ceases to exist.
Types of User Interface
There are four prevalent types of user interface :
1. Text-Based User Interface Or Command Line Interface.
2. Graphical User Interface
3. Menu-driven Interface
4. Touch screen Graphical Santosh
UserV. Kadam
Interface
,W.I.E.T. 102
 Command Line Interface
• The command line interface is no longer common as a form of basic user
interface in everyday consumer products, but it is still in use under certain
circumstances.
• Command Line Interface requires users to type appropriate instructions
into the command line.
• The computer is commanded to first go to the required file or directory.
From there, a whole host of commands become available, from retrieving
files to running programs.
• This method relies primarily on the keyboard. A typical example of this is
UNIX.
Advantages:
• Simple structure
• Minimal memory usage
• Great for slow-running computers, or those low on memory
• An expert CLI user can give commands and perform tasks much faster
than when using an alternative UI type
Disadvantages:
• Difficult to learn command language
• Complex for novice users
103
• Minimal error message information
 Graphical User Interface
• The graphical user interface, or GUI, is the type of interface with
which the majority of people are the most familiar.
• You interact with these interfaces by using a mouse, track pad, or
other peripheral to point and click on graphics or icons.
• A typical example of this type of interface is any versions of the
Windows operating systems.
Advantages:
• Self-explanatory. Less expert knowledge is required to use it.
• Easy to use. Easier to Navigate and can look through folders quickly
in a guess and check manner.
• Memorizing command lists is not necessary
• Allows for running multiple applications, programs, and tasks
simultaneously. The user may switch quickly from one task to
another and can interact with several different applications.
• Solid support facilities
• The similar format among different programs adds familiarity
Santosh V. Kadam ,W.I.E.T. 104
• WYSIWYG(What You See Is What You Get) makes for
easy design and formatting. WYSIWYG is a type of
editing software that allows users to see and edit
content in a form that appears as it would when
displayed on an interface, webpage, slide presentation
or printed document.

Disadvantages:
• Uses large amounts of memory – although this is less of
a concern as computers get more powerful
• Typically decreased options.
• Usually less customizable. Not easy to use one button
for tons of different variations.

Santosh V. Kadam ,W.I.E.T. 105

 GUI Characteristics
Characteristics Descriptions

Windows Multiple windows allow different information to be displayed

simultaneously on the user's screen.
Icons Icons different types of information. On some systems, icons
represent files. On other icons describes processes.
Menus Commands are selected from a menu rather than typed in a
command language.
Pointing A pointing device such as a mouse is used for selecting choices
from a menu or indicating items of interests in a window.

Graphics Graphics elements can be mixed with text or the same display.

Santosh V. Kadam ,W.I.E.T. 106

 Menu-Driven Interface
• The menu-driven user interface provides you with a range
of commands or options in the form of a list or menu
displayed in full-screen, pop-up, pull-down, or drop-down.
An ATM is an example of a menu-driven interface.
Advantages:
• It is not necessary to remember a long list of manual
commands
• Simple interface for novices
• Self-explanatory menu options
Disadvantages:
• Slower for experienced users
• Limited menu options
• Often requires you to access multiple menu screens to
perform simple functions
Santosh V. Kadam ,W.I.E.T. 107
 Touch screen Graphical User Interface
• The touchscreen GUI is very similar to the regular
GUI, except that you use your fingers or a stylus to
select icons and perform tasks, rather than a
mouse or trackpad.
• Touchscreen GUIs are commonly found on tablets,
smartphones, and medical devices, like the insulin
pump.
• The touchscreen GUI has the same benefits and
disadvantages as standard GUIs, but also offers a
more intimate method of interaction.
• The lack of peripherals makes touch screen GUIs
very convenient.

Santosh V. Kadam ,W.I.E.T. 108

 Other types of User Interface
• Voice User Interface (VUI): These are programs capable of
identifying and interpreting spoken language. As the clearest
example of this, we may mention the recent boom of Artificial
Intelligences (AI), such as SIRI, controlled by means of the
human voice.
• Text Interface: It is mainly employed in the Operating Systems
Programming field, and it is an evolution of the primitive
Command-line-Interface used by the first computer programs.
• Natural User Interface: The term denotes the type of Interface
which identifies and interpret human beings’ natural actions,
such as movement and facial expressions. As an example, we
may mention the videogames with a Kinect interface.
• Brain-computer interface: It is the most innovative kind of
interface existent up to now, and even though it does not yet
count on many daily applications, it is being employed to
control bionic prostheses and to give simple commands to
software by using brain-waves.
Santosh V. Kadam ,W.I.E.T. 109
 UI Design Principles
• While designing the user interface the capability,
need and experience of system or should be
considered.
• The designer should take into account the people’s
physical and mental limitations. For instance a
short memory or in game playing software a child
can recognize pictures rather than text.
• He should also be aware of the fact that people
make mistakes and the interface should tolerate
these mistakes in a friendly manner.
Following design principles are used

Santosh V. Kadam ,W.I.E.T. 110

The Concept of Structural
• This is the initial stage of to design the software application user interface which
deals with overall UI architecture.
• Design should organize the user interface purposefully, in the meaningful and
usual based on precise, consistent models that are apparent and recognizable to
users, putting related things together and separating unrelated things,
differentiating dissimilar things and making similar things resemble one another.
• The structure principle is concerned with overall user interface architecture.
• It provides the structural data of the software application with combined the
application related data and separated the unwanted things.
• This concept makes the software application to be well Organised (meaningful),
Innovative (technological development), understandable (purpose of the software
application) and useful (satisfy certain criteria).
The Concept of Simplicity
• The design should make the simple, common task easy, communicating clearly
and directly in the user's language, and providing good shortcuts that are
meaningfully related to longer procedures.
• User interface should be simple, long lasting, user friendly with user control over
user interface, sustainability, clarification on complexity, accurate throughput
response, maximum usability and user’s language.
• We expect our user do mistakes on UI, justify our data’s, don’t develop busy
interface and explain the rules that are the best tips for the design of user
interface for the software application.
• It will always helps to reduce the number of tasks to complete the total actions111
on the UI and protects the users data into the software application.
The Concept of Visibility:
• The design should make all required options and materials for a given
function visible without distracting the user with extraneous or
redundant data.
• It mainly deals with graphical user interface i.e. the alignment is correct
or not, spelling checking, position of logo or banners, consistency, easy to
navigate with status, color & brightness of UI and without hesitation to
the user. So that the look & feel of the interface should be perfect, clarity,
progressive disclose, transparency and error preventive. We should
emphasis on the performance issue of the UI.
The Concept of Feedback
• The design should keep users informed of actions or interpretation,
changes of state or condition, and bugs or exceptions that are relevant
and of interest to the user through clear, concise, and unambiguous
language familiar to users.
• It always welcomes to change or modify the UI depends upon the user or
client reviews. So the designer always analyse the process, view, any
ambiguity issues, bugs, technological advancement, change of conditions
and to make more user friendly of user interface of the software product.
• For users every action on the UI returns a meaningful and clear reaction
or feedback.
Santosh V. Kadam ,W.I.E.T. 112
The Concept of Tolerance
• It deals or affects the budgeting of the application.
• The design should be flexible and tolerant, decreasing the
cost of errors and misuse by allowing undoing and redoing
while also preventing bugs wherever possible by tolerating
varied inputs and sequences and by interpreting all
reasonable actions.
The Concept of Reusability
• The designer should design the way, that the user interface
view should be reusable inside the software application.
• Some internal or external components, behaviour of
components, consistency of application should be reuse
inside it. So that the user should not remember the
interrelated process flow of the application on the user
interface. It provides some short cut keys to the user for
easy to work on that.
Santosh V. Kadam ,W.I.E.T. 113
 Other User Interface Design Principles
• User familiarity – Instead of using computer terminology make use of
user oriented terminologies. For example, in ‘Microsoft Office’ software,
the terms such as document, spreadsheet, letter, folder are used and use
of the terms directory, file and identities are avoided.
• Consistency The appropriate level of consistency should be maintained in
the user interface. or example, the commands or menus should be of
same format.
• Minimal surprise – The commands should operate in a known way. This
makes user to easily predict the interface. For example, the in word
processing document under the tool menu there should be a facility of
spelling and grammar checking.
• Recoverability – The system should provide recovering facility to user
from his errors so that user can correct those error. For example, an undo
command should be given so that user can correct his errors, or while
deleting something the confirmation action must be provided, that user
can think again while deleting something.
• User guidance – The user interface can be effectively used by a novice
user if some user guidance such as help systems, online manuals etc. are
supplied.
Santosh V. Kadam ,W.I.E.T. 114
 Golden Rules
• Theo Mandel has proposed three golden rules for user
interface design .
• While analyzing any requirement during requirement analysis
the user often demands for the system which will satisfy user
requirements and help him to get the things done. That
means the user always wants to control the computerized
system.
• The golden rules are known as interface design principles.
The golden rules are divided into three groups:
1. Place Users in Control
2. Reduce Users’ Memory Load
3. Make the Interface Consistent

Theo Mandel Original Pdf

Santosh V. Kadam ,W.I.E.T. 115

1. Place the user in control Or Allow user to direct the current task into
meaningful manner
• Use modes judiciously (modeless)
• Allow users to use either the keyboard or mouse (flexible)
• Allow users to change focus (interruptible)
• Display descriptive messages and text(Helpful)
• Provide immediate and reversible actions, and feedback (forgiving)
• Provide meaningful paths and exits (navigable)
• Accommodate users with different skill levels (accessible)
• Make the user interface transparent (facilitative)
• Allow users to customize the interface (preferences)
• Allow users to directly manipulate interface objects (interactive).
Design for the direct interaction with objects that appear on the
screen.
• The technical internal details must be hidden from the casual user.
• Create a user interface with proper indicators on it so that user can
understand his current task and how to proceed for new task.
• The interaction should be defined in such a way that the user is not
forced to implement unnecessary actions.
Santosh V. Kadam ,W.I.E.T. 116
2. Reduce the user's memory load
• Relieve short-term memory (remember). The user interface
must be designed in such a way that it reduces the demands on
the user's short term memory.
• Rely on recognition, not recall (recognition).
• Provide visual cues (inform) .The interface screen should be
friendly to users.
• Provide defaults, undo, and redo (forgiving). Create the
meaningful defaults value as an advantage for the average users
in the start of application.
• Provide interface shortcuts (frequency). The shortcut should be
easily remembered by the users.
• Promote an object-action syntax (intuitive)
• Use real-world metaphors (transfer)
• User progressive disclosure (context)
• Promote visual clarity (organize)
• There must be a reset option for obtaining the default values.
Santosh V. Kadam ,W.I.E.T. 117
3. Make the interface consistent
• Sustain the context of users’ tasks (continuity)
• Maintain consistency within and across products (experience).
Consistency should be maintained for all the interaction. If an application
come in a packaged manner then every product of that application family
should possess the consistent user interface.
• Keep interaction results the same (expectations) .Do not change the past
system that is created by the user expectation unless there is a good
reason to do that.
• Provide aesthetic appeal and integrity (attitude)
• Encourage exploration (predictable)
• The system must allow the user to put task into meaningful context.

For Example
Microsoft Office family has several application products such as MS
WORD, MS Power Point, MS Access and so on.
The interface of each of these product is consistent (of course with
necessary changes according to its working!).
That means there is a title bar, menu bar having menus such as File, Edit,
View. Insert, Format, Tools, Table, Window, Help on every interface.
Then tool bars and then design layouts are placed on the interface. 118
4. If certain standards are maintained in previous
model of application do not change it until and
unless it is necessary
• Certain sequence of operation becomes a
standard for the user, then do not change these
standards because user becomes habitual with
such practices.
• For instance, control + s is for saving the file
then it has become a standard rule now, if you
assign different short cut keys for saving then it
becomes annoying to the user.

Santosh V. Kadam ,W.I.E.T. 119

 User interface design issues
The user interface design consist of following four issues:
1. Response time of the system
Length and variability are the two important characteristic of the system response
time.
2. User help facilities
The user of each software system needs the help facility or the user manual for the
smooth use of the software.
3. Error information handling
Many error messages and warnings are created which irritate the users as they are
not meaningful. Only the critical problems should be handled.
Error message guidelines are as follows:
• The language of error message should be described in plain language i.e easily
understandable for the users.
• For recovering the error, useful advice should be provided.
• The error message must have an audible or visual indications like beep, short flashing
or the special error color.
• The error messages must indicate any negative result so that the user verifies it.
• The wordings of message should not be blamed on the user.
4. Command labeling
The commands and menu labeling must be consistent, easy to understand and learn.

Santosh V. Kadam ,W.I.E.T. 120

 WebApp Interface design
• The principles for designing the WebApp are as follows:
1. Anticipation
A WebApp should be designed so that it can anticipate the
user's next move.
2. Communication
The interface must communicate the status of any activity
initiated by the user.
3. Consistency
Throughout the WebApp the use of navigation control, menus,
icons, decorative parts should be consistent.
4. Efficiency
The design of WebApp and its interfaces must optimize the
user's work efficiency and not the efficiency of developer.
5. Flexibility
The system must be flexible to accommodate the need of user.
6. Focus
The WebApp interface and the content present in it must focus
on the users task. 121
7. Readability
The presented information must be readable to all the
users.
8. Learnability
A WebApp interface must be designed to minimize the
learning time.After learned, It is necessary to minimize
the relearning when the WebApp is revisited.
9. Metaphors
An interface uses an interaction metaphor that is easier
to learn and use until the metaphor is appropriate for the
application and the user.
10. Maintain the integrity of work product
A work product should be saved automatically so it does
not lose an error message which has occurred
automatically.

Santosh V. Kadam ,W.I.E.T. 122

Interface elements include but are not limited to:
• Input Controls: buttons, text fields,
checkboxes, radio buttons, dropdown lists, list
boxes, toggles, date field
• Navigational Components: breadcrumb, slider,
search field, pagination, slider, tags, icons
• Informational Components: tooltips, icons,
progress bar, notifications, message boxes,
modal windows
• Containers: accordion

Santosh V. Kadam ,W.I.E.T. 123

 User Interface Design Process

The analysis and design process of a user interface is iterative and can be
represented by a spiral model.
The analysis and design process of user interface consists of four framework
activities. Santosh V. Kadam ,W.I.E.T. 124
1. User, task, environmental analysis, and modeling
• Initially, the focus is based on the profile of users who will interact with
the system, i.e. understanding, skill and knowledge, type of user, etc,
based on the user’s profile users are made into categories.
• From each category requirements are gathered. Based on the
requirements developer understand how to develop the interface.
• Once all the requirements are gathered a detailed analysis is conducted.
In the analysis part, the tasks that the user performs to establish the goals
of the system are identified, described and elaborated.
• The analysis of the user environment focuses on the physical work
environment.
• Among the questions to be asked are:
– Where will the interface be located physically?
– Will the user be sitting, standing, or performing other tasks unrelated
to the interface?
– Does the interface hardware accommodate space, light, or noise
constraints?
– Are there special human factors considerations driven by
environmental factors? Santosh V. Kadam ,W.I.E.T. 125
2. Interface Design
• This phase serves as the foundation for the implementation phase.
• The goal of this phase is to define the set of interface objects and
actions i.e. Control mechanisms that enable the user to perform desired
tasks. Indicate how these control mechanisms affect the system.
• Specify the action sequence of tasks and subtasks, also called a user
scenario.
• Indicate the state of the system when the user performs a particular
task.
• Always follow the three golden rules stated by Theo Mandel.
• Design issues such as response time, command and action structure,
error handling, and help facilities are considered as the design model is
refined.
3. Interface construction and implementation
• The implementation activity begins with the creation of prototype
(model) that enables usage scenarios to be evaluated.
• As iterative design process continues a User Interface toolkit that allows
the creation of windows, menus, device interaction, error messages,
commands, and many other elements of an interactive environment can
be used for completing the construction of an interface.
Santosh V. Kadam ,W.I.E.T. 126
4. Interface Validation
• This phase focuses on testing the interface.
• The interface should be in such a way that it should be able to
perform tasks correctly and it should be able to handle a variety
of tasks.
• It should achieve all the user’s requirements.
• It should be easy to use and easy to learn.
• Users should accept the interface as a useful one in their work.
User Interface Analysis and Design
User interface analysis and design can be done with the help of
following steps.
1. Create different models for system functions.
2. The order to perform these functions identify the human-
computer interface tasks.
3. Prepare all interface designs by solving various design issues.
4. Apply modern tools and techniques to prototype the design.
5. Implement design model.
6. Evaluate the design from end
Santosh user
V. Kadam to bring quality in it.
,W.I.E.T. 127
 Designing within the Context of Software Engineering
• Software design is a vital activity during the process of software
development. It is carried put irrespective of any process model used.
• During software engineering process, the first task is to identify and
analyze the requirements. Based on this analysis the software design is
developed. This design serves as a basis for code generation and testing.
Hence software design is an intermediate process which translates the
analysis model into design model.
• The four types of elements of analysis model are scenario based
elements, class based elements, behavioral elements, and flow oriented
elements.
• During the scenario based analysis various models such as use case
diagrams, activity diagrams or swimlane diagrams are created. During the
class based analysis the class diagrams are created. During flow oriented
analysis the Data flow diagrams are created. Behavioral analysis can be
done using state diagrams and sequence diagrams.
• The class based elements of analysis model are used to create class
diagrams.
• The flow oriented elements and class based elements are used to
create architectural design.
Santosh V. Kadam ,W.I.E.T. 128
Santosh V. Kadam ,W.I.E.T. 129
• The scenario based elements, flow oriented elements and behavioral
elements are used to create Interface design. The interface design
describes how software communicates with systems.
• The class based elements, flow oriented elements and behavioral
elements are used to create component level design. This design
transforms the structural elements of software architecture into
procedural description of software module.
• Software design is very important for assessing the quality of software.
Because design is the only way that we can accurately translate the user
requirements into the finished software product.
• Without software design, it is difficult to test the software product. Not
only this, but for making a small change in the software - it is the
software design which helps us to make the necessary changes without
disturbing other part of the software.

Santosh V. Kadam ,W.I.E.T. 130