## 3 System Model Definition
### Use Case Analysis of dNAS  
Given the defined system roles of dNAS, a use case analysis based on these system roles was performed, as demonstrated in Appendix B.1. dNAS is developed basing on a concept of _enterprise consortium_, as depicted in Figure 2, consisting of multiple registered nodes of the winemaker role, supply chain participant role and the consortium administrator, introduced to dNAS, unlike the legacy NAS on which the anti-counterfeiting system and mechanism are based _solely on winemakers_. Getting started with the blockchain system, as depicted in Figure 3, there are use cases only accessible to the consortium administrator, such as the management of smart contracts, which are decentralized software design patterns and methods with access shared across different blockchain nodes running on the network, based on the authorization mechanism defined. The smart contract will need to be developed, deployed or even upgraded to the blockchain network if necessary. The consensus level is indeed the number of votes from consortium members, required for a consensus to be reached to confirm that a registered  
Figure 2: Enterprise Consortium of dNAS. node will be added to or removed from the consortium. The consensus level can only be set by the consortium administrator if necessary, especially for a situation where the size of the consortium has changed, drastically affecting the degree of decentralization and fraction needed to reach a consensus. Other consortium members are able to propose the addition of a new node to, or removal an existing node from, the consortium, based on the public address of their designated blockchain node, which is stored in an on-chain registry. Every consortium member would be assigned with a blockchain node, and are therefore eligible to send and validate transactions of the blockchain network to help reach a consensus and state broadcasting. Regarding the use cases of the database-operating web application, as listed in Figure 4, any registered node of the winemaker role and supply chain participant role can obtain access to the functionalities provided by the web application to manage the inventory of wine products they hold, the list of collaborative supply-chain participants, and projects involving different wine products with different supply chain participants. A wine record, which could be created _only_ by registered nodes of the winemaker role, consists of four constituent data categories, such as wine pedigree data, transaction data, supply chain data and unsuccessful validation data. Likewise, only registered nodes of the winemaker role could perform operations such as create, update and delete in the web application, while registered supply-chain participant nodes and registered wine-consumer nodes could only update the respective transaction data and supply chain data via _ScanWINE_ mobile application at the point of  
Figure 4: Use Cases of Database Web Application. Figure 3: Use Cases of dNAS Blockchain System. wine acceptance or purchase, following a series of data validation steps, when scanning the NFC tags on wine products. Like the legacy NAS, only registered nodes of the winemaker role could access the NFC-enabled tag-writing mobile application-_TagWINE_, with use cases as listed in Figure 5, and perform its functionalities, such as viewing wine records on the mobile application, recording required data fields of the wine record in NFC tags, and checking the history of the previous writing activities for those tags on the wine products they produced. While, for the NFC-based tag-reading mobile application-_ScanWINE_, with use cases as listed in Figure 6, any registered nodes, including those of the wine-consumer role, is accessible to the functionalities, such as scanning NFC tags, which will also trigger the process of validating the provenance and authenticity of wine products by analysing the data stored in NFC tags, a unique identifier of scanned NFC tags and the identity of registered nodes.