Návrh aplikace. Project Westpon. Inteligentní simulátor budov. Martin Mudra, Jan Smejkal, Onřej Macoszek, Marek Žehra, Jiří Slivárich



Podobné dokumenty
Struktura třídy, operátory, jednoduché algoritmy, junit. Programování II 2. cvičení Alena Buchalcevová

MATURITNÍ PRÁCE dokumentace

Webové služby a XML. Obsah přednášky. Co jsou to webové služby. Co jsou to webové služby. Webové služby a XML

Editor pro vizualizaci interiérů bytů

Hydroprojekt CZ a.s. WINPLAN systém programů pro projektování vodohospodářských liniových staveb. HYDRONet 3. Modul EDITOR STYLU

Technologie JavaBeans

Metodika. Architecture First. Rudolf Pecinovský

Programování v Javě I. Leden 2008

Komunikační rozhraní SEP 1.6

Programování v Javě I. Únor 2009

ČVUT FAKULTA ELEKTROTECHNICKÁ, TECHNICKÁ 2, PRAHA, ČESKÁ REPUBLIKA. Semestrální projekt. Systém speech2text (pracovní název)

Michal Krátký. Úvod do programovacích jazyků (Java), 2006/2007

Teoretické minimum z PJV

Projekty pro výuku programování v jazyce Java

Metodika. Oznámení o vykonávání působností v agendě ve smyslu zákona č. 111/2009. Sb., o základních registrech. Verze 1.6

Infrastruktura UML. Modelování struktury v UML. Superstruktura UML. Notace objektů. Diagramy objektů

Manuál k aplikaci WANAS

KIV/PIA Semestrální práce

Workmonitor. Servisní návod. 24. června 2014 w w w. p a p o u c h. c o m

Student s Life. Návrhová dokumentace (Design) Lukáš Barák, Jakub Ječmínek, Jaroslav Brchel, Jiří Zmeškal

UJO Framework. revoluční architektura beans. verze

Obrázek. Základní popis, zadání úkolu. Struktura tříd,

Implementace A* algoritmu na konkrétní problém orientace v prostoru budov

PŘÍRODOVĚDECKÁ FAKULTA UNIVERZITY PALACKÉHO KATEDRA INFORMATIKY BAKALÁŘSKÁ PRÁCE. Vytváření a evidence smluv Petr Čulík

Studentská tvůrčí a odborná činnost STOČ 2015

Architektura aplikace

NEXIS 32 rel Generátor fází výstavby TDA mikro

MANUÁL MOBILNÍ APLIKACE GOLEM PRO OPERAČNÍ SYSTÉM ANDROID 4.X A VYŠŠÍ

Mobilní malware na platformě Android Přednáška 1. Ing. Milan Oulehla

Manuál k aplikaci FieldGIS v.2.27

MyIO - webový komunikátor

TouchGuard Online pochůzkový systém

Grafický zákaznický displej Manuál Verze: červen 2017

Mediator motivace. FontDialog. závislosti mezi jednotlivými ovládacími prvky jsou netriviální

Pokud nebude na příkazové řádce uveden právě jeden argument, vypište chybové hlášení a stručný

1 of :27

Vývoj, výroba, prodej a montáž docházkových a identifikačních systémů. Docházka 3000 Personalistika

Michal Krátký, Miroslav Beneš

Patenty. 1. Spuštění modulu Patenty. 2. Popis prostředí a ovládacích prvků modulu Patenty

Specifikace softwarových požadavků

Modelování webových služeb v UML

Úvod do programovacích jazyků (Java)

Programování v C++ 1, 5. cvičení

SOUBORY, VSTUPY A VÝSTUPY POKRAČOVÁNÍ

Správa a sledování SOA systémů v Oracle SOA Suite

1 Podrobná specifikace Yunifly Datasheet

Úvod do programování - Java. Cvičení č.4

UŽIVATELSKÁ PŘÍRUČKA PRO IZR NA PORTÁLU FARMÁŘE - HLÁŠENÍ POHYBŮ A OBJEDNÁVKY UZ

Modelování obchodních procesů

File: du_uloha2.odt Definition Name: Author: jirka

O nás. To vše a mnohem více Vám je schopna nabídnout již základní verze publikačního systému bravaweb.

Modul informačního systému SPŠSE Liberec

