Project Report: Sprint 2

Effort Table

Name	Contributions	Hours
Louis Barrette-Vanasse	Fixing the team's bugs User and pet controller and service Extra features such as encryption, mailing, token generation and password strength Mockito tests for user and pet	32
Mathieu Bissonnette	Forum and Comment classes (Service, TestService, Controller, DTO)	25
Christopher Boustros	Application classes (Service, TestService, Controller, DTO)	17
Ding Ma	UserServiceTesting, Donation classes (Service, TestService, Controller, DTO), Controller testing, Testing Report, integration	47
Katrina Poulin	Pet and Advertisement classes (Service, TestService, Controller, DTO), Sprint reports, Test plans	20

Meetings

Meeting 1

Location: Trottier 5th floor

Date: February 11, 2020

Time: 10:30AM -11:30AM

Attendees:

Christopher Boustros, Ding Ma, Katrina Poulin, Louis Barrette-Vanasse, Mathieu Bissonnette

Minutes:

• Division of labour for Deliverable 2 (see Effort Table). In general, every team member is assigned one main feature.
• Gathered questions about the backend in general and task specific questions for the TAs.
• Reviewed the model and how it fits into the task assigned

Meeting 2

Location: (Conference call)

Date: February 20, 2020

Time: 8:15PM - 9:00PM

Attendees:

Christopher Boustros, Ding Ma, Katrina Poulin, Louis Barrette-Vanasse, Mathieu Bissonnette

Minutes:

• General update on everyone's progress on the deliverable

  • Mathieu: Done: Service and DTO classes created and small changes to the Repository classes (all for Forum and Comment)
    ToDo: Controller classes and testing
  • Louis: Done: Service, Controller, DTO and ServiceTesting done for User
    ToDo: Controller tests for User
  • Ding: Done: Service, Controller, DTO and ServiceTesting done for Donation
    ToDo: Controller tests for Donation
  • Katrina: Done: Service, Controller, and DTO done for Advertisement, Pet DTO created
    ToDo: Service and Controller classes for Pet, Service and Controller testing for Pet and Advertisement
  • Chris: Done: Worked on Service, Controller, and DTO for AdoptionApplication
    ToDo: Finish Service, Controller, and DTO for AdoptionApplication and do unit tests for AdoptionApplication. Finish business methods for Pet.

• Discussion on some concerns and design decisions:

  • Should we create an association Forum ----> User in the model?
    No. We decided that even if it can be useful for a user to be able to delete their own forums and comments, it is a complicated addition to the program and we wish to focus on features that we think are more important, such as Advertisements, Pets and Users.
  • Should we create custom exceptions for all possible errors in the controller and service classes?
    Yes. It will be easier to debug and the program will be less ambiguous if we create a specific exception for illegal arguments. Hence, we replace IllegalArgumentExceptions by a meaningful exception name when needed.
  • Should advertisements posted and forums have a unique name?
    Advertisements should not have unique names. It is very likely that two different advertisements have the same name. For example, the title "Black cat for adoption" can come up in advertisements multiple times. However, forums should have unique names to gather all the information at the same place. For example, if a customer is asking for recommendations about the care of a Labrador dog, the question should be answered once. Then, all other customers who want the same information can refer to this post.

Meeting 3

Location: Trottier 5106

Date: February 27, 2020

Time: 4:10PM - 5:00PM

Attendees:

Christopher Boustros, Ding Ma, Katrina Poulin, Louis Barrette-Vanasse, Mathieu Bissonnette

Minutes:

• General update on everyone's progress for the deliverable
• Division of the project report tasks:
  • Ding: Test Reports (screenshots of Controller tests from Postman)
  • Katrina: Javadoc and meeting minutes
• Discussion about the number of token required to validate a user (in the Controller classes):
  • When trying to modify or create something, we need to make sure that a user is authorized to do so. For example, a user cannot edit a pet for which they are not the pet owner.
  • Hence, we either need an additional token to verify the user, or we can overwrite the registration token to use it in the login. We decided that we would keep only one token per user since it is more simple. Moreover, we don't need the registration token anymore once we are registered, so we can easily overwrite it with a login token.