[gme-users] GME tutorial question: a paradigm for routers that
have a fixed set of ports?
John K Black
John_K_Black at Raytheon.com
Wed Aug 16 16:36:42 CDT 2006
Sandeep, Zoltan, and Akos,
Thank you very much for your responses. GME is an
*amazing* tool, and I'm having a lot of fun seeing what
it can do.
The "macro" capability you speak of would be a very nice
and useful feature. With macros I could accomplish most
of what I am looking for -- e.g., letting modelers drop
pre-built 4-port routers into a model.
However, if I understand the idea correctly, macros won't
by themselves let GME enforce the clean separation of one
layer of abstraction from another.
For example (refering to the tutorials), if I build a model
with the networking paradigm, I am constrained to using the
constructs that the networking paradigm provides. I can't
drop down to the MetaGME layer and use "atoms" or "FCOs"
without changing the networking metamodel.
This separation is nice, because it constrains the kinds of
models that can be made with the networking paradigm, and I
(the metamodeler) don't have to write constraints to explicitly
prevent modelers from accessing "dangerous" low-level MetaGME
If I understand the macro idea correctly, it sounds like
a macro that allows a modeler to drop a pre-built,
pre-validated 4-port Yoyodyne 9000 router into a model would
(I think) be part of the networking paradigm rather than part
of a new higher-level paradigm that sits on top of networking.
So, you'd have a sort of mix of levels of abstraction in the
networking paradigm: macros at a "high" level, and "routers" and
"ports" at a "low" level. Is that right?
-----gme-users-bounces at list.isis.vanderbilt.edu wrote: -----
To: "gme-users" <gme-users at list.isis.vanderbilt.edu>
From: "Sandeep Neema" <sandeep.neema at vanderbilt.edu>
Sent by: gme-users-bounces at list.isis.vanderbilt.edu
Date: 08/16/2006 01:51PM
Subject: RE: [gme-users] GME tutorial question: a paradigm for routers
thathave a fixed set of ports?
This multi-layered abstraction that you refer to below is something we
are interested in as well. One of the enabler capability that we have
identified is the need for macro constructs. So the idea is that users
should be able to augment the basic construct set (i.e. model, atoms,
connections) with user-defined constructs such as a model with four
ports. So then your "Yoyodyne ..." router could be present in the part
browser as a pre-built block, and when you create an instance of it, you
get a model with four ports already in it.
Zoltan, could give you some more details on the implementation status of
Senior Research Scientist,
Institute of Software Integrated Systems, Vanderbilt University
Email: sandeep.k.neema at vanderbilt.edu
> -----Original Message-----
> From: gme-users-bounces at list.isis.vanderbilt.edu [mailto:gme-users-
> bounces at list.isis.vanderbilt.edu] On Behalf Of John K Black
> Sent: Wednesday, August 16, 2006 12:41 PM
> To: gme-users
> Subject: RE: [gme-users] GME tutorial question: a paradigm for routers
> thathave a fixed set of ports?
> Hi Ace and Zoltan,
> Thank you both for your thoughtful responses.
> As Ace mentioned in his response, I am interested in
> creating a domain specific modeling language that lets
> users model *with* routers -- not a DSML for or
> *creating* routers themselves.
> I have tried using MetaGME to model specific routers,
> but so far my attempts to do have been only partially
> successful. For example, I can create a "Yoyodyne 9000"
> router that shows up in the GME Parts Browser. When it
> is dragged onto a diagram you can double-click it and the
> Parts Browser shows exactly the fixed set of ports that
> are associated with the Yoyodyne 9000. Unfortunately,
> this approach still requires that the model drag the ports
> from the Parts Browser into the router. That's not how
> I'd like my DSML to behave. I don't know if this is a GME
> limitation, or if it's just because I have a messed
> up metamodel.
> I've experimented with Zoltan's ideas, and they work fine.
> However, the copy/pasting approach is a little awkward.
> The idea of having a separate UI that can manipulate
> the model by automating the cut and paste or by letting
> users pick pre-configured model elements from a palette
> is interesting. Could GME's scripting capabilities would
> be of any use in automating the insertion of preconfigured
> model elements?
> In the end, I'm looking for a way to cleanly separate the
> various levels of abstraction, so modelers only see the
> abstractions(s) they need to see. At the lowest level
> there is MetaGME. Layered on top of it would be a DSML for
> constructing routers. Layered on top of that is a DSML
> for modeling *with* routers. (I've left out other details
> like connections, etc., but I hope the idea is clear.)
> Of course if I build a separate UI as Zoltan suggested,
> and tell the modelers to use my UI and not to use the
> GME Parts Browser, then I suppose I could sort of achieve
> the effect that I'm looking for.
> BTW, I'm not *really* interested in modeling routers,
> especially the "Yoyodyne 9000" ;^) I'm just sticking with an
> example that lots of GME users are probably familiar with.
> -----"Ace Thompson" <acethompson at igniteweb.net> wrote: -----
> >To: "'John K Black'" <John_K_Black at raytheon.com>
> >From: "Ace Thompson" <acethompson at igniteweb.net>
> >Date: 08/15/2006 06:40PM
> >Subject: RE: [gme-users] GME tutorial question: a paradigm for
> >routers that have a fixed setof ports?
> >Mr. Black,
> >After I sent my response, I realized that the suggestion for using
> >library feature to model your "built-in" constructs really bumps
> >into your last comments in your email: that you'd like a language
> >modeling _with_ routers, not for creating the routers themselves.
> >Clearly using the library approach would pull you into building a
> >both for modeling routers and for modeling with routers, at least to
> >extent. Of course, the other approach involves using meta-GME to
> >routers, which might be a worse alternative depending on how much
> >will be involved; depending on your needs it may be easier simply to
> >a corner of your language that just won't be used too often by the
> >(i.e. the "model routers" part). I have done this in a number of
> >in order to allow myself a degree of flexibility rather than
> >something into the language. Of course the benefit depends on how
> >"hard-coded" something is (or not), and also on how your other tools
> >work with the user models...
> >At any rate, good luck (again),
> >-----Original Message-----
> >From: gme-users-bounces at list.isis.vanderbilt.edu
> >[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of John
> >Sent: Tuesday, August 15, 2006 2:24 PM
> >To: gme-users at list.isis.vanderbilt.edu
> >Subject: [gme-users] GME tutorial question: a paradigm for routers
> >that have
> >a fixed setof ports?
> >I've been working through the long GME tutorials, and have
> >a question about the way "Routers" are modeled.
> >Suppose I want to provide the modeler with a paradigm
> >that includes router models that are *preconfigured* with
> >a standard set of ports, so that when the router is dragged
> >from the parts browser it is not necessary to manually add
> >the ports. In other words, suppose all of my routers always
> >have exactly ports "e0", "e1", and "s0", and I don't want
> >the modeler to have model that, nor do I want the modeler
> >constructing his or her own router. The modeler should
> >simply drag the router from the parts browser and connect
> >it up.
> >Sort of like grabbing an IC from a parts bin.
> >Is there a way to accomplish this with GME?
> >For those familiar with CoSMIC and PICML, I've looked at how
> >idl2picml imports IDL3 constructs and partially builds a PICML
> >model. The modeler can then select components from the model
> >browser to build CCM applications. The modeler can also work
> >with PICML constructs from the parts browser to build new
> >components. So, with PICML and idl2picml you can both model
> >components and model with components.
> >That's not really what I want to do. I would like to build a
> >paradigm that is good for modeling with routers, but not for
> >creating models of routers.
> >John Black
> >gme-users mailing list
> >gme-users at list.isis.vanderbilt.edu
> gme-users mailing list
> gme-users at list.isis.vanderbilt.edu
gme-users mailing list
gme-users at list.isis.vanderbilt.edu
More information about the gme-users