- how to reset the metamodel
- how to run lint rules
- what are the lint rules for metamodel
On 7 juin 2011, at 16:18, Johan Fabry wrote:
+1 on that. Having selected e-mails as a reference/documentation on-line is much better
than having to search the mailing lists.
On 07 Jun 2011, at 05:26, Tudor Girba wrote:
> Yes :)
>
> Doru
>
>
> On 7 Jun 2011, at 11:20, Simon Denier wrote:
>
>>
>> On 7 juin 2011, at 09:53, Nicolas Anquetil wrote:
>>
>>> I was discussing with Usman yesterday about these emails to the list that are
also documentation artefacts.
>>>
>>> It would be nice to have a mean to flag such emails (manually) so that they
can form collectively some documentation of Moose that would be easier to search in than
the entire mailing list archive.
>>
>>
>> I think the simplest solution would be to copy-paste the email on the website,
with just a bit of formatting. Is it ok?
>>
>>
>>>
>>> nicolas
>>>
>>> De: "Simon Denier" <simon.denier(a)gmail.com>
>>> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
>>> Envoyé: Mardi 7 Juin 2011 09:40:55
>>> Objet: [Moose-dev] Fwd: Re: Moose for SAS
>>>
>>>
>>> There was some questions last week about extending the Famix metamodel. I
just forward the following guide I wrote last year. It should be formatted and put online
too.
>>>
>>>
>>> Begin forwarded message:
>>>
>>> From: Simon Denier <Simon.Denier(a)inria.fr>
>>> Date: 24 juin 2010 18:21:34 HAEC
>>> To: Related to the development of Moose and other related tools
<moose-dev(a)iam.unibe.ch>
>>> Cc: Simon Denier <Simon.Denier(a)inria.fr>
>>> Subject: Re: [Moose-dev] Re: Moose for SAS
>>>
>>> Hi Ross
>>>
>>>
>>> It's true that the metamodeling tools in Moose seem crude compared to
what exist elsewhere, but that's because we spend much more time using metamodels in
new tools than building metamodels :)
>>>
>>>
>>> Here is the procedure when you need to define a completely new metamodel. You
can still make mistake when defining the metamodel but it eliminates most redundancy.
>>> Once you have defined your metamodel, a set of lint rules can be run to check
some aspects of the metamodel (see below)
>>>
>>> The essential pragma documentation is here (should be integrated in the
book)
>>>
http://code.google.com/p/moose-technology/wiki/FameMetaDescriptions
>>>
>>> Also, a good rule of thumb is to have MooseEntity as root instead of Object,
it facilitates integration with Moose tools.
>>>
>>>
>>> 1) Metamodel declaration
>>> For the example below:
>>> - Create class RPGDragon from a class browser
>>> - add (class-side)
>>> RPGDragon class>>annotation
>>> <MSEClass: #Dragon super: #Object>
>>> <package: #RPG>
>>>
>>> Notice I just define the method with pragmas, I don't add any code in the
body for now.
>>>
>>> For each attribute, I need to define the accessor (the getter, not the
setter):
>>> - define RPGDragon>>hoard
>>> <MSEProperty: #hoard type: #RPGTreasure opposite:
#keeper><multivalued>
>>>
>>> (same thing, method decl + pragma, no code)
>>> No need to add the initialize, it will be defined by the generator.
>>>
>>>
>>> 2) To generate the implementation, do:
>>> MooseModel generateClassesFrom: {RPGDragon. RPGHero. RPGWall}
"collection of classes defining the metamodel"
>>>
>>> It should open a preview window, where you can see which method will be
defined/overridden by the generator. You can always tap Cmd-x to remove the selected
definition (in case you are doing some incremental metamodel definition).
>>> You can repeat the generation step as much as you want, provided you
understand it will overwrite existing methods.
>>>
>>> It works like a charm if you are doing your own metamodel. If you need to
extend (as in class extension, not the Java extend for inheritance) some existing Famix
classes with new attributes, you should be a bit more careful. Actually, when I need to
extend an existing metamodel with a few attributes, I just define the attributes directly
in the Smalltalk way (with pragmas AND method body). It's fast to do.
>>>
>>>
>>> 3) optionally, check that your metamodel is correct with lint rules
(especially soundness of opposite relationships): can be done from the meta browser...
>>>
>>>
>>>
>>>
>>>
>>> On 16 juin 2010, at 22:36, Ross Boylan wrote:
>>>
>>> On Wed, 2010-06-16 at 22:14 +0200, Tudor Girba wrote:
>>> Hi Ross,
>>>
>>> On 16 Jun 2010, at 21:17, Ross Boylan wrote:
>>>
>>> On Wed, 2010-06-16 at 09:37 +0200, Tudor Girba wrote:
>>> As mentioned before, there is no support for graphical support for
>>> writing MSE files. The main reason here is that Smalltalk already
>>> provides a good enough solution for quickly building classes and
>>> methods, and annotating them is a practical solution.
>>> I gather there is no facility to generate the smalltalk out of the
>>> method annotations. Is there any reason, in principle, that it
>>> couldn't
>>> be done?
>>>
>>> Well, if you have the method annotations, you already have the
>>> Smalltalk code :).
>>> Consider RPGDragon>>hoard
>>> <MSEProperty: #hoard type: #RPGTreasure opposite: #keeper>
>>> <multivalued>
>>> ^hoard
>>> ^hoard is smalltalk code. You also have to create the instance
>>> variable, define
>>> hoard: aTreasure
>>> hoard value: aTreasure
>>> and
>>> initialize
>>> super initialize.
>>> hoard := FMMultivalueLink on: self opposite: #keeper:.
>>> killedBy := FMMultiMultivalueLink on: self opposite: #kills.
>>>
>>> It's the redundancy, along with the possibilities for error that would
>>> put the smalltalk and annotation out of sync, that concerns me (and that
>>> I'm trying to avoid).
>>>
>>> I do not in some other classes the names in the annotations and the
>>> names of the methods and variables are not quite in sync, so maybe this
>>> is a feature.
>>> Ross
>>>
>>> Right now, the only possibility is to generate Smalltalk code out of
>>> MSE code that represents your meta-model. This is like the famixCore
>>> string that you saw in the image.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>>
www.tudorgirba.com
>>>
>>> "Not knowing how to do something is not an argument for how it cannot
>>> be done."
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> Simon
>>>
>>>
>>>
>>>
>>> --
>>> Simon Denier
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> Simon Denier
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
>
www.tudorgirba.com
>
> "Problem solving efficiency grows with the abstractness level of problem
understanding."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Johan Fabry
jfabry(a)dcc.uchile.cl -
http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev