Lists, Optional Elements, and Placeholders

In Software Product Line Engineering (SPLE), the ability of a software artifact to be used in different contexts is very essential for productivity. In order to manage and support this ability, different variability modeling methods have been proposed. An important group of such methods are based on UML. These methods typically introduce profiles for specifying mandatory and optional elements, identifying dependencies between elements, and modeling variation points and possible variants. However, the assessment of these methods still lacks. In this work, we have done a first step towards evaluating the comprehension and utilization of variability issues in UML-based models by suggesting a comparison framework which refers to different aspects of variability specification. Based on this framework, we chose a specific UML-based method – ADOM – and examined how advanced information systems students understood and utilized a model specified using this method. The results showed that the different means for specifying variability were understood and utilized only to a limited extent and that variation points were the least comprehensible variability specification means.

One of the outstanding problems of software engineering is the development of a program specification system which is rigorous, unambiguous, and powerful; yet one which is flexible, easy to use, and natural. This paper takes a step in that direction by introducing a new specification paradigm with much of the naturalness and flexibility of informal, natural language specifications yet with sufficient formality and rigor to allow machine processing of the specifications. This paper explains and analyzes the program specification method used by a working, automatic program synthesis system (the “C2,” Design Directed Program Synthesis System). This specification paradigm has a number of unique features: • The specifications consist of a number of independently stated, yet complementary elements or factors which clearly separate the “what” and “how” aspects of specification. • Each factored specification element is decoupled from the others and is meaningful by itself. • There is a well-defined (i.e., implemented) procedure for synthesizing programs using this specification paradigm. • One of the fundamental factored elements of this specification paradigm is an abstracted design. Each design is highly general and can be used to synthesize an infinity of target programs exhibiting a wide range of detailed control structures and functions. • The specification paradigm is intuitively appropriate in that each factored specification element contributes to the synthesis of the intuitively appropriate portions of the target program. This paper explains each factored specification element required by the C2 paradigm, what portions of the target program are developed from a specific element, and to a limited extent, how those target program portions are derived from the specification element. In addition, we will compare this specification methodology to other methods such as algebraic specification methods, specification languages, design languages, formal methods, and informal methods. Finally, we will discuss how this paradigm might be applied to a real-world system such as a business system.

Computers are fundamental tools to facilitate engineering design. But to provide adequate support, a systematic formalization is needed to express, communicate, and compute product knowledge between agents. This paper introduces the Design Knowledge Specification Language (DKSL), a knowledge representation (KR) language tuned to the engineering domain. It blends aspects of both specification and programming languages, allowing the definition, transmission, and computation of product knowledge for design process support. An overview of DKSL is presented, including its theoretical underpinnings, as well as a discussion of how DKSL can be applied to support design processes. Providing a rigorous formalization of product knowledge can significantly improve design processes.

In this paper we address the problem of specification and design of concurrent systems. More accurately, we present the definition of a new specification language that is formal, wide-spectrum, model-based, concurrent, polymorphic and strongly implicitly typed. The language is built upon a concurrent, funtional and imperative programming language: Concurrent ML. Specification aspects are supported thanks to the addition of some specification constructs and also by allowing axioms to ML structures and signatures. The resulting specification language is thus highly expressive though it embodies a restricted number of concepts. We present here the motivations underlying the definition of such a language as well as the design choices. Furthermore, we introduce the specification and development methology and illustrate it on various examples. We will see that many specification styles are allowed: algebraic, applicative, state-based, concurrent applicative and concurrent imperative. We show that the language rests on secure theoretical foundations exemplified by formal syntactic and semantic definitions. The latter consists in a static semantics together with a dynamic semantics. The static semantics reconstructs not only principal types but also minimal side and communication effects. This is done thanks to an extension of the type and effect discipline. The language is also endowed with a dynamic denotational semantics. The underlying model is based on an extension of the acceptance trees model to handle value-passing, communication, assignment, sequencing, return of results and higher order objects.

Action systems and the specification language Z, are integrated and used to give different aspects of a single systems specification. The static part of the system under development, i.e., the state declarations together with their accompanying invariants, are first specified using Z. Then the reactivity and real time aspects of the same system are specified within the action systems framework making use of the Z definitions. Furthermore, Z style is used to specify the actions in the action system. We exemplify the proposed methodology through a case study on a medical system specification.KeywordsAction SystemTime StampGlobal VariableSound SignalParallel CompositionThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Time and market pressure enforce a fast, flexible, safe and comfortable design of embedded control system software. The visualisation of the design process, i.e. graphical design capture, automatic translation and full functional and timing simulation of the target system in a workstation environment, allows to achieve these goals. This paper describes a system design methodology for embedded control systems based on a subset of ITU-T SDL, a language for specification and description of systems. While SDL is well suitable for the design of distributed heterogeneous systems we propose an extension to the subset, SDL/RealTime, which supports especially the graphical design of timing and safety critical embedded control systems with extensive local inter process communication. A timing concept will be introduced which is essential to embedded control applications. We decided to combine specification, targeting and timing aspects into one language to enable an integrated design flow. The article introduces SDL/RealTime and discusses the tool environment for design capture, automatic translation and run time support.

