Week 15 of 2009

I have spent most of this week reworking and finishing various bits of OOA Tool code associated with Attributes and Data Types. This rework was and still is a diversion from finishing the Action Language overview. Once I have finished this stuff, I will finish off the overview and then try to wrap up a new build. When I talk about finishing the overview here, I also include finishing the Action Language syntax along with a parser to test the syntax. Unfortunately, the next build won't be ready before the end of April.

I mentioned mathematically dependent referential attributes last week and I have now started to use them in the Information Model and Data Dictionary subsystems, e.g. Attribute.Data Type, Attribute.Initial Value and Data Item.Data Type. I also discussed in Week 10 of 2009, letting analysts use object instance types with simple and mathematically dependent attributes as long as they enable a project level option to do so. However, I no longer think there are any good reasons for allowing analysts to use object instance types with attributes now that mathematically dependent referential attributes are supported. If anyone can think of a good scenario where an object instance typed attribute is needed then let me know. I should point out that there are a number of different ways that object instance values may already be stored within model population attribute values:

• as a mathematically dependent referential attribute value,
• as an external typed attribute value which encapsulates an object instance value passed from another domain,
• and as an event instance typed attribute value which encapsulates an object instance self reference and/or one or more object instance value arguments.

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.

Week 9 of 2009

I continued working on operations and parameters this week. Creating a clean parameter based interface for Action Language code has required a considerable amount of iteration between modelling and coding. I'm trying to find a balance that results in a clean but simple OOA, Java and XML representation for operations and parameters. If I was generating the Java and XML directly from the OOA using archetypes then this wouldn't be an issue. However, since I'm creating an egg without a chicken at present I have to factor in all three.

I found a nasty J2SE 1.5 bug in GridBagLayout which results in OOA Tool locking up when there are more than 512 rows (see Java Bug ID 5107980). I hit this MAXGRIDSIZE limit when I tried to open a Subsystem editor in the OOA Tool project. The Subsystem editor tries to list all objects and relationships showing which subsystem each is assigned to. The bug is fixed in Java SE 6 (since the limit is removed entirely) but there are no plans to fix the bug in J2SE 1.5. I added a quick workaround which traps the problem but doesn't fix it. Build 014 now shows a blank panel if the limit is exceeded rather than locking up OOA Tool. To fix the problem entirely, I would have to stop using GridBagLayout which I don't want to invest time in at present since the problem is fixed in Java SE 6.

My confidence in J2SE 1.5 took a knock after finding this problem. I've only stayed with this version since the Mac still doesn't fully support Java SE 6 even though J2SE 1.5 is now End of Life. I've now decided to move to Java SE 6 as my default platform while still retaining J2SE 1.5 support for the moment at least. The latest version of Java SE 6 is build 12 which includes the new Nimbus look and feel. It looks better than Metal so I will use this as the standard look and feel from now on (while still allowing users to select their preferred look and feel). There were a few minor display issues when I first switched to Nimbus in OOA Tool but these are fixed in Build 014.

Week 8 of 2009

I've been working on mathematically dependent attributes and the framework behind their associated value calculations. This involved revisiting the Process Model subsystem to sort out the layer between models and Action Language code. The top-level concept in the Action Language subsystem is the Statement Block which defines a sequential set of executable statements along with a scope for defining local variables. My initial thought was to define different types of top-level block for value calculation, relationship navigation, actions, synchronous services, etc. However, the distinction between event data items and parameters led to some hidden dependencies in Action Language expressions. Thus, I expanded my initial generalization of operation (which previously included synchronous service and process) to include all processing activities. This means that all statement blocks are now encapsulated in an operation with defined parameters including:

• self parameter (which normally contains an object reference),
• received event parameters (which reference event data items),
• simple input parameters,
• return parameter,
• and simple output parameters (allowing multiple return values).

Some operations have fixed input and output parameters while others have user defined input and output parameters.

Operations themselves include:

• attribute calculations (for calculating one or more mathematically dependent attributes),
• relationship navigations (for navigating across a mathematically dependent relationship),
• actions (performed on entry to a state),
• synchronous services (for defining the public interface to a domain),
• processes,
• functions (for defining reusable side-effect free calculations),
• and bridge mappings (for mapping wormholes to control reception points).

Functions are like transformations within process models except that they can be defined on any operation owner and used within any operation.

Processes include:

• simple processes (including accessors, transformations and tests),
• state model event generators,
• polymorphic event generators,
• request wormholes including:
  • domain-crossing event generators,
  • and bridging processes,
• synchronous return wormholes,
• and asynchronous return wormholes.

In OOA91, simple processes are accessors, transformations or tests. Other processes include event generators and wormholes (added in OOA96). The objective being to partition processing into fundamental processes. However, this categorization is not really exclusive. Tests are processes returning values (normally boolean) used in conditional control flows. However, many transformations also return test values as well as their transformation outputs. Accessors are further categorized as either create accessors, read accessors, write accessors or delete accessors. OOA09 takes the view that simple processes are atomic access units that may include multiple accessors, transformations and tests. The important thing here is to ensure that hard constraints are not broken after simple processes are executed, e.g. don't create a supertype object in one process and the associated subtype object in another process. Simple processes still can't generate events and event generators still can't perform accesses or return output values in OOA09. This change in focus with regards to process partitioning is a crucial difference between OOA91 and OOA09.

While bridge mappings include:

• request mappings,
• synchronous return mappings,
• asynchronous return mappings,
• create counterpart mappings,
• semantic shift mappings,
• and watchpoint mappings including:
  • object created mappings,
  • object deleted mappings,
  • object updated mappings,
  • event generated mappings,
  • and operation invoked mappings.

I won't get into bridge mappings this week since it is a big topic.

I should also mention operation owners which include:

• objects,
• mathematically dependent relationships,
• event destinations,
• and bridges.

Most operations will be owned by event destinations (state models, terminators and polymorphic destinations) in OOA09 rather than objects. This is because Shlaer-Mellor is lifecycle centric rather than object centric. Objects own value calculations (for mathematically dependent attributes). Mathematically dependent relationships own relationship navigations. State models own actions, simple processes and state model event generators. Terminators own synchronous services, request wormholes (domain-crossing event generators and bridging processes) and return wormholes. Polymorphic event destinations own polymorphic event generators. Bridges own bridge mappings (all varieties). In addition, all operation owners may own one or more functions.

The next build of OOA Tool should allow all of the operations defined above to be created. However, I'm not sure yet whether I will have graphical process models in the next build. There are other issues to be resolved involving data and control flows before graphical process modelling can be delivered.