Chapter 2. Using Executable UML

Processes may be characterized along a spectrum from agile to deliberate. Agile processes, the exemplar of which is Extreme Programming (XP) [1], focus primarily on adaptation and feedback. They view running software as the primary measure of progress on a project. Consequently, agile processes generally disdain model building because a model does not provide feedback in the same way as code.

Deliberate processes, more commonly associated with model building, are more predictive in nature, viewing a model as a blueprint for construction. A common analogy for deliberate processes has been manufacturing, and software development has been viewed as a manufacturing process for which the models are the blueprint. The construction part of software has always been the automated part: compiling, linking, building, and so forth. A model compiler extends this automation to include repetitive coding decisions and so does away with the idea of model as blueprint.

You can use executable UML models at any point along this process spectrum. At the agile end, you can build a model and immediately verify its behavior, without the need to make coding decisions. You can use a model verifier to run tests automatically, and a model compiler for frequent builds. At the other, more deliberate end, you can know that the construction of an executable UML model helps us understand the system so you can select an appropriate organization for the software expressed as a model compiler.

This chapter describes how to use executable UML. Of necessity, the description of activities is linear, but that is not meant to imply that executable UML must be used in a strict, sequential order. To show how executable UML can be used in a modern iterative process, we describe the key iteration checkpoints at the end of each section.