How do you use a use case model to help in creating an object model?

jim conallen

The use case model is a collection of use case specifications (textual documents) and UML elements (the ovals, stick people, and a bunch of lines connecting them) that describe the functional requirements of the system.  The process of discovering the analysis model (which is what I think you are really asking for) from the use case model (and the non-functional requirements) is called Analysis (The Unified Software Development Process, by Ivar Jacobson).

Every organization does analysis a little differently but the essence is pretty much the same. Here is my simple prescriptive recipe:

  1. For each use case create an activity diagram. This ensures that the use case doesn't have any loose ends, and provides a good overall picture of it. For each principal scenario in the use case create a sequence diagram with the single actor and a single object representing the "System". Use natural language to express the messages between the actor and the system. I like to paste fragments of actual use case text along the left side of the sequence diagram to help describe the scenario better.
  2. Print out the use case text and with different color highlighters identify key nouns and key verb phrases. Key nouns would be things like "Customer", "Product", "Cart", "Order", etc. Action phrases would be things like "searches the catalog for matching items", or "adds the item to the cart".
  3. Using Jacobson's analysis stereotypes (boundary, control and entity), create analysis classes in the model that match up to the text. The nouns are candidate "entity" objects and the verbs are "controller" objects. Sprinkle interface classes in the model to connect up the actor to the control classes (depending upon the architecture this may be done differently).
  4. For each of the sequence diagrams, replace the "System" object with appropriate analysis objects, and make sure you can express all the scenarios with your objects. You may need to create new ones in order to get the task done (not everything appears in the use case after all).

If you can successfully express all the scenarios with analysis objects you are ready to transform the analysis model into a design model. At this point the system's architecture plays a big role and will govern how this workflow actually happens.

There are a zillion ways to do this so don't take what is written here as the defacto standard.