High Level Design
This high-level design document aims to document the design decisions to be made to develop the application per the requirements specified in the Software Requirements Specifications. This document will also serve as a guide for the developers to implement the application and provide answers to high-level questions such as technology stacks and architecture of the application
The high-level design document will cover the following aspects of the application:
- Database Architecture
- Application Architecture
- Flow of the application and data
- Technology Stack
- Non-functional Requirements
- API (Application Programming Interface) - An intermediary allowing two applications to communicate
- JSON (JavaScript Object Notation) - A lightweight data-interchange format
- JavaScript - A programming language that is used for both client-side and server-side development
- React - A JavaScript library for building user interfaces on the web
- Node.js - A runtime that executes JavaScript code outside of a web browser
- Express - A web application framework for Node.js that is used to build web applications and APIs
- AspectJ - An extension that extends Java by allowing injection of code at specified join points without modifying the source files
- AJC - Compiler for the AspectJ extension to Java
- Firebase - A mobile and web application development platform that provides authentication, real-time database, hosting, and storage services.
- REST (Representational State Transfer) - An architectural style for designing networked applications
The rest of the document will present the following:
- Provide an overview of various design decisions made for the application
- Explain the flow of the application and data
- Explain the rationale behind the technology stack chosen
- Describe the non-functional capabilities of the application
- Elaborate on the software architecture of the application and various interfaces
The door to door garbage collection application to be developed, as a part of course project in software engineering, will considerably improve the current garbage collection process by reducing the disturbance and time taken. The code will be maintained by the development and testing team who are also responsible for developing the application. In order to retrieve the necessary data, the application will utilize existing APIs, thereby creating an external dependency.
- Firebase - The specific tools used in firebase are firestore and authentication. Firestore is used to store application data and authentication is used to authenticate users.
- Express - This tool has been used to develop the backend of the application which includes the APIs and database interactions.
- React - This tool has been used to develop the frontend of the application.
- Lucidchart - This tool has been used to create the flowcharts and diagrams.
- GitHub - This tool has been used to maintain the codebase and track changes.
The significant limitations listed in the SRS are:
- 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 challenging to accomplish due to data collection overhead. API calls occur on a different thread, however.
It is assumed that the design of such a document will allow the detection of flaws early on in the software development life cycle. It is assumed that the design that is to be described in this document is feasible and implementable. There is also an assumption that none of the work or hardware will be stolen or sabotaged.
There are 4 primary components in the application: the user interface (web application), the Express backend, the database and the woven application. Various design requirements have been listed in the SRS. The details of the screenshots are given below:
- Landing Page - This is the landing page of the application. Provides user with the options of logging in and signing up.
- Info Page - This is the information page of the application. Provides user with the information about the application.
- Execution Flow
- Dashboard - This is the dashboard of the application. Provides user with the information about the applications that he has uploaded.
- Control Flow Diagram - Allows user to view the call graph of the application which shows which function has called which function
- Execution Time Diagram - Shows the average execution time and number of times each function has been called
- Function Diagram - Shows the number of times each function has been called and the average time taken to execute each function and the exceptions thrown by each function
The user interface of the application available to the end users will be a website that is built using React. The website will require authentication through Firebase in order to be set up. Once this is done, various options such as application selection and application upload will be presented to the user. The component based architecture of React will allow for easy development of the web application as opposed to vanilla JavaScript. The choice of React over other frontend frameworks has to do with the fact that it is the most popular frontend framework and hence has the most support and documentation.
The Express server will only entertain requests from the web application for the logged-in user and hence only applications that he has uploaded. The server will be responsible for authenticating the user and providing the necessary data to the web application. The server will receive data from the aspect and store it in the database. The server will also be responsible for retrieving data from the database and sending it to the web application. Express is chosen as it simplifies the development of web applications and provides a robust set of features for web and mobile applications. It also allows a single language to be used for both the frontend and backend of the application.
The database that is used is Firebase. Firebase itself provides an SDK that can be used to access the database and store requisite information. The database will be used to store the data collected by the aspect and the data collected by the application. The database will also be used to store information about the applications uploaded by the user, such as their application ID. A NoSQL database is preferable for this application as storing and retrieving data from it is easier. The database will store information such as function execution flow which is highly dynamic and not easily stored in a relational database.
Some of the collections that will be used in the database are:
- Users - This collection will store information about the users of the application. This will include the user ID, email, name and the applications that the user has uploaded.
- Profiler - This contains the caller callee relationship between the functions in the application. This will be used to generate the call graph. Some of the fields in the profiler are call_id, depth, start_time, end_time and parent.
- Function Statistics - This contains information about specific functions such as the number of times they have been executed and the total time taken to execute them. Some of the fields in the function statistics are function_name, executionCount and timeExecuted.
There is a single user interface available for all clients to interact with the application. 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. Development is to be done in React, the rational of which has been explained in section 3.3.1. Screenshots have been provided to give a better idea of the user interface.
The primary purpose of the application is to generate a report that will contain the analytics of the application. The report will be a component of the user interface itself. The report will represent graphically the information mentioned in section 3.4. Other information regarding number of requests, logins and client-side information can be collected from Firebase.
Should errors be encountered, an explanation will be displayed as to what went wrong. The user will be able to retry the operation. The user will also be able to contact the support team for further assistance as mentioned on the landing page of the application. Sufficient error handling tactics such as local storage of data and retrying the operation will be implemented.
The primary interfaces between various components of the application are defined as below:
- The web application will communicate with the Express server through REST APIs.
- The Express server will communicate with the database through the Firebase SDK.
- The Aspect will communicate with the Express server through REST APIs.
Instructions on how to use the application will be provided on the landing page of the application. Information can also be found in the documentation which will be provided along with the application. If time permits, detailed instructions will be provided with the objective of publishing this software as a plugin in a DevOps environment.
The project aims to have minimal hit on the performance of the actual application itself. This is important as the objective of analysis will be defeated if the application run time details are malformed. The connection to the database and the API calls must not affect the performance of the actual application itself and must be independant. The frontend application must have acceptably fast load times for visual information. The API performance must not act as a bottleneck for the application as this can hinder the data collection process. Good internet connectivity is considered a prerequisite for the application to function as intended. The database must have usable read and write times.
The application must have sufficient security precautions in place to provide unrestricted access. User applications are private intellectual property and must not be accessible to other users. API requests must be vetted to ensure that they are coming from the web application and not from any other source. The application must be able to handle malicious requests and not crash. Tokens must be used to authenticate users and prevent unauthorized access to application data. Use of HTTPS is preferable when communicating with the application data. Internal system must use obfuscated application names to prevent identification of the application if data is intercepted.
The API must be able to handle all requests coming from the woven applications without loss of data or crashes. Maintenance breaks must be conveyed to the concerned stakeholders apriori. Database must be sufficiently reliable to store all data without loss. Database must be accessible 24*7 to ensure updation of application data and allow real time monitoring of applications in deployment.
The project must be modular and well documented to allow for easy maintenance. The tests written must be use-case driven and not structure driven so as to not break when the structure of the application changes in the future, which is likely. Dependencies used must be minimal so as to minimize the chances of a dependency breaking in the future. File organization and naming must stick to preestablished standards and standards must be conveyed to all concerned stakeholders.
The application should use minimal operating system dependent packages. The application should be physically movable to any location. Dependencies must be downloadable via a package manager without requiring physical downloads on the part of the user. The application must be able to run on all major browsers and devices. All components should be compiled from source. The AJC weaver must be run on a container or a remote server to ensure successful weaving at all times. The JavaScript and Java components must use build scripts like Maven and NPM to ensure that they can be built on any system.
Various aspects of the code such as the frontend and the backend must be written to encourage reusability. Components written in react must be self contained so that they can simply be dropped into rewrites of the project, if ever necessary. Middleware architecture and routers must be used in Express to encourage reuse of code. Generic code must be written for the database to ensure that it can be reused in other projects. Base aspects with necessary exclusions must be written to ensure that the basic functionality is easy to set up in new aspects. Design practises such as MVC architecture must also be followed to ensure that the code is reusable.
The application must be compatible with all major browsers (Edge, Chrome, Safari, Firefox) and devices. The application must be able to run on all major operating systems. The application must be able to run on all major versions of the operating systems. JavaScript is to be used which can run on all major browsers. Care must be taken to avoid modern JavaScript features that may not be fully supported on the aforementioned browsers.
NodeJS is a single threaded runtime and so is going to be fully occupied with the requests as they come in. Resource utilization is going to be low as only reads and writes are to be performed. React is a client side technology and the resource utilization is going to be minimal on the server side. The minimum system requirements mentioned on the official distribution sites are to be followed for the various versions of Java. AJC is assumed to have the same utilization as the Java version it is running on.
There is only one major user class in the application:
- User - This class will contain information about the user such as the user ID, email, name and the applications that the user has uploaded. The user can upload multiple applications and view the analytics of each application.