CHAPTER 4 Use-Cases - IBM - United States

1 IN THIS CHAPTERH aving defined the project vision, the actors, and the events of interest inthe system, we next move to assigning the events to Use-Cases . the use -caseis the one UML artifact that focuses on whatthe system will be contractedto do, not howit will do it. Use-Cases are the hub from which all require-ments are event identified in CHAPTER 3 as part of the Inception phase must besatisfied by a use- case . One use- case can satisfy many events. As a result,a use- case may have more than one pathway through it. Apathwayis theset of steps that must be carried out to satisfy the goal of the actor. Thischapter examines how to identify these pathways, and it describes in detailthe primary pathway through each CHAPTER also investigates a preliminary software architecture. Thisarchitecture is based on what is known about the application s execution do-main and is represented by the UML component and deployment Inception phase will also produce an estimate of both the number ofiterations and increments in which the system will be realized and the timeand costs incurred for deliverables.

2 This grouping of functionality is visual-ized with the UML package 4 Use-CasesGOALS To add to our information about Remulak Productions, espe-cially pertaining to preliminary technology needs and goals. To explore the concept of the use - case and the use - case diagram. To review a sample use- case template. To define the various pathways through Use-Cases : primary,alternate, and exception. To learn how to give a detailed description of the most commonpathway through a use- case . To discuss a preliminary software and hardware architecture. To review the planned increments and implementation Sample ProjectRecall from CHAPTER 3 that Remulak Productions, which specializes inlocating hard-to-find musical instruments, primarily guitars, wants toreplace its legacy order entry application. Company founder, owner,and president Jeffery Homes has contacted us to address his concernabout his company s ability to keep up with is not an IT expert, but he knows that success depends on thereplacement system s extensibility into the future.

3 His initial concern isthe applicability of the Internet to his business. He wants to minimizecost outlays for the technology used while maintaining flexibility tochange platforms later. He makes the following observations about thecompany: Many of its products are very expensive and require quite a bit ofhand-holding and selling by the order clerk. Many, if not all, of its customers want to be able to get informationon orders that have been placed and shipped without interactingwith a company representative. Many of its customers want to order other products from Remu-lak that are not as unique as its instruments, including recordingand mixing technology, microphones, and recordable CD 4 Use-Cases1234567890123456789012345678901 234567890On the basis of these observations, Homes decides that an Internet-based inquiry capability could benefit Remulak. However, some casesstill require customized, personal interaction, at least initially to enter theorder in the system.

4 So it appears that all but the most complicated orderscould utilize an Internet-based order solution. These facts are crucial toconsider as we devise our initial software architecture for Process ModelOnce again, the Unified Process model is spotlighted, again with empha-sis on the Inception phase (Figure 4-1).In this CHAPTER , the following Unified Process workflows and activitysets are emphasized: Requirements: Analyze the Problem Requirements: Define the SystemThe Process Model65123456789111111111122222222223333 3333334 InceptionBusiness ModelingRequirementsAnalysis and DesignImplementationTestDeploymentConfig uration andChange ManagementProject ManagementEnvironmentElaborationConstruc tionTransitionInitialElab #1 Elab #2 Const#1 Const#2 Const#NTr a n#1Tr a n#2 PhasesIterationsWorkflowsFIGURE 4-1 Unified Process model: Inception phase Requirements: Manage the Scope of the System Test: Plan TestUse-CasesThe project s success depends largely on defining requirements in amanner that is intuitive to both the IT staff and the project requirements documentation not only serves as a key artifact, butalso must be a living artifact.

5 Requirements cannot be expected toremain stable throughout the project effort, so they must be in a formatthat can be easily assimilated by the current project team, as well as bynew team members. The key vehicle to capturing requirements is theuse- case . Many people I work with ask, But when do you do func-tional requirements? Use-Cases are the functional requirements of concept of the use - case sprang from Ivar Jacobson s early workon large telecommunications switching systems at Ericsson. This washis primary contribution to UML. As mentioned in earlier chapters,Jacobson s Objectory Process was transformed into Rational Software spopular process model, the Unified are goal-oriented and serve as containers of sorts for theinteractions that they satisfy. Jacobson s definition of a use- case willserve as a baseline as we begin our exploration of this key UML artifact:A behaviorally related sequence of interactions performed by an actor in a dialogwith the system to provide some measurable value to the s examine this definition in more relatedmeans that the interactions should, as a group,constitute a self-contained unit that is an end in itself, with nointervening time delays imposed by the use - case must be initiated by an actor and seen through tocompletion by an valuemeans that the use - case must achieve a particularbusiness goal.

