© 2008 Science Publications Synthesizing Behavioral Model of Event-Based Requirements

Problem Statement: in the software engineering field, satisfaction of user's requirements by software has been a matter of concern. Therefore, monitoring software behavior against user's high-level requirements has already received a considerable and significant attention. However, the gap between low-level software behavior and high-level requirements has put an obstacle in the way of monitoring. Approach: to overcome the obstacle, we presented a method to synthesize a behavioral model of the event-based requirements in three steps: (1) eliciting event-based requirements; (2) specifying the requirements in event-based formulae and (3) mapping the formulae into a behavioral model. Results: to show effectiveness of the method, it was applied to requirements of a safety critical system, called Railroad Crossing Control (RCC) one and a behavioral model was synthesized. The model was used to synthesize monitor of the RCC system. The monitor is responsible for surveillance of software behavior for preventing the collision between the train and some car at the junction of rail and road.Conclusions: we proposed a systematic method started from users' requirements elicitation and concluded with its behavioral specification. Focus of the method was on event-based real-time requirements which were stated by scenarios in a sequence of real-time interactions.


INTRODUCTION
A concern in some software engineering fields such as software monitoring, software development process, for example, has been reconciling behavior of system software with high-level users' requirements. For run-time software monitoring, for example, the reconciliation helps us to able to monitor the system software behavior and determine whether the software behavior is in accord with high-level users' requirements or not.
Since in real-time systems, users' requirements indicate real-time constraints posing on the system environment, the concern has been reconciling behavior of system software with the real-time constraints. A class of real-time systems is the event-based one in which the system is responsible for adequate response to the system environment events. The adequate response is a timely response to the environment on observing an environment event.
A Railroad Crossing Control (RCC) system, for example, is a real-time system that a "train arrival" is a system environment event, "moving down the gate" is a system reaction and "moving down the gate timely on observing the train-arrival event" is a user requirement.
The aim of this study was to present a method to synthesize a behavioral model from event-based users' requirements. In the first step, we considered system environment consisting of some concerns and then elicited event-based user's requirements in environment events and its related reactions. For example, in the RCC system, "train" is an environment concern and the arrival activity is an event and moving down the gate is its related reaction, which it is used to control the system environment.
Having elicited the requirements, in the second step, we presented a formal specification of the requirements in predicates having an event-variable in its premise and an action-variable in its conclusion. So, each predicate premise indicates an environment event and each predicate conclusion indicates a required action. Lastly, the requirements were mapped to a formal mode-based specification, which a mode indicates a system software operation and corresponds with a system action. The mode-based specification indicating behavior model of the system software was shown in the Petri-Nets automaton [1] .
To synthesize the behavioral model, we systematically mapped a sequence of event happening and reaction to a required mode changing of the system software. The need for the mapping, which has stipulated by [2] , has shown by Fig. 1 [3] . Fig. 1: Reconciling event-based requirements with software behavior [3] Problem Statement: In the software engineering field, satisfaction of user's requirements by software has been a matter of concern. To get this satisfaction, software behavior should be monitored against user's high-level requirements. However, the gap between low-level software behavior and high-level requirements has put an obstacle in the way of monitoring. To bridge on the gap, we reconciled high-level (user-level) requirements with low-level (operational-level) ones in three steps: we (1) elicited event-based requirements; (2) specified the elicited requirements in event-based formulae and (3) mapped the formulae to a behavioral model.

