I was telling my son about my childhood the other day. He's 13 now and no longer willing to believe the stories I used to tell him.

Gone are the days when I would recount tales of my pet dinosaur. He no longer finds it credible that rocks had yet to be invented when I was a child. Alas, so young, and already a cynic.

I then began telling him of the many hours I spent making scale models from kits: "We made scale model ships and - best of all - scale model cars! The best of them were intricately detailed, with doors that opened, a hood that revealed a tiny scale model motor, wheels that turned left or right. You had these little plastic pieces that you detached and then carefully glued together. Finally, when all was done, you applied paint and decals and the car was finished."

Later we played a game of Age of Empires and I was struck by the similarity between the scale models I used to create and the medieval town that was taking shape in our game. Here was a complete world, filled with buildings, people, and - of course - weapons. Various bands fought each other for possession of territory. It was, in fact, a scale model world.

Such scale models are delightful, and the more complete and faithful they are to their original, the more fun they are to play with. My scale model cars, after all my work, couldn't really drive off anywhere, but here, in a software scale model, the scale model people moved of their own volition and buildings that were attacked burned and were destroyed.

Such play seems worlds away from the task of building software for such mundane activities as managing inventory, selling goods, scheduling tasks and events, and managing people. But is it? The best software is, in fact, a scale model of the real world, a fact obscured by the technical details of building databases and queries and writing code that manipulates this data. But just as the most precise scale models are the most enjoyable to play with, so too are they the most valuable in building software.

Much is made of the notion of "scope creep" - the common occurrence of users adding more and more functionality to a project previously thought to have been well defined. Often, though, such scope creep points out that we haven't taken our play seriously enough, that the scale model worlds we build don't mirror their real-world counterparts closely enough. Users, believing that we have in fact faithfully rendered a software version of their real-world activities, expect that they should be able to do with software what they can do in the real world.

Is that such an unreasonable expectation? Perhaps we developers are too serious in the way we approach building software, not playful enough. Why is Age of Empires fun while an Inventory Manager is not? I won't deny that conquering kingdoms is inherently more fun than keeping track of widgets, but I think we can find much greater joy in our work if we remember that we're really building scale models. The problem of scope creep will be far less common if we train ourselves to be faithful model builders.

However, we need good tools for building scale models, tools that help us concentrate more on what the model should be. This is exactly what the goal of object-oriented programming was and is. The first OO language was called, appropriately, Simula. Created in Norway in 1967, the language introduced the idea of classes as blueprints, and objects made from those blueprints. Simula gave way to Smalltalk, Smalltalk to C++, and C++ to Java. All of these provided powerful tools for developers who could use them to faithfully create scale models.

With ColdFusion MX some of that same power is in the hands of ColdFusion developers in the form of ColdFusion components (CFCs). With CFCs we can create scale models of business systems more easily. We can let objects "talk" to one another, making and answering requests from other objects.

Seeing software in this light lets us change the way we build that software. Rather than start with database entities and relationships, we can think in terms of the actual things themselves. We can rapidly build up a diagram that shows what the inhabitants in our scale model world will be and how they will interact with each other. By trying out scenarios with the diagram, we can determine much more accurately how successful our software will be before we write a line of code.

Let's explore this idea with a small example. We have a client who has a small training company and wants us to write software to help her manage that business. Not surprisingly, the main problems seem to be keeping track of all the classes, students, instructors, and so on. We're committed to building a scale model - and to having fun - so a good start would be to create little boxes, each one representing something distinct that belongs to this scale model world. Each one will at coding time be turned into a CFC (see Figure 1).

We can start trying out scenarios to see if our identification of objects seems to work (see Table 1). You can think of a scenario as a very discrete action that one of the people involved in the system might want to accomplish.

There's a problem with some of our scenarios. Look at the scenario, "A manager wants to see which instructor is qualified to teach a course." It might seem that we could send a message like "isQualified( courseName )" to the Instructor class, but that won't work. The Instructor class is only a blueprint for making individual instructors. The same is true for the other classes. Unless we have a way to store a group of the individual objects produced from these classes, we'll have a hard time keeping track of them.

When working through this scale model building exercise, it's helpful to ask, "Who would keep track of that information in the real world?" For example, who would know about instructors, students, classes, and the like? It can't be a particular person, for when he or she leaves, the system's knowledge of those objects will leave too. We can solve this problem by creating a School class that will have the needed groups (instructors, students, etc.) as instance variables.

The more scenarios we work through, and the more we find that our scale model seems to be accurate and complete, the higher our confidence. When we feel we've got a good base to work from, we can begin adding in properties for these classes. You can think of a property as "something the object knows about itself." Information that must be known to the system should be a property of some class. Again, it's helpful to ask, "Who should know this information?"

One advantage of objects over their real-world matches is that they're always completely honest and trustworthy. If you're writing a mortgage application, for example, you can keep the loan balances and other important information with the Borrower. When a Banker needs this information, he can request information from the Borrower, something we decidedly would not do in the real world.

In addition to storing properties - those things the object knows about itself - we must define methods - those requests that the object knows how to deal with. For example, Figure 2 shows the class diagram for the School object.

As we pore over the system, we'll amend it, building up our scale model diagram little by little until, finally, we have a complete system ready to code. And when we are ready for code, CFCs provide an excellent mechanism for ColdFusion programmers to implement objects.

Building object models, scale models of the real world, is a very different procedure from what most ColdFusion programmers are used to. At first it may seem awkward and unnatural, but for those developers who persevere, the rewards are great: their software is more robust, easier to maintain, and - just as important - way more fun to write!

For more on building object models, take this month's lesson/test at www.halhelms.com.