1

Software Engineering

Software Design
Design Basics 2
Translating Analysis  Design
 4
Design Challenges
Design is a wicked problem
Design is a sloppy process
Design is About Trade-Offs and Priorities
Design Involves Restrictions
Design is Non-Deterministic – no right way
Design is a Heuristic Process – trail and error
Design: Fundamental Concepts 5

 Real world Objects

 Abstraction
 Encapsulation
 Information Hiding
 Inheritance
 Modularity
 Architecture
 6

Abstraction
 Safely ignore some details – handling different details at
different levels.

Advantages:
 Allows to ignore irrelevant information.
 7

Data Abstraction
 8

Encapsulation
Abstraction – Allowed to look at object at high level of detail
Encapsulation – Not allowed to look at object at any other level of
detail.

Not only you allowed to take a simpler view of a complex concept,

you are not allowed to look at any of the details of the complex
concept.

What you see is what you get—it’s all you get!

Example: Door in a house
 9

Inheritance & Information Hiding

 Inherit when Inheritance simplifies the Design

Information Hiding – class visibility

 Interface to a class should reveal as little as possible about its
inner workings.
 A good class interface is like the tip
of an iceberg, leaving most of the
class unexposed.
 10

Modular Design
easier to build, easier to change, easier to fix ...
 11

Number of modules in a software

module development cost

cost of
software
M

optimal number number of modules

of modules
 12

Modularity - Functional Independence

Coupling
Cohesion
 13

Modularity – Coupling
 The degree of dependence such as the amount of
interactions among components

No dependencies Loosely coupled Highly coupled

some dependencies many dependencies
 14

Types of Coupling
 15

Modularity – Content Coupling

 Definition: One component uses / modifies another.
 Example:
 Component directly modifies another’s data
 Component modifies another’s code, e.g., jumps (goto) into the
middle of a routine
 16

Modularity – Common Coupling

 Definition: More than one component share data such as global
data structures

 Usually a poor design choice because

 Lack of clear responsibility for the data
 Reduces readability
 Difficult to determine all the components that affect a data element
(reduces maintainability)
 Difficult to reuse components
 17

Modularity – External Coupling

 External coupling occurs when two modules share an
externally imposed data format, communication
protocol, or device interface.

 Mainly related to the communication to external tools

and devices.
 18

Modularity – Control Coupling

 Definition: Component passes control parameters to
coupled components.
 May be either good or bad, depending on situation.
 Bad if parameters indicate completely different behavior
 Good if parameters allow factoring and reuse of functionality

 Good example: sort that takes a comparison function as an

argument.
 The sort function is clearly defined: return a list in sorted order,
where sorted is determined by a parameter.
 19

Modularity – Stamp Coupling

 Definition: Component passes a data structure to another
component that does not have access to the entire
structure.
 Requires second component to know how to manipulate the
data structure (e.g., needs to know about implementation).
 The second has access to more information that it needs.
 May be necessary due to efficiency factors: this is a choice
made by insightful designer, not lazy programmer.
 20

Modularity – Data Coupling

 Data coupling occurs when modules share data
through, for example, parameters.
 Each datum is an elementary piece, and these are the
only data shared

 Eg., passing an integer to a function that computes a

square root).
 21

Modularity - Cohesion
 The degree to which all elements of a component are
directed towards a single task.
 The degree to which all elements directed towards a
task are contained in a single component.
 Internal glue with which component is constructed
 All elements of component are directed toward and
essential for performing the same task.
 22

Modularity - Types of Cohesion

 23

Modularity – Coincidental Cohesion

 Definition: Parts of the component are unrelated
functions, processes or data.
 Parts of the component are only related by their
location in source code.
 Elements needed to achieve some functionality are
scattered throughout the system.
 Accidental
 Worst form
 24

Modularity – Logical Cohesion

 Definition: Elements of component are related logically
and not functionally.
 Several logically related elements are in the same
component and one of the elements is selected by the
client component.
 25

Modularity – Temporal Cohesion

 Definition: Elements are related by timing involved
 Elements are grouped by when they are processed.
 Example: An exception handler that
 Closes all open files
 Creates an error log
 Notifies user
 Lots of different activities occur, all at same time
 26

