17.3 The Reverse Engineering Wizard

The Reverse Engineering Wizard

Let's have a general look at the Reverse Engineering Wizard and all its steps. Figure 1 shows the first step, which allows you to select the class libraries that you want to reverse-engineer.

There are two ways to select code to be reverse-engineered. The first is to select single class libraries, and the second is to open an entire project. In this case we'll analyze the entire project and select all its class libraries.

I'm frequently asked whether it is possible to reverse-engineer Visual FoxPro forms (not to be confused with form classes!). The answer is easy: "No, it isn't." The reason is simple. Forms are similar to classes, but they aren't real classes. With forms, the techniques of instance programming and (to a degree) pseudo-subclassing are used heavily. Those techniques are unique to Visual FoxPro and are not supported by any modeling tools.

Once the source code is selected, we can move on to step 2 (see Figure 2).

Figure 1. Selecting code to be reverse-engineered.

 

Figure 2. Selecting the model to be updated.

Again, you can either select a Rational Rose or Visual Modeler model file, or you can chose to export to the current model if the modeling tool is running in the background with a model file loaded. If you specify a model that doesn't exist, it will be created automatically as an empty model.

When moving from step 2 to step 3 (see Figure 3), the model file has already been analyzed, as has the source code to be exported. Step 3 shows the structure (packages) of the model file as well as all classes to be exported.

Figure 3. The model structure and all classes to be exported.

The purpose of step 3 is to organize your model. The tree shows the packages that already exist in the model. You can add new packages, and rename or delete the ones you've just created (see Figure 4). But you cannot rename or delete existing packages you need the modeling tool to do that.

Figure 4. Creating, renaming and deleting packages.

The list at the right shows all classes that have been chosen to be reverse-engineered. You can see the name of the class, the library it's located in, the model package the class is assigned to and the Visual FoxPro base class. You can now drag and drop classes into packages in the tree to assign those classes to individual packages. You can click on the list headers to re-sort the list and you can select multiple classes at once. This makes it easy to select all classes of a certain base class or all classes that are stored in the same library, for instance.

Classes that you don't want to reverse-engineer (even though you might reverse-engineer other classes in the same library) can be dropped into the Excluded node. This just means that they will be ignored at this time but not removed from the model.

If classes were imported earlier from the model, they will already have packages assigned. Even if you assign those classes to different packages, they won't be relocated because they already exist in the model. You can relocate classes in the actual modeling tool.

When the wizard encounters a class that hasn't been imported from a modeling tool, it assigns default packages, such as "User Services" for all interface objects. It will do so even if a package of this name doesn't exist (keep in mind that the wizards were initially designed for Visual Modeler, which always has those packages). You need to reassign these classes to existing packages before you start to export.

Once you have decided the location of your classes in the model, move on to the final step (see Figure 5).

Figure 5. Click Finish and you're done.

Step 4 offers two additional settings, one of which is to create a default diagram. I do not recommend this, for reasons explained below. The other option allows you to start the modeling tool right away so you can see what has been accomplished. Obviously, this is a good choice.

Creating diagrams

Just because you export classes to the modeling tool doesn't mean that you'll find diagrams showing those classes. As discussed in previous chapters, models are split into a number of small, scenario-oriented diagrams. There is no way for the Reverse Engineering Wizard to create useful scenario diagrams. Nevertheless, it offers the option of creating a default diagram that shows all exported classes. This is useful if you are creating a new model from scratch. Any time you update an existing model, you should not create a default diagram, because the wizard will add yet another diagram every time you run it.

Whether or not you create an existing diagram, you'll always have to do some editing afterward. You'll see all the exported classes in the Rational Rose/Visual Modeler Class Browser of the modeling tool. You can then simply drag and drop classes into a diagram. All the relations and dependencies will be drawn automatically, so this task will challenge your artistic skills above anything else.

Updating existing models

Typically, the Reverse Engineering Wizard will update existing models with changes made in classes that you've previously imported to Visual FoxPro. The wizard is actually quite smart, because it reliably remembers the class mappings even if classes are renamed to resolve conflicts. The wizard analyzes the additions you made in source code (visual classes, that is) and adds those to the classes in the model as well. This is an extraordinary tool to keep object models up to date.

No matter what the wizard encounters, it will never remove anything. It simply assumes that the classes, properties, methods or relations have yet to be implemented. For this reason, you always have to remove items by hand in the source code as well as in the model (otherwise they will show up again eventually).

Round-trip engineering

In a typical engineering cycle, you'd create an object model, implement the model in Visual FoxPro (or any other tool of your choice), make additional changes in the source code, update the model from those changes, possibly make more changes to the model and update the source code from those changes, and so forth. This cycle of going back and forth between the modeling tool and the implementation environment is called "round-trip engineering."

The Visual FoxPro Modeling Wizards fully support this kind of development cycle. The Code Generation Wizard creates new Visual FoxPro code or updates existing code. The Reverse Engineering Wizard updates existing models (or creates new ones as described below). This is an ongoing cycle that you can continue even over multiple versions of your application. In fact, the wizards allow you to work on both parts (model and implementation) simultaneously. In this case you have to run both wizards to update the source code and the model with the changes that occur in the other part. This scenario occurs frequently in real-life development cycles.

Creating new models

The Reverse Engineering Wizard also allows you to create new models based on your existing source code. This is a great way to impress your friends, your customers and your boss. They'll never know that you didn't do any real modeling (of course, you'll start doing this from now on, right?).

Creating new models from existing code isn't much different than updating models. The major difference is that all classes are created from scratch. In order to get a well-organized model, you'll have to create a number of packages in step 3 of the Reverse Engineering Wizard (see Figures 3 and 4) and assign classes to them.

For small to mid-sized applications, you might consider having the wizard create a default diagram. This diagram will be huge even for a small application, but it usually gives you a good starting point.

Creating models, even if you haven't done proper modeling, has a number of advantages (even beyond impressing your friends). First of all, it gives you quick, hassle-free, accurate documentation of your application. Programmers usually skip creating this kind of documentation because it's time-consuming and difficult to keep up to date. This is not an issue with the Visual FoxPro Modeling Wizards, thanks to their round-trip-engineering capabilities. As if this weren't enough, there are even more advantages especially for future iterations of your application, and also for maintaining and supporting the existing program.