Lecture 7

Software Design
BITP 2213 Software Engineering
Content

Software design

Software design process

Software architecture

Detail design

Software Design Document (SDD)

2
 Where are we NOW?
System in scenario Requirement
“as is”
Specification

System in scenario
Architecture
“to be”
Design
Implementation
Testing
Deployment
Maintenance
What is Design?

Creative
transformation
Problem Solution
process

Deriving a solution which satisfies software

requirements

4
In our case . . .

SDD

SRS

Workable pieces

• Goal : To make implementation simple and efficient

What is Software Design?
“The process of defining the software
architecture, components, modules,
interfaces, and data for a software system to
satisfy specified requirements.”

Reference :
Thayer, R. H. (2004). "Software Design Part 1." IEEE Software: 110.
Software Design is …
• Activity that acts as a bridge between requirements
and the implementation of the software
• Provides structure to any artifact
– Decomposes system into parts
– Assigns responsibilities
– Ensures that parts fit together to achieve a global goal

7
Software Design Process

8
Software Design Process
• Architectural design - Identify sub-systems
• Abstract specification - Specify sub-systems
• Interface design - Describe sub-system interfaces
• Component design - Decompose sub-systems into
components
• Data structure design - Design data structures to
hold problem data
• Algorithm design - Design algorithms for problem
functions

9
Software Architecture is …
“The architecture of a system is comprehensive
framework that describes its form and structure - its
components and how they fit together”

Jerrold Grochow, Pressman, Ch 10

10
Software Architecture …
• Provides a way of analyzing systems at a high level of
abstraction
– Maps analysis model (emphasis on problem domain) to design model
(emphasis on solution domain)
• Provide fundamental framework for structuring the
system and guides the development of the design.
• 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 the design process is a description of
the software architecture.
11
Software Architecture describes …

(large-scale)
subsystems & global control protocols for management of
components &
its organization structures communication data
its organization

12
 Architectural design
• An early stage of the system design process.
• Represents the link between specification and
design processes.
• Often carried out in parallel with some
specification activities.
• It involves identifying major system
components and their communications.

13
Role of Software Architecture?
Stakeholder communication
• Architecture may be used as a focus of discussion by system stakeholders.

System analysis
• Means that analysis of whether the system can meet its non-functional
requirements is possible.
• Exposes the blueprint of the system, which makes it easier to understand the
implications of change

Large-scale reuse
• The architecture may be reusable across a range of systems

14
Architectural Design Decision
• Is there a generic application architecture that can be
used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?

15
How Architecture Affects Implementation?
Performance
• Localize critical operations and minimize communications. Use large rather than fine-grain
components.

Security
• Use a layered architecture with critical assets in the inner layers.

Safety
• Localize safety-critical features in a small number of sub-systems.

Availability
• Include redundant components and mechanisms for fault tolerance.

Maintainability
• Use fine-grain, replaceable components.

16
Subsystem and Module
A sub-system is a system in its own right
whose operation is independent of the
services provided by other sub-systems.
A module is a system component that
provides services to other components
but would not normally be considered as
a separate system

17
Architectural Model
Structuring Model
• The system is decomposed into several principal sub-systems and
communications between these sub-systems are identified

Control Modelling
• A model of the control relationships between the different parts of
the system is established

Modular decomposition
• The identified sub-systems are decomposed into modules

18
Architectural Model
Structural Decomposition
Control Model
Model Model
• Repository • Centralized • Object Model
Model Model • Pipelining
• Client Server • Event-Driven Model
Model Model
• Abstract
Machine
(Layered)
Model

19
Repository Model
• When to use ?
– Sub-systems must exchange data.
– Large amount of data to be shared

• 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.

20
Example : CASE Tool Set

21
Repository Model Characteristics
• Advantages
– Efficient way to share large amounts of data;
– Sub-systems need not be concerned with how data is produced
Centralised management e.g. backup, security, etc.
– Sharing model is published as the repository schema.

• Disadvantages
– Sub-systems must agree on a repository data model. Inevitably a
compromise;
– Data evolution is difficult and expensive;
– No scope for specific management policies;
– Difficult to distribute efficiently.

22
Client Server Model
• What is 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.

• When to use?
– Set of clients which call on common services.
– Network which allows clients to access servers.

23
Example : Film and Picture Library

24
Client Server Characteristics
• Advantages
– Distribution of data is straightforward;
– Makes effective use of networked systems. May require cheaper
hardware;
– Easy to add new servers or upgrade existing servers.

• Disadvantages
– No shared data model so sub-systems use different data organisation.
Data interchange may be inefficient;
– Redundant management in each server;
– No central register of names and services - it may be hard to find out
what servers and services are available.

25
Abstract Machine (Layered) Model
• Used to model the interfacing of sub-systems.
• Organises the system into a set of layers (or abstract
machines) 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.
• However, often artificial to structure systems in this
way.

26
Example : Version Management System
Configur ation managem ent system layer

Object management syste m layer

Database syst em layer

Ope rating system layer

27
Control Styles
• Are concerned with the control flow between sub-
systems.
• Distinct from the system decomposition model.

Centralised Control Event-Based Control

One sub-system has overall Each sub-system can respond

responsibility for control and to externally generated events
starts and stops other sub- from other sub-systems or the
systems. system’s environment.

28
Centralized Control
• A control sub-system takes responsibility for managing the
execution of other sub-systems.
• Call-return model
– Top-down subroutine model where control starts at the top of a
subroutine hierarchy and moves downwards. Applicable to sequential
systems.
• Manager model
– Applicable to concurrent systems. One system component controls the
stopping, starting and coordination of other system processes. Can be
implemented in sequential systems as a case statement.

29
Call Return Model

30
Real-time system control

