[gme-users] Large number of entities in GME models

[Simon Görke]

Thanks to both of you; 
Maybe some words about the background of our concept:
The idea to use GME not only as a "human-machine interface" at the top level
but also at lower layers originated from a practical view:
The software which is to be configured by this tool is rather complex and
the knowledge on it is distributed over several software engineers. 
Each of them has expert knowledge on the insides of "his/her" module but
only superficial knowledge on the rest. 

Configuring the modules means defining the complete dataflow between them.
The problem is that the person who conceives the configuration tool needs
fairly good knowledge of *all* software modules (not only interfaces but
also interdependencies). This is especially demanding when bigger changes
within a module are necessary (e.g. the software is adopted to match another
project) 
We hope that using a combination of 
- models to describe the interfaces and the interna of a software module (as
far as it is needed for its configuration) 
- and rules to decribe the dependencies
may help here (each engineer models his/her module and this model helps to
define the dependency rules).

We had an internal discussion heading in a similar direction Larry argued.
However in the end we decided that apart from the point above, GME offers
many features which might also be useful at "lower" levels (including the
possibility to have a simple "look" at the output of a generation run).

Regards,
Simon

 

> -----Ursprüngliche Nachricht-----
> Von: gme-users-bounces at list.isis.vanderbilt.edu 
> [mailto:gme-users-bounces at list.isis.vanderbilt.edu] Im 
> Auftrag von Akos Ledeczi
> Gesendet: Donnerstag, 3. Januar 2008 16:46
> An: A list for GME users to share thoughts and discuss bugs and fixes.
> Betreff: Re: [gme-users] Large number of entities in GME models
> 
> And then there are those of us who disagree :) In many 
> situations I would generate GME models automatically and use 
> the features that come with GME for free. Why bother 
> implementing persistence etc. if you do not have to?
> 
> On the other hand, scalability is the big issue. If 5000 is 
> the maximum number of objects that ever needs to be 
> supported, then it should be OK. 
> Somewhere beyond that GME will slow down, memory will be scarce etc. 
> Where exactly the limit is depends on the paradigm, the models etc..
> 
> Hope this helps,
> Akos
> 
> 
> Larry Howard wrote:
> > Simon,
> >
> > In my experience, it is always better to consider generation as an 
> > aspect of outbound processes.
> >
> > If the generation of the lower-level objects is computationally 
> > expensive, making on-the-fly generation unattractive, then I would 
> > stage the outbound processes by generating a lighter-weight object 
> > representation and use file-based persistence.
> >
> > In no conceivable situation would I generate back into GME. 
>  Even if 
> > the scalability of the GME/COM representation was better, such an
> > approach is not paradigmatic.   Use models to represent and persist 
> > specifications that humans declare and refine.  Use computation for 
> > everything else.
> >
> > Regards,
> > lph
> > --
> > Larry Howard, Sr. Research Scientist
> > Institute for Software Integrated Systems, Vanderbilt University
> >
> > On Jan 3, 2008, at 7:10 AM, Simon Görke wrote:
> >
> >> Hello everybody,
> >>
> >> We are currently developing a GME-based configuration tool for 
> >> distributed embedded systems.
> >> The idea is
> >> - to have one (relatively simple) GME model at the top 
> (system level) 
> >> which is built up manually, i.e. by an engineer
> >> - to have some more layers of models below
> >> - in each layer: to use and refine the information stored in the 
> >> model and automatically fill the model one level below.
> >>  This step is realized by using rules which are formulated 
> in Python 
> >> scripts and control GME via its COM interface.
> >> - The lowest model represents our software implementation 
> which makes 
> >> it easy to export actual configuration data (e.g. c header files)
> >>
> >> While the top level model is quite simple, the lowest 
> modelling level 
> >> will consist of approx. 2000 (automatically generated) entities.
> >> Does anybody have experience with such huge numbers of 
> elements in a 
> >> model?
> >> We did a simple script which creates 5000 atoms and connects them 
> >> among each other, however it is difficult to do quick test of the 
> >> parsing of such a model. Anybody tried something like this?
> >>
> >> Thanks,
> >> Simon
> >>
> >> _______________________________________________
> >> gme-users mailing list
> >> gme-users at list.isis.vanderbilt.edu
> >> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
> >
> > 
> ----------------------------------------------------------------------
> > --
> >
> > _______________________________________________
> > gme-users mailing list
> > gme-users at list.isis.vanderbilt.edu
> > http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
> >   
> _______________________________________________
> gme-users mailing list
> gme-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
>