Jaa

Model-Driven Approaches

  • Artikkeli

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

Comments

  • Anonymous
    August 01, 2008
    Well structured, nice post. Modelling always has the advantage that you can play with your ideas on a simplified playground.

  • Anonymous
    August 02, 2008
    Thanks. > you can play with your ideas on a simplified playground Exactly!  

  • Anonymous
    August 15, 2008
    I think there are two places where CASE-type model<->code conversion works well and they both share the property that only the surface of the model--the part that defines how the modeled process and objects--is retained in the conversion. One is automated ER diagramming tools that allow good visual models that work for learning, sharing, and designing to be converted into creation and updating code. This was one of the earliest CASE successes and is still a major win in data modeling. The other is automated interface extraction tools that take sequence-type diagrams and identify exposed interfaces for your objects. It allows for clear common closure on interfaces, it can be reversed from a call tree (with moderate success), and it's far, far more successful than automatic conversion of full entity models to code objects. Given that ER database conversion is pretty early in the CASE history and that sequence and interface (whether from modern sequence diagrams, mid-90s DFDs, or whathaveyou) are from early BPR, we're seeing that some of the older (10-15 year) modeling tools are finally mature enough to be useful. Although, to be fair, ER/win has been great since approximately the dawn of time. I make teams I work with remove any automated model coupling that generates code and put warning on generated models. I have never seen either be reliable enough. Even with ER/win or a sequence diagram->interface tool I want a complex neural net trained to analyze code to verify the results.

  • Anonymous
    August 15, 2008
    Hey xowl > remove any automated model coupling that generates code > I want a complex neural net trained to analyze code to verify the results Good points!