OOAD and Use Cases

Thoughts by Jim McElroy

Many sites in industry are now using a combination of James Rumbaugh's (OMT) and Ivar Jacobson's Techniques in OOAD. The Unified Modeling Language represents a collaboration of these two, along with Grady Booch. Jacobson introduced the concept of Use Cases about 3 years ago, and it has caught on as a very effective requirements gathering front-end to the OO development process.

Basically, it boils down to this -

  1. The old method of Structured Analysis and Design relied on functional decomposition, and data flow diagrams. However, a system's functionality was one of the most unstable aspects of a system. In addition, the data/functionality split caused all sorts of headaches, all the way from the analysis stage through to the coding. A whole book can be written on these problems (indeed I have written several chapters of such a book, that will probably never get printed).
  2. People doing database work came up with ER diagrams, and found that they were much more stable than data flow diagrams and functional decomposition.
  3. So some people decided to include "information engineering" in with their analysis and design, along with data flow diagrams. However, the two views of the system - process oriented (DFDs) and data oriented (ER diagrams) mixed about as well as oil and water.
  4. OO languages came along, and from OO languages sprung OO analysis and design. OOA&D combined the data and the functionality into objects, and modeled the relationships between objects (inheritance, aggregation, and association). OOA&D seems to have effectively healed the data-functionality split that has caused headaches for so long.....
  5. In addition, OOA&D is mainly data oriented rather than process oriented, so OO models tend to be much more stable than DFDs and the old structured methods.
  6. Also, OOA&D offers a seamless development process. Analysis objects map directly to design objects, which map directly to objects written in code. Traceability is much more solid, slipping back and forth between development phases is much easier.
  7. Objects can act as "Software ICs", leading to greater reusability of software components. This actually extends all the way up into analysis and design.
  8. Although OOA&D creates a more stable (and yet more flexible) design, people still tend to state requirements in functional terms. This is where Use Cases come along as a better front-end to OO analysis and design from that described in James Rumbaugh's book on OMT.

Use Case requirements gathering goes like this:

  1. Developers and clients get together and discuss how a proposed system will be used. "Actors" are identified, which are roles that users play with the system. For example, the actors for a banking system might be "customer", "teller", "loan officer", "system administrator", etc.
  2. The way actors use the systems are called "Use Cases". For example, a "Use Case" for a customer using an ATM might go something like this:

    3. It gets more complicated than this, but this is the basic idea.

  3. With a basic set of Use Cases, potential system objects (or rather, classes) can be identified. In the above Use Case, several potential objects become immediately apparent - ATM, ATM card, central bank, ..... "Customer" is not an object in this case, because a customer is external to the system, and is therefore an actor. (However, a customer record is a valid object.)
  4. The relationships between the objects can be defined and the basic Object Model started.
  5. In addition, the Use Case model leads directly to scenarios, event trace diagrams and state transition diagrams, which form the dynamic aspects of the system. The "Dynamic Model" serves to reinforce the Object Model, by identifying the functions the objects must have to send and receive events and messages.
  6. Use Cases are also used to develop test plans for system testing.
  7. Use Cases are also very effective because they utilize the JAD (Joint Application Development) method of developing systems, where the customer is brought in early and becomes an active part of the requirements gathering phase. This method of requirements gathering helps eliminate the tendency to "create the wrong system right."