UŽIVATELSKÁ DOKUMENTACE PRO DODAVATELE. Stav ke dni v. 2.0

MenuLIB KNIHOVNA SIMPLE4 PRO TVORBU UŽIVATELSKÉHO ROZHRANÍ NA PLC MICROPEL

Tabulka symbolů. Vazba (binding) Vazba - příklad. Deklarace a definice. Miroslav Beneš Dušan Kolář

VYTVÁŘENÍ OBSAHU KURZŮ

ČESKÉ VYSOKÉ UČENÍ TECHNIKÉ Fakulta elektrotechnická. Microsoft Sharepoint 2007 Workflows Průmyslové informační systémy

Modul ročních zpráv o výsledcích finančních kontrol

Téma 5. Ovladače přístrojů Instrument Drivers (ID)

Barový systém. Stručný popis: Funkce systému: SW implementace:

1 - Úvod do platformy.net. IW5 - Programování v.net a C#

SEZNÁMENÍ S PROGRAMEM

Reliance 3 design OBSAH

Semináˇr Java X J2EE Semináˇr Java X p.1/23

DATA ARTICLE. AiP Beroun s.r.o.

Tvorba informačních systémů

Google Web Toolkit. Martin Šurkovský, SUR března Katedra informatiky

elearning tvorba studijních opor

5 Rekurze a zásobník. Rekurzivní volání metody

7 Jazyk UML (Unified Modeling Language)

Měřič krevního tlaku. 1 Měření krevního tlaku. 1.1 Princip oscilometrické metody 2007/

X33EJA Web Services. Martin Ptáček, KOMIX s.r.o.

Michal Krátký. Úvod do programovacích jazyků (Java), 2006/2007

UNIVERZITA PARDUBICE DOPRAVNÍ FAKULTA JANA PERNERA

Návrhové vzory. Jakub Klemsa, Jan Legerský. 30. října Objektově orientované programování.

SOFTWARE NA ZPRACOVÁNÍ MRAČEN BODŮ Z LASEROVÉHO SKENOVÁNÍ. Martin Štroner, Bronislav Koska 1

Statické proměnné a metody. Tomáš Pitner, upravil Marek Šabo

OBSAH. ÚVOD...5 O Advance CADu...5 Kde nalézt informace...5 Použitím Online nápovědy...5. INSTALACE...6 Systémové požadavky...6 Začátek instalace...

Mobilní aplikace Praha 11 v mobilu

Problém identity instancí asociačních tříd

Doplněk Parametry Plus pro Altus Vario

PREPROCESOR POKRAČOVÁNÍ

OSGi. Aplikační programování v Javě (BI-APJ) - 6 Ing. Jiří Daněček Katedra softwarového inženýrství Fakulta informačních technologií ČVUT Praha

Globální architektura ROS

Java a Caché IV: Manipulace s objekty

TÉMATICKÝ OKRUH Softwarové inženýrství

Spinelterminal. Terminálový program pro ladění aplikací s protokolem Spinel. 20. září 2005 w w w. p a p o u c h. c o m v

Sem vložte zadání Vaší práce.

NOVÁ VERZE OBD A JEJÍ VYUŽÍVÁNÍ Ing. Martina Valášková

PC-D218-ID. pro 2-vodičový systém D2. Uživatelský návod.

NÁVOD jak na webinář přes WizIQ

Abstraktní datové typy: zásobník

Č.j. PPR /ČJ Praha Počet listů: 8

Programátorské večery. Tomáš Herceg Microsoft Student Partner

mitesemo Popis programu pro komunikační zařízení

Uživatelská příručka + základní informace o IS o ISVS

Návrh - návrhové třídy a vzory

Architektura. Vedení sesterské dokumentace

Analýza publikačního systému. KÚ Zlínského kraje

Transkript:

Návrh aplikace Project Westpon Inteligentní simulátor budov Martin Mudra, Jan Smejkal, Onřej Macoszek, Marek Žehra, Jiří Slivárich

. Úvod.. Účel dokumentu Tento dokument má za účel detailně popsat návrh naší aplikace a to jak statickou, jak i dynamickou část. Převážně ho tvoří okomentované UML diagramy popisující každý problém, na který jsme během návrhu aplikace narazili..2. Reference a odkazy Při vývoji projektu byl použit systém, který umožňuje schraňovat veškeré materiály, které v průběhu vývoje vznikly v přehledné formě. Webová adresa do systému je: http://kenai.com/projects/westpon/.3. Obecné informace Návrh projektu by se měl číst postupně a bez přeskakování jednotlivých částí. V případě, že přečtete dokument od začátku až do konce, neměla by vám chybět žádná důležitá informace a měli byste pochopit návrh celého projektu simulátoru inteligentních budov. 2 S t r á n k a

