As the job climate is worsening, more and more students are not being able to find a job, and increasingly affiliated with mental health issues. This results in an increased workload from a larger number of patients to manage and appointments to schedule. CogniCare is a patient management system, designed to take care of SoC students who suffer from various mental health issues and concerns due to being unable to find internships or jobs.
CogniCare takes care of the load of many tedious tasks such as identifying today's appointments and measuring a patient's satisfaction progress levels over a period of time, until they are finally ready for discharge.
Refer to the guide Setting up and getting started.
Aspect: Patient ID
In any system that manages individual records, it is critical to ensure that we are able to distinguish between entities (which are patients) in our case.
Alternative 1: Using Integer ID as the primary key (Current Approach)
We needed some method to ensure that the patient was unique. The primary solution implemented involves a running integer identifier—which is saved together with each patient. The identifier serves as the primary key for the patient object, similar to how a unique ID in a database ensures each record's uniqueness.
This was different from how the AB3 application was originally designed—where the ID followed the natural ordering of the elements in the list.
Pros
Cons
Alternative 2: Using Name as the primary key
Alternative 3: Using Natural Ordering of the names in CogniCare application (AB3 approach)
Aspect: Search query with AND constraint
In enhancing the search functionality within CogniCare, the implementation of an AND constraint for search queries was paramount. This feature allows counsellors to refine search criteria, leading to more precise and relevant search results. For example, a counsellor can search for a patient using a combination of parameters (partial name AND partial phone number AND partial email address). It is to note that only one parameter is required; the others are optional.
This enhancement was driven by the need for:
Alternative 1: Single Criterion Search (AB3 Approach): The original AB3 approach of allowing search based on a single criterion was found to be too limiting for the different needs of patient management in CogniCare.
Alternative 2: Search Query with OR Constraint: While also considered, this approach was determined to potentially yield too broad of a search result, undermining the efficiency desired in retrieving patient record.
Aspect: Appointment ID
Alternative 1 (current choice): Generate auto-increasing fixed appointment ID when creating a new appointment. Fail commands that attempt to set the appointment ID still increase the appointment ID.
Alternative 2 (AB3 choice): No fixed appointment ID. AppointmentID is relative to the Appointment view.
Aspect: Where to store appointments locally
Alternative 1 (current choice): Store appointments in a separate file.
Alternative 2: Store appointments as a field in the Patient
class. Hence, all appointment data will be stored in the same file as the patientList
.
Aspect: How to store appointments
Alternative 1 (current choice): Store appointments as a AppointmentList
in Model
.
patientList
implementation.Alternative 2: Store appointments as a list of Appointment
objects in patientList
.
The Architecture Diagram given above explains the high-level design of the App.
Given below is a quick overview of the main components and how they interact with each other.
Main components of the architecture
Main
(consisting of classes Main
and MainApp
) is in charge of the app launch and shut down.
The bulk of the app's work is done by the following four components:
UI
: The UI of the App.Logic
: The command executor.Model
: Holds the data of the App in memory.Storage
: Reads data from, and writes data to, the hard disk.Commons
represents a collection of classes used by multiple other components.
How the architecture components interact with each other
The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command deletep 1
.
Each of the four main components (also shown in the diagram above),
interface
with the same name as the Component.{Component Name}Manager
class (which follows the corresponding API interface
mentioned in the previous point.For example, the Logic
component defines its API in the Logic.java
interface and implements its functionality using the LogicManager.java
class which follows the Logic
interface. Other components interact with a given component through its interface rather than the concrete class (reason: to prevent an outside component from being coupled to the implementation of a component), as illustrated in the (partial) class diagram below.
The sections below give more details of each component.
The API of this component is specified in Ui.java
The UI consists of a MainWindow
that is made up of parts e.g.CommandBox
, ResultDisplay
, ListPanel
, StatusBarFooter
etc. All these, including the MainWindow
, inherit from the abstract UiPart
class which captures the commonalities between classes that represent parts of the visible GUI.
The UI
component uses the JavaFX UI framework. The layout of these UI parts is defined in matching .fxml
files that are in the src/main/resources/view
folder. For example, the layout of the MainWindow
is specified in MainWindow.fxml
The UI
component,
Logic
component.Model
data so that the UI can be updated with the modified data.Logic
component, because the UI
relies on the Logic
to execute commands.Model
component, as it displays Patient
object residing in the Model
.API : Logic.java
Here's a (partial) class diagram of the Logic
component:
The sequence diagram below illustrates the interactions within the Logic
component, taking execute("deletep 1")
API call as an example.
Note: The lifeline for DeleteCommandParser
should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline continues till the end of diagram.
How the Logic
component works:
Logic
is called upon to execute a command, the command is passed to a CommandParser
object which in turn creates a parser that matches the command (e.g., DeletePatientCommandParser
) and uses it to parse the command.Command
object (more precisely, an object of one of its subclasses e.g., DeletePatientCommand
) which is executed by the LogicManager
.Model
when it is executed (e.g., to delete a patient).CommandResult
object which is returned back from Logic
.Here are the other classes in Logic
(omitted from the class diagram above) that are used for parsing a user command:
How the parsing works:
CommandParser
class creates an XYZCommandParser
(XYZ
is a placeholder for the specific command name e.g., AddPatientCommandParser
) which uses the other classes shown above to parse the user command and create a XYZCommand
object (e.g., AddPatientCommand
) which the CommandParser
returns back as a Command
object.XYZCommandParser
classes (e.g., AddCommandParser
, DeleteCommandParser
, ...) inherit from the Parser
interface so that they can be treated similarly where possible e.g., during testing.API : Model.java
The Model
component,
Patient
objects (which are contained in a UniquePersonList
object).Patient
objects (e.g., results of a search query) as a separate filtered list which is exposed to outsiders as an unmodifiable ObservableList<Patient>
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.UserPref
object that represents the user’s preferences. This is exposed to the outside as a ReadOnlyUserPref
objects.Model
represents data entities of the domain, they should make sense on their own without depending on other components)API : Storage.java
The Storage
component,
AppointmentListStorage
and UserPrefStorage
, which means it can be treated as either one (if only the functionality of only one is needed).Model
component (because the Storage
component's job is to save/retrieve objects that belong to the Model
)Classes used by multiple components are in the seedu.addressbook.commons
package.
This section describes some noteworthy details on how certain features are implemented.
Appointment is a new feature added to the app. It is a new entity that is related to a Patient
. An Appointment
object has the following attributes:
Appointment ID is a unique identifier for each appointment. It is generated by the system when a new appointment is created.
The Appointment Date Time is the date and time of the appointment.
The Patient ID is the unique identifier of the patient that the appointment is related to.
The Attended Status is a boolean value that indicates whether the patient has attended the appointment.
The Feedback Score is an integer value from 1 to 5 (inclusive) that indicates patient satisfaction.
The Appointment Description is a String that describes the appointment.
Appointments are stored in the Model
component as AppointmentList
which contains UniqueAppointmentList
object that is parallel similar to PatientList
storing UniquePatientList
.
The Model
component provides methods to add, delete, and retrieve appointments from AppointmentList
Appointment List is saved under a separate file appointmentList.json
in the data folder, apart from the patientList.json
file that stores the patientList
data.
The add patient feature is modified from the original AB3 which allows users to register new students as users and insert them into the application.
The add patient sequence diagram is displayed below:
Implementation: An observable list is used to store the list of appointments.
AddPatientCommandParser
obtains the values that correspond to the prefixes such as p/
, n/
, e/
, and a/
which represent phone, name, email address, and alias accordingly.
This class ensures that
a/
), but p/
, n/
, e/
may only appear once.If the constraints are violated, AddPatientCommandParser
will throw a ParseException
and log the invalid parameter passed into the function.
Otherwise, if the process is successful, a new Patient
object will be created to add the patient to the CongiCare application.
There are a few notable classes and methods that are used to interact with the add patient command:
AddPatientCommand
:
AddPatientCommand#execute()
AddPatientCommandParser#parse()
CommandException
if the specified patient is invalid. The new patient is only considered valid if it satisfies storing the required information in the required format.Alternatives Considered
The query patient command allows users to search for patients based on the given criteria. It makes use of the ListPatientCommandParser
which obtains the values that correspond to the criteria such as p/
, n/
, e/
, and a/
which represent phone, name, email address, and alias(es) accordingly, and combined with an AND
logic.
The diagram below shows the sequence diagram for querying patients:
The command for this operation is queryp
with at least one or zero parameters. If no parameters (or at least one invalid parameter is passed into the command), the queryp
command returns all the information of the patients (that is applied without any filters/predicates).
The ListPatientCommandParser
first checks for the presence of empty arguments / no prefix being specified. If this criterion is true, then all the patients are returned as normal. As such, this class does not throw any exceptions but just returns all the data in the CogniCare application even if the command is malformed (but reaches the ListPatientCommandParser
).
Otherwise, each of the search terms will be applied to each of the respective fields of the CogniCare application in a case-insensitive format.
Implementation There are a few notable features and methods that enable this feature.
Alternatives Considered
Patient
class will be less repetitive code as compared to the current approach (EmailContainsKeywordPredicate.java
, NameContainsKeywordPredicate.java
, PhoneContainsKeywordPredicate.java
, TagContainsKeywordPredicate.java
) which requires more (repetitive code) as compared to making a class such as StudentContainsKeywordPredicate.java
which would be easier to code - but harder to test and extend in future. Not to mention, this will also increase the difficulty in writing unit tests.AND
logic for combining predicates, instead of OR
predicate - the reason was that since the values already supported partial word matching (i.e. Searching for coco
in the String Coconut
will result in the row being returned). As such, using the OR
logic will lead to too many rows being returned and therefore confusing to the user.The edit command allows a user to update a patient's information if they relocate, change phone numbers, change email address, etc.
The diagram below shows the sequence diagram for editing a patient:
EditPatientCommandParser
obtains the patient index and the values that correspond to the prefixes such as p/
, n/
, e/
, and a/
which represent phone, name, email address, and alias accordingly.
a/
), but p/
, n/
, e/
may only appear once.If the constraints are violated, EditPatientCommandParser
will throw a ParseException
due to an invalid patient ID or invalid parameter being parsed.
Otherwise, if the process is successful, the current Patient
object corresponding to the respective ID will be updated with the edited information.
Implementation
There are a few classes and methods used to interact with the edit patient command.
EditPatientCommand
EditPatientCommand#execute()
CommandException
if the patient is not found, or if an invalid index is specified.EditPatientCommandParser#parse()
ParseException
is thrown if there are no parameters specified.EditPatientCommand
.Alternatives Considered
queryp
command before editing it.The delete patients feature allows users to remove patients from CogniCare (whether it is for privacy reasons etc).
The diagram below shows the sequence diagram for deleting patients:
DeletePatientCommandParser
obtains the patient index that is to be deleted.
Otherwise, if the process is successful, the current Patient
object corresponding to the respective ID will be updated with the deleted patient information containing the phone, email, respective affiliated-with, and linked appointment information.
Implementation
There are a few classes and methods used to interact with the delete patient command.
DeletePatientCommand
DeletePatientCommand#execute()
CommandException
if the patient is not found.DeletePatientCommand#parse()
DeletePatientCommandParser
will throw a ParseException
due to an invalid patient ID passed.DeletePatientCommand
Alternatives Considered
The add appointment feature allows users to create a new appointment and insert them into the application.
Below is the add appointment activity diagram.
Implementation An observable list is used to store the list of appointments.
There are a few classes and methods used to interact with the add appointment command.
AddAppointmentCommand
AddAppointmentCommand#execute()
AddAppointmentCommandParser#parse()
AddAppointmentCommandParser#parse()
AddAppointmentCommand.
Rationale for implementation There are a few key features that this module aims to implement
Alternatives considered
Appointment
. To standardise the implementation throughout the application, we decided to adopt the patient list implementation.
Therefore, each appointment has a unique identifier that does not change even when the natural order of the list is changed.The query appointment feature allows users to query appointments by specific fields through the use of patient ID or name or appointment ID. Querying by datetime is done via the filter appointment feature.
Below is the sequence diagram for querying appointments
And below is the activity diagram when a query appointment command is made
Implementation There are a few classes and methods that make this feature work
ListAppointmentCommand
- Command that is executedListAppointmentCommandParser
- Parses the command and performs the required validation checksRelationshipUtil
- In order to check that the specified patient ID is valid, we use a Util class which checks if a patient ID exists in a list of all patientsRationale for implementation
querya pid/999
and you see no appointments, you might assume that there is no appointment with the patient ID of 999, rather than there is no such patient ID in the first place
querya n/Tom
and no appointments are listed, this concludes that there is no appointment with the patient named "Tom".Alternatives considered
The edit appointment feature allows users to update appointment fields in case of any changes to the appointment details.
Below is the sequence diagram for editing an appointment.
Implementation There are a few classes and methods used to interact with the edit appointment command.
EditAppointmentCommand
EditAppointmentCommand#execute()
CommandException
if the appointment is not found.EditAppointmentCommandParser#parse()
ParseException
is thrown if there are no parameters specified.EditAppointmentCommand.
Rational for implementation
The delete appointment feature allows users to remove appointments from CogniCare.
Below is the activity diagram for deleting an appointment.
Implementation There are a few classes and methods used to interact with the delete appointment command.
DeleteAppointmentCommand
DeleteAppointmentCommand#execute()
CommandException
if the appointment is not found.DeleteAppointmentCommandParser#parse()
ParseException
is thrown if there are no parameters specified or the appointment index provided is not positive.DeleteAppointmentCommand
Rational for implementation
Alternative considered
deletea aid/APPOINTMENT_INDEX
. The appointment index prefix aid/
was deemed not necessary as it is very clear that this delete command only applies to appointments.The filter appointment feature allows users to filter appointments based on the date and time of the appointment.
Implementation A predicate was used to filter the list of appointments based on the date and time of the appointment. Criteria for filtering appointments:
StartDateTime
the appointment is before or at (<=) the specific startDateTime
of the predicateEndDateTime
the appointment is after or at (>=) the specific endDateTime
of the predicate
There are a few methods used to interact with the filter appointment command.FilterAppointmentCommand
FilterAppointmentCommandParser#parse()
FilterAppointmentCommandParser#parse()
ParserUtil#parseDateTime()
ParserUtil#parseEndDateTime()
and ParserUtil#parseStartDateTime()
ParserUtil#parseDateTime()
Rationale for implementation There are a few key features that this module aims to implement
Alternatives considered
Report patient feedback score is a feature that averages out the feedback scores of all currently filtered appointments. It allows getting the average scores of appointments within a given date range
The overall data flow of patient feedback data is detailed below using a class diagram.
Note: This class diagram doesn't represent the command flow, but rather, how patient feedback report data is stored and retrieved
Below is a sequence diagram of the user flow of the report command
Implementation
PatientFeedbackReport
- A model that contains information from both Patients and Appointments. It uses both data to determine which appointments to calculate the average fromPatientFeedbackReportList
- Contains a list of patient feedback reportsReportFeedbackCommand
- Reports the average feedback score for a given date rangeReportFeedbackCommandParser
- Parses ReportFeedbackCommand accordinglyFeedbackScore
- Contains a nullable Integer field. If it is null, then there is no rating for the appointment yetRationale for Implementation
ReportFeedbackCommand
, ReportFeedbackCommandParser
and PatientFeedbackReportList
was inspired from previous implementations of similar modelsFeedbackScore
because:
int
is not nullable, so we used a wrapper class insteadPatientFeedbackReport
is different from Appointment and Patient because it holds transient data and is dependent on data from the Patient and Appointment models.
PatientFeedbackReportList
does not have any direct list modification methods of its own. It only has a generateReportList function which is called every time there is an update to the list of patients or appointments, e.g., filter, add, edit or delete
generateReportList()
was called at the end of each of such functions inside ModelManager
Alternatives considered
PatientFeedbackReport
- We considered just passing the required fields; however, there were a few limitations
FeedbackScore
data representation
generateReportList()
functionality, however, it was scrapped because it was already implemented via the ObservableList
fields and implementing the pattern fully would not be worth the refactorCommand history is a feature that aims to improve the user experience for experienced users by allowing them to quickly navigate through their history of commands to make minor changes. Many features were inspired by macOS's Bash shell
Below is a general user flow of the command history
Note: The above diagram doesn't capture the audio playback feature because it's not a core part of the feature.
Below are the specific behaviours of the command history module
Undo
Redo
Implementation
An array list was used to store the history of commands and an index to indicate which command is the history currently at.
There are a few methods used to interact with the command history
getCurrentCommand()
- Gets the command at the current command indexundo()
- Decrements the current command index by 1
redo()
- Increments the current command index by 1Below shows the expected behaviour of the command history from a series of actions.
execute(args)
- when any command is executedundo()
- decrements the indexredo()
- increments the indexCommand | Command History |
---|---|
NA | [""] |
execute("help") | ["help", ""] |
undo() | ["help", ""] |
undo() | ["help", ""] |
redo() | ["help", ""] |
redo() | ["help", ""] |
undo() | ["help", ""] |
execute("query") | ["help", "query", ""] |
Rationale for implementation
There are a few key features that this module aims to implement
Alternatives considered
undo()
and redo()
both returned the previous and next command respectively - This had a flaw in which the logic of handling the command index became unnecessarily complex as we had to worry about when we incremented/decremented an index. This also made it harder to test the functionalityThe help feature provides users with a URL to the user guide online.
Rationale for implementation:
Alternative considered:
This details how the entries from the CogniCare application are cleared.
Target user profile: Rayson is a career guidance coach at the National University of Singapore (NUS) and is attached to the School of Computing (SoC) to provide computing students with career advice.
Recently there are many students that are unable to find an internship resulting in stress amongst the student population. This has led to SoC reducing the internship requirements (such as reducing stipend and allowing flexibility in internship periods). However, Rayson's manager, Aaron, thinks that more support needs to be done for the students.
Therefore, Aaron has launched a new initiative to provide counseling for computing students. To assist Rayson in managing the large number of potential students utilising this service, Aaron has employed the services of our team to allow Rayson to better manage the number of appointments.
Rayson is a technically inclined user (alumni of SoC) who is reasonably comfortable using CLI apps, and has the requirements of:
(Remark: Rayson and Aaron are both fictional characters)
Value proposition:
CogniCare provides a comprehensive set of features that help streamline especially tedious tasks such as:
Furthermore, CogniCare's operations are specialised for technically competent users who type fast.
Priorities: High (must have) - * * * *
, Medium (nice to have) - * * *
, Low (unlikely to have) - * *
, Not essential (implement only if got time) - *
Priority | As a … | I want to … | So that I can… |
---|---|---|---|
* * * * | Counsellor | create a new patient | store their data for future sessions. |
* * * * | Counsellor | view patient data | view their contact information and contact them. |
* * * * | Counsellor | delete patient data at a given index | discharge the patient. |
* * * * | Counsellor | search for patients | quickly access patients that come regularly. |
* * * * | Counsellor | schedule an appointment | avoid scheduling overlapping appointments with other patients. |
* * * * | Counsellor | view appointment data | view appointment data such as appointment description and scores. |
* * * * | Counsellor | delete an appointment | remove appointments I accidentally created. |
* * * * | Counsellor | search for all appointments for a specified patient | quickly view all appointments related to a student without having to remember the appointment ID or dates. |
* * * * | Counsellor | search for appointments by time range | quickly view all appointments within a date range. |
* * * * | Counsellor | update appointments | update appointment data after the appointment concluded. |
* * * * | Counsellor | track patient feedback scores over time | quickly identify which patients need more help. |
* * * | Counsellor | to categorise / tag my patients | patients with more serious issues can be attended to first. |
* * * | Counsellor | know what mistakes I make when creating patients | easily understand how to rectify my mistakes |
* * * | Counsellor | know what mistakes I make when creating appointments | easily understand how to rectify my mistakes |
* * * | New User | have a help function | so that I know how to use the application. |
* * | Experienced User | navigate through my history of successful commands | avoid retyping a command just to make minor modifications to a previous command. |
* | Experienced User | mass delete application data | sensitive data is not compromised. |
(For all use cases below, the System is the CogniCare
application and the Actor is the user
, unless specified otherwise)
Use case: UC01 - Add a Patient
MSS:
The user enters the command to add a patient with all mandatory information (Name, Email, Phone Number). Associated with is optional.
CogniCare validates the information is valid.
CogniCare saves the new patient information.
CogniCare displays a success message confirming that the new patient has been added.
Use case ends.
Extensions
1a. Required fields are left blank, or fields do not meet the specified format.
Use case ends
2a. Required fields are invalid (i.e. Phone Number does not meet SG format)
Use case ends
2b. Patient with the same name (regardless of case sensitivity and whitespace) already exists.
Use case ends.
Use Case: UC02 - Edit a Patient
MSS:
Use case ends.
Extensions
2a. The patient identifier does not match any patient in the system.
Use case ends.
3a. Required data fields are left blank or data is in the incorrect format.
Use case ends.
Use case: UC03 - List all / Search for patients meeting selected criteria / criterion
MSS:
User requests to list patients using the specified constraints
CogniCare shows a list of patients that meet the criteria
Use case ends.
Extensions
1a. The query has no parameters specified.
Use case ends.
1b. The query has no parameter value specified.
Use case ends.
2a. The list is empty.
Use case ends.
Use case: UC04 - Delete a patient
MSS:
The user list patients with certain criteria or no criteria.
User requests to delete a patient at the given index.
CogniCare deletes the patient.
CogniCare displays a successful message stating that the deletion was successful and displays information of the deleted patient.
Use case ends.
Extensions
2a. The query has a missing Id parameter.
Use case ends.
2b. The patient index is invalid.
Use case ends.
Use case: UC05 - Add an Appointment
MSS:
The user enters the command to add an appointment with all mandatory information.
CogniCare validates the information is valid.
CogniCare saves the new appointment information.
CogniCare displays a success message confirming that the new appointment has been added.
Use case ends.
Extensions
1a. Required fields are left blank, or fields do not meet the specified format.
1a1. CogniCare displays an error message associated with the relevant missing field.
Use case ends
2a. Required fields are invalid
2a1. CogniCare displays an error message associated with the relevant erroneous field
Use case ends
2b. Appointment timing clashes with an existing appointment.
2b1. CogniCare alerts the user about the clash and prevents the addition.
Use case ends.
Use Case: UC06 - Edit an Appointment
MSS:
The user list appointments with certain criteria or no criteria.
User enters command to edit appointment with required index and data field to be edited.
CogniCare displays a success message confirming the appointment details have been updated.
Use case ends.
Extensions
2a. The appointment identifier does not match any appointment in the system.
Use case ends.
3a. Required data fields are left blank or data is in the incorrect format.
Use case ends.
Use case: UC07 - Search appointments
MSS:
User requests to list all appointments using some criteria.
CogniCare shows a filtered list of appointments that meet the criteria.
Use case ends.
Extensions
1a. The query has no parameters specified.
Use case ends.
1b. The query specifies a prefix, but no value, e.g. querya n/
.
Use case ends.
Use case: UC08 - Delete a specific appointment
MSS:
User lists appointments with certain criteria or no criteria.
User requests to delete an appointment at the given appointment index.
CogniCare deletes the appointment.
Use case ends.
Extensions
2a. The query has missing parameters
2a1. CogniCare shows an error message.
Use case ends.
2b. The appointment index is invalid.
2b1. CogniCare displays an error message that the index is invalid. (No deletion is done)
Use case ends.
Use case: UC09 - Filter appointment in a date time range
MSS:
User requests to filter appointments based on the date and time range.
CogniCare shows a list of appointments that meet the criteria and success messages.
Use case ends.
Extensions
1a. The query has missing parameters
Use case ends.
1b. The query has incorrect parameters
Use case ends.
2a. The list of appointments is empty.
Use case ends.
Use case: UC10 - Report patient feedback over a given time period
MSS:
User requests to view all feedback scores from a given start date to a given end date
Feedback scores are updated to get the average of all appointments within the given time period
Use case ends.
Extensions
1a. User specifies the start date only
1a1. All appointments from the specified start date to the end of time are returned
Use case resumes from step 2
1b. User specifies the end date only
1b1. All appointments from the beginning of time to the specified end date are returned
Use case resumes from step 2
1c. User specifies neither the end or the start date
1c1. All appointments are returned
Use case resumes from step 2
1d. The date specified is in an incorrect format
1d1. Invalid format exception message is shown to the user
Use case ends
Use case: UC11 - Getting the previous command entered
MSS:
User executes any command.
User presses the Up arrow key to view his last command
User modifies his last command
User executes the modified command
User presses the Up arrow key and sees his last modified command
Use case ends.
Extension
2a. User presses the Up arrow key again
2a1. A sound is played indicating that there is no previous command
Use case resumes from step 3.
3a. User modifies the command, and without executing it, presses the Down arrow key, followed by the Up arrow key
3a1. The command before modification is shown because the modified command is not yet executed
Use case resumes from step 3
Use case: UC12 - Getting the next command entered
MSS:
User types in and executes any 2 commands.
User presses the Up arrow key twice to view his first command
User presses the Down arrow key to view his second command
Use case ends.
Extension
3a1. An empty string is returned
Use case ends.
11
or above installed.Given below are instructions to test the app manually.
Note: These instructions only provide a starting point for testers to work on;
Testers are expected to do more exploratory testing.
Ensure you have Java 11
or above installed on your Computer.
If you are on macOS on an Apple Silicon System, we recommend that you follow the guide on CS2103 Course website using the Zulu version zulu11.50.19-ca-fx-jdk11.0.12-macosx_aarch64.dmg
If you are on Windows / Intel architecture, most versions of Java 11 should work.
Download the latest cognicare.jar
from here.
Copy the file to the folder you want to use as the home folder for your CogniCare application.
Open a command terminal, cd
into the folder you put the jar file in, and use the java -jar cognicare.jar
command to run the application.
Expected: A GUI containing the sample patient list below should appear in a few seconds. Note that the app contains some sample data. You may need to re-scale the window size to suit your computer display.
Pre-requisite:
Command: queryp
Expected Output:
Expected Output in the Command Output Box:
Listed all persons
Tip: If there are no patients stored in the CogniCare application, then an empty ListView will be displayed.
Pre-requisite:
Command: queryp n/Jerome p/123
p/
: phone numbern/
: namee/
: email addressa/
: associated with
tag
queryp a/depression
Expected Output:
Expected Output in the Command Output Box:
Listed all persons
Tip: If there are no patients stored in the Application, or if there are no data that meets the required criteria, an empty ListView will be displayed
Pre-requisite:
Command: addp n/John Doe p/98765432 e/johnd@example.com a/Johnny a/owesMoney
p/
: phone numbern/
: namee/
: email addressa/
: associated with
tagExpected Output:
ListView
will be updated with the latest patient data.Expected Output in the Command Output Box:
New student added: John Doe; Phone: 98765432; Email: johnd@example.com; Associated with: [owesMoney][Johnny]
Pre-requisite:
patientId
) of the person that you are trying to edit.Command: editp 26 n/Jerome Chua
p/
: phone number
n/
: name
e/
: email address
a/
: associated with
the tagExpected Output:
ListView
will be updated with the latest patient data.Expected Output in the CommandBox: Edited Person: Bernice Yu; Phone: 91234567; Email: johndoe@example.com; Associated with: [jobless][anxiety]
ListView
will be updated with the latest patient data.Tip: The patient identifier that is commonly referred to in this article refers to the patient id that is permanently tagged to each patient and is not the index of the natural ordering in the list.
Pre-requisite:
patientId
) of the person that you are trying to delete.Command: deletep 26
Expected Output:
ListView
will be updated with the latest patient data.Expected Output in the CommandBox: Deleted Patient: Grace Lim; Phone: 83456789; Email: gracelim@outlook.com; Associated with: [anxiety][stress]
ListView
will be updated with the latest patient data (which removes the deleted patient).Pre-requisite:
Command: adda pid/1 sd/2024-04-04 09:00 ed/2024-04-04 10:00 att/true s/5 ad/This is a dummy appointment
pid/
: patient idsd/
: appointment start date and timeed/
: appointment end date and timeatt/
: attended statuss/
: feedback scoread/
: appointment descriptionExpected Output:
ListView
will be updated with the latest appointment data.Expected Output in the Command Output Box:
New appointment added: (Appointment index); PatientId: 1; Start: 04 Apr 2024, 09:00 am; End: 04 Apr 2024, 10:00 am; Attend: true; Score: 5; Description: This is a dummy appointment
Tip: The appointment identifier is permanently tagged to the appointment and is not the index of the natural ordering in the list.
Pre-requisite:
appointmentId
) of the person that you are trying to edit.Command: edita 3 pid/2
pid/
: patient idsd/
: appointment start date and timeed/
: appointment end date and timeatt/
: attended statuss/
: feedback scoread/
: appointment descriptionExpected Output:
ListView
will be updated with the latest appointment data.Expected Output in the CommandBox: Edited Appointment: 3; PatientId: 2; Start: 10 Oct 2021, 12:30 pm; End: 10 Oct 2021, 02:59 pm; Attend: true; Score: 5; Description: Third appointment
ListView
will be updated with the latest appointment data.Remember: The appointment identifier that is commonly referred to in this article refers to the appointment id that is permanently tagged to each appointment, and is not the index of the natural ordering in the list.
Pre-requisite:
appointmentId
) of the appointment that you are trying to delete.Command: deletea 4
Expected Output:
ListView
will be updated with the latest appointment data.Expected Output in the CommandBox: Deleted Appointment: 4; PatientId: 1; Start: 10 Nov 2021, 10:10 am; End: 10 Nov 2021, 10:59 am; Attend: false; Score: 4; Description: Fourth appointment
ListView
will be updated with the latest appointment data (which removes the deleted appointment).Pre-requisite:
Command: querya
Expected Output:
Expected Output in the Command Output Box:
Listed all appointments
Tip: If there are no appointments stored in the Application, then an empty ListView will be displayed.
Pre-requisite:
Command: querya n/Alex
n/
: patient namepid/
: patient indexaid/
: appointment indexExpected Output:
Expected Output in the Command Output Box:
(n) appointments listed!
Tip: If there are no appointments stored in the application, or if there are no data that meets the required criteria, an empty ListView will be displayed.
Pre-requisite:
Command: filter sd/2021-10-10 12:00
sd/
: start date and timeed/
: end date and timeExpected Output:
Expected Output in the Command Output Box:
(n) appointments listed!
Pre-requisite:
Command: reportf
Expected Output:
Expected Output in the Command Output Box:
Generated patient feedback report from the beginning of time to the end of time
Pre-requisite:
Command: reportf sd/2021-10-11
sd/
: start dateed/
: end dateExpected Output:
Expected Output in the Command Output Box:
Generated patient feedback report from 11 Oct 2021 to the end of time
Note: The reportf
command only requires the start and/or end date in the format yyyy-MM-dd
. This command does not take in any time.
Pre-requisite:
Testing method:
Expected output:
Expected Output in the Command Output Box:
v1.4
)This section describes the potential enhancements that could be improved in future editions of the application.
JSON
files. Currently, adding non-legible value like null
will cause the app to not launch. A future enhancement will include more validation checks, allowing skipping of non-legible data and detecting invalid data upon launching the app.editp
command to change the name of a patient, the appointment cards in the appointment list do not reflect the new name of that patient. Hence, a future enhancement will include changing the flow of how the appointment card is generated, enhancing the interactions between GUI and models, and allowing the GUI to reflect the current state of data.The implementation of the CogniCare application was an extremely challenging endeavour as we needed to morph and reshape the AB3 application in a team-based setting. The transformation process involved significant alternations and enhancements to reach the new requirements of the application.
The team-based setting also exposed us to various crucial skills such as improving our working styles to achieve a high level of collaboration. Skills that are crucial to a Software Engineer such as reviewing Pull Requests (PRs), and providing and receiving feedback from peers are also learned in the course of the project.
Code base adapted from Address Book Level-3 GitHub Copilot was used as an autocomplete tool to assist in writing parts of the documentation and diagrams by @vnnamng, @tankh99.