Change svg to png

docs/DeveloperGuide.md

@@ -28,7 +28,7 @@ Refer to the guide [_Setting up and getting started_](SettingUp.md).
 
 ### Architecture
 
-<img src="diagrams/ArchitectureDiagram.svg" width="280" />
+<img src="diagrams/ArchitectureDiagram.png" width="280" />
 
 
 
@@ -57,7 +57,7 @@ The *Sequence Diagram* below shows how the components interact with each other f
 
 
 
-<img src="diagrams/ArchitectureSequenceDiagram.svg" width="574" />
+<img src="diagrams/ArchitectureSequenceDiagram.png" width="574" />
 
 Each of the four main components (also shown in the diagram above),
 
@@ -66,7 +66,7 @@ Each of the four main components (also shown in the diagram above),
 
 For example, the `Logic` component defines its API in the `Logic.java` interface and implements its functionality using the `LogicManager.java` class which follows the `Logic` interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent outside component's being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
 
-<img src="diagrams/ComponentManagers.svg" width="300" />
+<img src="diagrams/ComponentManagers.png" width="300" />
 
 
 The sections below give more details of each component.
@@ -75,7 +75,7 @@ The sections below give more details of each component.
 
 The **API** of this component is specified in [`Ui.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/ui/Ui.java)
 
-<img src="diagrams/UiClassDiagram.svg" alt="Structure of the UI Component"/>
+<img src="diagrams/UiClassDiagram.png" alt="Structure of the UI Component"/>
 
 The UI consists of a `MainWindow` that is made up of parts e.g.`CommandBox`, `ResultDisplay`, `PersonListPanel`, `StatusBarFooter` etc. All these, including the `MainWindow`, inherit from the abstract `UiPart` class which captures the commonalities between classes that represent parts of the visible GUI.
 
@@ -94,11 +94,11 @@ The `UI` component,
 
 Here's a (partial) class diagram of the `Logic` component:
 
-<img src="diagrams/LogicClassDiagram.svg" width="550"/>
+<img src="diagrams/LogicClassDiagram.png" width="550"/>
 
 The sequence diagram below illustrates the interactions within the `Logic` component, taking `execute("delete 1")` API call as an example.
 
-<img src="diagrams/DeleteSequenceDiagram.svg" alt="Interactions Inside the Logic Component for the `delete 1` Command" />
+<img src="diagrams/DeleteSequenceDiagram.png" alt="Interactions Inside the Logic Component for the `delete 1` Command" />
 
 <box type="info" seamless>
 
@@ -114,7 +114,7 @@ How the `Logic` component works:
 
 Here are the other classes in `Logic` (omitted from the class diagram above) that are used for parsing a user command:
 
-<img src="diagrams/ParserClasses.svg" width="600"/>
+<img src="diagrams/ParserClasses.png" width="600"/>
 
 How the parsing works:
 * When called upon to parse a user command, the `AddressBookParser` class creates an `XYZCommandParser` (`XYZ` is a placeholder for the specific command name e.g., `AddCommandParser`) which uses the other classes shown above to parse the user command and create a `XYZCommand` object (e.g., `AddCommand`) which the `AddressBookParser` returns back as a `Command` object.
@@ -123,7 +123,7 @@ How the parsing works:
 ### Model component
 **API** : [`Model.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/model/Model.java)
 
-<img src="diagrams/ModelClassDiagram.svg" width="450" />
+<img src="diagrams/ModelClassDiagram.png" width="450" />
 
 
 The `Model` component,
@@ -137,7 +137,7 @@ The `Model` component,
 
 **Note:** An alternative (arguably, a more OOP) model is given below. It has a `Tag` list in the `AddressBook`, which `Person` references. This allows `AddressBook` to only require one `Tag` object per unique tag, instead of each `Person` needing their own `Tag` objects.<br>
 
-<img src="diagrams/BetterModelClassDiagram.svg" width="450" />
+<img src="diagrams/BetterModelClassDiagram.png" width="450" />
 
 </box>
 
@@ -146,7 +146,7 @@ The `Model` component,
 
 **API** : [`Storage.java`](https://github.com/se-edu/addressbook-level3/tree/master/src/main/java/seedu/address/storage/Storage.java)
 
-<img src="diagrams/StorageClassDiagram.svg" width="550" />
+<img src="diagrams/StorageClassDiagram.png" width="550" />
 
 The `Storage` component,
 * can save both address book data and user preference data in JSON format, and read them back into corresponding objects.
@@ -179,15 +179,15 @@ Given below is an example usage scenario and how the undo/redo mechanism behaves
 
 Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the initial address book state, and the `currentStatePointer` pointing to that single address book state.
 
-<img src="diagrams/UndoRedoState0.svg" alt="UndoRedoState0" />
+<img src="diagrams/UndoRedoState0.png" alt="UndoRedoState0" />
 
 Step 2. The user executes `delete 5` command to delete the 5th person in the address book. The `delete` command calls `Model#commitAddressBook()`, causing the modified state of the address book after the `delete 5` command executes to be saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
 
-<img src="diagrams/UndoRedoState1.svg" alt="UndoRedoState1" />
+<img src="diagrams/UndoRedoState1.png" alt="UndoRedoState1" />
 
 Step 3. The user executes `add n/David …​` to add a new person. The `add` command also calls `Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
 
-<img src="diagrams/UndoRedoState2.svg" alt="UndoRedoState2" />
+<img src="diagrams/UndoRedoState2.png" alt="UndoRedoState2" />
 
 <box type="info" seamless>
 
@@ -197,7 +197,7 @@ Step 3. The user executes `add n/David …​` to add a new person. The `add` co
 
 Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the `undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once to the left, pointing it to the previous address book state, and restores the address book to that state.
 
-<img src="diagrams/UndoRedoState3.svg" alt="UndoRedoState3" />
+<img src="diagrams/UndoRedoState3.png" alt="UndoRedoState3" />
 
 
 <box type="info" seamless>
@@ -209,7 +209,7 @@ than attempting to perform the undo.
 
 The following sequence diagram shows how the undo operation works:
 
-<img src="diagrams/UndoSequenceDiagram.svg" alt="UndoSequenceDiagram" />
+<img src="diagrams/UndoSequenceDiagram.png" alt="UndoSequenceDiagram" />
 
 <box type="info" seamless>
 
@@ -227,15 +227,15 @@ The `redo` command does the opposite — it calls `Model#redoAddressBook()`,
 
 Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
 
-<img src="diagrams/UndoRedoState4.svg" alt="UndoRedoState4" />
+<img src="diagrams/UndoRedoState4.png" alt="UndoRedoState4" />
 
 Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …​` command. This is the behavior that most modern desktop applications follow.
 
-<img src="diagrams/UndoRedoState5.svg" alt="UndoRedoState5" />
+<img src="diagrams/UndoRedoState5.png" alt="UndoRedoState5" />
 
 The following activity diagram summarizes what happens when a user executes a new command:
 
-<img src="diagrams/CommitActivityDiagram.svg" width="250" />
+<img src="diagrams/CommitActivityDiagram.png" width="250" />
 
 #### Design considerations: