1 Purpose

The purpose of this assignment is to help you acquire (and demonstrate that you have acquired) the knowledge and skills required to create UML Activity Diagrams using the required UML modeling tool (see the course "Tools" page).

2 Overview

For this assignment you must create a model (specifically, an activity diagram) of a single use case for a product named Wherez, which is being developed by the (fictitious) company Nearby.

For simplicity, you will be starting with a working version of Wherez rather than a textual description of the product which, of course, means that the product design, engineering design and construction have already been completed. However, you are creating the activity diagram for the software engineering team, not users. In other words, you are going to replicate some of the product design process that they have already completed, and your model must be consistent with the existing product.

3 Getting Started

Download (in most browsers, by right-clicking on the link) the following executable .jar file:

and the following street segment and intersection files for Harrisonburg, VA:

into an appropriate directory/folder.

Note that the .jar contains only .class files and is executable. You should not include it in an Eclipse project, you should run it from the desktop or a terminal window/command shell.

4 Tasks

You must complete the following tasks.

1. Execute Wherez and use it to find the longitude/latitude of an address in Harrisonburg, VA (e.g., 265 N Main St) after first loading the data files using Utilities-Read. Note that you will only select the .seg file, but both the .seg file and the .int file will be read in. So, you must have both of them in the same directory/folder. (If you have trouble running the program you might want to consult the course "Help" page on "Jar Files", specifically the section on "Permissions".)
2. Create an activity diagram containing a Geocode a Single Address with Wherez Activity that models the user's actions when running Wherez, reading a data file, entering a single address, finding the longitude/latitude for that address, and exiting Wherez. Your Activity must account for the normal flow and the exceptional flow in which the user cancels the reading process. It need not include any other exceptional flows and it need not include every possible way that the user can exit the program. Your Activity must have an input parameter for the address and an output parameter for the longitude/latitude. It must not include the actions performed by the product (except for the creation of the output parameter).

5 Submission

You must submit (using Gradescope) a .pdf file containing the activity diagram described above.

6 Getting Help

Help with using stu.cs.jmu.edu, using the required UML modeling tool, and running executable .jar files can be found on the course "Help" page.

7 Reminders

Remember to read and follow all policies related to homework assignments (including style guides, submission rules, collaboration rules, etc...). In particular, there is a UML style guide, and your submission must comply with it.

Also, remember to use the required UML modeling tool. (While this is not really important for this assignment since you are working on your own, it will be important when you start working on the team project. Hence, to help you get ready for what is to come, you must use the required UML modeling tool now.)

Next, remember that the target audience for your activity diagram is the software engineering team, not users. This means that, though your activity diagram will describe the way the product is used, it is a design document not a user guide. One way to think about this is to imagine that you are describing the use of a competitor's product for a software engineer who will not be able to use the product but is tasked with designing a product that will be used the same way. Note, however, that this does not mean that the activity diagram is a model of what the software engineer must to do, nor is it a model of what the product must do. It is still a model of what the user does.

Finally, remember to pay careful attention to:

1. The descriptions of the action nodes (which should, for the most part, be verbs or verb phrases).
2. Whether actions are performed in a particular order, simultaneously, or in an arbitrary order.
3. Whether an actions must be performed or are performed only when a condition holds.
4. How tokens are used.
5. Decision/Merge nodes and Fork/Join nodes "match".

8 A Question You Should Not Ask

As always, you should feel free to ask questions. However, you should not ask the following question:

Part of your job is to decide on the right level of abstraction given the audience. Your activity diagram should be detailed enough so that a product designer could use it to design the GUI and an engineering designer could use it to design the way the system will respond to user interactions. (So, for example, you wouldn't need to explain to either person that a user has to press the 2, the 6, and the 5 to enter the number 265.)

One way to verify/validate your activity diagram is to give it to a friend/roommate (who understand activity diagrams) and ask her/him to sketch a GUI that would be consistent with it and describe how she/he would interact with the GUI.