UNIT -3 Software Design

3.1) Design Process & quality, Design Concepts, The design

Model, Pattern based Software Design.
3.2) Architectural Design :Design Decisions, Views, Patterns,
Application Architectures, Modeling Component level Design:
component, Designing class based components, conducting
component-level design,
User Interface Design: The golden rules, Interface Design steps &
Analysis, Design Evaluation
 Introduction
+ Software design is an iterative process through
which requirements are translated into a blueprint
for constructing the software.
+ It consist of set of principles, concepts and practices
that lead to the development of high quality system

2
Objectives of Software Design

3
Objectives of Software Design
1. Correctness: Software design should be correct as per
requirement.
2. Completeness: The design should have all components
like data structures, modules, and external interfaces, etc.
3. Efficiency: Resources should be used efficiently by the
program.
4. Flexibility: Able to modify on changing needs.
5. Consistency: There should not be any inconsistency in
the design.
6. Maintainability: The design should be so simple so that
it can be easily maintainable by other designers.
4
Software design principles
+ Software design principles are a set of
guidelines that helps developers to make a
good system design.
+ Software design principles are concerned
with providing means to handle the
complexity of the design process effectively.

5
Software design principles
Some of the commonly followed design principles are as
following:
1. Software design should correspond to the analysis
model
2. Choose the right programming paradigm
3. Software design should be uniform and integrated
4. Software design should be flexible

6
 Software design principles
5. Software design should ensure minimal conceptual
(semantic) errors
6. Software design should be structured to degrade gently
7. Software design should represent correspondence
between the software and real-world problem
8. Software reuse
9. Designing for testability
10. Prototyping
7
Software Design Concepts
1. Abstraction: hide Irrelevant data
2. Architecture: design a structure of something
3. Pattern: a repeated form
4. Modularity: subdivide the system
5. Information hiding: hide the information
6. Refinement: removes impurities
7. Refactoring: reconstruct something
8. Structural partitioning: Structure of the program can be
partitioned
9. Concurrency: control the concurrent execution of process

8
Design Concepts – 1. Abstraction
+ Abstraction refers to a powerful design tool, which
allows software designers to consider components at
an abstract level, while neglecting the
implementation details of the components.
+ There are three commonly used abstraction
mechanisms in software design, namely, functional
abstraction, data abstraction and control abstraction.
+ All these mechanisms allow us to control the
complexity of the design process

9
Design Concepts – 1. Abstraction
1. Functional abstraction: It can be generalized as
collections of subprograms referred to as
‘groups’.
2. Data abstraction: This involves specifying data
that describes a data object.
3. Control abstraction: This states the desired
effect, without stating the exact mechanism of
control.

10
Design Concepts – 2. Architecture
+ Software architecture refers to the structure of the
system, which is composed of various components
of a program/ system, the properties of those
components and the relationship amongst them.
+ The software architecture enables the software
engineers to analyze the software design
efficiently.
+ It also helps them in decision-making and
handling risks.

11
Design Concepts – 2. Architecture
The software architecture does the following:
1. Enable the stakeholder to communicate with
each other
2. Highlights the early design designs
3. Creates intellectual models

12
Design Concepts – 3. Pattern
+ The pattern simply means a repeated form or
design in which the same shape is repeated
several times to form a pattern.
+ The pattern in the design process means the
repetition of a solution to a common recurring
problem within a certain context.

13
Design Concepts – 4. Modularity
+ Modularity is achieved by dividing the software into
uniquely named and addressable components, which
are also known as modules.
+ Modularizing a design helps to plan the development
in a more effective manner, accommodate changes
easily, conduct testing and debugging effectively and
efficiently, and conduct maintenance work without
adversely affecting the functioning of the software.

14
Design Concepts – 4. Modularity

15
Design Concepts– 5.Information hiding
+ Modules should be designed in such a way that the
data structures and processing details of one module
are not accessible to other modules.
+ They pass only that much information to each other,
which is required to accomplish the software
functions.
+ The way of hiding unnecessary details is referred to
as information hiding.

16
Design Concepts– 6. Refinement
+ Refinement simply means to refine something to
remove any impurities if present and increase the
quality of the software.
+ The refinement of software design is actually a
process of developing or presenting the software or
system in a detailed manner.
+ Refinement is very necessary to find out any error if
present and then to reduce it.

17
Design Concepts– 7. Refactoring
+ Refactoring means to reconstruct something in
such a way that it does not affect the behavior or
any other features.
+ Refactoring in software design means to
reconstruct the design to reduce complexity and
simplify it without affecting the behavior or its
functions.

