[Uml-devel] Fw: UML Modeller

[Jonathan Riddell]

> > I am working on another project called OSSET wich is a set of open source
> > software development tools.  It will include among other things a UML
> > modeller, code generators, and IDE integration.  I want to separate the
> > different systems allowing them to be run alone or in tandem.

This UML Modeller includes a modeller, code generators and IDE integration
has been talked about and should come along before too long.

> > 1.  Do you have any UML diagrams that I can view that will allow me to see
> > your current architecture?

As in UML diagrames of the code to the UML diagram programme.  No, but
this is something I would hope to soon after I got back to university (mid
september).

> > 1.  It will only run on linux.

It should run where ever KDE runs.

> This is very important but I would also
> like
> > my tools to run on winbloze.  KDE uses QT and I think it could be written
> to
> > run on any QT platform.

There isn't /too/ much reliance on KDE but I like KDE (and I think other
people do to) and if it's going to go in KDE CVS (3.2?) then it'll have to
be KDE.
Of course there are ways of getting KDE programmes to run under windows if
you're braver than me.

> A comment on this, I haven't been able to compile
> > UML Modeller on my Caldera linux box.  Because I have no printer I have no
> > kprinter.h file and the libs aren't compiled with printing support.

That's not a physical printer problem, that's because it requires KDE 2.1
(or it might be 2.2). CVS required KDE 3.  This basicly seems to be how
KDE is.

> > 2.  I see that you will support code importing and generating.  I would
> shy
> > away from doing this in your modeller.  The best way to do this is when
> your
> > modeller supports XMI you can save the diagrams in XMI format and then
> read
> > the XMI file into a generator that interprets it then generates code.  To
> > import a importing program will transform the code into an XMI file that
> is
> > read into your modeller.  This is the reason XMI is around and will
> separate
> > the responsibilities for the modeller/tools.

The CVS version does have XMI.  We should be making a release as soon as
Sourceforge allow us (hmm).  I do like the idea of generating code from
XMI rather than the programmes internal structure but.

> > My modeller would be a strictly compliant UML modeller.  It will do
> nothing
> > more than read/write/modify UML models in XMI format.  It will follow the
> > Model/View/Controller pattern to allow flexibility in many areas, e.g.
> allow
> > the integration into a suite of tools by separating the canvas, menu,
> > toolbars and such into components whos layout can be adjusted to suite the
> > needs of the application.

This is already mostly the case.

> > It will be able to model more than just object oriented systems.  UML can
> be
> > used to model many different systems, e.g. a MetaObject Facility
> model(MOF),
> --skip--
> > The tool will be customizable by reading a UML Profile and using the
> profile
> > -- skip --
> > It will support the Object Constraints Language.  This is in the UML
> > specification and is used throughout the UML metamodel(MOF) to specify
> > additional semantics that cannot be added any other way.
> > --skip--
> > CORBA support is something I am debating.  On the plus side it would allow
> > the developer to modify a model that is located in a repository on a
> remote
> > server.

That's all good stuff.  I would say that it could be done more by
evolution and gradual adding of features.

Hope that kind of helps

Jonathan Riddell