MATERIAL AND METHODS
Reconciling high-level (user-level) requirements to low-level (operational-level) ones is a matter of concern, which has already proposed by others. The common method to state high-level requirements is a narrative style of requirements i.e., scenarios specified in Message Sequence Charts (MSC) [4,5] and the common method to specify low-level requirements i.e., behavioral model is an automata-based one. For instance [6][7][8][9] , specify high-level requirements in MSC and then generate a behavioral model in Labeled Transition System (LTS). Kruger et al. [10] shows highlevel requirements in MSC and then generates a behavioral model in UML Statecharts. Lamsweerd and Willemet [11] shows user-level requirements in MSC and generates requirements specification in Linear Temporal Logic (LTL) formula and then generates a state-based (mode-based) model in Buchi automata. In a similar manner, some [12,13] show scenarios in UML Sequence Diagrams and then generate behavioral model in UML Statecharts. The derivation of the SCR tabular model from goal-oriented specification of requirements is a translation from special high-level requirements to behavioral model used by [14] .
However in this research, we consider real-time requirements via the scenarios stated in a sequence of real-time event-action variables called real-time interactions and is formally specified based on Event Calculus (EC) [15] formulae. Then a behavioral model in Petri-Nets is generated from the formula. The EC is capable of stating interrelationship between occurrences of environment events and initiating environment states. This feature assists us in the bridging gap between the event-based specification and the statebased one. While each EC formula formally shows an interrelationship between an environment event and an environment state changing, the Petri-Net shows the system state changing corresponding with the formula. In [16] , in a reverse manner, we stated the expected behavior (states) of a program in a tabular method and then extracted the program security policies in the EC formulae from the table.
The approach principles: Our approach deals with operationalization of user-level requirements by synthesizing a behavioral model of the requirements. Some efforts stated were recently made to systematize this process by deriving a behavior model from scenarios of interactions between the system environment and the system software; however, we focus on event-based real-time systems and therefore it is necessary to use a event-aware formal method to specify event-based requirements and use a mode-based formal method supporting clearly events to specify behavioral model.
To contribute to resolve the above mentioned concern, this study aims to present a method to map event-based real-time users' requirements to corresponding system software behaviors. The mapping is accomplished in three steps. In the first step, system environment events and system reactions to the events are elicited from user's and expert's vocabulary, which is consists of their concerns. On observing an event by the system, it should timely and properly takes some action to react to the event. The sequence eventreaction indicates an interaction between the system and its environment. Since an interaction is a realtime one, its specification should be time aware. The elicitation of events and their related actions from user's and expert's concerns constituting user's requirements are described in the research.
In the second step, we generate an implication rule for each interaction in form of Rule R 1.1 or Rule R 1.2 with an event in its premise and an action in its conclusion. The rules indicate a mandatory and a prohibitory reaction respectively. The first rule states if Event e i happens at time τ, the system is obliged to take Action a i at most after ∆τ. Rule R 1.2 states if Event e j happens at time τ, the system is prohibited to take Action a j . Time ∆τ is an allowable deadline for the mandatory reaction, which the system should meet it before the next event happening. Generation of the rules is described in the study. An instance of the rules for the RCC system is shown by Rule R 1.3 and Rule R 1.4 respectively.
In the third step, the event-based specification is mapped to a mode-based one indicating a transition from the current mode of the system software to a new one, which is specified by Petri-Nets automaton. A mode indicates a system software operation and corresponds with a system action. The mapping is described in this study.
Obtaining Event-Based Requirements, Step One: An event is an environment activity and an action is a system response to the activity, which we obtain them from user's and expert's vocabulary (Table 1). User's concerns are the environment concerns should be observed by the system. Table 1 shows event-based requirements in which we: (1) considered user's concerns and took an event-variable for each event of a concern entity. If a mandatory action should be taken in response to an event, we will assign an action to action variable; however, if some prohibited action to be taken, we will assign a Null value to the action variable, (2) determine a maximum allowable delay for each action taking. For the RCC system, an instance of a concern of Table 1 is as follows: the C 1 = train is a concern whose events are E 11 = Arrival (to arrive at input line), E 12 = Entrance (to enter to cross) and E 13 = Departure (to pass from output line).

Formalizing event-based requirements, step two:
The sequences of event-action requirement in Table 1 show a real-time interaction between the system and its environment; so, the requirements should be timeaware. This shows need to time-based specification of the interactions, which originally implied by the R 1.1 obligatory Rule and the R 1.2 prohibitory Rule in the research.  [17] . The axiom has shown by Formula F 1.1 in which β is a fluent and α 0 and α 1 are events. A fluent is a variable or a predicate changes its truth value during time; therefore, it is analogous with a state variable. So, if we replace the fluent by the state variable and the premise of Rules R 1.3 /R 1.4 by the righthand side of Formula F 1.2 , we will have Rules 1.5 and 1.6 by which we able to show relation between environment states and related system actions. For the RCC system, an instance of Rule R 1.5 is Rule R 1.7 (F 1.1 ): HoldsAt(β, τ) ← Happens (α 0 , τ 0 ) ∧ Ιnitiates (α 0 , β) ∧ ~ Clipped (τ 0 , β, τ) Clipped (τ 0 , β, τ) ≡

