Homework # 3

In this homework, you will implement the handling of plant hire requests in BuildIt’s information system. In order to test this functionality, you will implement the components of the RentIT system required to receive purchase orders, to retrieve/view purchases orders and to accept/reject purchase orders.

The RentIT and the BuildIT systems should be implemented as separate Spring boot projects. The RentIT system must be developed in Spring version 2.0.0 (this is the same version you used for homeworks 1 and 2), while the BuildIT system will be developed using Spring 2.1.3 (which is the version you used in Practice #7).

The required functionality is described below:

When a site engineer needs to hire a plant, he/she consults the catalogue of a plant supplier in order to identify a plant that fulfils the requirements. Every plant provided by a supplier is identified by a plant identifier. Once the site engineer has identified the required plant, he/she checks the plant’s availability during the required period of time as well as the price. If the plant is available, the site engineer creates a Plant Hire Request, which includes the identifier of the construction site where the plant is needed, the supplier of the plant, the plant’s identifier, the expected start and end date of the hire period and the cost of hiring the plant for this period of time. This cost is calculated based on the plant’s price per day of the selected plant and the number of days the plant is hired. Naturally, the plant hire request also includes the name of the site engineer making the request.

Every plant hire request has to be approved by a works engineer at BuiltIT. The purpose of this approval is to avoid excessive or unnecessary plant hiring and, more generally, to ensure that plant hiring costs are minimized. In some rare cases, the works engineer rejects the plant hire request or makes modifications to the plant hire request before approving it. If the works engineer rejects or changes the plant hire request, they normally write a short explanation in a “comments” field in the plant hire request. In such cases, it is usually the case that the works engineer talks with the site engineer prior to rejecting or modifying their request in order to avoid misunderstandings.

Once the works engineer has approved the plant hire request, Buildit’s information system automatically generates a Purchase Order (PO) for hiring the plant and sends this PO to the plant supplier. The supplier may accept or reject the PO. One reason why a PO might be rejected is that the plant that is being requested is no longer available during the requested period of engagement (e.g. it has been hired by someone else).

As you can see, in addition to the processing inside BuildIt, the scenario above incurs in at least 3 major REST interations between BuildIt and RentIt:

querying RentIt’s plant catalog (BuildIt ⇒ RentIt),
creating a purchase order (BuildIt ⇒ RentIt), and
notifying the decision made by a RentIt’s employee on Purchase order submitted by BuildIt (RenIt ⇒ BuildIt).

Different from some of previous lab sessions and homework, we will assume that the decision on whether to accept or reject a purchase order is made by a RentIt’s employee and not automatically. The latter also implies that we would need that both information systems are running and that you would write some Cucumber user stories to simulate the user interactions with both information systems. Since, in this moment we have not discussed anything about authentication/authorization, we would not distinguish the role of users in BuildIt side (e.g. no distinction between users playing the roles of site and works engineers).

Throughout the scenario, the information systems exchange information (e.g. BuildIt retrieves the information about plant inventory entries during the catalog query and later submits a purchase order to RentIt, etc.). Moreover, BuildIt’s information system must, at some stages, store reference to RentIt’s resources: e.g. the Plant Hire Request (BuildIt’s document) keeps a reference to the Purchase Order (RentIt’s document), etc. In this context, we expect that your domain model considers to store only the reference to remote resources a not the full representation as illustrated in the following (partial) diagram:

hw3 diagram

Henceforth, we would expect that your BuildIt’s information system stores only the reference to RentIt’s resources (e.g. “href” in hypermedia REST) and not their full representation. Note that such reference, i.e. href value, should be considered the resource identifier. As mentioned during the lecture, storing some additional information (e.g. plant inventory entry’s name) is possible to avoid some interactions and have enough information to render in BuildIt’s front-end. The idea is that, when the full representation is required, we can use the “href' to retrieve it.

Tasks

Based on the requirements above you will perform the following tasks:

Draw the domain model for handling the plant hire request as specified in the description above. In principle, there is only bounded context in the scenario, which I propose you to refer to as “procurement”. Clearly identify the aggregates, their corresponding aggregate roots and distinguish entities and value objects. Identify also there the classes that represent remote resources.
Using a sequence diagram, describe the components (e.g. controllers, repositories, services, etc.), method calls and message exchanges incurred in the scenario, illustrating different cases: plant hire request accepted by site engineer with its corresponding purchase order accepted, plant hire request rejected, and plant hire request accepted by site engineer with its corresponding purchase order rejected.
Design a REST API to handle the handling of plant hire requests. This API must capture the life cycle of a Plant Hire Request as described in the scenario. To this end, you have to draw a state model (like the one in slide 11 of Lecture 6) and its correspond table representation (like in slide 13 of Lecture 6).
Implement all the spring components that are associated with the design in the previous tasks (i.e. domain model using JPA, spring repositories, REST Controller, Application services, DTOs and resource assemblers). To this end, you have to create a new spring boot application for BuildIt. However, you can reuse several components from RentIt’s application.
Implement a minimal VueJS frontend covering the UI for handling the creation and processing of plant hire requests as designed/implemented in the previous tasks.
Using cucumber, write acceptance tests for the following scenarios:

- (1) querying RentIt's plant catalog, (2) selecting one plant for creating a Plant hire request, (3) accepting the plant hire request (this should entail the creation of the Purchase order in RentIt's side), (4) accepting the purchase order in RentIt’s side (which should result in notifying BuildIt about the decision, and (5) checking the state of the Plant hire request after receiving the response (notification) from RentIt's about the decision on the purchase order.

- Same as the previous scenario, except that RentIt’s employee rejects the purchase order in step (4)

- (1) querying RentIt's plant catalog, (2) selecting one plant for creating a Plant hire request, (3) rejecting the plant hire request

You can find some hints for writing the Cucumber tests here: https://stackoverflow.com/questions/50142537/how-do-i-perform-bdd-test-for-spring-application-when-am-running-the-the-front-e

You must submit the link to your bitbucket repository (no github) to the course’s submission web page. Add username manuel_camargo as a collaborator in your project repository(ies). Remember that the homework must be submitted in teams of 3 or 4 students. Add the name of the team members in a file to Git repository (e.g. text file or markdown file). If a student did not complete his part of the homework, please send an email to the lecturer.

As in the previous homeworks, you are required to submit the link to the Git repository(ies) – it can be only one or two repositories (or three or four if you wish to implement the frontends in separate repositories). The design artifacts (domain model, sequence diagram and other diagrams) must be added to the corresponding repository as a PDF file.