BCSE301L – Software

Engineering
Module – 4 – Software
Design

Winter 24-25 1
 Module: 4
Software Design
• Design concepts and principles

• Abstraction

• Refinement

• Modularity Cohesion coupling

• Architectural design

• Detailed Design Transaction Transformation,

• Refactoring of designs

• Object oriented Design

• User-Interface Design
Winter 24-25 2
Software
Design
• Software Design encompasses the set of principles, concepts and practices
that lead to the development of a high-quality system or a product.

• Design creates a representation or model of the software, but unlike the

requirements model (that focuses on describing required data, function
and behavior), the design model provides detail about software
architecture, data structure, interfaces and components that are necessary
to implement the system.

• Once software requirements have been analyzed and modeled, software

design is the last software engineering action within the modeling activity
and set the stage for construction (code generation and testing) .
Winter 24-25 3
Translating the
requirements
model into the
design model

Winter 24-25 4
 Design and Quality Goals
Software
 The designdesign is an
must implement all ofiterative process through
the explicit requirements contained inwhich
the
analysis model,
requirements areand it must accommodate
translated all of the implicit
into a “blueprint” requirements the
for constructing
desired by the customer.
software.
 The design must be a readable, understandable guide for those who
generate code and for those who test and subsequently support the
software.
 The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation
perspective.
Winter 24-25 5 5
 Quality Guidelines
 A design should exhibit an architecture that

(1) has been created using recognizable architectural styles or patterns,

(2) is composed of components that exhibit good design characteristics and

(3) can be implemented in an evolutionary fashion

 A design should be modular; that is, the software should be logically partitioned into elements or subsystems
 A design should contain distinct representations of data, architecture, interfaces, and components.
 A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from
recognizable data patterns.
 A design should lead to components that exhibit independent functional characteristics.
 A design should lead to interfaces that reduce the complexity of connections between components and with the
external environment.
 A design should be derived using a repeatable method that is driven by information obtained during software
requirements analysis.
 AWinter
design should be represented using a notation that effectively communicates its meaning.
24-25 6 6
 Design Principles
• The design process should not suffer from ‘tunnel vision.’

• The design should be traceable to the analysis model.

• The design should exhibit uniformity and integration.

• The design should be structured to accommodate change.

• The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered.

• Design is not coding, coding is not design.

• The design should be assessed for quality as it is being created, not after the fact.

• The design should be reviewed to minimize semantic errors.

Winter 24-25 7
 Quality Attributes [FURPS]

• Functionality is assessed by evaluating the feature set and capabilities

of the program and the security of the overall system etc.

• Usability is assessed by considering human factors, consistency and

documentation.

• Reliability is evaluated by measuring the frequency and severity of

failure, the mean-time-to-failure (MTTF), the ability to recover from failure
etc.

• Performance is measured by considering processing speed, response

time, resource consumption, throughput, and efficiency.

• Supportability combines the ability to extend the program

(extensibility), adaptability, serviceability
Winter 24-25 8
 Design Concepts
 Abstraction—data, procedure, control
 Architecture—the overall structure of the software
 Patterns—”conveys the essence” of a proven design solution
 Separation of concerns—any complex problem can be more easily handled if it is subdivided into pieces

 Modularity—manifestation of separation of concerns

 Information Hiding—controlled interfaces, no details of algorithms/data
 Functional independence—single-minded function and low coupling
 Refinement—elaboration of detail for all abstractions
 Aspects—a mechanism for understanding how global requirements affect design

 Refactoring—a reorganization technique that simplifies the design

 OO design concepts –Object oriented concepts
 Winter 24-25 9
Design Classes—provide design detail that will enable analysis classes to be implemented 9
1.Abstraction
• At the highest level of abstraction, a solution is stated in
broad terms using the language of the problem
environment.

• At lower levels of abstraction, a more detailed

description of the solution is provided.

Winter 24-25 10
 Data
Abstraction
door

manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism

implemented as a data structure

Winter 24-25 11
 DataAbstraction

Winter 24-25 Describes the door object 12

 Data Abstraction
• A data abstraction is a named collection of data
that describes a data object.

• In the context of the procedural abstraction open,

we can define a data abstraction called door. Like
any data object, the data abstraction for door
would encompass a set of attributes that describe
the door (e.g., door type, swing direction, opening
mechanism, weight, dimensions).

• It follows that the procedural abstraction open

would make use of information contained in the
attributes of the data abstraction door.

Winter 24-25 13
 Procedural
Abstraction
open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter

