[MonoDevelop] UML Modeler for Monodevelop

[Dishan]

Thanx a lot for the Tip.
I'm  Applying for GSOC for a project on a separate UML Modeler add-in for
Monodevelop and i'm planning to base
that on MonoUML so i'm going to look in to nUML as well.

But i do not think the Class Designer (Which i'm also proposing for) would
be based
on any type of specific UML model.

i would greatly appreciate if any one could give me some Pointers on the
Data Base Designer as well.

Thank You.

On Mon, Mar 30, 2009 at 9:08 PM, Mario Carrion <mario.carrion at gmail.com>wrote:

> On Sun, 2009-03-29 at 00:34 -0700, Michael Hutchinson wrote:
> > 2009/3/28 Manuel Alejandro Cerón Estrada <ceronman at gmail.com>:
> > >> There is a standalong peroject called Mono.UML, though AFAIK it has
> > >> not been active in several years.
> > >
> > > True. The project has been inactive for years. I'm one of the
> > > developers of MonoUML. We've been working on a framework for
> > > structured graphics that could be the base for this kind of
> > > applications. It's called MonoHotDraw
> > > (http://www.monouml.org/doku.php?id=monohotdraw)
> >
> > Yep, I'm aware of MonoHotDraw.
> >
> > >> I don't believe anyone is working on anything in this area at the
> > >> moment. I'd be happy to mentor a student who applies for this.
> > >
> > > I'm applying for the class designer this year.
> >
> > Oh, that's excellent news. Are you applying for other projects too?
> >
> > >> We are also very interested in a database designer, and I belive that
> > >> it would be good to implement a "designer canvas" for visualising
> > >> objects with relationships, that could be used for both a database
> > >> deigner and a class designer. I'd suggest basing this on Moonlight as
> > >> the retained mode 2D canvas. This re-usable component would be a good
> > >> mid-term goal, then the class designer could be built on top of it.
> > >
> > > Moonlight is really cool. But currently its GTK support is not working
> > > and work on the top of a project like moonlight is sometimes very
> > > difficult. That's why I proposed MHD instead.
> >
> > Hmm. What are the issues blocking it? Will they still be blocking it
> > when SoC starts? I'd prefer to fix or work around them (and factor
> > that into the project evaluation), simply because using Moonlight will
> > be easier to develop and mantain going forwards. I'm sure you can get
> > up to speed faster using MHD, but maintainability is a big concern
> > with SoC projects. In the worst case, you could do much of the work
> > inside Silverlight -- which would open up the interesting possibility
> > of having the "class explorer" functionality usable on the web :-)
> >
> > (I'm not opposed to using MHD, I'd just like to be sure it's the best
> option)
>
> (I'm also one of the developers behind MonoUML)
>
> I just want to let you know that if you are willing to implement a
> UML-based canvas you may need to use nUML[1], in MonoUML we use nUML
> intensively to define constraints and magic needed to support Models,
> Diagrams, XMI support and so on. I've been updating nUML to UML 2.2
> and .NET 3.5 so you can use recent changes any fancy linq syntax and all
> the new features found in 3.5. nUML trunk uses the older 1.1 profile,
> but using the newer profile will not affect anyhow,
> branches/numl-research contains the recent updates, however a lot of
> work (tests mostly) is missing.
>
> Mario
>
> [1] http://numl.sourceforge.net
>
>
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>



-- 
Dishan Metihakwala.
Department of Computer Science and Engineering.
University of Moratuwa.
0772240195
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20090331/1f6383b8/attachment-0001.html