COMP2021: Object-Oriented Programming - Group Project: A Command-Line Task Management System
Group Project: A Command-Line Task Management System
1 Overview
This project aims to develop a command-line-based task management system (TMS) that will enable its users to define, query, and modify the simple tasks they need to complete.
A task can be simple or composite. Simple tasks are the smallest unions of work to manage using the system, while each composite task is a collection of other (simple or composite) tasks. Each task has a unique name, a description, a duration, and a group of prerequisites. A task name 1) may contain only English letters and digits, 2) cannot start with digits, and 3) may contain at most eight characters. A description may contain English letters, digits, and the hyphen letter (-). A duration is a positive real number, and it gives the minimum amount of time in hours required to complete the task. The prerequisites is a comma-separated list of task names. Each task name in the list should be defined already, and a task can only start when all its prerequisite tasks have finished. An empty list is denoted using a single comma (i.e., “,”).
Note that the prerequisite relation between tasks is transitive. Consider three tasks t1, t2, and t3 for example. When creating or changing a simple task, you should only specify the direct prerequisites of the task under consideration. The indirect prerequisites will be derived by the TMS automatically.
2 Requirements
The system should satisfy the following requirements.
[REQ1] (2 points) The system should support creating simple tasks.
Command: CreateSimpleTask name description duration prerequisites
Effect: Creates a new simple task.
Example: CreateSimpleTask task1 boil-water 0.3 ,
[REQ2] (2 points) The system should support creating composite tasks.
Command: CreateCompositeTask name0 description name1,name2,...,namek
Effect: Creates a composite task. The new task is named name0 and has k sub-
tasks, named name1, name2, ..., namek (k ≥ 2), respectively.
Example: CreateCompositeTask composite1 make-coffee primitive1,primitive2,composite0
[REQ3] (2 points) It should support deleting tasks.
Command: DeleteTask name
Effect: Deletes an existing task.
Example: DeleteTask task1
Note: A simple task can be deleted if it is not the prerequisite of any other tasks;
A composite task can be deleted if it does not contain any sub-task that is the
prerequisite of another task. When a composite task is deleted, all the sub-tasks it
contains are deleted too.
(2 points) It should support changing the properties of an existing task.
Command: ChangeTask name property newValue
Effect: Sets the property of a specific task to the new value.
Example: ChangeTask task1 duration 0.5
Note: (1) If the task is primitive, property can be name, description, duration,
or prerequisites; If the task is composite, property can be name, description,
or subtasks. The newValue may take any valid value compatible with the corre-
sponding property. (2) The prerequisites of a task are not affected by changes to
the other properties of the task.
(1 point) It should support printing the information of a task.
Command: PrintTask name
Effect: Prints the information of a task.
Example: Print task1
Note: The printout should be easy to read.
(2 points) It should support printing the information of all tasks.
Command: PrintAllTasks
Effect: Prints the information of all existing tasks.
Example: PrintAllTasks
(4 points) It should support reporting the duration of a task.
Command: ReportDuration name
Effect: Reports the duration of a task.
Example: ReportDuration task1
Note: The duration of a composite task is the minimum amount of hours needed
to finish all its sub-tasks. Suppose that a composite task t0 has three subtasks
t1, t2, and t3, with their durations being 1 hour, 2 hours, and 2 hours, respec-
tively. Further suppose that both t1 and t2 are prerequisites for t3 and there is no
prerequisite relation between t1 and t2. The duration of task t0 is then 4 hours.
(4 points) It should support reporting the earliest finish time of a task.
Command: ReportEarliestFinishTime name
Effect: Reports the earliest finish time of a task.
Example: ReportEarliestFinishTime task1
Note: The earliest finish time of a task is calculated as the sum of 1) the earliest
finish time of all its prerequisites and 2) the duration of itself.
(2 points) It should support defining basic task selection criteria.
Command: DefineBasicCriterion name1 property op value
Effect: Defines a basic task selection criterion.
Example: DefineBasicCriterion criterion1 duration > 0.1
Note: name1 is a unique name for the new basic criterion. The construction of
criterion names follows the same rules as task names. property is either name,
description, duration, or prerequisites. If property is name or description,
op must be contains and value must be a string in double quotes; If property is
duration, op can be >, <, >=, <=, ==, or !=, and value must be a real value. If
property is prerequisites or subtasks, op must be contains, and value must
be a list of comma-separated task names.
(1 point) It should support a criterion to check whether a task is primitive.
Criterion name: IsPrimitive
Effect: Evaluates to true if and only if on a primitive task.
(3 points) It should support defining composite task selection criteria.
Command: DefineNegatedCriterion name1 name2
Command: DefineBinaryCriterion name1 name2 logicOp name3
Effect: Construct a composite criterion named name1. The new criterion con-
structed using DefineNegatedCriterion is the negation of an existing criterion
named name2; The new criterion constructed using DefineBinaryCriterion is name2 logicOp name3, where name2 and name3 are two existing criteria, while logicOp is either && or ||. The logical operators negation, and (&&), or (||) have the conventional precedence, associativity, and semantics.
(3 points) The tool should support printing all defined criteria.
Command: PrintAllCriteria
Effect: Print out all the criteria defined. All criteria should be resolved to the form
containing only property names, op, value, logicOp, and IsPrimitive.
(5points)Thetoolshouldsupportsearchingfortasksbasedonanexistingcriterion.
Command: Search name
Effect: List all tasks that satisfy the criterion with the given name.
(3 points) The tool should support storing the defined tasks and criteria into a file.
Command: Store path
Effect: Stores the defined tasks and criteria into the file at path.
Example: Store d:\tasks.data
(3 points) The tool should support loading tasks and criteria from a file.
Command: Load path
Effect: Loads the defined tasks and criteria from the file at path.
Example: Load d:\tasks.data
Note: Loading the tasks and criteria from a file will cause all tasks and criteria
defined before the Load command to be discarded.
(1 point) The user should be able to terminate the current execution of the system.
Command: Quit
Effect: Terminates the execution of the system.
The system may be extended with the following bonus features:
(8 points) Support for a graphical user interface (GUI) to visually show the tasks created or selected and their relationship. If you implement this bonus feature, your GUI should be able to support all the required functionalities. Note that you still need to implement the command line interface even if your TMS has a GUI.
(4 points) Support for the undo and redo1 of all the required commands ex- cept PrintTask, PrintAllTasks, ReportDuration, ReportEarliestFinishTime, PrintAllCriteria, Search, Store, Load, and Quit.
The requirements above are incomplete on purpose, and you need to decide on the missing details when designing and implementing the TMS. For example, you need to gracefully handle situations where a command is ill-formed or cannot be executed successfully, e.g., because a task name is already used or not defined. Poor design in handling those situations will lead to point deductions.
3 Group Forming
This is a group project. Each group may have 3 to 4 members. Form your group on or before 10 October 2023. Afterward, students with no group will be randomly grouped, and requests for group change are only approved if written agreements from all members of the involved groups are provided before or on 14 October 2023. No group change will be allowed after 14 October 2023.
4 Code Inspection
The inspection tool of IntelliJ IDEA2 checks your program to identify potential problems in the source code. We have prepared a set of rules for grading (COMP2021 PROJECT.xml in the project material package). Import the rules into your IntelliJ IDEA IDE and check your implementation against the rules. Note that unit tests do not need to be checked against these rules.
The inspection tool can check for many potential problems, but only a few of them are consid- ered errors by the provided rule set. 2 points will be deducted for each error in your code reported by the tool.
5 Line Coverage of Unit Tests
The line coverage3 achieved by a suite of unit tests is the percentage of source code lines that the tests exercise, and it is an important measure of the test suite’s quality. The higher the coverage, the more thoroughly the suite of tests exercised a program.
You should follow the Model-View-Controller (MVC) pattern4 in designing the system. Put all Java classes for the model into package hk.edu.polyu.comp.comp2021.tms.model (see the structure in the sample project) and write tests for the model classes.
During grading, we will use the coverage tool of IntelliJ IDEA5 to get the line coverage of your tests on package hk.edu.polyu.comp.comp2021.tms.model. You will get 10 base points for line coverage between 90% and 100%, 9 base points for coverage between 80% and 89%, and so on. You will get 0 base points for line coverage below 30%. For example, if you only implement 60% of the requirements and you achieve 95% line coverage in testing, you will get 6 = 10 * 60% points for this part.
6 Design Review
The 3-hour lecture time in Week 13 will be devoted to the peer review of your design. The review will be conducted in clusters of X groups (X is to be decided later); Each group needs to review the designs of the other groups in its cluster and fill out the review reports. In a review report, a group needs to point out which design choices from another group are good, which are questionable, which should have been avoided, and explain the reasons.
Details about the design review’s organization and the report’s format will be announced before the review.
7 Individual Report
It is crucial for each member to submit an individual report. The report should be prepared from your own perspective and reflect your understanding of the project. It is mandatory for the individual report to demonstrate a distinct difference of at least 30% from the reports of other group members.
Additionally, your report should include a dedicated subsection titled “My Contribution and Role Distinction.” In this subsection, you should provide a detailed account of your individual contributions to the project and highlight the unique aspects of your role in comparison to other group members. The content of all other sections, except the “User Manual,” should align with the claims made in this subsection.
Use of GenAI tools: If you use GenAI tools in preparing any of the deliverables, you need to clearly state in the subsection titled “My Contribution and Role Distinction” of your individual report 1) which deliverable(s) and which part(s) of the deliverable(s) were prepared with the help of GenAI tools, 2) , we will consider all the deliverables your original work. Using GenAI tools in the project is permitted, but you should give proper acknowledgement to all the content from those tools that you included in your
