15.2 Object modeling- an overview

Object modeling an overview

Object modeling is the step in which we architect our application. Similar steps can be found in most undertakings, such as building houses, bridges and concert halls, flying into space, or simply setting up a plan for the day ahead. However, there is one major difference between the planning step in software development and the planning step in all other aspects of life: Software planning steps are often skipped. To me, this is unbelievable! Can you imagine building a skyscraper without consulting an architect first? I wouldn't set foot on the second floor of that building. In fact, I wouldn't get anywhere near its construction! Or can you imagine flying into space without planning the mission first? Going through a day without having a proper plan (schedule) can be disastrous enough (even though programmers are known to be quite accustomed to this scenario).

For software projects, the lack of a plan is equally disastrous. However, most people don't seem to care. "It takes too long," they usually say. "I have to earn a living and cannot spend weeks doing object modeling!" they continue. And they have a point! Modeling takes awhile, just as it takes awhile to plan a house. Nevertheless, nobody would seriously skip this step in the construction business. If we explore the scenarios further, we soon recognize that building a mid-size application is far more complex than building a house. This makes it even more surprising that object modeling is such a hard sell in most projects. In the end, this lack of respect for the planning phase makes up a major part of the incredibly high percentage of canceled or failed software projects.

Beating the odds of finishing a project (maybe even on time and under budget?) is a major step in making a career in software. I model every application I build for myself, and I try to talk every customer into modeling as well. Of course I need to set aside time for this step. But is this time spent in addition to the "regular" development time? Absolutely not! Quite the opposite is true. Modeling my projects saves me a ton of time during implementation and testing. In fact, it saves me so much time that I'm able to write a book while working on other projects.

A picture is worth more than a thousand words

What exactly is an object model? Typically, a model is a bunch of diagrams describing the architecture of an application in a great level of detail. The diagrams show classes and objects as well as their relations (including inheritance), dependencies, properties, methods and interactions.

Object models are abstract and technical. Unlike use cases, the customer or domain expert typically doesn't understand object models. (And those who think they do typically are the most dangerous.) This also means that every shortcoming in the use cases is unlikely to be detected from this point on. Testing usually is the next quality milestone that discovers such problems. That's rather late, of course, so do everything you can to make sure quality milestones are met before you start to model. Make sure people take time to validate use cases and to point out and resolve problems.

Similar to use cases, object models describe an application in scenarios. Modeling scenarios are technology oriented. A scenario could describe how data is queried, for example. This scenario might show an interface object that uses business logic to retrieve data from some kind of storage mechanism. With use cases, I recommend sticking to one scenario per use case document to keep things simple. In the modeling step, this is no longer true. We typically have many diagrams describing similar (or even the same) scenarios, looking at them from different angles. One scenario might describe the inheritance situation using a class diagram, while another scenario describes objects used and their dependencies. Yet another diagram might show the messaging that occurs while the scenario is executed, using some kind of interaction diagram. Of course, the entire application could be described in two or three large diagrams. In fact, most customers expect to see a global diagram at some point. However, this is not practical. There is simply too much going on in most applications to show everything at once. However, I do recommend creating some "guiding diagrams" that provide a map of all scenarios organized in categories (or "packages" as they are called in the UML).

An object model must be an accurate and technical description of an application. This seems to be one of the hardest points for most modelers. Drawing diagrams is easy, but it's not so easy to make sure that the diagram can be implemented as drawn. Always keep in mind that every "box" you draw will become a class or object in the final product, so you have to consider FoxPro base classes and other issues. Of course, at this point we reach a level where a model is not entirely language independent, but that's fine, as long as such considerations aren't introduced too early in the modeling phase (see below). There are a number of things that can be helpful when creating the object model, including reusable model files. You can have a file with the entire set of Visual FoxPro base classes that you can use to subclass all your classes. This doesn't prevent errors automatically, but it makes it easier to detect problems. For instance, an object that's supposed to be a form, but that's instead somewhere in a chain of custom classes should make you suspicious.

There are a number of modeling notations. I use the newest and most widely accepted one: UML, the Unified Modeling Language. This notation has become extremely important in the last couple of years. In fact, I think it is so important, I spent an entire chapter (Chapter 12) explaining most of its aspects.