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).
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),
- functions (for defining reusable side-effect free calculations),
- and bridge mappings (for mapping wormholes to control reception points).
- 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.
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 should also mention operation owners which include:
- mathematically dependent relationships,
- event destinations,
- and bridges.
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.