---
# System prepended metadata

title: Untitled

---

## Design 1

![Design aromauld3](./images/design_aromauld3.png)

**Pros** 
* Good abstractions of things like comparison settings and location.

**Cons**
* Doesn’t scale well, if we want to have multiple users, due to the lack of a User class.
* Represents GUI elements like Menu.


## Design 2

![Design lgrosswiler3](./images/design_lgrosswiler3.png)

**Pros**
* Readable thanks to defined types.
* Solid basic structure of classes.
* Potentially scalable thanks to a User class.

**Cons**
* Job could use functionality to calculate adjusted cost of living.


## Design 3

![Design rbeall8](./images/design_rbeall8.png)

**Pros**
* Simple and straightforward

**Cons**
* Lacking a User class - could impact scalability.
* Would have to separate data from Driver.
* Job calculating its own score could be better abstracted out.


## Design 4

![Design vkarri3](./images/design_vkarri3.png)

**Pros**
* Separation of CurrentJob and JobOffer could improve scalability if they diverge.

**Cons**
* Diagram is missing some of the details (types, relationships).
* Entry points not defined.
* Missing User representation.


## Team Design

![Design Team](./images/design_team.png)

> Discuss the main commonalities and differences between this design and the individual ones, and concisely justifies the main design decisions.

* Include Job class and User class.
    * Some designs did not have this while others did. However, after discussion, it was decided that having a separate User class better follows OOP and UML guidelines and expresses the system.
* Comparison weights in separate data structure.
    * Not all of the designs had a separate class to represent this. But we all agreed to have this as a separate class for clarity.
* Job offers are for the specific user - so offers should live in the User class.
    * After much discussion about whether the User class and Driver class need to be separate especially after stating that the app is going to be for a single user, we decided to have separate User class and Driver Class to basically manage all UI actions and state in the Driver class and the User class will maintain data for current job and job offers.


## Summary

In the course of discussing each design, several conclusions were made. An ideal design needs to be simple and scalable in case of expanded scope and added features. A good design should have enough abstraction to clearly demonstrate the components of the system and keep data organized. Specific to this assignment, it was realized that despite the initial specification calling for a single user system, maintaining a user class allowed the design to be scalable to a larger system and made for a better object oriented design. 

Outside of the design, there were a handful of lessons learned for moving forward. Having a communication platform that allowed for quick communication between team members as well as video communication and screen sharing was key to completing this assignment. To this end, we used Microsoft Teams. In addition, using collaboration documents such as HackMD and Google Docs proved valuable for finishing the design description and the design discussion. 