|
|
The flip side of the principles we just discussed takes the form of a number of common errors that we have seen students make when they're drawing sequence diagrams on their projects for the first time. Our "Top 10" list follows.
Don't do a sequence diagram for each use case.
Jacobson provided a straightforward description of the need for interaction modeling in his business process reengineering (BPR) book (The Object Advantage, Addison-Wesley, 1995): "It is only after you have drawn interaction diagrams [called "sequence diagrams" in the UML] for all courses of events in all use cases that you can be certain that you have found all of the roles that the system requires each object to play and, thus, the responsibilities of each object."
Don't put the use case text on the sequence diagram.
Writing the original requirements-level text for the use case (after "disambiguation" of that text as a result of robustness analysis) in the margin of the sequence diagram provides visual requirements traceability from the design back to your user-certified requirements. The project team will have put a lot of effort into writing the use case text, and the user community should have signed off on the results. The diagram should match the narrative flow of the associated use case.
Don't identify all of the necessary objects first, on a robustness diagram.
If you're having trouble getting a sequence diagram started, you probably wrote the use case incorrectly and/or didn't complete robustness analysis. Having proper robustness diagrams, associated with rigorously defined use cases, in place makes the job significantly easier.
Don't provide a visual trace between the use case text and the message arrows.
Each sentence, and each sentence fragment as appropriate, within the use case text should have some white space around it, and each sentence or fragment should line up visually with the message or set of messages that correspond with the specified behavior. This will enable people reading the diagram to easily see how the system will accomplish the what that the use case describes.
Don't show plumbing; instead, keep your sequence diagram at a high level of abstraction.
It isn't necessary to show plumbing on robustness diagrams, since they reflect a preliminary design view, but the sequence diagrams serve as the last stop before coding and as such need to show the real design in full detail.
Turn your sequence diagram into a flowchart instead of using it to allocate behavior among objects.
Remember that the sequence diagram is the primary vehicle for making behavior allocation decisions. You're really using your sequence diagrams to assign operations to your classes as you go, which means that you should not label your message arrows with free-form text, but should instead link the message name to the name of an operation on a class. (In Rational Rose, for example, you make this linkage by right-clicking the mouse on the message arrow; Rose provides visual feedback in the form of parentheses after the operation name. Behavior allocation-deciding which operations belong to which classes-is of critical importance in the ICONIX approach. Decisions made during this phase of a project dictate whether the overall design is good or bad. This is where experienced designers earn their pay.
Don't focus on interesting methods (real software behavior), as opposed to getters and setters.
By exploring the dynamic behavior of the system, you learn which attributes and operations are needed in the classes contained within your static model. To start, add attributes and methods to your classes as soon as you decide where they go in the context of your sequence diagrams. Note, however, that you should not spend much time drawing "getAttribute" and "setAttribute" message arrows on your sequence diagram. However, it's still a good idea to take advantage of the principle of encapsulation: Only allow access to attributes via "getter"s and "setter"s. You just don't have to show every "get" and "set" on your sequence diagram. This gets counterproductive because it's easy for you to lose the flow of the scenario that way.
Don't think carefully about the origins of the message arrows (in other words, which object is in control at any given time).
Messages between objects invoke the operations on the associated classes. Whereas it's not that important to get the arrows precisely right on robustness diagrams, it's essential that you get them right on sequence diagrams. The flow of control needs to be explicit; it should be obvious at all times which object is in control.
Don't follow basic principles of responsibility-driven OOD when allocating behavior by drawing message arrows.
An object (and, by extension, a class) should have a single "personality," and you should do your best to avoid "schizophrenic" objects. This means that a class should be focused on a strongly related set of behaviors. This parallels the well-established rules that state that objects should be highly cohesive and loosely coupled. Other principles you should focus on include reusability (the more general your objects and classes, the higher the probability that you'll be able to reuse those objects and classes for other projects) and applicability (when you assign methods to the objects on your sequence diagrams, always ask yourself whether there seems to be a good fit between method and object, and also whether the task the method performs is obviously relevant to the object.)
Don't update your static model as you go by building local class diagrams for each package of use cases.
It's nice to keep a "clean" set of domain classes on a pure domain model diagram. However, it's also a good idea to draw "localized" static class diagrams that show both solution space objects and problem space objects. A good guideline for this is one such diagram per package of use cases. As you come up with scaffolding and other types of infrastructure, such as "helper" classes, put them on the static class diagram, as well. This is where you shift your focus from the problem space to the solution space. It's best to use localized class diagrams-say, one per use case package-because, by this time, your static model is probably too expansive to be captured within one readable diagram. Doing this also allows work to be split across teams.
|
|