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

For simplicity, you will be starting with a working version of Tempz 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 temperature history files:

into an appropriate directory/folder.

4 Tasks

You must complete the following tasks.

1. Execute Tempz and use it to find the maximum average temperature and the minimum average temperature for October 2020 (i.e., 10/2020) in Charlottesville, VA (at the Albermarle Airport). Hints: (a) You will need to read the appropriate .tem file using Utilities-Read. (b) You will need to enter some information into the input fields. (c) You will need to click on the button that looks sort of like a small calculator.
2. Create an activity diagram containing a Calculate Average Temperatures with Tempz Activity that models the user's actions when running/starting Tempz, reading a single data file, entering one set of inputs, finding the averages, and exiting Tempz. 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 inputs and output parameters for the outputs. 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.

From Gradescope's perspective, this assignment has only one question. So, you must associate all of the pages of your submission (if it has multiple pages), with that single question.

6 Getting Help

Help with the required UML modeling tool is available on the course "Help" page.

If you have trouble starting the program (i.e., getting the executable .jar file to run) you might want to consult the course "Help" page on "Jar Files", specifically the sections on "Permissions", "Associations", and "Testing".

If you have trouble finding the data files when the program is running, this is most likely because the program doesn't have the permissions to see the files. You may need to put the data files and .jar files in the same directory/folder to correct this problem. You may also need to change the owner of the files and/or the permissions on the files.

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.