Hour 6

HOUR 6

Introducing Use Cases

What Youll Learn in This Hour:. What use cases are. The ideas behind creating, including, and extending use cases. How to start a use case analysis

In the past three hours, youve dealt with diagrams that provide a static view of theclasses in a system. Youre going to ultimately move into diagrams that provide adynamic view and show how the system and its classes change over time. The staticview helps an analyst communicate with a client. The dynamic view, as youll see,helps an analyst communicate with a team of developers, and helps the developerscreate programs.

The client and the development team make up an important set of stakeholders in asystem. One equally important part of the picture is missing, howeverthe user.Neither the static view nor the dynamic view shows the systems behavior from theusers point of view. Understanding that point of view is key to building systems thatare both useful and usablethat is, that meet requirements and are easy (and evenfun) to work with.

Modeling a system from a users point of view is the job of the use case. In this houryoull learn all about what use cases are and what they do. In the next hour youlllearn how to use the UMLs use case diagram to visualize a use case.

Use Cases: What They AreI recently bought a digital camera. When I was shopping for it, I encountered a widevariety of possibilities. How did I decide which one to buy? I asked myself exactlywhat I wanted to do with a camera. Did I want extreme portability or did I want alarger camera with a bigger lens? Would I be taking distance shots? Did I want to

92 Hour 6

take pictures and post them on the Web? Did I primarily want to make prints? Ifso, how large? Did I want to make short movies? With sound?

We all go through a process like this when we make a non-impulse purchase.What were doing is a form of use case analysis: Were asking ourselves howwere going to use the product or system were about to shell out good money for,so we can settle on something that meets our requirements. The important thingis to know what those requirements are.

This kind of process is particularly crucial for the analysis phase of system devel-opment. How users will use a system drives the way you design and build it.

The use case is a construct that helps analysts work with users to determine sys-tem usage. A collection of use cases depicts a system in terms of what users intendto do with it.

Think of a use case as a collection of scenarios about system use. Each scenariodescribes a sequence of events. Each sequence is initiated by a person, anothersystem, a piece of hardware, or by the passage of time. Entities that initiatesequences are called actors. The result of the sequence has to be something of useeither to the actor who initiated it or to another actor.

Use Cases: Why Theyre ImportantJust as the class diagram is a great way to stimulate a client to talk about a sys-tem from his or her viewpoint, the use case is an excellent tool for stimulatingpotential users to talk about a system from their own viewpoints. Its not alwayseasy for users to articulate how they intend to use a system. Because traditionalsystem development was often a haphazard process that was short on up-frontanalysis, users are sometimes stunned when anyone asks for their input.

The idea is to get system users involved in the early stages of system analysis anddesign. This increases the likelihood that the system ultimately becomes a boon to thepeople its supposed to helpinstead of a monument to clever cutting-edge comput-ing concepts that business users find incomprehensible and impossible to work with.

An Example: The Soda MachineSuppose youre starting out to design a soda machine. In order to get the userspoint of view, you interview a number of potential users as to how theyll interactwith the machine.

Introducing Use Cases 93

Because the main function of a soda machine is to allow a customer to buy acan of soda, its likely the users will quickly tell you that youre concerned witha set of scenariosa use case, in other wordsthat you could label Buysoda. Lets examine each possible scenario in this use case. In normal systemdevelopment, remember, these scenarios would emerge through conversationswith users.

FIGURE 6.1A use case specifies a set ofscenarios foraccomplishingsomething usefulfor an actor. In thisexample, one usecase is Buy soda.

The Buy Soda Use CaseThe actor in this use case is a customer who wants to purchase a can of soda. Thecustomer initiates the scenario by inserting money into the machine. He or shethen makes a selection. If everything goes smoothly, the machine has at least onecan of the selected soda in stock, and presents a cold can of the soda to the cus-tomer.

In addition to the sequence of steps, other aspects of the scenario deserve consid-eration. What preconditions motivate the customer to initiate this scenario in theBuy soda use case? Thirst is the most obvious one. What postconditions resultas a consequence of the scenarios steps? Again, the obvious one is that the cus-tomer has a soda.

Is the scenario I described the only possible one for Buy soda? Others immediate-ly come to mind. Its possible that the machine is out of the soda the customerwants. Its possible that the customer doesnt have the exact amount of money thesoda costs. How should you design the soda machine to handle these scenarios?

