Week 14 of 2009

I've been working on a variety of things this week including event instance support, default values and mathematically dependent referential attributes. I won't expand on the event instance stuff yet since the Simulation subsystem still needs work. However, I will discuss the use of default values and introduce a new OOA09 feature which links mathematically dependent attributes with mathematically dependent relationships allowing caching and observation of those relationships.

The original Shlaer-Mellor Method discouraged the use of default values. Most developers will check the usage of an operation before they change it. However, checking the usage of a default value before changing it can be much more difficult leading to unexpected errors after a default value change. Executable UML does support the concept and OOA09 also allows default values on some data types and some attributes (as initial values and literal values).

After some though, I have replaced initial values on simple attributes and literal values on referential attributes with default values and initial values on all attributes. All attributes can now define a default value (which must not be UNDEFINED) assuming the attribute has a data type which allows a default value, e.g. default values are meaningless for external types since all external values must be created in another domain. In addition, all attributes now define an initial value which is used during object instance creation. The initial value matches the default value if defined, otherwise it will match the attribute type's default value if one is defined and the attribute is not conditional. Otherwise, the initial value will be UNDEFINED.

It is worth discussing OOA09 error handling behaviour here. Mathematically dependent attributes always retain their previous value when an attribute calculation fails. This will match the initial value defined above if the attribute calculation fails when first invoked. OOA09 also allows an attribute calculation to access the current values associated with the mathematically dependent attributes being calculated allowing iterative algorithms to be used. Referential attributes and polymorphic attributes both default to the initial value defined above if referential or polymorphic resolution fails. However, resolution errors can only occur when a model is incomplete or invalid.

OOA09 now also allows a default value to be associated with a data item (event data item, parameter or variable). This allows new event data items or parameters to be added to events and operations without requiring all usage of those events and operations to be changed.

Now onto mathematically dependent referential attributes. OOA09 introduced the concept of a mathematically dependent relationship which is resolved on demand when navigation is required across the relationship. However, the execution of the navigation logic is always on demand. There are situations where the navigation logic must be calculated in a more controlled fashion for performance reasons. For example, determining the data type associated with an attribute requires a complex resolution algorithm to be applied to all attributes on all objects within a domain. Even though the attribute to data type relationship is mathematically dependent, it can't be determined on demand in the real world. I initially got round this by defining ordinary mathematically dependent attributes (i.e. the Data Type and Data Type Predefined attributes) which can be used to determine the navigation quickly on demand. Those mathematically dependent attributes can be determined using an all attributes all objects algorithm which isn't recalculated more than once per second.

In a ideal world, we only need a single attribute here whose data type is an object instance type and whose value can be used to immediately navigate the relationship. This is exactly what a mathematically dependent referential attribute is. It is a mathematically dependent attribute with an object instance type which formalizes a mathematically dependent relationship without the need to define any relationship navigation operations. Obviously, mathematically dependent referential attributes can't be used to formalize many-to-many mathematically dependent relationships. Use of an object instance type here is perfectly acceptable since the implied relationship is explicitly defined. An (M-Rn) suffix is used to indicate mathematically dependent referential attributes.