Remove dead links in DG

docs/DeveloperGuide.adoc

@@ -17,9 +17,10 @@ endif::[]
 
 By: `AY1920-CS2103-W15-3`      Since: `Apr 2020`      Licence: `MIT`
 
-== Setting up
+== Introduction
+TAble is your handy desktop app, optimized for TAs who prefer to work with a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI)! Mark attendance, arrange consults, add module notes, set reminders and more with TAble! It has a GUI created with JavaFX and written in Java, and has about 20 kLoC.
 
-Refer to the guide <<SettingUp#, here>>.
+This document serves as a technical guide to developers who wish to understand the internal mechanisms of TAble or modify/extend the application.
 
 == Design
 
@@ -115,7 +116,7 @@ NOTE: The lifeline for `DeleteCommandParser` should end at the destroy marker (X
 [[Design-Model]]
 === Model component
 
-.Structure of the Model Component
+.Structure of the Model Component. Only the full details of Student is featured in this diagram for clarity.
 image::ModelClassDiagram.png[]
 
 *API* : link:{repoURL}/src/main/java/seedu/address/model/Model.java[`Model.java`]
@@ -130,7 +131,7 @@ The `Model`,
 [[Design-Storage]]
 === Storage component
 
-.Structure of the Storage Component
+.Structure of the Storage Component. The full structure is only shown for Consults for clarity.
 image::StorageClassDiagram.png[]
 
 *API* : link:{repoURL}/src/main/java/seedu/address/storage/Storage.java[`Storage.java`]
@@ -154,7 +155,7 @@ This section describes some noteworthy details on how certain features are imple
 *TAble* allows NUS SoC teaching assistants to track and record all modules that they are teaching. Users can leave notes on the modules that they are teaching and store a list of links for the module that are useful for reference.
 
 ==== Implementation
-A module can be stored as a Mod object in TAble (renamed due to naming restrictions on Java keywords). The main components are the module code, which is used to identify unique modules, and module name. Mod can also store the user's notes of the module through its description parameter, as well as a list of module links which are relevant to the course.
+A module can be stored as a Mod object in *TAble* (renamed due to naming restrictions on Java keywords). The main components are the module code, which is used to identify unique modules, and module name. Mod can also store the user's notes of the module through its description parameter, as well as a list of module links which are relevant to the course.
 
 .Class diagram of 'Mod' feature, displaying only directly related classes
 image::ModClassDiagram.png[]
@@ -164,7 +165,7 @@ The following sequence diagram shows how notes of a module can be updated with t
 .Sequence diagram of updating Mod notes
 image::NoteModSequenceDiagram.png[]
 
-Module links are stored as ModLink objects in TAble. The collection of ModLinks are stored as `List<ModLinkPair>` (where a ModLinkPair is actually a class wrapper for a Pair<String, ModLink> object) since each module link can be described differently. This allows for more flexibility in naming the module links, rather than solely using an index based notation, and ensures that the order of addition into the collection is maintained. The activity diagram of adding module links is shown below.
+Module links are stored as ModLink objects in *TAble*. The collection of ModLinks are stored as `List<ModLinkPair>` (where a ModLinkPair is actually a class wrapper for a Pair<String, ModLink> object) since each module link can be described differently. This allows for more flexibility in naming the module links, rather than solely using an index based notation, and ensures that the order of addition into the collection is maintained. The activity diagram of adding module links is shown below.
 
 .Activity diagram of adding ModLinks to Mod
 image::AddModLinkActivityDiagram.png[]
@@ -181,12 +182,12 @@ Users can then view the information associated with a Mod object by using the `v
 |*Alternative 2 :* Delete module together with its associated tutorials
 
 |*Pros*
-|Informs user if there are any dependencies between module to be deleted and tutorials in TAble.
+|Informs user if there are any dependencies between module to be deleted and tutorials in *TAble*.
 |Fast deletion of module and related objects.
 
 |*Cons*
 |User needs to individually delete associated tutorials before module can be deleted.
-|Information in TAble will be lost easily as user may not be aware of such an association. As there is no undo command, it will not be easy to undo this command and revert TAble to its original state.
+|Information in *TAble* will be lost easily as user may not be aware of such an association. As there is no undo command, it will not be easy to undo this command and revert TAble to its original state.
 |===
 
 Reason for choosing Alternative 1: On a user design perspective, it is not advisable to delete all objects associated with module, as the user may be unaware of these associated objects. By individually confirming the objects to be deleted, the user is made more aware of any information that they may want to export or save first before deleting said information.
@@ -204,7 +205,7 @@ Reason for choosing Alternative 1: On a user design perspective, it is not advis
 
 |*Cons*
 | User needs to open a browser before accessing link.
-| Very distracting when opening link, as focus changes from TAble to browser unexpectedly (depending on when browser loads).
+| Very distracting when opening link, as focus changes from *TAble* to browser unexpectedly (depending on when browser loads).
 |===
 
 Reason for choosing Alternative 1: On a user design perspective, it is less jarring to copy link into the user's clipboard, since the user can choose when they want to access the link and have the flexibility to share the link to others. Additionally, opening a new browser page requires more complicated code that depends on another program.
@@ -483,18 +484,6 @@ We are using `java.util.logging` package for logging. The `LogsCenter` class is
 
 Certain properties of the application can be controlled (e.g user prefs file location, logging level) through the configuration file (default: `config.json`).
 
-== Documentation
-
-Refer to the guide <<Documentation#, here>>.
-
-== Testing
-
-Refer to the guide <<Testing#, here>>.
-
-== Dev Ops
-
-Refer to the guide <<DevOps#, here>>.
-
 [appendix]
 == Product Scope