Week 8 of 2009

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).

Some operations have fixed input and output parameters while others have user defined input and output parameters.

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),
• processes,
• functions (for defining reusable side-effect free calculations),
• and bridge mappings (for mapping wormholes to control reception points).

Functions are like transformations within process models except that they can be defined on any operation owner and used within any operation.

Processes include:

• 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.

In OOA91, simple processes are accessors, transformations or tests. Other processes include event generators and wormholes (added in OOA96). The objective being to partition processing into fundamental processes. However, this categorization is not really exclusive. Tests are processes returning values (normally boolean) used in conditional control flows. However, many transformations also return test values as well as their transformation outputs. Accessors are further categorized as either create accessors, read accessors, write accessors or delete accessors. OOA09 takes the view that simple processes are atomic access units that may include multiple accessors, transformations and tests. The important thing here is to ensure that hard constraints are not broken after simple processes are executed, e.g. don't create a supertype object in one process and the associated subtype object in another process. Simple processes still can't generate events and event generators still can't perform accesses or return output values in OOA09. This change in focus with regards to process partitioning is a crucial difference between OOA91 and OOA09.

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 won't get into bridge mappings this week since it is a big topic.

I should also mention operation owners which include:

• objects,
• mathematically dependent relationships,
• event destinations,
• and bridges.

Most operations will be owned by event destinations (state models, terminators and polymorphic destinations) in OOA09 rather than objects. This is because Shlaer-Mellor is lifecycle centric rather than object centric. Objects own value calculations (for mathematically dependent attributes). Mathematically dependent relationships own relationship navigations. State models own actions, simple processes and state model event generators. Terminators own synchronous services, request wormholes (domain-crossing event generators and bridging processes) and return wormholes. Polymorphic event destinations own polymorphic event generators. Bridges own bridge mappings (all varieties). In addition, all operation owners may own one or more functions.

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.