Model-Based Software Design and Testing in Blockchain Smart Contracts: A Systematic Literature Review

Blockchain technology promises to spark a real revolution. One of most important concepts associated with this technology is smart contracts, which enable the automatic execution of agreements and augur a world without intermediaries. The conditions and rules of “contracts” are established in a computer codes and trust is enforced by consensus among the participants. One relevant feature associated with smart contract is the immutability property, which establishes the non-alteration of blockchain network data after the clauses of the contract are been approved by all parties or entities involved. For this reason, smart contract development requires more effort and care than the development of other common programs. They require systematic mechanisms to collect requirements and functional specifications. In addition, it is necessary to verify and validate the agreed functionality and the implemented code before they are deployed in the blockchain platform. This article presents a systematic literature review of primary studies in the field of Software Development Life Cycle, focusing on model-based software design and testing in the blockchain domain of smart contracts. This research aims to identify gaps and/or opportunities for further research. After carried out this review, it was observed that no clear methodology exists for evaluating and validating the quality either of this software or the overall development process. This means that software developers may implement smart contract code in which bugs and serious security vulnerabilities appear when the software is delivered to their customers.


I. INTRODUCTION
Blockchain technology has well-known benefits in many areas (e.g., economic, political, humanitarian, or social, among others) and could reconfigure many aspects of today's society [2]. Blockchain technology, based on distributed ledger technologies (DLT), is a chain of cryptographically linked blocks. This technology provides mechanisms to define agreements using the concept of smart contract [61], which is computer programs that run on blockchain networks without intermediaries. A smart contract, in the case of legal agreement, tends to replace the printed document with The associate editor coordinating the review of this manuscript and approving it for publication was Srinivas Sampalli . legal language. The software requirements that this computer program must satisfy, from the engineering perspective, are analogous to the terms, rules, and conditions in a conventional legal contract. However, it is important to highlight that smart contracts can encode automated agreement execution, but not all smart contracts may necessarily be agreements and do not always necessarily codify actions between more than one party.
The first conceptualization of the smart contract term was published by Nick Szabo in 1994 [66]. In this article, the author defines a smart contract as a set of clauses, data and protocols. These protocols implement algorithms to automatically verify the fulfilment of each condition by each party/entity involved in the contract. In this sense, these contracts are smarter than paper-based contracts because they automatically enforce the obligations of the parties involved. But a smart contract should not be seen as intelligent tools that can parse a contract's more subjective requirements.
On the other hand, it is important to note that the fact of eliminating the need for a trusted third party significantly reduces the transaction costs, that is, it facilitates the most economic exchanges.
In this context, a set of important concepts will be introduced: • Software Development Life Cycle (SDLC) is a process that defines good practices to document, develop, maintain, and replace the software adequately [57]. As mentioned above, smart contracts are also software. Therefore, it is necessary to apply methodological processes for eliciting their requirements and functional specifications to improve their quality [36]. However, to the best of our knowledge, there are currently no guidelines for implementing smart contracts.
• One of the most important aspects, to consider in SDLC, is the Software Testing because it allows improving the quality of the software [28]. However, this testing phase often becomes less important due to delays in development. Then, it is usually performed at the end once the coding phase is finished and before the software is delivered to the customer. In this context, it is relevant to start testing software as soon as possible when SDLC is carried out. Early testing allows detecting many defects soon what helps to increase quality and customer's satisfaction [14].
• Over last years, Model-Driven software engineering [70] has become a practical, efficient, and successful methodology for software design and testing. Many proposals [7], [20], [21], [26] use this paradigm to define software requirements in structured, comprehensible, and formal models. This formalization allows establishing mechanisms to measure, check and verify these requirements from early stages. In addition, the definition of these formal models facilitates the definition of transformation rules to generate a test case systematically and automatically, and even software code associated with these test cases [19]. These methodological practices facilitate code reusability and the reduction of human errors.
• Other important benefits achieved by Model-Driven software engineering are: (1) systematized design, and continuous software testing to increase software development effectiveness, and (2) reusable models and software code which can reduce costs and time in the software development process.
In this context, this article presents the results of a study that analyzes the state-of-the-art of research works in the field of SDLC. Concretely, this study is focused on proposals that address the Model-Based software design and testing for smart contracts within blockchain domain. For this purpose, the Systematic Literature Review (SLR) method is used to identify gaps and to offer future research guidelines related to our research topic.
The rest of the paper is structured as follows: Section II and III describe the method used for the systematic review and its planning, respectively; After defining the review protocol to be applied, it is conducted presenting in Section IV the results; Section V analyses and discusses the most relevant findings; finally, Section VI provides a set of conclusions and suggestions for future works.

