|
|
You want to achieve three primary goals during interaction modeling.
Allocate behavior among boundary, entity, and control objects. During robustness analysis, you identify (or at least take an educated guess at) a set of objects that together could accomplish the desired behavior of our use cases. You also break that behavior down into discrete units and create placeholder control objects for each of those units of behavior. Now you need to decide which objects are responsible for which bits of behavior. If you are not certain about what the relevant boundary, entity, and control objects are, it's too soon to be contemplating how you will allocate behavior. Go back to robustness analysis and make sure.
Show the detailed interactions that occur over time among the objects associated with each of your use cases. Objects interact at runtime by sending messages to each other. These messages serve as what Jacobson calls stimuli-that is, a message stimulates an object to perform some desired action. For each unit of behavior within a use case, you must identify the necessary messages/methods.
Finalize the distribution of operations among classes. You should aim to have a fairly high percentage (perhaps 75 or 80 percent) of your attributes defined within the static model when you finish with robustness analysis. We advocate a minimalist approach to defining operations during domain modeling and robustness analysis. In fact, we recommend that you don't assign any methods during preliminary design. That's because there isn't enough information available with which to make good design decisions about operations at that stage of a project. (Think about it: You haven't discovered all of the objects until you've completed all of your robustness diagrams, and trying to allocate behavior into an incomplete set of objects is going to be error-prone at best.) When you get to interaction modeling, however, you do have good information (at least you hope to). As you lay out the detailed behavior of your objects, on sequence diagrams, in the context of your use cases, you should begin to finalize the process of finding appropriate homes for attributes and operations. While you do this dynamic modeling, you will be updating and expanding your static model, which will solidify your increasing knowledge of how your new system should work.
The UML's sequence diagram evolved from Jacobson's object interaction diagram and the event trace diagram from OMT. Within the ICONIX approach, sequence diagrams represent the major work product of design. You draw one sequence diagram that encompasses the basic course and all alternate courses of action within each of your use cases. (You can use more than one page if you need to.) The results form the core of your dynamic model, in which the behavior of your system at runtime, including how the system will accomplish that behavior, is defined in great detail.
There are four types of elements on a sequence diagram.
The text for the course of action of the use case appears down the left-hand side. It's a good idea to break up the text with white space so that it's easy to see which sentence(s) correspond with each set of elements to the right.
Objects, which you bring over directly from your robustness diagrams, are represented in rectangular boxes with two names. The name or instance number, and the name of the object's class, appear in the form object:class. Either name can be omitted. The objects can optionally be displayed with their robustness diagram stereotypes; this is often helpful in keeping track of messages passed among actors, boundary objects, and entity objects.
Messages are arrows between objects. A message arrow can go directly between two dotted lines, between a line and a method rectangle, or between two method rectangles (see below).
Methods (operations) are shown as rectangles that lie on top of the dotted lines that belong to the objects to which you're assigning the methods. You can use the lengths of these rectangles to reflect the focus of control within the sequence: a particular method is in control up to the point at which its rectangle ends. Unfortunately, focus of control is often more useful in theory than in practice, because most visual modeling tools aren't very well-behaved with respect to this particular feature. If you find yourself getting frustrated with trying to show focus of control on your diagrams, don't hesitate to just turn its display off-you don't want anything to distract you from making good behavior allocation decisions.
|
|