5 Model Programs

Advanced Topics 229FSM(0, AcceptingStates(0),Transitions(t(0,ReqSetup(0,0),0), t(0,ReqSetup(0,1),0),t(0,ResSetup(0,0),0), t(0,ResSetup(0,1),0)),Vocabulary("ReqWork", "ResWork"))Figure 14.2. A parameter restriction scenario for the credits model.0ReqA(0,1)1ResA(0,1) ResA(0,0)32Figure 14.3. Composition of the model programs in Figures 14.1 and 14.2. State 2 violates the state invariantin Figure 14.1.Figure 14.2). The FSM disables all Work actions and provides concrete parameterdomains for message IDs and credits in the Setup actions. We can compose thecredits model program with the FSM. The resulting finite state machine is shown inFigure 14.3. We can see that state 2 is unsafe, because the update rule of the actionResSetup(0,0, ) from state 1 removes all pending requests and adds no credits, sothe client cannot send further requests.We need to strengthen the enabling condition of the response action so that ifthere are no pending requests and the window is empty, then the granted number ofcredits must be at least one. We do so by adding the additional enabling conditionto the credits model.[Requirement("Section ...: Client must have enough credits")]static bool ResEnabled1(int m, int c){return requests.Count > 1 || window.Count > 0 || c > 0;}Notice that if the window is empty and no credits are granted then there must beat least two requests pending when this enabling condition is checked, because theresponse action update rule will remove one of the requests.