Lets turn to the out-of-soda scenario, another sequence of steps in the Buy sodause case. Think of it as an alternative path through the use case. The customerinitiates the use case by inserting money into the machine. He or she then makes

94 Hour 6

a selection. The machine does not have at least one can of the selected soda, so itpresents a message to the customer, saying its out of that brand. Ideally, the mes-sage should prompt the customer to make another selection. The machine shouldalso offer the customer the option of getting his or her money back. At this pointthe customer selects another brand and the machine delivers (if its not sold out ofthe new selection), or takes the option of receiving the money. The precondition isa thirsty customer. The postcondition is either a can of soda or the returnedmoney.

Another Out-of-Soda ScenarioOf course, another out-of-soda scenario is possible: The out of brand messagecould display as soon as the machines stock disappears and remain on until themachine is resupplied. In that case, the user might not insert money in the firstplace. The client for whom youre designing the machine might prefer the first sce-nario: If the customer has already inserted money, the tendency might be to makeanother selection rather than to ask the machine to return the money.

Now lets look at the incorrect-amount-of-money scenario. Once again, the cus-tomer initiates the use case in the usual way, and then makes a selection. Letsassume the machine has the selection in stock. If the machine has a reserve ofappropriate change on hand, it returns the difference and delivers the soda. If themachine doesnt have a reserve of change, it returns the money and presents amessage that prompts the user for correct change. The precondition is the usualone. The postcondition is either a can of soda along with change, or the returnedmoney that was originally deposited.

Another possibility is that as soon as the machines change reserve is depleted, amessage appears informing potential customers that correct change is required.The message would remain visible until the machines reserve is resupplied.

Additional Use CasesYouve examined the soda machine from the viewpoint of one user: the customer.Other users enter the picture as well. A supplier has to restock the machine,(Figure 6.2) and a collector (possibly the same person as the supplier) has to col-lect the accumulated money from the machine (Figure 6.3). This tells us weshould create at least two more use cases, Restock and Collect money, whosedetails emerge through interviews with suppliers and collectors.

By theWay


Consider the Restock use case. The supplier initiates this use case because someinterval (say, two weeks) has passed. The suppliers representative unsecures themachine (probably by unlocking a lock, but that gets into implementation), pullsopen the front of the machine, and fills each brands compartment to capacity.

FIGURE 6.2Restocking a sodamachine is animportant usecase.

FIGURE 6.3Collecting themoney from a sodamachine is anotherimportant usecase.

96 Hour 6

The representative also refills the change reserve. The representative then closesthe front of the machine and secures it. The precondition is the passage of theinterval, the postcondition is that the supplier has a new set of potential sales.

For the Collect money use case, the collector also initiates because an intervalhas passed. He or she would follow the same sequence of steps as in Restock tounsecure the machine and pull open the front. The collector then removes themoney from the machine, and follows the Restock steps of closing and securingthe machine. The precondition is the passage of the interval, and the postcondi-tion is the money in the hands of the collector.

Notice that when we derive a use case, we dont worry about how to implementit. In our example were not concerned with the insides of the soda machine. Wedont care about how the refrigeration mechanism works, or how the machinekeeps track of its money. Were just trying to see how the soda machine will lookto someone who has to use it.

The objective is to derive a collection of use cases that we will ultimately show tothe people who will design the soda machine and the people who will build it. Tothe extent our use cases reflect what customers, collectors, and suppliers want, theresult will be a machine that all these groups can easily use.

Including a Use CaseIn the Restock use case and the Collect use case, youll note some commonsteps. Both begin with unsecuring the machine and pulling it open, both endwith closing the machine and securing it. Can we eliminate the duplication ofsteps from use case to use case?

We can. The way to do it is to take each sequence of common steps and form anadditional use case from each one. Lets combine the unsecure and pull opensteps into a use case called Expose the inside and the close machine andsecure steps into a use case called Unexpose the inside. (OK. Ive invented aword hereunexpose. Hide or conceal just didnt seem appropriate!) Figure 6.4illustrates these combinations of steps.

With these new use cases in hand, the Restock use case starts off with theExpose the inside use case. The suppliers representative then goes through thesteps as before and concludes with the Unexpose the inside use case. Similarly,the Collect use case starts off with the Expose the inside use case, proceeds asbefore, and finishes with the Unexpose the inside use case.


As you can see, Restock and Collect include the new use cases. Accordingly,this technique of reusing a use case is referred to as including a use case.

