IMS: Seminář o řešení projektů

Transkript

1 IMS: Seminář o řešení projektů Martin Hrubý Modelování a simulace (IMS) FIT VUT 2011/12

2 Zápočet v IMS Democvičení 1 a 2, bonusové cvičení. Seminář k řešení projektů. Půlsemestrální test až 10 bodů. Projekt až 20 bodů. Celkem (Zisk) až 30 bodů, 15 a více dává zápočet. Zisk 13 nebo 14 pokud dojde k dobré revizi projektu, lze navýšit celkovou sumu na 15. Zisk < 13 (tzn. 12, 11, 10, ) - bez zápočtu.

3 Smysl simulačního projektu Co se řeší? Proč se to řeší? Jak se to řeší? Jaký je výsledek, tzn. závěr? K čemu je výsledek/závěr dobrý? Speciálně u simulací: věří se tomu výsledku? Nácvik pro reálnou situaci vytvoření modelu a simulační studie.

4 Řešitelé projektu Typicky dvojice studentů, projekt odevzdává zástupce týmu (ten první ve dvojici). Řešit může i jednotlivec, ovšem bez úlev na kvalitě zpracování. Pokud se tým rozpadne: Stále mohou projekt dokončit jednotlivci (bez úlev). V dokumentaci tento fakt popsat. Fakt, že se tým rozpadne den před odevzdáním nelze brát jako argument pro slabší úroveň řešení.

5 Termín odevzdání Zatím stanoven na Budu se snažit projekty hodnotit průběžně Je tedy výhodné projekt odevzdat s předstihem: Dřívější informace o hodnocení. Odevzdání je ovšem konečné. Víc času na řešení problémů. První verze hodnocení by mohla být cca 15. ledna. Pokud nebudou zápočty jasné v době prvního termínu zkoušky, lze na zkoušku jít bez zápočtu.

6 Konzultace Tento seminář by měl odpovědět maximum otázek. Další otázky ve fóru předmětu. y nemají garantovanou odpověď (zejména v čase). Osobní návštěva, nejlépe v dopoledních hodinách.

7 Konzultace, nevhodné otázky Co znamená moje téma projektu? Co mám v projektu dělat? Jak mám projekt dělat? Jak mám projekt udělat, abych dostal plný počet bodů? Už je můj projekt ve stavu, abych za něj dostal plný počet bodů? Projekt je individuální dílo studenta ne výsledek spolupráce student-učitel.

8 Forma odevzdání projektu WIS, termín Projekt-odevzdávání projektů Archív.tar.gz,.zip (ověřit na merlinovi!!!). Zdrojové texty programu (bez diakritiky). Makefile. Dodatečná data (obrázky, grafy, tabulky, výsledky). Dokumentace výhradně PDF (ověřit čitelnost).

9 Funkčnost programu Povolené jazyky: C/C++, Python, Java. Simulační jazyky (Simula 67,...). Musí být přeložitelné a funkční na merlin/eva. Toto lze ověřit! Make, make run. Ant varianta. Tady větší důraz na ověření! Preferováno: C/C++, SIMLIB

10 Prezentace projektu Letos se nepraktikuje. Dobrovolná, volitelná, nehodnocena body. Termíny budou ještě stanoveny. Doba cca 5 minut. Cílem prezentace je k projektu něco zásadního říct, co by mohlo předejít nějakým pochybnostem při hodnocení. Ověřit zájem u studentů.

11 Hodnocení, podání vysvětlení Hodnotitel má právo povolat v libovolném okamžiku (po odevzdání) tým k podání vysvětlení. Vysvětlení musí být schopni podat oba členové týmu. Pokud nejsou: Snížení bodového hodnocení (nedůvěryhodný projekt). Snížení bodového hodnocení jednoho z týmu. Zpochybnění jeho účasti na projektu. V extrémním případě 0 bodů pro jednoho nebo oba.

12 Morální poklesky při řešení Hodnocení 0 body pro všechny zúčastněné. Předání kauzy přestupkové komisi FIT.

