Model-Driven Approaches

Note: This article is updated at Model-Driven Approaches.

When people ask me my take on model-driven approaches, I think of two ends of the spectrum -- human and the machine.

Key Points

  • Model for humans.  For humans, I find using a whiteboard (whiteboard modeling) works well -- it's universal.
  • Model for machines.  For machines, I find speaking closer to the code is a good thing and design is rarely a clean model.
  • Model to learn.  I've found modeling more useful when you throw it away -- it's a learning tool.  Model so you get it, then go to it.  I think the key is that the model is a map, not the actual territory.  The usefulness of a map is actually decoupling from the complexity and creating a simpler lens.
  • Model to share.  I think the real value of models is when you create a way to share the problem or solution in a simplified way.  This helps for sharing a vision of the end in mind, as well as getting more sustained thinking around the problem.

Model-Driven Code
I've never experienced an effective modeling approach that turns visuals of systems into code, where the model doesn't get in the way.  At some point, the model stops being useful for humans or stops being useful to the machine.  As a result, I've never really been a fan of model-driven approaches that are coupled to code in practice, although they're always interesting in theory.   While I'm open to the idea, I just haven't seen it.  Am I missing out?

Effective Modeling for Shaping Software
While I'm not a fan of most visual modeling tools, there’s some very real modeling approaches I find to be effective (which is more about modeling for the humans to understand what matters.)  I find that light-weight, human-oriented models are particularly effective for shaping software around quality attributes.  For example:

My Related Posts