2. Business návrh 2.. Doménový model Na Obrázku č. je znázorněn model struktur, ze kterých se skládá budova. Hlavní stavební kámen představuje třída BuildingObject. Tento objekt má svoje jméno a id, které ho jednoznačně určuje. To umožňuje aplikaci poskytovat API pro načítání a změnu dat libovolného objektu budovy. BuildingObjekty se dělí na dva druhy. První z nich, SimpleObject, představuje jednoduchý objekt, který má v sobě obsaženu pouze svoji polohu a velikost. Mezi tyto objekty patří například senzory, aktuátory, ale i dveře a okna. Oproti tomu ComposedObject reprezentuje objekt složený z dalších objektů. Toto složení je zaznamenáno pomocí třídy Ground, které obsahuje čtvercovou síť. V každém poli této čtvercové sítě je uložena informace o tom, jaký BuildingObject tuto pozici zabírá. Mezi složené objekty patří například podlaží. class Obje... BuildingObject - Id: int - Name: string Position - depth: int - height: int - width: int +is on position SimpleObject ComposedObject +has description of +belongs composition to Ground - content +has size Dimension - x: int - y: int - z: int Obrázek č.: Diagram business objektů struktury budovy Na obrázku č.2 je zobrazeno konkrétní složení budovy. Ta je reprezentována třídou Building. Tato třída v sobě kromě svého id a jména nese navíc ještě informaci o jednotlivých patrech, jejich počtu a pořadí. Její výška je určena součtem výšek jednotlivých pater. Dále je v budově uložena také informace o jejím okolním prostoru. Mapa budovy (Ground) se pak skládá z jejího půdorysu a tohoto okolního prostoru. Třída Floor reprezentuje jednotlivá patra. Tvar podlaží je určen půdorysem budovy. Patro v sobě obsahuje informaci o jednotlivých pokojích, které se v něm nacházejí. Jeho mapa 3 S t r á n k a

(Ground) se pak skládá z okolního prostoru a půdorysu budovy, který je vyplněn místnostmi. Část půdorysu, ve které se nenachází žádná místnost, představuje nevyplněnou část, tedy zeď. Patro v sobě dále nese informaci o své výšce. Pokoj představuje třída Room. Tato třída v sobě nese informaci o jednotlivých senzorech a aktuátorech, které se v něm nachází. Dále v sobě má uložen seznam všech otvorů ve zdi. Mezi ně patří okna, která vedou z pokoje do okolního prostoru budovy, dveře, které vedou mezi dvěma pokoji ve stejném patře a schody, které spojují dva pokoje v sousedních patrech. class Building BuildingObject Objects::ComposedObject Floor +consists of Building 0..* +is on floor +has outer space +consints of Room 0..* +is in room +from +to +is in room +is filled with 0..* Status - state: int +has status Dev ice BuildingObject Objects::SimpleObject +is in room HoleInWall Actuator Sensor DoorOrWindow Stairs Heating HeatSensor - currenttemperature: int - currenttemperature: int Obrázek č.2: Konkrétní struktura budovy 4 S t r á n k a

