domain with references to a specific one. This definition contains an important characteristic of SBPs.We prefer them to be associated with an abstract problem domain, easily substitutable by a concrete one. This can be implemented within the ReDSeeDS tool wherein the developers are able to quickly change the names in the domainmodel, and thus instantly “switching” from one domain to another. In this way, patterns can be quickly created or instantiated. Creation of a pattern consists in changing a concrete domain into an abstract one (e.g. “Add book” –> “Add whatever”), where instantiation is changing in the opposite direction (e.g. “Add whatever” –> “Add sales item”). Based on this mechanism we can create a library of patterns, reusable in many contexts.14 Here we present one example pattern which can serve as a starting point. This is a classical pattern that uses the well-known CRUD (Create, Read, Update, Delete) approach, presented also in the pattern book by Overgaard and Palmquist. Fig. 7.27 Structure of Software Behaviour Patterns 14 Similarly, a library of anti-patterns can be built [43] and used as guidance to avoid certain commonly made mistakes in use case modelling. 252 7 Applying MDRE in Practice Fig. 7.28 “Manage resources” pattern: use case model We call our version of the pattern “Manage resources”. After Cockburn we could also call it “Manage whatever” but we prefer the more formal name. The pattern is based on the use case model presented in Fig. 7.28. It involves an abstract “(user)” and five abstract use cases with “(resource)” being the recurring parameter in each of them. The central use case is “Show (resource) list”, which invokes the four other use cases which provide the actual CRUD functionality. Note that the “Create” use case is also accessible directly, and not only through an invocation. This is due to creating a “(resource)” that does not necessitate the context needed by the other three invoked use cases. To read, update or delete a “(resource)” we first need to select that resource which is provided by the central use case. The five use cases are further detailed with appropriate scenarios. Some of them are illustrated in Fig. 7.29. These scenarios are similar to the scenarios found in the examples in the previous chapters, and especially in Sect. 4.5. In fact, we can treat the current “Manage resource” pattern as a generalisation and extension of the presented use case models of the library domain (see e.g. Fig. 4.44). In Fig. 7.29, the functionality is quite basic.We can think ofmore complex scenarios with, e.g. the resource list being filtered or sorted. This can be subject to creating more elaborated patterns and later selecting the ones that are most suitable for the current problem at hand. Nevertheless, the scenarios are complete and coherent, with the necessary four invocation sentences in “Show (resource) list” consistent with the four invocation relationships. The scenarios are attached to the abstract domain model presented in fragment in Fig. 7.30. This is an important part of the overall pattern and defines all the abstract Screens, Triggers and Data Views that need to be involved. It contains all the relationships that determine the semantics of the individual domain elements within the whole model. For instance, note that “update (resource) button” is related with the “(resource) list” while “create (resource) button” is not. This is because the event associated with the first Trigger does not need any context (a resource selected from the list), while the second one does. The model also 7.3 Reuse Approaches with Requirements Models 253 Fig. 7.29 “Manage resources” pattern: selected scenarios Fig. 7.30 “Manage resources” pattern: domain model fragment contains all the verb phrases (“validate (resource)” etc.) that provide placeholders for the domain logic to be defined after instantiation. Note that the abstract domain model does not contain any Attributes because they can be determined only for a concrete domain. 254 7 Applying MDRE in Practice 7.4 Summary: Is MDRE for Me? In order to answer the title question, we should go back to the introduction and Sect. 1.1 which present the ideal dream of a software project manager. To judge if it is worthwhile to apply MDRE in our projects, we need to assess how close it brings us to fulfilling this dream. In making this judgment we should consider two major factors: quality of the resulting software and productivity in delivering software to the clients. In practice, this means answering the following two questions: (1) “How close is my working code to the real user needs?”, and “How much more productive are the development teams?” To answer these questions we can consider the current state of practice. The recent comprehensive market survey RE-Kompass [1] shows that 58% of companies were able to improve the quality of their software products by approaching more systematically to requirements. Thus, advancement in Requirements Engineering practices alone, leads to advancement in the quality of working code. Here we can identify two main areas of concern: • Understanding the user’s needs and capturing them correctly in adequately precise and complete descriptions of the intended capabilities of the system; • Translating these (evolving) descriptions accurately into technical artefacts, and finally to the executable code in a way that leads to software with consistently high quality. Unfortunately as the RE-Kompass survey shows, at least 70% of companies still use ambiguous natural language requirements with little template support. At the same time, according to another survey by El Emam andGünȩs Koru [45], “toomany requirements and scope changes” is seen as one of the two main causes (at 33%) of project failures. This is especially visible in case of long-term projects, aiming at large, complex and data intensive systems. It is thus evident that the software engineering industry struggles with poor quality of requirements. Note that the current process is largely manual especially in the area of user and software requirements. RE concentrates on managing largely textual paragraphs text and linking them manually to design. This is why—as the RE-Kompass survey shows—only 35% companies have experienced productivity increase through applying systematic RE. This causes a lack of stakeholder acceptance for making requirements formally precise—it adds effort but does not result in shorter development and evolution cycles. To change this we need to turn software requirements into first-class citizens in the software lifecycle. We need to seek ways to make them formally precise (but still comprehensible to business domain experts) and to automate their conversion into working code. MDRE assists us greatly in this quest through its techniques, tools and methodology, as presented in this book. By introducing automation right at the beginning of the software development process, MDRE promises significant gains in productivity. Of course, this has its limits and MDRE cannot be seen as the universal “silver bullet” from the famous 7.4 Summary: Is MDRE for Me? 255 Fred Brook’s paper [26]. There are always cases where high levels of automation are not possible or difficult. However, a high degree of automatic requirementsto-code generation for typical business systems seems perfectly achievable in the wider practice. This includes mainly systems with intensive user-system interaction and relatively standard structures of data processing and storage. For other types of systems, certain aspects of code need to be left for semi-automatic generation and manual completion. The key to mitigating the problems of software development seems to be shifting our efforts towards the essential complexity (cf. requirements), abstracting away the “accidents”, i.e. the technological details. In MDRE, all these details are captured within transformation programs capable of generating various target technological environments (web/mobile/desktop interfaces, databasemanagement systems, architectural frameworks, etc.). With a library of such transformations at hand, the various software project stakeholders can concentrate on providing semantically precise functional requirements specifications. As a result, the level of complexity at which developers need to operate decreases dramatically. This has two very significant impacts especially for large and complex systems: • Complex problems and their solutions have to be handled only at the conceptual level (the essence). This allows for buildingmuchmore complex systems at amuch lower cost associated with their unambiguous specification and implementation. • The quality of complex systems rises significantly through applying automation in generating code of repeatable high quality, from high-level requirements models. What is important is that the amount of effort to achieve these impacts in a given organisation might not be very significant. This mostly depends on the current practice in requirements specification. If the development teams have experience with writing good quality use cases and domain models, the effort would mainly consist in shifting to more semantically precise notations of RSL. In other cases, the effort would be obviously higher because it would involve acquiring knowledge on the fundamentals of use case and domain modelling. Of course, when implementing MDRE in our organisation, we should follow the best practices of software process improvement [125]. Generally, this should be a gradual process which improves our practices and raises maturity. This process can go through several levels. 1. Level 1. No systematic practices in requirements modelling. At this level, the organisation practices mainly textual requirements with perhaps some elements of modelling like use case diagrams and class diagrams for domain models. 2. Level 2. Practicing precise requirements models. At this level, t

