I’m always looking for nice little mnemonics to help out remember the important concepts in design. Here’s one for model-driven development I call the “Seven C’s”. It basically enumerates the seven stages a design goes through, from initial idea to code.
The Concept phase is about understanding the problem. In other words: requirements analysis. When you’re in Concept mode your main focus is on validation – am I solving the right problem for my customer?
In Creation mode you are synthesising a solution. At this stage we are building an Ideal model, ignoring many of the complications of the real world. Our design should be completely concurrent (every object has its own thread of control), completely asynchronous (messaging) and completely flat (no hierarchy)
Your focus should be on:
- Design verification – if I can’t demonstrate an ideal design works then there’s no way a less-than-ideal design will work!
- Design evaluation – as with all design: is this the best compromise?
Also known as ‘design levelling’ (but that doesn’t start with C!). Your Ideal model probably has some high-level elements (components, etc) that need further refinement; and plenty of low-level elements (objects) that can be collected together to perform ‘emergent’ behaviours. Design levelling is the act of (re)organising the design into appropriate levels of abstraction – sub-systems, components, objects, etc.
Our Ideal model treats every element as concurrent, but experience tells us that isn’t practical for a real software system, so reduce the number of concurrent elements in our system to get the most effective solution with the smallest number of threads.
Like any other construction project our plans must contain enough information so that skilled implementers can build our dream. In our case the construction plans are our class diagrams, composite structures, state machines and algorithm descriptions.
Once in the construction stage our focus is on verification – doesn’t this design still fulfil its requirements?
Our construction models may be complete and may be translatable directly to code. However, the result of that translation may not be ideal; and may not benefit from many of the features of our chosen implementation language. Corruption is the act of modifying our design to make the most effective use of our implementation language and platform.
The end result.
How does this all map onto typical model-driven-design nomenclature? Well, pretty much like this:
Computationally-Independent Model (CIM)
Platform-Independent Model (PIM)
Platform-Specific Model (PSM)
* Apologies to all the grammar fanatics out there for my use of the “grocer’s apostrophe”