Please find attached the latest PDF of FAMIX.Core beta
more informations will follow cheers, AA & Hani
Dear all!
I hope you are doing well! Thanks for this new version!
Here are some thoughts and question...
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?
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
Adrian Kuhn wrote:
Please find attached the latest PDF of FAMIX.Core beta
more informations will follow cheers, AA & Hani
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
First of all, thanks for your fast and thorough feedback!
On 15 Nov 2007, at 21:07 , Yann-Gaël Guéhéneuc wrote:
Dear all! I hope you are doing well! Thanks for this new version! Here are some thoughts and question...
After a 15 hour long long travel I am back in Switzerland ... there is train strike in France in Germany.
Why have an attribute "sourceAnchor" in "Entity", why not use a Decorator to add such "external" data?
Do you suggest to use a decorator pattern at the --model-- level? Since, at the --implementation-- level you are always free to use any pattern to store properties (instvars, a global dictionary (my favourite), wide classes, decorators, dynamic inst vars, etc...).
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"?
You are right, what about calling it Relation? (as we already have Entity, that would make also the ER analogy complete).
The attribute "candidates" seems to me very much Smalltalk oriented :-) I agree it is more general but... ;-)
There was a long mail recently why you need that also for Java, as it is not redundant unless you expect tools to re-implement the lookup logic of any language.
Why are modifiers in "NamedEntity" represented as String*, why not use classes?
You mean an enumeration?
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.)
belongsTo is derived, hence it is only relevant for implementation and will not show up in .mse files (names starting with / indicate derived attributes).
Why is there a "GlobalVariable" entity?
Why don't the "BehaviouralEntity" have a "returnType"?
Because we forgot ... it is back now, thanks!
cheers, AA
Cheers! Yann-Gael
Adrian Kuhn wrote:
Please find attached the latest PDF of FAMIX.Core beta
more informations will follow cheers, AA & Hani
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- 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 _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Adrian Kuhn wrote:
Please find attached the latest PDF of FAMIX.Core beta more informations will follow cheers, AA & Hani
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
What is the point of above/below in Association? The only thing I can think of is an extra abstraction for all those different types of "from/to" in the subclasses, but in that case the type and opposite seems very strange so I guess it's something else?
On 16 Nov 2007, at 15:35 , Toon Verwaest wrote:
What is the point of above/below in Association? The only thing I can think of is an extra abstraction for all those different types of "from/to" in the subclasses, but in that case the type and opposite seems very strange so I guess it's something else?
It is the source code order of invocations (the placement in association is incorrect, it should be pushed down to Invocation, as we do not want that for all associations).
AA
On Nov 16, 2007, at 23:57 PM, Adrian Kuhn wrote:
On 16 Nov 2007, at 15:35 , Toon Verwaest wrote:
What is the point of above/below in Association? The only thing I can think of is an extra abstraction for all those different types of "from/to" in the subclasses, but in that case the type and opposite seems very strange so I guess it's something else?
It is the source code order of invocations (the placement in association is incorrect, it should be pushed down to Invocation, as we do not want that for all associations).
I think that such information, in static analysis, is related to one behavioural entity: a List of ordered invocations --> a BehaviouralEntity (Method). So, Adrian, I suggest removing above/below and ensuring that the type of outgoingAccesses and of outgoingInvocations in BehaviouralEntity is List (the order should conform the order in the code)
Hani
AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev