On Sun, Jul 18, 2010 at 8:29 AM, Bob Tarling <[email protected]> wrote:
> Its always seemed bizarre to me that we are producing a tool to aid
> designing Object Oriented systems that we sometimes fail so much
> ourselves in OO design.
>
> The fact the the model interface forces everything outside the model
> subsystem to refer to our most important objects (the model elements
> themselves) as Object is terrible.
I agree.
> I've mentioned before the idea of wrapping the native MDR/EUML object
> in some class of our own so that we have for example an ElementFacade
> interface with basics such as getName(). This isn't a utility class
> like our current facade but a class that wraps each instance of a UML
> element. So there is no need to do
> Model.getFacade().getName(myObject), you just do myElement.getName().
Rather than wrapping, the idea I've had in the back of my mind for
this is dynamic decoration of objects with additional
methods/interfaces in the factory where they are created. I believe
this is what MDR does to create objects which not only have its
reflective JMI APIs, but also methods that align with arbitrary
metamodels which are loaded at run time.
> The following is the alternative I'm considering
>
> Introduce a MetaType interface, implementations of which would be a
> wrapper around the MDR or EUML class that represents the meta type in
> very much the same way that I have previous suggested wrappers around
> model elements.
>
> We can get a specific MetaType like this -
> Model.getMetaType("CallBehaviourAction");
> Model.getMetaType("Class");
...
> boolean instanceOf(String type) - allow us to test what type of meta
> type this is (could test for concrete such as "Class" or "Interface"
> but also abstract types like "Classifier" etc)
You're losing all the compile time checking by using these strings.
This syntax is also more verbose than just a plain old 'instanceof'
keyword. It would be better to leverage the Java type machinery so
you can use generics and all the rest of its power.
The real question I think is whether the differences between UML 1.4
and UML 2.1 are too big to paper over with a single interface.
Certainly Use Cases are pretty simple and Classes can probably be made
to work, but once you start to get into the more esoteric stuff, I
don't know how well it will hold together.
Tom
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2636731
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]]
