---
# System prepended metadata

title: Design 1

---

# Design 1

![design 1](images/Design1.png)

## Pros: 
Design 1 Offers a clear logic of this applicaion at a high level. It uses `User` Class as the entry point to tie all the parts together. It uses one single `Job` class as an abstrct class to decribe information of both current job and job offer concisely. `CurrentJob` and `JobOffer` classes are specifications inheritating from `Job` Class. 
## Cons:
The `Money` Class and `Day` Class might not need to be explicitly listed as two separate classes. It will be more concise if we can merge the `Location` class into `Job` Class's attributes.

# Design 2

![design 2](images/Design2.png)

## Pros:
Design 2's design logic overall is similar to Design 1. It adds `jobScore` and `isCurrentJob` attributes to `JobInfo` Class which uses to describe information of current job and job offer. These two attributes can easily track score to compare jobs and current job status. It uses `MainMenu` Class as entry point to tie everything together.

## Cons:
It lacks a `JobList` class to implement the function of ranking, comparing different jobs and adding or editing jobs from the list.

# Design 3

![design 3](images/Design3.png)

## Pros:
Design 3 also shares most of the logics with 1 and 2. It offers more detail and well-rounded logic flow of this app with all situations taking in to consideration. It can offer a lot of guidance to us to implement the following development process. It uses attribute `currentJobindex` in `ListJobOfferInterface` class to easily track the current job. It uses `JobList` class to create and rank a list of job for the comparision section.

## Cons:

The complex diagram might be hard to interpret and understand. We decide to sumbit a more high level uml design so we leave out the details of design 3 and referenced some main logic from it.

# Design 4

![design 4](images/Design4.png)

## Pros:

Design 4 is also a concise design of this app and shares a lot of logics of three other designs. It also uses Job class to describe both current job and job offer and uses `ComparisionSetting` to track weights. It also uses `MainMenu` Class as entry point to tie everything together and uses `currentOrOffer` attribute to track the status of job.

## Cons:

It lacks a `JobList` class to implement the function of ranking, comparing different jobs and adding or editing jobs from the list.

# Team Design

![design team](images/DesignTeam.png)

After discussion, we decided to choose Design 4 as our prototype of team design UML and combined features from three other designs. In the terms of UML structure, Design 4 is quite similar to Design 1 and 2. These three similar design share three classes: a job class, comparision setting class and a entry point class (in Design 1 it's `User` class, in Design 2 and, 4 it's `MainMenu` Class) to describe the app's logic. While in the terms of logic, four designs are quite similiar, particularly Design 3 construct a very useful `JobList` class to implement operations over a list of job. So we integrated this important class with Design 4. All four individual designs include attributes for job id and job score ties with job info related class. In this way, we can easily track and rank different jobs so we also include them in final team design. We all agree that current job class is an extension to job offer class. So in the final design, we create `Job` class to describe both. And add a boolean attribute `currentJobIndex` to track the current job. To this point, we believe we have constructed a UML design to describe the application level logic of this app. 

# Summary

In this discussion of team work, we chose to use video conference and let each one go through their individual design. It proves to be a very efficient way to get everyone understand all individual design. Then we discussed together to refine and produce the final design. In order to generate a team design, it is important to understand each design's pros and cons. Recognize similarity and difference between all designs are also crucial to generate an efficient final team design. 


-- To realize this requirement, I created a class called Job. The Job class will have all the attributes listed above plus 3 additional attributes: jobId (which will be automatically generated to identify a job), jobScore (which will be calculated each time the ComparisonSetting is adjusted) and cuurentOrOffer (which will be a Boolean that identifies if this job is the current job or an offered job). The Job class will have editCurrentJob() method to help save user's input for current job details.