More on IncludingEarly versions of the UML referred to including a use case as using a use case. Youmight still see the old way in print. The term including has two advantages. First, itsclearer: The steps in one use case include the steps of another. Second, it avoidsthe potential confusion of putting using near the use in use case. That way, we wonthave to say we promote reuse by using a use case.

Extending a Use CaseIts possible to reuse a use case in a way other than inclusion. Sometimes we cre-ate a new use case by adding some steps to an existing use case.

Lets go back to the Restock use case. Before putting new cans of soda into themachine, suppose the suppliers representative notes the brands that sold welland the brands that did not. Instead of simply restocking all the brands, the repmight pull out the brands that havent sold well and replace them with cans ofthe brands that have proven to be more popular. He or she would then also haveto indicate on the front of the machine the new assortment of available brands.

Expose the inside

Unexpose the inside

FIGURE 6.4You can combinesome of the stepsthat make up a usecase. The combination ofsteps constitutesan additional usecase.

By theWay

98 Hour 6

If we add these steps to Restock well have a new use case that we can callRestock according to sales. This new use case is an extension of the original,and this technique is called extending a use case.

Starting a Use Case AnalysisIn our example we jumped right into use cases and focused on a few of them. Inthe real world, you usually follow a set of procedures when you start a use caseanalysis.

You begin with the client interviews (and interviews with experts) that lead to theinitial class diagrams we discussed in Hour 3, Working with Object-Orientation.This gives you some idea of the area youre working in and a familiarity with theterms youll be using. You then have a basis for talking with users.

You interview users (preferably in a group) and ask them to tell you everythingthey would do with the system youre getting ready to design. Their answers forma set of candidate use cases. Next, its important to briefly describe each use case.You also have to derive a list of all the actors who will initiate and benefit fromthe use cases. As you get more into this phase, youll increase your ability tospeak to the users in their language.

Use cases crop up in several phases of the development process. They help withthe design of a systems user interface, they help developers make programmingchoices, and they provide the basis for testing the newly constructed system.

To go any further with use case analysis youre going to have to apply the UML,and thats the subject for the next hour.

SummaryThe use case is a construct for describing how a system will look to potential users.Its a collection of scenarios initiated by an entity called an actor (a person, a pieceof hardware, a passage of time, or another system). A use case should result insomething of value for either the actor who initiated it or for another actor.

Its possible to reuse use cases. One way (inclusion) is to use the steps from oneuse case as part of the sequence of steps in another use case. Another way(extension) is to create a new use case by adding steps to an existing use case.


Interviewing users is the best technique for deriving use cases. When deriving ause case, its important to note the preconditions for initiating the use case, andthe postconditions that result as a consequence of the use case.

You should interview users after you interview clients and generate a list of candi-date classes. This will give you a foundation in the terminology that youll use totalk with the users. Its a good idea to interview a group of users. The objective isto derive a list of candidate use cases and all possible actors.

100 Hour 6

Q&AQ. Why do we really need the use case concept? Cant we just ask users

what they want to see in a system and leave it at that?

A. Not really. We have to add structure to what the users tell us, and use casesprovide the structure. The structure comes in handy when you have to takethe results of your interviews with users and communicate those results toclients and developers.

Q. When we talk to users, are we constrained to just listing the use casesthey tell us about?

A. Definitely not. In fact, an important part of the process is to build on whatusers tell you and try to discover use cases they might not have thoughtabout.

Q. How difficult is it to derive use cases?

A. In my experience, listing the use casesat least the high-level onesisntall that difficult. Some difficulty arises when youre delving into each oneand trying to get the users to list the steps in each scenario. When yourebuilding a system that replaces an existing way of doing things, users typi-cally know these steps so well and have used them so often they find it diffi-cult to articulate them. Its a good idea to have a panel of users, because thediscussion in the group typically brings out ideas that an individual usermight have trouble expressing.

WorkshopThis hour was theory rather than UML. For this workshop, the objective is tounderstand the theoretical concepts and apply them in several contexts. Thepractice will firm up the concepts for you in advance of the next hour when youlllearn how to visualize them in the UML. The answers appear in Appendix A,Quiz Answers.

Quiz1. What do you call the entity that initiates a use case?

2. What is meant by including a use case?

3. What is meant by extending a use case?

4. Is a use case the same as a scenario?


Exercises1. Think of something you just purchased where you faced an array of choices.

What use cases were you thinking of when you made your decision?

2. List the use cases associated with a home entertainment center.

