# 1
Dámy a páni, moje meno je Kamila Součková a moja bakalárska práca bola “Dizajn a implementácia RFID prístupového systému”. [NEXT] Konkrétne...

# 2
cieľom bolo nahradiť systém používaný tu na fakulte napr. na prístup do počítačových miestností za niečo, čo bude viac vyhovovať požiadavkám fakulty. [SLAJDBLA]

[NEXT] Požiadavky našej fakulty sú...

# 3

v prvom rade dôveryhodnosť – keďže systém bude použitý na pomerne podstatné veci, chceme aby
sa dalo spoľahnúť na to, že bude fungovať aj v nečakaných situáciách, napr. pri problémoch s HW alebo SW častí systému
ďalej musí byť bezpečný, [SLAJDBLA]

aby bolo na našej fakulte praktické používať ho, musí [SLAJDBLA]
rozšíriteľný: nevieme predpovedať budúcnosť; a tiež chceme umožniť inkrementálny vývoj
jednoduchý na vývoj: Deadlock bude udržiavaný študentami v ich voľnom čase (ktorého nebýva veľa); členovia ŠVT sa budú často meniť
jednoduchý na použitie: musí byť jednoduché nastaviť prístupové práva (dôležitou súčasťou tohto je integrácia s existujúcimi systémami ako AIS); a obsluha nemá robiť veci, ktoré sa dajú automatizovať
ďalšie požiadavky existujú, ale nie sú kriticky dôležité pre moju prácu
[NEXT] zaujímavé sú tiež požiadavky na škálovateľnosť systému

# 4

[NEXT] Samozrejme, nejaké takéto systémy už existujú, preto je dôležitá otázka, čo má Deadlock navyše

# 5

[NEXT]: --

# 6

Ako teda deadlock vyzerá?

# 9

[NEXT]: V mojej práci bolo treba vyriešiť 3 dôležité otázky...

# 12

Vysokoúrovňové pravidlá sú špecifické pre účel a budú vyvinuté pre každý účel zvlášť.
Aplikácie implementujúce vysokoúrovňové pravidlá nesmú nič predpokladať o iných pravidlách v systéme – nesmú ich zmazať, editovať, alebo predpokladať, že iné neexistujú.

Aby sme umožnili túto spoluprácu medzi rôznymi modelmi vysokoúrovňových pravidiel (a aby sme zaistili konzistenciu), každé pravidlo je označené ako patriace do práve jedného ruleset-u. Toto umožňuje zabezpečiť, že aplikácie môžu chytať len “ich” pravidlá.

[NEXT] Keďže vysokoúrovňové pravidlá sú špecifické pre konkrétne použitie, ďalej sa pozrieme na interné pravidlá.


# 13

je ťažké nad nimi rýchlo rozmýšľať
vyhodnocovanie môže byť drahé


# 16

server/controller 

# 17

[NEXT] my favourite feature, because it emerged from these nice properties without explicitly designing for it [NEXT] are live version upgrades

# 19

PING…
ALOG…
XFER…

k zvyšku sa rada vrátim v diskusii

kódovanie packetov používa CBOR a rada sa o ňom porozprávam v diskusii

# 21

server/controller 

# 23

[NEXT] zhrnutie

# 24

cieľom práce bolo vytvoriť dôveryhodný a praktický systém pre našu fakultu, [NEXT] a hoci systém nie je celkom dokončený, dizajn a implementácia dôležitých častí existuje a požiadavky sme najmä vďaka dobrému dizajnu a dôrazu na jednoduchosť a modularitu splnili.

# 25

a hoci systém nie je celkom dokončený, dizajn a implementácia dôležitých častí existuje a požiadavky sme najmä vďaka dobrému dizajnu a dôrazu na jednoduchosť a modularitu splnili.

# 29

špecifikácia času (ktorá sa dá vidieť z databázových tabuliek uvedených v časti o implementácii a aj v tejto kapitole bola čiastočne popísaná)...

# 38

 * modularity: independent modules with well-defined, simple, minimal interfaces => easier development, sensible design, low new dev entry cost
 * Principle of Least Astonishment:  “People are part of the system. The design should match the user’s experience, expectations, and mental models.” [Saltzer, J.H. and Kaashoek, M.F. 2009. Principles of computer system design: an introduction. Morgan Kaufmann. ] If the design, implementation or behavior of a part of the system is obscure enough to surprise you, it should be redesigned. We should prioritize predictability of the parts of the system which are hard to observe (such as the embedded devices), so that they do not unpleasantly surprise the user.
 * State is bad: state => complexity and difficulties with failure recovery; if state needed, then explicit is better than implicit

# 39

rulesets may be created, modified, deleted atomically (no way to edit a single rule)