How to Configure the XRadar itself
Prerequisites
Prior to installing the XRadar, the following prerequisites are mandatory:
Setting up the testproject
The testproject coming with the release is already "preconfigured" for you. Simply, "cd" into its directory
and launch the appropriate testall.sh (or testall.bat).
The radar-config.xml
The radar-config.xml is the most important artifact in your XRadar configuration. It includes
the metadata that defines how your system is partitioned into subsystems, defines how these subsystems
are logically layered and how they are allowed to depend on each other. The file also defines the metric
breakdown structure that quantifies the quality of the system. This breakdown structure is a hierarchical
node tree where the end nodes are values calculated by the various metrics found in the XRadar common xml-database.
radar-config.xml resides in $YOUR_PROJECT/etc/. Through the property radar.config in statics.properties, you may put this file
anywhere you like. It is recomended to have only one radar-config.xml for all versions/releases of a project.
The easiest way to generate a radar-config file is by copying and modifying the same file in the testproject that comes with the XRadar
(This file is found here).
The root tag of the file is "radar-config". Underneath the possible elements are :
- Packages to skip within the "skip-packages" element
- The system public api by the "system-api" element
- Subsystems definitions "subsystems" element
- Defined metrics definitions "defined-metrics" element
skip-packages
Within the skip-packages element you may optionally skip packages that will be
left out of completely from the analysis.
As subelements, you can have as many "package-root" elements as you like:
- The "name" attribute points to the package root element
- If you want the XRadar to define everything below a certain root, set the attribute "recurse=true"
system-api
Within the system-api tag you may optionally set what is the system
api of the system. The system api is defined here as the input packages
to the system. This will form the basis of some of the reports and view
in the XRadar. As sub-elements, you can have as many "package-root"
elements as you like. The definition is as under "skip-packages" above.
subsystems
Within the subsystems tag you define the modularization of the XRadar. This is a really important part of the
configuration, since it defines the strucure of the system and forms a basis for several of the reports.
Follow these quidelines when setting up the subsystems and dependencies:
- Within the "subsystems" tag, you can have as many "subsystem" elements as you like:
- Each subsystem has a name that you declare in the "name" element
- Each subsystem must have a unique id the you put in the "id" attribute
- Each subsystem has a "level" attribute that defines on wich level in the
architecure layering that this subsystem resides on.
- Each subsystem consists of one or more packages "included-packages/package-root" elements
- The "name" attribute points to the package root element
- If you want the XRadar to define everything below a certain root, set the
attribute "recurse=true"
- Use the legal-subordinates/subsystem element to add all the subsystems that are legal below
the current one. This defines the layering structure. Note that you also need to include the current
susbsystem in this structure. Otherwise it will be illegal.
defined-metric
Follow these quidelines when setting up the defined metrics:
- Before you are fairly well used to the XRadar you should simply copy
the "defined-metrics" definition that comes the the XRadar
testproject. When you have become a more advanced user, you may define a metric
that is better suited to your particular application.
- The easiest way to define your own metric breakdown structure is to base it
on a the definition in the base project, and iteratively make
your own. It takes some testing and tuning and a lot of disvussion to define a metric
that suites your needs.
- Within the "defined-metrics" tag, you have one "thresholds" element. This tag defines threshold values for all metrics defined, a well as a color code for the metric. Each threshold is represented by a "threshold"
element that exists below "thresholds":
- Each threshold has a level that you declare in the "level" attribute.
- Each threshold must have a max value that is it valid for the you put in the "max-value" attribute.
- Each threshold has a "color" attribute that represents the color code that should be used in the XRadar for the values of the metric.
- Within the "defined-metrics" tag, you typically also have one "metric" element.
An important consideration is to define a metric that has a value between 0 (the worst
value) and 1 (the best value):
- Each metric has a name that you declare in the "name" attribute
- Each metric must have a unique abbreviation the you put in the "abbreviation" attribute
- Each metric has a "type" that has one of two values. If the "type" value is "aggregate", the
value is simply the sum of all underlying metrics.
If the "type" value is "value", the metric is a definition of various metrics as defined in the
XRadar.
-
The "metric" element consists of:
- a "value" element that defines the value in question. This element can have two formats:
- If "metric" element has type "aggregate", the value element has a one or more "metric" child element(s) below
that defines the value of the aggregate value by child metrics. Each metric element will linked to the child elements
defined below the super "metric" element. The abbreviation attribute specifies the metric to aggregate. The significance
attribute gives the metric's weight.
- If "metric" element has type "value", it is calculated be the procedure described below where the source are various
child metric values.
- "metric" child element(s), if and only if the "metric" element has type "aggregate". The defition of this element is
identical tom the "metric" description as described above. These metric values should also have a minimum value og 0 and
a maximum value of 1.
-
When the "metric" element is of type "value", its value element is a calculation that is defined by the elements within.
The child elements are nested recursively and can have the following types:
- "stat". Points to a unique package statistic, defined by the group and value attributes. To find legal values for that,
you can look under the the catalog ${XRADAR_HOME}/etc/data/metric-descriptions.xml. Here you can find the relevant group and
metric names that you can use to define the stat attributes.
- "number". Gives a specific value given by the value attribute.
- "value". Nested value element with exactly the same specification as the mother element.
- "operator". Must follow a and be followed by a : "stat", "number" og "value" element. This performs standard arithmetic
operations : "add", "subtract", "divide" and "multiply".