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:
Noneindicating an operation has no name,
Ownerindicating the real owner is also the name owner,
Active Objectindicating the active object associated with the lifecycle model which is the real owner defines the naming context,
Partitioning Objectindicating the partitioning object associated with the multiple assigner model which is the real owner defines the naming context,
Supertype Objectindicating the supertype object of the subtype-supertype relationship associated with the polymorphic destination which is the real owner defines the naming context.
The table below lists all operation types along with their real owners and name owners:
|Operation||Owner||Name Owner Category|
|Relationship Navigation||Mathematically Dependent Relationship||None|
|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|
|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.