Merge pull request #203 from CS2113-AY1819S1-T09-4/vincent_last

Vincent last

build.gradle

@@ -232,9 +232,9 @@ asciidoctor {
         idprefix: '',  // for compatibility with GitHub preview
         idseparator: '-',
         'site-root': "${sourceDir}",  // must be the same as sourceDir, do not modify
-        'site-name': 'FinancialPlanner-Level4',
-        'site-githuburl': 'https://github.com/se-edu/addressbook-level4',
-        'site-seedu': true,  // delete this line if your project is not a fork (not a SE-EDU project)
+        'site-name': 'Savee',
+        'site-githuburl': 'https://github.com/CS2113-AY1819S1-T09-4/main',
+        'site-seedu': false,  // delete this line if your project is not a fork (not a SE-EDU project)
     ]
 
     options['template_dirs'].each {

docs/DeveloperGuide.adoc

@@ -371,12 +371,7 @@ This feature has 2 different kind of modes as follows:
 
 . Duo Argument Mode - Input arguments must contain only 1 category and only 1 order, and can be input in no particular order
 
-The input given by the user
-
-
-
-
-is passed to `SortCommandParser` to split the input separated by whitespaces to ensure
+The input given by the useris passed to `SortCommandParser` to split the input separated by whitespaces to ensure
 there is either only one or two arguments input by the user. These arguments are stored in an array of strings and
 the size of the array determines the mode of the command.
 
@@ -408,16 +403,11 @@ The three argument modes are as listed below:
 * Dual Argument mode -- Requires 2 dates, a `start date` and an `end date`. It returns all records containing dates within the time frame of start date and end date, inclusive of both start date and end date
 The mechanism that facilitates these modes can be found in the `ListCommandParser#parse`. Below is a overview of the mechanism:
 
-. The input given by the user is passed to `ArgumentTokeniser#tokenise` to split the input separated by prefixes.
-. This returns a `ArgumentMultiMap` which contains a map with prefixes as keys and their associated input arguments as the value.
+. The input given by the user is passed to `ArgumentTokeniser#tokenise` to split the input separated by prefixes which returns a `ArgumentMultiMap` which contains a map with prefixes as keys and their associated input arguments as the value.
 . The string associated with `d/` is then passed into `ListCommandParser#splitByWhitespace` for further processing and returns an array.
 . The argument mode is determined by the size of this array and the elements are further processed into `Date` objects, before creating and returning a `ListCommand` object.
 
-The `ListCommand` has two constructors which makes use of overloading to reduce code complexity.
-
-* One constructor has no arguments and assigns default predicate for the `FilteredList` in `ModelManager`,
-`PREDICATE_SHOW_ALL_RECORDS` which will show all items in the list.
-* The second constructor takes in 2 `Date` arguments and assigns the predicate `DateIsWithinDateIntervalPredicate` which will only show items within the date interval.
+The `ListCommand` has two constructors which makes use of overloading to reduce code complexity, one with no argument and the other one with 2 `Date` arguments.
 
 The following sequence diagram shows how the list operation works:
 
@@ -449,12 +439,24 @@ The corresponding command required for this feature is `summary` and the user wi
 they are viewing *summary by date, by month or by category*. This feature involves most components of FinancialPlanner with the exception of `Storage`. It can also be broadly split into
 2 phases, the logic phase which generates the summary and the UI phase which allows users to view the summary in a table.
 
+As shown below, `SummaryByDateCommand`, `SummaryByCategoryCommand`, `SummaryByMonthCommand` is a type of SummaryCommand and thus inherits from `SummaryCommand`. The rationale behind this design choice is that
+code shared by these classes can be placed in `SummaryCommand` for code reuse. This makes it easier for future developers to easily extend this functionality.
+
+.Class diagram showing the inheritance from SummaryCommand
+image::SummaryCommandClassDiagram.png[width="500"]
+
+Also, these commands utilise their own version of summary lists which is also inherited from the parent class `SummaryList` as shown below.
+
+.Class diagram showing the inheritance from SummaryList
+image::SummaryListClassDiagram.png[width="500"]
+
 The sequence diagram below details the sequence of program executions for the logic phase.
 
+.Sequence diagram for high level interactions in logic phase
 image::SummarySequenceDiagram.png[width="790"]
 
 . When the user types in the command "summary date d/1-1-2018 12-12-2018", the command is passed from LogicManager to FinancialPlannerParser. In here,
-the system chooses which parser to use which is SummaryCommandParser and calls its parse method which is polymorphic, meaning that every parser has the same function but use different
+the system chooses which parser to use and calls its parse method which is polymorphic, meaning that every parser has the same function but use different
 implementation.
 . In this class, based on the `mode` parameter given, the system chooses a SummaryCommand to instantiate and pass the reference back to the Logic Manager. The various checks for the validity of the
 parameters also occur during this stage.
@@ -475,15 +477,15 @@ The next phase of the program execution is performed in the UI components.
 * **Alternative 1 (current choice):** Generate the summary list whenever the summary command is called.
 ** Pros: Easier to implement and maintain. Sufficient for the intended target audience of FinancialPlanner.
 ** Cons: This requires looping through each record in the filtered record list obtained from the `Model`.
-To aid in the time complexity, the internal implementation of SummaryList was done using hash maps instead with allowed for
-constant time random access unlike list. However, the initial filtering is close to linear time complexity which could slow down the app if many records are inside.
+To aid in the time complexity, the internal implementation of SummaryList was done using hash maps instead which allowed for
+constant time random access.. However, the initial filtering is close to linear time complexity which could slow down the app if many records are inside.
 Also, the list had to be created every time `summary` is called which could be slow if the command is called multiple times.
 
 * **Alternative 2:** Morph the record list into a record hash map of record lists instead
 ** Pros: A hash map allows for constant random access to a record list of a particular date assuming the key for the hash map is using dates.
 Thus, the filtering function does not need to loop through as many records and the time taken would be lower especially when the database in the application is large.
 ** Cons: Might be too specific to only 1 type of category like categorising by date. If any other types are required, another map may have to be added. This implementation may make the
-system rigid and hard to modify in the future. Also, the summary list still had to be generated every time command is called.
+system rigid and hard to modify in the future.
 
 * **Alternative 3:** Cache the summary list in financial planner
 ** Pros: By caching the summary list in the financial planner and assigning a boolean variable along with information on the filter predicate to it to determine if it is modified, we can
@@ -495,7 +497,7 @@ Also, if the sequence of commands is as follows, *summary, add, summary*, the ti
 ==== Aspect: Method of switching UI panels
 * **Alternative 1(current choice):** Disable all UI panels within the Main UI placeholder before enabling the desired one
 ** Pros: Easy to implement and apply it to other newly created panels. To make use of the current implementation, the panel can simply be the children of
-the main Ui placeholder and the event handler can be placed in main window.
+the main Ui placeholder and its event handler can be placed in main window.
 ** Cons: Might be inefficient when there are many panels or many switching as the same process must be repeated for all panels.
 However, this is unrealistic and it is unlikely that there are a lot of UI panels for it to make a significant impact.
 
@@ -514,6 +516,7 @@ The corresponding command required for this feature is `stats`.For this feature,
 This feature is facilitated by a few key components of FinancialPlanner, `Logic`, `Model`, `UI` and function executions can be split into 2 phases, the `Logic phase` and the `UI phase`.
 The detailed execution sequence of functions used for `Logic phase` are as shown below.
 
+.Sequence diagram for high level interactions in logic phase
 image::StatisticLogicSequenceDiagram.png[width="790"]
 
 Consider the situation where the user enters *"stats d/1-1-2018 12-12-2018"*:
@@ -524,6 +527,7 @@ parameter to StatisticCommandParser.
 * The StatisticCommandParser will then parse the arguments and create a new StatisticCommand object before returning its reference. The activity diagram below details the mechanism
 within the `StatisticCommandParser#parse` method.
 
+.Activity diagram for details in StatisticCommandParser
 image::StatisticParserActivityDiagram.png[width="790"]
 
 * Once `StatisticCommand#execute` is called, it will then search through the in-memory data of FinancialPlanner and return a list containing all records within the date range and including
@@ -538,15 +542,17 @@ is in the map.
 an event constructor before posting the event `ShowPieChartStatsEvent`.
 
 After the event is posted, the execution proceeds to the `UI phase` where there is a listener in `MainWindow` listening to this event. This is facilitated by
-the event system in FinancialPlanner. The sequence diagram below details the program flow of the functions executed in `UI phase`.
+the event system in FinancialPlanner. The sequence diagram below details the program flow of the functions executed in `UI phase` for creating the pie chart for total expense.
 
+.Sequence diagram for high level interactions in UI phase
 image::StatisticUiSequenceDiagram.png[width="790"]
 
 * When the event is caught by the listener in `MainWindow`, `MainWindow` looks through all children of the `MainWindow#mainUiPanelPlaceholder` and executes the hide function in them.
 This will make all children hidden from view in the UI which ensures that the UI is displayed correctly.
 * As shown above, the function `StatsDisplayPanel#handleShowPieChartDataEvent` is called which will call the constructor of `MixedPieChartData`. The detailed execution details within this class is as shown in
 the activity diagram below.
 
+.Activity diagram for details in MixedPieChartDataList
 image::StatisticUiActivityDiagram.png[width="790"]
 
 The program flow is then as shown above where the `CategoryBreakdown` is created and instantiated with 2 lists, one being expenseLabelData and other being expenseLegendData.
@@ -555,6 +561,7 @@ In the current implementation, whenever `stats` is called, 2 tabs will be create
 
 The sequence diagram below details the program flow after the constructor of CategoryBreakdown class is called.
 
+.Sequence diagram for creation of pie charts
 image::StatisticUiDetailedSequenceDiagram.png[width="790"]
 
 [NOTE]

docs/UserGuide.adoc

@@ -461,7 +461,7 @@ Examples:
 * `summary month d/apr-2018 sep-2018`
 * `summary month d/APR-2018 SeP-2018`
 * `summary category d/1-1-2018 12-12-2018`
-
+// end::summary[]
 The screenshots below are examples of what you can see once the command has been accepted. The commands entered have been left
 in for visualisation purposes. These screenshots are taken in *fullscreen mode*  at 1080p resolution.
 
@@ -474,7 +474,7 @@ image::UiSummaryByMonthTable.png[width="790"]
 image::UiSummaryByCategoryTable.png[width="790"]
 *Screenshot of app when `summary category d/1-1-2018 12-12-2018` is run*
 
-// end::summary[]
+
 // tag::stats[]
 === Showing a breakdown of total expenses and income into categories: `stats`