Hello Bob!
Yes, there will be a lot of changes to the Model interface when moving
towards UML2.
The metatypes
You are suggesting to create a new set of classes/objects in the Model
subsystem to represent each of the meta types. I consider this a replacement
of the tokens that represent each meta type (that today are classes).
>From the quick look at two examples on how meta types are used
(org.argouml.diagram.uml2.UMLClassDiagram2.java line 463 (and the same for
org.argouml.uml.diagram.static_structure.ui.UMLClassDiagram) and
org.argouml.uml.diagram.use_case.ui.UMLUseCaseDiagram line 423 (and the same
for uml2)) these tokens are immediately passed along to general code.
Because of this I don't understand why this change is required to have an
action that is reused for all tools, it seems we already have this (except
that it is a token that is registered instead of a name). Is it the problem
with the assumption that these are Classes that is the problem?
Because of the compile-time safety I prefer
Model.getMetaTypes().getUseCase()
to
Model.getMetaTypes().getNamedMetaType("UseCase") (that is more or less what
you are suggesting)
I consider this change a small one.
The big difference is in the functions of the return value. Let me examine
your suggestion of operations:
String getName() - return the identifying name for this metatype (eg,
"Class", "Interface", "CallBehaviorAction")
This is natural.
String getLabel() - return an i18n label for this metatype
This will make the Model subsystem depend on the i18n code. I don't think
this is a good idea.
Icon getIcon() - return an icon that represents this metatype
This will make the Model subsystem aware of how model elements are
represented graphically. I don't think this is a good idea.
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)
If this is package scope, then it is an internal issue within the EUML or
MDR subsystems if this is required or not. We shouldn't need to discuss or
describe it.
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)
If these objects are found using a String, this is the natural counterpart.
I would prefer a compile-time alternative if it could be found.
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
I don't understand how these three create methods can exist. Are you
thinking casts to get the right kind of object type? Should they throw
something if they are not appropriate.
>From this point of view, I have no objection to this but I'd prefer if this
new object could be used also for the old methods in
Model.getMetaTypes().get*(). That way we would not need to map from Strings.
The bigger picture
Both MDR and EUML (and before that NSUML) have interfaces that are generated
from a model description. In attempting to map both MDR and EUML at the same
time to the rest of the ArgoUML code, we are essentially building a new
ArgoUML interface that the rest of the ArgoUML code work against and that we
are mapping to within the MDR and EUML model implementations. This is what
we are facing if we want to solve the general problem.
Where are we going with the Model subsystem? Will it have an
ArgoUML-specific model? Will it disappear? Please be clearer about the
road-map so that we can make the right intermediate decisions!
/Linus
On Sun, Jul 18, 2010 at 2:29 PM, 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'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]]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2635599
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]]
