IMS: Seminář o řešení projektů
Martin Hrubý
Modelování a simulace (IMS)
FIT VUT
2011/12
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.
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.
Ř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í.
Termín odevzdání
●
●
●
Zatím stanoven na 19. 12. 2010
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.
Konzultace
●
●
●
●
Tento seminář by měl odpovědět maximum
otázek.
Další otázky ve fóru předmětu.
E-maily nemají garantovanou odpověď
(zejména v čase).
Osobní návštěva, nejlépe v dopoledních
hodinách.
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.
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).
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
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ů.
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.
Morální poklesky při řešení
●
●
Hodnocení 0 body pro všechny zúčastněné.
Předání kauzy přestupkové komisi FIT.
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).
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
Dokumentace
●
●
●
●
http://perchta.fit.vutbr.cz/vyuka-ims/16
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.
Obecná struktura technické
dokumentace
●
●
●
●
●
●
Úvod
Fakta
Koncepce
Způsob řešení
Testování/experimenty
Závěr
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!!!
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ů
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.
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í).
–
●
Fakta:
–
–
–
●
Alespoň jeden (lépe 2) zdroj.
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, ...
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...
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, ...).
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).
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ů.
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.
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
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.
Koncepce u ...
●
●
●
●
●
3. 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
●
●
●
●
●
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í
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
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ů.
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 ...
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.
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.
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.
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ů.
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, ...).
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ů.
Rozbor témat/okruhů
●
●
●
Základ:
http://perchta.fit.vutbr.cz/vyuka-ims/15
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í.
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í)
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
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)
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.
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.
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.
7. Model založený na MonteCarlo 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.
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.
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.
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í.
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
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.
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.
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é
Download

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