Connections: Mental Models and Micro-Architectures

From the previous sections it would seem that our discussions were neatly compartmentalized. This was not so at all. In fact, it was pointed out by one of the participants when he congratulated the working group report writers on "describing an indescribable working group". The main point here is that throughout our micro-architecture discussions, we were constantly thinking about and attempting to represent mental models of concepts (sort), implementations (heapsort), architectures (the event driven model), and system development paradigms (e.g., OO functional, Open systems, and generative paradigms). On the flip-side, whenever we focused on how we thought about and constructed mental models, we were typically dragged back into the domain of micro-architecture issues and design decisions.

As this tug of war became apparent to everyone, we developed the following agenda to better focus our discussions:

1. Examine more details about the tradeoff between generalizing a component as much as possible (design for reuse concerns) versus emphasizing the usability of a component (design with reuse concerns).
2. Consider the programming language issues raised.
3. Flesh out the Sorting_Machine example, both from the client perspective (what the specification looks like) and from the implementer perspective (what the implementation looks like).
4. Catalog our rules of thumb for generalizing components, which we variously called parameterizing, functorizing, and customizing.
5. Discuss the issues and examples in this agenda both from the perspective of how we think about them (good mental models), how we represent them (micro-architecture issues), and how we transition between these two sides of the same coin.
6. Examine in more detail the forces that lead to particular micro-architectural design decisions (composability, ...).

The concensus was that our subsequent approach would be to explore forcing leading to micro-architecture design designs (6) by working through examples (3), subsequently delivering rules of thumb for generalizing components (5).