Modularity – Procedural Cohesion

 Definition: Elements of a component are related only
to ensure a particular order of execution.
 Actions are still weakly connected and unlikely to be
reusable.
 Example:
 ...
 Write output record
 Read new input record
 Pad input with spaces
 Return new record
 27

Modularity – Communicational Cohesion

 Definition: Functions performed on the same data or to produce
the same data.
 Examples:
 Update record in data base and send it to the printer
 Update a record on a database
 Print the record
 Fetch unrelated data at the same time.
 To minimize disk access
 28

Modularity – Sequential Cohesion

 Definition: The output of one part is the input to another.
 Data flows between parts (different from procedural cohesion)
 Occurs naturally in functional programming languages
 Good situation
 29

Modularity – Functional Cohesion

 Definition: Every essential element to a single
computation is contained in the component.
 Every element in the component is essential to the
computation.
 Ideal situation
 What is a functionally cohesive component?
 One that not only performs the task for which it was designed
but it performs only that function and nothing else.
Architectural Design
 Architectural Design
 Process of defining a collection of hardware and
software components and their interfaces to establish
the framework for the development of a software
system.
 The design process for identifying the sub-systems
making up a system and the framework for sub-system
control and communication is architectural design.
 The output of this design process is a description of the
software architecture.
 Architectural Design

 An early stage of the system design process.

 Represents the link between specification and design processes.

 It involves identifying major system components and their

communications.
Architectural Style
Style describes a system category that encompasses

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

perform a function required by a system;

2. a set of connectors that enable “communication, co-ordinations and

cooperation” among components;

3. constraints that define how components can be integrated to form the

system

4. semantic models that enable a designer to understand the overall

properties of a system
Architectural Style
It can be represented by:

 Data-centered architecture (Repository model)

 System Structuring
 Client – Server Model
 Data flow architecture
 Call and return architecture
 Object oriented architecture
 Layered architecture.
Data-centered architecture
(Repository model)
Data-centered architecture
(Repository model)
Sub-systems must exchange data. This may be
done in two ways:
 Shared data is held in a central database or repository and may be
accessed by all sub-systems;
 Each sub-system maintains its own database and passes data explicitly to
other sub-systems.
When large amounts of data are to be shared, the
repository model of sharing is most commonly
used.
 System Structuring
 Concerned with decomposing the system into interacting sub-
systems.

 The architectural design is normally expressed as a block diagram

presenting an overview of the system structure.

 More specific models showing how sub-systems share data, are

distributed and interface with each other may also be developed.
System Structuring: Example
 Client-server model
Distributed system model which shows how data and
processing is distributed across a range of
components.
Set of stand-alone servers which provide specific
services such as printing, data management, etc.
Set of clients which call on these services.
Network which allows clients to access servers.
Client-server Architecture
 Data Flow architecture
 This architecture is applied when input data are to be
transformed through a series of components into output data.

 A pipe and filter pattern: set of components, called filters,

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

 Each filter works independently and is designed to expect data

input of a certain form, and produces data output of a specified
form.

 Filter does not require knowledge of the working of its

neighboring filters.
Data Flow architecture

Pipes and filters

Batch Sequential
 Abstract machine (layered) model
Used to model the interfacing of sub-systems.

Organises the system into a set of layers each of which

provide a set of services.

Supports the incremental development of sub-systems in

different layers. When a layer interface changes, only the
adjacent layer is affected.
Layered Architecture
Call and return architecture
 Architecture style enables a software designer (system
architect) to achieve a program structure that is
relatively easy to modify and scale.

 Two sub-styles exist within this category:

1. Main/sub program architecture

2. Remote procedure Call architecture

Call and return architecture
Object-oriented architecture
 The object-oriented paradigm, like the abstract data type
paradigm from which it evolved.

 Components of a system summarize data and the

operations that must be applied to manipulate the data.

 Communication and coordination between components is

accomplished via message passing.
Object-oriented architecture
 Structured / Detailed Design 49

 The process of refining and expanding the preliminary design

