Constructing Behavioral State Machine using Interface Protocol Specification

Transcription

1 Constructing Behavioral State Machine using Interface Protocol Specification Osamu Shigo School of Information Environment Tokyo Denki University Inzai-city, Chiba, Japan Atsushi Okawa Daiki Kato Abstract A behavior of an embedded system is designed by a state machine, which receives input events from externals through the interface, and sends output actions to externals through the interface. Thus the interface specification becomes major concerns in the system design. This paper describes a design method that defines the interface of a component by protocol state machines, and then systematically constructs a behavioral state machine of the component using the interface protocol state machines. The design support system developed to realize the method, which provides enough guidance for designing behavior state machine by using protocol specification, is also described. 1. Introduction Recently many embedded software systems have been developed to realize the effective ubiquitous systems. This forces that many engineers needs to design the embedded software without much knowledge about software engineering. To support those, many commercial software design support systems are available now[1][2], most of which are based on Unified Modeling Languages UML [3]. The UML consists of many standard diagrams to draw various aspects of software, from requirement and design analysis to coding and testing. Each diagram maybe understandable, however the meaning of different diagrams relation is not clear. Also, suitable selection of the set of diagrams from the UML for each engineer s purpose is not easy. The current version of the UML 2.0 contains many aspects for real-time embedded software design, including component diagram, port, protocol and behavioral state machines, similar to the ROOM [4] [5]. Still the relation among those concepts seems not to be clearly defined. For example, the relation between protocol state machine and behavioral state machine is not clear. By defining the behavioral state machine, the design becomes executable and may proceeds to automatic code generation, but no such support for the protocol state machine is provided. Thus, in many cases, protocol state machine is defined only for documentation purpose. The protocol state machine is used for defining the valid usage rules of the input and output messages, or provided and required methods, of the port. Here, the port is not a physical one but a logical window through which a meaningful set of input and output messages are received and sent. For valid connection of two ports, protocols of the ports should be compatible, that is, when port A send a message to port B, B should receive the message properly and timely. We extend the compatibility concept to the port and the component behavior relation, that is, when a port may receive a message, the component should receive the message properly and timely, and the component can only send the message which is permitted to send by the port protocol. A component behavioral state machine compatible to its port protocols can be constructed systematically or semiautomatically by using the protocol state machines. We proposed the basic model and the design method using the compatibility between the component behavioral state machine and a set of protocol state machines for the ports, and developed the design support system based on the model. In the followings, the basic model and the compatibility concept are described in section 2 and 3. The design support system using the concept is described in section 4, and related works are described in section 5. Finally in section 6, we discuss further problems with concluding remarks. 2. Basic model The basic model here is a simplified ROOM with protocol state machine. A system in the model is expressed in component hierarchy as a static system structure. Components are communicated with each other by message passing through ports. Protocol state machine is defined for each port. A component has a behavioral state machine to define dynamic behavior of the component.

