lab
Acme Video Games is a video game rental company that rents video games for the major gaming consoles (Sony PlayStation, Nintendo Wii, and Xbox 360). Acme has recently decided to expand its distribution by renting games through automated vending machines, similar to the way that Redbox rents DVDs. You have been hired by Acme as a business analyst to help develop the software for the new vending machines.
Each Acme vending machine will be stocked with a selection of popular video games. The machine will have a touchscreen, a credit-card swipe reader, a slot for dispensing rented games, and a second slot for returning games. Each machine is connected to the Internet.
To begin using the machine, a customer touches a button on the screen to select one of two options, Rent a Game or Return a Game.
If the customer chooses Rent a Game, he or she selects the desired game from a list displayed on the screen, swipes a valid credit card, enters his or her zip code, and enters an e-mail address. The vending machine contacts Acme’s bank over its Internet connection and charges the customer’s credit card for a one-night rental fee. If the charge is accepted by the bank, the bank returns an authorization code to the machine. The machine then dispenses the game to the customer and e-mails a receipt to the customer’s e-mail address. The machine transmits a record of the rental, including the customer’s information and the unique ID number of the game disc that was dispensed, to a central computer system at Acme’s headquarters over its Internet connection.
If the customer chooses Return a Game, the screen prompts the customer to insert the game into the return slot. The machine reads the game disc’s ID number from a bar code on the disc, and transmits it to the central computer system at Acme headquarters over its Internet connection. The central computer returns the date and time of the rental and the customer’s information. If the customer kept the game for more than one night, the machine sends an additional rental charge to Acme’s bank over its Internet connection, and receives an authorization code from the bank if the charge was accepted. The machine e-mails a receipt for the returned game to the customer’s e-mail address. The additional rental charges, if any, are noted on this receipt.
Upon completing this lab, you will be able to:
- Create a use case diagram for a simple system or subsystem;
- Write a use case description for a selected use case, including a main success scenario and extensions;
- Identify the principal classes involved in implementing a use case;
- Create a domain model class diagram showing the classes involved in a use case, their attributes, and their relationships, but not detailed methods.
Necessary materials: All materials marked with * are already installed in your lab environment.
- Background information (Scenario/Summary section above)
- Template for use case description (BIS261_W6_iLab_Template.docx; download from iLab Files folder in Doc Sharing)
- Microsoft Visio* for creating use case diagram and class diagram
- Microsoft Word* for creating use case description
Deliverables
You will submit two files in order to complete this lab:
- Use case diagram for Acme video game vending machine (page 1 of Visio file);
- A Word file containing a use case description for the Rent a Game use case (Word file); and
- A Visio file containing two pages: a use case diagram for the Acme vending machine (page 1 noted above), and a domain model class diagram for the Rent a Game use case (page 2).
Grading rubric:
Item | Percentage |
---|---|
Use case diagram | 30% |
Use case description | 40% |
Conceptual class diagram | 30% |
100% |
iLAB STEPS
STEP 1: Review background information
Review the information on Acme’s video game vending machine project given in the Scenario/Summary. This brief description specifies the main requirements for the project. In completing the remaining steps of this iLab, you may need to make reasonable assumptions about additional requirements not stated explicitly in the Scenario/Summary.
As you review the Scenario/Summary, make notes of your answers to the following questions. These notes will not be turned in, but you will use them in completing the remaining steps in this iLab.
- What are the use cases–the major activities that the system performs in response to user requests?
- What are the actors–people who use the system, or other external systems with which this system interacts? TIP: The scope of the system” for your analysis should be only the vending machine itself. Any persons or other systems with which the vending machine interacts, including other systems that it communicates with over a network, should be considered as actors.
- What are the classes–the categories of persons, places, things, or events that need to be represented in the system?
STEP 2: Draw a use case diagram
Based on your answers to the questions in Step 1, use Microsoft Visio to draw a UML use case diagram for the Acme vending machine system. To do so:
- Log in to the Citrix iLab. (For help with logging in, see the iLab page under Course Home.)
- Open the Microsoft Office Applications folder and, from within that folder, launch Microsoft Visio.
- Under Template Categories, select Software and Database. Under Featured Templates, select the UML Model Diagram template. Click the Create button.
- Using the drop-down list in the toolbar, set the zoom level to 100%.
- In the Shapes toolbox, click the UML Use Case heading to expand it.
- Drag a system boundary rectangle from the Shapes toolbox and drop it in the approximate center of the diagram. While the system boundary rectangle is still selected, type Vending Machine” as the name of the system and click outside of the rectangle.
- For each actor that you identified in Step 1, drag an actor shape from the Shapes toolbox onto the diagram. After dropping each actor onto the diagram, type the name of the actor. The name will be displayed under the actor symbol. Position the actors outside of the system boundary rectangle.
- For each use case that you identified in Step 1, drag a use case shape from the Shapes toolbox and drop it on the diagram inside of the system boundary rectangle. To name each use case, right-click on the use case symbol and select Properties, as shown:
In the UML Use Case Properties dialog, enter the name of the use case in the Name box and click OK.
The use case name will be displayed inside of the use case oval.
- For each interaction between an actor and a use case, drag a Communicates line from the Shapes toolbox onto the diagram. Drag one endpoint of the Communicates line onto the actor, dropping it when you see a red outline appear around the actor symbol, as shown:
The red outline appears when Visio has attached the endpoint to the symbol. Drag the other endpoint of the Communicates line onto the use case, dropping it when you see a red outline appear around the use case symbol.
- To remove the unnecessary -End1 and -End2 labels, right-click on the Communicates line and select Shape Display Options, as shown:
In the UML Shape Display Options dialog, under Suppress, check the boxes for First end and Second end. Also, near the bottom of the dialog, check the box labeled Apply to subsequently dropped UML shapes . . . , as shown:
Click OK to close the dialog.
- If any use case on your diagram is included as a common subroutine of other use cases, drag a Uses arrow from the Shapes toolbox and drop it onto the diagram. Connect the arrowhead endpoint of the Uses arrow to the use case that is the common subroutine. Connect the other endpoint of the Uses arrow to the use case that uses the common subroutine.
The following shows a partially completed version of the use case diagram, with one actor and two use cases. Your completed diagram should include at least three use cases and at least three actors.
- Save your completed use case diagram by using the file name LastName_W6_iLab.vsd. Remember that when saving files within the Citrix iLab environment, your local computer’s disk drives will appear with a dollar sign after the drive letter (for example, the C: drive on your local computer will appear as C$).
TIP: Review the video tutorial Creating a Use Case Diagram in Microsoft Visio in the Week 6 Lecture for additional help with creating your use case diagram.
STEP 3: Write a use case description
Write a fully developed use case description for the Rent a Game use case, as follows:
- Download and open the BIS261_W6_iLab_Template.docx file from the iLab Files folder in Doc Sharing;
- Enter your name after Created by. Enter the current date after Date;
- Note that the use case name, Rent a Game, has been filled in for you in the template;
- In the Scenario section, enter a one-sentence overview of what happens in this use case. This should be slightly more detailed and specific than the use case name;
- In the Triggering Event section, briefly describe what happens to initiate this use case;
- In the Brief Description section, summarize the steps that take place when this use case is performed. This should be more detailed than your one-sentence overview in the Scenario section, but not as detailed as the Flow of Events;
- In the Actors section, list the actors that take part in this use case. These are the actors that are connected to this use case by the Communicates lines in your use case diagram;
- In the Related Use Cases section, list other use cases, if any, that are connected to this one in the use case diagram. These include use cases that use this one, and use cases that are used by this one. If there are none, enter none;
- In the Stakeholders section, identify any parties with an interest in the outcome of this use case, other than the actors who directly participate in the use case. These might be, for example, other departments within the company that utilize data generated by this use case. If there are none, enter none;
- In the Preconditions section, describe the state of the system before the use case is performed;
- In the Postconditions section, describe the state of the system after the use case has been performed;
- In the Flow of Events section, list the specific steps involved in performing the normal or usual flow of events in the use case. Assign a sequential number (1, 2, 3, and so on) to each step. List steps performed by an actor in the Actor column, and steps performed by the system in the System column;
- In the Exception Conditions section, identify any errors or other unusual conditions that might occur while performing the use case, and describe what should happen if each one occurs. For each exception condition, identify the step number in the Flow of Events at which the exception condition might occur; and
- Save the completed use case description with the file name LastName_W6_iLab.docx.
STEP 4: Identify classes
Analyze your use case description to identify the major classes that would be involved in implementing the Rent a Game use case. Remember that classes are indicated by important nouns in the use case description that represent persons, places, things, or events that the system must track or manipulate when performing the use case. To identify classes, do the following:
- Carefully read the Rent a Game use case description that you created in Step 3, and as you do so, make a list of the important nouns representing persons, places, things, or events that appear in the description.
- For each noun on your list, ask yourself whether the system needs to store information about or manipulate that person, place, thing, or event in order to perform the use case. For example, the noun button might appear in your use case description, but the system does not need to store information about the button, so you would not need to include a Button class in your list.
- For each noun on the list, ask yourself whether the noun represents an independent person, place, thing, or event needing its own class, or whether it may be an attribute of another person, place, thing, or event. For example, the noun, zip code might appear in your use case description, but the zip code is an attribute of the Customer class and does not need a class of its own.
- For each noun on the list, ask whether it is a synonym of another noun that also appears on the list. Only one class should be used to represent a person, place, thing, or event, even if it is sometimes referred to by different words. For example, you might have used the words customer and client in your use case description. If these both refer to the same person, then only one class named Customer should be used to represent both items.
STEP 5: Draw class diagram
Based on your final list of classes from Step 4, draw a domain model class diagram showing the classes involved in the Rent a Game use case. Your diagram should include at least five classes, at least two attributes for each class, and class relationships with multiplicities. To create this diagram:
- If necessary, log in to the Citrix iLab, open the Microsoft Applications folder, launch Microsoft Visio, and open the LastName_W6_iLab.vsd file that you created in Step 2;
- Right-click on the sheet tab labeled Use Case-1 at the bottom of the window, and select Insert Page, as shown:
- In the Page Setup dialog, enter Class Diagram-2 in the Name box as shown:
Click OK to close the dialog.
- Using the drop-down list in the toolbar, set the zoom level to 100%.
- In the Shapes toolbox, click the UML Static Structure heading to expand it.
- For each class that you identified in Step 4, drag a class symbol from the Shapes toolbox onto the diagram. After dropping each class onto the diagram, while the class is still selected, type the name of the class. The class name should appear in the top third of the class symbol. Click outside of the class shape to deselect it.
- Right-click on each class and select Properties. In the UML Class Properties dialog, under Categories on the left, select Attributes. In the Attributes grid on the right, click in the first blank cell in the Attribute column, enter the name of an attribute, and press Enter. You should enter at least two attributes for each class.
Click OK to close the dialog after entering your attributes. You should see the attributes displayed in the middle third of the class symbol, as shown:
- For each relationship between two classes, drag a binary association line from the Shapes toolbox onto the diagram. Connect the endpoints of the binary association line to the related classes in the same way that you connected the endpoints of the Communicates lines to actors and use cases in Step 2.
- To remove the end labels from the binary association lines, right-click on the binary association line and select Shape Display Options. In the UML Shape Display Options dialog, under End options, uncheck the boxes for First end name and Second end name. Ensure that the box for End multiplicities is checked. Near the bottom of the dialog, check the box for Apply to subsequently dropped UML shapes . . . Click OK.
- To designate multiplicities for each relationship, right-click on the binary association line and select Properties. In the UML Association Properties dialog, select Association under Categories on the left. In the Association Ends grid on the right, click on each cell in the Multiplicity column and use the drop-down list to select the desired multiplicity, as shown:
After setting the multiplicity for each end, click OK to close the dialog.
The following shows a partially completed class diagram with two classes, two attributes for each class, and a binary association between the classes with appropriate multiplicities. Your completed class diagram should include at least five classes, with at least two attributes per class and all necessary association lines and multiplicities.
- Save your changes to the Visio file LastName_W6_iLab.vsd, which now contains your use case diagram on page 1 and your class diagram on page 2.
TIP: Review the video tutorial Creating a Class Diagram with Microsoft Visio in the Week 6 Lecture for additional help with creating your class diagram.
STEP 6: Save and submit
Submit the following two files to the Dropbox for this week’s iLab assignment.
- The Visio drawing file LastName_W6_iLab.vsd containing your use case diagram and class diagram; and
- The Word document LastName_W6_iLab.docx containing your use case description.