Skip to content

Commit

Permalink
Merge pull request #53 from Capstone-Projects-2024-Spring/BP-127-Requ…
Browse files Browse the repository at this point in the history
…irements-Document-Feedback-2-System-Architecture

Bp 127 requirements document feedback 2 system architecture
  • Loading branch information
gummyfrog committed Mar 15, 2024
2 parents d1ebffe + 0bf7ede commit cc3d872
Show file tree
Hide file tree
Showing 5 changed files with 253 additions and 209 deletions.
183 changes: 183 additions & 0 deletions 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. -->
@@ -1,5 +1,5 @@
---
sidebar_position: 4
sidebar_position: 5
---

# Electrical Diagrams
Expand Down
54 changes: 54 additions & 0 deletions 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"
```

0 comments on commit cc3d872

Please sign in to comment.