Why Modeling Tools Fail

This chapter has extolled the virtues of modeling techniques and modeling tools. The use of models in software development offers significant advantages to the software engineer. Modeling tools underpin the development of software models and enable a model-centric approach to software development.

Despite the benefits of modeling tools, their use is far from commonplace on development projects. These next sections examine some of the reasons projects are seemingly unable to make effective use of modeling tools.

Christmas Puppy Syndrome

Animal rights campaigners spread the message that a dog is for life, not just for Christmas. Anyone buying a modeling tool would do well to heed this advice. Research has shown that like the Christmas puppy, modeling tools in general do not enjoy a lot of use once the wrapping has been removed and the novelty of the new toy has worn off.

This is an expensive white elephant to leave sitting on the shelf. Modeling tools are sophisticated pieces of software, targeted at the enterprise developer, and as such, they often carry enterprise-sized price tags.

The reason many modeling tools fail to win popularity with developers is not because of any shortcomings with the tools themselves; instead it is often because of the purchaser's unrealistic expectations.

Here are some of the common misconceptions surrounding the capabilities of modeling tools:

• Complex code can be replaced with simple diagrams.

• Object-oriented design knowledge is not required.

• Modeling tools provide an ease-of-use layer on top of J2EE.

• They ensure a proper development methodology is followed.

• They are easy to use, so no training is needed.

The next sections address each misconception in turn.

Replacing Code with Diagrams

A well-thought-out picture can convey a great deal of information succinctly and accurately. The use of diagrams to convey design detail is a central tenet of software modeling. One of the major misconceptions, however, is that the information in a UML diagram can be translated directly into fully functional code and that the UML offers a superior substitute to Java as a programming language.

Modeling tools can generate source code from UML artifacts such as class and interaction diagrams, and yes, the code they generate does save the developer effort. However, this level of code generation falls far short of the concept of executable UML, whereby the entire system is maintained purely in model form. The UML is simply not expressive enough to describe a system to the level at which it can be executed directly.

Models and modeling tools are not a replacement for developers, and the concept of fully executable UML is still more of a research project than a viable commercial reality.

Modeling Tools as a Replacement for OO Skills

Buying a state-of-the-art modeling tool will not make you a skilled object-oriented designer. If you cannot exhibit artistic flair with a box of colored crayons, then you are equally unlikely to prove a talented artist with the latest computer graphics package.

Warning

Applying modeling techniques without staff skilled in object-oriented design will cost time, not save it.

Modeling tools support designers in developing object-oriented software. They enable designers to use their hard-earned object-oriented design skills productively. Consequently, modeling tools are best used by designers already conversant with object-oriented development practices. They are not a tool for novices, nor are they a teaching aid.

Ease-of-Use Layer

Modeling tools do not provide an abstraction layer upon the underlying platform for which the software is targeted. For our purposes, the underlying platform is J2EE. While some modeling tools cater to the development of J2EE components, these tools do not remove the need for the software engineer to understand the intricacies of J2EE. It is the architect's responsibility to apply his or her knowledge of J2EE when designing with the tool; the tool will not do this for the architect.

Interestingly, much work is ongoing in this area to make models platform-neutral. In this way, code can be generated directly from the model for any given platform. This approach is known as Model-Driven Architecture (MDA), and the technology is still in its infancy. If the goals of MDA can be realized, a significant step forward in terms of software development productivity can be made.

Model-Driven Architecture is discussed in Chapter 8.

No Inbuilt Methodology

Modeling tools are process-agnostic in that they do not support any particular software development methodology. Instead, it is left to the project team to use the modeling tool as part of the chosen development process.

Perhaps the confusion that modeling tools come with a ready-made methodology has come about because of the association with the UML and the IBM Rational Unified Process. Booch, Rumbaugh, and Jacobson, who formulated the UML, also combined their own respective development methodologies to create the Unified Process that later became the IBM Rational Unified Process. The UML and the RUP, while quite distinct in their uses, are synonymous in the minds of many developers. Because the UML is common to virtually all modeling tools, the leap is often made that by using a modeling tool, a RUP-like process is intrinsically followed. This is certainly not the case. Models are complementary to the development methodology, not a replacement.

Training Is Not Required

Getting the most out of a modeling tool involves being aware of all the tool's features and understanding how to use those features on a development project. A common failing is to introduce project teams to new tools with no supporting information on how those tools can assist the team in the process of developing quality software.

Training on the use of the tool, possibly in conjunction with general training on UML notation, helps to educate the development team on the benefits the chosen modeling tool brings to the software development process. Training also helps teams buy in to the concept of working with models.