D. Harel and R. Marelly. Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach. Technical Report MCS01-15, The Weizmann Institute of Science Rehovot, Israel, 2002.  Home/Search   Document Details and Download   Summary   Related Articles   Check

.... a rather weak role and in the second instance one has to usually synthesize an executable speci cation from the requirements which is a dicult problem even in abstract settings [16, 15, 10, 13] An alternative approach that has been advocated and which we follow here by Harel and his co workers [6, 9, 12, 11] is to develop executable speci cation mechanisms called Live Sequence Charts (LSCs) that are directly based on MSCs. The key idea here is that LSCs can be used to describe scenario based liveness and safety properties : for instance, interactions which must occur provided some pre condition ....

....set of mutually exclusive predicates. However our model di ers from LSCs in that we explicitly x the distributed control ow. As a result our operational semantics even though given in terms of conventional transition systems herecan capture concurrency whereas in the play in play out approach of [12], the play engine has to monitor against the violation of any universal chart in every step and hence is inherently sequential. We however envision the key logical aspects of LSCs to play a role in the formal veri cation of executable CTP speci cations. There is a wealth of literature available ....

D. Harel and R. Marelly. Specifying and executing behavioral requirements: The play-in/play-out apprroach. Technical report, Weizmann Institute of Science, 2001.

....the case study. Although this is still preliminary work, it seems that we managed to specify accurately interesting properties, in an easy to use and understandable manner. We believe that this work can be a first step in apply1 ing execution, verification and synthesis methods developed for LSCs [13, 12, 11, 4], on a real world case study. The paper is organized as follows. Sec. 2 provides a brief overview of the case study, of the assumptions we made while specifying it and of the scope of requirements we handled. Sec. 3 describes the LSC language used and illustrates how the case study requirements ....

....is set to some value (assignment) As one sees on Fig. 1, framed variables are those who are inside the system boundary. This approach makes the rules of updating system variables explicit, through assignments and framed variables, whereas they were more implicit and part of the framework in [13, 12]. 4 CTAS GET NEW WTHR C in CM.connected yes status(WTHR CLIENT POSTUPDATING) CTAS USE NEW WTHR CM : CommManager cycleStatus : UPDATE cycleStatus : POSTUPDATE Figure 5. Requirement 2.8.12 4. Main findings 4.1. Language Problems with specifying behavior depending on universal ....

[Article contains additional citation context not shown here]

D. Harel and R. Marelly. Specifying and Executing Behavioral Requirements: The Play-In/ Play-Out Approach. Software and System Modeling, 2003. To appear. (Preliminary version appeared as Weizmann Institute Technical Report MCS01-15).

No context found.

D. Harel and R. Marelly, "Specifying and executing behavioral requirements: The play in/play-out approach," Software and System Modeling, To Appear 2003.

....interobject, scenario based approach to reactive system specification. The language we use to formalize the data is called live sequence charts (LSCs) 5] and capturing the data and analyzing it is carried out using the play in play out methodology, supported by the Play Engine tool [6,7]. 1.1# The Biological System Our current effort is focused on a means to formalize and analyze primary data such that the consistency of inferences made from these data can be tested as part of the model. We have chosen the development of the nematode Caenorhabditis elegans as a subject since ....

....a number of issues that provide evidence for the flexibility and potential of this modeling approach. 1. 2# The Modeling Methodology We are adopting an inter object, scenario based modeling approach, using the language of live sequence charts (LSCs) 5] and the play in play out methodology [6, 7], both supported by the Play Engine modeling tool [6,7] The decision to take this approach, rather than the statechart based one, emerged from the consideration of how to best represent the C. elegans data formally, and how to best carry out the formalization process. LSCs constitute a visual ....

[Article contains additional citation context not shown here]

# Harel, D. and Marelly, R., Specifying and Executing Behavioral Requirements: The Play In/Play-Out Approach, Software and System Modeling (SoSyM), to appear (2003)

....and instead use a more recently developed inter object, scenario based approach to reactive system specification. The language we use is called live sequence charts (LSC) 5] and the modeling and analysis is carried out using the play in play out methodology, supported by the Play engine tool [6,7]. 1.1 The Biological System Our current effort is focused on a means to formalize and analyze primary data such that the consistency of inferences made from these data can be tested as part of the model. We have chosen the development of the nematode Caenorhabditis elegans as a subject since ....

....for the flexibility and potential of this modeling approach. 1. 2 The Modeling Methodology We are taking an inter object, scenario based modeling approach, using the language of live sequence charts (LSCs) 5] and the play in play out methodology, both supported by the Play Engine modeling tool [6,7]. The decision to take this approach, rather than the statechart based one, emerged from the consideration of how to best represent the C. elegans data formally, and how to best carry out the formalization process. LSCs constitute a visual formalism for specifying sequences of events and message ....

Harel, D. and Marelly, R., "Specifying and Executing Behavioral Requirements: The Play In/Play-Out Approach", Software and System Modeling (SoSyM), to appear (2003)

