Merge pull request #242 from acekhoon/DG

Add design consideration for get and slots left

docs/DeveloperGuide.md

@@ -212,6 +212,22 @@ The following sequence diagram shows how a get operation goes through the `Logic
 
 ![GetSequenceDiagram](images/GetSequenceDiagram.png)
 
+**Design considerations:**
+
+**Aspect: Format of get command:**
+
+**Alternative 1 (current choice):** Use index as argument.
+
+Pros: It is easier for the user to type out the index at the end user's side.
+Cons: This requires the user to know the index from the list of candidates displayed in the UI. If there is a long list of candidates in the UI, observing from the UI may not be so feasible.
+
+We choose this alternative because we have a search command which supports narrowing down of the candidate list to find the desired candidate.
+
+**Alternative 2:** Use Candidate's Email as argument.
+
+Pros: Email is usually known beforehand midst of the recruitment process, and email is the unique primary key for all candidates in the list.
+Cons: Email could possibly be a bit long and cumbersome for users to type out.
+
 ### Search Command
 
 Search Command searches candidates whose attributes match all the corresponding attributes (i.e. intersection of all the matches). Phone, email and country are matched by equality, while name, comment, tag are matched by substring of the candidate attributes. The search operation is executed as follows:
@@ -262,6 +278,13 @@ The following sequence diagram shows how a SlotsLeft operation goes through the
 
 ![SlotsLeftSequenceDiagram](images/SlotsLeftSequenceDiagram.png)
 
+**Design Consideration:**
+
+**Aspect:** Rationale behind implementation of SlotsLeft command:
+
+At the outset, there were discussions centered around whether `vacancy` attribute for the job class should denote the remaining count of job openings or the total number of candidates intended for recruitment by the hiring entity. In consideration of the recruiters' potential necessity to adjust the vacancy count for a given job and constantly refer to the initial vacancy, it was resolved that the `vacancy` attribute shall denote the total number of positions that the recruiters aim to hire. To accommodate a functionality enabling recruiters to ascertain the number of remaining job openings after deducting the count of candidates already offered positions, a 'slots_left' command was instituted for this purpose.
+
+
 ### Add_app Command
 
 Add_app adds an application containing a job and a person
@@ -274,17 +297,18 @@ Step 3. `AddApplicationCommandParser#parse(String)` creates a new `AddApplicatio
 
 Step 4.`AddApplicationCommand#execute(Model)` is then called in `LogicManager#execute(String)`, where the matching `Person` and `Job` are found, and an `Application` object containing the `Person` and the `Job` is created. `model#addApplication(Application)` is then called and the `Application` is added to the list of `Application`s in `model`.
 
-Design considerations:
-Aspect: Format of add_app command:
+**Design considerations:**
+
+**Aspect:** Format of add_app command:
 
-Alternative 1 (current choice): Use primary keys for `Person` (`Email`) and `Job` (job `Title`) as argument.
+**Alternative 1 (current choice):** Use primary keys for `Person` (`Email`) and `Job` (job `Title`) as argument.
 
 Pros: `Email` of a candidate and the job `Title` that the candidate applies for are usually known beforehand to the recruiters, and they are unique primary keys for all candidates and jobs in the their respective lists.
 Cons: It is harder for the users to type out the email of a candidate and job title that the candidate intends to apply to use the command.
 
 We choose this alternative because recruiters can reduce the probability of adding incorrect application by enforcing them to explicitly type out a candidate's email and a job title that the candidate applies for.
 
-Alternative 2: Use an index of Candidate (`Person`) in the candidate list and an index of job in the job list as an input
+**Alternative 2:** Use an index of Candidate (`Person`) in the candidate list and an index of job in the job list as an input
 
 Pros: It is easier for the users to type out index of candidates and jobs displayed in their respective lists than writing email and job title everytime.
 Cons: Recruiters need to scroll down the list of candidates and jobs in order to find respective indices, which could require additional effort. Recruiters might be prone to make a mistake since they need to identify candidates and job via indices, and it might be confusing for them to discern which index is for candidates and which one is for job when employing this command.