Sprint 1

Project

The business logic

The business logic encoded in the parkmanagerserviceactor follows precisely the finite-state machine diagram presented during the problem analysis, but with some simplifications given by the presence of just one parking-slot. All the states of the automaton are already present and the ability to take in and deliver meaningful SLOTNUM and TOKENID values has been arranged.

The trolley

The customer provided a new piece of software, called BasicRobot, which is compatible with the WEnv and with real DDR robots and requested it to be used as the implementation of the trolley.

Our trolleyactor does not need the presence of the RobotProxy component anymore and may directly send messages to the BasicRobot instead, which is identified as an ExternalQActor on a different context. The fundamental behavior of the trolleyactor is however unchanged.

The coordinates of the points of interest of the parking-area, previously hard-coded inside the trolleyactor, are now externally stored as a Prolog knowledge-base.

home(0, 0, s).
parking(1, 1, e).
indoor(6, 0, n).
outdoor(6, 4, s).

The client GUI

The ParkServiceGUI for clients has been developed in Spring Boot as an external application and is accessible via any Web browser on port 8100.

The GUI sends messages to the business logic as an alien component and receives information by watching the CoAP resource associated with the parkserviceguiactor.

The messages enterRequest and carEnter and their responses (i.e. SLOTNUM and TOKENID) are dispatches instead of requests-replies to simplify the testing (the component making the requests and the one receiving the replies may differ) and because the external ClientGUI service receives status changes via CoAP.

Testing

We just need to check wether the trolley manages to reach the correct points of interest in the correct order and in a sensible amount of time. Moreover, the trolley must be unaffected by enter requests while the parking-slot is full or exit requests while it's empty. The JUnit module will send messages to the business logic pretending to be parkserviceguiactor and will try to check the reactions of the trolley.

The class DirectionalPlanner, previously discussed and developed for the problem analysis executable model, has been refactored into a Kotlin object to closely resemble its wrapped component (PlannerUtil) and to simplify the testing. This component will be used to check the position and the orientation of the trolley.

The full test plan for this sprint can be retrieved from the following local link: Sprint1Test.kt (copy on GitHub here). We report hereunder the most significant fragments:

@Test
fun checkCleanSequence() {

  actor!!.forward("enterRequest", "enterRequest(0)", "parkmanagerserviceactor")
  assertNotMovingInTime(3000)

  actor!!.forward("carEnter", "carEnter(1)", "parkmanagerserviceactor")
  assertLocationInTime("6", "0", "N", 10000)
  assertLocationInTime("1", "1", "E", 10000)
  assertLocationInTime("0", "0", "S", 10000)
  assertNotMovingInTime(3000)

  actor!!.forward("exitRequest", "exitRequest(1)", "parkmanagerserviceactor")
  assertLocationInTime("1", "1", "E", 10000)
  assertLocationInTime("6", "4", "S", 10000)
  assertLocationInTime("0", "0", "S", 50000)
  assertNotMovingInTime(3000)

}

Summary architecture of the system as of Sprint 1

Executable model: trolley.qak

Test plan: Sprint1Test.kt

New workplan

Because of other exams we had to take, the delivery dates have shifted.

Sprint 1 will be delivered on July the 28th.
We expect Sprint 2 to be completed within 3 working days.
We expect Sprint 3 to be completed within 3 more working days.
We expect the whole project to be finished by August the 4th.