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:

  • Minimize complexity by capturing complex moving parts in multiple views, enable clear overall view of interactions
  • Enable effective communication among stake holders, business analysts, enterprise architects and software developers by providing a common view, language and notation
  • Facilitate collaboration via model sharing, transition and refinement between domain experts (business modeling), architects (system modeling) and software developers (analysis, design and implementation)
  • Increase developer productivity and shorten the development life cycle by providing ways to generate executables from models either at design time (code generation) or run time (executable models).

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
(Visited 638 times, 1 visits today)