”Other views”
Information view
The IoT IM details the structure of the information that constitutes a VE and the
ServiceDescription of a Service that acts on the VE (see Section 3.4.1. In this
section we will describe the modelling of these two elements for the PBL use
case. Notice that the information view does not cover data formats. These lie
within the purview of the deployment view.
Modelling the VE
Figure 75 : IM of the VE for resident-parker and time-parkers. (in orange edge: unique
to resident-parking).Following the IoT Information Model (see Section 3.4) a VE can have one or
more attributes, each having an attribute Name and an attribute Type. In the
PBL use case, a VE is an entry in the Parking-White-List database identifying a
car that is allowed to use the PBL parking facility. Since we have considered
two types of parking cars (the car of a resident-parker and the car of a time-
parker), the VE for one car type is slightly different than the other one. The first
two attributes (License plate numbers and Parking zone) depicted in Figure 75
are common attributes for both types of VEs, while the third attribute (Parker
type) is part of the VE resident-parker. Notice though that we only chose the
license plate number as the VE and did not include in the parking zone. This
design decision is based on several previous decisions. First, one of the main
business principles behind the PBL system is its future extensibility. As
discussed in the requirements section above, there are many requirements that
stipulate the evolvability of the PBL system. This boilt, among others, down into
loose coupling rather independent FCs. One example for the latter is the choice
to introduce a Virtual Entity Repository for the White List in the system
architecture. In the information model we drive this modularisation one step
further in that we chose a single piece of information, the license-plate number,