Skip to content

A comprehensive console-based simulation of a Smart Home system. Implements complex entity interactions, device state management, and resource consumption tracking using Object-Oriented Programming principles

Notifications You must be signed in to change notification settings

Suriok/SmartHome-Simulation

Repository files navigation

Smart home

Uživatelská dokumentace

Simulace chytré domácnosti s uživateli, místnostmi a zařízeními (senzory, spotřebiče, sportovní vybavení). Generuje reporty (konfigurace domu, spotřeba, události, aktivita uživatelů) a demonstruje návrhové vzory.

  • Stažení závislostí a build:
    ./gradlew clean build
  • Spuštění simulace (výchozí scénář ze zadání):
    ./gradlew run
    Hlavní třída: cz.cvut.fel.omo.golyakat_aschehub.smarthome.Main (spouští SimulationRunner).
  • Konfigurace a logy:
    • Logování: src/main/resources/log4j2.xml (výstup do konzole a souborů dle konfigurace).
    • Parametr simulace (počet kroků) je nastaven v Main při vytváření SimulationRunner;

Použité návrhové vzory

  • Singleton + Observer: EventManager jako centrální publisher; EventListener odběratelé se registrují a dostávají události.
  • State: Device (stav ON(IDLE)/OFF/IN_USE) a User (WAITING/USING_DEVICE/DOING_SPORT) mají stavovou logiku pro validní přechody.
  • Visitor: Reporty prochází strom HouseFloorRoomDevice (např. ActivityAndUsageReportVisitor).
  • Observer: User a HouseController poslouchají události z EventManager a reagují na ně.
  • Iterator: Samostatné iterátory pro zařízení a uživatele usnadňují průchod strukturou.
  • Factory: DeviceFactory vytváří konkrétní zařízení podle DeviceType bez vazby na implementaci.
  • Builder: Konfigurace domu (patra, místnosti, zařízení, uživatelé).
  • Stream API: Například ve třídě User v metodě tryToUseDevice nebo v konstruktoru DeviceIterator

UML Class diagram

Main diagram

Smart Home Class Diagram

Iterator pattern

House will have two iterators:

  • one for all devices (it will simplify the navigation through the location hierarchy)
    • ActivityAndUsageReport will use this iterator to get activity stats from each device
  • one for all users

Iterator Pattern Diagram

Subsystém Event Manager

  • EventManager (Singleton, Lazy Initialization, Observer)
    • Centrální bod systému. Spravuje seznam odběratelů, rozesílá jim události a ukládá historii všech proběhlých akcí.
  • EventPool (Object Pool, Singleton)
    • Optimalizuje využití paměti tím, že recykluje objekty Event. Zabraňuje zbytečnému vytváření a mazání instancí (Garbage Collection overhead) při vysoké frekvenci událostí.
  • EventSource
    • Rozhraní pro zdroje událostí (např. senzory, uživatelé). Zdroje nevytvářejí nové instance, ale "půjčují" si prázdné události z EventPool a posílají je do EventManager.
  • Stream (Stream API)
    • Nástroj, který EventManager využívá k efektivní filtraci odběratelů (např. podle typu události) a k agregaci dat pro generování reportů.

Stream class diagram

Popis aplikace

Základní struktura aplikace je postavena na kompozici objektů. Hlavní třída House agreguje (vztah 1..) instance Floor. Každá instance Floor dále agreguje (1..) Room. Tím je vytvořena jasná hierarchie Dům -> Patro -> Místnost.

Každý Device je poté asociován s právě jednou Room (vztah located in) a každý User je v daný okamžik také spojen s jednou Room. Což slouží k automatizacím a kontextovému chování (např. User může ovládat pouze zařízení ve své aktuální místnosti).

Správa Zařízení (Device a Factory)

