-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
14 changed files
with
251 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,124 @@ | ||
# Team Project - Proposal | ||
|
||
**MORAS: An Intelligent RISC-V/MIPS IDE** | ||
|
||
Group: 0 | ||
|
||
Member: 侯芳旻(12111448) 贾禹帆(12111224) 蒋钦杰(12111110) 刘宇涵(12111811) 欧阳安男(12211831) | ||
|
||
## Part I. Project Proposal | ||
|
||
### Project Overview | ||
|
||
Our goal is to **provide a convenient and user-friendly IDE** for **students learning computer organization**. Our target users are those who are studying this subject, and we have developed a range of features to enhance their coding experience. | ||
|
||
To achieve our goal of providing a convenient and user-friendly IDE for students learning computer organization, our IDE incorporates various functionalities. We **leverage AI's API** to enhance the capabilities of our system, offering advanced features and intelligent assistance. Additionally, our IDE supports **multi-user simultaneous editing**, encouraging collaboration and teamwork among students. It also provides **code completion, highlighting, and error tips** to assist students in writing code efficiently and accurately. For debugging purposes, **robust debug support** is available, enabling students to analyze variables and resolve issues or bugs. The **"dump" functionality** allows students to inspect memory and register values, enhancing their understanding of program execution. **Built-in documentation** offers quick access to relevant information and resources, while the **"replace same name label"** feature helps students manage and organize their code effectively. Overall, our IDE aims to create a comfortable and enriching coding experience for students studying computer organization. | ||
|
||
Overall, our overall goal is to **create an IDE that simplifies the learning process for students studying computer organization**. By providing a user-friendly interface and a range of powerful features, we strive to offer students a comfortable and enriching coding experience. | ||
|
||
### Preliminary Requirement Analysis | ||
|
||
#### Functional Requirements | ||
|
||
##### Using AI's API | ||
|
||
As a assembly language programmer, I want to be able to directly ask questions about code to AI, so that I can complete programming tasks more quickly and accurately. | ||
|
||
##### Multi-user Simultaneous Editing | ||
|
||
As students for Computer Organziation cource, they need to write assembly code for their self-design cpu. So that to improve the efficent of debug and coding, multiple user simultaneous editing. | ||
|
||
##### Code Completion, Highlighting, Error Tips | ||
|
||
As a developer, I want code completion, highlighting, and error tips so that I can write code more efficiently and identify and correct errors quickly during development. | ||
|
||
##### Debug Support | ||
|
||
As a MIPS programmer, I want to step through my code line by line, so that I can understand the flow of execution and identify where errors occur. | ||
|
||
##### Dump | ||
|
||
As a embedded developer, I want to be able to dump my code into the real microcomputer so that I can simply run it in the actual situation. | ||
|
||
##### Built-in Documentation | ||
|
||
As a beginner in assembly language, I want to be able to view documentation directly within the editor, so that I can access the necessary knowledge without having to open a browser and disrupt my workflow. | ||
|
||
##### Replace Same Name Label | ||
|
||
As a picky coder, I want to do lable rename like IDE's symbol rename. So that I can reduce errors caused by misstake and improve my coding experience. | ||
|
||
#### Non-functional Requirements | ||
|
||
##### Usability | ||
|
||
The usability of our IDE is a key consideration. We have designed it to be accessible and compatible with multiple platforms, including Windows, MacOS, and Linux. This allows students to use our IDE on their preferred operating system, providing flexibility and convenience. | ||
|
||
##### Safety | ||
|
||
Ensuring the safety of user code is of utmost importance to us. Our IDE has implemented strict security measures to prevent any leakage of user code to unauthorized individuals or external sources. We prioritize the privacy and confidentiality of our users' work, creating a secure environment for their coding projects. | ||
|
||
##### Security | ||
|
||
In addition to safeguarding user code, our IDE focuses on maintaining overall security. We have implemented measures to prevent memory leaks, ensuring that system resources are properly managed and utilized. By addressing potential security vulnerabilities, we strive to provide a secure coding environment for our users. | ||
|
||
##### Performance | ||
|
||
To enhance the performance of our IDE, we have optimized the execution of assembly code. Our IDE is designed to run assembly code quickly and efficiently, minimizing any delays or slowdowns during the execution process. By prioritizing performance, we aim to provide a smooth and seamless coding experience for our users. | ||
|
||
#### Data Requirements | ||
|
||
We need **assembly language documents** and **AI API keys** in this project. To get assembly language documents, we may use web pages from official assembly language documents. And we may apply for AI API keys directly on their official websites. | ||
|
||
#### Technical Requirements | ||
|
||
We will use **Tauri** to develop our application. The operating environment is desktop OS such as Windows, MacOS, and Linux. Tauri is a **multi-platform** desktop application framework with **Rust** as backend and **Javascript** as frontend. | ||
|
||
## Part II. Task Decomposition & Planning | ||
|
||
![part2_1](img/p2_1.png) | ||
![part2_2](img/p2_2.png) | ||
|
||
## Part III. AI Usage | ||
|
||
### Have you used AI to propose features for the project? | ||
|
||
No. We came up with these features in a brain storm. | ||
<details> | ||
<summary>ChatGPT4</summary> | ||
<img src="img/1.png" alt="1"> | ||
</details> | ||
The AI could generate most of our features for common usecase, but if couldn't generate more specific feature for SUSTech student. | ||
|
||
### Have you used AI to conduct the preliminary requirement analysis (e.g., identify functional and nonfunctional requirements)? | ||
|
||
Yes. | ||
<details> | ||
<summary>ChatGPT</summary> | ||
<img src="img/2_1.png" alt="2_1"> | ||
<img src="img/2_2.png" alt="2_2"> | ||
<img src="img/2_3.png" alt="2_3"> | ||
<img src="img/2_4.png" alt="2_4"> | ||
</details> | ||
We used them to generate content about non-functional requirements, but we did not use AI to identify these requirements. Besides, we also use AI to help us write better language. | ||
|
||
### Have you used AI to generate user stories? | ||
|
||
No. We write it by ourselves. | ||
<details> | ||
<summary>Ernie Bot</summary> | ||
<img src="img/3.png" alt="3"> | ||
</details> | ||
Compared the user stories generated by Ernie Bot with our manual answers. The user story generated by AI captures the essence of these requirements, demonstrating that the AI model can understand and synthesize the needs of students learning computer organization. However, the user stories provided by a real person offer a more personalized and specific perspective, reflecting the needs and preferences of someone with direct experience in the field. | ||
|
||
The manual answer is better because it offers more personalized and specific perspective, by I think AI do can assist the requirement analysis. | ||
|
||
### Have you used AI to generate issues or tasks? | ||
|
||
No, we didn't use AI. | ||
<details> | ||
<summary>Tongyi Qianwen</summary> | ||
<img src="img/4.png" alt="4"> | ||
</details> | ||
We asked Tongyi Qianwen for comparison. We think it's barely satisfying but too basic compared to our manual answers. It lists the fundamental issues and tasks but lacks innovative and practical functions. | ||
|
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,123 @@ | ||
# Moras - Sprint2 | ||
|
||
## 1. Metrics | ||
|
||
We use a script to statics our project, which have a Rust backend with a NextJS frontend. The script could be found at here: [statics.sh](../../scripts/stastics.sh) | ||
|
||
```text | ||
# Output | ||
Counting lines of code... | ||
Counting number of packages... | ||
Counting number of source files... | ||
Counting number of dependencies... | ||
------------------------------------------------------------------------------------------------------------------------------------------------- | ||
Lines of Code: | ||
=============================================================================== | ||
Language Files Lines Code Comments Blanks | ||
=============================================================================== | ||
Assembly 1 149 148 0 1 | ||
CSS 1 33 20 9 4 | ||
JavaScript 9 422 365 30 27 | ||
JSON 5 8550 8550 0 0 | ||
JSX 11 1782 1618 56 108 | ||
Protocol Buffers 1 75 61 0 14 | ||
Shell 2 56 35 10 11 | ||
SVG 3 9 8 1 0 | ||
TOML 3 48 40 4 4 | ||
------------------------------------------------------------------------------- | ||
HTML 1 14 14 0 0 | ||
|- CSS 1 22 22 0 0 | ||
(Total) 36 36 0 0 | ||
------------------------------------------------------------------------------- | ||
Markdown 5 389 0 261 128 | ||
|- BASH 1 7 4 3 0 | ||
(Total) 396 4 264 128 | ||
------------------------------------------------------------------------------- | ||
Rust 90 11460 10396 211 853 | ||
|- Markdown 10 306 0 263 43 | ||
(Total) 11766 10396 474 896 | ||
=============================================================================== | ||
Total 132 22987 21255 582 1150 | ||
=============================================================================== | ||
------------------------------------------------------------------------------------------------------------------------------------------------- | ||
Number of Packages: 2 | ||
------------------------------------------------------------------------------------------------------------------------------------------------- | ||
Number of Source Files: 118 | ||
------------------------------------------------------------------------------------------------------------------------------------------------- | ||
Number of Dependencies: 18 | ||
------------------------------------------------------------------------------------------------------------------------------------------------- | ||
``` | ||
|
||
## 2. Documentation | ||
|
||
### Documentation for End Users | ||
|
||
Our project includes comprehensive documentation for end users, which provides essential information and step-by-step instructions on how to use the software. This documentation is designed to be a user manual, helping end users to navigate and utilize the features of our application effectively. You can find the user documentation [here](https://rosswasd.github.io/team-project-24spring-0/). | ||
|
||
### Documentation for Developers | ||
|
||
To assist developers, collaborators, and potential future contributors, we have created detailed API documentation. This documentation is intended to explain the design, purpose, and implementation of important code entities, such as classes and methods, enabling developers to update or extend our software with ease. The backend developer documentation, generated by Rust's `rustdoc`, can be accessed [here](https://sustech-cs304.github.io/team-project-24spring-0/moras/). This documentation provides clear explanations of the main APIs that both frontend and backend developers may use. | ||
|
||
By maintaining thorough and up-to-date documentation for both end users and developers, we ensure that our software is easy to use and maintain. And our doc is generate | ||
|
||
## 3. Tests | ||
|
||
Since we use Rust as our main language, we can easily write tests in our code with the `#[test]` attribute. We have written 29 unit tests in total, covering major functions of the backend logic. However, since our backend and frontend are separated, writing tests for frontend logic is challenging, so the part that communicates with the frontend is not tested. | ||
|
||
We generate our test report with the command `cargo tarpaulin --out html`. (need to install `cargo-tarpaulin` first.) This command generates the coverage report. We also use GitHub CI to run tests, generate the coverage report, and deploy the test result to our GitHub Pages automatically. You can check it [here](https://sustech-cs304.github.io/team-project-24spring-0/report#src). We achieved a 63.85% coverage rate for our backend code. | ||
|
||
## 4. Build | ||
|
||
Our project leverages a highly automated and robust build process to streamline the compilation of source code, the assembly of dependencies, and the production of executables. We have integrated several tools and frameworks to achieve this seamless automation. | ||
|
||
### Tools and Frameworks Utilized | ||
|
||
To manage our build process, we rely on a combination of `cargo` for Rust, `npm` for JavaScript dependencies, and GitHub CI/CD for continuous integration and deployment. Additionally, we use the `tauri` framework to build cross-platform applications, further enhancing our development workflow. | ||
|
||
### Build Process Tasks | ||
|
||
Our build process encompasses both continuous integration (CI) and continuous deployment (CD) tasks, ensuring that our codebase is always in a deployable state. | ||
|
||
**Continuous Integration (CI)** | ||
|
||
The CI process is meticulously defined in our [build.yaml](../../.github/workflows/build.yml) configuration. It begins with a format check to ensure code consistency and adherence to styling guidelines. This is accomplished using `cargo fmt -- --check` for Rust code and `npm run format-check` for JavaScript files. Maintaining consistent code style is crucial for collaboration and code readability. | ||
|
||
Next, we generate a comprehensive test coverage report using the script [report.sh](../../scripts/report.sh), which runs `cargo tarpaulin --out Html` to create detailed coverage metrics. This helps us identify untested parts of our code and improve overall test coverage. | ||
|
||
We then execute all unit tests with `cargo test`, ensuring that our backend logic functions as intended. This step is vital for catching any regressions or bugs early in the development cycle. | ||
|
||
To further enhance our documentation, we generate it alongside the test reports using `cargo doc --no-deps`. This provides up-to-date and accurate documentation for our codebase, which is essential for both current and future developers working on the project. | ||
|
||
Finally, our CI pipeline automatically deploys the generated documentation and test reports to GitHub Pages, making them easily accessible for review. This seamless integration with GitHub CI/CD highlights the high level of automation in our build process, significantly reducing manual intervention and errors. | ||
|
||
**Continuous Deployment (CD)** | ||
|
||
Our CD process, defined in [release.yaml](../../.github/workflows/release.yml), focuses on building our application for multiple platforms. Utilizing the `tauri-apps/tauri-action@v0` action, we run `cargo tauri build` to compile the application. This ensures that our build artifacts are consistent and reliable across different operating systems. | ||
|
||
The final step in our CD pipeline is the deployment of the executable to GitHub. This automated deployment ensures that our latest application version is always available for download on our [releases page](https://github.com/sustech-cs304/team-project-24spring-0/releases). | ||
|
||
### Build Files and Configuration | ||
|
||
Our build process is defined and managed through several configuration files: | ||
|
||
- The backend configuration is specified in the [Cargo.toml](../../src-tauri/Cargo.toml) file, detailing dependencies and build scripts for the Rust project. | ||
- The frontend dependencies and build commands are defined in the [package.json](../../src-ui/package.json) file. | ||
- The CI and CD workflows are meticulously outlined in the [build.yaml](../../.github/workflows/build.yml) and [release.yaml](../../.github/workflows/release.yml) files respectively. | ||
|
||
These configurations collectively ensure a smooth and automated build process, reflecting our commitment to maintaining a high level of automation and efficiency in our development workflow. | ||
|
||
## 5. Deployment | ||
|
||
This is a desktop application without any server provided online services, so there is no need for deployment it to container(docker also not support to run GUI application without tricks like X11-forwording or virtual desktop). However, since our application is a cross-paltform application, we can build it for multiple platforms and release it to GitHub with github actions. | ||
|
||
We use Tauri to build our application, which can build our application for Windows, macOS, and Linux. Moreove, we use GitHub CD to automatically build our application for multiple platforms easily. Our github release action is heree [release.yaml](../../.github/workflows/release.yml), it could do multi-platforms builds and push the artifacts to a draft release without any maunally operation. This workflow is trriger by tag operation, once we push a teg like "v1.0.0", it will release our v1.0.0 version's applications. | ||
|
||
And application releases can be found [here](https://github.com/sustech-cs304/team-project-24spring-0/releases). | ||
|
||
## 6. Collaborations And AI Usages | ||
|
||
![img](img/collaborations.png) | ||
|
||
AI useage: To faster our develop, we us AI to generate some of our unit test cases. All test cases generate by has a comment. | ||
|
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters