Kipling & Software Architecture

My previous post attempted to show that Kipling's wise men had good advice for project managers.

Of the six wise men, five have good advice for the design of software architecture.

1. What. The functionality expected of the application.
2. Why. The problem that delivery of the functionality will solve; the advantage/improvement that it will deliver.
3. How. The broad, coarse-grained steps that need to be executed to deliver the functionality. This is the high-level algorithm; the high-level flow-charts (both control and data).
4. Where. 
1. The blocks of  the flow-chart is where the action takes place.
2. Step-wise refinement of the flow-chart leads to more precisely defined blocks with progressively narrow responsibility. This is recursive application of steps #1 thru #3.
3. The connection between the blocks are directed edges. It denotes that the block at the tail of the edge accesses the block at its head. The interface for this access must be defined (the .h files). The data that is transferred in either direction must be defined. 
4. This is the step that leads to modules/sub-modules (the .c files).
5. Refinement should be guided by the principles of:
1. Minimization of inter-module coupling. Changes in a module that do not affect the interface, should not effect other modules. 
2. Maximization of intra-module cohesiveness. 
1. Data required by functions in the module should either be passed in as parameters, or be present as data items in the module, or obtained by calls to collaborating modules.
2. Functions in the module should all be related to the purpose of  the module.
5. When. The sequence-diagrams.

Comment

Deciding the "Where" is what architecture is about. Deciding that, has to be based on broad principles. Like all design it involves finding a compromise subject to conflicting forces. That requires a clear understanding of values.