6 If we cannot find a business-related objective forthe use- case , we should rethink use- case must leave the system in a stable state; it cannot behalf 4 Use-Cases1234567890123456789012345678901 234567890 Use-Cases are goal-oriented. Remembering this is key to using themeffectively. They represent the whatof the system, not the also technology neutral, so they can apply to any application archi-tecture or process. Even if you were to throw out all that UML offers anduse only Use-Cases , a project s requirements would be defined in a muchclearer and more coherent fashion than if Use-Cases were not used. Fig-ure 4-2 identifies the sequence that we follow to arrive at the process of identifying Use-Cases is easier if the event table isgrouped by actor, as in Table 4-1. Often a use- case will be associatedwith only one actor. However, some types of Use-Cases for example,those that provide information such as reports often have more thanone that certain events in the table tend to cluster together, such asthose dealing with order entry.

7 Also some events deal with maintainingan order, as well as inquiring about an existing order. We take these nat-ural groupings and write a short descriptive phrase (one or two words)for each, asking these questions: What do these events have in common? Do these events have the same ultimate goal? If so, what is it?The Process Model67123456789111111111122222222223333 3333334 FeaturesEvent ListEvent TableUse-CasesFIGURE 4-2 Getting to use-cases68 CHAPTER 4 Use-Cases1234567890123456789012345678901 234567890 TABLE 4-1 Event Table with Events Grouped by ActorArrival SubjectVerbObjectFrequency PatternResponseCustomerPlacesOrder1,000/ dayEpisodic Order is edited and saved in Order is validated as to termsand then Order is edited to make thechange and then Order is removed from Order information is ChangesAddress5/weekEpisodic Address is clerkShipping SendsOrder700/dayEpisodic Order is packaged and shipped clerkaccording to the shipping 10/dayEpisodic New inventory is checked 3/weekEpisodic Report is 1/weekEpisodic Interface is added to the PreparesOrder100/dayEpisodic Package is readied for Orders5/dayEpisodic Request is clerk Inquires Past-due 10/dayEpisodic Past-due report is we place each of these descriptive phrases next to an oval (thedesignation for a use- case )

8 , along with the associated actors to produceour first attempt at a use- case diagram, shown in Figure actors are connected to the Use-Cases by arrows, which indicateassociationrelationships. Notice the accounting system actor. Becauseit is an external system and nonhuman, this actor is rendered by theinterface stereotypeand drawn as a box. Stereotypes are discussed inmore detail later in the CHAPTER . For now, think of a stereotype as a cate-gorization or grouping mechanism. Using stereotypes is optional; thereis nothing semantically incorrect about representing this actor as a stickfigure. I consulted on a project whose management took a dim view ofstick figures as part of the deliverables, so we went with the box nota-tion. You can probably guess that this organization had quite a fewother hurdles to clear before it became successful at using also the line with the large triangle arrow connecting the cus-tomer service clerk and order clerk actors.

9 This arrow means that a cus-tomer service clerk is an order clerk, thereby denoting a generalizationThe Process Model69123456789111111111122222222223333 3333334 Order ClerkCustomerService ClerkMaintain OrdersMaintain InventoryProcess OrdersDecision SupportShippingMaintain RelationshipsInvoicingManagerTimeBilling ClerkSupplierPackaging ClerkShipping ClerkCustomer Interface Accounting SystemFIGURE 4-3 Remulak use- case diagramrelationship. That is, the two actors can be substituted for the samething, and they perform the same logical function but happen to bephysically one person (recall from CHAPTER 3 that we should focus onthe role and not on the actor).One last feature to notice is the dashed line from the order clerk tothe customer, which denotes a dependency associationrelationship that is, a relationship in which one actor depends on the other. In thiscase the fact that the arrow points from the order clerk to the customer(rather than vice versa) shows that the order clerk depends on the cus-tomer.

10 Many practitioners would say that the actor involved in pro-cessing an order is the customer. This is debatable because the userinterface will be geared toward the order clerk, not the customer. How-ever, the order clerk is useless without the customer s check consistency, we determine whether any events identifiedduring the Inception phase have not found a home in a use- case . Anythat haven t are out of scope, worded incorrectly, or missing a s a good practice to add a new column to the event table for record-ing which use- case satisfies each is a good time to talk about scope creep. Every project suffersfrom it. If you have experience with one that hasn t, then you have hadthe luxury of wonderful project sponsors, or you aren t telling thetruth, in order to protect the guilty. Keep the following bit of wisdomclose at all times:All requirements originate as features in the project vision.