Happens
(α 1 , τ 1 ) ∧ Terminates (α 1 , β) ∧ τ 0 < τ 1 < τ (R 1.5 ): HoldsAt(s ij , τ) → TakeAct(a ij , τ+∆τ) (R 1.6 ): HoldsAt(s ij , τ) → TakeNotAct (a ij ) (R 1.7 ): Happens(arrival, τ) → TakeAct(MoveDown, τ+∆τ) Specifying mode-based requirements, step three: In this study, we aim to represent a behavioral specification of event-based requirements stated by Rules R 1.1 and R 1.2 and mapped to the rules to Rules R 1.5 and R 1.6 . For this purpose, we use an automatabased specification called Petri-Nets. To represent behavioral specification by Petri-Nets, we should map premise and conclusion parts of the rules predicates to elements of a Petri-Net. A Petri-Net consists of places, arcs and transitions which places are connected to transitions by arcs. Places constitute inputs/outputs to/from transitions. Each place may own some token(s) and associated with each transition there are an event and some condition(s). A transition is enabled when its input(s) place own some tokens. When the associated event on an enabled transition happens and its condition(s) hold, the transition will fire. On firing a transition, the token(s) of input place(s) of the transition will be removed and its output place(s) will take token(s).
Transitions of a Petri-Net can be time-aware which called timed transition Petri-Net (TTPN) [18] . In a TTPN, firing an enabled transition can be delayed or can be set by a deadline. Figure 2a shows a TTPN before firing its transition in which transition T 1 has two input places (P 1 and P 2 ), an output place (P 3 ), 2 time units delay and 3 time units deadline. Since all input places of T 1 own tokens, it is enabled and will fire not before 2 time units and not after 3 time units when event E 1 happens and conditions Cs hold. Figure 2b shows the TTPN after firing its transition in which a token has removed from the input place and the output place has taken a token.
By using Petri-Nets, we can show behavioral specification of the system and its environment concurrently. For this purpose, we first designate a Petri-Net for each environment concern in study and complete it in research for the system behavior.

