The RADAR Modelling Language
4.1 The Modelling Language
A radar model is defined as a tuple (Obj, V ar, Contr), where Obj is set of objective definitions, V ar is a set of variable definitions and Contr is a set of constraint definitions.
4.1.1 Objective Definition
An objective definition has the form:
Objective (Min | Max) Name = Statistic(X)
where Name is the objective name, Min or Max declares whether the objective function should be minimised or maximised, and Statistic(X) is a statistical measure on a single random variable X. Statistical measures include:
• EV(X) denoting the expected value of X.
• Pr(X ∼ x) denoting the probability that X ∼ x where ∼ is ≤, <, =, >, or ≥.
• x=percentile(X, i) denoting the ith percentile of X, i.e. the value x such that Pr(X ≤ x) = i.
76
We saw examples of the use of first two types of statistics in the refactoring model and the bike sharing model in Chapter3. Percentiles are useful statistics for measuring risk.
For example, in the refactoring example, the Value at Risk (VaR) can be defined as:
Objective Min VaR = percentile(NB, 5);
4.1.2 Variable Definition
A variable definition is either an AND-refinement, an OR-refinement, or a parameter estimation.
An And-refinement has the form:
X = F (X1, ..., Xn)
where X is a variable and F (X1, ..., Xn) is an arithmetic or Boolean expression involving variables X1, ..., Xn.
The equation defining NB in bike sharing model in Section 3.2 is an example of And-Refinement where NB is defined as Benefit − Cost.
A parameter estimation has the form:
X = ProbabilityDistribution
where ProbabilityDisribution defines a probability distribution for the variable X. Prob-ability distributions include:
• uniform(min, max) denoting the uniform distribution between values min and max.
• exponential(x) denoting an exponential distribution that describes the time be-tween events which occur at a constant average rate x.
• triangular(min, mode, max) denoting the triangular distribution with lower limit min, upper limit max and the most likely value mode.
• normalCI(lower, upper) denoting a normal distribution characterised by the lower and upper bounds of its 90% confidence interval (i.e. lower is the 5th percentile and upper the 95th) percentile.
• geometric(x, n) denotes the geometric distribution that describes the probability of occurrence of the first success (x) in n independent trials.
• deterministic(x) denoting that the variable has the certain value x.
Examples of parameter estimations in our motivating example are:
68 NbrBikesToDeploy = triangular(500, 550, 600);
69 NbrOfBikesCurrentlyDeployed = deterministic(500);
An OR-refinement is used to express alternative option choices at a decision point.OR-refinements can be characterised by exclusive-or (single option selection) or inclusive-or (multiple option selections).
An OR-refinement with exclusive-or (XOR) selection has the form:
X = decision(label){
Option1 : Expression1; ...
Optionn: Expressionn; }
where label is the decision name, Optioni are option names, and Expressioni is an AND-refinement or parameter estimation defining the value of X if Optioni is selected.
When Expressioni is a parameter estimation, the value of a variable X is a parameter X[Optioni]. For example, in the cost-benefit refactoring model, the OR-refinement for Cost introduces the parameters Cost[As-is] and Cost[Refactoring].
The definitions of Cost and Benefit in the refactoring model are examples of OR-refinement with single option selection.
NbrFraudPerAccountBeforeBlocked = decision(“blocking policy”){
“block first” : NbrFraudBeforeDetection;
“investigate first” : NbrFraudBeforeDetection + NbrFraudDuringInvestigation;
}
NbrFraudBeforeDetection = decision(“processing type”){
“continuous” : 1 / ContinuousTrueAlertRate;
“batch” : NbrFraudsPerCompromisedAccountPerDay / BatchTrueAlertRate ; }
Figure 4.1: Fragment of radar model showing all OR-refinements in the financial fraud detection system
Consider also Fig. 4.1that shows all OR-refinements with single option selection of the fraud detection example introduced in Section1.2. The first OR-refinement states that NbrFraudPerAccountBeforeBlocked depends on the blocking policy; the second that NbrFraudBeforeDetection depends on the processing type; etc. Justification for these equations can be found in the detailed model in Chapter 7.2.1
Multiple OR-refinements can refer to the same decision. For example, in Fig 4.1, the variables ContinuousTrueAlertRate and BatchTrueAlertRate depend both on the fraud detection method.
An OR-refinement with multiple option selection (inclusive-or) has the form:
X = decision-subset(op)(label){
Option1 : Expression1; ...
Optionn: Expressionn; }
where label is the decision name, Optioni denotes options’ names, Expressioni denotes AND-refinement or parameter estimation corresponding to the selection of Optioni, op is an arithmetic operator (‘+’ or ‘*’) for combining multiple Expressioni if multiple Optioni are selected. The value of X, V alue(X), is defined as:
OPo∈O(d)selected(o) × Expression(o) (4.1)
where OP is either a P or Q, O(d) is the set of options in decision d, selected(o) = 1 if option o is selected and 0 otherwise, Expression(o) denotes AND-refinement or parameter estimation corresponding to the selection of option o. An OR-refinement with inclusive OR selection has a total of 2|O| possible option combinations, where |O|
is the number of options of a particular decision.
An example of OR-refinements with multiple option selection from the bike sharing example is:
79 CostOfBikeLocalisation = decision-subset(+)(“Tracking Mechanism”){
80 “GPS feature” : normalCI(5,10);
81 “RFID feature” : normalCI(2, 7);
82 }
The above example states that the cost of bike localisation depends on the tracking mechanism. Zero cost is incurred if none of the tracking mechanism is selected. However, if the choice is to select only the GPS option, the cost is believed to be between £5m and
£10m; if the choice is to select only the RFID option, the cost is believed to be between
£2m and £7m. Finally, if the choice is to select both GPS and RFID options, the cost is the sum of the individual cost incurred by implementing each feature separately. The costs are added because of the ‘+’ operator in the expression.
An inclusive-or refinement with a multiplication operator is useful for modelling reli-ability of system components. For example, in the bike sharing system example, the reliability of the system’s localisation component is defined as:
ReliabilityOfSystemLocalisationComponent = 1 - FailureOfSystemLocalisationComponent FailureOfSystemLocalisationComponent = decision-subset(*)(“Tracking Mechanism”){
“GPS feature” : FailureProbabilityOfGPSComponent;
“RFID feature” : FailureProbabilityOfRFIDComponent;
}
FailureProbabilityOfGPSComponent = normalCI(0.01, 0.05);
FailureProbabilityOfRFIDComponent = normalCI(0.10, 0.20);
The above example states that the reliability of the system localisation components depends on the tracking mechanism. If none of the tracking mechanism is selected, the reliability is zero. However, if the choice is to select only the GPS option, the reliability is the failure probability of the GPS component deducted from one. Similarly, if the choice is to select only the RFID option, the reliability is the failure probability of the RFID component deducted from one. Finally, if the choice is to select both GPS and RFID options, the reliability is the product of the reliabilities of each component.
It is important to note that one can model inclusive-or option selections in the bike sharing example using the XOR construct of an OR-refinement. For example, we model the tracking mechanism decision that involves inclusive OR option selection between GPS and RFID as below:
79 CostOfLocalisation=decision(“Tracking Mechanism”){
80 “No feature” : deterministic(0);
81 “GPS” :CostOfGPS;
82 “RFID” : CostOfRFID;
83 “GPS and RFID” : CostOfGPS + CostOfRFID;
84 }
85 CostOfGPS = normalCI(5,10);
86 CostOfRFID = normalCI(2, 7);
The limitation of using the XOR construct to model an OR option selection is that the modelling effort increases as the number of options for an OR decision increases. As a result, one would have to write expressions explicitly for all possible option combina-tions. This implies introducing AND-refinements (e.g. CostOfGPS and CostOfRFID) for each possible option combination. radar addresses this problem using the inclusive-or constructs.
4.1.3 Constraint Definition
radar provides constructs to model constraint relationships between options of deci-sions. Such Constraints have the syntax
Constraint labeli : optioni ./ labelj : optionj
where optioni and optionj are options’ names, labeli and labelj are decisions names,and ./ is a constraint relationship in the set {requires, excludes, couples}.
Definition (requires). optioni : label1 requires optionj : labelj means that the selec-tion of opselec-tioni implies the selection of optionj. However, optionj can be selected without optioni being selected.
Definition (excludes). optioni : labeli excludes optionj : labelj means that both optioni and optionj cannot be selected together.
Definition (couples). optioni : labeli and optionj : labelj are said to be coupled if none of option1 or option2 can be selected separately.
Examples of constraints relationships in the bike sharing model example of Section 3.4 are:
121 Constraint “Bike Manufacturer Brand” : “A-Bike” excludes 122 “Tracking Mechanism ”: “GPS feature”;
123 Constraint “Kiosk Registration” : “Card Dispenser” couples 124 “System Access Management”: “Key Card”;
125 Constraint “System Access Management” : “Key Card” requires 126 “Kiosk Registration” : “Key card reader”;
The expressions above declare that a bike of brand “A-Bike” does not support the GPS feature; the card dispenser option of the Kiosk registration and the key card option of the systems access management must be implemented together; and the key card option of the kiosk registration requires a key card reader.