Winter 24-25 14
 Procedural Abstraction
• A procedural abstraction refers to a
sequence of instructions that have a
specific and limited function.
• The name of a procedural abstraction
implies these functions, but specific details
are suppressed.
• An example of a procedural abstraction
would be the word open for a door.
• Open implies a long sequence of
procedural steps (e.g., walk to the door,
reach out and grasp knob, turn knob and
pull door, step away from moving door,
Winter 24-25
etc.). 15
Architecture
• The overall structure of the software and the ways in which
that structure provides conceptual integrity for a system.”

• Structural properties. This aspect of the architectural design representation

defines the components of a system (e.g., modules, objects, filters) and the
manner in which those components are packaged and interact with one
another.

• Extra-functional properties. The architectural design description should

address how the design architecture achieves requirements for performance,
capacity, reliability, security, adaptability, and other system characteristics.

• Families of related systems. The architectural design should draw upon

repeatable patterns that are commonly encountered in the design of families of
similar systems. In essence, the design should have the ability to reuse
architectural
Winter 24-25 building blocks. 16
 Models to represent the Architectural design:
• Structural models represent architecture as an organized collection of program
components.

• Framework models identify repeatable architectural design frameworks that

are encountered in similar types of applications.

• Dynamic models address the behavioural aspects of the program architecture,

indicating how the structure changes when an external event occurs.

• Process models focus on the design of the business or technical process that
the system must accommodate.

• Functional models can be used to represent the functional hierarchy of a

system.
Winter 24-25 17
 Patterns
A pattern is a named nugget of insight which conveys the
essence of a proven solution to a recurring problem within
a certain context amidst competing concerns”.
The intent of each design pattern is to provide a
description that enables a designer to determine
• (1) whether the pattern is applicable to the current work,
• (2) whether the pattern can be reused (hence, saving design
time)
• (3) whether the pattern can serve as a guide for developing
Winter 24-25 18
 Separation of Concerns
 Any complex problem can be more easily handled if it is

subdivided into pieces that can each be solved and/or optimized

independently

 A concern is a feature or behavior that is specified as part of the

requirements model for the software

 By separating concerns into smaller, and therefore more

manageable pieces, a problem

Winter 24-25 takes less effort and time to19
 Modularity
 Modularity is the most common manifestation of separation of concerns.
Software is divided into separately named and addressable components,
sometimes called MODULES, that are integrated to satisfy problem
requirements.
 "modularity is the single attribute of software that allows a program to be
intellectually manageable"
 Monolithic software (i.e., a large program composed of a single module)
cannot be easily grasped by a software engineer.
 In almost all instances, you should break the design into many modules,
hoping to make understanding easier and as a consequence, reduce the
cost required to build the software.
Winter 24-25 20
 Pay attention to integration costs too.
 Modularity: Trade-offs
What is the "right" number of modules for a specific
software design?
module development cost

cost of software

module integration cost

optimal number of
Winter 24-25 number of modules 21
modules
 Information Hiding
• The principle of information hiding suggests that modules be
“characterized by design decisions that (each) hides from all others.

• Modules should be specified and designed so that information

(algorithms and data) contained within a module is inaccessible to
other modules that have no need for such information.
• Hiding implies that effective modularity can be achieved by defining a set of
independent modules that communicate with one another only that information
necessary to achieve software function.

Winter 24-25 22
 Information Hiding

module
controlled • algorithm
interface • data structure
• details of external interface
• resource allocation policy

clients "secret"

a specific design decision

Winter 24-25 23
 Why Information Hiding?
 Reduces the likelihood of “side effects”
 Limits the global impact of local design decisions
 Emphasizes communication through controlled interfaces
 Discourages the use of global data
 Leads to encapsulation—an attribute of high quality design
 Results in higher quality software

Winter 24-25 24
 Functional Independence
 Functional independence is achieved by developing modules with
"single-minded" function and an "aversion" to excessive interaction
with other modules.
 Cohesion is an indication of the relative functional strength of a
module.
 A cohesive module performs a single task, requiring little
interaction with other components in other parts of a program.
 Coupling is an indication of the relative interdependence among
modules.
 Coupling depends on the interface complexity between
Winter 24-25 25
modules, the point at which entry or reference is made to a
Refinement
• It begin with a statement of function (or description of information) that is defined
at a high level of abstraction.

• That is, the statement describes function or information conceptually but provides
no information about the internal workings of the function or the internal structure
of the information. You then elaborate on the original statement, providing more
and more detail as each successive refinement (elaboration) occurs.