II. REVIEW METHOD
The present study was carried out using one of the SLR methods most successfully and widely applied in software engineering field. Specially, the Kitchenham's method [30]. This method present rigorous stages to analyze research knowledge using a trustworthy and auditable methodology. Some authors, however, have criticized Kitchenham's method and/or proposed improvements on this one [15], [31].
In the wake of these criticisms and suggestions for improvement, Kitchenham published an updated version of her method in [30]. But, at present, some authors [15] admit that an important gap still exists regarding the evaluation of quality in studies based on empirical methods. This SLR follows the latest version of Kitchenham's method, referenced above. It describes three phases for executing a systematic review: (1) planning, which defines aspects such as the need for the research, review protocol and research questions; (2) conducting, which the previously established protocol is carried out; and (3) reporting, which presents the final analysis to answer each research question. Figure 1 shows these phases and their tasks on a timeline to achieve research objective of this article.

III. PLANNING THE SYSTEMATIC REVIEW
This section describes the planning process conducted in this SLR. During this process, the need to perform the review was identified, the research questions (RQs) were formed, and the review protocol was established and verified. VOLUME 8, 2020 A. THE NEED FOR THE REVIEW Over the last few years, much researches around the world to evaluate and identify challenges and obstacles to the application of blockchain smart contracts in different fields. This research has reported and evaluated the use of blockchain technology in multiple processes and services in different business areas (e.g., Internet of Things [39], Supply Chain [55], [64], [68], education [74], agriculture [72] or health [73], among others). In addition, one of the objectives of these investigations has been identifying challenges and barriers of this technology in different scenarios (e.g., quality [32], Big Data [29] or e-government [4]).
In addition, some works partially related to our proposal have been published. Alharby et al. [3], present a Systematic Mapping Study (SMS) of technology-oriented research in smart contracts. In this study, the authors followed the method presented by Petersen et al. [52]. However, the process followed is not well detailed which makes reproducibility difficult. Following the same method, Macrinici et al. [41] propose an SMS to know the state-of-the-art in smart contract applications within blockchain technology. Authors deeply reviewed 64 papers identifying some gaps but, there is no mention about testing. Leka et al. [35] develop an SLR but the authors follow the SMS method mentioned earlier, they do not follow the SLR process. Moreover, no explanation about the execution is described and results cannot be reproducible. Finally, Dhaiouir and Assar [17] present an SLR of Blockchain-Enabled Smart Contracts, focusing on platforms, languages, or applications among others. Again, there is no mention about testing.
Conversely to the present literature, this article describes an SLR carried out in the field of SDLC, in particular on smart contract development life cycle. The focus is on the modelbased design and testing of blockchain smart contracts. More specifically, we review the state of formal smart contract modelling and automatic code generation, together with the verification/validation of this code, in order to characterize and present the state-of-the-art (approaches) in this field and identify gaps and opportunities for further research.

B. RESEARCH QUESTIONS
Following Kitchenham's method, RQs needed to be stablished for clearly focus the research on the topic and improve our understanding of the proposals being studied. The general RQ guiding our whole SLR was: What is the state-ofthe-art as regards blockchain smart contracts in software engineering? . If software engineering is applied, it is fundamental to have specific analysis and design methods, quality control through testing and metrics, security assessment and overall development process. Therefore, this question could be considered very general, so it was reformulated in several more specific questions to provide a clear view of the most relevant aspects of proposals addressing the collection of requirements and functional specifications, analysis, design, coding and testing in the context of blockchain smart contracts. Table 1 shows together the defined RQs with their motivations and corresponding sub-questions. In addition, the possible answers to be responded are described.

C. REVIEW PROTOCOL
After formulating each research question, the review protocol must be specified to define search strategies, inclusion and exclusion criteria for primary studies (PS), and quality criteria. This section aims to define these aspects.

