anchor.diff:  [[Design-Storage]]
   === Storage component
   
  +.Structure of the Storage Component
   image::StorageClassDiagram.png[width="800"]
  -_Figure 2.5.1 : Structure of the Storage Component_
   
   *API* : link:{repoURL}/src/main/java/seedu/address/storage/Storage.java[`Storage.java`]
   
  
positive.code: 
  For example, the `Logic` component (see the class diagram given below) defines it's API in the `Logic.java` interface and exposes its functionality using the `LogicManager.java` class.
  
  image::LogicClassDiagram.png[width="800"]
  _Figure 2.1.2 : Class Diagram of the Logic Component_
  
  [discrete]
  ==== Events-Driven nature of the design
  
  The _Sequence Diagram_ below shows how the components interact for the scenario where the user issues the command `delete 1`.
  
  image::SDforDeletePerson.png[width="800"]
  _Figure 2.1.3a : Component interactions for `delete 1` command (part 1)_
  
  [NOTE]
  Note how the `Model` simply raises a `AddressBookChangedEvent` when the Address Book data are changed, instead of asking the `Storage` to save the updates to the hard disk.
  
  The diagram below shows how the `EventsCenter` reacts to that event, which eventually results in the updates being saved to the hard disk and the status bar of the UI being updated to reflect the 'Last Updated' time.
  
  image::SDforDeletePersonEventHandling.png[width="800"]
  _Figure 2.1.3b : Component interactions for `delete 1` command (part 2)_
  
  [NOTE]
  Note how the event is propagated through the `EventsCenter` to the `Storage` and `UI` without `Model` having to be coupled to either of them. This is an example of how this Event Driven approach helps us reduce direct coupling between components.
  
negative.code: [[Design-Architecture]]
  === Architecture
  
  .Architecture Diagram
  image::Architecture.png[width="600"]
  
  The *_Architecture Diagram_* given above explains the high-level design of the App. Given below is a quick overview of each component.
  
  