Week 12/13 of 2009

I've been off duty (I wouldn't exactly call it a holiday) for most of week 12 and week 13. However, I did spend a few days back on data types sorting out the issue of predefined type visibility.

In the Week 10 of 2009 weekly report I mentioned splitting data types into user defined types and predefined types. All predefined types now exist in all domains but aren't always visible. When to make them visible was an outstanding issue. I could have required the analyst to explicitly import predefined types. The problem here is that this would not work well for implicitly declared predefined types in Action Language code. Either the analyst would forget to import a predefined type or import predefined types that aren't being used. Instead, I introduced a Reference Count attribute on all data types. This reference count includes manual data type references from attributes and data type references from data items (event data items, parameters and variables). All data type references on attributes are derived from manual data type references so we don't have to count them as well. All predefined types with positive reference counts are now automatically visible while those with zero reference counts are hidden.

The main complication here is that bridge mappings associated with bridges may include data type references (in parameters or variables). Do we include such references in reference counts associated with domain specific data types. It feels like domain pollution. However, I don't see any way of eliminating the need for data type references within a bridge mapping operation and if we don't include such references then the analyst will not be able to identify those references via a data type form. I'm not sure whether this is a real issue for the analyst. However, I am also going to use this reference count to determine which predefined types to include in metamodel populations. There is no benefit adding all predefined types to a metamodel population, only those which are actually referenced need to be included.

Another issue is the shear volume of predefined types that may exist in a model. An object instance type exists for every object, an event instance type exists for every event, a current subtype type exists for every subtype-supertype relationship and a current state type exists for every state model. The last two types are new and will be discussed in greater detail at a later date. Obviously, not all of these will be referenced within a project and thus won't be visible. However, enough will be visible to swamp the tree browser in OOA Tool. To counter this, data types are now distributed across the tree browser:

• object specific arbitrary ID types and object instance types are now shown below their associated objects,
• event instance types are shown below their associated events,
• return coordinate types and transfer vector types are shown below their associated return wormholes,
• and the remaining data types are shown below their associated information model as normal.