News

Text Language - Coming along

Leon Starr — Tue, 09 Oct 2012 06:22:20 +0000

Well, it's taken a bit longer than expected with a number of distractions, but I'm making progress. Hope to have the model population language parser up and running by the end of the month.

Text language

Leon Starr — Sat, 08 Sep 2012 15:45:01 +0000

I'm finally getting around to specifying the lean and mean text representation of miUML that I've always wanted. It is possible to just write a command script to be processed by the interactive command line editor, but that's really only intended for making edits. It's rather clunky when it comes to building whole models. Now that I've settled on the Air Traffic Control (ATC) example as a test pattern, I can use that as an initial case to get things going. If there aren't too many distractions this weekend, I hope to have something up and running on GitHub.

Next batch coming soon

Leon Starr — Thu, 30 Aug 2012 05:09:50 +0000

I'm creating a test pattern using the Air Traffic Control example on the Model Integration site. That way, when you load everything you'll be able to run a script that will build a complete, albeit small, domain. Also I'm adding functionality in the command line editor to cover more of the API. Look for an update in the next couple of weeks.

Big News!

Leon Starr — Wed, 08 Aug 2012 01:14:09 +0000

It's been quiet here for a while as I have been up to my elbows in new code and documentation. So quiet is a good thing. Here's the news:

All models and code are now up on GitHub
This means that all .zip file downloads here are officially deprecated
I have coded up a Command Line Editor in Python that uses the metamodel API
I am now using code generation to output some API stored procedures
Each repository has one or more wiki pages, these will be filled out as I go along
Each repository has a bug/issue tracking feature

In the coming days I will be doing some housekeeping here at miuml.org to replace the old links and downloads with references to the corresponding GitHub repositories.

A few qualifications:

The command line editor has some nice features, but only a few API calls have been integrated. So it's not ready for serious use yet, but you might want to play with it a bit to see how the API is integrated into an application.
Code generation is currently limited to attribute setter functions, but it will be expanded to generate more and more of the PostgreSQL stored procedures. As miUML is intended for code generation, it makes sense that it should be able to generate it's own supporting code. (Otherwise, what the hell good is it, right?)
Finally, the wiki pages are in good shape for the command line editor, but a bit sparse for the rest. More to come!

API Code Gen, Teaching Break

Leon Starr — Sat, 09 Jun 2012 00:23:57 +0000

I took a little break to teach a class in Stockholm, Sweden and am now getting back to work on miUML. As an adjunct to the command line interpreter work, I decided to code generate some of the miUML API's to 1) ease maintenance, 2) make them more consistent (focusing on attribute setter functionality for now) and 3) to start using miUML technology to build miUML itself. No goodies to post yet, but there should be some significant updates in the next couple of weeks. Then I can get back to extending the metamodel itself.

Cmd line interpreter

Leon Starr — Fri, 13 Apr 2012 19:20:29 +0000

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

Leon Starr — Tue, 03 Apr 2012 01:21:43 +0000

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

Leon Starr — Tue, 20 Mar 2012 16:45:44 +0000

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

Leon Starr — Thu, 15 Mar 2012 23:47:22 +0000

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

Leon Starr — Mon, 12 Mar 2012 01:32:33 +0000

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.