1 Purpose

The primary purpose of this assignment is to help you review (and demonstrate that you have acquired) the knowledge and skills required to program in Java. From a language and algorithms perspective, there is nothing new in this assignment. There is also nothing new from a software engineering perspective.

This assignment will also help you gain some experience with the integrated development environment that you will be using this semester in this course. Some of the tools you will be using this semester will be new to some of you, and we will discuss aspects of them as the semester progresses. However, at this point, regardless of whether you have used the tools in the past, you should be able to figure out everything that you need for this assignment.

This asignment will also, hopefully, lead you to improve the process that you use during the construction phase of the software engineering lifecycle. For example, it will hopefully get you to start earlier, work on a regular schedule, test properly, and ask questions appropriately.

Finally, this assignment will expose you to the kinds of software engineering documents you will be reading and writing throughout the semester, and the kinds of questions that you may need to ask while carefully reading these documents.

2 Overview

perspecTV is a (fictitious) company that designs, creates and markets products that provide a new perspective on television. Their products make television both more interactive and more informative.

They are in the process of developing a suite of products called forScore for judged competitions of various kinds (e.g., sporting events like diving and gymnastics, singing contests, dance competitions). These products will be used by the organizers of the events, the broadcasters of the events, and the viewers/audience. They have hired you to construct several interfaces/classes that will, ultimately, become part of these products.

These classes/interfaces will initially be used by an application that can be used to score the required program for one diver in a sanctioned intra-departmental 1-meter springboard diving competition (like the one that the Computer Science Department has scheduled for later in the semester). For example, running this application with the command-line parameters 8.5 9.0 5.0 8.0 7.5 7.5 8.0 4.0 9.0 7.5 Bernstein should generate the following output.

Results for Bernstein

                               ALB BEL CAN DJI ESA |  Raw
           Forward Dive - Pike 8.5 9.0 5.0 8.0 7.5 | 24.0
     Forward Somersault - Tuck 7.5 8.0 4.0 9.0 7.5 | 23.0
                 Points:  63.4
  

As another example, running this application with the command-line parameters 4.5 4.0 9.0 5.5 5.0 6.0 6.5 9.5 6.0 6.5 Fox should generate the following output.

Results for Fox

                               ALB BEL CAN DJI ESA |  Raw
           Forward Dive - Pike 4.5 4.0 9.0 5.5 5.0 | 15.0
     Forward Somersault - Tuck 6.0 6.5 9.5 6.0 6.5 | 19.0
                 Points:  46.1
  

3 Preparatory Tasks

Before you do anything else you should:

Install the basic components of the IDE on your computer. (See the course "Help" page for more information.)

Read all policies related to homework assignments (including style guides, submission requirements, collaboration rules, etc...).

4 Documents

We will be discussing several software development processes, including an agile process known as "scrum", and you will use scrum to complete the final project. Hence, to help you gain some experience with this process, all of the documents prepared for this assignment (and several subsequent assignments) assume that perspecTV uses scrum. As you complete these assignments, you should think about these documents and their origins. This will help you later in the semester when you will have to create documents like these on your own.

The terms that perspecTV uses when discussing forScore and its functionality are described in the following document.

• Product Domain Glossary

When using scrum, time is divided into time intervals called sprints that typically last 1-2 weeks, and product features are organized into stories. perspecTV categorizes stories as either epics, abstract stories that might take several releases (developed over the course of many months) to completely realize, and sprintable stories that describe what will be completed in a single sprint (and included in the product at the end of the sprint). The sprintable stories (which are what you are concerned with for this assignment) for forScore have been collected in the following document (along with some epics that are not part of this assignment).

• Stories for forScore

Your team at perspecTV used the sprintable stories to create a set of tasks for this assignment. The other members of your team completed some of the tasks and have left others for you to complete. The complete set of tasks is contained in the following document.

• Tasks for forScore

The tasks that are "checked" have already been completed by other team members, the evidence for which is contained in the following documents.

• Engineering Design for forScore
• Implementation of the main class (named IndividualScorer in the app package) for this release
• Implementation of the DifficultyTable1mS class (in the diving package) for this release
• Specification of the Position enum
• Specification of the Missing class
• Specification of the the Score class
• Specification of the SizeException class
• Specification of the DropRule class
• Specification of the TotalSystem class
• Specification of the WeightedTotalSystem class
• System/Integration Tests for forScore

