[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[gmt-dev] RE: Relation and Type Cardinalities
|
Hi Adi
I think this ties up with nested transformation cardinalities.
[Please ignore the drivel about transformation input and output
cardinalities in my gmt-dev email on 10-Jun.] The only interesting
cases seem to be:
1) the cardinality of the nested transformation matches with
respect to one match of the invoking transformation. This is denoted
in UMLX by a multiplicity constraint in [] at the top right of a
transformation.
2) the cardinality of the nested transformation matches as a
guard/gluing condition for a succeeding nested transformation. This
is denoted in UMLX by a multiplicity constraint at the source of a
transformation to transformation relation.
See the 0-cardinality chain leading to CompileTimeError in
Main.MainRecursion in the Workflow example posted to gmt-dev today
for a concrete and relevant example.
A nested transformation corresponds to a nested set in your paper,
and so a successful transformation has a cardinaility of 1 or more.
An unsuccessful transformation has a cardinality of 0. So 'on failure'
is a 'successful' match with 0 cardinality.
0/non-0 cardinality transformations with inputs but no outputs also
have a nice ability to modularise a complicated match and express
an arbitrary 'and','or','not' match. A one level match can only do
'and'. With the aid of 0 cardinaility this extends to 'not', with
transformations acting as predicates we can do anything, since 'or' can be
expressed using concurrent nested transformations or by using negative
logic and further 'and's.
Exceptions: well that's a more complicated issue. See earlier gmt-dev
traffic.
There is at least a need to distinguish between
static anomalies e.g. type violations resolvable at compile-time,
dynamic anomalies e.g. type violations not resolvable at compile-time,
static user-defined anomalies e.g. constraints resolvable at compile-time
dynamic user-defined diagnosis e.g. constraints not resolvable at
compile-time
fatal exceptions which terminate a transformation and exit as-is
fatal exceptions which abort a transformation and unwind
non-fatal exceptions particularly error diagnostics that contribute to a
growing
exception result.
The as-is option is useful for diagnosis but totally incompatible
with any concept of consistent results independent of exzecution order.
Unfortunately exceptions have a very nasty interaction with zero
cardinalities,
which allow the most awful side effects from interactive transforms to be
handled
'cleanly'. How do you unwind a completed user interaction without leaving
the
user very confused, or worse still annoyed at repeated attempts to fill in
pop-up forms whose usage then gets aborted?
[An interactive transform is one that interacts with a stateful external
actor,
typically a human via a GUI.]
Regards
Ed Willink
As the originator, I grant the addressee permission to divulge
this email and any files transmitted with it to relevant third parties.
> -----Original Message-----
> From: Adi - Vandy [mailto:aditya.agrawal@xxxxxxxxxxxxxx]
> Sent: Wednesday, July 23, 2003 4:30 PM
> To: 'Willink, Ed'
> Subject: RE: Relation and Type Cardinalities
--snip
> The concern you raised has also been raised within our group.
> However, the
> proposed solution is different. We were looking at introducing a "on
> failure" concept in our language. The matcher should return a failure
> message, say an exception. The "On failure" will catch the
> exception and can
> either give a warning, exception or exit the transformation
> completely. I
> believe this can be used for a finer understanding of failures.
>
> To have an if-then-else construct for type checking, you can use the
> test/case. We actually use the test/case for type checking
> extensively. To
> test the type of an object we create cases that do not perform any
> additional match but just check the type of the object.
--snip
>
> -----Original Message-----
> From: Willink, Ed [mailto:Ed.Willink@xxxxxxxxxxxxxxx]
> Sent: Tuesday, June 10, 2003 7:47 AM
> To: Gmt-Dev (E-mail)
> Cc: Aditya. Agrawal (E-mail)
> Subject: Relation and Type Cardinalities
>
>
> Hi All
>
> Adi: I don't know whether you subscribe to [gmt-dev].
>
> I've been getting concerned about the silent do-nothingness
> of matches.
>
> Extension of the GReAT concepts to full UML, with arc
> cardinalities and
> inheritance matching, means that each relationship has two separate
> opportunities to not match.
>
> A match may fail because the relationship connectivity of
> cardinality fails,
> or because the target object is of an inappropriate type.
>
> It must be possible to write transformations that positive;ly
> do something,
> rather than only if nothing is wrong. In particular matching dies not
> support input type checking.
>
> If the actual input type is the formal type, it obviously
> matches. If the
> actual input type derives from the formal type, it also
> matches. If the
> actual input type shares a base type with the formal type (e.g.
> Object)
> then the match fails but reports no error since it could be one of a
> polymorphic family of match alternatives.
>
> It must therefore be possible to perform the type match
> independently of the
> cardinality/connectivity match.
>
> A solution to this is to add a new relationship 'self',
> conveniently drawn
> as a bi-composition in GME. If A contians B and B contains A
> then A is B.
>
> With a 'self' relationship the connectivity/cardinality may
> establish the
> match for the base type, which will succeed. Then a 1:1
> 'self' relationship
> from the base-type to the intended derived type will succeed
> if the type
> osok, and a separate 1:0 'self' relationship from the base-type to the
> intended type will succeed if the type check fails. This
> therefore acts as
> an if-then-else to support error diagnosis locally, end
> ensure that a match
> did exist hierarchically.
>
> Regards
>
> Ed Willink
