in state machine diagram ,I don't understand why the condition is ErrCounter >= limit . i think it is good to write ErrCounter == limit .
-
That's called **robustness**. Go with Ister's answer. – qwerty_so Apr 30 '19 at 08:13
-
See https://en.wikipedia.org/wiki/Robustness – qwerty_so Apr 30 '19 at 13:04
-
Just a note: the diagram is not well written because of conflicting transitions (the conditions [incorrect] and [incorrect and Errcounter >= Limit] are not exclusive). See UML 2.5.1 standard chapter p. 317 and 318. – Slávek Rydval Apr 30 '19 at 14:23
1 Answers
ErrCounter >= limit
is stronger than ErrCounter == limit
. You have a gain with no risk.
This is to be on a safe side. The problem is there might be also something else that increments the ErrCounter
while in one of the states (or even in transition) or the ErrCounter
can be already equal to limit when starting the process (BTW this should lead to rejection anyway but never mind).
Let's make it a life example. Imagine those two scenarios (let's say limit = 3
):
The card holder has already tried trice at some other point (e.g. in a shop) failing to use the correct pin. Now
ErrCounter = 3
. The card holder decides to give it another try in the ATM. The ATM reads theErrCounter
(as part ofAuthentication
) and as theCheckPin
failed (automatically due to too many earlier tries) now theErrCounter
is incremented again (soErrCounter = 4
). With weak case you can try again and again in an infinite loop.The card is duplicated (you know, now it can be handled through any NFC phone for example). Imagine two people want to withdraw a large amount so they work simultaneously on two ATMs. The bad luck is that they find themselves in the situation where both of them make a mistaken the PIN twice. Let's say the ATM reads the current
ErrCounter
as part ofAuthentication
. So we have (in brackets resultantErrCounter
):- partner 1 enters incorrect PIN on ATM1 (
ErrCounter = 1
) - partner 2 enters incorrect PIN on ATM2 (
ErrCounter = 2
) - partner 1 enters incorrect PIN on ATM1 (
ErrCounter = 3
). Partner 1's try (with phone) is now rejected - partner 2 enters incorrect PIN on ATM2 (
ErrCounter = 4
). If there wasn't>=
it would again put an infinite loop of tries. With the stronger inequation this try is also rejected.
- partner 1 enters incorrect PIN on ATM1 (

- 5,958
- 17
- 26
-
for the first scenario , when ErrCounter set 3 , ATM eats card . So The card holder can't do another try in the ATM. – Muhammad Al-ealyawi Apr 29 '19 at 19:41
-
@MuhammadAl-ealyawi that's why I wrote "at some other point". Of course probably this "other point" should stop the card. But there might be a small shop with insufficiently educated staff who did not stop the card even though they should. – Ister Apr 30 '19 at 06:02
-