Cmd line interpreter

To ease testing, and make the overall interface easier to play with, I am building an interactive command interpreter in Python 3.2.  The user will be able to type in a simple command (or load a file) using a vocabulary like: <metamodel class> [<op> [<prop>]],... <scope> with some helpful scoping commands so that you don't have to keep re-entering the same domain name.  An example session might look like this:

* scope domain 'Banking'

* id add attr 'Branch name' class

(the second of which will invoke the UI_add_attr_to_id(...) db function)

And, of course, a simple help system.

Should have it working by the end of the weekend if all goes well.

2.0 API Code Posted

The 1.0 API supported class model editing only.  The 2.0 update, now avaiable from the 'All The Code' link to the right, includes support for state model editing.  Basically, the code just doubled in size.

I have just written an extensive README file at the top of the file tree to help you get everything installed and working on your platform.

There is still an issue we are resolving with respect to the way polymorphic events should be handled.  And a couple of other issues just surfaced which may lead to some interesting changes in the next month or two.  I will keep you posted.

Also, I am starting work on a Python3 wrapper to provide a non-SQL interface to the metamodel.  This will also give me a more robust testing environment.

Latest Progress

Work on the State/Poly API/Editor was slowed a bit this month with many distractions.  And the delegation issue (see previous posts) didn't help things either!  That said, it's still progressing nicely.  I've got all of the key edit functions working yesterday and now need to backfill the queries (see the State API spreadsheet) and do a little more testing all around.  It looks like I'll be posting all the code by the end of the month, if all goes well.

Updated Poly Subsystem

To accommodate polymorphic delegation along compound generalizations (supporting case 2 as described in the previous post), the Polymorphism Subsystem has been updated.  Note the inclusion of the Delegation Direction class.  Also R551 was removed since it's now a many-many association between a Poly Event Spec's Class and any Generalizations stemming from it.  This multiplicity is handled by R569 now.

The State API has been updated accordingly, note differences in the UI_delegate_event, UI_delete_event and UI_new_polymorphic_event calls.

Testing Polymorphism

A conversation with Andrew Mangogna revealed that he and I had two different, and conflicting interpretations of how polymorphic events are supposed to be delegated on a compound generalization (multiple specializations from the same class as illustrated).  Unfortunately, the Mellor-Balcer Executable UML book, specifically rule 6, p228 is ambiguous:

6. If a superclass has multiple specializations, the polymorphic signal occurrence is received by at most one state machine instance in each specialization hierarchy.

The question being:  Must an Event Specification declared as polymorphic on a Class be delegated down (1) ALL Generalizations rooted in that Class or (2) AT LEAST ONE.  Both cases satisfy rule 6.  In either case, a run-time event is guaranteed to be processed by at least one Subclass instance.  In a given Generalization, again, in either case, each Subclass must define an Event Response for the delegated Event Specification unless there deeper delegation is specified (thorugh another level of Generalization).

Until we get this resolved (meeting with Stephen Mellor here in SF in a couple of weeks), the API will assume case (2) as it is the least restrictive and can be readily extended to case (1) if necessary.