By: Team T09-1 Since: Aug 2018 Licence: MIT
-
JDK
9or later⚠️ JDK 10on Windows will fail to run tests in headless mode due to a JavaFX bug. Windows developers are highly recommended to use JDK9. -
IntelliJ IDE
ℹ️IntelliJ by default has Gradle and JavaFx plugins installed.
Do not disable them. If you have disabled them, go toFile>Settings>Pluginsto re-enable them.
-
Fork this repo, and clone the fork to your computer
-
Open IntelliJ (if you are not in the welcome screen, click
File>Close Projectto close the existing project dialog first) -
Set up the correct JDK version for Gradle
-
Click
Configure>Project Defaults>Project Structure -
Click
New…and find the directory of the JDK
-
-
Click
Import Project -
Locate the
build.gradlefile and select it. ClickOK -
Click
Open as Project -
Click
OKto accept the default settings -
Open a console and run the command
gradlew processResources(Mac/Linux:./gradlew processResources). It should finish with theBUILD SUCCESSFULmessage.
This will generate all resources required by the application and tests. -
Open
XmlAdaptedPerson.javaandMainWindow.javaand check for any code errors-
Due to an ongoing issue with some of the newer versions of IntelliJ, code errors may be detected even if the project can be built and run successfully
-
To resolve this, place your cursor over any of the code section highlighted in red. Press ALT+ENTER, and select
Add '--add-modules=…' to module compiler optionsfor each error
-
-
Repeat this for the test folder as well (e.g. check
XmlUtilTest.javaandHelpWindowTest.javafor code errors, and if so, resolve it the same way)
-
Run the
seedu.address.MainAppand try a few commands -
Run the tests to ensure they all pass.
This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,
-
Go to
File>Settings…(Windows/Linux), orIntelliJ IDEA>Preferences…(macOS) -
Select
Editor>Code Style>Java -
Click on the
Importstab to set the order-
For
Class count to use import with '*'andNames count to use static import with '*': Set to999to prevent IntelliJ from contracting the import statements -
For
Import Layout: The order isimport static all other imports,import java.*,import javax.*,import org.*,import com.*,import all other imports. Add a<blank line>between eachimport
-
Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.
Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.
After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).
|
ℹ️
|
Coverage reporting could be useful for a team repository that hosts the final version but it is not that useful for your personal fork. |
Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).
|
ℹ️
|
Having both Travis and AppVeyor ensures your App works on both Unix-based platforms and Windows-based platforms (Travis is Unix-based and AppVeyor is Windows-based) |
When you are ready to start coding,
-
Get some sense of the overall design by reading Section 2.1, “Architecture”.
-
Take a look at [GetStartedProgramming].
The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.
|
💡
|
The .pptx files used to create diagrams in this document can be found in the diagrams folder. To update a diagram, modify the diagram in the pptx file, select the objects of the diagram, and choose Save as picture.
|
Main has only one class called MainApp. It is responsible for,
-
At app launch: Initializes the components in the correct sequence, and connects them up with each other.
-
At shut down: Shuts down the components and invokes cleanup method where necessary.
Commons represents a collection of classes used by multiple other components. Two of those classes play important roles at the architecture level.
-
EventsCenter: This class (written using Google’s Event Bus library) is used by components to communicate with other components using events (i.e. a form of Event Driven design) -
LogsCenter: Used by many classes to write log messages to the App’s log file.
The rest of the App consists of four components.
Each of the four components
-
Defines its API in an
interfacewith the same name as the Component. -
Exposes its functionality using a
{Component Name}Managerclass.
For example, the Logic component (see the class diagram given below) defines it’s API in the Logic.java interface and exposes its functionality using the LogicManager.java class.
The Sequence Diagram below shows how the components interact for the scenario where the user issues the command delete 1.
delete 1 command (part 1)|
ℹ️
|
Note how the Model simply raises a AddressBookChangedEvent when the Address Book data are changed, instead of asking the Storage to save the updates to the hard disk.
|
The diagram below shows how the EventsCenter reacts to that event, which eventually results in the updates being saved to the hard disk and the status bar of the UI being updated to reflect the 'Last Updated' time.
delete 1 command (part 2)|
ℹ️
|
Note how the event is propagated through the EventsCenter to the Storage and UI without Model having to be coupled to either of them. This is an example of how this Event Driven approach helps us reduce direct coupling between components.
|
The sections below give more details of each component.
API :
Logic.java
-
Logicuses theAppParserclass to parse the user command. -
AppParserthen sends the command to the appropriate module parser. -
This results in a
Commandobject which is executed by theLogicManager. -
The command execution can affect the
Model(e.g. adding a person) and/or raise events. -
The result of the command execution is encapsulated as a
CommandResultobject which is passed back to theUi.
Given below is the Sequence Diagram for interactions within the Logic component for the execute("contacts delete 1") API call.
contacts delete 1 Command
API : Model.java
The Model,
-
stores a
UserPrefobject that represents the user’s preferences. -
stores the Address Book data.
-
exposes an unmodifiable
ObservableList<Person>andObservableList<Task>that can be 'observed' e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change. -
does not depend on any of the other three components.
This section describes some noteworthy details on how certain features are implemented.
The Task class consists of list of Tag objects and a Name object, corresponding to the same classes in the Person namespace. It also has two DateTime objects, one for the start date and time and the other for the end date and time of the task.
The DateTime class encapsulates a Java Calendar object to store a date and time. It also includes methods to parse and validate date/time inputs from the user, and methods to return the date or time as a String.
Listing and finding of tasks is facilitated by ModelManager and displayed through TaskListPanel.
ModelManager implements the following relevant methods:
-
ModelManager#updateFilteredTaskList(Predicate<Task> predicate)— Updates the the internalfilteredTaskslist with the predicate given. Exposed through theModelinterface. -
ModelManager#getFilteredTaskList()— Returns an unmodifiable view of the internalfilteredTaskslist that updates with any changes to the baselist. Exposed through theLogicandModelinterfaces.
|
ℹ️
|
ModelManager#filteredTasks is a JavaFX FilteredList around the unmodifiable list of tasks provided by VersionedAddressBook#getTaskList()). |
TaskListPanel is constructed with the JavaFX ObservableList returned by
ModelManager#getFilteredTaskList() when the application is started and displays it.
To find specific tasks, the appropriate predicate is passed into ModelManager#updateFilteredTaskList(), which updates
the filteredTasks list, propagating the change up to the TaskListPanel display.
Currently, there are 2 use cases where ModelManager#updateFilteredTaskList() is called, examples are given below.
Case 1: On application startup or after running tasks list command
ModelManager#updateFilteredTaskList() is called with
Model#PREDICATE_SHOW_ALL_TASKS which returns true for all tasks
Case 2: After running tasks find [KEYWORDS] command
ModelManager#updateFilteredTaskList() is called with
NameContainsKeywordsPredicate formed with the keywords provided,
which returns true only for tasks with keywords in the name.
The use of ObservableList and FilteredList from JavaFX saves us the trouble of handling task list updates.
Under this design, addition, updates and deletion of tasks will only need to interface with VersionedAddressBook,
and the lists for display will be updated through JavaFX.
If we were use Java Lists instead, events will need to be raised to update lists stored for display.
The undo/redo mechanism is facilitated by VersionedAddressBook.
It extends AddressBook with an undo/redo history, stored internally as an addressBookStateList and currentStatePointer.
Additionally, it implements the following operations:
-
VersionedAddressBook#commit()— Saves the current address book state in its history. -
VersionedAddressBook#undo()— Restores the previous address book state from its history. -
VersionedAddressBook#redo()— Restores a previously undone address book state from its history.
These operations are exposed in the Model interface as Model#commitAddressBook(), Model#undoAddressBook() and Model#redoAddressBook() respectively.
Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
Step 1. The user launches the application for the first time. The VersionedAddressBook will be initialized with the initial address book state, and the currentStatePointer pointing to that single address book state.
Step 2. The user executes delete 5 command to delete the 5th person in the address book. The delete command calls Model#commitAddressBook(), causing the modified state of the address book after the delete 5 command executes to be saved in the addressBookStateList, and the currentStatePointer is shifted to the newly inserted address book state.
Step 3. The user executes add n/David … to add a new person. The add command also calls Model#commitAddressBook(), causing another modified address book state to be saved into the addressBookStateList.
|
ℹ️
|
If a command fails its execution, it will not call Model#commitAddressBook(), so the address book state will not be saved into the addressBookStateList.
|
Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the undo command. The undo command will call Model#undoAddressBook(), which will shift the currentStatePointer once to the left, pointing it to the previous address book state, and restores the address book to that state.
|
ℹ️
|
If the currentStatePointer is at index 0, pointing to the initial address book state, then there are no previous address book states to restore. The undo command uses Model#canUndoAddressBook() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the undo.
|
The following sequence diagram shows how the undo operation works:
The redo command does the opposite — it calls Model#redoAddressBook(), which shifts the currentStatePointer once to the right, pointing to the previously undone state, and restores the address book to that state.
|
ℹ️
|
If the currentStatePointer is at index addressBookStateList.size() - 1, pointing to the latest address book state, then there are no undone address book states to restore. The redo command uses Model#canRedoAddressBook() to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
|
Step 5. The user then decides to execute the command list. Commands that do not modify the address book, such as list, will usually not call Model#commitAddressBook(), Model#undoAddressBook() or Model#redoAddressBook(). Thus, the addressBookStateList remains unchanged.
Step 6. The user executes clear, which calls Model#commitAddressBook(). Since the currentStatePointer is not pointing at the end of the addressBookStateList, all address book states after the currentStatePointer will be purged. We designed it this way because it no longer makes sense to redo the add n/David … command. This is the behavior that most modern desktop applications follow.
The following activity diagram summarizes what happens when a user executes a new command:
-
Alternative 1 (current choice): Saves the entire address book.
-
Pros: Easy to implement.
-
Cons: May have performance issues in terms of memory usage.
-
-
Alternative 2: Individual command knows how to undo/redo by itself.
-
Pros: Will use less memory (e.g. for
delete, just save the person being deleted). -
Cons: We must ensure that the implementation of each individual command are correct.
-
-
Alternative 1 (current choice): Use a list to store the history of address book states.
-
Pros: Easy for new Computer Science student undergraduates to understand, who are likely to be the new incoming developers of our project.
-
Cons: Logic is duplicated twice. For example, when a new command is executed, we must remember to update both
HistoryManagerandVersionedAddressBook.
-
-
Alternative 2: Use
HistoryManagerfor undo/redo-
Pros: We do not need to maintain a separate list, and just reuse what is already in the codebase.
-
Cons: Requires dealing with commands that have already been undone: We must remember to skip these commands. Violates Single Responsibility Principle and Separation of Concerns as
HistoryManagernow needs to do two different things.
-
The calendar show feature is facilitated by the ModelManager. It extends ModelManager with a calendar panel that allows the user to more easily view the tasks.
It exposes the following operations via the Model interface:
-
Model#updateCalendarMonth()— Saves the given calendar that encapsulates the month to be displayed in the calendar panel. -
Model#getCalendarMonth()— Returns anObservableValue<Calendar>for the calendar panel to identify which weekday the month begins with. -
Model#updateCalendarTaskList()— Updates the model with a predicate to filter the tasks that should be displayed in the calendar. -
Model#getCalendarTaskList()— Returns anObservableList<Task>for the calendar panel to display.
Given below is an example usage scenario and how the calendar show mechanism behaves at each step.
Step 1. The user launches the application. The MainWindow class calls Model#getCalendarMonth() and Model#getCalendarTaskList() when creating the calendar panel. This initialises the calendar panel with an ObservableList<Task> and ObservableValue<Calendar> to allow it to perform UI updates when necessary.
Step 2. The calendar panel constructs a GridPane and initialises the cells with empty containers.
Step 3. The calendar panel registers listeners to both the ObservableList<Task> and ObservableValue<Calendar> with a task that would empty grid cells and repopulate them with ListView elements that display the tasks starting on the corresponding dates.
Step 4. The user creates any number of tasks with start date in January 2018. The tasks will be stored appropriately.
Step 5. The user executes calendars show y/2018 m/1. The calendars show command calls Model#updateCalendarMonth() and Model#updateCalendarTaskList(), listeners in the calendar panel to be notified of the changes.
-
Alternative 1 (current choice): Done in the model
-
Pros: Application logic does not reside in the view layer.
-
Cons: Repeated filtering at multiple steps. Tasks are duplicated in two data lists.
-
-
Alternative 2: Calendar object representing current month and full task list passed to calendar pane, all filter operations done in the calendar pane.
-
Pros: Less data duplication.
-
Cons: Poorer separation of concerns, less modularity.
-
-
Alternative 1 (current choice): Delete and regenerate
ListViewelements each time the moth is changed-
Pros: Ease of implementation, especially since
GridPanedoes not support random access. -
Cons: Poorer performance, although this is likely insignificant since number of elements to be created/deleted is small.
-
-
Alternative 2: Create and store
ListViewcontainers and reuse them.-
Pros: Better performance, since deleting and recreating them incurs some computational cost.
-
Cons: Requires creating an auxillary data structure to store the elements to get around deficiencies in the
GridPaneAPI.
-
We are using java.util.logging package for logging. The LogsCenter class is used to manage the logging levels and logging destinations.
-
The logging level can be controlled using the
logLevelsetting in the configuration file (See Section 3.7, “Configuration”) -
The
Loggerfor a class can be obtained usingLogsCenter.getLogger(Class)which will log messages according to the specified logging level -
Currently log messages are output through:
Consoleand to a.logfile.
Logging Levels
-
SEVERE: Critical problem detected which may possibly cause the termination of the application -
WARNING: Can continue, but with caution -
INFO: Information showing the noteworthy actions by the App -
FINE: Details that is not usually noteworthy but may be useful in debugging e.g. print the actual list instead of just its size
Certain properties of the application can be controlled (e.g App name, logging level) through the configuration file (default: config.json).
The code for editing and deleting tasks is actually pretty similar to how it is implemented for persons. This is a combination of adding support for two additional commands: tasks edit and tasks delete inside TasksParser, defining EditCommand and DeleteCommand themselves, and finally, adding void updateTask(Task target, Task editedTask); and void deleteTask(Task target); in the Model interface, and implementing them in the ModelManager class.
After any task is updated/deleted, indicateAddressBookChanged() is called to fire off the event such that the UI is updated.
To explain more clearly, you can see below a diagram of what happens when the user asked the program to edit a task:
Tasks and contacts can be assigned to each other using the commands tasks assign and contacts assign. This many-to-many relationship is stored simply as a list of task IDs and person IDs in the Person and Task classes respectively.
The commands are parsed by AssignCommand in both TasksParser and ContactsParser. If both the specified task and contact are found, the task and person IDs will be added to Person.taskIds and Task.personIds respectively, and the edited objects will be saved to disk. As happens when the edit commands are run, indicateAddressBookChanged() is called to update the UI. The data flow is similar to the one for EditCommand in the previous section.
An alternative implementation that was considered was to model the many-to-many relationship using an Assignment class, which will act like a join table in relational databases. This would have slightly decoupled the Person and Task classes. However, we chose not to implement it this way as a Person will always be assigned to a Task, and also because implementing such a relationship with manually managed IDs is extremely complex without a relational database to abstract away the complexity.
We use asciidoc for writing documentation.
|
ℹ️
|
We chose asciidoc over Markdown because asciidoc, although a bit more complex than Markdown, provides more flexibility in formatting. |
See UsingGradle.adoc to learn how to render .adoc files locally to preview the end result of your edits.
Alternatively, you can download the AsciiDoc plugin for IntelliJ, which allows you to preview the changes you have made to your .adoc files in real-time.
See UsingTravis.adoc to learn how to deploy GitHub Pages using Travis.
We use Google Chrome for converting documentation to PDF format, as Chrome’s PDF engine preserves hyperlinks used in webpages.
Here are the steps to convert the project documentation files to PDF format.
-
Follow the instructions in UsingGradle.adoc to convert the AsciiDoc files in the
docs/directory to HTML format. -
Go to your generated HTML files in the
build/docsfolder, right click on them and selectOpen with→Google Chrome. -
Within Chrome, click on the
Printoption in Chrome’s menu. -
Set the destination to
Save as PDF, then clickSaveto save a copy of the file in PDF format. For best results, use the settings indicated in the screenshot below.
The build.gradle file specifies some project-specific asciidoc attributes which affects how all documentation files within this project are rendered.
|
💡
|
Attributes left unset in the build.gradle file will use their default value, if any.
|
| Attribute name | Description | Default value |
|---|---|---|
|
The name of the website. If set, the name will be displayed near the top of the page. |
not set |
|
URL to the site’s repository on GitHub. Setting this will add a "View on GitHub" link in the navigation bar. |
not set |
|
Define this attribute if the project is an official SE-EDU project. This will render the SE-EDU navigation bar at the top of the page, and add some SE-EDU-specific navigation items. |
not set |
Each .adoc file may also specify some file-specific asciidoc attributes which affects how the file is rendered.
Asciidoctor’s built-in attributes may be specified and used as well.
|
💡
|
Attributes left unset in .adoc files will use their default value, if any.
|
| Attribute name | Description | Default value |
|---|---|---|
|
Site section that the document belongs to.
This will cause the associated item in the navigation bar to be highlighted.
One of: * Official SE-EDU projects only |
not set |
|
Set this attribute to remove the site navigation bar. |
not set |
The files in docs/stylesheets are the CSS stylesheets of the site.
You can modify them to change some properties of the site’s design.
The files in docs/templates controls the rendering of .adoc files into HTML5.
These template files are written in a mixture of Ruby and Slim.
|
|
Modifying the template files in |
There are three ways to run tests.
|
💡
|
The most reliable way to run tests is the 3rd one. The first two methods might fail some GUI tests due to platform/resolution-specific idiosyncrasies. |
Method 1: Using IntelliJ JUnit test runner
-
To run all tests, right-click on the
src/test/javafolder and chooseRun 'All Tests' -
To run a subset of tests, you can right-click on a test package, test class, or a test and choose
Run 'ABC'
Method 2: Using Gradle
-
Open a console and run the command
gradlew clean allTests(Mac/Linux:./gradlew clean allTests)
|
ℹ️
|
See UsingGradle.adoc for more info on how to run tests using Gradle. |
Method 3: Using Gradle (headless)
Thanks to the TestFX library we use, our GUI tests can be run in the headless mode. In the headless mode, GUI tests do not show up on the screen. That means the developer can do other things on the Computer while the tests are running.
To run tests in headless mode, open a console and run the command gradlew clean headless allTests (Mac/Linux: ./gradlew clean headless allTests)
We have two types of tests:
-
GUI Tests - These are tests involving the GUI. They include,
-
System Tests that test the entire App by simulating user actions on the GUI. These are in the
systemtestspackage. -
Unit tests that test the individual components. These are in
seedu.address.uipackage.
-
-
Non-GUI Tests - These are tests not involving the GUI. They include,
-
Unit tests targeting the lowest level methods/classes.
e.g.seedu.address.commons.StringUtilTest -
Integration tests that are checking the integration of multiple code units (those code units are assumed to be working).
e.g.seedu.address.storage.StorageManagerTest -
Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
e.g.seedu.address.logic.LogicManagerTest
-
See UsingGradle.adoc to learn how to use Gradle for build automation.
We use Travis CI and AppVeyor to perform Continuous Integration on our projects. See UsingTravis.adoc and UsingAppVeyor.adoc for more details.
We use Coveralls to track the code coverage of our projects. See UsingCoveralls.adoc for more details.
When a pull request has changes to asciidoc files, you can use Netlify to see a preview of how the HTML version of those asciidoc files will look like when the pull request is merged. See UsingNetlify.adoc for more details.
Here are the steps to create a new release.
-
Update the version number in
MainApp.java. -
Generate a JAR file using Gradle.
-
Tag the repo with the version number. e.g.
v0.1 -
Create a new release using GitHub and upload the JAR file you created.
A project often depends on third-party libraries. For example, Address Book depends on the Jackson library for XML parsing. Managing these dependencies can be automated using Gradle. For example, Gradle can download the dependencies automatically, which is better than these alternatives.
a. Include those libraries in the repo (this bloats the repo size)
b. Require developers to download those libraries manually (this creates extra work for developers)
Target User: NUS Computing students doing group projects
Target user profile: - is a student managing a project with multiple team members - has a need to manage a significant number of contacts - has a need to manage a significant number of tasks - prefer desktop apps over other types - can type fast - prefers typing over mouse input - is reasonably comfortable using CLI apps
Value proposition: manage tasks faster than a typical mouse/GUI driven app
Priorities: High (must have) - * * , Medium (nice to have) - ,
Low (unlikely to have) -
| Priority | As a… | I want to… | So that I can… |
|---|---|---|---|
|
user |
CRUD Tasks |
|
|
existing user |
be alerted to tasks near their deadline |
will not miss any of them and delay the completion of the project or face any other consequences |
|
existing user |
assign other tasks to people |
I can track who’s supposed to complete them and notify them (by email) that they are supposed to complete the task |
|
existing user |
see an overview of all tasks and people assigned |
so that I can quickly get a sense of the state of my project and tasks |
|
existing user |
sort the overview |
|
|
existing user |
see the tasks assigned to each person |
I know what they’re supposed to do |
|
existing user |
group tasks according to categories/tags |
manage a larger number of tasks easily |
|
user |
send email notifications to people I assigned tasks to |
send updates/reminders |
|
user |
see notifications on other messaging platforms |
conveniently view my tasks |
|
user |
see all tasks in a visual manner |
|
|
user |
see milestones visualised using a calendar |
|
|
user |
view team members’ calendars and share my own |
coordinate meetings and track progress |
|
user |
track the extent of others’ involvement in each task |
ensure that irresponsible do not get undue credit |
|
user |
use this product as a web app |
easily access my tasks/work on all platforms |
|
user |
recurring tasks |
need not to re-create recurring tasks |
|
user |
Autocomplete when typing tags |
find tags faster |
|
user |
vim-mode CLI |
use the app more efficiently |
|
user |
emacs-mode CLI |
use the app more efficiently |
|
a self-respecting computing user |
open a window that traces each line of code that is executed when I perform an action |
MSS
-
User requests to add person, together with all the attributes
-
Cow adds that person to the contacts. Use case ends
Extensions
-
1a. Invalid attribute provided
-
1a1. Cow shows an error message.
Use case ends
-
MSS
-
User requests to list persons
-
Cow shows a list of persons
-
User requests to update a specific person in the list, together with the new attributes
-
Cow updates the person with the given attribute
Use case ends
Extensions
-
2a. The list is empty.
Use case ends
-
3a. The given index is invalid.
-
3a1. AddressBook shows an error message.
Use case resumes at step 2
-
-
3a. Invalid attribute provided
-
3a1. Cow shows an error message.
Use case resumes at step 2
-
MSS
-
User requests to list persons
-
Cow shows a list of persons
-
User requests to delete a specific person in the list
-
Cow deletes the person
Use case ends
Extensions
-
2a. The list is empty.
Use case ends
-
3a. The given index is invalid.
-
3a1. AddressBook shows an error message.
Use case resumes at step 2
-
MSS
-
User requests to add task, together with all the attributes
-
Cow adds that task.
Use case ends
Extensions
-
1a. Invalid attribute provided
-
1a1. Cow shows an error message.
Use case ends
-
MSS
-
User requests to list tasks
-
Cow shows a list of tasks
-
User requests to update a specific task in the list, together with the new attributes
-
Cow updates the task with the given attribute
Use case ends
Extensions
-
2a. The list if empty Use case ends
-
3a. The given index is invalid.
-
3a1. AddressBook shows an error message.
Use case resumes at step 2
-
-
3a. Invalid attribute provided
-
3a1. Cow shows an error message.
Use case resumes at step 2
-
MSS
-
User requests to list tasks
-
Cow shows a list of tasks
-
User requests to delete a specific task in the list
-
Cow deletes the task
Use case ends
Extensions
-
2a. The list is empty.
Use case ends
-
3a. The given index is invalid.
-
3a1. AddressBook shows an error message.
Use case resumes at step 2
-
MSS
-
Create a task
-
Assign people to task
-
Email people involved about the task
Use case ends
Extensions
-
3a. Email could not be sent.
-
3a1. Cow shows an error message.
Use case ends
-
MSS
-
Find a contact by entering
find_contact <contact_name> -
View tasks assigned to the contact
-
Unassign contact from all tasks by entering
unassign_contact <contact_id> <task_id> -
Assign new contact to all tasks by entering
unassign_contact <contact_id> <task_id>. -
Use case ends
MSS
-
Enter command to list calendars
-
See list of all calendars I have access to, including shared calendars
Use case ends
-
Disability friendly
-
colour scheme
-
compatibility with screen readers
-
on-screen keyboard
-
-
Infinitely scaleable (serverless backend on AWS Lambda-equivalent)
-
Support alternative (better, faster) forms of storage
-
Should work on any mainstream OS as long as it has Java 9 or higher installed.
-
Advanced analytics on tasks for work efficiency insights
-
Remove all \(n+1\) queries and \(\geq O(n)\) lookups
-
Mainstream OS
-
Windows, Linux, Unix, OS-X
-
-
Tasks
-
Text describing work to be done, may be attached to one or more contacts
-
-
Alternative storage
-
Local/Remote databses
-
-
Contact
-
Represents a person, with name, email, etc.
-
-
GitHub/GitLab/Bitbucket Issues
-
Bugzilla
-
Jira
-
Launchpad
-
Asana
-
Trello
-
Pen and paper
-
Email
-
Orgmode
-
Jolene: Contact transfer & Tasks Add
-
v1.1: Create basic task addition
-
v1.2: Change existing contacts commands to fit CowBae
-
v1.3: Refine task format
-
-
Julius: Tasks Edit Delete
-
v1.1: Delete
-
v1.2: Edit
-
v1.3: Batch delete
-
-
John: Tasks List Find
-
v1.1: Add task GUI & task list
-
v1.2: Task Find
-
v1.3: Pagination
-
-
Shaowei: Calendar Show
-
v1.1: Draw a grid with date numbers
-
v1.2: Fill in grid with contents
-
v1.3: Nice formatting
-
-
E-Liang: Assign Unassign
-
v1.1: Contacts Assign
-
v1.2: Task assign
-
v1.3: Task unassign, contacts unassign
-
Seize the means of production ! Supreme leader demands that everyone do their best