Sequence Diagrams and System Design

System Initialization: Recipe List

The RecipeApplication initiates the system by calling RecipeList.getInstance().
The getInstance() method within RecipeList then invokes the RecipeList constructor.
The RecipeList constructor is responsible for initializing an ArrayList of Recipe objects.
To populate this list, the RecipeList constructor calls the getDataLoader().getRecipes() method.
The DataLoader processes a JSON file (the mechanics of which are not explicitly illustrated).
Prior to returning the ArrayList of recipes, the DataLoader iterates through the JSON data, calling the Recipe constructor for each individual recipe object as it loads them.
Upon completion, getDataLoader().getRecipes() returns an ArrayList<Recipe> to the RecipeList.
At this point, the RecipeList is considered fully initialized and created.

Similar to the RecipeList, the RecipeApplication constructor also initializes the UserList and User objects.
It begins by calling UserList.getInstance().
This getInstance() method, lacking a direct constructor invocation, proceeds to call the UserList constructor.
The UserList constructor subsequently interacts with the DataLoader to retrieve an ArrayList<User>.
getDataLoader().getUsers() is responsible for creating User objects from the JSON file.
As getDataLoader processes each user entry, it invokes the User constructor to instantiate each user.
Finally, getDataLoader().getUsers() returns the ArrayList<User> to the UserList.
The UserList is now initialized.
Crucially, the entire initialization sequence for both the recipe and user lists is orchestrated by the RecipeApplication constructor.

The primary goal for this illustrative scenario is to leave a compliment, rating, or review on a specific recipe, "banana bread."

The scenario begins with the RecipeApplication calling its login() method.
The login() method expects to receive a username and password (passed via a facade or front-end interface).
A potential security concern is noted where the UserList's getUser() method, which the login() method interacts with, may only accept a username and not a password, requiring a fix.
The UserList.getUser() method likely iterates through its internal ArrayList of users to find a match.
An essential method, such as isUser(String username, String password) or getUsername(), is identified as potentially missing within the User object, needed for proper validation.
After validation, UserList.getUser() returns the validated User object.

Once logged in, the system returns to the RecipeApplication, which calls findRecipes(String keyword) (e.g., "banana").
This method then interacts with the RecipeList.
The RecipeList is expected to have a getRecipesByKeyword(String keyword) method, which takes the search term (e.g., "banana"). This method would need to be added to the class diagram if not already present.
RecipeList.getRecipesByKeyword() returns an ArrayList<Recipe> containing matching recipes, or potentially a single Recipe object if a direct match is found.

With the target recipe (e.g., "banana bread") identified, the next step involves reviewing it.
This process includes adding the new review data to the corresponding Recipe object.
It's noted that Review class instances could either be created during the initial data loading phase by the DataLoader or at the moment a new review is submitted.

The iterative process of constructing sequence diagrams is crucial for identifying 'holes' or missing functionalities in the class diagram.
Identified 'Holes' and Necessary Additions:
- The UserList.getUser() method might require a password parameter for enhanced security (getUser(String username, String password)).
- The RegisteredUser (or parent User) class needs methods like isUser() or getUsername() to facilitate user validation efficiently.
- The RecipeList needs an explicit getRecipesByKeyword(String keyword) method.
- A logout() method must be added to the facade, which in turn calls save() on the UserList, and eventually saveUsers() on the DataWriter to persist user data.
Sequence diagrams serve as a direct tool to ensure all necessary methods and interactions are present and correctly defined in the class diagram.

Sequence diagrams are developed around specific user scenarios to thoroughly test the system's design.
Scenario Examples:
- Current Scenario: A registered user logs in and leaves a compliment/review on "banana bread."
- New User Scenario (e.g., Escape Room application):
- A new user enters the system.
- They create an account.
- They open an escape room.
- They successfully answer a room puzzle.
- Existing User Scenario (e.g., Game application):
- An existing user logs into their account.
- They view their leaderboard to check their standing.
- They open an existing game session.
- They proceed to the next puzzle in the game.
- They might encounter a puzzle where a hint has already been used.
The more detailed and 'rich' the scenarios, the more effectively they will test the class diagram, uncovering missing elements and refining the overall design.
The ultimate goal is to ensure both the class diagram and the sequence diagrams are completely aligned and finalized.

It is highly recommended to work on both the class diagram and sequence diagrams concurrently, iterating between them to refine the design.
Only after both diagrams are thoroughly solidified should the JSON files be created, based exclusively on the finalized class diagram.
Premature creation of JSON files before diagram solidification is discouraged.
Emphasizes the critical importance of a comprehensive upfront design, as coding commences next week (Thursday).
A rushed or poorly thought-out design will lead to a "rough 2 hours of coding" (referring to a significant struggle during implementation).
Encourages in-person collaboration for this complex design phase, as online work is considered less effective for such tasks.

Sequence diagrams graphically illustrate the flow of information and method calls within the system.
They are essential for 'connecting the dots' between different classes and objects.
A primary benefit is the identification of methods that are missing from the class diagram but are necessary for scenario execution.
Thorough design in this phase significantly reduces future coding time and effort.
Typically, at least 2 distinct scenarios are required for robust sequence diagram creation.
Students are reminded to ensure their Git repository is well-organized and polished for submission.