Results 1 - 10
of
138
The STATEMATE Semantics of Statecharts
, 1996
"... This article describes the semantics of the language of statecharts as implenented in the STATEMATE system [Harel et al. 1990; Harel and Politi 1996]. The initial version of this semantics was developed by a team about.10 years ago. With the added experience of the users of the system it has since b ..."
Abstract
-
Cited by 501 (10 self)
- Add to MetaCart
This article describes the semantics of the language of statecharts as implenented in the STATEMATE system [Harel et al. 1990; Harel and Politi 1996]. The initial version of this semantics was developed by a team about.10 years ago. With the added experience of the users of the system it has since been extended and modified. This executable semantics has been in operation in driving the simulation, dynamic tests, and code generation tDols of STATEMATE since 1987, and a technical report describing it has been available from i-Logix, Inc. since 1989. We have now decided to revise and publish the report so as to make it more widely accessible, to alleviate some of the confusion about the "official semantics of the language, and to counter a number of incorrect comments made in the literature about the way statecharts have been implemented. For example, the survey [yon der Beek 1994] does not mention the STATEMATE implementation of statecharts or the semantics adopted for it at all, although this semantics is different from the ones surveyed therein (and was developed earlier than all of them except for Harel et al. [1987]). As another example, Leveson et al. [1995] describe a case that exhibits an unacceptable kind of behavior in a statechart, which they say is what the "semantics of statecharts" leads to (pp. 695-697). Unfortunately, they base their discussion of statechart semantics on one of the many semantics proposed by various authors (that of Pnueli and Shalev [1991]) and give the reader the impression that this is the official semantics of the language
Executable Object Modeling with Statecharts
, 1997
"... Statecharts, popular for modelling system behavior in the structural analysis paradigm, are part of a fully executable language set for modelling object-oriented systems. The languages form the core of the emerging Unified Modelling Language. ..."
Abstract
-
Cited by 338 (38 self)
- Add to MetaCart
Statecharts, popular for modelling system behavior in the structural analysis paradigm, are part of a fully executable language set for modelling object-oriented systems. The languages form the core of the emerging Unified Modelling Language.
LSCs: Breathing Life into Message Sequence Charts
, 2001
"... While message sequence charts (MSCs) are widely used in industry to document the interworking of processes or objects, they are expressively weak, being based on the modest semantic notion of a partial ordering of events as defined, e.g., in the ITU standard. A highly expressive and rigorously defin ..."
Abstract
-
Cited by 318 (58 self)
- Add to MetaCart
While message sequence charts (MSCs) are widely used in industry to document the interworking of processes or objects, they are expressively weak, being based on the modest semantic notion of a partial ordering of events as defined, e.g., in the ITU standard. A highly expressive and rigorously defined MSC language is a must for serious, semantically meaningful tool support for use-cases and scenarios. It is also a prerequisite to addressing what we regard as one of the central problems in behavioral specification of systems: relating scenario-based inter-object specification to state-machine intra-object specification. This paper proposes an extension of MSCs, which we call live sequence charts (or LSCs), since our main extension deals with specifying "liveness", i.e., things that must occur. In fact, LSCs allow the distinction between possible and necessary behavior both globally, on the level of an entire chart and locally, when specifying events, conditions and progress over time within a chart. This makes it possible to specify forbidden scenarios, for example, and enables naturally specified structuring constructs such as subcharts, branching and iteration.
Model-integrated development of embedded software
- Proceedings of the IEEE
, 2003
"... Proceedings of the IEEE January 2003 The paper describes a model-integrated approach for embedded software development that is based on domain-specific, multiple view models used in all phases of the development process. Models explicitly represent the embedded software and the environment it operat ..."
Abstract
-
Cited by 96 (19 self)
- Add to MetaCart
Proceedings of the IEEE January 2003 The paper describes a model-integrated approach for embedded software development that is based on domain-specific, multiple view models used in all phases of the development process. Models explicitly represent the embedded software and the environment it operates in, and capture the requirements and the design of the application, simultaneously. Models are descriptive, in the sense that they allow the formal analysis, verification and validation of the embedded system at design time. Models are also generative, in the sense that they carry enough information for automatically generating embedded systems using the techniques of program generators. Because of the widely varying nature of embedded systems, a single modeling language may not be suitable for all domains, thus modeling languages are often domain-specific. To decrease the cost of defining and integrating domain-specific modeling languages and corresponding analysis and synthesis tools, the model-integrated approach is applied in a metamodeling architecture, where formal models of domain-specific modeling languages – called metamodels – play a key role in customizing and connecting components of tool chains. The paper will discuss the principles and techniques of model-integrated embedded software development in detail, as well as the capabilities of the tools supporting the process. Examples in terms of real systems will be given that illustrate how the model-integrated approach addresses the physical nature, the assurance issues, and the dynamic structure of embedded software.
A Compositional Real-time Semantics of STATEMATE Designs
, 1998
"... Introduction This paper presents a reference semantics for a verification tool currently under development allowing to verify temporal properties of embedded control systems modelled using the StateMate system. The semantics reported differs from others reported in the literature [24] by faithfully ..."
Abstract
-
Cited by 50 (6 self)
- Add to MetaCart
Introduction This paper presents a reference semantics for a verification tool currently under development allowing to verify temporal properties of embedded control systems modelled using the StateMate system. The semantics reported differs from others reported in the literature [24] by faithfully modelling the semantics as supported in the StateMate simulation tool. It differs from the recent paper by Harel and Naamad [8] by providing a compositional semantics, a prerequisite for the support of compositional verification methods, and by the degree of mathematical rigour. We use a variant of synchronous transition systems introduced by Manna and Pnueli [18] as base model for our semantics. The StateMate modelling language constructs covered in this paper are Activity charts , modelling the functional decomposition of a design into subunits called activities
Smart Play-Out of Behavioral Requirements
- 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 in many s ..."
Abstract
-
Cited by 49 (34 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.
Specifying and Executing Behavioral Requirements: The Play-In/Play-Out Approach
- 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, which we call the play-en ..."
Abstract
-
Cited by 47 (18 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.
Matching and merging of statecharts specifications
- In 29th International Conference on Software Engineering (ICSE’07
, 2007
"... Model Management addresses the problem of managing an evolving collection of models, by capturing the relationships between models and providing well-defined operators to manipulate them. In this paper, we describe two such operators for manipulating hierarchical Statecharts: Match, for finding corr ..."
Abstract
-
Cited by 42 (14 self)
- Add to MetaCart
Model Management addresses the problem of managing an evolving collection of models, by capturing the relationships between models and providing well-defined operators to manipulate them. In this paper, we describe two such operators for manipulating hierarchical Statecharts: Match, for finding correspondences between models, and Merge, for combining models with respect to known correspondences between them. Our Match operator is heuristic, making use of both static and behavioural properties of the models to improve the accuracy of matching. Our Merge operator preserves the hierarchical structure of the input models, and handles differences in behaviour through parameterization. In this way, we automatically construct merges that preserve the semantics of Statecharts models. We illustrate and evaluate our work by applying our operators to AT&T telecommunication features. 1
Multiple Instances and Symbolic Variables in Executable Sequence Charts
- In Proc. 17th Ann. ACM Conf. on Object-Oriented Programming, Systems, Languages and Applications (OOPSLA’02
, 2002
"... submitted for publication. We extend live sequence charts (LSCs), a highly expressive variant of sequence diagrams, and provide the extension with an executable semantics. The extension involves support for instances that can bind to multiple objects and symbolic variables that can bind to arbitrary ..."
Abstract
-
Cited by 39 (19 self)
- Add to MetaCart
submitted for publication. We extend live sequence charts (LSCs), a highly expressive variant of sequence diagrams, and provide the extension with an executable semantics. The extension involves support for instances that can bind to multiple objects and symbolic variables that can bind to arbitrary values. The result is a powerful executable language for expressing behavioral requirements on the level of inter-object interaction. The extension is implemented in full in our play-engine tool, with which one can execute the requirements directly without the need to build or synthesize an intra-object system model. It seems that in addition to many advantages in testing and requirements engineering, for some kinds of systems this could lead to the requirements actually serving as the final implementation. 1
Tool Support for Verifying UML Activity Diagrams
- IEEE Transactions on Software Engineering
, 2004
"... We describe a tool that supports verification of workflow models specified in UML activity diagrams. The tool translates an activity diagram into an input format for a model checker according to a mathematical semantics. With the model checker, arbitrary propositional requirements can be checked a ..."
Abstract
-
Cited by 26 (2 self)
- Add to MetaCart
We describe a tool that supports verification of workflow models specified in UML activity diagrams. The tool translates an activity diagram into an input format for a model checker according to a mathematical semantics. With the model checker, arbitrary propositional requirements can be checked against the input model. If a requirement fails to hold, an error trace is returned by the model checker, which our tool presents by highlighting a corresponding path in the activity diagram. We summarize our formal semantics, discuss the techniques used to reduce an infinite state space to a finite one, and motivate the need for strong fairness constraints to obtain realistic results. We define requirement-preserving rules for state space reduction. Finally, we illustrate the whole approach with a few example verifications.

