Lecture 6

Design Concepts and Principles

 Analysis to Design

Data PSPEC component

Object (procedural)
Description design
ERD DFD

Data interface
Dictionary design

architectural
design
STD
data
design
CSPEC

THE ANALYSIS MODEL THE DESIGN MODEL

Where Do We Begin?

modelling
Prototype
Spec

Design
Design Principles [Dav95]
 The design process should not suffer from
‘tunnel vision.’
 The design should be traceable to the
analysis model.
 The design should not reinvent the wheel.
 The design should “minimize the intellectual
distance” between the software and the
problem as it exists in the real world.
 The design should exhibit uniformity and
integration.
Design Principles [Dav95]
 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
conceptual (semantic) errors.
 Fundamental Concepts
 abstraction—data, procedure, control
 refinement—elaboration of detail for all abstractions
 modularity—compartmentalization of data and
function
 architecture—overall structure of the software
 Structural properties
 Extra-structural properties
 Styles and patterns
 procedure—the algorithms that achieve function
 hiding—controlled interfaces
Data Abstraction
door

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

implemented as a data structure

Procedural Abstraction
open

details of enter
algorithm

implemented with a "knowledge" of the

object that is associated with enter
Stepwise Refinement
open

walk to door;
reach for knob;

open door; repeat until door opens

turn knob clockwise;
walk through; if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
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 number of modules

of modules
 Functional Independence
COHESION - the degree COUPLING - the degree
to which a module to which a module is
performs one and only “connected” to other
one function. modules in the system.
HIGH
 Independent X Compiler/OS
• Communication, • Content
Procedural • External, Common
X Coincidentally, • Control
logically,  Data, Stamp
temporal
LOW
 Architecture
“The overall structure of the software and the
ways in which that structure provides
conceptual integrity for a system.” [SHA95a]

Structural properties: 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: address how the design
architecture achieves requirements for performance, capacity,
reliability, security, adaptability, and other system characteristics.
Families of related systems: draw upon repeatable patterns
that are commonly encountered in the design of families of
similar systems.
Information Hiding
module • algorithm
controlled
interface • data structure
• details of external interface

• resource allocation policy

clients "secret"

a specific design decision

Architectural Design
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.
Data Design
 refine data objects and develop a set of
data abstractions
 implement data object attributes as one or
more data structures
 review data structures to ensure that
appropriate relationships have been
established
 simplify data structures as required
 Component Level Data Design
1. Apply systematic analysis principles to function
and behavior to data.
2. Identify all data structures and the operations to
be performed on them
3. Establish a data dictionary.
4. Defer low level data design decisions.
5. Reveal data structure representation only to
those modules that must make direct use of its
content.
6. Develop a library of useful data structures and
the operations that may be applied to them
7. Abstract data types should be supported.
Architectural Styles
Each 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, coordination
and cooperation” among components, (3) constraints that
define how components can be integrated to form the
system, and (4) semantic models that enable a designer to
understand the overall properties of a system by analyzing
the known properties of its constituent parts.

 Data-centered architectures
 Data flow architectures
 Call and return architectures
 Object-oriented architectures
 Layered architectures
Data-Centered Architecture
Client Client
software software

Client Client
software software

Data store
(repository or
blackboard)

Client
Client software
software

Client Client
software software
Data Flow Architecture
pipes filter filter

filter filter filter filter

filter filter filter

filter

(a) pipes and filters

filter filter filter filter

(b) batch sequential

Call and Return Architecture
 main program/subprogram
 remote procedure call
Layered Architecture
components

user interface layer

application layer

utility layer

core layer
Analyzing Architectural Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment
description.
3. Describe the architectural styles/patterns that have
been chosen to address the scenarios and
requirements: module, process and data flow views
4. Evaluate quality attributes by considered each
attribute in isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural
style.
6. Critique candidate architectures (developed in step 3)
using the sensitivity analysis conducted in step 5.
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."

architectural design
Deriving Program Architecture

Program
Architecture
Partitioning the Architecture
 “horizontal” and “vertical”
partitioning are required
 Horizontal Partitioning
 define separate branches of the module
hierarchy for each major function
 use control modules to coordinate
communication between functions
function 1 function 3

function 2
Vertical Partitioning: Factoring
 design so that decision making and
work are stratified
 decision making modules should reside
at the top of the architecture
decision-makers

workers
 Why Partitioned Architecture?

 results in software that is easier to test

 leads to software that is easier to maintain
 results in propagation of fewer side effects
 results in software that is easier to extend
Structured Design
 objective: to derive a program
architecture that is partitioned
 approach:
 the DFD is mapped into a program
architecture
 the PSPEC and STD are used to indicate
the content of each module
 notation: structure chart
Flow Characteristics

Transform flow
transaction

action paths
transaction centre

Transaction
flow
General Mapping Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center

working from the boundary outward, map

DFD transforms into corresponding modules

add control modules as required

refine the resultant program structure

using effective modularity concepts
Transform Mapping

b g h
a e f
d
c i
j
data flow model

