od 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...
- 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.
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ů.
[list]
[*] 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: [url=https://cs.wikipedia.org/wiki/Unified_Modeling_Language#Diagramy]česká Wikipedie[/url] uvádí skupiny diagramů tři, kdežto [url=https://en.wikipedia.org/wiki/Unified_Modeling_Language#Diagrams]anglická Wikipedie[/url] jen dvě a používá obrázek, který je na slajdech a který obsahuje i [url=http://www.omg.org/spec/UML/2.5/]specifikace UML 2.5[/url] (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.[/list]