No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Let's play: scenario-based programming using lscs and the play-engine. springer-verlag
... Scenario-based modeling (SBM) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012b) is a modeling paradigm, designed to facilitate the development of reactive systems from components that are aligned with the way humans perceive and describe system behavior. The focus of SBM is on inter-object, system-wide behaviors, thus differing from the more conventional, object-centric paradigms. ...
... A scenario-based model is fully executable: when it runs, all its scenario objects are composed and run in parallel, in a synchronized fashion, resulting in cohesive system behavior. The resulting model thus complies with the requirements and constraints of each of the participating scenario objects (Harel and Marelly, 2003;Harel et al., 2012b). ...
... In practice, SBM is supported in a variety of textual and visual frameworks. Notable examples include the language of live sequence charts (LSC), where SBM concepts are applied to produce modal sequence dia-grams (Damm and Harel, 2001;Harel and Marelly, 2003); implementations in various high level languages, such as Java, C, C++, Erlang, JavaScript, and Python (see, e.g., (Harel et al., 2012b)); and various domain specific languages (Greenyer et al., 2016a) and extensions (Harel et al., 2020;Katz et al., 2019). ...
Deep reinforcement learning has proven remarkably useful in training agents from unstructured data. However, the opacity of the produced agents makes it difficult to ensure that they adhere to various requirements posed by human engineers. In this work-in-progress report, we propose a technique for enhancing the reinforcement learning training process (specifically, its reward calculation), in a way that allows human engineers to directly contribute their expert knowledge, making the agent under training more likely to comply with various relevant constraints. Moreover, our proposed approach allows formulating these constraints using advanced model engineering techniques, such as scenario-based modeling. This mix of black-box learning-based tools with classical modeling approaches could produce systems that are effective and efficient, but are also more transparent and maintainable. We evaluated our technique using a case-study from the domain of internet congestion control, obtaining promising results.
... Scenario-based modeling (SBM) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012b) is a modeling paradigm, designed to facilitate the development of reactive systems from components that are aligned with the way humans perceive and describe system behavior. The focus of SBM is on inter-object, system-wide behaviors, thus differing from the more conventional, object-centric paradigms. ...
... A scenario-based model is fully executable: when it runs, all its scenario objects are composed and run in parallel, in a synchronized fashion, resulting in cohesive system behavior. The resulting model thus complies with the requirements and constraints of each of the participating scenario objects (Harel and Marelly, 2003;Harel et al., 2012b). ...
... In practice, SBM is supported in a variety of textual and visual frameworks. Notable examples include the language of live sequence charts (LSC), where SBM concepts are applied to produce modal sequence dia-grams (Damm and Harel, 2001;Harel and Marelly, 2003); implementations in various high level languages, such as Java, C, C++, Erlang, JavaScript, and Python (see, e.g., (Harel et al., 2012b)); and various domain specific languages (Greenyer et al., 2016a) and extensions (Harel et al., 2020;Katz et al., 2019). ...
A method for programming reactive systems, called scenario-based algorithmics, can have several advantages, both in programming and in computer science education. We provide new examples, experiments, and perspectives.
... Specifically, the method introduces scenario coding techniques and design approaches for constructing reactive systems [5] incrementally from their desired and undesired behaviors. The work on behavioral programming began with scenario-based programming, a way to create executable specifications of reactive systems, introduced through the language of live sequence charts (LSC) and its Play-Engine implementation [6,7]. The initial purpose was to enable testing and refining specifications and prototypes, and the approach was later extended towards building actual systems [8]. ...
... To this end, the underlying behavioral principles have also been implemented in imperative programming languages, via, e.g., the BPJ package [8] adding a more conventional programming point of view to that of requirement specification. Following this direction there are several tools supporting the behavioral programming principles in other languages, such as Erlang [9], C [10], and with graphical tools such as the Play-Engine [7], PlayGo [11], and SBT [12]. Our approach to scenario-based specification is based on the LSC language [6,7]. ...
... Following this direction there are several tools supporting the behavioral programming principles in other languages, such as Erlang [9], C [10], and with graphical tools such as the Play-Engine [7], PlayGo [11], and SBT [12]. Our approach to scenario-based specification is based on the LSC language [6,7]. It allows GUI-based or natural language-based playing in of behavioral scenarios, and is multi-modal, allowing constraints (for example, forbidden scenarios) to be part of the program. ...
... Scenario-Based Modeling (SBM) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012b) is a notable candidate that fits this description. In SBM, systems are modeled through the specification of scenario objects: objects that represent individual behaviors of the system being modeled. ...
... In practice, users very seldom describe models by providing the transition graphs of their scenario objects. Instead, SBM has been implemented in a variety of tools, either as dedicated frameworks (e.g., the Play-Engine tool for Live Sequence Charts (LSC) (Harel and Marelly, 2003) or the ScenarioTools engine), or on top of popular programming languages, such as JavsScript (Bar-Sinai et al., 2018), Python (Yaacov, 2020), Java (Harel et al., 2010) and C++ . ...
... The general research question that this paper addresses, namely how to effectively model complex systems and then repair these models, has been studied extensively. Here, we focused on the scenariobased modeling paradigm, in which system behaviors are modeled as scenarios (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012b). There are numerous related approaches for modeling event-driven reactive systems: notable examples include Esterel (Berry and Gonthier, 1992), Lustre (Halbwachs et al., 1991), Signal (Le Guernic et al., 1991), and Petri Nets (Holloway et al., 1997). ...
Repairing legacy systems is a difficult and error-prone task: often, limited knowledge of the intricacies of these systems could make an attempted repair result in new errors. Consequently, it is desirable to repair such systems in an automated and sound way. Here, we discuss our ongoing work on the automated repair of scenario-based models: fully executable models that describe a system using scenario objects that model its individual behaviors. We show how rich, scenario-based models can be model-checked, and then repaired to prevent various safety violations. The actual repair is performed by adding new scenario objects to the model, and without altering existing ones - in a way that is well aligned with the principles of scenario-based modeling. In order to automate our repair approach, we leverage off-the-shelf SMT solvers. We describe the main principles of our approach, and discuss our plans for future work.
... In addition to natural-language descriptions in requirement documents, such scenarios are often expressed in rigorous languages. A good example is the visual language of Live Sequence Charts (LSCs) [2,8], which evolved from Message Sequence Charts (MSCs). The LSC concepts were adopted in the later formalization of UML sequence diagrams and in a variety of tools and methodologies. ...
... Detailed semantic definitions have made it possible to simulate and execute these scenario-based specifications via run-time concurrent consideration of all scenario constraints and preferences (a process termed play-out). This gave rise to the inter-object paradigm of scenario-based programming (SBP), also termed behavioral programming, originally supported by the Play-Engine [8] and later by PlayGo [7]. SBP was later extended to standard programming languages like Java, C++, JavaScript and Erlang (see, e.g., [9]), and to domain-specific textual modeling languages like ScenarioTools's SML [3]. ...
... The conceptual duality between the inter-object and intra-object approaches is illustrated in Fig. 1, originally appearing in [8]. The 'full story' of the sequence of events in each scenario is provided explicitly in the inter-object scenarios, while it is only implicit in the intra-object specification. ...
In all software development projects, engineers face the challenge of translating the requirements layer into a design layer, then into an implementation-code layer, and then validating the correctness of the result. Many methodologies, languages and tools exist for facilitating the process, including multiple back-and-forth `refinement trips' across the requirements, design and implementation layers, by focusing on formalizing the artifacts involved and on automating a variety of tasks throughout. In this paper, we introduce a novel and unique development environment, which integrates scenario-based programming (SBP) via the LSC language and the object-oriented, visual Statecharts formalism, for the development of reactive systems. LSC targets creation of models and systems directly from requirement specifications, and Statecharts is used mainly for specifying final component behavior. Our integration enables semantically-rich joint execution, with the sharing and interfacing of objects and events, and can be used for creating and then gradually enhancing testable models from early in requirements elicitation through detailed design. In some cases, it can be used for generating final system code. We describe the technical details of the integration and its semantics and discuss its significance for future development methodologies.
... In scenario-based modeling (SBM) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012), also termed scenario-based programming (SBP) and behavioral programming (BP), one can create executable models of reactive systems from modules, called scenarios, each of which focuses on a separate facet of overall system behavior, as manifested in a collection of mandatory, allowed, and forbidden behaviors. SBM is event-based, where all behaviors are abstracted as a sequence of triggered events. ...
... The collective model can then be directly executed (in a process termed play-out), which enables the construction of simulators or even of final system components. Scenario-based programming in the LSC language is implemented in the Play-Engine and the PlayGo development and execution environ-ments (Harel and Marelly, 2003;Harel et al., 2010). ...
... In addition to executability and incrementality, benefits of using SBM include the alignment of the code structure with the requirements, the intuitiveness and ease of understanding of the SBM specifications (see, e.g., (Gordon et al., 2012), amenability to compositional verification (see, e.g., (Harel et al., 2013)) and even conciseness of the specification (see, e.g., (Harel et al., 2015)). The approach was first introduced in (Damm and Harel, 2001;Harel and Marelly, 2003), with the graphical language of live sequence charts (LSC) and the Play-Engine tool. It was subsequently generalized and implemented in standard procedural languages, such as Java, C++ and JavaScript, in domain-specific languages (DSLs) such as the SML language in the SCENARIOTOOLS environment, and has recently been embedded in the Statecharts visual language (Marron et al., 2018). ...
Scenario-based modeling (SBM) is an emerging approach for creating executable models of complex reactive systems. In addition to its use in software and system development, SBM has been shown to serve well in
modeling biological processes. In this position paper, we show that SBM can be used effectively in modeling biochemical pathways at the molecular level, complementing existing biochemical modeling techniques. One
of the key benefits of these SBM models is in helping professionals and students better conceptualize and understand such complex processes.
... In scenario-based modeling (SBM) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012), also termed scenario-based programming (SBP) and behavioral programming (BP), one can create executable models of reactive systems from modules, called scenarios, each of which focuses on a separate facet of overall system behavior, as manifested in a collection of mandatory, allowed, and forbidden behaviors. SBM is event-based, where all behaviors are abstracted as a sequence of triggered events. ...
... The collective model can then be directly executed (in a process termed play-out), which enables the construction of simulators or even of final system components. Scenario-based programming in the LSC language is implemented in the Play-Engine and the PlayGo development and execution environ-ments (Harel and Marelly, 2003;Harel et al., 2010). ...
... In addition to executability and incrementality, benefits of using SBM include the alignment of the code structure with the requirements, the intuitiveness and ease of understanding of the SBM specifications (see, e.g., (Gordon et al., 2012), amenability to compositional verification (see, e.g., (Harel et al., 2013)) and even conciseness of the specification (see, e.g., (Harel et al., 2015)). The approach was first introduced in (Damm and Harel, 2001;Harel and Marelly, 2003), with the graphical language of live sequence charts (LSC) and the Play-Engine tool. It was subsequently generalized and implemented in standard procedural languages, such as Java, C++ and JavaScript, in domain-specific languages (DSLs) such as the SML language in the SCENARIOTOOLS environment, and has recently been embedded in the Statecharts visual language (Marron et al., 2018). ...
Scenario-based modeling (SBM) is an emerging approach for creating executable models of complex reactive systems. In addition to its use in software and system development, SBM has been shown to serve well in modeling biological processes. In this position paper, we show that SBM can be used effectively in modeling biochemical pathways at the molecular level, complementing existing biochemical modeling techniques. One of the key benefits of these SBM models is in helping professionals and students better conceptualize and understand such complex processes.
... This requires the definition of a formal satisfaction relation. Moreover, as experienced in the play-out approach for Live Sequence Charts (LSCs) [7], a formal semantics provides a basis for playing out the current scenario catalog, hence, generating traffic flows which in an expert can judge for unrealistic or missing real-life traffic flows. Challenge C2 requires a formal semantics to identify the gaps between the space of possible worlds described in the scenario catalog, and the concrete in-field incident or accident. ...
... With other words, we derive from the symbol('s anchor) placement that the respective object( anchor)s' x/y positioning are less, equal or greater in comparison to an other object(anchor's position). 7 If absolute distances need to be specified, this can be done by distance lines, i.e., lines that describe their distance relation cf. No. Section 5.5. ...
We present a formalism for scenario based specification via Snapshot Charts (SCs). Snapshot Charts (SCs) are a specification formalism within Traffic Sequence Charts (TSCs), where Snapshot Charts describe the continuous evolution and Live Sequence Charts (LSCs) are used to describe the communication protocols.
A snapshot can be thought of as a description of the current state. Like pages in a flip book, we can place snapshots in a sequel to tell a story about dynamic objects. Here, a single snapshot describes invariant properties of a sequel of time contiguous states that hold until the next snapshot.
We describe the syntax and semantics of Snapshot Charts (SCs).
... On the other hand, domain-expert knowledge, represented as executable specifications (ES), does offer explainability, ease of enhancement, and amenability to formal analysis. ES can be defined using classical procedural programming, structural and behavioral modeling, rule-based systems, specialized formalisms (such as Statecharts [7], scenario-based programming [8][9][10], temporal logic [11]), and more. Still, the required expertise in the problem domain is costly and hard to acquire. ...
... Subsection headings are adapted from the titles of the main cited articles. All of these efforts are based on a specific ES paradigm called behavioral programming (BP) -a modeling approach focused on allowing users to specify the system behavior in a natural and intuitive manner that is aligned with how humans perceive the system requirements [8][9][10]. A behavioral program consists of a set of scenarios (that state what to do) and anti-scenarios (that state what is not allowed to happen), which are interwoven at runtime, yielding cohesive behavior. ...
Deep learning (DL), which includes deep reinforcement learning (DRL), holds great promise for carrying out real-world tasks that human minds seem to cope with quite readily. That promise is already delivering extremely impressive results in a variety of areas. However, while DL-enabled systems achieve excellent performance, they are far from perfect. It has been demonstrated, in several domains, that DL systems can err when they encounter cases they had not hitherto encountered. Furthermore, the opacity of the produced agents makes it difficult to explain their behavior and ensure that they adhere to various requirements posed by human engineers. At the other end of the software development spectrum of methods, behavioral programming (BP) facilitates orderly system development using self-standing executable modules aligned with how humans intuitively describe desired system behavior. In this paper, we elaborate on different approaches for combining DRL with BP and, more generally, machine learning (ML) with executable specifications (ES). We begin by defining a framework for studying the various approaches, which can also be used to study new emerging approaches not covered here. We then briefly review state-of-the-art approaches to integrating ML with ES, continue with a focus on DRL, and then present the merits of integrating ML with BP. We conclude with guidelines on how this categorization can be used in decision making in system development, and outline future research challenges.
... Scenario-Based Programming. Scenario-based programming (SBP) [16,28] is a paradigm designed to facilitate the development of reactive systems, by allowing engineers to program a system in a way that is close to how it is perceived by humans -with a focus on inter-object, system-wide behaviors. In SBP, a system is composed of scenarios, each describing a single, desired or undesired behavioral aspect of the system; and these scenarios are then executed in unison as a cohesive system. ...
... Scenarios that requested or waited for the triggered event wake up, perform local actions, and then synchronize again; and the process is repeated ad infinitum. The resulting execution thus complies with the requirements and constraints of each of the individual scenarios [28,17]. For a formal definition of SBP, see the paper from Harel et al. [17]. ...
Deep reinforcement learning (DRL) has achieved groundbreaking successes in a wide variety of robotic applications. A natural consequence is the adoption of this paradigm for safety-critical tasks, where human safety and expensive hardware can be involved. In this context, it is crucial to optimize the performance of DRL-based agents while providing guarantees about their behavior. This paper presents a novel technique for incorporating domain-expert knowledge into a constrained DRL training loop. Our technique exploits the scenario-based programming paradigm, which is designed to allow specifying such knowledge in a simple and intuitive way. We validated our method on the popular robotic mapless navigation problem, in simulation, and on the actual platform. Our experiments demonstrate that using our approach to leverage expert knowledge dramatically improves the safety and the performance of the agent.
... The sequence diagram language of UML [9] generalises these linear sequences of actions to allow branches, loops and concurrency. The live sequence chart (LSC) language of [16] goes even further than UML by integrating temporal logic concepts and modalities (so called hot and cold conditions). Our approach could be extended to cover these advanced features, but they are not the subject of this initial research. ...
... The UML object constraint language (OCL) has typically been used for this. By contrast, our constraints are based on linear temporal logic (LTL) and are conceptually closer to the live sequence charts of [16]. ...
As a methodology for system design and testing, use cases are well-known and widely used. While current active machine learning (ML) algorithms can effectively automate unit testing, they do not scale up to use case testing of complex systems in an efficient way.
We present a new parallel distributed processing (PDP) architecture for a constrained active machine learning (CAML) approach to use case testing. To exploit CAML we introduce a use case modeling language with: (i) compile-time constraints on query generation, and (ii) run-time constraints using dynamic constraint checking. We evaluate this approach by applying a prototype implementation of CAML to use case testing of simulated multi-vehicle autonomous driving scenarios.
... Creation of business process models by using demonstration presented in this paper is akin to Lieberman's elements of scenario-oriented recommendation [8] and especially on Harel's play-in/play-out techniques [9]. ...
... Harel et al. [9] have developed an approach where especially profiled interaction models with formal semantics of execution, called Live Sequence Charts (LSC), can be specified by behavior demonstration of systems based on scenarios (which they call playin). After the specification of the LSC model, the system can reproduce the defined scenarios in specific cases itself (the technique which they call play-out). ...
Programming by demonstration (PBD) is a technique which allows end users to create, modify, accommodate, and expand programs by demonstrating what the program is supposed to do. Although the ideal of common-purpose programming by demonstration or by examples has been rejected as practically unrealistic, this approach has found its application and shown potentials when limited to specific narrow domains and ranges of applications. In this paper, the original method of applying the principles of programming by demonstration in the area of process mining (PM) to interactive construction of block-structured parallel business processes models is presented. A technique and tool that enable interactive process mining and incremental discovery of process models have been described in this paper. The idea is based on the following principle: using a demonstrational user interface, a user demonstrates scenarios of execution of parallel business process activities, and the system gives a generalized model process specification. A modified process mining technique with the α|| algorithm applied on weakly complete event logs is used for creating parallel business process models using demonstration.
... Plethora's underlying environment is based on Play.Go [5,6], a comprehensive tool for behavioral, scenario-based, programming, built around the language of live sequence charts (LSC) [2,3]. LSC is a powerful and expressive visual language, which can describe easily and intuitively the behavior of large and complex systems. ...
... This header is taken from the title of the book referenced in[3].2 Supported on Chrome v. 54.0.2840.71 ...
... Each LSC is a diagram that describes a specific scenario of the system: a possible one, a necessary one or a forbidden one. A set of LSCs specifies the behavior of an entire system, and such a set can be directly executed, or compiled into conventional executable code that realizes that behavior [Harel & Marelly, 2003;Harel et al., 2010]. ...
... These inherent lexical ambiguities cause the language to be highly ambiguous. Yet, combining the CNL translation with LSCs means that we are able to generate executable code (see [Harel & Marelly, 2003]) out of textual requirements in a controlled subset of English. ...
... For the messages shown (for instance, ma1, mb1, mc1, and so on), we assume that when they are received, they imply an occurrence for instance p. The marked points along the lifeline of instance p and next to the conditions are what we call locations, borrowing terminology from Live Sequence Charts (LSCs) [26]. They do not serve a purpose at the design level but make it easier to understand the formal semantics (cf. ...
... Systems are usually designed through a combination of several models, some to capture structural aspects and some to describe more complex aspects of behaviour. As argued in [26], modelling the complete behaviour of a component or subsystem is difficult and error prone. Instead, it is easier to formulate partial behaviour as scenarios in Live Sequence Charts (LSCs), UML sequence diagrams or similar. ...
Scenarios of execution are commonly used to specify partial behaviour and interactions between different objects and components in a system. To avoid overall inconsistency in specifications, various automated methods have emerged in the literature to compose scenario-based models. In recent work, we have shown how the theorem prover Isabelle/HOL can be combined with an SMT solver to detect inconsistencies between sequence diagrams and, only in their absence, generate the behavioural composition. In this paper, we exploit this combination further and present an efficient approach that generates all valid composed traces giving us an equivalent representation of the conflict-free valid composed model. In addition, we show a novel way to prove the correctness of the computed results, and compare this method with the implementation and verification done within Isabelle alone. To reduce the complexity of our technique, we consider priority constraints and a notion of dephased models, i.e., models which start execution at different times. This work has been inspired by a problem from a medical domain where different clinical guidelines for chronic conditions may be applied to the same patient at different points in time. We illustrate the approach with a realistic example from this domain.
... Modeling complex systems is a difficult and errorprone task. The emerging Scenario-Based Programming approach (SBP) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012b) aims to mitigate this difficulty. The key notion underlying SBP is modeling through the specification of scenarios, each of which represents a certain aspect of the system's behavior. ...
... The SBP approach has been implemented in dedicated frameworks such as the Play-Engine and PlayGo for the visual language of Live Sequence Charts (LSC) language (Harel and Marelly, 2003;Harel et al., 2010a) or ScenarioTools (Greenyer et al., 2017) for the Scenario Modeling Langauge (SML) textual language. ...
Scenario-Based Programming is a methodology for modeling and constructing complex reactive systems from simple, stand-alone building blocks, called scenarios. These scenarios are designed to model different traits of the system, and can be interwoven together and executed to produce cohesive system behavior. Existing execution frameworks for scenario-based programs allow scenarios to specify their view of what the system must, may, or must not do only through very strict interfaces. This limits the methodology's expressive power and often prevents users from modeling certain complex requirements. Here, we propose to extend Scenario-Based Programming's execution mechanism to allow scenarios to specify how the system should behave using rich logical constraints. We then leverage modern constraint solvers (such as SAT or SMT solvers) to resolve these constraints at every step of running the system, towards yielding the desired overall system behavior. We provide an implementation of our approach and demonstrate its applicability to various systems that could not be easily modeled in an executable manner by existing Scenario-Based approaches.
... Modeling complex systems is a difficult and errorprone task. The emerging Scenario-Based Programming approach (SBP) (Damm and Harel, 2001;Harel and Marelly, 2003;Harel et al., 2012b) aims to mitigate this difficulty. The key notion underlying SBP is modeling through the specification of scenarios, each of which represents a certain aspect of the system's behavior. ...
... The SBP approach has been implemented in dedicated frameworks such as the Play-Engine and PlayGo for the visual language of Live Sequence Charts (LSC) language (Harel and Marelly, 2003;Harel et al., 2010a) or ScenarioTools (Greenyer et al., 2017) for the Scenario Modeling Langauge (SML) textual language. Further, SBP has been implemented on top of several standard programming languages, such as Java (Harel et al., 2010b), C++ , and JavsScript , and was amalgamated with the Statecharts visual formalism SBP has been successfully used in modeling complex systems, such as web-servers , cache coherence protocols (Harel et al., 2016), robotic controllers , and as part of the Wise Computing effort aimed at turning computers into proactive members of system development teams . ...
... To that end, we propose to research integration of statecharts [3] and scenariobased programming (abbr. SBP hereafter, a.k.a behavioral programming; see introduction of SBP in Sec. 5 and in [1,6,7]). Statecharts have been shown to be an excellent modeling and coding medium from design to final code, and SBP is particularly geared to describing the inter-object scenarios common in requirements specification, testing and the like. ...
... One implementation we propose for SIB-design is that of scenario-based programming (SBP) [1,6,7], which we feel is particularly apt as a basis for it. It was first introduced with the visual language of live sequence charts (LSC), and later implemented in standard languages such as Java and C++. ...
Despite many advances in automating system and software engineering, the knowledge, skills and experience of human engineers and domain experts are, and will continue to be, critical factors in the success of complex system development projects. In a new research direction we term towards wise computing we aim to make some of these abilities available to all project-team members, at any time, by adding several radically-new capabilities to the development environment. For example, the development environment will be able to, on its own, notice and suggest a required action for, an unexpected, unspecified, emergent system property. A report on the ultimate wise-computing vision and an initial demonstration of the desired functions have been published separately. Clearly, advanced tools, such as formal verification and synthesis, machine learning and automatic reasoning, which were not previously available, are now maturing and will be essential to wise computing. Yet, a comprehensive feasibility plan was not shown until now, and despite the above arsenal of tools, a challenge is often presented: is it indeed possible to automate some critically relevant abilities of humans, like free association, applying general knowledge to a wide variety of specific cases, or "thinking outside the box" to find a solution to a problem. In this report we outline research directions for several software capabilities and design principles that we have begun to work on, and which we believe can remove key remaining obstacles to feasibility of wise computing. 1 The Wise-Computing Challenge Rich knowledge and sophisticated skills, acquired by experienced engineers over years of training and hard-earned practical lessons, are key ingredients, and even critical success factors, in complex software and system engineering projects. In a new research vision that we term towards wise computing, we aim to endow the software development environment with those engineering abilities that are particularly considered unique to humans and make them available to the project team at all times. Some of the relevant capabilities we are most interested in are:-Free association: i.e., when an event can trigger a distantly related action-Applying engineering and domain expertise: e.g., to new and varied situations-Noticing irregularities: e.g., answering "what's wrong with this picture?" With apologies to Lewis Carroll
... To help engineers with the development of reactive systems, including cyber-physical systems, we developed a scenario-based modeling approach centered around a DSL we call Scenario Modeling Language (SML) [7]. SML, which is a text-based variant of Life Sequence Charts [11], makes it easy to write formal, scenario-based specifications by writing short scenarios. Each scenario describes how components may, must, or must not behave. ...
... The play-out algorithm [11] defines how multiple concurrently active scenarios are interwoven into valid event sequences. In SML, components are divided into controllable system components (the controller in the center of the left side of Fig. 1) and uncontrollable environment components (every other component). ...
Cyber-physical systems can be found in many areas, e.g., manufacturing, health care or smart cities. They consist of many distributed components cooperating to provide increasingly complex functionality. The design and development of such a system is difficult and error-prone. To help engineers overcome these challenges we created a formal, scenario-based specification language. Short scenarios, i.e., event sequences, specify requirements and the desired behaviors by describing how components may, must, or must not behave. Scenarios provide an intuitive way for creating formal assume-guarantee (GR(1)) specifications, giving engineers easy access to simulation, for validating the specified behavior, and controller synthesis, for creating controller software which is correct by construction. In this paper we present an approach for generating Programmable Logic Controller (PLC) code from a scenario-based specification. Previous code generation efforts, including our own, created large, verbose source files causing some tools, e.g., compilers or editors, to perform slowly or even become unresponsive. Our new approach creates compact files, shifting significant amounts of code from executable instructions to data, to reduce the burden on the compiler and other tools. The generated code is efficient and introduces minimal to no latency between the occurrence of an event and the system’s reaction to it.
... The Scenario Modeling Language (SML) [16] is a DSL we developed to offer engineers an easy to use way to write formal, scenario-based specifications. It is a text-based variant of Life Sequence Charts [10,18], offering a similar feature set with a few extensions. Listings 1 shows the specification of our production system example. ...
... The play out algorithm [18,19] defines how scenarios can be interwoven into valid event sequences. Basically, the algorithm waits for the environment to choose an event, activates and progress scenarios accordingly, and then picks a reaction which is valid according to all active scenarios. ...
... This model can be complemented by a model of inter-object behavior [Harel et al., 2008] that describes how this object interacts with other objects in particular situations. In [Harel and Marelly, 2003], the inter-object behavior is modeled with scenarios that specify the interactions between objects. ...
... For convenience and succinctness of the specification, the b-programs in this paper are written using BPjs -an environment for running behavioral programs written in JavaScript [17]. While the b-programs specification may be considered programming rather than modeling, the same program can be specified using diagrammatic implementations of the BP paradigm, including live-sequence charts [24] and Blockly [10]. Moreover, b-programs can be translated to PN models and vice versa, as described in Section 7. ...
We identify and demonstrate a weakness of Petri Nets (PN) in specifying composite behavior of reactive systems. Specifically, we show how, when specifying multiple requirements in one PN model, modelers are obliged to specify mechanisms for combining these requirements. This yields, in many cases, over-specification and incorrect models. We demonstrate how some execution paths are missed, and some are generated unintentionally. To support this claim, we analyze PN models from the literature, identify the combination mechanisms, and demonstrate their effect on the correctness of the model. To address this problem, we propose to model the system behavior using behavioral programming (BP), a software development and modeling paradigm designed for seamless integration of independent requirements. Specifically, we demonstrate how the semantics of BP, which define how to interweave scenarios into a single model, allow for avoiding the over-specification. Additionally, while BP maintains the same mathematical properties as PN, it provides means for changing the model dynamically, thus increasing the agility of the specification. We compare BP and PN in quantitative and qualitative measures by analyzing the models, their generated execution paths, and the specification process. Finally, while BP is supported by tools that allow for applying formal methods and reasoning techniques to the model, it lacks the legacy of PN tools and algorithms. To address this issue, we propose semantics and a tool for translating BP models to PN and vice versa.
... For convenience and succinctness of the specification, the b-programs in this paper are written using BPjs -an environment for running behavioral programs written in JavaScript [16]. While the b-programs specification may be considered programming rather than modeling, the same program can be specified using diagrammatic implementations of the BP paradigm, including live-sequence charts [23] and Blockly [9]. Moreover, b-programs can be translated to PN models and vice versa, as described in Section 7. ...
We identify and demonstrate a weakness of Petri Nets (PN) in specifying complex behavior. Specifically, we show how, when specifying multiple requirements in one Petri net model, modelers are obliged to specify mechanisms for combining these requirements. This yields, in many cases, over-specification and incorrect models. We demonstrate how some execution paths are missed, and some are generated unintentionally. To support this claim, we analyze Petri net models from the literature, identify the combination mechanisms, and demonstrate their effect on the correctness of the model. To address this problem, we propose to model the system behavior using behavioral programming (BP), a software development and modeling paradigm designed for seamless integration of independent requirements. Specifically, we demonstrate how the semantics of BP, which define how to interweave scenarios into a single model, allow avoiding the over-specification. Additionally, while BP maintains the same mathematical properties as PN, it provides means for changing the model dynamically, thus increasing the agility of the specification. We compare BP and PN in quantitative and qualitative measures by analyzing the models, their generated execution paths, and the specification process. Finally, while BP is supported by tools that allow for applying formal methods and reasoning techniques to the model, it lacks the legacy of PN tools and algorithms. To address this issue, we propose semantics and a tool for translating BP models to PN and vice versa.
... Our vision approach can also be based on interpreters instead of compilers or compiler-compilers. Typical examples are [24,23] using MetaCASE [59,58], Come-In-And-Play-Out [45] based on algorithmics [19,44], and model-driven web engineering approaches (beside [92], for instance, Hera [48], HDM [41], MI-DAS [113], Netsilon [80], OOHDM [94], OOWS [84] RMM [50], UWE [65], WAE2 [21], Webile [89] WebML [18], WebSA [77], W2000 [8], and WSDM [110]). The interpreter approach is useful in the case of relatively simple modelling languages. ...
The history of programming languages can be separated into four or five generations. Most languages are nowadays at the level of the third or fourth generation. The fifth generation programme failed mainly due to the infrastructure that has been available at that time. We are going to revive this fifth generation programming efforts by deployment of models as a source code for compilation to programs. Currently models are used as a blueprint or as some inspiration for programmers. At present, we are able to develop an approach of modelling to program. In future, we might have models as programs. This programme will then result in true fifth generation programming.
... The work on BP began with scenario-based programming (SBP), a way to create executable specifications of reactive systems, introduced through the language of live sequence charts (LSC) and its Play-Engine implementation [12,25]. As explained in Section 3.4, while BP allows for behavioral specification only, the LSC language includes idioms for both behavioral and data specifications. ...
Context
Modern systems require programmers to develop code that dynamically adapts to different contexts, leading to the evolution of new context-oriented programming languages. These languages introduce new software-engineering challenges, such as: how to maintain the separation of concerns of the codebase? how to model the changing behaviors? how to verify the system behavior? and more.
Objective
This paper introduces Context-Oriented Behavioral Programming (COBP) — a novel paradigm for developing context-aware systems, centered on natural and incremental specification of context-dependent behaviors. As the name suggests, we combine behavioral-programming (BP) — a scenario-based modeling paradigm — with context idioms that explicitly specify when scenarios are relevant and what information they need. The core idea is to connect the behavioral model with a data model that represents the context, allowing an intuitive connection between the models via update and select queries. Combining behavioral-programming with context-oriented programming brings the best of the two worlds, solving issues that arise when using each of the approaches in separation.
Methods
We begin with providing abstract semantics for COBP and two implementations for the semantics, laying the foundations for applying reasoning algorithms to context-aware behavioral programs. Next, we exemplify the semantics with formal specifications of systems, including a variant of Conway’s Game of Life. Then, we provide two case studies of real-life context-aware systems (one in robotics and another in IoT) that were developed using this tool. Throughout the examples and case studies, we provide design patterns and a methodology for coping with the above challenges.
Results
The case studies show that the proposed approach is applicable for developing real-life systems, and presents measurable advantages over the alternatives — behavioral programming alone and context-oriented programming alone.
Conclusion
We present a paradigm allowing programmers and system engineers to capture complex context-dependent requirements and align their code with such requirements.
... The work on BP began with scenario-based programming (SBP), a way to create executable specifications of reactive systems, introduced through the language of live sequence charts (LSC) and its Play-Engine implementation [9,20]. While BP allows for behavioral specification only, the LSC language includes idioms for both behavioral and data specifications. ...
Modern systems require programmers to develop code that dynamically adapts to different contexts, leading to the evolution of new context-oriented programming languages. These languages introduce new software-engineering challenges, such as: how to maintain and keep the separation of concerns of the codebase? how to model the changing behaviors? how to verify the system behavior? and more. This paper introduces Context-Oriented Behavioral Programming(COBP) - a novel paradigm for developing context-aware systems, centered on natural and incremental specification of context-dependent behaviors. As the name suggests, we combine behavioral-programming(BP) - a scenario-based modeling paradigm - with context idioms that explicitly specify when scenarios are relevant and what information they need. The core idea is to connect the behavioral model with a data model that represents the context, allowing an intuitive connection between the models via update and select queries. Combining behavioral-programming with context-oriented programming brings the best of the two worlds, solving issues that arise when using each of the approaches in separation. We begin with providing abstract semantics for COBP, laying the foundations for applying reasoning algorithms to context-aware behavioral programs. We then exemplify the semantics with formal specifications of systems, including a variant of Conway's Game of Life. Finally, we present a JavaScript-based implementation of the paradigm and provide two case studies of real-life context-aware systems (one in robotics and another in IoT) that were developed using this tool. Throughout the examples and case studies, we provide design patterns and a methodology for coping with the above challenges.
... [307,405]). Different authors propose to include runtime capabilities for RE, e.g., modeling requirements at runtime (e.g., [29,168,259]) or reasoning through requirements reflection at runtime (e.g., [39,265,287,336]). Additionally, different authors present requirement languages tailored to SASs (e.g., [29,76,89,155,302,404,409]). ...
The increasing complexity and size of information systems result in an increasing effort for maintenance. Additionally, miniaturization of devices leads to higher mobility and the need for context-adaptation, especially in new types of systems, such as Cyber-physical Systems (CPS) or Internet-of-Things (IoT). Self-adaptive Systems (SAS) has the ability to adapt to changes in their environment or the system resources and address the aforementioned challenges. So far, however, development of these systems is frequently tailored towards the requirements of use cases. The research for frameworks and reusable elements –- for implementation as well as design processes –- is often neglected. Integrating reusable process and implementation artifacts into a framework and offering a tool suite to developers would make development of SAS faster and less error-prone. This thesis presents the FESAS framework. It offers a reusable implementation of a reference system, tools for implementation and design as well as a middleware for controlling system deployment.
Due to distribution of systems and an increase of available information, the complexity for adaptation reasoning increases. This can lead to uncertainty at runtime resulting in incompleteness or obsolescence in adaptation goals, models or rules. Therefore, the need for changing the adaptation reasoning arises. As a second contribution, this thesis introduces a new approach for self-improvement of SAS. It complements the SAS with an additional module for meta-adaptation. Unlike existing approaches, the approach is not limited to a specific type of adaptation nor to specific implementation frameworks. The thesis describes the integration of the module for self-improvement with the FESAS framework.
Following a design science approach, this thesis explains the design of the artifacts based on requirements derived from an analysis of related work. For evaluation, prototypes of the artifacts are implemented in a proof by prototyping approach and discussed regarding their usability, applicability, and performance.
... Previous demonstrations of BP include a show case of a fully functional nano-satellite [5], a development tool that allows an integration of BP models with imperative code [6], a model-checking tool for verifying the correctness of BP models [7], and implementations in a variety of languages, including Live Sequence Charts (LSC) [8], [9], JavaScript [6], Java [10], C [11] and more. Research results on BP cover, among others, run-time lookahead (smart playout) [12], methods for compositional verification [13], for synthesis [14] and for interactive analysis of unrealizable specification [15]. ...
... Lussy [10] is an intermediary between SystemC and the synchronous Lustre language. Instead of directly exporting the intern results into another formalism, the scenario concept [8] based on Live Sequence Charts rather authorizes reasoning, constructions, manipulation and verification in the formalism itself. With different kinds of scenarios, like use-case scenario, specification scenario, integration scenario, Quality of Service scenario, the scenarios are a hope to follow the development flow with successive transformations. ...
... Most of the applications of the Scenario-Based Design (SBD) method can be found in the software development, computer engineering, technology product design, and human-machine interaction domains (e.g. Carroll and Haynes, 2011;Cervantes and Kazman, 2016;Harel and Marelly, 2003;Hertzum, 2003;Kazman et al., 1998;Rosson and Carroll, 2002;Palotta, 2007), and in fewer examples of medical and healthcare products (e.g. Huis in't Veld et al., 2010;Rasoulifar et al., 2009;Thomann and Caelen, 2007;Vincent and Blandford, 2015) to simulate product performance and user-product-interface potentials. ...
Architectural design targets mainly humans, the lives of whom are dynamic and continuously changing. Consequently, the conventional design methodologies that deal with buildings as static entities do not always represent the proper method to generate user-friendly buildings. This paper presents a methodology that deals dynamically with the changing settings of buildings and their associated systemic configurations. This method is scenario-based design, in which scenarios represent essential tools for exercising various role playing and exploring potential “what-if” settings. In this method, a scenario structure aims to develop knowledge about each setting׳s compatibility to a set of prescribed expectations and quality criteria. To test the applicability of the proposed methodology, an experiential studio project is implemented. The project is orchestrated to illustrate the methodological use of scenarios and to gain in-depth understanding and predictive insights into the real-world architecture from various users’ perspectives. The method presented and discussed in this paper uses scenarios to analyze, develop and evaluate architectural design solutions that aim to achieve specific performance attributes, such as the flexibility, modifiability, transformability, adaptability, extensibility, functionality and operation of building components. The project that demonstrates the proposed method in action is illustrated by examples. The reflections about the method and its implementation seem to encourage its adoption as an alternative design processing tool that fits strongly within emergent typologies such as metamorphic, interactive, responsive and kinetic architectures.
... In the workshop, the students analyzed the requirements and subsequent implementation of various robotic systems. The workshop was designed as an advanced robotics programming workshop and was anchored upon a particular programming paradigm, termed scenario-based programming (SBP) ( [18], [19], [20]). In SBP the software for reactive systems (in robotics, transportation, manufacturing, etc.) is comprised of modules, called scenarios, each of which is responsible for a separate aspect of overall system behavior. ...
... PlayEngine [8], PlayGO [7], and Scenario Tools [4] support BP by implementing Live sequence charts (LSC) [3]. BPjs, as well as BPC and BPj, offer more generality, but lack the intuitive visual interface these tools have. ...
We present unified and extensible semantics for Behavioral Programming (BP). The presented semantics support a direct embedding of executable models in regular software systems. We further present BPjs --- a tool-set for executing, embedding, and verifying behavioral models, based on the proposed semantics. Being extensible, embeddable, and supporting verification, BPjs can serve as a common infrastructure for BP and executable modeling research.
... Although the issue of completeness of the set observations remains, approaches like [1] may guide the design of the ontology based on which observations are captured and indicate gaps at the observed behaviors. Moreover, as experienced in the play-out approach for Live Sequence Charts (LSCs) [11], a formal semantics provides a basis for playing out the current scenario catalog, thus generating traffic flows which in an expert can judge for unrealistic or missing real-life traffic flows. ...
This paper paves the way for a future scenario catalog-based approach to acceptance testing for highly autonomous vehicles by providing a rigorous formal semantics for a visual specification language of traffic sequence charts to be used for building the scenario catalog. It builds on our previous work on Live Sequence Charts [2] that defines a semantics sufficiently rich to cover both the requirement analysis phase and the specification phase for highly autonomous vehicles. This formal semantics provides the basis for tool support, in particular supporting the future V&V environment for autonomously driving cars under development by the German automotive industry.
... A minimal requirement for checking for completeness is thus the need to formally define, whether a particular observed traffic behavior is already covered or not by the current scenario catalog, thus requiring the definition of a formal satisfaction relation. Moreover, as experienced in the play-out approach for Live Sequence Charts (LSCs) [4,17] a formal semantics provides a basis for playing out the current scenario catalog, thus generating traffic flows which in an expert can judge for unrealistic or missing real-life traffic flows. As described in Section 3, Challenge C2 requires a formal semantics to identify the gaps between the space of possible worlds described in the scenario catalogue, and the concrete in-field incident or accident. ...
We propose a series of methods based on learning key structural properties from traffic data-basis and on statistical model checking, ultimately leading to the construction of a scenario catalogue capturing requirements for controlling criticality for highly autonomous vehicles. We sketch underlying mathematical foundations which allow to derive formal confidence levels that vehicles tested by such a scenario catalogue will maintain the required control of criticality in real traffic matching the probability distributions of key parameters of data recorded in the reference data base employed for this process.
... PlayEngine [11], PlayGO [12], and Scenario Tools [10] support BP by implementing Live sequence charts (LSC) [7]. BPjs, as well as BPC and BPj, offer more generality, but lack the slick visual interface these tools have. ...
We describe some progress towards a new common framework for model driven engineering, based on behavioral programming. The tool we have developed unifies almost all of the work done in behavioral programming so far, under a common set of interfaces. Its architecture supports pluggable event selection strategies, which can make models more intuitive and compact. Program state space can be traversed using various algorithms, such as DFS and A*. Furthermore, program state is represented in a way that enables scanning a state space using parallel and distributed algorithms. Executable models created with this tool can be directly embedded in Java applications, enabling a model-first approach to system engineering, where initially a model is created and verified, and then a working application is gradually built around the model. The model itself consists of a collection of small scripts written in JavaScript (hence "BPjs"). Using a variety of case-studies, this paper shows how the combination of a lenient programming language with formal model analysis tools creates an efficient way of developing robust complex systems. Additionally, as we learned from an experimental course we ran, the usage of JavaScript make practitioners more amenable to using this system and, thus, model checking and model driven engineering. In addition to providing infrastructure for development and case-studies in behavioral programming, the tool is designed to serve as a common platform for research and innovation in behavioral programming and in model driven engineering in general.
... ANP is meant to be a graphical modelling language, yet with formal logical reasoning underpinnings. For BCS modelling we encourage the use of graphical languages, where prime examples that are also formally grounded include the statecharts [78,79] and the live sequence charts [80], which were intended for describing concurrent and reactive systems. ...
The rapidly increasing pervasiveness and integration of computers in human society calls for a broad discipline under which this development can be studied. We argue that to design and use technology one needs to develop and use models of humans and machines in all their aspects, including cognitive and memory models, but also social influence and (artificial) emotions. We call this wider discipline Behavioural Computer Science (BCS), and argue in this paper for why BCS models should unify (models of) the behaviour of humans and machines when designing information and communication technology systems. Thus, one main point to be addressed is the incorporation of empirical evidence for actual human behaviour, instead of making inferences about behaviour based on the rational agent model. Empirical studies can be one effective way to constantly update the behavioural models. We are motivated by the future advancements in artificial intelligence which will give machines capabilities that from many perspectives will be indistinguishable from those of humans. Such machine behaviour would be studied using BCS models, looking at questions about machine trust like “Can a self driving car trust its passengers?”, or artificial influence like “Can the user interface adapt to the user’s behaviour, and thus influence this behaviour?”. We provide a few directions for approaching BCS, focusing on modelling of human and machine behaviour, as well as their interaction.
... Process windows are related to and inspired by a broad body of work on scenario-based system specification and analysis methods [20]. In particular, Message-Sequence Charts (MSCs) [21] and Live Sequence Charts (LSCs) [22] are widely used for the specification of protocols of the communication between system components by means of messages. MSCs and LSCs are supported by tools and can be automatically transformed to transition systems for further model-checking and synthesis. ...
... The Play-In Method LSC is supplemented with a method for building the scenario-based specification over a real or a mock-up GUI of the system called the play-in method. 9,10,12 With play-in, users specify the scenarios in a way that's close to how real interaction with the system occurs. ...
This is the second part of a two-part series that describes a pilot programming course in which high school students majoring in computer science were introduced to the visual, scenario-based programming language of live sequence charts. The main rationale for the course was that computer science students should be exposed to at least two very different programming paradigms and that LSCs, with their unique characteristics, can be a good vehicle for that. Part 1 (see the previous issue) focused on the pedagogic rationale of the pilot, on introducing LSC, and on the structure of the course. Part 2 centers on the evaluation of the pilot’s results.
... An SML specification defines how objects in an object model shall interact by sending messages. SML is a textual variant of Live Sequence Charts (LSCs) [5], extended with concepts for modeling environment assumptions. ...
Distributed, software-intensive systems such as fully automated cars have to handle various situations employing message-based coordination. The growing complexity of such systems results in an increasing difficulty to achieve a high quality of the systems’ requirements specifications, particularly w.r.t. the realizability of the specifications. Scenario-based requirements engineering addresses the message-based coordination of such systems and enables, if underpinned with formal languages, automatic requirements validation techniques for proving the realizability of a requirements specification. However, formal requirements modeling languages require a deep knowledge of requirements engineers and typically require many manual iterations until they find a realizable specification. In order to support requirements engineers in the stepwise development of scenario-based requirements specifications, we propose to evolve a high-quality specification from a (presumably unrealizable) manually created specification employing an evolutionary algorithm. In this paper, we show our results on automatically evolving new assumptions on the systems’ environment behavior that guarantee a realizable requirements specification. Based on this contribution, we outline our research roadmap toward our long-term goal of automatically supporting requirements engineers in finding high-quality requirements specifications.
Systems in the automotive industry achieve complex functionalities through the interaction in dynamically interconnected system networks. The individual systems offer partial functions developed within extensive development networks, which are then integrated to create a functionality that can be experienced by the user. For the successful development and validation of these systems, requirement and test specifications play a vital role, as these specifications form the basis for development work across disciplines and organisa- tions. However, it is challenging to specify requirements and tests in a way that they can be easily edited and communicated, while also precisely defining the expected system properties. This thesis describes a comprehensive model-based approach. Starting from a central system model, early and automated analysis of requirements is supported, leading to complete and consistent requirement and test specifications derived from the system model. The appropriate combination of techniques from Model-Based Systems Engineering (MBSE), Natural Language Processing (NLP), and scenario-based modeling enables a formal yet intuitive and application-oriented specification of requirements and tests.
Every object and every idea can be used as a model in an application scenario if it becomes useful as an instrument in a function in the scenario. Through this use and function, an object or idea becomes a model, at least for a certain or long time for the respective model user in its context and environment. Models therefore actually tell something about the use, the function, the scenario and the users without this being explicitly seen in the model. Being a model of an object or idea also explains a lot about the object or idea.
Models are used in a variety of ways in the sciences and technology, as well as in all phases of daily life, including ceremonies, presentations, templates and guides. Therefore, models are universal tools of every human activity, since every object and every idea can become a model and models are also usually much simpler as well as oriented towards concrete use.
The functions of models also allow a classification, i.e. an abstract characterisation of model-being for the respective scenario. Model-being represents a model as a model “of something”. Instrument-being places a model in relation to the outcome, i.e. a model is suitable “for something”. This from-for dichotomy of models is the starting point for the classification of models as representational, activity, explanatory, orientational, instructional, perceptual, declarative, socialisation or interactional, or conceptual or investigative, and the respective subcategories. An object or idea can be used in several functions at the same time, so that a model can also be assigned to different categories at the same time.
This raises questions such as the following: when does something become a model, what are the characteristics of a model, what quality is expected from a model, to what extent can one trust a model, which characteristics exclude being a model, to what extent is a model suitable and when not, what potential and what performance can be expected from a model, etc.
This paper presents a semi-automated approach for detecting conflicts and inconsistencies between architecture solutions. Inconsistencies occur when two or more architecture solutions rely on each other but cannot be satisfied, and conflicts when there are contradictions within one single decision specification, such as contradictory variable range and value. The proposed approach comprises a set of checks followed by transformations of architecture solutions specified according to a domain-specific-language, also created in the context of this work, into state machines. The semi-automated approach is implemented as a plugin for the MagicDraw modeling tool, and was evaluated in a project from the automotive domain.
A broad, long-term research project is described, which will lead to the computer becoming an equal member of the system-development team, continuously making proactive contributions, akin to those expected from an experienced and knowledgeable customer or user, a conscientious QA engineer, a strict regulatory auditor, an engineering -team leader, or the organization’s CTO. The web extra at https://youtu.be/mmrv8ZACbpU describes the authors’ novel “wise computing” approach and demonstrates one possible application. The second web extra at https://youtu.be/DtpvMxMwYPM extends the discussion of the authors’ novel “wise computing” approach and presents a case study.
Scenarios of execution are commonly used to specify partial behaviour and interactions between different objects and components in a system. To avoid overall inconsistency in specifications, various automated methods have emerged in the literature to compose (behavioural) models. In recent work, we have shown how the theorem prover Isabelle can be combined with the constraint solver Z3 to efficiently detect inconsistencies in two or more behavioural models and, in their absence, generate the composition. Here, we extend our approach further and show how to generate the correct composition (as a set of valid traces) of dephased models. This work has been inspired by a problem from a medical domain where different care pathways (for chronic conditions) may be applied to the same patient with different starting points.
ResearchGate has not been able to resolve any references for this publication.