Tvorba Katalógu požiadaviek

[Krajcovic70]

• [x] Prvé stretnutie so zadávateľom
• [x] Tvorba úvodného draftu požiadaviek
• [x] Dokončenie katalógu požiadaviek

[tibor-cernak]

Poslal som upravený draft KP na skontrolovanie. Čakáme na odpoveď.

[pavelpetrovic]

posledne pripomienky od zadavatela:

• vstup z klaves: moduly si z inicializacie mozu zaregistrovat callback na nejaku mnozinu shortcut klaves napr. CTRL-A a CTRL-D (zmena v 2. casti: " ak nie je aktívny žiadny konkrétny vstupný prvok." => " ak ma focus lubovoľný jeden vstupný prvok, ak to použitý GUI framework dovolí".
• 3.7. prec slovo niektorych
• 3.8. mozu byt => budu
• 3.10 interagovať s rozhraním => tato formulacia ma zmiatla
• 3.12.2 "Taktiež bude možné" => api umozni sem este napisem komentare k ostatnym

[pavelpetrovic]

• v 3.14 mi skôr sedí požiada ako vyžiada
• navrhujem 3.18 prehodiť do 3.22 a urobiť z toho tretí mód - prehrávanie. (následne poprehadzovať trochu tie požiadavky) v prehrávacom móde sa predpokladá, že riadiaci systém robota nebeží a GUI "simuluje" predchádzajúci beh prevádzkového módu pre tie prvky, pre ktoré bol vytvorený záznam. Jeden z parametrov inicializačnej funkcie modulu je režim. Ak sa modul inicializuje v konfiguračnom režime, vie, že nebude prevádzka, ale stále musí komunikovať s GUI do určitej miery - napr. oznámiť aké prvky poskytuje. Ak sa inicializuje v prehrávacom režime, rovnako a je jeho úlohou zabezpečiť dáta z predchádzajúcej jazdy (ale od GUI dostane priečinok, do ktorého ich predtým zaznamenával). V prevádzkovom režime by sa mali zaznamenávať všetky prvky, ktoré sa nachádzajú aspoň v jednej "aktívnej" šablóne, aby používateľ počas prehrávania vedel ľubovoľne šablóny prepínať, tie prvky, ktoré nie sú v žiadnej, sa nemusia logovať. Toto má ale dosť vážne dôsledky, čiže GUI manažér by mal volať samostatný callback modulu pre logovanie. Jeden callback bude kresliť a druhý bude logovať. Asi bude stačiť pre grafické prvky, textové nech sa logujú ako vedia po svojom. Čiže ak je prvok viditeľný a logovaný, bude sa volať vykresli_sa(handle_na_canvas) zaloguj_sa() ak je viditelny, ale nie je logovany, zavola sa vykresli_sa(handle_na_canvas) a ak nie je viditelny, ale je logovany, zavola sa zaloguj_sa() ine mozno lepsie riesenie moze byt namiesto toho urobit jeden callback a to, ci sa kresli a loguje dat ako jeden parameter "action", co bude bitova maska obsahujuca dva atributy DO_PAINTING, DO_LOGGING, ktore GUI manazer adekvatne nastavi. toto je sice uz diskusia trochu o navrhu, ale v tomto projekte patri to rozhranie do specifikacie a toto je vec rozhrania, takze to asi stale patri sem. Logovanie by mal mať na starosti sám každý modul, nie GUI manažér (asi by GUI manažér mohol poskytnúť aspoň API na uloženie nejakého obázka v pamäti do súboru .PNG, ale to už veľmi záleží na tom, aký grafický framework sa použije a ako celkovo funguje... takže to sem asi nepíšme, alebo iba ako voliteľnú požiadavku)
• 3.19: "Ak áno, systém pošle cestu k adresáru, kde sa majú potrebné údaje ukladať a taktiež maximálnu frekvenciu ukladania." - tieto dve položky (ktorý záznam a frekvencia) by si GUI manažér mal vypýtať od používateľa pri spustení. // už je požiadavka dosť kombinovaná, tak to prípadne rozbite na menšie, aby boli atomické
• v kontexte ostatných tu komentárov je 3.20 asi možné celkom odstrániť (ale najskôr to premyslite či áno), idea je že buď je prevádzka alebo je replay a keď je replay, tak sa iba "animuje" zo záznamu, pričom nemusí sa animovať všetko, ale iba to, čo bolo v prevádzke logované, ostatné prvky šablóny nebudú ukazovať nič (ak máte iný/lepší nápad/predstavu, prípadne skúste sformulovať nejak inak)
• 3.21 by som asi prehodil niekam vyššie, napr. pred 3.16
• 3.23.2. append(" do zvoleného súboru (save-as).")
  // zostáva nevyjasnená otázka ako bude systém vedieť medzi ktorými troma (napr. troma) šablónami // má prevádzkový mód prepínať - napr. pripravím si sedem rôznych šablón, ale teraz chcem používať // iba tri z nich - musím tie ostatné presunúť do iného priečinka a systém bude prepínať medzi všetkými, // ktoré nájde v nejakom priečinku? ok, dá sa s tým žiť, alebo iná možnosť, že niekde - napr. v tom konfigu, // keď ho už máme - bude zoznam šablón, ktoré majú byť použité, keď sa nabudúce spustí prevádzkový mód // potom by bolo fajn mat možnosť poslať konfig ako command line parameter, čiže budem mať pripravených // viac konfigov
• 3.24.2. Prevádzkový mód umožní používateľovi prepínať medzi šablónami pomocou klávesových skratiek => append(", alebo kliknutím na nenápadnú kontrolku niekde v GUI rozhraní.")
  // to pre situácie, že GUI beží na tablete a klávesnica tam ani nie je
• 3.23.7. "Ďalšou" -> "Hlavnou" // alebo nieco podobne a "nastavenia veľkosti a polohy" => "nastavenia prítomnosti, veľkosti a polohy"
  // teda nie vsetky dostupne prvky musia byt v kazdej sablone, da sa vybrat, ci tam prvok je, alebo nie je
• 3.24.3. "3.7" => "3.10"

[tibor-cernak]

V komentári sa spomína "inicializácii modulu v režime", ale úplne nerozumieme prečo by sa mal modul inicializovať v rôznych režimoch? Nestačila by jedna inicializácia, kde modul poskytne svoje funkcie, prvky alebo prípadne premenné s možnými hodnotami? Nie je to zbytočná komplexita.

V prevádzkovom režime by sa mali zaznamenávať všetky prvky, ktoré sa nachádzajú aspoň v jednej "aktívnej" šablóne, aby používateľ počas prehrávania vedel ľubovoľne šablóny prepínať

Máme to teda chápať, že v prevádzkovom režime sa majú zaznamenávať všetky možné prvky, ktoré su v šablóne? Nechceli sme to spraviť tak, že v konfiguračnom móde systému si použivateľ zvolí, ktoré prvky sa budú logovať?

3.19: "Ak áno, systém pošle cestu k adresáru, kde sa majú potrebné údaje ukladať a taktiež maximálnu frekvenciu ukladania." - tieto dve položky (ktorý záznam a frekvencia) by si GUI manažér mal vypýtať od používateľa pri spustení.

Je už v poriadku táto požiadavka?

• Pri inicializácii GUI prvku vie používaťeľ cez textový konfiguračný súbor alebo v konfiguračnom móde systému oznámiť, či sa výstup prvku bude logovať pre prípadné prehranie. Vtedy si GUI manažér pri spustení vypýta od používateľa adresár pre záznam a frekvenciu.

alebo po rozbití

• Pri inicializácii GUI prvku vie používaťeľ cez textový konfiguračný súbor alebo v konfiguračnom móde systému oznámiť, či sa výstup prvku bude logovať pre prípadné prehranie.
• Pri logovaní výstupu prvkov pre prípadné prehranie si GUI manažer pri spustení vypýta od používateľa adresár pre záznam a frekvenciu

Taktiež sme sa bavili, že či je treba mať konfiguračný súbor pre GUI manažer. V požiadavkách sa spomína v bode:

• 3.4. GUI manažér načíta zoznam modulov z konfiguračného súboru

Ale keďže sme sa bavili, že moduly budu manuálne prilinkované a program sa bude zakaždým prekompilovávať, treba mať tento konfiguračný súbor? Ďalej je spomenutý v bode:

• 3.19. Pri inicializácii GUI prvku vie používateľ cez textový konfiguračný súbor alebo v konfiguračnom móde systému oznámiť

Tu tiež si úplne nevieme predstaviť, ako v tom konfiguračnom súbore sa bude spomínať nejaký modul a ešte k tomu prvok tohto modulu. Čo ak ten modul nebude prilikovaný? Pri zmene bude treba robiť zmeny na rôznych miestach. Nestačilo by v konfiguračnom móde systému žaškrtnúť checkbox ktorý bude znamenať, že sa výstup prvku má logovať?

Tým pádom potreba mať konfiguračný súbor padá. Aký je Váš názor na to?

Ostatné poznámky sme zapracovali do KP, ktorý zašleme po vyriešení vyššie spomenutých bodov.

[pavelpetrovic]

V komentári sa spomína "inicializácii modulu v režime", ale úplne nerozumieme prečo by sa mal modul inicializovať v rôznych režimoch? Nestačila by jedna inicializácia, kde modul poskytne svoje funkcie, prvky alebo prípadne premenné s možnými hodnotami? Nie je to zbytočná komplexita.

Tým, že mu tam pošleme v akom režime sa má inicializovať, komplexitu nejak zásadne nezvyšujeme, lebo tie režimy tam už aj tak sú. Keď sa modul ale dozvie v akom režime to celé beží, tak bude vedieť, či sa má pripájať na zvyšok systému (prevádzkový mód), alebo pre replay mód bude načítavať a zobrazovať záznamy z logu, alebo iba konfiguračný modul, keď nemusí robiť nič. Nejakym sposobom modulu musite oznamit, v akom rezime to bezi, tak preco nie hned cez init?

V prevádzkovom režime by sa mali zaznamenávať všetky prvky, ktoré sa nachádzajú aspoň v jednej "aktívnej" šablóne, aby používateľ počas prehrávania vedel ľubovoľne šablóny prepínať

Máme to teda chápať, že v prevádzkovom režime sa majú zaznamenávať všetky možné prvky, ktoré su v šablóne? Nechceli sme to spraviť tak, že v konfiguračnom móde systému si použivateľ zvolí, ktoré prvky sa budú logovať?

Máte pravdu, že je to v konfigu zaznačené, ktoré sa majú zaznamenávať. Týmto som skôr chcel povedať, že tie, ktoré nie sú v ani jednej šablóne zobrazené sa zrejme zaznamenávať nemusia, lebo sa nikdy nezobrazia, ale keď tak nad tým rozmýšľam, zrejme by sa dal ten záznam pustiť aj s inou mnozinou sablon, cize s inym konfigom, aj ked neviem, ake ine nasledky by to malo a ci to chceme vobec dovolit... mal som pocit, ze sa bude dat urobit replay iba s rovnakym konfigom ako bol urobeny zaznam, alebo teda aspon s takym, ktory je dostatocne kompatibilny - no a tym padom mate asi pravdu, ze ak je v konfigu zapisane, ze sa ma logovat, tak nech sa loguje nezavisle od toho, ci je v nejakej sablone zobrazeny alebo nie. To mi ale pripomenulo jednu informáciu - že zaznamenané obrázky sa môžu zobrazovať aj v inej veľkosti ako boli zobrazené počas prevadzky, čiže prehrávanie podľa záznamu by malo vedieť preškálovať obrázky do inej veľkosti (môžete to niekde pripomenúť - v predpokladoch v 2.casti, alebo kde chcete).

Tiež prosím jemne upravte ešte druhú časť dokumentu na základe vecí, ktoré pribudli neskôr a nie sú tam ani trochu spomenuté. (mám na mysli hlavne ten záznam, ale celkovo to pozrite). Naopak, v druhej časti sa píše o tom klikaní a ťahaní mysou v grafickom prvku a nie som si istý, či to niekde v tretej časti máme, tam by to urcite malo byt.

3.19: "Ak áno, systém pošle cestu k adresáru, kde sa majú potrebné údaje ukladať a taktiež maximálnu frekvenciu ukladania." - tieto dve položky (ktorý záznam a frekvencia) by si GUI manažér mal vypýtať od používateľa pri spustení.

Je už v poriadku táto požiadavka?

* Pri inicializácii GUI prvku vie používaťeľ cez textový konfiguračný súbor alebo v konfiguračnom móde systému oznámiť, či sa výstup prvku bude logovať pre prípadné prehranie.  Vtedy si GUI manažér pri spustení vypýta od používateľa adresár pre záznam a frekvenciu.

alebo po rozbití

* Pri inicializácii GUI prvku vie používaťeľ cez textový konfiguračný súbor alebo v konfiguračnom móde systému oznámiť, či sa výstup prvku bude logovať pre prípadné prehranie.

* Pri logovaní výstupu prvkov pre prípadné prehranie si GUI manažer pri spustení vypýta od používateľa adresár pre záznam a frekvenciu

to 3.19 a 3.20 je trochu matuce, lebo to vyzera skoro rovnako, ale jedno hovori, ze ci sa ma logovat a druhe, ci sa ma prehravat. Myslim, ze sme dospeli k zaveru, ze bud sa prehrava alebo je prevadzka, ze kombinovany rezim nepodporujeme (lebo by aj tak neboli tie ulozene casovo synchronizovane s tymi, co sa deju nazivo), takze toto nastavenie asi moze byt to iste - v konfigu, kde je zoznam modulov, bude ku kazdemu zaznacene, ci sa zaznamenava alebo nie a znamena to, ze v prevadzkovom rezime sa teda zaznamenava a v replay rezime sa teda prehrava zo zaznamu. Cize ak aspon jeden modul ma zapnuty zaznam, tak pri prevadzkovom rezime potrebujeme ziskat adresar, do ktoreho budu vsetky logovane moduly zapisovat zaznamy, ale pre kazdy modul potrebujeme aj frekvenciu (ak frekvencia nema byt spolocna, co by asi nemusela byt). Jedno nastavenie frekvencie (napr * alebo 0) by malo ale znamenat, ze sa uklada kazdy novy udaj. Bolo by neprijemne, ak by sa pri spusteni museli rucne nahadzovat frekvencie zaznamu pre kazdy jeden prvok, co je spusteny, takze tie frekvencie nech su radsej iba v konfiguracnom subore. A najlepsie bude, ked aj ta cesta, do ktoreho priecinka sa robia zaznamy, bude v tom konfiguracnom subore, nech to furt pri spustani netreba rucne vyberat. V tom subore priecinku so zaznamami nech sa vytvori vzdy podpriecinok podla aktualneho datumu casu. Tazke dajme prec, ze nieco musi pouzivatel pri spusteni este vyberat, staci toto mat v konfigu - pre prevadzkovy rezim. Avsak pre replay rezim treba mat nejaky sposob ako urcime, co sa replayne. A to by teda mohlo byt tak, ze bud to povie cez command line, alebo to vyberie v nejakom listboxe po spusteni, ale to by som nechal ako volitelnu poziadavku, ak to pojde cez command line vybrat, to je zaklad, ak to pojde vybrat aj v okienku po spusteni, ak clovek nedal nic do command line, tak nam to samozrejme sprijemni zivot, lebo kopirovanie mena adresara do command line pri spustani je otrava, ale da sa s tym zit.

Taktiež sme sa bavili, že či je treba mať konfiguračný súbor pre GUI manažer. V požiadavkách sa spomína v bode:

* 3.4. GUI manažér načíta zoznam modulov z konfiguračného súboru

Ale keďže sme sa bavili, že moduly budu manuálne prilinkované a program sa bude zakaždým prekompilovávať, treba mať tento konfiguračný súbor? Ďalej je spomenutý v bode:

* 3.19. Pri inicializácii GUI prvku vie používateľ cez textový konfiguračný súbor alebo v konfiguračnom móde systému oznámiť

Tu tiež si úplne nevieme predstaviť, ako v tom konfiguračnom súbore sa bude spomínať nejaký modul a ešte k tomu prvok tohto modulu. Čo ak ten modul nebude prilikovaný? Pri zmene bude treba robiť zmeny na rôznych miestach. Nestačilo by v konfiguračnom móde systému žaškrtnúť checkbox ktorý bude znamenať, že sa výstup prvku má logovať?

Tým pádom potreba mať konfiguračný súbor padá. Aký je Váš názor na to?

konfiguracny mod sa pusti raz, ked je to nakonfigurovane, ulozi sa to (do mnoziny templejtov a este do nejakeho configu, ktory hovori, ktore templejty platia pre dany config). a potom na druhy den sa to spusti, ked uz je iba prevadzka a nic netreba znovu prekonfigurovat.

cize do suborov treba ukladat jednak templejty, jednak niekde povedat, ktore templejty z tych vsetkych, co su tam ulozene maju byt v danom behu k dispozicii a tiez to, ci sa moduly loguju a s akou frekvenciou, do akeho priecinka sa vytvara datumovy-casovy podpriecinok so vsetkymi logmi z daneho behu. no a mal by tam byt aj zoznam modulov, lebo nie vsetky moduly, ktore maju bezat musi byt nutne vidno.

V zdrojakoch je jedna funkcia, kde je zoznam init-ov na moduly, ktore su prilinkovane, ano, takze to, ktore moduly sa spustia je urcene touto funkciou. Bolo by mozne mat zoznam modulov, ktore sa maju inicializovat este aj v konfigu, potom by implementacia mohla vyzerat nejak takto:

if (configured("lidar")) init_lidar(....); if (configured("camera")) init_camera(...); ...

kazdy modul je identifikovany svojim menom...

cize dolezita informacia - konfigov moze byt viacero - podla toho co ideme ladit, tak si vyrobime sadu sablon pre ten use-case a k tomu prislusny konfig. preto konfig je parameter command line, ak sa nezada, nech sa vyberie prvy, co sa najde v prislusnom adresari.

Ostatné poznámky sme zapracovali do KP, ktorý zašleme po vyriešení vyššie spomenutých bodov.

supra

[tibor-cernak]

@pavelpetrovic Na mail sme poslali finálnu verziu KP na formálne odsúhlasenie.