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.

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.