Another point that was raised in discussions here, is related to Package.

In the first day of re-modeling :), Package had a superclass called DeployableEntity, but then we could not really find another subclass that cannot be modeled as Package.

Also we could not find a good name for the superclass: Deployable means it can be deployed, but we need a name that also says that things can be put/deployed in it.

So, all in all we removed the class. But, if any of you can give some good candidates for stuff that is similar to Package, we can put it in.

Just to show that we discussed a bit :), Jar does not really fit in this hierarchy, but rather in a FileSystem hierarchy, in which entities can be filedIn, and not packagedIn.

Cheers, Doru

On Oct 18, 2007, at 4:05 PM, Tudor Girba wrote:

To open the discussion, I vote to rename StructuralEntity to VariableEntity :).

Doru

On Oct 18, 2007, at 4:03 PM, Toon Verwaest wrote:

...

Hi,

Find in attachment the first open draft version of the FAMIX 3.0 metamodel. Review and comments welcomed!

cheers, Toon<FAMIX3.0.pdf>_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/

"Sometimes the best solution is not the best solution."

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/

"No matter how many recipes we'll know, we'll still value a chef."

...

To open the discussion, I vote to rename StructuralEntity to VariableEntity :).

why? What is a variableEntity?

A Girbasonian neologism :) whereas "structural-" and "behavioural-" are used terms in modelling, compare eg to UML's StructuralFeature and BehavioralFeature.

AA

this is true that variableEntity would be better than structuralEntity

stef

On 19 oct. 07, at 10:06, Tudor Girba wrote:

This was mainly just a mail to stir things up :).

Yet, I still remember asking myself when I came to Bern, why is a class not a structural thing. And given that all subclasses describe different types of what we call variables, one possibility is to name the superclass accordingly.

Doru

On Oct 19, 2007, at 9:04 AM, Adrian Kuhn wrote:

...

...

...

To open the discussion, I vote to rename StructuralEntity to VariableEntity :).

why? What is a variableEntity?

A Girbasonian neologism :) whereas "structural-" and "behavioural-" are used terms in modelling, compare eg to UML's StructuralFeature and BehavioralFeature.

AA _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/

"Obvious things are difficult to teach."

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

BTW toon gabi is at my place right now and I discover that you were belgium and bot argentinian :).

So if you want to drop by when you come back to your home country and show us what you you did during your master, I would be really happy. We are at lille :)

Stef

This is the core, there will be package extensions for C++, Java, Dynamoose etc...

AA

----- Original Message ----- From: "Michele Lanza" michele.lanza@unisi.ch To: "Related to the development of Moose and other related tools" moose-dev@iam.unibe.ch Sent: Thursday, October 18, 2007 4:59 PM Subject: [Moose-dev] Re: FAMIX 3.0 draft v0.8

looks cool..what happened to "Function"?

M

On Oct 18, 2007, at 16:03 , Toon Verwaest wrote:

...

Hi,

Find in attachment the first open draft version of the FAMIX 3.0 metamodel. Review and comments welcomed!

cheers, Toon <FAMIX3.0.pdf> _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Just a silly question: why don't we take EMOF as a starting point for FAMIX3.0 since they already spent months rying to design it? We could remove and add what we need.

Stef

Good point! actually it does not look soooo different from MOF (without E!) I started there when I prepared the redesign, but returned back to doing some stuff again as in Famix 2.2 to keep the diff smaller.

AA

You are right, the standard should specify that as well.

There are two ways to do it

a) model class side with (modifiers includes: #static)

b) model class side as seperate FAMIX.Class instance

In FAMIX 2.2, we from SCG did a) and other groups did b) I personally would prefer to suggest solution a) as default.

AA

On 19 Oct 2007, at 9:30 , Lukas Renggli wrote:

Even if I am just a lurker here, I dare to ask a question ...

How do you model classes and meta-classes?

Does a class know if it is a meta-class?

Does a class know is meta-class and vice versa?

I always found the current implementation a bit strange in that respect, but maybe this is just my Smalltalk centric view? ;-)

Lukas

-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

This is just some extension to UML that I made to show the opposite of an attribute.

So, in this case, the sender attribute in Invocation is of type BehaviouralEntity and has an opposite in the outgoingInvocations attribute in BehaviouralEntity.

Cheers, Doru

On Oct 19, 2007, at 9:08 AM, Stéphane Ducasse wrote:

I do not understand

Invocation sender: BehavioralEntity -> outgoinginvocations

---

How should I read that?

-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/

"To lead is not to demand things, it is to make them happen."

ok I thought so but I wanted to be sure.

On 19 oct. 07, at 10:08, Tudor Girba wrote:

Any entity can be packagedIn in a Package, and a NamedEntity can belongTo a ScopingEntity.

The extendedIn part should come as an extension to the current core :).

Doru

On Oct 19, 2007, at 9:08 AM, Stéphane Ducasse wrote:

...

How can I say that a class belong to a namespact is defined in a package and is extended in others?

-- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/

"Every successful trip needs a suitable vehicle."

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

A comment on half of the questions...

On (29/10/07 12:25), Yann-Gaël Guéhéneuc wrote:

From: Yann-Gaël Guéhéneuc guehene@iro.umontreal.ca To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch Subject: [Moose-dev] Re: FAMIX 3.0 draft v0.8 Date: Mon, 29 Oct 2007 12:25:46 -0400

Dear all!

I read with great interest the proposal for the FAMIX meta-model 3.0. Here are my two-cent comments. Please, bear in mind that I am a totally newbie when it comes to FAMIX :-)

First, some questions regarding the notation: what does it mean when an attribute is prefixed with a "/", like "/isRead" and "Access"?

This means it's a derived property. isRead can be derived from the value of isWrite since it's some sort of an enum.

Do I understand correctly that "sender: BehaviouralEntity -> outgoingInvocations" in "Access" means that "Access" defines an attribute named "sender" of type "BehaviouralEntity", pointed by the attribute "outgoingInvocations" of "BehaviouralEntity"?

the first part yes, the -> means that outgoingInvocations is the opposite of sender. In other words, the field outgoingInvocations in BehaviouralEntity will contain Accesses; and in the BehaviouralEntity we link to in a specific sender-tag, will contain the specific access in it's outgoingInvocations. (I hope it makes sense to you now :))

psuedo-code: (anaccess (id 1) (sender (idref 2))) (abehaviouralentity (id 2) (outgoingInvocations (idref 1)))

Why is "Package" not a "ScopingEntity", at least in Java, with respect to modifiers, it seems to me that packages define a scope?

package is mearely structural. In java this means that creating a package creates 2 things at the same time. It creates a packages + a namespace with the same name. Where the namespace is the scoping entity, and the package the structural one.

I understand the rationale for putting back references, such as "belongsTo" in "ScopableEntity" but it feels to me more an implementation choice to ease navigating the models rather than a true concept that must be represented in the models. (Also, it may make it harder to build models.)

Most of the time, one of both is / -> deriveable.

Why don't the "BehaviouralEntity" have a "returnType"?

Huh? Types? :)

Cheers, Toon