13 Kritické případy 0 bodů Model je nevalidní tak, že to pozná i laik. Model/program je nepřeložitelný, nedokončený nebo nefunkční. Obzvlášť pochybný je projekt prezentující výsledky z evidentně nefunkčního modelu. Nejsou dodrženy formální náležitosti projektu (jako např. formát souboru, programací jazyk). Některá část projektu zcela chybí nebo nedosahuje minimálních požadavků (není dokumentace nebo je triviální, případne je dokumentace, ale chybí model).

14 FAQ: je moje zadání dostatečně složité? Toto není důležité. Podstatné je: Reálnost problému a jeho smysluplnost. Od počátku jasná prvotní otázka projektu (co má být výsledným zjištěním a bude to pro někoho novým sdělením?). Validní model. Technicky obsažná simulační studie se zodpovězením prvotní otázky. Poznámka: poradce od Arthur Andersen Výsledné sdělení je důležité speciálně u SHO

15 Dokumentace Technická zpráva má povinnou strukturu (nedodržení > ztráta bodů). Zpráva (simulační studie) musí obsahovat všechna důležitá fakta. Nejsou ústní dodatky. Struktura je obecná, přesto u jednotlivých okruhů je třeba formulace přizpůsobit.

16 Obecná struktura technické dokumentace Úvod Fakta Koncepce Způsob řešení Testování/experimenty Závěr

17 1. Úvod Úvod musí vysvětlit, proč se celá práce dělá a proč má uživatel výsledků váš dokument číst. V této práci je řešena implementace..., která bude použita pro sestavení modelu... Na základě modelu a simulačních experimentů bude ukázáno chování systému... v podmínkách... Smyslem experimentů je demonstrovat, že pokud by..., pak by... Správnost zvolené koncepce byla ověřena... Psaní úvodů je náročná práce. Úvody se čtou!!!

18 1.1 Zdroje faktů Kdo se na práci podílel jako autor, odborný konzultant, dodavatel odborných faktů, význačné zdroje literatury/fakt,... je ideální, pokud jste vaši koncepci konzultovali s nějakou autoritou v oboru (v IMS projektu to je hodnoceno, ovšem není vyžadováno) pokud nebudete mít odborného konzultanta, nevadí. Nelze ovšem tvrdit, že jste celé dílo vymysleli s nulovou interakcí s okolím a literaturou. Zdroj údajů

19 1.2 Validita modelu/koncepce V jakém prostředí a za jakých podmínek probíhalo experimentální ověřování validity modelu. Pokud čtenář/zadavatel vaší zprávy neuvěří ve validitu vašeho modelu, obvykle vaši práci odmítne už v tomto okamžiku.

20 2. Rozbor tématu a použitých metod (Fakta) Podstatná fakta o systému musí být zdůvodněna a podepřena důvěryhodným zdrojem (vědecký článek, kniha, osobní měření a zjišťování). Alespoň jeden (lépe 2) zdroj. Fakta: Kterékoliv číslo, fakt, stav, vztah Za každým takovým údajem musí následovat odkaz na zdroj (1 důvěryhodný nebo několik jiných). Hypotézy/předpoklady (podklady) SHO: proces příchodů požadavků/doby obsluhy, struktura systému,...

21 2.1 Použité postupy Popis použitých postupů pro vytvoření modelu a zdůvodnění, proč jsou pro zadaný problém vhodné. Zdůvodnění může být podpořeno ukázáním alternativního přístupu a srovnáním s tím vaším. Zdůvodnit volbu metody. Zdůvodnit volbu jazyka/knihovny. Ideální je zdůvodnění podpořit ukázáním alternativy...

22 2.2 Původ metod Popis původu použitých metod/technologií (odkud byly získány (odkazy), zda-li jsou vytvořeny autorem) - převzaté části dokumentovat (specificky, pokud k nim přísluší nějaké autorské oprávnění/licence). Je typické, že studenti chybně vymýšlí již hotové věci a dojdou k naprostému nesmyslu. Implementace simulátorů: původní práce studenta, ovšem postupy jsou převzaté. Ostatní modely převzaté (SIMLIB, Simula,...).

