Identifying a Viable Strategy
A viable architectural strategy can be developed using:
- Abstraction
- Modularity
- Inspiration where creativity is needed.
- Predictable techniques where established solutions are available.
- Experience from the architect or other engineers.
Basic Design Tools
Abstraction
Abstraction involves focusing on concepts rather than unnecessary implementation details.
There are two directions of abstraction:
- Abstract up
Start with details and identify higher-level concepts. - Move down
Start with concepts and add detailed substructure.
Separation of Concerns
Separation of concerns divides a problem into hopefully independent parts.
It can involve:
- Functional concerns such as features, behaviors, or areas of interest.
- Technical concerns such as layered design.
Complete independence between concerns may not always be possible, so tradeoffs may be required.
A key software architecture example is separating:
- Components computation
- Connectors communication
Modularity
Modularity divides a system into functional units that can be composed into a larger application.
A module represents a set of related concerns.
Simple Machines
A simple machine can provide an initial abstraction of a potential system that performs a required task.
Simple machines provide a plausible first conception of how an application might be built.
Different application domains have different common simple machines.
| Domain | Simple Machines |
|---|---|
| Graphics | Pixel arrays, transformation matrices, widgets, abstract depiction graphs |
| Word processing | Structured documents, layouts |
| Process control | Finite state machines |
| Income Tax Software | Hypertext, spreadsheets, form templates |
| Web pages | Hypertext, composite documents |
| Scientific computing | Matrices, mathematical functions |
| Banking | Spreadsheets, databases, transactions |
Level and Terms of Discourse
Using abstraction requires choosing:
- A level of discourse
- The terms of discourse
Three alternatives are possible:
Alternative 1
Start at the level of the application as a whole and refine it step by step.
Alternative 2
Start below the level of the whole application.
Individual sub-problems are solved and then composed into an overall solution.
Alternative 3
Start above the level of the desired application.
For example, a general parser can be used to handle application input.
Refined Experience
Experience should be reflected upon and refined.
Lessons can come from:
- Successful projects
- Failed projects
- Other engineers’ experiences
- Literature
- Conferences
Refined experience can provide an initial set of alternative arrangements for the overall design.
