Developer Home Page
VisArt is a project made for art galleries facilitating Art Piece transactions from local Artists to art enthusiasts. VisArt will provide a website where customers can browse various Art Listings from local Artists as well as some straight from the gallery, if interested, customers can purchase straight from the website. Verified local artists can post their Art Listings which will be stored in our back-end database system.
To access the VisArt website, please visit: VisArt
| ID | Requirement | Type |
|---|---|---|
| 01 | The art gallery management system shall allow the artist and manager to upload artworks for sale. | Functional |
| 02 | The art gallery management system shall allow the customer to arrange logistics of pickup. | Functional |
| 03 | The art gallery management system shall notify the customer when their purchases are shipped or ready for pickup. | Functional |
| 04 | The art gallery management system shall allow artists and customers to create a profile to purchase and upload artworks*. | Functional |
| 05 | The art gallery management system notify the artist when one of their works has been purchased. | Functional |
| 06 | Upon request of a user, the art gallery management system shall list all non-purchased pieces from a chosen artist. | Functional |
| 07 | The art gallery management system shall list the 50 featured art pieces, selected by the manager, in the user’s feed page. | Functional |
| 08 | The art gallery management system shall allow the customer to choose between postal shipping or pickup when a piece is purchased. | Functional |
| 09 | The art gallery management system shall mark the artwork as sold when a customer purchases it. | Functional |
| 10 | The art gallery management system shall allow the customer to save their favorite artworks. | Functional |
| 11 | The art gallery management system shall display artworks based on the tag selection made by the customer. | Functional |
| 12 | The art gallery management system shall be available for usage during 98% of the day. | Non-Functional |
| 13 | The art gallery management system shall replace all characters in the password with an asterix, immediately upon entry by the user, on the login page. | Non-Functional |
| 14 | After the customer presses the order button, the art gallery management system shall process* the order with a latency of no greater than 15 seconds. | Non-Functional |
| 15 | The art gallery management system shall make an artwork available for sale, after being uploaded by an artist, with a latency of no greater than 15 seconds. | Non-Functional |
**Process: Mark the ordered item as "sold" and send a notification to the artist that one of their artworks has been purchased.
REQ4: The art gallery management system shall allow the artist to create their own profile page.
Associated user story: The art gallery management system shall allow artists and customers to create a profile to purchase and upload artworks*. *Only an artist may upload artworks after profile creation.
Actors: Artist and Customer
“Artist and Customer” will be referred to as “user” from this point.
-
- The user does not have an existing profile yet.
-
- The user is on the sign up page.
-
- The user has successfully created a profile and can now start purchasing artworks and uploading art pieces (artist profile only).
-
- The user clicks on the sign up button.
-
- The user enters their full name in the appropriate field box
-
- The user enters an email in the appropriate field box.
-
- The user enters a username in the appropriate field box.
-
- The user enters a password in the appropriate field box.
-
- The user enters the previously entered password in the appropriate field box.
-
- The user specifies if they are an artist or a customer by checking the appropriate checkbox.
-
- The user clicks on the “continue” button to go to the next page.
-
- The user writes a description of themselves in the appropriate field box.
-
- The user uploads a profile picture by clicking on the “upload” button.
-
- The user clicks on the “create profile” button to finish creating their profile.
- 2a) The user includes non-alphabetical symbols in the name field box. The art gallery system will warn the user to provide a valid name.
- 3a)The user does not write a valid email address (ex: @gmail.com missing). The art gallery system will warn the user to provide a valid email.
- 4a)The user enters a username that is already being used. The art gallery system will warn the user to provide an alternative username.
- 5a)The user enters a password that does not match the previously entered password. The art gallery system will warn the user to re-enter the password.
- 8a)The user clicks on the continue button without completing all fields or respecting the requirements. The art gallery system warns the user to review the fields as it is empty or does not meet the specified requirements.
- 9a)The user writes a description of themselves but exceeds the 150 words count. The art gallery system warns the user to stay within the 150 words limit.
- 11a) The user clicks on the “create profile” button without uploading a profile picture or writing a description of themselves. The art gallery system warns the user to upload a profile picture and to write a description.
REQ7: The art gallery management system shall list the 50 featured art pieces, selected by the manager, in the user’s feed page.
Associated User Story: As a manager, I want to select up to 50 artworks that will be showcased on a feed.
Actors: Manager, Art gallery, ArtListing
-
- The manager has created a profile in the system
-
- The manager has logged in to the system
-
- The manager has navigated to the main feed section of the system that displays all artwork.
-
- The pined ArtListing is present in the “Main” feed and the “Gallery Favorites” feed.
-
- The system displays a button next to each listing that is only visible to Manager accounts prompting them to set that art listing as a favorite.
-
- When the button is pressed, a note appears next to the art listing indicating that it has been tagged.
-
- After the button is pressed, the art listing is in the list of “Gallery Favorites” as well as “Main” feed.
- 4a) There are 50 art listings already selected as a Gallery Favorite, so the system displays a message indicating that the manager cannot add a new favorite art listing.
REQ6: Upon request of a user, the art gallery management system shall list all non-purchased pieces from a chosen artist.
Associated User Story: As an artist or customer, I want to view all the artwork uploaded into the system that is still for sale.
Actors: Artist, Manager, Art gallery
-
- The customer/artist/manager has created a profile in the system
-
- The customer/artist/manager has logged in to the system
-
- The customer/artist/manager has navigated to the main feed section of the system that displays all artwork.
-
- The customer/artist/manager can view all unsold Art Pieces.
-
- The customer/artist/manager enters their personal profile after logging in.
-
- The system displays their personal profile page.
-
- The user locates the “Main Feed” bar.
-
- The art gallery system displays a single column scrollable list of all non-sold artwork.
- 4a) There is no artwork posted in the database. The system displays a message indicated there are no posted artworks.
- 5a) There is no unsold artwork posted in the database. The system displays a message indicated there are no unsold artworks.
REQ1: The art gallery management system shall allow artists and managers to upload artworks for sale.
Associated user story: As an artist or customer, I want to be able to upload artworks into the system so that customers and artists can purchase.
Acceptance criteria: The artist or manager needs a valid account in the system to log in first. Then the artworks can be uploaded.
Use Case Specification:
Actors: Artist, Manager, Art gallery
-
- The artist/manager has created a profile in the system
-
- The artist/manager has logged in to the system
-
- The artist/manager has navigated to the post your artwork section.
-
- The artist/manager has successfully uploaded their artworks
-
- The artist/manager enters their personal profile after logging in.
-
- The system displays their personal profile page.
-
- The users locate the “Artwork” bar.
-
- The users click the Artwork bar and locates the “Add my Artwork” bar.
-
- The users click the “Add my artwork” bar and selects the “Upload Artwork” button.
-
- Once the artwork is uploaded, the artists/manager writes a title in the “Title Field”.
-
- The artist/manager then writes a short description in the “Description” field.
-
- The artist/manager then writes the price of the artwork in the “Price” field.
-
- The artist/manager then writes the specific style, medium and material of an artwork in their respective fields.(“Style”, “Medium”, “Material”)
-
- The artist/manager then writes the dimension of the artwork in the “Dimension” field.
-
- Then the artist/manager clicks the “Upload” button after all description of the artwork is provided.
-
- The art gallery management system displays a message “The artwork has been successfully uploaded”.
- 5a) The artist/Manager uploads a file that exceeds 20MB. An error message is displayed and the artist/manager goes back to the previous step.
- 6a) The Artist/Manager writes a title longer than 100 characters. The Title field in the system does not let the user write more than 100 characters.
- 8a) The Artist/Managers writes a negative price by mistake. The system only takes positive non-zero values as input.
REQ2: The art gallery management system shall allow the customer to arrange logistics of pickup.
Associated User Story: As a customer buying an art piece, I want to be able to organize how I will pick up the piece.
Actors: Customer, Artist, Art Gallery
-
- The customer/artist has created a profile in the system
-
- The customer/artist has logged in to the system
-
- The customer/artist has navigated to an Art Listing.
-
- The customer/artist has begun the purchase process of an Art Piece.
-
- The artist receives information on how the Art Piece will be picked up.
-
- The customer/artist/manager navigates to an Art Listing after logging in.
-
- The system displays the Art Listing.
-
- The user locates the “Buy” button.
-
- The art gallery system displays a form regarding how the Art Piece will be picked or delivered
-
- The user fills out the form and submits it
-
- The artist receives information regarding the delivery/pick-up
- 4a) There is no pickup option for the given art piece therefore it displays to the delivery form
- 4b) There is no delivery option for the given art piece therefore it displays the pick-up form
REQ5: The art gallery management system notify the artist when one of their works has been purchased.
Associated User Story: As an artist, I want to get informed each time one of my art pieces has been bought by a customer. Acceptance criteria:
Actors: Artist, Customer, Art Listing, Art Gallery
-
- The Artist has created a profile in the system
-
- The Artist’s profile has been approved by a manager.
-
- The Artist has uploaded at least one Art Piece to their artwork collection.
-
- The Artist has published an Art Listing with said Art Piece.
-
- The Customer has created a profile in the system.
-
- The Customer has navigated to one Art Listing made by the Artist.
-
- The Artist has purchased the Art Piece present in the Art Listing.
-
- The Artist Receives information that the Art Piece was purchased
-
- The Artist Receives information about the customer who purchased the Art Piece.
-
- The customer navigates to an Art Listing after logging in.
-
- The system displays the Art Listing.
-
- The customer locates the “Buy” button.
-
- The customer fills out shipping information
-
- The customer clicks on "pay" to get redirected to a separate payment website (ex: e-tranfer banking website).
-
- The customer pays the artist by filling the required fields.
-
- The customer submits the payment form.
-
- The order is successfully placed and a notification is sent to the artist.
-
- The Artist gets a pop-up notification with the art-piece purchased and the customer who purchased it
- 4a) The customer fills out shipping information but does not complete all text boxes. The art gallery system will warn the customer to complete all required fields.
- 8a) The customer submits the payment form but did not fill out all required fields. The banking website will warn the customer to complete all required fields.
- 9a) The order is not successful due to an error. The art gallery system will tell the customer to try again later.
- 9a.1) The artist does not get any notification.
At the highest level is the Gallery class, which represents the Art Gallery system. The Gallery is composed of Users. The user class has many of the general variables commonly found in a user, such as the username, displayname, email address, password, profile description, profile picture link, etc. User is also associated with the abstract class UserRole. The generalization of UserRole with Manager and Customer is to differentiate the different types of accounts that are on the Art Gallery system. The Manager class is to represent the role and responsibilities of Art Gallery managers who are monitoring the system. The Customer class is to represent all non-manager users on the application. Customers have a composition relationship with 0 to 1 Artist, on a high level the reasoning behind this relationship is that Artists are customers that can both buy and sell art, however customers can only buy art. All UserRoles, Manager and Customer as well as Customers composed of Artist have an association with ArtListing. ArtListing represents the art that is for sale. An artist class can post many art listings of their own art for sale, and an Art Listing can only be associated with one artit, therefore, the multiplicity of the association is 0..* to 1. Managers can promote different listings, therefore the association between Manager and ArtListing 0..1 to *, since an art listing does not have to be promoted and therefore can have no manager association. Customers can favorite listings as a way to place an order for the piece, inversely, ArtListings can have many Customers that placed an order on the listing. This is because an ArtListing can actually have multiple Art Pieces, this accounts for Copies and Originals of an Art Piece. So the amount of favorited customers an ArtListing can have is bounded by the amount of ArtPieces in the ArtListing. Therefore the ArtPiece class has a 1 to many composition relationship with the ArtListing class. ArtListing also has a composition relationship with the Tag class, which uses enumerations to help gain more insight into the type of art that is being posted, which will help us query ArtListings based on the type of art we want. An ArtPiece has a composition relationship with the ArtOrder class. ArtOrder is the information related to the purchasing of a specific ArtPiece. In addition, ArtPiece has an association to Ticket class. The Ticket class contains all the information related to the payment that has to be done. Both Customer and Artist have associations with Ticket since a ticket must have 1 artist and 1 customer involved in the transaction.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/get/{idCode}
- This operation returns the ArtListing based on the IdCode
- Requires non-Null and non-empty string containing an Id Code
- Returns the appropriate Dto associated with the id and returns null if the ArtListing does not exist
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/get_all
- This operation returns all the ArtListings in the database
- Queries the database and returns ArtListingDto in the form of a list
- Returns the appropriate Dto associated with the id and returns null if the ArtListing does not exist
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/create
- This operation adds a new ArtListing to the database and returns an ArtListingDto object
- Requires a JSON object containing "aVisibility":{value 1}, "aDescription":{value 2}, "aTitle":{value 3}, "artistId":{value 4} the values must be non-Null and respect the rules layed out in the QA report.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/delete/{idCode}
- This operations removes an ArtListing from the database and returns whether the ArtListing was successfully deleted as a boolean.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/update/{aIdCode}
- This operation updates an existing ArtListing in the database and returns the updated ArtListingDto object
- Requires a JSON object containing "aVisibility":{value 2}, "aDescription":{value 3}, "aTitle":{value 4}, "artistId":{value 5} the values could null as null values indicate no change.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/update_dimensions/{aIdCode}
- This operation updates an existing ArtListing in the database but specifically changes the dimensions and returns the updated ArtListingDto object
- Requires a JSON object containing "aDimensions":{value 2}.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/update_post_images/{aIdCode}
- This operation updates an existing ArtListing in the database but specifically changes the post images and returns the updated ArtListingDto object
- Requires a JSON object containing "aPostImages":{value 2}.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/add_piece/{aIdCode}
- This operation updates an existing ArtListing in the database by adding an ArtPiece to it based on the given Art Piece id in the JSON and returns the updated ArtListingDto object.
- Requires a JSON object containing "artPieceId":{value 2}
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/remove_piece/{aIdCode}
- This operation updates an existing ArtListing in the database by removing an ArtPiece from it based on the given Art Piece id in the JSON and returns the updated ArtListingDto object.
- Requires a JSON object containing "artPieceId":{value 2}
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/get_favorited_customers/{aIdCode}
- This operation gets the favorited customers from the ArtListing which corresponds to the given ID in form of a list of the ids of the customers which are strings.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/add_tag/{aIdCode}
- This operation updates an existing ArtListing in the database by adding a Tag to it based on the given Tag ID in the JSON and returns the updated ArtListingDto object.
- Requires a JSON object containing "tagCode":{value 2}
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/add_tag/{aIdCode}
- This operation updates an existing ArtListing in the database by removing a Tag to it based on the given Tag ID in the JSON and returns the updated ArtListingDto object.
- Requires a JSON object containing "tagCode":{value 2}
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/get_unsold_art
- This operation gets all ArtListings from the database that have at least one unsold ArtPiece and returns it as a list of ArtListingDto objects.
URL Mapping: https://vis-art-application.herokuapp.com/artlisting/get_artwork_by_keyword
- This operation gets all ArtListings that have a tag from the keywords given and returns them as a list of ArtListingDto objects.
- Requires parameters in URL, ex: https://vis-art-application.herokuapp.com/artlisting/get_artwork_by_keyword?keywords=example,example2,example3
URL Mapping: https://vis-art-application.herokuapp.com/artorder/get_all
- This operation returns all the art orders in the database
- Queries the database and returns all the art orders in the database as a List of ArtOrderDto’s
- Requires no input
URL Mapping: https://vis-art-application.herokuapp.com/artorder/get/{idCode}
- This operation returns the art order with the corresponding id code.
- Queries the database and returns the artOrderDto.
- Requires a JSON object containing "idCode":{value1}
- Return null if the art order does not exist.
URL Mapping: https://vis-art-application.herokuapp.com/artorder/create/
- This operation adds a new art order to the database and returns an art order DTO object.
- Requires a JSON object containing “aIsDelivered”:{value 1}, “pieceLocation”:{value 2}, “aTargetAddress”: {value 3}, “aDeliveryTracker”: {value 4}, “artPieceDto”: {value 5}. These values must not be null and respect the restrictions specified in the quality assurance report.
- This operation throws an exception if the inputs are not valid.
URL Mapping: https://vis-art-application.herokuapp.com/artorder/update/{aIdCode}/
- This operation finds an art order given an Id Code and updates the art order fields with the new values passed.
- Requires a JSON object containing “aidCode“:{value1}, aIsDelivered”:{value 2}, “pieceLocation”:{value 3}, “aTargetAddress”: {value 4}, “aDeliveryTracker”: {value 5}, “artPieceDto”: {value 6}.
- This operation returns an art order Dto with updated fields. If a value is null then the corresponding field is not updated.
URL Mapping: https://vis-art-application.herokuapp.com/artorder/add_ticket/{artOrderId}/{ticketId}/
- This operation finds the art order given its id, and finds the ticket given its id, then add the ticket to the art order and also updates the art order object to persist in the database.
- Requires a JSON object containing “artOrderId”:{value 1} and “ticketId”:{value 2}.
- This operation will throw an exception if the art order ID is not valid
- This operation will throw and exception if the ticket ID is not valid
URL Mapping https:vis-art-application.herokuapp.com/artorder/delete/{id}/
- This operation finds an art order in the database, given its id, and permanently deletes it from the database.
- Requires a JSON object “id”:{value 1}.
- This operation throws an exception if the art order does not exist.
URL Mapping: https://vis-art-application.herokuapp.com/artpiece/get_all
- This operation returns all the art piece in the database
- Queries the database and returns all the art piece in the database as a List of ArtPieceDto’s
- Requires no input
URL Mapping: https://vis-art-application.herokuapp.com/artpiece/get/{idCode}
- This operation returns the art piece with the corresponding id code.
- Queries the database and returns the artPieceDto.
- Requires a JSON object containing "idCode":{value1}
- Return null if the art order does not exist.
URL Mapping: https://vis-art-application.herokuapp.com/artpiece/create/
- This operation adds a new art order to the database and returns an art piece DTO object.
- Requires a JSON object containing “pieceLocation”:{value 1}, “aAddressLocation”:{value 2}, “aArtListingId” : {value 3}. These values must not be null and respect the restrictions specified in the quality assurance report.
- This operation throws an exception if the inputs are not valid.
URL Mapping: https://vis-art-application.herokuapp.com/artpiece/update/{aIdCode}/
- This operation finds an art piece given an Id Code and updates the art piece fields with the new values passed.
- Requires a JSON object containing “aIdCode”:{value 1} , “pieceLocation”:{value 2}, “aAddressLocation”:{value 3}, “aArtListingId” : {value 4}.
- This operation returns an art opiece Dto with updated fields. If a value is null then the corresponding field is not updated.
URL Mapping: https://vis-art-application.herokuapp.com/artpiece/add_order/{aIdCode}/
- This operation finds the art piece given its id, and finds the art order given its id, then add the art order to the art piece and also updates the art piece object to persist in the database.
- Requires a JSON object containing “aIdCode”:{value 1} and “artOrderId”:{value 2}.
- This operation will throw an exception if the art piece ID is not valid
- This operation will throw and exception if the art order ID is not valid
URL Mapping https:vis-art-application.herokuapp.com/artpiece/delete/{id}/
- This operation finds an art piece in the database, given its id, and permanently deletes it from the database.
- Requires a JSON object “id”:{value 1}.
- This operation throws an exception if the art piece does not exist.
URL Mapping: https://vis-art-application.herokuapp.com/users/get/{idCode}
- This operation returns the user based on the idCode
- Queries the database and returns a UserDto
- Requires a non-Null and non-empty string containing an Id code
- Returns the appropriate Dto associated with the id and returns null if the user does not exist
URL Mapping: https://vis-art-application.herokuapp.com/users/get_all
- This operation returns all the users in the database
- Queries the database and returns all users in the database as a List of UserDto's
- Requires no input
- Queries the database and returns all users in the database as a List of UserDto's
URL Mapping: https://vis-art-application.herokuapp.com/users/create/
- This operation adds a new user to the database and return a UserDto object
- Requires a JSON object containing "emailAddress":{value2}, "displayName":{value3}, "userName":{value4}, "password":{value5}, "profilePicLink":{value6}, "profileDescription": {value7} the values must be non-Null and respect the rules layed out in the QA report.
- This operation adds a new user to the database and return a UserDto object, throws an exception if the inputs are invalid
URL Mapping: https://vis-art-application.herokuapp.com/users_update/users/update/{idCode}/
- This operation finds a user given an Id then updates that users fields with the new values passed
- Requires a JSON object containing "idCode":{value1}, "emailAddress":{value2}, "displayName":{value3}, "userName":{value4}, "password":{value5}, "profilePicLink":{value6}, "profileDescription": {value7} the values must respect the rules layed out in the QA report.
- This operation finds a user given an Id then updates that users fields with the new values passed, if a value is null then the value is not updated
URL Mapping: https://vis-art-application.herokuapp.com/users/delete/{id}
- This operation finds a user given an Id then deletes it from the database
- Requires a JSON object containing "idCode":{value1}
- This operation finds a user given an Id then deletes it from the database, if the user does not exist or the input is invalid then nothing occurs
URL Mapping: https://vis-art-application.herokuapp.com/managers/create/
- This operation adds a new manager and subsequently a new user to the database and return a ManagerDto object
- Requires a JSON object containing "emailAddress":{value2}, "displayName":{value3}, "userName":{value4}, "password":{value5}, "profilePicLink":{value6}, "profileDescription": {value7} the values must be non-Null and respect the rules layed out in the QA report.
- This operation adds a new manager to the database and return a ManagerDto object, throws an exception if the inputs are invalid with respect to QA report
URL Mapping: https://vis-art-application.herokuapp.com/managers/get/{idCode}
- This operation returns the manager based on the idCode
- Queries the database and returns a ManagerDto
- Requires a non-Null and non-empty string containing an Id code
- Returns the appropriate ManagerDto associated with the id and returns null if the user does not exist
URL Mapping: https://vis-art-application.herokuapp.com/managers/get_all
- This operation returns all the Managers in the database
- Queries the database and returns all users in the database as a List of UserDto's
- Requires no input
- Queries the database and returns all users in the database as a List of UserDto's
URL Mapping: https://vis-art-application.herokuapp.com/managers/delete/{id}
- This operation finds a manager given an Id then deletes it from the database
- Requires a JSON object containing "idCode":{value1}
- This operation finds a manager given an Id then deletes it from the database, if the user does not exist or the input is invalid then nothing occurs
URL Mapping: https://vis-art-application.herokuapp.com/managers/get_listings/{idCode}
- Returns a list of all the managers favorited listings
- Requires a JSON object containing "idCode":{value1}
- Returns a list of all the managers favorited listings, an empty list if otherwise
URL Mapping: https://vis-art-application.herokuapp.com/managers/add_listing/{idCode}
- Finds a manager from the database given an ID, and finds an art listing from the database given an ID, then adds the art listing to the manager's favorite listings and updates the manager object to persist in the database.
- Requires a JSON object containing "idCode":{value1},"listingIdCode":{value1}
- Finds a manager from the database given an ID, and finds an art listing from the database given an ID, then adds the art listing to the manager's favorite listings and updates the manager object to persist in the database. The method will throw an exception if the inputs are invalid.
URL Mapping: https://vis-art-application.herokuapp.com/managers/remove_lisiting/{idCode}/
- Finds a manager from the database given an ID, and finds an art listing from the database given an ID, then deletes the art listing from the manager's favorite listings and updates the manager object to persist in the database.
- Requires a JSON object containing "idCode":{value1},"listingIdCode":{value1}
- Finds a manager from the database given an ID, and finds an art listing from the database given an ID, then adds the art listing to the manager's favorite listings and updates the manager object to persist in the database. The method will throw an exception if the inputs are invalid.
URL Mapping: https://vis-art-application.herokuapp.com/customers/create
- This operation adds a new customer and subsequently a new user to the database and return a CustomerDto object
- Requires a JSON object containing "emailAddress":{value2}, "displayName":{value3}, "userName":{value4}, "password":{value5}, "profilePicLink":{value6}, "profileDescription": {value7} the values must be non-Null and respect the rules layed out in the QA report.
- This operation adds a new customer to the database and return a customerDto object, throws an exception if the inputs are invalid with respect to QA report
URL Mapping: https://vis-art-application.herokuapp.com/customers/get/{idCode}
- This operation returns the customer based on the idCode
- Queries the database and returns a CustomerDto
- Requires a non-Null and non-empty string containing an Id code
- Returns the appropriate CustomerDto associated with the id and returns null if the user does not exist
URL Mapping: https://vis-art-application.herokuapp.com/customers/get_all
- This operation returns all the Customers in the database
- Queries the database and returns all users in the database as a List of UserDto's
- Requires no input
URL Mapping: https://vis-art-application.herokuapp.com/customers/delete/{idCode}
- This operation finds a customer given an Id then deletes it from the database,if the user does not exist or the input is invalid then nothing occurs
- Requires a JSON object containing "idCode":{value1}
URL Mapping: https://vis-art-application.herokuapp.com/customers/get_favorite_listings/{idCode}
- Returns a list of all the customers favorited listings
- Requires a JSON object containing "idCode":{value1}
- Returns a list of all the customers favorited listings, an empty list if otherwise
URL Mapping: https://vis-art-application.herokuapp.com/customers/add_favorite_listings/{idCode}
- Finds a customer from the database given an ID, and finds an art listing from the database given an ID, then adds the art listing to the customer's favorite listings and updates the manager object to persist in the database.
- Requires a JSON object containing "idCode":{value1},"listingIdCode":{value1}
URL Mapping: https://vis-art-application.herokuapp.com/customers/remove_favorite_listings/{idCode}
- Finds a customer from the database given an ID, and finds an art listing from the database given an ID, then deletes the art listing from the customer's favorite listings and updates the customer object to persist in the database. The method will throw an exception if the inputs are invalid.
- Requires a JSON object containing "idCode":{value1},"listingIdCode":{value2}
URL Mapping: https://vis-art-application.herokuapp.com/customers/purchase_artpiece/{idCode}
- Finds a customer from the database given an ID, and finds an art piece from the database given an ID, then creates a ticket and an art order with the art piece and the customer. Initiating a purchase agreement. The method will throw an exception if the inputs are invalid or null.
- Requires a JSON object containing "idCode":{value1},"listingIdCode":{value2}, "targetLocation":{value2}, "targetAddress":{value3}, "deliveryTracker":{value4}
URL Mapping: https://vis-art-application.herokuapp.com/tags/get/{idCode}/
- This operation returns the tag based on the idCode
- Queries the database and returns a TagDto
- Requires a non-Null and non-empty string containing an Id code
- Returns the appropriate TagDto associated with the id and returns null if the user does not exist
URL Mapping: https://vis-art-application.herokuapp.com/tags/get_all/
- This operation returns all the Tags in the database
- Queries the database and returns all tags in the database as a List of TagDto's
- Requires no input
URL Mapping: https://vis-art-application.herokuapp.com/tags/get_by_type/{type}/
- This operation returns all the Tags in the database
- Queries the database and returns all tags that have a certain type in the database as a List of TagDto's
- It requires a string input that specifies the type we want to look for in the database
URL Mapping: https://vis-art-application.herokuapp.com/tags/get_by_keyword/{keyword}/
- This operation returns all the Tags in the database with a certain keyword
- Queries the database and returns all tags that have a certain type in the database as a List of TagDto's
- It requires a string input that specifies the type we want to look for in the database
URL Mapping: https://vis-art-application.herokuapp.com/tags/create/
- This operation adds a new tag to the database and return a TagDto object
- Requires a JSON object containing "type":{value2}, "keyword":{value3}, "aListingDto":{value4} the values must be non-Null and respect the rules layed out in the QA report.
- This operation adds a new tag to the database and return a tagDto object, throws an exception if the inputs are invalid with respect to QA report
URL Mapping: https://vis-art-application.herokuapp.com/tags/update/{aIdCode}/
- This operation finds a tag given an Id then updates that tag's fields with the new values passed
- Requires a JSON object containing "idCode":{value1}, "type":{value2}, "keyword":{value3}, "aListing":{value4} the values must respect the rules layed out in the QA report.
- This operation finds a tag given an Id then updates that tag's fields with the new values passed, if a value is null then the value is not updated
URL Mapping: https://vis-art-application.herokuapp.com/tags/delete/{aIdCode}/
- This operation finds a tag given an Id then deletes it from the database, if the tag does not exist or the input is invalid then nothing occurs
- Requires a JSON object containing "idCode":{value1}
URL Mapping: https://vis-art-application.herokuapp.com/tickets/get/{aIdCode}
- This operation returns the ticket based on the idCode
- Queries the database and returns a ticketDto
- Requires a non-Null and non-empty string containing an Id code
- Returns the appropriate TicketDto associated with the id and returns null if the user does not exist
URL Mapping: https://vis-art-application.herokuapp.com/tickets/get_all
- This operation returns all the Tickets in the database
- Queries the database and returns all tickets in the database as a List of TicketDto's
- Requires no input
URL Mapping: https://vis-art-application.herokuapp.com/tickets/create
- This operation adds a new ticket to the database and return a TicketDto object
- Requires a JSON object containing "aIsPaymentConfirmed":{value2}, "aPaymentAmount":{value3}, "aOrderDto":{value4}, "aCustomerDto":{value5}, "aArtistDto":{value6} the values must be non-Null and respect the rules layed out in the QA report.
- This operation adds a new ticket to the database and return a ticketDto object, throws an exception if the inputs are invalid with respect to QA report
URL Mapping: https://vis-art-application.herokuapp.com/tickets/update/{aIdCode}/
- This operation finds a ticket given an Id then updates that ticket's fields with the new values passed
- Requires a JSON object containing "aIdCode":{value1}, "aIsPaymentConfirmed":{value2}, "aPaymentAmount":{value3}, "aOrderDto":{value4}, "aCustomerDto":{value5}, "aArtistDto":{value6} the values must be non-Null and respect the rules layed out in the QA report.
- This operation finds a ticket given an Id then updates that ticket's fields with the new values passed, if a value is null then the value is not updated
URL Mapping: https://vis-art-application.herokuapp.com/tickets/delete/{aIdCode}/
- This operation finds a ticket given an Id then deletes it from the database, if the ticket does not exist or the input is invalid then nothing occurs
- Requires a JSON object containing "idCode":{value1}
The system should be able to create, get, delete, update, login a user and retrieve a list of all users in the database. User attributes have enforced rules that cannot be broken when creating and updating a user.
- No attributes can be NULL
- Usernames and Display names must be unique and between 5 and 25 characters
- Passwords must be between 8 and 40 characters and will be hashed in the frontend of the application before being stored in the database for security.
- Email addresses must follow correct email structuring
- Id codes must be randomly generated and unique
- Profile descriptions must be less than 250 characters
- Profiles Picture links can be empty strings
As a result of the above rules to get a user or delete a user or login a user the Id code passed in must be non-Null and not an empty string. Ensuring uniform and industry-standard behavior across the entire application.
The system should be able to create, get, delete, update, add an art piece, remove an art piece, get favorited customers, add a tag, remove a tag, get unsold artworks and filter artworks by tag. While creating an ArtListing, each attribute must not be null. If one of the attributes is null, an exception will be thrown. When updating an art listing, if an attribute is set to null, those attributes will not be updated. When adding an art piece or removing an art piece, the id of the art piece must not be null. By following these rules, we ensure that any art listing posted is correctly structured and does not lack data.
The system should be able to create a manager, get a manager, add a favorite listing, and delete a favorite listing.
Creating a manager must abide by the same input rules as defined for those in the User services. Getting a manager should return the manager based on a given Id code and return null if the manager does not exist. Furthermore, given the Id of a manager and Id for an art listing the system should be able to add the art listing or remove the art listing from the managers favorited art listings. All of these methods should not accept null inputs or empty strings for Id codes, ensuring only valid elements get pushed to the database.
The system should be able to create an artist, get an artist, delete an artist, add an art listing, remove an art listing, add a sold ticket, and remove a sold ticket as well as return all the artists in the database.
Inputs to the Artist service method must first be checked to only accept non Null values. Furthermore, idCode’s will also be compared with empty strings to ensure they take the form of a valid id. Illegal Argument Exceptions will be thrown if these rules are violated.
The system should be able to create a customer, get a customer, add a favorite listing,delete a favorite listing,add a ticket,remove a ticket.
Creating a customer must abide by the same input rules as defined for those in the User services. Getting a customer should return the customer based on a given Id code and return null if the customer does not exist. The system should be able to add or remove art listings from a list of favorited art listings for a customer with a unique Id. Every time a new customer is created, it checks if the unique Id is null. If the unique id is null, it throws an error until the generated id satisfies the condition. The system should be able to add or remove a ticket for a customer with a specific Id. All of these methods should not accept null inputs or empty strings for Id codes, ensuring only valid elements get pushed to the database.
The system should be able to create, get, update and delete an Art Order. It should also be able add a ticket to an art order. Creating an order must abide by the same inputs rules as defined for those in the art piece services. Therefore, all inputs must be checked to make sure that they are not null or empty. Getting an art order should return the corresponding art order to the id code and return null if the art order does not exist. The delivery status, the target location, the target address as well as the delivery tracker of an art order may also be updated. Updating an art order should return the updated art order. Attributes that are not updated should remain the same. Deleting an art order should delete the art order permanently and return true if the deletion is successful. The system should throw an exception when trying to add a ticket with an invalid idCode to an Art Order.
The system should be able to create, get, update and delete an Art Piece. It should also be able to add an art order to an art piece. Creating an art piece must abide by the same inputs rules as defined for those in the art piece services. Therefore, all inputs must be checked to make sure that they are not null or empty. Getting an art piece should return the corresponding art piece to the id code and return null if the art piece does not exist. The basic location and address location may also be updated. Updating an art piece should return the updated art piece. Attributes that are not updated should remain the same. Deleting an art piece should delete the art piece permanently and return true if the deletion is successful. The system should throw an exception when trying to add an art order with an invalid idCode to an art piece.
The system must be able to create, get, update and delete a Tag. It should also be able to get all tags, and get specific tags by types. Creating a Tag must abide by the same input rules as defined for those in the tag services. Therefore, all inputs must be checked to make sure that they are neither null or empty. Since we often pass the objects by id, we have to make sure that those ids correspond to an object in the database. We can get a tag by its id. The Tag attributes can also be updated, returning the updated Tag. Attributes that are not updated remain unchanged. Deleting a tag from the database can be done through the tag object or its id and it removes the tag permanently from the database, then returns true if it succeeds. The edge cases must be covered meaning that all ids should be checked.
The system must be able to create, get, update, and delete a ticket. Creating a Ticket must abide by the same input rules as defined for those in the ticket services. Meaning that all inputs must be checked to make sure that they are neither null, nor empty and that they do not refer to a non-existing object when we pass a parameter by id. A ticket’s attributes can be updated using the update method, leaving the remaining attributes unchanged. In addition, we can retrieve or delete a ticket from the database using its id.
Test Coverage
The objective of a minimum text coverage of 60% was exceeded in the implementation of tests with total coverage of 89.7%.
Furthermore, 2 team code reviews were had before the end of deliverable 2 to ensure the entire team was aligned in their approach for testing and coding style.
Testing Approach
The testing approach that has been used for this deliverable is the bottom-up approach. We first started unit testing all our service classes. Each of the service classes have a test class in which many test cases are covered. Testing all the services separately ensures that each one of them functions properly without having any exterior factor that may interfere with the testing. When all the unit tests have passed, the next step was to move onto integration testing. Many tests that involved several classes were performed. The purpose of this testing was to evaluate if the system works as a whole and not only in isolated cases. Therefore, the testing has started in a low level and gradually went up to high level testing.
This is the architecture model for the Artist viewpoint. The artist can have two roles: it can act as an artist and as a customer as well.
The explanation for the model is just below the image
The frontend is divided into two components: Android and Web. They both have the same functional components as shown in the architecture model. The frontend displays the actions that can be done by the user. The user interacts with the frontend to use the Art Gallery Management system.
Login/sign up: The user can access the art gallery management system by signing up or logging in to the app. If the user is new, the user needs to sign up for a new account and selects his role in the system which is either admin or member. The member can be an artist or a customer. Then the user follows certain steps which includes information like username, password, email address, Full name. If it is an existing user, the user needs to log in to access the system.
Home page: The artist can access the Home page once logged in. The home page displays some important features of our system which includes profile page, all art page, featured art page, Messages.
Profile: The artist can access this page to create a profile and add more information. The profile also displays the list of artworks purchased, published and already sold. The artist can use this page to add a new art Listing to the system. This page displays the list of artworks favorited by the artist as an artist can also be a customer and purchase art. The artist can favorite listings from featured Art or All art pages.
All Art page: The artist can access the list of artworks in the system by clicking the All-art button from the home page. The featured art page only displays the artwork posted on the system by the Manager. The All-art page includes artworks posted by induvial artists as well as artworks from the gallery itself.
Purchase page: This page displays every information required to purchase an artwork from the system.
Messages: The artist gets a notification every time a personal artwork is sold.
The backend highlights the key services implemented for the art gallery management system. The frontend interacts with the backend through REST API method calls every time any user(customer) uses the system. The backend Service component interacts with the persistence component to get information from the database using the CRUD operations in the backend.
The explanation is just below the image.
The frontend is divided into two components: Android and Web. They both have the same functional components as shown in the architecture model. The frontend displays the actions that can be done by the user. The user interacts with the frontend to use the Art Gallery Management system.
Login/sign up: The user can access the art gallery management system by signing up or logging in to the app. If the user is new, the user needs to sign up for a new account and selects his role in the system which is either admin or member. The member can be an artist or a customer. Then the user follows certain steps which includes information like username, password, email address, Full name. If it is an existing user, the user needs to log in to access the system.
Home page: The user(customer) can access the Home page once logged in. The home page displays some important features of our system which includes profile page, all art page, featured art page, Messages.
Profile: The customer can access this page to create a profile and add more information. The profile also displays the list of artworks already purchased. This page also displays the list of artworks favorited by the customer. The customer can favorite listings from featured Art or All art pages.
All Art page: The customer can access the list of artworks in the system by clicking the All-art button from the home page. The featured art page only displays the artwork posted on the system by the Manager. The All-art page includes artworks posted by induvial artists as well as artworks from the gallery itself. Whenever a customer clicks on a specific art Listing, it displays the tag for that specific art listing which includes all information about the. Art Listing.
Purchase page: This page displays every information required to purchase an artwork from the system.
Messages: The customer gets a notification every time an artwork is purchased and includes the shipment information.
The backend highlights the key services implemented for the art gallery management system. The frontend interacts with the backend through REST API method calls every time any user(customer) uses the system. The backend Service component interacts with the persistence component to get information from the database using the CRUD operations in the backend.
The explanation is just below the image.
The frontend is divided into two components: Android and Web. They both have the same functional components as shown in the architecture model. The frontend displays the actions that can be done by the user. The user interacts with the frontend to use the Art Gallery Management system.
Login/sign up: The user can access the art gallery management system by signing up or logging in to the app. If the user is new, the user needs to sign up for a new account and selects his role in the system which is either admin or member. The member can be an artist or a customer. Then the user follows certain steps which includes information like username, password, email address, Full name. If it is an existing user, the user needs to log in to access the system.
Home page: The user(manager) can access the Home page once logged in. The home page displays some important features of our system which includes profile page, all art page, featured art page, Messages.
Profile: The manager can access this page to create a profile and add more information. The profile also displays the list of artworks already published and already sold. The manager can use this page to add new artworks to the system. The manager can add or remove art Listing from this page.
All Art page: The manager can access the list of artworks in the system by clicking the All-art button from the home page.
Featured Art Page: The featured art page only displays the artwork posted on the system by the Manager.
The backend highlights the key services implemented for the art gallery management system. The frontend interacts with the backend through REST API method calls every time any user(customer) uses the system. The backend Service component interacts with the persistence component to get information from the database using the CRUD operations in the backend.
-Daniel: recapping the sprint deliverables* -Daniel: Let’s just start with the project management setup, so people have tasks. Maybe we can do the requirements model today. We can also talk about the domain model. We don’t have access to the wiki. We should do the requirements model as a team, separate into techie tasks afterward.
-Creating the Requirements Model together -Group discussion on the project -Understanding of the project: Art Gallery in the neighborhood. Connect local artists with potential customers. Focus on local artists. Promote and sell their work Artists create a profile, present their art pieces, then sell. Interested customers (create accounts) browse, and buy art. Gallery promotes (and sells) in-store artwork. Gallery makes income on commission.
Discussed requirements (informal): Platform to display/promote individual Artwork Each art piece belongs to an artist Art can be in-store or from the artist Artists create accounts that can post art pieces Customers can create accounts to browse and buy art Gallery can promote their own art (done by different artists) Each art piece has artist(s) attributed Customers can pick up art from the gallery locations or have it delivered Artists can drop off art at Gallery locations Customers can have the art delivered to themselves Artists that are local get preference
-Ryan discovers that we need a use-case diagram amongst other things -Agreed on another meeting tomorrow to further discuss the domain model.
-Discussion about the domain model. -Sketched out a domain model on Daniel’s tablet:
-Discussed about the difference between an artist and a customer: Artists are customers with further permission. An artist may purchase artworks just like any customer but can also upload artworks for sale.
-Discussed on multiplicities between classes.
-Explained the domain model several times so that all group members are on the same page and understand the model completely: TAG class is important so that customers can filter art pieces.
-Decided to prepare a few requirements for tomorrow.
29/09/2020 - Daniel, Riad and Yuta (Focused Group Call)
-Went through all written functional and nonfunctional requirements. -Picked a few requirements that are really important for this project. -Edited some requirements that were not as good. -Made new requirements for the art gallery system.
Requirements that were discussed:
The art gallery management system shall allow artists to sell their work. The art gallery management system shall allow customers to arrange logistics of pickup. The art gallery management system shall notify customers when their purchases are shipped or ready for pickup. The art gallery management system shall allow customers to contact art gallery support for assistance and questions. The art gallery management system shall allow customers to contact the artist directly. The art gallery management system shall allow customers to select pickup time. The art gallery management system shall allow artists to create their own profile page. The art gallery management system notify the artist when one of their works has been purchased. The art gallery management system shall allow customers to save their favorite artworks. The art gallery management system shall mark the artwork as sold when a customer purchases it. Upon request of a user, the gallery management system shall list all non-purchased pieces from a chosen artist. The gallery management system shall hide a purchased piece from its author’s art inventory. The manager accounts in the gallery management system shall list the preselected 20 featured pieces in the user’s dashboard. The gallery management system shall only allow manager profiles to edit the featured pieces list. The gallery management system shall allow customers to privately message artists. The gallery management system shall be able to permanently ban artists profile from the system upon request of a manager profile. The gallery management system shall allow artists to add up to 7 keywords to describe their artwork. Upon request of a user, the gallery management system shall return a time-ordered list of pieces with the keywords chosen by the user. The gallery management system shall allow users to like pieces. Upon request of a user, the gallery management system shall return liked pieces. The gallery management system shall allow artists to edit the specifications of their pieces (price - keywords - pictures - title - description). Once a piece is purchased, the gallery management system shall allow the buyer to choose the shipping method.
- These requirements are to be reviewed and are subject to possible change in future meetings.
Discussion Topic: Implementing the persistence layer strategy
JPA Annotations: As we work through this we are going to make tweaks to our model, and annotating is going to be a big issue if we have to do it each time. We need to find a way to auto-generate these annotations somehow. Ryan pitched a solution that embeds comments in .ump file that end up in the generated classes and we just have to remove the duplicated variables and the comments later using a search tool, making it much more efficient. CRUD vs EntityManager Which do we want to use, as of now the recording of the tutorial seems to cut out when doing CRUD, so for the purpose of time and what seems simple enough we’ll go with what we have more resources on, which is using Entity Manager. Daniel, Ryan and Nik spend some time learning and researching the basic operations with entityManager
Objective moving forward after this is to keep learning about entityManager and implement a few repos with it.
- Discussion on J unit test implementation
- Discussion on J unit test structure
- Went over on how to write a proper J unit test: Need to create, get, update and delete. Task separation: Riad will be doing customer test, manager test, tag test and ticket test. Yuta will be doing artist test, art listing test, art piece test and art order test. Mahin will be doing user test.
Started discussing the set-up and understanding the repositories in order to write the first tests Went through the example written by Ryan called Event Test to understand the flow of the persistence layer testing Ryan explained spring annotations and how to check the heroku database.
Went through the repository classes written by Daniel and Nikola Debugged persistence problem in one of the repositories that made all the tests fail Verified create methods in heroku Fixed git issues Fixed ArtistTest.java and CustmerTest.java for create and get methods
Briefing on which tests work Live coding session Fixed build problem and merge issues Nikola and Daniel talked about the CRUD implementation and CRUD testing including comments Ryan helped the team debug tests and repos Discussion about the model and reconsidering certain key decisions regarding distinguishing the ticket from the art order. Model change with art order and ticket that created an infinite loop was fixed Model change - decided to add a profile picture and profile description to the user class Model change - decided to add a picture and description to an art listing.
Briefing about what was done Task redistribution to complete the documentation Yuta and Riad are assigned completing and compiling the meeting minutes into one file Daniel and Nikola are assigned to work the Wiki and the Readme. The group talked about the use case scenarios for everyone.
What went well in Deliverable 1:
- We communicated well
- We used git well in the sense that we used proper branching and had few merge conflict issues
- We all delivered our parts by the promised time.
What we need to improve for Deliverable 2:
- We need to be more proactive on Github issues and the issue board
Planning Deliverable 2:
- Be more active in logging all our issues on GitHub
- Also in Deliverable 1, we divided the work by sections, and while this worked well from a final result perspective it led to gaps in our knowledge. So for deliverable 2, everyone will work on every aspect of Deliverable 2 so that we can learn what is happening at every level.
This resulted in a work distribution such as:
Create DTOs
- ArtListing (Nik)
- ArtOrder (Yuta)
- ArtPiece (Nik - Yuta)
- Customer (Mahin)
- Manager (Daniel)
- Tag (Riad)
- Ticket (Riad)
- Artist - Ryan
- User - Ryan
Create Services, the REST APIs, and the Mock Tests
- ArtListing - Nik
- Tag - Riad
- ArtPiece - Yuta
- ArtOrder - Yuta
- Ticket - Riad
- Customer - Mahin
- Manager - Daniel
- User - Daniel + Nik + Ryan
This was an educational call for the team to understand what has to be done from a technology perspective. SO we first explored what Dto classes, services and RESTful controllers are. As a team, we implemented the Dto, some Services, and some Controller methods for the User class. Building off of this example we then cover all the general requirements that must be implemented for every action that needs to be made and created a GitHub issue and assigned the task to a team member. The next meeting will pertain to setting up a Software Quality Assurance plan.
The objective of this meeting was to develop a general Software Quality Assurance plan to ensure that our persistence layer adheres to a predefined set of standards. The basic elements of A Software Quality Assurance plan obtained from this call are:
- FOR ALL - no nulls, unless explicitly stated.
- Passwords - hashed (in service), >=8 character length max 255, no special characters, >1 lowercase, >1 uppercase, >1 number
- Usernames - no special characters, no repeating usernames, 8<length<255
- Display names - no special characters, no repeating display names, 8<length<255, no foul languages* (optional, worth a shot to try and implement)
- Art Listings - limit number of artist’s listings?
- art listing dimensions - no infinite values, no zero values, must be 3 dimensions (no 4th dimensional objects here, and yes paper has thickness, so 3 dimensions)
- art listing title - no special characters, 8<length<255, no foul languages*
- art post images - minimum 1 image (max 10, optional, this is an arbitrary value right now)
- art order targetAddress - does not have to be a valid address, sometimes it’s special and weird, so don’t bother verifying this. Better off using a web api to set this
- art order delivery tracker - could be a valid website, but then again it could just be a code
- Artpiece addressLocation - does not have to be a valid address, sometimes it’s special and weird, so don’t bother verifying this. Better off using a web api to set this
- tag keyword - short, 1<length<255 (arbitrary value), letters/numbers/some special characters (look on internet for this).
- ticket payment amount - 0<amount<infinite, cannot be infinite, null, negative infinite, cannot be negative value.
- User email - valid email address
- profile description - less than 255 characters, (arbitrary amount, maybe take twitter’s value?)
- DeliveryTracker must be 15 digits
Update call on team progress. All team members had many midterms going into the week so it was established that communications would resume on Thursday October 29th where we would all meet up once again and go over all the services that have been done for a review.
In this call, we went over more elaborate test cases and Ryan spent time explaining to the team how to properly test our services. Around 30 minutes was spent reviewing how to mock repository functions in the test. After this call, we all left with the objective to finish all our assigned services, tests, and controller methods by Saturday for a code review.
Ryan shared screen on a Google Hangouts call and went over all the finished Services and tests and we all looked out for 3 things: The first being if they were respecting the guidelines laid out in the provisional software quality assurance plan. The second criterion upon which we were judging code in the code review is if there were any missing test cases. The third criteria were if the code made sense and properly completed its functions in an efficient manner.
Not all members had their code ready for review so we agreed to do that the next day.
Meeting participants: All team members. Started discussing the third deliverable. Went over the project document to ensure that everything that needs to be implemented is understood by all team members. Also spoke about the different pages that need to be implemented for the front end. The decided pages are: Home page, art listing page, individual art listing page, checkout page and artist page. Additional pages will be discussed later. Finally, splitted individual pages to work on between team members.
Meeting participants: Riad, Daniel, Yuta Discussed about the several pages that need to be implemented. Precisely spoke about key features that need to be implemented such as a button to upload new art pieces on every webpage. Also discussed about the theme and colors to be used for the front end. At last, we discussed several issues regarding the implementation of the front end.
Discussed on how to start running the server and setting up the front end. Ryan helped the team so that every member has all the necessary tools working for this deliverable. Several technicalities concerning javascript were also discussed in this meeting.
In this call, we discussed the views/components each of us is working on. Daniel explained the logistics of how each page is supposed to look like. We discussed the artist and customer to have the same page because an artist can be a customer as described in our domain model. We have two logins: either as an administrator or customer. We discussed working on the art listing page which has not been implemented yet. We brainstormed about adding a view more button in the featured listing page. Then we talked about the architecture model and what to write for the explanation.
Ryan will give an update on what everything looks like. Daniel worked on the users page, artist page, and manager’s page. Daniel gave an update about what has been done. We could now see all the artwork, including favorited artwork on the art listing page. The artist can see all the artwork pinned, purchased, and can delete the artwork that has not been sold. Yuta talked about the individual art listing page that needs to pass an art listing id in order for it to work. For the checkout page, when an order is placed, the art order needs to be created in the database. Then we discussed about the architecture model to make sure if we need to make any changes to the three viewpoints architecture. Ryan talked about the firebase authentication and how to handle images on the publish art page. Ryan will work on publish art listing page and make changes.
Last meeting before the project submission. Ryan fixed several issues and helped other teammates fix last minute problems. We essentially discussed if everything is working well together and that the website is glitch free. Riad also suggested that he would start populating the database with popular art pieces to beautify the website.
Meeting participants: All team members.
This was our first meeting for Sprint 4. Daniel started going through the deliverable 4 pdf and what we need to do for the sprint. We discussed the features we need to implement for the mobile frontend. Daniel did the UI of the login page. We are going to have 4 views for the mobile app which include the login page, add favorite (buy favorite page), all art page, checkout page for our initial draft. We are doing the frontend from the customers/artists point of view using android studio. Then we talked about the presentation and working on the presentation slides and having a mock presentation the day before the deadline.
Meeting participants: All team members.
This meeting was to practice our presentation for the web app. Daniel went through the PowerPoint slides explaining why we worked on this particular web app and the need for it. Then we talked about the different users that are going to use the app and the functionalities of the app. Then we presented a live demo of the web app showing what we can do on the web app. Then we talked about the mobile app and its functionalities. Then we did a demo for the mobile app too. We discussed the grading for the presentation and what we need to add to the presentation slides.