1) SEARCH STRATEGY
The search strategy is the procedure followed to locate the most relevant PS that have been indexed in different digital libraries. In this sense, this strategy is focused on locating papers published in peer-review journal and international conferences. The search strategy was divided into two phases: • Phase 1. The first phase consists of defining keywords that are going to be used in the search protocol. This definition has been performed after running different pre-searches, which allow to refine the most appropriate set of keywords. In this sense, it is important to obtain appropriate keywords because these allow improving the quality of the results. Table 2 presents the keywords used in this SLR.  [48] propose more than ten digital libraries (i.e., Academic Search Premier, ACM Digital Library, Emerald Full Text or IEEE Xplore Digital, among others) considering their relevance. However, during the process of carrying out preliminary searches, we noticed that many papers were repeatedly returned by different digital libraries. After considering this fact, we decided to use only the following databases: ACM Digital Library, IEEE Xplore Digital Library, ScienceDirect, Elsevier's Scopus, and Springer Link. References were managed using the Jabref tool [23] and a spreadsheet.
Boolean expression for the metadata of a paper (2) Once keywords and digital libraries were established, search expressions were formalized using Equation 1 and executed on each digital library. For this purpose, titleabstract-keyword metadata of each paper were selected as information sources. The use of these metadata is formalized in Equation 2. Each digital library has its own syntax for indicating custom search expressions. Moreover, they have certain limits on the maximum number of logical clauses in the same search. Therefore, Equation 2 was applied into different queries. Table 3 shows each of the queries executed in each of the databases selected in this SLR.
In addition, it was also necessary to extend each search query using filters due to the considerable number of search queries. These filters are provided by each digital library. For example, scientific area, specific topic, and year of publication greater than or equal to 2016 were some of the filters applied. Only from 2016, we started to identify paper that enhanced the predefined search criteria. Although Ethereum, for instance, was formally announced by Vitalik at The North American Bitcoin Conference in 2014 [8], the Ethereum network was not launched till 2015. In that year, developers began writing smart contracts and decentralized apps to deploy on the live Ethereum network.
Finally, the previously defined systematic search protocol has been extended using the ''snowball'' technique [71]. This technique involves extending the search process to cover both the reference lists and the citations in each paper under study.
Section IV-A describes in detail how the search strategy was executed.

2) SELECTION PROCESS, EXCLUSION AND INCLUSION CRITERIA, AND QUALITY ASSURANCE
This section defines the selection process of relevant papers, which are going to be later analyzed considering the objectives of this SLR. Three researchers are responsible for carrying out this selection process. Table 4 summarizes each phase conducted in the process of selecting papers for study.
Our selection process includes some face-to-face meetings to offer a forum for discussion and agreement between researchers when there are doubts to evaluate a paper. The objective of these meetings is to reduce the bias of each researcher. On the one hand, the first meeting each face is made in the third phase (Ph3) of our selection process (see Table 4). As mentioned above, this phase aims to resolve any doubts when inclusion/exclusion criteria are applied. In these cases, a full reading of dubious papers is necessary. After this reading, all researchers decide -always jointly -to finally include or exclude the PS. The decision must be joint to avoid subjectivity. On the other hand, the second face-to-face meeting (Ph5) is carried out after applying the ''snowball'' technique and its objective is also to resolve any doubts when the papers returned by this technique are evaluated or when exclusion/inclusion criteria are applied.
Regarding exclusion/inclusion criteria, we have established some objective criteria which have been grouped by each phase of the selection process (Table 5). In short, we consider papers written in English and published in well-reputed  journals (i.e., journals indexed in Journal Citation Reports; JCR) or prestigious conferences (i.e., A*, A, B and C conference level categorized in CORE Conference Ranking). Regarding international conferences, we have considered conferences. Furthermore, we have decided to exclude surveys, discussion, reviews or opinion papers related to blockchain smart contracts.
Finally, Table 5 summarizes criteria defined to include and exclude PS during the selection process.

3) QUALITY QUESTIONS
Quality Criteria (QC) were defined to obtain the best results for future research. Table 6 shows the quality questionnaire applied in this SLR. The cumulative score for each criterion would make up the final quality score for each PS. It is important to note that these quality criteria are not used to exclude papers, but they are used to determine the most relevant and representative PS in future research.