3. For our soda machine example, create another use case that includes theExpose the inside and the Unexpose the inside use cases.

4. Use cases can help you analyze a business as well as a system. Consider acomputer superstore that sells hardware, peripherals, and software. Who arethe actors? What are some of the major use cases? What are some scenarioswithin each use case?

HOUR 7

Working with Use CaseDiagrams

What Youll Learn in This Hour:. How to represent a use case model. How to visualize relationships among use cases. How to create and apply use case models

The use case is a powerful concept for helping an analyst understand how a systemshould behave. It helps you gather requirements from the users point of view. Inthis hour, youll learn how to visualize the use case concepts you learned in the lasthour.

As powerful as the use case concept is, use cases become even more powerful whenyou use the UML to visualize them. Visualization allows you to show use cases tousers so they can give you additional information. Its a fact of life that users oftenknow more than they can articulate: The use case helps break the ice. Also, a visualrepresentation allows you to combine use case diagrams with other kinds of dia-grams.

One of the objectives of the system analysis process is to generate a collection of usecases. The idea is to be able to catalog and reference this collection, which serves asthe users view of the system. When its time to upgrade the system, the use case cat-alog serves as a basis for gathering the requirements of the upgrade.

Representing a Use Case ModelAn actor initiates a use case, and an actor (possibly the initiator, but not necessarily)receives something of value from the use case. The graphic representation is

104 Hour 7

straightforward: An ellipse represents a use case, and a stick figure represents anactor. The initiating actor is on the left of the use case, and the receiving actor ison the right. (Many modelers omit the receiving actor, and the UML 2.0 specifica-tion doesnt mention it.) The actors name appears just below the actor. The nameof the use case appears either inside the ellipse or just below it. An associationline connects an actor to the use case, and represents communication between theactor and the use case. The association line is solid, like the line that connectsassociated classes.

One of the benefits of use case analysis is that it shows the boundary between thesystem and the outside world. Actors are typically outside the system, whereas usecases are inside. You use a rectangle (with the name of the system somewhereinside) to represent the system boundary. The rectangle encloses the systems usecases.

The actors, use cases, and interconnecting lines make up a use case model.Figure 7.1 shows the symbols.

System

Use case

Actor Actor

FIGURE 7.1In a use casemodel, a stick figure representsan actor, an ellipserepresents a usecase, and an association linerepresents communicationbetween the actorand the use case.

The Soda Machine RevisitedLets apply the symbols to the example from the previous hour. As youll recall,you developed use cases for a soda machine. The Buy soda use case sits insidethe system along with Restock and Collect. The actors are Customer,Suppliers Representative, and Collector. Figure 7.2 shows a UML use case modelfor the soda machine.

Working with Use Case Diagrams 105

Tracking the Steps in the ScenariosEach use case is a collection of scenarios, and each scenario is a sequence of steps.As you can see, those steps do not appear on the diagram. Theyre not in notesattached to the use cases. Although the UML doesnt prohibit this, clarity is key increating any diagram and attaching notes to every use case would make the dia-gram too busy. How and where do you keep track of the steps?

Your use case diagrams will usually be part of a design document that the clientand the development team refer to. Each diagram will have its own page. Eachscenario of each use case will also have its own page, listing in text form

. The actor who initiates the use case

. Assumptions for the use case

. Preconditions for the use case

. Steps in the scenario

. Postconditions when the scenario is complete

. The actor who benefits from the use case

You can also include a brief, one-sentence description of the scenario. Note thatthis text page is outside the boundaries of the UML. Thus, the UML doesnt specifyany particular format for this.

Buy soda

Customer Customer

Restock

Supplier'sRepresentative


Collect

Collector Collector

Soda Machine FIGURE 7.2A use case modelof the sodamachine from Hour 6.

106 Hour 7

Hour 6, Introducing Use Cases, presented some alternative scenarios for theBuy soda use case. In your description, you can either list these scenarios sepa-rately (Out-of-brand and Incorrect change), or you can consider them excep-tions to the first scenario in the use case. Exactly how you do all this is up to you,your client, and the users.

Another PossibilityTo show the steps in a scenario, another possibility is to use a UML activity diagram(discussed in Hour 11, Working with Activity Diagrams).

Visualizing Relationships Among UseCasesThe example in Hour 6 also showed two ways that use cases can relate to oneanother. One way, inclusion, enables you to reuse one use cases steps insideanother use case. The other way, extension, allows you to create a new use caseby adding steps to an existing use case.

