BSc ITMB Level 2 Object Oriented Analysis and Design Assignment PDF

# College of Engineering ## BSc ITMB Level 2 ### Object Oriented Analysis and Design Assignment Cover Page | STUDENT NAME 1 | STUDENT NUMBER 1 | |-------------------|--------------------| | STUDENT NAME 2 | Sundus Abdu;;ah Alajmi | STUDENT NUMBER 2 | NU230121 | | STUDENT NAME 3 | Maathir Bada...

# College of Engineering ## BSc ITMB Level 2 ### Object Oriented Analysis and Design Assignment Cover Page | STUDENT NAME 1 | STUDENT NUMBER 1 | |-------------------|--------------------| | STUDENT NAME 2 | Sundus Abdu;;ah Alajmi | STUDENT NUMBER 2 | NU230121 | | STUDENT NAME 3 | Maathir Badar Alhabsi | STUDENT NUMBER 3 | NU230071 | # SHAS A diagram of a SHAS system is shown. The diagram is comprised of a square containing nine circles. The square is labelled SHAS, with each circle representing a process or feature of the system. - The circles are labelled from left to right: user registration, guest access management, device control and monitoring, manage alerts, monitor surveillance, optimize energy usage, energy management, voice and remote control, automate scheduling, automation rules, data privacy and security, maintenance and troubleshooting. - The diagram also shows lines connecting the circles to external actors, who are represented by stick figures. The actors are labelled from left to right: home owner, service provider, guest, central hub, and system administrator. - Lines connecting the actors to the circles represent the flows of interactions between the actors and the system. # Use Case Description ## Use Case 1: Guest Access Management The homeowner grants the guest limited access to specific smart devices within the home for a certain period. First, the homeowner logs into the smart home app and selects "guest access management". Then he chooses "add new guest" and enters the guest details (name, email, access level) then he selects the chosen device for the guest access. Then the system generates temporary access and sends them to the guest via email. Then the guest receives the access credentials and uses them to log into the app. Then the guest will be able to access the device during the permitted timeframe. Ones when the access period expires the system automatically revoke guest credentials. The guest might try to log in after the access duration has expired so the system denies access and shows an error message to contact the homeowner. So the guest loses the access credentials and the homeowner is the only person who can reissue new temporary credentials. | Use case name | Guest access management | |-------------------|--------------------------| | Primary actor | homeowner | | Goal | To grant and manage temporary access permissions for guest | | Scope | Smart home automation system | | Precondition | The homeowner is logged in and authenticated guest details are available | | Postconditions | Guest access is granted or revoked system logs the guest interactions | **Main Flow** 1. The homeowner logs into the smart home app 2. Select the guest access option from the main menu 3. Choose an existing guest from the list or create a new guest profile. 4. Sets up the guest's access permissions, indicating: The devices the guest can operate and the access timeframe 5. The system creates the visitor's temporary login credentials. 6. After receiving the credentials, the guest uses them to enter the house and operate the authorized equipment within the allotted time. 7. For reporting purposes in the future, the system records every device interaction the visitor makes. **Alternative Flows** 1. The guest attempts to access the home outside the specified timeframe. 2. The system denies access and sends a notification to the homeowner about the attempted access outside permitted hours ## Use Case 2: Device Control and Monitoring - **Description:** Allows the Homeowner to control and monitor smart devices, such as lights and thermostats, through an app. - **Main Flow:** 1. The homeowner logs into the app. 2. Select the device to control (e.g., a light). 3. Issues a command (e.g., turn on/off). 4. System sends a status update to confirm the action. - **Alternative Flow:** - System fails to connect to the device - The system sends an alert to the Homeowner about the disconnection. ## Use Case Form: Device Control and Monitoring | Use Case Name | Device Control and Monitoring | |----------------|------------------------------| | Actors | Homeowner | | Description | Controls and monitors smart devices like lights and thermostat. | | Preconditions | User must be logged in with active device connections. | | Main Flow | 1. Homeowner logs in. 2. Selects a device to control. 3. Issues command to control the device. 4. System updates the device's status and notifies the homeowner. | | Alternative Flow | Device connection fails – System alerts the homeowner of device disconnection. | | Postconditions | Device status is updated and displayed in the app. | ## Use Case 3: Automation Rules and Schedules Homeowners, Central Hub, and Based on time and sensor data, the homeowner sets up an automation rule to control smart devices, such as lowering the temperature and shutting off lights when no one is home. The main scenario on the smart home app, the homeowner signs in and chooses "Automation Rules." The homeowner calls it "Energy Saver" and selects "Create New Rule." The homeowner establishes the rules' requirements: "When the time is after 10:00 PM and no motion is detected for 30 minutes." The homeowner sets up the following actions: lower the thermostat to ­18°C, turn off the lights in the living room and hallway, save the rule, and the system verifies that it is enabled. The Central Hub keeps an eye on sensor data and applies the rule when certain criteria are satisfied. The message "Energy Saver rule activated" is sent to the homeowner. **Alternative Scenarios:** The homeowner sets conflicting conditions specified by the homeowner (for example, two rules that modify the thermostat in opposite ways): "Conflicting rules detected," the system says. Please check the settings. Device fault prevents Central Hub from executing the rule: "Failed to adjust thermostat due to device malfunction," the system notifies the user. Unexpected activation of an automation rule (for example, because of a sensor error): "Rule deactivated due to unexpected behavior," the system alerts. Check the sensor, please. | Use case name | Automation Rules and Schedules | |---------------|-----------------------------------| | Primary actor | Admin | | Goal | Allows the admin to create, modify, and manage automation rules and schedules for various system tasks. | | Scope | Admin is logged into the system. | | Preconditions | Admin is logged into the system. | | Postconditions | New automation rule is saved and scheduled for execution. | **Main Flow** 1. Admin navigates to the "Automation" section. 2. Admin selects "Create New Rule." 3. Admin specifies rule parameters (e.g., trigger event, action to take). 4. Admin sets the schedule for the rule (immediate, daily, weekly, etc.). 5. Admin saves the rule. 6. System validates and confirms the rule has been created. **Alternative Flows** - Invalid rule parameters: System displays an error message indicating the parameters must be corrected.  - User lacks permission: If the admin does not have permission to create rules, the system denies access and displays an error message. - Conflicting schedule: If the new schedule conflicts with existing rules, the system prompts the admin to resolve the conflict. # Create Activity Diagrams **Use case 1: Guest access management** A diagram shows a sequence of actions for the guest access use case. 1. The flow begins with a black circle at the top. 2. The first step is "guest requests access" 3. Next, the system "notifies home owner". 4. Then the system checks "approved access". 5. If "approved access" is not true (no), the flow goes to "grant access to guest". 6. Next, "guest controls permitted devices" 7. If "approved access" is true (yes) the flow goes to "notify guest of denial". 8. The flow ends with a solid circle inside another circle at the bottom, indicating that the sequence of steps is complete. The flow can then restart by going back to the black circle at the top, starting the sequence over again. **Use Case 2: Device Control and Monitoring** A sequence diagram is shown which details interactions between the Homeowner, App, System and Device. 1. The Owner initiates a login sequence with the app. 2. The app then authenticates the user and communicates authentication success. 3. The app retrieves the current device status. 4. The app displays the status to the owner. 5. The owner then issues a command (turn on/off). 6. The app sends the command to the system. 7. The system executes the command on the device. 8. The device confirms the action taken. 9. The system updates the action status to the app. There is also an alternative flow, where if the system fails to connect to the device: 1. The app receives an alert that the connection failed, which it displays to the owner.