4) DATA SCHEMA
The analysis of each PS could become a difficult task due to the heterogeneous information and different structures of each study. In this sense, we propose a characterization scheme (see Table 7) to homogenize this analysis and reduce the complexity of this task.

5) REVIEW PROTOCOL VALIDATION
Following the recommendations given in Kitchenham's method, the SLR protocol was reviewed to obtain a comprehensive review process. As mentioned above, some random searches were applied to refine definitive keywords and exclusion/inclusion criteria, among other aspects. However, we decided to seek advice from experts in the conduct of SLR to define a systematic, full and comprehensive process. In this sense, a Full Professor in Software Engineering at   the University of Seville (Spain) participated as an external expert to validate our review protocol.

IV. CONDUCTING AND QUALITY RESULTS
This section aims to present the results obtained after executing the review protocol defined in the previous section. This section also presents the set of PS obtained, as well as the quality score of each PS according to our quality criteria questionnaire (cf. Table 6). Finally, Section IV-B describes some threats to this work's validation process.  Table 8 presents the distribution of PS obtained after applying inclusion/exclusion criteria in each phase of the selection protocol. For each digital library, it is showed the number of papers thrown up in each stage of the review protocol. Table 8 also includes a record of papers obtained after the ''snowball'' technique had been applied (to streamline the handling of the results, these papers were not classified by digital library). Figure 2 graphically displays the evolution of the considered PS in the search protocol.

B. THREATS TO VALIDITY
The review and validation protocol presented in previous sections may involve weaknesses or threats on this protocol because the tasks have been conducted by people. Due to this human factor, the selection of papers could be affected by errors during the process of classification and selection of PS. These risks have been mitigated with the execution of several iterations in the review process and several meetings between researchers when there were doubts about the categorization of any PS.
Although the review process has been exhaustively defined and executed, it is not possible to guarantee full coverage of the scientific literature about a topic (e.g., non-indexed papers or grey literature are not considered in this SLR).
Moreover, Schmucker et al. [60] states that those types of publications are very rarely relevant in SLR results. That is VOLUME 8, 2020 why in our study the search terms were used in five online digital libraries covering a wide range of topics enough to be reasonably considered exhaustive for the research field on which this SLR focused. Furthermore, it is important to note that all authors have been involved in the definition of the search protocol, RQs and search terms. This decision has allowed to increase the objectivity of the review process.

