News

Cmd line interpreter

2012-04-13T19:20:29Z

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: [ []],... 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

2012-04-03T01:21:43Z

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

2012-03-20T16:45:44Z

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

2012-03-15T23:47:22Z

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

2012-03-12T01:32:33Z

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.

Collaboration Diagrams

2012-03-09T18:34:53Z

If, for some morbid reason, you find yourself poking through my API code, you may find these collaboration diagrams helpful. I have added them to the document register as td15. Link to them from there, or here in this post.

PDF (click thumbnail) or Omnigraffle.

Weekend Updates

2012-03-04T18:48:43Z

The following files have been updated: Polymorphism Subsystem Class Diagram/Descriptions, Relationship Subsystem Class Diagram/Descriptions, Class and Attribute Subsystem Descriptions only. Changes: Poly - see previous news post, Relationship Subsys - Thanks to Dave Moten's eagle eyes for spotting R25 which should have been R23, Class / Relationship Descriptions, 'Specialized Class' description moved from Class to Relationship Subsystems (descriptions were out of sync with diagrams). As always, just use the existing links, they now point to updated files.

Delegation Constraint Added

2012-03-04T03:55:24Z

In the process of coding up the API, I've discovered a missing constraint in the Polymorphism Subsystem. Due to rule #4 in Mellor-Balcer regarding polymorphism, it is critical that delegation of a polymorphic event proceed down exactly one Generalization. This is important when we have a compound generalization where multiple hierarchies sprout from the same Class. I will be posting an updated model by the close of the weekend with this constraint added.

State Signature

2012-02-29T01:04:33Z

In the process of coding up the API, I realized that R564 on the Poly Subsystem should be going to Destination and not State. Therefore, a Deletion Pseudo State also has a signature since, like a State, it may specify a Procedure (not yet modeled) and that Procedure will accept parameters. I will post an updated model later in the week. Back to coding...

Poly Test Pattern

2012-02-25T02:37:54Z

Here is a test pattern I am testing against this weekend on the poly subsystem API / Editor.