# MDA-Based Approach for Blockchain Smart Contract Development
## 2 Related Work  
Model-driven development [12; 15] can facilitate development by eliminating redundant or automating repeated manual actions during smart contract development and shifting the focus to development activities such as requirement elicitation, design, verification, and validation that are generally neglected [8]. A number of research efforts to introduce model-driven development principles into smart contracts development exist [15] and are mostly tailored for testing [5], code generation [11; 12; 15; 16], deployment [23; 24], or requirement verification/validation [16; 25] activities. Such activities are deemed especially important due to the immutability of smart contracts, which requires that smart contracts be completely developed before deployment, as changes after deployment are either impossible or very complicated [3; 26]. In smart contract engineering, model-driven development encompasses areas of smart contract structure and/or behaviour modelling. The most common approach to outline the structure of smart contracts is to use UML class diagrams, which are used for visualisation [27], validation [24], deployment [23], and code generation [28; 29]. Additionally, some proposals for code generation and validation also employ behaviour models that, in addition to the structure, are used to verify [30], simulate [16], or generate code. The smart contract behaviour specifications range from business process modelling using BPMN notation [31] to modelling the smart contract as a software artefact using state machine such as notations [32; 33; 34]. Some methods propose to use sequence diagrams/interaction specifications for outlining the behaviour and collaboration of multiple system components [35]. In some cases, code embeddings can also be included directly in the model [25; 36]. Specific embeddings could be tailored to a variety of cases such as outlining the behaviour of functions, classes, and additional structural details, and in the case of smart contracts, such embeddings can be tailored to community-based ERC standards [37; 38; 39]. The specific case of model-driven development is Model-Driven Architecture (MDA) framework. Although a relatively small proportion of current research in smart contract engineering uses MDA, overall, four methods are based on or adjacent to MDA [17; 18; 19; 20], and are directly compared to each other and our proposed method in terms of MDA Computation-Independent, Platform-Independent, and Platform-Specific Models (Table 1). The CIM abstraction layer is the least utilised in smart contract development, as is often the case in other domains [10]. In [18], the CIM is specified in textual notation using ADICO statements, in which a developer can outline the aim, conditions, input, and outputs. Similarly, in [17], the developer outlines contract party agreements. In [19], the REA ontology is used as a basis to outline the class diagram that consists of a transaction, contract, commitment, events, commitments, and resources. The authors of [20] do not employ the CIM abstraction layer at all, and none of the aforementioned approaches support automatic transitions between the CIM and PIM abstraction layers. The PIM abstraction layer is where the most common characteristics between the different methods can be observed. In [18], the ADICO statements are used to outline the behavioural details of smart contracts as a finite state machine. Considering that the smart contract is closely related to state behaviour, the FSM allows one to model the behaviour of a smart contract consisting of states, transitions, and conditions. In [17], an Event-B notation is used to outline a formal smart contact description. Event-B is a modelling notation which allows one to specify discrete transition systems consisting of contexts and machines. Specifically, the machine encapsulates the state by a set of variables and captures transitions as guarded events.