Week 18 of 2009

I had hoped to get back to finishing the Action Language overview which I put on hold to mull over some choices I have to make. I sometimes find that putting off an arbitrary choice for a while can lead to a better choice later. I have found that making the wrong design choice can lead to lots of rework later. Here I am looking forward to providing Action Language code for all the mathematically dependent attributes in the metamodel. However, I want to be sure the Action Language addresses my requirements.

Instead, I implemented EnumeratedSubtypeType allowing users to determine the current subtype of a subtype-supertype relationship. This will allow users to switch (using the new switch statement) on a subtype without needing to perform multiple subtype-supertype relationship navigations. I also implemented EnumeratedStateType allowing users to determine the current state of a state model. OOA91 gave users access to the current state of a state model while OOA96 dropped this feature. OOA09 gives users access to current state since it is very useful for bridging and debug code. OOA09 recommends that both current subtype and current state should primarily be used with the new switch statement since all cases must be supplied and an error will be reported if a new case is required or an old case is redundant. Both types are always predefined and can be used as attribute types. They only appear as browsable types below subtype-supertype relationship and state model respectively when they are referenced by one or more attributes or data items.

I also rewrote the entity (object and terminator) key letters calculation logic so that key letters are always unique. Prior to Build 014 (the next build), non-unique key letters would simply be shown in red. The new logic which is discussed in detail in the previous blog now always generates unique key letters.

On an Action Language related issue, I managed to download the latest copy of Mentor Graphics BridgePoint UML Suite Object Action Language (OAL) manual. The main changes from OAL02 involve support for components, interfaces, ports and inter-component communications. Some form of array access which is not discussed in the body of the document also appears in the syntax grammar. However, I was surprised not to see a new variable declaration statement since I had previously spotted a BridgePoint pre-release note that suggested a variable declaration statement was going to be added. I won't be providing any support for components or interfaces in OOA Tool since it adds nothing (in my opinion) to OOA or xtUML. I will however be defining a variable declaration statement which is sorely missing from OAL.

Finally, I just want to mention that a new Executable UML group has been created by Lee Riemenschneider on LinkedIn. I added a few postings and I hope the group will provide a useful forum for Executable UML (and Shlaer-Mellor) specific discussions.

Custom and Automatic Key Lettering

Shlaer-Mellor OOA uses key letters to identify various model elements. Objects and terminators (collectively known as entities) define key letters (normally an abbreviation of their names) as a unique short identifier. Key letters can be used to identify entities within Action Language code. However, OOA09 also allows entity names to be used within Action Language code instead. For this reason, key letters are not allowed to match another entity's name.

Key letters (often referred to as key letter singular in old Shlaer-Mellor literature) where introduced in OOA91 at a time when there was minimal CASE tool support. UML has no similar notion since it was defined with CASE tools in mind. That said, key letters still have a useful role to play with regards to event and operation labelling. Within OOA Tool, users can leave the creation and updating of key letters entirely in the hands of OOA Tool.

Key letters are also used to compose event and operation labels via the Label Prefix attribute on Operation Owner. While entity key letters are no longer strictly necessary in their own right, they are essential for use within event and operation labels since event and operation meanings are not by themselves unique. The format of event and operation labels will not be discussed here. However, they do rely on the fact that key letters are always unique.

OOA09 defines key lettering on the Entity object. It defines a Name attribute, an optional Custom Letters attribute, a mathematically dependent First Letters attribute and a mathematically dependent Key Letters attribute. The custom letters attribute allows users to specify their own key letters for an entity. However, the custom letters must be unique otherwise they will be ignored. The first letters attribute is derived from the name attribute and is composed from the first letter of each word in the name (see Naming). This is the recommended convention for key letters. However, first letters may not always be unique which is why custom letters may be needed for some entities.

OOA91 also defined the notion of subsystem prefix letters allowing an optional common key letters prefix to be defined for all objects within a subsystem. Prefix letters can't be defined for terminators since terminators are never assigned to a subsystem. OOA09 requires any prefix letters to be automatically added to assigned object key letters. The prefix letters must not be included in custom letters (otherwise it will be duplicated) and is not added to first letters. It is always added to key letters, i.e. it can't be selectively dropped from a single object's key letters. Prefix letters are not defined as a unique identifier on subsystem so two or more subsystems may use the same prefix letters. Prefix letters normally end with an underscore but that isn't a requirement.

All entity key letters must be unique within a domain. If custom letters (with any prefix letters added) is defined which doesn't match another entity's name or custom letters then it is used. Otherwise, first letters (with any prefix letters added) is used instead. If the first letters match another entity's name, custom letters or first letters then a suffix is added to make the final key letters unique. The suffix used is "_z", "_zz", "_zzz" etc. The convention is a little arbitrary but it does ensure key letters are always unique. Users should (but are not required to) define custom letters when first letters are not unique which will be obvious when the sleep suffix appears.

Week 16/17 of 2009

Back to work after Easter. I hadn't planned on having a long Easter break. However, I started reading the novel Guilty Pleasures, the first in the Anita Blake: Vampire Hunter series by Laurell K. Hamilton. I then went on to read the next 15 novels in the series back to back!! I'm not exactly happy with the direction the series is now heading in, i.e. more and more sex while less and less plot. However, you can't help getting attached to most of the characters in the series. Anyway, all of that reading made a good diversion from OOA modelling and Java coding.

Prior to the Easter diversion, I continued reworking and finishing various bits of OOA Tool code associated with Attributes and Data Types. I rewrote a number of algorithms including those for Mapping Complete, Mapping Compatible and Data Type Acceptable. I added a Manual Constrained attribute to Referential Attribute Mapping and rewrote the Loop Constrained and Constrained algorithms. Most of these algorithms will be published as Action Language code within the OOA of OOA once I have finished the simulator allowing the Action Language code versions of the algorithms to be tested.

While coding OOA Tool, I spend a significant amount of time coding model element listeners since most model elements within the OOA of OOA have derived attributes which depend on many other model elements. OOA Tool automatically refreshes itself when any model elements change rather than relying on manual refreshes. This listener logic which can be very complex, needs to be completely automated in the Java software architecture, i.e. the model compiler. This will require automatic analysis of the dependencies within attribute calculation code. I am currently hopeful that this can be done efficiently without the need for design colouring. I eventually hope to replace the OOA of OOA model element Java classes in OOA Tool with classes generated directly from the OOA of OOA metamodel.

I also spent some time searching the web for any other projects, forums or blogs relevant to Shlaer-Mellor and/or Executable UML. I didn't find any ongoing projects in the public domain. The only active forum seems to be The Model Driven Software Network. I'm not a member of the OMG and so can't report on any activity there, other than to say, not much is happening in the public areas. I haven't found any other bloggers with an active interest in Shlaer-Mellor and/or Executable UML. It is all very disappointing.

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.