MetaCase Homepage
Forum Home Forum Home > > MetaEdit+
  New Posts New Posts RSS Feed - meta edit and rule based reasoning
  FAQ FAQ  Forum Search   Events   Register Register  Login Login

meta edit and rule based reasoning

 Post Reply Post Reply
Author
Message
grossd View Drop Down
Member
Member


Joined: 17.Apr.2012
Points: 2
Post Options Post Options   Thanks (0) Thanks(0)   Quote grossd Quote  Post ReplyReply Direct Link To This Post Topic: meta edit and rule based reasoning
    Posted: 17.Apr.2012 at 13:03
I've been asked by an RE consultant to help build a DSL for mapping input
to output attributes in a requirements document. From my early
experimenting with MetaEdit+, I can see how i/he can simply define
a I/O mapping DSL.

I am however wondering do you know if MetaEdit+ was used in
conjunction with some kind of rule based reasoning, to analyze for
example, how changes in input definitions affect outputs and
vice-versa.

One could, for example, envision having MetaEdit+ generate
Prolog "data" clauses, which are then analyzed using some predefined
goal seeking backtracking ... was something like this already done?
Could results be fed back into MetaEdit+ to produce reports?
Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 305
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 17.Apr.2012 at 14:06

Sure, quite a lot of customers have some kind of mapping DSL. We also have cases that generate Prolog facts, which are then processed by the customer's rules to identify the best solution and output it. In the cases I know, the output is some kind of code or data file, not something that is imported back into MetaEdit+.

Getting the output into MetaEdit+ is no problem - you can either output in the MXM Model XML format and import that, or then have Prolog or another program call the MetaEdit+ API to modify the existing models or create new ones.

Feeding the results back into MetaEdit+ to create models may however leave you open to the old problem of editing generated results, rather than the original source. Obviously there's no way to ensure the original model and the transformed results model remain in sync - unless the transformation is a simple bijection, which sounds unlikely if you're using Prolog.

You say you want the results fed back into MetaEdit+ "to produce reports". Maybe you can get the desired report straight out of Prolog? It's maybe no harder than having Prolog produce the results in MXM format. Alternatively, maybe the result from Prolog is small and simple, and the final report is something that needs to combine that with the original models. Depending on the balance between the two parts, you could either have Prolog do the combining (it presumably has most of the model info already, and any extra bits could be included in the original generation from MetaEdit+), or then you could have Prolog write its part of the results in a simple text file, and then read that with MERL and combine it with the model data:

  1. generate Prolog data
  2. run Prolog rules on data with external..executeBlocking,
    producing a text file, e.g. in .ini-style, key=value
  3. read Prolog result into variable $PrologResult:
         variable 'PrologResult' write
            filename 'PrologResult.txt' read
         close
  4. iterate over model and $PrologResult, parsing with regex translators:
       foreach .Input
       {   id '>'
           do $PrologResult
           {   if id%key = id;1 then id%value endif
           }
           newline
       }

The translators use regular expressions to identify and output the left and right sides of the .ini mapping:
   to '%key'   newline '/([^=]+)=(.*)/ $$1' endto
   to '%value' newline '/([^=]+)=(.*)/ $$2' endto

If there's a lot of data, you can improve the O(M*N) performance of step 4 to O(M*logN) by parsing the $PrologResult lines into variables first:

   do $PrologResult { variable id%key write id%value close }
   foreach .Input { id  '>'   variable id%key read   newline }

Back to Top
grossd View Drop Down
Member
Member


Joined: 17.Apr.2012
Points: 2
Post Options Post Options   Thanks (0) Thanks(0)   Quote grossd Quote  Post ReplyReply Direct Link To This Post Posted: 17.Apr.2012 at 14:38

Hello Steve,

Thank you for the prompt and detailed response. 

I guess, without having seen the actual requirements just yet, whether its necessary to feeding back data to meta edit will in the end depend on how changes to mappings are indicated.  This could perhaps be done interactively, by visually indicating possible changes to input attributes, in models, before  actually making them, and then run an analysis and view the results in generated change models; or perhaps indicating the changes as an external report only. 

I guess if one wants to reduce the learning curve of the scripting language, could working in prolog against the API to retrieve (and later add to) the model (or just parse an XML export) be a viable option?

thank you,

Dan

Back to Top
stevek View Drop Down
MetaCase
MetaCase
Avatar

Joined: 11.Mar.2008
Points: 305
Post Options Post Options   Thanks (0) Thanks(0)   Quote stevek Quote  Post ReplyReply Direct Link To This Post Posted: 17.Apr.2012 at 15:22
Hi Dan,
 
MERL is easier to learn and use than the API, and is much faster at runtime too. I wouldn't use the API to retrieve 'the whole model', if there is the option of using MERL to output the model in a format suitable for easy import by your program.
 
Like the MetaEdit+ UI, MERL hides the details of the MetaEdit+ data structures, but the API reveals them and thus requires you to understand them. Because MERL is inside MetaEdit+, the tools can provide a lot of context and understanding to help you build and debug the generators. The API is used from outside, and the MetaEdit+ end can't see your full program, only each call as it comes in; similarly your program can't see MetaEdit+, the metamodel or model, only the result of each call, so there's very little context to help you write and debug the programs. Obviously I'm not against the API in any way - it's great when you need it. I'm just guessing which is the best route for you now.
 
The learning curve for MERL is mostly about learning to think in terms of navigating through the model, and of producing a stream of output. That's a bit different from OO, imperative or functional programming, but not complex in itself. The code I wrote above is rather advanced MERL, so don't let that put you off! MERL's sweet spot is turning models into text, and so using it there is a lot simpler.
 
To return to your first paragraph: you can also make the symbols display differently depending on properties or generator results. Since there will be lots of attributes and lots of mappings, running Prolog on the fly for each isn't an option :), but reading a text file produced on request by Prolog might be, as might running Prolog on request to change properties via the API. But I guess you need to see the actual requirements first and then decide what kind of interaction is necessary for visualization and experimentation. Certainly showing results simply in text format is the best way to go at the start, since it's easiest to do and can be reused to build more advanced interaction functions later.
Back to Top
 Post Reply Post Reply
  Share Topic   

Forum Jump Forum Permissions View Drop Down

Forum Software by Web Wiz Forums® version 10.14
Copyright ©2001-2012 Web Wiz Ltd.

This page was generated in 0.469 seconds.