Named after the Titan of Time, ‘Kronos’ is a great tool for planning and managing your schedule. You can efficiently organize tasks and track habits. It also comes with a Pomodoro Timer.

As students, we have to balance and keep track of various things at the same time. Hence, we decided to create a Time-management system based on our personal experiences and needs.

• Account Creation and Login
• Habit Creation and Tracking
• Task and Category Creation
• Pomodoro Timer
• User Habits Visualization

The user needs to have an account on the system to be able to access the features. In case the user has an account, they can log in.

Logging in leads to the Menu page which has options for the features: Habits, Tasks, Categories, Data Visualization and Timer. The user can then choose any of them and they will be led to the corresponding page.

NOTICE: The UI for the features are not currently connected properly to the main UI, so the user needs to run the following files for each feature:

• MainUI : User feature
• HabitProfileScreen : Habit Feature
• ToDoListMain : Category and Tasks Features (has makeshift user data)
• TimerScreen : Tomato Timer Feature
• Database Visualization Feature has no UI, database is mostly backend

The design patterns implemented in the project are:

• The use cases are implemented using the Façade design pattern.

• The entities are implementing using the Private Data Class design pattern. This is to reduce coupling and limit user access to the core of the system.

We ensured that the project followed all the SOLID principles.

• Each use case is specifically responsible for one function, ensuring the Single Responsibility Principle. We are

• We used interfaces in the use cases which are open to extension but not modification.

• We ensured that that the principle was not violated. Application behaviour does not depend on which subtypes it uses.

• We ensured that no classes were forced to implement or use interfaces they did not need.

• It was implemented by the User use cases.

The project mainly follows the MVP model. However, to ensure clean architecture, we implemented controllers and presenters separately.

The GitHub features used in project are:

• Issues
• Pull Requests
• Action
• License

• The test coverage is 80%.
• We have tested the entities, use cases, controllers and database.
• We did not test UIs because we though the way to ensure its correctness is to check if it runs correctly and fulfils its function.
• We partially tested controllers and presenters.

• Our initial plan for this project was too ambitious as we only had a limited time. We didn't realize this until we implemented it. During the implementation, we removed some features mentioned in our plan because implementing these features can be very complicated, and we don't know how to make things work for some of them.

• We would use Mockito or a property-based testing library to add more unit tests to improve the test coverage of our project.

• Currently, text, frame sizes, and colors are fixed in our UI. Users with more limited sensory abilities may have different preferences that aren't accounted for. Also, the UI is very limited and undynamic. We need to make it more interactive and user-friendly.

• Currently, our program is inaccessible to some groups of people. For example, our program does not accommodate blind people as we did not have functions such as automatic reading and cursor navigation. We can add these to our program to make it more accessible to blind people.