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.
.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).
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).
.pdf
file containing the activity
diagram described above.
.jar
files, and using stu.cs.jmu.edu
is available on the course "Help" page.
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:
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
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.
Copyright 2024