Role of Modeling

We model to understand complex things. Software today is more complex than ever. As a result, we model software. Our models describe what we want to build, what we are building, and what we have built. Models are used throughout the development life cycle and are key artifacts. Models often connect different types of artifactsuse case specifications to database tablesand provide a chain of responsibility and traceability.

These models are simplifications of reality. Models exist at various levels of abstraction. A level of abstraction indicates how far removed from the reality a model is. High levels of abstraction represent the most simplified models.[1] Low levels of abstraction have close and near 1:1 correspondence with the things they are modeling. An exact 1:1 correspondence is no longer a model but rather a transformation of something in one form to another.

[1] PowerPoint slides and your favorite clip art represent the highest levels of abstraction a system can have.

The real value of a model is not in what it contains but rather what is hidden. Class diagrams in a UML model, for example, do not include the individual statements of each class operation. These details are hidden in the model and are available only in the source code.[2] Class diagrams further hide things by not exposing all a class's operations, attributes, and associations. The choice of elements to suppress in a diagram is determined by its goal. Each class diagram is created for a reason: to communicate or to explain something. Details that don't help in communicating or explaining don't belong in the diagram. So most diagrams contain classes that have only the relevant details exposed.

[2] I consider source code itself a model, with the choice of variable names and comments the prime source of added value.

Many models are involved in the development process. Each model has its viewpoint. In fact, part of a model's definition[3] is that it is a semantically complete view of a system. Each model is at a different level of abstraction. Because they model the same system, the mappings between the models of the same system are of immense importance. The mappings establish chains of traceability and dependency that help us connect the various and sometimes confusing artifacts of the development process. A user profile screen definition can be traced to the JSP code that implements it, and the state change behavior of a purchase order can be traced to a use case specification that defined itall done through the various UML models of the system.

[3] See James Rumbaugh, Ivar Jacobson, and Grady Booch,The Unified Modeling Language Reference Manual (Boston, MA: Addison-Wesley, 1998).

In addition to understanding, modeling has other benefits. It is a communication mechanism, allowing one group to communicate to another in a common language. Modeling encourages us to break the problem into manageable pieces. Because of its object-oriented roots, UML modeling in particular encourages us to think of things in terms of objects and to encapsulate properties and behaviors in objectlike concepts. Modeling with computer-aided software engineering (CASE) tools can help us generate source code and components directly from the models.

Before we go on, I need to make one point very clear. The role of modeling is not to produce code through automation or to produce documentation through reverse engineering. These are simply handy by-products of modeling software systems with CASE tools. All too often, we become obsessed with a particular tool's ability to round-trip engineer code and models, and we often miss the whole point of modeling. Automated round-trip engineering will make it easier to connect the abstractions in the model to source code artifacts, but it will not be able to construct a diagram that communicates a point. It won't be able to selectively hide or expose key properties that make understanding easier. Most reverse-engineering tools can reverse engineer only a source code structure. The few tools that attempt to reverse engineer behavioral diagrams usually end up with diagrams so large and complex that they aren't even worth printing.

The real value in models and modeling is the ability to look at a simplification of a system through a particular viewpoint where the system becomes easier to understand. If the models are as complex as what is being modeled, there is little point in modeling.