From Requirements to Java in a Snap

The automatic generation of computer programs is one of the main applications with practical relevance in the field of evolutionary computation. With program synthesis techniques not only software developers could be supported in their everyday work but even users without any programming knowledge could be empowered to automate repetitive tasks and implement their own new functionality. In recent years, many novel program synthesis approaches based on evolutionary algorithms have been proposed and evaluated on common benchmark problems. Therefore, we identify and discuss in this survey the relevant evolutionary program synthesis approaches in the literature and provide an in-depth analysis of their performance. The most influential approaches we identify are stack-based, grammar-guided, as well as linear genetic programming (GP). For the stack-based approaches, we identify 37 in-scope papers, and for the grammar-guided and linear GP approaches, we identify 12 and 5 papers, respectively. Furthermore, we find that these approaches perform well on benchmark problems if there is a simple mapping from the given input to the correct output. On problems where this mapping is complex, e.g., if the problem consists of several subproblems or requires iteration/recursion for a correct solution, results tend to be worse. Consequently, for future work, we encourage researchers not only to use a program’s output for assessing the quality of a solution but also the way toward a solution (e.g., correctly solved subproblems). 

A Comprehensive Survey on Program Synthesis With Evolutionary Algorithms

In Genetic Programming (GP) systems, particularly those that target general program synthesis problems, it is common to use imperative programming languages to represent evolving code. In this work, we consider the benefits of using a purely functional, rather than an imperative, approach. We then demonstrate some of these benefits via an experimental comparison of the pure functional language Haskell and the imperative language Python when solving program synthesis benchmarks within a grammar-guided GP system. Notably, we discover that the Haskell programs yield a higher success rate on unseen data, and that the evolved programs often have a higher degree of interpretability. We also discuss the broader issues of adapting a grammar-based GP system to functional languages, and highlight some of the challenges involved with carrying out comparisons using existing benchmark suites.

