Hello Tom!
The "support multiple loaded subsystems" requirement that you mention, how
can it best be solved?
Because Andreas started discussion of the uml2 UMLFactory I am focused on
the createXXX() functions here.
My first thought is that we need to have a mechanism providing the
information, when createXXX() is called, what model subsystem implementation
the newly created object belongs to. Either we need several factories
running at the same time and some way of knowing which to use or we must
remove the use of the createXXX() functions in favor of the
buildXXX(whatever) functions that create an object with its relation to some
other object.
My second thought is that we would like to support cut'n'paste between the
model subsystems and that means that we will have the mechanism in place to
move objects between the model subsystem implementation. For that reason it
is not important if the object is created in the correct or in the wrong
subsystem. When the object is connected to the model, it can be moved to the
other one. We could even let the createXXX() functions provide "empty"
objects and create the object in the implementation when the object is
connected to the model (Lazy Initialization pattern) but that would mean
that we introduce an extra object for each model object.
We are, as always in this discussion, torn between doing it right and doing
it in a simplest possible way. Because of our historical experience of
having two model repositories becoming unsupported, I have some kind of
mental block and would like to stick our layer of interfaces. This to
prepare for the next repository that we want to integrate but it is
appearant that this is extra work.
/Linus
2009/5/28 Tom Morris <[email protected]>
> Perhaps the use of my name was only to catch my eye so I'd be tempted
> to respond (in which case it worked!), but just to set the historical
> record straight, the Model API was defined long before I joined the
> project.
>
> As I understand it, it was created as a first step to isolate direct
> access to the Novosoft UML 1.3 library (NSUML) which was scattered
> throughout the code, in preparation for the move to UML 1.4.
>
> My major contributions were the UML 1.4 MDR implementation with
> Ludovic, eliminating duplicate methods, extending the API to support
> UML 1.4 functionality, beginning to extend it to UML 2.x, deprecating
> obsolete methods, etc. In other words, maintenance and cleanup of
> what was, for the most part, already defined.
>
> Because stability of the API is key, I did *not* change a lot of
> things which arguably need fixing. If anyone is going to seriously
> consider major compatibility breaking changes, I'd recommend starting
> fresh with a clean sheet of paper, probably with an API largely
> machine generated from the UML metamodel (which would, of course, lose
> all your UML version isolation/compatibility).
>
> Some other things that need changing (but aren't worth the cost):
>
> - make the API more object oriented. The current "every element
> handle is just an Object" style is a hack
> - make the API more granular. Having huge interfaces like Facade is crazy.
> - make the API definition interface only with no required concrete classes
>
> Something that I would like to see fixed to help with the migration to
> UML 2.x by allowing both UML 1.4 and UML 2.x models to be open is:
>
> - support multiple loaded Model subsystems which can be selected at
> runtime on a per-project/model basis
>
> Although all my major contributions are EPL licensed now, I'd be
> willing to help collaborate on a BSD licensed version of the API which
> supports this last goal (as well as needed UML 2.x extensions, of
> course). That would allow Model subsystems which are written for
> ArgoUML and those written for ArgoEclipse to continue to remain
> compatible.
>
> Tom
>
> ------------------------------------------------------
>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356334
>
> To unsubscribe from this discussion, e-mail: [
> [email protected]].
> To be allowed to post to the list contact the mailing list moderator,
> email: [[email protected]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2356660
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
