Thursday, 1 May 2008

AIR UML Tool : Defining the UML scope

UML 2.0 is pretty vast.

This is an attempt to summarise the parts of the UML that need to be available within the tool. My current thinking is that different languages will have an xml spec file that maps these UML Language elements to the translated element for that language.  We should begin with AS3 as a primary goal, but ensure we support parts of the UML which aren't yet available to actionscript but might be included in PHP6 or AS4.

For example - AS3 doesn't support 'private' or 'protected' on a constructor, so the AS3 xml config might map it to 'public' in this case.  AS3 also doesn't support 'abstract', so that would be skipped when constructing the stub AS3 code.  

The list below is probably incomplete but it's a really good place to begin.  Strict UML terms are given in (brackets).

  • package
  • class
  • interface
  • property
  • function (operation)

  • public
  • protected
  • private
  • internal (package)

Scope / implementation modifiers
  • static
  • abstract (unsupported in AS3 but we can hope and at least add to comments)
  • const (readOnly)
  • binds
  • dynamic (not sure this has a strict UML equivalent?)
  • overrides [thanks dauntless]
  • final [thanks dauntless]

Class relationships
  • extends  (generalizes)
  • implements (realizes)

Any glaring errors?  If you're out there following this and it makes sense to you please do speak up, encouragement, questions, interrogation and the pointing out of obvious fundamental flaws are all appreciated.

[edit]: Dauntless has also mentioned composition, which is definitely required within the laying out of diagrams / relationships, but doesn't really map to an AS3 file other than by declaring a property of that type - or am I missing something?  

We'll also need to represent the Aggregation / one-to-many : many-to-many : many-to-one type relationships as well, and also event listener lollipop etc, but again I don't think they map into the final exported AS3 files.

Dauntless also brought up the issue of types - something I've been thinking a lot about and hope to post some ideas for a strategy later today.


Dauntless said...

Looks good! (Both this post & your graphic of the CRC cards)

The only thing I'm missing here is composition, but maybe that's not one of the strict UML parts that you're aiming for?

Also keep in mind that all those types should be pretty expandable as well. Fe: Java has an enum type, that would require a new type of item in the application.

If you're starting up an OS project at osflash, I will be glad to sign up.

Ps: I'm 'Jeroen' from the previous comments

Dauntless said...

Oh yeah, you also forgot 'final' & 'override'. (And maybe 'namespace')

Stray said...

Thanks dauntless - good to have multiple brains on this to pick up the little holes as early as possible :)