Hi Richard,
See my comments
inline.
Eric
From: Richard
Craddock (rcraddoc)
Sent:
Tuesday, February 19, 2008 8:34 AM
To: Eric
Dillon (erdillon)
Cc: Jim Strawn (jistrawn); Duncan Keysell (dkeysell)
Subject: Some
questions.
I raised bugs where I could. Heres a
variety of thoughts/questions
[ER>]
I’ve addressed 219420, 219444, 219450, 219454, 217823, 217825. This will be in
tonight’s nightly build.
1. What is the option "Cascade
Delete References" for in the Preferences/General tab for ? I've never noticed
it before......
[ER>]
I initially couldn’t remember what this could be, but I remember talking with
Chris about this case: when deleting an artifact from the model that has
incoming or outgoing associations, these associations/relations are currently
left “dangling”. This option mean that all relationships would be removed as
well. I am unclear as what is really implemented, so I would be in favor of
removing this option from the GUI until we can vouch for what it really means
L.
2. I think we need to review the
OSS/J settings in the "factory default" profile - the OSS/J specifics appear
unless you turn them off - should be the reverse ?
[ER>]
Agreed. The OSSJ settings should all be turned off by
default.
3. On Method we have a method called
getMethodReturnName() - is might be simpler to just have
getReturnName()
[ER>]
Please make the change.
4. I seem to remember that
*somewhere* in the code you can query an AbstractArtifact to see if it supports
Methods, Constants etc. This might be quite handy to add to the API. And add a
similar thing to say if it has Ends.
[ER>]
As discussed briefly on the phone today, I think it makes sense to provide a way
to “introspect” the artifacts. This will be needed/available from the EMF
implementation later on. I was hoping to get around to doing it today… not sure
anymore. I’ll send you an email if I do finish this
tonight.
5. Isn't the refBy stuff really an
OSS/J specific ?
[ER>]
Hmmm…. This needs to be thought thru. It should indeed be considered as an OSSJ
extension in the metamodel, but it is currently embedded quite deeply in the
core, so we have look at the consequences…
6. On an associationEnd - there is
no current method to say if it is the AEnd or ZEnd of a relationship - I'm not
sure exactly what this truly means in context as the navigability are the truly
useful things, but we have had to do some (admittedly simple) checking whenever
we want to get the "otherEnd". Maybe a couple of methods could be added isAEnd()
isZEnd() ?
[ER>]
I believe there is a getOtherEnd() method on the implementation of
IAssociationEnd. It should simply be a matter of pushing this into the
IAssociationEnd Interface and it should do the trick?
7. (Warning - Modelling question!) Still on the
associationEnd - we have Multiplicity, but we also have a type which has
multiplicity - the TypeMultiplicity is always 0..1 - should that be 1, or is it
really irrelevant?
[ER>]
Yes. This is a bit redundant. IAssociationEnd exposes a multiplicity, and the
IType on that end does too. For consistency we should probably use the IType one
only. Also, we need to look into migrating the current Enumeration-based
multiplicity to support arbitrary bounds (upperBound,
lowerBound).
8. (This is very minor) when I add
an attribute to an artifact it generates the names attriubute0, attribute1,
attriubute2 . If I then switch artifact, it starts at attriubute2
....
[ER>]
Yes, a little annoyance indeed, maybe there is a “static” somewhere we should
remove J.