To open the discussion, I vote to rename StructuralEntity to VariableEntity :). Doru On Oct 18, 2007, at 4:03 PM, Toon Verwaest wrote: -- www.iam.unibe.ch/~girba www.iam.unibe.ch/~girba/blog/ "Sometimes the best solution is not the best solution."

looks cool..what happened to "Function"? M On Oct 18, 2007, at 16:03 , Toon Verwaest wrote:

Sounds good. I have problem to read the document Why this is not UML (because you generate it) I do not understand -------------------------- Invocation sender: Behavioral -> outgoinginvocations -------------------------- How should I read that? I do not understand why the receiver of an invocation which is a namedENtity has to be in package. for example if I have self or super as receiver do we have to say that this is in a package and all the rest? For expressions most of the time you do not have modifiers, name, pakagedIn... For example foo := (super new with: #(jklhklh kjhhkjhjkh) size. Is there a relation between name and packagein? Why the variables do not hold value? or I do not get it. How do you model that Transript is referencing an instance of TranscriptStream and that it is references by a lot of methods (incomingAccesses) I do not understand how you can express that foo is defined in a different package than its class. How can I say that a class belong to a namespact is defined in a package and is extended in others? 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

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"? 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"? Now, some thoughts :-)... Why have an attribute "sourceAnchor" in "Entity", why not use a Decorator to add such "external" data? The role/concept of the entity named "Association" is confusing with respect to "traditional" UML where an association is a relationship between two or more entities, why not categorise the sub-concepts of "Invocation", "Access", "Reference" as "MethodConstituent" or "BehaviouralEntityConstituent"? The attribute "candidates" seems to me very much Smalltalk oriented :-) I agree it is more general but... ;-) Why are modifiers in "NamedEntity" represented as String*, why not use classes? Why is "Package" not a "ScopingEntity", at least in Java, with respect to modifiers, it seems to me that packages define a scope? 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.) Why is there a "GlobalVariable" entity? Why don't the "BehaviouralEntity" have a "returnType"? Cheers! Yann-Gael PS. I join two pictures representing our PADL meta-model and other classes and their related DP for comparison :-) -- Yann-Gaël Guéhéneuc Ph.D. et ing. jr. / Ph.D. and jr. eng. Professeur adjoint / Assistant professor DIRO, Université de Montréal 1-514-343-6782 (Téléphone / Phone) C.P. 6128, succursale Centre-Ville 1-514-343-5834 (Télécopie / Fax) Montréal, QC, H3C 3J7, Canada www.ptidej.net