You must complete the tasks that have not been "checked-off". The code you write must be consistent with the documents prepared by the team.

5 Testing

Some of the tasks that you must complete involve unit testing. You must use JUnit (v5) for this purpose. Your JUnit test suite should cover all statements and all branches (as measured by EclEmma) in all of the classes/enums you write. You should not write tests for the code that was provided to you. Your tests must be in a package named testing and each test class must include the word "Test" in its name.

6 A Recommended Process

The tasks are organized by story. Hence, though they are numbered (so that they can be referred to in documents and conversations), the numbers should not, in any way, influence the order in which you complete them. I would suggest you use the process described below.

For any project you should start as follows:

1. Read all of the documents.
2. Review any source code you've been given (in this case, the IndividualScorer class) so that you understand how the classes you are implementing will be used.
3. Stub-out all of the components (classes, enums, etc.), including all comments. This will make it much easier for you to test and debug your code. (Your stubs should conform to the style guide. This will make enable you to correct style defects incrementally, rather than at the last minute.)
4. Complete several examples by hand so that you understand what each of the components will be used for and how they will be used. (In this case, you are given several integration/system tests. Make sure you can replicate the calculations by hand and then think about how the different components will be used to perform those calculations.)

For this particular project, you should then:

1. Implement the Position enum.
2. Test and debug the Position enum.
3. Implement the Missing class.
4. Test and debug the Missing class.
5. Implement the Score class.
6. Test and debug the Score class.
7. Implement the SizeException class.
8. Implement the ScoringSystem interface.
9. Think about how the WeightedTotalSystem and TotalSystem classes should be related (if at all).
10. Implement the WeightedTotalSystem or TotalSystem class (whichever one you think should be implemented first).
11. Test and debug the class you just implemented.
12. Implement the WeightedTotalSystem or TotalSystem class (whichever one you think should be implemented second).
13. Test and debug the class you just implemented.
14. Implement the Rule interface. (You should really have done this when you stubbed-out everything else.)
15. Implement the DropRule class.
16. Test and debug the DropRule class.
17. Test and debug the complete system (using the main class named IndividualScorer).

7 Submission

You must submit (using Gradescope) a .zip file that contains:

1. Your implementation of the required interfaces/classes/enums in the appropriate package(s). Do not submit the code that was provided to you (unless you need it for your tests).
2. JUnit tests for all of your classes/enums in a package named testing.

The .zip file you submit must contain the diving, scoring, and testing directories/folders at the top level.

There is no limit on the number of submissions and no penalty for excessive submissions.

Note that your submission will not be graded if it does not comply with the specifications. So, if you are unable to complete the assignment, your submission should include a stubbed-out version of all of the components. (This will allow you to get credit for the components that you do implement correctly.)

8 Grading

Your submission will be graded as follows:

• Conformity to the Style Guide (Style) - 10% (All or Nothing)
• Passing your Tests (SelfTests) - 10% (All or Nothing)
• Coverage of your Tests (Coverage) - 20% (Partial Credit Possible)
• Correctness of your Code (OfficialTests) - 60% (Partial Credit Possible)

Points will be deducted for code that is unclear, inelegant, and/or poorly documented.

9 Reminders

Remember to read and follow all policies related to homework assignments (including style guides, submission requirements, collaboration rules, etc...).

10 Help

You should be a fairly proficient object-oriented programmer at this point. However, in case you've forgotten some details, help is available.

11 Questions to Think About

You do not need to submit answers to the following questions, but you should think about them as the answers will be important throughout the semester.

1. Were any of the documents prepared by your team members at perspecTV unclear or incorrect?
2. How did the quality of the documents impact you?
3. How would you avoid these kinds of situations if you had to prepare documents like these (which you will)?
4. When a specification was unclear or something was missing from the specifications did you ask a question or did you make an assumption? If you asked, did you do so before or after submitting your code and discovering it was incorrect?
5. When you asked a question did you phrase it carefully and use clear and unambiguous language?
6. Was the recommended process a good process? If so, why? If not, why not?
7. How will you identify and/or create good processes for future assignments? (Remember, in this course, the processes is more important than the outcome! In other words, this is a "process course".)