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

96. sor:

[[Fájl:Remo_modelltipusok_20160720.png|thumb|Szekvenciális programozásra hasonlító (balra), és helyes állapotalapú (jobbra) modellek]]

* <code>after 0s</code> használata. Gyorsabb, de ez csak egy kiskapu, nem segíti a tanulást.

* 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~~. Eseményvezérelt felépítésre~~ van szükség. A kép ~~oldal~~ 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 "whiteMoves = true" 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 állapotátmenetre~~, akkor valójában nem történik állapotváltás, 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 ~~alól~~ természetesen ~~lehet kivétel~~, de ha ~~e szerint~~ próbálod meg megtervezni a modelled felépítését, kiküszöbölheted az üres élek problémáját.

* 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.

== 1. ZH ==

@@ 96. sor: / 96. sor: @@
 [[Fájl:Remo_modelltipusok_20160720.png|thumb|Szekvenciális programozásra hasonlító (balra), és helyes állapotalapú (jobbra) modellek]]
 * <code>after 0s</code> használata. Gyorsabb, de ez csak egy kiskapu, nem segíti a tanulást.
-* 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. Eseményvezérelt felépítésre van szükség. A kép oldal 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 "whiteMoves = true" 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 állapotátmenetre, akkor valójában nem történik állapotváltás, 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 alól természetesen lehet kivétel, de ha e szerint próbálod meg megtervezni a modelled felépítését, kiküszöbölheted az üres élek problémáját.
+* 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.
 == 1. ZH ==