Two other kinds of relationships are generalization and grouping. As is the casefor classes, generalization has one use case inheriting from another. Grouping isa simple way of organizing a set of use cases.

InclusionLets examine the Restock and Collect use cases from the Hour 6 example.Both begin with unsecuring the machine and pulling it open, and both end withclosing the machine and securing it. The Expose the inside use case was createdto capture the first pair of steps, and the Unexpose the inside use case to cap-ture the second. Both Restock and Collect include these two use cases.

To represent inclusion, you use the symbol you used for dependency betweenclassesa dashed line connecting the classes with an arrowhead pointing to thedepended-on class. Near the line, you add the keyword include. Figure 7.3shows the inclusion relationship in the use case model of the soda machine.

In the text notation that tracks the steps in the sequence, you indicate the includeduse cases. The first step in the Restock use case would be include (expose theinside).

By theWay


ExtensionHour 6 showed that the Restock use case could be the basis of another use case:Restock according to sales. Instead of just restocking the soda machine so thatall brands end up with the same number of cans, the suppliers representativecould take note of the brands that sold well and the brands that did not, andrestock accordingly. The new use case is said to extend the original one because itadds new steps to the sequence in the original use case, also called the base usecase.

Extension can only take place at specific designated points within the base usecases sequence. These points are called, appropriately, extension points. In theRestock use case, the new steps (noting the sales and designating the appropri-ate refills) would occur before the suppliers representative opened the machineand was ready to fill the compartments of the soda brands. For this example, theextension point is before filling the compartments.

Like inclusion, you visualize extension with a dependency line (dashed line andarrowhead) along with a keyword. In this case the keyword is extend. Withinthe base use case, the extension point appears in a compartment named

Buy soda

Customer Customer

Restock



Collect

Collector Collector

Soda Machine

Expose the inside

Unexpose the inside

Expose the inside

Unexpose the inside

include

include

include

include

FIGURE 7.3The soda machineuse case modelwith inclusion.

108 Hour 7

extension point (or extension points if you have more than one) below thename of the use case. Figure 7.4 shows the extension relationship for Restockand Restock according to sales along with the inclusion relationships forRestock and Collect.

Expose the inside

Unexpose the inside

Restock

Extension PointBefore filling thecompartments

extend

include

include

Restock accordingto sales

FIGURE 7.4A use case dia-gram showingextension andinclusion.

Its important to be aware that the locations of the use cases in the use case dia-gram dont signify anything. In Figure 7.4, for example, Expose the inside isabove Unexpose the inside. This does not mean that Expose the inside pre-cedes Unexpose the inside. Common sense tells you that it does, but the usecase diagram doesnt take that into account.

Some have tried to number the use cases in order to show their order. This is waymore trouble than its worth, particularly when a use case is included in severalothers. If its included in Use Case 3 and Use Case 4, is it Use Case 3.1? Or is it4.1? Suppose its the first included use case in Use Case 3, but the second in UseCase 4. Then what?

Its best to understand that the intent of the use case diagram is to show what theuse cases are without specifying their order of occurrence. (In that spirit, see theaccompanying sidebar Extension, Inclusion, and Confusion.)


Extension, Inclusion, and ConfusionIn my experience, people who are used to modeling process flows (from pre-UMLtimes) are sometimes confused by the direction of dependency arrows. The confu-sion often emerges when it comes to modeling extension and inclusion of usecases. This happens because process-flow veterans are used to seeing arrows thatdenote sequences of operations or activities: The first one in a sequence connectswith the second one via an arrow that points from the first to the second.

Thus in a use case diagram that shows Use Case A including Use Case B, their ten-dency is to think that Use Case A takes place first, followed immediately by UseCase B. Many timesby the nature of inclusionthe opposite turns out to be true.

The key is to bear in mind that a dependency arrow doesnt specify the direction ofa process. Instead, it specifies the direction of a relationship. A dependency arrowthat starts at Use Case A and ends at Use Case B means that A depends on B, notthat A precedes B.

GeneralizationClasses can inherit from one another, and so can use cases. In use case inheri-tance, the child use case inherits behavior and meaning from the parent andadds its own behavior. You can apply the child wherever you apply the parent.

Suppose youre modeling a soda machine that allows a customer to buy either acan of soda or a cup of soda. In that case, Buy soda would be a parent use case,and Buy a can of soda and Buy a cup of soda would be child use cases. Youmodel generalization of use cases the same way you model generalization ofclasseswith a solid line that has an open triangle pointing at the parent, as inFigure 7.5.

