design-discussion.md

# Individual Designs

## Design 1 - Aman

__Design Pros:__
- This design is similar to the team's current design. It separated the JobOffer objects fromt the CurrentJob objects while having both inherit from the Job object.
- This design used a list of Job objects ordered by job score to keep track of rankings. This list would then be used to display the jobs in the GUI thereby reducing the need to recalculate rankings everytime the user would want to look at it.

__Design Cons:__
- This design has many unnecessary objects like the CompareJob object would could be simplified to just a simple function. Another unnecessary object is the JobScore object would could just be saved as a private variable within the Job object.
- This design also has duplicate methods between the Job object and the JobOffer object that have the exact same behaviour. Removing these will help simplify the design
- This design incorrectly creates an association between the SystemStartClass and the Job object. Instead there should be an associations between the JobOffer and CurrentJob objects as the user is adding/modifying those objects.

## Design 2 - Cyndi

__Design Pros:__
* Had a system class that saved the current job and list of job offers as well as provided an entry way to compare offers
* Included and consolidated most of the details in a single Job class
* The design included a ComparisonSettings class to hold the weights used to rank the jobs

__Design Cons:__
* Did not include JobOffer and CurrentJob classes explicitly
* Grouped other attributes such as calculating job score in ComparisonSettings as opposed to associating with Job class
* Rather than keeping ranked offer details with ComparionSettings, its best if the System handles it

## Design 3 - Doug

__Design Pros:__
- This design is similar in nature to the team's implementation and makes use of JobOffer and CurrentJob classes that inherit the job class. This allows for differentiation in the System class between a job offer and the user's current job
- The ComparisonSetting class stores user weights independently of the system class.

__Design Cons:__
- Job aggregation not required by design and can be managed by the system class
- Differentiation between modify and add methods is not required.
- Job ranking has to be recalculated every time it's used to display jobs to the user.

## Design 4 - Haru

__Design Pros:__
- Comparison settings singleton will be created and that will offload System singleton from having more functions
- Job keeps track of the rank, so it'd be easier to check out a job's relative position whenever a user wants
- Current job and job offers are added as subclasses of the abstract Job class, so it would be easier to expand and add subclass-specific attributes or functions in the future if necessary.

__Design Cons:__
- Ranking of the jobs gets updated whenever a job is added or modified, so that adds an unnecessary overhead to the system if the user doesn't check the ranking or scores of jobs often.

---
# Team Design

The team design makes use of elements from each of the individual designs documented here-in. As a team we elected to develop this application with an object-oriented design approach shown by Design 1 and 3 opposed to function-oriented design approach in Design 2 and 4. However, we also tried to incorporate the simplistic approach from Design 2 and 4, so the final team design sits somewhere in between with all trade-offs considered.

For simplicity, methods for modifying and creating a current job or job offer were consolidated into a single method. Each job's relative ranking will be stored within the Job class and updated when a job is added or modified. The collection of Jobs will be stored within a list in the System class and GUI representations present in the individual designs were removed from the Team class diagram.

There are many similarities between the team design and the individual designs. All designs keep a separate CompareSettings object in order to keep track of all the comparison settings that will be set by the user. A similarity with Designs 1, 2, and 4 is that the System object contains a list of jobOffer objects in order to keep track of all job offers. Finally, most designs also tried to maintain a separation between the JobOffer and the CurrentJob objects.

There are also many differences between the team design and the individual designs. Some of the original individual designs were more complicated and relied on creating more objects when a simple method would have sufficed. These extraneous objects were replaced with relevant methods in the team design. Furthermore, Design 4 included the ability to validate input. Even though that is currently not a requirement, we liked the forward thinking displayed. Ultimately we removed this functionality but left space for it to be added at a later date in the Job object.

---
# Summary
From this discussion we learned that there are many different ways to represent one system and therefore it is important to consider all aspects and angles and then try to merge all of their benefits while leaving behind their negatives. Furthermore, we learned that it is better to try and simplify the design as much as possible so that it is easier to explain to others.

As a team, we were able to effectively discuss and evaluate each of the designs documented here-in and used collective editing tools to create a single agreed-upon class diagram. Overall, our discussions were effective, efficient, and constructive and the team as a whole was very responsive.