18
Design Concepts– 8. Structural partitioning
+ When the architectural style of a design follows a
hierarchical nature, the structure of the program can
be partitioned either horizontally or vertically.
1. Vertical partitioning: In this, the functionality is
distributed among the modules in a top-down
manner. The modules at the top level called control
modules that perform the decision-making and do
little processing whereas the modules at the low
level called worker modules that perform all input
computation and output tasks.
19
Design Concepts– 8. Structural partitioning
2. Horizontal partitioning: In this, the control modules
are used to communicate between functions and
execute the functions.

20
Design Concepts– 8. Structural partitioning
+ Structural partitioning provides the following
benefits.
• The testing and maintenance of software
becomes easier.
• The negative impacts spread slowly.
• The software can be extended easily.

21
UNIT -3 Software Design
3.1) Design Process & quality, Design Concepts, The design
Model, Pattern based Software Design.
3.2) Architectural Design :Design Decisions, Views, Patterns,
Application Architectures, Modeling Component level Design:
component, Designing class based components, conducting
component-level design,
User Interface Design: The golden rules, Interface Design steps &
Analysis, Design Evaluation
Design Concepts– 9. Concurrency
+ To utilize the resources efficiently, multiple tasks
must be executed concurrently. This requirement
makes concurrency one of the major concepts of
software design.
+ Every system must be designed to allow multiple
processes to execute concurrently, whenever
possible.
+ The system must control the concurrent execution
and synchronize the actions of concurrent processes.

23
Effective modular design
+ Effective modular design can be achieved if the
partitioned modules are separately solvable,
modifiable as well as easy to compile.

+ Here separate compilation of modules means that

after making changes in a module there is no need
of recompiling the whole software system.

24
Effective modular design
+ In order to build a software with effective modular
design there is a factor “Functional
Independence” which comes into play.
+ The Functional Independence means a function is
atomic in nature so that it performs only a single task
of the software without or with least interaction with
other modules.
+ Independence of modules of a software system can be
measured using 2 criteria : Cohesion, and Coupling.

25
 Effective modular design

A good software design requires high cohesion and low coupling.

26
 Coupling
● Coupling refers to the degree of interdependence between software
modules.
● High coupling means that modules are closely connected and
changes in one module may affect other modules.
● Low coupling means that modules are independent, and changes in
one module have little impact on other modules.

27
 Cohesion
● Cohesion refers to the degree to which elements within a module
work together to fulfill a single, well-defined purpose.
● High cohesion means that elements are closely related and focused
on a single purpose, while low cohesion means that elements are
loosely related and serve multiple purposes.

28
 Cohesion
+ Cohesion is a measure of the
degree to which the elements of
the module are functionally
related.
+ It is the degree to which all
elements directed towards
performing a single task are
contained in the component.
+ A good software design will have
high cohesion.
29
Types of Cohesion
1. Functional Cohesion: Functional cohesion is said to
exist if different elements of a module cooperate to
achieve a single function.
2. Sequential Cohesion: An element outputs some data
that becomes the input for other element, i.e., data flow
between the parts.
3. Communicational Cohesion: Two elements operate
on the same input data or contribute towards the same
output data.

30
Types of Cohesion
4. Procedural Cohesion: components within module
ensure the order of execution. Actions are still weakly
connected and unlikely to be reusable.
5. Temporal Cohesion: This cohesion contains the code
for initializing all the parts of the system or lots of
different activities occur, all at time of initialization.

31
Types of Cohesion
6. Logical Cohesion: The elements are logically related
and not functionally. All the code for these functions is
in the same component. Operations are related, but the
functions are significantly different.
7. Coincidental Cohesion: The elements are not
related i.e., it performs a set of function or tasks that
relate to each other very loosely. The elements have no
conceptual relationship other than location in source
code. It is accidental and the worst form of cohesion.

32
 Coupling
+ Coupling between two modules is
a measure of the degree of
interaction or interdependence
between the two modules.
+ A module having low coupling and
high cohesion is said to
be functionally independent of
other modules.

33
Types of Coupling
1. Data Coupling: If the dependency between the
modules is based on the fact that they communicate
by passing only data, then the modules are said to
be data coupled. In data coupling, the components
are independent to each other and communicating
through data.
2. Stamp Coupling: In stamp coupling, the complete
data structure is passed from one module to
another module.

34
Types of Coupling
3. Control Coupling: Control coupling exists
between two modules if data from one module is
used to direct the order of instructions executed in
another. An example of control coupling is a flag
set in one module and tested in another module.
4. External Coupling: In external coupling, the
modules depend on other modules, external to
the software being developed or to a particular type
of hardware.

