Step 1: Process in Detail
You should begin Step 1 by identifying your actors and domain objects (this list doesn’t have to be perfect—you can always come back to amend it later on). Next, for each actor you’ve identified, you should list all the use cases initiated by that actor, and check whether any other actors are involved in those use cases. You can then look at your collection of use cases and see which domain objects are necessary for them.
Let’s look at this process in more detail.
When modeling a complex system, you can identify actors for your system in many ways: end-user interviews, marketing studies, requirements documents, etc. This is discussed in more detail in Chapter 6.
If you and your team are working through Step 1 as an exercise, then you’re going to have to rely on yourselves to define all of your requirements, which you can do by brainstorming together to identify useful actors. Think about what actors might either request behavior from your system or provide services to your system.
Don’t worry if you can’t think of every possible actor: you can use your known actors to identify unknown actors. Also, don’t worry if you may have extraneous actors: you can use your Use Case Diagrams to identify the relevant actors. These are candidate actors: you’ll revise the list as you go along. Put all actors you identify into an Actor List.
Remember, if the search for actors gets hung up on any question, your customer rep is always the final arbiter.
In case you’ve never been in a brainstorming session, here are the basics of
“formal” brainstorming that you’ll need for the exercises in this chapter:
In Chapter 6, we’ll look in more detail about techniques you can use to identify your domain objects, but for now you can brainstorm to identify candidate domain objects, just as you did for actors. A good place to start is to think about the sort of information that is important to your candidate actors.
Some useful categories of domain objects are
Again, these domain objects should depict the real-world entities, not their software representations. Don’t worry if you can’t think of every possible domain object: you can use your actors and Use Case Diagrams to identify more domain objects. Put all the objects you identify into a Domain Object List.
Remember, if the search for domain objects gets hung up on any question, your customer rep is always the final arbiter.
Pick an Actor
Select the actor that is most likely to use your system. When in doubt, then Customer is usually a good bet, because most systems have some sort of customer, who is the ultimate end user of the services provided.
“That’s Not What We Call It. . . ”
Your customer rep may tell you that customers are referred to as “clients” (or “patrons,” or “guests,” etc.). That’s great! Learn to speak the customer’s language. We all know (or are supposed to know) that code-and-fix is a bad thing; but design-and-fix is a good thing. Never be afraid to put something on a page that someone may dispute. The sooner the dispute is out in the open, the sooner you’ll resolve it.You have to be careful, in fact, of the opposite problem: customers who are afraid to tell you that you’re wrong. Whether in an exercise or in real requirements gathering, keep the tone loose and comfortable. All participants have to feel free to speak their minds and raise their concerns.
Identify Requirements for the Actor
Document the actor’s requirements as use cases in a Use Case Diagram for the chosen actor.
Note that if you’re using paper and pencil (rather than a modeling tool), you may find it extremely helpful to draw your actors and use cases and even the communications on Post-it notes, so that you may rearrange the diagrams as you refine your ideas. Add each use case to a Use Case List.
Examine the use cases in the diagram. Do any of them affect domain objects? If the diagram isn’t too complex, add the domain objects affected, along with any communications to those objects. Do not add the objects if the diagram is harder to read as a result. You’ll have a chance to address domain objects later.
Identify Participating Actors
For each use case for the chosen actor, identify any new or existing actors that also participate in the use case. Add any new actors to the Actor List.
Repeat for Each Remaining Actor
Check off the chosen actor in the Actor List. Then pick another actor, and draw the Use Case Diagram for that actor. Repeat until all requirements have been diagrammed for all actors. If you find an actor that neither requires any behavior from the system nor provides any services to the system, cross that actor off the Actor List.
If you’re working through this process as an exercise, I recommend that you do at least two actor-centered Use Case Diagrams for practice, and more if you wish.
Pick a Domain Object
Select a domain object from your Domain Object List, and start a new Use Case Diagram centered on that object.
Identify Requirements That Relate to the Domain Object
Determine which use cases affect that domain object, and add them to the diagram. Then add the communications from the use cases to the object, and label the communications to describe the changes made by the use cases. Then add the actors that initiate each use case. (Don’t add other participating actors, because the diagram will likely become too cluttered.)
Repeat for Each Remaining Domain Object
Check off the chosen domain object in the Domain Object List. Then pick another domain object, and draw the Use Case Diagram for that object. Repeat until all modifications have been diagrammed for all domain objects. If you find a domain object that is never modified by any known use case, cross that object off the Domain Object List.
If you’re working through this process as an exercise, I recommend that you do at least two object-centered Use Case Diagrams for practice, and more if you wish.
I won’t run through this first step of the process in full detail for my Kennel Management System here, because we’ll be looking at that in Chapter 6. But let’s look at a couple of diagrams from this, just to get a feel for how it all works.
For example, one of the actors identified for the Kennel Management System is the Reservation Agent and Figure 2-3 shows the Use Case Diagram for this particular actor.
Note how, for the sake of completeness, I showed the Reserve a Pen use case in which the Reservation Agent participates, rather than initiates.
If you find that including all the use cases in which an actor participates makes your diagram too cluttered, then you could opt to only show the use cases initiated by a given actor.
Figure 2-4 is another Use Case Diagram from the Kennel Management System, but this time we’re focusing on one of the domain objects that has been identified, Pen.
TIP: Don’t worry if any of this still seems confusing. I’ll be walking through this first step of Five-Step UML in a lot more detail in Chapter 6, where you can see how I go about defining all of the requirements of the Kennel Management System.
So that’s it! By the time you’ve finished this first step, you should have a complete set of Use Case Diagrams. You may need to modify these later as you discover more about your model, but for now it’s time to move on to Step 2 of the process.
blog comments powered by Disqus