Software Architecture & Design Assignment 5: Software Design
Assignment 5: Software Design
Background
A fellow classmate, George P. Burdell, is looking for a new job in the US after graduation. As it can be complicated to compare job offers with benefits, in different locations, and other aspects beyond salary, he would like an app to help with this process and has asked for your assistance in creating a simple, single-user job offer comparison app. As a first step, he would like you to create an initial design for the app, expressed in UML, based on a set of requirements he provided. This deliverable thus consists of (1) a UML design document and (2) a design description
Requirements
-
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 yet1).
-
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 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
-
Number of stock option shares offered
-
Home Buying Program fund (one-time dollar amount up to 15% of Yearly
Salary)
-
Personal Choice Holidays (A single overall number of days from 0 to 20)
-
Monthly Internet Stipend ($0 to $75 inclusive)
-
-
Be able to either save the job details or cancel and exit without saving, returning
in both cases to the main menu.
-
-
When choosing to enter job offers, a user will:
1 To be precise, this functionality will be enabled if there are either (1) at least two job offers, in case there is no current job, or (2) at least one job offer, in case there is a current job.
-
Be shown a user interface to enter all 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).
-
When adjusting the comparison settings, the user can assign integer weights to:
-
Yearly salary
-
Yearly bonus
-
Number of Stock Option Shares Offered
-
Home Buying Program Fund
-
Personal Choice Holidays
-
Monthly Internet Stipend
If no weights are assigned, all factors are considered equal.
-
-
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
-
Number of Stock Option Shares Offered
-
Home Buying Program fund (one-time up to 15% of Yearly Salary)
-
Personal Choice Holidays (A single overall number of days from 0 to 20)
-
Monthly Internet Stipend ($0 to $75 inclusive monthly)
-
-
Be offered to perform another comparison or go back to the main menu.
-
-
When ranking jobs, a job’s score is computed as the weighted average of: AYS + AYB + (CSO/3) + HBP + (PCH * AYS / 260) + (MIS*12)
where:
AYS = yearly salary adjusted for cost of living
AYB = yearly bonus adjusted for cost of living
CSO = Company shares offered (assuming a 3-year vesting schedule and a price-per-share of $1)
HBP = Home Buying Program
PCH = Personal Choice Holidays
MIS= Monthly Internet Stipend
For example, if the weights are 2 for the yearly salary, 2 for the yearly bonus, 2 for Internet Stipend, and 1 for all other factors, the score would be computed as:
2/9 * AYS + 2/9 * AYB + 1/9 * (CSO/3) + 1/9 * HBP + 1/9 * (PCH * AYS / 260) + 2/9 * (MIS*12)
-
The user interface must be intuitive and responsive.
-
For simplicity, you may assume there is a single system running the app (no
communication or saving between devices is necessary).
Details
To create your design, you should follow the same approach that we present in the P3L2 lesson. That is, analyze the requirements (provided above) to identify and refine (1) classes, (2) attributes, (3) operations, and (4) relationships in your design. Just to be completely clear, your task is to design the system, not to implement it. At this stage, the design should be implementation neutral, and not involve constructs specific to a language or framework. For example, we are not looking for Android Activity classes.
Your design should be expressed using a UML class diagram, and the level of detail of the
design should be analogous to the level of detail we used throughout the whole P3L2 lesson.
That is, do not limit your design to only the elements shown in the final video, where some of the
elements shown earlier (e.g., methods) are elided for space). Specifically, you must provide
enough details for the design to be self-contained and for us to be able to assess
whether the design suitably realizes all system requirements.
To help to make your design self-contained, you must also provide a “design description” document, in which you concisely describe, for each of the requirements listed above, either (1) how that requirement is realized in your design, or (2) why it does not directly affect the design and is therefore not shown. To produce this document, you must copy the list of requirements and add your explanation for each one of them. For example, using some partial requirements for a cash register app:
...
2. After starting the cash register, the cashier enters her name, and the total amount of money available in the till.
To realize this requirement, I added a ‘currentCashier’ to the register class to track the signed-in cashier, and a float ‘till’ to represent the money in the till. These values are entered by the startup() method, after prompts are handled within the GUI.
...<additional requirements reflected in example UML diagram>...
16. The User Interface (UI) must be intuitive and responsive.
This is not represented in my design, as it will be handled entirely within the GUI implementation.
The explanation in the design description should be clear enough to allow us to follow the rationale behind your design and how it will fulfill each specified requirement, including any that are not directly depicted in your class diagram. You can also provide in the document additional information about your design, such as assumptions or rationale for some design decisions. Use the document to review your design and ensure you have included everything necessary for your app to fill the list of requirements.
NOTE: A requirement that constrains application behavior cannot be completely handled by the GUI. For example, a GUI may implement the display of output, but the application determines what data to display. The design document should contain a description of the application-specific behavior.
