Hi, I'd expect something rigor here: associations between profile and user element should never be navigable from the profile element. (This includes: no user associations between profile elements.)
An example: java.lang.String from the Java profile. A user class of course can have associations to String, it can even be composed of Strings. But String can never have knowledge of that user class, like it is the case in Java. So the assotiation must be modelled in a way that a profile element will never have knowledge of a user model element. Of course the association itself must be in the user model. That's my opinion. Thomas -------- Original-Nachricht -------- > Datum: Fri, 1 Aug 2008 17:46:29 -0400 > Von: "Tom Morris" <[EMAIL PROTECTED]> > An: [email protected] > Betreff: Re: [argouml-dev] Question on non-editable profiles > On Fri, Aug 1, 2008 at 4:27 PM, Bob Tarling <[EMAIL PROTECTED]> wrote: > > We're working to the point that a profile can't be edited, only the > users model. > > > > But what happens when the user draws some association between his user > > model and some element in the profile. That is surely changing the > > profile as the class there will have a reference to the association > > end of the association. > > There are three elements involved in this scenario. As long as the > Association is placed in a namespace contained in the user model, > there will be no trace of it in the profile. > > > I tried saving and loading expecting to see some sort of error but > > this seemed to work. I guess MDR corrects the profile model when it > > detects the association on load (or do we do this). This is good as I > > can see we need to do such things as model the user model relationship > > to profile elements by association, I had worried that we could only > > include profile elements in the user model as attributes. > > > > I wonder if we need some enforcement of the relationships though. > > > > Some experimentation shows me that the user can draw an association > > between two elements in the profile. Should that be allowed? > > It should be allowed if the association isn't place in the profile > model, but I would have expected that by default an association > between two elements in the same namespace would also be placed in > that namespace. > > > Should we also control direction of relationship between user model > > and profile to ensure that, as an example, an association can only be > > unidirectional from user model to profile? > > I think it's more about composition than navigability. As long as the > Association doesn't get placed in the profile model, we should be all > set. > > Note that one of the big changes from UML 1.3 to UML 1.4 was to > eliminate navigability one direction from a bunch of different > relationships in the metamodel so that things would work reasonably > among federated repositories, and, by extension, between loosely > coupled models. > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
