![]() |
meta edit and rule based reasoning |
Post Reply
|
| Author | |
grossd
Member
Joined: 17.Apr.2012 Points: 2 |
Post Options
Thanks(0)
Quote Reply
Topic: meta edit and rule based reasoningPosted: 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? |
|
![]() |
|
stevek
MetaCase
Joined: 11.Mar.2008 Points: 305 |
Post Options
Thanks(0)
Quote Reply
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:
The translators use regular expressions to identify and output the left and right sides of the .ini mapping: 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 } |
|
![]() |
|
grossd
Member
Joined: 17.Apr.2012 Points: 2 |
Post Options
Thanks(0)
Quote Reply
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 |
|
![]() |
|
stevek
MetaCase
Joined: 11.Mar.2008 Points: 305 |
Post Options
Thanks(0)
Quote Reply
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. |
|
![]() |
|
Post Reply
|
|
|
Tweet
|
| Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |