Bp 127 requirements document feedback 2 system architecture

documentation/docs/system-architecture/class-diagram.md

@@ -0,0 +1,183 @@
+---
+sidebar_position: 1
+---
+
+# Class Diagram
+
+```mermaid
+---
+title: BlastPad Class Diagram
+---
+classDiagram
+    BlocklyEditor o-- "0..*" Game
+	UserManager --o "0..*" Database
+	Classroom o-- "0..*" Game
+	DeviceManager <-- "1" UserManager
+	BlocklyEditor o-- "0..*" Block
+	Database o-- "0..*" Classroom
+	BlocklyEditor o-- "1" Documentation
+	Gallery <-- "1" ClassroomManager
+	Gallery <-- "1" BlocklyEditor	
+	ClassroomManager *-- "0..*" Classroom
+	Block <-- "0..*" Sensor
+	Gallery <-- "1" Configuration	
+	DeviceManager <-- "1" Gallery
+	Game <-- "1" CodeCompiler
+
+    class Game{
+        -title: String
+		-imageFile: String
+        -version: String
+		-author: String
+
+		+startGame()
+		+pauseGame()
+		+quitGame()
+		+uploadToClassroom(Classroom)
+		+compileGame() String
+    }
+    class BlocklyEditor{
+        -workspaces: Game[]
+		-availableBlocks: Block[]
+
+		+saveWorkspace()
+		+loadWorkspace(game: Game)
+    }
+    class Block {
+        +type: String
+		+message0: String
+		+message1: String
+		+args0: Object[]
+		+args1: Object[]
+		+previousStatement: String
+		+nextStatment: String
+		+tooltip: String
+		+helpurl: String
+		+style: String
+    }
+    class Sensor {
+		+sensorID: int
+		-sensorData: int[]
+		-calibration: Boolean
+
+		+getSensorData(): int[]
+		+recalibrateSensor()
+		+clearSensorData()
+    }
+    class Classroom {
+        +classroomID: int
+		+teacherID: int
+
+		+deleteGame(userID: int) bool
+		+approveGame(userID: int) bool
+		+uploadGame(game: Game)
+    }
+	class ClassroomManager {
+		-classrooms: Classroom[]
+
+		+joinClassroom(c: Classroom) bool
+		+leaveClassroom(c: Classroom) bool
+		+viewClassrooms()
+	}
+	class UserManager {
+    	-String: username
+		-String: password
+		+login(username: String, password: String) bool
+		+createAccount(username: String, password: String) bool
+    }
+    class Configuration {
+		+connectionStatus: Boolean
+		+listOfAvailNetworks: String[]
+		+SSID: String
+		-securityKey: String
+
+		+scan() String[]
+		+connect(SSID: String, securityKey: String)
+		+close()
+    }
+    class Gallery {
+    	+openCodeEditor()
+		+openConfiguration()
+		+viewClassrooms()
+		+viewGames() Games[]
+
+    }
+    class Documentation {
+		+header: String
+    	+body: String
+
+		+loadContent(type: String) String
+	}
+	class DeviceManager {
+		+currentScreen: String
+
+		+loadGallery()
+	}
+	class Database {
+		-users: User[]
+		-classroom: Classroom[]
+
+		+addUser()
+		+removeUser()
+		+addClassroom()
+		+removeClassroom()
+	}
+	class CodeCompiler {
+		+compileBlocklytoPython()
+	}
+```
+
+## Class Relationships
+
+The class diagram above demonstrates various relationships between classes within the BlastPad system. The **User** class is associated with the **DeviceManager** class, indicating that a user can interact with the device via the device manager. The **DeviceManager** class is also associated with the **Gallery** for loading it, as indicated by the loadGallery() method. Furthermore, the **Gallery** class is connected to the **ClassroomManager**, allowing users to view multiple classrooms, as shown by the viewClassrooms() method.
+
+The **ClassroomManager** maintains a one-to-many relationship with the **Classroom** class, signifying that it can manage multiple **Classrooms**. Each **Classroom** is capable of handling multiple **Game** objects, as depicted by their **one-to-many** association. The **Game** class is similarly connected to the **BlocklyEditor** class through a **one-to-many** relationship, suggesting that the **BlocklyEditor** can manage numerous **Block** objects.
+
+The **Database** class has a **one-to-many link** with both the **User** and **Classroom** classes, indicating that it stores and manages data from both Users and **Classrooms**.
+
+The **Block** class has a **one-to-many** relationship with the **Sensor** class, illustrating that blocks can access and utilize one or many sensors. The **Documentation** class is standalone but associated with the **BlocklyEditor** to provide tutorials for different blocks in the **BlocklyEditor**.
+
+Lastly, the **Gallery** class is linked to the **Configuration** class to handle WiFi connections.
+
+## `Block`
+- Describes the properties necessary to define and create a Blockly code block
+
+## `BlocklyEditor`
+- Allows the user to work on Blockly based projects and create/place code blocks within it
+
+## `Classroom`
+- Acts as a platform to host user-created Blockly games
+
+## `ClassroomManager`
+- Lets the user interact with classrooms
+
+## `CodeCompiler`
+- Converts the raw Blockly JSON definition into a runnable code Block in Python
+
+## `Configuration`
+- Manages the Blastpad's WiFi connection supporting scanning for new networks, connecting to one, and disconnecting from one
+
+## `Database`
+- Stores user and classroom information used for logging in and for retrieving classrooms
+
+## `DeviceManager`
+- Loads the BlastPad's screen upon startup and keeps track of the current screen displayed
+
+## `Documentation`
+- Loads help documentation for the Blockly code blocks
+
+## `Gallery`
+- Manages the current screen displayed to the user and allows them to navigate to different pages
+
+## `Game`
+- Contains the metadata of a Blockly game, allows users to play the game it defines, and upload it to a Classroom
+
+## `Sensor`
+- Allows Blockly blocks to retrieve data from the BlastPad's onboard sensors (temperature, light, etc.)
+
+## `UserManager`
+- Manages user login for the BlastPad with username/password authentication and allows the creation of a new account
+
+
+
+<!-- A check list for architecture design is attached here [architecture\_design\_checklist.pdf](https://templeu.instructure.com/courses/106563/files/16928870/download?wrap=1 "architecture_design_checklist.pdf")  and should be used as a guidance. -->

documentation/docs/system-architecture/electrical-diagrams.md

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 4
+sidebar_position: 5
 ---
 
 # Electrical Diagrams

documentation/docs/system-architecture/entity-relation-diagram.md

@@ -0,0 +1,54 @@
+---
+sidebar_position: 3
+---
+
+# Entity Relation Diagram
+
+According to the following Entity-Relationship diagram below, there are four different relationships we can observe.
+1. "Teaches in" Relationship
+	This is a One-to-Many (1:N) relationship between Teachers and Classrooms. Each teacher can belong to multiple classrooms but each Classroom may only have a single Teacher.
+	Furthermore, a Teacher belongs to 1 or many Classrooms and a Classroom may have one and only one Teacher.
+2. "Contains"
+	A One-to-Many (1:N) relationship between Classrooms and Students. Each Classroom may contain multiple Students, but each Student belongs to a single Classroom.
+	Furthermore, Classrooms have one or many Students and a Student may belong to one and only one Classroom.
+3. "Played by"
+	A Many-to-Many (N:N) relationship between Students and Games. A Student may play multiple Games and a Game may be played by multiple Students.
+	Furthermore, Games may belong to one or many Students and Students may have one or many Games.
+```mermaid
+---
+title: "E-R Diagram SQL Database"
+---
+erDiagram
+    Teachers {
+        teacher_id INT PK
+        first_name VARCHAR(255)
+        last_name VARCHAR(255)
+        username VARCHAR(255)
+		password VARCHAR(255)
+    }
+    Classrooms {
+        room_number INT PK
+        teacher_id INT FK
+    }
+    Students {
+        student_id INT PK
+        first_name VARCHAR(255)
+        last_name VARCHAR(255)
+		username VARCHAR(255)
+        room_number INT FK
+        password VARCHAR(255)
+        games VARCHAR(255)
+    }
+    Games {
+		game_name VARCHAR(255)
+        game_id INT PK
+        name VARCHAR(255)
+        last_edited_date DATE
+        json_file BLOB
+        image_icon BLOB
+    }
+
+    Teachers ||--|{ Classrooms : "Teaches in"
+    Classrooms ||--|{ Students : "Contains"
+    Games |{--|{ Students : "Played by"
+```