This article was published as a part of the Data Science Blogathon.
4+1 architectural views represent the overall architecture of the software incentive system. It describes the system from different viewpoints like developers, engineers, project managers or stakeholders. These 4 views are logical, process, development and physical. The +1 view represents the scenarios view, which is the model’s centre.
This tutorial will discuss the 4+1 architectural views of an Electronic Voting System design using Blockchain for different use cases.
These are the two use cases:
1. User Authentication
2. Voting Procedure
But before starting this tutorial, let us discuss the components of 4+1 architectural views and blockchain networks.
Logical View: The logical view is concerned with the system’s functionality to end-users.
Development View: The process perspective is concerned with the dynamic features of the system, describes the system processes and how they communicate, and focuses on the system’s run-time behaviour. Concurrency, distribution, integrator, performance, scalability, and other issues are addressed from the process perspective.
Process View: The development view depicts a system from a programmer’s standpoint and is concerned with software management. It is often referred to as the implementation perspective.
Physical View: The physical view (also known as the deployment view) illustrates the system from the perspective of a system engineer. It is concerned with the physical layer structure of software components and the physical connections between these components.
Scenario View: A limited selection of use cases, or scenarios, are used to explain the architecture description, which becomes the fifth view. The scenarios represent interaction sequences between objects and processes. They are used to identify architectural aspects and depict and assess architectural designs. They also serve as a starting point for architecture prototype testing. It is often referred to as the use case view.
It is only a brief explanation, but you can read more about them here.
It is a chain of blocks that stores information or a digital ledger of transactions maintained by a network of computers. The pieces of information are stored so that it is almost impossible to hack or change. In this technology, two persons can directly contact or commit a transaction with each other without any third party interference like bank or government entities. You can refer to that paper to get more information about the working of the Blockchain Network.
This use case discusses how users can securely log in to the voting portal by verifying their login credentials. We first take the user’s login credentials as input and validate the user. For validation, we can check the user details in our database. If the details entered by the user are correct, then we authenticate the user. Otherwise, we throw an error message.
The user gets a user interface in the form of a web application. In this, the users must authenticate themselves using their login credentials. Then these credentials are verified in the government’s database. If the credentials are correct, we authenticate the user. Otherwise, we will send an error to the front end.
In the process view, we can first verify if the credentials are correct or not. After checking the credentials, we verify if the user has already given the vote or not. If the user is giving the vote for the first time, we authorize the user to cast his vote.
As previously said, this application utilizes a variety of technologies. A single team will not be able to complete the mission. As a result, we may divide the groups depending on employee competence and create separate groups that include-
All the teams will work separately, so we need a version control system and a testing mechanism to test the other’s team progress. We can use CI/CD (Continuous Integration and Delivery) and Git/GitHub.
In the physical deployment view, we don’t have any intermediary nodes for this program. All of the operations are carried out entirely within the client and server. We may use any web browser on the client-side, such as Google Chrome, Firefox, Internet Explorer, etc. We have a MySQL database on the server-side (an open-source relational database management system). As a web server, Apache is utilized. On the other hand, Apache Server is a free and open-source web server that distributes online content. It’s known as Apache, and Apache Software Foundation created it.
The use case of this Authentication scenario is to verify the user and to check whether they are eligible for voting or not. If the information checks have passed, then convey this verification to the voting layer.
This use case discusses how users can cast their votes and how their votes are stored securely in the blockchain network.
The various modules involved in this use case are as follows:
It explains the complete procedure for voting from a distance. After the user’s authentication, we again verify the user by their Voter ID Card, like two-factor authentication. Then after the complete verification of the user, we generate a ballot and send this to the user. Then, the user casts their vote for the preferred candidates. Then that CandidateID is forwarded to the backend. After that, a node is added to the blockchain network for that Candidate. After that, the user gets a response that their vote has been successfully submitted.
As previously said, this application utilizes a variety of technologies. A single team will not be able to complete the mission. As a result, we may divide the groups depending on employee competence and create separate groups that include-
All the teams will work separately, so we need a version control system and a testing mechanism to test the other’s team progress. We can use CI/CD (Continuous Integration and Delivery) and Git/GitHub.
The client’s functionality is appropriately implemented with the necessary security measures once a specific time has passed. Now is the time for site developers and security experts to step in. Security specialists will conduct rigorous vulnerability assessments, such as Denial of Service attacks, before distributing the software to select beta testers. The program is made available during elections following these adjustments, with additional updates if a security or accessibility issue arises.
We have deployed all three things separately but interconnected with each other. E.g., the client layer consists of a React app, with various pages in it, like pages for displaying the candidates, pages for giving some input for verification, etc. And all these pages are connected to the backend server through routes. And the backend can send and receive the data from the client using GET and POST methods, respectively. We can use Apache server and MySQL database to serve the backend. And the final vote is committed in the blockchain network in a new node.
We can now discuss some key takeaways of this tutorial:
1. We have discussed the 4+1 architectural views and got a basic understanding of them.
2. After that, we have also discussed the blockchain network.
3. Then, we have taken a scenario of an Electronic Voting System Using Blockchain. In this, we have discussed two scenarios. The first one is the User Authentication, and the second one is Voting Procedure.
In User Authentication, we have discussed how users can securely log in to the voting portal by verifying their login credentials.
In Voting Procedure, we have discussed how a user can cast their vote after identification and how that vote is added to the blockchain network.
I hope you have enjoyed the article. It is all for today. If you have any suggestions or comments, please feel free to ask. Also, connect with me on LinkedIn. I will be happy to get associated with you.
The media shown in this article is not owned by Analytics Vidhya and is used at the Author’s discretion.