„Rendszermodellezés” változatai közötti eltérés

=== Félévvégi jegy ===

* Ponthatárok:

* [[Media:Tomor_remo_2020.PDF | Tömör Remo összefoglaló - 2020]]

 

* '''Előadások diái 2016''':

* A 5. héten kerül kiadásra, beadni elektronikusan kell a 12. héten. ('''Az új házi feladat portál miatt nincsen már szóbeli védés év végén, de a régebbi házikat se fogadják már el. Külön kérésre viszont lehet javítás érdekében szóbelire menni, de arra külön jelentkezni kell.''')

* Egy sakkórát utánozó programot kell elkészíteni, mindenkinek különböző tulajdonságokkal. A házi feladat kiírása, és technikai segédlet elérhető a [https://inf.mit.bme.hu/edu/courses/remo/hazifeladat tárgyhonlapon].

* Leggyakoribb hiba: olyan állapotátmenet használata, amik nem is valódiak, mert az átmenet nem egy esemény bekövetkezésekor történik meg.  

* Lehetséges, hogy amire mi gondolunk, az egy esemény, de modellezési szempontból másként kell értelmezni ezt a fogalmat. 5 ilyen elem van tiltva:

** <code>always</code>

** <code>oncycle</code>

** Olyan nyíl (állapotátmenet), amire nincs semmi írva (nincs őrfeltétel, mindig lefut).

** <code>after 0s</code> / <code>after 0ms</code> / <code>every 0s</code> stb. A modell szempontjából ezek is feltétel nélküli átmenetek.

** '''[trigger && feltétel]''' kiváltó esemény, ezeket egy [trigger]-re és egy choice-ra kell szétbontani.

* Ha a modelledben ezeket használod, az oldal nem fogja elfogadni a házidat. A hiba megoldása:

* Meg kell érteni az állapotalapú modellezés alapját. Sokan úgy próbálják felépíteni a modellt, mint egy C nyelvben írt programot, ahol egymás után hajtódnak végre a feladatok, és az állapot egy művelet végrehajtásának felel meg. Ez hibás gondolkozás, mert állapotmodellezésre van szükség, és nem folyamatmodellezésre! Eseményvezérelt felépítés kell. A kép oldalt illusztrálja a kettő közötti különbséget. A hagyományos programozási módszer használatával keletkezik egy olyan állapotátmenet, aminek nincs kiváltó eseménye. Az állapotalapú modellezésnél ilyet ne csináljunk, mert a ChangeSettings nem egy olyan állapot, ami tartósan jellemezné a modellünket, hiszem a <code>whiteMoves = true</code> művelet elvégzése után azonnal bekövetkezik egy újabb állapotváltás, így a ChangeSettings csak egy pillanatig, és nem egy valamekkora időegységig jellemezte a modellt. Ha viszont a műveleteket nem az állapot belsejébe írjuk, hanem egy hurokélre, akkor valójában nem történik állapotváltás (ugyan oda térünk vissza), a művelet mégis végrehajtódik! Többnyire igaz, hogy úgy kell megtervezni a modellt, hogy az élekre kerülnek a változók módosításai, az állapotokra pedig az, ami megjelenik a képernyőn, lásd a képet. Ez természetesen nem mindig van így, de ha eszerint próbálod meg megtervezni a modelled felépítését, kiküszöbölheted az üres élek problémáját.

* ''Ha továbbra sem műküdik a programod, és nem érted, hogy mi a gond, látogasd meg a [http://q2a.inf.mit.bme.hu/rendszermodellez%C3%A9s Házi feladat fórum] oldalát, hátha már akadt másnak is hasonló problémája.''

 

* [[Rendszermodellezés_1._ZH/Igaz_Hamis_kikérdező | 1. ZH]]

* [[Rendszermodellezés_2._ZH/Rendszermodellezés | 2. ZH]]

* Félév vége fele a tanszék meg szokott hirdetni egy Rendszermodellezés versenyt (~április 25 körül). Erre érdemes felkészülni, mert ha eléred a versenyen a 60%-ot, az megfelel egy 100%-os 2. ZH-nak, ami sokat tud segíteni, mivel a második ZH-n nagyon nehezen lehetne elérni alapból 100%-ot.  

* Érdemes tisztában lenni minden fogalommal, mert utána elég csak a józan paraszti eszet használni. Nem túl bonyolult belőle 4-est 5-öst szerezni, mert rengeteg extra pont jár és a házi sok pontot ér. A ZH-k beugróit ne vedd könnyű péznek. Legtöbben azért bukják el a tárgyat, mert a beugró nem sikerül. Az elméleti részeket jól át kell nézni, bizonytalan esetekben inkább ne írj be semmit, mert hibás válaszért pontot veszíthetsz. A házi egy-kétnapos munka, ha teljesen nulláról kezdik, de ha már foglalkozott a Yakinduval egy kicsit előtte, akkor maximum négy óra.