Specifying the environment behavior:
Considering the premise of Rule R 1.5 , we designated a Petri-Net for each concern as follows. For each j (state of a concern), we designated a transition whose input and output places are s ij-1 and s ij respectively and its event and decline deadline are e ij and δτ ij respectively (Fig. 3).
Before firing the transition, token of the input place indicates the environment is in the s ij-1 state. After firing, the token is removed from the input place and the output place takes a token indicating the environment is in the s ij state. So, the Petri-Net implies both of the HoldsAt (s ij , τ) and the ~HoldsAt (s ij-1 ,τ) predicates.
We show the evolution of a TTPN of Fig. 3 by Reachability Graph ρ 1 in which mv 0 and ev 0 are marking and enabling vectors respectively.
Reachabilty graph ρ 1 representing Fig. 3 Each number in the marking vector indicates the number of tokens of a place and each number in enabling vector indicates deadline of firing a transition. Reachabilty graph ρ 1 states that: (1) state s ij-1 owns one token and state s ij owns no token before firing transition T ij , (2) state s ij-1 owns no token and state s ij owns one token after firing the transition and (3) transition T ij is enabled before firing and disabled after firing. Graph ρ 1 , in fact, represents behavioral specification of the system environment for a concern.
Specifying the system behavior: In this research by representing the system behavior, we complete the Petri-Net designated in the study. For this purpose, we consider the conclusion part of obligatory/prohibitory Rules R 1.5 /R 1.6 . The rules show relation between states of the system environment and the system actions. If we think of a system action as a system mode of operation including the idle mode, the TakeAct predicate will represent happening a new mode of system operation; therefore, each TakeAct predicate will represent a transition from current system mode of operation (o ij-1 ) to new one (o ij ) which has shown in Relation Re 1 . We designate two places representing current and new modes of operation with a transition between them in the Petri-Net. For the TakeNoAct predicate, however, no places are considered.
(Re 1 ): TakeAct(a ij , τ+∆τ ij ) ≡ (HoldsAt(o ij-1 , τ) ∧ HoldsAt(o ij , τ+∆τ ij ) We complete Fig. 3 as a TTPN in Fig. 4 in which o ij-1 and o ij indicate the system operation modes before and after taking the action respectively. The behavior of the TTPN is as follows: because environment transition T ij and the system transition are enabled, on happening event e ij transition T ij will fire before deadline δτ ij . . . .
Reachabilty Graph ρ 2 representing evolution of Fig. 4 Then during ∆τ ij , if system takes action a ij , tokens will remove from places s ij-1 and o ij-1 and places s ij and o ij will take the token; however, if the system takes no action, token will only be removed from Place s ij-1 and Place s ij will take the token. For the TTPN in Fig. 4, Reachability Graph ρ 1 is completed as Reachability Graph ρ 2 . Enabled vector mv 0 has 2n elements in which elements 1 to n represent state s i1 to state s in and elements n+1 to 2n represent state o i1 to sate o in . In Graph ρ 2 , evolving TTPN from (1-a) into (1-b) represents firing both of the transition (i.e., both event e ij happens and action a ij is obligated); while, evolving TTPN from (2-a) into (2-b) represents firing only the environment transition (i.e., event e ij happens, but any action is prohibited by the system). Vector ev 1 indicates that transition T ij is no longer enabled after firing.

RESULTS
We applied our method to an event-based realtime system called Railroad Crossing Control (RCC) one: (1) we dealt with specification of the RCC system user's requirements and presented behavioral specification of the requirements. The RCC system has been intended to prevent from the collision between the train and some car at the junction of rail and road. The distance between the input sensor and the crossing to cross point is given (after the train detected by the input sensor, at least it takes t time units until the train arrives at the crossing point.

Exit to
The interval time between two successive trains is detect given (there is at least t/3 time units between a train departure from the crossing point and the next train arrival at the input sensor) Pass Maximum speed of train is given (at least it will take a time unit until the train passes the crossing point) The system comprised of an input sensor to monitor an approaching train to the cross, an output sensor to monitor a train exit from the cross, a timer to monitor the passing of time, a gate to close and open the road and a control unit. The unit controls the gate by the system application. On sensing the train, the input sensor (or the output one) notifies the control unit to move down (or move up) the gate. Therefore, the system contains three monitoring and one controlling components. The system responses deadlines to the events are shown in Table 2 in which the first and the second row indicate the acceptable maximum time to close and to open the road respectively.

DISCUSSION
Obtaining event-based requirements: The system environment consists of the train and the road which the train needs to monitor; therefore, the set of concerns is [c 1 = train] and the set of the concern events is E train = [e 11 = arrival, e 12 = entrance, ane 13 = departure].
In response to the events, the system actions are: A system = [a 11 = "gate move down" for the arrival event, a 12 = "no action" for the entrance event and a 13 = "gate move up" for the passed event]. Corresponding with Table 1, Table 3 shows train events and the corresponding system actions. Present study declared, to formalize event-base requirements stated in Table 2, we should determine the environment (train) states. Event e 11 raises the approaching state, Event e 12 raises the inside state and the Event e 13 raises the passed event; so the concern states consist of: S train = [s 11 = distant (far from the rail crossing), s 12 = approaching (near the rail crossing), s 13 = inside (within the rail crossing) and s 14 = passed (departure from the crossing)] which the default value is the "distant" value.
Moreover, there is a timer to monitor the passage of time, which the system application sets it to zero when the application receives an E train event and increments it by one when it receives an Interrupt event; so the timer value always shows the elapsed time of an event (i.e., δτ). operation modes before and after taking the action respectively. The behavior of the TTPN in Fig. 6 is as follows: on happening e 11 Transition T 1 will fire before δτ 11 . Then during ∆ 11 , if system takes a 11 , tokens will remove from s 11 and up places and then s 12 and down places will take the token. For the TTPN in Fig. 6, Reachability Graph ρ 3 was completed as Reachability Graph ρ 4 . Each element of the graph has a marking vector and an enabling one.
Each marking vector consists of seven numerical values (four values for the train states and three values for the system states) in which each numerical value indicates the number of tokens of a corresponding place of Fig. 6. Each enabling vector consists of four numerical values (three values for the train events and two values for the system actions) in which each positive numerical value indicates an enabled transition/action deadline and each zero value indicates an disabled transition/action.

CONCLUSION
In this study, we proposed a method to map event and interaction based specification of real-time requirements to the behavioral one in which the former was specified based on Event Calculus Formulae and the latter was specified in Petri-Nets and its corresponding Reachability Graph.
In compare with the other related research, we considered some issues not proposed by them: • We proposed a systematic method started from users' requirements elicitation and concluded with behavioral specification of them. In our opinion, before formalizing users' requirements, they should be elicited in a proper manner. This helps requirements both to be taken comprehensively and to be ready to formalize. This is why we use a tabular method to elicit users' requirements. Using tabular method to state users' requirements is an appropriate method has already used by others [14] . • While others have used MSCs to state scenarios and considered un-timed requirements, we considered event-based real-time requirements and stated them by scenarios in a sequence of real-time interactions. The scenarios were formalized in time-aware formulae and rules which the formulae were stated based on Event-Calculus predicates. Because the calculus is capable of stating interrelationship between event happenings and states, we could bridge gap between the interaction-based specification and the behavioral one.
• The used automaton we presented to specify behavior was Petri-Net. Since the net supports both concurrency and time-aware constraints, it is capable of behavioral specifying complex and realtime requirements; while the used automata by others, such as the LTS one has not the capability to the requirements. However, since the UML Statecharts automaton supports hierarchical and nested states, the detailed and in-depth requirements can be specified more detailed than Petri-Nets.
Dealing with the goal-oriented requirements is an interesting issue used by [14] which we didn't consider them in this research. They have derived the eventbased specification of requirements from goal-oriented ones in a tabular method.