---
---
design-description.md

# Design Description
This file provides a concise description of how each design requirement is either realized within the design of the class diagram or handled by the user interface. The description for each requirement is provided in *italics* below.

## Requirement 1
When the app is started, the user is presented with the main menu, which allows the user to (1) enter or edit 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).

*The main menu and ability to select different functions are not depicted in this class diagram and will be handled by the application GUI. These functions are covered in subsequent requirements and are detailed below.*

## Requirement 2
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)
- Cost of living in the location (expressed as an index)
- Yearly salary
- Yearly bonus
- Allowed weekly telework days (expressed as the number of days per week allowed for remote work, inclusively between 0 and 5)
- 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.

*The __Job__ class which is inherited by the __CurrentJob__ class allows entry of all details noted above. The __modifyCurrentJob()__ methods of the __System__ class allow for first-time entering and modification of the __CurrentJob__ class. Saving or exiting without saving will be handled by the GUI side of the application and is not detailed in this class diagram.*

## Requirement 3
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 (if they saved it) with the current job details (if present).

*The __Job__ class which is inherited by the __JobOffer__ class allows entry of all job details noted in requirement 2. The __modifyJobOffer()__ method of the __System__ class allow for creation and modification of a __JobOffer__ class. Saving or exiting without saving will be handled by the GUI side of the application and is not detailed in this class diagram. The __modifyJobOffer()__ method of the __System__ class will allow for the creation of additional job offers. Details of the job comparison structure will be covered by the design description for requirement 5. The selection of different functions such as entering offers, returning to main menu, and comparing job offers will be covered by the GUI.*

## Requirement 4
When adjusting the comparison settings, the user can assign integer weights to:
- Yearly salary
- Yearly bonus
- Allowed weekly telework days
- Retirement benefits
- Leave time
If no weights are assigned, all factors are considered equal.

*The __ComparisonSettings__ class contains the weight value for each criteria used in the comparison of jobs. The __adjustComparisonSettings()__ method of the __System__ class allows for modification of these settings. On initialization of the __System__ class the __ComparisonSettings__ class will be instantiated with equal weights.*

## Requirement 5
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
- Yearly bonus adjusted for cost of living
- Allowed weekly telework days
- Retirement benefits (as percentage matched)
- Leave time
- Be offered to perform another comparison or go back to the main menu.

*After any __Job__ object is saved or modified, it's __jobScore__ is calculated and used to place the ordered list of __Job__ objects in the __rankedListOfAllJobs__ object within the __System__ class. This __rankedListOfAllJobs__ object will be used to keep track of the rankings of all the jobs and will be used to generate the table of offers ranked from best to worst for this requirement. Selection of two jobs for comparison in table format will be handled by the GUI and based on the information retreived from the __System__ class's __rankedListOfAllJobs__ object the two jobs will be compared and a table will be generated that compares the two jobs.*

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

AYS + AYB + (RBP * AYS) + (LT * AYS / 260) - ((260 - 52 * RWT) * (AYS / 260) / 8)

where:
- AYS = yearly salary adjusted for cost of living
- AYB = yearly bonus adjusted for cost of living
- RBP = retirement benefits percentage
- LT = leave time
- RWT = telework days per week
- The rationale for the RWT subformula is:
- value of an employee hour = (AYS / 260) / 8
- commute hours per year (assuming a 1-hour/day commute) =
1 * (260 - 52 * RWT)
- therefore travel-time cost = (260 - 52 * RWT) * (AYS / 260) / 8

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 * AYB + 2/7 * (RBP * AYS) + 1/7 * (LT * AYS / 260) - 1/7 * ((260 - 52 * RWT) * (AYS / 260) / 8)

*When a __Job__ is added or updated, the __calculateScore()__ will be called automatically and it will update __score__ field in the __Job__ object. There is no requirement explicitly to display the weights, but the job offers will be displayed in order of ranking with __title__ and __company__ diplayed.*

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

*This is not represented in the UML design provided. It will be handled entirely within the GUI application design.*

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

*The application will contain a singleton object of the __System__ class which is only accessible to the running device. No user login or credential capability is documented in the class diagram. Further no saving/communication with a remote server (for storage) is documented. Thus, this requirement is met by the design shown in this class diagram.*