Třída HoleInWall je jednoduchý objekt, který reprezentuje již zmíněný otvor ve zdi. Ať už ji tvoří okno, dveře nebo schody, má v sobě vždy uloženu informaci o původním prostoru a prostoru, do kterého vede. Poslední jednoduchý objet je zařízení (Device). Tato zařízení jsou rozmístěna po jednotlivých pokojích a okolním prostoru budovy. Dělí se na dva druhy, Sensor a Actuator. Sensor představuje typ zařízení, který měří a ukládá hodnoty svého okolí. Příkladem senzoru je teplotní senzor. Oproti tomu Actuator je zařízení, které ovlivňuje svoje okolí. Jeho příkladem je topení, protože mění teplotu místnosti. Každé zařízení má v sobě seznam svých aktuálních hodnot. Mezi ně patří například cílová teplota u topení nebo naměřená teplota u teplotního senzoru. Kromě toho má každé zařízení ještě svůj stav (Status). Jeho nejjednodušší reprezentace je binární status, který zaznamenává, jestli je zařízení vypnuté nebo zapnuté. 2.2. Aktivity diagram act v ytv oření budo... Uživatel vytváří novou budovu Změní název podlaží Změní výšku podlaží Edituje místnosti Edituje otvory ve zdech Rozmístí zařízení po patře Systém Uživatel Vyplní název budovy Určí počet pater Nastav í v elikost půdorysu budov y Založí novou budovu Určí tvar půdorysu budov y Vytvoří určený počet prázdných podlaží Vybere podlaží k editaci Uloží tvar půdorysu budov y [Ano] Uloží tvar půdorysu podlaží Chce editovat nějaké podlaží? [Ne] Konec Uloží změny v podlaží Obr č.3: Aktivity diagram vytvoření modelu budovy Aktivity diagram popisuje postup, kterým je vytvořena budova. Uživatel nejdříve vyplní název, počet pater a velikost půdorysu budovy. Aplikace data zpracuje. Vytvoří novou budovu a určený počet prázdných pater. Uživatel dále určí velikost půdorysu, který bude budova zabírat. Aplikace tento půdorys uloží jak jako půdorys budovy, tak i jako půdorys každého patra. Zbylé místo je označeno jako okolní prostor. Poté uživatel edituje jednotlivá patra. Jejich Editace probíhá ve dvou krocích. V prvním kroku uživatel rozmístí místnosti, otvory ve zdech, patro pojmenuje a nastaví jeho výšku. V druhém kroku už edituje rozložení senzorů v jednotlivých místnostech. Následně se editované patro uloží. Pokud už uživatel nechce editovat žádné patro, vytváření budovy končí. 5 S t r á n k a

3. Architektura aplikace 3.. Diagram balíčků Na začátek bych uvedl trochu teorie. To, co z javy známe jako projekt a balíčky, se v C# nazývá solution a projecty. Jedná se pouze o změnu názvu, jinak obě dvojice pojmů znamenají to samé. Pokud bychom měli být přesní, řekli bychom, že na obrázku č.4 je znázorněn diagram projektů. Aplikace se skládá ze čtyř projektů. Největší jsou UserInterface, který se stará o celé GUI a správ událostí, které uživatel generuje a Business. Ten obstarává celou business logiku aplikace, obsluhuje simulaci a podobně. Protože projekt UserInterfase volá metody z projektu Business, je na něj závislý. Další dva projekty Communicator a Physical module obstarávají komunikace s externími aplikacemi, které reprezentují lidský modul, fyzikální modul a neuronovou síť. Tyto balíčky implementují API, které popisuje komunikaci. pkg Class Mo... UserInterface Business Communication Physical Module Obrázek č. 4 Package diagram 3.2. Datový model 3.2.. Business vrstva Business vrstva je uložena v balíčku Business a reprezentuje obchodní logiku aplikace. Kromě objektů doménového modelu, který je popsán výše, obsahuje ještě obslužné třídy, které s tímto modelem pracují a zprostředkovávají ho ostatním vrstvám. Jejich struktura je zobrazena na obrázku. Veškerá komunikace s grafickou vrstvou probíhá pomocí interfacu IBusinessFasade. Tento interface obsahuje metody pro načtení a uložení nové budovy, spuštění a zastavení simulace a práci s externími moduly. Třída BusinessFasade, která toto rozhraní implementuje, je 6 S t r á n k a

