Contents > 9 Extending the Metrics and Rule Engine > 9.4 Procedure Definition Guidelines
9.4 Procedure Definition Guidelines
Before you embark on creating new metric, set, or rule procedures,
consider the following guidelines:
- Defining new procedures should rarely be necessary. The primary means of
defining new metrics and rules is the SDMetricsML, which is faster to do and
only requires a text editor for tool support. Only when the capabilities
of the SDMetricsML are absolutely insufficient should you consider defining
new procedures.
- A metric, set, or rule procedure does not define a concrete metric, set,
or rule. It rather provides a template and algorithm for the definition of
a whole family of different metrics/sets/rules. Think of the many different
metrics you can define with just the "projection" procedure. Therefore, aim
to define the attributes of your procedures to provide as much flexibility as
possible. Make sure that all inputs to the procedure can be specified as
procedure attributes, and only hardcode default values for optional attributes
in the implementation of the procedure.
- When you define the attributes for your new procedure, use established
groups of attributes such as the standard filter attributes
supported by class FilterAttributeProcessor,
or the "sum/stat" attributes of class SummationHelper. Your new
procedures will better blend in and form a cohesive whole with the standard
procedures, and the implementation of your procedure will be easier.
Where to go from here
The above examples for metric, set, and rule procedures did not cover
the entire metrics and rule engine API. On the SDMetrics web site,
you can
- view the documentation of the complete API,
- download the SDMetrics Open Core distribution, which contains
the implementations of all the standard metric, set, and rule procedures
described in Section 8 "Defining Custom Design Metrics and Rules". Knowing what these procedures do, you can
study their implementation, which also makes use of the entire API.