31
Event-driven systems
• Driven by externally generated events where the timing of the
event is outwith the control of the sub-systems which process
the event.
• Two principal event-driven models
– Broadcast models. An event is broadcast to all sub-systems. Any sub-
system which can handle the event may do so;
– Interrupt-driven models. Used in real-time systems where interrupts
are detected by an interrupt handler and passed to some other
component for processing.
• Other event driven models include spreadsheets and
production systems.

32
Broadcast model
• Effective in integrating sub-systems on different
computers in a network.
• Sub-systems register an interest in specific events.
When these occur, control is transferred to the sub-
system which can handle the event.
• Control policy is not embedded in the event and
message handler. Sub-systems decide on events of
interest to them.
• However, sub-systems don’t know if or when an
event will be handled.

33
Selective broadcasting

34
Interrupt-driven systems
• Used in real-time systems where fast response to an
event is essential.
• There are known interrupt types with a handler
defined for each type.
• Each type is associated with a memory location and a
hardware switch causes transfer to its handler.
• Allows fast response but complex to program and
difficult to validate.

35
Interrupt-driven control

36
Sub-systems and modules
• A sub-system is a system in its own right whose
operation is independent of the services provided by
other sub-systems.
• A module is a system component that provides
services to other components but would not
normally be considered as a separate system.

37
Modular decomposition
• Another structural level where sub-systems are decomposed
into modules.
• Two modular decomposition models covered
– An object model where the system is decomposed into interacting
object;
– A pipeline or data-flow model where the system is decomposed into
functional modules which transform inputs to outputs.
• If possible, decisions about concurrency should be delayed
until modules are implemented.

38
Object models
• Structure the system into a set of loosely coupled
objects with well-defined interfaces.
• Object-oriented decomposition is concerned with
identifying object classes, their attributes and
operations.
• When implemented, objects are created from these
classes and some control model used to coordinate
object operations.

39
Invoice processing system

40
Object model advantages
• Objects are loosely coupled so their implementation
can be modified without affecting other objects.
• The objects may reflect real-world entities.
• OO implementation languages are widely used.
• However, object interface changes may cause
problems and complex entities may be hard to
represent as objects.

41
Function-oriented pipelining
• Functional transformations process their inputs to
produce outputs.
• May be referred to as a pipe and filter model (as in
UNIX shell).
• Variants of this approach are very common. When
transformations are sequential, this is a batch
sequential model which is extensively used in data
processing systems.
• Not really suitable for interactive systems.

42
Invoice processing system

43
Pipeline model advantages
• Supports transformation reuse.
• Intuitive organisation for stakeholder
communication.
• Easy to add new transformations.
• Relatively simple to implement as either a
concurrent or sequential system.
• However, requires a common format for data
transfer along the pipeline and difficult to support
event-based interaction.

44
Architectural Conflicts
• Using large-grain components improves performance
but reduces maintainability.
• Introducing redundant data improves availability but
makes security more difficult.
• Localising safety-related features usually means more
communication so degraded performance.

45
Interface design
• Interface is a set of operations that describes the
externally observable behavior of a class and
provides access to its operations
• Important elements
– User interface (UI)
– External interfaces to other systems
– Internal interfaces between various design components
• Modeled using UML collaboration diagrams

46
Component Level Design
• Describes the internal detail of each software
component
• Defines
– Data structures for all local data objects
– Algorithmic detail for all component processing functions
– Interface that allows access to all component operations
• Modeled using UML component and activity
diagrams, and pseudocode (PDL)

47
Data Structure Design
• Systematic analysis applied to functional behavior, can be
applied to data.
• Data structures and operations should be identified.
• Establish a data dictionary and use it to guide both data
and program design.
• Defer low level data structure decisions until late in the
design.
• Information hiding.
• Libraries of useful data structures and operators is
developed.
• Environment must support creation of ADT’s (abstract
data types).

48
Writing Algorithm
• An algorithm is a general solution of a problem which
can be written as a verbal description of a precise,
logical sequence of actions.
• E.g. : Cooking recipes, assembly instructions for
appliances and toys, or precise directions to reach a
friend's house
• A computer program is an algorithm expressed in a
specific programming language.
• An algorithm is the key to developing a successful
program.

49
Expressing Algorithm
• Algorithms can be expressed using natural languages,
pseudocode, flowcharts, and programming languages.
• Natural language
– tend to be verbose and ambiguous
– rarely used for complex or technical algorithms.
• Pseudocode and flowcharts
– structured ways to express algorithms
– avoid many of the ambiguities common in natural language
statements
– independent of a particular implementation language
• Programming languages
– Expressing algorithms in a form that can be executed by a compute

50
 Start Class : Login
Method : verifyLogin
Input : user id, password
Start
Read user id and password
Connect to database
Get user id and password from database
If record size > 1
Get user id and password Display error message “Invalid user id and password”
from database return false
Else
Display main page
return true
End
Is user id and
password valid?
public void verifyLogin(String userid, String pwd) {
…
yes no …
ResultSet rs = new ResultSet();
Display main page rs = dbUser.getUser();
if(rs.size() > 1){
Message m = new Message();
m.displayMessage(Invalid user id and password);
Display error message } else {
MainPage mp = new MainPage();
mp.setVisible(true);
End }

51
What is a Good Design?
• A “good” design may be the most efficient, the cheapest, the
most maintainable, the most reliable,etc
• Include exception identification and handling
• Include fault prevention and fault tolerance
• A good design produces code that is:
– Easier to debug, test, maintain, change and extend
• In engineering, good design offers economy of resources
• For software engineering, one can define a good design as:
“A design which balances trade-offs to minimise the total cost of the
system over its entire lifetime”
End of Lecture 7
Software Design
BITP 2213 Software Engineering

Next on Lecture 8
Software Testing