Language is rule-governed. Language is flexible, creative and bursts with odd patterns which then demonstrate a hidden regularity when examined further—or not. Which is it? I argue: Both, and everything in between. I review examples from multiple domains of language, such as orthography, morphology, semantics and syntax, where aspects of language span the spectrum from rule-governed to exception. This is used to motivate the quasiregularity manifesto: Traditional linguistic categories and generalizations are descriptively useful but do not exist in one-to-one correspondence with a discrete brain or cognitive entity. Connectionist and neural-networks models can implement quasiregular systems in ways that illuminate what is easy and difficult for human language users and learners. Can we predict where and how much quasiregularity will be exhibited in a specific language or aspect of language? I propose that how the continuum of regularity is colonized depends on whether communicative pressures prioritize efficiency of message transmission or flexibility of interpretation.

Automatic software reengineering changes or repairs existing software systems. They are usually tailor-made for a specific customer and language dependent. Maintaining similar reengineering for multiple customers and different language dialects may, therefore, soon become problematic unless advanced language technology is used. Generic pretty-printing is part of such technology and is the subject of this paper. We discuss specific pretty-print aspects of software reengineering such as fulfilling customer-specific format conventions, preserving existing layout, and producing multiple output formats. In addition, we describe pretty-print techniques that help to reduce maintenance effort of tailor-made reengineering supporting multiple language dialects. Applications such as COBOL reengineering and SDL documentation generation show that our techniques, implemented in the generic pretty-printer GPP, are feasible.

Using simulation monitors that are formally defined and automatically synthesized is already part of the standard methodology of hardware design and verification. However, this is not yet the case in the domain of systems engineering for cyber-physical systems. The growing trend towards model-based systems engineering is making the use of simulation monitors more relevant and possible. Recent related work focuses almost exclusively on the aspects of requirements specification. In this work, we explain how monitors can play a much more pervasive role in systems engineering, going beyond merely checking requirements. We describe how monitors can be used along the entire product lifecycle, from early design alternative analysis to final field testing. This work also covers the special considerations that must be addressed when designing a monitor specification language, specifically in the context of systems engineering. Our focus is on the practical issues related to the use of monitors and describes a prototype monitor specification and synthesis platform applied to the hybrid simulation of an automotive subsystem.KeywordsSimulationMonitorsCyber Physical SystemsSystems Engineering

We present DynAlloy, an extension to the Alloy specification language to describe dynamic properties of systems using actions. Actions allow us to appropriately specify dynamic properties, particularly, properties regarding execution traces, in the style of dynamic logic specifications. We extend Alloy's syntax with a notation for partial correctness assertions, whose semantics relies on an adaptation of Dijkstra's weakest liberal precondition. These assertions, defined in terms of actions, allow us to easily express properties regarding executions, favoring the separation of concerns between the static and dynamic aspects of a system specification. We also extend the Alloy tool in such a way that DynAlloy specifications are also automatically analyzable, as standard Alloy specifications. We present the foundations, two case-studies, and empirical results evidencing that the analysis of DynAlloy specifications can be performed efficiently.

Formal specification of visual languages

There has been a growing interest in recent years in the use of abstract building blocks in system specification. Designs based on patterns and communities are two examples. However, these structures are then refined further during design and implementation, and it is often difficult to determine whether the eventual system implementation is a faithful reflection of the original properties of the pattern specified. This is particularly true of patterns used to describe an enterprise view of the system. The paper concentrates on the behavioural aspects of pattern specification, and investigates the way that observation of the system can be interpreted to check that properties of the pattern specification are preserved. It describes a diagnostic tool that checks the actual system behaviour against the pattern specification, and discusses the requirements this places on the form of the specification language and a number of the problems of interpretation that arise in applying such tools.

We present DynAlloy, an extension to the Alloy specification language to describe dynamic properties of systems using actions. Actions allow us to appropriately specify dynamic properties, particularly, properties regarding execution traces, in the style of dynamic logic specifications. We extend Alloy's syntax with a notation for partial correctness assertions, whose semantics relies on an adaptation of Dijkstra's weakest liberal precondition. These assertions, defined in terms of actions, allow us to easily express properties regarding executions, favoring the separation of concerns between the static and dynamic aspects of a system specification. We also extend the Alloy tool in such a way that DynAlloy specifications are also automatically analyzable, as standard Alloy specifications. We present the foundations, two case-studies, and empirical results evidencing that the analysis of DynAlloy specifications can be performed efficiently.

The accessible specification of performance queries is a key challenge in performance analysis. To this end, we seek to combine the intuitive aspects of natural language query specification with the expressive power and flexibility of the Performance Tree formalism. Specifically, we present a structured English grammar for Performance Trees, and use it to implement a Natural Language Query Builder (NLQB) for the Platform Independent Petri net Editor (PIPE). The NLQB guides users in the construction of performance queries in an iterative fashion, presenting at each step a range of natural language alternatives that are appropriate in the query context. We demonstrate our technique in the specification of performance queries on a model of a hospital’s Accident and Emergency department.KeywordsPerformance requirements specificationNatural languagePerformance TreesPerformance analysis

Behaviour driven development: A systematic mapping study