Week 3 of 2009

First week is now over and I'm not sure where it all went! I've been answering lots of email, tweaking stuff on my website, getting a tooth filled, adding an RSS feed to the Portal website so that users can be informed whenever new releases are made.

I also read Leon Starr's recent article Time and Synchronization in Executable UML. It discusses the fact that time is relative to each state machine, actions aren't interruptible, events aren't lost while actions are being processed, events are processed one at a time and that events aren't generally ordered. The two exceptions being that events sent from a specific state machine to itself are always processed before other events and that events sent between two specific state machines are always ordered. What the article doesn't discuss is synchronization of access to attribute values or relationship instances. Since any state machine can access any attribute values and navigate any relationships, this is a significant synchronization issue which is left to the software architecture to sort out.

OOA09 will have to address this issue to ensure domains are reusable across different software architectures. This will be done by introducing units of locking and a locking strategy. Units of locking will be either accessor processes or complete actions if there is no process model (accessor actions or complete procedures in Executable UML). Basic locking strategy will be either none, pessimistic or optimistic. Pessimistic will lock any object instances or relationship instance sets before allowing a process or action to be started. Optimistic will lock object instances and relationship instance sets just before they are accessed. Pessimistic locking reduces deadlock possibilities but keeps more stuff locked for longer. The amount of locking required in a system depends on the number of threads being used. If there is only one thread, no locking is required at all. If each state machine has its own thread then every unit of locking needs to perform locking. Obviously, a domain needs to define potential threads so that synchronization can be tested. Anyone who reuses that domain can decide to use a subset of those threads and still be confident in the original testing but if they introduce additional threading then additional testing of the domain will be required. The whole concept of locks and threads (not just the design and implementation of locks and threads) is left to individual software architectures prior to OOA09. However, this leads to significantly reduced reusability across different software architectures. More on this stuff in the future. OOA09 will tackle these issues in its Simulation subsystem.

What's up for this week? I need to finish off Build 013 and get it released. The tasks that are outstanding are:

• completion of arbitrary ID calculation logic along with an associated technical note,
• completion of object instance table editor and other population editing forms,
• completion of metamodel relationship population (metamodel object instance population is now finished),
• and the normal updating of web pages and release files.

The complicated task is finishing the arbitrary ID stuff while the big task is finishing the table editors and forms associated with population editing. Metamodel relationship population coding is just tedious and energy sapping, i.e. each relationship in the metamodel requires a chunk of Java code to populate. If I'm lucky, the next build will get released at the end of this week, if I find problems or issues or I run out of time then it may not get released until next week or even the week after. The firm deadline for this build is the end of January.