CSC207-2023Y-UofT · aricasas · Aug 16, 2023 · Aug 14, 2023 · Aug 14, 2023 · Aug 14, 2023
diff --git a/README.md b/README.md
@@ -4,9 +4,13 @@
 
 - [Overview](#overview)
 - [Key Features](#key-features)
-- [Abbreviations](#abbreviations)
 - [Usage](#usage)
   - [Installation](#installation)
+  - [Screens](#screens)
+- [Implementation](#implementation)
+  - [Code Structure](#code-structure)
+  - [Testing](#testing)
+  - [JavaDoc](#javadoc)
 - [Clean Architecture Specifications](#clean-architecture-specifications)
   - [Clean Architecture Violations](#clean-architecture-violations)
   - [SOLID Principles](#solid-principles)
@@ -52,55 +56,109 @@ accumulated remain preserved and accessible over time.
 4. Compile the project: `javac Main.java`
 5. Run the project: `java Main`
 
-## Abbreviations
+### Screens
 
-| Name              | Abbreviation |
-|-------------------|--------------|
-| Controller        | C            |
-| UseCaseInteractor | UCI          |
-| InputBoundary     | IB           |
-| InputData         | ID           |
-| OutputBoundary    | OB           |
-| OutputData        | OD           |
-| Presenter         | P            |
-| ViewBoundary      | VB           |
-| View              | V            |
-| Gateway           | G            |
+![session_load.png](images/session_load.png)
 
+![main_menu.png](images/main_menu.png)
+
+![month_menu.png](images/month_menu.png)
+
+![add_category.png](images/add_category.png)
+![edit_category.png](images/edit_category.png)
+
+![add_expense.png](images/add_expense.png)
+![edit_expense.png](images/edit_expense.png)
+
+![graphical_summary.png](images/graphical_summary.png)
+
+## Implementation
+
+### Code Structure
+The whole project is built by following the MVC design pattern. We have divided our classes into three main packages:
+`entities`, `use_cases`, and `views`. The three of them correspond to different layers of Clean Architecture.
+
+Firstly, the `entities` package corresponds to the Enterprise Business Rules layer. It contains all the basic entity
+object types (`Expense`, `Category`, `MonthlyStorage`, `SessionStorage`), an exception type used for errors related to
+the entities (`EntityException`), and the factory classes used to build `Category` and `Expense` objects.
+
+Secondly, the `use_cases` package corresponds to the Application Business Rules layer. It contains the use case
+interactors for all of our features, and their corresponding input boundary, input data, output boundary, and
+output data. In addition, the `generate_summary_use_case` subpackage contains an extra class used to help in generating
+the statistical data it needs, and the `session_load` subpackage also contains an interface used to communicate with our
+file storage gateway.
+
+Finally, the `views` package corresponds to both the Interface Adapters, and Frameworks & Drivers layers. It contains
+the view, controller and presenter classes for all of our features. Additionally, this package also holds our
+file storage gateway, which is the class that handles loading and saving session files.
+
+There is a `Main` file outside the packages, which builds the program windows and screens, and displays the UI.
+
+### Testing
+This project uses JUnit as its testing framework. All the tests are contained inside the `src/test/java` directory.
+It contains tests for the entity classes, use case interactor classes, and the file storage gateway. It doesn't contain
+any tests for most of our `view` package, since the classes contained in it are view, presenter, and controller classes.
+View classes contain UI elements that can't really be tested in any way other than by being looked at, and 
+presenter/controller classes only pass data around without much logic to be tested.
+
+To run tests: 
+1. Open the project in IntelliJ.
+2. Open the 'Project' panel on the left.
+3. Right-click `src/main/test` directory and select `Run 'Tests in 'course-project-DoorKeepers.test''`
+
+To run any specific testing class, navigate to it in the 'Project' panel in IntelliJ, right-click it, and 
+select `Run 'ClassNameTest'`.
+
+Test coverage can be seen below:
+
+![test_coverage.png](images/test_coverage.png)
+
+The full report is contained inside the `reports/coverageReport` directory.
+
+### JavaDoc
+The project uses the JavaDoc framework to provide documentation for all of our methods, classes, and interfaces. 
+This documentation is written into the code, but we also provide generated documentation pages inside our 
+`reports/JavaDoc` directory.
 
 ## Clean Architecture Specifications
 
 ### Clean Architecture Violations
-- Expense and Category are basic object types we have for conveying information that are not separable. For instance, an 
-expense called "Walmart" would have no meaning unless we know the specific amount of money spent shopping in Walmart. 
-These classes belong to the Entity layer, but are passed around in both the use_case and views packages, which is a 
-Clean Architecture violation. We could remove the imports to these entities, and change the output data to Object[][] 
-type in the UpdateViewUCI to accommodate Java Swing requirements. However, we thought it is not adhering to SOLID 
-principle from the point that Object[][] may not be the type required by other view libraries that could be imported, 
-which is in contrary to the Open/Closed Principle.
-- SessionStorage is an object type used to hold all information contained in the user's session. Every time a use case 
-is called, the interactor of that use case needs to access the information within the SessionStorage object. Thus, it 
+- `Expense` and `Category` are basic object types we have for conveying information that are not separable. 
+For instance, an expense called "Walmart" would have no meaning unless we know the specific amount of money spent 
+shopping in Walmart. These classes belong to the Entity layer, but are passed around in both the `use_case` and `views` 
+packages, which is a Clean Architecture violation. We could remove the imports to these entities, and change the output
+data to `Object[][]` type in the `UpdateViewUseCaseInteractor` to accommodate Java Swing requirements. 
+However, we thought it is not adhering to SOLID principle from the point that `Object[][]` may not be the type required 
+by other view libraries that could be imported, which is in contrary to the Open/Closed Principle.
+- `SessionStorage` is an object type used to hold all information contained in the user's session. Every time a use case 
+is called, the interactor of that use case needs to access the information within the `SessionStorage` object. Thus, it 
 needs to be passed throughout all layers of our program, despite being a violation of Clean Architecture.
 
 ### SOLID Principles
 - **Single Responsibility Principle:** All classes are acted upon by a single actor and adhere to this principle.
-- **Open-Closed Principle:** Since our classes with main functionality implement IB and OB interfaces, the user is able 
-to modify any interactor or presenter as they see fit. For example, if the user wanted to implement another view that 
-generates statistical data with all months they could create another interactor to do that.
-- **Liskov Substitution Principle:** All of our IB and OB objects adhere to this principle. In order to adhere to the 
-DIP, the interactors and presenters are cast to the IB and OB, respectively. This demonstrates the LSP, as any class 
-that implements these interfaces can be used. Another example is the LoadMonthMenuVB, which 
+- **Open-Closed Principle:** Since our classes with main functionality implement Input Boundary and Output Boundary
+interfaces, the user is able to modify any interactor or presenter as they see fit. For example, if the user wanted to 
+implement another view that generates statistical data with all months they could create another interactor to do that.
+- **Liskov Substitution Principle:** All of our Input Boundary and Output Boundary objects adhere to this principle. 
+In order to adhere to the Dependency Inversion Principle, the interactors and presenters are cast to the Input Boundary 
+and Output Boundary, respectively. This demonstrates the LSP, as any class that implements these interfaces can be used.
 - **Interface Segregation Principle:** All of our interfaces adhere to this rule, as they are all small and contain only
 the necessary methods needed.
 - **Dependency Inversion Principle:** All classes have a boundary between every layer in Clean Architecture, to create 
 the dependency inversion.
 
 ### Design Patterns
-- The Facade design pattern is used to implement the GenerateSummaryUCI to delegate tasks to the 
-GenerateSummaryUCInterpreter for generating the statistical data, and the GenerateSummaryP for returning it.
-- In the future, we could implement the Factory design pattern to implement the Add/Edit Categories and Add/Edit 
-Expenses.
+- All of our features are implemented using the MVC design pattern. We chose the MVC design pattern to help us organize
+our code in a way that clearly separates the Clean Architecture layers. The Model, View, and Controller concepts
+in MVC clearly separate responsibilities, and they organize dependencies such that they only point inwards. 
+Furthermore, using MVC for all our features helped us keep them with a consistent structure, even if they
+were implemented separately.
+- The Factory design pattern is used to implement the Add/Edit Category and Add/Edit Expense features. We chose to add 
+this implementation to avoid tight coupling between the creators (`ExpenseUseCaseInteractor` and 
+`CategoryUseCaseInteractor`) and their products (`Expense` and `Category`). This choice helps our code adhere to the 
+Open/Closed Principle, since we can introduce new types of `MonthObject`s into the code and avoid breaking our current
+implementation. Additionally, it adheres to the Single Responsibility Principle, as the product creation code is moved
+to a separate class, allowing the Use Case Interactors to focus on error handling and post-creation tasks.
 
 ## Authors
-
-This project was created by Ari, Katarina, Lulu, and Yin for [CSC207] Software Design at the University of Toronto.
+This project was created by Ari, Katarina, Lulu, and Yin for [CSC207] Software Design at the University of Toronto.
diff --git a/images/add_category.png b/images/add_category.png
diff --git a/images/add_expense.png b/images/add_expense.png
diff --git a/images/closed_issue.png b/images/closed_issue.png
diff --git a/images/closed_project.png b/images/closed_project.png
diff --git a/images/create_branch.png b/images/create_branch.png
diff --git a/images/create_pr.png b/images/create_pr.png
diff --git a/images/create_project.png b/images/create_project.png
diff --git a/images/edit_category.png b/images/edit_category.png
diff --git a/images/edit_expense.png b/images/edit_expense.png
diff --git a/images/graphical_summary.png b/images/graphical_summary.png
diff --git a/images/link_branch.png b/images/link_branch.png
diff --git a/images/link_project.png b/images/link_project.png
diff --git a/images/main_menu.png b/images/main_menu.png
diff --git a/images/month_menu.png b/images/month_menu.png
diff --git a/images/new_issue.png b/images/new_issue.png
diff --git a/images/new_pr.png b/images/new_pr.png
diff --git a/images/rename.png b/images/rename.png
diff --git a/images/session_load.png b/images/session_load.png
diff --git a/images/set_tags.png b/images/set_tags.png
diff --git a/images/test_coverage.png b/images/test_coverage.png
diff --git a/project_plan_dev.md b/project_plan_dev.md