35
Types of Coupling
5. Common Coupling: The modules have shared data
such as global data structures. The changes in
global data mean tracing back to all modules which
access that data to evaluate the effect of the change.
6. Content Coupling: In a content coupling, one
module can modify the data of another module
or control flow is passed from one module to the
other module. This is the worst form of coupling
and should be avoided.

36
Cohesion vs Coupling

37
38
UNIT -3 Software Design
3.1) Design Process & quality, Design Concepts, The design
Model, Pattern based Software Design.
3.2) Architectural Design :Design Decisions, Views, Patterns,
Application Architectures, Modeling Component level
Design: component, Designing class based components,
conducting component-level design, User Interface Design:
The golden rules, Interface Design steps & Analysis, Design
Evaluation
 The design Model
● A design model in software engineering is a blueprint that describes how a
system will be built. It's based on the system's analysis and architectural
requirements.
● What does a design model do?
1) Describes the system's structure and implementation
2) Represents the application components
3) Determines how components are placed and used in the architecture
4) Guides builders, engineers, and designers during the creation process
5) It helps share unambiguous meaning

40
 The design Model
● What are the elements of a design model?
1) Architecture: Defines the structural representation of the software
2) Interface design: Focuses on enhancing user experience
3) Component-level design: Transforms architectural elements into procedural
descriptions
4) Deployment-level design: Describes the physical architecture of the system
● How does a design model help?
1) It's a simpler representation than words alone
2) A group of people can quickly get the general idea behind a system
3) It enables effective communication
4) It helps share unambiguous meaning
41
 Pattern-based design
● Pattern-based design creates a new application by finding a set of proven
solutions to a clearly delineated set of problems.
● Each problem and its solution is described by a design pattern that has been
cataloged and vetted by other software engineers who have encountered the
problem and implemented the solution while designing other applications.
● Each design pattern provides you with a proven approach to one part of the
problem to be solved.

42
 Who does it
● A software engineer examines each problem encountered for a new application
and then attempts to find a relevant solution by searching one or more patterns
repositories.

Why is it important?
● Have you ever heard the phrase “reinventing the wheel”?
● It happens all the time in software development, and it’s a waste of time and
energy.
● By using existing design patterns, you can acquire a proven solution for a
specific problem. As each pattern is applied, solutions are integrated and the
application to be built moves closer to a complete design.

43
Design pattern as per Technology

44
UNIT -3 Software Design
3.1) Design Process & quality, Design Concepts, The design
Model, Pattern based Software Design.
3.2) Architectural Design :Design Decisions, Views, Patterns,
Application Architectures, Modeling
Component level Design: component, Designing class based
components, conducting component-level design, User
Interface Design: The golden rules, Interface Design steps &
Analysis, Design Evaluation
 Architectural Design
● Architectural design in software engineering refers to the process of defining
the structure, components, modules, and relationships of a software system
to satisfy specified requirements.
● It is a crucial phase in the software development life cycle where high-level
system structures are designed to ensure that the system meets its functional and
nonfunctional requirements.

46
 What is Software Architecture?
● Definition:
A software system’s architecture is the set of principal design decisions
about the system
● Software architecture is the blueprint for a software system’s construction
and evolution
● Design decisions encompass every facet of the system under development
● Structure

● Behavior

● Interaction 47

● Non-functional properties
Other Definitions of Software Architecture
● Perry and Wolf
● Software Architecture = { Elements, Form, Rationale }
what how why
● Shaw and Garlan
● Software architecture [is a level of design that] involves
● the description of elements from which systems are built,
● interactions among those elements,
● patterns that guide their composition, and
● constraints on these patterns.
● Kruchten 48
● Software architecture deals with the design and implementation of the
high-level structure of software.
● Architecture deals with abstraction, decomposition, composition, style,
and aesthetics.
 Temporal Aspect
● Design decisions are and unmade over a system’s lifetime
🡪 Architecture has a temporal aspect
● At any given point in time the system has only one
architecture
● A system’s architecture will change over time

49
Prescriptive vs. Descriptive Architecture
● A"prescriptive architecture" defines a set of rules and guidelines
for how a system should be built, acting like a blueprint for
developers to follow,
● A "descriptive architecture" simply documents how a system was
actually built after the fact, capturing the existing structure
without dictating design decisions.
● Prescriptive is "how it should be" 50

● Descriptive is "how it is" based on observation

Prescriptive vs. Descriptive Architecture
● Purpose:
● Prescriptive: To guide development by providing a clear set of
design principles and patterns to be followed during
implementation.
● Descriptive: To analyze and understand an existing system by
documenting its components, relationships, and how they
interact. 51
Prescriptive vs. Descriptive Architecture

