1. Design Concepts and Principles
Lecture 6
Design Concepts and Principles

2. Analysis to Design PSPEC ERD DFD STD CSPEC THE DESIGN MODEL
Data
Object
Description
PSPEC
component
(procedural)
design
ERD
DFD
Data
Dictionary i n t e r f a c e 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?
Spec
Prototype
Design
modelling

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

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
Independent
Communication, Procedural
Coincidentally, logically, temporal
Compiler/OS
Content
External, Common
Control
Data, Stamp
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 clients • algorithm controlled
interface
• data structure
• 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 Data-centered architectures
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
filter
pipes
(a) pipes and filters
(b) batch sequential

21. Call and Return Architecture
main program/subprogram
remote procedure call

22. Layered Architecture components user interface layer application layer
utility layer
core layer

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

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
function 1
function 3
function 2

28. Vertical Partitioning: Factoring
design so that decision making and work are stratified
decision making modules should reside at the top of the architecture
workers
decision-makers

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 Transform flow Transaction flow transaction
action paths
transaction
transaction centre

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

36. Second Level Mapping

37. Transaction Flow T
incoming flow
action path

38. Transaction Example fixture fixture setting servos commands operator
process
fixture setting
report
robot control
fixture
servos
display
screen
robot
control
software
in reality, other
would also be shown
assembly
record

39. Refining the Analysis Model1.
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!

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
status
fixture
servos
read
operator
commands
fixture setting
valid command
analyse
fixture
fixture
status
determine
command
select report
type
report
generate
control
display
report
robot
screen
send
control
assembly
value
record
robot
control
system
robot control

42. Level 2 Data Flow Diagram
read
command
produce
error
msg
validate
determine
type
fixture
status
setting
format
record
calculate
output
values
report
assembly
invalid command
error msg
robot control
send
control
value
start /stop
combined
raw setting
fixture setting

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 error msg produce error msg format read
command
produce
error
msg
validate
determine
type
fixture
status
setting
format
record
calculate
output
values
report
assembly
invalid command
error msg
robot control
send
control
value
start /stop
combined
raw setting
fixture setting

46. Map the Flow Model process operator commands command input controller
read
validate
produce
error
message
determine
type
fixture
status
report
generation
send
control
value
each of the action paths must be expanded further

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 user’s 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 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.

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

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