Do we have enough information to start this work? Can I start by creating
classes and interfaces or drawing class diagrams?
/Linus
2010/10/6 Bob Tarling <[email protected]>
> Hi Linus
>
> I think we shouldn't align ourselves to tightly to any structure as
> the OMG could then break us at any time in some future release. Much
> of own package structure is based around UML1.3 which makes little
> sense now. We should think of our needs for these interfaces first.
>
> However chapter 9 of the MOF Core Specification (06-01-01) is closest
> to what I have in mind for the first level level wrapper. However
> there would be some differences.
>
> 1. I would have add and remove methods as well as the set method
> specified here so that we can easily things like add operations to a
> class.
> 2. I would have MetaType class, instances of which would be the factory
> classes
> 3. I would have no Package at this level
> 4. I would have have methods such as canAdd and canSet so that a
> caller can test what the particular UML element version being wrapped
> is able to contain (e.g. UML 1.4 would return false when testing
> attribute in an interface whereas UML2 would return true)
> 5. The factory methods of MetaType will take an existing element as an
> argument. The newly created element will be assigned to that existing
> owner as soon as it is created. This prevents the possibility of
> creating a model element and having it left outside the model.
>
> Using the above I think the XML property panels would shrink down in
> code size massively as there is a lot of work in there at the moment
> that is effectively one big switch statement to determine.which
> specific methods of the model interface to use.
>
> If we can also drive the Figs by XML then we will have the same result
> there.
>
> "Element" then becomes the most basic type of object we pass around
> representing a UML element rather than our current use of a dumb
> Object as a token.
>
> I'm currently wondering if there are other things we should allow at
> this level that can be done with any Element. e.g. Provide methods to
> get Stereotypes and TaggedValues and define the interfaces for those
> here also.
>
> The RepositoryFacade level would be extensions of the Element from
> RepositoryInterface and would only be a small subset of the model
> elements available in UML2. There is no need to create some of the
> more esoteric elements used by activity diagrams and state diagrams if
> the diagram code doesn't need it and the property panel code doesn't
> need it.
>
> Bob
>
> On 6 October 2010 06:19, Linus Tolke Tigris <[email protected]> wrote:
> > These two levels, do they fit well with the UML2
> > Infrastructure/Superstructure-separation?
> > /Linus
> >
> > Den 6 oktober 2010 03.14.53 UTC+2 skrev Bob Tarling <
> [email protected]>:
> >>
> >> Sorry for spending so long getting back to this I've been rather
> >> preoccupied with work matters.
> >>
> >> Although we have problems in adapting the to the EUML repository my
> >> gut feeling is that creating our own would not be the right way to go.
> >> Some way of auto-generating a wrappers around EUML may be useful
> >> though.
> >>
> >> We have a very limited team here and it would worry me that we are
> >> stretching ourselves too far to develop our own model or if we lose
> >> the required skills to do so we have gone too far down one path. In
> >> theory there should be far more than our small team working on
> >> improving the tools within eclipse.
> >>
> >> Our biggest problem at the moment does not appear to be with the model
> >> itself but with actually creating the new diagram types for UML2. I'm
> >> finding it difficult to find the time myself at the moment.
> >>
> >> I recently raised issue
> >> http://argouml.tigris.org/issues/show_bug.cgi?id=6161 - if we could
> >> get our diagrams to construct themselves by interpreting some XML file
> >> in a similar way to how our properties panels now build I think we can
> >> reduce much of our the effort in future and reduce the overall code
> >> size.
> >>
> >> I still think we also need to consider an alternative interface to our
> >> current model interface (facade). History and problems with the model
> >> interface can be found here -
> >> http://argouml.tigris.org/wiki/Model_Interface_History and here
> >> http://argouml.tigris.org/wiki/Model_Interface_Criticisms
> >>
> >> I'm still putting all my arguments together for what I've been
> >> referring to as the Repository Interface. I think that interface
> >> requires a lot less detail than either UML1.4 or UML2 would suggest we
> >> need. For the property panels much of the code doesn't care about the
> >> model element its dealing with. It just looks up in the XML of what
> >> needs to be displayed and calls the model interface to get the detail.
> >> It doesn't actually go as far as I'd like with this, I think I can
> >> move more logic into the model that is currently in the property panel
> >> module.
> >>
> >> Once the GUI of ArgoUML is XML driven the code then becomes a lot more
> >> generic. Double clicking an compartment of a compartmentbox need only
> >> determine the model element that owns the compartmentbox (owner) and
> >> they type of compartmentbox clicked (type) and do -
> >>
> >> type.createElement(owner);
> >>
> >> For what I have documented so far on the Repository Interface see -
> >>
> http://argouml.tigris.org/wiki/Repository_Comparison_With_Model_Interface
> >>
> >> There has been some criticism that such an interface would be
> >> difficult to use for more specific tasks that are not driven by some
> >> XML file. For example our code generation and reverse engineering code
> >> would likely become quite clunky looking if there weren't more
> >> specific classes and methods available.
> >>
> >> Typically though this would be limited to those classes that correlate
> >> to programming languages such as Class, Interface, Attribute,
> >> Operation, Parameter etc. These have remained fairly static between
> >> UML releases and where they do differ has been easy to code around. I
> >> agree that for these some more specific interfaces would required and
> >> for this I'm considering another layer on top of the Repository
> >> Interface, the Repository Facade.
> >>
> >> This layered approach makes sense to me, the first layer being as
> >> simple as possible wrapping and hiding the repository implementation
> >> (MDR or EUML) and the second layer adding just enough detail to make
> >> the interface easier to use (the true purpose of a facade which I fear
> >> we fail with in our current model facade). Use of either layer by
> >> ArgoUML should be valid.
> >>
> >> Regards
> >>
> >> Bob
> >>
> >> ------------------------------------------------------
> >>
> >>
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2668353
> >>
> >> 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=2668503
>
> 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=2668598
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]]
