CSCE 315 Lecture 9

« previous | Monday, February 8, 2012 | next »

Software Design Process

(Chapter 5)

Challenges in Design

• A problem that can only be defined by solving it
  • Only after solving it do you understand what the needs actually are.
  • "Plan to throw one away" ???
• Sloppy process
  • Mistakes
  • Dead-end paths (Git branching is good for this)
  • Stop when "good enough"
• Tradeoffs and prioritiez
  • Performance vs. Robustness
  • Determine whether design is good
  • Priorities can change
• Restrictions are Necessary
  • More Constraints will improve the result
  • The more open-ended, the harder it is to write good code
• Nondeterministic process
  • Not one "right" solution
• Heuristic process
  • Rules of thumb (not a fixed process)
• Emergent
  • Evolve and improve during design and coding

Levels of design

• System as a whole
• Division into subsystems
• Classes within packages
• Data and routines within classes
• Internal routine design

Work at one level can affect those below and above.

Design can be iterated at each level.

Key design concepts

Manage Complexity!!

• Software already involves conceptual hierarchies and abstraction; leverage these to abstract away thinking about details
• Goal: minimize how much of a program you have to think about at once
• Completely understand the impact of changing code

Good Design Characteristics

• Minimal complexity: favor "simple" over "clever" (clever might be better in some instances"
• Ease of maintenance: write to people in the future; code should be self-explanatory
• Loose coupling: Abstraction, encapsulation, information hiding;
  • Keep connections between parts of programs minimized
• Extensibility: System should be able to be modified without affecting the rest of the project
• Reusability: Design so code could be "lifted" into another system
• High Fan-in:
• Low-to-medium fan-out:
• Portability: Consider how the program will react when moved to another environment
• Leanness: Don't add extra code; that code must be tested and reviewed in future changes
• Stratification: Keeping things in layers; don't worry about things in other layers
• Standard Techniques Use stuff that's been done before.

Design Heuristics

• Rules-of-thumb
  • Trials in "Trial and Error"
  • keep in mind that there are always exceptions
• Understand the Problem
• Devise a plane
• Carry out the plan
• Look back and iterate

Find Real-World Objects

Tie abstract ideas and objects to something in the real world

TANGENT A guy at boeing tries to talk about design before anything is sketched since as soon as something is drawn, everything else is "anchored" to that idea. Avoiding concrete anchors can be a bad idea.

• Standard object-oriented approach
• Identify objects and their attributes
• Determine what can be done to each object
• Determine what each object is allowed to do to other objects
• Determine the parts of each object that will be visible to other objects
• Define each objects public interface.

Form Consistent Abstractions

View concepts in the aggregate

• Car rather than "engine", "body", "wheels", etc

Identify common attributes

• Form base classes

Focus on interface rather than implementation

Form abstractions at all levels

• Car, engine, piston...

Inheritance

• Inherit when helpful
  • when there are common features
  • can be easily misused

Information Hiding

• Interface should reveal little about inner workings
  • EX: assign ID numbers. Algorithms could be hidden; use a Memento to hide actual ID number;

• Easier to comprehend complexity
• Localized effects allow local changes

Issues:

• Circular dependencies: A depends on B, which depends on A
• Global Data (or too-large classes)
• Performance penalties