Why functional program synthesis matters (in the realm of genetic programming)

The automatic generation of computer programs is one of the main applications with practical relevance in the field of evolutionary computation. With program synthesis techniques not only software developers could be supported in their everyday work but even users without any programming knowledge could be empowered to automate repetitive tasks and implement their own new functionality. In recent years, many novel program synthesis approaches based on evolutionary algorithms have been proposed and evaluated on common benchmark problems. Therefore, we identify in this work the relevant evolutionary program synthesis approaches and provide an in-depth analysis of their performance. The most influential approaches we identify are stack-based, grammar-guided, as well as linear genetic programming. Further, we find that these approaches perform well on benchmark problems if there is a simple mapping from the given input to the correct output. On problems where this mapping is complex, e.g., if the problem consists of several sub-problems or requires iteration/recursion for a correct solution, results tend to be worse. Consequently, for future work, we encourage researchers not only to use a program's output for assessing the quality of a solution but also the way towards a solution (e.g., correctly solved sub-problems).

Recent Developments in Program Synthesis with Evolutionary Algorithms.

A family of multi-concept program synthesisers in Alloy⁎

Combining model finder and genetic programming into a general purpose automatic program synthesizer

This paper presents a vision on how the software development process could be a fully unified mechanized process by getting benefits from the advances of Natural Language Processing and Program Synthesis fields. The process begins from requirements written in natural language that is translated to sentences in logical form. A program synthesizer gets those sentences in logical form (the translator's outcome) and generates a source code. Finally, a compiler produces ready-to-run software. To find out how the building blocks of our proposed approach works, we conducted an exploratory research on the literature in the fields of Requirements Engineering, Natural Language Processing, and Program Synthesis. Currently, this approach is difficult to accomplish in a fully automatic way due to the ambiguities inherent in natural language, the reasoning context of the software, and the program synthesizer limitations in generating a source code from logic.

Alexandre R. S. Correia

Papers

Combining model finder and genetic programming into a general purpose automatic program synthesizer

From requirements to ready to run software: a brief thought on how to mechanize the software development process

A family of multi-concept program synthesisers in Alloy⁎

The effect of distance metrics in a general purpose synthesizer: An empirical study on integer domain imperative programs