Design Concepts and Principles

1
Lecture 6

• Design Concepts and Principles

2
Analysis to Design
PSPEC
Data Object Description
component (procedural) design
ERD
DFD
i
n
t
e
r
f
a
c
e
Data Dictionary
d
e
s
i
g
n
a
r
c
h
i
t
e
c
t
u
r
a
l
d
e
s
i
g
n
STD
d
a
t
a
d
e
s
i
g
n
CSPEC
THE DESIGN MODEL
THE ANALYSIS MODEL
3
Where Do We Begin?
4
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.

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

6
Fundamental Concepts

• abstractiondata, procedure, control
• refinementelaboration of detail for all
  abstractions
• modularitycompartmentalization of data and
  function
• architectureoverall structure of the software
• Structural properties
• Extra-structural properties
• Styles and patterns
• procedurethe algorithms that achieve function
• hidingcontrolled interfaces

7
Data Abstraction
door
manufacturer
model number
type
swing direction
inserts
lights
type
number
weight
opening mechanism
implemented as a data structure
8
Procedural Abstraction
open
details of enter
algorithm
implemented with a "knowledge" of the
object that is associated with enter
9
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
10
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
11
Functional Independence
COHESION - the degree to which a module
performs one and only one function.
COUPLING - the degree to which a module is
connected to other modules in the system.

HIGH

• Compiler/OS
• Content
• External, Common
• Control
• Data, Stamp

• Independent
• Communication, Procedural
• Coincidentally, logically, temporal

LOW
12
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.
13
Information Hiding
module
algorithm

controlled
data structure
interface

details of external interface

resource allocation policy
clients
"secret"
a specific design decision
14

• Architectural Design

15
Why Architecture?

• The architecture is not the operational software.
  Rather, it is a representation that enables a
  software engineer to
• analyze the effectiveness of the design in
  meeting its stated requirements,
• consider architectural alternatives at a stage
  when making design changes is still relatively
  easy, and
• reduce the risks associated with the construction
  of the software.

16
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

17
Component Level Data Design

• Apply systematic analysis principles to function
  and behavior to data.
• Identify all data structures and the operations
  to be performed on them
• Establish a data dictionary.
• Defer low level data design decisions.
• Reveal data structure representation only to
  those modules that must make direct use of its
  content.
• Develop a library of useful data structures and
  the operations that may be applied to them
• Abstract data types should be supported.

18
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

19
Data-Centered Architecture
Client software
Client software
Client software
Client software
Data store (repository or blackboard)
Client software
Client software
Client software
Client software
20
Data Flow Architecture
21
Call and Return Architecture

• main program/subprogram
• remote procedure call

22
Layered Architecture
23
Analyzing Architectural Design

• Collect scenarios.
• Elicit requirements, constraints, and environment
  description.
• Describe the architectural styles/patterns that
  have been chosen to address the scenarios and
  requirements module, process and data flow views
• Evaluate quality attributes by considered each
  attribute in isolation.
• Identify the sensitivity of quality attributes to
  various architectural attributes for a specific
  architectural style.
• Critique candidate architectures (developed in
  step 3) using the sensitivity analysis conducted
  in step 5.

24
An Architectural Design Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design
25
Deriving Program Architecture
Program Architecture
26
Partitioning the Architecture

• horizontal and vertical partitioning are
  required

27
Horizontal Partitioning

• define separate branches of the module hierarchy
  for each major function
• use control modules to coordinate communication
  between functions

28
Vertical Partitioning Factoring

• design so that decision making and work are
  stratified
• decision making modules should reside at the top
  of the architecture

29
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

30
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

31
Flow Characteristics
32
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
33
Transform Mapping
34
Factoring
35
First Level Factoring
main
program
controller
output
input
processing
controller
controller
controller
36
Second Level Mapping
37
Transaction Flow
38
Transaction Example
39
Refining the Analysis Model
write an English language processing narrative
1.
for the level 01 flow model
apply noun/verb parse to isolate processes, data
2.
items, store and entities
develop level 02 and 03 flow models
3.
create corresponding data dictionary entries
4.
refine flow models as appropriate
5.
... now, we're ready to begin design!
40
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.
41
Level 1 Data Flow Diagram
operator
commands
Error msg
fixture
status
servos
read
operator
commands
fixture setting
analyse
valid command
fixture
fixture
status
determine
command
select report
type
report
generate
display
control
report
screen
robot
send
control
assembly
value
robot
record
control
system
robot control
42
Level 2 Data Flow Diagram
43
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
44
Transaction Mapping
45
Isolate Flow Paths
46
Map the Flow Model
47
Refining the Structure Chart
48
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

49

• User Interface Design

50
Interface Design
Easy to learn?
Easy to use?
Easy to understand?
51
Interface Design
Typical Design Errors

• lack of consistency
• too much memorization
• no guidance / help
• no context sensitivity
• poor response
• unfriendly

52
Golden Rules

• Place the user in control
• Reduce the users memory load
• Make the interface consistent

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

54
Reduce the Users 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.

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

56
User Interface Design Models

• System perception the users 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

57
User Interface Design Process
58
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

59
Interface Design Activities

• Establish the goals and intentions for each task.
• Map each goal/intention to a sequence of specific
  actions.
• Specify the action sequence of tasks and
  subtasks, also called a user scenario, as it will
  be executed at the interface level.
• Indicate the state of the system, i.e., What does
  the interface look like at the time that a user
  scenario is performed?
• Define control mechanisms, i.e., The objects and
  actions available to the user to alter the system
  state.
• Show how control mechanisms affect the state of
  the system.
• Indicate how the user interprets the state of the
  system from information provided through the
  interface.

60
Design Evaluation Cycle