• Abstraction and refinement are complementary concepts. Abstraction enables you

to specify procedure and data internally but suppress the need for “outsiders” to
have knowledge of low-level details. Refinement helps you to reveal low-level
details as design progresses. Both concepts allow you to create a complete design
model as the design evolves.
Winter 24-25 26
 Stepwise Refinement
 Refinement is a process of elaboration
 It is the development of a program by successively refining levels of procedure detail

open

walk to door; reach

for knob;

open door; repeat until door opens turn

knob clockwise;
walk through; if knob doesn't turn, then take
close door. key out;
find correct key; insert in
lock;
endif pull/push
door
move out of way;
end repeat

Winter 24-25 27
 Aspects
 An Aspect is a representation of a cross-cutting concern.
 Consider two requirements, A and B. Requirement A crosscuts
requirement B “if a software decomposition [refinement] has been
chosen in which B cannot be satisfied without taking A into account.
 These concerns include requirements, use cases, features, data
structures, quality-of-service issues, variants, intellectual property
boundaries, collaborations, patterns and contracts

Winter 24-25 28
 Refactoring
"Refactoring is the process of changing a software system in such a way that it does not

alter the external behavior of the code [design] yet improves its internal structure.”

 When software is refactored, the existing design is examined for

 redundancy

 unused design elements

 inefficient or unnecessary algorithms

 poorly constructed or inappropriate data structures

 or any other design failure that can be corrected to yield a better design.
Winter 24-25 29
 OO Design Concepts
 Inheritance—all responsibilities of a superclass is immediately inherited by
all subclasses
 Messages—stimulate some behavior to occur in the receiving object
 Polymorphism—a characteristic that greatly reduces the effort required to
extend the design

Winter 24-25 30
 Design Classes

Types of Design Classes

User interface classes – define all abstractions necessary for human-computer

interaction

Business domain classes – refined from analysis classes; identify attributes and

methods that are required to implement some element of the business domain

Process classes – implement business abstractions required to fully manage the

business domain classes

Persistent classes – represent data stores (e.g., a database) that will persist beyond
Winter 24-25
the execution of the software
 Design Model
• The design model can be viewed in two different
dimensions as illustrated in following figure.
• Process dimension
• Abstraction dimension

• The process dimension indicates the evolution of

the design model as design tasks are executed as
part of the software process

• The abstraction dimension represents the level of

detail as each element of the analysis model is
transformed into a design equivalent and then
refined iteratively

Winter 24-25 32
 The Design Model

Winter 24-25 33 3
 Design Model
Elements
 Data elements

 Architectural elements

 Interface elements

 Component elements

 Deployment elements

Winter 24-25
 Data/Class Design Elements
• Data design creates a model of data and objects that is represented at a high level of

abstraction

• This data model is then refined into progressively more implementation-specific

representations

• At the program component level, the design of data structures and the associated

algorithms are used for the creating the high-quality applications.

• At the application level, the translation of a data model into a database is essential to

achieve the business objectives of a system.

• At the business level, the collection of information stored in different databases and

reorganized into a data warehouse enables data mining or knowledge discovery.

Winter 24-25 35
 Architectural Elements
 Architectural design depicts the overall layout of the software

 The architectural model is derived from three sources:

(1) Information about the application domain

(2) Specific requirements model elements such as data flow diagrams and their

relationships

(3) The availability of architectural styles and patterns.

 The architectural design element is usually represented as a set of

interconnected subsystems, each have its own architecture

Winter 24-25
 Interface design elements

• Interface design tells how information flows into and out of the system and

how it is communicated among the various components of the architecture

• Elements of interface design:

• user interface

• external interfaces

• internal interfaces

Winter 24-25 37
 Component Design
Elements
• Component level design describes the internal detail of each software
component like data structure definitions, algorithms, and interface
specifications.

• A UML activity diagram can be used to represent processing logic.

• Pseudocode or some other diagrammatic form (e.g., flowchart or box

diagram) is used to represent the detailed procedural flow between the
component.

• Algorithmic structure follows the rules established

SensorManagement Sensor
for structured
programming
Winter 24-25 38
 Deployment-level design elements

• This design indicates how software functionality and

subsystems will be allocated within the physical
computing environment that will support the software

Winter 24-25 39
 Software Architecture Design

 Architectural Styles

 Architectural Design

 Architectural Mapping

Winter 24-25 40
 Why Architecture?
 Architecture of a system describes the components and how they fit

together.

 Architecture 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.