2 2.1. System structure The system structure in the model is expressed by a component hierarchy, which is similar to the ROOM actor hierarchy [4] [5]. A whole system is represented as component class. A component class may have ports as communication windows to outside through which incoming messages are received and outgoing messages are sent. Port is conceptually located at component boundary. A component class may have one or more component instances as subcomponents to realize component hierarchy. A component instance is an instance of component class. Component instance has ports at the boundary as defined by its class. Ports of component instances in a component class may be connected to each other, or to ports of the component class. Each connector has exactly two ports as its two sides, and no port has more than one connector Protocol Each port has a protocol as its type. A protocol specifies a set of input and output message types and valid message exchange sequences which may appear through the port. Message type is defined as a message name. 1 A set of valid message sequences is defined by protocol state machine, a kind of finite state automaton. Formally, protocol state machine, or simply protocol P is a four-tuple, P = (S p, s p0, M p, δ p ), where S p : a set of finite states s p0 S p : initial state M p : a set of messages δ p S p IO M p S p : a set of transition rules, where IO = {?,!} IO defines message flow types by? as input and by! as output. That is, (s,?, m i, s ) δ p means when the state is s, the message m i may be received which make the state change to s, and (s,!, m o, s ) δ p means when the state is s, the message m o may be sent which make the state change to s. Protocol P should be deterministic, or if (s, d, m, s 1 ) δ p and (s, d, m, s 2 ) δ p then s 1 = s 2. This permits to decide the protocol state by the sequence of message flows, or a component can determine the port state from the sequence of messages received from or sent to the port. Let δ p be a transitive closure of δ p, such that, δ p S p (IO M p ) S p, where (s, ɛ, s) δ p 1 To extend the model for more detail design purpose, data elements may be added to the message type as message parameters. if (s, d, m, s ) δ p and (s, act, s ) δ p, then (s, (d, m).act, s ) δ p For s S p, let I p (s) be a set of input messages enabled at the state s, or I p (s) = {m M p s S p : (s,?, m, s ) δ p }, and O p (s) be a set of output messages enabled at the state s, or O p (s) = {m M p s S p : (s,!, m, s ) δ p }. If a component C has a port p of the protocol P defined above and p is in state s, then C should wait to receive all messages in I p (s) from port p, and C may send messages in O p (s) to port p. Note that, protocol does not specify the behavior of port, but specifies the valid usage rules of port for the component as the Interface Automata [6]. Also note that the protocol state machine here is not the same as the one defined in UML 2.0 [3], but the same as the one defined in ROOM [4] [5]. In UML 2.0, protocol state machine defines only for input messages and may specify pre and post conditions for each transition. Here protocol state machine defines for both input and output messages and no conditions are specified to the transition. Protocol may be seen as an abstraction of all components or equipments which may be connected to the port. Each component function can be understood independently from other components by its port protocols Component behavior Behavior of component class with subcomponents may be obtained as concurrent processes of subcomponent behaviors. Here, we don t discuss the problems of subcomponents combination, which are beyond the scope of the paper. Behavior of leaf component class with no subcomponents is defined by behavioral state machine. Let s define a leaf component class in formal way. A leaf component class C is defined as C = (P, T, B) where P is a set of ports of the component, T is a function to assign a protocol to each port in P, that is for p P, T (p) is a protocol of p, and B is a behavioral state machine of the component. Behavioral state machine, or simply behavior B is defined as a four-tuple B = (S b, s b0, M b, δ b ) where, S b : a set of finite states s b0 S b : initial state M b P IO M ps : a set of messages from ports where M ps = p P M T (p), the messages of all ports δ b S b I b {ɛ} O b S b : a set of transitions, where I b = {(p, d, m) M b d =?}, input messages O b = {(p, d, m) M b d =!}, output messages

