The Agile Modeling (AM) Method

Menu

Comparing the Various Approaches to Modeling in Software Development

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 initiative, 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.

 

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 lifecycle, 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 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.