diff --git a/docs/DeveloperGuide.adoc b/docs/DeveloperGuide.adoc index fd2f156e943..728ade53f70 100644 --- a/docs/DeveloperGuide.adoc +++ b/docs/DeveloperGuide.adoc @@ -161,6 +161,9 @@ The `UI` component, === Logic component [[fig-LogicClassDiagram]] + +The following class diagram shows the structure of the Logic component. + .Structure of the Logic Component image::LogicClassDiagram.png[] @@ -183,6 +186,8 @@ NOTE: The lifeline for `DeleteCommandParser` should end at the destroy marker (X [[Design-Model]] === Model component +The following class diagram shows the structure of the Model component. + .Structure of the Model Component image::ModelClassDiagram.png[] @@ -203,6 +208,8 @@ image:BetterModelClassDiagram.png[] [[Design-Storage]] === Storage component +The following class diagram below displays the structure of the Storage Component. + .Structure of the Storage Component image::StorageClassDiagram.png[] @@ -293,95 +300,6 @@ Alternative 1 was chosen due to the ease of implementation. As the current statistics feature does not require a large amount of data, the number of method calls is not too large. Alternative 2 requires a change in the architecture which may result in higher complexity. -// tag::undoredo[] -=== [Proposed] Undo/Redo feature -==== Proposed Implementation - -The undo/redo mechanism is facilitated by `VersionedSpendingBook`. -It extends `SpendingBook` with an undo/redo history, stored internally as an `spendingBookStateList` and `currentStatePointer`. -Additionally, it implements the following operations: - -* `VersionedSpendingBook#commit()` -- Saves the current spending book state in its history. -* `VersionedSpendingBook#undo()` -- Restores the previous spending book state from its history. -* `VersionedSpendingBook#redo()` -- Restores a previously undone spending book state from its history. - -These operations are exposed in the `Model` interface as `Model#commitSpendingBook()`, `Model#undoSpendingBook()` and `Model#redoSpendingBook()` respectively. - -Given below is an example usage scenario and how the undo/redo mechanism behaves at each step. - -Step 1. The user launches the application for the first time. The `VersionedSpendingBook` will be initialized with the initial spending book state, and the `currentStatePointer` pointing to that single spending book state. - -image::UndoRedoState0.png[] - -Step 2. The user executes `delete 5` command to delete the 5th Spending in the spending book. The `delete` command calls `Model#commitSpendingBook()`, causing the modified state of the spending book after the `delete 5` command executes to be saved in the `spendingBookStateList`, and the `currentStatePointer` is shifted to the newly inserted spending book state. - -image::UndoRedoState1.png[] - -Step 3. The user executes `add n/David ...` to add a new Spending. The `add` command also calls `Model#commitSpendingBook()`, causing another modified spending book state to be saved into the `spendingBookStateList`. - -image::UndoRedoState2.png[] - -[NOTE] -If a command fails its execution, it will not call `Model#commitSpendingBook()`, so the spending book state will not be saved into the `spendingBookStateList`. - -Step 4. The user now decides that adding the Spending was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#spendingBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous spending book state, and restores the spending book to that state. - -image::UndoRedoState3.png[] - -[NOTE] -If the `currentStatePointer` is at index 0, pointing to the initial spending book state, then there are no previous spending book states to restore. The `undo` command uses `Model#canUndoSpendingBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo. - -The following sequence diagram shows how the undo operation works: - -image::UndoSequenceDiagram.png[] - -NOTE: The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. - -The `redo` command does the opposite -- it calls `Model#redoSpendingBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the spending book to that state. - -[NOTE] -If the `currentStatePointer` is at index `spendingBookStateList.size() - 1`, pointing to the latest spending book state, then there are no undone spending book states to restore. The `redo` command uses `Model#canRedoSpendingBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo. - -Step 5. The user then decides to execute the command `list`. Commands that do not modify the spending book, such as `list`, will usually not call `Model#commitSpendingBook()`, `Model#undoSpendingBook()` or `Model#redoSpendingBook()`. Thus, the `SpendingBookStateList` remains unchanged. - -image::UndoRedoState4.png[] - -Step 6. The user executes `clear`, which calls `Model#commitSpendingBook()`. Since the `currentStatePointer` is not pointing at the end of the `SpendingBookStateList`, all spending book states after the `currentStatePointer` will be purged. We designed it this way because it no longer makes sense to redo the `add n/David ...` command. This is the behavior that most modern desktop applications follow. - -image::UndoRedoState5.png[] - -The following activity diagram summarizes what happens when a user executes a new command: - -image::CommitActivityDiagram.png[] - -==== Design Considerations - -===== Aspect: How undo & redo executes - -* **Alternative 1 (current choice):** Saves the entire spending book. -** Pros: Easy to implement. -** Cons: May have performance issues in terms of memory usage. -* **Alternative 2:** Individual command knows how to undo/redo by itself. -** Pros: Will use less memory (e.g. for `delete`, just save the Spending being deleted). -** Cons: We must ensure that the implementation of each individual command are correct. - -===== Aspect: Data structure to support the undo/redo commands - -* **Alternative 1 (current choice):** Use a list to store the history of spending book states. -** Pros: Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project. -** Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both `HistoryManager` and `VersionedSpendingBook`. -* **Alternative 2:** Use `HistoryManager` for undo/redo -** Pros: We do not need to maintain a separate list, and just reuse what is already in the codebase. -** Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as `HistoryManager` now needs to do two different things. -// end::undoredo[] - -// tag::dataencryption[] -=== [Proposed] Data Encryption - -_{Explain here how the data encryption feature will be implemented}_ - -// end::dataencryption[] - === Logging We are using `java.util.logging` package for logging. The `LogsCenter` class is used to manage the logging levels and logging destinations. @@ -408,7 +326,7 @@ Certain properties of the application can be controlled (e.g user prefs file loc The find feature allows the user to search for a spending based on specified field. If search results are too broad, fields may be combined to increase specificity. -For example, `find n/Apple c/2.50-3.00` will find an `Apple` of cost range `2.00` to `3.00`. +For example, `find n/Apple c/2.50-3.00` will find an `Apple` of cost range $`2.50` to $`3.00`. ==== Implementation @@ -418,15 +336,31 @@ The `FindCommandParser` class stores these predicates, which are combined using The sequence diagram below demonstrates how the `find` command is executed: -.Sequence diagram for an example find command -image::FindSequenceDiagram.png[Find Sequence Diagram] +.Sequence diagram for an example `find` command +image::FindSequenceDiagram.png[Find Sequence Diagram,width=75%] + +The following steps explain the sequence diagram: + +1. The user enters `find n/apple`. +2. `LogicManager` calls `SpendingBookParser#parseCommand()`. +3. `FindCommandParser` is created and validates user input, creating a list of `predicates`. +4. `FindCommand` receives `predicates` and stores it in a list. +5. On `execute()`, `predicates` are reduced and `Model#updateFilteredSpendingList(predicate)` is called to refresh the displayed list. NOTE: The lifeline for `FindCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. -The following activity diagram summarises what happens when the user uses the `find` command: +To summarise what happens when the user uses the `find` command, the following activity diagram is shown below: -.Activity diagram for an example find command -image::FindActivityDiagram.png[Find Activity Diagram] +.Activity diagram for an example `find` command +image::FindActivityDiagram.png[Find Activity Diagram,width=75%] + +The following steps explain the activity diagram: + +1. The user executes the `find` command. +2. If there are valid inputs, each field from the input is saved as predicates into a predicate list. +3. Else, there are two cases. +.. If there is an invalid field, display an error message for the invalid field. +.. If there is a missing field, display an error message for the missing field. ==== Design Considerations @@ -468,15 +402,31 @@ image::SortPackageDiagram.png[Sort Package Diagram] The sequence diagram below demonstrates how the `sort` command is executed: -.Sequence diagram for an example sort command -image::SortSequenceDiagram.png[Sort Sequence Diagram] +.Sequence diagram for an example `sort` command +image::SortSequenceDiagram.png[Sort Sequence Diagram,width=75%] + +The following steps explain the sequence diagram: + +1. The user enters `sort n/ASC`. +2. `LogicManager` calls `SpendingBookParser#parseCommand()`. +3. `SortCommandParser` is created and validates user input, creating a set of `fields`. +4. `SortCommand` receives `fields` and stores it. +5. On `execute()`, `fields` are passed into a `SpendingComparator` object and `Model#updateSortedSpendingList(comparator)` is called to refresh the displayed list. NOTE: The lifeline for `SortCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. The following activity diagram summarises what happens when the user uses the `sort` command: -.Activity diagram for an example sort command -image::SortActivityDiagram.png[Sort Activity Diagram] +.Activity diagram for an example `sort` command +image::SortActivityDiagram.png[Sort Activity Diagram,width=75%] + +The following steps explain the activity diagram: + +1. The user executes the `sort` command. +2. If there are valid fields from the input, each field is saved into a list and determines sort order for `Model`. +3. Else, there are two cases. +.. If there is an invalid field, display an error message for the invalid field. +.. If there is a missing field, display an error message for the missing field. ==== Design Considerations @@ -527,7 +477,7 @@ e.g. `dreminder 1` - delete the first reminder in the reminder list shown in UI. Below is the activity diagram describing the steps take by MoneyGoWhere when it receives `AddReminderCommand`. .Activity diagram for adding a reminder -image::AddReminderActivityDiagram.png[] +image::AddReminderActivityDiagram.png[width=75%] [NOTE] In the above diagram, it can be seen that respective error messages will be shown for invalid inputs. @@ -535,7 +485,7 @@ In the above diagram, it can be seen that respective error messages will be show Shown below is the sequence diagram containing the interactions between respective components in MoneyGoWHere when user inputs `AddReminderCommand`. .Sequence diagram while user attempts to add a new reminder -image::AddReminderSequenceDiagram.png[] +image::AddReminderSequenceDiagram.png[width=75%] [NOTE] The above sequence diagram demonstrates how a new reminder is constructed from valid user input. @@ -543,7 +493,7 @@ The above sequence diagram demonstrates how a new reminder is constructed from v Following is the activity diagram including the series of actions performed by MoneyGoWhere when it receives `DeleteReminderCommand` .Activity diagram for removing a reminder -image::DeleteReminderActivityDiagram.png[] +image::DeleteReminderActivityDiagram.png[width=75%] [NOTE] The negative index from user input will leads to invalid command format error. @@ -551,7 +501,7 @@ The negative index from user input will leads to invalid command format error. The below sequence diagram summarize the interactions between different components when user enter `DeleteReminderCommand`. .Sequence diagram while user attempt to remove a reminder -image::DeleteReminderSequenceDiagram.png[] +image::DeleteReminderSequenceDiagram.png[width=75%] [NOTE] The above diagram also highlights how logic and model components interact with each other while deleting a reminder. @@ -565,7 +515,7 @@ Given below is the Sequence Diagram for interactions within the `Logic` componen `execute("import p/validSpending.csv")` .Interactions Inside the Logic Component for the `import` Command -image::ImportSequenceDiagram.png[] +image::ImportSequenceDiagram.png[width=75%] //When a user gives an `import` command, the application will start processing the request by calling the `LogicManager`. //It will then call the `SpendingBookParser`, which parses the command string. @@ -582,7 +532,7 @@ Following that, the application will then prints an output, showing the result o The following activity diagram summarizes what happens when a user executes an import command: .Import Feature Activity Diagram -image::ImportActivityDiagram.png[] +image::ImportActivityDiagram.png[width=25%] When a user calls the `import` command and inputs a valid `.csv` file, the application will read and parses all the data inside the file and save them to the `SpendingBookList` and `moneygowhere.json`. @@ -604,6 +554,95 @@ Cell Formatting ** """yummy"", ""juicy""" ** """fresh"", ""clean""" +// tag::undoredo[] +=== [Proposed] Undo/Redo feature +==== Proposed Implementation + +The undo/redo mechanism is facilitated by `VersionedSpendingBook`. +It extends `SpendingBook` with an undo/redo history, stored internally as an `spendingBookStateList` and `currentStatePointer`. +Additionally, it implements the following operations: + +* `VersionedSpendingBook#commit()` -- Saves the current spending book state in its history. +* `VersionedSpendingBook#undo()` -- Restores the previous spending book state from its history. +* `VersionedSpendingBook#redo()` -- Restores a previously undone spending book state from its history. + +These operations are exposed in the `Model` interface as `Model#commitSpendingBook()`, `Model#undoSpendingBook()` and `Model#redoSpendingBook()` respectively. + +Given below is an example usage scenario and how the undo/redo mechanism behaves at each step. + +Step 1. The user launches the application for the first time. The `VersionedSpendingBook` will be initialized with the initial spending book state, and the `currentStatePointer` pointing to that single spending book state. + +image::UndoRedoState0.png[] + +Step 2. The user executes `delete 5` command to delete the 5th Spending in the spending book. The `delete` command calls `Model#commitSpendingBook()`, causing the modified state of the spending book after the `delete 5` command executes to be saved in the `spendingBookStateList`, and the `currentStatePointer` is shifted to the newly inserted spending book state. + +image::UndoRedoState1.png[] + +Step 3. The user executes `add n/David ...` to add a new Spending. The `add` command also calls `Model#commitSpendingBook()`, causing another modified spending book state to be saved into the `spendingBookStateList`. + +image::UndoRedoState2.png[] + +[NOTE] +If a command fails its execution, it will not call `Model#commitSpendingBook()`, so the spending book state will not be saved into the `spendingBookStateList`. + +Step 4. The user now decides that adding the Spending was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#spendingBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous spending book state, and restores the spending book to that state. + +image::UndoRedoState3.png[] + +[NOTE] +If the `currentStatePointer` is at index 0, pointing to the initial spending book state, then there are no previous spending book states to restore. The `undo` command uses `Model#canUndoSpendingBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo. + +The following sequence diagram shows how the undo operation works: + +image::UndoSequenceDiagram.png[] + +NOTE: The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram. + +The `redo` command does the opposite -- it calls `Model#redoSpendingBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the spending book to that state. + +[NOTE] +If the `currentStatePointer` is at index `spendingBookStateList.size() - 1`, pointing to the latest spending book state, then there are no undone spending book states to restore. The `redo` command uses `Model#canRedoSpendingBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo. + +Step 5. The user then decides to execute the command `list`. Commands that do not modify the spending book, such as `list`, will usually not call `Model#commitSpendingBook()`, `Model#undoSpendingBook()` or `Model#redoSpendingBook()`. Thus, the `SpendingBookStateList` remains unchanged. + +image::UndoRedoState4.png[] + +Step 6. The user executes `clear`, which calls `Model#commitSpendingBook()`. Since the `currentStatePointer` is not pointing at the end of the `SpendingBookStateList`, all spending book states after the `currentStatePointer` will be purged. We designed it this way because it no longer makes sense to redo the `add n/David ...` command. This is the behavior that most modern desktop applications follow. + +image::UndoRedoState5.png[] + +The following activity diagram summarizes what happens when a user executes a new command: + +image::CommitActivityDiagram.png[] + +==== Design Considerations + +===== Aspect: How undo & redo executes + +* **Alternative 1 (current choice):** Saves the entire spending book. +** Pros: Easy to implement. +** Cons: May have performance issues in terms of memory usage. +* **Alternative 2:** Individual command knows how to undo/redo by itself. +** Pros: Will use less memory (e.g. for `delete`, just save the Spending being deleted). +** Cons: We must ensure that the implementation of each individual command are correct. + +===== Aspect: Data structure to support the undo/redo commands + +* **Alternative 1 (current choice):** Use a list to store the history of spending book states. +** Pros: Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project. +** Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both `HistoryManager` and `VersionedSpendingBook`. +* **Alternative 2:** Use `HistoryManager` for undo/redo +** Pros: We do not need to maintain a separate list, and just reuse what is already in the codebase. +** Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as `HistoryManager` now needs to do two different things. +// end::undoredo[] + +// tag::dataencryption[] +=== [Proposed] Data Encryption + +_{Explain here how the data encryption feature will be implemented}_ + +// end::dataencryption[] + == Documentation Refer to the guide <>. diff --git a/docs/UserGuide.adoc b/docs/UserGuide.adoc index a5480785d98..276c4818321 100644 --- a/docs/UserGuide.adoc +++ b/docs/UserGuide.adoc @@ -18,7 +18,7 @@ By: `Team CS2103T-F13-3` Since: `Sep 2019` Licence: `MIT` == Introduction -*MoneyGoWhere* is a personal finance application targeted at students who have yet to earn a stable income. +*MoneyGoWhere* is a personal finance application targeted to students at the National University of Singapore (NUS). It allows students to keep track of all their spending and their related information such as date, cost and tags. Users can also set budget goals, view statistics, set reminders for bills and export their data to a .csv file. With an easy-to-use Graphical User Interface (GUI) and employment of Command Line Interface (CLI), users can easily navigate through the application, contributing to its user-friendliness and efficiency. @@ -48,7 +48,7 @@ Useful information for a deeper understanding of the command. . Ensure you have Java `11` or above installed in your Computer. . Download the latest `MoneyGoWhere.jar` link:{repoURL}/releases[here]. . Copy the file to the folder you want to use as the home folder for MoneyGoWhere. -. Double-click the file to start the app. The GUI should appear in a few seconds as shown below. +. Double-click the file to start the app. The GUI should appear in a few seconds as shown in `Figure 1`. + .User Interface of MoneyGoWhere @@ -86,43 +86,48 @@ Format: `help` [TIP] Optionally, you can press kbd:[F1] or click `help` which can be found on the menu bar at the top left hand corner of the application. +The following image shows how the help bar can be accessed: + +[.text-center] .Accessing Help from Menu Bar image::help.png[width="300"] -=== Flexible date format +Help can be accessed from the menu bar by clicking on the `Help` button. + +=== Flexible date formats Whenever a particular command requires a `DATE` field, you can choose either of the following formats. -* Formal Dates +* *Formal Dates* ** 1978-01-28 ** 1984/04/02 ** 1/02/1980 ** 26/2/2019 -* Relaxed Dates +* *Relaxed Dates* ** The 31st of April in the year 2008 ** Fri, 21 Nov 1997 ** Jan 21,'97 ** jan 1st ** february twenty-eight -* Relative Dates +* *Relative Dates* ** next thursday/ last wednesday ** today/ tomorrow/ yesterday ** next week/ next month / next year ** 3 days from now ** three weeks ago -* Date Alternatives +* *Date Alternatives* ** next wed or thurs ** oct 3rd or 4th -* Prefixes +* *Prefixes* ** day after/ the day before ** the monday after/ the monday before ** 2 fridays before/ 4 tuesdays after [NOTE] -You do not need to specify which date format you would like to use as the application will be able to differentiate it from the input received. +You do not need to specify which date format you would like to use as MoneyGoWhere will be able to differentiate it from the input received. [NOTE] -The application will also automatically check whether a given date is valid. +MoneyGoWhere will also automatically check whether a given date is valid. Should you accidentally provide an invalid date such as 31/02/2019, it will be rejected as there are only 28 days in February 2019. === Adding a spending : `add` @@ -256,7 +261,7 @@ COST_MIN must be smaller or the same as COST_MAX. **** -Example: +Examples: * `find n/apple c/1.50-2.00 d/01/09/2019 d/30/09/2019` + Returns a list of spending with `apple` keyword within the cost range `1.50` to `2.00` and date range within `01/09/2019` to `30/09/2019`. @@ -275,7 +280,7 @@ Displays a list of all tags. + Format: `ltags` === Setting monthly budget : `budget` -Sets a monthly budget for the current month in Singapore dollars. + +Sets a budget for the current month in Singapore dollars. + Format: `budget MONTHLY_BUDGET` + [NOTE] @@ -459,15 +464,18 @@ Format: `exit` == Glossary -* Spending: An expense incurred by the user. * Budget: The maximum amount of money set by the user to spend. +** Safe: The user has spent less or equal to his budget set. +** Deficit: The user has spent more than his budget set. * Cost: Money spent by the user. -* Safe: The user has spent less or equal to his budget set. -* Deficit: The user has spent more than his budget set. +* Spending: An expense incurred by the user. == Command Summary -[width="100%",cols="20%,<30%",options="header",] +Listed below is a summary of all available commands. + +.Command Summary table +[width="100%",cols="20%,<30%",options="header"] |======================================================================= |Feature | Command | *Help* | `help` + @@ -505,3 +513,5 @@ e.g. `dreminder 2` | *Clear*| `clear` + | *Exit*| `exit` + |======================================================================= + +The command summary above displays all commands available in MoneyGoWhere. diff --git a/docs/diagrams/FindActivityDiagram.puml b/docs/diagrams/FindActivityDiagram.puml index 7d14d7b7286..72e40bd8f9c 100644 --- a/docs/diagrams/FindActivityDiagram.puml +++ b/docs/diagrams/FindActivityDiagram.puml @@ -10,9 +10,9 @@ if () then ([valid fields present]) :Combine Predicate List to form a single predicate; :Update Model based on predicate; else ([else]) - if () then([invalid field present]) + if () then([invalid field]) :Display error message for invalid field; - else ([missing field present]) + else ([missing field]) :Display error message for missing field; endif endif diff --git a/docs/diagrams/FindSequenceDiagram.puml b/docs/diagrams/FindSequenceDiagram.puml index 604037a1255..b27ea90133f 100644 --- a/docs/diagrams/FindSequenceDiagram.puml +++ b/docs/diagrams/FindSequenceDiagram.puml @@ -6,7 +6,7 @@ participant ":LogicManager" as LogicManager LOGIC_COLOR participant ":SpendingBookParser" as SpendingBookParser LOGIC_COLOR participant ":FindCommandParser" as FindCommandParser LOGIC_COLOR participant "f:FindCommand" as FindCommand LOGIC_COLOR -participant ":SpendingPredicateList" as SpendingPredicateList LOGIC_COLOR +participant ":List>" as SpendingPredicateList LOGIC_COLOR participant ":CommandResult" as CommandResult LOGIC_COLOR end box @@ -58,7 +58,7 @@ deactivate SpendingBookParser LogicManager -> FindCommand : execute() activate FindCommand -FindCommand -> FindCommand : reduce() +FindCommand -> FindCommand : predicates.reduce(Predicate::and) activate FindCommand FindCommand --> FindCommand : predicate diff --git a/docs/diagrams/SortActivityDiagram.puml b/docs/diagrams/SortActivityDiagram.puml index 67d7b625bee..e9b0598bcf1 100644 --- a/docs/diagrams/SortActivityDiagram.puml +++ b/docs/diagrams/SortActivityDiagram.puml @@ -9,9 +9,9 @@ if () then ([valid fields present]) :Determine sort order in parser based on given fields; :Update Model based on the sort order; else ([else]) - if () then([invalid field present]) + if () then([invalid field]) :Display error message for invalid field; - else ([missing field present]) + else ([missing field]) :Display error message for missing field; endif endif diff --git a/docs/images/DeleteSequenceDiagram.png b/docs/images/DeleteSequenceDiagram.png index fa327b39618..50cae889ae9 100644 Binary files a/docs/images/DeleteSequenceDiagram.png and b/docs/images/DeleteSequenceDiagram.png differ diff --git a/docs/images/FindActivityDiagram.png b/docs/images/FindActivityDiagram.png index 2086591c660..91ba83d9cb5 100644 Binary files a/docs/images/FindActivityDiagram.png and b/docs/images/FindActivityDiagram.png differ diff --git a/docs/images/FindSequenceDiagram.png b/docs/images/FindSequenceDiagram.png index 96b1d63ccbc..4f4d6aacf0f 100644 Binary files a/docs/images/FindSequenceDiagram.png and b/docs/images/FindSequenceDiagram.png differ diff --git a/docs/images/SortActivityDiagram.png b/docs/images/SortActivityDiagram.png index e894c128a22..512fe1055c4 100644 Binary files a/docs/images/SortActivityDiagram.png and b/docs/images/SortActivityDiagram.png differ