3 We write p?m for (p,?, m), an input message m from the port p, and p!m for (p,!, m), an output message m to the port p. For s S b, let I b (s) = {p?m I b act Ob, s S b : (s, p?m, act, s ) δ b }, a set of input messages waiting at the state s. For a message sequence m bs Mb and a port p, let m bs /p be a subsequence of p messages in m bs. That is, if m bs = (p 1.d 1.m 1 ).(p 2.d 2.m 2 )...(p n.d n.m n ), then m bs /p = (d i1.m i1 ).(d i2.m i2 )...(d ik.m ik ), where p ij = p(1 j k) and the list of p ij.d ij.m ij (1 j k) appear in m bs in the same order. As in protocol state machine, behavioral state machine should be deterministic, or if (s, i, m 1, s 1 ) δ b and (s, i, m 2, s 2 ) δ b then m 1 = m 2 and s 1 = s 2. 2 The ɛ moved transition is only enable for the initial state, that is, if (s, ɛ, act, s ) δ b, s should be s b0, and if the ɛ moved transition is defined, no other transitions from the initial state may be defined. This guarantee that, in any states except initial state with ɛ moved transition, the component should wait input messages from ports, which only make a trigger of the state transition. In other words, all states except initial state are stable, because no autonomous activity is permitted for the state. Note that timeout event is treated as input message of explicit port with protocol timer. As noted above, behavioral state machine is for describing the component dynamic behavior, similar to UML Statechart, while protocol state machine is for defining the valid sequence of messages sent and received through the port, as in ROOM [4]. The behavioral state machine specifies actions, a list of output messages, as in UML Statechart, while the protocol state machine has no actions. Figure 3 shows examples of protocol state machines, and an example of behavioral state machine is shown in Fig. 7 in the next section. 3. Compatibility rules Two ports can be connected when protocols of them are mutually compatible [4]. Also, component behavior should be compatible to all of its port protocols. The compatibility check among port protocols guarantees the valid connection of components without knowing there behaviors. The compatibility check between port protocols and component behavior guarantees that the component behavior design is valid to follow its interface specifications Compatibility among protocols Simple protocol compatibility is defined in the ROOM [4] where protocol specifies only input and output messages, without state machine definition. If P 1 is a protocol 2 To add a guard condition in the transition like UML statechart, we can define two different transitions with the same state and the input message. with a set of input messages I 1 and a set of output messages O 1, and P 2 is a protocol with a set of input messages I 2 and a set of output messages O 2, then P 1 and P 2 are said to be compatible if O 1 I 2 and O 2 I 1. When protocol has the state machine, the similar concept of compatibility is defined for each corresponding state. Let P 1 be a protocol with a protocol state machine P 1 = (S 1, s 10, M 1, δ 1 ), and P 2 be a protocol with a protocol state machine P 2 = (S 2, s 20, M 2, δ 2 ). We define the pair state set of P 1 and P 2, P S S 1 S 2, as follows; 1. (s 10, s 20 ) P S 2. if (s 1, s 2 ) P S and (s 1, d, m, s 1) δ 1 and (s 2, d, m, s 2) δ 2, where? =! and! =?, then (s 1, s 2) P S 3. only 1 and 2 generate the elements of P S Here (s 1, s 2 ) is a pair state if, after valid message exchanges between P 1 and P 2, P 1 state becomes s 1 and P 2 state becomes s 2 simultaneously. The two protocols P 1 and P 2 are said to be compatible, if for each (s 1, s 2 ) P S, O 1 (s 1 ) I 2 (s 1 ) and O 2 (s 2 ) I 1 (s 1 ) where I 1 (s 1 ) is a set of input messages of P 1 when its state is s 1, and O 1 (s 1 ) is a set of output messages of P 1 when its state is s 1. This means that, for each pair of states s 1 in P 1 and s 2 in P 2, the output messages of P 1 should be received by P 2 as input messages, and output messages of P 2 should be received by P 1 as input messages. This definition is similar to the compatibility defined in the Interface Automata [6] Compatibility between component behavior and its port protocols We now define the compatibility between component behavior and its port protocols. At each state, the component behavioral state machine should receive all input messages of its ports, and may send output messages to the port only when the protocol of the port permits to send them. Let C = (P, T, B) be a component with a set of ports P, port protocol assignment T and behavioral state machine B = (S b, s b0, M b, δ b ). For each state s b S b, and for each port p P with a protocol T (p) = (S p, s p0, M p, δ p ), we define corresponding p s states in s b, s b (p) M p as follows; 1. s b0 (p) = {s p0 } 2. if (s b, i, act, s b ) δ b and s p s b (p) and (s p, i.act/p, s p) δ p, then s p s b (p) 3. only 1 and 2 generate s b (p)