phase of a system or component to the extent that the design
is sufficiently complete to be implemented.

 During Detailed Design designers go deep into each

component to define its internal structure and behavioral
capabilities, and the resulting design leads to natural and
efficient construction of software.
Structured / Detailed Design - Major 50

Tasks
1. Understanding the architecture and requirements
2. Creating detailed designs
3. Evaluating detailed designs
4. Documenting software design
5. Monitoring and controlling implementation
 Structured / Detailed Design - Major Tasks 51

1. Understanding the architecture and requirements - Unlike the software architecture, where the
complete set of requirements are evaluated and well understood, designers during detailed design
activity focus on requirements allocated to their specific components.

2. Creating detailed designs - When creating detailed designs, focus is placed on the topics such as

Interface Design - Internal & External, Graphical User Interface (GUI) Design, Internal Component Design
& Data Design
3. Evaluating detailed designs - The most popular technique for evaluating detailed designs involves
Technical Reviews.
4. Documenting software design - Documentation of a project’s software design is mostly captured in
the software design document (SDD), also known as software design description. The SDD is used widely
throughout the development of the software.
5. Monitoring and controlling implementation - Monitor and control detailed design.
 52

Structured Design

 Transaction analysis

 Transform analysis

 System integration
 53

Structured Design
 After set of DFDs were produced, there are three steps to turn the design into
structure charts (from which the system can be implemented):

 1. Transaction analysis
– divides the system into tractable units
 2. Transform analysis
– converts units into structure charts
 3. System integration
– recombines charts by linking units together
 54

Structured Design
 55

Step 1: Transaction analysis

A transaction has five basic components:
 1. event in the system’s environment that causes the transaction to occur
 2. stimulus that is applied to the system to inform it about the event
 3. activity that is performed by the system as a result of the stimulus
 4. response that is generated in terms of output from the system
 5. effect that this has on the environment of the system
 56

Step 1: Transaction analysis – Eg.,

 1. event: student ‘signs up’ for bank account
 2. stimulus: information about student, university, date of opening account,
grant source, etc.
 3. activity: add account details to bank records
 4. response: free gifts to student, cheque book, debit card, bank statements
 5. effect: student can spend money
 57

Step 2: Transform analysis

 Goal is to find a module’s core function:
– take DFD model of the problem and transform it into hierarchical
structure

1. First, identify the central transform in the DFD

2. DFD is ‘picked up’ by central transform so other functions hang from it

 58

Step 2: Transform analysis

 59

Step 3: System integration

 Finally, last step combines all separate charts from the transaction and
transform analyses:
 60

Summary of Structured design

• Transaction analysis to identify components
 1. Event
 2. Stimulus
 3. Activity
 4. Response
 5. Effect
• Transform analysis to design components
 1. Draw DFD
 2. Identify central transform
 3. Produce first-cut structure chart
 4. Revise and develop design
• System integration to re-combine components
 Detailed Design – Refactoring 61

 Refactoring is usually motivated by noticing a code smell.

 For example the method at hand may be very long, or it may be a near
duplicate of another nearby method.
 Once recognized, such problems can be addressed by refactoring the
source code, or transforming it into a new form that behaves the same as
before but that no longer "smells".
 For a long routine, one or more smaller subroutines can be extracted; or
for duplicate routines, the duplication can be removed and replaced with
one shared function.
 Failure to perform refactoring can result in accumulating technical debt.
 Detailed Design – Refactoring 62

There are two general categories of benefits to the activity of refactoring.

1. Maintainability: It is easier to fix bugs because the source code is easy to read /
manage.

2. Extensibility: It is easier to extend the capabilities of the application if it uses

recognizable design patterns, and it provides some flexibility where none before may
have existed.
SUMMARY 63

 This module discussed in detail about the various design concepts and
principles.
 Abstraction and Refinement are discussed in this module.
 The Modularity is explained with two major things such as Cohesion &
Coupling.
 The various types of cohesion are discussed in detail.
 The different coupling are explained in this module.
 The Architectural Design is provided with rules and regulations.
 The Detailed Design is explained with Transaction and Transformation
analysis.
 The Refactoring analysis is also discussed in the direction of software
design.