Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[gmt-dev] Debugger principles

Hi All

Turning an Excel box communication into a thread.

>>>Jorn Bettin suggested that we need:
>>>Debugging interface for model transformations

>>Ed Willink replied:
>>Good idea, but how?

>Jorn Bettin replied
>A viewer that plugs into Eclipse. Details to be specified

Obviously it needs to be in Eclipse.

A debugger needs to operate at our level of source abstraction.

Thus an assembler debugger steps instructions.

A language debugger steps statements/procedure calls.

A transformation debugger must step matches and possibly builds too.

In stepping a match, it should be possible to advance
	one 'box' on the transformation diagram
	one complete match
	one transformation and all its nested transformations

Between steps, I must be able to view the information model, and
see the prevailing candidates for matches. Hopefully I can also
experiment with matches interactively.

This is all to try to support the major transformation problem of

Why didn't I get a match for ...
Why did I get a match for ...

This clearly needs to operate within the context of a UML(X) diagram
if that is the users chosen input, so it must work within a GUI-model tool.

Provision of this is very hard until we have a GUI-model environment that
we're happy to develop from - one that is part of Eclipse.

There may be a more tractable solution to this problem in the short term.
If we have a textual form, we can use more conventional interfaces.

Option 1) We use a textual form of UMLX. Given sufficient flexibility,
I might be prepared to call this a template language.

Difficult because graphics is 2D, and the match generator chooses an
evaluation order. Text is 1D, so a chosen match could be confusingly
ordered.

Option 2) we use a compact textual form to present the compiled matching
algorithm, so that single stepping is linear in 1D.

Once we have debugged our debugger on the text representation, we may then
be
able to map this back through a GUI-model interface.

	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.


Back to the top