Software Architecture and Detailed Design

CS 300 Lecture 7-1
Bart Massey



Intro To Design

• How are we gonna build the thing?

• Two phases:

  • Architecture: What is the overall shape of the thing?
  • Detailed Design: What does a blueprint for the thing look like?

• Today, Architecture

  

Architectural and Detailed Design

• Architecture: overall block diagram of what you are building

  • Is it a pipeline? client-server? plugin architecture? file processor? database-driven? gui?
  • What sorts of constraints does the design impose?
  • How well does the architecture fit the requirements?
  • All else being equal, simpler is better

• Detailed Design: Module decomposition of what you are building

  • Usually all the way down to "units" (procedures, functions, methods)
  • Rule of 7 ± 2
  • Bottom-up vs top-down

  • All else being equal, simpler is better

    

How To Architecture

• Figure out what the simplest thing is that could solve your problem

• Relevant questions:

  • What kind of state does your system need?
  • What kinds of inputs and outputs does it have?
  • What kind of control need to be maintained?

• Environment matters:

  • What languages and tools will you leverage?

  • What kind of computing resources do you need and where will they come from?

    

Traceability

• It is hard to trace architecture to the SRS, but worth trying

  • Good way to spot architecture problems
  • Good way to spot requirements problems
  • Good way to simplify the architecture

• Will also trace to detailed design (easy) and would be nice to transit that tracing to know what elements of the pseudocode match elements of the SRS

  

State

• Every software can be thought of as a bunch of state manipulation

• An architecture defines an overall view of where the state will live

• Structures like pipelines or databases or OO components are all about putting the state in places where it is useful and manageable

  

Design Patterns

• Idea from a book on actual architecture: A Pattern Language by Christopher Alexander et. al. (http://www.amazon.com/dp/0195019199)

• Nonetheless, mostly used at intermediate or detailed design level in SE

• Most used by OO people at this point

• Prof. Antoy teaches our course

  

Example Architecture: The Pipeline

• Data flows in, through a series of transformations, out

• Often parallelized: gives good throughput, not-so-good latency

• Only works when data flows one way, so not for e.g. interactive systems

  

Example Architecture: Event-Stream Callbacks

• Architecture for concurrent systems

  • Callbacks are set up to handle incoming events (spontaneous data sent by remote) and responses
  • Requests are sent to a (usually remote) module by the callbacks
  • The main loop sits reading events and responses and caling the appropriate callbacks

• Essentially a coroutining thing

• Callbacks are evil

• This is how most X stuff works

  

Get Experienced Help

• Architecture botches are prevalent and terrible

  • Hard to notice: bad architectures still kind of work
  • Can really make systems harder to build and validate

• Experienced architects are "special"

• Experienced architects love to architect

  

Detailed Design

• Guiding principles:

  • Coupling and Coherence
  • Rule of 7 ± 2
  • Rule of idiom

• Functionality / correctness is job 1

• Algorithm selection

• Traceability to architecture and code

  

Pseudocode

• Not necessarily every unit, but any that have anything interesting.

• Rules of Pseudocode:

  • Should be translatable to code about as fast as you can type
  • Shouldn't be code
  • English to make things clearer
  • Easy details omitted

  • 1-5 LOC per line

    

Principles Of Routines

• Routines come from design

  • Not too little functionality
  • Not too much functionality

• Routine interfaces should be narrow and understandable

• Routines come with preconditions and postconditions

• Routines should be coherent

• Invariants should strengthen down the page

  • Handle corner cases first, then general case

• Control flow should be as simple as possible

  

Modules

• Modules generally take a bottom-up pass

• Module interfaces are just interfaces

• Modules are a way of doing data hiding

  

ADTs

• Capture the abstract notion of values and operations

• Really useful design technique

  • With the right ADTs in place architecture is usually easy

• "Berkeley Abstraction" and other pitfalls

  

OO Design

• Gives some of the things any good design will have

  • Modularity via classes
  • Control flow via patterns

  • ADTs

    

The "Whitepaper Method"

• Write the design document as an informal description of system architecture

• Elaborate important modules and routines to pseudocode

• Include necessary context

• Great way to produce strong software quickly

• Documentation bonus