LSCs: Breathing Life into Message Sequence Charts. (2001)

by W Damm, D Harel
Venue:In Formal Methods in System Design
Add To MetaCart
Results 1 - 10 of 444

Inference of Message Sequence Charts

by Rajeev Alur, Kousha Etessami, Mihalis Yannakakis , 2002
"... Software designers draw Message Sequence Charts for early modeling of the individual behaviors they expect from the concurrent system under design. Can they be sure that precisely the behaviors they have described are realizable by some implementation of the components of the concurrent system? If s ..."
Abstract - Cited by 212 (11 self) - Add to MetaCart
Software designers draw Message Sequence Charts for early modeling of the individual behaviors they expect from the concurrent system under design. Can they be sure that precisely the behaviors they have described are realizable by some implementation of the components of the concurrent system? If so, can we automatically synthesize concurrent state machines realizing the given MSCs? If, on the other hand, other unspecified and possibly unwanted scenarios are “implied ” by their MSCs, can the software designer be automatically warned and provided the implied MSCs? In this paper we provide a framework in which all these questions are answered positively. We first describe the formal framework within which one can derive implied MSCs, and then provide polynomial-time algorithms for implication, realizability, and synthesis.

Synthesizing State-Based Object Systems from LSC Specifications

by David Harel, Hillel Kugler , 2000
"... Live sequence charts (LSCs) have been de ned recently as an extension of message sequence charts (MSCs � or their UML variant, sequence diagrams) for rich inter-object speci cation. One of the main additions is the notion of universal charts and hot, mandatory behavior, which, among other things, en ..."
Abstract - Cited by 99 (24 self) - Add to MetaCart
Live sequence charts (LSCs) have been de ned recently as an extension of message sequence charts (MSCs � or their UML variant, sequence diagrams) for rich inter-object speci cation. One of the main additions is the notion of universal charts and hot, mandatory behavior, which, among other things, enables one to specify forbidden scenarios. LSCs are thus essentially as expressive as statecharts. This paper deals with synthesis, which is the problem of deciding, given an LSC speci cation, if there exists a satisfying object system and, if so, to synthesize one automatically. The synthesis problem is crucial in the development of complex systems, since sequence diagrams serve as the manifestation of use cases | whether used formally or informally | and if synthesizable they could lead directly to implementation. Synthesis is considerably harder for LSCs than for MSCs, and we tackle it by de ning consistency, showing that an entire LSC speci cation is consistent i it is satis able by a state-based object system, and then synthesizing a satisfying system as a collection of nite state machines or statecharts. 1

Incremental Elaboration of Scenario-based Specifications and Behavior Models using Implied Scenarios

by Sebastian Uchitel, Jeff Kramer, Jeff Magee - ACM Transactions on Software Engineering and Methodology , 2004
"... Behavior modeling has proved to be successful in helping uncover design flaws of concurrent and distributed systems. Nevertheless, it has not had a widespread impact on practitioners because model construction remains a difficult task and because the benefits of behavior analysis appear at the end o ..."
Abstract - Cited by 79 (12 self) - Add to MetaCart
Behavior modeling has proved to be successful in helping uncover design flaws of concurrent and distributed systems. Nevertheless, it has not had a widespread impact on practitioners because model construction remains a difficult task and because the benefits of behavior analysis appear at the end of the model construction effort. In contrast, scenario-based specifications have a wide acceptance in industry and are well suited for developing first approximations of intended behavior; however, they are still maturing with respect to rigorous semantics and analysis tools. This article proposes a process for elaborating system behavior that exploits the potential benefits of behavior modeling and scenario-based specifications yet ameliorates their shortcomings. The concept that drives the elaboration process is that of implied scenarios. Implied scenarios identify gaps in scenario-based specifications that arise from specifying the global behavior of a system that will be implemented component-wise. They are the result of a mismatch between the behavioral and architectural aspects of scenario-based specifications. Due to the partial nature of scenariobased specifications, implied scenarios need to be validated as desired or undesired behavior. The scenario specifications are then updated accordingly with new positive or negative scenarios. By iteratively detecting and validating implied scenarios, it is possible to incrementally elaborate the

