UML Modeller/Code-Generator?

Hi,

I am considering to move to Dolphin Smalltalk. Are there any tools, which
help me writing code-concepts in UML (or similar) and then let me generate
the code (and back again, aka "round-trip engineering")?

Thanks for your help!

Andreas

--
Andreas Brodbeck
www.mindclue.ch

Andreas Brodbeck wrote:

> Are there any tools, which
> help me writing code-concepts in UML (or similar) and then let me generate
> the code (and back again, aka "round-trip engineering")?

It doesn't look like it.  Certainly, I don't know of any myself.

FWIW, I don't think there's a lot of demand for such tools (even without
round-tripping -- which is especially difficult in Smalltalk).  The attitude
that UML diagrams only belong on the backs of envelopes, or scribbled on
whiteboards, seems to be very common among Smalltalkers.

    -- chris

Chris, Andreas,

> It doesn't look like it.  Certainly, I don't know of any myself.

Take a look at DOME, but a quick scan suggests that it's a VW project.


> FWIW, I don't think there's a lot of demand for such tools (even without
> round-tripping -- which is especially difficult in Smalltalk).  The attitude
> that UML diagrams only belong on the backs of envelopes,

That much planning is usually sufficient in Smalltalk, because there is
so little punishment for being wrong about details.  Further,
Smalltalk's "true" polymorphism (there's that Smalltalk bigotry
again<g>) allows things that would not work elsewhere to work in Smalltalk.

There are situations in which it is very nice to have (perhaps semi-)
automatic code generation, but those often seem involve external
interfacing, and are not redesigned so much as they are regenerated if
something changes.  Dolphin's type library analyzer is a great example.
  I have several home-grown tools based around the CodeGenerator package
that is available on my web site.  CodeGenerator does very little on its
own, other than offer a way to preview and conditionally compile
"chunks" created by more specific tools based on it.


 > or scribbled on
> whiteboards, seems to be very common among Smalltalkers.

Whiteboards are great - even better now that I have a digital camera to
capture what I scribble on them :)

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:

> > FWIW, I don't think there's a lot of demand for such tools (even without
> > round-tripping -- which is especially difficult in Smalltalk).  The
> > attitude that UML diagrams only belong on the backs of envelopes,
>
> That much planning is usually sufficient in Smalltalk, because there is
> so little punishment for being wrong about details.  Further,
> Smalltalk's "true" polymorphism (there's that Smalltalk bigotry
> again<g>) allows things that would not work elsewhere to work in
> Smalltalk.

I agree. But I'd rather put it the other way around: some other languages
impose static restrictions that break perfectly good code ;-)


> There are situations in which it is very nice to have (perhaps semi-)
> automatic code generation, but those often seem involve external
> interfacing, and are not redesigned so much as they are regenerated if
> something changes.  Dolphin's type library analyzer is a great example.

Indeed.  And <advt> my own JNIPort </advt> does something similar but more
dynamic.


>   I have several home-grown tools based around the CodeGenerator package
> that is available on my web site.  CodeGenerator does very little on its
> own, other than offer a way to preview and conditionally compile
> "chunks" created by more specific tools based on it.

I've recently got around to starting work on "Grunt!" which is tool I've been
meaning to hack together for /years/; the idea is to generate and preview code
from "templates" which are stored in external files. I really must take a
proper look at CodeGenerator (which I'd forgotten all about) before I spend any
more time on it...


>  > or scribbled on
> > whiteboards, seems to be very common among Smalltalkers.
>
> Whiteboards are great - even better now that I have a digital camera to
> capture what I scribble on them :)

Using a camera is cheating!  (If, unlike me, you ever look at digital pictures
after you've taken them ;-).

    -- chris

Chris,

> I agree. But I'd rather put it the other way around: some other languages
> impose static restrictions that break perfectly good code ;-)

I stand corrected :)


