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 Taxeze, which is being developed by the (fictitious) company FreeMarket.

For simplicity, you will be starting with a working version of Taxeze rather than a textual description of the product which, of course, means that the product design, engineering design and construction have already been completed. Nonetheless, 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 tax tables for the United States in 2019:

into an appropriate directory/folder (e.g., the downloads directory for this course).

4 Tasks

You must complete the following tasks.

1. Execute Taxeze and use it to find the marginal tax rate and tax for a single person who earned $85,750 in tax year 2019 after first loading the appropriate tax table using Utilities-Read. (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 Calculate a Tax Payment with Taxeze Activity that models the user's actions when running/starting Taxeze, reading a tax table, entering one income, choosing a filing status, finding the tax information, and exiting Taxeze. Your Activity must account for the normal flow and the "unusual" flow (also called an "exceptional" flow, which is not the same as an exception) in which the user cancels the reading process (which can happen before or after a file is selected). It need not include any other exceptional flows. Your Activity must have input parameters for the taxable income and filing status and output parameters for the tax and marginal tax rate. It must not include the actions performed by the product (except for the creation of the output parameter).

5 Submission

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

6 Getting Help

Help with the required UML modeling tool, working with .jar files, and using stu.cs.jmu.edu is available 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 (see the "Tools" page). (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 action must be performed or is 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 them to sketch a GUI that would be consistent with it and describe how they would interact with the GUI.