x1 "Transform" mapping
x2 x3 x4

b c d e f g i

a h j
Factoring
direction of increasing
decision making typical "decision
making" modules

typical "worker" modules

First Level Factoring
main
program
controller

input processing output

controller controller controller
Second Level Mapping
main
D
C
control

B A
A
B
C

mapping from the D

flow boundary outward
Transaction Flow
incoming flow

action path
T
Transaction Example
fixture setting fixture
servos

commands
operator process
operator
report display
commands screen

robot control

robot
control
software
assembly
record
in reality, other
commands
would also be shown
Refining the Analysis Model
1. write an English language processing narrative
for the level 01 flow model

2. apply noun/verb parse to isolate processes, data

items, store and entities

3. develop level 02 and 03 flow models

4. create corresponding data dictionary entries

5. refine flow models as appropriate

... now, we're ready to begin design!

 Deriving Level 1
narrative for " process operator commands“ after noun-verb parse

Process operator command software reads operator commands from

the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture status
is analysed and a fixture setting is output to the fixture servos. When a
report is selected, the assembly record file is read and a report is
generated and displayed on the operator display screen. When robot
control switches are selected, control values are sent to the robot
control system.
Level 1 Data Flow Diagram
operator commands Error msg status fixture
servos
read
operator
commands fixture setting
valid command analyse
fixture
fixture status
determine
command select report
type

generate report
control report display
robot screen

send
control
assembly
value robot
record
control
system
robot control
Level 2 Data Flow Diagram
command error msg

produce
error
msg
status format
read command setting fixture setting
command determine
invalid command setting
validate read raw setting
command fixture
status combined
determine status
type

robot control read

record record
calculate
send output values
control values report
format
value
report

assembly
record

start /stop
Transaction Mapping Principles
isolate the incoming flow path

define each of the action paths by looking for

the "spokes of the wheel"

assess the flow on each action path

define the dispatch and control structure

map each action path flow individually

Transaction Mapping
e f
a d
b
t i
g
h k
l j
data flow model
m
x1 n
Mapping
b t

a x2 x3 x4

d e f g h x3.1 l m n

i j
k
Isolate Flow Paths
command error msg
produce
error
msg
status format
read command setting fixture setting
command invalid command determine
setting
validate read raw setting
command fixture
status combined
determine status
type

robot control read

record record
calculate
send output values
control values report
format
value
report

assembly
record

start /stop
Map the Flow Model
process
operator
commands

command determine
input type
controller

read validate produce fixture report send

command command error status generation control
message controller controller value

each of the action paths must be expanded further

 Refining the Structure Chart
process
operator
commands

command determine
input type
controller

read validate produce fixture report send

command command error status generation control
message controller controller value

read determine format read calculate format

fixture setting setting record output report
status values
Interface Design
 Inter-modular interface design
 driven by data flow between modules
 External interface design
 driven by interface between applications
 driven by interface between software and non-
human producers and/or consumers of
information
 Human-computer interface design
 driven by the communication between human and
machine
User Interface Design
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
unfriendly
Golden Rules
 Place the user in control
 Reduce the user’s memory load
 Make the interface consistent
Place the User in Control
 Define interaction modes in a way that does not
force a user into unnecessary or undesired actions.
 Provide for flexible interaction.
 Allow user interaction to be interruptible and
undoable.
 Streamline interaction as skill levels advance and
allow the interaction to be customized.
 Hide technical internals from the casual user.
 Design for direct interaction with objects that
appear on the screen.
Reduce the User’s Memory Load
 Reduce demand on short-term
memory.
 Establish meaningful defaults.
 Define shortcuts that are intuitive.
 The visual layout of the interface
should be based on a real world
metaphor.
 Disclose information in a progressive
fashion.
Make the Interface Consistent
 Allow the user to put the current
task into a meaningful context.
 Maintain consistency across a family
of applications.
 If past interactive models have
created user expectations, do not
make changes unless there is a
compelling reason to do so.
User Interface Design Models
 System perception — the user’s mental
image of what the interface is
 User model — a profile of all end users of
the system
 System image — the “presentation” of the
system projected by the complete
interface
 Design model — data, architectural,
interface and procedural representations
of the software
User Interface Design Process
Task Analysis and Modeling
 All human tasks required to do the
job (of the interface) are defined and
classified
 Objects (to be manipulated) and
actions (functions applied to objects)
are identified for each task
 Tasks are refined iteratively until the
job is completely defined
 Interface Design Activities
1. Establish the goals and intentions for each task.
2. Map each goal/intention to a sequence of specific actions.
3. Specify the action sequence of tasks and subtasks, also called
a user scenario, as it will be executed at the interface level.
4. Indicate the state of the system, i.e., What does the interface
look like at the time that a user scenario is performed?
5. Define control mechanisms, i.e., The objects and actions
available to the user to alter the system state.
6. Show how control mechanisms affect the state of the system.
7. Indicate how the user interprets the state of the system from
information provided through the interface.
Design Evaluation Cycle