> I've recently got around to starting work on "Grunt!" which is tool I've
been
> meaning to hack together for /years/; the idea is to generate and preview
code
> from "templates" which are stored in external files. I really must take a
> proper look at CodeGenerator (which I'd forgotten all about) before I
spend any
> more time on it...

Don't be disappointed - CodePreview would be a better name.  CodeGenerator
does very little on its own; it is the result of an excellent suggestion of
Ian's to programmatically compile classes and methods rather than to create
chunks to file-in.  Given the right tools creating the "chunks" for it, it
has been _very_ useful.  Depending on the situation (and how often I use the
tool in question), I either embed one or more CodeGeneratorResultsPresenters
in a wizard, or simply open it as a shell at the end of skirmish.  Migrate
and 'MVP generators base' should give you some examples.  While
ViewGenerator is pluggable, it is really intended to be subclassed.

In addition to goodies that use CodeGenerator, I have some code that writes
what CodeGenerator would need to create an existing method.  That is
probably not in my posted goodies, but I will try to dig it out for you.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> > I've recently got around to starting work on "Grunt!" which is tool
> > I've been meaning to hack together for /years/; the idea is to generate
> > and preview code from "templates" which are stored in external files. I
> > really must take a proper look at CodeGenerator (which I'd forgotten
> > all about) before I spend any more time on it...
>
> Don't be disappointed - CodePreview would be a better name.  CodeGenerator
> does very little on its own;

I've taken a look now.  It's nice stuff.  It doesn't work in the way that I
want Grunt! to work -- my emphasis is on /templated/ generation -- but there
are some good ideas there from which I can learn (read: that I plan to
steal ;-)  Thank you!


> In addition to goodies that use CodeGenerator, I have some code that
> writes what CodeGenerator would need to create an existing method.  That
> is probably not in my posted goodies, but I will try to dig it out for
> you.

Thank you, but please don't bother.  It's not really a necessity in a templated
tool, and anyway recovering a template from an example would be a rather
different problem.

But an /interesting/ problem...  Hmm...  Starting from:

Input = "XAutomationAspect"
Output =
----------------
visitAXAutomationAspect: anAXAutomationAspect
 "private -- visit an AXAutomationAspect as part of the visitor pattern"

 "default is to treat it as an Aspect"
 ^ self visitAspect: anAXAutomationAspect.
----------------

And then inferring the template:

----------------
visit<%Source%>: <%aSource%>
 "<%privacy%>visit <%a Source%> as part of the visitor pattern"

 "default is to treat it as <%a Superclass%>"
 ^ self visit<%Superclass%>: <%aSource%>.
----------------

Is just too much /fun/ to leave out, especially for the more complicated
templates that (may, eventually) generate methods like #queryCommand: and
#createComponents:...

    -- chris

Chris,

> I've taken a look now.  It's nice stuff.  It doesn't work in the way that
I
> want Grunt! to work -- my emphasis is on /templated/ generation -- but
there
> are some good ideas there from which I can learn (read: that I plan to
> steal ;-)  Thank you!

Happy stealing :)  Please do not feel obligated to use anything as-is, but
you might find that you could have a generic filter that turns your
templates into method source that the various "chunk types" understand, and
then use the preview/compile features unchanged or with some small
additions.


[snip]
Well, fun comes in many forms :)  Good luck though, because it could be
quite useful.


>  especially for the more complicated
> templates that (may, eventually) generate methods like #queryCommand: and
> #createComponents:...

I've found that #createComponents: can be generated as a by-product of
pasting the view resources (ViewGenerator has the pieces to get started),
but I make no claim to a general solution for the other stuff.  So far, my
ViewGenerator subclasses have been able to add what I needed.  Specifying a
template might be a nice option, though I suspect it would need to be able
to take some stream or collection inputs??

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> I've found that #createComponents: can be generated as a by-product of
> pasting the view resources (ViewGenerator has the pieces to get started),
> but I make no claim to a general solution for the other stuff.  So far, my
> ViewGenerator subclasses have been able to add what I needed.

I make no such claims for Grunt! either -- it's "use cases" are the things that
/I/ have become tired of typing in repeatedly.  An attempt to alleviate the
tedium for the Dolphin community a whole is not one of the deliverables of this
project ;-)

Still, I will probably put it on my website once it's a bit less green.


> Specifying
> a template might be a nice option, though I suspect it would need to be
> able to take some stream or collection inputs??

Yes, the underlying generator currently takes a String as an input[*], or -- if
it contains a looping construction -- a collection of Stings, and produces the
source to one method as output.  The tool itself has three main panes.  A
"source selection" pane, where you nominate a collection of strings.  You can
select a class and use, say, its instance vars, or the names of the
sub-presenters from the View resources, or you can generate the strings from
code in a workspace.  An "operation" pane, where you select the destination
class, and can choose and edit the template.  Lastly a "preview" pane, which is
nothing special unless/until I really do have a go a generating templates from
examples (I'm still tempted, but I want to let the template "language"
stabilise first).

[*] May change to be a Dictionary....  The design hasn't quite "set" yet ;-)

    -- chris