Why Do We Need Visual Models ?

Posted at March 30, 2009

modelsOne of the questions that often comes up during a discussion on Model Driven Development is “why do we even need visual models”?  The question varies based on the experience and extent of use of modeling within the target audience – but the essence of the question remains the same.

Modeling is an inherent part of human life — as they say “a picture is worth a thousand words”.  A picture can communicate information better by hiding the complexities and displaying only the relevant details.  For example, when we look for directions we tend use the map representation instead of the textual directions as the map provides us with just enough details to visualize the directions.  Models also have been used in several disciplines including science and engineering for a long time.   CAD/CAM models are used in engineering to model engineering parts and structural models are used in architecture to model large structures and buildings.  Irrespective of the problem domain, models provide a simplified abstraction of the complexity involved in that domain.  While models do not have to be visual, most models are visual and the visual representation further adds to minimization of complexity.  Different models can be used to capture different characteristics of the problem domain and the type of diagrams used to visualize the model of a specific problem domain really depends on the problem domain itself.

Visual models have also been used in software engineering to different extents depending on the context, skills, time and tools available.  Depending on the size of the organization or team working on project and the complexity involved, no modeling step may be involved in certain implementations.  Developers go directly from requirements to coding and no models are produced during the lifecycle of the project.  In other cases, models drawn on white board are used to facilitate discussions around design ideas and modeling stops when the discussion ends.  In most cases, models are used primarily for communication among various groups involved during the early stages of the project – during requirements gathering, analysis and design.  The primary intent of these models is to capture a high level view of the system under consideration and to present a common view to all parties involved.  These models could be technical architectural diagrams, data models, use case models, class diagrams, sequence diagrams, etc., and are drawn using tools such as Powerpoint or Visio or a more formal UML modeling tool.  However, these models are thrown away once the development starts since it is hard to keep the code and models in sync as the requirements change during the remaining life cycle of the project.

Today’s systems are complex with many moving parts (thanks to modern multi-tier and distributed architectures) — models enable us to cope with this complexity by providing a visual abstraction layer that focuses on the higher level concepts in the problem domain and de-couple the “what” from “how”.  For instance, imagine trying to understand the dependencies in a large system by looking at the code vs. looking at visual design models (use case models, component diagrams, class diagrams and activity diagrams, etc.).  Depending on the level of detail desired, the needs of the target stake holder and the choice of architectural framework (TOGAF, Zachman, etc.), multiple views or perspectives of the entire enterprise architecture can be captured in various models including use cases, system architecture, data flows, object models, business processes, physical network, deployment nodes, system dependencies and database schemas, etc.

In summary, visual models provide us with the following important benefits:

As I mentioned earlier, in most traditional code-based development approaches, these models are merely used as design artifacts that provide a starting point for an extensive coding exercise where the higher level details captured in these models are translated into lower level details based on the target architecture.  What if the models we created are semantically 100% complete and are immediately executable instead of merely being design artifacts?  This is the promise of Model Driven Development and more on “Executable Models” later.