By theWay

Buy soda

Buy a can of soda Buy a cup of soda

FIGURE 7.5The generalizationrelationship worksfor use cases aswell as for classes.

110 Hour 7

The generalization relationship can exist between actors, too. You might haverepresented both the suppliers representative and the collector as agents of thesupplier. If you rename the representative as the Restocker, the Restocker andCollector are both children of the Supplier Agent, as Figure 7.6 shows.

Supplier's Agent

Restocker Collector

FIGURE 7.6Like classes anduse cases, actorscan be in a general-ization relationship.

GroupingIn some use case diagrams, you might have a multitude of use cases and youllwant to organize them. This could happen when a system consists of a number ofsubsystems. Another possibility is when youre interviewing users in order to gatherrequirements for a system. Each requirement would be represented as a separateuse case. Youll need some way of categorizing the requirements.

The most straightforward way to organize is to group related use cases into apackage. A package, remember, appears as a tabbed folder. The grouped usecases appear inside the folder.

Use Case Diagrams in the AnalysisProcessGiven the example you worked with, you dived right in and applied the use casesymbols. Now its time to step back and put use cases in the context of an analy-sis effort.

Client interviews should start the process. These interviews will yield class dia-grams that serve as the foundation for your knowledge of the systems domain(the area in which it will solve problems). After you know the general terminologyof the clients area, youre ready to start talking to users.


Interviews with users begin in the terminology of the domain but should thenshift into the terminology of the users. The initial results of the interviews shouldreveal actors and high-level use cases that describe functional requirements ingeneral terms. This information provides the boundaries and scope of the system.

Later interviews with users delve into these requirements more closely, resulting inuse case models that show the scenarios and sequences in detail. This mightresult in additional use cases that satisfy inclusion and extension relationships. Inthis phase its important to rely on your understanding of the domain (from theclass diagrams derived from client interviews). If you dont understand thedomain well, you might create too many use cases and too much detaila situa-tion that could greatly impede design and development.

Applying Use Case Models: An ExampleTo further your understanding of use case models and how to apply them, letstake a look at a more complex example than a soda machine. Suppose you haveto design a local area network (LAN) for a consulting firm, and you have to fig-ure out the functionality to build into the LAN. How do you start?

Exactly What Is a LAN?A LAN is a communication network that an organization uses over a limited dis-tance. It allows users to share resources and information.

Understanding the DomainBegin with client interviews to create a class diagram that reflects what life is likein the world of consulting. The class diagram might include these classes:Consultant, Client, Project, Proposal, Data, and Report. Figure 7.7 shows whatthe diagram might look like.

Understanding the UsersNow that the domain is in hand, turn your attention to the users, because theobjective is to figure out the kinds of functionality to build into the system.

In the real world, you would interview users. For this example youll base yourideas on some general knowledge about LANs and about the domain. Bear in

By theWay

112 Hour 7

mind, however, that in real-world systems analysis, nothing can substitute forinterviews with real people.

One group of users will be consultants. Another will be clerical staff. Other poten-tial users include corporate officers, marketers, network administrators, officemanagers, and project managers. (Can you think of any others?)

At this point, its helpful to show the users in a generalization hierarchy, as inFigure 7.8.

Consultant

Client

Report

Project

Proposal

Data

works on1 1..*

1writes

1..*1..* leads to1

serves

1..*

1

1

reads1 1..*

1is presented to appear in

appear in1 1..*1..* 1..*

FIGURE 7.7A class diagram forthe consultingworld.

Employee

CorporateOfficer

Manager Consultant ClericalStaff

OfficeManager

ProjectManager

NetworkAdministrator

FIGURE 7.8The hierarchy ofusers who willinteract with theLAN.


Understanding the Use CasesWhat about the use cases? Here are some possibilities: Provide security levels,Create a proposal, Store a proposal, Use e-mail, Share database informa-tion, Perform accounting, Connect to the LAN from outside the LAN,Connect to the Internet, Share database information, Catalog proposals,Use prior proposals, and Share printers. Based on this information, Figure 7.9shows the high-level use case diagram that we build.

This set of use cases constitutes the functional requirements for the LAN.

Drilling DownLets elaborate on one of the high-level use cases and build a use case model. Oneextremely important activity in a consulting firm is writing proposals, so letsexamine the Create a proposal use case.

