By: Team SE-EDU Since: Jun 2016 Licence: MIT
Refer to the guide here.
The Architecture Diagram given above explains the high-level design of the App. Given below is a quick overview of each component.
|
💡
|
The .puml files used to create diagrams in this document can be found in the diagrams folder.
Refer to the Using PlantUML guide to learn how to create and edit diagrams.
|
-
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.
The following class plays an important role at the architecture level:
-
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 with each other for the scenario where the user issues the command delete 1.
delete 1 commandThe sections below give more details of each component.
API : Ui.java
The UI consists of a MainWindow that is made up of parts e.g.CommandBox, ResultDisplay,
PersonListPanel, Page etc. All these, including the MainWindow,
inherit from the abstract UiPart class.
The UI component uses JavaFx UI framework. The layout of these UI parts are 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
Overall, the UI component,
-
Executes user commands using the
Logiccomponent. -
Listens for changes to
Modeldata so that the UI can be updated with the modified data.
The Page UiPart, as contained by MainWindow, is the key component that reflects the differences
in the data displayed across different pages of the application.
Each class extending Page is able to implement its various components and root JavaFX node types
separately, allowing for much flexibility in terms of the different user interfaces of the pages.
Due to its flexibility, the Page abstract class is mainly only responsible for :
-
Providing its child classes with the supporting instances of
ModelandMainWindowin order to,-
populate the classes' components with data
-
execute commands from the user interface, outside of the
CommandBox(e.g. an add button).
-
-
Providing a way to execute any callback function (such as one to update display data), through use of the abstract method
fillPage. ThefillPagemethod is registered insideMainWindow, such that it runs after each command execution.
API :
Logic.java
-
Logicuses theAddressBookParserclass to parse the user command. -
This results in a
Commandobject which is executed by theLogicManager. -
The command execution can affect the
Model(e.g. adding a person). -
The result of the command execution is encapsulated as a
CommandResultobject which is passed back to theUi. -
In addition, the
CommandResultobject can also instruct theUito perform certain actions, such as displaying help to the user.
Given below is the Sequence Diagram for interactions within the Logic component for the execute("delete 1") API call.
delete 1 Command|
ℹ️
|
The lifeline for DeleteCommandParser should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
|
API : Model.java
The Model,
-
stores a
UserPrefobject that represents the user’s preferences. -
stores the Address Book data.
-
exposes an unmodifiable
ObservableList<Person>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.
|
ℹ️
|
As a more OOP model, we can store a Tag list in Address Book, which Person can reference. This would allow Address Book to only require one Tag object per unique Tag, instead of each Person needing their own Tag object. An example of how such a model may look like is given below.
|
API : Storage.java
The Storage component,
-
can save
UserPrefobjects in json format and read it back. -
can save the Address Book data in json format and read it back.
This section describes some noteworthy details on how certain features are implemented.
Editing of trip/day/event can be accessed from TripsPage/DaysPage/EventsPage respectively. The
The execution of commands in the each page is facilitated by TripManagerParser/DayViewParser/EventViewParser and respectively.
They extends from PageParser class which serves as the abstraction for all parsers related to each Page.
The operations are exposed to the Model interface through the Model#getPageStatus()
method that returns the PageStatus containing the current state of application.
Given below is an example usage scenario and how the program behaves at each step.
Step 1. When the user launches the application. The PageStatus is initialized under along with other Model components. PageStatus at launch does not contain any EditTripDescriptor/EditDayDescriptor/EditEventDescriptor responsible for storing information for the edit.
Step 2. The user currently on the TripsPage/DaysPage/EventsPage is displayed a list of Trip/Day/Event respectively. The user executes the edit command EDIT1 using the OneBasedIndex on the list to edit it.This executes the EnterEditTripFieldCommand/EnterEditDayFieldCommand/EnterEditEventFieldCommand that initializes a new descriptor within PageStatus before switching over to the EditTripPage/EditDayPage/EditEventPage containing to perform the editing.
Step 3. The user is now on the edit page displaying a list of fields that the user can edit in the Trip/Day/Event.
The following is an example list of commands available in DaysPage and the execution of the program when a field is edited in DaysPage:
-
edit n/<name> ds/<startDate> de/<endDate> b/<totalBudget> l/<destination> d/<description>- Edits the relevant fields -
done- Completes the edit and returns to the Overall View -
cancel- Discards the edit and returns to the Overall View
The user executes the command edit n/EditedName on the DaysPage. The command creates a new descriptor from the contents of the original, replacing the fields only if they are edited. The new descriptor is then assigned to PageStatus replacing the original EditDayDescriptor. The result of the edit is then displayed to the user.
Step 4. The user has completed editing the Trip/Day/Event and executes done/cancel to confirm/discard the edit. The execution of the two cases are as follows:
-
The user executes
doneto confirm the edit. This executes theDoneEditTripCommand/DoneEditDayCommand/DoneEditEventCommandand aTrip/Day/Eventis built from the descriptor respective to the type it describes.DayList#set(target, edited)proceeds to be executed which accesses theDayto edit from thedayfield inPageStatusas the target. The method replaces the original day with the newly built day from the descriptor. The descriptor inPageStatusis then reset to contain empty fields.
-
The User executes
cancelto discard the edit. This executes theCancelEditTripCommand/CancelEditDayCommand/CancelEditEventCommandwhich resets the descriptor inPageStatusto contain all empty fields.
Upon completion of the edit, the user is returned to the TripPage/DaysPage/EventsPage depending on where the user entered the edit page from.
Below is an sequence diagram illustrating the execution of the command "edit ds/10/10/2019":
The UI for to edit fields are associated with the EditTripPage/EditDayPage/EditEventPage respectively.
The diagram above shows the EditTripPage of the 3 pages and how it displays its contents. All the pages extend the Page class and contains several FormItems. These pages classes can also navigate to the Model and Logic interfaces through the ModelManager and LogicManager class respectively.
The FormItems (e.g. DateFormItem) are instantiated by the EditTripPage#initFormWithModel method called by the constructor of EditTripPage . Each FormItem contains an executeChangeHandler that executes whenever the onChange property is modified by the user. These are initialized as execution of the various edit commands (e.g. EditTripFieldCommand/EditDayFieldCommand/EditEventFieldCommand) using the value in the FormItem.
The contents of the fields are updated by the execution to the commands above. When the user edits any of the FormItems, the commands are executed which will cause the EditTripPage/EditDayPage/EditEventPage#fillPage() to execute again. fillPage retrieves the updated fields from PageStatus and displays them as the values in the FormItems.
The logic of editing a field and committing it to memory is a simple process of validating each field. If any field fails to meet the specifications, the Trip/Day/Event will not be created/edited. Below is an example execution of validating the edit:
Deletion of Trip/Day/Event is facilitated by PageStatus. PageStatus stores the current state of execution of the user program.
Upon initial startup of the program Model is initialized with PageStatus with the PageType set to enum PageType#TRIP_MANAGER. This indicates the current page displayed to the user. PageStatus is initialized with empty references to the Trip/Day/Event the user executes an action for.
Step 1. When the user launches the application. PageStatus is initialized along with other Model components with empty references.
Step 2. The user enters the DaysPage/EventsPage using the goto command. This instantiates a new PageStatus object from the the existing PageStatus with a modified Day/Trip, providing the context for subsequent actions. Below is an example execution of the command:
Step 3. The user is now on the TripManager/DaysPage/EventsPage, the user can execute the delete command in accordance to the display ordered index on any of the aforementioned pages.
When the command delete <index> is executed, DeleteTripCommand/DeleteDayCommand/DeleteEventCommand is executed. This command accesses Trip/Day reference in PageStatus assigned by the previous step. (Note: deleting Trips do not require PageStatus, it being directly accessible to Model using TripList accessors).
The Day/Trip reference contains the list of Events/Days in memory respectively (DayList/EventList). DayList#remove/EventList#remove are methods in the respective list classes used to delete the day/event. These are executed, modifying the in memory TravelPal and Trip/Event/Day is removed.
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 lifeline for UndoCommand should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
|
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 photo manager pertains to components for storing, and displaying user specified photos on the disk.
PhotoList as contained by a diary entry, and its contained modelsThe model for a photo stored in memory is stored in the DiaryPhoto class.
It contains three key fields, that is, the imagePath, description, and dateTaken fields which are used to display key information of the image to the user.
The imagePath and dateTaken were implemented respectively with the robust java apis of Path and LocalDateTime, while description is simply a String.
In addition, a JavaFX Image is also stored inside the DiaryPhoto (not shown in Figure 11, “Class diagram of a PhotoList as contained by a diary entry, and its contained models” for brevity),
which holds the Image to use for displaying in an ImageView inside the user interface. The Image is cached this way,
as the Image construction directly in the user interface involves costly I/O operations.
|
ℹ️
|
Restrictions on fields during
|
On the other hand, the DiaryPhoto models are contained within a PhotoList. It stores the photos in a JavaFX ObservableList,
so that changes are registered with the user interface. (see Section 3.6.2, “Aspect: User interface of photo manager”)
It also supports several convenience wrapper methods around the underlying ObservableList, tailored for use for the logic components.
The main UiPart component that displays photos is the DiaryGallery.
It abides by the Page implementation (see Section 2.2.1, “Page API”), and is thus contained within,
in one of DiaryPage’s placeholders.
DiaryPage (not shown)The main JavaFX component responsible for displaying the photos is a ListView<DiaryPhoto> component.
The ListView obtains its data from the PhotoList of
the DiaryGallery, which is automatically observed by the ListView.
Hence, changes in the PhotoList, such as the addition of a DiaryPhoto are immediately communicated
to the user interface.
The ListView uses a simple custom cell factory, which sets the ListCells of the ListView to use DiaryGalleryCards
as its graphic. DiaryGalleryCards are in turn generated in the cell factory using the ListCell’s index and a DiaryPhoto instance.
DiaryGalleryCards display the information as supplied by the DiaryPhoto model using a series of Labels and one ImageView.
Additionally, the index of the card as ordered in the DiaryGallery is also displayed, but not stored in the model.
The logic for photo manager plays to the same PageParser structure of parsing commands, that is,
DiaryParser returns either AddPhotoParser, DeletePhotoParser when the appropriate command word is parsed, which
in turn returns instances of AddPhotoCommand and DeletePhotoCommand respectively.
Following DiaryParser returning an instance of AddPhotoParser that calls parse() on the user specified arguments,
a number of operations happen, as per the UML sequence diagram below ([AddPhotoParser parse sequence diagram]). The specifics of getFilePath,
parseDescription, parseDateTime are detailed further down below.
-
Using
ArgumentMultimap, the file chooser prefix, "fc/", is checked for. If present, the OS file choosing gui is opened usingImageChooser(a simple extension of JavaFX’sFileChooserenforcing image file extensions), and the data file path prefix is ignored. -
Otherwise, the presence of the data file prefix is checked, and its subsequent argument is validated as a valid image file.
-
If the file chooser prefix is unspecified and the data file path is invalid,
AddPhotoParserthrows aParseException
-
If the description prefix is present,
AddPhotoParsertries to construct theDiaryPhotoinstance with the specified input. If validation of the description, as described in the Section 3.6.1, “Aspect: Models” fails, then a ParseException is thrown during the instance construction. -
Otherwise, the file name of the validated file from Section 3.6.3.1.1, “Parsing the image file path” (truncated to match
DiaryPhoto’sdescription constraints) is used.
-
If the date time prefix is present,
ParserDateUtilis used to parse the date time as per the app level date formats. AParseExceptionis automatically thrown in the case of date parsing failure, byParserDateUtil. -
Otherwise, the last modified date of the validated file from Section 3.6.3.1.1, “Parsing the image file path” is used.
The DiaryPhoto instance is then constructed, and passed to AddPhotoCommand which simply adds the DiaryPhoto to the
current PhotoList of the DiaryEntry.
Following DiaryParser parsing the 'delphoto' command from the user, an instance of DeletePhotoParser is created, which parses the received arguments.
-
The
DeletePhotoParsersimply parses the arguments for a valid integer, failing which aParseExceptionis thrown. -
An instance of
DeletePhotoCommandis returned, which attempts a delete operation on the currentPhotoListof theDiaryEntrywith the specified index. ACommandExceptionis thrown to alert the user if the index was out of bounds.
| Feature | Alternative 1 | Alternative 2 |
|---|---|---|
Validation of image file path |
The first option is to implement the file path validation directly inside the This would have enforced a stricter level of validation on the image file path throughout the code,
if an instance of However, since the storage model for |
The second, chosen option, was to implement the file path validation inside the parser itself. Although this option limited the validation to only the 'addphoto' command, it allowed for leeway in
image path validation in other areas such as Moreover, Since the function for parsing the image file can and was abstracted into a single utility function, any other areas in future development needing this functionality can simply reuse this code. Overall, this leads to a more robust behaviour of the application, while providing the same level of extensibility as the first option. |
The diary entry is capable of displaying text with inline images, or lines consisting of only images.
There are two primary facets of input styles to this feature, one being commands that edits a part or the whole of the entry through the command line input, and the other being the JavaFX text editor.
The main model abstraction holding the data of an entry is the DiaryEntry class.
It stores three key fields, namely:
1. An Index denoting the day the entry is for
2. A String written by the user in the domain specific language (see Section 3.7.2.1, “Entry text parsing”) required by the user interface.
3. A PhotoList storing the photos of the entry, as described in Section 3.6.1, “Aspect: Models”.
The DiaryEntry models are contained within a DiaryEntryList, which enforces the uniqueness of the Index (denoting the day index)
of each DiaryEntry, and supports common list operations.
As one of the desired specifications of our application was to allow the user commands, and edits made directly to the edit box
to be non final until the done command is executed, a separate buffer model, EditDiaryEntryDescriptor, was needed to store the edit information.
This buffer model stores the same PhotoList and Index as the initial DiaryEntry it is constructed from,
but the diary text references a different String, that is, the buffered diary text String.
Multiple UiPart components come into play in displaying the diary entry.
However, Page implementation (see Section 2.2.1, “Page API”) is still followed, and all components are thus contained within,
in one of DiaryPage’s placeholders.
|
ℹ️
|
In the diagram above, all parts and subparts of the composition of DiaryPage extend from UiPart, although not shown.
|
The DiaryEntryDisplay is the component responsible for displaying the content of the DiaryEntry model.
Internally, it uses a JavaFX ListView<CharSequence> with a custom cell factory that
returns DiaryTextLineCell (as detailed in Section 3.7.2.1.3, “Graphic of ListView cells in DiaryEntryDisplay”). DiaryTextLineCells in turn uses the
DiaryLine UiPart as its graphic.
In both facets of input styles, special entry text parsing is required to display the various formats of lines, and dynamic text updates that occur when the text in the text editor is changed should propagate to the display immediately.
To accomplish this, the internal ListView is set to observe the paragraphs of the DiaryEditBox, which is done in the
constructor of DiaryEntryDisplay during the initialisation of DiaryPage.
The two facets of inputs dictate two separate ways the paragraphs can change.
In this case, the edits to the TextArea input in DiaryEditBox are immediately propagated to the observable paragraphs, since the
ListView was set to observe the same list provided by DiaryEditBox.
-
The
modelis updated, depending on whether the edit box is currently shown to the user.
1.1. The edited but uncommitted text stored in the currentEditDiaryEntryDescriptorwill be updated if the edit box is shown. (second branch in the diagram Figure 18, “Sequence diagram of updating of DiaryPage UI post command execution”)
1.2. Otherwise, the currentDiaryEntryin thePageStatusof themodelis updated immediately. (first branch in the diagram Figure 18, “Sequence diagram of updating of DiaryPage UI post command execution”) -
The text in the
DiaryEntryEditBoxis then refreshed with the updatedmodelin thefillPagecallback function executed byMainWindow(as per thePageapi), resulting in the changes reflecting in the observable paragraphs.
The ListView of DiaryEntryDisplay uses a custom cell factory and cell implementation, that is, DiaryTextLineCell.
Once the data has been updated in the above two ways, the ListView receives the notification for which cell(s) to update.
The parsing is done in the inner class DiaryTextLineCell based on the text line received, using a
customised regex pattern. DiaryTextLineCell then creates new instances of DiaryLines
based on the parsed input, setting them as the graphic for the ListCell.
|
ℹ️
|
For DiaryLines with photos, the parsing process uses the photoList as set in the DiaryPage’s
fillPage method. (see branch 1 in Figure 18, “Sequence diagram of updating of DiaryPage UI post command execution”)
|
Numerous design decisions and comprimised had to be made due to the desired specifications of text editing and displaying.
Specifically, the following had to be achieved :
-
Changes to text in the
DiaryEntryEditBoxmust reflect immediately in theDiaryEntryDisplayto provide visual cue to the user. -
While the
DiaryEntryEditBoxis active, commands that edit the entry must behave like they edit theDiaryEntryEditBoxdirectly. That is, the changes should not be committed immediately. -
In general, where mentioned below, performance was favoured because of how a singular diary line can present both multimedia and text to the user, which puts a considerable strain on the system.
| Aspect | Option | Implementation |
|---|---|---|
Updating of UI |
1 |
The first option was to abide by the However, this implies updating all Alternative 2 attempts to solve this performance bottleneck. |
2 |
The second option, was to implement the diary text in For user commands, this solves the problem posed by alternative 1, since user commands can make edits only where needed in
the However, this meant that user edits to the Hence, one solution was to add a separate listener to the |
|
3 |
The last option was to set the Edits to the paragraphs in the On the other hand, edits using commands would reflect in the UI through setting the text
of the A hybrid solution built upon alternatives 2 and 3 was also considered, in that the
Having considered the performance impacts of alternatives 1 and 2, and the desired specifications of the application, the chosen solution was thus alternative 3. |
|
High level composition of |
1 |
The first solution to was to make Although it supports various apis to format and position text, displaying multimedia with it required
complex parsing logic of the Moreover, the parsing would be re run on the entire text of the |
2 |
The second solution is to use a wrapper ( On one hand, this increases extensibility, as the the graphic of a Secondly, |
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.9, “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
Refer to the guide here.
Refer to the guide here.
Refer to the guide here.
Target user profile:
-
Has a need to manage multiple trips
-
Prefers using a notebook to other types
-
Frequently uses the computer while overseas
-
Wants to micromanage all parts of their trips
-
Wants to plan all details of the trip before leaving
-
Wants to manage a trip even without an internet connection
Value proposition: Able to micromanage a trip and access one’s plans more conveniently than traditional forms of trip planning
Use case: UC1 - Add Trip
MSS
-
User requests to Trip Manager to list trips
-
TravelPal shows a list of Trips
-
User requests to add a specific Trip to the list
-
User <span class="underline">edits the Trip (UC2)</span>
-
TravelPal adds the Trip
-
TravelPal shows the list of Trips. Use case ends.
Extensions
5a. The trip added clashes with another trip
5a1. TravelPal shows an error message
5a2. TravelPal does not discard information the user has provided
5a3. TravelPal displays the Edit Trip page containing the user’s previous input
5a4. TravelPal requests the user to change the dates of the Trip
Steps 5a1-5a2 are repeated until no clashes occur between trips
<span class="underline">Use case: UC2 – Edit Trip</span>
MSS
-
User chooses to edit specific Trip
-
Travelpal shows Edit Trip Screen with fields to edit/enter
-
User edits the information in the specified Trip
-
User submits the details and confirms the edit. Use case ends.
Extensions
3a. User enters an invalid field
3a1. TravelPal shows an error message
3a2. TravelPal does not edit invalid field
Use case continues at step 2
3b. User requests to list of Days in the trip
3b1. TravelPal shows a list of days to the user (can be empty)
3b2. User chooses to <span class="underline">add/edit/delete (UC4/5/6) Day</span>
Use case continues at step 4
4b. User leaves necessary information empty
4a1. TravelPal shows an error message
4a2. TravelPal does not submit the details and does not confirm the edit
4a3. User enters new data
Steps 4a1-4a3 are repeated until the data entered are non empty
Use case ends.
Use case: UC3 – Delete Trip
MSS
-
User requests to Trip Manager to list Trips
-
TravelPal shows a list of Trips
-
User requests to delete a specific Trip in the list
-
TravelPal deletes the Trip
Use case ends ` Extensions
2a. The list is empty
Use case ends
3a. The Name provided is invalid
3a1. TravelPal shows an error message
3a2. TravelPal does not delete any trips
Use case ends
Use case: UC4 – Add Day
MSS
-
User chooses to add a Day to a specified Trip
-
User edits the day (UC5)
-
TravelPal saves the Day
Extensions
3a Day added clashes with other days in the Trip
3a1. TravelPal shows an error message
3a2. TravelPal does not discard information the user has provided
3a3. TravelPal displays the Edit Day page containing the user’s input
3a4. TravelPal requests the user to change the date of the Day
Steps 3a1 – 3a4 are repeated until the user provided non clashing date
Use case: UC5 – Edit Day
MSS
-
User requests to edit specific Day
-
TravelPal shows the Edit Day page with fields to enter
-
User edits information in the specified Day
-
User submits and confirms the edit
Use case ends
Extensions
3a. User enters an invalid field
3a1. TravelPal shows an error message
3a2. TravelPal does not edit invalid field
Use case continues at step 2
3b. User requests to list of Events in the trip
3b1. TravelPal shows a list of Events to the user (can be empty)
3b2. User chooses to add/edit/delete (UC 7/8/9) Event
Use case continues at step 4
4b. User leaves necessary information empty
4a1. TravelPal shows an error message
4a2. TravelPal does not submit the details and does not confirm the edit
4a3. User enters new data
Steps 4a1-4a3 are repeated until the data entered are correct
Use case ends.
User case: UC6 – Delete Day
MSS
-
User requests to delete a specific Day in the list
-
TravelPal deletes the Day
Use case ends
Extensions
2a. The list is empty
Use case ends
3a. The Name provided is invalid
3a1. TravelPal shows an error message
3a2. TravelPal does not delete any Day
Use case ends
User case: UC7 – Add Event
MSS
-
User chooses to add a Event to a specified Day
-
User edits the event (UC5)
-
TravelPal saves the Event
Extensions
3a Event added clashes with other Events in the Day
3a1. TravelPal shows an error message
3a2. TravelPal does not discard information the user has provided
3a3. TravelPal displays the Edit Event page containing the user’s input
3a4. TravelPal requests the user to change the date of the Event
Steps 3a1 – 3a4 are repeated until the user provided non clashing date
User case UC8 – Edit Event
MSS
-
User requests to edit specific Day
-
TravelPal shows the Edit Day page with fields to enter
-
User edits information in the specified Day
-
User submits and confirms the edit
Use case ends
Extensions
3a. User enters an invalid field
3a1. TravelPal shows an error message
3a2. TravelPal does not edit invalid field
Use case continues at step 2
3b. User requests to list of Events in the trip
3b1. TravelPal shows a list of Events to the user (can be empty)
3b2. User chooses to add/edit/delete (UC 7/8/9) Event Use case continues at step 4
4b. User leaves necessary information empty
4a1. TravelPal shows an error message
4a2. TravelPal does not submit the details and does not confirm the edit
4a3. User enters new data
Steps 4a1-4a3 are repeated until the data entered are non empty
Use case ends.
User case UC9 – Delete Event
MSS
-
User requests to delete a specific Event in the list
-
TravelPal deletes the Event
Use case ends
Extensions
2a. The list is empty
Use case ends
3a. The Name provided is invalid
3a1. TravelPal shows an error message
3a2. TravelPal does not delete any Event
Use case ends
-
Should work on any [mainstream OS] as long as it has Java 11 or above installed.
-
A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
-
Should be able to hold up to 30 trips without a noticeable sluggishness in performance for typical usage.
-
A user familiar with travelling should be able to navigate the app easily
-
A novice user should be able to navigate without prior experience
-
Application does not depend on online resources to operate
-
Products is not required to make decisions for the user
TravelPal – Our cross-platform desktop application for those who love to plan and micromanage their travels
CLI – Command Line Interface. CLI is a command line program that accepts text input to execute operating system functions.
GUI – Graphical User Interface. The graphical user interface is a form of user interface that allows users to interact
OS - An operating system, or "OS," is software that communicates with the hardware and allows other programs to run
Mainstream OS - Windows, Linux, Unix, OS-X
Given below are instructions to test the app manually.
|
ℹ️
|
These instructions only provide a starting point for testers to work on; testers are expected to do more exploratory testing. |
-
Initial launch
-
Download the jar file and copy into an empty folder
-
Double-click the jar file
Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
-
-
Saving window preferences
-
Resize the window to an optimum size. Move the window to a different location. Close the window.
-
Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained.
-
{ more test cases … }
-
Deleting a person while all persons are listed
-
Prerequisites: List all persons using the
listcommand. Multiple persons in the list. -
Test case:
delete 1
Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated. -
Test case:
delete 0
Expected: No person is deleted. Error details shown in the status message. Status bar remains the same. -
Other incorrect delete commands to try:
delete,delete x(where x is larger than the list size) {give more}
Expected: Similar to previous.
-
{ more test cases … }