navržena jako singleton, aby k ní bylo možné přistoupit odkudkoli z prezentační vrstvy, bez nutnosti uchovávání reference. Další důležitá třída je třída Simulator. Jak její název napovídá, ukládá v sobě všechna data potřebná k simulaci inteligentní budovy. Budova, která je v simulátoru uložena, je dále předávána BusinessFasade, která umožňuje její získání v prezentační vrstvě. Dále Simulator obsahuje také informaci o tom, jestli je aktuálně spuštěna simulace, nebo jestli uživatel edituje data. BusinessFasade obsahuje také referenci na instanci třídy implementující rozhraní IBuildingLoader, které umožňuje serializaci budovy. K disposici je jak serializér do binárního souboru, tak i serializér do XML (BinBuildingLoader a XmlBuildingLoader). Další důležitou částí business vrstvy je sběrnice Communicator. Tato sběrnice sbírá události, které nastanou v simulátoru (zapnutí, vypnutí) a v budově (změna struktury, změna hodnoty na aktuátoru nebo sensoru). Po odchycení události se na sběrnici zavolá příslušná metoda, která na ni zareaguje. V tomto případě upozorní externí moduly na změnu stavu simulace nebo pro ně zajímavých hodnot. Sběrnice funguje také opačným směrem. Pokud dostane data od externího modulu, upozorní budovu, aby tato data zpracovala. Budova pak rekurzivně projde celou svoji strukturu a změny aplikuje. Podrobné složení business vrstvy včetně všech vnitřních metod a proměnných naleznete v přiloženém souboru s dokumentací aplikace. class Class Mo... «interface» IBusinessFasade «interface» ISimulator BusinessFasade «interface» IBuildingLoader Simulator «interface» IBuilding BinBuildingLoader XmlBuildingLoader Building Communicator «interface» ICommunicator Obrázek č.5: Struktura business vrstvy 7 S t r á n k a

3.2.2. Prezentační vrstva class Class Mo... Button GeneralView GridFragmentView ObjectWithPositionView ComposedObjectView RoomFragmentView FloorFragmentView HoleInWallView Dev iceview OuterSpaceFragmentView ActuatorView SensorView Obrázek č.6: Struktura náhledů na objekt v prezentační vrstvě V prezentační vrstvě je na mnoha místech potřeba vykreslit náhled patra, jak už k editaci, tak i k pouhému prohlížení simulace. Toto vykreslení obstarává algoritmus, který z business vrstvy načte plán aktuálního podlaží. Ten je tvořen čtvercovou sítí. Algoritmus poté projde celou síť a vytvoří si podle ní svoji vlastní, která neobsahuje objekty budovy, ale instance třídy GeneralView a jejích potomků. Konkrétní třída, že které se vytvoří instance, se vybírá dynamicky podle typu objektu, který se nachází v budově na dané pozici (Např. Actuator a ActuatorView nebo Room a RoomFragmentView). Protože třída GeneralView dědí od třídy Button, je možné ji vykreslit a pokud se vykreslí celá nová čtvercová síť, vznikne náhled vybraného podlaží. Ze stejného důvodu je také možné na objekty navěsit obslužné metody, které se spustí, pokud dojde ke kliknutí na objekt. Tyto metody například přidají danou část půdorysu do pokoje, vytvoří dveře do vedlejšího pokoje a podobně nebo načtou hodnoty aktuátoru. Původní objekty budovy jsou navíc stále uloženy v grafických, takže je možné rovnou přistoupit k jejich metodám a pracovat s nimi. 8 S t r á n k a

Obrázek č.7: Posloupnost oken průchodu aplikací Stavový diagram na obrázku č.7 popisuje návaznost oken a dialogů. Po spuštění aplikace se zobrazí úvodní obrazovka Welcome Screen. Ta vám nabízí dvě možnosti. Můžete zvolit načtení modelu budovy ze souboru a tím rovnou zobrazit náhled simulace. V opačném případě vás čeká průchod několika dialogy, které dohromady tvoří editor modelu budovy. Jako první se vám zobrazí dialog Create new building. V tohoto dialogu vyplníte jméno budovy, její rozměry a počet pater. Po potvrzení pomocí Outer Space creatoru a Building Creatoru vyznačíte na čtvercové síti půdorys budovy a oblast, ve které se nachází pouze okolní prostor. Pokud už jste s tvarem spokojeni, zbývá pouze naplnit patra pokoji, ty pospojovat dveřmi a schody, umístit okna a nakonec i jednotlivá zařízení. Toho docílíte tak, že v dialogu Floor Picker vyberete patro, které chcete přizpůsobit a následně v okně Floor Creator vytvoříte pokoje, opět pomocí čtvercové sítě. Můžete umisťovat také schody a okna s dveřmi. Ty se po kliknutí do čtvercové sítě přichytí na nejbližší zeď a tím určí svoji pozici. Poté můžete přejít do Floor Decoratoru, ve kterém pomocí klikání umístíte zařízení a celé patro uložíte. Nakonec se vám znovu zobrazí Floor Picker a vy můžete opět vybrat patro k editaci nebo potvrdit kompletní vytvoření vámi namodelované budovy. 9 S t r á n k a