23 Citování pojmů z IMS Velmi důležité, až fanaticky povinné, kontrolované a hodnocené: na každém místě v textu, kde se poprvé objeví pojem z předmětu IMS bude v závorce uveden odkaz na předmět a číslo slajdu, na kterém je pojem definován. Zamezení nevhodné tvůrčí tendenci některých studentů (implementace algoritmů a metod).

24 3. Koncepce modelu/simulátoru Konceptuální model je abstrakce reality a redukce reality na soubor relevantních faktů pro sestavení simulačního modelu. Pokud některé partie reality zanedbáváte nebo zjednodušujete, musí to být zdůvodněno a v ideálním případě musí být prokázáno, že to neovlivní validitu modelu. Výsledek kapitoly: konceptuální (abstraktní) model s vyznačením relevantních faktů.

25 3.X Zdokumentované a zdůvodněné partie konceptuálního modelu. Jednotky fyzikálních veličin. Komentované grafy/diagramy/schemata. V naléhavých případech lze tyto partie čitelně napsat rukou a vložit jako obrázek.

26 AM Petriho síť Typické vyjádření AM pro SHO Neberme AM v Petriho síti jako detailní program. AM má ukázat zásadní fakta o systému. Části, které v PS nelze vyjádřit, vyjádřete slovním popisem. Konkrétní fronta se volí podle... Vygeneruje se normal(x,y) značek... AM musí být stručný, přehledný a srozumitelný Může být čitelně psán rukou + scan

27 Koncepce u implementačních zadání Odlišujte koncepci a implementaci Popis koncepce/implementace nemá být beletrií! Koncepce programu: Abstraktní pojetí algoritmů a datových struktur Srozumitelné pro neinformatika Formální pojetí Vývojové diagramy, pseudokód, schémata Do implementační kapitoly jdou pouze technické detaily.

28 Koncepce u P. sítě jak se projeví definice P. sítě v algoritmickém pojetí 4. číslic. obvody koncepce algoritmu simulátoru 5. výroba koncepce plánu a jeho nasazení na linky 6. CA koncepce prostoru, času a její vliv na model 7. MontC přizpůsobení obecné koncepce metody pro danou úlohu

29 8. Simula koncepce jazyka a knihoven 9. stoch postup statistického zpracování dat 10. SHO P. síť, rozbor vlastního chování obou (více) procesů 11. SHO s řízením smysl řízení v modelu 12. logistika - koncepce strategií řízení

30 4. Architektura simulačního modelu Nejméně zajímavá/důležitá kapitola. Technický popis programu. Různá důležitost u různých témat. Implementační témata rozbor detailů implementace. Simula 67 vysvětlení kódu programu. 4.1: Minimálně je nutno ukázat mapování abstraktního (koncept.) modelu do simulačního (resp. simulátoru). Např. které třídy odpovídají kterým procesům/veličinám a podobně SHO, spojité modely

31 5. Dokumentace experimentování Nezaměňujte pojmy testování a experimentování (důvod pro bodovou ztrátu)!!! Zopakovat/shrnout co přesně chcete zjistit experimentováním a proč k tomu potřebujete model. Pokud experimentování nemá cíl, je celý projekt špatně. Je běžné, že při experimentování najdete v modelu/konceptu chybu (dokumentovat). Experimentálně ověříte (ne)platnost vstupních předpokladů.

32 5.X kapitola 5.1: Naznačit postup experimentování jakým způsobem hodláte prostřednictvím experimentů dojít ke svému cíli (experimentování musí mít metodiku). kapitola 5.2: Dokumentace jednotlivých experimentů kapitola 5.3: Závěry experimentů bylo provedeno N experimentů v těchto situacích...

