Intermezzo

For the intermezzo, you will not be working on your usual repository, but on the repository of another team. The repository change match the formula: ((i+2)mod 6)+1

That is: 1 -> 3, 2 -> 4, 3 -> 5, 4 -> 6, 5 -> 1, 6 -> 2.

The security settings on github should have been changed so that you have access to the other team repo, but not yours anylonger. Contact the assistants in case of troubles.

The intermezzo consists of three tasks.

1. Reverse-engineer the main use cases implemented in the application. Create a UML use case diagram and upload it into your wiki under /intermezzo (you don’t have access to the other team wiki). You can use a computer tool or draw it by hand and then scan it. But it must be readable, and digital.

2. Implement a feature. You must implement several stories that correspond to a feature. When you are done, create a git tag intermezzo. The exact stories to implement are described below

3. Code review. Write a code review checklist according to the following perspectives: design, coding style, documentation, tests. You can use these Hints as a starting point. Items in the checklist must be unambiguous and self-explaining (also to someone who is not part of your team). Use the checklist to write a constructive and useful review of the project assigned to your team.The review should serve as guidelines to improve the existing code. Upload your checklist and review into your wiki under /intermezzo.

The three tasks represent 12 points. The three parts are due in two weeks and the deadline to deliver all three parts is November, 14 at 12:00.

Feature: Auctions

Story 1: Seller put an item for auction

As a seller, I can sell an item for auction, so that I can guarantee a minimal revenue yet maximize my profit.

• Acceptance criteria: Items can be sold in either mode: fixed price or auction.
• Acceptance criteria: Seller can specify a minimal price.
• Acceptance criteria: Seller can specify an "increment" for the auction.
• Acceptance criteria: Seller can specify an end time for the auction.
• Acceptance criteria: The selling mode, the minimal price, the increment and the end time can be changed as long as no buyer has placed any bid.

Story 2: Buyer bids for an auction

As a buyer, I can bid for an auction up to a maximal price, so that I can win the auction if I've the highest maximal bid yet minimize the actual price to pay.

• Acceptance criteria: The maximal price of the bid must be >= the minimal price defined in the auction.
• Acceptance criteria: The maximal price of the bid can be increased anytime, as long as the auction is not over.
• Acceptance criteria: Two bidders can not have the same maximal price.
• Acceptance criteria: If the n>0 bidders are sorted according to their maximal prices MP1 <= MP2 <= ... <= MPn, the current winner of the auction is the bidder n; the current selling price is defined as MP(n-1)+increment. The current winner and the current selling price is updated each time a new bid is placed or increased. If there are no bidder (n=0), there is no current winner nor current selling price.
• Acceptance criteria: Buyers see the item minimal price, increment, current winner, and current selling price.
• Acceptance criteria: When the current winner changes, the old winner receives an email.
• Acceptance criteria: At the time the auction terminates and there was at least one bidder (n>0), the transaction proceeds in accordance with the current winner and the current selling price at that time. The winner receives a confirmation email. If there was no bidder (n=0), the auction simply closes.
• Acceptance criteria: The highest bidder can't use the money they bid as long as the auction is not over. You need to ensure, I'm able to pay the bid.
• Acceptance criteria (optional): If several users interact with the system concurrently, a user might see and act on stale (outdated) data, e.g. stale selling price. The system must detect such situation (optimistic locking?) and inform users accordingly.

Note: as per this description, you can place or increase bids with values that are < the current selling price. Clearly, doing so is useless since it will never make you a winner.

Note 2: the most attentive reader will notice that the above description does not specify formally what's the current winner and selling price for n=1. We appeal to your common sense to define a sensible behavior

Story 3 (optional): View history of past winners

As a buyer, I want to see the history of past winners, so that I can guess the "eagerness" of competing bidders.

• Acceptance criteria: When auction is created, the history of past winners is empty.
• Acceptance criteria: When the current winner changes, the pair <current winner, current selling price> is added to the history.