Research Directions in Requirements Engineering

by Betty H. C. Cheng, Joanne M. Atlee - In 2007 Future of Software Engineering (May 23 - 25, 2007). International Conference on Software Engineering. IEEE Computer Society , 2007
"... This paper reviews the current state of the art of require-ments engineering (RE) research and identifies RE research challenges for future systems. First, the paper overviews the highlights of RE research over the past two decades; the re-search is considered with respect to requirements technolo-g ..."
Abstract - Cited by 74 (2 self) - Add to MetaCart
This paper reviews the current state of the art of require-ments engineering (RE) research and identifies RE research challenges for future systems. First, the paper overviews the highlights of RE research over the past two decades; the re-search is considered with respect to requirements technolo-gie, including notations and methodologies, developed to address specific RE tasks, such as elicitation, modeling, and analysis. Such a review enables us to identify mature areas of research, as well as areas that warrant further investiga-tion. Next, we identify several research challenges posed by emerging systems for the future. In order to help delineate the scope of future RE research directions, we then identify several strategies for performing RE research. (The spec-trum of research strategies ranges from empirical research to paradigm shifts.) Finally, within the context of these RE research strategies, we identify “hot areas ” of research that address RE needs for emerging systems of the future. 1.
(Show Context)

Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach

by David Harel, Rami Marelly - Software and System Modeling (SoSyM , 2002
"... A powerful methodology for scenario-based specification of reactive systems is described, in which the behavior is "played in" directly from the system's GUI or some abstract version thereof, and can then be "played out". The approach is supported and illustrated by a tool, ..."
Abstract - Cited by 69 (21 self) - Add to MetaCart
A powerful methodology for scenario-based specification of reactive systems is described, in which the behavior is "played in" directly from the system's GUI or some abstract version thereof, and can then be "played out". The approach is supported and illustrated by a tool, which we call the play-engine. As the behavior is played in, the play-engine automatically generates a formal version in an extended version of the language of live sequence charts (LSCs). As they are played out, it causes the application to react according to the universal ("must") parts of the specification; the existential ("may") parts can be monitored to check their successful completion. Play-in is a user-friendly high-level way of specifying behavior and play-out is a rather surprising way of working with a fully operational system directly from its inter-object requirements. The ideas appear to be relevant to many stages of system development, including requirements engineering, specification, testing, analysis and implementation.
(Show Context)

Assert and negate revisited: Modal semantics for UML sequence diagrams

by David Harel, Shahar Maoz - SOFTW SYST MODEL , 2007
"... ... from necessary behavior. They thus enable the specification of rich multi-modal scenario-based properties, such as mandatory, possible and forbidden scenarios. The sequence diagrams of UML 2.0 enrich those of previous versions of UML by two new operators, assert and negate, for specifying requir ..."
Abstract - Cited by 68 (26 self) - Add to MetaCart
... from necessary behavior. They thus enable the specification of rich multi-modal scenario-based properties, such as mandatory, possible and forbidden scenarios. The sequence diagrams of UML 2.0 enrich those of previous versions of UML by two new operators, assert and negate, for specifying required and forbidden behaviors, which appear to have been inspired by LSC. The UML 2.0 semantics of sequence diagrams, however, being based on pairs of valid and invalid sets of traces, is inadequate, and prevents the new operators from being used effectively. We propose an extension of, and a different semantics for this UML language—Modal Sequence Diagrams (MSD)— based on the universal/existential modal semantics of LSC. In particular, in MSD assert and negate are really modalities, not operators. We define MSD as a UML 2.0 profile, thus paving the way to apply formal verification, synthesis, and scenario-based execution techniques from LSC to the mainstream UML standard.
(Show Context)

Smart Play-Out of Behavioral Requirements

by David Harel, Hillel Kugler, Rami Marelly, Amir Pnueli - The Weizmann Institute of Science , 2002
"... We describe a methodology for executing scenario-based requirements of reactive systems, focusing on "playing-out" the behavior using formal verification techniques for driving the execution. The methodology is implemented in full in our play-engine tool . The approach appears to be useful ..."
Abstract - Cited by 68 (43 self) - Add to MetaCart
We describe a methodology for executing scenario-based requirements of reactive systems, focusing on "playing-out" the behavior using formal verification techniques for driving the execution. The methodology is implemented in full in our play-engine tool . The approach appears to be useful in many stages in the development of reactive systems, and might also pave the way to systems that are constructed directly from their requirements, without the need for intra-object or intra-component modeling or coding.

Synthesis revisited: Generating statechart models from scenario-based requirements

by David Harel, Hillel Kugler, Amir Pnueli - IN FORMAL METHODS IN SOFTWARE AND SYSTEMS MODELING , 2005
"... Constructing a program from a specification is a long-known general and fundamental problem. Besides its theoretical interest, this question also has practical implications, since finding good synthesis algorithms could bring about a major improvement in the reliable development of complex systems. ..."
Abstract - Cited by 61 (9 self) - Add to MetaCart
Constructing a program from a specification is a long-known general and fundamental problem. Besides its theoretical interest, this question also has practical implications, since finding good synthesis algorithms could bring about a major improvement in the reliable development of complex systems. In this paper we describe a methodology for synthesizing statechart models from scenario-based requirements. The requirements are given in the language of live sequence charts (LSCs), and may be played in directly from the GUI, and the resulting statecharts are of the object-oriented variant, as adopted in the UML. We have implemented our algorithms as part of the Play-Engine tool and the generated statechart model can then be executed using existing UML case tools.

Model checking timed UML state machines and collaborations

by Stephan Merz, Christopher Rauh - 7th Intl. Symp. Formal Techniques in Real-Time and Fault Tolerant Systems (FTRTFT 2002 , 2002
"... Abstract. We describe a prototype tool, hugo/RT, that is designed to automatically verify whether the timed state machines in a UML model interact according to scenarios specified by time-annotated UML collaborations. Timed state machines are compiled into timed automata that exchange signals and op ..."
Abstract - Cited by 58 (2 self) - Add to MetaCart
Abstract. We describe a prototype tool, hugo/RT, that is designed to automatically verify whether the timed state machines in a UML model interact according to scenarios specified by time-annotated UML collaborations. Timed state machines are compiled into timed automata that exchange signals and operations via a network automaton. A collaboration with time constraints is translated into an observer timed automaton. The model checker uppaal is called upon to verify the timed automata representing the model against the observer timed automaton. 1
(Show Context)

Detecting Implied Scenarios in Message Sequence Chart Specifications

by Sebastian Uchitel, Jeff Kramer, Jeff Magee - In ACM Proceedings of the joint 8th ESEC and 9th FSE , 2001
"... Scenario-based specifications such as Message Sequence Charts (MSCs) are becoming increasingly popular as part of a requirements specification. Scenarios describe how system components, the environment and users work concurrently and interact in order to provide system level functionality. Each scen ..."
Abstract - Cited by 48 (4 self) - Add to MetaCart
Scenario-based specifications such as Message Sequence Charts (MSCs) are becoming increasingly popular as part of a requirements specification. Scenarios describe how system components, the environment and users work concurrently and interact in order to provide system level functionality. Each scenario is a partial story which, when combined with other scenarios, should conform to provide a complete system description. However, although it is possible to build a set of components such that each component behaves in accordance with the set of scenarios, their composition may not provide the required system behaviour. Implied scenarios may appear as a result of unexpected component interaction.
(Show Context)