Úvod do spolehlivých systémů 10. 1. 2017

Vše co není uvedeno jinde

Úvod do spolehlivých systémů 10. 1. 2017

Příspěvekod Palec » 15. 1. 2017 20:22

Zápočtová písemka s uzavřenými odpověďmi, z nichž je vždy alespoň jedna správně. Otázek je deset, bodování dohlížející Jan Kofroň nechtěl specifikovat ("napište to, jak nejlépe umíte"), časový limit byl 60 minut. Test probíhal od 09:00 do 10:00, druhý den před polednem mi dorazil zápočet v SISu. V půl třetí pak dorazil ještě mail ze SISu, že pro ty, kdo na test nedorazili nebo v něm neuspěli, je náhradní termín další týden (9 dní po původním termínu) a tento termín je poslední.

Před testem bylo řečeno, že tento předmět nedovoluje velkou variabilitu v otázkách; je to jenom jedna přednáška za čtrnáct dní. Jde tedy čekat, že na náhradním termínu bude prakticky stejný test, a nejspíš se nebude test moc lišit ani mezi ročníky přednášky.

Dvě otázky jsem si stihl zaznamenat téměř doslova, včetně odpovědí, u zbytku jen rámcově znění otázky. Tučné odpovědi jsou ty, kterém jsem zvolil, kurzívou jsou mé komentáře.


  1. Mechanismy RPC zpravidla generují proxy/stub podle signatury volané procedury. Jak ji lze pro tyto účely popsat?

    1. deklarace z jazyka aplikace (Tímhle si nejsem jistý. V principu to ale smysl dává.)
    2. speciální jazyk pro popis signatur
    3. deklarace z jazyka aplikace, doplněná o nezbytné anotace
    4. deklarace v obecném datovém formátu (např. XML)
    5. introspekce přeloženého kódu

  2. Jaké funkce jsou typicky dostupné v middleware pro komunikaci zprávami v distribuovaném prostředí?

    1. zaslání zprávy typované jako strukturovaný datový typ
    2. otevření streamu bytů mezi procesy
    3. odeslání zprávy s čekáním na doručení
    4. odeslání zprávy bez čekání na doručení
    5. odeslání zprávy zašifrované pro příjem konkrétním procesem

  3. Co je to throughput?

  4. Jaké druhy performance counters neexistují?

  5. Co neplatí pro model určený pro verifikaci? (Určitě nepostihuje všechny detaily. Model pro generování kódu by naopak musel.)

  6. Jaké jsou problematické aspekty model checkingu? (Model checking není inherentně exponenciálně těžký, problematická je exponenciální velikost stavového prostoru.)

  7. Jaké existují behavior diagrams v UML? (Výběr z konkrétních.)

  8. Jaké charakteristiky mají interní DSL?

  9. Co platí o hard RT systémech?

  10. Která z tvrzení platí pro periodické plánování úloh?
(Cca polovina tvrzení se týkala rate monotonic plánování.)

Odpovědi se snažily být koncipované tak, aby bylo potřeba trochu přemýšlet. Ne všechno zaznělo na přednášce explicitně, často bylo potřeba domyslet jednoduché důsledky.
Palec
 

Re: Úvod do spolehlivých systémů 10. 1. 2017

Příspěvekod Palec » 15. 1. 2017 20:24

Eh, ta závorka pod otázkami patří k poslední otázce... Říkal jsem si, že tahle editace před odesláním snad už náhled nepotřebuje. :-/
Palec
 

Re: Úvod do spolehlivých systémů 10. 1. 2017

Příspěvekod Palec » 15. 1. 2017 20:42

Abyste nemuseli hledat starší příspěvky na tomhle fóru, tady je seznam odkazů:


  • příprava z roku 2016: Odkazuje na dokument na Google Docs, kde má každý možnost navrhovat úpravy. Původní autor, Petr Mánek, mé úpravy schválil během několika hodin, napodruhé během deseti minut. Slajdy a tenhle výtah z nich mi na přípravu na test celkem stačily. Poznámky z přednášky jsem skoro nepotřeboval.

  • 10. 2. 2016: Otázky prý měly možnosti A-F (letos jen A-E), jinak stejný formát i konkrétní otázky jako letos. Potřeba 4/10 bodů, z každé otázky max. 1.

  • 29.1.2014: Otázky vypadají stejně jako letos, formát také. Prý za částečnou odpověď možno získat část bodů, jediná chybná odpověď znamená ztrátu celé otázky, pro úspěšné splnění jsou potřeba 4 body. Úspěšnost prý cca 50 %.
Palec
 

Re: Úvod do spolehlivých systémů 10. 1. 2017

Příspěvekod Palec » 13. 2. 2017 11:53

Při konzultaci s jednou druhačkou, která musela na opravný termín, jsem si uvědomil, že tenhle předmět určitě není vhodný pro druháky bakaláře (ačkoliv tady na fóru je tak klasifikovaný). Předpokládá se, že student má dobře zvládnuté principy počítačů a OS (předmět v ZS prváku); bez toho se nebude chytat v middleware, RT a výkonnosti. Musí umět dobře objektově programovat a dokázat si představit opravdu velký systém (IMO předmět C# & .NET v ZS druháku). Hodí se vědět, co je to logika (předmět v ZS druháku), jinak nedává smysl mluvit o temporální logice u model checkingu a i metamodelování bude dávat menší smysl. Pokud neví, co je to automat a gramatika (předmět v LS druháku), velká část přednášky o modelování mu bude nesrozumitelná. U metamodelování se jako příklad uvádí XML; bez jeho znalosti nejspíš ani jiné příklady nepadnou na úrodnou půdu a bez konkrétního příkladu se hodně těžko dá chápat, o co jde. Na XML jde narazit všude možně, ale také se mu jde snadno vyhnout. Studovat kvůli němu samostatný předmět (Technologie XML) je IMO overkill; kdo má zájem o tenhle úvod do D3S, XML se naučí sám někde na netu a bude mu na to stačit pro pochopení do rozumné hloubky pár odpolední.

Opravný termín prý měl identické zadání jako první termín testu.

Byl jsem si popovídat s kolegou Kofroněm o předmětu a o testu (abych se podíval, co jsem měl špatně, a lépe pochopil, co od toho chtěli). Vyplynulo z toho několik zmínění hodných závěrů.


  • Bodování se shodovalo s předchozími lety (za otázku max. 1 bod, za částečné zaškrtání poměrná část, za jedinou chybně označenou odpověď ztráta celé otázky). Potřeba byly 4 body, nejlepší bylo asi 8,9 bodu, já měl kolem 8, většina byla někde kolem 7, úspěšnost byla cca 80 %.

  • Otázka 1 má podle vzorového řešení mít zaškrtnuté všechny odpovědi. V odpovědi d) podle mě chybí popis sémantiky toho XML, co do toho, jak jsou signatury reprezentovány pomocí XML nodes (elementy, atributy, atd.); a kdybych ho dodal, dostanu aplikaci XML, která jde už považovat za IDL. U introspekce přeloženého kódu přiznávám, že jsem narazil na limity své představivosti a uvažoval o příliš slabé introspekci. V principu to fungovat může.

  • Otázka 7 nepočítá diagramy interakcí mezi diagramy chování, přestože ve slajdech je docela jasně nakresleno, že jsou jejich podtypem. Tahle nekonzistence se vyskytuje i na Internetu: česká Wikipedie uvádí skupiny diagramů tři, kdežto anglická Wikipedie jen dvě a používá obrázek, který je na slajdech a který obsahuje i specifikace UML 2.5 (aktuální) v příloze A. Tipuji, že důvodem je historická změna ve standardu UML. Ověřovat to se mi nechce, ale kdybyste někdo chuť měli nebo na to náhodou narazili, vysvětlení si tu rád přečtu v odpovědi.

  • U otázky 9 není pravda, že hard RT systémy potřebují vlastní HW (stačí, aby HW uměl RT software separovat od software, který RT není). Také mě překvapilo, že se i u hard RT systémů považuje cost function za možné kritérium porovnávání kritičnosti, když se pro různé systémy liší vlastně jen v deadline a ceně (zaplacené za nestihnutí deadline). Přišlo mi, že cost function dává smysl hlavně pro soft RT, kde je důležitý průběh funkce po překročení deadline. Vzorová odpověď má ale nejspíš na mysli to, že je důležitý nejenom tvar grafu, ale i hodnota (kolik za nestihnutí zaplatím, např. přepočteno na peníze). Primární problém je asi v tom, že jsem nikdy neslyšel definici kritičnosti RT... :twisted:

  • Příští rok dost možná bude ten předmět vypadat trochu jinak. Uvažuje se o seškrtání až absurdně širokého záběru a probrání některých částí do větší hloubky, aby se také šlo v testu ptát na zajímavější věci.
Palec
 


Zpět na Ostatní

Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 2 návštevníků

cron