Improving Design

1
Improving Design

• 1 Reduce complexity
• - narrow-down the project scope
• - optimize underlying process
• - eliminate unneeded parts
• 2 Find and eliminate redundancies

2
Design by Contract

• In principle a detailed technical spec should
  contain a precise description of what the inputs
  and outputs of the system should be, hence the
  spec can be viewed a as contract specifying what
  the system should do.

3
Contract Approach

1. Supplier
2. Client
3. Preconditions (requirements)
4. Post-conditions (guarantees)
5. Consistency constraints (safetry checks)

4
Dictionary Example

1. Supplier provides source data to be inserted
   into dictionary
2. Client inserts data into the dictionary
3. Preconditions the client requires source data to
   be available for reading the supplier requires
   the dictionary not to be full.
4. Post-conditions the client ensures that the
   dictionary is not full the supplier ensures that
   there is source data.
5. Consistency constraints source data dictionary
   size const.

5
Fault Trees

• Display logical path from effect to cause.
• Think of what can go wrong
• Trace how events unfold and build a graph whose
  nodes are failures
• Graph edges represent related components labeled
  by logical relationships (AND/OR).
• Once the graph is constructed we can improve
  design by searching for
• single points of failure
• Undefined or ambiguous behavior

6
Fault Tree Example
7
Comparing Designs

• Criteria for comparison
• Implementation cost
• Ease of algorithms change
• Ease of data structure changes
• Ease of functionality expansion
• Performance
• Reusability
• Maintainability

8
Design Review

1. Preliminary review of conceptual design uncovers
   design traits that are unacceptable to customer
2. Critical review of technical design
   cross-examination of the design by developers,
   testers, hardware network administrators,
   analysts, and customer reps uncovers design
   deficiencies.

9
Questions to Ask

1. Does the design solve the problem?
2. Does design address all the requirements?
3. Is the design easy to understand?
4. Can the design be improved / simplified /
   optimized?
5. Does the design allow for feature expansion?
6. Is the design compatible with available (target)
   hardware?
7. Is the design compatible with available
   (interfacing) software?
8. What upgrade path does the design support?
9. What maintenance issues arise from the design?

10
Refactoring

• Bad design requires extensive refactoring, i.e.
  patching to accommodate unforeseen or neglected
  issues.
• As a result the system may fail and require
  redesign due
• to inadequacy of the original design
• gradual degradation of design due to refactoring

11
Bad Design Traits

• Also caused by refactoring
• Reduced performance
• Loss of clarity / elegance
• Increased complexity
• Increased development time (deadline risks)
• Increased maintenance costs (both passive and
  active)
• Increased bug introduction probability
• Reduced faith in the system

12
Why We Need Open Source

• Proven fact 1 peer review increases software
  quality.
• Proven fact 2 we need source code to fix bugs
  that weve discovered.
• Proven fact 3 we need source code to figure out
  poorly documented features and side-effects.

13
Commercialization Issues

• Potentially cheaper software (thanks to unpaid
  development)
• Potentially higher code quality (thanks to peer
  review)
• Potentially surviving software (not linked to
  vendor fortunes)
• Potentially a disaster?(no support
  accountability)

14
Commercialization Paradigm

• You cant sell open-source software, but you can
  make money on it anyway!
• How?
• Assume responsibility / accountability and sell
  support (as well as assurance)!

15
Commercialization Downside

• Intellectual property (IP) transfers into public
  domain.
• Good bye to trade secrets.
• Forget your software patents.
• One has to strike a balance between open and
  closed source.