Week 8 Implementation Design

1
Week 8Implementation Design

• Alex Baker

2
Implementation Design

• System Design
• Describes what the system should do
• Implementation Design
• Describes what the implementer should do

Implementation CGprofile vertexProfile
cgD3D9GetLatestVertexProfile()const char
vertexOptions cgD3D9GetOptimalOptions(
vertexProfile ),    NULL,const char
vertexOptions "-profileopts", "dcls", NULL,
System Design
3
Implementation Design

• System Design
• Describes what the system should do
• Implementation Design
• Describes what the implementer should do

Given what our system design tells us Whats
our plan?
4
Motivation Why Bother with Implementation Design?

• Suppose we code an object-oriented program
• 16 implementers
• No Implementation Design
• What problems might arise?

5
Motivation Why Bother with Implementation Design?

• Suppose we code an object-oriented program
• 16 implementers
• No Implementation Design
• What problems might arise?
• Poorly chosen classes
• Multiple people on the same code
• Functionality in hidden, or multiple, places
• Inefficiencies and interaction problems emerge
• Bad match to the system design
• No common vision

6
3 Goals of Implementation Design

• Provide a shared plan to follow
• Consistency
• Ensure the plan meets its recipients needs
• Helpfulness
• Ensure the solution is appropriate
• Effectiveness

7
Goal Consistency

• As we mentioned in week 6, our audience is
• system designers
• implementation designers themselves
• programmers
• testers

8
Goal Consistency

• As we mentioned in week 6, our audience is
• system designers
• implementation designers themselves
• programmers
• testers

9
Goal Consistency

• As we mentioned in week 6, our audience is
• system designers
• implementation designers themselves
• programmers
• testers

Communication
10
Goal Consistency

• Ensuring implementers have the same plan
• Every design is a plan, to some extent

11
Goal Consistency

• Ensuring implementers have the same plan
• Every design is a plan, to some extent

12
Goal Consistency

• Ensuring implementers have the same plan
• Every design is a plan, to some extent

13
Goal Consistency

• Ensuring implementers have the same plan
• Every design is a plan, to some extent

14
Goal Consistency

• Ensuring implementers have the same plan
• Every design is a plan, to some extent
• Division of Labor
• Separate parts to work on
• Ensuring they work together

15
Goal Consistency

• Ensuring implementers have the same plan
• Every design is a plan, to some extent
• Division of Labor
• Separate parts to work on
• Ensuring they work together
• A common vision (Ideas)
• Will the developers guesses coincide?

16
Goal Consistency
17
Communication isnt enough

• A good representation is important
• What if we just communicate really well?
• Some problems cant be seen along the way
• Implementation design is a birds eye view
• Need a plan that
• Supports the key work
• Will lead to an effective product upon completion

18
Role of the Implementation Design

• As we mentioned in week 6, our audience is
• system designers
• implementation designers themselves
• programmers
• testers

Reflective Conversation with Materials
19
3 Goals of Implementation Design

• Provide a shared plan to follow
• Consistency
• Ensure the plan meets its recipients needs
• Helpfulness
• Ensure the solution is appropriate
• Effectiveness

20
Goals Helpfulness

• In a way, the implementer is our customer!
• What are the implementers needs?

21
The Implementers Needs

• Implementers must
• Create code
• Modify code
• Reuse code

22
The Implementers Needs

• Implementers must
• Create code
• Subtle connections must be adjusted for
• Modify code
• How can you find it? What else will it effect?
• Reuse code
• How can you integrate new code? Reuse this code?
• The difficulty is in the interconnectivity

23
Spaghetti vs. The Ideal Program
vs.

24
Goals High-Quality Implementation

• Reducing interdependency (Low Coupling)
• Proper cooperation easier to maintain
• Changes dont propagate
• Reuse is facilitated
• Grouping functionality (High Cohesion)
• Easier to find things
• Metaphor guides decisions
• Both aid in dividing work

25
Design Notations

• Assuming we have a supportive plan
• How do we present it?
• What representation will we use?
• Class Diagrams
• Interface specifications
• Textual Descriptions
• Sequence Diagrams
• Data Flow Diagrams
• Petri Nets
• any of the notations from system design

26
Design Notations

• Each has its advantages and disadvantages
• Diagrams can
• Help deal with complexity, abstract, give the big
  picture
• Visualize the invisible code objects,
  interactions, timing, etc.
• Text can explain
• Depends on the needs of the system too

27
Goal Helpfulness

• When designing, we must recognize the difficult
  work we are describing
• A design must help implementers keep complexity
  under control
• We must

28
Goal Helpfulness

• When designing, we must recognize the difficult
  work we are describing
• A design must help implementers keep complexity
  under control
• We must
• provide a plan that meets implementers needs
• present the plan in a way that the implementers
  can understand

29
3 Goals of Implementation Design

• Provide a shared plan to follow
• Consistency
• Ensure the plan meets its recipients needs
• Helpfulness
• Ensure the solution is appropriate
• Effectiveness

30
What makes a design effective?

• Quality of Service
• Security
• Reliability
• Scalability
• Portability
• Minimal Hardware Requirements
• Also still maintainability, testability,
  reusability
• Remember your system design!

31
Getting down to Business

• Existing notations may suit your needs
• Created with existing wisdom
• Will be more familiar to your implementers

32
The Class Diagram
33
The Class Diagram

• Again
• Implementers must code, maintain, reuse
• Systems needs

34
The Class Diagram

• Again
• Implementers must code, maintain, reuse
• Systems needs

• But what classes do I need?
• System design provides hints
• Requirements emphasis can set priorities
• What parts are likely to change or be reused?
• Carefully apply information hiding
• Create classes with secrets

35
Context may also guide classes

• Frames which classes to use
• Suggests I/O, interfaces, places for converters

36
Further Existing Wisdom

• Patterns provide insight into common issues
• More next week

37
Data Flow Diagrams

• A more active depiction of the system
• Context
• InternalProcesses

38
Sequence Diagrams

• Can describe usage scenarios
• Might be especially useful in some games
• Logic of services andtransactions
• Can suggest classesand methods

39
Sequence Diagrams Communication
40
Petri Nets

• Maybe communication is very dicey
• A distributed system with concurrent processes
• Petri nets are a notation designed for this
• Not as common, but can be useful

41
User Interface Specification

• Could spend a whole year on it
• May use existing components
• This will guide what is possible
• Needs to be determined early in some cases

42
User Interface Specification
43
User Interface Specification

• Can explain
• UI layout itself, but
• Intended functionality
• User experience
• Simple sequences
• Can imply specificimplementation,given a
  particular API

44
Or something else entirely

• Overhead of learning

45
Summary

• Must create an effective plan for implementers
• And ensure they can readily
• Create code
• Change code
• Reuse code
• Must consider the system designs needs
• A tricky balancing act

46
Implementation Design in Context
Domain of Materials
Representation
Activity
Ideas
concern
manipulates
informs
Goal
captures
enhances
47
Next week

• Specific Domain wisdom about tackling software
  design problems
• Some walkthroughs
• Implementation design drafts due Thusday