In the last couple of chapters, I gave you an overview of object modeling and the software development life cycle. My goal was to explain the necessary steps in a way that relates to Visual FoxPro and is easier to understand than the usually abstract definitions and explanations. It obviously isn't possible to cover—in a single book or even a series of books—everything that's involved. That's why so many books have been written about this topic. In fact, even the three main brains behind the UML (Grady Booch, Ivar Jacobson and James Rumbaugh) wrote three books to explain the details and then edited a number of others. And, as we know by now, the UML is only part of the entire development cycle.

With the knowledge I gave you in this book, you should be ready for your first successful modeling adventure. However, I still recommend reading some additional books and articles on this topic. You now know how things relate to Visual FoxPro and you're familiar with all the important terms. This should make it much easier to understand the high-level books. Check out my Web site (www.eps-software.com) for a continually updated list of further recommended reading.

The ideas behind object modeling aren't new. However, many of the tools and notations are. The UML is rather young; in fact, we just received the first version that covers everything the average modeler needs and that has been widely accepted. Rational Rose was around for a while, but it didn't support UML, nor did it tie into any of the Visual Studio components until recently. Visual Modeler first appeared with Visual Studio 97. The Visual FoxPro Modeling Wizards are available in their first incarnation today.

These facts make us hope for further acceptance and more advanced tools. One thing I'd really like to see in Visual FoxPro (and the rest of the modeling cycle) are traceability links. These links allow tracing requirements all the way from requirements lists through use cases and object models to the actual implementation. If we clicked an item in the requirements matrix, the modeling tools would automatically highlight all Visual FoxPro classes that are somehow related to this requirement. The advantages are obvious: Changes could be made with high confidence. We'd know exactly how long it would take to work on those changes. We'd also know exactly what to change, and we wouldn't run the risk of forgetting one of the involved components, which would cause a drop in overall product quality.

When the Visual FoxPro Modeling Wizards were created, the UML wasn't fully defined. I'm confident that the next version of the Modeling Wizards will support additional features, allowing us to automate more steps in the development process and to document existing code at a more detailed level.