● A system’s prescriptive architecture captures the design

decisions made prior to the system’s construction
● It is the as-conceived or as-intended architecture
● A system’s descriptive architecture describes how the system
has been built
● It is the as-implemented or as-realized architecture 52
 Software Architecture Elements
● A software system’s architecture typically is not (and
should not be) a uniform monolith
● A software system’s architecture should be a composition
and interplay of different elements
● Processing
● Data, also referred as information or state 53

● Interaction
 Components
● Elements that encapsulate processing and data in a system’s
architecture are referred to as software components
● Definition
● A software component is an architectural entity that

● encapsulates a subset of the system’s functionality and/or data

● restricts access to that subset via an explicitly defined interface

● has explicitly defined dependencies on its required execution

context 54

● Components typically provide application-specific services

 Architecture design views
● In software engineering, architecture design views are representations of
a system's architecture from different perspectives.
● These views help stakeholders understand the system and ensure it
addresses their needs.

55
 Common architecture views:
● Logical view: Focuses on the functionality of the system as seen by the
end-user
● Process view: Focuses on the system's dynamic aspects, such as how
processes communicate and perform
● Development view: Focuses on the technical specifications of the
software, and is used by technical staff to build and test the software
● Physical view: Focuses on the physical aspects of the system

56
 Architectural Patterns
● Definition
● It is a set of architectural design decisions that are applicable to a

recurring design problem, and parameterized to account for

different software development contexts in which that problem
appears.
● A widely used pattern in modern distributed systems is the 3-tiered
system pattern
● Science 57

● Banking
● E-commerce
● Reservation systems
 Architectural Patterns
• An architectural pattern is a set of architectural design
decisions that are applicable to a recurring design
problem, and parameterized to account for different
software development contexts in which that problem
appears.
• Architectural patterns are similar to DSSAs
(Domain-Specific Software Architecture) but applied “at
a lower level” and within a much narrower scope.
58
 State-Logic-Display: Three-Tiered Pattern
● Application Examples
● Business applications

● Multiplayer games
● Web-based applications

59
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Three-Tiered Pattern

● Front Tier
● Contains the user interface functionality to access the
system’s services
● Middle Tier
● Contains the application’s major functionality
● Back Tier
● Contains the application’s data access and storage
functionality
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Software Architecture
■ The software architecture of a program or computing system is
the structure or structures of the system, which comprise
software components, the externally visible properties of those
components, and the relationships among them.

61
 Why Architecture
The architecture is not the operational software. Rather, it is a
representation that enables a software engineer to:

■ (1) analyze the effectiveness of the design in meeting its stated

requirements,

■ (2) consider architectural alternatives at a stage when making design

changes is still relatively easy, and

■ (3) reduce the risks associated with the construction of the software.

62
 Importance
There are three reasons for the importance of software architecture in the
real world software development.

1. Using this model even the stakeholders can take active part in the software
development process. This helps in understanding of requirements.

2. Some early design decisions can be taken during software architecture and
hence system performance and operations remain under control.

3. Finally, it describes the structure and the working of various components

which together collaborate to form a single software

63
 Architectural Genre
■ Genre implies a specific category within the overall software domain. Within
each category, you encounter a number of subcategories.

■ Architectural genre will often dictate the specific architectural approach to

the structure that must be built

■ Few architectural genres for software-based systems: Artificial intelligence,

Commercial, Content, Entertainment and Sports, Financials, Games, Government, Industrial,

Legal, Medical, Operating, Platforms, Tools, Transportation, Utilities

■ Each genre represents a unique challenge - For example - it is important to

recognize that the gaming system genre can be addressed with an
architectural Style that has been specifically designed to address gaming
system concerns
64
 Architectural Styles
■ An architectural style transforms the designs of an entire system with an
intention of providing suitable structure to various components of that
system. It may sometimes happen that the existing architecture is to be
reengineered.

■ Each style describes a set of components, connectors, constraints and

semantic models:
■ Computational components such as clients, server, filter, and database to execute the desired
system function
■ A set of connectors such as procedure call, events broadcast, database protocols, and pipes
to provide communication among the computational components
■ Constraints to define integration of components to form a system
■ A semantic model, which enable the software designer to identify the characteristics of the
system as a whole by studying the characteristics of its components.

65
 Architectural Styles
The following are the five types of architectural styles .

■ Data – centered Architecture

■ Data – flow Architecture

■ Call and return Architecture

■ Object – oriented Architecture

■ Layered Architecture

