Introducing GreenPlate

This domain model represents the classes we have implemented in our app and their respective attributes, offering a comprehensive and easy-to-see view of the structure of our app. Our model consists of a two different 'types' of classes. First, we have the 'entry' type class, or any type of class that can have an instance. This includes the user, recipe, ingredient, and input meal classes, which have individual attributes that depend on user input. The second type of class is the 'database' type class.This includes the user database, meal database, the cookbook (recipes database), the pantry (ingredients database), and the shopping list. These databases are structured using Firebase to store instances of the 'entry' type class accordingly. The domain model shows the relationship between these classes using arrows, multiplicities, and verbs.

The sequence diagram is a model that shows a specific user-system interaction based on one use case. This sequence diagram shows a scenario where a user wants to add an ingredient entry into their pantry. First, the user must use the navigation bar to click on the ingredients section, which is facilitated by Main Activity. From there, the user is able to click the add ingredient button, which calls the addIngredient method, displaying a pop up that allows the user to enter the name, quantity, calories per serving, and expiration date of the ingredient. The system attempts to write this to the ingredient database using Firebase, and this can lead to one of two outcomes: onFail or onSuccess. OnFail is called when adding the ingredient was unsuccessful, due to reasons such as the ingredient being a duplicate, the user entering only whitespace, etc. This will then return an error message to the user describing the issue. OnSuccess is called when adding the ingredient is successful, which then allows the pop up screen to close, and the ingredient to be added to the database.

The Design Class Diagram can be thought of as a more detailed, rigorous extension of the idea of the domain model. In the design class diagram, classes are represented as a box with two sections, the top section being attributes of the class, and the bottom section being methods of the class. The visibility of the attributes and methods are defined by the -, #, or + symbol before them. - represents private, # is protected, and + is public. Defining the visibility in this way provides an easy way to determine how classes are working in interaction with each other. Similar to the domain model, this diagram also uses verbs and multiplicities to describe the relationship, but also includes the directionality. The lines and arrows of the diagram also define the relationship between classes. For example, the dotted open arrow connecting the ingredients database and the ingredients fragment indicates a dependency relationship, while the white diamond arrow from recipes fragment to recipes activity indicates an aggregational relationship. Thus, the DCD provides a comprehensive view into the intricate details of the app's classes.