Week 24/25 of 2009

Progress has been slow over the last few weeks since I have been away in Nottingham empting a 20ft storage container holding all sorts of junk! I'm now trying to focus exclusively on coding operation support in OOA Tool. If I were working in a team as I have done in the past then we would sit around planning and reviewing a detailed design before we started coding each set of features. However, when you are working alone then the only approach that works in my experience is continuous prototyping and refactoring. Unfortunately, it can result in wasted effort when bad design decisions are discovered. I had planned on releasing Build 014 ages ago but implementing operation support has raised lots of issues which have lead to rework several times. In the previous weeks I have nailed down Recursive Design bridging operations. During the last week I have sorted out operation ownership which I discuss below. However, there is still more coding to do before operation support is finished.

In OOA09, operation ownership is split between real ownership and name ownership. Real ownership is the natural consequence of which OOA of OOA element is responsible for defining what operations, e.g. a Bridge defines and thus owns bridge operations. Name ownership is a partial relationship (i.e. not all operations are named) connected with Action Language syntax (i.e. how names are used to identify specific operations within code). All operations now have a mathematically dependent Name Owner Category attribute whose value is either:

• None indicating an operation has no name,
• Owner indicating the real owner is also the name owner,
• Active Object indicating the active object associated with the lifecycle model which is the real owner defines the naming context,
• Partitioning Object indicating the partitioning object associated with the multiple assigner model which is the real owner defines the naming context,
• or Supertype Object indicating the supertype object of the subtype-supertype relationship associated with the polymorphic destination which is the real owner defines the naming context.

This attribute is used to navigate a mathematically dependent relationship to the name owner of a given operation. This classification took some time to resolve and there are issues with allowing non-Object owners to be name owners, e.g. Executable UML associates all operations with Classes while single assigner models in OOA09 can define state model processes whose names must be qualified using the assigner label prefix of their owner.

The table below lists all operation types along with their real owners and name owners:

Operation	Owner	Name Owner Category
Domain Observer	Domain	None
Bridge Mapping	Bridge	None
Function	Information Model	Owner
Attribute Calculation	Object	None
Relationship Navigation	Mathematically Dependent Relationship	None
Action	State Model	None
Synchronous Service	Terminator	Owner
State Model Process	Lifecycle Model	Active Object
State Model Process	Single Assigner Model	Owner
State Model Process	Multiple Assigner Model	Partitioning Object
Polymorphic Process	Polymorphic Destination	Supertype Object
Bridging Process	Terminator	Owner
Synchronous Return Wormhole	Terminator	None
Asynchronous Return Wormhole	Terminator	Owner

From the table, it is clear that many operations have no name since they can't be explicitly invoked and thus require no name. Synchronous return wormholes require no name since they are always invoked on a specific return coordinate. Asynchronous return wormholes are given a name even though they are always invoked on a specific transfer vector but only so that transfer vector types can be meaningfully labelled.