Interviews with consultants would probably tell you that a number of steps areinvolved in this use case. First of all, the initiating actor is a consultant. The con-sultant has to log on to the LAN and be verified as a valid user. Then he or shehas to use office suite software (word processing, spreadsheet, and graphics) towrite the proposal. In the process, the consultant might reuse portions of priorproposals. The consulting firm might have a policy that one corporate officer andtwo other consultants review a proposal before it goes to a client. To satisfy thispolicy, the consultant stores the proposal in a central repository accessible to theLAN and e-mails the three reviewers with a message telling them that the propos-al is ready and informing them of its location. After receiving feedback and mak-ing necessary modifications (again, using the office suite software), the consultantprints out the proposal and mails it to the client. When everythings finished, theconsultant logs off the network. The consultant has completed a proposal, and isthe actor who benefits from the use case.

Business LogicWhen an interview reveals something like that three reviewers policy I just men-tioned, take careful note. It means that youre starting to hear about a companysbusiness logicits set of rules for how it conducts itself. The more business logicyou can find out, the better off youll be as an analyst. Youll understand your clientscorporate culture, and youll be better able to understand organizational needs.

By theWay

114 Hour 7

From the preceding sequence, its clear some of the steps will be repeated fromone use case to another, and thus lead to other (possibly included) use cases youmight not have thought of before. Logging on and getting verified are two stepsthat numerous use cases can include. For this reason, youd create a Verify user

CorporateOfficer

OfficeManager

ProjectManager

Consultant

NetworkAdministrator

ClericalStaff

Connectfrom

outsideProvidesecurity levels

Create proposals

Store proposals Use

e-mail

Sharedatabaseinfo Catalog

proposals

Use priorproposals

ConnecttoInternet Share

printers

LANFIGURE 7.9A high-level usecase diagram of aLAN for a consulting firm.


use case that Create a proposal includes. Two other included use cases are Useoffice suite software and Log off the network.

Additional thought about the proposal process might make you realize that theproposals written for new clients differ from the proposals written for existingclients. In fact, new-client proposals probably provide promotional informationabout the firm. This information usually precedes the statement of the problem.With existing clients, its not necessary to send that kind of information. Thus,another new use case, Create a proposal for a new client extends Create a pro-posal.

Figure 7.10 shows the use case diagram that results from this analysis of theCreate a proposal use case.

Verify user

Log off the network

Use office suitesoftware

Create a proposal

Extension PointPrior to problem

statement

extend

include

include

include

Create a proposal fora new client

FIGURE 7.10The Create a pro-posal use case inthe LAN for a con-sulting firm.

This example brings home an important pointa point that was stressed before:The use case analysis describes the behavior of a system. It doesnt touch theimplementation. This is particularly important here because the design of a LANis far beyond the scope of this book!

Taking Stock of Where We AreThis is a good time to look at the overall structure of the UML because youvegone through two of its major aspectsobject orientation and use case analysis.Youve seen their foundations and symbols, and youve explored some applica-tions.

116 Hour 7

In Hours 27, you worked with

Classes

Objects

Interfaces

Use cases

Actors

Associations

Generalizations

Dependencies

Realizations

Aggregations

Composites

Stereotypes

Constraints

Notes

Packages

Extensions

Inclusions

Lets try to partition this set of items into categories.

Structural ElementsClasses, objects, actors, interfaces, and use cases are five of the structural elementsin the UML. Although they have a number of differences (which, as an exercise,you ought to enumerate), they are similar in that they represent either physicalor conceptual parts of a model. As you proceed through Part I, youll encounteradditional structural elements.

RelationshipsAssociations, generalizations, dependencies, aggregations, composites, and real-izations are the relationships in the UML. (Inclusion and extension are two kindsof dependencies.) Without relationships, UML models would just be lists of struc-tural elements. The relationships connect those elements and thereby connect themodels to reality.


GroupingThe package is the only grouping element in the UML. It allows you to organizethe structural elements in a model. A package can hold any kind of structural ele-ment and can hold many different kinds at once.

AnnotationThe note is the UMLs annotation element. Notes enable you to attach constraints,comments, requirements, and explanatory graphics to your models.

ExtensionStereotypes and constraints are two constructs the UML provides for extending thelanguage. They allow you to create new elements out of existing ones, so that youcan adequately model the slice of reality your system will play in.

