论文下载
Challenges&Opportunities-in-low-code-testing.pdf
定义描述在第 2 节背景部分：
2 BACKGROUND
Low-code is an alive and in-progress domain that requires new techniques and tools proposal for resolving the existing challenges or for realizing new requirements. This needs an understanding of the theory behind the low-code domain that is described in this section.
2.1 Domain-Specific Language
A Domain-Specific Language (DSL) is a computer language special- ized to a particular application domain that enables domain experts to create a system using concepts they are familiar with. A DSL has to be designed in a way to be understandable for humans while executable by machine. For example, SQL is a well-known DSL specific for manipulation of databases [8].
Regarding the main objective of LCDPs, i. e., providing system development facilities for domain experts, DSLs are the underlying theory in the LCDP development. The target application domain of an LCDP, or more specifically, the aspects of a system that are modeled in that LCDP, defines which kind of DSLs are used on its basis. For instance, the Business Process Model and Notation (BPMN) is a well-known DSL for modeling business processes. It is used in Mendix LCDP to enable users to develop applications for automating the business processes of their organizations [31].
2.2 Model-Driven Engineering
Model-Driven Engineering (MDE) is a software development method- ology that uses models as the pivotal elements in the development. Model is an abstract representation of a system that conforms to a specific metamodel (i. e. the abstract syntax of a specific DSL), and is also independent of the technologies. To build a system following MDE principle, a domain expert first models the application domain manually, and then the models are automatically transformed to either intermediate models (i. e., model-to-model transformation) or source code (i. e., model-to-text transformation) [6]. In the first case, a model-driven execution platform is used for interpreting and running the intermediate models at runtime, while in the second, code generation engines produce executable code of the system (i. e.,
editable source code or bytecode) that can be executed at runtime environments [5]. In both cases, the transformation is implemented once by language engineers, and then is used several times to auto-generate many systems of the same type. Abstraction along with automation resulted in simplicity, reusability, higher accuracy, portability, interoperability, complexity management, lower cost, and faster release time [6], and these are the potential advantages offered by LCDPs.
LCDPs follow MDE principles. Indeed, they support system de- sign through visual modeling, and automatic generation of the executable final system following two distinct architectural ap- proaches. Some LCDPs, such as OutSystems, use code generation engines to produce executable code, and others, such as Mendix and Lightening, use a model-driven execution platform [5].