Všechna chytrá zařízení (jako SmartWindow, Television, Stove atd.) jsou implementována jako konkrétní třídy dědící z abstraktní třídy Device.

  • Vytváření zařízení je řešeno pomocí návrhového vzoru Factory. Třída DeviceFactory má metodu createDevice(DeviceType), která na základě enum hodnoty DeviceType (např. SMART_LIGHT, SENSOR, REFRIGERATOR) vrací správnou instanci konkrétního zařízení. Pokud bude při vytváření potřeba složitější logika, může dojít k implementaci samostatných Factory tříd pro různá zařízení.
  • Stav zařízení (např. ON, OFF, IN_USE) je reprezentován enum výčtem DeviceState. Jak je poznačeno v diagramu, k řízení přechodů mezi těmito stavy je použit návrhový vzor State. To zajišťuje, že se zařízením nelze interagovat neplatným způsobem (např. setChannel v Television, která je OFF).
  • Spotřeba je spravována přes enum ConsumptionType (např. ELECTRICITY, WATER). Každé Device má metodu generateConsumptionReport() pro hlášení své spotřeby.

Uživatelé a Stavy (User a State)

Členové domácnosti jsou reprezentováni třídou User.

  • Role a Oprávnění: Každý User má atribut role definovaný enum výčtem Role (např. ADMIN, CHILD, PET). Oprávnění k interakci se zařízením je řízeno porovnáním User.role s atributem Device.canBeUsedBy.
  • Stav Uživatele: Podobně jako zařízení, i User využívá návrhový vzor State pro správu svého chování. enum UserState (WAITING, USING_DEVICE, DOING_SPORT) definuje, co uživatel právě dělá.
  • Interakce: Uživatelé interagují s prostředím voláním metod useDevice(Device) nebo useEquipment(SportsEquipment). SportsEquipment (jako Ski a Bicycle) jsou samostatné třídy, ke kterým lze přistupovat přes House.

Zpracování Událostí (EventManager a Observer)

Systém událostí je klíčovou součástí a je implementován pomocí návrhového vzoru Observer.

  • Zdroje: Třídy User i Device implementují rozhraní EventSource, které jim dává metodu generateEvent(String, EventPriority). Tím mohou vytvářet události (např. "Pes odešel ven", "Sensor detekuje déšť").
  • Centrální Manager: Třída EventManager je implementována jako Singleton. Funguje jako centrální "subject" (vydavatel). Udržuje si seznam odběratelů a upozorňuje je, když je publikována nová událost.
  • Pub/Sub: Ostatní objekty (uživatelé nebo zařízení) se mohou u EventManager zaregistrovat pomocí subscribe() a unsubscribe().
  • Tok Události:
    1. Device (např. WindSensor) nebo User zavolá publishEvent().
    2. EventManager přijme tento Event a uloží jej do paměti i do souborového logu.
    3. EventManager následně rozešle (notifikuje) tuto událost všem svým přihlášeným odběratelům (User nebo Device), kteří na ni mohou reagovat.
    4. Když je událost vyřízena, může ji odběratel označit jako vyřízenou a z EventManager ji odebrat.

Generování Reportů (Reporty a Visitor)

Generování reportů je rozděleno mezi odpovědné třídy:

  • HouseConfigurationReport: Je generován voláním metody generateHouseConfigurationReport() na instanci House. Jak je uvedeno v poznámce diagramu, pro sběr dat ze stromové struktury (House -> Floor -> Room -> Device) bude použit návrhový vzor Visitor.
  • EventReport: Generuje EventManager ze svého souborového logu událostí.
  • ActivityAndUsageReport: Generuje každý User na základě historie volání useDevice / useEquipment. A celkový report může být agregován na úrovni House pomocí iterátoru pro uživatele.
  • ConsumptionReport: Generuje každé Device pro sebe.

About

A comprehensive console-based simulation of a Smart Home system. Implements complex entity interactions, device state management, and resource consumption tracking using Object-Oriented Programming principles

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •  

Languages