Software Architecture and Detailed Design
CS 300 Lecture 7-1
Intro To Design
How are we gonna build the thing?
- Architecture: What is the overall shape of the thing?
- Detailed Design: What does a blueprint for the thing look like?
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
- 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?
- 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
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
- Coupling and Coherence
- Rule of 7 ± 2
- Rule of idiom
Functionality / correctness is job 1
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
Gives some of the things any good design will have
- Modularity via classes
- Control flow via patterns
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