SRS
The purpose of this project is to build a source code analyzer. The application aims to provide tooling allowing the detection of bottlenecks in code and execution sequences, allowing rapid improvement and development.
Currently in order to generate usage information, developers have to use an amalgamation of language specific tools. These varied tools can be replaced by our tool that takes the load of tooling the code off the programmer and provides easy to access data about the program that may otherwise have required effort on the part of the programmer. This involves uploading jar files onto the platform which is automatically recompiled with the tooling and linked with the backend and visualization tools.
Here we list some groups of people who may require this document or come across this document in some shape or form. This section does not list any technical details.
Here we list some groups of people who may require this document or come across this document in some shape or form. This section does not list any technical details.
| ID | Stakeholder | Description |
|---|---|---|
| S-1 | Course Instructor and Teaching Assistances | Provide tasks and necessary deadlines to U-2 and U-3 and confirm whether satisfactory progress is being made in the correct direction in application development. |
| S-2 | Development Team | Develop fully functioning application with afore-mentioned specifications from U-1 and input from U-4. Ensure integration between different teams and components developed. |
| S-3 | Testing and Maintenance Team | Test the application and ensure proper functioning under boundary conditions and identify and rectify possible vulnerabilities. Update and monitor possible breaking changes to dependencies |
| S-4 | End User | Use the platform for tooling and monitoring purposes |
The application aims to improve developer experience while building applications by tracking various facets of the application, such as exceptions, function call frequencies, function execution paths and function execution times. The application provides a visual representation of data that allows the developer to identify possible bottlenecks and points of disruption in the program.
The product that is developed will reduce the time that is spent during Java program development in analysing and optimising the program by enabling rapid identification of bottlenecks. The visibility of favoured paths through the application can also enable developers to quickly figure out possible flaws in program logic causing repetitive processing. The exception statistics will allow developers to quickly figure out buggy pieces of code and fix them before going into production.
The primary functions that the application provides can be described as follows
-
Bytecode Weaving - The application takes a jar file and instruments it with the aspect code. The woven code contains the necessary ability to monitor various aspects of the code that the user wishes to monitor and is integrated with the rest of the monitoring suite.
-
Data Collection - The code modifications collect data regarding the woven application and send the information to the server, which acts as a central repository. This is done while allowing different users to function separately and monitor and access only data that belongs to their own applications.
-
Data Visualization - The collected data is shown in an easily comprehensible manner to the user so that complex runtime data can be easily understood and used to make decisions regarding application design and performance.
The operating environment for the application is listed below:
-
Frameworks - External libraries and dependencies include:
-
AspectJ: ajc, aspectjrt, aspectjtools, aspectjweaver have been used to generate weaved bytecode.
-
Gson: Library to serialize the generated data so that it can be sent to the backend
-
ExpressJS: To create the REST endpoint, which is used by the application to push data to the database and fetch data to the front end.
-
ReactJS: To design the analytics dashboard.
-
Operating System - All code has been written and tested on the Windows Operating System
-
Database - Cloud Firestore (non-relational database) has been used to store the generated data
-
Hardware Platform - Any hardware with the capability to host a ExpressJS server that can handle 2880 requests per day per user. Varies based on the expected audience size
The AspectJ compiler will be used to perform the weaving of the pre-written aspects with the provided JAR file. The AspectJ compiler is capable of instrumenting the code by itself and also provides functionality to call user defined functions at particular “Join Points” in the code. We have leveraged this to gain insights on the execution of the program and send this data to our backend server to store and analyze.
We will be using Firebase as a NoSQL database. A NoSQL database would be suitable for this purpose as data of various structures, such as graph edge structures and function call orders, have to be handled by the database. A cloud-based database also facilitates rapid development, as well-established APIs are available for CRUD operations. It would also be easier to switch in the future to other NoSQL providers in the future if required, as there are no language-specific structures weighing down the application. Deployment on physical servers is also feasible if ever required.
We will be using ReactJS along with Tailwind to develop the front-end application. The component-based facet of React allows us to develop reusable code that can be used throughout the application. We will also use the visualization tools provided by React Google Charts to create graphs and charts to better analyze the data generated by the woven applications. Authentication and login have also been implemented using Firebase.
We will be using NodeJS along with ExpressJS to develop the back-end application. applications: Express.js provides a set of features that make it easy to build web applications using Node.js. It includes a routing system for handling HTTP requests, middleware for handling requests and responses, and templating engines for rendering HTML views. They are used for building RESTful APIs in real-time applications. Express.js provides a set of features that make it easy to create APIs, including support for handling different HTTP methods (GET, POST, PUT, DELETE).
-
Web Interface - A web browser is necessary for end users to upload JAR files and perform the weaving operations and also view data that has been collected from the application. It is a completely online tool with no offline functionality.
-
Client Server System - A client server system has been adopted so as to not put the load of dependencies on the client side system. An internet connection is crucial for proper functioning. Client server communication is essential for the application as that is the sole means to collect and visualize data on the browser.
-
Database - An easily accessible online database is necessary for the application. An always on database is necessary to monitor and receive information from clients at all times. The database must support concurrent read-write requests from multiple users.
-
Availability - The system must be always on and listening. Mechanisms should be implemented on the client side application to facilitate short term local storage of information in case of server outages. Care must be taken to not hog network bandwidth causing disruptions in functioning of applications that may be running on the client side system during data recovery after outages.
-
Performance - Package sizes of bundled web application must be minimal so as to allow quick loading and visualization and not hinder the user experience. Database must be distributed and always on to minimize client-side latency in pushing application data and latency between running the app and viewing the data on the dashboard.
-
Security - Applications uploaded by one user should not be available for access by another user. Users should only be allowed to access information from the server once they are logged in. Users should only be able to view data collected from applications that they have uploaded and not from the applications of other users.
-
Scalability - Databases used must be such that they can be easily commissioned if greater load is received that expected. The application must be designed in such a way that it can be easily deployed on multiple servers to handle greater load. Minimal dependencies must be used so as to not hinder the ability to deploy on different servers due to package sizes.
-
Maintainability - Aspect weaving system must be easily extensible so as to add more features, if required, in the future. Integration between various components such as the SPA, API and database must be such that modifications can be made in the tech stack if need is felt in the future. Test cases must be use based and not structure based to minimize need to rewrite tests due to changes in code.
-
Reliability - The aspects must communicate with the server without the ability of users to inject malicious content into them. The application must be able to handle multiple requests from multiple users at the same time without crashing, losing data or sending data to the wrong user.
-
Robustness - The aspects must be able to handle exceptions and errors that may occur during runtime. The web browser should not contain any vulnerabilities that may allow malicious users to access data that does not belong to them. Sections of the application should not fail to function due to errors the aspect.
The database will not contain any sensitive information and will be used only to store the data generated by the woven applications. The database will be used to store the following information:
-
Application Name - The name of the application that has been woven
-
Function Name - The name of the function that has been sent by the aspect
-
Execution Time - The time taken by the function to execute
-
Execution Count - The number of times the function has been executed
-
Path Counters - The number of times each path of functions in the application has been executed
-
Exception Counters - The number of times each exception has been thrown by various functions in the application
Brief description |
Uploading files to the server and subsequent weaving of the files on the server |
Target user |
U-2 |
Business trigger |
Pressing the upload jar button on the app |
Preconditions |
The user has logged in |
|
Basic Flow:
| ||
|
Assumptions:
| ||
Line |
System Actor Action |
System Response |
1. |
User logs into the system |
Web browser sends an authentication request to the backend and receives a postive response |
2. |
User uploads the file |
Browser sends the file to the firebase backend and AJC is used to weave the available aspects |
Post condition |
User is shown a message if the weaving was successful |
|
Alternate Flow : 1) The external APIs do not function properly or there is no internet connection | |
File upload is unsuccessful and the file is not sent to the server. The user has to reupload the file as and when they get internet connectivity again or the API starts functioning properly again. | |
The use case terminates | |
Post condition: |
User is notified that the weaving was not successful / File upload was not successful |
Brief description |
Woven client application sends data to the API which is stored in the database |
Target user |
U-2 |
Business trigger |
User runs the woven application |
Preconditions |
The application has been downloaded to the server and it has performed the weaving |
|
Basic Flow:
| ||
|
Assumptions:
| ||
Line |
System Actor Action |
System Response |
1. |
User starts the woven application |
Application starts collecting data about the application locally in a class that the aspect is going to include along with the woven application |
2. |
User keeps the application running |
Application sends a request to the API periodically containing data that was collected from the previous period until current time and clears out the local memory |
Post condition |
None |
|
Alternate Flow : 1) The external APIs do not function properly or there is no internet connection | |
If ever there is a problem with connecting to the server, the aspect code waits to send until an active connection is detected and data collection continues normally. The local store grows in size until the connectivity is regained at which point normal functioning will resume | |
The use case terminates | |
Post condition: |
None |
Brief description |
Web application fetches data from the database through the backend API and displays it on the React SPA |
Target user |
U-2 |
Business trigger |
User selects an application from the dashboard to view analytics |
Preconditions |
The application has been woven and the woven application has run for sufficient time to facilitate collection of data |
|
Basic Flow:
| ||
|
Assumptions:
| ||
Line |
System Actor Action |
System Response |
1. |
User logs into the web application |
Browser fetches data regarding all the applications that the user has uploaded apriori and shows them on the dashboard |
2. |
User selects a particular application |
Browser fetches data from the API regarding various functions in the applications and application specific data such as call histories |
Post condition |
Graphical representation of application specific data is displayed to the user |
|
Alternate Flow : 1) The external APIs do not function properly or there is no internet connection | |
In case of a problem with the external APIs the web application not display anything. Whenever the API is restored a reload will trigger the call that will fetch the corresponding data from the database | |
The use case terminates | |
Post condition: |
Graphical data is not displayed to the user |
Every user who interacts with the system will have the same user interface. The single central interface for interacting with the application will be the web application. This will be a highly visual interface involving a minimal, easy to navigate UI. The interface would be primarily useful to users to view the analytics of their applications. The interface will be designed to be intuitive and easy to use. The interface will be designed to be responsive and work on all devices. The interface will be designed to be compatible with all major browsers.
The interface will primarily be required to display information about the applications that the user has previously uploaded, the functions in those applications and various data collected about those applications. The interface will also be required to display the analytics of the applications in the form of graphs and charts. The primary objective of the interface is to allow users to grasp information about their programs quickly without having to go through the inconvenience of manually sifting through the textual data that is collected.
There are 4 primary components in the application which are the web application, an Express server, a non-relational database and the aspect files. These require the following components to interact with each other:
-
The web application will be built using ReactJS and will communicate with the Express server through an API.
-
The Express server will be built using NodeJS and will communicate with the database through the Firebase SDK and will be controlling the AspectJ compiler during the bytecode weaving process.
-
The AJC files will be written in AspectJ and will be compiled using the AspectJ compiler which is on our hosted server.
The communication interfaces are primarily between the React SPA - Express server and the Express server - Firebase server. The communication between the React SPA and the Express server will be through HTTP AJAX requests. The communication between the Express server and the Firebase server will be through the Firebase SDK that uses HTTPS for communication.
-
The users have a beginner level grasp of English to be able to understand the interface.
-
The users understand how to run a compiled JAR file on their server with the requisite parameters.
-
The users have a reasonably fast internet connection to be able to upload the JAR files to the server.
- The only dependency of the application is the Firebase server. The application will be hosted on the Firebase server and will use the Firebase SDK to communicate with the database. The Firebase server will also be used to compile the AJC files.
The major limitations are listed below:
-
The application will only be able to analyze Java applications.
-
The application has to constantly communicate with the API to exchange data. There is no feature to do the opposite side communication which would substantially minimize traffic.
-
There is no option to select the files to be woven. The application will weave all the files in the application.
-
True measure of time is difficult to accomplish due to the overhead of data collection. API calls occur on a different thread however.
Given below is a general description of the various users who would be involved with the application
| ID | User Class | Description |
|---|---|---|
| U-1 | Developers, Maintainers | This would includes people from S-2, S-3 and possibly S-1 who would be involved in actively making changes to the application, maintenance etc. These users would have access to non graphical components such as the database and the Express server |
| U-2 | External Java Developers | These users are from the stakeholder class S-4 who would be uploading JAR files, instrumenting them and using the services of the web application to monitor their application. They will only have access to the web application component |
Documentation of the entire codebase would have to be provided to users of the U-1 class so that they can actively maintain the application. This includes the Aspect files, the Express server and the React application. Suitable test files must also be given so as to ensure maintenance of prior functionality.
Users of the U-2 class would only have to be given documentation as to how to use the web application and how to run the instrumented Java application. This would be provided in the form of a README.
| User Type | Actions |
|---|---|
| U-1 | General Maintenance Security patches on dependency updates Updating Aspect files on new releases |
| U-2 | Uploading JAR files Viewing analytics about woven applications Downloading and running JAR files |
-
Subham Subhasis Sahoo - 2020CSB1317
-
Parth Jain - 2020CSB1106
-
Aman Pankaj Adatia - 2020CSB1154
-
Abhijith T R - 2020CSB1062
-
Pratham Kundan - 2020CSB1114