Adding a new resource

Until now, we kept the application as minimal as possible considering the involved resources. As a consequence, the definition of our metro network, only constituted with generic connections, is not really user-friendly. In this lesson, we will add new resources to our application to enhance its model and progress in the direction of a real life application. As an example, we are going to introduce the notion of line in our metro network, to assist the customers in finding their way during their travels.

In our simplistic model, a line is just represented by a color value associated with a Connection (link between 2 stations, a departure and an arrival). So, introducing the notion of line is reduced to associating a line field to the notion of Connection. This latter notion is represented in our model by the resource build as the (departure, arrival) couple, which exists place in the Connection and Travel bags. The line field (or, in our case, the line resource) is then added to these bags.

Here are the updated descriptions of the bags integrating the new line resource:

 bag2 = data.BagDescription()
 bag2.name = "Connection"
 bag2.type = ("Multiset", "TupleSpace")
 bag2.fieldnames = ['line', 'depature', 'arrival']
 bag2.params = {}

 bag4 = data.BagDescription()
 bag4.name = "Travel"
 bag4.type = ("Multiset", "TupleSpace")
 bag4.fieldnames = ['line', 'departure', 'arrival', 'name']
 bag4.params = {}

Updating the scripts

As the resource model evolves, the application script should be updated accordingly.

Initialization script: init.ls

Considering the 2 bags integrating the new line resource, only the Connection one is involved during the initialization phase. In the init.ls script, the corresponding rule is updated as follow :

::
{
["Metro","Connection"].put("red","A","B") ;
["Metro","Connection"].put("lightblue","A","D") ;
["Metro","Connection"].put("yellow","C","D")
}.

A dedicated color is associated to each distinct Connection.

Application logic script : trom.ls

The Travel resources are inserted at runtime based, among other things, on the information read from the Connection bag. The line resource should be copied from the read Connection and propagated in the Travel bag, like the departure and arrival fields of the resource. Then, the coherence is preserved within the system, concerning the line, departure and arrival resources.

The rule is updated as follow :

 {*,!}["People","Customer"].rd(name,departure) &
 {*,!}["People","Destination"].rd(name,arrival) &
 {*,!}["Metro","Connection"].rd(line,departure,arrival)      <--- read the line resource in the Connection
 ::
 {
 ["People","Customer"].get(name,departure);
 ["People","Destination"].get(name,arrival);
 ["Metro","Connection"].rd(line,departure,arrival);          <--- re-read the line resource in the Connection (validation)
 ["People","Customer"].put(name,arrival) ;
 ["Supervision","Travel"].put(line,departure,arrival,name)   <--- propagate the line resource in the Travel
 }.

Start the application and run the rules with following command:

python quinoa.py --go

Results

Initial state of bags

| People.Customer| People.Destination| Metro.Connection| Supervision.Travel| |---|---|---|---| | ("Alice","A")| ("Alice","D")| ("red","A","B")|| | ("bob","B")| ("bob","D")| ("lightblue","A","D")|| | ("charles","C")| ("charles","D")| ("yellow","C","D")|| | ("denis","A")| ("denis","D")||

The state of bags after the rules are enacted:

| People.Customer| People.Destination| Metro.Connection| Supervision.Travel| |---|---|---|---| | ("alice","D")| ("bob","D")| ("red","A","B")| ("lightblue","A","D","alice")| | ("bob","B")|| ("lightblue","A","D")| ("yellow","C","D","charles")| | ("charles","D")|| ("yellow","C","D")| ("lightblue","A","D","denis")| | ("denis","D")|||