Custom Default Values

It is unlikely that you will ever need to customize a default value plug-in for a domain. The displayed default value can be customized using the respective UML domain definition option. The predefined assumed default values for the domains are probably sufficient for every need. However, in the unlikely event that you need to customize an assumed default value, the steps are little different from those for other plug-ins.

Another reason for customizing a default value plug-in is where the displayed default value is not fixed and cannot be defined in the UML model. An example of this is the use of the current date as a displayed default value.

1. Identify an existing default value plug-in class that you want to customize.
2. Create a new sub-class of the relevant default value plug-in and override the getDisplayedDefault method.
3. The implementation of the method should simply return a value compatible with the Java type used to represent values for the relevant root domain. These Java types are listed in Java Object Representations.
4. Configure your new plug-in for the relevant domains.

In this example, the displayed default value for an interest rate is calculated dynamically using a notional CentralBank class that somehow returns the current interest rate.

/**
 * Returns the current interest rate by contacting the
 * central bank!
 */
public class InterestRateDefault
       extends SvrFloatDefault {
  public Object getDisplayedDefault()
         throws DomainException {
    try {
      return new Float(CentralBank.getInterestRate());
    } catch (Exception e) {
      throw new CustomDomainException(-200099, e);
    }
  }
}

The example assumes that the InterestRateDefault class will be associated with a descendant of the SVR_FLOAT domain that requires a default value to be of the java.lang.Float type. By extending the SvrFloatDefault class, the new default value plug-in will automatically use zero as the assumed default interest rate value.

The exception handling uses a CustomDomainException class. As the getDisplayedDefault method throws a DomainException, and not a ConversionException, you could create such a custom exception class by deriving it from DomainException in exactly the same way as the CustomConversionException class was derived from ConversionException in Custom Exception Classes. You might note that, as the DomainException class is an ancestor of the CustomConversionException class that the CustomConversionException class could be used here instead. This will work, but you must not attempt to report a message containing the "%0s" placeholder for the field label, as automatic replacement of the field label is not supported when a DomainException type is expected.

The example above shows the unknown exception thrown by the CentralBank class being added to the new custom exception. You only need to implement the appropriate constructor to support this. The super-class already has a constructor with the same signature, so your constructor's implementation need only call that. There is no need to extract a string value or stack trace from the exception; all will be reported correctly when necessary.