66
UNIT -3 Software Design
3.1) Design Process & quality, Design Concepts, The design
Model, Pattern based Software Design.
3.2) Architectural Design :Design Decisions, Views, Patterns,
Application Architectures, Modeling
3.3) Component level Design: component, Designing class
based components, conducting component-level design,
User Interface Design: The golden rules, Interface Design
steps & Analysis, Design Evaluation
 Application architecture
● Application architecture in software engineering is the process of designing
the structure of an application. It defines how the application's components
interact, and how the application will meet its technical and operational
requirements.

68
 Application architecture
● Why is application architecture important?
It helps ensure the application meets its requirements
It helps ensure the application is maintainable and scalable
It helps stakeholders understand how the application will achieve qualities like
modifiability, availability, and security
● How do I choose an application architecture?
Consider whether to use a monolithic or microservice-based architecture
Consider whether your team is ready to use microservices
Consider your hosting model
Consider whether a combination of multiple architecture models would work
69
 Data – centered Architecture

a typical data-centered style. Client software accesses a central

repository 70
 Data – centered Architecture
■ In this architecture the data store lies at the center of the
architecture and is accessed frequently by other components that
update, add, delete or modify data within the store.

■ In some cases the data repository is passive. That is, client

software accesses the data independent of any changes to the
data or the actions of other client software

■ Data-centered architectures promote integrability . That is, existing

components can be changed and new client components added to
the architecture without concern about other clients (because the
client components operate independently). 71
Data Flow Architecture

72
 Data Flow Architecture
■ This architecture is applied when input data are to be transformed through
a series of computational or manipulative components into output data.

■ A pipe and filter structure has a set of components, called filters,

connected by pipes that transmit data from one component to the next.

■ Each filter works independently of those components upstream and

downstream, is designed to expect data input of a certain form, and
produces data output (to the next filter) of a specified form.

■ However, the filter does not require knowledge of the working of its
neighboring filters

73
Call and Return Architecture

74
 Call and Return Architecture
■ This architectural style enables a software designer (system
architect) to achieve a program structure that is relatively easy to
modify and scale. Two substyles exist within this category:

■ Main program/subprogram architectures. This classic program

structure decomposes function into a control hierarchy where a
“main” program invokes a number of program components, which
in turn may invoke still other components.

■ Remote procedure call architectures. The components of a main

program/ subprogram architecture are distributed across multiple
computers on a network. 75
 Object – oriented Architecture
■ In object-oriented architectural style, components of a system
encapsulate data and operations, which are applied to
manipulate the data.

■ The components of a system encapsulate data and the

operations that must be applied to manipulate the data.
■ Communication and coordination between components is
accomplished via message passing

■ In this style, components are represented as objects and they

interact with each other through methods (connectors).
76
Layered Architecture

77
 Layered Architecture
■ A number of different layers are defined, each accomplishing
operations that progressively become closer to the machine
instruction set.

■ At the outer layer, components service user interface operations.

■ At the inner layer, components perform operating system

interfacing.

■ Intermediate layers provide utility services and application software

functions.

78
Domain Specific Software Architecture
■ Solve the problem (design architecture) from scratch

■ Unexpected solutions can be found

■ Labor-intensive and error-prone

■ Apply a generic solution/strategy (style/pattern) and adapt it to the problem

at hand

■ Reuse, less work and less errors

■ Generic solution might be ill-fitting or too generic, requiring rework

■ Apply a solution specific for your domain (DSSA) •

■ Highest amount of reuse

79
Domain Specific Software Architecture
■ Examples of domains
■ Compilers
■ Consumer electronics

■ Electronic commerce system/Web stores

■ Video game
■ Business applications

■ Subdivision of a domain:
■ Avionics systems -> Boeing Jets -> Boeing 747-400

80
Domain Specific Software Architecture
■ Domain-specific software architecture refers to the design and
structure of software systems that are tailored to meet the
specific requirements and constraints of a particular domain or
industry.
■ In contrast to general-purpose software, which is designed to
be versatile and applicable in a wide range of contexts,
domain-specific software architecture is optimized for a
particular field or application area.

81
Domain Specific Software Architecture
■ A Domain-Specific Software Architecture (DSSA) is an
assemblage of software components
■ specialized for a particular domain,
■ generalized for effective use across that domain, and
■ composed in a standardized structure (topology) effective
for building successful applications.

■ DSSAs are the means for maximal reuse of knowledge and prior
development

82
Domain Specific Software Architecture
■ A domain-specific software architecture comprises:
■ a reference architecture, which describes a general
computational framework for a significant domain of
applications;
■ a component library, which contains reusable chunks of
domain expertise; and

■ an application configuration method for selecting and

configuring components within the architecture to meet
particular application requirements
83