Enhanced by Zemanta
Modeling, Technical

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

  • Nice post. I like to see that we agree on the benefits (http://modeling-languages.com/content/benefits-...). Let me just make a quick comment on your last sentence: "What if the models we created are semantically 100% complete and are immediately executable instead of merely being design artifacts?" In principle that would be great: full code-generation from software models that would avoid (almost completely) the need to program the software. However, we need to be careful with this. What's the cost of defining a 100% complete with all the details for a complete code-generation of the software? Maybe this is even more time-consuming than directly programming part of the software. For me the more difficult task is to decide what it is the "right ammount of modeling" to maximize the benefits of modeling without having big trade-offs.
  • ashoknare
    Jordi,

    Thanks for the comments.

    We do seem to agree on most of the benefits of modeling. When I talked about creating 100% semantically complete models, I was talking about executable UML models -- not code generation. It is possible to create models that are immediately executable and I have been using this approach for the past few years to develop business applications. You can see references to some examples in the previous comments.

    However, as you pointed out, picking the right amount of and types of models is important. Key is to use just enough models to impart executable semantics to the target domain. For example, in the platform I worked with used only class diagrams (to capture business objects) and activity diagrams (to capture business processes) to create a fully functioning application from the models.

    Ashok
  • claude marchal
    It is impossible to satisfy in the SAMe model both end-user needs for validation and developer's needs for verification/code delivery
    BUT
    I agree it is possible in UML to have an incremental approach where a fist model is created and maintained for validation and transformed/extended to another with more detailed for validation purpose; And this is the right way to go.
    From another hand, it is the same story between visual and textual formal modeling; the last one can be produced/extended from the first one. And this way is still better because drawing is more time consumming than editing but visual is better for communication/validation purpose.
  • Model Driven Development doesn't mean you are suppose to use only "visual" models. You still have some parts of you application that are much better to be captured as text (I think some business rules or OCL-like invariants). The idea is to have multiple DSL (Domain Specific Languages) for different aspects of your application and provide textual model editor or graphical (visual) model editor or even both, whatever is the best for the user/consumer of DSL.
    Also, there are other good reasons to use textual modeling: small footprint, light editors, better source control management and textual merging (sometimes graphical merging is quite difficult). For example, you can create Eclipse EMF models using a visual editor (UML/Rational Rose/Eclipse .ecore editor) or textual editor ( Plain Java or KM3).
    In the end, what is important in Model Driven Development is to have model as first class citizen, not how your create the models.
  • Ioan,

    Thanks for the comments !

    I agree -- MDD does not necessarily imply visual models. Models can be visual or text based -- in fact, I pointed that out early in my post -- and I happen to focus on exploring MDD via visual models. However, most visual models also provide the facilities to capture textual constructs such as business rules, as part of the visual model. This is the case especially with "executable" models where capturing the rules with the model becomes essential for the execution of the models.

    There has been quite a bit of discussion on the differences and merits of MDD using DSLs Vs Executable Models already -- I suppose that's a topic for another blog post :-)

    Ashok
  • Ashok and Lucas,
    I found this blog through a LinkedIn EA group post.

    You may be interested in my recent blog post on the major variations between modeling languages:
    http://metimea.ca/2009/04/05/modeling-languages/

    It's usually unrealistic to use the same models for communicating with business people, and specifying implementations/executions. Normally architects/ designers need at least two translations: from business/conceptual to logical/system to physical.

    UML has many notations; some are more for business, some are more technical, but all can be judiciously simplified and adapted to a purpose.
  • Alana,

    Thanks for the comments.

    Depending on the context of modeling, some models have more of a business context than others. UML does have diagrams to span th entire process and provides diagrams to server a specific context. Business maturity models, use case models, high level business process diagrams, and high level sequence diagrams are excellent for communication with stake holders and domain experts -- these models generally do not contain any execution semantics to contribute to run time. In this case, the models are used exclusively for system analysis and communication.

    However, once we start going through analysis and high level design to produce domain object models, detailed process diagrams, etc., it is possible to use the same diagrams for both business communication and execution. In tradition development approaches, I can imagine the necessity for models to be transitioned from concept to system to physical levels to match the needs of the corresponding user & phase. In the case of executable models, enough run time semantics can be captured in the same models using technology independent action languages (not OCL) to make the models immediately executable thus eliminating the needs for the transition. For example, all the business rules related to domain objects can be captured as part of the objects and all the business logic required to execute a business process can be captured in each of the activities -- using action languages. Using meta data, different aspects of the model can be captured and the model, if required, can even be presented to different users differently -- although in most cases, this is not required.

    As the models themselves are executable, in a way the transition happens -- but it is automated and happens either in design time (as in PIM to PSM transformation in MDA) or run time (as in Executable UML).

    We have been using this approach at Intelliun for the past few years with great success. Please check the following URL for some demos:

    http://www.intelliun.com/Developers/OnlineDemon...

    Ashok
  • I find it extremely difficult to create models that are both useful for humans to communicate and understand processes (or systems, or organizations, etc...) and capable of being executed. You can always try to separate the details and formalism needed for a model to be executable, and clearly state traceability between them.

    It is very usual to see models that have too much detail for workers to be able to consult and understand them. Based on this, I am working on SOMoF (a set of procedure documentation techniques and tools that allows organizations (enterprises, divisions, departments, etc...) to describe their operations in a simple way):

    http://nevant.metocube.com/mc/element/view-web/...
  • Lucas,

    Interesting tool and approach. I agree -- it is very usual to see models with too much detail to an extent they are unusable. UML itself is loaded with diagrams that introduce unnecessary complexity when it comes to creating executable models.

    However, I do think it is possible to create diagrams that are useful to humans (from a documentation perspective) and are executable at the same time -- key is to capture enough and just enough semantics in the models to serve both purposes (keep it simple). Executable models are a reality and we have proved that Intelliun many times on customer engagements. We try to keep the models simple (Class diagrams for capturing business objects and activity diagrams for capturing business processes) and these models are 100% semantically complete and are immediately executable as soon as they are created. It is possible to capture the documentation details needed for human consumption and the formalism needed to the make the models executable in the same model using meta data.

    Ashok
blog comments powered by Disqus