# Team 08 Design Description
Anthony Meyer, Trey Pero, James Guyer, Alejandro Kantor

## Requirement 1
**Requirement**

*When the app is started, the user is presented with the main menu, which allows the user to (1) enter current job details, (2) enter job offers, (3) adjust the comparison settings, or (4) compare job offers (disabled if no job offers were entered yet).*

**Design**
1) When you enter current job details, the job will be saved in the ```saveJob``` method of the ```JobService``` class. The ```JobService``` class will know you are saving a "current job" by the ```currentJob``` field on the ```Job``` object.
2) When you enter job offer details, the job will be saved in the ```saveJob``` method of the ```JobService``` class. The ```JobService``` class will know you are saving a job offer object because the ```currentJob``` field will be ```false``` on the associated ```Job``` object.
3) The comparison settings are represented by the JobWeights object and can be saved through the ```saveJobWeights``` method on the ```JobWeightsService``` class.
4) To know there are no job offers, the ```JobService``` class would return an empty list on a call to ```getJobs```. The app could use this to disable comparison from the UI.

## Requirement 2
**Requirement**

When choosing to enter current job details, a user will:

* *Be shown a user interface to enter (if it is the first time) or edit all of the details of their current job, which consist of:*
* *Title*
* *Company*
* *Location (entered as city and state)*
* *Overall cost of living in the location (expressed as an index)*
* *Yearly salary*
* *Signing bonus*
* *Yearly bonus*
* *Retirement benefits (as percentage matched)*
* *Leave time (vacation days and holiday and/or sick leave, as a single overall number of days)*

* *Be able to either save the job details or cancel and exit without saving, returning in both cases to the main menu.*

**Design**

It will be the user's first time if there are no jobs returned from ```JobService.getJobs```.

Saving of jobs is handled by the ```JobService```, but cancel functionality is application specific and outside of the scope of this design.

## Requirement 3
**Requirement**

*When choosing to enter job offers, a user will:*
* *Be shown a user interface to enter all of the details of the offer, which are the same ones listed above for the current job.*
* *Be able to either save the job offer details or cancel.*
* *Be able to (1) enter another offer, (2) return to the main menu, or (3) compare the offer with the current job details (if present).*

**Design**
1) The user can enter another offer and save it via ```saveJobs```.
2) Returning to main menu is application specific and outside of the scope of this design.
3) Comparison of job offers with current job can be done via the ```JobComparator```.

## Requirement 4
**Requirement**

*When adjusting the comparison settings, the user can assign integer weights to:*
* *Yearly salary*
* *Signing bonus*
* *Yearly bonus*
* *Retirement benefits*
* *Leave time*

*If no weights are assigned, all factors are considered equal.*

**Design**

The ```JobWeights``` object defaults to equal weights, illustrated in the UML by showing all values at 1. The value doesn't have to be 1, but the UML displays that for clarity that they will all be defaulted to the same value. If the user enters any weights, they will be packaged in a ```JobWeights``` object and passed to ```JobService```'s save```JobWeights``` method and overwrite the previous values automatically.

## Requirement 5
**Requirement**

*When choosing to compare job offers, a user will:*
* *Be shown a list of job offers, displayed as Title and Company, ranked from best to worst (see below for details), and including the current job (if present), clearly indicated.*
* *Select two jobs to compare and trigger the comparison.*
* *Be shown a table comparing the two jobs, displaying, for each job:*
* *Title*
* *Company*
* *Location*
* *Yearly salary adjusted for cost of living*
* *Signing bonus adjusted for cost of living*
* *Yearly bonus adjusted for cost of living*
* *Retirement benefits (as percentage matched)*
* *Leave time*
* *Be offered to perform another comparison or go back to the main menu.*

**Design**

Since this is the only view where the job offers would be displayed, the ```getJobs``` method on the ```JobService``` class would sort the list prior to returning it using a ```JobComparator``` with the appropriate ```JobWeights```. The current job would be in the list with the ```currentJob``` boolean flag set in order to indicate it on the UI. For a two job comparison, we can use the ```JobComparator``` to compare the jobs and then when displaying, the adjusted values are provided via methods on the ```Job``` objects.

## Requirement 6
**Requirement**

*When ranking jobs, a job’s score is computed as the weighted sum of:*

*AYS + ASB + AYB + (RBP AYS) + (LT AYS / 260)*

*where:*

*AYS = yearly salary adjusted for cost of living
ASB = signing bonus adjusted for cost of living
AYB = yearly bonus adjusted for cost of living
RBP = retirement benefits percentage
LT = leave time*

*For example, if the weights are 2 for the yearly salary, 2 for the retirement benefits, and 1 for all other factors, the score would be computed as:
2/7 AYS + 1/7 ASB + 1/7 AYB + 2/7 (RBP AYS) + 1/7 (LT AYS / 260)*

**Design**

This calculation is performed via the score method on the ```Job``` object. The ```JobComparator``` keys into this method when comparing two arbitrary ```Job``` objects. The score method accepts a ```JobWeights``` parameter to account for the custom user weights when calculating this score.

## Requirement 7
**Requirement:**
*The user interface must be intuitive and responsive.*

**Design:**
This is out of scope of this design; it will be handled entirely with the GUI implementation.

## Requirement 8
**Requirement**

*The performance of the app should be such that users do not experience any considerable lag between their actions and the response of the app.*

**Design**

This is out of scope of this design, but our design supports the option of performance tuning. For example, if we wanted to avoid expensive persistence calls to retrieve user job offers on every call to the ```JobService```, we could cache the list of jobs in the ```JobService``` implementation and update that cached list on every user update. Performance is moreso directly impacted by database design, OS implementation, hardware, etc and is a non-functional requirement.

## Requirement 9
**Requirement**

*For simplicity, you may assume there is a single system running the app (no communication or saving between devices is necessary).*

**Design**

Whether or not this is running on a single system doesn't impact our design, but rather our implementation.