# MDA-Based Approach for Blockchain Smart Contract Development
## 3 MDA-Based Smart Contract Development Method
### Transformation from Blockchain PSM to Smart Contract Code  
The Ethereum PSM or Hyperledger Platform PSM is further transformed into a smart contract in Solidity or Go programming language, respectively. Model-to-text transformations (M2T) are employed in this process and the produced smart contract code can be used for deployment on a specific platform as is or can be manually extended by the developer if needed. Metamodels for both implementation languages were developed (the Solidity metamodel in Figure 8 and the Go metamodel in Figure 9) and were used to define transformations from PSM elements to Solidity or Go language concepts. Figure 5: The extended UML metamodel with stereotypes and datatypes for both Hyperledger Fabric Blockchain PSM and Ethereum PSM. Figure 6: Blockchain PIM to Ethereum PSM transformation. Figure 8: Ethereum Solidity smart contract metamodel. Figure 7: Blockchain PIM to Hyperledger Fabric PSM transformation. During the Blockchain PSM transformation to smart contract code, a specific platform smart contract code file (Solidity file for Ethereum PSM, or a Go file for Hyperledger Fabric PSM) is created. The file is then appended line by line based on the specified Blockchain PSM structure and behaviour as the PSM stereotypes are directly related to the Ethereum Solidity smart contract (Figure 8) and Hyperledger Fabric Go chaincode (Figure 9) metamodels. In both cases, for the transformation to the Solidity smart contract (Figure 10) or the Go chaincode (Figure 11) source code, the file is appended with the Solidity or Go Variables (Figures 8 and 9) based on the Blockchain PSM <<variable>> properties. Additionally, depending on the PSM property stereotype, in the case of the Ethereum PSM, a Solidity mapping may also be appended to the code. Based on <<struct>> from Ethereum PSM and <<structure>> from the Hyperledger Fabric PSM classes, the data structs or structures are appended to Solidity or Go code, respectively, together with their Member or Field Elements based on PSM <<member>> or <<field>> properties. Next, in the case of the Ethereum PSM, the enumerations are transformed into Solidity <<enums>> and have their literals appended as <<enum>> members. Afterwards, the Solidity file is appended with the modifiers, based on the PSM <<modifier>> constraints. The enumeration and constraint transformation steps are not present in the case of the Hyperledger Fabric PSM, as the Go chaincode does not support such concepts (Figure 9). Afterwards, for both the Ethereum PSM and Hyperledger Fabric PSM, the PSM operations transformation starts during which functions based on <<function>> operations that are not utilised in the state machines are appended to the smart contract or chaincode. Additionally, in the case of Ethereum PSM, if any operations exist with an applied <<constructor>> or <<event>> stereotype, instead of Solidity function, a constructor or an event is created instead. As the concepts of constructor and event are not supported in Go, this step is skipped in the Hyperledger PSM transformation. Additionally, in any Blockchain PSM, provided that the specific <<function>> operations have a behaviour specified in a form of interaction or the opaqueBehavior, this behaviour is also included as a function body (blocks or expressions). Otherwise, if the behaviour was not specified, such a step is skipped, which results only in a function header that includes the function name, parameters or arguments, platform-specific data types, and modifier invocations (in Solidity). Next, state machines are analysed, and any functions based on the PSM <<function>> operations that are used in state machines as transition call events are appended to the smart contract or chaincode. The appended function header includes the function name, parameters, data types, and (only in Solidity) modifier invocations. Afterwards, based on PSM state machine, the function body code is extended with conditional statements or expressions which ensure that functions are only called when a contract is in a specific state.