Winter 24-25
 Horizontal & Vertical Partitioning

• Horizontal Partitioning define separate branches of the

module hierarchy for each major function
• This use control modules to coordinate communication
between functions

Vertical Partitioning: Factoring

• Vertical partitioning suggests the control and work should
be distributed top-down in the program structure.
• The decision making modules should reside at the top of
the architecture

Winter 24-25 42
 Architectural Styles
The architectural styles is used to describes a system which has :

(1)set of components (e.g., a database, computational modules) that perform a

function required by a system,

(2)set of connectors that enable “communication, coordination and cooperation”

among components,

(3)constraints that define how components can be integrated to form the system,

and

(4)semantic
Winter 24-25 models that enable a designer to understand the overall properties
 Taxonomy of Styles in Software
 Data-centered architectures
There is a central data server which is accessed by clients
 Data flow architectures
Data travels through a series of components
 Call and return architectures
Classical
 Object-oriented architectures
Modern style. Components pass messages
 Layered architectures
High-level to machine level

Winter 24-25
 Data-Centered Architecture

Winter 24-25
Data-Centered Architecture

 A data store (e.g., a file or database) resides at the center of this architecture

and is accessed frequently by other components that update, add, delete, or

modify data within the store.

 The main goal is to integrate the data

 The shared data may be a passive repository or an active blackboard

 Passive repository means the client software accesses the data independent of

any changes to the data or the actions of other client software.

 A variation on this approach transforms the repository into a “blackboard”

Winter 24-25 46
 Data Flow Architecture
 This architecture is used when input has to be
transformed into output through a series of
computational components.
 The main goal is modifiability
Pipe-and-filter style
 A pipe-and-filter pattern has a set of components,
called filters, connected by pipes that transmit data
from one component to the next.
 The filters incrementally transform the data
 The filter does not require knowledge of the workings
of its neighboring filters.
Batch sequential style
 If the data flow degenerates into a single line of
transforms, it is termed batch sequential.
Winter 24-25 47
 Call and Return
Architecture
 This architectural style enables to achieve a program structure that is relatively easy to
modify and scale.

Substyles of call and return architecture:

Main program/subprogram architectures

This style decomposes the function into a control

hierarchy where a main program invokes a

number of program components which in turn

may invoke other components.

Remote procedure call architectures

The components of a main program/subprogram

architecture
Winter 24-25 are distributed across multiple 48
 Object-oriented architectures

 The components of a system encapsulate data and the operations

that are applied to manipulate the data.

 Communication between components are accomplished through

message passing.

Winter 24-25 49
 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

Winter 24-25 50
services and application software
 ARCHITECTURAL DESIGN PROCESS

Architectural Design Steps

1) Represent the system in context

2) Define archetypes

3) Refine the architecture into components

4) Describe instantiations of the system

Winter 24-25 51
 1. Represent the System in Context

Winter 24-25 52
 2. Define Archetypes

Winter 24-25 53
 3. Refine the Architecture into Components

Winter 24-25 54
 4. Describe Instantiations of the System

Winter 24-25 55
 Architectural Mapping
 Structured design provides a convenient transition from a data flow diagram to software Architecture

Types of information flow

The 2 different types of information flows:

1. Transaction flow - a single data item triggers information flow along one of many paths

2. Transform flow

o overall data flow is sequential and flows along a small number of straight line paths

o Incoming Flow: The paths that transform the external data into an internal form

o Transform Center: The incoming data are passed through a transform center and begin to move along paths
that lead it out of the software

o Outgoing Flow: The paths that move the data out of the software

Winter 24-25 56
 Steps Involved

 Step 1. Review the fundamental system model.

 Step 2. Review and refine data flow diagrams for the software.

 Step 3. Determine whether DFD has transform or transaction flow characteristics

 Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries

 Step 5. Perform “first-level factoring”

 Step 6. Perform “second-level factoring”

 Step 7. Refine the first iteration program structure using design heuristic

Winter 24-25 57
Step 1. Review the fundamental system model.

SAFE HOME PROJECT

Winter 24-25 58
Step 2. Review and refine data flow diagrams for the software.

Winter 24-25 59
Step 3. Determine whether DFD has transform or transaction flow
characteristics.

 in general---transform flow

 special case---transaction flow

Winter 24-25 60
Step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries

Winter 24-25 61
Step 5. Perform “first-level factoring”

Winter 24-25 62
Step 6. Perform “second-level factoring”

Winter 24-25 63
Step 7: Refine the first iteration program structure using design heuristics

Winter 24-25 64