Lecture 7-1

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?


  • 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


  • 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


  • 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 generally take a bottom-up pass

  • Module interfaces are just interfaces

  • Modules are a way of doing data hiding


  • 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

Last modified: Sunday, 8 November 2015, 11:54 PM