4 The s b (p) is a possible set of port p s states when the component C is in state s b.note that, in above 2, if s p s b (p) and there are no messages of port p in i.act, or i.act/p = ɛ, then s p s b (p), because (s p, ɛ, s p ) δ p. Now we define the compatibility rules of ports and component behavioral state machines, which guarantees the validness of component behavioral state machine based on its port protocols. For component C = (P, T, B), the behavior B is said to be compatible to the port P if B satisfies following two conditions. 1. Input condition : If a port p may receive a input message m from outside at a state s p, and the component becomes state s in which the port p becomes in the state s p, then the component should wait to receive the message m from the port p at the state s, or if s p s(p) and m I p (s p ), then p?m I b (s). 2. Output rule : If component defines action act (a sequence of output messages) in the transition from state s and receiving input i, that is, (s, i, act, s ) δ b, then for each port p P, i.act/p, a sequence of port p s messages in i.act, should be accepted by the protocol state machine of port p from the state s p, which correspond to the state s of the component, or if (s, i, act, s ) δ b, then for each p, s p s(p) and s p s (p) and (s p, i.act/p, s p) δ p. The above rules guarantee that for any port p P and any reachable component state s S b, s(p) φ. If for all p P, s(p) has exactly one state, the state s is said to be rigid. If all states are rigid, the behavioral state machine is said to be rigid. From now on, we consider only a rigid behavioral state machine Constructing compatible behavioral state machine Given the protocol state machines of the ports, we can systematically construct a behavioral state machine compatible to the port protocols. Let P be a set of ports of the component and T (p) = (S p, s p0, M p, δ p ) be a protocol state machine for port p P. Followings are the steps to construct behavioral state machine B = (S b, s b0, M b, δ b ) compatible to its ports P. 1. Define a set of messages M b = {(p, d, m) p P, (d, m) is appeared in δ p } 3 If state may have hierarchical structure as UML statechart where a state can contain a state machine, no-leaf state s may have more than one port state for some port p P. Still leaf state containing no state machine may be rigid. Here, for simplicity, we decided not to introduce hierarchy in both protocol and behavioral state machines. 2. Add the initial state s b0 to S b, where s b0 (p) = s p0. 3. Add, if necessary, the initial ɛ moved transition (s b0, ɛ, act, s b ) to δ b and add s b to S b, where act and s b are obtained as explained in step For each state s b in S b, generate a set of possible input messages I b (s b ) = {p?m p P, m I p (s b (p))}, where m is an input message of p at s b (p) state. 5. For each state s b S b and input p?m I b (s b ), construct actions act as follows; (a) Let act = ɛ and create a new state s t S b, where for all q P (q p), s t (q) = s b (q) and s t (p) = s p such that (s b (p),?, m, s p) δ p. (b) Generate a set of the output message candidates ACT S = {q!m o q P and m o O q (s t (q))} (c) Select q!m o ACT S, if necessary, and add to the act, then make s t (q) = s q where (s t (q),!, m o, s q) δ q. (d) Repeat (b) and (c) until all necessary actions are included in act. (e) If there exists the state s o S b such that s o (q) = s t (q) for all q P, then add transition (s b, p?m, act, s o ) to δ b and remove s t from S b, otherwise add transition (s b, p?m, act, s t ) to δ b. 6. Repeat steps 4 and 5 until all necessary transitions are completed. In the above steps, a designer of the behavioral state machine needs only to select the output messages from the candidates set to determine the actions of each transition. All other decisions, including new state creation, input message selection for a transition, etc., may be done automatically. 4. The state machine design support system As described in 3.3, using the protocol state machines for the ports, a behavioral state machine compatible to the protocols can be obtained systematically. We have developed a design support system based on the model described above. To demonstrate the system functions, a well known simple ATM example is used in this section The ATM example and the system structure For simplicity, we use a small subset of the ATM example, similar to the example described in [8]. The major functions of ATM, including cash dispenser and deposit, are not discussed here. Instead, abnormal usages of ATM, like

5 bad password, bad account and cancel, are considered to design as in [8]. The system structure of the ATM system is drawn as the component structure diagram as shown in figure 1, where the ATM component has four ports, card to represent a card reader with the protocol Card, pswd to enter password with the protocol P swd, veri to verify the card ID and password by the Bank Center with the protocol V eri, and msg to show messages to customers with the protocol M sg. The component structure diagram can be drawn similar to the existing commercial design tools [1] [2]. Figure 2. Protocol design window.. to know that the customer insert a card. After card is inserted, the card reader may receive the cancel message from outside as input cancel, or the component may send the eject card message to the card reader as output ejectcard. If cancel is received, the component will send ejectcard to the port, then send requestt akecard to ask the customer to take card. When customer takes the card, the port state goes to the initial. Other protocols are rather simple to understand their meanings. Figure 1. The ATM component structure design Protocol state machine To define a new protocol, the input and output messages should be defined, and then the state machine is drawn using the messages. At first, the initial state with a start mark is appeared. The state symbol in the items window is selected and put into the diagram window to create the new state. The transition arrow symbol in the items window is selected when a transition is created between two states. An input and output messages list is appeared for transition definition to select the transition message. Figure 2 shows an example of protocol design window, which is similar to the existing commercial design tools. The protocol state machines for the ATM system are illustrated in figure 3. We use the similar message names of the ATM system described in [8]. For card reader protocol Card, the component send displaym ainscreen message to request card insertion, then wait to receive insertcard 4.3. Behavioral state machine After drawing system structures and protocol state machines, a behavioral state machine of the component can be designed by using the automatic guidance of the system. Existing commercial state machine design tools provide the functions to create the state, connect two states by transition arrow, and add additional information to the state and the transition, like the input, the guard condition and the actions. Our design support functions for the behavioral state machine are quite different from those of existing systems. After defining the component structure diagram and the protocol state machines for the ports, we can proceed to design a behavioral state machine of the component, which is compatible to the port protocols. 1) Initial State and the ɛ moved transition First, the initial state with a start mark is shown. To define the ɛ moved transition, click the initial state, then select the necessary actions from the action candidate list for each port appeared in the right area of the window, as

