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.
