I worked with several small software development groups that used various computer-aided software engineering (CASE) tools over a period of several years (Wiegers 1996). CASE tools let analysts and designers draw models of requirements and designs according to a variety of standard modeling notations and languages. Commonly used models include data flow, entity-relationship, statechart, class, sequence, and activity diagrams. When they first came on the scene in the 1980s, vendors claimed fabulous benefits from CASE tools. In fact, the potential payoff from CASE tools was so exaggerated that the term CASE has fallen out of favor even though those sorts of modeling tools still exist.

I’ve seen several groups use such tools simply to document completed systems. This is useful, and practicing on something that already exists is a good way to learn how to use both the tools and the modeling techniques. However, this approach doesn’t help you improve your software; it just records information about software you’ve already built. Lesson six therefore is:

Use the tool’s built-in methodology rules to validate diagrams and detect errors that are difficult for people to find. Your team should use the tools to iterate on design models before they start cutting code, because developers will never conceive the best design on their first attempt. Iterating on requirements and designs, rather than on code, is one way to improve quality and reduce product cycle times.

These tools implement various standard modeling methodologies, such as Yourdon-DeMarco structured analysis, and modeling notations, such as the Unified Modeling Language (UML). Our team had some energetic discussions in which we haggled over exactly what rules we should follow for various design models. Resolving these issues was critical to successfully implementing both modeling methods and tools in our group. We finally agreed on some conventions we could all live with. Lesson seven from our experience is:

Even if the developers do a great job on design, programs rarely match their designs exactly. The team must decide how to reconcile inconsistencies between design diagrams and delivered software. If you want the models to provide long-term benefits, heed lesson eight:

Ideally, team members will update the models to match the reality of the system as it was built and they’ll keep the models current as they modify the system. This approach demands considerable effort and discipline. If the system evolves while the models remain static, inconsistencies between code and designs can cause confusion, wasted time, and errors during maintenance. If you decide not to update the design models, either discard them once they’ve served their purpose, or clearly identify them as representing the initial design, not the current software implementation.

Some design tools permit round-trip engineering—generating code from a design and regenerating design models automatically from source code. This approach guarantees the correctness of the as-built design documentation. You can repeat the model generation anytime code changes are made to create a new set of accurate models. However, we did have problems when we needed to modify generated code to make it more efficient, to add custom code, or to insert hooks to connect to external routines. Anytime we regenerated the code we needed to make the same manual revisions again. Your best bet is to use tools that permit you to generate all the necessary code from the models and vice versa.