33 5.2 Dokumentace jednoho experimentu Protokolární forma. 1) Cíl experimentu: ověřit, zjistit, 2) Vstupní okolnosti experimentu 3) Průběh experimentu (pokud je něčím zajímavý). 4) Výsledek experimentu: Komentované statistiky, resp. výtah ze statistik. Interpretace výsledků + zajímavé části výsledků. Vysvětlení výsledků experimentu: výsledkům musíte rozumět, případě pátrat po důvodech v modelu. Zhodnocení experimentu, případně návrh dalšího.

34 5.3 Závěry experimentů Co bylo experimentováním zjištěno. Jaké chyby v modelu byly odstraněny (oproti původním předpokladům došlo ke změně koncepce protože...). Co lze zjistit dalšími experimenty.

35 6. Shrnutí experimentů, závěr Závěrem dokumentace se rozumí zhodnocení simulační studie a zhodnocení experimentů. např. Z výsledků experimentů vyplývá, že... při předpokladu, že... Validita modelu byla ověřena... V rámci projektu vznikl nástroj..., který vychází z... a byl implementován v Pokud byla na počátku studie nějaká prvotní otázka, pak tady musí být zodpovězena nebo zdůvodněn případný neúspěch.

36 Co nemá být v závěru: Poznámky osobního charakteru (např. práce na projektu mě bavila/nebavila,...). Technická zpráva není osobní příběh autora. Kolik úsilí jste projektu věnovali Do závěru se velmi nehodí psát "autozhodnocení" kvality práce, to je výhradně na recenzentovi/hodnotiteli (např. v projektu jsem zcela splnil zadání a domnívám se, že můj model je bezchybný a výsledky taktéž). Předat podklady pro zhodnocení práce (zdůvodnění validity a výsledky) a zhodnocení nechat na odběrateli výsledků.

37 Grafy (a tabulky) Graf má název a popis os včetně jednotek. V textu musí být graf odkazován s vysvětlením, co na grafu má čtenář vidět. Pokud to tam není vidět, graf je špatně. Graf/obrázek není solitér v textu. Ujistětete se, že kdokoliv ve vašich grafech uvidí to, co tam má být vidět. V extrémních případech zvýraznit detail (barva, šipka,...).

38 Obecné poznámky Znát svůj text studie jsou oponovány/prezentovány Korektní technické vyjadřování Žádný slang/žargón, slova v uvozovkách, neformální obraty. Žádné vtipné poznámky. Fakta, analýzy, rozhodnutí, výsledky a jejich interpretace. Rozsah technické zprávy: Stránky se nepočítají. Minimalizujte rozsah s ohledem na kvalitní podání faktů.

39 Rozbor témat/okruhů Základ: V následujícím textu budou především dodatky. Reálné zadání nikdy nebude precizní: Znalosti, zkušenosti, schopnost učinit rozhodnutí. Příklad: Implementujte diskrétní simulátor na bázi událostního modelování a demonstrujte jeho činnost. Student však musí činit rozhodnutí.

40 1. Knihovna pro kombinovanou simulaci Události, kalendář. Nejsou procesy proces je rozložen do obsluh událostí, kde každá plánuje tu následující. Transakce. Jednoduchá spojitá část. Základem je alg. kombinované simulace (včetně dokročení). Zadávání modelu inspirace SIMLIB Demopříklady. pohyb míčku v krabici (odrazy, gravitace) kombinovaný model, 3 diskrétní stavy (např. topení)

41 2. Knihovna pro vnořenou simulaci Základ jako téma 1. Transakce. Důraz na instancovatelnost modelu/simulátoru. Vnořená simulace v určitém okamžiku je možno instancovat nový simulátor, vypočítat jeho průběh a převzít výsledek. Reflektivní simulace. Využití v řízení procesů např. zjišťování kapacit ve složitějších systémech. model řídicího prvku se schopností analyzovat budoucí stavy

42 3. Simulátor P/T Petriho sítí Sémantika Petriho sítí (přechodu) stav sítě výpočet proveditelných přechodů Kalendář událostí. Kontrola korektnosti zadání. Vstup libovolně. Výstup ve formě časové posloupnosti stavů sítě. Bonus: detekce rychlých smyček (v síti, kde jsou časované přechody)

