|
|
The use case concept is fairly straightforward, and hence simple narrative text as we've seen thus far in the chapter is often sufficient for expressing use cases. The UML does, however, provide a formal means for diagramming use cases and their interactions with actors. As mentioned earlier, actors (whether people or systems) are represented as stick figures; use cases are represented as ovals labeled underneath with a brief phrase describing the use case; and the box surrounding the oval(s) represent the system boundaries. Figure 9-3 shows a sample UML use
case diagram; here, we depict three actors—Student, Faculty, and Registrar—as having occasion to participate individually in the Request Transcript use case.
When deciding whether or not to go to the trouble of diagramming your use cases rather than merely expressing them in narrative form, think back to the rationale for producing use cases in the first place: namely, to think through, and to then communicate, the software development team's understanding of the system requirements to the users/sponsors in order to obtain consensus. It's up to you, your project team, and your users/sponsors to determine whether diagrams enhance this process or not. If they do, use them; if they don't, go with narrative use case documentation instead.
Once you've documented a system's actors and use cases, whether in text alone or with accompanying diagrams, these become part of the core documentation set defining the problem to be automated. In the next chapter, we'll examine how to use such documentation as a starting point for determining what classes we'll need to create and instantiate as our system "building blocks."
The UML spells out some additional formalism with regard to use case modeling; for more details on use case diagrams, including advanced diagramming techniques, please see our recommended reading list in Chapter 17.
|
|
