Last modified 10 years ago Last modified on 10/19/2009 09:17:03 PM


A policy is a set of named parameters that can be used to configure the internal data and behavior of an object within an application. An important feature of Policy objects is that the parameters can be loaded in from a file. Thus, it allows applications fine grained control of objects even if much of the configuration parameters they provide are normally set to defaults and otherwise do not change.

Policy objects are built around DataProperty objects, although the types allowed value types are restricted (to ensure a simple serialization format). In particular, Policy parameters can be hierarchical, just like DataProperties. That is, a Policy can contain a parameter whose type itself is a Policy. This feature can be used to configure a whole hierarchy of objects, even if the object classes (and their associated policy parameters) have developed by different people.

The UML design allows for a special parameter value called a PolicyRule. This allows for the actual value to be determined according to a a rule that interprets the values of other parameters or other runtime conditions. Implementation of this class is not planned for inclusion in DC2.

Configuring an Object using a Policy

A developer that wishes to support a configuration via a Policy will normally do so by providing a constructor that takes a Policy object as an argument. Then, within the implementation, the constructor is coded to look for specific names (of its devloper's choosing) that the paramaters saved under. (Documentation of these names are provided via a Dictionary; see below.) In particular, the class will want to access the configuration via these names without concern for name collisions (other objects looking for different Policy parameters under that same name) not knowledge of how the class being configured is being used. That is, encapsulization of information is preserved.

It is expected that one object may in turn need to configure other objects it manages. For example, an Image Subtraction Stage object may need to internally configure a Kernel object. The support for hierarchical parameters means that the outer object (Image Subtraction Stage) can pull out all of the policy data for a Kernel instance under a single name and pass it to the Kernel object. In this way, the Kernel policy names won't conflict with the Image Subtraction Stage policy names. It is not required that a developer make use this hierarchal method; however if he/she does not, it will require collatoration with the design of all the other objects that may draw from the same level policy data. necessary

Parameter Types

The Policy interface restricts what types of values that can be loaded and retrieved. See PolicyFormats for the list

File Formats

Use paf.


It will be necessary for developers to document the policy parameters an class implementation will look for to configure itself. I propose the creation of parameter dictionaries based on the same format used for the policy files themselves. A Dictionary will be able to record for a class's Policy each parameter name, its types, default value and other syntactic information. This can be used to validate a particular policy file or be used as a default when none is available. An example of a dictionary is here in JSON and PAF formats.