Figure U.03 - Instance of Usage Specification

As mentioned above there are two alternatives to model specific usage record structure:<br/><ul>
<li>As sub-class of the Usage; in such case the UsageSpecification is irrelevant and the subclass definition well defines the set of required and optional characteristics including its constrains, default values, etc.</li></ul>
<ul>
<li>As instance of UsageSpecification with specific set of UsageSpecCharacteristics.</li></ul>
A combination of the above might be used as well or as an instance of UsageSpecification as shown in Figure U.03.<br/>The sub-class modeling approach is considered to be strongly type approach. It enables the user/implementer to easily check and refer the Usage definition in modelling time, but it is much less dynamic, and each time new usage is defined, or existing usage is modified the model and probably the underlying database changes. Usage definition cannot be defined in run time and parsing the Usage event becomes easy. This approach is suitable for events with fixed structure (such as standardized events) that are not likely to change in the future.<br/>The Usage Specification approach is very dynamic and enables changing and adding Usage definition in run time. This approach is much more flexible but parsing the Usage event in run time becomes more complex. This approach is more suitable for events that change from time to time, since the change is modeled in meta data and not in classes.<br/>Three classes were pre-identified in the SID:<br/><ul>
<li>ResourceUsage</li><li>ServiceUsage</li><li>ProductUsage</li></ul><p/>