. . . And MoreIn addition to structural elements, relationships, grouping, annotation, andextension, the UML has another categorybehavioral elements. These elementsshow how parts of a model (such as objects) change over time. You havent dealtwith these yet, but you will learn about one in the next hour.

The Big PictureNow you have an idea of how the UML is organized. Figure 7.11 visualizes thisorganization for you. As you go through the remaining hours in Part I, keep thisorganization in mind. Youll keep adding to it as you go along, and this big pic-ture will show you where to add the new knowledge you acquire.

SummaryThe use case is a powerful tool for gathering functional requirements. Use casediagrams add still more power: Because they visualize use cases, they facilitatecommunication between analysts and users as well as between analysts andclients. In a use case diagram, the symbol for a use case is an ellipse. The symbolfor an actor is a stick figure. An association line joins an actor to a use case. Theuse cases are usually inside a rectangle that represents the system boundary.

118 Hour 7

Inclusion is represented by a dependency line with the keyword includes.Extension is represented by a dependency line with the keyword extends. Twoother relationships between use cases are generalization, in which one use caseinherits the meaning and behaviors of another, and grouping, which organizes aset of use cases. Generalization is represented by the same generalization line thatshows inheritance among classes. Grouping is represented by the package icon.

Use case diagrams figure heavily into the analysis process. Begin with client inter-views that yield class diagrams. The class diagrams provide a foundation forinterviewing users. User interviews result in a high-level use case diagram thatshows the functional requirements of the system. To create use case models, drilldown into each high-level use case. The resulting use case diagrams provide thefoundation for design and development.

Object orientation and use cases are the two heavyweight concepts behind theUML. Now that youve seen them, youre ready for the big picture of the UML.The elements youve learned about in Hours 27 fall into these categories: struc-

Use case

Class

Structural Elements

Relationships

Grouping Extension

Stereotype{Constraint}

Annotation

Interface

Association

Generalization

Dependency

Realization

Package

Note

Actor

FIGURE 7.11The organization ofthe UML, in termsof the elementsyouve dealt withthus far.


tural elements, relationships, organization, annotation, and extension. In thenext hour, youll learn about an element in the remaining category: behavioralelements. Keeping this big picture in mind will help you as you learn more aboutthe UML.

120 Hour 7

Q&AQ. I noticed that in the high-level use case diagram, you dont show associa-

tions between the actors and the use cases. Why is that?

A. The high-level use case diagram emerges at the early stages of interviewswith users. Its still more or less a brainstorming exercise at that point, andthe objective is to find the overall requirements, scope, and boundaries of thesystem. The associations make more sense when subsequent client interviewsget you deeper into each requirement and use case models take shape.

Q. You mentioned business logic in connection with the use case analysis.Is this the only part of the analysis process that yields business logic?

A. Not necessarily. You have to be alert to business logicrelated informationthroughout the process.

Q. Why is it important to have that big picture of the UML? Cant I justknow when to use each type of diagram?

A. If you understand the organization of the UML, youll be able to handle sit-uations you havent encountered before. Youll be able to recognize whenan existing UML element wont do the job, and youll know how to con-struct a new one. Youll also know how to create a hybrid diagram (a dia-gram that encompasses a diverse set of UML elements) if it turns out to bethe only way to clearly present a model.

WorkshopIn this workshop, youll continue with the knowledge you gained in Hour 6, usingit as a foundation for the knowledge from this hour. The objective is to use yournew knowledge to visualize use cases and their relationships. The answers appearin Appendix A, Quiz Answers.

Quiz1. Name two advantages to visualizing a use case.

2. Describe generalization and grouping, the relationships among use casesthat you learned about in this hour. Name two situations in which youwould group use cases.

3. What are the similarities between classes and use cases? What are the differences?

4. How do you model inclusion and extension?


Exercises1. Sketch the diagram of a use case model for a TV remote control. Be sure to

include all the functions of the remote as use cases for your model.

2. In the fourth exercise in Hour 6, you listed the actors and use cases for acomputer superstore. This time, draw a high-level use case diagram basedon the work you did for that exercise. Then create a use case model for atleast one of the high-level use cases. In your work, try to incorporate theincludes or extends relationships.

3. Consider what happens when you go shopping for groceries and othernecessities in a supermarket. Create the concept for a device that eliminatessome of the annoyances associated with this experience and model the usecases for that device. In your set of use cases, use inclusion, extension, andgeneralization wherever theyre appropriate.

Documents

Hour 6