Contrary to what the computer aided system engineering (CASE) proponents may tell you, there is a wide range of modeling approaches which you can take on a software development project, some of which involves software-based modeling tools but other which involve simpler tools such as paper or whiteboards.  Agile modelers use the simplest tools for the job, and sometimes that's a whiteboard, sometimes that's a unit regression testing tool, and sometimes that's a complex modeling tool.  This article, overviewed in Figure 1, compares the various approaches to modeling, mapping the four common modeling paradigms (MDA, Software Factories, AMDD, and Agile MDA) to these approaches, and estimates the rate of adoption for each modeling approach.

Figure 1. Comparing the various approaches to modeling.

 

Throughout this article I use the term CASE (computer aided system/software engineering) tool to indicate software-based modeling tools.  CASE as a term has gone out of favor in recent years because the CASE tool vendors have realized that the term has far too many negative connotations for those of us who were around for the integrated CASE (I-CASE) debacle of the late 1980s.  Many vendors prefer the term "modeling tool" over the term CASE because it doesn't have the negative connotation and because it has the side effect that many developers have been brainwashed to think that in order to "officially model" you need a software-based modeling tool.  The fact, as I will show in this article, is that the vast majority of developers do in fact model but that they use simple/inclusive tools such as whiteboards and paper to do so.

Modeling Approaches

Figure 1 compares the following approaches to modeling software-based systems:

1. No modeling.  Basically, you're not doing any of the other things in this list.  A serious problem in the IT industry is that too many people think that just because they aren't using a CASE tool that they're not modeling. 
2. Discussion.  When you are discussing a problem, either in the problem domain or the solution domain, you're effectively modeling it in your head as you talk about it.  The important thing is that you are thinking the issue through before you code the solution, therefore you're still modeling albeit in a very low fidelity manner.
3. Sketching/Paper.  I believe that the vast majority of visual modeling is done by hand using simple/inclusive tools such as whiteboards or paper (see Figure 1 for some survey findings).  Furthermore, I also believe that the real thinking is often done in such modeling sessions, and that drawing and CASE tools are simply used for documentation and detailing purposes.  The sketching approach to modeling should be taken just as seriously as the blueprint form of modeling, yet it always seems to get short shrift in the literature (it's fairly hard to find modeling books with hand-drawn sketches in them, even though the authors are usually willing to admit that they do a lot of sketching in their modeling practices).
4. Test Driven Design (TDD).  With a TDD approach you create a test then write enough production code to fulfill that test.  In other words, the tests form your detailed design model (as executable specifications), arguably making TDD a modeling approach.
5. Drawing Tools.  Many people use drawing tools such as Visio, or perhaps even PowerPoint, to draw technical diagrams.  For the most part these tools are used to draw pretty pictures, which can be important, for documentation and/or presentation purposes.
6. Documentation CASE.  CASE tools that can only be used for documentation purposes.  These tools are often called front end CASE, logical CASE, platform independent CASE, or enterprise CASE.  Although you can draw and capture information with documentation CASE tools, you cannot generate working software (or source code from which you could then create working software) from them.
7. Generative CASE.  CASE tools that are "close to the metal" and can both engineer and reverse engineer source code and/or working software. 
8. Integrated CASE.  Simply put: documentation CASE + generative CASE. 

The DDJ 2008 Modeling and Documentation survey explored how people approach modeling and documentation.  Figure 2 summarizes the results of the question that looked into the primary approach to modeling, and regardless of development paradigm sketching was the most common approach to modeling (SBMT = Software Based Modeling Tool).

Figure 2. Primary approaches to modeling.

Modeling Paradigms

The right hand side of Figure 1 presents the following modeling paradigms:

1. Model Driven Architecture (MDA). The MDA is based on the idea that a system or component can be modeled via two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs).  PIMs are further divided into Computation Independent Business Models (CIBMs) and Platform Independent Component Models (PICMs).  As the name implies PIMs do not take technology-specific considerations into account, a concept that is equivalent to logical models in the structured methodologies and to essential models within usage-centered techniques.  The CIBMs represent the business requirements and processes that the system or component supports and the PICMs are used to model the logical business components, also called domain components.  PSMs bring technology issues into account and are effectively transformations of PIMs to reflect platform-specific considerations. 
2. Software Factories. Software factories is a paradigm for automating software development that integrates these advances to increase agility, productivity, and predictability across the software life cycle. A software factory schema is a graph of viewpoints used to separate concerns, relating work done at one level of abstraction, in one part of a system, or in one phase of the life cycle, to work done at other levels, or in other parts and phases, and about how the schema can be used to deliver guidance and to support its enactment through model transformation, constraint checking and other techniques.
3. Agile Model Driven Development (AMDD). As the name implies, AMDD is the agile version of Model Driven Development (MDD). MDD is an approach to software development where extensive models are created before source code is written. The difference with AMDD is that instead of creating extensive models before writing source code you instead create agile models which are just barely good enough.  With AMDD there is an initial envisioning/modeling activity during iteration  0 where you do initial requirements modeling and initial architecture modeling.  Then, during development cycles/iterations, you model storm on a just-in-time (JIT) basis. 
4. Agile MDA.  With an agile approach to MDA you still have the PIM and PSM modeling efforts, but you also have inclusive modeling using simple tools to enable effective interaction with your project stakeholders.  Furthermore, an agile approach enhances the MDA with a comprehensive testing effort.

It's interesting to see how well each modeling paradigm does when compared to the various modeling techniques.  Traditional MDA and Software Factories are the most narrowly focused, requiring sophisticated tooling for them to work.  From a modeling point of view they are very similar: first, the MDA is UML-based whereas the software factories approach employs smaller domain specific models (DSMs); second, the software factories approach seems closer to the metal than does the UML, likely a reflection of the practical nature of Microsoft compared to the far more theoretical nature of the OMG.   AMDD is the most expressive of the four modeling paradigms, being applicable to every modeling approach except TDD (TDD was purposefully left out of scope for AMDD).  Agile MDA also fairs well, which makes sense because it adopts the best of breed from the MDA, AMDD, and TDD.

Estimated Adoption Rates

These adoption rates are my gut feel estimates, I don't know of any studies that have looked at the full range of modeling options.

Recommended Resources

		This is the book for learning about the Software Factories methodology.  If you're a Microsoft developer you should take the time to read this book.
		This is a concise, well written book overviewing MDA.
		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.