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.

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.

Week 11 of 2009

I've been working on the Action Language for OOA09. I was planning to publish a technical note on Action Language design. However, that discussion will now be included on the main Action Language page when it is published (hopefully this week). I will also be putting the Action Language under change control and it will be a major feature of the next OOA Tool build. A number of interesting issues have surfaced during this work:

• Are collections needed in an Action Language?
• Should the creation (and deletion) of supertype object instances (and the associated subtype-supertype relationships) be completely automated?

The first issue will be covered in a separate technical note while the second issue is discussed below.

Most of the existing Shlaer-Mellor and Executable UML Action Languages (e.g. [OAL02] and [ASL03]) take the view that all object instances are created and deleted separately from each other and that subtype-supertype relationships are related and unrelated separately also. However, [xtUML02] proposed that supertype object instances and subtype-supertype relationships (called generalizations in Executable UML) should be created automatically whenever leaf object instances are created. Furthermore, when a leaf object instance is deleted, all supertype object instances and the associated subtype-supertype relationships should be automatically deleted. Where a leaf object instance is part of a multiple subtype-supertype hierarchy then a leaf object from each hierarchy must be specified in the Create object instance statement. This proposal significantly reduces the amount of creation and deletion code required in an application, especially if the application uses lots of subtype-supertype relationships.

Shlaer-Mellor and Executable UML also support the concept of subtype migration while most object-oriented programming languages do not. If users are no longer able to relate and unrelate subtype-supertype relationships then we need some way of performing subtype migration. xtUML02 proposed a new Action Language statement that could reclassify object instances:

RECLASSIFY OBJECT INSTANCE variable FROM objectName TO objectName

However, this proposal requires multiple statements to perform reclassification across multiple hierarchies which is potentially inefficient since each statement may require a complete rebuild of the object instance hierarchy if the deployment programming language is object-oriented. An alternative more generic and potentially more efficient statement is given below:

RECLASSIFY OBJECT INSTANCE variable AS objectName { ',' objectName }*

There is no need to specify a from clause here. There is also no need to specify a leaf object for each hierarchy unless you want it to be a specify subtype in each hierarchy after the statement is executed.

OOA09 will adopt this approach for object creation and deletion and will support the above reclassify statement. However, for backwards compatibility with OAL, a Manual Supertype Creation : Boolean = FALSE attribute will be added to projects to allow users to create object instances without automatically creating supertype object instances and the associated subtype-supertype relationships. However, using this option will not be recommended since it is verbose and error prone. It will of course need to be used in projects loaded from BridgePoint export files.

On a completely separate note, the programme for Code Generation 2009 has now been published. I went last year and wrote up some notes (see Code Generation 2008). However, I am somewhat disappointed with this year's programme. There doesn't seem to be anything for hardcore 'model is the code' analysts and developers. Chris Raistrick from Kennedy Carter is giving an unspecified talk on Executable UML. However, it will probably be an overview or basic tutorial like last year. I would have liked to have seen some Action Language (rather than DSL) talks. Some discussion on what the OMG is doing with action semantics and fUML would have been useful. Any progress on the new RFP for a standard UML Action Language would also have been very interesting. However, I will admit to not proposing any talks for this year's conference and there are lots of things I could have talked about. Public speaking isn't one of my core skills unfortunately (nerves tend to get the better of me). Maybe, I will propose some talks for next year. I am not yet decided on whether I will go this year.

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.