V. DISCUSSION AND ANALYSIS
This section aims to answer and discuss each research question to identify state-of-the-art weaknesses according to the objective of this SLR.  Table 9 shows the PS that were found and finally included in this SLR following all the quality criteria described in Section III-C.
It is important to mention that the number of PS has not been reduced after applying quality measurements. These measures allow us to score the most relevant and representative PS for consideration in future research. In this sense, Table 9 shows the quality score (chosen in the last column of Table 9; SC column) for each PS. The maximum score for quality measurement is ten points according to the criteria established in Section III-C.
For instance, Grigg (PS15) proposes to use the Ricardian contracts. A Ricardian contract places the defining elements of a legal agreement in a format that can be expressed and executed in software. This work is very relevant to be considered in future research. In this studies list, highlights several papers as: • Marchesi (PS01) proposes a software development process to gather the requirement, analyze, design, develop, test and deploy blockchain applications.
• Choudhury (PS03) provides a novel framework for autogenerating smart contracts by enabling the seamless translation of constraints encoded in knowledge representation to blockchain requirements. This framework uses ontologies and semantic rules to encode domainspecific knowledge and then leverages the structure of abstract syntax trees to incorporate the required constraints.
• Tateishi (PS04) proposes a technique to automatically generate a smart contract from a human-understandable contract document that is created using a document template and a controlled natural language (CNL). The automation is based on a mapping from the document template and the CNL to a formal model that can define the terms and condition in a contract including temporal constraints and procedures.
• Mavridou (PS13) argues, in practice, the smart contracts are riddled with vulnerabilities comprising a critical issue. To facilitate the development of secure smart contracts, we have created a framework, which allows developers to define contracts as finite state machines (FSMs) with rigorous and clear semantics.
• Syahputra (PS19) discusses the development process of a smart contract platform that aims to generate smart contracts for heterogeneous blockchain technologies.
• Mavrodou (PS22) introduces a framework for the formal verification of smart contracts that are specified using a transition-system based model with operational semantics. This framework allows the generation of Solidity code from the verified models, which enables the correct-by-design development of smart contracts.
After the detailed analysis of numerous studies, it can be said that software development practice has progressed steadily, and many methods and models have been recommended to enhance its productivity and effectiveness. Royce [58] is acknowledged as the first person to introduce a methodology specifically conceived for software development. Known as the waterfall model, this method was subsequently redefined by many different organizations and people, resulting in several variations known collectively as SDLC methodology.
Despite the appearance of some new agile models it is also important to mention that SDLC is still the most widely used development methodology in most organizations [5]. The main phases of SDLC are requirements gathering, system analysis and design, coding, testing, deployment, and maintenance. Table 10 shows the distribution of PS about the phases they support, in the context of smart contract Development Life Cycle.
In these aspects, highlights the work of Marchesi (PS01) and Tsai (PS05). Marchesi proposes a software development process to collect the requirements, analyze, design, develop, test and deploy blockchain applications. On the other hand, Tsai (PS05) proposes a framework. This framework has 5 stages: smart contract template development from domain analysis, formal smart contract model and code development from templates and verification/validation.
It can be concluded that the scientific community's efforts are currently aimed at implementing some kind of SDLC. But in the smart contract context, this process consists only of a certain number of unlinked phases, lacking in a common vocabulary. These phases are not arranged in a clear order of precedence and the inputs/outputs are not clearly defined from one step to the next. In addition, there is no deterministic ''definition of done'' that can be used to confirm whether a step is truly completed.
On the other hand, it is important to highlight the fact that, despite its importance to efficient blockchain development, the phase with the least impact in the literature is that of software testing. Blockchain differs from other, traditional applications, requiring testers to address specific requirements and acceptance criteria. Once a smart contract is implemented, its execution cannot be reversed. This calls for robust testing with emphasis on code debugging, but blockchain software testing is a highly specialized domain which requires proven expertise and a rigorous approach. Moreover, smart contract testing involves simulating all possible expected and unexpected variables for every smart contract and for the triggers that execute transactions.
Smart contract testing requires expert knowledge of scenarios, business, and transaction variables specific to blockchain networks. In this kind of network, with numerous nodes and combinations, automatic testing should predominate. Since smart contracts enforce a set of rules through strong cryptography, it is also necessary to validate encryption codes using robust testing methodologies. Smart contract testing is complicated and requires specialized validation capabilities. Testers need QA (quality assurance software) skills and API skills in addition to regulatory, business process management, security, and compliance skills.

