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:

  1. 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.
  2. 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"
  3. 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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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".