---
# System prepended metadata

title: 'Design 1 (Jeremy):'

---

# Design 1 (Jeremy):
- Clear starting point with Main Menu
- Being able to edit job details (+)
- Is this a single screen app or multiple screens?
- Shouldn't need to select a job offer as a current job. Current job details can simply be edited.

# Design 2 (Patrick):
- How do jobs / offers persist or be accessed between screens?
- AppUIEnterOffer handles Current Job and Job Offers.
- Handling of "current job" is inelegant, one object could be labeled as "current job" and kept in the manager class

# Design 3 (John):
- Current job vs. Job offer seems overly complex in its inheritance model, potentially simplify to a manager class that keeps track of the current job as an attribute
- compare job screen should be clear that it can be accessible via enter job screen- 

# Design 4 (Asihim):
- compare job offer / boolean / relationships don't make sense
- why is the relationship between Job offer and comapre job offers a "has a" relationship?
- redundancy between current job details class and job offer class
- why are there two classes related to weights?

# Consensus for team design
- John's design modified in the following ways:
- remove GUI related components
- remove extra "Job" classes and have a single JobDetails class, where the JobManager can differentiate between a current job and job details

Part1:
John: design.pdf
John: design-description.md
Patrick: design-discussion.md

Part2:
Patrick: ProjectPlan.md
UseCaseModel.md
ExtraRequirements.md
DesignDocument.md
Jeremy: TestPlan.md