4. Rozhraní s ostatními aplikacemi 4... Fyzikální modul Fyzikální modul bude vložen jako DLL knihovna a komunikace mezi ním a simulátorem inteligentních budov bude probíhat po předem určeném rozhraní, které bude tvořeno dvěma interface. V první fázi si při spuštění aplikace simulátor nareferencuje instanci modulu a modul si zaregistruje tento simulátore. Tento krok je z důvodů, aby o sobě modul i simulátor navzájem věděli. Ve druhé fázi si modul zažádá o model celé budovy, který mu bude simulátorem navrácen. Tento krok je proveden metodou (getbuildingparameters). Následně si modul zažádá o informace o teplotách v jednotlivých pokojích pomocí metody (getroomtemperature). Veškeré případné změny bude simulátor modulu hlásit pomocí eventy, která bude mít v sobě jednoznačné id zařízení, na kterém se něco změnilo, a modul si již zažádá o nové informace od simulátoru. Obr č.8: Popis komunikace s fyzikálním modulem Simulátor pomocí metody RegisterSimulator() zavolá fyzikální modul, tímto modul získá referenci na Simulátor. Modul zavolá metodu RegisterPhysicalModel() a tím předá Simulátoru referenci na sebe. Dále probíhá komunikace pouze pomocí metod UpdateBuilding() a UpdateTemperatureSettings() pro přenos serializovaných dat. class ClassDiagram «interface» IPhysicalModuleFacade + RegisterSimulator(ISimulatorFacade) : void + UpdateBuildingModel(String) : void «interface» ISimulatorFacade + RegisterPhysicalModel(IPhysicalModuleFacade) : void + UpdateTemperatureSettings(String) : void Obrázek. č.9: Rozhraní pro komunikaci s fyzikálním modulem 0 S t r á n k a

4..2. Neuronová vrstva Komunikace mezi naším simulátorem a neuronovou sítí bude probíhat pomocí dvou websevice a předem domluvených rozhraní. Následuje popis metod, které do těchto rozhraní patří. Naše aplikace bude poskytovat rozhraní s těmito metodami: RequestWholeModel () Tato metoda serializuje strukturu budovy a výsledek zveřejní pomocí webservice. Neuronová sít si poté může tuto strukturu stáhnout. setvalues (Map <string, double>) Nastaví nové hodnoty na zařízeních budovy. Kolekce obsahuje klíče, které představují Id objektů, a hodnoty, které se mají na těchto objektech nastavit. getvalues() : Map <string, double> Tato metoda vrátí všechny hodnoty zařízení, které se změnily. Nová hodnota je vždy identifikována pomocí Id zařízení Neuronová síť bude poskytovat rozhraní s těmito metodami: ModelReady() Touto metodou bude neuronová síť upozorněna, že je pro ni připraven nový model budovy a že si o něj může zažádat zavoláním metody RequestNewModel() ModelChanged () Touto metodou bude neuronová síť upozorněna, že se změnily hodnoty nějakého zařízení v budově a má si o ně zažádat pomocí metody getvalues() S t r á n k a

sd sequence OurSystem Neuron Network ModelReady() RequestWholeModel() setvalues(map <string, double> values) *ModelChanged() getvalues() :Map <string, double> values setvalues(map <string, double> values) ModelReady() RequestWholeModel() Obr. č.0: Příklad komunikace s neuronovou sítí 2 S t r á n k a

5. Diagram nasazení Obrázek č.: Deployment diagram aplikace Celá naše aplikace bude spuštěna na jednom osobním počítači s operačním systémem Windows pod platformou.net 4.0 a skládá se ze dvou částí, naší spustitelné aplikace a dll knihovny Physical Model, které je vytvořena skupinou 4ML. Aplikace navíc pomocí protokolu http komunikuje s externí webservice. 3 S t r á n k a

6. Přiložené dokumenty K návrhu je přiložena vygenerovaná dokumentace, která detailně popisuje celou implementaci. 4 S t r á n k a

7. Závěr Aplikace byla navržena tak, aby byla lehce rozšiřitelná jak o další objekty, které jsme do modelu budovy nezahrnuli, tak i o další externí moduly, se kterými bude komunikovat. Společně s tím, že bude šířena jako open source tak získává obrovský potenciál být využita v praxi jako simulátor inteligentních budov. 5 S t r á n k a