Updating

The updating takes place at regular intervals and the purpose is to get new data for the contents of the data model from the WPP data generator. A potential outcome of the updating is that reporting or logging must occur. The Server is Information Expert when it comes to updating its data since it holds the data model. It contacts the WPP data generator in order to get current data for all its data attributes, as can be seen in figure 3.7. The updating takes place one data attribute at a time. The Server object loops through all its data attributes in the data model and for each data attribute it asks WPP data generator for a value. As mentioned before, WPP data generator generates a random value, rather than realistic wind power plant data. It generates a random value that has a type corresponding to the type of data attribute and returns the value.

The type of the data attribute is specified by the Server object. For instance, in

Server EventMonitor

CheckAttribute (dataAttributeReference , oldValue , newValue , triggerOption )

Figure 3.8: Server contacts EventMonitor

figure 3.7 the type of the data attribute is a string, and the WPP data generator generates and returns a string.

A possible outcome of the updating is that reporting or logging must occur.

In order to investigate this, the Server delegates the task to the EventMonitor object. Every time a data attribute has been updated, the Server object contacts the EventMonitor. It passes along the following information

• Reference to data attribute that has been updated

• Old value for the data attribute

• New value for the data attribute

• Trigger option for the data attribute

Interaction between Server and EventMonitor can be seen in figure 3.8. With the parameters provided from the Server, EventMonitor is able to determine if the condition for a trigger is satisfied. As mentioned earlier three types of triggers exist: Dupd, dchg and qchg. Conditions for the triggers are

• dupd: This trigger is satisfied immediately, because the update takes place.

• dchg: If the new value is different from the old value, this trigger is satisfied

• qchg: Applies only to data attribute of type q (quality). The trigger is satisfied, if the new quality is different from the old quality.

If the trigger option for the current data attribute is dupd, then the trigger condition is satisfied immediately. This is due to the fact that the Server only informs the EventMonitor when a data update takes place. The dchg trigger depends on the values after and before the update. If the values are different, then the condition for dchg has been satisfied. It must be noted that from the system’s perspective there is no difference between the two triggers dchg and qchg. This is because a data attribute of type quality is treated like all other values such as strings or numbers. If change has happened then a dchg has happened. In other words qchg is a part of dchg.

From the perspective of EventMonitor, it does not matter whether dupd or dchg was satisfied. The important part is that a trigger condition has been sat-isfied, thus further action must be taken. If no trigger condition was satsat-isfied, there is no more work for the EventMonitor to do in relation to the current data

EventMonitor CBMediator

Notify(dataAttributeReference , oldValue , newValue , triggerOption )

Figure 3.9: EventMonitor informs CBMediator

CBMediator UBRCB

CheckAttribute (dataAttributeReference , newValue , triggerOption )

Figure 3.10: CBMediator informs UBRCB

attribute. It waits to be contacted by the Server next time a data attribute gets updated. If a trigger condition is satisfied, it the responsibility of EventMoni-tor to inform the object CBMediaEventMoni-tor (abbreviation for ControlBlockMediaEventMoni-tor).

Interaction between EventMonitor and CBMediator can be seen in figure 3.9.

The responsibility of CBMediator is to inform every control block in the system. Thus, CBMediator is considered as a Mediator, in pattern terms. CB-Mediator knows all the control blocks in the system indirectly because it knows CBManager. As mentioned before, CBManager knows all control blocks in the system. Each control block is responsible for determining if it must report/log.

Control blocks determine this by looking in their subscriptions. Interaction be-tween CBMediator and control block, in this example UBRCB, is illustrated in figure 3.10.

When CBMediator has informed all control blocks, there is no more work for it to do related to the current data attribute. What happens after this depends on the state of subscriptions in the control blocks.

The objective of each control block is to determine if it has a subscription for the data attribute. This can be done by looking in its Subscription object to retrieve its subscriptions and then for each subscribed data set use the DataSet-Manager to investigate if the data attribute reference is included in the data set. If it is the case then reporting or logging must occur depending on the type of control block. Up to this point the logic for reporting and logging has been identical. This is why common tasks for reporting and logging have been chosen to be represented as an abstract object named ControlBlock. The inter-action diagram in figure 3.11 shows how the control block object determines if

Control Block Subscription DataSetManager

Subscription

True or false GetSubscription

AttributeInDataSet (dataSet , dataAttributeReference )

Figure 3.11: Control block (UBRCB, BRCB or LCB) determines if report-ing/logging must occur

ExchangeModel CallBackManager

InsertCallBack (clientId , callback )

Figure 3.12: Storing contact details for the connected client

reporting/logging must occur.