In the CMU-SEI 2005 PSP-II Designing and Verifying State Machines PowerPoint document on pages starting on page 40 they begin the analysis and design of a Login state machine. So here we go again: Good Idea Poorly Implemented. Let's start with do one thing do it well. They claim there are four states: Start, CheckId, CheckPW, and End.
State Transition-1 has four bullet points for CheckId. State Transition-2 also has four bullet points. State Transitions-3 they build a truth table with 11 rows and 13 columns. The define A, B, and C conditions:
A: (!ValidId or !ValidPw) and N < nMax and !Timeout --> CheckId then N = N + 1; remember do one thing and do it well. FAIL.
B: ValidId and ValidPw --> End then Fail = false and LogIn user; if the Id and the Pw test fails is false the the user gets to login.
C: N >= nMax or Timeout --> End then fail = true and cut off user; the user made too many attempts or the timeout clock expired and the user was "cut off".
State Transition-4 - C and be changed to C: (N >= nMax or Timeout) and (!ValidId or !ValidPw) --> End then Fail = true and cut off user;
Their correct state template is on page 49 consists of 14 rows of logic for four of their states. The Example State Template is on page 36 of their Software Design+ii.pptx with the same 14 rows.
The VSM StateMachine™ approach uses four defined Rules they are Start, Count, UserId, UserPw and two system generated states Done and Error. There are seven total Step in the VSM Matrix™. The Start, Count, UserId, and UserPw rules consist of only one step each.
The Done rule has two steps and the Error rule has one step. The Done and Error rules are generated by Dtangle™ and are not used in this example.
With the focus on do one thing well the each VSM Rule is one step equating to one state. The entire VSM StateMachine executes in exactly four states that can be seen in the VSM Matrix.
How it works: the user enters a username and password and clicks on the Logon button. The engine starts at Time=0 executing the Start rule. The Start rule simply sets the retry count to zero. Then goes to the Count Rule checking the limit. If the limit has been exceeded that application stops that is the user is "cut off". If the user is within the retry limit the next Rule is UserId where if the id is not valid the application clears both edit windows increments the retry counter and turns the engine off. The Temporal Pointer remains at the Count Rule so when the next attempt is made the retry is tested.
If the user were to enter the correct user name the UserPw rule would be checked. In order for the logic to be at this rule the UserId must be valid, therefor it does not need to be checked and the retry count must also be valid. If the UserPw is correct the user is logged on. If the UserPw is not valid then the user is "cut off" and the UserPw Rule sets the Temporal Pointer back to the Counter Rule.
This is VSM Temporal Engineering™ where a state has two conditions true or false. When everything is correct the user logs on, notice that the UserPw rule indicates that after the GoodPw procedure is executed the VSM Engine is directed to the Rule LogonError. Thats becuase this example application is used only to demonstrate the Logon application. Before the LogonError can be executed the VSM Engine is turned of by the GoodPw procedure becuase there is nothing further to do.
