[gmt-dev] Transform cardinalities

["Willink, Ed" <Ed.Willink@xxxxxxxxxxxxxxx>]

Hi All

My UmlxGrphicalLanguage paper describes relationship cardinalities.

The original ISIS work described cardinalities for nested sets as well.

I was aware that these should somehow be interpreted as transform
cardinalities.

So far my examples have used the policy that a nested transformation
is available to perform as many matches as it can. It has only been
possible to detect what it did by testing its outputs.

This makes it difficult to use a nested transformation as a predicate,
and so difficult to formulate partial matches for re-use.

There appears to be a very consistent way of using cardinalities on
transform
instance invocation bindings.

A transform input cardinality specifies how many inputs are used by each
successful nested transfdorm invocation. So far I have implicitly used unit
input cardinality.

A transform output cardinality specifies how many outputs are produced by
all
the nested transform invocations. I have so far used an implicit 0..*.

A unit transform output cardinaility therefore mandates that the transform
matches exactly once.

A zero transform output cardinality mandates that the transform fails to
match.
This may be used to construct an if-then-else tree of prioritised
transforms, in
conjunction with an unlabelled transform to transform connection. An
unlabelled
transform connection may be viewed as syntactic sugar for output of a void
object
from the source transformation and input to the sink, thereby establishing
execution
precedence.

	Regards
			
		Ed Willink

------------------------------------------------------------------------
E.D.Willink,                             Email: mailto:EdWillink@xxxxxxx
Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
Worton Drive,                            or  +44 118 986 8601 (ext 8278)
Worton Grange Business Park,             Fax:  +44 118 923 8399
Reading,   RG2 0SB
ENGLAND          http://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------
(formerly Racal Research and Thomson-CSF)

As the originator, I grant the addressee permission to divulge
this email and any files transmitted with it to relevant third parties.