# Easing DApp Interaction for Non-Blockchain Users from a Conceptual Modelling Approach
## 4 From DApp to App: A UML Modeling Analysis  
To identify how to ease the interaction with DApp's, we opted for a Model Driven Development approach. Therefore, aiming at answering RQ1, we will identify the relationship among DApp's and Apps elements by modeling an Ethereum-based blockchain architecture and a common App. Figure 1 shows such modeling. Hence, at the top of the figure we can see the UML class architecture of a DApp interacting with a blockchain, as suggested in [16]. Moreover, at the bottom it can be seen the equivalent App architecture where its classes have been related to each blockchain element they will have to access in order to expose the blockchain functionality to a non-expert user in an App. For the sake of model comprehension, the relationship among DApp and App elements will be presented in the following through the model entities:  
* User: The proposed App model features a collection of users (UsersDB). In this sense, the user entity will be associated with the blockchain address for the user to be able to interact with the blockchain without needing to be aware of its address' public and private keys. Further, the user entity will also be associated to the blockchain token's balances. Therefore, it will represent the number of tokens the user will have. Note that for the sake of the model understandability, we will consider only ERC20 (fungible) tokens [28]. Nevertheless, the model could be easily adapted to working with ERC721 [29] (non-fungible) tokens. * Login: Since we are modeling an App, it is common to have a login functionality. Therefore, our model will have an action called login. Hence, when a user logs in with a correct email/password combination, the wallet containing its Address will be unlocked, thus enabling such user to make transactions towards the blockchain. * Recovery: One of the issues of blockchain is that if the user loses the private key of an address, he/she will never be able to access it since blockchain does not provide any private key recovery mechanism. It is worth noting that users are used for counting with password recovery systems in almost every App. Therefore, this functionality will be enclosed within the Recovery entity. Therefore, if requested, this entity can access the UserDB to provide password restoration mechanisms. Note that what will be recovered will be the User's password, not the private key. That is because, to facilitate the interaction, we would provide a non-custodial system, where the user is not directly responsible for his/her private key or wallet, being those custodied by the App database. It is worth noting that a password recovery procedure would imply the creation of a new password. Therefore, this entity will make use of the WalletGateway entity. Such an entity will communicate directly with de node (not using Web3 [30] since it cannot re-encrypt wallets, but accessing Geth directly [31]) and re-encrypt the user's wallet with the new password. * PasswordChange: Another issue of blockchain is that the user cannot change his/her private key. Indeed, getting a new private key would imply also getting a new public address. Then, the user would have to move his/her assets to the new address, task that would require gas to be performed. To overcome this issue, we propose the _PasswordRecovery_ entity. Since the authentication is made by using an email/password combination, we will offer the possibility of changing the passwords. It is done though this entity that, in turn, will make use of WalletGateway. Therefore, the password will be changed by re-encrypting the user's wallet by using the new password. * Movement: This entity will represent the transfer of tokens among users in a straightforward manner. In that sense, if a user wanted to send funds to a different App user, the only required data would be the number of tokens to be transferred and the recipient's email. Therefore, the recipient's address will never be required, thus making it more difficult to choose the wrong recipient when making token transferences.