B. RQ2. DO THEY PROMOTE MODEL-BASED ENGINEERING, EARLY STARTING OF THE TESTING PHASE OR AUTOMATIC SMART CONTRACT GENERATION?
Since a few years ago, modelling tools [59] have been helping document enterprise process functionality and using model transformations to automate software code generation with Unified Model Languages (UML) and other modelling standards. For example, Marchesi (PS01) and Syahputra (PS19) make use of UML-Diagrams to describe the requirements of the applications.
UML for testing, known as the UML 2.0 Testing Profile (U2TP) [13] has also closed the gap between designers and testers by providing a good reason for using UML for VOLUME 8, 2020 both system modelling and test specification. This allows UML-Design documents to be reused for testing and, most importantly, enables test development in an early phase of system development.
Since models are usually easier to understand than software source code [24], it also makes it possible to improve development productivity and quality. It is easier to check the correctness of a model, and modelling tools can ensure that the deployed code, from the model, has not been modified after its generation [40].
Model-based software engineering [53], [56] is important in blockchain-oriented applications for the following reasons: • Best practices can be implemented, and well-tested codes generated, thereby reducing the occurrence of vulnerable code. Moreover, model-based tools can improve the verification/validation of smart contract code by applying testing techniques right from the early stages of the SDLC, a practice known as early testing.
• The software code is more difficult to understand than the models. It is, therefore, easier to check the correctness of a model. Software code can also be generated automatically from model-based tools, thus ensure that the generated code has not been modified after it is obtained.
• As they are platform-agnostic, models can avoid lockin to specific blockchain technology and model-based engineering can be applied across multiple blockchain platforms. Table 11 shows the distribution of PS concerning this type of proposals.
As the table shows, the types of proposals most addressed by authors are, respectively: (B1) Application of model-based software engineering (48%), (B2) Promotion of early testing (5%), and (B3) Proposal of automatic code generation (48%).
It can be concluded that although early testing helps to reduce the number of defects and, ultimately, cuts the cost of final revisions, the scientific community's efforts are currently not aimed at this approach. Every software engineer knows that if a bug is detected in the final stage of testing [59], changes may then need to be made in the design and analysis phase. It is therefore important to carry out testing in every phase to ensure that software will run according to expectations and will not fail once it has been delivered to the client. When testing is performed at the end of the SDLC, i.e., after the coding phase, there may not be enough time to do it properly, resulting in compromises which could affect the quality of the software [27]. Early testing will provide enough time to identify the absence or inadequacy of any functional requirements. Moreover, test cases obtained from the requirements and shared with the developer's team before the coding phase may reveal new possibilities and help them to estimate the chances of failure in their code [27].
In this context, Koul (PS06) highlights the need to deliver first-time quality while minimizing the impact of testing on the delivery teams. This PS stands out the challenges currently faced in testing such applications. It also acknowledges the need to devise specialized tools and techniques for blockchain-oriented software testing to ensure high standards of quality. In short, the role of software testing is not only to verify the ''rightness'' of the software but rather to discover defects in time for then be rectified. The goal should be to develop smart contracts with higher quality code and as few errors as possible. Exhaustive testing, covering 100% of a software's functionality, is not possible, but it is important to eliminate the highest number of errors as soon as possible. All members of the development team should be involved early in the SDLC. This will, in turn, have a positive impact on the development of the smart contract. If there are testers at the beginning of the development cycle, then errors can be reported at every step and team members may contribute to remedying those errors. By including early testing throughout this process, smart contracts can be implemented with higher reliability, and lower development costs [27].
Another important aspect to consider in connection with automatic smart contract generation is the technique used. Table 12 shows the distribution of PS regarding the different techniques used in the proposals.
In our opinion, another important aspect is an automatic smart contract code generation using a model-based software engineering process. This eliminates the manual effort required in coding from design and therefore accelerates the process while decreasing the possibility of errors in comparison with manual coding from requirements or models. As the table shows, the techniques most proposed by authors are, respectively: (C1) Automatic code generation using domain-specific ontologies and/or semantic rules (4%), (C2) Automatic code generation using model-based software engineering (4%), and (C3) Automatic code generation through templates and other utilities (28%).
Model-based software engineering has been gaining traction in the development of embedded software in industries, especially in safety-critical domains [6]. Automatic code generation with model-based development is an important technology that offers software engineers advanced options for requirements gathering and software deployment and verification. In this context, Syahputra (PS19) discusses the development process of a smart contract platform that aims to generate smart contracts for heterogeneous blockchain technologies. With the modeling approach they are using in their paper, UML, and OCL (Object Constraint Language), they implement the workflow and algorithm in a supply chain demo sample. It is important to understand the potential applications of code generation, but technology alone is not going to improve software quality processes. Developers must also establish an SDLC that leverages code generation technologies and yet adheres to well-established software engineering principles like the reduction of complexity, requirements traceability, efficient configuration management and version control.

C. RQ3. WHAT SCIENTIFIC OR EMPIRICAL VALIDATION METHODS WERE USED IN THE DIFFERENT PROPOSALS?
After analyzing the PS shown in Table 13, it can be seen that only 12% of the papers used scientific validation. More specifically, the table details the distribution of each of the PS with respect to the evaluation methods used to validate proposals. As can be seen, 44% of the PS carry out their evaluation by means of experimental case studies or proofs of concept, and yet the same percentage of studies does not even have a full validation plan, making it difficult to verify their assertions.

