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'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().
I've had some further thoughts while working on activity diagrams of
what might be better in a new implementation or maybe even to adapt
what we have.
Typically to add a new UML2 element to the activity diagram I'm having
to modify the MetaTypes interface and add to its MDR/EUML
implementations things like getControlFlow() and
getCallBehaviourAction() etc. This is needed as that value is recorded
in the diagram tools action and passed to the UML factory to create
the correct element.
I'm also having to add recognisers to Facade for isControlFlow() etc
so that the diagram can check what type of element has just been
created and decide on the correct Fig.
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");
This means we have a concrete object with specific methods to operate
on for a meta type rather than just using Object as we do at the
moment and relying on some utility method in another class to do the
operations on it.
The MetaType interface would have methods like the following on that
object rather than having to pass some dumb object to a utility method
String getName() - return the identifying name for this metatype (eg,
"Class", "Interface", "CallBehaviorAction")
String getLabel() - return an i18n label for this metatype
Icon getIcon() - return an icon that represents this metatype
Class getNativeClass() - return the actual EUML or MDR class that is
wrapped inside this object (package scope only we don't want this used
outside the model implementation)
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)
boolean instanceOf(MetaType type) - As above but for another MetaType
rather than a string identifier.
boolean create(Object owningElement) - create a new element instance
of this metatype owned by the given element.
boolean create(Object element1, Object element1) - create a new
element instance of this metatype as a relationship joining element1
and element2
boolean create(Object[] elements) - create a new element instance of
this metatype as a relationship joining multiple elements
With the above done I could have a toolbar Action that just takes a
MetaType name as a constructor argument. That action can be reused for
all tools, it will just call the factory of the MetaType to create the
element when required. There is no need to change the model interface
when a new metatype is added.
The GUI becomes simple and reusable.
The model interface become more stable.
We start the process where we are replacing at least some dumb Objects
that have to call some utility method for functionality with concrete
objects with methods of their own.
The compile time safety lost due to using String literals to identify
meta types is unfortunate but we really have no compile time safety
anyway. What use is the supposed compile time safety of
Model.getFacade().getAttributes(myObject) if it possible for that
method to throw an exception because it wasn't passed the correct
object type.
I'd like to get this wiki-ed. Are there any thoughts from others before I do so.
The model implementation is going to take a severe bashing anyway to
get to UML2. Is there any object from anyone if I was to implement
some of this sooner rather than later.
Regards
Bob
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2634658
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]]
