To model or not to model – that is the WRONG Question

The discussion about whether modeling is good or bad does is not really appropriate. We all and always create a mental model of the system before coding it. As Olivé says in [1], the model always exists, the only option designers have is about its form: it may be mental (exists only in the designers’ heads) or explicit.

Therefore, the real discussion is whether the effort of making the models explicit is worth or not. Let me try to justify why I think this difference is important.

After this distinction, I think I can convince you that all arguments against modeling are not against modeling per se but against modeling using the current modeling languages and CASE modeling tools . That is, in my opinion, the problem is not modeling, the problem is the limitations of the tools we are forced to use when modeling!.

In fact, I strongly believe that a new generation of CASE tools that:

  • Simplify the drawing of the models (e.g. allowing free-hand drawing of the models on a TabletPC, promoting simpler versions of the modeling notation for certain types of users and uses, allowing to combine or drag-and-drop elements from different types of diagrams when defining the models and so forth)
  • Offer interesting model-based services (e.g. quality checks in a reasonable amount of time, model version control for distributed teams, code-generation services,…)

could end the “Modeling War” since then, clearly, the time invested in making the models explicit (now less) would pay off thanks to benefits of the model-based services.

I don’t think having one of  these tools is science fiction at all. Most of  these aspects have already been published as  prototypes or research papers. We “just” need to combine them in a single tool. Maybe it is  just me, but I would be very excited if I had a tool that could let me use my TabletPC TO sketch a class diagram, get an immediate feedback that the model is OK and automatically generate the DDL script for my preferred DBMS. Don’’t you agree? If you had that tool (or, even better, picture the tool of your dreams), wouldn’t you start thinking that maybe modeling (better said: explicit modeling)  is not such a bad idea?

[1] Antoni Olivé: ON the Role OF Conceptual Schemas IN Information Systems Development. ADA-Europe 2004: 16-34

If you enjoyed this post you can subscribe to this Software Modeling blog , to the portal’s mailing list , follow me on twitter and/or participate in the forums . And if you really liked it help me pass it on to others by sharing the post using the links below. Don’t forget to check our consulting , advertising and code-generation services either!

5 Responses to To model or not to model – that is the WRONG Question

  1. Anonymous says:

    …you’re saying that modeling IS good, it’s just all realizations of it up until this point in time that have been flawed. It sounds like the arguments my Marxist friends made about Communism in the 1990s… :-)

  2. Anonymous says:

    Yes, we create models of the system in our heads before coding it, but these models are (a) partial, (b) informal, (c) high-level, and (d) often inconsistent. Except perhaps for (d), that’s how it should be.

    The effort needed making our mental models explicit IS the effort needed making them complete, formal, low-LEVEL, AND consistent. It IS a similar effort TO that OF actually coding the software, AND we should ONLY need TO do it once.

    Many people do use models informally now AND THEN, AS needed, AND that’s fine –it’s the push TO institute models AS a formal step IN a process, OR AS a necessary phase before generating code, that troubles me AND others.

    ~Jorge Aranda

  3. Anonymous says:

    From my point of view, the key issue is that those mental (implicit) models that people have when programming are very fuzzy. Explicit modeling enforce software developers to think early (and hard) about the problem they are facing… and that’s so tired… Moreover, clients usually do NOT have clear what they want, so, why expending TIME IN something boring, hard AND that we ARE sure that will change? It’s easier to start with a not much clear (mental) view of the system, doing some repetitive and comfortable coding tasks, and then solving concrete problems while they arise, altough that approach implies wasting lots of time re-implementing functionality. But, you know, coding is the “real” work… so the more you code the better worker you are.

    Of course, current tools do not help too much to change this way of thinking, since the modeling effort is not exploited in other development phases (coding, testing, etc.). Silver-bullet modeling languages are also tainting modeling approaches, since they hardly can fit smoothly with any domain problem (when you are trying to describe the problem, and not the computer-based solution).

    Fortunately, technology evolves fast and now is affordable building fancy modeling languages (and tools, of course) well suited for specific domains. Anyway, there’s still a lot OF WORK TO be carried out TO widely obtain ALL the benefits that modeling approaches can provide, AS you highlight IN the blog entry.

    Javier Muñoz

  4. Anonymous says:

    I agree WITH the article about the difference BETWEEN implicit AND explicit models.

    An implicit model helps just the person who has it IN mind. It IS about knowledge hiding. But models ARE there FOR documentation (FOR others) AND communication. An implicit model can NOT be used FOR this purpose.
    An explicit model makes thoughts transparent.

    Although it might be great TO have an easy modeling tool (especially FOR beginners) this will lead TO less exact results. Sketches might be good FOR a FIRST discussion, they ARE NOT rich enough AND exact enough FOR a definition what exact IS TO do.

    Especially companies who use models IN a stringent process FROM analysis TO testing, means the whole SDLC, exact models ARE essential.

    In my opinion CURRENT modeling tools ARE pretty good. Although MORE integration IN one OR another way would NOT be bad. If I just need TO sketch something I use a flip chart.

    The basis IS the notation. Once people understand the basics OF the notation the tool IS a secondary issue.

  5. jordi says:

    (story originally posted by John F. Miller as a reply to this stackoverflow question ):

    There is a story told that Walt Disney never used story boards. He would simply tell the story and then work work with the animators to make it happen. When Mr. Disney passed away the team tried to continue this approach since it had been so effective, but found that they could not makes things work without the storyboards. They reached the conclusion that they had always had storyboards, but that previously they had been embodied in Walt Disney himself.

    Even if I have no idea whether this story is real or not, it is perfect to illustrate the fact that we always use mental models of what we pretend to create. Whether it is worth to make this mental models explicit (and to which degree) depends on the circunstances of the project/team/…. In this case, once Walt Disney was gone and (I guess) the storyboards had to be created following a more collaborative approach, they were forced to make the models explicit so they could share and discuss them.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress
More in modeling
UML tools – Textual notations to define UML models
Role of modeling in a Micro-ISV
Future developments of the UML (a UML 3.0? no, please)