VI. CONCLUSION AND OPEN ISSUES
This paper presents the results of an SLR which identifies and analyses the state-of-the-art of scientific publications in the field of software design, coding, testing and SDLC phases, all in the context of blockchain smart contracts. To achieve its objectives, the paper follows Kitchenham's most recent method for carrying out an SLR.
This study, however, presents some limitations. Following Kitchenham's method, we did not consider grey literature, which might contain other significant results. Nor papers from other languages rather the English. After conducting a search of potential studies and having selected a few PS, we identified several types of proposals addressing SDLCs in the target context. Specifically, 25 PS were identified once the search protocol described in this paper had been executed. These studies were also classified according to the phases of the SDLC for which they offer support. After conducting the review, open issues were identified.
Requirements gathering and, above all, software testing is among the most important aspects of smart contract development, but they are almost always overlooked. For example, Marchesi (PS01) proposes a software development process to gather the requirements, analyze, design, coding, testing and deploying blockchain applications. The process is based on several Agile practices. But it makes use of UML-Diagrams to describe the design of the applications. This work moves toward this direction providing full modeling of interactions among traditional software and blockchain environment, including Class diagrams, Sequence diagrams, Smart Contracts diagrams, etc. Other authors as Syahputra (PS05) discusses on the development process of smart contract platform that aims to create a smart contract for heterogeneous blockchain technologies. The author starts the process by creating blueprint design and modelling with UML and OCL.
Whenever we create a smart contract, we must make sure that it works properly. Emphasis should be placed on the functionality, security, and performance of smart contracts, and testing is the only way to reduce the risk. Functional tests and non-functional tests are both necessary for validating and correcting a contract's behaviour before it is released. Smart contract testing is crucial in the blockchain development process, because blockchain, with its immutability, forgives no errors. The only way to fix a bug on an already deployed smart contract is to deploy a new release of that agreement; the old version with the bug will remain on the blockchain (and will stay there forever).
Efficiently testing a smart contract before deploying it will ensure that it works as expected, following the established requirements. In functional testing, all business rules or requirements -including valid/invalid arguments, boundary values, and argument combinations -should be verified in various test cases. In this context, Koul (PS06) highlights the need to deliver first-time quality while minimizing the impact of testing on the development teams. This PS stands out the challenges currently faced in testing such applications. It also acknowledges the need to devise specialized tools and techniques for blockchain-oriented software testing to ensure high standards of quality.
In traditional development software processes, analysis and design information is usually transferred and handled in the form of text-based documents, which are difficult to understand and subject to interpretation bias. Engineers create embedded code from those text-based documents, leading to error-prone processes. There is also little scope to ascertain whether or not functionality is being implemented correctly. In this regard, the main benefit of using modelbased development software is the auto-generation of code, which can eliminate human error and facilitate code reusability. Other important benefits of model-based software engineering are (i) disciplined analysis, design and continuous testing to improve development effectiveness, (ii) the possibility of using verification as a parallel activity taking place throughout the development process, because test cases can be automatically generated from models, and (iii) reusable models which can reduce development times and costs. Given all this, the following conclusions were from this SLR: • The efforts of the scientific community should be aimed at implementing a smart contract Development Life Cycle with clearly defined phases and a common vocabulary for each step.
• In this context, the software testing phase is critical to efficient blockchain development. Smart contract testing requires expert knowledge of scenarios, business, and transaction variables specific to blockchain networks.
• Model-based design and model-based testing should be promoted by the scientific community because modelbased software engineering makes it possible to find errors in design and code. Model-based tools can also improve the verification/validation of smart contract code through the application of testing techniques right from the early stages of the SDLC. Early testing provides enough time to identify the absences and the inadequacies of functional requirements. In addition, test cases composed amid prerequisites and shared with the development team before the coding phase can reveal new possibilities and help developers estimate the chances of failure in their code.
• Automatic smart contract (code) generation in a modelbased software engineering process is vital for effective quality development. It eliminates the manual effort required when coding from design and therefore accelerates the process while decreasing the chance of error in comparison with manual coding from requirements or models.
Having completed this SLR, we plan to explore a new line of potentially very interesting research: the possibilities offered by the model-based software engineering paradigm, which may facilitate mechanisms for validating smart contracts by applying early testing techniques before a contract code is deployed in the blockchain network. The use of this approach has given very satisfactory results in other technologies and its application would appear to be of great interest in blockchain technology.
Such application constitutes our future objective, and we also intend to apply other methods such as the one published by ISD2014 [22] to enrich this study, where not only new articles should appear, but also the existing grey and commercial literature. For example, during the last few months, new relevant papers have appeared as Pankov [49] lists several existing tools for testing and verifying blockchain systems and smart contracts, and also identifies the problem of the lack of an appropriate normative base and standards in this area. Miraz and Ali [47] explores the 6 traditional SDLC models and advocates that there is an urgent need to develop a new standard model(s). This paper concludes that the traditional SDLC models are unsuitable for blockchain-enabled smart contract-based applications. These studies confirm the current need and indicate that we are on the right track in our investigations.
NICOLÁS SÁNCHEZ-GÓMEZ received the degree in computer engineering and the master's degree in engineering and software technology from the University of Seville.
He has developed a large part of its professional career in the technology and process consultancy sector, both in the private and public sectors. Throughout more than 30 years of professional experience, he has gone from implementing ICT solutions to supervising work teams, managing clients, and leading ICT projects. He is currently a member of the Web Engineering and Early Testing Research Group. In recent years, he has been coordinating different projects of the research group, including the Project Management Office of the Ministry of Culture (Andalusian Regional Government). He currently has a broad knowledge of the functions and processes that make up the activity environment of the sectors in which he has participated and has completed his studies in computer engineering. He has knowledge and skills of people management, ICT project management, customer management, and practical application of computer engineering methodologies and techniques, in addition to obtaining the Prince2 Foundation Certified, the ISTQB Certified Tester, Foundation Level and the PMP Certified. From 2001 to 2009, he developed his professional activity as the Manager of the company Everis, Spain, being responsible for different accounts in public and private sectors. From 1990 to 2001, he has worked for the company Coritel (Accenture Group), where he also carried out management and project management activities.
JESUS TORRES-VALDERRAMA received the M.Sc. and Ph.D. degrees in computer systems in 1997.
He has been working with the Department of Computer Languages and Systems, Seville's University, since 1991, where he is currently a Senior Lecturer. He was the Dean of the School of Computer Engineering, Seville's University, from 2006 to 2014, where he has been the Manager of the Foundation for Research and Development of Information Technology in Andalusia, since 2016. His main research interests include requirements engineering, web-based systems development, user interfaces, usability, and early software testing. In these areas, he has directed several Ph.D. theses and published numerous papers in journals and conferences. He has managed and participated in a high number of projects related to his areas of research. J. A. GARCÍA-GARCÍA received the Ph.D. degree in computer science from the University of Seville, Spain, in 2015. He is currently a Lecturer and a Researcher with the Department of Computing Languages and Systems, University of Seville. Since 2008, he has participated in Research and Development projects as a Researcher in the Web Engineering and Early Testing Group (IWT2). His current research interests include business process management, business process modeling, modeldriven engineering, and quality assurance. He is responsible for the BPM area and responsible for security in IWT2. He also participates as a member of committee in several international conferences and journals. JAVIER J. GUTIÉRREZ received the Ph.D. degree in computer science from the University of Seville, Spain, in 2011.
Since 2004, he has been a Professor with the Department of Computer Languages and Systems, University of Seville, where he has been a collaborating Professor, since 2006. He is currently a member of the Web Engineering and Early Testing Research Group. Among his most notable research results, it is worth mentioning his transfer to the business world. With the development of the concept of early testing and its integration with the NDT methodology also developed within the research group, he has managed to develop a set of methodological solutions for the development and quality assurance that has been widely used in the Andalusian and national business network or even by international companies. This can be measured not only in the transfer projects, but also in the number of publications with companies and in the tools registered.
M. J. ESCALONA received the Ph.D. degree (Hons.) in computer engineering from the University of Seville, in 2004. She is currently a Full Professor with the Department of Computer Languages and Systems, University of Seville. She is also the Director of the Web Engineering and Early Testing Research Group. Her main research interests include software engineering, specifically to software requirements, software early quality assurance, and early software testing. In these areas, she has directed several Ph.D. theses and published numerous papers in journals and conferences. She is also a member of the editorial board of JWE and IEEE IT Professional and she collaborates as a regular reviewer with several conferences and journals. She has managed and participated in a high number of projects related to her areas of research. VOLUME 8, 2020