Sprint 2

Project

Sensors and actuators

The behavior of weightactor, sonaractor, thermometeractor and fanactor is fundamentally unchanged. We however refactored the code to decouple the actors from the mock objects and to reflect the presence sensors taxonomy presented during the requirements analysis. We also made these actors update their associated CoAP resources to perform some testing and to communicate with the Web GUIs. If requested to do so, they are also able to reply with their last issued event.

While the client and the manager GUIs should have proper Web interfaces, we believe that, for mock-objects, simpler Java Swing GUIs are more adequate.

Since parkmanagerserviceactor has many states and the processing of the events fired by the sensors would be too cumbersome, we introduced a new actor called sensorsbrokeractor which reads such events and stores their meaning. Parkmanagerserviceactor may then request them on-demand when it needs to know their status.

The manager GUI

The ParkServiceStatusGUI for the manager has been developed in Spring Boot as an external application. To simplify the testing, it is currently deployed on the same node as the ParkServiceGUI for clients and it's accessible via Web browser on port 8100, mapping "/status".

The interaction with the business logic of this external component, called ManagerGUI, is essentially the same as in the other Web GUI. Although, to receive data without waiting for user input, we regularly update the page via AJAX and read each interested CoAP resource. The parkservicestatusguiactor receives messages from the external GUI and redirects them to the correct actor.

The ClientGUI has been refactored to follow the same cleaner approach. Since all the data needed by the ClientGUI come from messages specifically intended for the parkserviceguiactor, it does not need to interact with any other actor inside our context.

Testing

All the tests conceived for Sprint 1 must still hold. Moreover, we defined a new test case to ensure that the system checks INDOOR-area and OUTDOOR-area to be free before starting related actions.

We also implemented an additional test case to check wether the mock objects are working as intended. Such test requires human interaction to be completed, otherwise we would not be able to assure that the GUIs are working. All the other test cases simulate the behavior of the mock objects and do not require human interaction to be completed.

We report hereunder the most significant fragments of the new tests:

@Test
fun checkDoors() {

  actor!!.emit("indoorOccupied", "indoorOccupied(0)")
  actor!!.forward("enterRequest", "enterRequest(0)", "parkmanagerserviceactor")
  actor!!.forward("carEnter", "carEnter(1)", "parkmanagerserviceactor")
  assertNotMovingInTime(3000)

  actor!!.emit("indoorCleared", "indoorCleared(0)")
  actor!!.forward("enterRequest", "enterRequest(0)", "parkmanagerserviceactor")
  assertLocationInTime("6", "0", "N", 10000)
  assertLocationInTime("0", "0", "S", 20000)

  actor!!.emit("outdoorOccupied", "outdoorOccupied(0)")
  actor!!.forward("exitRequest", "exitRequest(0)", "parkmanagerserviceactor")
  assertNotMovingInTime(3000)

  actor!!.emit("outdoorCleared", "outdoorCleared(0)")
  actor!!.forward("exitRequest", "exitRequest(0)", "parkmanagerserviceactor")
  assertLocationInTime("6", "4", "S", 20000)
  assertLocationInTime("0", "0", "S", 50000)

}

Summary architecture of the system as of Sprint 2

Executable model: trolley.qak

Test plan: Sprint2Test.kt