Should I Model My Entire Application?

Whenever possible, you should model your entire application (or system). That way, you have conscious control over the architecture and design of the application. In some cases—for instance, when you don't have control over the entire system—you can't model it in its entirety. Still, it can be very valuable to model what you do have control over.

From the Real World—More Holes than Swiss Cheese While working as a systems integrator on a very large project (thus not having direct control over any particular implementation piece of the project), I was looking at a product production scenario that others had specified in the system requirements. The scenario was quite complex. I was just getting to know object-oriented techniques at that time, and I decided to develop a statechart diagram of that scenario. (As you will learn in an upcoming chapter, statechart diagrams typically depict the state of a specific object. I decided to try this technique on an entire scenario.) To my great surprise, I found there were a number of holes in this production scenario. In many situations, this scenario did not specify what should happen under certain common conditions. In other words, if this scenario were implemented, it would fail miserably. I did not “own” this part of the system, but I was still able to learn about it and find the flaws in it through modeling, which enabled me to recommend key changes.

Lessons Learned Don't be afraid to use modeling techniques in creative ways (e.g., using the statechart diagram against a scenario instead of an object). As long as you use them properly (i.e., don't undermine the principles underlying the diagram or technique), you might find new ways to extract great value from them. The UML police will not come and kick your door in for doing so.

If you are dealing with an existing system (maybe you have to interface with this system or need to refurbish or replace a part of it while keeping it operational), you might just choose to “wrap” that existing system. When you wrap an existing system, you “surround” it with an interface layer that presents the same, existing interfaces to external applications but that enables the underlying technology to change. When modeling, you would just model the interfaces to the system or application, not the internals (later in this chapter, when discussing classes, we will revisit modeling interfaces). This also would enable you to add new interfaces without disrupting the existing ones (indeed, your new interfaces might use the old interfaces, but this would all be hidden under the wrapper), and it would enable you to change the underlying implementation while keeping the interface the same.

In cases where you are limited by budgetary, schedule, or staff skill issues (i.e., you don't have many people who can do the modeling), you should model only the critical parts of the system. For example, you might choose to model in detail only your high-priority use cases. Any part of the application or system that is high-risk should be modeled. If your application is a real-time application, it should be modeled. They are too critical to risk development based on poor, unidentified designs. After all, if you can't make these critical pieces work, why bother with the less critical parts?