6 Figure 4. The initial ɛ moved transition. ReqCard(M sg) = Init. 2) Transition design with new end state Figure 3. Protocol state machines for the ATM. shown in Fig 5. When the initial state is clicked, the action candidates for port p become the initial output messages O p (s p0 ). In the example, {displaymainscreen} for card, {requestp assword} for pswd, {verif yaccount} for veri and { canceledm sg, badaccountm sg, badp asswdmsg, P rintreceipt } for msg are the candidates at the initial states, which can be generated from the protocols specification. We need a ɛ moved transition with the action card!displaym ainscreen to ask the customer to insert card. After selecting displaym ainscreen message in action candidates of card, no action candidates exist for card, because no output message transition is defined after displaym ainscreen message transition in the card reader protocol Card as shown in Fig 3(1). The state after the ɛ moved transition is new, we names the state ReqCard for request card, and the ɛ moved transition (s b0, ɛ, card!displaymainscreen, ReqCard) δ b is generated as shown in figure 4. In the figure, the component state is shown with the corresponding port states. The corresponding port states for the ReqCard are ReqCard(card) = ReqInsert, ReqCard(pswd) = Idle, ReqCard(veri) = Idle and Now let s proceed to define other transitions. Click a state, the transition candidates are generated automatically with the input message possibly received at the state. For example, when ReqCard state is clicked, a transition with card?insertcard input message appears as a candidate, as shown in Fig 5, because card?insertcard is the input message enabled at the ReqCard state. To complete the transition definition, select output messages from the action candidate list for each port, appeared in right part in figure 5. For example, the action candidates for card become ejectcard, while the action candidates of other ports are the same as in ReqCard state. We select a message requestp assword from the action candidates for pswd port, and complete the transition, (ReadCard, card?insertcard, pswd!requestp assword, ReqP asswd) δ b, where ReqP asswd is the new state name for request password. The corresponding port states for the ReqP asswd are ReqP asswd(card) = Inserted, ReqP asswd(pswd) = W aitp swd, ReqP asswd(veri) = Idle and ReqP asswd(msg) = Init. To generate the transitions from ReqP asswd, click ReqP asswd state to generate the transition candidates. This time two transition candidates are generated from the ReqP asswd state, pswd?enterp assword and card?cancel, by analyzing the protocol state machines. We can complete the transition for pswd?enterp assword input with the action to proceed account verification, veri!verif yaccount message, and obtain the transition (ReqP asswd, pswd?enterp assword, veri!verifyaccount, V erify) δ b, where V erify is the new state name. This can be done to select the end state of the transition candidate, then select the necessary output messages from the action candidates list. For cancel request, we need to cancel the password veri-