....exit from a (sub)chart, while using it in an if then else construct allows for a non deterministic choice between alternatives. Fig. 23 shows an example of non deterministic choice with equal probabilities for both alternatives. Non determinism and the SELECT command are described in [17, 28]. Figure 23: Non deterministic choice in LSCs 9.4 Forbidden Elements A message that appears in a chart must occur only when it is expected, otherwise, the chart is violated. We sometimes want to say that a message should not appear while a chart is active, even if it does not appear explicitly ....

....in this algorithm. Before an event is selected, the algorithm simulates the immediate impact of the event on the objects in the system, and if this event causes some hot forbidden message to become true, it is not selected to be executed. 34 Forbidden elements are described in detail in [17, 28]. 9.5 External Objects Often, a reactive system works in the presence of other elements, besides the user who interacts with it. Such elements might include other machines, computers, sensors, and even Mother Nature. The collection of all these elements is referred to as the system s ....

[Article contains additional citation context not shown here]

R. Marelly. Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach. PhD thesis, The Weizmann Institute of Science, 2002.

.... A novel approach to behavioral requirements for reactive systems is described, in which highly expressive scenario based requirements are played in directly from the system s GUI, or some abstract version thereof [2] and behavior can then be played out freely, adhering to all the requirements [3]. The approach, which is joint with Rami Marelly, is supported and illustrated by a tool we have built the play engine. As the requirements are played in, the play engine automatically generates a formal version of them, in an extended version of the language of live sequence charts (LSCs) 1] ....

D. Harel and R. Marelly, \Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach", to appear.

....true (otherwise the system aborts) Moreover, the progress of instances may be defined to be hot thus enforcing the instance to progress, or cold thus enabling the instance to remain in its location. Among many other things, LSCs can express forbidden behavior ( anti scenarios ) In previous work [12, 15] we have extended the language of LSCs with additional constructs and features, such as assignments, loops, variables and symbolic object instances. Assignments allow values of object properties or functions to be stored at one point in a chart, and referred to later. Loops provide means for ....

....and parameterized, and thus to represent classes rather than actual objects. The expressiveness of the extended language makes it possible to view LSCs as a rather powerful executable model, and not only as a transient development product to be used for verification and documentation. Indeed, in [12, 15] a play out execution mechanism is described. Using play out, the user can execute requirement specifications given in the inter object style of LSCs directly, without the need to build or synthesize a system model consisting of intra object statecharts or code. The play out mechanism is one part ....

[Article contains additional citation context not shown here]

D. Harel and R. Marelly, "Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach", Tech. Report MCS01-15, The Weizmann Institute of Science, 2001. Submitted.

....uses a variant of classical message sequence charts (MSCs) 21] called sequence diagrams, which can be viewed as a simple existential variant of LSCs. A new approach for capturing behavioral requirements (proposed briefly in [12] has been developed recently, and is described in detail in [14]. In it the user plays in the behavior using a graphical interface (GUI) of the target system or an abstract version thereof. The formal requirements in the language of LSCs are then automatically generated from the play in by a This research was supported in part by the John von Neumann Minerva ....

....some capabilities of the play engine tool are available on the web: http: www.wisdom.weizmann.ac.il #rami PlayEngine tool called the play engine, without a need to explicitly prepare the LSCs or to write complex formulas in, e.g. temporal logic. Complementary to the play in process is play out [14]. In the play out phase the user plays the GUI application as he she would have done when executing a system model (or, for that matter, the final system) but limiting him herself to end user and external environment actions only. While doing so, the play engine keeps track of the actions taken, ....

[Article contains additional citation context not shown here]

D. Harel and R. Marelly. Specifying and Executing Behavioral Requirements: The Play-In/ Play-Out Approach. Tech. Report MCS01-15, The Weizmann Institute of Science, 2001.

....the end of [2] this problem was addressed, and a higher level approach to the problem of specifying scenario based behavior, termed play in scenarios, was proposed and briefly sketched. The details of this play in methodology and the play engine tool we have built to support it are given in [10]. The same paper also describes playout, a complementary idea to play in, which, rather surprisingly, makes it possible to execute the requirements directly without having to build or synthesize an intra object model of the system. In [11] smart play out is introduced, which strengthens the ....

.... with different specific values in the messages, symbolic instances that allow for the instances themselves to be symbolic, representing classes rather than actual objects, and a rather powerful means for dealing with real time [14] The algorithmic mechanism underlying play out is described in [10,13]. 2 4 44 4. Smart Play Smart Play Smart Play Smart Play Out OutOut Out Play out is actually an iterative process, where after each step taken by the user, the play engine computes a super step, which is a sequence of events carried out by the system as response to the event input by ....

Harel, D., and R. Marelly, "Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach", Tech. Report MSC01-15, The Weizmann Institute of Science, 2001. 3

No context found.

D. Harel and R. Marelly. Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach. Technical Report MCS01-15, The Weizmann Institute of Science Rehovot, Israel, 2002.

No context found.

Harel, D., Marelly, R.: Specifying and executing behavioral requirements: The play-in/play-out approach. Software and System Modeling (SoSyM) (to appear)

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC