A domain-specific language based approach to component composition, error-detection, and fault prediction

Current methods of software production are resource-intensive and often require a number of highly skilled professionals. To develop a well-designed and effectively implemented system requires a large investment of resources, often numbering into millions of pounds. The time required may also prove to be prohibitive. However, many parts of the new systems being currently developed already exist, either in the form of whole or parts of existing systems. It is therefore attractive to reuseexisting code when developing new software, in order to reduce the time andresources required. This thesis proposes the application of a domain-specific language (DSL) to automatic component composition, testing and fault-prediction. The DSL ISinherently based on a domain-model which should aid users of the system m knowing how the system is structured and what responsibilities the system fulfils. The DSL structure proposed in this thesis uses a type system and grammar hence enabling the early detection of syntactically incorrect system usage. Each DSL construct's behaviour can also be defined in a testing DSL, described here as DSL-test. This can take the form of input and output parameters, which should suffice for specifying stateless components, or may necessitate the use of a special method call, described here as a White-Box Test (WBT), which allows the external observer to view the abstract state of a component. Each DSL-construct can be mapped to its implementing components i.e. the component, or amalgamation of components, that implement(s) the behaviour as prescribed by the DSL-construct. User-requirements are described using the DS Land appropriate implementing components (if sufficient exist) are automatically located and integrated. That is to say, given a requirement described in terms of the DSL and sufficient components, the architecture (which was named Hydra) will be able to generate an executable which should behave as desired. The DSL-construct behaviour description language (DSL-test) is designed in such a way that it can be translated into a computer programming language, and so code can be inserted between the system automatically to verify that the implementing component is acting in a way consistent with the model of its expected behaviour. Upon detection of an error, the system examines available data (i.e. where the error occurred, what sort of error was it, and what was the structure of the executable), to attempt to predict the location of the fault and, where possible, make remedialaction. A number of case studies have been investigated and it was found that, if applied to the appropriate problem domain, the approach proposed in this thesis shows promise in terms of full automation and integration of black-box or grey-box software. However, further work is required before it can be claimed that this approach should be used in real scale systems

Challenges and Directions in Formalizing the Semantics of Modeling Languages

Developing software from models is a growing practice and there exist many model-based tools (e.g., editors, interpreters, debuggers, and simulators) for supporting model-driven engineering. Even though these tools facilitate the automation of software engineering tasks and activities, such tools are typically engineered manually. However, many of these tools have a common semantic foundation centered around an underlying modeling language, which would make it possible to automate their development if the modeling language specification were formalized. Even though there has been much work in formalizing programming languages, with many successful tools constructed using such formalisms, there has been little work in formalizing modeling languages for the purpose of automation. This paper discusses possible semantics-based approaches for the formalization of modeling languages and describes how this formalism may be used to automate the construction of modeling tools

Identifying Bugs in Make and JVM-Oriented Builds

Incremental and parallel builds are crucial features of modern build systems. Parallelism enables fast builds by running independent tasks simultaneously, while incrementality saves time and computing resources by processing the build operations that were affected by a particular code change. Writing build definitions that lead to error-free incremental and parallel builds is a challenging task. This is mainly because developers are often unable to predict the effects of build operations on the file system and how different build operations interact with each other. Faulty build scripts may seriously degrade the reliability of automated builds, as they cause build failures, and non-deterministic and incorrect build results. To reason about arbitrary build executions, we present buildfs, a generally-applicable model that takes into account the specification (as declared in build scripts) and the actual behavior (low-level file system operation) of build operations. We then formally define different types of faults related to incremental and parallel builds in terms of the conditions under which a file system operation violates the specification of a build operation. Our testing approach, which relies on the proposed model, analyzes the execution of single full build, translates it into buildfs, and uncovers faults by checking for corresponding violations. We evaluate the effectiveness, efficiency, and applicability of our approach by examining hundreds of Make and Gradle projects. Notably, our method is the first to handle Java-oriented build systems. The results indicate that our approach is (1) able to uncover several important issues (245 issues found in 45 open-source projects have been confirmed and fixed by the upstream developers), and (2) orders of magnitude faster than a state-of-the-art tool for Make builds

Domain-specific languages

Domain-Specific Languages are used in software engineering in order to enhance quality, flexibility, and timely delivery of software systems, by taking advantage of specific properties of a particular application domain. This survey covers terminology, risks and benefits, examples, design methodologies, and implementation techniques of domain-specific languages as used for the construction and maintenance of software systems. Moreover, it covers an annotated selection of 75 key publications in the area of domain-specific languages

Using a Dynamic Domain-Specific Modeling Language for the Model-Driven Development of Cross-Platform Mobile Applications

There has been a gradual but steady convergence of dynamic programming languages with modeling languages. One area that can benefit from this convergence is modeldriven development (MDD) especially in the domain of mobile application development. By using a dynamic language to construct a domain-specific modeling language (DSML), it is possible to create models that are executable, exhibit flexible type checking, and provide a smaller cognitive gap between business users, modelers and developers than more traditional model-driven approaches. Dynamic languages have found strong adoption by practitioners of Agile development processes. These processes often rely on developers to rapidly produce working code that meets business needs and to do so in an iterative and incremental way. Such methodologies tend to eschew “throwaway” artifacts and models as being wasteful except as a communication vehicle to produce executable code. These approaches are not readily supported with traditional heavyweight approaches to model-driven development such as the Object Management Group’s Model-Driven Architecture approach. This research asks whether it is possible for a domain-specific modeling language written in a dynamic programming language to define a cross-platform model that can produce native code and do so in a way that developer productivity and code quality are at least as effective as hand-written code produced using native tools. Using a prototype modeling tool, AXIOM (Agile eXecutable and Incremental Objectoriented Modeling), we examine this question through small- and mid-scale experiments and find that the AXIOM approach improved developer productivity by almost 400%, albeit only after some up-front investment. We also find that the generated code can be of equal if not better quality than the equivalent hand-written code. Finally, we find that there are significant challenges in the synthesis of a DSML that can be used to model applications across platforms as diverse as today’s mobile operating systems, which point to intriguing avenues of subsequent research