## 3 Methodology and Implementation
### Functions  
In this section, we explain the decision making behind the construction of our smart contracts and try to describe functions used in these contracts and their jobs. We have a separate function for each action that can be performed during the lifecycle of the supply chain. In this project's codebase, we implement common programming best practices such as DRY (don't repeat yourself), which represents reusing code blocks defined at functions as much as possible without writing new code blocks. ACID (atomicity consistency isolation and durability) represents transactions that are happening at the chain and have a binary status. They are either performed or not performed, and there will be no unfinished transactions at any stage of the workflow; each transaction is independent of the other at the flow of the system, so there will be no race condition or contradiction between their states; when a transaction is completed, its state will be recorded to the ledger, and it is not going to be corrupted by other states, or its states will not be lost. But, also, due to not creating any security vulnerabilities and exploitable logical fallacies in the code, we tried to isolate functions to their specific roles and make their logic as non-complex as possible. To increase the manageability of our code base, we utilized the import feature of the Solidity language. The important feature of Solidity, which also exists in most modern programming languages, is the implementation of modular programming. The idea behind modular programming is to break the codebase into reusable components and then expose these components to other files or a handler file to manage their relationship. Modular programming helps developers organize codebase by grouping variables and functions that make sense to be together. For example, functions are variables that define or manipulate an entity or variables or functions that represent similar functions. By utilizing Solidity imports, we can create reusable pieces that other files can import, make it easier to understand and digest the project's codebase, focus on individual parts, and debug a part of the codebase. We have four modules in our main contract called Structs.sol, Parties.sol, Products.sol, and SupplyChain.sol. In Types.sol, we define the names and data types of the group of variables. These data models are mentioned above as structs. In Products.sol, operations that involve products directly are handled. This contract inherits Struct.sol for product structure definitions and emits a product if it is newly added to the chain, or the ownership of a product is changed; this contract utilizes the following functions, and the functional diagram of Products.sol and its interactions with other contracts can be seen in Figure 4, while the UML diagram for the contract can be seen in Figure 5.  
Public functions:  
1. getPartyProductsInternal(): This function returns all the products registered in the inventory of the caller party; this function returns data in the product struct. 2. getSpecificProduct(): This function returns the details of the specified product and its lifecycle and timeline, such as transferred from whom to whom and when. This function takes productid as a parameter and returns productHistory. \begin{table}
\begin{tabular}{l l} \hline \hline
**Data Type** & **Variable Name** \\ \hline PartyRole & role \\ \hline address & id\_ \\ \hline string & name \\ \hline string & email \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Party details struct. setForReturn(): This function flags products that will be entered to return flow, takes productid as an argument, and sets product structs isReturning field to true for activating return flow. 4. addProductInternal(): This function adds a new product to the ledger, taking input data in the product struct as argument and currentTime as epoch timestamp. 5. transfer(): This function transfers the ownership of the product. It takes sender and receiver addresses, current time, and productid as parameters.