Week 10 of 2009

I'm still working on operations and parameters but I had to take a detour into the Data Dictionary subsystem this week. First to implement Object Instance Types and then to redesign what it means to be a preferred type. I also revisited Action Language design since I've had a number of requests for more information on this. I hope to publish a technical note next week explaining my design choices for the OOA09 Action Language. I'm not sure yet how much executable support for the Action Language will be in the next build. However, the OOA Tool simulator is high on my priority list.

Now back to data types. Object instance references (sometimes called handles) are required at the event and operational level, e.g. Lifecycle Model actions define a Self Parameter which references the event destination object instance. There aren't any special attributes for object instance types so they are always predefined. I have adopted the naming convention Object Instance<Example Object> for object instance types. It is important to note that data types are independent of multiplicity and conditionality in OOA09 since they define a single unit of data. Most programming languages define multiplicity as a special type of data type, e.g. int[]. However, OOA09 associates multiplicity with data items (event data items, parameters and variables). This eliminates the need for multiple forms of object instance types (or other data types).

I originally introduced the notion of a predefined type so that Executable UML Core Types could be defined in a standard way while also allowing any OOA09 compatible tool to add their own predefined types, i.e. actual predefined types are defined at the tooling level rather than by the formalism. However, I ran in to a problem when I started looking at the typing of parameters and variables across all the operations required in OOA09. Action Language code requires permanent implicit access to a subset of core types (i.e. Boolean, Integer, Real and String) so that transient expressions can be evaluated. It also requires permanent implicit access to all object instance types so that results from a Select statement can be properly typed. To enable implicit access, all predefined types are now permanently defined in all domains. Furthermore, actual predefined types are now defined by the formalism, i.e. OOA09 compatible tools can't define their own predefined types anymore. OOA Tool now parses but ignores all predefined types when a project is loaded and no longer outputs predefined types when a project is saved. However, this change introduced several additional problems.

The first problem was that users could no longer define their own core types. This problem was solved by allowing users to create user defined types which override predefined types while still allowing users to access the original predefined types. To specify a predefined type, a user simply needs to add a <> suffix. However, this suffix doesn't need to be used for predefined types unless the user has overridden those predefined types. Within the OOA of OOA, all data type identifiers now include a predefined status to ensure predefined types are distinct from user defined types.

Another minor problem was that the OOA Tool tree browser becomes cluttered with predefined types. I solved this by no longer showing predefined types in the tree browser. However, I will need to provide some way of accessing predefined types in the future since data type forms show all references to those data types and that information is useful even for predefined types.

An interesting issue with regards to object instance types is whether to allow them to be used as attribute types. The obvious answer is no since you are effectively defining a hidden relationship by doing so. However, there is no technical reason for saying no. I think I will provide a project (and user property) level option for allowing object instance attribute types which will default to disallowing them. This logic can be incorporated into the existing Data Type Acceptable status associated with attributes.