1. Designing the system Conceptual design and technical design
Design styles, techniques and tools
Characteristics of good design
Validating designs
Documenting the design
Chapter 5

2. Conceptual design Tells the customer what the system will do Answers:
Where will the data come from?
What will happen to the data in the system?
What will the system look like to users?
What choices will be offered to users?
What is the timing of events?
What will the reports and screens look like?
Characteristics of good conceptual design
in customer language with no technical jargon
describes system functions
independent of implementation
linked to requirements
Chapter 5

3. Technical design Tells the programmers what the system will do
Includes:
major hardware components and their function
hierarchy and function of software components
data structures
data flow
Chapter 5

4. Conceptual and technical designs
Chapter 5

5. Difference in design documentation
Chapter 5

6. Five ways to create designs
Modular decomposition
Data-oriented decomposition
Event-oriented decomposition
Outside-in design
Object-oriented design
Chapter 5

7. Levels of decomposition
Chapter 5

8. “Toaster model”
Chapter 5

9. Three design levels
Architecture: associates system components with capabilities
Code design: specifies algorithms and data structures for each component
Executable design: lowest level of design, including memory allocation, data formats, bit patterns
Chapter 5

10. Design styles Pipes and filters Object-oriented design
Implicit invocation
Layering
Repositories
Interpreters
Process control
Client-server
Chapter 5

11. Pipes and filters
Chapter 5

12. Layered security architecture
Chapter 5

13. Blackboard model
Chapter 5

14. Interpreter example
Chapter 5

15. Feedback and feed-forward systems
Chapter 5

16. Ring and star topologies for distributed systems
Chapter 5

17. Example of implicit invocation
Chapter 5

18. Important design issues
Modularity and levels of abstraction
Collaborative design
Designing the user interface
metaphors, mental model, navigation rules, look and feel
cultural issues
user preferences
Concurrency
Design patterns and reuse
Chapter 5

19. Example of abstraction
Rearrange L in non-decreasing order
DO WHILE I is between 1 and (length of L)-1:
Set LOW to index of smallest value in L(I), ..., L(length of L)
Interchange L(I) and L(LOW)
END DO
Chapter 5

20. Chapter 5

21. Typical design space
Chapter 5

22. Characteristics of good design
Component independence
coupling
cohesion
Exception identification and handling
Fault prevention and tolerance
active
passive
Chapter 5

23. Component coupling
Chapter 5

24. The range of coupling measures
Chapter 5

25. Example of content coupling
Chapter 5

26. Example of common coupling
Chapter 5

27. Types of cohesion
Chapter 5

28. Examples of cohesion
Chapter 5

29. Scope of control
Chapter 5

30. Techniques for improving design
Reducing complexity
Design by contract
Prototyping design
Fault-tree analysis
Chapter 5

31. Portion of power plant control system
Chapter 5

32. Cut-set tree generated from the fault tree
Chapter 5

33. Fault rate vs. system design complexity
Chapter 5

34. Design evaluation and validation
Mathematical validation
Measuring design quality
Comparing designs
one specification, many designs
comparison table
Design reviews
Chapter 5

35. Shared data solution for KWIC
Chapter 5

36. Abstract data type solution for KWIC
Chapter 5

37. Implicit invocation solution for KWIC
Chapter 5

38. Pipe-and-filter solution to KWIC
Chapter 5

39. Chapter 5

40. Design reviews Preliminary design review Critical design review
examines conceptual design with customer and users
Critical design review
presents technical design to developers
Program design review
programmers get feedback on their designs before implementation
Chapter 5

41. Questions for any design review
Is it a solution to the problem?
Is it modular, well-structured, and easy to understand?
Can we improve the structure and understandability?
Is it portable to other platforms?
Is it reusable?
Is it easy to modify or expand?
Does it support ease of testing?
Does it maximize performance, where appropriate?
Does it reuse components from other projects, where appropriate?
Are the algorithms appropriate, or can they be improved?
If this system is to have a phased development, are the phases interfaced sufficiently so that there is an easy transition from one phase to the next?
Is it well-documented, including design choices and rationale?
Does it cross-reference the components and data with the requirements?
Does it use appropriate techniques for handling faults and preventing failures?
Chapter 5

42. Documenting the design
design rationale
menus and other display-screen formats
human interfaces: function keys, touch screen descriptions, keyboard layouts, use of a mouse or joystick
report formats
input: where data come from, how they are formatted, on what media they are stored
output: where data are sent, how they are formatted, on what media they are stored
general functional characteristics
performance constraints
archival procedures
fault-handling approach
Chapter 5