43 4. Simulátor číslicových obvodů Hradla zpoždění. Netlist propojení hradel. Vstupy signály. Kalendář/SIMLIB. Výstupy simulátoru signály, textový výstup, zobrazení např. GNUplot. Rychlé smyčky netřeba řešit. Události a jejich šíření sítí. Příklady: kombinační, sekvenční obvody. Ideální příklad: HW implementace KA.

44 5. Simulátor výrobního systému Články o RCSP. Operace, obnovitelné/neobnovitelné zdroje. Vstupem simulátoru: Zadání úlohy (operace, zdroje, materiál). Startovní časy operací nebo Relativní pořadí operací (proveditelný plán). Kompatibilita s PSPLIB (single-mod). Výstup: statistiky o oper/zdrojích/mat. Ověření proveditelnosti plánu.

45 6. Aplikace CA v biologii Najděte článek o modelu pomocí CA (netriviální, je o něm nějaká publikovaná studie). seriózní zdroj (konferenční publikace, časopis). Zopakujte studii vlastními prostředky. Implementujte CA a model. Zopakujte experimenty, navrhněte další. Originalita není to jenom o šíření chorob.

46 7. Model založený na Monte- Carlo metodě Problém z Physical sciences, Engineering nebo Computational Biology. Článek. Zopakovat model a experiment. Ukažte použití Mont-Carl. Srovnání s jinými přístupy.

47 8. Model v jazyce Simula 67 Implementace cim na merlinovi. Prostudujte jazyk Simula 67. Implementujte jeden z příkladů prezentovaných na democvičeních IMS. V dokumentaci důkladně popište význam jednotlivých řádků/bloků kódu. Simulační studie není nutná (pouze ověření funkčnosti modelu). Příklady berte z democvičení IMS. Bonusově použití DEMOS.

48 9. Model stochastického procesu Tři reálné stochastické procesy. příchody do systému, doby obsluhy. jev v technice (v PC, v síti,...). Změřit stat. významný vzorek soubor dat. Aproximace vhodným rozložením (exaktní postup) jádro práce! Ověření grafickým srovnáním. Ověření pomocí generátorů v SIMLIB vygenerování souborů, srovnání. Bonus: provedení chi-kvadrat testu.

49 10. Model zvoleného SHO Vlastní volba problematiky. Dva různé kooperující procesy (čtenáři/písaři), nutná synchronizace. Simulační studie dle zadané struktury. Studie musí mít nějaký cíl a sdělení.

50 11. Model SHO s prvky plánování a řízení Základ je SHO. Proměnlivé vnitřní parametry/kapacity. Dynamika např. hodinová diskretizace. Vžijte se role šéfa brněnského Tesca. obslužné linky (pokladny, vozítka, ) zaměstnanci různé schopnosti proces příchodu zákazníků, dodávek zboží Experimentálně vytvořte chodné strategie řízení pro různé situace

51 12. Model fiktivní logistické firmy Centrála, N I/O poboček, M vozidel. Pobočky=větší města v ČR (15-20). Realistický proces příchodů požadavků (módy: běžný, konec roku,...). Model prostředky SHO. Prostorový charakter. Navrhněte strategie řízení firmy. Simulačně prověřte. Bonus: vazba na reálnou firmu.

52 Hodnocení Odevzdání po termínu nepřípustné. Zásadní vada v modelu 0 bodů. Chybí (nebo je pouze triviální) nějaká část projektu 0 bodů. Rozložení bodů (10+10): 10 bodů programátorská část 10 bodů experimentální/dokumentační část. Důraz: Zdůvodnění validity modelu. Experimentování a jeho závěr. Programátorsky styl pouze v extrémních případech.

53 Chvilka pro reklamu Modelování a simulace jsou základy informatiky. Pokročilejší témata v magisterském studiu: Obory Inteligentní systémy a Matematické metody v IT Další moje předměty: Teorie her (THE) modely rozhodování Geografické informační systémy (GIS) prostorové modely Simulační nástroje a techniky (přednáší dr. Peringer, SNT) IMS pro pokročilé