Repository navigation
Release 2 Evaluation Guide
Sze LAI (50012728): slai354, working for 4 story points and unit tests in this release.
Tingyi JIANG (50012637): julia0228, working for 6 story points and android tests in this release.
Zhouan SHEN (50012974): angelshen55, working for UML graphs, unit tests and CI/CD file in this release.
Aisleon is an intelligent shopping list tool designed to simplify your purchasing management. You can quickly create the needed list, or easily scan the receipts after shopping, and it will automatically identify the products and archive them in the history record. The application will manage the status of each item or the specific location in the supermarket or at home, allowing you to have a clear overview of your purchases and inventory.
Iteration 1: https://github.com/angelshen55/DataScience/milestone/3
Objective: Some bugs remaining in sprint 2 solution, finish shop-product relation reorganization, history filter function addition and draw all UML grpahs needed.
Iteration 2: https://github.com/angelshen55/DataScience/milestone/4
Objective: Further improvement on photo related function, which can automatically create products. Complete all the Unit test and Android test for modified app.
Total: 2 stories, 4 points over 4 weeks
Sprint 3 (1 stories, 4 points): https://github.com/angelshen55/DataScience/issues/30
Sprint 4 (1 stories, 6 points): https://github.com/angelshen55/DataScience/issues/31
Our project is of layered architecture. User interact with usecase models in domain layer by UI and then usecase models interact with entities in database with repositories and mappers.
This UML class diagram outlines the core domain model of our inventory management system, showcasing a structured hierarchy centered around Location, Aisle, and Product. The model effectively manages complexity through key relationships: a Locationaggregates multiple Aisles, and the many-to-many relationship between Aisleand Productis resolved by the associative entity AisleProduct, which also handles product ranking within an aisle. The Recordentity on the right tracks individual transactions, capturing essential details like purchase date, quantity, and shop. Specialized view classes such as AisleWithProductsand LocationWithAisledefine specific data compositions required by the application, demonstrating a clear separation between core data entities and their usage in different contexts.
Same content in: https://github.com/angelshen55/DataScience/issues/35
1. dependency injection - Koin(https://insert-koin.io/)
Reason: Choose Koin because of its simple DSL configuration and excellent Kotlin support, which makes it suitable for medium-sized projects. Also follow the original style of cloned repo for easy modification.
2. Local Database - Room(https://developer.android.com/training/data-storage/room)
Reason: Provide type-safe abstraction for SQLite, support data migration and initial data injection, and ensure the security of user historical data.
Alternative considered: Considered Realm but was more familiar with SQL
3. Testing Framework - JUnit 5(https://junit.org/)
Reason: The modern testing framework, combined with coroutine testing support, effectively verifies the business logic at the domain layer.
4. Architecture Pattern - Clean Architecture with Use Cases(https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
Reason: The use case pattern clearly separates the business logic, enabling the domain layer to be independent of the framework and enhancing testability.
Alternative considered: MVVM mainly addresses issues related to the UI layer; a simple layered architecture is insufficient to handle complex business rules.
5. UI Framework - XML(https://developer.android.com/develop/ui/views/layout/declaring-layout?hl=zh-cn)
Reason: Mature and stable, with a well-supported toolchain, and a clear separation between interface and logic. Follow the original setting of cloned repo.
Kotlin Coding Conventions: https://kotlinlang.org/docs/coding-conventions.html
-
app/src/main/kotlin/com/aisleron/ui/photos/PhotosFragment.kt(): use information we get in photos to add new products.
-
app/src/main/kotlin/com/aisleron/data/record/RecordDao.kt (): help users check history about specific shop, date and product.
We adhere to the principle that each user story requires testing before it is considered complete. For all the new functions we have added—such as the Record Table, new product features, and the price related usecases — we have correspondingly developed unit tests to ensure their quality. Furthermore, for the UI-related tests, we implement them using the AndroidTest framework to conduct integrated instrumentation tests that run on an actual device or emulator.
In terms of our overall testing approach, we employ some additional end-to-end validation methods. A notable example is our use of a dedicated app download testing process. By installing and testing the application build in a real-environment scenario, we were able to identify and subsequently resolve a subtle bug concerning the product and shop relationship, which was not easily detectable in isolated unit tests.
-
app/src/test/java/com/aisleron/domain/product/usecase/IsPricePositiveUseCaseTest.kt (https://github.com/angelshen55/DataScience/commit/8b0e2522d480bf384d3cd141b7ddeccd51cff677): A new test usecase for added feature price positiveness.
-
app/src/test/java/com/aisleron/data/DataLayerTest.kt (https://github.com/angelshen55/DataScience/commit/e5592d10583375ffac1740fd195829762200ba87): A tester to check all changes we have done in data layer(Record and Product).
-
app/src/test/java/com/aisleron/domain/product/usecase/IsPricePositiveUseCaseTest.kt (https://github.com/angelshen55/DataScience/commit/8b0e2522d480bf384d3cd141b7ddeccd51cff677): A new test usecase for added feature price positiveness.
-
app/src/test/java/com/aisleron/data/DataLayerTest.kt (https://github.com/angelshen55/DataScience/commit/e5592d10583375ffac1740fd195829762200ba87): A tester to check all changes we have done in data layer(Record and Product).
Our Android project utilizes GitHub Actions as our CI/CD platform, which is directly integrated with our GitHub repository. The workflow is specifically configured for building and testing the debug version of our application.
Key Configuration Details:
Trigger Conditions: The pipeline automatically executes on three events:
Pushes to the mainor workflowUpdatebranches.
The creation or update of any pull request.
Manual triggering via the workflow_dispatchevent in the GitHub UI.
Pipeline Stages:
1.Environment Setup: Checks out the code, validates the Gradle wrapper, and sets up the necessary environment including JDK 17, the Android SDK, and Gradle.
2.Unit Testing: Executes the unit test suite for the debug build variant (./gradlew :app:testDebugUnitTest). The results are then uploaded as a downloadable artifact.
3.Instrumentation Testing: Leverages the android-emulator-runneraction to automatically launch an Android emulator and run the Android instrumentation tests (./gradlew :app:connectedDebugAndroidTest). The results from these tests are also archived.
4.Build: Assembles the debug APK (./gradlew :app:assembleDebug).
Concurrency Control: The workflow includes a concurrency group setting that ensures only one CI run per branch is active at a time, automatically canceling any in-progress runs for the same branch to conserve resources.
Permissions: The workflow is granted contents: writepermission, which is typically used for operations like uploading build artifacts.
Our CI file link:
We use Tencent Yuanbao and Cursor to help with the code debugging and correction and report modification.