|
|
PDR should involve representatives of both the customer(s) and the development team, as well as any necessary managers, just like requirements review. There's a key difference, though: this is the last chance for the customer to change requirements before the developers drive the given set of use cases through to code. You can think of PDR as representing a line beyond which customers are no longer welcome to actively participate in the process. We talked previously about how use cases represent contracts between customers and developers; it's during PDR that you finalize those contracts.
As we described in Chapter 5, robustness analysis provides a sanity check by helping you make sure that your use case text is correct and that you haven't specified system behavior that's unreasonable-or impossible-given the set of objects you have to work with.
This refinement of the use case text changes the nature of that text from a pure user manual perspective to a usage description in the context of the object model. PDR should center around peer review of all use case text and robustness diagrams. Each reviewer should be able to do the following for each use case.
Read the course of action.
Trace his or her finger along the associations on the corresponding robustness diagram.
See a clear match between text and picture.
Figure 5-5 shows the rules of robustness analysis. Given that both boundary objects and entity objects are nouns, and that controllers are verbs, we can see that nouns can't talk to other nouns, but verbs can talk to either nouns or verbs. The goal is to itemize all the required behavior of the use case in the form of control objects (controllers). This involves taking the user manual view and identifying all the logical functions that must occur, then massaging the narrative of the use case text into a straightforward noun-verb-noun format. This format will allow us to check for correctness when we embark upon detailed design by ensuring that we don't forget any behavior while we're doing the design. Doing this also helps enforce a common noun-verb-noun style of writing use cases across a design team.
As we just mentioned, the verbs in your use case text are represented as controllers on your robustness diagrams. These controllers encapsulate the control flow, and they serve as the "glue" between boundary objects and entity objects, between boundaries and other boundaries, and between entities and other entities. Remember that the reason we call them controllers, rather than control objects, is that they serve as placeholders-we're not ready to assign the behavior they represent to any objects yet because we don't have enough information. Decisions about which methods go on which boundary objects and entity objects, and also about which controllers deserve to become full objects in your static model, are premature; we make them during sequence diagramming, not on robustness diagrams.
Arrows can go in one or both directions between different types of objects on a robustness diagram. An arrow pointing from a boundary object to a control object indicates that the former is signaling the latter to perform. Or there might be a two-headed arrow between a control object and an entity object, signifying that they read from each other and write to each other. Note, however, that you need to use only one type of arrowhead, which is not the case on several types of UML diagrams. Unlike arrows on sequence diagrams, arrows on robustness diagrams don't represent software messages; rather, they simply indicate communication associations. Because you won't code from these diagrams, focus on the logical flow of your use case and worry about the directions of arrows later, in your sequence diagrams.
You should, however, be aware of the presence of patterns across robustness diagrams. Patterns often start becoming visible during robustness analysis. There are two strategies, "control in the screen" and "use case controller," that lend themselves to discovering patterns connected to use cases. (See Use Case Driven Object Modeling for details about these terms.) Looking ahead to interaction modeling, design patterns can be highly useful in the context of sequence diagrams and design-level class diagrams. You should not, though, start drawing full design patterns on your robustness diagrams; it's sufficient to start thinking about how you'll be able to use them to advantage during detailed design.
We used the term technical architecture at the beginning of the chapter. This refers to the set of basic decisions you need to make about what technologies you're going to use in implementing the system. These decisions involve things such as the programming language (for instance, Java versus Visual Basic) and how you're going to build and distribute software components (will you go with Enterprise Java Beans [EJBs] and Java Server Pages [JSPs], or take the Microsoft route with Distributed Component Object Model [DCOM] components and Active Server Pages [ASPs]?). The decisions you make about your technical architecture need to be reflected, to some extent, on your robustness diagrams.
If, for instance, you're building with a technical architecture that involves EJBs and JSPs, your robustness diagrams will tend to reflect the "control in the screen" pattern more than they would if you were building pure HTML pages. Thus, robustness analysis, which is meant to give you a loose description of the design that you can crank out quickly, offers the chance for you to verify that your technical architecture works for the scenarios you're building, and your review of these diagrams becomes a "do-ability" check on that architecture.
Continuing the thought about patterns: The concept of throwaway diagrams is useful in connection with preliminary design; it is not a useful concept when it comes to detailed design. Sequence diagrams are the appropriate place for detailed design. Robustness analysis should be a quick pass across all of the scenarios you're going to build, in order to provide maximum value to your project. If your preliminary design takes as long as detailed design, you'll lose the benefits of this quick sanity check.
Robustness analysis allows you to make a reuse pass through the entire use case model before you commit any use cases to the design. Looking for reuse possibilities also helps you identify objects you missed during domain modeling. You must update your static model before you can consider yourself done with robustness analysis and ready to move on to interaction modeling (the subject of Chapter 7). The new objects you discovered while you were drawing all those robustness diagrams and talking about them with your customers need to go onto your class diagrams now, not later.
This is also the right time to add some key attributes to your more significant classes. While we're talking about attributes: As we introduce windows and screens-in the form of boundary objects-to our robustness diagrams, we begin to trace data associated with those objects back to the entity objects from which the data comes and/or to which it goes. The natural result of that tracing is the addition of attributes to the classes in the domain model.
|
|