We'll start this module with a discussion of a method for developing smart contracts. Begin with a problem statement, analyze the problem to come up with a basic design, its state variables and functions, recall our principle from the last lesson, design first, represent the design using a class diagram. Based on the problem statement, define the visibility for the state variables and functions. Based on the requirements, define the access modifiers for the functions, define validation for input variables of the functions, define conditions that must hold true on completion of critical operations within functions, declaratively express the conditions that were discovered in steps four to seven using access modifiers, visibility modifiers require an assert classes. We will use solidity language and remix IDE to develop and test a smart contracts according to this method. Upon completion of this module, you will be able to apply the concepts learned in the last two modules to write a smart contract, analyze a problem statement to design and implement a smart contract, program smart contracts using solidity language and remix IDE. Incrementally, add features to the ballot smart contract code. Let's review the ballot problem. We'll use the ballot problem that is defined and solidity documentation. This problem will be used as a base problem on which we'll develop our solution. Recall that we discussed the ballot problem in the last module. We have chosen a familiar problem so that we can focus on designing and implementing the smart contract, rather than spending time on explaining the problem that is unfamiliar to you. Moreover, the concepts and the function used in the solution can be easily adapted to any other problem. Here is a formal problem statement for ballot. Problem description, version one: An organization invites proposals for a project, a chairperson organizes this process. The number of proposals is specified at the time of creation of the smart contract. The chairperson registers all the voters. Voters including the chairperson vote on the proposal. To make things interesting, we've given a weight of two for the chairperson's vote and a rate of one for the regular voter. The winning proposal is determined and announced to the world. We'll exclude the delegation of voting function that is present in the current valid smart contract in solidity documentation, we will not consider this function. Let's perform an analysis to determine the state variables. Let us now consider the data or state variables needed for the program. Details of a proposal and the set of proposals will keep track of only the proposal number and the vote for each proposal. Auto details, the vantage of the vote, one for the regular voter, two for the chairperson. Voted or not, and to what proposal number they voted. Keep track of the addresses of the chairperson and other voters, address of a voter will be used as a key to map to the details of the voter. Major differences from the traditional object oriented analysis is in the smart contract specific data types, such as address and the message center. Let us now discuss the functions. The chairperson is the creator of the smart contract. He or she will be the only person who can register the voters. Here is a list of functions. Constructor is a function that is called to create the smart contract. In solidity, unlike a regular object oriented language, there can be only one constructor. Also, the constructor has the same name as a contract. The sender of the message invoking the constructor is the chairperson. The second function is the register function to register the voter. Only the chairperson can register a voter. The sender of the message for registration has to be the chairperson. The third function is the vote function. Voters including the chairperson. can vote for a proposal. The final function determines the winning proposal and that can be called by client application. Let's look at remix to explain the ballot version one. Let's recap what we did in remix ballot version one. Note that the visibility modifiers for the state variables and the functions represent the details of a single voter using a struct. Single proposal also using a struct possibly allowing for future expansion. A mapping of voters, mapping voter address, externally-owned accounts to voter details. An array of proposals and a chairperson address are defined. Also, review all the function. Try it for yourself.