7 Figure 5. Generated transition candidate and action candidates. fication, show cancelled message, eject the card and ask the customer to take the card. This can be done to select the output messages pswd!cancelp W. msg!cancelledm sg. card!ejectcard. card!requestt akecard from the action candidates list in this order. Note that requestt akecard message will appear in the action candidates for card after ejectcard message of the card port is selected as an action. After the transition, a new state ReqT akecard is generated, where the corresponding port states are ReqT akecard(card) = ReqT ake, ReqT akecard(pswd) = Idle, ReqT akecard(veri) = Idle and ReqT akecard(msg) = Init. Figure 6 shows the diagram after generating the transition from ReqP assword to ReqT akecard by card?cancel input. 3) Transition design with existing end state At ReqT akecard, the transition candidate by card?takecard input message is generated, and we select card!displaym ainscreen as action. This results the end state with the same corresponding port states as the existing state ReqCard. Thus, instead of generating new state, the existing state ReqCard is used to the transition end, and the new transition (ReqT akecard, card?takecard, card!displaym ainscreen, ReqCard) δ b is obtained. After defining necessary actions for all candidate transactions by selecting the output messages from dynamically generated action candidates list, the resulting behavioral state machine is obtained as shown in Fig 7, which is valid to keep the protocol usage specification. Figure 6. Transition design example. The above result is similar to the one by Whittle and Schumann [8]. The differences of the two are as follows; Their state machine contains transitions with no input message, while only initial transition may not have input message in our state machine. However, the both state machines have the same functions and we can transform them automatically. Our resulting state machine contains additional messages, cancelp swd and cancelv erify, to notify the cancel occurrences to each port. This is not a drawback, because they may be helpful for future efficient implementation. 5. Related works One of the main ideas in this paper is to associate the corresponding port states to each state of the component state machine. This is not new, for old versioned SDL state diagram [9] has the concept of pictorial elements which shows each equipment state, including on-hook and off-hook telephone, tone sending, ringing, timer on/off, etc. However the pictorial elements in SDL had been treated not formally but just as comment documents, and the current SDL [7] exclude them. Our model presented is said to provide the formal basis to SDL pictorial elements as the port state.

8 ReqP asswd and V erify. Now we can put the transition with card?cancel input from the higher level state Operation, instead of writing the transitions from all inside states. For evaluation purpose, we have successfully applied the system into several small embedded software designs, including the washing machine, the automatic vending machine, etc, as an experimental project. To apply the system to more detailed design, more elements such as variables and general actions as in executable UML [11] should be prepared in the system. However for the analysis and basic design phase the system seems to provide enough modeling capabilities. We plan to apply the method and the system to more realistic sized software design, to understand the real effectiveness and the problems of the method and the system. References Figure 7. Resulting ATM state machine. More formally, the model is similar to the Kripke structure, where each state has propositions. In our model, the proposition corresponds to the state of each port. The model checking based on the Kripke model [10] provides the way to check the validity of the state machine after design completion, while our method provides how to construct the valid state machine during design phase. Whittle and Schumann [8] proposed the state machine generation from scenarios, where OCL (Object Constraint Language) description is used for the messages usage rule. We believe that the concept of the port and its protocol specification by the state machine as discussed in this paper is more understandable than the OCL description, especially for usual embedded software engineers. 6. Discussion and conclusion The design method and the system for constructing the behavioral state machine compatible to its interface port protocol specification have been presented. The state machine here is not hierarchical. It is straightforward to introduce the hierarchy in the protocol and behavioral state machine model. The port state provides the proper guidance to make a new higher level state including the set of original states. For example, in figure 7, we can group the states in which the card port state becomes Inserted, that is, ReqP asswd and V erify, and make a new higher state named Operation which includes [1] IBM : Rational Rose, ibm.com/software/awdtools/developer/rosexde/ [2] Microsoft : Office Visio, [3] OMG : UML 2.0 Superstructure Specification, [4] Brian Selic, et. al : Real-time Object-oriented Modeling, John Wiley and Sons, Inc [5] Brian Selic, James Rumbaugh : Using UML for Modeling Complex Real-time Systems, White paper, IBM, [6] Luca de Alfaro, Thomas A. Henzinger : Interface Automata, ACM SIGSOFT FSE01, [7] SDL Forum Society : SDL, [8] Jon Whittle, Johann Schumann : Generating Statechart Designs From Scenarios, 22nd International Conference on Software Engineering, [9] CCITT: Recommendations Z.101 to Z.104, Functional Specification and Description Language (SDL), Yellow Book, Volume VI=Fascicle VI.7, Geneve [10] Edmund M. Clarke,Jr., Orna Grumberg and Doron A. Peled : Model Checking, The MIT Press, [11] Stephen Mellor and Marc J. Balcer : Executable UML : A Foundation for Model-Driven Architecture, Addison-Wesley, 2002.